昨年のことになりますが、アプリケーション開発におけるモデルベースの要件定義手法である「リレーションシップ駆動要件分析 RDRA2.0」の作者である神崎善司さん（@zenzengood）をお招きし、社内で勉強会を開催しました。
RDRA2.0についてはこちらを記事を是非ご覧ください。
リレーションシップ駆動要件分析(RDRA)
RDRA２.０についてまとめみた（前編）
RDRA２.０についてまとめみた（後編）
#参加者の声
参加者からのアンケートは以下のようなものでした。
相手（顧客）のレイヤーによっても、プロジェクトのフェーズによっても変わってくると思いますが、いかに相手に伝わる、相手に伝えるために考えられたフレームワークかということを感じられました。ぜひ今後この考え方を参考にさせてください。ありがとうございました。
少しお話もさせていただきましたが、私はUIデザインを担当する立場から今回のお話を聞かせていただき、大変勉強になりました。数え切れない数のシステムと要件定義が存在する中で、今回のような新しい手法が生み出されているということはそれだけ要件定義というもの自体に課題があるのだろうと実感しました。
「要件定義の段階でHOWを考えるとすべてにおいて手がとまる」と話されていたのが、個人的にとても印象に残りました。私もHOWまで考えていて、とても苦労しました。今回受講させて頂き、要件定義で何を可視化して、顧客に説明すればよいのかとても参考になりました。
ありがとうございました。
「決める」要件定義をするために、システムの機能自体だけを見て議論をするのでなく、依存関係を持つ外側のレイヤーから議論を進めていくという考えが勉強になった。現在、コードの修正をする際に他への影響調査に苦労することがあるので、今回の話の中にあった影響度分析がしやすくなるという点も良いと思った。1時間半の中で盛りだくさんの話を聞かせていただいたので、まだ内容を整理しきれていない面はあるが、学びが多く楽しい勉強会だった。
#要件定義で一番大切にするべきこと
結局RDRAでやりたいことは何なのか？書籍を読んだり何度かお話を聞ききつつ、実際に自分でも書いてみながら考えました。多分ポイントだと思うことを表現しているスライドを抜粋しました。
「一覧」→「詳細」型でタスクを割り振り、各担当者が相互連携して全体整合を維持しながらそれぞれの要件を深堀りしていくというのは、私の経験上理想でしかありません。
ほっておくとタコツボ化しがちなPJ作業において、常に全体像をわかりやすく表現し、かつそのつながりを検証できる価値は非常に大きいと思います。
「伝え方が９割」という本もありましたが、まさにシステム開発の要件もその典型です。利用ユーザーとベンダーとの境界がなくなり、全員で整合性と網羅性の担保を意識し続けられれば、大きな手戻りを要する要件不備は防げるはずです。「誰か一人の優秀なPMやSEに頼るのではなく、全員で要件の抜け漏れや不整合を防ぐー」全体をわかりやすく表現できる手段を持つことは、上流工程においてチームで品質を創り込む上で不可欠なツールと言えるでしょう。
#実際書いてみた
ある内製の社内システムの要件定義をRDRAで書いてみました。
書いてみた印象としては、業務階層を順次ブレイクダウンさせながらDFD的業務フローを書いている印象でした。慣れると結構サクサク進みますし、まったくRDRAの記述様式を知らない他のメンバーの可読性も高かったのが印象的でした。書式にのっとり書くのは多少ハードルはあるが、書いてあるものを理解することはさほど大変ではないことがわかりました。
また標準書式にはありませんでしたが、ビジネスユースケースに要件定義時に並行して作成したワイヤーフレームを添付させました。（図中のP6,P7,P10）弊社では要件定義時にデザイナーチームが参画しデザインテイストを加えながらワイヤーを書くことが多く、今回もそのアプローチをとりましたが、各画面がどういったシーンで利用されるかが俯瞰でき非常にわかりやすくなりました。
また継続して実践事例を重ねながら、ノウハウを共有していければと思います。