要求仕様戦争（その4）

■開発工程をどうこうする――「要求開発」というフェーズを設ける

　いったい何が作りたいのか?――この問答を真摯に行う作業がすっぽりと抜け落ちている。仕様凍結ギリギリまで曖昧なままにしておこうとする顧客と、早い段階で仕様をFIXさせてしまおうとする開発側の、両方から引っ張られ、要求仕様決めが考慮されていないのが実情。

　これまで後工程に埋め込まれ、属人的に処理されている「仕様のカケラから要求を復元する作業」「経営課題から要求まで洗練する作業」に名前を付けよう。それだけでなくその作業を一つのフェーズとしてキチっと定義しよう…そんな提言を行っているのが要求開発アライアンス[参照]。

　例えば、システムをいかに効率的に作るかについては、開発手法、プロセス、開発支援環境が編み出され、適用されている。例えば、Eclipse はコード書きのためのツールだけでなく、テスター、QC（品質管理）、生産物、バグトレースから再利用まで、様々な立場の人に使われている。

　しかし、要求を決める方法はおそまつ。とてつもなく場当たり的に試行錯誤を繰り返して「要求」を決めている。これは「情報システム部門」を作れば解決というわけでもなく、システムを超えた業務の全体最適化を図るためには、情報システムへの要求がロジカルに導出される必要がある（情報システム部は、「システム」しか目が行かないからね）。

　いかに良いツール（Eclipse）を有していても、何を作るかが曖昧モコモコのままだったら、まともなブツができるはずがない。まちがった要求を正しく作っても仕方がない――要求開発の発想はここが原点。そこで、ソフトウェア工学技術によって体系化された方法論――Openthology の出番。これを用いて、ビジネス上の目的と整合性の取れた価値のあるシステム要求を導くことを目的とした2冊をご紹介。

■「要求開発」のバイブル

　ひとつめ。「要求開発」はズバリそのもの、バイブルを目指して編まれており、要求開発を考える上で必要な全てのトピック・手法を網羅している。

　その重要性や位置付けはとても同意できる。特に激しくうなづけるのは次の一文――要求はもともとあるものではなく、ビジネス要求をもとに合理的かつ能動的に開発すべきもの――つまり、要求分析、要求定義といった「いまそこにあるもの」ものを紙に落としたりモデリングするやり方ではダメよ、というところ。

　確かにユーザーヒアリングを通じて得られる「要件定義」には限界がある。ユーザーから聞き出した要求を明文化したり、分析したりする作業とは一線を画した、能動的に要求を開発することが必要だ――が本書の主張。

　ではどうすればよいか? その答えを出来る限り網羅しようとしている。

　モデリング手法にUMLを取り入れ、ほとんどのグラフはUMLの流用。さらに、BSC戦略マップ、問題分析ツリー、ターゲット分析モデルといったコンサル手法もおさえている。すなわち、開発者とコンサルタントの双方のイイトコ取りをしている。スタッフ部門やコンサルタントがこっそり参考にすると重宝する。

　必読は第5章。それまでの「体系化」「網羅性」をかなぐり捨てて、「要求開発を『絵に描いた餅』に終わらせないために」とある。「Openthology に魂を入れる45のポイント」と銘打って、要件定義の場の泥臭い丁丁発止や、プロジェクト立上げに絶対やっておかなければならないこと、沢山の失敗事例がコレデモカというぐらい続く。これは読んでおくべき　…まぁ、全ての要件定義フェーズに共通するリアルな教訓なんだが、Openthology に胡散臭さを感じ取っている人には良いキックとなるだろう。

■コンサルティング寄りの「要求開発」本

　さらに上流の次元での話。「戦略的要求開発のススメ」は、視座が高いから「良い」というわけではない。鳥瞰的な分、より具体性が薄れている面もあるが、これから重要になることは間違いない。

　ひとたび作り始めてしまえば、あとは「いかに与えられたモノを正しく作るか」に没頭することになり、「与えられたモノ」を論議することはない（あたりまえだ）。あるいは、昨今の開発手法論議やメソドロジーは、ほとんどといってよいほど、「いかに正しく作るか?」に全力を費やしている。しかし、与えられたモノが誤っていたなら? 間違ったものをいかに正しく作っても無意味だ、「顧客は要求を正しく表現できる」なんて寝言だろ！というのが趣旨。

　で、そのために、「要求開発」というフェーズを設けましょうという提案が続く。経営レベルの要求をITで実現するために「やるべきこと」を明確化するフェーズだ。まず、経営分析から「ビジネス要求」がアウトプットとして出てくる。「××の売上○%アップ」や「△△製品の歩留まりを○%にする」とかいうやつ。次に、それを実現するために、ITとして何ができるのかをああだこうだと議論する。それが「要求開発」というやつ。

　言っていることはごもっともなんだけれど、本書を読むと、これ、一度も動かしたことがないやり方だということが良く見える。コンサルティングメソッドをかじった抽象論が延々と続いており、そのままでも煮ても焼いても使えない。書いてる人も分かっているようで、「これからそんな戦略的なフェーズが要りますよ」と提唱をくり返す。

　むしろ、ここから真髄を素直に読み取り、自分のやり方に適用するのが賢い本書の使い方なんだろ。例えば、1コ上の要求（を併記した）仕様書にからめて、より高い（ビジネス戦略から見た「要求仕様」）とのリンケージをするとか（やりすぎ?）。

■「要求開発」というフェーズの弱点

　システムのグランドデザインを決めるフェーズにおいて、「要求を開発する」ことは、今後ますます重要視されるだろうし、その方式論がもてはやされるのも必至。コンサルタントは銭のネタとして、そして、ベンダーは要求仕様戦争の要因を回避する最終兵器として。

　しかし、経営者（意思決定者）にとってのメリットが皆無。ないことはないが、無理矢理ひねり出している後付けの理由。考えてもみるがいい。自分が経営者だとして、コンサルタントが書いた計画書がある段階で、こいつをRFPなり仕様書なりに落とすためにさらにひと手間かかる、といわれたら何と答えるだろうか?

　「要求仕様」の必要性なり必然性を確信しているのは、作り手であって顧客ではない。「デスマを回避するために必要」などとヌかしたら、顧客はきっとこう言う「期限内・予算内で、そうならないようにするのがオマエの仕事だ」と。ご紹介した2冊はこの疑問に答えていない。

　言い換えると、経営者に要求開発の動機づけをさせたSIer が勝ち、と読み取るのだ。つまり、フェーズ（期間）を新たに設けるのではなく、経営戦略フェーズにメンバを潜り込ませたり、人員増のための方便として… 等など。フェーズ、すなわち時間という概念を外しても可。例えば、要求仕様の「成果物」を出すための作業の必要性を認識させる。で、その作業への予算を割り当ててもらう。

　要は、この考え方を銭につなげられたモン勝ち。システム開発にあたり、見えてなかった本質が本書によりクッキリあぶりだされている。