翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# ステップ 1. アプリケーションの評価
<a name="step1"></a>

このフェーズの目標は以下のとおりです。
+ アプリケーションの状況を十分に理解し、最新のデータプラットフォーム向けにアプリケーションを準備することで、ビジネスに影響を与えずに価値実現までの時間を短縮し、モダナイズ、最適化、スケーリングを行うことができます。
+ アプリケーションランドスケープのプロファイルを作成して、変更に伴うメリット、リスク、コストを特定します。
+ 戦略と計画から、導入、移行、アプリケーションのモダナイゼーション、継続的なサポートまで、エンドツーエンドのサービスを提供します。
+ 継続的なビジネス価値を提供するために、再利用可能なプラクティスとツールを提供するポリシー、推奨、コントロールを構築します。

評価段階では、アプリケーションオーナーとアーキテクトはモダナイゼーション診断プレイブックを使用して、モダナイゼーションの目標と優先事項を検証します。

## モダナイゼーション診断プレイブックの使用
<a name="diagnostic"></a>

モダナイゼーション診断プレイブックは、企業にとって現在の状態から将来の状態へ移行する価値を決定するためのプロセスを提供します。これには、モダナイゼーションに伴うテクノロジーの変化も含まれます。

診断プレイブックを使用して、クラウドのモダナイゼーションにおけるアプリケーションまたはアプリケーションスイートの優先順位を決定し、モダナイゼーションの際に対処する必要のあるコンポーネントを特定します。

### 診断サイズ
<a name="dimensions"></a>

モダナイゼーション診断プレイブックは、アプリケーションまたはアプリケーショングループの現在とターゲット (移行後) の状態について、以下の側面を理解するのに役立ちます：
+ アプリケーションのグループ化 — モダナイゼーションの対象となるアプリケーションを (たとえば、テクノロジーや運用モデルごとに) グループ化する理由はありますか?
+ シーケンシング — 依存関係に基づいてアプリケーションをモダナイズすべき順序はありますか?
+ テクノロジー — テクノロジーのカテゴリーは何ですか (例えば、ミドルウェア、データベース、メッセージング) ？
+ 依存関係 — アプリケーションは他のシステムやミドルウェアと重要な依存関係を持っていますか?
+ 環境 — 開発環境、テスト環境、本番環境はいくつ使用されていますか？
+ ストレージ - ストレージ要件は何ですか (例えば、テストデータのコピー数)。
+ 運用モデル - アプリケーションのすべてのコンポーネントが、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを採用できますか。
  + もしそうなら、どのようなインフラ責任をアプリケーション・チームに分配し、誰に分配すべきですか。
  + そうでない場合、どのようなインフラ責任 (例えば、パッチ適用など) を運用チームに残すべきですか。
+ デリバリーモデル：
  + アプリケーションやアプリケーション群に基づいて、リプラットフォーム、リファクタリング、リライト、リプレイスのどれを行うべきですか。
  + モダナイゼーションのどの部分にクラウドネイティブサービスを使用すべきですか。
+ スキルセット — どのような専門知識が必要ですか? 例：
  + コンテナやサーバーレスの技術を一から使い、モジュラーアーキテクチャでアプリケーションを構築するクラウドアプリケーションのバックグラウンドです。
  + オープンソースと AWS ツールおよびサービスを使用して、CI/CD プロセス、Infrastructure as Code、自動化またはアプリケーションのオブザーバビリティの分野でソリューションを開発する DevOps の専門知識。
+ モダナイゼーションアプローチ — アプリケーションの現状、クラウドテクノロジーの選択肢、現在の技術的負債、CI/CD、監視、スキル、運用モデルを考慮すると、どのような技術的移行作業を行う必要があるのでしょうか。
+ モダナイゼーションのタイミング — モダナイゼーションのタイミングに影響を与える可能性のある、事業ポートフォリオのタイミングやその他の計画的な作業上の考慮事項は何ですか？
+ インフラストラクチャのユニットコストと総コスト – 経済分析に基づくと AWS、オンプレミスと のワークロードを維持するための年間コストはいくらですか?

