開発プロセスの話-プロセスのアドオンは悪

再発防止策≠プロセスの追加
ではかならずしもそうではないよ。

100%防げる方法があるなら教えてほしいし、
知ってる人がいるなら今すぐやるべき。
ただそんな楽観的ではいけない。

100点を取るのは0点を取るより難しいのです。
ではどうするか、
個人的には「リカバリー可能な状態」を作る方が先だと思っている。

例えば、デグレート。
デグったら、
・まず謝る
・最速で、回避策なり暫定策を構築
・原因を突き止め再発防止策を検討
・直す
このとき、再発防止策は「無意識的有能」な状態がベスト。

誰でも思いつくものであれば、それは出荷時の怠慢なので、しっかりクリティカルシンキングして、ベストを探す。

ここを高速に実行出来る体制なら、
多少のリスクは取れるのでは？と思う。
スピードダウンさせる無駄なプロセスは排除できるのでは？と思う。

少なくとも私は、
ちゃんと単体テスト書いて、
E2Eも必要十分にやってる。
それでも平均年1でデグレ起こしてる。(3〜40件のうち1件)
(そこはすまん。一方でまだまだ成長の余地だとポジティブに考えてはいる)

ただ、
理論的に大丈夫だけど、もし「この案件デグったら」「デグるとしたら」をだいたい考えているので、
何か起きてもたいてい、最速で暫定なり原因追求なり、回避策を出せていると思う。

社員の成長を後押しすると言う建前の裏では
ルールに縛られて、重たいプロセスで、初めての1件出荷するのに膨大な工数を使っている。

というのは成長速度を遅め、製品の改善速度を遅め、結果、市場価値の成長が鈍化する原因と考えている。

ゆえに、私は、チームメンバーの成長速度を最も重視すべきだと考えているので、

とにかく経験積ませる、技術や経験を伝える

というところを最も大切にしたい。

その結果、仕事が粗く、品質があまり高くない場合は、マネージャーやシニアエンジニアがフォローして直して、「なぜダメなのか」「なぜ品質が低いのか」を振り返りすれば良い。

この方が、無駄なデグレ対策プロセスをアドオンしていくより、よっぽど現実的かつ、中長期的に最も生産性の高いやり方であり、

「働くを楽しんでいる」状態だと思っている。