見出し画像

モデルベース要件定義手法RDRAの紹介

モデルベースの要件定義手法であるRDRAのワークショップに参加しました。

自社におけるアプリケーション開発の組織的品質向上を計る上で、ベースとする標準手法を模索していた折、アクティアの高崎さんのTweetをきっかけにこのRDRAを知りました。書籍を紐解いた第一印象で、複雑すぎず簡易すぎず、うちの組織と相性が良さそうに思い、まずは使ってみるべしと私が担当しているある社内PJで適用を開始しました。今日はそんな中で実際に作者の神崎さんのお話を伺えるということで参加しました。

なおRDARの解説書籍はこちらです。Kindle Unlimited対象です。(社内で布教するために書籍版も購入しました)

内容としては、リレーションシップ駆動形という名の通り「各レイヤー間やモデル間の整合性の表現」に腐心された設計になっており、要件の不整合に気づきやすい構造になっている点が特徴です。「各個別機能としては問題ないが、全体結合した際に不整合が生じる」という問題を、できるだけ前工程で拾うことが大きな狙いの一つのようです。

対照的に、「概要→一覧→詳細」という、いわゆる要件定義の王道アプローチに警鐘を鳴らされていました。どうしても各論に陥りがちな傾向は、経験者ほど耳が痛い所です。これはベンダー主導によるプロジェクト管理都合に起因しているのでは?というのが神埼さんの意見で、一覧から詳細に落とし込む流れが、タスクの母数を拾い上げることに適しているため、上記の不整合リスクを含みながらもこの手法から抜け出せないのでは?という見解でした。確かにそれはそうかもしれないなと思います。

この体系全体を通して「程よい抽象度」へのこだわりを感じました。
この適切な抽象度のバランスは、上流工程の一つの勘所だと思っていて、詳細に書きすぎてもわかりにくい、概要すぎても中身がない、というありがちな現場SEの抱えるジレンマへの、作者なりの一つの落とし所がこのRDARなのだと思います。

全体を通して、システム開発における主要な品質リスクである

・ステークホルダー間でのシステムへの期待のズレ・過剰なドキュメント生成による工数の肥大化・要件全体を把握できる人材がいないことによる部分最適化

に対する有効なソリューションであると感じました。

今後我々が実践適用していく上での運用的課題としては以下があるかなと考えています。

・概算見積りスキームの確立(要件定義終了後に通常要求される)
・この後の設計開発工程への連携(終了後のビアバッシュでもここは意見が分かれた)
・エンジニアへのセッション運営スキル教育(その場で顧客陣と会話しながらモデルに落とし合意形成していくには、一定の場馴れとファシリテーションスキルが必要だと理解)

その他諸々課題はあるかと思いますが、弊社のデザイン先行型スタイルと融合させた形での要件定義方法論に発展できる可能性を大きく感じました。実践を通し研究を続けたいと思います。

最後になりましたが、講師の神崎さん、高崎さん、会場をご提供いただいたアクティアさん、ありがとうございました。

✳︎公開時神崎さんの氏名表記に誤りがありました。お詫びします。上記訂正済みです。

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