偽物の完璧主義者のエンジニアにはアウトプットを小さく積み上げさせよ

ドキュメントを作る、レビューする、修正する。プログラムを作る、コンパイルする、テストをする。単体ででストをする、繋いでテストをする、業務でテストをする。

どれもこれも、一つの作業はさらに分解されて、小さな部品を積み重ねて大きなシステムに纏まっていくわけで。その一つ一つの部品の出来が、作る人によってまちまちなら、その部品を持ち寄って組み立ててみても気持ちよく組み合わさるなんてありえないです。

一つひとつの部品を作るにしても、いくつかの段取りを踏まえて出来上がるわけでその段取りからアウトプットを出すこと自体が日々の生業なわけで。

その一つの小さなアウトプットが1枚の設計書でもパラメータシートでも、書いて、セルフでレビューして、レビューして、と段取りを踏むことはどこのプロジェクトでも変わらないもので、そのレビューで行われるレビュー観点で求められる品質要求がプロジェクトで何を大切に思っているかで左右されるものだと思うのです。

偽物の完璧主義者
ワタシは納期に間に合わない、品質要求を確保できない割に納期間際になるまで自分の満足のいくように作り込んで、要求とは違うものを作るエンジニアは“偽物の完璧主義者”だと思っています。

本物の、職人肌の完璧主義とは程遠い、ちょっと見ればあちらこちらに修正漏れや言葉の揺れがみつけられるようなアウトプットしか作れないエンジニアは意外といるものです。

プロジェクトにそうした“偽物の完璧主義者”のエンジニアが紛れていることが判明すると途端に生産性が落ちます。こうしたいエンジニアがなぜ生き延びるのかは不思議でありませんが、するすると紛れ込むとプロジェクトマネージャにとっては厄介なことをしょい込んだことになるのです。

何せ、“偽物の完璧主義者”のエンジニアは、その自覚がないから、“偽物の完璧主義者”だとこちらがわかってから仕事の進め方を変えてもすぐにやり方を戻してしまうのです。何度言っても。

その根底には、“偽物の完璧主義者”自身がそれまで生き延びて掴んできた何かがあるのかもしれないですが、そのエンジニアのアウトプットを受け入れる方の立場になれば、迷惑千万でしかないのです。だって、自ら方向性のズレを確認したり、要求品質の充足を確認するために途中経過見せてと言っても出てくるのは、中途半端だし、いやそれがわかるだけでもあきらめがついて助かるけれど、納期間際になってもそのままのレベル出てくるので、「もう！」と毎回、牛のごとくうなるしかないのです。

当のエンジニアは自分としてある程度満足して作っているので「どうしたの？」って不思議な顔していたり、「いや、もっと直したいんですけど。」と納期なんてさっぱりどこかにやってしまって、一体いつになったら「お前は要求子売る品質レベルのアウトプットを作れるんだよ！」って突っ込みたくなるんです。で、それは絶対にやらせてはいけないですが。砂場の中で砂をずっと混ぜているだけなので一向に砂上の城もオブジェクトもできないのです。

幾ら修正箇所を伝えても、赤い入れしても、一回で直ることはありません。が、分業している以上、あれもこれも巻き取るわけにはいかないですから。

インパクトは小さく受ければその粒度で受けられる人のパイは増えるものです。つまり、それは自分一人で受けるのではなく、誰かほかの人に一次的に小さな粒度でアウトプットのインパクトを緩衝してもらい、それを積み重ねることで納期には最低限度の品質を確保しようとするインパクトを最小限にマネジメントする手立てが一番地味で確実なのではないかと思うんですけど。

いや、ほんと、こうした偽物の完璧主義者が混ざっているとプロジェクトで元々抱えなくていいオーバーヘッドのリスクを識別しちゃうことになるので辛いです。こうした偽物の完璧主義者って愛想がよかったりするからするっと紛れ込むんだよなぁ。