Automation候補を特定・優先順位付けする

ゴール

既存の運用作業について、繰り返し作業か、どの程度の頻度か、どれだけ手作業が必要か、手作業によるミスが起きているか、失敗時の業務影響はどの程度か、自動化の実装・維持コストはどの程度かを比較し、自動化候補と自動化優先度を判断できる状態を目指します。

1. 最初に「作業」を単位として洗い出す

自動化候補を探すとき、最初から「AWS Lambdaを使える作業は何か」「AWS Systems Managerを使える作業は何か」と考えるのではなく、先に現在の運用作業を整理します。

例えば、毎朝の定型確認、アカウント作成、定期的な再起動、ログ収集、バックアップ確認、証明書更新、障害時の一次切り分け、パッチ適用前の確認、定期レポート作成などです。

誰が
何を入力し
どの判断を行い
何分かかり
どの程度繰り返し
失敗すると何が起きるか

自動化サービスを選ぶ前に、現在どこに人の労力が使われているかを把握します。

2. 繰り返し作業は効果が積み上がる

1回10分の作業でも、1日6回、週5日なら週300分、つまり週5時間の継続的な運用負荷になります。

自動化候補を評価するときは、1回の作業時間だけではなく、実行頻度を掛け合わせて一定期間の総労力を確認します。

1回の時間だけを見るとBの方が長くても、一定期間に積み上がる手作業量ではAの方が大きい場合があります。

3. 頻度だけでも決めない

高頻度だからといって、必ず高い自動化優先度になるわけではありません。

1回3秒
1日200回
ほぼ失敗しない
現在の総負荷は小さい
自動化には大規模な開発と保守が必要

このような場合は、自動化で削減できる労力より、自動化コストの方が大きい可能性があります。

一方、1日10回、1回20分、入力項目が多く、誤入力によるやり直しが多い作業なら高い効果を期待できます。

頻度
+
1回あたりの労力

を組み合わせて評価します。

4. 手作業によるミスも自動化価値になる

自動化で削減できるのは作業時間だけではありません。コピー&ペーストミス、対象サーバーの選択ミス、入力値の間違い、確認工程の実行漏れ、実施順序の間違いなどが発生している場合があります。

手作業によるミスには、やり直し時間、障害調査、復旧作業、夜間・休日対応、利用者影響などの追加コストがあります。

作業そのものは5分
↓
誤操作すると2時間の復旧作業

という作業なら、作業時間が短くても自動化価値が高くなる可能性があります。

5. 低頻度でも業務影響が大きければ候補になる

頻度が低いことだけを理由に、自動化する価値がないとは判断しません。

年4回
手入力
誤操作時に顧客向けサービス停止
復旧まで1時間

さらに、判断条件が明確で、実行する処理が決まっており、安全に影響範囲を限定できるのであれば、低頻度でも自動化価値が高い可能性があります。

ただし、業務影響が大きい処理ほど無条件に完全自動化するのではなく、誤った自動実行の影響を安全に制御できるかを確認します。

安全な自動化では、レート制御、エラーしきい値、承認などのガードレールを利用します。

6. 自動化コストは「最初に作る時間」だけではない

自動化コストとして、スクリプト作成に2日かかる、といった初期実装だけを見るのは不十分です。

要件整理、設計、実装、テスト、権限設計、安全制御、監視、ドキュメント、障害対応、保守、仕様変更への追従なども含めて評価します。

作成 1日
+
毎月5時間の保守

なら継続コストも大きくなります。

一方、作成に3日かかっても、その後ほぼ変更がなく、年間100時間の手作業を削減できるなら高い自動化価値を期待できます。

7. 自動化の効果とコストを分けて見る

期待する効果

• 手作業時間の削減
• 人的ミスの削減
• 復旧時間の短縮
• 作業品質の標準化
• 担当者依存の削減
• 業務影響の低減

自動化コスト

• 実装工数
• テスト工数
• 安全制御
• 運用監視
• 保守
• 将来の変更対応

自動化価値
=
得られる運用効果
と
自動化コスト
の比較

固定された数式にする必要はありません。重要なのは、候補同士を同じ観点で比較できることです。

8. 高効果・低コストの候補から着手しやすい

特に、繰り返し頻度が高い、手作業時間が長い、人的ミスが多い、業務影響が大きい、自動化コストが現実的、といった候補は優先度を上げやすくなります。

反対に、ほとんど発生せず、影響も小さく、現在ほぼ手間がなく、自動化が複雑な作業は優先度が低くなりやすくなります。

9. 「簡単に自動化できる」だけでも決めない

