Modernizationとは何を変えることか

1. AWSへ移したこととModernizationは同じではない

ワークロードをAWSへ移行して正常に稼働させても、それだけでModernizationが完了したとは限りません。

例えば、

オンプレミス
↓
Amazon EC2
↓
業務は正常稼働

していても、

リリースに数週間かかる

定常的な手作業が多い

変更のたびに停止が必要

需要変動への対応に時間がかかる

といった課題が残っている場合があります。

Modernizationでは、AWSへ移ったかではなく、技術や運用の仕組みを変えることでどのBusiness Valueを改善するかを考えます。

2. Modernizationは「新しいAWSサービスを使うこと」ではない

新しいAWSサービスや新しいアーキテクチャを採用しただけでは、Modernizationの成功とは言えません。

例えば、

新しいサービスを3つ導入

しても、

リリース時間
→ 変化なし

障害復旧時間
→ 変化なし

運用工数
→ 変化なし

なら、目的としていた価値を得られていない可能性があります。

逆に、大規模な書き換えを行わなくても、定常運用を削減し、変更を安全に高速化し、必要な容量へ追従しやすくすることでBusiness Valueを改善できる場合があります。

技術変更そのものを成果としないことが重要です。

3. Business Valueから逆算する

Modernizationの出発点は、どの技術を使いたいかではなく、何を改善したいかです。

例えばBusiness Valueとして、新機能を早く提供したい、障害による業務停止を減らしたい、定常運用へ使う時間を減らしたい、需要増加へ早く対応したい、変更によるリスクを減らしたい、といった目的があります。

Business Value
↓
現在それを妨げる要因
↓
変更すべき技術・運用

という順序で具体化します。

4. Technical DebtはBusiness Valueとの関係で扱う

Technical Debtそのものの特定方法は既に確認しているものとします。

Modernizationでは、特定済みのTechnical Debtを「古いから直す」のではなく、何を妨げているかで扱います。

手動リリース工程
↓
リリースまで10日必要
↓
市場要求への対応が遅れる

なら、Technical DebtとBusiness Valueの関係が明確です。

一方、古いコードが存在していても、現在の変更・運用・安全性に具体的な悪影響が確認されていないだけなら、他の課題より優先すべきとは限りません。

Technical Debt
↓
技術面 / 運用面への影響
↓
Business Valueへの影響

をつなげます。

複数のTechnical Debtがある場合も、古さ、コード量、利用年数だけで優先順位を決めるのではなく、Business Valueをどれだけ妨げているかを判断材料にします。

5. Operational OverheadはModernizationの機会を見つける根拠になる

日常的なOperational Overheadも、Modernization候補を見つける材料になります。

毎月40時間
OSパッチ
バックアップ確認
容量変更
定型障害対応

に使っている場合、問題は単に40時間かかっていることだけではありません。

その結果、改善開発へ使える時間が減る、新機能リリースが遅れる、障害原因の恒久対策へ時間を使えないのであれば、Business Valueにも影響しています。

Operational Overhead
↓
奪われている人的キャパシティ
↓
Business Valueへの影響

まで確認します。

6. Managed Serviceは目的ではなく変更手段の1つ

互換性や必須要件を満たすManaged Serviceを利用すると、利用者が直接担う基盤運用の一部を減らせる場合があります。

しかし、Managed Serviceへ移行したこと自体がModernization成功ではありません。

変更前
定常運用 40時間 / 月

変更後
定常運用 10時間 / 月

となり、30時間を製品改善、自動化、信頼性改善へ振り向けられるようになったなら、Modernizationによる効果を説明できます。

Managed ServiceはOperational Overheadを変えるための手段であり、採用そのものがBusiness Valueではありません。

7. Cloud-nativeは特定のAWSサービス名ではなく特性として捉える

Cloud-nativeは、クラウド環境を前提として、俊敏性、拡張性、柔軟性、回復力、頻繁で安全な変更などを実現しやすくするアプローチです。

したがって、Amazon EC2を使っている、または特定のAWSサービスを使っているだけでCloud-nativeかどうかを判断しません。

