作れるものと、効くものは違う：バリューの見積もり方【第9回】

この記事を読み終えると、機能の価値を3つの源泉（コスト・リスク・新しい能力）で分解でき、「作れるから作る」を避ける判断ができ、実装前に軽い検証で確かめる手順を持てるようになります。ジュニアエンジニア向け 成果の出し方シリーズ（全12回）の第9回です。

🎯 テーマの主役：「バリュー（価値）」

今回の主役はバリューです。一言で言えば、バリューとは「誰かの状態が良くなる量」です。作ったものの量ではありません。良くなった量です。

日常の例えで言うなら、薬です。薬は「作れるから」良いのではありません。「効くから」良いのです。そして効き目の大きさと、副作用の大きさを比べて選びます。どれだけ高度な設計で作られていても、効かなければ意味がありません。そして副作用が強ければ、使われません。ソフトウェアの機能も同じ構造です。効き目（誰がどれだけ良くなるか）と、副作用（維持コスト・複雑さ・学習コスト）の両方を見ます。

さらに薬にはもう1つの性質があります。効く相手が限定されることです。同じ薬でも、効く人と効かない人がいます。だから「誰に効くのか」を言えない薬は、評価できません。機能も同じで、「誰の、何が、どれだけ良くなるか」を言えない機能は、価値を判断できません。

この記事の仮説はこうです。機能の価値は、作る前にある程度見積もれる。見積もりの精度は、実装のうまさより、問いの立て方に依存する。したがって価値を出す技術とは、作る技術ではなく、問いを立てて確かめる技術である。もしこれが正しければ、あなたが身につけるべきは実装力の向上だけでなく、価値の見積もりになります。

なお第8回で扱った提案は「通し方」でした。今回の第9回は「何を通すか」です。そして第1回で扱ったアウトカムの考え方が、この記事の土台になります。

動機：「作ったのに、誰も使っていない」

ジュニアエンジニアが、キャリアの早い段階で必ず経験する挫折があります。時間をかけて作った機能が、使われない。

そして厄介なのは、作った本人が最も気づきにくいことです。実装の難しさに集中しているので、使われるかどうかを考える余裕がない。そしてリリース後、静かに使われなくなります。廃止の判断もされないまま、コードだけが残ります。そして半年後の改修で、その機能が邪魔をします。「これ、誰も使っていないのに、なぜ直さないといけないのか」。

この連鎖を止める方法は1つです。作る前に、価値を言葉にすることです。「誰が、何に困っていて、どう良くなるのか」。これを1文で言えない機能は、作っても価値になりません。そして言えるなら、作る前に確かめることができます。

この記事のゴールは、価値の見積もりと、軽い検証ができるようになることです。

🔍 検証①：価値の源泉は3つしかない

まず、価値を分解します。「良くなる」と言っても、種類は3つしかありません。

①コストが減る：同じことを、少ない時間・少ない人手・少ない費用でできる。手作業の自動化、処理時間の短縮、待ち時間の削減。最も分かりやすく、最も測りやすい価値です。

②リスクが減る：起きるかもしれない悪いことが、起きにくくなる／起きても小さく済む。障害の予防、データ消失の防止、法規制違反の回避、セキュリティの強化。測りにくいですが、金額で語れます（発生確率 × 影響額）。

③新しい能力が増える：いままでできなかったことができる。新しい売上、新しい顧客、新しい提供方法。最も大きな価値を生みますが、最も不確実です。

重要なのは、1つの機能が複数の源泉を持つことです。たとえば自動テストの整備は、コスト削減（手動確認の削減）であり、リスク削減（障害の予防）でもあります。だから「主たる源泉はどれか」を1つ決めます。主たる源泉が決まると、測り方が決まり、価値の主張が明確になります。

🔍 検証②：価値の大きさは4つの数の引き算で見積もる

次に、大きさの見積もりです。精密な計算は不要ですが、構造を持つことが重要です。

