こんにちは。レッドハットコンサルティングチームの木嶋です。
「アプリケーションモダナイゼーション(以下、モダナイゼーション)」について解説する連載は、とうとう最後の3つの “R” であるRepurchase, Retain, Retire を扱います。 なお、本連載における「6R」の全体像については、第1回の記事でご紹介しています。必要に応じてあわせてご参照ください。
アプリケーションモダナイゼーションというと、システムを作り替える、クラウドへ移す、マイクロサービス化するといった「変える」話に注目が集まりがちです。 しかし、現実のITポートフォリオでは、すべてを同時に変えることはできません。重要なのは、何を変えるかだけでなく、何を標準に寄せ、何を今は維持し、何を止めるかを、ライフサイクルの中で継続的に見直すことです。
本記事では、6Rの中でも見過ごされがちな Repurchase / Retain / Retire を、「変えない」選択肢としてではなく、モダナイズの起点として捉え直します。
- 6Rの罠
- Retain: あえて変えない理由を明確にする
- Repurchase: ランニングコストを低減する
- Retire: 止めるために棚卸しする
- まとめ
- Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート
6Rの罠
このシリーズで今までご紹介してきた “6R” は、 アプリケーションモダナイゼーションの議論で広く使われる整理軸です。
ただし実務で扱う際にはひとつ注意があります。 6Rを、今あるモノリス全体や分散システム全体に対して一括で当てはめると、判断が粗くなりやすいのです。
実際のシステムには、変更頻度が高く開発スピードを求められる領域、慎重な運用が必要な領域、すでにほとんど手を入れない領域が混在しています。 さらに、「アプリケーション共通機能」という名前の下に、現在ならインフラレイヤーや基盤側で担うべき機能まで抱え込んでいることも少なくありません。こうした異なる性質の要素をまとめて評価すると、結論は往々にして Retain に寄ってしまいます。
こうした粗い判断のしわ寄せが、ビジネス部門側が施策を諦めることで吸収することも珍しくありません。 古いシステムであればあるほど、IT側が遅いから諦めた施策がたくさんあるのです。
このような問題を避けるため、6R の判断は、システム全体ではなく、サブドメイン単位あるいはコンポーネント単位で行うべきです。 「サブドメイン」でピンとこない方は、「業務的な意味づけを持つ機能のかたまり」と捉えていただければ、本稿では十分です。
このように評価粒度を下げて考えると、これまで脇役に見えがちだった Repurchase / Retain / Retire は消極策ではなく、モダナイズを進めるための重要な戦略的起点になります。
Retain: あえて変えない理由を明確にする
本連載1回目で、Retainは以下の通りご紹介しました。
現時点では十分に機能しており、他システムと密に連携しているなどの理由から、あえて変更せずに現状維持する選択です。将来的な移行対象として棚上げする場合も含まれます。
Retain は、単に「今は変えない」という結論ではありません。 Retainと判断したものについて重要なのは、定期的に見直すことと、なぜ変えないかを都度確認することです。
6R の判断は、ビジネス状況やシステムを取り巻く制約の変化によって、最適な選択肢が変わり得ます。つまり、一度決めた Retain は永続的な判断ではありません。
実際にお客様のお話を伺うと、Retain が選ばれている理由は大きく2つあります。
- スパゲッティ化して複雑であり、変更リスクが高いため、投資対効果を説明しにくい
- 利用者が少ない、あるいは業務変化が乏しく、投資するメリットが小さい
前者はいわば消極的なRetainです。
本来は変えたい、あるいは変える価値があるかもしれないものの、安全に変える方法が見つかっておらず、結果として Retain になっている状態です。
こうした Retain から脱出するヒントは、この連載の中でも共有してきましたので、ぜひ活用してください。
一方、後者は 積極的な Retain です。
現時点の利用実態や変化の少なさを踏まえたうえで、あえて投資しないと判断しているのであれば、それは十分に戦略的な選択だといえます。
重要なのは、Retain というラベルそのものではなく、なぜそう判断したのかを説明できること、そしてそれが組織のビジネス状況と合致していることです。
Repurchase: ランニングコストを低減する
最近は、AIによるコード生成の登場を受けて、「SaaSの時代は終わるのではないか」といった議論も見かけます。
たしかに「なんでも SaaS にすればいい」という時代は終わったのかもしれませんが、だからといって「なんでも自前で開発すればいい」という話でもないのです。
長年の作り込みによって複雑化した領域ほど、業務上の固有性と、単なる過去の都合による作り込みが混在しています。
例えば実際のシステム調査の現場では、Excel で管理していた時代の業務運用が、そのままシステムのデータモデルに焼き付いているケースをよく目にします。
こうした「Excel 由来データモデル」は、現在の業務要件やシステム実装に必ずしも適しているとは限りません。もともとは、表計算ソフトの表現力や機能制約の中で業務を成立させるための形だったはずだからです。
それにもかかわらず、その構造を前提にビジネスロジックが積み上がり、さらにその非効率を補うための機能が追加されることで、元の業務表現はプラットフォームを変えても踏襲され、結果としてスパゲッティ状態が形成されていきます。
こうした構造に対して有効なのが、Repurchase を通じた Fit to Standard です。
標準機能に寄せていく過程で、本当に必要な業務要件と、過去の運用都合を引きずっただけの作り込みを切り分けやすくなるからです。
ただし、そこには落とし穴があります。
Fit to Standard は、決して平坦な道ではない ということです。
複雑化した業務を標準 に乗せるということは、現在の運用や実装の中に埋もれてしまった業務の存在意義や意図をいったん取り出し、蒸留し、それを標準の中に再構成することを意味します。
ここで安易に機能追加へ逃げると、Repurchase のはずが、結局は新しい土台の上に古い複雑さを載せ替えるだけになってしまいます。
その先にあるのは、アップグレードコストの増加です。
最近のパッケージやSaaSはアップグレード頻度も高く、作り込み部分に対してテストを実施し、壊れた箇所を修正するための時間を毎回十分に確保することは容易ではありません。
その結果、作り込みが多いほどアップグレードコストは積み上がりやすくなります。
Repurchase の成否は、導入時の機能充足率ではなく、将来のアップグレード容易性をどこまで守れるかで決まると言ってもよいでしょう。
もちろん、どれだけ丁寧に見直しを重ねても、パッケージや SaaS だけで必要な機能がすべて充足することは、実際にはほとんどありません。
その場合に重要なのは、不足分を安易に本体へ作り込まないことです。必要な固有機能は、可能な限りパッケージや SaaS の外側に切り出して実装する。その方が、本体の標準性を守りながら、将来の変更自由度も確保できます。
難しそうに見えるマイクロサービス化も、必ずしも最初から大がかりに進める必要はありません。こうした小さな切り出しが、その第一歩になることもあります。
Retire: 止めるために棚卸しする
IT効率化の最前線がITILだった時代に、講演会でこんなエピソードを聞いた記憶があります。
データセンターを使い始めてから数年後、初めてサーバーの棚卸しをしたところ、3分の1 がすでに使われていないサーバーだったというのです。
サーバーは、使っているかどうかにかかわらず、データセンター費用や電気代がかかります。
こうした問題は、物理サーバーに限りません。
仮想化基盤上のシステムやクラウド上のアプリケーションであっても、似たようなことが起こります。
例えば運用や保守にかかる人件費は、ユーザーが使っているかどうかに関わらず発生します。こういったコストは見えにくいまま大きなコストとして積み上がっていきます。
最後にアプリケーション全体の棚卸しをしたのはいつでしょうか。また、その時には必要と言い切れるシステムばかりでしたか？
もちろん、その判断には利用実態や依存関係の確認が欠かせません。
実際には、リタイアを検討すべきほど利用者が少ないにもかかわらず、説明責任や移行先の検討が面倒で、結果として Retain が選ばれてきたシステムもあるはずです。
しかし、確認しないまま残し続けることもまた、ひとつの高コストな意思決定です。
Retire の価値は、単に古いものを減らすことではありません。価値を生んでいない資産に払い続けているコストを止め、その分を本当に必要なモダナイズ投資へ振り向ける、いわば軍資金を確保することにあります。
Retire は、止める判断そのものよりも、「本当に残す理由があるのか」を問い直す行為だと言ってもよいでしょう。
まとめ
Repurchase / Retain / Retire は、それ自体が独立した戦略判断であると同時に、Replatform / Refactor を含むモダナイズ投資にどれだけ健全に資源を振り向けられるかを左右する前提条件でもあります。
残すべきもの、標準に寄せるべきもの、止めるべきものが整理されていなければ、本当に変えるべき領域への予算配分はどうしても偏りやすいのです。
こうした投資配分の健全性は、Repurchase / Retain / Retire の判断を一度行っただけでは担保できません。ビジネス状況や利用実態、依存関係は変化し続けるからです。こうした棚卸しと再評価を継続的に行う仕組みは、すでに「アプリケーションポートフォリオ管理」という名前で体系化されています。どのようにサイクルとして回していくか、といった実践のヒントに関心がある方は、この領域もあわせて参照するとよいでしょう。
一方で、そのサイクルの中でどのような判断を行うべきかは、全体最適を見据えたアーキテクチャ上の意思決定と深く結びついています。どこを標準化し、どこに固有性を残し、将来の変更に耐えられる構造をどう維持するか。これはまさに設計の問題であり、われわれエンジニアにとっても避けて通れないテーマです。
変えることだけでなく、残す、買う、止めるを見直し続けることもまた、アプリケーションモダナイゼーション の重要な実践なのです。
Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート
「技術的負債を解消し、ビジネスの変革を加速する第一歩を踏み出しませんか？ Red Hatが提供するベストプラクティスと実践的なコラボレーションにより、お客様に最適化された『戦略的ロードマップの作成』から、最終的な『全社規模への拡張』までを伴走支援します。」 ご興味のある方は、Red Hat コンサルティングへぜひお問い合わせください。 www.redhat.com
