アプリポートフォリオのためのTIMEモデル（許容、投資、移行、排除）

アプリケーションの合理化会議は午前9時に開始した。午前11時までに、チームは対象となる400のアプリケーションのうち12を分類した。その12の分類のうち3つは、すでに異議申し立て、修正、そして再び異議申し立てを受けている。給与計算を実行するCOBOLバッチプログラムは明らかに削除対象ではないが、容​​認対象か投資対象かは不明だ。技術的に不十分であると誰もが認めるレガシー請求システムは明らかに移行対象だが、何に移行するのか、そしてそれに依存する17のプログラムはどうなるのか。会議は正午まで予定されている。正午に、誰かが来週も続けることを提案した。翌月までに、この取り組みは静かに成果を生み出さなくなった。

Gartner TIME モデルは、エンタープライズ IT において最も広く使用されているアプリケーション ポートフォリオ管理フレームワークです。このフレームワークは、ビジネス価値と技術的適合性という 2 つの評価基準を用いて、ポートフォリオ内のすべてのアプリケーションを、「許容」、「投資」、「移行」、「排除」の 4 つの状態のいずれかに分類します。このフレームワークは論理的に妥当で、幅広い適用性を持ち、米国連邦 CIO 協議会のアプリケーション合理化プレイブックで推奨手法として引用されています。しかし、このフレームワークの支持者が言及するものの、ほとんど説明されない理由から、実際には成功よりも失敗することの方が多いのです。それは、分類の妥当性は、その背後にある証拠によって左右されるからです。構造的な証拠、実際の依存関係の数、実際の複雑性の測定、所有者へのインタビューではなく実行トレースから得られる実際のビジネス価値データがなければ、TIME 分類は組織内の政治になってしまいます。配置に関する議論は「移行」と「排除」の段階で始まり、誰かのお気に入りのアプリケーションが対象となり、決して解決することはありません。

モデル：2つの軸、4つの配置

TIMEモデルでは、すべてのアプリケーションを2×2のマトリックス上にプロットします。横軸は技術的適合性、つまりアプリケーションの現在の技術的実装が意図された機能をどの程度サポートしているかを示します。具体的には、アーキテクチャの品質、保守性、統合性、セキュリティ体制、運用信頼性などです。縦軸はビジネス価値、つまりアプリケーションの機能が組織の事業運営、収益創出、規制遵守、または戦略目標にとってどの程度重要であるかを示します。

	高い技術適合性	技術適合度が低い
高いビジネス価値	投資資金提供すべきだ。このアプリケーションは戦略的に重要であり、技術的にも優れている。その優位性を維持するために投資すべきだ。	移住するビジネス上は必要だが、技術が間違っている。機能ではなく、プラットフォームを置き換えるべきだ。
低い事業価値	許容する今はそのままにしておきましょう。アプリケーション自体は健全ですが、追加投資する価値はありません。	なくす廃棄しましょう。価値も品質も低く、保管しておく理由はありません。

そのシンプルさは意図的なものです。TIMEは、詳細な投資計画を作成するためのものではなく、ポートフォリオ内のすべてのアプリケーションに対して明確な方向性を示すためのものです。明確に位置づけられないアプリケーションは、分類が可能になる前にさらなる情報が必要なアプリケーションです。

4象限オペレーティングモデル

TIMEの各処分は単なるラベルではなく、組織が今後どのようにアプリケーションを管理していくかを決定する運用モデルです。

投資：最大限の価値抽出

投資対象アプリケーションは、ポートフォリオの至宝と言えるでしょう。高いビジネス価値と高い技術的適合性を備えているため、新機能の開発、パフォーマンスの最適化、統合の拡大、そして技術の最新性維持に最も積極的に投資する価値があります。一方、技術的な最新性、古いランタイム、時代遅れのセキュリティ体制、蓄積された依存関係といった問題を抱えた投資対象アプリケーションは、気づかれる前に移行段階へと移行してしまうリスクがあります。

Investの運営上のコミットメント：

• 機能開発と技術保守のための専任エンジニアリング能力
• 最優先のセキュリティパッチ適用とコンプライアンスアップデート
• 重要な変更すべてに対する建築審査委員会の対応
• Tier 1レベルでのSLA目標に基づくプロアクティブな監視

移行：プラットフォームを置き換え、機能を維持する

移行対象アプリケーションは、組織が真に必要とするビジネス機能を実行するものですが、既存の技術プラットフォームはもはや適切ではなく、維持管理コストが高すぎ、拡張性が低すぎ、最新の統合環境から孤立しすぎています。ビジネス価値は移行投資を正当化しますが、現状の技術プラットフォームへの継続的な投資は、費用対効果が低いと言えます。

