いきなりエベレストの登頂を目標にするのはやめよう。

要件定義フェーズで、お客様と会話をしていると、その要望が止まらなくなってくる、
ということはよくある話だ。
基幹システムリプレースともなれば、その積年の思いの対象も限りなく広くなる。
いかに、現行のシステムが使いにくいか、どうしたいかをとうとうと語り出し
はじめる。いったい、その話は、今回の開発のスコープなのか、それとも単なる
愚痴なのか…。
とにもかくにもお客様の、現行のシステム・業務を改善しようという思いは
強い。
一方、そのような話を聞くと、同情にも似た気持ちがエンジニア側に沸く。
これはひどい。分かりにくい。混沌としてる。混乱している。
こんなシステムを使って良く業務が回る。これなら、現行よりももっと良いシステムを
作ることができる。

依頼主と、作り手の思いはある時点、ある意味では、一致している。
それが、なぜいつの日か、そう遠くもない、いつの日にかは
プロジェクトは破綻し、デスマーチが始まるのだろう。
依頼主は、とはいうもののこれだけのことを今回の予算でやるのは無理だ
ということを、直感的に理解している。
だから、できるだけ今の予算でできるだけ機能を詰め込もうとする。
あるいは、理解していないからこそ、詰め込めることが可能だと信じている。
作り手は、請負契約を結んでいるために、あらかじめコストと期間の制約が
課せられている。にも関わらず、スコープだけが肥大し、そのバランスを
欠けさせたままプロジェクトを進めていくことになる。
やがて、依頼主と作り手の感情は、全くシンクロしなくなる。
お互いに不満だけを募らせていく。
お客様のストレスは溜まり、エンジニアの健康は損なわれていく。

システム開発には二つの枠がある。
依頼主は、予算という枠を持っており、作り手は、請負契約という枠を作る。
作り手はこの枠によって、身を守ろうとするが、その実、役に立っていない。
なぜならば、この契約は、建て前はどうであれ、相手に白紙の小切手を
渡すようなものだからだ。
依頼主は、いくらでもその紙に機能を書き出して、作り手に返し、
すべての実装を要求することができる(と思っている)。
もちろん、いくら紙に必要な機能を書き出したとしても、その紙は
不履行になる可能性を持っている。
それは、依頼主にとっても大きなリスクを抱えることになる。

だから、この枠で、仕事をすること自体をやめるか、せめて、枠を小さくしよう。
そもそもの枠が小さいのだから、明らかに詰め込められる容量はそこには無い。
枠が小さければ、それが理解できる。
枠が一杯になったら、次の小さな枠を作ればいい。
しかし、なまじ最初から枠が大きいと、その容量の見極めを誤ってしまう。
いきなりエベレストの登頂を目標におくようなことはやめよう。
まずは小さな山を登ろう。
その山の高みから、次に登るべき山を探す方が健全だ。