価値 ＝（影響を受ける人数 × 1人あたりの変化量 × 発生頻度）−（実装コスト ＋ 維持コスト）

4つの数を、それぞれ桁で見積もります。精密に出す必要はありません。「20人か200人か2000人か」が分かれば十分です。そして最も見落とされるのは「維持コスト」です。作った後にかかり続けるコスト——バグ対応、仕様変更への追随、ドキュメント、テスト、学習コスト、将来の変更を難しくする複雑さ。

「頻度」が最も効きます。同じ「30分の短縮」でも、毎日なら年120時間、年1回なら30分です。頻度を確認せずに作ると、大きな手戻りになります。「これは月に何回起きますか」と必ず聞く習慣を持ってください。この1問が、無駄な開発の多くを防ぎます。

そして維持コストの見積もり方には、シンプルな目安があります。「この機能は、今後3年間で何回変更されるか」を考えます。変更が多い機能は、維持コストが高い。変更が少なく、使う人が多い機能が、最も効率が良い。逆に変更が多く、使う人が少ない機能が、最も悪い投資です。

🔍 検証③：「作れるから作る」が起きる4つの型

次に、価値の見積もりが省略される典型パターンを扱います。どれも善意から発生します。

①技術的に面白いから：新しい技術を使いたい、綺麗に書き直したい。学習意欲は素晴らしいのですが、利用者の課題と無関係なことがあります。技術の選定理由として「面白い」は、利用者への説明には使えません。

②他社がやっているから：競合が同じ機能を出したから作る。競合の状況は参考情報ですが、あなたの利用者の課題ではありません。競合の利用者と、あなたの利用者は違う可能性があります。

③声の大きい人の要望だから：特定の1人が強く要望している。その人の課題は本物ですが、その人だけの課題かもしれません。「他に誰が困っていますか」と確認します。

④自分の痛みだから：自分が困っているから作る。開発者自身の痛みは、しばしば本物です（開発効率の改善など）。しかしそれが利用者の価値と混ざると、判断を誤ります。「これは誰のためか」を自覚しておきます。

これらの型を完全に避ける必要はありません。自覚して、価値の検証を追加するだけです。技術志向の開発は、開発効率という価値を持つことがあります。競合追随も、表の機能としては必要なことがあります。大事なのは、理由を偽らないことです。

🔍 検証④：価値が小さい機能の5パターン

次に、「作らないほうがよい機能」の見分け方です。5つのパターンがあります。

①誰も困っていない：課題が想像上のもの。問い合わせログや利用状況を見ると、困っている形跡がない。
②既に回避策がある：手作業でも、別のツールでも、すでに解決されている。回避策を置き換える価値が、実装コストを上回るかを問います。
③頻度が低すぎる：年1回しか起きない。自動化しても元が取れません。
④代替手段が多い：既存の機能で代用できる。新しく作るより、使い方を案内するほうが安い。
⑤変化が激しい：仕様が固まっていない。作った直後に不要になります。

「手作業のままでよい」という結論は、正しい結論です。そして驚くほど多くの場面で正解です。自動化にはコストがかかり、維持も必要です。月1回・10分の手作業は、年2時間です。自動化に20時間かけて、維持に年5時間かかるなら、合理的ではありません。「自動化しない」という判断を、堂々としてよい。これは手を抜くことではなく、資源を正しく配分することです。

🔍 検証⑤：作る前に、3つの軽い検証をする

次に、実装前に価値を確かめる方法です。本格的に作る前に、安く確かめられます。3つの方法があります。

①手作業で提供する（コンシェルジュ方式）：あなたが手でやってあげる。たとえば自動化したい集計作業があれば、まず自分が手で集計して提供します。使われるか、役に立つかが1日で分かります。そして手作業の限界（時間・ミス）が、自動化の要件になります。

②動画や画面で見せる（デモ方式）：動くものを全部作らず、動いているように見せる。既知の事例では、実際に動く製品を作る代わりにデモ動画を公開して需要を確かめた取り組みがあります。実装の前に、反応が分かります。

