CASE 14 ／ 期待値の管理
「言わなかったが、気づいてほしかった」
仕様通りに作ることと、課題を解決すること。その間には、誰かが埋めるべき溝があります。都度開発のモデルでは、その溝が構造的に放置される。
状況
あなたは、あるメディア企業のアプリ追加開発を担当しています。契約は準委任で、依頼が来るたびに見積もり、開発する「都度開発」のスタイルです。
ある機能を公開し、検収に入ったところで、先方から指摘が入ります。要望の一部が、入っていないというのです。
先方も、こう言っています。「該当箇所を、はっきり伝えられていなかった自覚はあります」。ただし、続けてこうも言いました。
「ビジネス課題を考えたとき、違和感を持ってほしいポイントでした。そこを期待していたんです。」
あなたなら、どうする？
「言われていないこと」を求められています。どう受け止めますか。 — 選ぶと、その選択の「ありがちな帰結」が開きます。正解当てではありません。全部読み比べてください。
— 残り 3 件の帰結が未読です —
実際の顛末
改修の見積もりを提示しつつ、当面は運用でカバー。並行して、要件の粒度が粗いまま見積もり依頼が来る構造自体への改善（先方社内での要件整理の進め方）にも働きかけました。
「仕様通りに作る」と「課題を解決する」の間には、誰かが埋めるべき溝があります。都度開発のモデルでは、その溝が構造的に放置される。埋めるのは気配りではなく、工程です。
このケースの教訓
- 「仕様通りに作る」と「課題を解決する」の間の溝は、工程で埋める。個人の気配りに任せない。
- 都度開発モデルには、ビジネス文脈を理解する工程が構造的に存在しない。
- 相手が本当に問うているのは、1機能ではなく「事業を考えてくれているか」。
持ち帰りチェックリスト
- 見積もり時に、ビジネス背景をヒアリングする項目があるか
- 受け取る要件の粒度に、受け入れ基準があるか
- 「言われていないが必要なこと」を拾う工程が、体制の中にあるか
同じ穴が自分の案件にもないか、16項目で点検できます（登録不要・約3分）。
案件の健康診断を受ける →NEXT STEP
こうした事故は、担当者の能力ではなく「孤立」から起きます。
株式会社Enlyt（エンライト） は、10年かけて言語化した“観点”を、現役の実践者が御社の会議に入って移植します。 AIは、その観点を毎週回し続けるエンジン。6ヶ月で、御社だけで回る状態にして抜けます。
無料の健康診断を申し込む →診断を受けても、契約の義務は一切ありません。本サイトのケーススタディは、プロジェクトの現場で起こりがちな状況を再構成したものです。特定の企業・団体・案件を指すものではありません。