「アジャイル開発から要件定義・設計重視な開発への回帰(2/2)」社内プロジェクトマネジメント勉強会第2回後半
こんにちは、リチャード 伊真岡です。私が勤務しているマーベリック株式会社で行ったプロジェクトマネジメント勉強会第2回の後半の内容についてブログに書き起こします。
第2回の前半内容はこちら、
以下勉強会の発表内容です
要件定義・設計重視な開発にRDRAで対応する
ここまでの話の流れは、アジャイル開発宣言の価値観自体は今でも通用するものの、ベスト・バランスの取り方については、当初は比較的重要でないとされた「左側」に比重を移すことが望ましい、と述べました。
もちろん「左側」に比重を移す際に、2000年以前のようなムダが多い要件定義や設計に戻っては意味がないので、現代のツールや手法の進化を生かした、実践的な方法論が必要になります。そこで私はRDRAという手法に注目していて、今回はこれを紹介します。
RDRAは株式会社バリューソースの神崎善司 (@zenzengood) さんが提唱している要件定義の手法で、一部設計に関わる工程も含みます。詳しく知りたい方は、こちらの2冊の書籍を合わせて読むと良いでしょう。
大きな特徴として、
- 素早く全体像を把握する、早い段階で詳細を詰め「過ぎ」ない
- RDRAをコミュニケーションの土台にする
という点が挙げられます。要件定義や設計はどうしても長期化しやすく、早すぎる段階で網羅的・詳細に検討してしまう傾向があります。RDRAは素早さを重視して要件定義をまとめ上げ、続く設計フェーズへの橋渡しをスムーズにします。とにかく ** 素早さ、素早さです！** 要件定義の素早さを実現するための仕組みをいくつも持っているのがRDRAの画期的な部分です。
RDRAでは要件定義のフェーズを4つに分け「システム価値」「システム外部環境」「システム境界」「システム」と呼んでいます。詳しい内容は書籍に譲りますが、これら4つのフェーズを行ったり来たりしながら要件定義を進めます。一度にひとつのフェーズを完璧に終わらせようとするより、こちらのほうがむしろ早くなります。ソフトウェアエンジニアにとっては、イテレーティブな開発にならって、 イテレーティブな要件定義 といえば通じやすいかもしれません。
RDRA登場以前にも、要件定義には歴史に裏打ちされた知見の集積があり、大学で教わるソフトウェア工学では中心的課題の1つです。日本ではSIerやソフトウェア開発ベンダの得意とするところでもあります。学術的なソフトウェア工学の世界での積み重ねだけではなく、アジャイル流の「ストーリー」を中心とした要件定義手法も数多くあります。
ここでRDRAの概念を通して既存の要件定義手法を見直してみましょう。RDRAの4つのフェーズに沿ってみると、学術的なソフトウェア工学もアジャイル手法も、要件定義については縦方向に深く掘り下げる手法がほとんどだったと言えます。横方向にフェーズを移動を繰り返すアプローチはあまりなかったので、 ひとつのフェーズの終了に長い時間がかかる、どこまで掘り下げればいいか分かりづらい のが悩みどころでした。
たとえば最初の「システム価値」というフェーズ、この部分に相当するのは既存の手法ではサーベイ、ヒアリング(ソフトウェア工学)、インセプションデッキ(アジャイル)などがあります。サーベイやヒアリングに関しては、最新技術や業界動向の知識を深めることはシステムの根源的な価値を高めるのに有効ですが、調査ばかりに時間を取られていてはソフトウェア開発はすすみません。サーベイやヒアリングが終わらないと次に進めない！というやり方ではなく 一旦は システム価値を定義するフェーズを素早く終わらせ、他フェーズと行ったり来たりするのがRDRA流です。
「システム外部環境」フェーズに関わる既存手法はBABOKつまりビジネスアナリシス(ソフトウェア工学)やユーザーストーリー・マッピング(アジャイル)が挙げられるでしょう。これらも有効な手法ではあるものの、それだけで要件定義全体を終わらせるほど守備範囲の広い体系ではありません。比較的軽量と考えられているユーザーストーリー・マッピングでも、マッピングのミーティング自体は数時間で終わるものの、 関係者を一同に集めるには非常に時間がかかる ので、何度も繰り返すのは現実的ではありません。RDRAでは、このフェーズも早めに終わらせ「時間がかかるユーザーストーリー・マッピングは後回しにする」と言った判断も可能です。
残りの2つ、「システム境界」フェーズに関わる既存知識体系としてはUMLやICONIXがあり、「システム」フェーズにもUMLの一部やオブジェクト指向開発論全般が関わります。
最後に縦にも横にも深く広い体系としてPMBOKを紹介します。これは要件定義だけでなくプロジェクトマネジメント全般にまたがる膨大な知識体系ですが、学ぶべき内容が多すぎて、とくに資格試験をパスしようとすると「60ヶ月のプロジェクトマネジメント経験」が要求されるなど、かなりハードルが高いです。ソフトウェア工学の本流をいく素晴らしい知識体系ですが、多くの人にとってはより軽量な体系のほうが利用しやすいはずです。
少し話がそれますが、RDRAは日本のドメイン駆動設計コミュニティからも注目されているようです。ドメイン駆動設計も横方向の意識を持って「システム」の設計から「システム価値」までさかのぼって要件定義全体を見通す方法論だと言えそうです。
なんでもかんでも理論体系を取り入れてつなげればいいというものではありませんが、RDRAは他の設計や要件定義の手法論と排他的なものではなく、素早い要件定義を行うために RDRAを活用し、必要に迫られたら馴染みのある別の手法をもちいて、縦方向に要件を深く掘り下げていくとよいでしょう。
まとめ
今回はRDRAのほんのさわりの部分だけ紹介しました。繰り返しますが要件定義を素早く行える点が優れている手法だと私は考えています。要件定義や設計といったソフトウェア開発プロジェクトの「早いフェーズ」の重要性が増してきている時代によくマッチした手法論です。
次回の勉強会では要件定義より一歩後のフェーズである「設計」の話、とくにAPI設計を中心にいかにソフトウェア開発プロジェクト全体のスピードを上げていくか、というお話をします。
- 第1回の記事はこちら - 「ディズニー映画制作、ゲーム開発そしてソフトウェア開発の類似点」
- 第2回前半はこちら - 「アジャイル開発から要件定義・設計重視な開発への回帰」(前半)
- 第3回の記事を公開しました！ - 「並行作業とスキーマ駆動開発」
- 第4回の記事を公開しました！ - 「効果計測が当たり前のデジタル広告、計測が当たり前じゃないエンジニア生産性」