【第66回】「要件」という蜃気楼（３）

そんな困難な「要件定義」工程ですが、どうすればうまく進めることができるでしょうか？

「お前ごときが偉そうに！」

と怒られそうなことは重々承知の上、考えていることを２つほど。

一つ目は「誰が、どのような体制でやるか？」

実現性を無視した理想を言えば、「情報システム構築を担当する開発会社のＩＴエンジニアが、顧客企業の中に入り込んで対象業務を３年ほど経験、現場も管理業務も知り尽くしてからプロジェクトをスタートさせる」が一番ですね。

え？無理だって？

そうですか。そりゃそうですね。

（でも、もしアメリカ型の「成功請負人が高額の有期雇用契約でプロジェクトを転々」というような契約形態が一般化すれば無理ではないかも、とは思います）

次善の策としては、「優秀な」（←ココ重要）独立系ＩＴコンサルタントに陣頭指揮取ってもらうプランでしょうか。

顧客企業とも開発会社とも一定の距離を保ち、冷静かつ客観的に、社内政治やセクショナリズムの影響を頑として受け付けない立場で業務推進するパターンですね。

え？いないって？

そうですか。そうかもですね。

では仕方ありません。

顧客企業のエースと開発会社のエースにそれぞれちゃんと出てきてもらい、必要な権限を持たせた上で徹底的に議論進めながら共同で進めてもらいましょう。

最終決定権は顧客企業側が持つとしても、開発会社側も堂々と渡り合いましょう。

え？なんですか？

いやいやいや、ここはもう、ぜひそうしてください。以上です。

次です。

二つ目は「どこまでやるか？」です。

前述の通り、「要件定義」とは「蜃気楼を捕まえる」ような工程です。

それなのに、その成果物「要件定義書」は、とかく「絶対的存在」になりがちです。

にもかかわらず、後工程に入ってから要件定義書を読み直すと、「なんて何も見えていなかったのだろう？」とあきれる思いをしたこと、皆さんもあるのではないでしょうか？

「要件定義に過度な期待をせず、まずは最小限にしてスモールスタートを目指す」

「曖昧な要件は無理せず次期開発や保守工程にまわす」

結局それしかないのでは、というのが、今の私の結論です。