「社内で使われているシステムとSaaSは、全部でいくつありますか」——この問いに即答できる情報システム部門は多くありません。基幹システムのように予算規模の大きなものは把握できていても、事業部門がクレジットカードで契約したSaaS、退職者が立ち上げたまま誰も止めていないツール、そして最近急増した生成AIサービスまで含めた全体像となると、途端に輪郭がぼやけます。

2026年に入り、SaaS管理ツールやシャドーIT・シャドーAIの検知機能を打ち出す製品発表が相次いでいます。可視化の手段が増えたこと自体は前進です。しかし多くの組織で止まるのは、その次の段階です。一覧が出てきたあとに、何を残し、何を統合し、何を捨てるのかを、誰がどの基準で決めるのかが決まっていないため、リストは作られたまま塩漬けになります。

本記事では、この「一覧を作った先」を扱います。アプリケーションポートフォリオ管理（APM：企業が保有するアプリケーション群を台帳として把握し、価値と健全性の観点から評価して、投資・維持・統合・廃止を継続的に判断する仕組み）を、台帳づくりから評価軸の設計、仕分け、体制と運用まで、IT企画・情報システム部門の推進目線で整理します。ツールの操作手順ではなく、何を決め、誰に担わせ、どう回し続けるかに焦点を当てます。

課題 ― 「棚卸しはしたが、何も減らなかった」

アプリケーションが増えすぎた組織には、共通する3つの症状があります。

症状1：同じ用途のツールが複数走っている

部門ごとに個別最適でSaaSを選定した結果、タスク管理ツールが部門の数だけ存在する、といった状態です。ライセンス費が重複するだけでなく、情報が分散して横断的な把握ができなくなります。異動のたびに使い方を覚え直す負担も現場に発生します。

症状2：誰も使っていないのに止められないシステムがある

利用者がほとんどいないにもかかわらず、稼働し続けているシステムです。止めようとすると「一部の業務で月次だけ使っている」「過去データの参照に必要」といった声が出て、判断が止まります。責任を持って「止める」と言える立場の人が定義されていないため、結論が先送りされ続けます。

症状3：一覧はあるが、判断材料になっていない

資産管理ツールやSaaS管理ツールを導入し、アプリケーションの一覧までは出せている組織も増えました。ところがその一覧には「何のシステムか」「いくらかかっているか」は載っていても、どの業務を支えているか、止めたら誰が困るか、技術的にあと何年もつかが載っていません。これでは投資判断にも廃止判断にも使えません。

経済産業省が2025年に公表した「レガシーシステムモダン化委員会総括レポート」でも、IT資産の可視化——保有するITシステム群と、その構成要素であるハードウェア・ソフトウェア・ネットワーク・データベースなどのIT資産、およびそれらの相互関係を把握し管理すること——が、モダン化を進めるうえでの出発点として位置づけられています。同レポートでは、経営層と情報システム部門の間で情報が共有されている企業ほど、可視化やブラックボックス対策が進む傾向があることも指摘されています。裏を返せば、可視化が進まない組織では、情報が経営に届いていないことが多いということです。

背景 ― なぜアプリケーションは増え続けるのか

症状の裏には、意思決定の構造的な偏りがあります。

「足す」判断はできても「引く」判断の場がない

新しいシステムやSaaSの導入には、稟議・予算・導入プロジェクトという明確な手続きがあります。一方で廃止には、そうした手続きがありません。誰かが問題提起しない限り、議題にすら上がらないのです。結果として、ポートフォリオは足し算だけで膨らみ続けます。

調達の権限が分散した

SaaSは事業部門が単独で契約でき、金額も月額数万円規模から始められます。稟議の閾値を下回る調達が積み重なることで、全社的には無視できない支出と統制の穴になります。これはガバナンスの不備というより、購買のあり方が変わったことに管理の仕組みが追いついていない状態です。

廃止のコストが見えていない

システムを止めるには、データの移行と保管、代替手段の準備、業務手順の変更、契約の解約手続きが必要です。この手間が個別部門に降りかかる一方、削減効果は全社の予算に薄く広がります。当事者から見ると割に合わないため、放置が合理的な選択になってしまいます。

生成AIサービスが同じ経路で増えている

