Zenn で 【失敗談】大規模開発をして残ったのは技術負債だけだった話 〜作らないことの重要性〜 が話題になりました。要点は、使われない機能を大量に作り込んだ結果、保守コストだけが残り、肝心の価値は生まれなかったという告白です。重要なのは、「作る力」より「作らない判断」のほうが、システムの寿命とコストを左右するという教訓です。
受託システム開発の現場では、「言われた機能を全部作ったら、半分は使われず保守だけが重くなった」「あれもこれもと盛り込んだ結果、納期も予算も超過した」という事故が後を絶ちません。受託でシステムを支える立場では、これは 「要件を満たすか」ではなく、「本当に必要なものを見極め、過剰を削ぎ、運用に組み込んだ状態で引き渡せるか」を設計に組み込む課題だと捉えています。これまで AI 時代のリファクタリング判断・技術的負債ガバナンスの受託（GH Media） で扱った 負債の判断、仕様・要件ハーネス設計の受託（GH Media） で扱った 要件の構造化、テスト自動化の定着支援の受託（GH Media） で扱った 定着の設計と接続して、本記事では 「要件・スコープ設計支援」を 受託パッケージとして整理します。
なぜ「いま」「作らない」設計なのか
| 観点 | 全部作る（過剰開発） | 必要だけ作る（2026） |
|---|---|---|
| 要件 | 言われたまま盛り込む | 価値から取捨選択 |
| スコープ | 際限なく膨張 | 段階的に絞る |
| 保守 | 使われない機能も維持 | 維持対象を最小化 |
| 納期・予算 | 超過しがち | 守りやすい |
| 負債 | 完成と同時に発生 | 発生を抑える |
| 成果 | 重いだけ | 使われ続ける |
つまり 「全部作ること」と「価値を生むこと」は別物であり、受託でも 「必要なものを見極め、過剰を削ぎ、運用に組み込んで引き渡す」ことが品質の前提になりました。これにより 「軽くて使われ続けるシステム」を成果物として保証できます。
受託案件で活きる 3 つの構造変化
構造 1: 「言われたまま」から「価値で取捨選択」へ
要望をすべて実装すると保守が膨張します。受託では 価値と利用頻度から優先度を付け、作らない機能を明確に合意します。
構造 2: 「一括で全部」から「段階リリース」へ
一度に作り切ると検証できません。受託では 最小構成で出して使われ方を観測し、実需に基づいて拡張する設計を提供します。
構造 3: 「完成主義」から「撤退設計」へ
作った機能は残り続けます。受託では 使われない機能を畳む撤退基準も設計し、負債の蓄積を防ぎます。
受託で提供する「要件・スコープ設計支援」5 フェーズ
フェーズ 1: 価値の整理（1 週間）
- 解決したい課題と成功指標の明確化
- 利用者・利用シーンの特定
- 要望の洗い出しと背景のヒアリング
- 既存システム・代替手段の確認
フェーズ 2: スコープ設計（1 週間）
- 価値・頻度による要件の優先度付け
- 作る / 作らない / 後回しの線引き
- 最小構成（MVP）の定義
- 撤退・見直しの基準設定
フェーズ 3: 段階計画（1 週間）
- リリース段階とマイルストーン設計
- 各段階の検証指標の定義
- リスクと前提の明示
- 見積・スケジュールの合意
フェーズ 4: 実装・検証（案件規模に応じて）
- 最小構成の実装
- 利用状況・指標の観測
- 実需に基づく拡張判断
フェーズ 5: 継続運用（継続）
- 利用されない機能の見直し
- スコープの定期棚卸し
- 負債の蓄積監視
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| 要件整理 | ユーザーストーリー / 課題分解 | 機能一覧 |
| 優先度 | 価値 × 頻度マトリクス | MoSCoW |
| 検証 | 利用計測 / フィードバック | ヒアリング |
| 段階提供 | フィーチャーフラグ | 段階リリース |
| 指標 | 利用率 / 成功指標 | アクセス解析 |
| 管理 | スコープ台帳 | 課題管理ツール |
どの案件に必要か / 不要か
| 必要な案件 | 優先度が低い案件 |
|---|---|
| 要望が膨らみ収拾がつかない | 仕様が確定した小規模 |
| 過去に作り過ぎて保守が重い | 使い捨ての一時システム |
| 納期・予算が逼迫している | 潤沢なリソースがある |
| 何が使われるか不確実 | 利用が確定している |
| 長期運用を前提とする | 短命で廃止前提 |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象範囲 | 作る / 作らないの線引き | スコープの合意 |
| 成功指標 | 価値の測り方 | 指標の承認 |
| 段階 | リリース計画 | マイルストーン |
| 見直し | 撤退・拡張基準 | 判断基準 |
| 引き渡し | 手順 / Runbook | 保守体制 |
| 継続運用 | スコープ棚卸し | 運用費用 |
価格モデル — 要件・スコープ設計パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| スコープ診断 | 25 万円〜 | 小規模 | 価値整理 + 優先度付け |
| 設計パッケージ | 80 万円〜 | 中規模 | スコープ設計 + 段階計画 |
| 上流伴走 | 30 万円〜 / 月 | 中〜大規模 | 要件・スコープの継続伴走 |
| Lite 保守 | 5 万円〜 / 月 | 小規模 | スコープ棚卸し |
| Standard 保守 | 15 万円〜 / 月 | 中規模 | + 利用計測 + 見直し提案 |
顧客側 ROI 試算（中堅企業の業務システム想定）
| 項目 | 既存（全部作る） | 必要だけ作る | 差分 |
|---|---|---|---|
| 初期開発費 | 過剰機能で膨張 | 必要分に圧縮 | 開発費の削減 |
| 保守費 | 全機能を維持 | 対象を最小化 | 保守費の削減 |
| 納期 | 超過しがち | 守りやすい | リスクの低減 |
| 価値実現 | 後ろ倒し | 早期に検証 | 価値の早期実現 |
| 年間効果 | — | — | 過剰開発の削減による初期・保守費の圧縮 |
設計パッケージ（80 万円〜）でも、使われない機能の作り込みと保守を一度避けられれば十分に正当化できます。
ハマりやすい 5 つの落とし穴
落とし穴 1: 要望をすべて実装する
保守が膨張します。価値で取捨選択します。
落とし穴 2: 一度に全部作る
検証できず外します。段階的に出して観測します。
落とし穴 3: 撤退基準を決めない
機能が永遠に残ります。畳む基準を先に決めます。
落とし穴 4: 利用状況を測らない
要否を判断できません。利用率を計測します。
落とし穴 5: 「作らない」を言語化しない
後で蒸し返されます。合意を記録します。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1 | 課題・成功指標・要望の整理 |
| Week 2 | 価値 × 頻度でスコープを設計 |
| Week 3 | 段階計画 + 撤退基準の合意 |
| Week 4〜10 | 最小構成の実装 + 利用観測 |
| Week 11〜13 | 実需に基づく拡張・見直しの運用開始 |
まとめ — 「全部作る」から「必要だけ作る」へ
本当に価値を生むのは、作る力ではなく「作らない判断」です。受託でシステムを支える立場では、必要なものを見極め、過剰を削ぎ、運用に組み込んで引き渡す 「要件・スコープ設計支援」が、軽くて使われ続けるシステムを届ける新しい主力サービスです。
弊社ではスコープ診断 / 設計パッケージ / 上流伴走 / Lite / Standard の各段階で本パッケージを提供しています。「要望が膨らんで収拾がつかない」「作り過ぎて保守が重い」「納期と予算を守りたい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
