eapINTERNAL TRAINING PROPOSAL DESIGN
社内教育コンテンツ|提案・見積もりの教科書

提案・見積もりの 「視座」を再現する

工数の足し算から、価値の設計へ。

「なんとなくうまく提案できる人」の頭の中を、誰でも辿れる形にする。読み終えたら、次の提案で「この視点で見直してみよう」と思える——それがこのページのゴールです。

見えない摩擦に、名前と値段をつける。
HOW TO READ

この資料は、二つの声で読む

見積もりや提案を作るとき、ベテランは無意識のうちに「ある視座」を通して物事を見ています。その視座があるかないかで、同じ案件でも提案の質はまったく変わります。この資料は、その視座を言語化して再現可能にするためのものです。

各ステップの頭には、同じ場面を見ている二つの声が登場します。

■ エンジニアの「僕」 現場で摩擦を「痛み」として感じている声。目の前のコードや作業に向き合う視点。
■ CTOの「私」 その摩擦がなぜ起きるのか、形そのものを設計しにいく声。一段引いて構造を見る視点。

どちらが上ということではありません。この二つを行き来できることが、良い提案の土台になります。対比を追いながら読むと、視点の切り替わりが自然と身につきます。

OVERVIEW

良い提案は、4つのステップで
組み立てられている

01 翻訳する

クライアントの言葉を「形・エネルギー・摩擦・コスト」に置き換える

02 可視化する

見えていない負債やリスクを、相手にも見える形にする

03 値付けする

工数ではなく「解消される摩擦の価値」で見積もる

04 自走を設計する

納品後に相手が自分で回せる形を、提案に織り込む

提案を組み立てる4ステップ。上流の「翻訳」の精度が、下流の値付けまで全部を決める。
01
翻訳する
STEP 01 — TRANSLATE

クライアントの言葉を、
そのまま受け取らない

■ エンジニアの僕は 「サイトが重い」と言われたら、まず原因のコードを探しにいく。どのクエリが遅いのか、どこがボトルネックか——手が自然に動く。
■ でもCTOの私は その「重い」がクライアントにとって何を意味するのかを先に考える。離脱なのか、コストなのか、信頼の話なのか。症状の裏にある「形」を名指しするところから始める。

クライアントは自分の課題を「症状」で語ります。「サイトが重くて困っている」「新機能の開発が遅い」「バグが多い」——。これをそのまま受け取って「じゃあ速くします」「開発体制を増やします」と返すと、提案は御用聞きになります。値段も相手の言い値か、単純な工数見積もりになってしまう。

ここで一段深く翻訳します。すべての事象を、次の4つに置き換えて見ます。

KATACHI
構造・仕組み。アーキテクチャ、役割分担、フロー。
エネルギーENERGY
そこを流れるもの。開発力、処理、判断、コミュニケーション。
摩擦MASATSU
形とエネルギーの不整合。遅い、詰まる、噛み合わない。
コストCOST
摩擦を放置した時の総支払い。負債、利子、疲弊。
翻訳に使う4つのキーワード。あらゆる症状は、この4つの言葉に置き換えられる。

翻訳の例 —「サイトが重い」を分解する

症状(クライアントの言葉) 「サイトが重い」
↓ 翻訳する
形の問題 N+1クエリを生む設計になっている/キャッシュ層が存在しない
エネルギーの無駄 本来1回で済む処理に、何十回もアクセスしている
摩擦 ユーザーの離脱、サーバーコストの増大
放置コスト 機能追加のたびに遅くなる。いずれ全面改修が必要になる
症状を4層に降ろす。最下層の「放置コスト」まで見せられると、提案の言葉が変わる。

この翻訳ができると、提案は「速くします」から「遅さの原因である形を作り変えます。これを今やらないと、機能を足すほど遅くなり続けます」に変わります。相手が気づいていなかった「放置コスト」まで見せられるのがポイントです。