2025年以降は、ここに生成AIサービスが加わりました。無料あるいは少額で始められ、業務効率への効果が実感しやすいため、現場からの導入が先行します。SaaSで起きたことが、より速いスピードで繰り返されている状態です。AIそのものの利用ルールについてはAIガバナンスの始め方で扱っていますが、ポートフォリオ管理の観点では「台帳に載せる対象がまた増えた」ことを意味します。

アプリケーションポートフォリオ管理とは何か

APMは、企業が保有するアプリケーションを投資対象の集合（ポートフォリオ）として扱い、個々のアプリケーションについて維持・強化・統合・廃止の判断を継続的に下す仕組みです。金融のポートフォリオ運用と同じ発想で、全体のバランスを見ながら配分を組み替えていきます。

エンタープライズアーキテクチャ（EA：企業のビジネス・データ・アプリケーション・技術の構造を全体最適の観点から設計する手法）の枠組みで言えば、APMはアプリケーションアーキテクチャ層の中核的な実務にあたります。TOGAFでもアプリケーションポートフォリオカタログが標準的な成果物として位置づけられています。EA全体をどう立ち上げるかはエンタープライズアーキテクチャ（EA）の始め方で扱いましたが、EAを「全部やる」のが難しい組織にとって、APMは最初に着手する実行単位として現実的です。効果が費用として目に見えやすく、経営に説明しやすいからです。

似た取り組みと混同されやすいため、違いを整理します。

取り組み 主な問い 主な担い手
IT資産管理・SaaS管理ツール どこに何があるか、誰が使っているか 情報システム部門（運用）
IT投資の可視化（TBM・FinOps） 何にいくら使っているか、投資は妥当か IT企画・経営企画
アプリケーションポートフォリオ管理 このアプリケーションを残すか、統合するか、捨てるか IT企画・EA担当
基幹システム刷新の意思決定 この大型資産をいつ・どう作り替えるか 経営・IT企画・PMO

資産管理ツールはインプットを集める手段であって、APMそのものではありません。ツールを導入しただけで判断が進まないのは、この違いが押さえられていないためです。コストの可視化についてはIT投資の見える化から始める投資管理、大型資産の作り替え判断については基幹システムのサポート終了をどう決めるかで扱っています。APMはこれらをつなぐ土台と考えるのが実務的です。

進め方 ― 4つのステップ

ステップ1：台帳をつくる（粒度を先に決める）

最初にやるべきは、網羅性の追求ではなく粒度の定義です。ここを曖昧にしたまま情報を集め始めると、基幹システム1本と、あるチームだけが使うツール1本が同じ行に並び、比較できない台帳ができあがります。

現実的な決め方は、「独立して契約・廃止できる単位」を1件とすることです。同一製品でも、部門ごとに別契約で運用しているなら別行にします。逆に、モジュールが多数ある基幹システムは、廃止判断が一体で下されるなら1行にまとめます。

初回に集める項目は、多すぎないことが重要です。実務では次の程度から始めます。

項目 なぜ必要か
名称・提供形態（自社開発／パッケージ／SaaS） 打ち手の選択肢が変わる
支えている業務 止めたときの影響を判断する起点
業務所管部門と業務側の責任者 廃止・統合の意思決定者を特定する
IT側の担当者・保守ベンダー 実行の担い手を特定する
年間コスト（ライセンス・保守・運用工数） 削減効果を見積もる
利用状況（アカウント数・アクティブ利用の有無） 廃止候補の一次スクリーニング
技術面の期限（サポート終了時期・老朽度） リスクの時間軸を持つ
連携先システム 止めたときの波及範囲を把握する

すべてのアプリケーションについてこれらを完璧に埋めようとすると、着手前に力尽きます。まず全件について名称・所管部門・コストだけを埋め、詳細は仕分けの候補に絞ってから深掘りするという二段構えが実務的です。

なお、業務との対応づけの精度を上げようとすると、業務そのものが整理されていないという壁に当たることがあります。その場合は業務側の整理を待たず、「この部門のこの業務」という粗い対応づけで先に進めます。完璧な業務モデルは、APMの前提条件ではありません。

ステップ2：評価軸を決める

台帳ができたら、何をもって「価値がある」「健全である」と判断するかを決めます。ここを組織として合意しておかないと、仕分けが担当者の主観になり、後で覆されます。

一般的には次の2軸を使います。

ビジネス価値：そのアプリケーションが支えている業務の重要性、利用の広がり、競争力への寄与、止まったときの事業影響。

