— PROCESS
診断から運用まで、再現性のある型で。
新規構築も、既存サイトの改修も、運用の継続も、同じ4ステップで進めます。 各ステップで「何を受け取り・何を出し・何を検証するか」を先に決めることで、担当者が変わっても品質が揺らぎません。
-
STEP 1
診断
Assessment
2〜4週間
-
STEP 2
設計
Design
4〜8週間
-
STEP 3
実装
Build
4〜12週間
-
STEP 4
運用
Operate
月次契約（継続）
STEP 01 of 04 Assessment — 2〜4週間
診断
現状の構造・指標・運用・リスクを「事実」として記録します。対策は次のステップで考えます。
受け取るもの（Input）
- サイト / システムのURL・アクセス権
- 現行の運用ルールやドキュメント（あれば）
- 関係者ヒアリング（30-60分 × 数名）
提出するもの（Output）
- 現状診断レポート（スコア化・優先度付き）
- 改善リスト（対応一覧）のドラフト
- 次ステップの範囲と前提
STEP 02 of 04 Design — 4〜8週間
設計
リスクと優先度に基づき、情報構造・監視台帳・運用規約を文書として定義します。
受け取るもの（Input）
- 診断レポート
- 事業目標と制約条件
- 既存システム・データの仕様
提出するもの（Output）
- IA / URL規約URL規約各ページのURLの付け方を統一するルール。一貫性があると検索・運用・計測のすべてで扱いやすくなります。用語集で見る → / コンテンツモデルコンテンツモデルページや記事が持つべき項目（タイトル・リード・本文・公開日など）を構造として定義したもの。更新担当が変わっても品質を保てます。用語集で見る →
- 監視台帳・通知ワークフロー
- AWSAWSAmazon Web ServicesAmazonが提供するクラウドサービスの総称。仮想サーバ・DB・ストレージ・ネットワークなど200超のサービスがあります。用語集で見る →構成図・復旧手順書のドラフト
- 計測設計書・KPIKPIKey Performance Indicator目標の達成度を測るための主要な指標。サイトでは問い合わせ件数・CV率・流入数などが用いられます。用語集で見る →定義
検証の観点
- 再現性があるか（他者が運用できるか）
- 検証可能か（数値・証跡で確かめられるか）
- 維持可能か（担当が変わっても回るか）
STEP 03 of 04 Build — 4〜12週間
実装
テストと証跡を前提に、動くものを作ります。レビュー・検証・移行をこの段階で完了させます。
受け取るもの（Input）
- 設計書一式
- 本番・ステージング環境へのアクセス
- コンテンツ・素材の提供
提出するもの（Output）
- 動作するシステム / サイト
- ログ・監視・バックアップバックアップデータ・システムの複製を別の場所に保管しておくこと。取得するだけでなく、戻せることを定期確認します。用語集で見る →の稼働
- 移行記録・検証レポート
- 運用者向け手順書
検証の観点
- 設計書と実装の差分をゼロにする
- 失敗を再現できるテストを残す
- ロールバック手順を必ず用意する
STEP 04 of 04 Operate — 月次契約（継続）
運用
更新・評価・改善・保護の4条件を回し続けます。月次で改善リストをレビューし、四半期で構造を見直します。
受け取るもの（Input）
- 稼働中のシステム・サイト
- 月次の指標・ログ
- 運用チームとの定例
提出するもの（Output）
- 月次レポート（指標・改善提案）
- 改善リストの継続的な更新
- インシデントインシデント平常運用を損なう障害・事故のこと。サービス停止だけでなく、情報漏洩・誤送信なども含まれます。用語集で見る →記録・振り返り
- 四半期の構造見直し報告
検証の観点
- 数字が動いているか（評価）
- 施策が次に繋がっているか（改善）
- 検知・通知・証跡が機能しているか（保護）