はじめに
Red Hat コンサルタントのフェンです。「アプリケーションモダナイゼーション」に関連する連載の第4回目となります。本連載では「アプリケーションモダナイゼーション(アプモダ)」をテーマに、現場で役立つ実践的な知見をお届けしています。
これまでの話を振り返ってみましょう。
-
第1回:
アプリケーションモダナイゼーションとは、単なる技術の刷新ではなく、アプリケーションの価値を現在のビジネスニーズに適合させる営みであると定義し、その戦略的選択肢として「6R」を紹介しました。
-
第2回:
なぜモダナイゼーションが必要なのか、その根源にある「技術的負債」という深刻な問題に焦点を当てました。システムの脆弱性や非効率な運用が、いかにビジネスの俊敏性を奪っているかを見てきました。
-
第3回:
どこから手をつけるべきか?という問いに対し、その「羅針盤」となる現状分析(アセスメント)の実施方法を解説しました。アセスメントによって、ITポートフォリオの健康状態を客観的に診断し、勘や声の大きさではなく、データに基づいた意思決定の土台を築くことができます。
しかし、羅針盤が指し示す方向が分かっても、それだけでは航海には出られません。診断結果を手に、「何が問題かは分かったが、具体的にどう治せばいいのか分からない」という「迷い」に陥ってしまうケースは後を絶ちません。
本記事は、アセスメントという羅針盤で得たデータを、実行可能な「海図」、すなわち戦略的なロードマップへと落とし込むためのナビゲーターズガイドです。このロードマップ策定の核心は、ポートフォリオ内の各アプリケーションに対し、Red Hatが提唱する6つの戦略的選択肢 (Retire, Retain, Rehost, Replatform, Refactor, Repurchase) のいずれかを合理的に割り当てるプロセスです。この海図は、単に進むべき航路を示すだけでなく、目的地(目標)を定義し、航海の各段階を詳述し、そして船員とその支援者(ステークホルダー)全員に、この旅の価値を納得してもらうための強力なコミュニケーションツールとなります。
そして、今回はモダナイゼーションの「目標設定とロードマップ策定 – ゴールの明確化と現実的な計画」を紹介したいと思います。
1. 目標設定:モダナイゼーションの「北極星」を定義する
あらゆる計画の第一歩は、「成功とは何か」を定義することです。「システムを改善する」「技術的負債を解消する」「コストを削減する」といった曖昧な目標は、プロジェクトの漂流、予算超過、そして価値欠如を招く恐れがあります。前回のステップで得たアセスメント結果こそが、具体的で意味のある目標を練り上げるための材料となります。
明確な目標設定のためのSMART原則
ここで役立つのが、効果的な目標設定のフレームワークとして広く知られる「SMART」原則です。各目標は、特定の6R戦略と密接に関連しているべきです。以下に、SMART原則の各要素と、6R戦略を意識した具体例を示します。
|
SMART要素 |
説明 |
具体例 |
|
Specific (具体的) |
誰が読んでも同じように理解できるほど、具体的に設定します。「5W1H」を意識することで、目標はより明確になります。 |
オンプレミスで稼働するJavaベースのモノリシックな「顧客管理システム」の「顧客情報参照API」を、コンテナ基盤上で稼働するマイクロサービスとしてリファクタリング(Refactor)する。 |
|
Measurable (測定可能) |
成果を客観的に評価できる、定量的な指標を定義します。これにより、成功が主観的な「感想」ではなく、客観的な「事実」として測定可能になります。 |
「在庫管理システム」のデータベースをオンプレミスからクラウドのマネージドDBサービスにリプラットフォーム(Replatform)することで、インフラ運用コストを月額50万円から30万円以下に、40%削減する。 |
|
Achievable (達成可能) |
現在のリソース(人材、スキル、予算、時間など)の制約を考慮し、現実的に達成できる目標を設定します。主要なステークホルダーからの合意も不可欠です。 |
「蓄積用レポートサーバー」はOSサポート切れのリスクを抱えている。アプリケーション改修は不要なため、今四半期末までにOpenShift Virtualization上のRHEL仮想マシンへリホスト(Rehost)し、セキュリティリスクを即時解消する。 |
|
Relevant (関連性) |
モダナイゼーションを単なる技術刷新で終わらせず、組織全体のビジネス戦略と連携させます。なぜその取り組みがビジネスにとって重要なのかを明確にします。 |
中期経営計画にある「ECサイトにおけるパーソナライズ機能の強化」を達成するため、機能追加を迅速に行えるアーキテクチャが必要である。その実現手段として、商品レコメンド機能をマイクロサービスとして切り出す(Refactor)。 |
|
Time-bound (期限) |
すべての目標には期限が必要です。「いつまでに」を明確にすることで、プロジェクトに計画性が生まれます。長期目標の場合は、中間マイルストーンを設定することが重要です。 |
現行の人事管理システムを、本会計年度末(3月31日)までにSaaSソリューションへ移行(Repurchase)を完了させる。これにより、次年度からの保守費用を90%削減する。 |
2. ロードマップの策定:目的地までの現実的な航路を描く
ロードマップは、単なるプロジェクトのスケジュール表やガントチャートではありません。それは、「いつ、何を、どのように」を可視化し、価値が段階的に提供される物語を伝える、戦略的なコミュニケーションツールとして捉える必要があります。
ロードマップ策定するには、様々なアプローチが存在しますが、以下では2つの例を説明します。
例1: 段階的移行のロードマップ
段階的なモダナイゼーション戦略の代表例が「ストラングラーフィグ・パターン」です。ストラングラーフィグ・パターンは、既存の古いシステム(レガシーシステム)を一度に全て作り替えるのではなく、新しい機能を段階的に追加・移行し、最終的に古いシステムを「絞め殺す(strangle)」ように置き換えていく手法です。
仕組みは以下の通りです:
- 継ぎ目(Seam)の特定: モノリスの中から、明確に分離可能な機能(例:商品検索機能)を見つけます。
- 新サービスの構築: その機能を再現する、モダンな新しいマイクロサービスを構築します。
- ファサード(Proxy)の導入: モノリスの前に、リクエストを振り分ける層を設置します。最初はすべてのトラフィックを古いシステムに流します。
- リダイレクト(strangle): ファサードの設定を変更し、特定の機能(例:検索クエリ)へのトラフィックだけを新しいマイクロサービスに振り向けます。残りのトラフィックは依然としてモノリスに向かいます。
- 繰り返し: このプロセスを機能ごとに繰り返し、古いモノリスが担う役割がなくなるまで徐々に「絞め殺し」、安全に停止・廃止します。
このアプローチのメリット・デメリットは以下の通りです:
|
メリット 👍 |
デメリット 👎 |
|
リスクを大幅に低減できる |
移行期間中、新旧システムが共存し構成が複雑になる |
|
ダウンタイムを最小限に抑えられる |
ストラングラー・ファサードの設計・実装に手間がかかる |
|
新しい価値を継続的に提供できる |
新旧システム間でデータの一貫性を保つのが難しい場合がある |
|
途中で計画の修正や技術の見直しが容易 |
モダナイゼーションが長期にわたる可能性ある |
例2: アジャイル・ロードマップ
未来は不確実性があり、ビジネスの優先順位も変化します。そのため、厳格な日付ベースのタイムラインよりも、「Now-Next-Later」のような柔軟なアジャイル・ロードマップ形式を推奨します。
- Now (現在): チームが今四半期に具体的に取り組んでいること。確度が高く、詳細なユーザーストーリーが存在します。
- Next (次): 次の1〜2四半期で計画していること。確度は中程度で、主要な機能やエピックが定義されています。
- Later (将来): 長期的に視野に入れていること。確度は低く、広範な戦略的なテーマやアイデアのレベルです。
以下のサンプルは、時間軸、戦略テーマ、6Rの選択、そしてKPIを一つの分かりやすい成果物に統合したもので、皆さんの計画策定の出発点として活用できます。
|
時間軸 |
戦略テーマ |
取り組み(アプリケーション/モジュール) |
6R戦略 |
追跡すべき主要KPI |
|
Now (Q1-Q2) |
インフラリスクの低減とコスト最適化 |
顧客管理システム (CRM) |
Rehost |
インフラTCOを20%削減 OSサポート切れリスクの解消 |
|
開発者体験の向上 |
請求処理バッチ (Billing Batch) |
Replatform |
バッチ処理時間を50%短縮 手動デプロイ作業の撤廃 |
|
|
Next (Q3-Q4) |
市場投入までの時間短縮 |
商品検索機能 (Product Search) |
Refactor |
新検索機能のリリースサイクルを4週→1週に短縮 検索応答速度を30%改善 |
|
不要資産の整理 |
旧営業支援ツール (Old Sales Tool) |
Retire |
年間ライセンス費用1,000万円を削減 |
|
|
Later (3年後) |
新規ビジネスモデルの実現 |
課金・決済モジュール (Payment Module) |
Refactor |
新規サブスクリプションサービスの立ち上げ 決済APIの外部提供 |
|
コモディティ機能のSaaS化 |
人事管理システム (HR System) |
Repurchase |
保守運用工数を90%削減 |
3. 合意形成:プロジェクトを推進する「追い風」を得る
どんなに完璧な計画も、組織の支持を得られなければ絵に描いた餅です。合意形成は、一度きりの「承認」プロセスではなく、継続的なコミュニケーション、交渉、そして調整のプロセスです。
以下は合意を得るためのポイントを2つ紹介します。
ポイント1: 対象者に合わせて伝えるメッセージを仕立てる
ここで重要なのは、コミュニケーションを一種の製品開発サイクルのように捉えることです。モダナイゼーション計画が「製品」であり、各ステークホルダーは異なる「顧客ペルソナ」です。画一的なプレゼンテーションは失敗します。それぞれのペルソナのニーズ、懸念、動機に響くように「マーケティングメッセージ」を仕立てる必要があります。
|
合意の対象者 |
彼らの言語 |
あなたのメッセージ |
|
経営層・事業部門リーダー |
ROI, TCO, リスク削減, 競争優位性, 収益成長。 |
「これはITプロジェクトではなく、ビジネス投資です。X円を投資することで、運用リスクをY%削減し、Z円の新規収益を生むと予測される新サービスの立ち上げを可能にします。3年間で150%のROIを見込んでいます。こちらが、その価値を段階的に提供していくためのロードマップです。」セクション2で解説した「価値の連鎖」を用いて、この物語を構築します。 |
|
関連業務部門 (営業、マーケティング、運用など) |
「私の仕事はどう楽になるのか?」「チームの業務は混乱しないか?」「ずっと要望していたあの機能はいつ入るのか?」 |
「遅くて使いにくいCRMへのご不満は理解しています。計画のフェーズ1では、皆さんが求めていた新しいレポート機能を搭載した、より高速で信頼性の高いシステムを第3四半期までに提供します。移行がスムーズに進むよう、皆さんのチームと緊密に連携します。」計画を彼らの日々のペインポイントや業務目標に直接結びつけます。 |
|
IT部門・開発/運用エンジニア |
技術的負債, 運用負荷, 自動化, モダンなツール, CI/CD, 燃え尽き症候群。 |
「この計画は、深夜の障害対応や苦痛なデプロイ作業の原因となっている技術的負債に直接取り組みます。ロードマップにある請求バッチのReplatformにより、手動のデプロイプロセスを自動化します。検索機能のRefactorにより、スパゲッティコードを解消し、モダンなCI/CDパイプラインを導入することで、安全かつ迅速に機能を出荷できるようになります。」 |
ポイント2: トレードオフに備える
異なる部門は、しばしば相反する優先順位を持っています。営業は機能Aを、マーケティングは機能Bを、そしてIT部門は基盤が崩壊寸前だと訴えます。ここでプロジェクトリーダーが陥りがちな過ちは、全員を喜ばせようとして優先順位のない計画を作ること、あるいは「声の大きい部門」に屈することです。
そのため、あなたの役割は、優先順位を決定することではなく、データに基づいた論理的なトレードオフを促進することです。
- 共通のゴールを再確認する: 会議の冒頭で、合意済みの最上位ビジネス目標(例:「今年の最優先目標は顧客維持率を10%向上させることです」)を改めて共有します。
- 選択肢を可視化する: 競合する要望(機能A, 機能B, 基盤改修)をホワイトボードに書き出します。
- 客観的なデータを用いる: 各選択肢について、現状分析(アセスメント)で得たデータを提示します。「機能Aはユーザーの5%が抱える課題に対応します。機能Bはマーケティングの新規キャンペーンに必要です。一方、基盤改修はアセスメントで特定された最重要セキュリティリスクに対応するものであり、そもそも新しい機能を安定して開発するための前提条件です。」
- トレードオフを提案: 「顧客維持率の向上という最優先目標と、我々の限られたリソースを考えた場合、これらのうちどれが今、その目標に最も大きなインパクトを与えますか?」と問いかけます。これにより、会話の焦点が「私が欲しいもの」から「ビジネスが必要とするもの」へとシフトします。ロードマップとKPIが、交渉のための中立的な土俵となるのです。
まとめ:実行可能な計画こそが、変革の第一歩
実行可能な計画は、以下の3つの柱の上に成り立っています。
- 目標設定: 何を達成しようとしているのか、そしてそれをビジネスが理解できる言葉でどう測定するのかを知る必要があります。
- ロードマップ: リスクを管理しながら段階的に価値を提供する、現実的なアプローチに基づく計画が必要です。
- 合意形成: それぞれに最適化されたコミュニケーションと、説得力のある客観的なデータを通じて、幅広い組織の支持を得る必要があります。
このロードマップは、一度作って終わりではありません。(1)ビジネス環境の変化、(2)新しいテクノロジーの登場、そして(3)アプリケーション自体のライフサイクルに応じて、最適な戦略は常に変化します。また、(4)チームの成長につれて、四半期ごとに見直され、調整されるべき「生きた計画書」です。(特にアジャイル・ロードマップの形式は、まさにこの適応性のために設計されています。)
次回は、6Rの実践に移るため、Replatformにフォーカスし、「Replatformで変わる開発と運用体験」について、さらに深く掘り下げていく予定です。
コメント