マイページ
静かに起動する「安請け合い時限爆弾」
条件が曖昧なまな、営業が「安請け合い」したプロジェクトは、「時限爆弾」のようなものです。この爆弾の恐ろしいところは、起動音も出さずに、一定の時間差をおいてから多大な被害をもたらす点です。
表面上の言葉は「できます」「頑張ります」と前向きで協力的でも、納期・スコープ（範囲）・予算といった明確な合意が欠如したまま進めば、その代償は必ずどこかで清算されなければなりません。
そして、その清算の多くは、現場のエンジニアの過酷な残業や、システムの品質低下という形で静かに行われます。爆発の音がしないため、営業も顧客も「プロジェクトは順調に前に進んでいる」と錯覚してしまいますが、開発現場の疲弊は確実に蓄積されているのです。
「曖昧さ」を徹底的に排除する
では、この「安請け合い時限爆弾」の起動を防ぐためにはどうすればよいのでしょうか。その確実な解決策は、コミュニケーションから「曖昧さを排除する」ことです。
開発現場には、「なるはやでお願い」「良い感じで仕上げて」「しっかりテストして」といった言葉があふれています。しかし、これらは解釈が人によってバラバラになる「情報ゼロ」に等しい危険なフレーズです。
例えば、「なるはや」が今日中なのか今週中なのか、「しっかり」が単体テストなのか結合テストまで含むのか、人によって受け取り方は大きく異なります。この認識のズレが、後々の手戻りや炎上を引き起こします。
こうした曖昧さを排除するためには、タスクの「期限」と「状態」を明確にする必要があります。期限については「なるはや」ではなく「金曜の18時までに」、状態については「良い感じで」ではなく「レスポンスを1秒以内に」「テストを全件実行して」と、個人の解釈の余地が生じない具体的な条件で定義するのです。
もし、営業や顧客から状態が曖昧なまま「週明けまでに対応お願いできる？」と要求されたら、エンジニアは決して安請け合いしてはいけません。
自ら「対応とはどの状態までですか？ 形だけ動けばいいですか？ テストまで含めますか？」と質問をし、グレーな部分を明確化しましょう。
曖昧な言葉をそのまま流せば、必ず後で修正や残業という重いコストを払うことになります。逆に、最初に条件を具体化し、認識のズレをなくしておけば、その後の仕事は驚くほどスムーズに進みます。
曖昧な「技術的には可能です」に逃げるのではなく、互いの前提を言葉にして明確な合意を作ること。それこそが、プロジェクトを時限爆弾から救う第一歩なのです。
