システムの価値をどう測るか――CIOに刺さるアプリケーションポートフォリオ評価の作り方

CIOから「全システムの価値を見える化してほしい」と言われたとき、あなたの現場にはどんなデータがありますか？EA（エンタープライズアーキテクチャ）の現場に10年以上いる自分から正直に言わせてもらうと、まともなデータはほぼない。それが現場の出発点です。

システムの価値を可視化することは、ITスリム化への第一歩であり、CIOが意思決定するための最重要インプットです。ただし、「価値を測る」という作業は思ったより泥臭い。自分自身、バブルチャートを作って会議で撃沈した経験も、データ収集でヒアリングをかけて痛い目を見た経験もあります。きれいごとなしに、現場で使える話だけを語ります。

アプリケーションポートフォリオ評価には前提条件がある
APMが求められる理由とEAの役割
バブルチャートは全体把握には使える。廃止判断には使えない
台帳だけでは足りない――ポートフォリオ評価に必要な3つのデータ
システム評価は「断捨離フロー」で動かせ
- Step1：システムの性質で大分類する
- Step2：業務アプリはこの断捨離フローで判定する
分析結果だけ見せても意味がない――アクション提案をセットで出せ
システムをスリム化すれば業務もスリム化される――これは意思だ
まず明日から始めること
［参考文献］

アプリケーションポートフォリオ評価には前提条件がある

この記事が対象としているのは、自社にどんなシステムが何個あるかを、ある程度把握できている組織です。

まだその把握ができていない段階であれば、この記事の前にやるべきことがあります。ITアセット台帳の整備、つまり「自社にどんなシステムが存在するのか」を明確にする作業です。これはアプリケーションポートフォリオ評価の前提条件であり、第1段階と第2段階を並行してやるのは現実的に不可能です。評価対象のシステム一覧が固まっていない状態でポートフォリオ評価を進めると、対象が変動し続けて判断の根拠が崩れるからです。自分の経験から言うと、両方を同時に動かそうとしたとき、どちらも中途半端になりました。

👉 詳しくはこちら：APMより先に現状を見えるようにせよ――アプリケーションポートフォリオ管理を始める前にやるべきこと

ITアセットの全体像がある程度整理できている組織が、次のステップとして取り組むのがこの記事のテーマです。

この記事で伝えたいことは3点です。

バブルチャートによるポートフォリオ評価がなぜ廃止判断に使えないのか
現場で機能する「断捨離フロー」の設計と運用方法
分析結果にアクション提案を必ずセットで出す方法

APMが求められる理由とEAの役割

CIOからの要望は明快です。「システムが何個あって、それぞれどんな価値があるのか、全体像を見たい」。これはアプリケーションポートフォリオ管理（APM）の典型的な出発点です。

APMとは、企業が保有するすべてのアプリケーションをビジネス価値・技術的健全性・コストの観点から継続的に評価・最適化する規律のことです。「どのシステムを維持し、どれを廃止すべきか」という戦略的意思決定を支援することが主眼にあります※1。

この要望の背後には明確な目的がある。ITスリム化、つまりシステムを終息させることです。IT部門としては「どのシステムを廃止候補にするか」の目処を立てたい。業務部門としては「自分たちの業務がスリムになってほしい」。CIOとしては「ITコストをコントロールしたい」。表向きはこの三者の目的が一致しているように見えます。

業務側は本心では、自分たちのシステムが廃止候補になることを望んでいません。調査への協力を求めると、最初は快諾する。でもポートフォリオ評価の目的が「システムの終息」だとわかった瞬間、態度が変わる。10年やってきて、これは例外なく起きます。ボトムアップで廃止を進めようとすると、不利益を被る部門が必ず抵抗する。業務部門が自分たちのシステムを守ろうとするのは、組織として合理的な行動であり、責められない。

ここにEAの役割があります。業務部門は自分たちの業務・システムしか見えていない。経営層は全体最適を求めるが、現場の実態が見えていない。EAはその両方を繋ぐ最も適したポジションにいます。全社のシステムを横断的に可視化し、廃止の根拠を整理し、経営層が意思決定できる形で提案する。それがEAの役割です。EAが分析・提案し、経営層が決断する。この役割分担なしに、あるべき論を押し付けながらトップダウンで進めることはできません。

実際、日本企業の約8割がレガシーシステムを抱えており、その約7割が「デジタル化の足かせになっている」と回答しています※2。さらに、多くの組織がソフトウェア予算の10〜20%を、使われていないか重複しているアプリケーションのライセンス料として浪費しています※3。この二つの現実に向き合うことが、ポートフォリオ評価を始める理由です。

