oldwaveの日記： 設計しないことがデスマーチを呼ぶ（予算もスケジュールも関係ない）

●画面設計書しかない開発現場

デスマーチになったプロジェクトに火消しとして参加してみると、設計書らしい設計書が画面設計書しかない、という場合がしばしばある。

「いや、そりゃ、わかってるよ。ちゃんと設計した方がいいってことはね。でも、スケジュール的にも予算的にも設計に時間と人を割けなかったんだよ」

「しかし、この混乱は設計書がなかったためでは？ 設計書がないから、各人が勝手な実装をしていて、同じ機能が二重に実装されていたり、画面によって入力値のチェック方法が違っていたりしてるんですよ。セッションに保持されている値はグローバル変数同様なんですから、その使い方はきちんと文書化しておかないと...」

「そうですね、ご説ごもっとも、私もちゃんと設計したかったです。でもね、スケジュールがね...」

こういう会話は何度も経験しているのだが、こういうことを口にする人は重要なことに気付いていない。予算もスケジュールが十二分にあるプロジェクトなどというものは存在しない、ということをまず理解すべきだ。

●予算とスケジュールは必ず足りない

必要な機能をリストアップし、簡単な画面遷移図を書いて企画書を作る。企画書をもとに粗見積りが作られる。顧客が企画書と粗見積りに合意すると、プロジェクトがスタートする。

企画書をもとに画面設計書が作られる。だいたい、画面設計書をある程度のレベルまで仕上げるところまでは、ほとんどのプロジェクトで行なわれるようだ。
それは顧客が画面設計書を見たがるからでもあるし、受注側としても何か書面化された仕様で合意しないと心配だからでもある。

何度か画面設計書を書き直し、ようやく顧客と合意を形成すると、顧客が要求する期日までにプログラムを完成させるには何人のプログラマーが必要か見積られる。すると、早くも結構な人数をアサインしなければ間に合わないという ことがハッキリする。結構な人数をアサインしなければならない、ということからスキルにこだわってはいられないという気持ちにもなる。

「レベルの高いプログラムは無理だから、とにかく画面設計書通りに一画面ずつ愚直な方法で書くことにしよう。顧客と合意しているのは画面設計だけなんだから、内部構造はどうなってたっていいわけだし」

このような気分で荒っぽく方針が決められ、アサインされたプログラマーには一方的に画面設計書と開発範囲が示される。

「君はこの画面設計書のここからここまでを実装して。なるべく単純明快にコーディングして、後から保守する人がわかりやすいようにね。なあに、それほど複雑なアプリじゃないから、とにかく難しいテクニックなんかは要らないからさ」

作業が始まると、いろいろと仕様上の疑問点が出てくる。いくつかは自分たちで判断できるが、いくつかは顧客に判断を仰がなければならなくなる。

「そうか。たしかにこの画像ファイルをどのようにサーバにアップロードするかについては決めてなかったな。まさかFTPであげてくれとは言えないし...」

「でも、商品1個ごとに参照ボタンでアップさせるんですか？ 商品登録の仕様自体がちょっと無理がないですか？」

「それもそうか。次のミーティングで確認しよう」

顧客との定期ミーティングで発見された問題を相談すると、顧客は軽いノリでこんなことを言ってきたりする。

「そりゃ、1個ずつ登録するインターフェースの他に、一括登録用のインターフェースは必要だよね。商品データはエクセルに入ってるんだから、エクセルのシートをそのまま読めればベストだね」

「商品の画像のファイル名は商品コードか何かを使うように規則的な名前になっていますか？」

「どうなってる？ まちまち？ どうも部署毎にまちまちみたいですね」

「画像のファイル名は命名規則を決めるか、エクセルのシートに画像ファイル名のカラムを追加してもらう必要がありますね」

「手配しましょう。それがあれば作れるよね？」

「そうですね。ちょっと仕様が変わるので、スケジュールの方が...」

「おいおい。この機能は当然必要だよね？ 商品の数は何万とあるんだから1個ずつ登録する方法しかないなんて絶対に無理だよ。まさか、実用にならないものを納品するつもりだったんじゃないよね？ もう広告展開の方も準備は進んで るんだから、今さらスケジュールは変えられないよ」

