👋

AWS案件での詳細設計を進めるためのWBS整理メモ

に公開
AWS
wbs
詳細設計
idea

AWS案件での詳細設計を進めるためのWBS整理メモ

ECS / Step Functions / Lambda / EventBridge を使ったバッチ系システムの詳細設計をやる中で、

  • どこまで検証前提にするか
  • 何を先に決めておくべきか
  • 基盤／アプリ／検証タスクをどう分けるか

を自分なりに整理した WBS メモ。

1. WBS用タスク一覧（優先度つき）

前提：

  • 列イメージ：ID / 優先度 / タスク名 / 担当 / 内容 / 依存 / 成果物
ID 優先度 タスク名 担当 内容のざっくり説明 依存 成果物イメージ
T01 高 非機能要件の整理 自分 性能・可用性・運用・締切・再試行方針などを整理して1枚にまとめる なし 非機能要件まとめ資料
T02 高 使用サービス・コンポーネント棚卸し 自分 VPC/ECS/SFN/Lambda/EventBridge/監視/IAMなど、使うコンポーネントをすべて列挙 なし コンポーネント一覧
T03 高 全体アーキテクチャ図作成 自分 コンポーネント一覧から、矢印でつないだ構成図を書く T01,T02 アーキテクチャ図
T04 高 Step Functions 全体フロー案作成 自分 正常系／異常系のステート遷移（どこで何を呼ぶか）をざっくり図にする T01,T03 フロー図・ステート一覧案
T05 高 Lambdaの役割・範囲の整理 自分＋アプリ担当 どの処理をLambdaに任せるか、やる／やらないの境界を決める T03,T04 Lambda役割定義メモ
T06 最高 Lambda I/F仕様ドラフト 自分 入力・出力・エラー形式のJSON例を含めたI/F仕様のたたきを作る T05 Lambda I/F仕様ドラフト
T07 高 Lambda I/F仕様レビュー＆確定 基盤＋アプリ アプリ・基盤メンバーとドラフトを見て修正し、合意した版を確定 T06 合意済み I/F仕様
T08 高 詳細設計：Step Functions設計（方針） 自分 Standard/Express選定、リトライ／タイムアウト方針、エラー時挙動などの設計方針を書く T01,T04 詳細設計・StepFunctions方針章
T09 高 詳細設計：監視・ログ・アラート方針 自分 何が起きたらどこに通知するか、ログをどこに集約するかを決めて書く T01 監視・ログ・アラート設計方針
T10 高 技術検証テーマ一覧（T-XX）の洗い出し 自分 ECSタスクサイズ、SFNリトライ、Lambda性能、監視動作など「検証が必要な項目」を一覧化 T01〜T09 技術検証一覧（T-01〜T-xx）
T11 中 詳細設計：全体構成・サービス選定理由 自分 なぜこのサービス構成なのか、代替案との比較含めて簡潔に記載 T03 詳細設計・全体構成章
T12 中 詳細設計：Lambda I/F章 自分 確定した I/F仕様を詳細設計に組み込む T07 詳細設計・Lambda I/F章
T13 中 詳細設計：技術検証計画章 自分 T-xxごとに目的・方法・成功条件・担当・期日を記載 T10 詳細設計・検証計画章
T14 高 詳細設計：VPC/SG/IAM 詳細設計 基盤B CIDR/サブネット/通信経路/IAMロールなどの具体値を設計 T03 詳細設計・NW/IAM章
T15 高 詳細設計：ECSタスク/サービス詳細設計 基盤B vCPU/メモリ/ENV/オートスケール条件など具体的なパラメータ案を決める T01,T03 詳細設計・ECS章
T16 高 詳細設計：Step Functions/EB 詳細設計 基盤B ASL定義、EventBridge の cron/rate 値など具体設計 T08 詳細設計・SFN/EB具体設計
T17 中 詳細設計：Lambda実行環境設計 基盤B LambdaのIAM/VPC接続/Secrets取得など環境側の詳細設計 T07,T14 詳細設計・Lambda実行環境章
T18 高 Lambdaロジック設計 アプリ担当 I/F仕様に基づき、内部処理フロー・外部API/DBアクセスの設計 T07 Lambda内部設計メモ
T19 中 Lambda実装（正常系＋異常系） アプリ担当 ハンドラ実装、例外処理、ログ出力など T18 Lambdaコード
T20 中 Lambda単体テスト アプリ担当 正常系・異常系テストコード作成＆実行 T19 テスト結果
T21 中 IaC実装（poc/dev環境最小構成） 基盤B VPC/ECS/SFN/Lambda/監視の最低限をIaCで構築 T14〜T17 IaCコード・poc/dev環境
T22 高 技術検証 T-01〜T-xx 実行 基盤B＋アプリ＋自分 検証計画に沿ってPoC実施、ログ収集 T21,T20 検証ログ・測定結果
T23 高 検証結果の整理＆パラメータ確定 自分 検証結果からタスク数/メモリ/タイムアウト/リトライなどの確定値を決めて一覧化 T22 確定パラメータ一覧
T24 高 詳細設計への最終反映 自分 T23の確定値を詳細設計の各章に反映し、暫定表記を確定値に置き換える T23 完成版詳細設計
T25 中 最終レビュー＆説明 自分 基盤B・アプリ・PMに説明し、指摘をもらって修正 T24 レビューコメント・修正済み設計

2. 優先度「高・最高」のタスクの具体像

🔥 T01 非機能要件の整理

目的
ECS・Step Functions・Lambda のパラメータを決めるための「ものさし」を先に作る。

