Q1 — 単一選択AWSへリホスト済みの業務アプリケーションは安定稼働していますが、新機能のリリースに6週間かかり、定常運用にも毎月多くの時間を使っています。事業側はリリース時間の短縮と運用工数の削減を求めています。
Modernizationの進め方として最も適切なものはどれですか。
A. 現状のリリース時間と定常運用時間を基準値にし、それらを悪化させる要因と変更案、期待効果、確認指標を対応付ける
B. 利用するAWSサービス数をModernizationの目標にし、サービス数が増えるほど成功と判断する
C. 既存アプリケーションを全面的に書き直し、変更量そのものをModernizationの成果として扱う
D. すでにAWSへ移行済みなので、運用負荷やリリース速度に課題が残っていてもModernizationは不要と判断する
答えと解説
答え：A
ModernizationはAWSサービスの導入数や変更量ではなく、現在の課題を変更へつなぎ、その変更が狙ったBusiness Valueを改善したかで評価します。
現状値と期待する変化を対応付けることで、実施後に目的を達成したか確認できます。
Q2 — 単一選択Modernization候補として3つのTechnical Debtが見つかりました。
- 8年前に作成されたが、現在の変更や運用への影響が確認されていないコード
- 毎回のリリースに手作業を発生させ、提供まで10日かかる仕組み
- 現在は利用されていない古い内部ツール
事業側は新機能の提供速度を改善したいと考えています。
最初に優先して評価すべきTechnical Debtはどれですか。
A. リリースを10日遅らせている手作業の仕組みを、Business Valueを妨げているTechnical Debtとして優先して評価する
B. 作成年が最も古いコードを、現在の影響を確認せず自動的に最優先で全面的に書き換える
C. 利用されていない内部ツールを、Business Valueとの関係にかかわらず最優先で再実装する
D. Technical Debtはすべて同じ価値を持つため、Business Valueへの影響を比較せず同時に解消する
答えと解説
答え：A
Technical Debtは、単純な古さや存在期間だけで優先順位を決めません。
このシナリオでは新機能の提供速度がBusiness Valueとして求められており、リリースを直接10日遅らせている仕組みがその価値を妨げています。Technical DebtとBusiness Valueへの影響をつなげて優先度を判断します。
Q3 — 単一選択セルフマネージドのミドルウェアでパッチ適用、バックアップ確認などに毎月多くの運用時間を使っています。互換性を満たすManaged Serviceへ移行する案を採用しました。
Modernizationの成果を確認する方法として最も適切なものはどれですか。
A. 導入完了だけでなく、定常運用時間の削減と、その結果として価値を生む作業へ振り向けられた時間を確認する
B. Managed Serviceへ移行できた時点でModernizationは成功とし、運用負荷が実際に減ったかは確認しない
C. Managed Serviceを採用すると利用者側の運用がなくなるため、導入前後の運用作業を比較する必要はない
D. 運用時間が減ってもBusiness Valueには関係しないため、サービス料金の変化だけを成果として扱う
答えと解説
答え：A
Managed ServiceはModernizationの目的ではなく、Operational Overheadを変えるための手段になり得ます。
採用後に実際の運用時間が減り、その人的キャパシティを価値の高い作業へ移せたかまで確認します。
Q4 — 単一選択あるModernization計画では、次の3つの変更を予定しています。
- セルフマネージドのデータベース運用をManaged Serviceへ変更する
- 手動リリース工程を自動化する
- 密結合な一部機能のアーキテクチャ構造を変更する
ModernizationとRe-architectureの関係として最も適切な説明はどれですか。
A. 3つすべてModernizationに含められるが、Re-architectureに該当するのはアーキテクチャ構造を変更する3のような取り組みである
B. ModernizationとRe-architectureは常に同義なので、Managed Serviceへの変更やリリース自動化もすべてRe-architectureである
C. Re-architectureだけがModernizationなので、Managed Serviceへの変更とリリース自動化はModernizationには含まれない
D. AWSサービスを利用する変更はすべてRe-architectureであり、アプリケーション構造を変更したかどうかは関係ない
答えと解説
答え：A
ModernizationはBusiness Valueを改善するための変更全体を扱います。
その中には、プラットフォーム変更、運用改善、自動化、アーキテクチャ構造の変更など複数種類の取り組みを含められます。Re-architectureは、その中でアーキテクチャ構造そのものを変更する取り組みとして位置付けます。
Q5 — 単一選択同じAWS上で動作する2つのアプリケーション構成があります。
構成Aは固定容量で、デプロイは手動、障害時は担当者が手動で復旧し、大きな単位でしか変更できません。
構成Bは需要変化へ追従でき、自動化されたデプロイを行い、障害時には自動復旧し、小さな変更を継続的に提供できます。
Cloud-nativeという観点で最も適切な説明はどれですか。
A. 構成Bは俊敏性、拡張性、回復力、継続的な変更といったCloud-nativeで重視される特性をより強く持っている
B. 両方ともAWS上で動作しているため、運用特性や変更特性に関係なく同じ程度にCloud-nativeである
C. Cloud-nativeかどうかは利用しているAWSサービス数だけで決まり、変更・拡張・復旧方法は判断材料にならない
D. 構成Aは手作業が多いため、利用者が直接制御できるという理由だけで構成BよりCloud-nativeである
答えと解説
答え：A
Cloud-nativeは特定のAWSサービスを使ったかどうかだけでは判断しません。
俊敏性、拡張性、回復力、自動化、頻繁で安全な変更など、クラウド環境を活用するワークロード特性として捉えます。
Q6 — 単一選択Modernization候補として、運用工数削減、リリース高速化、アプリケーション構造変更の3つが挙がっています。
運用工数削減はBusiness Valueとの関係と期待効果が明確ですが、他の2つは効果と変更リスクの評価がまだ十分ではありません。
進め方として最も適切なものはどれですか。
A. 価値と期待効果が明確な改善を段階的に実施して結果を測定し、その実測結果も使って次のModernization候補を判断する
B. Modernizationではすべての候補を同時に開始する必要があるため、効果や変更リスクが不明でも3つを一括実施する
C. 一度Modernizationを開始したら結果確認は最後だけに行い、途中の実測結果を次の判断には使用しない
D. 改善候補に優先順位を付けるとCloud-nativeではなくなるため、Business Valueとの関係を比較しない
答えと解説
答え：A
Modernizationは一度の全面刷新である必要はありません。
Business Valueとの関係や期待効果が明確な改善から段階的に進め、その結果を測定して次の判断へ利用できます。これにより、改善効果を早く確認しながら、不確実な大規模変更を一度に抱えることを避けられます。