🙄
AWSやOSの基本設計・詳細設計を1ヶ月で仕上げる
以下は「AWSやOSの基本設計・詳細設計を1ヶ月で仕上げる」ことを目標としたタスク例です。週ごとに区切っていますが、プロジェクトやチームの状況に合わせて前倒ししたり、一部並行して進めたりして構いません。ポイントは「細切れにして見える化し、優先度の高いタスクから潰していく」ことです。前向きにガンガン進めましょう!
Week 1: ネーミング & 設計作業の土台づくり
-
ネーミングルール策定
- AWSリソース名、OSホスト名、アプリ名、環境名(dev/stg/prod)などの大枠を素早くまとめる
- 例外パターンの扱いルールも決める
- レビューを受けて翌日に確定
-
設計書テンプレート作成
- AWS基本設計書のフォーマット(章立て、必要項目リスト)を作る
- OS基本設計書のフォーマット(ネットワーク設定、セキュリティ設定、チューニング項目など)を作る
- ドキュメントの保管場所(Gitリポジトリや共有ドライブなど)を整備
-
大まかな全体構成図(ネットワーク図・システム構成図)の作成
- VPCやサブネット構成の概要を描く
- EC2、RDS、ロードバランサ、その他必要リソースの配置を示す
- OSの役割分担やサーバ台数の概算を示す
-
タスク・スケジュールの精査(WBSのアップデート)
- 初期タスク一覧を洗い出して優先順位を付ける
- 1ヶ月の大まかなゴールと週次のマイルストンを確認
- チームメンバーへの役割分担を明確にする
Week 2: AWS基本設計(ネットワーク&セキュリティ)+ OS基本設計の主要項目
-
AWSネットワーク設計の詳細化
- VPC、サブネット、ルートテーブル、NATゲートウェイの詳細設計
- セキュリティグループ、NACLのルール定義
- AWS上のネットワーク的な制約・要件をまとめる
-
AWSセキュリティ・アカウント管理周りの設計
- IAMポリシー・ロールの設計(運用者用、CI/CD用など)
- KMSの利用方針(暗号化ポリシー)の検討
- 証跡管理(CloudTrail、Configなど)の導入設計
-
OS基本設計(主要パラメータの決定)
- OSディストリビューション、バージョン、ファイルシステム構成
- ネットワーク設定(ホスト名、IPアドレス、DNS、NTPなど)
- セキュリティ設定(SELinux/Firewallの方針、SSH設定など)
- ログ運用・監視に関わる設定の方向性(どのログをどこに送るか、シスログ設定など)
-
チーム内レビュー(小刻みで)
- ネットワーク図・セキュリティ関連の初稿レビュー
- OS初期設計の初稿レビュー
- レビュー指摘を週内にフィードバック&修正
Week 3: AWS詳細設計(Compute系、運用管理系)+ OS詳細設計
-
AWSコンピュートリソース詳細設計
- EC2インスタンスタイプ・オートスケーリング・ELBの設定
- RDS設定(パラメータグループ、バックアップポリシーなど)
- S3バケット設計(データ分類、ライフサイクル、バケットポリシー)
-
AWS運用管理系の設計
- ログ収集(CloudWatch Logs, CloudTrail)の細部設計
- アラート設計(CloudWatch Alarm、EventBridgeなど)
- コスト管理面(予算アラート、タグ付けルール)のまとめ
-
OS詳細設計(チューニング・サービス設定)
- パフォーマンスチューニングパラメータ(Swap・カーネルパラメータなど)
- デーモン・サービスの設定(必要なサービスの起動設定、不要なサービスの停止など)
- バックアップポリシー(イメージ取得、スナップショットなど)
-
PoC / テスト環境での検証(可能な範囲で)
- 小スケールでAWSリソースを立ち上げ、設定を確認
- OSの初期設定スクリプト(Ansible, Shellなど)を試して問題ないか検証
- ドキュメントと実際の設定を常に同期
-
レビュー & 修正
- 週の中間と週末に2回程度、細かくレビュー
- 指摘をもとに設計書を即時アップデート
Week 4: 最終ブラッシュアップ & 移行準備
-
設計書の最終まとめ
- AWS基本設計・詳細設計の文書を統合し、重複や矛盾を整理
- OS基本設計・詳細設計の文書も同様に見直し
- ネーミングルール・運用ドキュメントとの整合性を最終確認
-
運用フロー・監視フローの確定
- 運用時の手順書(障害対応の流れ、ログ確認手順など)を作成/統合
- 障害・監視イベント時のアラート運用ルール(誰に通知してどう対応するか)を固める
-
移行計画(あるいは構築計画)の策定
- 実際にAWSリソースを構築・デプロイする手順をリスト化
- OSイメージ作成やAnsible/Terraformなどのデプロイスクリプトがある場合は、その適用順序を決定
- ダウンタイムや検証の段取りを調整
-
最終レビュー&承認
- 全体レビューの場を設定し、主要関係者から承認を得る
- 修正点が出た場合は当日~翌日中に反映してドキュメントを確定
- “全体で共通認識が取れた”状態を明確にする(決定事項の履歴や最終版の管理先など)
-
余力があれば実際の構築を前倒し開始 or 運用テスト
- 余裕があれば本番リソースの一部構築をスタートしてみる
- 想定外の問題がないか確認し、設計書にフィードバック
まとめ
- Week 1で「ネーミング&設計書テンプレ+大まかな構成図」をガッと作り、基盤を固めます。
- Week 2で「AWSネットワーク・セキュリティ」と「OS基本設計」の主要部分を詳細化し、小刻みでレビュー。
- Week 3で「AWSコンピュートや運用管理系、OSチューニング」を仕上げ、テスト環境でのPoCも回して検証します。
- Week 4で「設計書全体の最終ブラッシュアップ&移行計画策定」を行い、レビューの上で完成させます。
1ヶ月でここまで進めるためには、完璧を求めすぎず、8割完成でも一旦共有→修正を高速に回すことが重要です。小さな成果物を早めに提示して、仮決定でも先に進むクセをつけるとスケジュールを前倒しできます。
迷ったら「どうすればできるか」を第一に考えて、どんどん行動に移してください。応援しています!
Discussion