エンジニアは正解に合わせるのではなく、正解を作る仕事している

ある日、ミーティングに出ていながら「（そうじゃないんだよ）」と感じたことを記憶に引きずったまま、翌朝、それを電車の中で思い出した。

その場では、話の持って行き方はケースごとに変えないとおかしくなってしまうよ、と伝えたがいったいどれだけ通じていたか。

システム開発は、顧客の実現したいことを探りながら工程で詳細化することでコードに落とし込み、それをテストを組み上げることで動くものとして実現する。

このアプローチの良いところは、作業する前にゴールを設定できることだ。これを作ればいいと確認した上で、作業を始められる。

別の切り口で見てみよう。

内製で作るのでなければ、つまり、作業を外部に委託する場合、その組織間には契約が生じる。その契約を履行させたい、履行するために、双方で役務を具体的に書面に記述する。

ここでもまた、履行したかどうかを判定する基準が定められる。そのため、お互いに成果物となっているかを検査する。ここにも作業前にゴールを設定することになる。

2つのことから、それを実現するエンジニアには契約を履行するための成果物を正として作業をすることになる。また、それができるようになるように刷り込まれる。

それの弊害が、作業をする前に正解を求める。

確かに、委託元とのやり取りではそれでもいい。その相手が組織の中であったらどうだろうか。

組織の中でも分掌があるのだから契約書は交わさないまでも分担するのだから、作業のゴールがあるだろうという意見もあるかもしれない。一担当であればそう考えていてもいい。でも、それで許容されるのは担当までの話だ。組織の成長ステージによっては、新人だろうがそういう考えはリジェクトされる。

エンジニアが正解を作らなければならないこともある。現実にはSIプロジェクトでもエンジニアが正解を作りながら、作った正解を積み上げながらプロジェクトを進めているのだが。

今はこうだ、という仮説を置き、積み重ねるのはそうしないと進まないということもあるが、間違っていたらそこまで立ちもどれるようにするためだ。

そう言ったやり方は、正解だったじゃないかと人質にとるようなものではない。エンジニアが正解に合わせて作業をしていては単なる作業工でしかない。そこには知的労働は皆無だ。エンジニアは正解を作る側を担う専門職であるのだから。