【2026年8月版】

実装しない技術（第3回）― 作らない判断を妨げる予算・契約・決裁の構造

公開日: 2026/08/11
読了時間: 約 22分

第1回で ECRS により業務を減らし、第2回で残った業務からシステム化の範囲を決めた。

ただし、担当者がこの二つを実行しても、開発を止められない場面がある。予算部門はシステム開発の費目で予算を確保済みであり、発注部門は納品物に対して対価を支払う契約を結んでいる。利用部門は役割と責任分界を変えずに済む案を選び、決裁者は開発を中止する判断を下す権限を持たされていない。

つまり、担当者が業務を減らす提案をしても、それを受け取る側の制度がその提案を評価できない。第3回では、この制度の側にある要因を七つに分けて示したうえで、これまでの内容を開発着手の条件として整理する。

1. 作らない判断を妨げる組織上の要因

作らない方が合理的でも、組織は開発へ進みやすい。要因は個人の判断より構造の側にあり、次の七つが順に働く。

#	要因	内容
1	予算承認が解決策を先に固定する	予算制度が問題探索ではなく具体的な投資案件の承認を求める。開発として承認された後は、調査で不要と分かっても変更や中止が難しい
2	成果物が目的化する	「新システムを導入する」は成果物であって、成果そのものではない。導入自体が目標になれば、導入しない結論は失敗と見なされる
3	契約が作ることに報酬を与える	機能数、工数、固定スコープの納品へ対価が支払われる契約では、作らない方がよいという発見を経済的成果として扱いにくい
4	既存業務には現状維持の力が働く	システムだけ替えれば役割、権限、責任分界を変えずに済む。業務の廃止や統合は部門間調整と責任変更を伴う
5	始める仕組みはあっても止める仕組みが弱い	提案、予算、承認という開始手続きに対し、再評価して終了する手続きが同じ強さで設計されているとは限らない
6	問題が技術的解決へフレーミングされる	規程の複雑さや権限の曖昧さが、データ統合基盤やワークフローエンジンの要件として受け取られる
7	一度作ったものは捨てるにもコストがかかる	廃止にはデータ移行、利用者への通知、依存システムの整理、アーカイブが伴う

この並びには因果がある。予算化された案件が成果物として定義され、契約がその納品に報酬を与え、組織は業務を変えずにシステムだけを替える。投資が始まれば止める判断は働きにくく、残った複雑さは技術で処理され、その結果が次のレガシーになる。本来の目標は、処理時間の削減、事故の減少、顧客負担の軽減の側にある。

1.1 予算承認が解決策を先に固定する

OECD の Digital Government Outlook 2026 は、各国のデジタル投資について、開始時点の仕組みが成熟していると評価している。needs identification から business case、資金確保までがそれにあたる。一方で、途中に予算や方向を変更する仕組み、成果が出なければ止める仕組みは弱いと指摘している。

資金制度が事前承認と年度予算を中心に設計されると、期待を下回った投資でも支出の停止や振り向け直しが難しくなる。承認を得るために解決策を先に具体化する必要があり、その時点で開発という手段が確定する。

1.2 成果物が目的化する

英国政府のプロジェクトデリバリー標準は、benefits management を、なぜ変更が必要か、目的は何か、成功とはどの状態かという問いから始める構造にしている。

システムの導入は成果物であって、処理時間の短縮や誤りの減少がその先の成果にあたる。この区別が失われると、導入したかどうかで達成が判定される。

1.3 契約が作ることに報酬を与える

これは外部ベンダーの問題というより発注構造の問題になる。英国政府の調達ガイダンスは、固定価格方式がスコープの固定された仕事を前提とするとし、スコープが変動する仕事へ適用しないよう求めている。

100人月、20画面、指定機能の実装という形で発注した後に、業務を変えれば10画面が不要と分かっても、それを成果として扱う経路がない。成果を中心に契約すれば、解決策を変更する余地を残せる。

