新しい業務システムを計画どおり納品し、検収を終え、運用部門へ引き渡す。従来のプロジェクト管理では重要な節目です。 しかし、顧客の行動、競争環境、制度、利用データが変わり続ける中で、納品時点の要件を固定したままでは、ソフトウェアが事業の変化へ追随できなくなります。 完成したはずのシステムが、改修待ち、手作業、部門ごとの補助ツールを増やし、数年後には次の全面刷新を待つ状態になることもあります。

IPAが2026年3月に公表した「2025年度ソフトウェアモダナイゼーション委員会報告書」は、ソフトウェアが企業や社会の価値創出を左右する一方、 内製開発、DevOps、アジャイル開発などの採用が十分に広がっていない状況を示しています。同委員会は、ソフトウェアの価値を最大化し、 変化へ対応できる産業・社会へ転換することを重視しています。

ここでの要点は、すべてを自社開発へ切り替えることでも、特定の開発手法を導入することでもありません。経営・事業・IT・外部パートナーが、 価値仮説を共有し、小さな変更を安全に届け、利用結果から次の優先順位を決められることです。本記事では、ソフトウェアを一度きりの「納品物」から、 継続的に育てる「事業能力」へ変える5つのステップを整理します。

具体的な課題：引き渡した瞬間から、改善が遠くなる

プロジェクトの成功を予算、納期、要件の充足だけで判断すると、利用開始後に価値が生まれたかを追う責任が曖昧になります。 事業部門は要望を提出する側、IT部門は作る側、運用部門は守る側、外部パートナーは契約範囲を履行する側に分かれ、 実際の利用結果を見ながら一緒に改善する場がなくなりがちです。

  • 要件を早く固定しすぎる：着手時の仮説を正解として扱い、利用後に分かった課題を変更要求へ追い出す。
  • 意思決定が遠い：小さな改善にも複数部門の予算・稟議・契約変更が必要で、価値が出る前に待ち時間が増える。
  • 成果が引き継がれない：検収後は稼働率や障害件数だけを見て、利用率、完了率、手戻り、顧客行動を追わない。
  • 知識が分断される：業務判断、設計理由、コード、運用上の制約が別々に保管され、変更の影響を判断できない。
  • 次の刷新を繰り返す：継続改善の予算と体制がなく、技術的負債が膨らんでから大規模な置換を計画する。
開発を誰が行うかより先に、「価値を決め、変更を届け、結果から学ぶ意思決定を誰が持つか」を設計することが出発点です。

考え方：ソフトウェアを4つの循環で運営する

デジタル庁の「アジャイル開発実践ガイドブック」は、変化が大きく、利用者の反応を見ながら要求を明らかにする領域では、 短い期間で動くものを作り、評価し、計画を見直す考え方を示しています。ただし、アジャイルという名称を付けるだけでは十分ではありません。 事業上の判断と開発上の判断を同じ循環へ載せる必要があります。

  1. 価値仮説：誰のどの行動・業務状態を変え、どの事業成果へつなげるかを明らかにする。
  2. 小さな変更：仮説を確かめられる最小単位へ分け、安全に本番へ届ける。
  3. 利用結果：利用、業務、品質、運用負荷を観測し、想定との差を確かめる。
  4. 優先順位：結果と新しい制約を踏まえ、続ける、変える、止めるを判断する。

内製化は、この循環に必要な知識と意思決定能力を組織内へ残すための選択肢の一つです。外部パートナーを活用する場合でも、 価値の定義、優先順位、受け入れ判断、運用データの理解まで外部へ丸投げしなければ、共同で継続改善できます。 逆に、開発者を雇っても事業側が優先順位を決められず、変更を本番へ出せなければ、内製率だけを高めても事業能力にはなりません。

実践手順1：システム名ではなく、変えたい成果を一つ選ぶ

「基幹システムを刷新する」「内製比率を上げる」ではなく、顧客の申込み完了までの停滞を減らす、見積り回答を早める、 在庫判断の手戻りを減らすなど、利用者または業務の変化を一つ選びます。その成果へ影響する業務、データ、システム、権限を一枚に描き、 どこまでを最初の改善単位にするか決めます。

売上やコストのような最終成果だけでは変化に時間がかかるため、途中の行動も見ます。たとえば、完了率、処理時間、再入力、問い合わせ、 担当者の判断待ちなどです。数値目標は根拠なく置かず、現在値と利用者・現場の観察から、最初に確かめたい仮説を明確にします。

実践手順2：価値と品質を決める小さな責任チームを置く

事業責任者、現場担当、プロダクト責任者、エンジニア、運用・セキュリティなど、成果に必要な役割を小さなチームへ集めます。 全員を専任にできなくても、誰が優先順位を決め、誰が技術上の判断を行い、誰が本番運用の安全性を確認するかを明確にします。 会議へ案件を送るだけでなく、一定範囲の予算と変更判断をチームへ委ねます。

