見出し画像

要件定義品質向上への突破口

中野ヤスオ｜ARI

先日、アプリケーション開発におけるモデルベースの要件定義手法として最近注目を集めている「リレーションシップ駆動要件分析 RDRA2.0」の作者である神崎善司さん（@zenzengood）をお招きし、社内で勉強会を開催しました。

「RDRA2.0」については以下を参考にしていただければと思います

参加者のアンケート結果

参加者のみんなにもアンケートをもらいました。そのコメントが多くの示唆を示すと思いますので、抜粋してこの場で共有します。

相手（顧客）のレイヤーによっても、プロジェクトのフェーズによっても変わってくると思いますが、いかに相手に伝わる、相手に伝えるために考えられたフレームワークかということを感じられました。ぜひ今後この考え方を参考にさせてください。ありがとうございました。
少しお話もさせていただきましたが、私はUIデザインを担当する立場から今回のお話を聞かせていただき、大変勉強になりました。数え切れない数のシステムと要件定義が存在する中で、今回のような新しい手法が生み出されているということはそれだけ要件定義というもの自体に課題があるのだろうと実感しました。
私はまだ新人で、要件定義には少ししか関わったことがありませんが、
スプレッドシートの機能一覧よりもRDRAの方が分かりやすかったです
（特に影響範囲が一目でわかるのがいいと思いました）
今後も勉強して、RDRAをプロジェクトに取り入れられるようになりたいです。ありがとうございました。
本日は勉強会ありがとうございました。
これまでのPJ運営課題(合意スピードや成果物品質など)を解決する手法として早速活用させていただきます。

①ステークホルダーや内部で合意するスピードアップ
　打合せが終わったら合意資料が出来そうで、発散して決まらない無駄な打合せが削減できそうです。

②要件定義工程以降の工数削減
　設計インプットやテスト仕様書のシナリオ、運用設計インプットに活用出来るので、工数削減とMECEも実現できそうです。

③アウトプットの品質と生産性向上・上流課題抽出に役立つ
　PJメンバーに対して、ツールを活用することで自分の経験工程(実装を前提に考える)で必要以上に検討工数をかける人達の思考制限・検討スピードアップが期待できそうです。

「要件定義の段階でHOWを考えるとすべてにおいて手がとまる」と話されていたのが、個人的にとても印象に残りました。私もHOWまで考えていて、とても苦労しました。今回受講させて頂き、要件定義で何を可視化して、顧客に説明すればよいのかとても参考になりました。
ありがとうございました。
「決める」要件定義をするために、システムの機能自体だけを見て議論をするのでなく、依存関係を持つ外側のレイヤーから議論を進めていくという考えが勉強になった。現在、コードの修正をする際に他への影響調査に苦労することがあるので、今回の話の中にあった影響度分析がしやすくなるという点も良いと思った。1時間半の中で盛りだくさんの話を聞かせていただいたので、まだ内容を整理しきれていない面はあるが、学びが多く楽しい勉強会だった。

要件定義で一番大切にするべきこと

結局RDRAでやりたいことは何なのか？書籍を読んだり何度かお話を聞ききつつ、実際に自分でも書いてみながら考えました。多分ポイントだと思うことを表現しているスライドを抜粋しました。

画像1

「一覧」→「詳細」型でタスクを割り振り、各担当者が相互連携して全体整合を維持しながらそれぞれの要件を深堀りしていくというのは、私の経験上理想でしかありません。
ほっておくとタコツボ化しがちなPJ作業において、常に全体像をわかりやすく表現し、かつそのつながりを検証できる価値は非常に大きいと思います。

「伝え方が９割」という本もありましたが、まさにシステム開発の要件もその典型です。利用ユーザーとベンダーとの境界がなくなり、全員で整合性と網羅性の担保を意識し続けられれば、大きな手戻りを要する要件不備は防げるはずです。

全員品質への足がかりへ

「誰か一人の優秀なPMやSEに頼るのではなく、全員で要件の抜け漏れや不整合を防ぐー」
全体をわかりやすく表現できる手段を持つことは、上流工程においてチームで品質を創り込む上で不可欠なツールと言えるでしょう。
今後このRDRAを一つのきっかけとして、今期目標としている全員品質への足がかりにしていきたいと思います。

この記事が気に入ったらサポートをしてみませんか？