アプリケーションの合理化

アプリケーション合理化を進めるための段階的なフレームワーク

Apptio Solution 1 - アプリケーションの合理化 - Apptio

アプリケーションの合理化とは

アプリケーションの合理化とは、組織全体で使用されるソフトウェア アプリケーションをカタログ化し、重複を排除するプロセスです。このプロセスにより、IT 部門は効率を改善し、ポートフォリオの複雑性を解消して、アプリケーション ポートフォリオの総所有コスト (TCO) を削減できます。

適切なフレームワークがあれば、組織は、組織的な政策や不要な縄張り争いに妨げられることなく、アプリケーション合理化イニシアチブを運用できます。主観的な主張ではなく、事実に基づいた対話により、アプリケーション合理化イニシアチブはより良い結果に導かれ、アプリケーション増殖を抑制し、削減できる資金を新たなイノベーションに投入できます。

この記事では、IT アプリケーション合理化のイニシアチブを成功に導く、強力なフレームワークの構築方法について解説します。

アプリケーション合理化が必要となる理由

支出管理やネットワーク保護という企業努力にもかかわらず、IT 組織は困難な闘いを強いられています。

シャドー IT と縦割りの購買傾向により、IT 組織の精査と管理が及ばず、重複した無駄なアプリケーションが増加しています。

M&A

M&A により、買収した企業のアプリケーションとサービスも引き継ぐことになりますが、その多くは買収側の既存資産と重複します。

非常に複雑で無秩序な状態も可視性を狭める原因であり、広大なアプリケーションポート フォリオのどこで重複が発生しているのか突き止めるのは容易ではありません。

過去の取り組みの失敗、アプリケーション合理化とコスト削減がうまく行かなかった経験が、それが原因で新たな最適化計画に積極的に取り組めないこともあります。

総保有コスト (TCO) 計算の複雑性により、アプリケーションの廃止や保持によるコストへの影響がわかりにくくなっています。

ゾンビ アプリ、つまり廃止計画が途中で止まっていたり、正常に完了しなかったために稼働し続けていたりするケースもあります。

アプリケーション合理化の成功を妨げる最大の課題:​

エンゲージメントの欠如

ビジネス パートナーのエンゲージメントが不足している場合、アプリケーション合理化イニシアチブが頓挫する可能性があります。エンゲージメントの鍵となるのは、アプリケーションの総保有コスト (TCO) の事実に基づく対話です。しかし、この TCO の数字についてコンセンサスを確立するのは決して簡単なことではありません。前提条件が単純すぎると、利用部門はこの数字に納得できません。複雑すぎると、データ統合を行うときに数字の精度が低下します。単純すぎず、複雑すぎず、この間で適切なバランスがとれれば、エンゲージメントは向上します。

利用部門のステークホルダー、インフラストラクチャおよびオペレーション部門マネージャーは、ポートフォリオの重要部分に問題があることをすでに把握しています。なぜなら、レガシー システムで稼働している古いアプリケーションが、開発リソースを圧迫し、イノベーションを妨げているからです。まず、そこからスタートしましょう。アプリの TCO イニシアチブでは、エンゲージメントにこだわる必要はありませんが、すでに問題と認識されている部分に対処することを心がけます。

膨大なアプリケーション ポートフォリオ

膨大なアプリケーション ポートフォリオにより、冗長性が失われ、イノベーションに投入できたはずの資金がレガシー アプリに留まってしまいます。成功への近道は、単純にアプリ数を減らすことです。アプリ プール内の絶対数が少なければ、使用量や投資の異常値を特定しやすくなります。さらに、ポートフォリオを縮小すれば、新しいアプリケーションのビジネス価値をより綿密に評価できます。アプリケーション合理化プロセスにより、新たなアプリの正しい評価を促進できます。

冗長なプラットフォーム変更

オンプレミスの永久ライセンスを廃止し、その資金を SaaS フットプリントの拡大に充当するのは、健全な IT 戦略です。しかし、ビジネスへの価値を評価せずに、すべてのアプリを別のプラットフォームに移動するのでは、機会損失につながります。アプリケーションを少しずつ移動すれば、技術的な作業負荷を抑え、ビジネス価値を重視した SaaS ポートフォリオを構築できます。

使用率の低いアプリケーション

新しいアプリケーションを購入するのは簡単ですが、アプリケーション合理化イニシアチブの精神には反します。アプリケーション合理化イニシアチブで成功を収めている組織は、新しいアプリをポートフォリオに追加する前に、まずは既存アプリのビジネス価値を最大限まで高める取り組みを行います。

優れたアプリケーション合理化フレームワークを構築するには

アプリケーション ポートフォリオ全体の評価を実施する