外部パートナーには作業範囲だけでなく、成果仮説、利用データ、品質基準、設計上の判断を共有します。自社側には、業務知識、 アーキテクチャの意図、データの意味、運用上の制約を理解し、変更の可否を判断できる人を残します。役割は会社の内外ではなく、 意思決定と説明責任で定義します。

実践手順3：価値を確かめられる単位へ分けて届ける

全機能がそろうまで待つのではなく、特定の利用者、業務、商品、地域などへ範囲を絞り、実利用から学べる変更単位を作ります。 画面だけでなく、裏側の業務、データ連携、サポート、権限、監視、障害時の戻し方まで含めて、小さくても端から端まで成立させます。

重要な業務では、段階公開、機能切替、並行稼働、手作業への退避などを使い、失敗の影響を限定します。変更頻度を上げること自体を目標にせず、 自動テスト、レビュー、監視、バックアップ、復旧手順を整え、安全に試せる範囲を少しずつ広げます。

実践手順4：価値・品質・流れ・学習を同じ場で測る

利用者の行動と事業成果に加え、障害、性能、セキュリティ、運用負荷、変更の待ち時間を確認します。リリース数だけを見ると、 小さな変更を増やすことが目的化し、品質低下や現場負担を見落とします。逆に、障害ゼロだけを目指すと、必要な改善まで止まりかねません。

定例では、作った機能の一覧ではなく、仮説、実際の利用、想定外、品質、次の判断を並べます。使われない機能は理由を調べ、 続ける価値がなければ止めます。成果が出た場合も、どの条件で再現できるかを確認し、別部門へ一律展開する前に違いを検証します。

実践手順5：契約・予算・技術資産を継続改善へ合わせる

年度単位の一括予算と詳細要件の固定契約だけでは、学習結果を次の変更へ反映しにくくなります。成果の方向性と安全・品質の境界を合意したうえで、 短い期間ごとに優先順位と実施範囲を見直せる契約・予算の形を検討します。契約方式にはそれぞれ条件があるため、調達、法務、経理、 パートナーと早期に相談し、自社に合う管理方法を選びます。

コード、テスト、設計判断、運用手順、データ定義、依存ソフトウェアを変更可能な資産として管理します。担当者交代や契約終了があっても、 別のチームが安全に理解・変更できるかを定期的に確かめます。技術的負債は一度に消すのではなく、事業影響と変更頻度を踏まえて優先順位を付け、 新たな負債を増やさないルールと合わせて減らします。

注意点：内製化やアジャイルを目的にしない

  • 内製率だけで成熟度を決めない：価値、優先順位、設計、運用を自社が理解し、意思決定できるかを見る。
  • 全面刷新を唯一の解にしない：置換、改修、切り出し、廃止を事業価値とリスクで使い分ける。
  • 速度だけを競わない：品質、セキュリティ、運用負荷、復旧可能性と合わせて変更能力を評価する。
  • 現場へ責任だけを渡さない：優先順位を決められる権限、予算、時間、必要な専門支援をセットにする。
  • ツール導入を変革と呼ばない：CI/CDやクラウドの利用より、学習から次の変更までの待ち時間が減ったかを見る。
  • 公的ガイドを機械的に適用しない：業種、事業影響、契約、規制、安全性、既存資産に合わせて取り入れる。

まとめ：完成を目指すプロジェクトから、学び続ける能力へ

ソフトウェアを事業能力として扱うとは、開発を終わらせないことではありません。変えたい成果を定め、価値と品質を判断できるチームを置き、 小さく安全に届け、利用結果から次を決め、契約・予算・技術資産を継続改善へ合わせることです。止めるべき機能やシステムを判断できることも、 育てる能力の一部です。

最初の一歩は、改修待ちが多い一つのサービスを選び、直近の要望を「誰のどの状態を変えたいか」に書き換えることです。 その仮説を確かめる最小の変更、公開後に見る指標、次の優先順位を決める責任者を一枚にまとめてください。 一回の納品ではなく、学習から次の変更までの流れが見えれば、DXを支えるソフトウェア能力の改善点が具体化します。

参考にした公式資料

本記事は公的資料をもとに、一般的なDXとソフトウェア運営の考え方を整理したものです。個別組織の契約、調達、会計、法令適合性、 セキュリティその他の法律上・専門上の助言を行うものではありません。公式資料は2026年8月21日時点で確認しています。 実際の運用では、自社の事業目的、利用者、既存システム、委託関係、適用される法令・規格、リスク許容度を踏まえ、 必要に応じて関係部門や専門家へ確認してください。

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る