デスマーチで学んだディレクターを殺さないための10の教訓
失敗談デスマーチディレクターCMS開発
「要件はほとんどできてるから、納品を経験してください。」
——その言葉を聞いてから3ヶ月後の日曜日、僕は会社のデスクに座っていた。そういえば月350時間超の終わらない労働時間、シャワーしか自宅に帰れない日々、深夜3時の呼び出し。もはや思い出したくもないプロジェクトを今こそ解剖してみる。
プロジェクト概要
あのプロジェクトはいったい何だったのか、、
モバイルCMS開発案件。エンドクライアントは「モバイルCMSをアジャイルで、FeliCaポイント機能つきで、予算500万で、3ヶ月で、ドキュメントは不要で、アプリ版管理画面も」という要求を複数の部署から別々に飛ばしてくる状態でスタートする。
エンドクライアントは好き勝手を言う担当が5名以上、元請け企業は会議にもメールにもいっさい出てこない。そしてエンジニア中心のチームの先頭に立って、その全方位の要求を受け止めたのは、ディレクターたったの1名。
クライアント折衝・進捗管理・ドキュメント作成・デバッグ・予算管理・見積もりになかったマニュアル作成、担当名なきタスクたちは基本自分だった。
事件連発
あの3ヶ月で起きたこと
振り返ると、あれはただの過労ではなかった。構造的に設計ミスが重なった、予測可能な失敗であった。
「検収不可.pdf」というパワーワード
検収基準が最初から合意されていなかった。完成の定義が存在しない状態でプロジェクトが走っていた。
現場の不満がメーリングリスト違いでクライアントに誤爆
疲弊したチームのミスは情報管理の崩壊から始まる。内部用と対外用の境界が溶けた瞬間だった。
深夜3時に元請けの検証作業現場へ複数回呼び出し
断れる関係性が構築されていなかった。NOと言えない状態がスタンダードになっていた。
2度目の納品直前、テストデータALL DELETE事件
環境分離が不完全なまま本番に近い作業が走っていた。インフラ設計の甘さが最悪のタイミングで露出した。
完成したモバイルCMSは結局「お蔵入り」
使われないものを全力で作り続けた。ビジネス目的の合意がないまま開発が完走した証拠だった。
現場の実態
「自社オフィスの執務室では学生インターンのエンジニアが他案件の指示も受けながら無双阿修羅状態。MTGスペースでは元請けクライアントが10分おきに進捗を確認。ディレクターはその中間で『めっちゃ作業進んでると思ってるんだろうな…』と思いながら板挟み。」
教訓
あの地獄が教えてくれた10のこと
「完成の定義」を最初に文書化する
検収条件が合意されていないプロジェクトに「完了」は来ない。契約前に検収基準を書面で固める。
要件を一元窓口に集約する
課長・役員・メンバーがそれぞれ別の要件を言ってくる構造は、必ず矛盾を生む。クライアント窓口を1名に絞ることを土下座してでも条件にする。
「ドキュメント不要」は受け入れない
ドキュメントを省略するとディレクターが仕様書の代わりになる。記憶で走るプロジェクトは必ず崩壊する。
アジャイルとスコープ固定は両立しない
「流行りのアジャイルで」と言いながら予算と期日が固定されているのはアジャイルではない。偽アジャイルを見抜く。
NOと言えない関係性は作らない
深夜呼び出しに応じ続けると、それが標準になる。最初の1回に応じた時点でルールが設定される。
ディレクターは全責任を1人で背負わない
クライアント折衝・進捗管理・デバッグ・予算管理を同時に1人でやる体制は、設計ミスだ。それを許容した側にも責任がある。
インフラ設計をケチらない
本番データ消失事件は弱いインフラの必然的な結果だった。「悲しい弱インフラ」はプロジェクトの地雷になる。
ビジネス目的を最初に確認する
「このシステムが完成して、誰が何を得るのか」を言えない関係者がいるプロジェクトは、お蔵入りリスクが高い。
「もうすぐ終わる」を信じない
「ほとんどできてる」は進捗ではない。残課題の定量的な確認なしに続行判断を下さない。
撤退・縮小の判断基準を持っておく
デスマーチは止める判断が遅れるほど被害が拡大する。「辞める」を選択肢として最初からテーブルに置いておく。
chat_bubble コメント
かなしい
のーとくん