最低押さえる4観点

  • 性能

    • 1実行あたりの処理対象量（レコード件数・ファイル数など）
    • いつまでに終わっていればOKか（例：日次バッチなら「○時までに完了」）

  • 可用性

    • リトライしてでも完了させるべき処理か
    • ダメなら「失敗として人が対応」で良いのか

  • 運用

    • 誰がアラートを見るのか（運用チーム／担当エンジニア など）
    • 24h対応なのか、営業時間内で良いのか

  • 外部制約

    • 外部APIのタイムアウトやレート制限
    • バックエンド側メンテ時間帯など

アウトプット
A4 1枚のメモでOK：

  • 「性能」「可用性」「運用」「外部制約」の4見出しで箇条書き

後で、タイムアウト値・リトライ回数・並列数などを決める土台になる。

🔥 T02 使用サービス・コンポーネント棚卸し

目的
「このシステムは何の箱でできているか」を先に洗い出して、抜け漏れをなくす。

やること

  • 使う予定のAWSサービスを全部列挙

    • VPC / Subnet / SG / Endpoint
    • ECS(Fargate)
    • Step Functions
    • EventBridge
    • Lambda
    • S3 / SQS / RDS など（あれば）
    • CloudWatch Logs / メトリクス / アラーム
    • IAM / Secrets Manager / KMS など

  • それぞれに「一言役割」を付ける
    例：

    • ECS：バッチ処理A/Bの実行コンテナ基盤
    • Step Functions：バッチ全体のフロー制御

アウトプット

  • 2列の表：

    • サービス名
    • 役割（短く一言）

この表がそのままアーキ図と詳細設計の材料になる。

🔥 T03 全体アーキテクチャ図作成

目的
関係者（基盤・アプリ・PM）が同じ「1枚の絵」を見て話せるようにする。

やること

  • T02のコンポーネントを箱として並べる
  • どの箱からどの箱にデータが流れるか矢印で描く
  • 「どこで EventBridge → Step Functions → Lambda/ECS になるか」を見えるようにする

アウトプット

  • PNGでもPPTでもよいので「1枚のアーキ図」

ラフでもいいから、とにかく早めに 1 枚作って、後から更新していく前提にする。

🔥 T05〜T07 Lambda I/Fまわり

T05 Lambdaの役割・範囲の整理

  • Step Functions のフローの中で、「どのポイントを Lambda にやらせるか」を決める

  • そのLambdaについて：

    • 入ってくる情報（入力）
    • 外部API / DBへのアクセス有無
    • 戻したい情報（出力）

  • 「Lambda がやるところ」と「ECS / 他サービスがやるところ」の境界を明確にする

T06 Lambda I/F仕様ドラフト

入力／出力／エラーのイメージを「具体的な JSON」で書く。

  • 入力例
{
  "jobId": "xxx",
  "date": "2025-11-28",
  "retryCount": 0
}
  • 出力例
{
  "status": "OK",
  "processedCount": 123
}
  • エラー例
{
  "status": "ERROR",
  "code": "VALIDATION_ERROR",
  "message": "xxxxx"
}

T07 Lambda I/F仕様レビュー

  • アプリ担当に「この形で実装しやすいか？」を確認
  • 基盤側に「Step Functions側から扱いやすいか？」を確認
  • フィールド名や構造を必要に応じて調整し、その場で「この仕様で行く」と合意する

🔥 T08 Step Functions設計方針

決めておくこと

  • Standard / Express のどちらを採用するか（理由もセットで）

  • リトライ方針

    • 「何回」「どのエラーコード／例外」でリトライするか

  • タイムアウト

    • 1ステートごとのタイムアウト
    • 全体フローとしてのタイムアウト

  • エラー時の挙動

    • どのエラーは「FAILED」で止めるか
    • どのエラーは「エラーだけ記録して次に進めるか」

🔥 T09 監視・ログ・アラート方針

ざっくり決めておくポイント

  • 失敗時に通知するチャンネル（メール／チャットなど）

  • どのイベントを INFO / WARN / ERROR にするか

  • どのレベルからアラートにするか
    例：

    • SFNの FAILED はアラート
    • Lambda の一時的な WARN は ログに記録するのみにとどめる など

これが決まっていると、CloudWatch Logs / アラームの設計がブレにくくなる。

🔥 T10 技術検証テーマ一覧

机上の空論だと怖いところをすべて書き出す

例：

  • ECSタスク性能（タスクサイズ／並列数を変えたときの処理時間）
  • Lambda のメモリ変更による性能差
  • Step Functions のリトライ設定が本当に想定どおりに動くか
  • アラートが本当に想定どおりのタイミングで飛ぶか

それぞれに対して：

  • テーマ
  • 目的
  • ざっくりどうやって確かめるか（方法）
  • 成功条件

を1行ずつ付けておく。

これがそのまま「T-01〜T-xx」の検証タスクになる。

3. 実際にどこから手を付けるか（優先順位）

詳細設計と並行しつつ、優先度の高いものからこの順で進めると回しやすい：

  1. T01 非機能要件まとめ（A4 1枚）
  2. T02 コンポーネント棚卸し
  3. T03 全体アーキ図（ラフでもOK）
  4. T05〜T07 Lambdaの役割 → I/Fドラフト → レビュー
  5. T08〜T10 StepFunctions方針・監視方針・技術検証テーマ

ここまで終わると、

  • アプリ担当 → Lambda 設計〜実装へ進める
  • 基盤側 → VPC/ECS/SFN の詳細設計＆IaC へ進める
  • 自分 → 詳細設計書の骨格作りと検証設計へ進める

という形で、3レーン並行で走れる状態になる。

Discussion