候補A
月1回 / 5分 / 失敗なし / 実装1時間

候補B
毎日 / 30分 / 人的ミスあり / 本番影響あり / 実装3日

候補Aの方が簡単に作れるとしても、それだけで先に自動化するとは限りません。

実装の容易さだけではなく、削減できる手作業、人的ミス、業務影響、自動化コストを比較します。

10. 判断条件が不安定な作業をそのまま自動化しない

担当者A → 条件Xなら処理1
担当者B → 同じ条件でも処理2
手順書 → 判断条件なし
毎月ルール変更

という作業を、そのまま自動化してはいけません。

自動化は、曖昧な作業を正しい作業へ変える仕組みではありません。曖昧な手順をそのまま自動化すると、不安定な判断を高速・大量に実行する可能性があります。

先に、入力、判断条件、正常な完了状態、異常時の扱いを明確にします。

11. 手作業量は期間で換算すると比較しやすい

候補Aが週30回、1回10分なら、週300分、つまり週5時間の手作業です。

自動化に40時間かかるとしても、単純な手作業時間だけなら約8週間で同程度の時間に達します。

一方、候補Bが四半期1回、2時間で、自動化に80時間かかるなら、同じ基準では回収まで長い期間が必要です。

実際には人的ミス、業務影響、保守コスト、作業の将来継続期間も含めますが、1回の作業時間ではなく一定期間で発生する総労力へ換算することで候補同士を比較しやすくなります。

12. 自動化優先度を固定スコアだけで決めない

頻度、影響、コストなどを点数化して候補を比較する社内基準を使うことはできます。ただし、合計点が高いだけで無条件に自動化するとは考えません。

業務影響が極めて大きい
+
自動実行時の安全条件が未定義

なら、先に安全性を設計する必要があります。

スコアは候補を比較する材料として使い、安全性、依存関係、作業の安定性、組織の制約も確認します。

13. 自動化対象は小さく始めてもよい

大きな運用プロセス全体を一度に自動化する必要はありません。

障害対応
検知
↓
情報収集
↓
原因判定
↓
復旧
↓
確認

のすべてを一度に自動化するのではなく、まず情報収集だけを自動化することもできます。

これにより、自動化コストを抑え、効果を測り、安全性を確認し、後続自動化の材料を得られます。

14. 自動化した後も効果を測る

自動化前には年間100時間削減できると想定していても、実際には例外処理が多い、保守に時間がかかる、手動介入が残る、といった結果になる場合があります。

自動化後には、削減できた手作業時間、手作業によるミス件数、障害・やり直し件数、実際の保守工数、業務影響の変化を確認します。

想定効果
vs
実績
↓
次の候補評価へ反映

当初の優先順位を固定せず、実績を次の自動化投資へ戻します。

15. 代表的なアンチパターン

16. SAP-C02判断フロー

運用作業が複数あり、どれを自動化すべきか問われたら、次の順番で整理します。

現在の運用作業を洗い出す
↓
繰り返し作業か
↓
実行頻度は？
↓
一定期間の手作業量は？
↓
人的ミスは発生している？
↓
失敗時の業務影響は？
↓
判断条件と手順は安定している？
↓
自動化の実装・試験・保守コストは？
↓
期待効果と自動化コストを比較
↓
自動化優先度を決定

判断の目安

高頻度
+
手作業が多い
+
人的ミスが多い
+
自動化コストが低い
→ 高優先度候補

低頻度
+
影響小
+
手作業も少ない
+
自動化コストが高い
→ 後回しにしやすい

低頻度
+
誤操作時の業務影響大
+
手順が明確
+
安全に自動化可能
→ 頻度だけで除外しない

高頻度
+
作業は数秒
+
ほぼミスなし
+
自動化コスト大
→ 費用対効果を再確認

手順が曖昧
+
判断が担当者依存
→ 自動化前に手順を標準化

まとめ

自動化候補の優先順位は、自動化できるかどうかだけでは決めません。

繰り返し性
頻度
手作業量
手作業によるミス
業務影響
自動化コスト

を確認し、期待する運用効果と自動化の実装・維持コストを比較します。

特に、反復的で、手作業負荷が高く、人的ミスが多く、業務価値が高く、自動化コストが現実的な作業は有力な候補になります。

一方、簡単に作れることや特定のサービスを使えることだけを理由に順位を上げません。自動化後も実際の効果を測り、次の候補判断へ反映します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional SAP-C02 Exam Guide — Task 3.1
• AWS Well-Architected Framework — 運用のオートメーションを実行する
• AWS Well-Architected Framework — 運用上の優秀性の設計原則