摩擦は「頑張り不足」ではなく「形の欠陥」

摩擦が起きているとき、それはエネルギー(頑張り)の不足ではなく、形(構造)の欠陥であることが多い。
✕ 頑張り(エネルギー)を足す ここで詰まる(摩擦) 形が同じなら、いくら足しても摩擦は残りつづける ○ 形(構造)を作り変える 同じエネルギーが、摩擦なく流れる 「増員」ではなく「フローの再設計」が提案になる
「開発が遅い=能力不足→増員」ではなく、「仕様が固まる前に着手する形になっている→フロー再設計」。後者のほうが根本を解決するぶん、価値が高い。

症状の裏にある「形」を名指しできるかどうかが、翻訳力の核心です。

02
可視化する
STEP 02 — VISUALIZE

相手に見えていないものを、
見える形にして置く

■ エンジニアの僕は 負債の在り処が見えている。「ここ、いつか痛い目に遭うぞ」と肌で分かる。でもその危機感を、そのまま口にしても相手には伝わらない。
■ でもCTOの私は その見えない負債を相手の言葉に翻訳して、目の前に置いてみせる。技術の話ではなく、時間とお金の話として。見えないものを見えるようにするのが、ここでの仕事。

翻訳して見えた「形の欠陥」や「放置コスト」は、多くの場合クライアント自身には見えていません。だからこそ価値があります。

技術的負債やリスクは、放っておくと利子がついて膨らむ「借金」のようなものです。でも財務上の借金と違って、貸借対照表には載りません。見えないから、経営判断上は「無い」ことにされがちです。提案の役割は、この見えない借金を相手の言葉で可視化することです。

コツ① 時間軸で語る

コスト 半年後 1年後 今は小さく見える 放置した場合(利子つき) いま形を直した場合 この差が 提案が防ぐ損失
負債やリスクは「今」だけを見ると小さく見える。時間軸を伸ばしたときの差分が、そのまま提案の価値になる。

「このコードには技術的負債があります」

→ 技術用語のまま。相手には他人事

「今のままだと、機能追加のたびに工数が1.5倍かかり続けます。半年後には新機能ひとつに今の3倍の時間がかかる計算です」

→ 時間とお金の話になった瞬間、自分事になる

技術用語ではなく、時間・お金・事業インパクトに翻訳して見せる。これができると、相手は「今手を打つ理由」を自分で理解できます。

コツ② 選択肢とトレードオフで示す

リスクを「危険です」と伝えるだけだと、脅しになってしまいます。そうではなく、選択肢の形で見せます。

A
今すぐ全面改修
コスト リスク
B
段階的に直しながら運用
コスト リスク
C
今は手を入れず様子見
コスト リスク
ただし、利子は増えつづける
意思決定の主導権は相手に残す。こちらは「各選択肢の本当のコスト」を示す専門家として立つ。信頼が生まれるのはこの構図。
03
値付けする
STEP 03 — PRICE

かかる時間ではなく、
防ぐ損失で値段を語る

■ エンジニアの僕は つい「この作業は何日かかるか」で値段を考えてしまう。手を動かす時間が、そのままコストに見えるから。
■ でもCTOの私は 「この提案が防ぐ損失はいくらか」で値段を考える。かかる時間ではなく、生み出す価値・避けられる損失の側から値付けする。同じ3日でも、守っているものの大きさはまったく違う。

見積もりを「作業時間 × 単価」だけで作ると、提供している価値の大きさが値段に反映されません。同じ「3日の作業」でも、それが解消する摩擦の大きさはまったく違います。

工数はどちらも「3日」で同じ 工数 3日 解消する摩擦 ケースA 見た目を少し整える 工数 3日 防ぐ損失 ケースB 将来の全面改修を防ぐ 数百万円規模 工数ベースだと、この2つが同じ値段になる。
作業3日は同じでも、ケースBが守っているのは数ヶ月分のリスク。値付けの基準は「解消される摩擦の大きさ」に置く。

