システム要件の暗黙知化について（あるいは無知）

要件定義のポイントは、だれにでもその要件がわかるようにすることが必要と思う。文章でもいいし図表でもいいし確かにああそうだねと理解できることが必要。業務の流れ、データの流れ、インプットとアウトプットを明確に知りたいと思う。
しかし要件定義において良くあるのは、「現行通りにつくってください」ということがよくある。そのパターンが一番困る。現行を知るためには、無限のインプットのパターンとそのアウトプットを確認するか、何万行〜何百万行のソースコードをよむしかない。ソースコードの中にもマジックリテラルが仕込まれていて意味不明なことは普通にあり得る。

ではお客様はどのようにシステムを使って仕事をしているのだろうか？仕事のひとつひとつの意味を理解している人は少ないのかもしれない。企業は、一人一人の仕事の総体でお金を稼いでいるはずなのだけれでも、自分の担務の意味（特にシステムを使う意味）を理解している人は少ないのかもしれない。画面の文字の位置、帳票の文字の大きさには異常にこだわるのに、なぜその位置に文字がないと困るのか答えられる人はいない。

当初この文章を書き始めたのは、要件が属人化していてプロジェクト全体に共有化されにくいということを書こうと思った。その仕事のある領域では達人みたいなひとがいて、またそれを聞き取ったエンジニアも共有できる形に要件をまとめきれず、結果的に設計をするにあたって「聞き直す」しかない。「なんでそんなこともわからないのか？」「まえに話したはずなんだけれども」と怪訝な顔をされる場面が過去によくあったからだ。

しかし、よくよく考えてみると上段で書いたように実は「本当に要件を知っている」人はいないのかもしれない。細部にわたってこだわりがあり、何かを知っているように見えて、なぜそのような仕事の仕方なのかを理解している人はいない気がする。
したがって要件が不明なプロジェクトは失敗する。

※最後に「プロジェクトは失敗する」でしめるのが多くなってきた気がする。失敗シリーズとでも名付けようかな。