1.4 既存業務には現状維持の力が働く

システムだけを替えるなら、組織内の役割、権限、規程、責任分界は変えずに済む。業務そのものを廃止したり統合したりすると、部門間の調整と責任の変更が伴う。情報システムの研究でも、新しいシステムの導入に対する利用者の抵抗が、現状維持バイアスの観点から扱われている。

既存業務の非効率は日常のコストとして埋没している一方、業務変更には学習、移行、調整の負担が新たに発生する。この非対称から、技術的には大きな変更を行いながら業務だけは従来どおり残す、という逆転が起こる。

1.5 始める仕組みはあっても止める仕組みが弱い

Management Science の研究は、価値の低い製品がなぜ終了しにくいのかを扱い、すでに投じた費用が追加投資を正当化してしまう構造を示している。中止の判断そのものにも評価と報酬が要る、という指摘は組織設計に直接効く。

1.1 で見た制度の側と合わせると、開始には提案、予算、承認という手続きがある一方、再評価して終了する手続きは同じ強さで設計されていない。

1.6 問題が技術的解決へフレーミングされる

ACM の論考は、社会的・制度的な問題まで技術で解決できるものとして扱う傾向を technological solutionism と呼び、その危うさを論じている。情報の意味が部署ごとに違うからデータ統合基盤を作る、規程が複雑だからAI検索を作る、権限関係が曖昧だから柔軟な権限管理を作る、という判断は、元の問題を残したまま処理する層を足すことになる。

これが生じる範囲は技術者より広い。経営者が導入を決め、ベンダーが製品で問題を説明し、発注部門がシステム案件として予算化し、開発者が実装問題として受け取る、という連鎖の結果になる。技術的に面白い問題と、事業上解くべき問題は一致するとは限らない。

1.7 一度作ったものは捨てるにもコストがかかる

作って不要なら消せばよいとは限らない。GOV.UK はサービスの廃止を独立した工程として扱い、構築時と同じように利用者のニーズを検討し、そのニーズが廃止後にどう満たされるかを考えるよう求めている。英国政府のレガシーITガイダンスも、古い資産の維持がセキュリティとコストの負担になると指摘している。

開発着手の判断には、初期開発費だけでなく将来の撤去コストも含まれる。

評価指標も同じ方向へ働く。実装した機能数、完了したチケット数、開発規模、導入した製品数、自動化した作業数だけで開発組織が評価されるなら、不要なものでも作り続けることになる。代わりに測れる数字は、廃止した業務数、削減した入力項目数と承認段階数、統合した帳票数、問い合わせ件数と処理時間と待ち時間の減少幅、開発せずに解決した課題数、将来発生しなかった運用費、廃止できた既存システム数である。

作らなかった機能は画面に残らないが、設計上の成果としては測定できる。機能を一つ削れば、その機能に付随する設計、実装、テスト、監視も消える。権限制御、問い合わせ対応、障害対応、データ移行、セキュリティ修正、将来改修も同じように消える。作らないことによる利益は初期開発費の削減にとどまらず、将来にわたって発生する責任を引き受けずに済むところにある。

2. 要件を固める前に、開発へ進む条件を定義する

従来の要件定義では、必要な機能が漏れなく定義され、関係者が合意したことが一つの区切りになる。IPA の DX SQUARE も、ビジネス要求を基にシステム化要求を導出し、ステークホルダーとの合意によって要件とする構造を示している。

ここで扱うのは、その手前に置くゲートである。判定するのは要件定義書が完成したかどうかではなく、システム開発へ進むだけの理由がそろったかどうかになる。満たすべき条件は、第1回からここまでで扱った内容の到達点にあたる。四つのまとまりに分けて振り返る。

2.1 問題を理解したか

解決すべき問題と目指す結果が定義されている
利用者と、問題によって影響を受ける主要な関係者が特定されている
現在の業務・情報・サービスの流れが把握されている

