Red Hat コンサルタントのフェンです。
「アプリケーションモダナイゼーション」に関連する連載の第3回目となります。
本連載では「アプリケーションモダナイゼーション（アプモダ）」をテーマに、現場で役立つ実践的な知見をお届けしています。第１回ではモダナイゼーションの定義と「6R」という主要なアプローチを、第２回ではその背景にある「技術的負債」の深刻さについて掘り下げました。
そして、今回はモダナイゼーションの「最初の一歩：現状分析（アセスメント）」を紹介したいと思います。
- はじめに
- 1. なぜアセスメントが羅針盤となるのか？
- 2. 何を評価するのか？：4つの評価領域
- 3. どのような観点で見るのか？：4つの評価軸
- 4. どうやって評価するのか？：定性と定量の評価
- 5. 評価結果をどう活かすか？：優先順位付け
- まとめ
はじめに
多くの企業が「このままではいけない」という危機感を共有し、変革の必要性を感じています。しかし、その一方で、「では、膨大なシステム群のどこから、何から手をつければいいのか？」という問いの前で立ち尽くしてしまう、いわゆる「現状麻痺」の状態に陥るケースが後を絶ちません。「この帳票のレイアウトをちょっと変えるだけで1ヶ月かかる」という現場の悲鳴は、問題の氷山の一角に過ぎません。その根本原因はどこにあるのでしょうか？どのシステムを最初に手術台に乗せるべきなのでしょうか？
この問いに答えるための唯一の、そして重要な活動が、今回ご紹介する「現状分析（アセスメント）」です。アセスメントとは、モダナイゼーションという先の見えない航海における「羅針盤」であり「海図」です。勘や口コミ、あるいは「声の大きい部門」の意見に流されることなく、データに基づいて自社のIT資産の「健康状態」を客観的に診断し、進むべき航路を定めるための戦略的なプロセスです。
本記事では、このアセスメントをどのように進めていけばよいのか、その重要性から具体的な手法、そして評価結果を戦略にする方法までを解説していきます。この記事を読み終える頃には、皆さんの組織でアセスメントを実施するための具体的なイメージと、次の一歩を踏み出すための確信が持てるはずです。
1. なぜアセスメントが羅針盤となるのか？
モダナイゼーションのプロジェクトにおいて、アセスメントは単なる「資産の棚卸し」ではありません。それは、企業のIT戦略そのものの妥当性を問い直し、未来への投資対効果を最大化するための、戦略的な診断プロセスです。第2回の記事で見たように、多くのシステムは長年の運用を経て「ブラックボックス化」し、「属人化」が進んでいます。このような不確実性の高い状況で、適切なアセスメントを経ずにモダナイゼーションに着手することは、羅針盤を持たずに荒波に乗り出すようなものです。
もし、この重要なステップを省略したり、簡易的に済ませてしまったりすると、モダナイゼーションの実施段階で以下のリスクに直面します。
- 予算の誤配分: ビジネス上の価値が低いアプリケーションの延命に多額の予算を投じてしまう。
- 的外れな解決策: 例えば、根本的な問題が複雑なアーキテクチャにあるにもかかわらず、表層的なインフラ移行（Rehost）に終始してしまい、本質的な課題解決に至らない。
- 新たな技術的負債の産出: チームのスキルセットや組織のプロセスに合わない最新技術を拙速に導入した結果、逆に開発・運用が複雑化し、新たな「レガシーシステム」を生み出してしまう。
- プロジェクトの失敗: 期待されたROI（投資対効果）を達成できず、ビジネス部門からの信頼を失い、将来のIT投資そのものが停滞する。
これを避けるためのアセスメントは、人間ドックに例えることができます。いきなり過酷なトレーニングを始める前に、まずは健康診断で自身の体力や課題を正確に把握するように、モダナイゼーションもまずは自社のIT資産の「健康状態」を客観的に診断することから始まります。実際、多くの先進的な取り組みでは、アセスメントがモダナイゼーションの「出発点」として位置づけられています。
さらに、アセスメントの価値は、最終的に得られるデータやレポートだけに留まりません。そのアセスメント活動自体が、組織にとって重要な副次的効果をもたらします。これまでサイロ化しがちだったIT部門とビジネス部門が、アセスメントという共通の目的で会話をせざるを得なくなるのです。アセスメントでは、アプリケーションのビジネス価値を評価するために、ビジネスオーナーへのヒアリングやワークショップが不可欠です。この過程で、IT部門はビジネスの優先順位や現場のペインポイントを深く理解し、ビジネス部門はシステムの技術的な制約やリスク（IT部門がなぜ予算を要求するのかの背景）を学びます。このように、アセスメントは、IT部門の独走ではなく、「ビジネスとITの連携」を自然に生み出し、この成功体験は組織変革や、持続可能な組織に進化するための触媒となると考えられます。
2. 何を評価するのか？：4つの評価領域
効果的なアセスメントは、単にアプリケーションのコードをマイグレーションツールや、静的分析などにかけるだけでは不十分です。アプリケーションを取り巻く環境全体、すなわち、技術と人が織りなす「複合体」として捉え、包括的に評価する必要があります。この「複合体」は大きく4つの領域に分けて評価できます。
表1: 4つの評価領域
|
領域 |
概要 |
主な評価項目 |
|
アプリ |
アセスメントの中核となるソフトウェア資産そのもの。組織内の全アプリケーションのインベントリ作成が第一歩。 |
プログラミング言語、フレームワーク、データベース管理システム、サードパーティ製ライブラリ、ソースコードの管理方法、設計書の最新状態、アプリケーション間の連携・依存関係。 |
|
インフラ |
アプリケーションが稼働する土台となるプラットフォーム。インフラ自体が変化の足かせとなるケースも。 |
物理サーバーや仮想サーバーの老朽化度、OSやミドルウェアのバージョンとサポート期限、現在のクラウド利用状況、ネットワークアーキテクチャ、拡張性（スケーラビリティ）の限界。 |
|
組織 |
システムを開発・運用・保守する「人」と「チーム」に関する領域。技術的問題の根源が組織構造やスキルセットにあることも。 |
チームの構成（サイロかクロスファンクショナルか）、保有技術スキルセット（レガシー技術、クラウドネイティブ技術）、知識の分布状況（属人化のリスク）、変化に対する組織文化や部門間協力体制。 |
|
プロセス |
ソフトウェアを構築し、展開し、運用監視するための一連のワークフロー。非効率なプロセスは開発リードタイム増大や品質低下の直接原因となる。 |
開発手法（ウォーターフォールかアジャイルか）、CI/CDの自動化成熟度、テストプラクティス（手作業での回帰テストの有無など）、リリース頻度、システムの監視や障害対応の仕組み。 |
これら4つの評価領域は、独立しているわけではなく、密接に絡み合っています。例えば、技術的負債は、これら複数の領域にまたがって、まるでクモの巣のように張り巡らされています。巨大で複雑なモノリシックアプリケーション（アプリケーション領域の問題）は、変更が困難なため、長年アップデートされずに放置されがちです。その結果、サポート切れの古いOSが稼働する老朽化した物理サーバー上で動き続けることになります（インフラ領域の問題）。その古い技術を扱えるのは、社内でもごく一部のベテランエンジニアのみとなり、深刻な「属人化」を引き起こします（組織領域の問題）。そして、どんな些細な変更もリスクが高く、影響範囲の特定が困難なため、リリース前には膨大な手作業でのテストが必要となり、年に数回しかリリースできない、という状況に陥ります（プロセス領域の問題）。
このように、ある領域で見つかった一つの問題は、他の領域における問題の兆候でもあります。良いアセスメントとは、単に各領域の問題点をリストアップするだけでなく、これらの因果関係を解き明かし、課題の全体像を体系的に描き出すことです。このシステム全体への深い洞察こそが、場当たり的な技術修正ではなく、真に効果的なモダナイゼーション戦略を立案するための鍵となるのです。
3. どのような観点で見るのか？：4つの評価軸
評価対象となる4つの評価領域を特定したら、次はその「健康状態」を測るための統一された物差し、すなわち「評価軸」を定義する必要があります。この評価軸を定めることで、ポートフォリオ内の多種多様なアプリケーションを客観的に比較し、戦略的な意思決定を下すことが可能になります。ここで紹介する評価軸は、後述するGartnerのTIMEモデルのようなポートフォリオ分析フレームワークの基礎となる、極めて重要な要素です。
ここでは、特に重要となる4つの評価軸を、その評価項目と戦略的な意味合いと共に整理します。
表2: 4つの評価軸
|
評価軸 |
主な評価項目 |
なぜ重要なのか？ |
|
ビジネス価値 |
|
投資の優先順位を決定する上で最も重要な指標です。この価値を維持・向上させることがモダナイゼーションの最終目的であり、すべての判断の起点となります。 |
|
技術的健全性 |
|
システムの「柔軟性」、「疎結合」に直結する指標です。健全性が低い、すなわち技術的負債が溜まったシステムは、改修コストとリードタイムを増大させ、ビジネスの俊敏性を著しく阻害します。 |
|
リスク |
|
事業継続性を脅かす潜在的なリスクを特定します。放置されたリスクは、ある日突然、ビジネス価値損失や顧客信用失墜といった形でビジネスに壊滅的なインパクトをもたらす可能性があります。 |
|
運用コスト |
|
IT予算の圧迫要因を可視化します。コスト削減はモダナイゼーションの主要な動機の一つであり、投資対効果（ROI）を算出する上での基礎データとなります。 |
これらの評価軸を用いて各アプリケーションをスコアリングすることで、組織のITポートフォリオ全体を俯瞰的に、そして定量的に把握することが可能になります。
4. どうやって評価するのか？：定性と定量の評価
評価軸が定まったら、次はいよいよ具体的なデータ収集のフェーズです。信頼性の高いアセスメントを実現するためには、定性的なアプローチと定量的なアプローチを組み合わせた情報収集が不可欠です。
表3: 定性・定量の評価
|
|
目的 |
主な手法 |
|
定性的評価 |
ツールでは見えない「生きた情報」の収集。ドキュメント化されていない暗黙知、ビジネスプロセスにおける重要性、過去の改修経緯、開発者・運用者のペインポイントなどを引き出す。特に「ビジネス価値」の正確な測定に不可欠。 |
|
|
定量的評価 |
人の主観や記憶だけでなく、客観的なデータで裏付けを取る。自動化ツールを活用し、アプリケーションのソースコードやバイナリ、インフラの構成情報を大規模かつ効率的に分析。「技術的健全性」や「リスク」といった評価軸を客観的なデータに基づいて評価する。 |
|
補足: 定性的評価と定量的評価は互いに補完し合い、その結果を突き合わせることで、より深く、確かな洞察を得ることができます。これにより、定量的データが示す「What（何が起きているか）」と、定性的情報が示す「So What（だから何なのか）」を往復し、アセスメントの精度を向上させます。
市場には様々なアセスメントツールが存在しますが、私たちRed Hatが提供するツール「Red Hat Migration Toolkit for Applications (MTA) 」の詳細情報は過去のブログをご参考ください。
- Migration Toolkit for Applicationsを使って組織のシステムのクラウドへの移行を促進させる 1.概要編
- Migration Toolkit for Applicationsを使って組織のシステムのクラウドへの移行を促進させる 2.インストール編
- Migration Toolkit for Applicationsを使って組織のシステムのクラウドへの移行を促進させる 3. 使用(アセスメント)編
- 【令和6年最新版】JBoss EAP 7.4からJBoss EAP 8.0への移行
5. 評価結果をどう活かすか？：優先順位付け
さて、アセスメントによって情報が集まりました。しかし、情報はそれだけでは価値を生みません。次に必要なのは、このデータを意思決定に繋げるための「集約」と「可視化」です。ここで活躍するのが、アプリケーションポートフォリオ管理（APM: Application Portfolio Management）の枠組みです。「APM」という大きな枠組みの中で、具体的な手法として、業界標準として広く認知されている「GartnerのTIMEモデル」を紹介します。GartnerのTIMEモデルはアプリケーション単体の評価ではなく、ビジネスプロセス全体との整合性からIT投資の優先順位を決める、よりトップダウンで戦略的なアプローチです。
Gartner TIMEモデルの紹介
TIMEモデルは下図のように、「ビジネス価値（Functional Fit）」と「技術的健全性（Technical Fit）」の2つの軸を用いて、アプリケーションを分類します。
- 縦軸 - ビジネス価値 (Business Value)
そのアプリケーションがどれだけビジネスに貢献しているかを示します。- 高: 企業の収益に直結する、競争優位性を生み出す、基幹業務に不可欠など。
- 低: 利用者が少ない、代替手段がある、ビジネス戦略との関連性が薄いなど。
- 横軸 - 技術的適合性 (Technical Fit)
そのアプリケーションが、企業の目指すITアーキテクチャや技術標準にどれだけ適合しているかを示します。- 高: モダンな技術で作られている、保守性が高い、セキュリティリスクが低い、他システムと連携しやすいなど。
- 低: 古い技術（レガシー）で作られている、保守できる人材がいない、セキュリティリスクが高いなど。
これにより、各アプリケーションは以下の4つの象限のいずれかに分類され、それぞれ取るべき戦略が明確になります。
表4: TIMEモデルの象限
|
象限 |
特徴 |
方針 |
|
Tolerate |
技術的健全性は高いが、ビジネス価値は低いアプリケーション群。安定稼働しており、手もかからないが、戦略的な重要性は低い。 |
積極的な投資は行わず、現状を維持する。リソースは他のより価値の高い領域に集中させる。 |
|
Invest |
技術的健全性、ビジネス価値ともに高いアプリケーション群。組織の「スター選手」であり、競争力の源泉。 |
さらなる価値向上のため、機能強化やパフォーマンス改善に積極的に投資する。 |
|
Migrate |
ビジネス価値は高いが、技術的健全性が低いアプリケーション群。ビジネスに不可欠だが、技術的負債の塊でリスクも高い「問題児」。 |
ビジネス価値を維持・向上させつつ、技術的な問題を解消するため、モダナイゼーションを積極的に検討する。 |
|
Eliminate |
技術的健全性、ビジネス価値ともに低いアプリケーション群。もはや組織のお荷物であり、維持しているだけでコストがかかる。 |
リソースを解放するため、計画的に廃止・削除する。 |
仕上げ：TIMEモデルと6Rアプローチの連携
このTIMEモデルによる戦略的な分類（何をすべきか）と、本連載の第1回でご紹介した具体的なモダナイゼーションアプローチである「6R」（どうやるか）を結びつけることで、アセスメントから実行計画までの一貫したストーリーが完成します。これは、モダナイゼーション戦略を策定する上で重要な検討プロセスです。
以下の表は、TIMEの各象限に対して、どのような6Rアプローチが対応するのかを整理した一例です。これで、皆さんの組織がモダナイゼーションの具体的なアクションを意思決定の参考になればと考えています。
表5: TIMEモデルと6Rアプローチの戦略
|
象限 |
特徴と戦略 |
対応する6Rアプローチの提案 |
|
Tolerate |
安定稼働しているため、積極的な投資は行わない。現状を維持し、リソースを他に集中させる。 |
|
|
Invest |
さらなる価値向上のため、機能強化やクラウドネイティブ化を推進する。 |
|
|
Migrate |
ビジネス価値を維持しつつ、技術的負債とリスクを解消する。最も多様な選択肢が存在する。 |
|
|
Eliminate |
組織にとってお荷物。リソースを解放するため、計画的に廃止・削除する。 |
|
このマトリックスを活用することで、「どのアプリケーションに」「どのようなアプローチで」モダナイゼーションを適用すべきか、また優先順位が明確になり、モダナイゼーションのロードマップを策定することが可能になります。
まとめ
アプリケーションモダナイゼーションは、単なるコーディング作業ではなく、現状分析（アセスメント）から始まる問いの旅です。本記事で述べたように、成功への羅針盤となるのは、アプリケーション、インフラ、組織、プロセスの4つの領域を、ビジネス価値、技術的健全性、リスク、コストの4つの視点から評価することです。
このような現状分析により、IT資産の実態が明らかになり、勘や経験則に頼っていた場当たり的な意思決定が、事実情報に基づいた戦略的な投資判断へと進化します。その過程で、ITとビジネス間の対話が促進され、組織全体の方向性が一致するという価値が生まれます。
また、現状分析を一過性のイベントで終わらせないことも重要です。ビジネス環境も技術も絶えず変化するため、アセスメントとポートフォリオ評価は、年次や半期ごとのサイクルで継続的に見直し、IT資産が常にビジネス目標に最適化された状態を維持する「規律」として組織に定着させるべきです。
これで、どこから手をつけるべきか、そのための「地図」の入手方法が分かりました。しかし、地図があっても、実際に旅を進めるには具体的な旅程計画と、共に旅をする仲間からの協力が不可欠です。
次回は、このアセスメント結果という地図を基に、具体的なモダナイゼーションロードマップの策定方法について、さらに深く掘りしていきます。
