APMより先に現状を見えるようにせよ――アプリケーションポートフォリオ管理を始める前にやるべきこと
APMを始めよう、という号令がかかった。さっそくシステムの棚卸しを始めた。半年後、集まったデータは古くて使い物にならなかった――。これは作り話ではありません。現場で何度も見てきた光景です。そしてその失敗の原因は、ほぼ例外なく同じところにあります。「APMより先にやるべきことを、やっていなかった」という一点です。
社内システムの棚卸しが必要だという合意はすでにある。でも、その先の進め方を間違えると、せっかく動き出した取り組みが半年後に空回りします。問題は「何をするか」ではなく「どの順序でやるか」です。
APMが機能しない現場の現実――理想と実態のギャップ
そもそもアプリケーションポートフォリオ管理という概念が生まれた背景には、「システムのデータが揃えば、廃止・継続・投資の判断がデータドリブンでできるはずだ」という仮説があります。Gartnerが提唱するTIMEモデル（Tolerate・Invest・Migrate・Eliminate）はその代表的なフレームワークで、技術的な健全性とビジネス価値の2軸でアプリケーションを4象限に分類し、投資判断を下すというものです。理屈の上では完璧なシナリオだ。
ただしTIMEモデルが機能する前提は、評価対象のシステム情報が正確に揃っていることです。その前提が崩れている現場では、どんなフレームワークも絵空事になる。
大手企業の現場には、何十年も複雑に絡み合った歴史と組織の都合と政治的事情と、担当者の頭の中にしか存在しない暗黙知がある。そういう世界の中で、「現状把握なしにデータでシステム廃止を判断できる」などという美しい話は、到底成立しません。
Flexeraの調査でも、APM導入の失敗要因は技術的な問題よりも「組織的な文化やガバナンスの欠如、データの不備といった非技術的側面」に根ざしていることが明らかになっています。現状把握が不十分なまま下された廃止判断は、現場からの強い反発を招き、IT部門への不信感を増大させる――これは海外の調査が示す事実であり、自分の現場でも何度も目撃してきた光景です。
さらに、最初の調査で何十項目もの情報を一度に集めようとするのも失敗のパターンです。現場の負担が大きすぎて回答の質が下がり、集まったデータはスカスカになります。調査した時点からすでに時間が経ち始め、活用しようとする頃には情報が陳腐化して使い物にならない。APMの成熟度モデルでは、最初期の「アドホックな可視化」から「構造化されたインベントリ」へ移行するステップが最も重要だと言われています。このステップを軽視することが、後の致命的なデータ品質問題を引き起こします。
では正しい順序はどうか――APMより先にやる3つのステップ
APMより先にやるべきことは、シンプルに3段階です。
第1段階：システム情報の収集：まず「どこに何のシステムがあるか」という基礎情報を揃える。この段階では項目を絞ることが重要です。完璧を求めず、まず存在を把握することを優先する。
第2段階：現場の声を聞く：基礎情報が揃ったら、現場へのヒアリングを行います。「なぜそのシステムが存在するのか」「誰が使っているのか」「なくなったら困るか」という問いに答えてもらう。データと現場の感覚を照合するプロセスです。
第3段階：意識合わせと判断：現場の声を踏まえた上で、「やはり減らせるのではないか」という感覚が組織として共有されて、初めてアプリケーションポートフォリオとしての判断ができるようになります。
この3段階を経て、ようやくTIMEモデルのような投資判断フレームワークが機能し始めます。最初からポートフォリオ判断をしようとするのは、第3段階から始めようとするのと同じです。
第1・第2段階の実践――内製整理から現場依頼まで
第1段階で最初にやるべきことは、現場への調査依頼を出す前に、事務局が自分たちでできることをやり切ることです。
社内には何らかのマスター情報が必ず存在しています。Excelファイル、購買システムの記録、セキュリティ管理の資料、予算管理表など、システムに関連する情報は複数の場所に散らばっています。これをまず内製で掻き集める。
ただし、この作業は思ったより大変です。名寄せの問題が必ず発生します。同じシステムが別の名前で複数の台帳に登録されていたり、粒度がまったく異なる情報が混在していたりします。管理元・管理者・利用部門といった属性情報を手がかりに地道に紐付けていくしかありません。これはITAM（ITアセット管理）の世界でも「名寄せ（Normalization）とデータクレンジングが最も工数を要するステップ」として広く知られています。
これは特定の組織の問題ではありません。IPAの調査によれば、IT戦略を統括するCIOが不在あるいは権限が限定的な企業が約50%に上るとされており、全社横断的なシステム棚卸しを推進するリーダーシップが欠如している実態は日本企業全体に共通する構造的な課題です。リソース不足を理由に現場丸投げにすると、データ品質は必ず下がります。
内製の情報整理が一定程度進んだら、第2段階の現場への依頼に移ります。依頼される側も人間です。「なんかよくわからない調査が来た」と感じると、回答の質は下がります。現場が協力してくれるかどうかは、依頼する側の準備と姿勢で決まります。
目的を明確にする：何のためにこの情報が必要なのかを、現場の言葉で説明できること。「アプリケーションポートフォリオ管理のため」では伝わりません。正確なデータが存在することで、インシデント発生時の影響範囲を素早く特定できる。担当者が異動しても引き継ぎコストが下がる。そういった現場にとっての恩恵をセットで伝えることが効果的です。
事務局が最大限汗をかく：自分たちで集められる情報は集め切ってから依頼する。現場に渡す調査票はできる限り事前入力しておく。「すでにこれだけ調べた上でお願いしている」という姿勢が、現場の回答品質を変えます。
トップダウンの意思を背景に持つ：事務局の努力だけでは動かない現場も存在します。経営層からの明確な意思表示があることが前提条件です。ただし振りかざすのではなく、丁寧な依頼姿勢と組み合わせることが重要です。
ServiceNow・CSDMの活用――第1段階の登録作業でどの層から入るべきか
第1段階でシステムの基礎情報が揃い始めたら、並行してITSMツールへの登録を進めます。ここでもAPMと同じ原則が適用されます。最初から全部を入れようとしないことです。
ServiceNowが提唱するCSDM（Common Service Data Model）を例に挙げると、ビジネスサービス層（業務上のサービス単位）、アプリケーションサービス層（システムの論理的な単位）、テクノロジー層（サーバーや構成アイテムなどの物理的な単位）という層構造があります。
現場の感覚として、最初に着手すべきはアプリケーションサービス層です。「このシステムは何で動いているか」「環境は何か」といった、人が管理しやすい粒度の情報からまず入れていく。次にテクノロジー層、つまりサーバーレベルの構成情報やCI（構成アイテム）レベルの情報を追加します。このテクノロジー層の把握を第1段階のゴールとして設定することが現実的です。ビジネスサービス層との紐付けは、第2段階以降で構いません。
ServiceNow以外のツールを使っている場合でも、「どの粒度から入るか」という考え方は同様に適用できます。
現実的な時間軸――システム可視化に2年かかる理由
これは覚悟の話です。断言します。甘く見ると必ず後悔します。
1年目はシステム棚卸しと基礎情報の収集・整理です。名寄せ、ツールへの登録、データクレンジングを進める。これだけで約1年かかります。「そんなにかかるのか」と思う方もいるでしょう。でも現場でやってみると、むしろ1年では足りないと感じる局面の方が多い。
2年目はデータ品質を維持する仕組みの確立です。承認フロー、更新ルール、棚卸しのサイクル、担当者が変わっても情報が劣化しないプロセスを整備する。合計2年を経て、ようやくアプリケーションポートフォリオ管理として機能し始める状態になります。
データ陳腐化の主な原因は、組織変更・システムの小規模な改修・担当者の異動・手動入力への依存です。維持するプロセスがなければ、正確に作ったデータも気づかないうちに劣化していく。これは現場で何度も繰り返し経験してきた事実です。だからこそ2年目の「仕組みづくり」に、1年目と同じかそれ以上の本気度で取り組む必要があります。
「データが揃ってからでは遅い。並行して進めればいいのでは」という意見もあります。ただ、品質が担保されていないデータでAPMを動かすと、間違った優先順位付けや誤った意思決定につながるリスクがあります。土台のないところに建物を建てようとするのと同じです。
経営層への説明は、最初にスケジュールを合意しておくことが鍵です。暫定的な状況報告を定期的に続けながら、段階的に進捗を見せていく。
APMより先にやること――明日からの最初の一手
APMより先に現状を見えるようにする。この順序を守ることが、結果的に最短ルートです。
「では明日から何をすればいいか」。3段階の順序に沿って、最初の一手を示します。
- 第1段階の一手：社内に散らばるマスター情報の在り処を3つ書き出す。Excelの台帳でも購買記録でも構いません。「どこに何があるか」を付箋1枚に書き出すところから始めてください。それが内製整理のスタートラインです。
- 依頼前の一手：現場に渡す調査票に、事前入力できる項目をすべて埋めてから依頼する。空欄を減らすことが目標です。白紙の調査票を送るのをやめるだけで、現場の回答率と品質が変わります。これは経験上の確信です。
- ツール登録の一手：アプリケーションサービス層から入力を始め、テクノロジー層の把握を最初のマイルストーンに設定する。全層を一度に埋めようとしない。この一点を守るだけで、登録作業の前に立ちはだかる「どこから手をつければいいかわからない」という壁が消えます。
完成形を最初から目指さないこと。依頼する前に自分たちが汗をかくこと。この2つを忘れなければ、APMより先にやるべきことの道筋は必ず開けます。
関連記事：ITアセット台帳の可視化、何から始めるべきか——現場で10年やってわかったこと
あなたの現場では、APMより先に現状の可視化はできていますか？システム棚卸しの段階でどんな壁にぶつかりましたか？ぜひコメントで教えてください。
筆者：EAの中の人｜事業会社の社内IT部門にてエンタープライズアーキテクトとしてEA推進・ITガバナンス・データ活用・AI活用に携わって10年以上。
本記事の内容は個人の見解であり、所属組織を代表するものではありません。
参考文献
- Flexera「Application Portfolio Management (APM) – Definition」※APM定義・失敗要因の参照元
https://www.flexera.com/resources/glossary/what-is-application-portfolio-management - Bizzdesign「Application Portfolio Management: Introduction and Best Practices」※APMベストプラクティスの参照元
https://bizzdesign.com/blog/what-is-application-portfolio-management-amp - Zylo「3 Application Portfolio Management Best Practices」※APM成熟度モデルの参照元
https://zylo.com/blog/application-portfolio-management-best-practices - BlueDolphin「What Is Application Portfolio Management? Definition and Benefits」※TIMEモデル・データガバナンスの参照元
https://bluedolphin.io/blog/what-is-application-portfolio-management-definition-benefits-how-it-works/ - LeanIX「Application Portfolio Management – The Definitive Guide」※データ陳腐化・継続的管理の参照元
https://www.leanix.net/en/wiki/apm/application-portfolio-management