バブルチャートは全体把握には使える。廃止判断には使えない

APMを実践しようとするとき、最初に思いつくのがバブルチャートです。GartnerのTIMEモデルに代表されるバブルチャートは、横軸にビジネス価値、縦軸に技術的健全性を取り、各システムをバブルでプロットする。全体の分布を把握する初期段階では有効な手法です※4。

自分も最初はバブルチャートを作りました。スコアリングの式を組み、データを集め、それなりのバブルチャートが完成した。CIOに見せたときの反応は悪くなかった。「見えなかったものが見えてきた」という高揚感が、その場にはありました。自分自身も手応えを感じていた。

ところが現場に見せた瞬間、空気が変わりました。「なぜこのシステムがこのスコアなのか」「なぜこの評価軸なのか」「なぜこの重み付けなのか」という「なぜ？」が横行した。式は出せる。でも「なぜその式なのか」を明確に説明できなかった。数字の根拠を問われると答えられず、会議は「この評価軸の定義から見直そう」という話になり、前に進めなかった。

廃止判断のツールとしては機能しません。

研究によれば、主観的なスコアリングは強いバイアスを生みやすく、「総論賛成・各論反対」を招く一因になると指摘されています※5。財務部門はコストの高さから廃止を求めるが、現場のユーザーにとっては「たまにしか使わないが極めて重要な」機能が含まれている場合、廃止への強い抵抗が生じます※6。バブルチャートは全体感の把握に使い、廃止判断には別の道具が必要です。

台帳だけでは足りない――ポートフォリオ評価に必要な3つのデータ

ITアセット台帳には「システムが存在すること」は記録されています。しかしポートフォリオ評価には、台帳だけでは不足するデータが必要になります。具体的には以下の3つです。

① 業務との紐付け（BCM観点）
台帳にはシステム名と所管部門が記録されていても、「そのシステムがどの業務プロセスを支えているか」「業務継続管理上の重要度はどれくらいか」という紐付けは、多くの場合ITとは別の部門が管理しており、粒度も軸も異なります。この変換作業が避けて通れません。

② 利用者の実態
台帳に記載されている「利用者数」は登録ユーザー数であることが多い。ポートフォリオ評価に必要なのは「実際に使っているユーザー数」です。ヒアリングをかけたときの話をします。項目を揃え、定義を統一して調査票を作った。でも回答者がそれぞれの目的で答えるため、同じ項目でも意味合いが変わってしまった。ある部門は「登録ユーザー数」で答え、別の部門は「月次アクティブユーザー数」で答える。自分も最初から完璧なデータを求めて失敗した。粗くても動かした方が結果的に早い。

③ 業務オーナーの評価
「このシステムはあなたの業務にとってどれくらい重要か」と聞くと、ほぼ全員が「重要だ」と答えます。これも現場で必ず直面する壁です。重要度は絶対評価ではなく相対評価で聞くことが必要です。「このシステムが1週間止まったらどうなりますか？」という問いに変換することで、業務継続への実質的な影響度が見えてきます。台帳には存在しないこのデータを、ビジネスオーナーへのヒアリングで収集することが不可欠です。

3つのデータが揃ったら、次はフローを回す番です。

システム評価は「断捨離フロー」で動かせ

EAがフローを設計し、実務担当者が各システムの情報を埋めていく。この役割分担で動かすことが現実的です。

システムをなくすことは、そのシステムを使う業務を変えざるを得ない状況を作ることでもあります。それを最初から意図してフローを設計することが重要です。

ヒアリングで補完データを集めるときは、「ITスリム化・システムの終息」という大義名分を前面に出すことで協力を得やすくなります。「コスト削減のため」ではなく「業務をスリムにするため」という言い方が、業務側には刺さります。業務部門は日常的に「業務が複雑すぎる」「システムが使いにくい」という不満を抱えています。その不満に直接応える言葉を選ぶことが、協力を引き出す最短ルートです。「コスト削減」は自分たちへの影響が見えにくく他人事に感じやすい。「業務をスリムに」は自分たちの痛みに寄り添う言葉だから響く。

フローの考え方はシンプルです。条件を一つずつ問いとして立て、答えを積み重ねることで分類していく。まず2つに大分類し、それぞれ4つの問いで判定する構造です。

Step1：システムの性質で大分類する

まず「業務アプリケーション系か、インフラ系か」で大きく二分します。HR・会計・調達などの業務アプリと、ネットワーク・サーバー・基盤系とでは、評価の軸がまったく異なります。

インフラ系は以下の4点を軸に優先度をつけます。