ポートフォリオ評価の基本となるのは、アプリケーション名とオーナーです。アプリケーション合理化イニシアチブは、ポートフォリオの一部を対象とする具体的目標 (2 四半期以内に廃止アプリを削除するなど) を定めれば、効果的に進めることができます。しかし、ポートフォリオ全体のベースライン評価によって、現状のイニシアチブに影響を与える誤ったアプリ設定 (誤ったオーナー、廃止済とアクティブを取り違えた不正確なラベル等)を発見できる可能性があります。さらに、将来的にアプリケーション合理化イニシアチブの適用範囲を広げる際に必要な基盤を確立できます。

利用部門のステークホルダーは、ポートフォリオ分析を支援し、アプリケーション合理化イニシアチブに早い段階から関与します。IT ファイナンスが利用できるデータは、アプリケーション一覧とアプリ – サーバー間マッピング ファイルのみになっている例があります。このデータには、コンテキストと検証が必要です。ソース データが間違っていれば、アプリケーション合理化イニシアチブによる推奨事項は無意味になります。アプリケーション合理化イニシアチブを成功に導くには、検証された正確なデータが必要です。財務部門はデータを所有していないため、インフラ & オペレーション部門がアプリケーション リストのデータを運用データとともに検証する必要があります。

ポートフォリオ評価では、専用のインフラを必要とする古いレガシー システムで実行されているアプリケーションを特定します。このようなメンテナンス費用が継続的にかかるため、イノベーションを促進するための新たな開発コストが確保できなくなります。

アプリケーション評価フレームワーク完了に必要となるタスク:

  • アプリケーションとオーナーの紐付け
  • アプリケーション名とオーナーをインフラ & オペレーション部門データで検証
  • レガシー インフラの支援のアプリへの紐付け

ビジネス価値を定義するのは、アプリケーションが次に該当する場合です:

  • 利用部門への影響と冗長性のニーズについて評価される場合

ビジネス価値の定義

アプリケーション合理化の分析ができていれば、アプリケーション名とそのビジネス価値を明確に区別できるようになります。例えば、SaaS ベースのプロジェクト管理ソフトウェアである Trello について話しましょう。アプリケーション合理化イニシアチブでは、このアプリのビジネス価値を定義する必要があります (Trello は、請負会社プロジェクト管理により、正社員と比較して人件費を 30% 節約します)。この価値の評価により、類似したアプリケーションの機能を評価する基準ができます (Trello の他に、Wrike と Nutcache の余剰ライセンスも保有している。1 つのアプリに集約し、残りは廃止できるのでは)。

余分な機能にみえても健全なビジネス ケースにつながる場合は、合理化の対象にはなりません。例えば、可動時間は、従業員が複数のタイム ゾーンにまたがる組織に影響を与えます。北米の夜間帯は、オーストラリアでは早朝、日本では夕方、フランスでは深夜の時間帯に当たります。組織の全アプリ サーバーを 1 か所に集約してしまうと、インフラ & オペレーション部門によるメンテナンスの時間帯がいずれかの地域のコア ビジネス アワーと重なることになります。この場合は、ビジネス維持にこの機能が必要です。

アプリケーション TCO の計算

アプリケーション TCO では、アプリの支援とデリバリーに必要な全負荷コストを判断する必要があります。これには、総勘定元帳 (GL) のライセンス コストに対応する項目だけでなく、インフラストラクチャおよびオペレーションの間接コストに対応する項目も含まれます。アプリ TCO 分析では、「この数字はどのくらい正確か」という正当化に関する質問が常につきまといます。アプリケーション合理化イニシアチブを成功に導くには、アプリ TCO 分析を継続的な活動にする必要があります。クライアントは、Apptio Cost Transparency を利用して、月次のオペレーションと財務データを統合させ、IT ファイナンスはこのデータをもとにセルフサービス分析を実施できます。

アプリケーション TCO は、コストの見直し、コスト要因の特定、各アプリケーションに関連するプロジェクト支出の分析が必要です。

アプリケーション TCO は、次の場合に制御できます:

  • オペレーションおよび財務データが反復可能なプロセスで更新される場合
  • 直接コストと間接コストを考慮する場合
  • アプリケーション コスト、その要因、関連するプロジェクト支出を特定した場合

ビジネス価値は、次の場合にビジネス機能と一致していると言えます。

  • 組織が企業目標に沿っている
  • ステークホルダーが各々の枠を越えて企業目標を支持している
  • 既存スタッフの再トレーニングが分析内で考慮されている

コストおよびビジネス価値をビジネス機能と一致させる

ビジネス価値とアプリケーションを一致させるには、組織内に抵抗が生じます。アプリケーション コストをビジネス機能別に分割すると、Run-the-Business (RTB) の支出と Grow-the-Business (GTB) 支出への投資内訳が明らかになります。このとき GTB のみが重要な支出だと考えられていると、「IT 部門 vs 利用部門」の対立シナリオが発生する可能性があります。IT 部門の重要な責任範囲には、ビジネス維持/Keep-the-Lights-On (KTLO) 機能を提供することでもあるため、KTLO を単なるイノベーションの阻害要因として軽視すると、変化に対する抵抗が生じます。アプリケーション合理化プロセスの実施時に、IT 支出を企業目標と一致させ、広範なステークホルダー グループの支持を取り付けて、こうした抵抗に備える必要があります。