技術的健全性：サポート提供の継続性、老朽度、保守できる要員の有無、ドキュメントの整備状況、他システムとの連携のしやすさ、セキュリティ上の状態。

この2軸に加えて、判断の材料としてコストとリスクを添えます。2軸で位置づけを決め、コストで優先順位を、リスクで着手時期を決める、という使い分けです。

評価は精緻さより組織内で説明できることが重要です。100点満点の点数を積み上げるより、各軸を「高・中・低」の3段階で、判断根拠を1行添えて記録するほうが実用に耐えます。評価者は業務側とIT側の両方を必ず含めます。片方だけで評価すると、業務側は「全部重要」と答え、IT側は「全部古い」と答えるためです。

ステップ3：仕分ける

評価結果を使って、アプリケーションごとの方針を決めます。ここで広く使われているのが、Gartnerが提唱したTIMEフレームワークです。ビジネス価値と技術的健全性の2軸で4つの区分に分けます。

区分 位置づけ とるべき方針
Tolerate（許容） 技術的には問題ないが、ビジネス価値は限定的 追加投資はせず、現状のまま維持する。統合の機会があれば検討
Invest（投資） ビジネス価値も技術的健全性も高い 機能強化・活用範囲の拡大に投資する
Migrate（移行） ビジネス価値は高いが、技術的健全性が低い 代替手段への移行、または刷新を計画する
Eliminate（廃止） どちらも低い 廃止する、または他システムへ統合する

この枠組みの効用は、分類の正確さそのものではなく、「投資しない」という選択肢を明示的に用意することにあります。多くの組織では、判断が「投資するか、しないか」の二択になっており、「価値は低いが技術的には安定しているので、あえて何もしない」という中間解が言語化されていません。Tolerateという区分があることで、「手をつけない」という判断を意図的な決定として記録できるようになります。

仕分けにあたっての注意点が2つあります。

第一に、分類は目的ではなく議論のきっかけです。境界線上にあるアプリケーションほど議論の価値が高いため、無理に4象限に押し込めるより、「なぜ判断が割れるのか」を記録しておくほうが後で効きます。

第二に、MigrateとEliminateには実行計画が必要です。分類しただけで実行が伴わなければ、翌年も同じ分類が並ぶだけになります。仕分けの時点で、少なくとも着手時期の目安と担当を決めておきます。

ステップ4：定例の意思決定プロセスに載せる

APMが単発の棚卸しで終わるか、仕組みとして定着するかの分かれ目は、判断の場が定例化されているかです。

実務では次の2つを組み合わせます。

年次のポートフォリオレビュー：予算編成のサイクルに合わせ、全アプリケーションの区分を見直します。予算プロセスと接続することで、削減効果が次年度の投資原資として説明できるようになります。

都度の入口審査：新規のシステム・SaaS導入時に、台帳への登録と、既存アプリケーションとの重複確認を必須にします。入口を押さえないと、レビューで減らした分が翌年また増えます。このとき審査を重くしすぎると現場が回避行動をとるため、小額のSaaSは登録と重複確認のみ、一定額以上は正式な審査というように、重さを分けるのが定着のコツです。

判断基準 ― 「捨てる」をどう決めるか

APMで最も難しいのは廃止の判断です。反対する声は必ず出ますし、その声には正当な根拠があることも少なくありません。判断を前に進めるには、次の問いを順に確認します。

問1：その業務は本当に続くのか

「使っている」という声の中には、業務そのものが惰性で続いているケースが混ざっています。システムの要否ではなく、業務の要否から確認します。

問2：代替手段はあるか

既存の別システムで代替できるなら、統合が第一候補です。この確認は台帳上の「支えている業務」が揃っていて初めて可能になります。台帳の項目にこれを含める理由がここにあります。

問3：データをどう扱うか

廃止で最も見落とされるのがデータです。法令や社内規程で保存期間が定められているデータがあれば、システムを止めてもデータは残す必要があります。参照用に別形式で保管する、後継システムへ移行する、といった扱いを先に決めます。データの所在と定義が整理されていない場合は、データガバナンスの始め方の観点も併せて検討します。

問4：契約と再委託の状態はどうなっているか

保守契約の解約条件、複数年契約の残期間、ベンダーが保有しているソースコードやドキュメントの引き渡し条件を確認します。委託先が複数にまたがる場合の統制についてはマルチベンダー時代のベンダーマネジメントで整理しています。

問5：誰が最終的に決めるのか