例えば同じAWS上でも、

構成A

固定容量
手動デプロイ
障害時は人が再起動
大きな単位でしか変更できない

構成と、

構成B

需要へ追従
自動化されたデプロイ
障害時に自動復旧
小さな変更を継続的に提供

する構成では、後者の方がCloud-nativeで重視される特性を強く持っています。

重要なのは、どのサービスを使ったかではなく、どのような変更・拡張・復旧特性をワークロードとして実現したかです。

後続では、このような特性を実現する具体的なモダナイゼーション方法を個別に判断します。

8. Re-architectureはModernization全体の中の1種類の変更である

ModernizationとRe-architectureは同義ではありません。

Modernizationでは、Business Valueを改善するために複数種類の変更を組み合わせることがあります。

データベースの運用方法を変更

リリース工程を自動化

監視と復旧方法を改善

一部のアプリケーション構造を変更

という取り組みが同じModernization計画に含まれることがあります。

この中で、アプリケーションやサービスの構造そのものを変更する取り組みがRe-architectureです。

Modernization
        │
        ├─ プラットフォームの変更
        ├─ 運用方法の変更
        ├─ 自動化
        └─ 必要な範囲のRe-architecture

すべてのModernization施策をRe-architectureへ分類する必要はありません。

9. モダナイゼーション価値仮説を作る

Modernization候補は、次の因果関係で整理できます。

現在の課題
        ↓
Technical Debt /
Operational Overhead
        ↓
変更手段
        ↓
期待する技術・運用上の変化
        ↓
Business Value
        ↓
確認する結果

例えば、

現在
手動リリース工程が多い

↓
変更
リリース工程を改善

↓
期待する効果
本番反映までの時間を短縮

↓
Business Value
市場要求への対応を高速化

↓
確認
変更から本番反映までの日数

という形です。

課題から技術変更で止めず、課題 → 技術変更 → 期待効果 → Business Value → 確認結果までつなげます。

10. Modernizationの成果は導入数では測らない

例えば次の2つを比較します。

案A

AWSサービスを5つ新規導入

リリース速度
変化なし

障害影響
変化なし

運用時間
変化なし

案B

変更したサービスは1つ

定常運用
40時間 → 12時間 / 月

リリース
14日 → 3日

Modernizationでは、単純な変更量やサービス数ではなく、狙ったBusiness Valueが実際に改善したかを確認します。

11. すべてを一度にModernizationする必要はない

Modernizationは一度だけの全面刷新である必要はありません。

最もBusiness Valueを妨げる課題
↓
最初に改善

↓
結果を確認

↓
得られた結果を使って
次の改善候補を判断

という段階的な進め方ができます。

これにより、大規模な変更リスクを抑え、改善効果を早く確認し、実測結果を次の判断へ使うことができます。

例えば3つの改善候補があっても、

A
運用時間を大きく削減できる

B
変更速度を改善できる

C
効果がまだ不明確

なら、必ず3つを同時に実行する必要はありません。

優先度の高い改善を実施し、期待した効果が出たかを確認したうえで、次の改善判断へ進めます。

AWSへの大規模移行でも、まず移行を完了し、その後にModernizationを進める方針が適する場合があります。

Modernizationは1回のイベントではなく、継続的に価値を改善する活動として考えます。

12. Modernization候補の判断表

13. 判断フロー

Business Valueを定義
        │
        ▼
現在それを妨げるものを確認
        │
        ├─ Technical Debt
        │
        └─ Operational Overhead
        │
        ▼
何を変える必要があるか
        │
        ├─ プラットフォーム / Managed Service
        │
        ├─ 運用
        │
        └─ 必要な範囲のRe-architecture
        │
        ▼
必要なCloud-native特性を確認
        │
        ▼
期待する効果を定義
        │
        ▼
測定できる結果へ接続
        │
        ▼
優先順位を決定
        │
        ▼
段階的に実施して結果を確認

中心となる考え方は、新しい技術を導入してからBusiness Valueを期待するのではありません。

Business Value
↓
阻害要因
↓
必要な変更
↓
期待効果
↓
結果を確認

という順序です。