これらの側面に照らしてアプリケーションを評価することで、クラウドへのモダナイゼーションを推進するにあたり、ビジネス、テクノロジー、経済に定着し続けることができます。

### ビルディングブロック
<a name="blocks"></a>

アプリケーションをモダナイズする場合、観察結果をビジネスアジリティ、組織のアジリティ、エンジニアリングの有効性という 3 つの構成要素に分類できます。
+ **ビジネスアジリティ** ー ビジネスニーズを要件に変換するための、ビジネス内の効果に関係するプラクティス。デリバリー組織がビジネスの要求にどれだけ迅速に対応できるか、また、本番環境への機能リリースをビジネスがどれだけコントロールできるかのです。
+ **組織のアジリティ** — デリバリープロセスを定義するプラクティス。例としては、アジャイル方法論や DevOps セレモニーのほか、役割の割り当てと明確化、組織全体にわたるコラボレーション、コミュニケーション、支援などがあります。
+ **エンジニアリングの有効性** — 品質保証、テスト、CI/CD、構成管理、アプリケーション設計、ソースコード管理に関連する開発プラクティス。

## 測定基準の特定
<a name="metrics"></a>

顧客にとって重要なことを提供しているかどうかを知るには、改善を促進し、提供を早めるための対策を講じる必要があります。目標、質問、測定基準 (GQM) は、測定基準がこれらの基準を満たしていることを確認するための効果的な枠組みを提供します。このフレームワークを使い、以下のステップで目標から逆算する：

1. 取り組んでいる目標や成果を特定します。

1. 目標が達成されているかどうかを判断するために答えなければならない質問を導き出します。

1. 質問に適切に答えるために何を測定すべきか、何を測定できるかを決めます。対策には 2 つのカテゴリがあります。
   + 製品メトリクスは、顧客にとって重要なものを提供していることを確認するものです。
   + ソフトウェアデリバリライフサイクルを改善していることを確認するための運用指標。

### 製品指標
<a name="product-metrics"></a>

製品メトリクスはビジネス成果に焦点を当て、新しい業務範囲の投資収益率 (ROI) が決定された時点で確立する必要があります。製品指標を確立するうえで役立つ手法は、その新しい作業範囲が導入されたときに、ビジネスで何が変わるかを確認することです。この考え方を定式化して、モダナイゼーション機能が提供されたらどうなるかに焦点を当てたテスト形式にすると便利です。

たとえば、トランザクションをレガシーシステムから移行することで、クライアントをオンボーディングする新しい機会が開かれると考えているなら、その改善策とは何ですか？ 次のクライアントをオンボーディングするには、どのくらいのキャパシティを作成する必要がありますか？ その結果を検証するためのテストはどのように構築されるのでしょうか。このシナリオの場合、製品の評価基準には次のようなものが考えられる：
+ ビジネス価値のテストや仮説を特定します (例えば、トランザクション容量の x％を解放することで、y％の新規ビジネスを取り込むことができる)。
+ ベースラインを確立します (例えば、x 件の現在の取引能力が y 件の顧客をサポートしている)。
+ 結果を検証します (たとえば、キャパシティが x パーセント向上したので、今では y パーセントの新規ビジネスに対応できるか？)

### 運用メトリクス
<a name="ops-metrics"></a>

ソフトウェアデリバリーのライフサイクルを改善し、モダナイゼーションを加速させているかどうかを判断するには、ソフトウェア配信のリードタイムと実装時間を把握する必要があります。つまり、ビジネスニーズをどれだけ早く本番環境の機能に変換できるかということです。

運用上の有用な指標には以下が含まれます。
+ リードタイム — ある作業範囲が要求から製造に移行するまでにどれくらいの時間がかかりますか？
+ サイクルタイム — ある範囲の作業を、開始から終了まで実施するのにどれくらいの時間がかかりますか？
+ デプロイ頻度 — どのくらいの頻度で変更を本番環境にデプロイしますか?
+ サービスの復旧に要する時間 — 障害からの回復にはどのくらいの時間がかかりますか (平均修復時間またはMTTRとして測定)。
+ 変更障害率 — 平均故障間隔 (MTBF) は？