③限られた範囲で提供する（限定方式）：1チーム・1機能だけに提供して、使われ方を観察する。第5回の段階的リリースが、価値の検証としても機能します。使われ方を見れば、想定が当たっていたか分かります。

「手作業で提供する」が最も見落とされますが、最も強力です。理由は2つあります。第一に、「使われるか」を最短で確かめられる。第二に、手作業を経験した人が、最も良い設計を知っている。手作業の苦労を知らないまま作った自動化は、たいてい現場に合いません。「まず手でやってみる」は、遠回りではなく最短ルートです。

🔍 検証⑥：「削る」ことも価値である

最後に、価値を高める最も強力な手段を扱います。それは機能を削ることです。

同じ目的を、より少ない機能で達成できないかを必ず考えます。機能が少ないほど、早く出せて、維持コストが低く、学習コストも低い。3つの機能を1つにまとめられれば、価値は同じでコストは3分の1です。

そのための実践的な技術がスコープハンマーと呼ばれます。期限を守るために、機能を削る作業です。削る基準を持っておくと、判断が速くなります。

①なくても目的を達成できるか（代替手段があるなら削る）
②使う人が気づくか（気づかないなら削る）
③後から足せるか（足せるなら削る。第5回の可逆性）
④いまの利用者の何割が使うか（1割なら削る）

そして品質の見方を知っておくと、削る判断が正確になります。「当たり前品質」（欠けていると不満になるが、あっても褒められない）、「一元的品質」（高いほど満足、低いほど不満）、「魅力的品質」（あると嬉しいが、なくても不満ではない）。この分類は狩野モデルとして知られています。

削ってよいのは、たいてい「魅力的品質」です。「あると嬉しい」機能を削る。逆に「当たり前品質」を削ると、利用者は離れます。削る順番を間違えると、価値が大きく損なわれます。「なくても不満にならないもの」から削る——この基準を持っておくと、期限が迫ったときに迷いません。

結果：価値の見積もりシート

提案や着手の前に、このシートを埋めます。15分で書ける粒度がちょうどよいです。

【機能名】〈一行で、誰の何がどうなるか〉
　例：経理担当の月次集計を、8時間から30分にする

■ 誰が（人数）
　経理担当 20名（うち実際に集計するのは4名）

■ 何がどれだけ良くなるか（変化量）
　1回あたり 8時間 → 30分（7.5時間削減）
　頻度：月1回

■ 価値の源泉（主たるもの1つ）
　☑ コストが減る　□ リスクが減る　□ 新しい能力が増える

■ 年間の効果（概算）
　7.5時間 × 12回 × 4名 ＝ 年360時間

■ コスト
　実装：約40時間（調査・テスト・レビュー含む）
　維持：年10時間（仕様変更への追随・問い合わせ対応）

■ 見積もりの根拠
　1回8時間：先月の作業記録より（実測）
　頻度：過去6か月の実施記録（6回）

■ 事前に確かめる方法（実装前にやること）
　① 手作業で1回、代行して提供する（1回分の工数だけで需要を確認）
　② 4名のうち1名に試してもらい、使い方を観察する

■ 作らない場合の代替
　・手順書を整備して、作業時間を8時間→6時間に短縮（工数10時間）

■ 削れる要素（スコープハンマー）
　・見た目のカスタマイズ → 後回し（使う人が気づかない）
　・複数フォーマットの出力 → 最初は1種類だけ
　・承認フロー → 当面は手作業で代替

このシートの価値は、埋める過程で「分からない」が見つかることです。「頻度は？」「誰が使う？」に答えられないなら、まだ提案できません。そして「分からない」ことは、調査で埋められます。第8回の「調べるだけの提案」が、ここで活きます。このシートを先に書いておくと、調査の的が絞られます。

考察：価値の判断は「作らない勇気」を要求する

