1. 何かが間違っている
負のスパイラルの原因は「レガシーコード」が原因という側面がある。
そうならないために技術プラクティスがどのように機能するかを理解し実践すると、負のスパイラルにはならない。
ということを長い例え話で説明している。
負のスパイラルの例
チームの中心的な開発者たちは優秀だった。
一方で、チームにはコードモンキーがいて、自分の機能を作ることだけしか見ていなかった。
その機能が全体にどう影響するかは考えておらず、彼らの仕事のいくつかが短期間で大きな問題を引き起こし、そのあとさらに大きな問題を引き起こすことに気づいていなかった。
チーム全体は、技術プラクティスの背後にある理由を理解してはいなかった。
しまいには、あっちこっちで異なる標準を使って作業を進め、システム全体は見ていなかった。
そして、賢くて経験豊富なエキスパートがリードしていたのにも関わらず、ソフトウェアは扱いづらいものになった。
コードの統合は、誰も楽しみにしていない悪夢のような体験になった。
重量級のソフトウェア開発プロセスは大きな妨げになっていて、もはやまったくコードを生み出せないほどだった。
マネージャーたちも賢くて経験豊富だったが、結局、開発者と同じようにイライラしやる気を失った。
もう、開発者に何を指示すればよいかわからないかのようだった。
組織内に信頼はなかった。
そこで経営陣は、多くのプロセスを追加する対応を取った。それがさらに信頼を損ね、締切がさらに変更となった。
会社全体が死のスパイラルに陥っていて、7億5,000万ドルの事業全体が危機に瀕していた。
会社は過去10年間で飛躍的に成長したにもかかわらず、結果としてコードはひどいことになっていた。
この会社は何年にもわたって「アジャイル」を進めようとしていたが、多くのチームでアジャイルプラクティスのいくつかを導入すると、既存のコードがいつも邪魔をした。
既存のレガシーコードと、こんな状況になるまで蓄積してきたすべての悪習の両方に対処しなければいけないことを彼らはわかっていた。
私は、この問題を「人の問題」ではなく「レガシーコードの問題」だと考えた。
学び
- アーキテクチャや設計を考慮せず、言われたことだけやるプログラマをコードモンキーと言うのか。
- 長い例え話に思いが詰まっていることが伝わる。そして共感する部分もある。
- 経験が浅いうちはやる気があっても視野が狭かったりスキルが追いつかなかったりで、実質コードモンキーの時期はある。
学びを活かすアイディア・行動
- キャリア整理のための資料作り
