生き様202. 要件定義のフレームワーク「RDRA2.0」と要件定義のコツ
「RDRA」とは
先日、ペチオブさん主催の勉強会
『(【RDRA × AI】 AI時代の要件定義ワークショップ！)[https://phper-oop.connpass.com/event/289267/]』
に参加してきました。
会としては、AI時代を迎えて「システムの要件定義はこう変わっていく」という部分の解説と、
最新の【RDRA2.0】ツールを使ったRDRAのワークショップを受けることができました。
その【RDRA2.0】とは、「リレーショナルシップ駆動要件分析」の略称です。
神崎 善司さんが提唱する手法になります。
日本で生まれた要件定義のフレームワークです。
「システムの価値」等に注目し、複数の視点からシステム要件を分析、モデル化することで直感的に要件を分析・理解することができます。
こちらのWebページに、文章や動画での解説が載っています。
興味を持たれた方は、上記ページを確認してみてください。
他にも事例など関連する情報がたくさんあります。
白栁自身は、現在要件定義に関わる立場ではありません。
ですが、このワークショップを通じて、見えてきた要件定義のコツみたいなものを、今回お話したいと思います。
大きい範囲→小さい範囲、大雑把→細部、抽象→具象へ
ワークショップ中に、神崎さんがしきりに声を掛けていた言葉がありました。
「大きなところから考えて、細かいところを考えるようにしましょう」
これは、プログラミング経験のある人が陥りがちな罠でもあります。
最初は、要件を整理する段階です。
その段階で、DBがどうなるだとか、画面がいくつ必要とかは重要な情報ではありません。
ビジネスとして、何に「価値」を見出しているのか。
その「価値」がどのように生まれ、提供されているのか。
そして、どう遷移しているのか。
そこには誰が関わっていて、どういう行動が必要なのか。
この様なことを洗い出していくことが重要なのです。
その為に、最初は大雑把で抽象的な情報の羅列でも良いと感じました。
複数のレイヤーを行き来するなかで、不要な情報を削り、欠けた情報を埋め、抽象的な情報を具体的な事例にしていくことが大事なのだと考えています。
その検討の中で、ビジネスについて理解が深まる事もあるでしょう。
このことからRDRAは、ビジネス分析ツールとしての側面も持つことを感じました。
ビジネスへの理解が大事
これは確信を深めた事柄になります。
はやり「ビジネスを理解していないと、良いシステムは作れない」のです。
今なお現在、主流となっているウォーターフローモデルの開発では、この点が疎かにされることが多いと感じています。
経営権のある人からの「良きに計らえ」を受けてプロジェクトが始動。
業務への知識のない人達が必死で情報をかき集め【要求】としてまとめる。
それを、ビジネスに疎い開発者が【要件】や【仕様】へとまとめてシステム化していく。
この流れを完全に検証できる存在はなく、実際に運用して「良・不良」の博打。
こんなことで「良いシステム」が生まれるはずがないのは自明の理です。
それをヒアリング技術や標準化でまとめ上げている、日本のIT業界に変態的な才能の無駄遣いを感じます。
それを脱しようとした側面が、アジャイル開発にもあるのでしょう。
白栁は、アジャイル開発で一番需要なところは「ステークスホルダーを巻き込む」ところだと考えています。
いくらマイクロなシステムをリリースしても、イテレーションを回しても、ビジネス側の存在と壁があったら、価値が薄いと確信しています。
他にも、多くの技術が「ビジネスとシステム開発の壁」を壊そうとしています。
ですが、どうにも「上意下達」を尊ぶ日本の社会制度・ビジネス習慣は強固です。
白栁が現役のうちに、この壁が壊れる日が来て欲しいと願うばかりです。
以上！