第1回の第1節で見たとおり、依頼は解決策の形で届く。それを問題へ戻し、誰の何を解くのかを決めるのがここになる。関係者には利用者だけでなく、受益者、統制責任者、意思決定者が入る。現状の把握は第2回で扱った実態の可視化にあたり、マニュアル上の手順ではなく実際に行われている処理を指す。

2.2 業務を減らしたか

各工程について、提供する価値または存続させる必要性が説明できる
不要な工程、重複、再入力、承認が特定され、廃止・統合・簡素化の方針が決まっている
既存業務をそのまま移すのではなく、あるべき業務が検討されている

第1回の ECRS がこの三つに対応する。排除、結合と分離、入替えと代替、簡素化を順に適用した結果が、5と6になる。4は3の裏返しで、価値を説明できない工程は排除の候補として残る。ここを飛ばすと、第1回の五類型で見たとおり、手段だけが置き換わって業務の構造が残る。

2.3 作らない案と比べたか

システム開発以外の解決手段が検討されている
開発しない選択肢を含め、次工程へ進む価値が評価されている

規程変更、組織変更、契約変更、既存サービスの利用を、システムを作る案と同じ土俵で比較したかを見る。8は、比較の結果として何も作らない結論を選べる状態になっているかを問う。GOV.UK は調査の結果として次の段階へ進まない判断も失敗にはあたらず、時間と費用を別の場所へ回せるとしている。

2.4 範囲・判定基準を決めたか

問題として扱う範囲と対象外が合意されている
そのうちシステムが担う範囲と、担わない範囲が明確になっている
現状の基準値、期待する改善、成功判定指標が定義されている
次工程へ進む条件と、進まない場合の判断基準が明確になっている

9と10は別のものになる。問題の対象外を決めても、残った問題のうちどこまでをソフトウェアで扱うかは未定のままである。GOV.UK は問題を捉え直す作業について、何を問題に含めないかの合意もその一部だとしている。10は第2回のシステムの担当範囲にあたる。

11は第2回で取った基準値が効いてくる箇所で、これがなければ改善したかどうかを後から判定できない。12は、あらかじめ機械的な中止条件を置くという意味ではない。継続と中止のどちらも選べるだけの情報と評価軸を、この時点で持っている状態を指す。

この形にすると、要件は機能を漏れなく集めた結果ではなくなる。問題を理解し、業務を再設計し、非システム手段と何も作らない案を比較したうえで、それでもシステムが必要と判断された部分だけが要件として残る。

3. 開発着手が引き受ける責任

システム開発では、技術的に難しいものを作れる人が評価されやすい。複雑な権限管理、柔軟なワークフロー、汎用的なルールエンジン、大量のデータを扱う基盤、高度なAIエージェント。ただし複雑なシステムが必要になった理由を遡ると、複雑な業務、曖昧な責任、統一されていない規程、残り続けた例外が見つかることがある。その複雑性を技術で受け止めることはできるが、受け止められることと受け止めるべきことは違う。

システムを作れば、組織はそのシステムを長期間保守し続ける。データを守り、障害へ対応し、利用者を教育し、制度変更へ追従し、古い技術を更新し、最後には移行と廃止を行う。開発着手はコードを書く判断であると同時に、将来にわたる維持責任を引き受ける判断になる。

シリーズ全体の検討は、着手前に確かめる五つの問いに集約できる。

その業務は本当に必要なのか
その確認は何のために行っているのか
その情報をなぜ保存しているのか
その承認は誰を守っているのか
そもそもシステムを作る必要があるのか

いずれも技術ではなく業務の側にある問いで、答えが出るまで実装の対象は決まらない。作らずに解決できるなら、それが最も小さく、速く、安全で、保守しやすい形になる。実装しない技術は、作る価値のあるものだけを残すための、最も上流の設計技術である。

コードを書けば、そこには必ず不具合のリスクが生じる。書かなければ、そのリスクは発生しない。背負わなくてよいリスクを背負う理由はない。