ここが決まっていない組織が最も多く見られます。原則は、業務所管部門の責任者が業務としての要否を判断し、IT部門は判断材料と代替案を提示するという分担です。IT部門が単独で廃止を決めようとすると、必ず抵抗に遭います。逆に業務部門に丸投げすると、現状維持が選ばれ続けます。

体制 ― 誰が何を担うか

APMを回すために新しい組織を作る必要はありません。既存の役割に責任を割り当てるほうが定着します。

役割 担うこと
IT企画・EA担当 台帳の設計と維持、評価軸の定義、仕分けの取りまとめ、経営への報告
情報システム部門（運用） 技術面の評価、利用状況・コストデータの提供、廃止・移行の実行
業務所管部門 ビジネス価値の評価、業務としての要否判断、廃止時の業務手順の見直し
調達・法務 契約条件の確認、解約手続き、新規調達時の入口審査
PMO 移行・統合案件のプロジェクト管理、複数案件の優先順位調整
経営層・CIO 評価軸と方針の承認、部門間で判断が割れた場合の裁定

体制設計で決定的に重要なのは、経営層の裁定の場を用意しておくことです。廃止・統合は部門間の利害が対立する意思決定であり、実務レベルでは結論が出ないことがあります。エスカレーション先が定義されていないと、対立した案件がそのまま塩漬けになります。PMOやIT企画の体制設計の考え方についてはPMOの立ち上げ方と組織設計も参考になります。

台帳の規模が大きくなると、表計算ソフトでの維持は限界を迎えます。アプリケーション間の依存関係や業務との対応づけを継続的に保つ段階では、EAツールの利用が現実的な選択肢になります（当社もITマネジメント向けのEAツールPortistを提供しています）。ただし、ツールは評価軸と体制が決まったあとに入れるのが順序です。決め方が固まっていない段階でツールを入れると、空欄の多い台帳が増えるだけになります。

SaaSとシャドーAIをどう台帳に載せるか

SaaSと生成AIサービスは、従来の自社システムとは別の扱いが必要です。数が多く、入れ替わりが速く、契約主体が分散しているためです。

発見の経路を複線にする

購買・経費データからの抽出、ID基盤の認証ログ、ネットワーク経路での検知、そして部門への申告——これらを組み合わせます。単一の経路では必ず漏れます。特に、クレジットカード決済や個人アカウントで契約されたサービスは、経費精算のデータからしか見つからないことがあります。

申告を罰しない

シャドーITの発見を摘発として運用すると、申告されなくなり、可視性がかえって下がります。一定期間は申告すれば咎めないという運用にし、その間に台帳へ載せきるのが実務的です。

生成AIサービスは判定基準を先に決める

生成AIサービスは、業務データを外部に渡す可能性がある点で、通常のSaaSよりリスクの評価が難しくなります。個別に判断していると処理が追いつかないため、入力してよいデータの区分、契約形態（学習利用の有無）、承認が必要な範囲を先に基準として定めておき、基準に照らして機械的に振り分けます。基準づくりの進め方はAIガバナンスの始め方で詳しく扱っています。

軽量なものは軽量に扱う

少人数が使う低額のツールに、基幹システムと同じ評価工数をかけるのは非効率です。金額と扱うデータの機密度で階層を分け、下位の階層は「登録と年次の利用確認のみ」といった簡易な扱いにします。

よくある失敗と回避策

失敗 何が起きるか 回避策
網羅性を求めすぎる 台帳が完成する前に推進力が尽きる 全件は最小項目のみ。詳細は候補を絞ってから
評価軸を精緻にしすぎる 点数計算が目的化し、判断に使われない 3段階＋根拠1行から始める
IT部門だけで評価する 業務側の納得が得られず、廃止が覆る 評価には業務所管部門を必ず入れる
分類して終わる 翌年も同じ分類が並ぶ 仕分け時に着手時期と担当を決める
入口審査を作らない レビューで減らした分がまた増える 新規導入時の台帳登録と重複確認を必須にする
審査を重くしすぎる 現場が回避し、シャドーITが増える 金額・データ機密度で審査の重さを分ける
ツールを先に入れる 空欄の多い台帳ができる 評価軸と体制を決めてからツールを選ぶ
削減額だけを成果にする 削りやすいものだけが削られ、リスクの高い資産が残る リスク低減（サポート切れの解消等）も成果指標に含める

