俊敏性と市場投入までの時間のシナリオ判断

試作品の準備、キャンペーン対応、標準環境の配布を比較し、俊敏性の改善箇所と残る統制を判断します。

この単元で学ぶこと

1. 新規案を試す事例新しい販売機能を試すたびに環境準備で待っていた会社が、標準環境を短時間で作れるようになったとします。この変化は新しい要求への対応を速める俊敏性に関係します。毎秒の処理能力を増やす性能改善と、課題を混同しないことが大切です。

2. 需要変動へ対応する事例キャンペーンの来訪者が増えたら能力を増し、終了後に減らすのは弾力性です。新しい企画を早く検証する俊敏性とは直接の目的が違います。両方を備えることはできますが、設問では「新規案への対応」か「同じサービスの負荷増減」かを読み分けます。

3. 工程の合計を計算仮に調達12日、実装4日、試験2日が順番に必要なら計18日です。調達だけを2日へ短縮すると計8日で、短縮は10日です。処理が並行なら単純合計ではなくなるため、問題の前提を確認します。クラウドが減らすのは対象工程の待ちであり、他の工程まで消えません。

4. 実験の停止判断試作品の利用料金が仮に1日500円、5日で結果が分かり終了したなら計2,500円です。30日放置すれば計15,000円になります。他費用なしの例でも、終了後に資源を整理することが重要だと分かります。試験の目的、評価指標、終了日を最初に決めます。

5. 標準化を活かす毎回人手で設定していた開発環境を定義から作るようにすると、作成時間だけでなく差分の発見も改善します。ただし同じ誤設定を配布しないように、標準のレビューと変更履歴を持ちます。設定が揃うことと、その設定が適切であることは別の確認です。

6. 権限と費用のガードレールセルフサービスの範囲を、必要なサービス、承認された構成、利用期限等で決めます。利用者がすぐ試せる一方、誰が何を作ったかと費用を追える状態にします。手順全てを毎回手動に戻すのではなく、繰り返す確認を標準へ取り込む方法を比較します。

7. 本番移行は別の確認試作が動いた後は本番データの扱い、可用性、性能、運用方法等を確認します。短時間で環境を作れた事実は、障害復旧や全利用者への対応が検証済みという意味ではありません。速く試すことに価値があっても、試作の条件から外れた結論を出さないようにします。

8. 改善を継続する準備、試験、承認、公開それぞれの時間を測り、残る待ちを見つけます。試験環境の準備を短縮した後に承認待ちが最長なら、次はその流れの改善を考えます。成功した実験だけでなく、早く中止して次の案へ移れたことも学習の成果として評価します。

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。