プロジェクト　ミューズ：バイリンガルプロジェクトは辛いよ　～その3～

＝　初めに仕様ありき　＝

今回のプロジェクトに限らず、日本流のプロジェクトの進め方はまず初めに仕様を固める。仕様が決まるまでは開発は始まらない。そしていったん決めた仕様を変更することに大きな難色を示すというのが日本流の特徴だ。一方、私がこれまで経験した米国流のプロジェクトの進め方は、基本的な仕様は最初に決めるけれど、細かい点は開発しながら決めていく、開発しながら設計変更することも珍しくなかった。日本人に言わせると「アバウトな仕様の決め方」だ。

何をどうやって作るのか、最初にちゃんと決めておかなくては、というのが日本式開発の根底にあり、それはそれで理にかなっている。一方、開発は当初の想定通りに進まないことの方が多い、そんな時は柔軟な対応が必要だ、最初から細部まで決めようと時間をかけてもどうせ変更することになったら時間の無駄だという欧米式の言い分もわかる。どちらが良い悪いの問題ではない。けれどもお互いに自分達の開発手法が「当たり前」と思っていて、それを相互に確認しなわないがゆえの食い違いが問題なのである。

今回のプロジェクトで、日本側SIは、まず顧客が提示した要件を十分に理解したことを示す要件定義書を作成しようとしていた。この要件定義書で、このシステムを適用する業務のフローを追いかけながら、各ステップで必要となるシステム要件を明記するつもりだったのである。要件仕様を明らかにしたら、基本設計をし、さらに詳細設計をするという段取りを組んでいたのである。この進め方を前提に、SIはPGKから教示された開発手法を踏まえてプロジェクト計画を立てようとしていた。パッケージベースのシステムでは、要件の八割方は製品の標準機能で対応し、カスタマイズしなければならないのは全体と二割だと言われていたが、そもそも製品の標準機能で何がどこまでできるか理解しきれていないSIにとって、まず要件を全て網羅し、その中でカスタマイズが必要なものとそうでないものを整理するという方法を頭に描いていたのである。

ところが、、、。

製品を熟知しており、かつその製品の機能を拡充する自社モジュールまで開発しているPGKは、SIが製品のことを良く知らないということを十分に理解していなかった。しかもPGKは、SIにはATLANTICと呼ばれる独特の言語での開発経験がないため、自分達がSIの代わりにシステムを開発してあげなくてはと考え、SIにどのようにして開発するのかを十分に説明せずに開発計画を練り始めていたのである。ところがSIは、MAGIKの教育を受け、自分達で開発するつもりでいた。そしてPGKには自分達が開発する際の援助をしてもらうつもりだったのである。ここにも両者の考えに大きなギャップがあった。

自分達で作る気になっているPGKは、製品のカスタマイズする部分にだけ着目している。ところがSIは全体要件がちゃんと満足されるのかどうかをまず把握したいと思っている。SIは全体要件の整理がプロジェクトの初めの一歩でそれがすまない限り前には進めないと考えていた。だからいつまでも全体要件仕様書がPGKから提出されるのを待っている。ところがPGKはそのような文書を作成する気はさらさらなかったのだ。

最近のソフト開発は、Waterfall型はまず使わないとシリコンバレーのコンサルタントから教えてもらった。Rapid Application Developmentが当たり前になっていると言う。けれどもRapid Application Developmentでも開発前にまず全体要件を決めるのだそうだ。そして各要件をストーリーと呼ばれるタスクに細分化する。そのタスクは優先順位を付けて開発していく。しかも週次、日次の単位で作業項目を決め、進捗を管理していく。Waterfall型開発だと全ての開発が完了しなければ動くものがないのでゼロか一か成果物だが、RD型開発だと常に何か動くものある。最初は原始的なシンプルなもので、それがだんだんにより高度な完成度の高いものになっていく。RD型ならそのつどその時点での成果物を見ながら、設計や開発を微調整することができるのである。

このプロジェクトが、ジャネットという女神様の来臨でスタートしたにもかかわらず、最初の4ヶ月を無駄にしてしまった原因に、開発手法（WaterfallなのかRapid Developmentなのか）を初めに明確にしておかなった点にある。