株式会社ラフティ | Time Craft Consulting
Chapter 2 企画・提案
期待値を壊さないために最初に決めること
ITプロジェクトにおける失敗の多くは、
開発中やリリース後に起きているように見えます。
しかし実際には、
企画・提案の段階で、すでに期待値は壊れ始めています。
この章では、
「なぜプロジェクトは炎上するのか」ではなく、
「どこで期待値が壊れたのか」
を一つずつ分解していきます。
2-1. 理想像が言語化されないまま進む
企画の初期段階で、
次のような言葉がよく使われます。
-
「業務を効率化したい」
-
「DXを進めたい」
-
「使いやすいシステムにしたい」
これらは 理想 ではありますが、
要件でもゴールでもありません。
理想像が言語化されないまま進むと、
-
人によって完成イメージが違う
-
評価基準が存在しない
-
成功か失敗かが判断できない
という状態になります。
「何をもって成功とするか」
これが言語化されていない企画は、
必ず途中で期待値が崩れます。
2-2. 前提条件が共有されていない
多くの提案では、
「できること」だけが語られます。
しかし、現実のプロジェクトには
必ず制約があります。
-
既存業務のやり方
-
現場のITリテラシー
-
実際に触る人の人数やスキル
-
使える時間と使えない時間
これらの 前提条件が共有されないまま
提案が進むと、次のズレが起きます。
-
ベンダーは「使える前提」
-
現場は「そんな余裕はない」
-
経営は「すぐ成果が出ると思っていた」
期待値は、
前提条件が共有されなかった瞬間からズレ始めます。
2-3. 前提条件が共有されていない
提案書には、
魅力的な機能や将来像が並びます。
-
機能一覧
-
技術構成
-
拡張可能性
-
他社事例
しかし多くの場合、
「できないこと」「やらないこと」 が書かれていません。
結果として、
-
書いていないこともやってくれると思われる
-
暗黙の期待が膨らむ
-
「それも含まれていると思っていた」という言葉が出る
これは悪意ではありません。
構造の問題です。
提案とは、
「夢を語ること」ではなく、
「範囲を区切ること」 です。
2-4. スケジュールが希望ベースで決まる
企画・提案段階では、
スケジュールが次のように決まることがあります。
-
「このイベントまでに」
-
「年度内に何とか」
-
「できればこの日までに」
これは判断ではなく、
希望や願望です。
スケジュールが希望ベースで決まると、
-
無理が現場に押し付けられる
-
品質か安全性が犠牲になる
-
トラブル時に誰も責任を取らない
本来、スケジュールは
コスト・品質・リスクとのトレードオフで
判断されるべきものです。
それが行われていない場合、
期待値は必ず壊れます。
2-5. 責任の所在が曖昧なまま合意する
企画・提案フェーズでは、
次のような言葉が使われがちです。
-
「一緒に進めましょう」
-
「協力しながらやりましょう」
-
「柔軟に対応しましょう」
一見すると前向きですが、
責任の所在を曖昧にする言葉でもあります。
合意とは、
-
誰が決めるのか
-
誰が責任を持つのか
-
何が起きたら誰が判断するのか
これが明確になって初めて成立します。
責任なき合意は、
後で必ず期待値を破壊します。
2-6. 契約が「信頼関係」で締結される
企画・提案の最後に、
次のような空気が流れることがあります。
-
「細かいところは後で」
-
「信頼しているから」
-
「長い付き合いだから」
しかし契約とは、
信頼を前提にするものではありません。
信頼が揺らいだ時のために存在するものです。
期待値を文章に落とさず、
関係性だけで契約した場合、
-
解釈の違いが起きる
-
トラブル時に感情論になる
-
「話が違う」という言葉が出る
これは避けられません。
2-7. この章のまとめ
期待値は、
勝手に壊れるものではありません。
-
言語化されなかったとき
-
前提が共有されなかったとき
-
判断が曖昧だったとき
設計されなかった瞬間に壊れます。
企画・提案フェーズでやるべきことは、
期待値を上げることではありません。
期待値を正しく整えることです。
プロジェクトを成功させるとは、
期待を煽ることではなく、
失望を生まない設計をすることです。
次章では、
この期待値を壊さないまま
要件定義をどう設計するかを扱います。