値段の根拠は「払わずに済む総コスト」

価値ベースの提案では、値段の根拠を「この提案によってクライアントが払わずに済む総コスト」に置きます。ステップ2で可視化した「放置コスト」が、そのまま値付けの根拠になります。

「この改修は、放置した場合に半年後に発生する全面改修コストと、その間の機会損失を防ぎます」「作業自体は数日ですが、防いでいるのは数ヶ月分のリスクです」——工数はあくまで「かかるコスト」の説明であって、「値段の根拠」ではありません。

工数見積もりは、信頼のために併記する

とはいえ工数を隠すわけではありません。「価値の説明」と「工数の説明」は役割が違う、と理解しておくのが大事です。

価値の説明
この提案が防ぐ損失・生み出す価値はいくらか。
→ なぜこの値段なのか(提案の背骨)
工数の説明
この会社はちゃんと計算している、という担保。
→ その値段で成立するのか(信頼の裏付け)
04
自走を設計する
STEP 04 — SELF-RUNNING

作業を渡すのではなく、
能力を渡す

■ エンジニアの僕は 目の前の課題をきれいに解決することに集中する。良いコードを書いて、動くものを納める。それで仕事は完了、と思いがち。
■ でもCTOの私は 納めた後に相手が自分で回せるかまで見る。僕がいなくなった後も、この仕組みは摩擦なく動き続けるか。作業を渡すのではなく、能力を渡す。そこまでが提案の範囲だと考える。

短期的には、クライアントを自社に依存させたほうが継続案件になって儲かるように見えます。でも長期的には、「この会社に頼むと、自分たちで回せるようになる」という評判こそが最大の営業資産になります。

✕ 作業を渡す 自社 成果物だけ クライアント また困ると、また外に頼むしかない ○ 能力を渡す 自社 成果物+判断基準 +手順+仕組み クライアント 自分で回る 担当者が変わっても、仕組みが回りつづける
「作業の納品」は一方通行で終わり、依存だけが残る。「能力の移植」は、渡した先で回りつづける。

自走する形を、提案にどう入れるか

判断の基準を残す
なぜこの技術・この設計を選んだのか。意思決定の記録を残す。
再現できる手順を残す
同じことを相手が繰り返せるドキュメントやテンプレートを渡す。
回る仕組みを渡す
属人化せず、担当者が変わっても機能するプロセスにして渡す。

「自走できる形まで含めて提供します」というのは、それ自体が提案の差別化になります。そしてこの「自走する形の設計」こそ、工数には表れにくい、価値ベースの値付けが最も効く領域です。

CAUTION — 一番大事な注意

本質を見抜いてからが、
本当の勝負

■ エンジニアの僕は 本質が見えた瞬間に「わかった!」となって、そこで一息ついてしまう。原因が特定できた達成感で、つい満足しがち。
■ でもCTOの私は 本質が見えたところをスタート地点だと思っている。「で、それをどう直すか」を具体に描ききって、相手が動き出せる形にするまでが本番。見抜くのは、まだ入り口。
本質を見抜くのはスタート地点であって、ゴールではない。

翻訳して「形の欠陥」を名指しできると、頭が良くなった気になります。でもクライアントが本当に欲しいのは「あなたの課題の本質はこれです」という診断ではなく、「で、それをどう直すのか」という具体的な手当てです。

本質を語って満足してしまうと、抽象度だけが上がって「言ってることは分かるけど、で、どうするの?」で止まります。これが一番やってはいけないパターンです。

本質を見抜く (入場券・まだ入り口) ① 作り変える形を、絵にする ② 最初の一手を、小さく示す ③ 本質とやることを、1対1で結ぶ 動ける提案 (勝負はここで決まる) 「降りる力」が差になる
見抜いた本質は、3段の落とし込みで「動ける具体」まで降ろす。動き出せる提案が、動けない正論に勝つ。