ここまでを踏まえて、1つ踏み込んだ話をします。価値の見積もりで最も難しいのは、計算ではありません。「作らない」と決める勇気です。

エンジニアは作ることが好きです。そして作ることを期待されています。だから「作らない」という結論は、自分の仕事を減らすように見えます。しかし第1回で扱ったとおり、成果は「作った量」ではありません。作らないことで防いだ損失は、立派な成果です。「この機能は作らないほうがよい、理由はこれ」と言える人は、最も価値の高い仕事をしています。

そして、作らない判断は、記録に残すと価値が増します。「なぜ作らなかったか」を書いておくと、半年後に同じ提案が出たときに、同じ議論を繰り返さずに済みます。第8回で扱った決定の記録と同じ技術です。「2026年9月時点では、頻度が年1回のため見送り。年4回を超えたら再検討」。この一文は、未来の誰かの時間を節約します。

もう1つの考察は、価値は時間とともに変化することです。いま価値が小さい機能が、半年後に価値を持つことがあります。利用者が増えれば頻度が上がります。法規制が変われば必須になります。だから「作らない」は「永久に作らない」ではありません。「いまは作らない」です。そして再検討の条件（トリガー）を書いておけば、見落としません。「利用者が100人を超えたら」「月4回を超えたら」。条件を書くことが、見送りの正しい形です。

📌 注目ポイント

核心は4点です。第一に、価値の源泉は3つ（コスト削減・リスク削減・新しい能力）で、主たる源泉を1つ決めること。第二に、価値は「人数 × 変化量 × 頻度 − コスト」で桁を見積もること。第三に、「作れるから作る」の4つの型を自覚すること。第四に、作る前に手作業で提供して確かめること。

特に第三点と第四点の組み合わせが効きます。「技術的に面白い」と感じたときは、いったん手作業で提供してみる。それで使われなければ、あなたの面白さは利用者の課題ではありません。この一手間が、無駄な開発を防ぎます。

💡 活用事例：在庫を持たずに需要を確かめる

価値の検証には、「作る前に確かめる」という強力な先例があります。靴のオンライン販売で知られる企業は、初期に在庫を一切持たずに始めました。注文が入ったら、近くの店舗で靴を買って発送する。つまり裏側は手作業でした。この方法（コンシェルジュ方式／ウィザード・オブ・オズ方式と呼ばれます）で、「オンラインで靴を買う人がいるか」という最大の不確実性を、在庫のリスクを負わずに確かめました。

機能を減らして成功した例も同様に示唆的です。写真共有のサービスは、当初から多機能ではなく、フィルタと投稿という最小の機能に絞って伸びました。機能数を競わず、1つの体験を磨いたわけです。

3つの事例に共通するのは、「価値は作る前に確かめられる」という姿勢です。そして確かめた後で、必要になった部分だけを作る。この順序が、資源の無駄を最小化します。手作業は恥ずかしいことではありません。手作業は、最も安い検証手段です。そして手作業を経験した人だけが、本当に必要な自動化を作れます。第1回で扱った「成果」の定義に照らせば、手作業での検証は、最短でアウトカムに到達する方法です。

✅ 要点まとめ

• 価値＝誰かの状態が良くなる量。作った量ではない
• 価値の源泉は3つ：コスト削減・リスク削減・新しい能力。主たる源泉を1つ決める
• 価値は人数 × 変化量 × 頻度 −（実装コスト＋維持コスト）で桁を見積もる
• 頻度の確認が最も効く。「月に何回起きますか」を必ず聞く
• 維持コストを必ず入れる。作った後に毎年かかる
• 「作れるから作る」の4つの型（技術志向・競合追随・声の大きい人・自分の痛み）を自覚する
• 価値の小さい5パターン：誰も困っていない・回避策がある・頻度が低い・代替がある・変化が激しい
• 手作業で提供して確かめるのが最も安い検証
• 削ることも価値。削る順番は「魅力的品質」から。当たり前品質は削らない
• 「作らない」は成果。再検討の条件（トリガー）を書いて残す