移行方針は、特定の問いに答えるものです。その機能は維持する価値があるか？もしそうであれば、移行します。移行先や移行方法は、TIME分類が決定するものではなく、単に現在のプラットフォームが解決策ではないことを示すものです。

レガシー環境における最も一般的な移行シナリオは、重要なビジネスロジック、複雑な規制計算、独自の価格設定ルール、管轄区域固有の税務ロジックを実装したCOBOLバッチプログラムが、拡張、テスト、統合にコストがかかるプラットフォーム上で稼働している場合です。ロジックはかけがえのないものであり、問​​題はプラットフォームにあります。ロジックを維持しつつ、ビジネスが現在必要とする運用特性を提供する最新のプラットフォームに移行しましょう。

容認：期限付きの意図的な不作為

「容認」は最も誤解されやすい象限です。これは「このアプリケーションは問題ない」という意味ではありません。「このアプリケーションの技術的な品質は、現時点で変更するための投資を正当化するものではなく、また、そのビジネス上の価値も、それを廃止することを正当化するものではない」という意味です。これは、無期限の延期ではなく、一定期間現状維持を受け入れるという意図的な選択なのです。

「許容」とは、永続的な状態ではなく、一定期間保留することを意味します。「許容」象限にあるすべてのアプリケーションには、通常12～18か月という明確なレビュー日と、早期再分類のトリガーとなる定義済みの条件が必要です。例えば、パッチを適用できないセキュリティ脆弱性、プラットフォーム変更を余儀なくされる依存関係の廃止、アプリケーションへの投資に見合うビジネス価値の向上、あるいはその目的をなくすビジネス機能の変更などが挙げられます。

Tolerateを恒久的なものとして扱う組織は、TIMEモデルが防止しようとしていたまさに技術的負債を蓄積してしまう。2019年にTolerateとされたCOBOLプログラムが2026年になってもTolerate象限に残っている場合、7年間もメンテナンスが先送りされたことになり、最終的には何らかの不具合が発生した際の緊急対応、あるいはプラットフォームのサポートが不可能になった際の強制的なMigrateといった形で、メンテナンスが必要になるだろう。

排除：誰もが下す決断だが、誰も実行しない決断

削除は最も単純な分類であり、最も実行頻度の低い処理方法です。このアプリケーションはビジネス価値が低く、技術的な適合性も低いため、維持する理由がありません。廃止しましょう。

実行の失敗は周知の事実である。「削除」リストは熱心に作成されるものの、実際に実行されることはほとんどない。ある大手金融機関が2024年に実施したポートフォリオレビューでは、87件の「削除」候補が挙げられた。しかし18か月後、そのうち71件がまだ稼働していた。分類から廃止までのギャップこそが、合理化プログラムの勢いを失わせる原因なのである。

排除の実行を妨げる3つの具体的な障害：

隠れた依存関係。このアプリケーションは、一見すると独立したアプリケーションであるように見えたため、「削除対象」に分類されました。しかし、分類後に構造分析を行ったところ、他の12個のプログラムが、削除対象候補が処理する出力を生成していること、あるいは3つの外部システムが、文書化されていないファイルインターフェースを介してこのアプリケーションにデータを送信していることが明らかになりました。このアプリケーションは独立したアプリケーションではなく、他のシステムの隠れたインフラストラクチャとして機能しているのです。分類を見直す必要があります。

データ移行の阻害要因。当該アプリケーションには、削除できないデータ、保存期間が義務付けられている規制関連記録、後継システムへ移行する必要のある顧客データ、監査プロセスで毎年照会される過去の取引記録などが含まれている。データ移行はシステム廃止に先立って実施する必要があり、データ移行には費用がかかる。

規制上の義務。一部のアプリケーションは、たとえビジネス価値がゼロになったとしても、規制の枠組みでその機能が必要とされているため、廃止することはできません。四半期ごとの規制提出書類を作成する報告アプリケーションは、ビジネス価値調査には反映されないものの、規制上の価値を持っています。規制上の義務が別のシステムに移行されるまでは、そのアプリケーションは稼働し続けなければなりません。

証拠の問題：構造データなしでTIMEが失敗する理由