抽象で終わらせないための、3つの落とし込み

「作り変える形」を具体的に描く
「N+1を生む設計が問題です」で止めない。「こういうキャッシュ層をこう入れて、この処理をこう束ねます」まで、変えた後の形を絵にする。相手が「その形なら確かに摩擦が減りそう」とイメージできるレベルまで具体化して、初めて価値が生まれる。
「最初の一手」を明示する
全部を一気に直す提案は、大きすぎて相手が動けない。「まずここから手を付けます」という最小の一歩を示す。本質が大きくても、着手点は小さく具体的に。動き出せる提案が、動けない正論に勝つ。
「見抜いた本質」と「やること」を1対1で結ぶ
翻訳で見えた課題と、提案する作業が、線でつながっているか確認する。「本質はA、でも提案はBとCとD」と散らかっていると、本質が飾りになる。欠陥と手当てが過不足なく対応して、初めて「本質を見抜いた提案」が完成する。

本質を見抜く力は、慣れればある程度誰でも身につきます。でも見抜いた後に「じゃあ具体的にどう形を作り変えるか」は、経験と技術力が問われる領域です。ここでこそ、20年の蓄積や引き出しの多さが効いてきます。

視座(見抜く力)は入場券であって、勝負は「見抜いた後の具体化」で決まる。この降りる力こそが、提案の本当の差別化になります。

SUMMARY

次の提案で、
この4つの問いを通す

提案を作るとき、この4つの問いを順番に自分に投げかけてみてください。チェックを付けながら、いま手元にある提案を見直すのに使えます。

御用聞きの見積もり
症状に反応して、工数を足す。
価値ある提案
形を翻訳して、見えないコストを可視化し、価値で値付けし、自走まで設計する。

最初はチェックリストのように意識的に辿ってみて、慣れてきたら自然に頭の中で回るようになる——それがこの視座を「再現する」ということです。そして忘れてはいけないのが、本質を見抜いた後こそが本番だということ。診断で止まらず、必ず「で、どう直すか」まで提案しきる。そこまでやって、ようやく提案が武器になります。

FINALLY

この作業は、
AIには代われない

■ 二つの声の正体 ここまで登場してきたエンジニアの僕も、CTOの私も、どちらも人間の声です。そしてこの二人がやってきたことこそ、AIには代われない領域なのです。

AIの活用が当たり前になった今だからこそ、はっきりさせておきたいことがあります。この4つの視座のうち、AIが助けてくれる部分と、人間にしかできない部分は、明確に分かれています。

AIに任せていい部分
翻訳と可視化の「下ごしらえ」
  • 症状を聞いて「形の欠陥」として構造化する
  • 負債を時間軸で整理し、計算する
  • もらった情報を綺麗に翻訳・整理する
人間が握る部分
提案の勝負どころ、すべて
  • 本質を見抜く一歩目 — 「重い」の裏が、納期ではなく信頼の問題だと掴む。言葉の奥を読むのは、現場を知る人間の直感の領域。
  • 具体に降ろす — 「この形に作り変える」と描ききるには、経験の引き出しがいる。AIは選択肢を並べられても、「これでいく」と選びきれない。
  • 腹をくくる — 外したときに誰かが困り、お金が動く。その責任を引き受けて意思決定できるのは、人間だけ。
  • 現場の温度で一手を決める — 誰の手が空いているか、予算のリアルな上限はどこか。文脈を全部背負って「まずここから」と決める。
この線引きの左側をAIに助けてもらい、浮いた余力を右側——見抜く・降ろす・腹をくくる——に全部注ぐ。
AIが実装や整理を加速させる時代だからこそ、人間にしかできない部分の価値は、むしろ上がっている。

だからこの資料は、裏を返せば「どこをAIに任せ、どこを人間が握るか」の線引きでもあります。そこにこそ、提案の本当の差が生まれます。