🚀 取り込み方：明日から使う3段階

今日（5分でできること）：いま自分が担当している機能を1つ選び、「誰が・何が・どれだけ良くなるか」を1文で書いてください。書けない場合、その機能の価値はまだ言語化されていません。3つの源泉（コスト・リスク・能力）のどれかを選び、数字を1つ入れます。「月8時間が30分になる」。これが言えると、その機能の優先順位を自分で説明できるようになります。

今週（小さく試す）：新しい作業を始める前に、「頻度」を確認してください。「これは月に何回起きますか」。そして手作業で1回、やってみます。手作業で提供できるなら、実装はまだ必要ありません。この経験を1回すると、「まず手でやってみる」が習慣になります。そして手作業の記録が、そのまま実装の要件定義になります。

今月（業務に組み込む）：価値の見積もりシートをチームに提案します。あわせて「見送りリスト」を作ります。検討したが作らなかったものと、その理由と再検討の条件を記録します。これがあると、半年後に同じ議論を繰り返しません。第8回の提案、第5回の可逆性、第1回のアウトカム——これまでの技術が、1つのシートに統合されます。そしてあなたの提案は、通るだけでなく、効く提案になります。

🔥 ハマりポイント：価値の見積もりで外す3つの型

その1：「全員が使う」と思いがちだが、実は使う人は一桁少ない

症状は、全社員1,000人分の価値を見込んで提案し、実際には20人しか使わなかった。原因は利用者数を最大値で見積もっていることです。対処は、「実際に手を動かす人」だけを数えることです。権限がある人・閲覧する人・実際に操作する人は違います。最も少ないほうで見積もると、安全側の判断になります。そして「まず何人に使ってもらうか」を限定して出す（検証⑤）ことで、見積もりの精度が上がります。

その2：「便利になるから使われる」と思いがちだが、実は習慣は変わらない

症状は、明らかに便利な機能を作っても、既存の手順が使われ続ける。原因は人の習慣の強さを過小評価していることです。人は、いま使っている方法を変えません。特に「動いている」方法は変わりません。対処は、「切り替えのコスト」を価値から引くことです。学習時間・移行作業・心理的な抵抗。そして「今の方法より明確に楽」でなければ、使われません。「便利」ではなく「楽」を目指してください。10秒の差では人は動きません。10分の差なら動きます。

その3：「作った機能は資産」と思いがちだが、実は維持コストを生む負債にもなる

症状は、使われていない機能が、後の改修を妨げる。原因は作った後のコストを見積もっていないことです。対処は、廃止の基準を同時に決めることです。「半年間で利用が月10回を下回ったら廃止を検討する」。作るときに廃止の条件を決めておくと、判断が感情抜きでできます。そして廃止は新しい機能と同じくらい価値のある仕事です。コードを消すと、変更が速くなります。第4回の「削除は最も難しい」を思い出してください。廃止の条件を先に決めることが、その難しさを下げます。

🔄 代替アプローチとの比較：価値の考え方の型

「何を作るか」の判断には複数の考え方があります。組み合わせて使うものです。

遅延コスト（コスト・オブ・ディレイ）という考え方も強力です。「いつかやる」ではなく「いつやると、いくら得か」で測ります。同じ機能でも、1か月早く出せば1か月分の効果が早く出ます。だから「いつ出すか」も価値の一部です。完璧にして遅く出すより、十分な品質で早く出すほうが、総価値が高くなることが多い。第5回の可逆性は、この「早く出す」を安全にする技術でした。価値・可逆性・段取りが、1つの設計判断に統合されます。

📅 今後の展望：価値の判断は「計測」と「AI」で変わる

「何を作るべきか」の判断は、この10年で計測可能な領域に変わりました。利用状況の分析、A/Bテスト、行動ログ。「作ってみないと分からない」が減り、「小さく出して測る」が標準になりました。さらにAIの支援で、過去のデータから優先順位の候補を出すことも可能になっています。

