開発者がCTOに嘘をついた経緯
- 数年前、フォーチュン500企業で働いていた頃の話
- 当時のCTOは個人的な人脈のある重要顧客のために大きなプロジェクトを受注し、核心部分を大手技術サービス企業にアウトソーシングすることを決めた
- しかしベンダーの「製品」は、実際には要件に合わせるために大規模なカスタマイズが必要で、最悪の選択だった
- CTOとの進捗確認会議では誰もこのアイデアが良いとは思っていなかったが、みな「いい考えです、ボス」と言うだけだった
- 結局、ベンダーが「製品」を納品した時にはすでに9月で、10月リリースに向けたデスマーチが始まった
- テスト中に性能問題やMongoDBの16MBドキュメント制限に引っかかるなど、深刻なバグが見つかった
- 顧客には1か月遅れでリリースすると伝える一方で、同時にベンダー統合を置き換える秘密プロジェクトを始めることにした
- 若く情熱的な開発者だった私は、チームメンバー3人を割り当てられ、代替システムの開発を始めた
- 12月中旬、ここ1か月で代替ソフトウェアをほぼ完成させたが、全員が燃え尽き状態だった
- そのときCTOがやって来て、休暇を取り消すと言い、私は「わかりました」と答えた
- しかし父の助言を思い出し、チームメンバーには休暇に行くよう伝えたあと、ひとりでCTOとのデスマーチ進捗確認会議に出席して嘘をついた
- 「チームは一生懸命取り組んでいます。今日、73番目のマイルストーン統合ポイントに到達しました」
- 「チームは昨日、良い進展を見せました。また別のWebサービスを完成させたんです」
- 1週間後、休息を取ったチームメンバーが戻り、1月に期限どおり無事リリースできた
GN⁺の見解
- 劣悪な環境と無理な要求の中でも、プロジェクトを成功に導いたリーダーシップが際立つ事例。特にチームメンバーのコンディション管理に気を配った点が印象的
- ただし、CTOに嘘をついたことは望ましくない。長期的には組織内の信頼を失い、より大きな問題を招く可能性がある
- ベンダー選定とアウトソーシング管理に失敗した責任はCTOに大きくあるが、それを正す過程では、より透明で積極的なコミュニケーションが必要だったように思える
- 開発者の燃え尽きを防ぐためには、そもそももっと現実的なスケジュールを立て、十分な人員を投入すべきだった。クランチモードは避けるべき慣行である
- 類似の問題状況に直面した際に参考になる代替案としては、アジャイル手法がある。短い周期で開発し、フィードバックを受ける過程を繰り返すことで、リスクを最小化し、チームメンバーの業務負荷を調整できる
1件のコメント
Hacker Newsの意見