TIMEの実装における最も深刻な失敗モードは、Catioのドキュメントで正確に指摘されているとおり、配置に関する議論が「移行」と「削除」の段階で始まり、誰かのお気に入りのアプリケーションが問題となることです。客観的な証拠がなければ、すべての分類は交渉になります。アプリケーションの所有者は「投資」を主張し、ITチームは「移行」を主張し、財務チームは「削除」を望みます。会議は、最も議論の余地が少ない「容認」で終了します。

構造的証拠は、意見を測定に置き換えることで、これらの交渉を解決する。

技術的な適合性評価において重要な証拠は以下のとおりです。

テクニカルフィット指標	ソース	分類を次の方向へ
プログラムあたりの循環的複雑度（平均）	静的コード分析	低い＝フィット感が高い、高い＝フィット感が低い
デッドコードの割合	到達可能性分析	デッドコードが高いほど適合度が低くなる
ファンイン（受信依存関係数）	依存関係のマッピング	高いファンインは排除よりも許容を増加させる
コピーブックの共有範囲	コピー依存性分析	高い共有度＝高い結合度＝低い適合度
最後に意味のある変更があった時点	Git/変更管理ログ	長期間の休止状態は、デッドコードまたは安定性を示している可能性があります。
セキュリティ脆弱性の数	SASTスキャン	カウント数が多いほどフィット感は低くなります

ビジネス価値評価において重要な証拠は以下のとおりです。

ビジネス価値指標	ソース	分類を次の方向へ
期間ごとの取引量	JCL実行ログ、スケジューラレコード	大量生産＝高価値
下流へのファンアウト	依存関係のマッピング	ファンアウトが大きいほど価値が高くなる（多くの企業がそれに依存している）
規制機能フラグ	データ分類、コンプライアンス登録	提示＝他のスコアに関係なく最低値フロア
収益隣接性	請求／収益システムへのデータフロー分析	直接隣接＝より高い値
ユーザー数またはAPI呼び出し数	アクセスログ、ネットワークトラフィック	カウント数が多いほど値が高い

重要な洞察は、従来のCOBOLシステムの場合、これらの指標のほとんどはCMDBエントリ、アプリケーション所有者へのインタビュー、ネットワークトラフィック分析からは得られないということです。これらの指標は、ソースコード、実行ログ、および本番環境で実際に何がいつ実行されるかを記録したJCLジョブスケジュールの構造分析から得られます。

COBOLおよびレガシーシステムに対する技術的適合性の評価

標準的な技術適合性評価基準であるAPI互換性、クラウドネイティブ対応、コンテナ化サポート、マイクロサービスアーキテクチャなどは、COBOLバッチプログラムには無関係です。COBOLプログラムはコンテナ化できないため、クラウドネイティブ基準で評価すると、すべてのレガシープログラムの技術適合性スコアがゼロとなり、組織にとって何の役にも立たない情報しか得られません。

COBOLおよびメインフレームシステムの場合、技術適合スコアにはCOBOL固有の基準が必要です。

複雑性スコア（重み：30%）：プログラムの段落およびセクション全体の平均循環的複雑度。平均CCが10未満のプログラムは管理可能な複雑性を持ち、20を超えるプログラムは構造的に複雑で、保守にコストとリスクが伴います。

保守性スコア（重み：25%）：デッドコードの割合、コピーブックの共有範囲、および重複率を組み合わせたものです。デッドコードが40%、共有コピーブックが15個、かつコードの重複が多いプログラムは、機能的に正しくても保守性は低くなります。

依存関係リスクスコア（重み：20%）：インバウンド依存関係の重要度に応じて重み付けされたファンイン数。ティア1プログラムから50個のインバウンド依存関係を持つプログラムは、依存関係リスクが高く、変更には50個のダウンストリームプログラムの調整が必要となります。

通貨スコア（重み：15%）： COBOL方言とコンパイラバージョンの最新性、JCL構文の最新性、およびデータベースインターフェース（組み込みSQLの古さ、VSAM対DB2、バッチのみ対バッチ＋CICS）。DB2組み込みSQLを使用したCOBOL-85構文で書かれたプログラムは、VSAMのみのファイルアクセスを使用したCOBOL-74で書かれたプログラムよりも最新です。

セキュリティ態勢スコア（重み：10％）：ハードコードされた認証情報の存在、保護されていないファイルアクセス、ファイルステータスチェックの欠如、および動的SQL構築におけるSQLインジェクションの脆弱性。

Technical Fit Score = (100 - complexity_score) × 0.30
                    + maintainability_score × 0.25
                    + (100 - dependency_risk) × 0.20
                    + currency_score × 0.15
                    + security_score × 0.10

Where each component is scored 0-100, with 100 being best.

