「要求開発の心」を活かすポイント

【おことわり】
この記事は、もともとエンジニア向けフリーペーパー"EM WEST"の連載記事「現場での要求開発のはじめ方」の第２回として書き下ろしたドラフトです。EM WEST Vol.3（だっけ？）の発行がまだ先になりそうなので、現時点でブログの方で番外編として公開してしまいます。また、この連載自体は、読者のみなさんに「要求開発」あるいは「要求開発アライアンス」が提唱するOpenthologyを、より身近に感じていただくために始めたものですが、その内容については私個人の見解も多分に含まれており、必ずしも要求開発アライアンスの公式見解ではないことをあらかじめご了承ください。

はじめに

要求開発に関してよくある質問の一つが、「何ができていたら『要求開発をやった（やっている）』と言えるの？」というものです。今回は、かなりの私見も含めてそのあたりについて語ってみたいと思います。

要求開発の心

要求開発宣言が出されたのが2003年12月、そしていわゆる「白本」と呼ばれている書籍「要求開発」（日経BP）の出版が2006年3月です。それから年月を経て、ビジネスを巡る環境も、要求開発に求められるものも大きく変わってきています。
単に「白本」に書かれたプロセスやプラクティスをなぞればそれが要求開発かというと、決してそうではないでしょう。私は以下のことが「要求開発の心」として重要なポイントであると考え、実践でも心がけています。
ポイント１： ３つのT
ポイント２： 開発者/エンジニアが主体的に関わる活動
それぞれについて以下に簡単に説明します。

３つのT

要求開発を支えるものとして次の３つが重要であり、これらを具現化するためにさまざまなプロセスやプラクティスを「現場のコンテキストに応じて」使い分けていくことこそが要求開発の本質なのではないかというのが、私が「３つのT」と名付けて提唱している仮説です。

Transparency（透明性）

モデルによる可視化、ステークホルダーの適切な巻き込み（コタツモデル）と適切なコミュニケーションなど。

Traceability（追跡可能性）

要求分析ツリーで要求の階層化・上位要求との関連の明確化、目的と手段の連鎖の可視化、各種モデル間の連携などにより、各個別要求事項の出自と正当性を明らかにしていくこと。

Triage（トリアージ）

要求をきちんと評価・分別・取捨選択して、制約の中で価値最大化を目指すこと。

開発者/エンジニアが主体的に関わる活動

前述の３つのTが３本の脚と考えた場合、それが支えるものは何でしょうか？私は、それこそが要求開発宣言の理念である「情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて『開発』されるべきものである」という考え方だと思います。
ここでは、敢えて「開発」という語を使ってシステム開発のアナロジーを、要求を創りだす活動に援用しているところがポイントです。また、要求開発が要求の可視化を行うに当たって当初よりUMLによるモデリングを取り入れて活用してきたことからも、この活動がいわゆるビジネスアナリストだけでなく、開発者/エンジニアが主体的に関わる活動を意図していることがわかると思います。

クラウド/アジャイル時代の要求開発

誤解のないように書いておきますが、「開発者/エンジニア主導」とはいえ、経営陣をはじめとするビジネスサイドや現場担当者などそれぞれのステークホルダーがそれぞれに重要な役割を果たすことは言うまでもありません。
ただ、昨今の状況を見ていると、この開発者/エンジニアが主体的に関わるという部分が、より重要な意味を持つようになってきているのではないかと思います。
その背景にあるのは、クラウドでありアジャイル開発です。従来から、要求開発では要求の実現可能性を探ったりするための「フロントローディング開発」や、開発者の知見をより価値の高い要求作りにフィードバックすることの有用性が言われていました。近年、クラウドコンピューティングの広まりにより今まで以上に実装レベルでの手探りの環境が整ってきていますし、アジャイル開発の普及によってより高い頻度でフィードバックループを回すことができるようになってきました。そこで重要となってくるのがそのメリットを最大化できるような開発者/エンジニアの存在なのです。

まとめ

少し話が横道にそれた部分もありますが、筆者の見解をまとめると、

• 「要求開発をやる」ということは要求開発宣言の理念を、要求開発の３つのTを通じて具現化したプロセスやプラクティスを実装することである
• その実践にあたっては、開発者/エンジニアの力をいかにうまく活用していくかというのがポイント

となります。
そして、それらの活動が「ビジネス価値」にもとづいたものであるべきだということは言うまでもありません。

【コラム： あれもこれも要求開発！？】
そこのあなた、「そうは言っても、仕事でシステム企画とか上流工程とかやってないし、要求開発なんてあまり関係ないなぁ。」と思っていませんか？いえいえ、そんなことはありません。あなたが実装を担当するエンジニアだとしたら、あなたの実装視点からのフィードバックは要求開発の重要な要素の一つです。アジャイルチームで開発している人が、最近流行（？）のインセプションデッキつくりに取り組んでいる時、それも要求開発です。もっと言えば、旅行の計画を立てるときも、晩ご飯の献立を考えるのも…あれもこれも要求開発！？結局は、要求開発も、”It’s All About Common Sense!”なのです。それをどういうふうに構造化し、実効性を持たせる工夫をするかというところでちょっとカッコつけてるだけなのです（笑）。

要求開発~価値ある要求を導き出すプロセスとモデリング