アプリケーション合理化イニシアチブによる行動喚起 (Call to Action) は、多くの場合追加支出を生み出します。アプリケーション合理化によって、スタッフの再トレーニングが必要になると、導入と実施コストに影響します。必要なリソースの特定、スケジュール確保、ビジネス価値貢献への評価に追える必要があります (例: 再トレーニングはトレーニング リソースにとって妥当か?)。

各アプリケーションの品質分析

アプリケーション ポートフォリオの一片は、定量化できるビジネス価値を追えるものと捉えることができます。このとき、「ビジネス価値をどの程度効果的に提供できるか」という質問が続くことでしょう。アプリケーション合理化イニシアチブであれば、この質問に答えることができます

アプリケーションのビジネス価値効果は、既存のプロセスと機能をどのようにサポートしているかによって判断されます。組織が、既存プロセスをサポートするアプリケーションを選択する場合も、アプリケーションによってプロセスを再定義する場合も (Salesforce SalesCloud のセールス段階など)、主な考慮は「アプリケーションは、ビジネスプロセスをどの程度効果的に自動化しているか」ということになります。自動化は、アプリケーション評価における重要な機能品質です。

アプリケーション合理化イニシアチブでは、従業員が自身の体験に基づいてアプリケーションに重み付けすることができます。アプリケーションが使いづらく、ユーザー体験がよくない場合は、ユーザーのビジネスに取り組む姿勢やエンゲージメントに影響します。

技術的な制限も、IT の目標に基づいて評価する必要があります。ステークホルダーが IaaS および SaaS のクラウド フットプリントを拡大したいと思っても、既存ソリューションはレガシー インフラがサポートされているオンプレミスでしか利用できない場合があります。SaaS 製品を利用できなければ、選択肢が狭まり、時代に取り残されることになります。また、クラウドの選択肢がある場合には詳細な分析が必要となり、選択が難しくなります。そのアプリは、クラウド上でも安全だと言えるでしょうか? おそらくはそうでしょう。IT 戦略をクラウドに集中しすぎていませんか? 執着するあまりに、最新化に多大な投資をしようとしてはいませんか? おそらくそうでしょう。

アプリケーション ポートフォリオを変更すれば、ハードウェアの変更も生じます。クラウド製品に移行すると、オンプレミスのサーバーやストレージを再割り当てできます。しかし、再割り当てをせずにインフラをクラウド移行すると、オンプレミス キャパシティが余剰となり、投じた労力と資金が無駄になります。

アプリケーションの技術的および機能的品質が定義されるのは、次のような場合です:

  • アプリケーションによりビジネス プロセスがどのように自動化されるかを確認できている
  • エンドユーザーのフィードバックが評価に反映されている
  • 技術的制限を特定し、対処している
  • インフラ キャパシティを開放し、他の目的に再割り当てできている

成功メトリックの定義

アプリケーション合理化イニシアチブでは、成功したかどうかを判断できるメトリックが必要です。ビジネス価値の低いアプリケーションは、そのうちポートフォリオから外され、また新しいアプリのビジネス価値が低ければ、調達プロセスを通過できせん。

IT 部門は、アプリケーション合理化イニシアチブの成否を次の指標で示します:

  • 分析の結果から、廃止の合意ができたアプリケーション数
  • 廃止したアプリから回収したソフトウェア ライセンス数
  • 廃止したアプリから回収したサーバーおよびストレージ資産の価値 (実行測定)
  • 経時的なアプリの削減率
  • 重複機能を持つアプリの削減率
  • 本番環境と非本番環境の 1 インスタンス当たりコスト差異の割合
  • TCO 削減率 (価格低下とインフラ削減)
  • オンプレミス アプリの SaaS 移管による価値の変化

アプリケーション合理化イニシアチブでは、既存アプリケーションの支出を特定し、さらに効果的な支出の活用方法について分析します。IT 部門は、利用部門にサービスを提供するために存在し、その視点でアプリケーション ポートフォリオを見直す必要があります。価値、機能的品質と技術的品質、機能の冗長性: これらはテクノロジーではなく、ビジネスに基づく評価です。アプリケーション合理化イニシアチブは、毎月発生する財務データやオペレーション データを取り込み、アプリ TCO に関するセルフサービス分析を行い、ビジネス価値に効果の高いアプリケーション支出を促進できたとき、成功を収めたと言えるのです。

The Definitive Framework for Application Rationalization thumb

アプリケーション合理化のフレームワーク

アプリケーション合理化のフレームワークは、重複するアプリケーションの識別と削除における規範的なガイダンスを提供します。 6 段階のアプローチに従ってアプリを削減し、リターンがより大きい分野に浮いた資金を投入しましょう。