最後の項目は特に注意が必要です。コスト削減だけを目標に据えると、契約解除が容易な小規模SaaSばかりが対象になり、本当に手を打つべき老朽化した基幹資産が後回しになるという逆転が起きます。成果は「削減額」と「リスクが解消されたアプリケーション数」の両輪で報告するのが望ましい形です。

最初の90日で何をするか

一度に全体をやろうとせず、判断の型を先に作ることを勧めます。

期間 やること 成果物
1か月目 粒度を定義し、既存の資産管理データ・購買データ・ID基盤から全件の名称・所管部門・コストを集約する アプリケーション台帳（最小項目版）
2か月目 評価軸を定義して経営の承認を得る。コスト上位と業務影響の大きいものに絞って業務側とIT側で評価する 評価基準書、優先対象の評価結果
3か月目 評価済みの範囲でTIMEの仕分けを行い、廃止・統合の候補について着手時期と担当を決める。新規導入時の入口審査ルールを定める 仕分け結果とロードマップ、入口審査ルール

3か月で全アプリケーションを仕分ける必要はありません。一部でも「評価して、仕分けて、実行を決める」という一連の流れを通すことが目的です。この型ができていれば、残りは同じ手順を繰り返すだけになります。

FAQ

Q. アプリケーションポートフォリオ管理は、IT資産管理やSaaS管理ツールと何が違うのですか。

A. 資産管理・SaaS管理ツールは「どこに何があり、誰が使っているか」を把握する手段です。APMはそのデータを使って「残すか、統合するか、移行するか、捨てるか」を判断する仕組みです。ツールは入力を集めるところまでを担い、判断の枠組みは組織側で用意する必要があります。

Q. EAを立ち上げていない組織でも始められますか。

A. 始められます。むしろAPMは、EA全体を立ち上げる前の入口として適しています。効果がコスト削減とリスク低減という形で見えやすく、経営に説明しやすいためです。APMで作った台帳は、後からEAに取り組む際のアプリケーションアーキテクチャの基礎資料としてそのまま使えます。

Q. 台帳は何件くらいから管理が必要になりますか。

A. 件数よりも、「所管が分散しているか」で判断するのが実務的です。すべてのシステムを情報システム部門が把握・契約している段階なら、表計算ソフトでも回ります。事業部門が独自に契約を始めた時点で、件数にかかわらず仕組みとしての管理が必要になります。

Q. 廃止に反対されて進まない場合はどうすればよいですか。

A. 反対の理由を「業務が必要」「データが必要」「移行の手間が負担」の3つに分解します。業務が必要なら廃止対象から外し、データが必要なら保管方法を決め、手間が負担なら移行の支援体制を用意します。多くの場合、反対の実体は3つ目です。この場合、廃止側にIT部門が実務支援を提供することで前に進みます。

Q. 生成AIサービスも同じ台帳で管理すべきですか。

A. 同じ台帳に載せることを勧めます。別管理にすると全体像が見えなくなるためです。ただし評価の軸は追加が必要です。通常の項目に加え、扱うデータの区分と、学習への利用可否を含む契約条件を記録します。

Q. 経営層にどう説明すれば取り組みが承認されますか。

A. 「整理する」ではなく、「次の投資の原資を作る」と「期限のあるリスクを可視化する」の2点で説明します。前者は削減見込み額、後者はサポート終了時期が近いアプリケーションの一覧が材料になります。特に後者は期限が外から与えられているため、経営の判断を促しやすい材料です。

まとめ

システムやSaaSが増え続けることは、それ自体が問題ではありません。問題は、増やす判断の仕組みはあるのに、減らす判断の仕組みがないという非対称です。可視化ツールが普及した今、多くの組織にとってのボトルネックは「見えないこと」ではなく「見えたあとに決められないこと」に移っています。

APMの本質は、精緻な台帳を作ることでも、正確に4象限へ分類することでもありません。「このアプリケーションをどうするか」を、決められた基準で、決められた人が、決められた頻度で判断する状態をつくることです。台帳も評価軸も仕分けも、そのための道具にすぎません。

着手にあたっては、全体を完璧に把握してから動き出そうとしないことです。粒度を決め、最小項目で全件を並べ、優先度の高いものから評価して仕分ける。この一連の流れを一度通してしまえば、あとは同じ手順の繰り返しになります。次の投資の原資も、期限のあるリスクへの対処も、その先に見えてきます。

参考資料