木こりのジレンマ〜開発プロセスとコミュニケーション〜
「木こりのジレンマ」という話がある。
木こりが一生懸命木を切っていた。でもノコギリの刃が鈍くなって作業効率が下がっていく。
「ノコギリを研いだら？」と聞かれたが、「そんな暇はない！木を切らなきゃ！」と答えた。
効率を上げるための時間を取らずに、ひたすら作業を続けてしまうジレンマの話。
これ、開発プロセスやコミュニケーションの改善にも当てはまると思う。
「このやり方は非効率だな」と思いつつ、改善せずに目の前のタスクをこなし続けることで、
じわじわとチームの生産性が下がっていく。
開発プロセスの木こりのジレンマ
開発チームでは、こんなことが起こりがち。
CI/CDが遅いけど、見直さない
「ビルドに15分かかるけど、直すの面倒だしこのままで」
1回の待ち時間は小さいが、積み重なると大きなロスになる
毎回同じ問題で手戻りが発生する
「この仕様、また認識ズレてた」
仕様の確認プロセスを整備せず、繰り返し手戻りが発生する
技術的負債を放置し続ける
「リファクタリングしたいけど、今はそれどころじゃない」
放置するほど影響範囲が広がり、結果的に改修コストが跳ね上がる
どれも改善すれば開発スピードが上がるのに、
「今はそんな余裕がない」と後回しにされがち。
コミュニケーションの木こりのジレンマ
開発プロセスだけでなく、チーム内のコミュニケーションも改善されずに停滞しがち。
無駄なミーティングが続いている
「この定例、いるのかな？」と思いながらも、なんとなく続いている
みんな時間が取られているが、誰も見直そうとしない
質問しづらい環境がそのまま
「この仕様、誰に聞けばいいのか分からない」
問い合わせの手間が増え、同じ質問が何度も繰り返される
ドキュメントが整備されない
「この情報、どこにある？」と毎回探し回る
でも「ドキュメントを作る時間がない」と改善しない
こうした問題も、時間をかけて整理すれば解決できるのに、
「今はそんな暇がない」と後回しにされてしまう。
改善の時間を確保するには？
開発もコミュニケーションも、改善の時間を確保しないとジレンマから抜け出せない。
1. まずは課題を見える化する
「どこに無駄があるか？」を洗い出す
例えば、「ビルド時間」「手戻り回数」「ミーティングの頻度」などを可視化
2. 小さな改善から始める
いきなり大きな改革をしようとせず、「1つのミーティングを試しに減らしてみる」くらいの規模で試す
3. 改善を定期的なタスクにする
「手が空いたらやろう」ではなく、「週1時間は改善の時間」とルール化する
定期的に「改善の余地はないか？」を振り返る
結局、改善しないと開発スピードは落ちる
開発プロセスやコミュニケーションの問題は、
「今は忙しいから」と後回しにしていると、
その影響でどんどん非効率になっていく。
短期的には目の前のタスクを優先するのが正解に見えるけど、
長期的に見ると「ノコギリを研ぐ時間」を意識的に取ることが大事。