何かの案件で最短で着地させたい、着地優先でという話が時々あります。その時の戦い方を間違えているのを頻繁に見るので記しておこうと思います。
良く遭遇する間違った戦い方
- 修正コードが少ないだろうからと、業務遂行能力の低い人に振る
- 既存の機能をこねくり回して無理矢理実現しようとする
それぞれ考察します。
1. 修正コードが少ないだろうからと、業務遂行能力の低い人に振る
Productionに40点の品質を出すわけにはいかないので、80点以上にする必要があります(状況によっては60点でも良しと判断する時もありますが、結局40点ではリリースできません)
こちらを参照レビューには様々な目的がありますが、その1つには繰り返して良くないコードを書かないための教育も含まれます。ここを怠ってしまうと何度もProductionに出せないコードを書いてしまいます。またコードの品質だけでなく、コミットの粒度はこうした方がBetterではないかという話も含みます。
端的に言えば、いくら着地を優先するからと言っても40点の品質で出すわけにはいかないので、短い修正コードでも何度か往復する事になります。結果的にシニア人材の工数とジュニア人材の工数を使ってしまい、着地が伸びるという事に繋がります。
着地優先だからレビューを甘めにという考えがそもそもおかしいのです。
2. 既存の機能をこねくり回して無理矢理実現しようとする
ちょっと手を入れた方が確実に着地が早まるのに、既存の機能だけでどうにか実現しようとしてぐちゃぐちゃにする事案です。コードを書かない方が早いというのはQA工数など割けると考えているのか、単純に実力不足なのかは分からないですが、設定変更をしたり、普段とは違う使い方をするなら検証は必要です。それでも、どっちにしろQAやってないじゃんというお気持ちではありますが。
既存の機能の抜け道を考えてぐちゃぐちゃに考えた結果、それに時間がかかって最短で着地できないどころか、そもそも着地出来ないという事を見かけます。
コードに手を入れない事が最速であるという前提がそもそも間違っており、時間がよりかかる方法で積み木を変な風に重ねていって機能としてロールバックできない負債を作ろうとしているのに遭遇すると、一体何をしたいのだろうと思います。
まとめ
これを読むと、仕事を任せると言うことは〜みたいな話になりますが、そういう話ではなく本当に着地を優先させるのであれば、着地を優先させるための戦い方というのがあるという話です。着地が最優先と言いながら、理にかなった戦術をとらないのが目の前で何回も起きているので、首を傾げている毎日です。
あと、コンパイルが通ったからと言って正しく動くわけではないし、正常ケースのみ動かして検証したと言うのはQAでも何でも無いただの動作確認だし、ログや内部状態を見ないで動いたというのはエンジニアのやる行為では無い。という事も付け加えておきます。