こういう具合で、顧客に押し切られ、プロジェクトマネージャーは軽くパニックを起こす。スケジュールを引き直し、1日のノルマを少し厳しくするしかないと感じる。

「追加の要員をアサインできるように営業と予算の交渉をするから、とりあえずはちょっとピッチを上げて作業してほしい」

こうして、プロジェクトはいとも簡単にデスマーチに突入する。あとは坂道をころげ落ちるよう、である。

何が問題だったのだろうか？ 顧客が当然必要だと感じるはずの機能を見落していたためだろうか？ それもある。だが、本当の問題はそこにはない。このプロジェクトマネージャーには、安定した仕様が与えられ、それに見当ったスケ ジュールと予算が与えられるべきだという気持ちがあるのだ。現状は、そのような「あるべき状態」に程遠い。ゆえに、多少のトラブルに巻き込まれるのは仕方がないと思ってしまう。

だが、それは無理な想定なのだ。どこまで行っても仕様には不備があるのだし、予算とスケジュールが十分にあるということも期待できない。もし完全な仕様を得られるとすれば、それは最終的な製品が完成したときである。

実際には、当初の想定通りにすべての機能を最初のリリースに実装できないことも多く、また、実装の過程で「あって当然」の機能を発見してしまうことも多い。かくしてバージョンアップがどうしても必要になるもので、そういう意味では、仕様が安定するには何度かバージョンアップを経てからになるし、結局使いものにならずに捨てられるまで仕様が安定しないことだってないとは言えない。

仕様が安定しないんだから、予算やスケジュールが足りることもない。

「その機能を実装するとなると、予算とスケジュールが厳しいですね」

「だったら何かを削るしかないか」

というような具合で、仕様変更がさらなる仕様変更を生んでしまったりする。

現実には、予算とスケジュールに縛りのないプロジェクトは存在しない。それでいて、仕様は安定しない。予算とスケジュールと仕様の間で「綱引き」が続く。それが現実のプロジェクトというものなのだ。

ここで挙げたプロジェクトマネージャーは、このような綱引きのないプロジェクトを「あるべき姿」と想定しているのだが、そこに最大の誤ちがあるのである。

●成功している組織は分析と設計に力を入れている

プロジェクトには予算とスケジュールという制約がある。その範囲で利益を確保しつつ、顧客にも満足してもらう必要がある。そのために何ができるか？ 答えは「分析と設計に力を入れる」ということである。

もちろん、予算とスケジュールの制約があるから、無制限に分析と設計に時間を割けるわけではない。「この期間、この人数で分析をやり、この期間、この人数で設計をやろう」と決め、その制約の範囲でベストの結果を出すようにするのである。

くりかえしになるが、予算とスケジュールは足りるということがない。だから、限られた予算とスケジュールの範囲で可能なかぎりの分析と設計をするのだ。要求の細部に入り込み、リスクを洗い出し、プログラムの構造を検討する。もちろん、実際にコーディングして初めて気付くような問題をなくせるわけではない。だからこそ、プログラムの課題全体を俯瞰しながら、なるべく早い段階でプログラムを構想すべきなのである。軽く全体を構想してみると、うまくイ メージできない部分が見付かったりする。そこは急所であるかも知れない。まさにそのような急所を発見することが分析や設計の目的なのだ。

「商品の数はどのくらい登録されるんだっけ？ 数万のオーダか。とすると、一括登録の機能が必要になるな。あと、検索画面の仕様もよく練った方がいい。間違って登録してしまった商品を探せないと困ったことになるし」

このようなことは「商品の数」のような具体的な事象をイメージしないと見付からない。「商品の数」が少ないならば、1個ずつ登録するのでも問題ないわけだから。

どこに急所があるかは、往々にして予想外である。したがってプロジェクトの初期には分析能力の高いスタッフをアサインし、分析の成果が出始めたら設計能力の高いスタッフをアサインすると良い。いつまでもそのプロジェクトに拘束する必要はないのだから、思い切って社内でもっとも有能なスタッフに参加してもらうことだ。ともかく、分析と設計の成果を書面に残させることだ。そうした成果物が蓄積されることによって、後進の学ぶ材料となり、組織全体の レベルも向上していくことになるからだ。