① 保守サポート終了年の確認
ベンダーのサポートが切れているか・切れそうかを確認する。サポート切れのシステムはセキュリティリスクが高く、廃止・移行の優先度が自動的に上がります。

② 老朽化による障害リスクの評価
過去の障害発生頻度・復旧にかかった工数を確認する。障害が多いシステムは維持コストが見えにくい形で膨らんでいることが多い。

③ 現行コストと移行コストの比較
現状維持にかかる年間コストと、クラウド移行や更改にかかる初期コストを比較する。一般的に5年を目安としたTCO（総保有コスト）で比較する手法が使われます。短期の初期費用だけで判断すると、移行後のランニングコストで想定外の増加が起きるケースがあるため注意が必要です。

④ クラウド移行可否の判断
オンプレミスで動いているシステムをクラウドに移行できるか。ただしクラウド移行がコスト最適化に直結するとは限りません。移行できる・できないの判断と同時に、移行した場合のコスト試算を必ずセットで行うことが重要です。

業務アプリ系は以下の断捨離フローで判定します。

Step2：業務アプリはこの断捨離フローで判定する

① グローバル標準システムへの移行可否
このシステムが担っている機能は、すでに導入済みのグローバル標準システム（ERPやSaaSなど）に移行できるか？ Yesなら移行・廃止候補。Noなら次の問いへ。この判断基準としてフィット・トゥー・スタンダードの考え方が有効です。標準プロセスへの準拠はアドオン開発コストを抑え、AI等の最新機能の導入も容易にします※7。

② ケイパビリティの重複確認
同じ業務機能（たとえば給与計算）を担うシステムが複数存在していないか？企業が利用するSaaSアプリケーションの数は平均130個に達しており、その多くがIT部門の把握していないシャドーITとなっています※8。これは北米企業を中心とした調査ですが、日本企業でも同様の傾向が見られます。重複があるなら、どちらを残すかの判断フェーズへ。

③ 利用者数・業務必須性の確認
利用者が極端に少ない、またはBCM（業務継続管理）上の必須度が低いシステムは、廃止候補として優先度を上げる。BCMにおけるビジネスインパクト分析（BIA）で設定されるRTO/RPO※9は、このシステム重要度の格付けに活用できます。

④ 廃止できない理由の名指し確認
「廃止できない」という声が出たとき、「全社対応できればなくせる」では不十分です。グループ会社単位・拠点単位で「どこがなぜ対応できないか」を具体的に名指しで記録する。実際にこのフローを回してみると、④に辿り着いた時点で「廃止できない理由」が想定より多く出てくることに気づきます。それ自体が組織の現状を可視化する成果です。システム間の複雑な依存関係がある場合は、このフローとは別に依存関係の課題管理が必要になります。

このフローを回すことで、「断捨離候補」「維持すべき理由あり」「別の課題がある」という三分類が見えてきます。

分析結果だけ見せても意味がない――アクション提案をセットで出せ

フローを回して三分類が出た。ここからが本当の勝負です。分析結果をどうCIOに見せるか。

ポートフォリオ評価をCIOに報告するとき、陥りやすい失敗があります。分析結果だけ見せて終わること。

「断捨離候補が20システムありました」と言われたCIOは、「で、どうするの？」としか思わない。分析に時間をかけるほど、「自分たちはどうしたいのか」という意思表示が後回しになる。社内IT担当者なら一度は経験があるはずです。

報告のセオリーはこうです。まず全体像（システム総数・分類結果）を示す。次にフォーカスする対象を絞り込む。そして「我々はこうしたい」というアクション提案を必ずセットで出す。

案を出せないなら、案を出せる人と連携する。それすら難しければ、「案を出せる状態にするために何が必要か」を正直に伝える。いずれにせよ、「分析して終わり」では報告ではなく、ただのデータ提出であり、提案ではありません。

システムをスリム化すれば業務もスリム化される――これは意思だ

「システムをスリム化すれば、業務もスリム化される」。証明できるデータは正直まだない。でも、自分はこれを意思として持つべきだと考えています。

システムが残り続ける限り、そのシステムを使う業務プロセスも残り続ける。システムがなくなれば、業務のやり方を変えざるを得ない。その強制力こそが業務変革の推進力になる。ただしこの強制力を機能させるには、CIOや経営層のトップダウンが前提条件です。EAが分析・提案し、経営層が意思決定する。この役割分担なしに、業務部門は動きません。

アプリケーションポートフォリオ管理は、単なる棚卸し作業ではありません。「何を残し、何をなくすか」という強い意思を持って臨む、経営判断の支援活動です。レガシーコストを削減して生まれたリソースを、AI投資や次の成長へと振り向ける。それがEAの仕事です。