## 注意事項

- 勉強会の様子はリアルタイム配信 & 後日編集した動画としてYoutubeにて公開させて頂きます
- 顔出し NG の方は遠慮なくおっしゃってください
- ゴミは各自で持ち帰ってください

## お願い

- ハッシュタグ `#ペチオブ` で勉強会の様子を Tweet してね！
- [Discord](https://discord.gg/d3xxrYEKRD) への参加もお願いします！
- 今日は Zoom はありません
- [Youtube](https://www.youtube.com/@miraito) のチャンネル登録もぜひ！

## 参加者

### 開催する人
- hiro
- yuki
- takuma
- hoge

### 現地参加する人
- 白柳
- suzuki_mar

## テーマ
- RDRA 2.0 の中で何が最新化されたのか聞いてみたい ( 白柳 )
- 新メンバーを受け入れる時に RDRA がどう役に立つのか知りたい ( suzuki_mar )
- RDRA がないころから要件定義してきた人たちに RDRA で要件定義がどうかわったか聞きたい ( takuma )
- RDRA を理解してもらいながらお客さんと進めていくのが大変そう、導入コストとかどんな感じなんだろう ( yuki )
- ツールを使ってみて思ったことを他の人からも聞きたい ( hiro )
- 実運用ではどの順番で書いたりどこを繰り返したりするのか話してみたい ( hoge )

## 議事録

### RDRA 2.0 の中で何が最新化されたのか聞いてみたい ( 白柳 )
- 従来: パワポで図を書いて分析していく
- 図やアイコンの意味を理解できないと合意が難しい
- 最新: スプレッドシートにテキストを書いて、ツールで図を生成する
- 図をクリックすると詳細度を変えたり遷移したりできる
- RDRA をやるために覚えることが減った印象
- Notion で ( PlantUML とか ) で図を書いてるけど、楽そうだな
- RDRA は頭の中にある断片化された情報を明確にするためのツールだと感じる

### 新メンバーを受け入れる時に RDRA がどう役に立つのか知りたい ( suzuki_mar )
- RDRA は全体を整理できていると思うので役に立つんだろうなって思ってる
- RDRA は要件定義なので仕様の詳細ではない
- 全体を俯瞰で把握するのには向いている
- DB とかはわからないよ
- 登場人物とか UC とステータス遷移とか、そういうのは図が遷移できたりするのですごいわかりやすいと思う
- けど RDRA はドキュメントを作るためのものではないので、これだけで受け入れをできるわけではないと思う
- テキストの仕様書より図になっているのは直感的にはわかりやすい
- xxx 機能の実装者とかテスターとか、局所的な関わり方をする人には粗いという面もあるのかも？
- レンダリングが外部ドメインなので、会社のセキュリティポリシーに抵触しないかはちょっと心配
- LocalStorage だから大丈夫ということなはず
- そもそも GoogleDrive も外部だけど
- 図の配置が毎回変わっちゃうのがちょっと難点かも？
- ビジネスサイドの人やクライアントサイドの人と一緒に可視化するというのは大変有用
- 「確認します」みたいなのが多発してはっきりしていって良い
- RDRA は要件定義
- DesignDoc は設計や根拠
- 最新の RDRA を実案件でやってるけど、概念モデルは別であった方がいいと感じている

### RDRA がないころから要件定義してきた人たちに RDRA で要件定義がどうかわったか聞きたい ( takuma )
- 要件定義をやったことあるエンジニアってどれくらいいるの
- 人それぞれ内容も工程もまちまちだったりする
- 要件定義という単語が機能仕様を決めることを指していることがある
- どの画面に機能を足して DB をどうするか、みたいな
- 要望があって要求あって、限られたリソースで何を作るかが要件定義だと思っている
- ビジネスのこととシステムのことを両方わかる必要がある
- → ビジネス用の資料を作ります / システム用の資料を作ります ということになる
- → ビジネス資料ができたのでシステム資料も作りましょう、という流れになりやすい
- RDRA はどちら向けというのを分けず横断してやっていくので、そこがいいと感じている
- 一連をつなげて進めていけるところがいいかなと思っている
- 共通モデルと共通意識が作れるところがいいよね
- フレームワークであるというところが大きいと思う
- 「誰が」とか「何を」とか「いつ」とかを思いつきで整理すると、粒度がまちまちだったり考える順番が不適切だったりしてしまう
- シートを左から書いていくと順々に粒度が細かくなっていくよ、線が繋がっていくよ、みたいなレールがあるのは進めやすいなと感じた
- RDRA だけの特徴ではないだろうけど、フレームワークである利点は感じた
- やっぱり不慣れだとどこに何を書けばいいかわからないので、RDRA のシートを書くことに一生懸命になりすぎてしまうのではないかとも感じた
- 完璧を目指さないようにしよう
- RDRA の中のいいと思ったところだけ抜粋したという使い方をした時期があったなぁ

### RDRA を理解してもらいながらお客さんと進めていくのが大変そう、導入コストとかどんな感じなんだろう ( yuki )
- お客さんに RDRA とはを説明する必要はないのかもね
- 何をやりたいか何を整理するべきかを共通認識にできる方が大事
- 手を動かすのはお客さんも交えてやるべきだけど、RDRA レイヤーとはみたいなことを説明しなくてもいいかもね
- エンジニアだからビジネスサイドだからで RDRA シートの理解度が変わるものではない気がするな
- お客さんと一緒にやる作業では全部で発生するけどね
- 要件定義の必要性を理解してもらって一緒に要件定義できるようにすることも、要件定義スキルだよ
- 相手が理解してくれないので要件定義失敗しましたはプロではないよね

### ツールを使ってみて思ったことを他の人からも聞きたい ( hiro )
- 不整合が起こっていることがわかるのがいい
- シートの並びでやることの順番がわかるのがいい
- → いろいろループしてブラッシュアップするのも大事
- 図が出てくれるのでとっつきやすくなったしメンテコストはすごい下がったよね
- 似てるものの扱いに混乱したりした
- AI の部分があまり理解できなかった...
- 1 つは「シートを読まなくても日本語の要約が得られる」という点だったよね
- 図を描かなくていいの圧倒的なインパクト
- 初見でシートを書くのはハードル高い
- 目的わかってやらないと書くだけで終わってしまう、図の生成が目的になってしまう
- フレームワークとツールがしっかりしすぎているから、うっかりしてしまうことがありそう

### 実運用ではどの順番で書いたりどこを繰り返したりするのか話してみたい ( hoge )
- 基点は BUC なんじゃないか
- そこから登場人物 ( アクター ) とかに広げていく
- 書けるところから書いてもいいのでは
- RDRA レイヤの左からでいんじゃね

## 資料

## アンケートのご記入をお願いします！！

今後の参考にしたいので [こちら](https://www.noway-form.com/ja/f/afaf2623-3b77-4d73-9293-79ca14938511) からアンケートの記入をお願いします！！