PR

 前回は,私が要求開発アライアンスの執行委員になった理由の一つ,「要求開発への期待」について述べた。今回はもう一つの理由である「要求開発が難しい印象を持たれているのを何とかしたい」について,なぜ難しい印象を持たれているのか,またどうすればそれを取り除けるのか,私なりの視点で述べたいと思う。

概念と方法論を区別して学ぶ

 「要求開発」というキーワードに興味を持ったときに,Webや書籍で調べてみると,まずやたらと目に付くのが「Openthology」という言葉だろう。さらに調べると,プロセス・キャビネットやプロセス・セルといった新たなキーワードが出てくる。だが,こうしたキーワードを調べようと要求開発アライアンスの公式サイト(http://www.openthology.org)を眺めてみても,ダウンロードできるドキュメントは膨大でどこから手をつけていいか分からない。結局「要求開発」って何なの? ということになってしまう。これが1つめの落とし穴である。かく言う私も,その落とし穴にはまった経験がある。

 「要求開発」とは“概念”であり,「Openthology」は要求開発を実践するための“方法論”である。まずは,これら2つをきちんと区別したうえで,要求開発のコンセプトや目的を理解し,さらに実践に向けてOpenthology(要求開発方法論)を学ぶ必要がある。これらを混同したままでいっぺんに理解しようとしても,「結局何なの?」という状態になりかねないからだ。

 「情報システムに対する要求は,あらかじめ存在しているものではなく,ビジネス価値にもとづいて『開発』されるべきものである」---要求開発のこのコンセプトに賛同していただける方は多いと思う。だが,どんなにコンセプトが良くても,実践できなければ意味がない。そこで,要求開発アライアンスの理事らが,実プロジェクトにおける豊富な経験と知恵を結集して体系化した方法論がOpenthologyというわけだ。

 私は要求開発の概念は,システム開発のほかにも様々な分野に適用できると考えている。企画段階での曖昧な要求(要望や願望を含む)を適切に具体化する必要性は,何もシステム開発に限ったことではないからだ。同様にOpenthologyも,要求を具体化するための段階的な詳細化の方法や,継続的な改善のためのPDCA(Plan−Do−Check−Act)プロセス,それに含まれるプロセス・キャビネットやプロセス・セルなどは,システム開発に限らない様々な分野に適用できるだろうと思っている。

目指すところに常に忠実であれ

 さて,要求開発とOpenthologyの関係を理解したうえで,もう一つの問題は,「要求開発とはすなわち,Openthologyのプロセスを忠実に実践することである」という誤解を受ける可能性があることだ。これが2つめの落とし穴だと思う。なぜそのような懸念をするかというと,要求開発に限らず,意外に多くの人が「考え方(概念)には共感するけれど,やり方までは押しつけられたくない」という反応を見せるからである。

 その顕著な例が,XP(eXtreme Programming)である。「すべてのプラクティスをしなければXPとは言えないのでは」などと議論になることが少なくないし,その独特のやり方にアレルギー反応を起こす人も後を絶たない。要求開発も方法論とセットで紹介している以上,カスタマイズ方法や最低限実施すべきポイントなどを,より具体的に示す必要があるだろう。いずれにせよ,重要なのは,紹介されている方法を単になぞるのではなく,その目指すところ(=価値)に常に忠実であれ,ということだ。これは,要求開発でもXPでも同じである。この点をぜひ忘れないでいただきたい。

 最後に,「要求開発」の直感的な難しさを取り除くためにどうすればいいかを考える。Openthologyは,きちんと理解することによって初めて要求開発を実践するためのフレームワークとして利用できるようになる。つまり,フレームワークとして利用するには,いかに理解しやすく,導入しやすいかが重要なポイントとなる。

 しかし,現在のところ,Openthologyを容易に取り入れられるよう解説したドキュメントは少ない。課題としては,実践的な事例やより分かりやすいコンテンツなどを積極的に提示する必要があると考えている。今後,より多くの方に「要求開発」を知っていただき,Openthologyが実プロジェクトで役立つ身近な方法論となるよう,若手メンバーによる執行委員会は検討を進めていくつもりである。今後の活動にぜひ期待していただければと思う。

(眞庭 奈々子=要求開発アライアンス執行委員)