この流れで、人間の役割が変わります。データは「何が使われているか」を教えてくれますが、「何が使われるべきか」は教えてくれません。そして新しい能力の価値（まだ存在しない使い方）は、データに出ません。過去のデータは、未来の価値を測れないのです。だから仮説を立てて確かめる仕事の重要性は、むしろ上がります。

もう1つの流れは、「作らない」という選択肢の正当化です。機能の数を競う時代から、体験の質を競う時代へ。「うちはこれをやらない」と決められることが、戦略になります。あなたが「作らない理由」を数字で説明できる人材であれば、その価値はこれから上がっていきます。作る技術は自動化されていきますが、選ぶ技術は自動化されません。第9回で扱ったのは、自動化されない側の技術です。

まとめ

この記事では、バリューの見積もり方を扱いました。価値は誰かの状態が良くなる量であり、3つの源泉（コスト・リスク・新しい能力）に分解できます。人数 × 変化量 × 頻度 −（実装＋維持）コストで桁を見積もり、頻度と維持コストを必ず確認します。そして作る前に手作業で提供して確かめ、削ることも価値と捉えます。「作らない」も成果であり、再検討の条件を残すことで見落としを防ぎます。

これを読んだあなたは、機能の価値を数字で分解し、作る前に確かめ、作らない判断も説明できるようになりました。次の第10回では、見積もりと約束を扱います。予測と約束は別物である——それが次のテーマです。第9回が「何を作るか」なら、第10回は「いつできると言うか」です。

参考文献

1. Marty Cagan『INSPIRED』（第2版, 2017） — アウトカム志向と「機能工場」からの脱却。 https://www.svpg.com/
2. Theodore Levitt に帰される有名な指摘（「ドリルではなく穴が欲しい」） — 手段と目的の混同に関する古典的説明。
3. Clayton M. Christensen, Taddy Hall, Karen Dillon, David S. Duncan『Competing Against Luck』（2016） — 片付けたい仕事（JTBD）という考え方。
4. 狩野紀昭ほか（1984）「魅力的品質と当り前品質」 — 品質の分類（当たり前・一元・魅力的）の原典。 https://www.juse.or.jp/
5. Donald G. Reinertsen『The Principles of Product Development Flow』（2009） — 遅延コスト（Cost of Delay）と経済的な優先順位づけ。
6. Eric Ries『The Lean Startup』（2011） — 最小の検証と学習の設計。 http://theleanstartup.com/
7. Ash Maurya『Running Lean』（第3版, 2022） — 課題と解決策の検証手順。 https://leanstack.com/
8. Sean Ellis の Product-Market Fit テスト（40%ルール） — 価値が実在するかの簡易な指標。
9. Ryan Holiday／在庫を持たずに需要を確かめた事例（Zappos初期の運用に関する公開インタビュー・講演） — 手作業による検証の代表例。
10. Drew Houston ほか、動作イメージの公開による需要確認に関する公開資料（2007年） — 実装前の検証事例。 https://www.dropbox.com/
11. Ryan Singer『Shape Up』（Basecamp, 2019） — スコープハンマーと、削る前提の計画づくり。 https://basecamp.com/shapeup
12. Kerry Rodden, Hilary Hutchinson, Xin Fu（2010）「Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications」（CHI） — HEARTフレームワーク。 https://research.google/
13. Ron Kohavi, Diane Tang, Ya Xu『Trustworthy Online Controlled Experiments』（2020） — 実験による価値の測定。
14. Ward Cunningham（1992）「The WyCash Portfolio Management System」 — 技術的負債と、機能追加のコスト。
15. IPA『iコンピテンシ ディクショナリ』 — 価値創出に関する能力定義。 https://www.ipa.go.jp/
16. 経済産業省『DXレポート 2』 — 既存システムの複雑化と、選択と集中に関する政策的文脈。 https://www.meti.go.jp/