技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす

元糞コードマイスターとしては、生産性については思うところある。

技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。

そもそもマイナスになる人がいるって話。

隠しパラメータをモデル化

エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。

ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く

次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。

これは割とエンジニアにとっては直感的だと思う。このときAはBに比べて7/5, 1.4倍の生産性があると言ってもいいのではないか。

この技術的負債、エンジニア以外には観測できないから厄介だと思う。小さいプロジェクトだったりすると、このリスクが露見する前に終わったりするから、問題になりにくいけど、プロジェクトが巨大であればあるほど破綻リスクがある。コード書けないSIerに進捗管理されたくないってのもこれに尽きる話であると思う。

マイナスの成果

外から見た時にエンジニアの成果はそれぞれに見える。みんな同じことをしているわけではないから、わかりにくいと思う。

それでも、エンジニア同士での評価として、中には「週に10の成果を出して10の負債を生む人」がいるとする。この人は、外から見た時にプロジェクトに貢献しているように見えるが、その実プロジェクトに貢献していない。

でも、見た目上はそれなりに仕事しているので、他のまともなエンジニアと同じぐらい外部から信頼されてしまう。リファクタリングもできないから、とりあえず新規に開発することを任されてしまい、負債係数aによって実は負債の蓄積を加速させる。しかも他のまともなエンジニアが尻拭いさせられている。

こういう人が責任ある立場だったり、昔成果を出してたり、政治が上手い人だったりすると、現場がデスマに向かっていく。

成果を出してない人をどう扱うべきか

一人でコードを書かせてはいけない。教育されなければならない。プロダクション品質のコードが書ける人間として扱ってはいけない。これはエンジニア間で、ペアプロなりコードレビューなりで指導する必要がある。

繰り返すけど、こういう人ほど技術的な向上心がなかったり、政治が上手いので同僚は警戒する。で実際にデスマを起こすと、まともな、尻拭いをさせられる人から離職する。

見積もりを失敗させる「対糞コード耐性」

さらにエンジニア毎に隠しパラメータがあって、「対糞コード耐性」というパラメータがある。このパラメータが高いほど技術的負債によるパラメータaの係数を軽減できる。さらには「糞コード習熟度」というパラメータもあり、既存の糞コードへの理解が高過ぎると技術的負債を無視してしまう。もちろん、個人の資質であり、チームには貢献しない。

さらに、エンジニアは「自分の生み出した負債」については、その負債の量が半分未満に見える、もしくは見えないという性質がある。これによって他人がその人が書いたモジュールを触るとき、見積りが失敗する。もちろんこれによってリファクタリングが早くなるのだが、糞コード耐性と自分の生み出した負債に対する甘えで、属人性の高い危険なモジュールができあがる。コワイ！

エンジニアに言いたいこと

見つけ次第ペアプロして、コードレビューで教育しろ。チームで会話しろ。政治で解決しようとしたやつを止めろ。

コードを書くと必ず負債は貯まる。負債をみつけるのも技術のうちだ。誰もが最初は糞コードを書くから、経験値を貯めてそうならないようにしよう。負債が貯まるより速く、負債を解消する技術を身につけよう。

状況が改善されないなら離職という態度をとるのも仕方ないと思う。

「週に9の成果を出して0の負債を生む人」がいる。パッと見地味だけど、そういう人を正しく発見して尊重にするのがエンジニアとしての貢献のうちであるとも思う。

マネージャに言いたいこと

初週のベロシティが未来永劫続くと思うな。