この採点方式では、定性的な評価ではなく、構造コード分析に基づいて0～100の技術適合スコアが算出されます。機能は同じでも構造特性が異なる2つのアプリケーションは、異なる技術適合スコアとなり、それぞれの維持・拡張に必要な投資額の違いを正確に反映します。

ドリフト問題への対処：保有象限におけるガバナンス

Tolerate（許容）は、明示的なToleateガバナンスなしにTIMEを使用しているすべての組織において、時間の経過とともに負債が蓄積される象限です。そのメカニズムは単純です。アプリケーションは変更する価値がないという理由でToleateに入り、その後、変更が最優先事項にならないため、無期限にToleateにとどまります。

「寛容」というガバナンス規律は、無期限の延期を防ぐ。

条件に基づく再分類のトリガー：

• 30日以内にパッチを適用できないセキュリティ脆弱性が特定されました → 移行または削除を検討してください
• ベンダーが、アプリケーションが依存するプラットフォームコンポーネントのサポート終了を発表 → Migrate のレビュー
• ビジネス価値スコアが閾値を超えた場合（新たな規制要件、ビジネスモデルの変更など）→投資または移行の検討
• 依存関係の解消によりインターフェースの変更が必要になった場合 → 移行または削除の検討
• デッドコード分析により、アプリケーションが実質的に非アクティブであることが判明 → 削除対象として検討

時間ベースのレビュー頻度：

• Tolerateへの申請は、12か月後の審査日をもって受理されます。
• 12か月後の審査において、申請は明示的に再分類されるか、または新たな12か月の日付で明示的に再承認されます。
• 再容認には、状況が変わっていない理由を文書化した根拠書が必要となる。
• 再分類されずに2回以上再承認されたアプリケーションは、アーキテクチャレビュー委員会へのエスカレーションをトリガーします。

Tolerateレジストリ： Tolerateアプリケーションの一覧で、分類日、レビュー日、所有者、および再分類のトリガーとなる条件が記録されています。このレジストリは、年次ポートフォリオレビューだけでなく、すべてのアーキテクチャレビュー委員会でレビューされます。

削除実行可能にする：廃止措置のギャップを埋める

「排除対象と分類された」状態と「廃止措置が完了した」状態の間のギャップこそが、合理化プログラムが停滞する原因である。このギャップを埋めるには、それぞれの排除決定を結論としてではなく、明確な範囲、依存関係、成功基準を持つプロジェクトとして扱う必要がある。

排除実行チェックリスト：

• 依存関係の検証が完了しました。 静的解析により、インバウンドの本番環境への依存関係がゼロであることが確認されました（文書化された依存関係がゼロであるだけでなく、構造的に検証された依存関係もゼロです）。
• データ廃棄計画が承認されました。 規制上のデータ保持要件が特定され、法務およびコンプライアンス部門によってデータ移行またはアーカイブ計画が承認された。
• 下流通知完了： 各消費システムの所有者に通知し、アクティブな依存関係がないことを確認しました。
• 規制上の義務の確認が完了しました。 申請内容によっては、規制当局への提出、監査、またはコンプライアンス要件は発生しません。
• 廃止措置の責任者として割り当てられました: 分類決定だけでなく、廃止措置の実行責任者として指名された個人
• ロールバック計画が定義されました: 廃止措置によって未発見の依存関係が明らかになった場合のサービス復旧手順
• 廃止予定日： ITカレンダー上の具体的な日付。「いずれ着手する」というものではない。

構造分析ゲート：構造分析によって本番実行パスからのインバウンド依存関係がゼロであることが確認されるまで、削除決定は廃止計画に進みません。削除実行失敗の最も一般的な原因は、廃止発表後に依存関係が発見され、ロールバックが強制されることです。発表前に構造的依存関係分析を行うことで、これを防止できます。

TIME再評価サイクル

TIME分類は永続的なものではありません。組織の戦略が進化するにつれて、ビジネス価値は変化します。アプリケーションの保守、拡張、または経年劣化に伴い、技術的な適合性も変化します。このモデルはあくまでスナップショットであり、ポートフォリオには動的な変化が必要です。

年次全面再評価：ポートフォリオ内のすべてのアプリケーションは、現在のビジネス価値と技術的適合性の基準に基づいて評価されます。3年連続で分類が変更されていないアプリケーションについては、アプリケーションが真に安定している（その理由を文書化）か、または評価が実際の変化を捉えていないかのいずれかであるかどうかが個別に検討されます。

イベント発生時の再評価：特定のイベントが発生すると、直ちに再分類の見直しが行われます。

• 合併または買収（新たなポートフォリオの組み合わせ）
• 法令遵守義務に影響を与える規制変更
• 主要プラットフォームのサポート終了のお知らせ（データベース、オペレーティングシステム、ランタイム）
• 事業モデルの大幅な変更（新製品ライン、市場撤退、組織再編など）
• アプリケーションに関連するセキュリティインシデント

変更ログの規律：すべての再分類は、以前の分類、新しい分類、日付、変更の根拠、および承認者とともに記録されます。各アプリケーションの分類履歴は、ポートフォリオが分類されたまま忘れ去られるのではなく、積極的に管理されていることを示す監査証跡となります。

認定条件 SMART TS XL TIME分類の証拠を提供する

TIMEモデルの分類判断は、その根拠となる証拠の質に左右されます。CMDBによるカバレッジ、APIモニタリング、およびドキュメント化されたアーキテクチャを備えた最新のアプリケーションの場合、その証拠は容易に入手できます。しかし、CMDBが不完全で、所有者が退職し、依存関係構造が文書化されていないレガシーCOBOLポートフォリオの場合、証拠はコード自体の構造分析から得る必要があります。

SMART TS XLさん 静的コード分析 COBOLスコアリングに必要な技術的適合性入力値（プログラムごとの循環的複雑度、デッドコードの割合、セキュリティパターン検出結果（ハードコードされた認証情報、保護されていないファイルアクセス）、COBOL方言の最新性）を生成します。これらの指標は、開発者の推定値ではなくソースコードから導き出され、アプリケーションの機能に関する記憶に頼る必要もありません。

アプリケーションの依存関係マッピングは、時期尚早な削除決定を防ぐためのファンイン数と、ビジネス価値スコアリングをサポートするファンアウト数を生成します。本番プログラムから45個のインバウンド依存関係を持つアプリケーションは、所有者がそのビジネス価値をどのように評価したとしても、安全な削除候補とは言えません。依存関係数は、分類の議論を凌駕する構造的な事実です。

レガシーシステムの近代化分析によって、分類を変更するデッドコードインベントリが生成されます。CMDB上ではアクティブなアプリケーションとして表示されるものの、インバウンドの本番環境への依存関係がゼロのプログラムはデッドコード候補であり、ビジネスオーナーが存在すら知らなかった可能性のあるプログラムに対する評価ではなく、構造的な証拠に基づいて「容認」から「排除」に再分類されます。

影響分析機能により、排除実行チェックリストの達成が可能になります。これは、廃止計画を開始する前に、インバウンドの運用依存関係がゼロであることを確認する構造分析です。これは、排除実行で最もよく発生する失敗、つまり発表後に明らかになる未発見の依存関係を防ぐための重要なステップです。

エンタープライズ検索機能により、TIME分類プロセスは再評価サイクル全体を通してクエリ可能になります。例えば、今後30日以内にレビュー予定の「容認」に分類されたすべての申請、廃止予定日が割り当てられていない「排除」に分類されたすべての申請、技術適合スコアが30未満で「投資」に分類されているすべての申請を検索できます。これらのクエリは、TIMEモデルを単なる一度限りの分類作業ではなく、アクティブな管理ツールとして維持するためのガバナンスツールです。

枠組みの良し悪しは、その根拠となる証拠の質によって決まる。

TIMEモデルの2軸構造は正しい。ビジネス価値と技術的適合性は、アプリケーションポートフォリオの意思決定において適切な指標である。4つの選択肢も正しい。問題はフレームワークそのものではなく、組織がそれに基づいて提示するエビデンスにある。

インタビューデータとCMDBの推定値に基づいて構築された分類は、組織内で議論を巻き起こします。構造分析、測定された複雑性、検証された依存関係の数、コードから導き出された技術的適合性に基づいて構築された分類は、正当化可能な決定を生み出します。COBOLプログラムは移行ではなく投資すべきだと主張するアプリケーションオーナーは、構造分析で循環的複雑度が平均35、デッドコードが40%、セキュリティ上の問題が12件あることが示された場合、主張が難しくなります。プログラムを削除できると主張するITチームは、依存関係分析で本番環境への依存関係が45件あることが示された場合、主張が弱くなります。

TIMEモデルは、証拠がそれを裏付ける場合に有効です。アプリケーションポートフォリオの構造分析は、組織が、合理化の意思決定が最も必要でありながら、意思決定を容易にするドキュメントが不足している可能性が高いレガシーアプリケーションに関する証拠を構築する方法です。