連載「AI時代にIT業界に求められるスキルや人材は何か」で進めている、AquaDraftの運用をAIで自動化するプロジェクトの成果物です。実際に作成したプロジェクト計画書(文書番号 ADO-PP-001)を、体裁を変えずそのまま公開しています。本文が「である調」なのは、社内で使う設計文書の様式に合わせているためです。
この計画は完成品ではなく、進行に応じて書き換えていく文書です。予定が変わったこと自体も残していきます。
プロジェクトの経緯はAI時代にIT業界に求められるスキルや人材は何か -実践編 #1-、前提となる分析は要求分析書(ADO-RA-001)と要件定義書(ADO-RD-001)をご覧ください。
文書管理情報
| 項目 | 内容 |
|---|---|
| 文書番号 | ADO-PP-001 |
| 文書名 | AquaDraft Ops Automation プロジェクト計画書 |
| 版数 | 1.1 |
| 作成日 | 2026-08-20 |
| 最終更新日 | 2026-08-20 |
| 作成者 | Claude(実行・分析担当) |
| 承認者 | プロジェクトオーナー(やまかず) |
| 承認状態 | 未承認 |
| 機密区分 | 公開(WordPress上で公開管理する。秘匿値・個人情報は記載しない) |
| 関連文書 | ADO-RA-001 要求分析書、ADO-RD-001 要件定義書 |
| 更新方針 | 各Phaseの完了時および重要な決定の発生時に改版する(12章) |
改訂履歴
| 版数 | 日付 | 改訂者 | 改訂内容 |
|---|---|---|---|
| 1.1 | 2026-08-20 | Claude | 現在フェーズを表上で明示。Phase 1の対象決定をPhase 0の残タスクからPhase 1の起点タスク1.1へ移し、Phase 0を完了とした |
| 1.0 | 2026-08-20 | Claude | 初版作成。Phase構成、WBS、成果物一覧、KPI体系、現在地を定義 |
1. はじめに
1.1 本書の目的
本書は、AquaDraft Ops Automationプロジェクトの全体像を示すことを目的とする。具体的には、何を、どの順序で、どこまでやるのか、そして今どこまで進んでいるのかを、一枚で追える形にまとめる。
要求分析書(ADO-RA-001)が「何が問題か」、要件定義書(ADO-RD-001)が「何を作るか」を扱うのに対し、本書は「どう進めるか」を扱う。
1.2 適用範囲
本プロジェクトの全期間、Phase 0からPhase 5までを対象とする。
1.3 対象読者
- プロジェクトオーナー(進行判断のため)
- 本プロジェクトを外部から評価する読者(進め方そのものを検証の対象とするため)
1.4 関連文書
| 文書番号 | 文書名 | 位置づけ |
|---|---|---|
| ADO-RA-001 | 要求分析書 | 現行業務の分析と要求事項の定義 |
| ADO-RD-001 | 要件定義書 | 機能要件・非機能要件・受入基準の定義 |
| ADO-PP-001 | プロジェクト計画書 | 本書。進め方とスケジュールの定義 |
2. プロジェクトの目的とゴール
2.1 目的
AIの能力を業務単位で正しく評価し、可能な限り人間の関与を外した状態でAquaDraftの運用を回す。その過程で得た判断とノウハウを、資格に代わる実績として残す。
2.2 最終ゴール
オーナーがいなくてもAquaDraftの運営が回る状態にする。
2.3 ゴールの判定基準
要件定義書9章の受入基準AC-01からAC-08を満たした状態をもって達成とする。とくにAC-08(自動化を見送った、または人間へ戻した業務について、判断理由が記録されていること)は、自動化の達成度ではなく判断の記録を問うものであり、本プロジェクトの目的に直接対応する。
2.4 このプロジェクトが検証していること
「AI時代にIT業界で求められるのは、AIの能力を見極めて業務へ組み込む判断力である」という仮説を、実在するサービスの運用で検証する。仮説が外れた業務、つまり自動化を試みて人間に戻した業務も、検証結果として等しく記録する。
3. 推進体制
| 役割 | 担当 | 権限範囲 |
|---|---|---|
| プロジェクトオーナー・最終承認者 | オーナー | 本番反映の可否、公開判断、素材のクオリティ判定、セキュリティ関連の最終判断 |
| 実行・分析・自動化設計 | Claude | 業務分析、自動化の設計・実装、レポート生成、下書き作成、AI評価カテゴリの判定 |
対象システムは、AquaDraft本体、AquaDraft公式ブログ、アクセス解析基盤、ソースコードリポジトリ一式である。
本表は分業のための体制表ではない。関与する人間は1名のみであり、これは現時点で人間側に残っている役割の棚卸しである。プロジェクトが進むほどオーナーの担当欄が小さくなることを、進捗の指標とする。
4. 全体スケジュール
4.1 なぜ日付を置かないか
本計画には期日を置かない。オーナーは2026年8月から平日日中の稼働ができず、作業可能な時間が夜間と週末に限られる。加えて、AIの利用枠という時間以外のボトルネックがある(制約条件CON-01およびCON-02)。
守れない日付を並べても計画としての意味がないため、各Phaseには期日ではなく完了条件を置き、それを満たした時点で次へ進む方式とする。
4.2 Phase構成
| Phase | 名称 | 目的 | 主な成果物 | 発信 | 状態 |
|---|---|---|---|---|---|
| Phase 0 | 企画・要求分析 | 何が問題で何を作るかを確定する | 要求分析書、要件定義書、プロジェクト計画書 | プロローグ、実践編#1 | 完了 |
| Phase 1 | 最初の自動化 | 1つの業務を実際に自動化し、仕組みを通しで動かす | 対象業務の自動化一式、通し回帰テスト | 実践編#2 | 決定待ち |
| Phase 2 | 検知と起票の自動化 | 人間の目視に依存している検知経路を機械に置き換える | 稼働監視、課題の自動起票、改善案の下書き生成 | 実践編#3 | 未着手 |
| Phase 3 | 発信業務の自動化 | 素材マスタから告知と記事の下書きを自動生成する | 告知文生成、辞典記事の下書き生成、リリースノート生成 | 実践編#4 | 未着手 |
| Phase 4 | 監視・通知・例外処理 | 自動処理が失敗しても業務が止まらない状態にする | 通知の仕組み、例外処理ルール、フォールバック定義 | 実践編#5 | 未着手 |
| Phase 5 | 効果測定と実績証明 | どこまで人間が外れたかを測り、ノウハウを言語化する | 効果測定レポート、実績証明パッケージ | 連載完結記事 | 未着手 |
色が付いている行が、本書の最終更新時点で進行中のPhaseである。現在はPhase 1に入っているが、後述のとおり最初の起点タスクで止まっている。
4.3 各Phaseの完了条件
| Phase | 完了条件 |
|---|---|
| Phase 0 | 要求分析書と要件定義書が作成され、全要求が要件へ展開されていること |
| Phase 1 | 対象業務が実際に自動で流れ、通し回帰テストが自動実行されること。オーナーの関与が承認のみに縮小されていること |
| Phase 2 | 不具合と異常の検知がオーナーの目視に依存しなくなり、課題が自動で起票されること |
| Phase 3 | 素材追加1件から、対象媒体分の告知文と記事の下書きが自動生成されること(受入基準AC-05) |
| Phase 4 | 自動処理の失敗が検知され、フォールバックへ切り替わり、業務が停止しないこと(NFR-102、NFR-104) |
| Phase 5 | 受入基準AC-01からAC-08の充足状況が測定され、レポートとして公開されていること |
4.4 Phase 1の対象は未確定
Phase 1で何を自動化するかは、本書の作成時点で確定していない。候補は2案ある。
| 案 | 対象業務 | 主な要件ID | 先に着手する利点 | 懸念 |
|---|---|---|---|---|
| 案A | 素材追加業務の自動化 | FR-101からFR-104、FR-201 | 影響度が最も高い課題(ISS-001)に直接効く。素材マスタが他機能の前提になっているため、後続の設計が単純になる | 工程数が多く、最初のPhaseとしては重い |
| 案B | 週次運用レポートの自動生成 | FR-301からFR-303 | 独立して作れるため着手が軽く、仕組みを一巡させやすい | 集約対象がまだ存在せず、報告する中身が乏しい |
要件定義書11章では案Aを推奨している。理由は3点である。
- 課題の影響度が最も高く、かつ現在の主業務である
- 素材マスタ(FR-101)が告知文生成、辞典記事生成、描画性能の記録すべての材料元になっており、先に作ると後続が単純になる
- 週次運用レポートは集約先であり、集約対象がない段階で作っても報告する内容が乏しい
ただし案Aを採る場合、素材追加だけを自動化して動作確認を人手に残すと、自動化した分だけ確認の負荷がオーナーへ集中してかえって悪化する。これを避けるため、通し回帰テスト(FR-201)を並行して整備することを条件とする。
4.5 決定がPhase 2以降に与える影響
| 決定 | Phase 2以降の組み替え |
|---|---|
| 案Aを採用 | 週次運用レポート(FR-301からFR-303)はPhase 2へ移す。Phase 2は検知の自動化と集約の両方を担う |
| 案Bを採用 | 素材追加業務の自動化はPhase 2へ移す。Phase 2の検知と起票はPhase 4へ統合する |
5. タスク一覧(WBS)
Phase 0とPhase 1は個別タスクまで分解する。Phase 2以降は、着手時点の状況によって内容が変わるため、本書ではPhase単位までの記載にとどめ、各Phaseの開始時に分解する。段階的詳細化の方針を採る。
5.1 Phase 0(完了)
| WBS | タスク | 成果物 | 状態 |
|---|---|---|---|
| 0.1 | 要望の言語化 | 実践方針とゴールの確定 | 完了 |
| 0.2 | 現行業務の棚卸し | 業務一覧BIZ-01からBIZ-09、素材追加13工程の可視化 | 完了 |
| 0.3 | AI評価基準の設計 | 4カテゴリの判定基準 | 完了 |
| 0.4 | 自動化分類ルールの設計 | 分類AからEと承認ルール | 完了 |
| 0.5 | 課題の洗い出しと構造化 | 課題ISS-001からISS-012 | 完了 |
| 0.6 | 要求事項の定義 | 要求REQ-001からREQ-024 | 完了 |
| 0.7 | 要求分析書の作成 | ADO-RA-001 | 完了 |
| 0.8 | 機能要件・非機能要件の定義 | FR 24件、NFR 26件 | 完了 |
| 0.9 | 要件定義書の作成 | ADO-RD-001 | 完了 |
| 0.10 | プロジェクト計画書の作成 | ADO-PP-001(本書) | 完了 |
5.2 Phase 1の起点(案A・案B共通)
Phase 1はすでに開始しているが、最初のタスクで止まっている。以降のタスクは、この1件が決まるまで分岐が確定しない。
| WBS | タスク | 成果物 | 状態 |
|---|---|---|---|
| 1.1 | Phase 1で自動化する対象の決定(OPEN-01) | 決定記録 | 決定待ち |
5.3 Phase 1(案Aを採用した場合)
| WBS | タスク | 対応要件 | 依存 |
|---|---|---|---|
| 1.2 | 素材マスタの設計と構築 | FR-101 | 1.1 |
| 1.3 | 通し回帰テストの実装 | FR-201 | 1.1 |
| 1.4 | 回帰テストの自動実行 | FR-202 | 1.3 |
| 1.5 | 既存素材との差分抽出 | FR-103 | 1.2 |
| 1.6 | 素材候補の調査の自動化 | FR-102 | 取得経路の承認(OPEN-09) |
| 1.7 | 優先順位付けルールの実装 | FR-104 | 1.5、1.6 |
| 1.8 | クオリティ判定の承認フロー | FR-106 | 1.2 |
| 1.9 | 実行ログの記録 | FR-502 | 1.1 |
| 1.10 | タスク起票と評価カテゴリの記録 | FR-501 | 1.9 |
| 1.11 | 実践編#2の執筆と公開 | 連載記事 | 1.2から1.10 |
5.4 Phase 1(案Bを採用した場合)
| WBS | タスク | 対応要件 | 依存 |
|---|---|---|---|
| 1.2 | 解析データの定期取得 | FR-301 | 1.1 |
| 1.3 | コミットログ取得の自動化 | FR-303 | 1.1 |
| 1.4 | 異常値検知の実装 | FR-302 | 1.2 |
| 1.5 | レポートテンプレートの設計 | FR-303 | 1.2、1.3 |
| 1.6 | 要約プロンプトの設計 | FR-303 | 1.5 |
| 1.7 | 定期実行の仕組み化 | FR-303 | 1.6 |
| 1.8 | 即時通知と週次通知の実装 | FR-304、FR-305 | 1.4、1.7 |
| 1.9 | 実行ログの記録 | FR-502 | 1.1 |
| 1.10 | 実践編#2の執筆と公開 | 連載記事 | 1.2から1.9 |
5.5 Phase 2以降
| Phase | 含まれる要件 |
|---|---|
| Phase 2 | FR-204(稼働監視)、FR-205(フィードバック受付)、FR-505(課題・改善案の下書き生成)、FR-503(判定見直しの記録) |
| Phase 3 | FR-401(告知文生成)、FR-402(辞典記事の下書き)、FR-403(リリースノート)、FR-404(配信の実行管理) |
| Phase 4 | FR-304、FR-305(通知)、NFR-102(フォールバック)、NFR-104(失敗の検知)、例外処理ルールの整備 |
| Phase 5 | 受入基準AC-01からAC-08の測定、効果測定レポート、実績証明パッケージ |
6. 成果物一覧
| 成果物 | Phase | 公開先 | 状態 |
|---|---|---|---|
| 要求分析書(ADO-RA-001) | 0 | WordPress | 公開済み |
| 要件定義書(ADO-RD-001) | 0 | WordPress | 公開済み |
| プロジェクト計画書(ADO-PP-001) | 0 | WordPress | 公開済み(本書) |
| 対象業務の自動化一式 | 1 | ソースコードリポジトリ | 未着手 |
| 通し回帰テスト | 1 | ソースコードリポジトリ | 未着手 |
| 稼働監視・課題自動起票の仕組み | 2 | ソースコードリポジトリ | 未着手 |
| 告知文・記事下書きの生成系 | 3 | ソースコードリポジトリ | 未着手 |
| 監視・通知システム、例外処理ルール一覧 | 4 | ソースコードリポジトリ、WordPress | 未着手 |
| 効果測定レポート | 5 | WordPress | 未着手 |
| 実績証明パッケージ | 5 | WordPress | 未着手 |
| 連載記事(プロローグから完結まで) | 全Phase | WordPress | 進行中 |
成果物は原則としてWordPress上で管理する。コードとスクリプトのみソースコードリポジトリで管理する。個人アカウント配下のクラウドストレージは使わない(NFR-505)。
7. マイルストーン
| 番号 | マイルストーン | 判定 | 状態 |
|---|---|---|---|
| M0 | 何を作るかが文書として確定した | 要求分析書と要件定義書の作成完了 | 達成(2026-08-20) |
| M1 | 1つの業務が自動で流れた | Phase 1の完了条件を満たす | 未達 |
| M2 | 検知が人間の目視から外れた | Phase 2の完了条件を満たす | 未達 |
| M3 | 素材追加1件から発信物が自動で出た | 受入基準AC-05を満たす | 未達 |
| M4 | 自動処理が失敗しても業務が止まらなくなった | Phase 4の完了条件を満たす | 未達 |
| M5 | オーナーの関与が承認のみになった | 受入基準AC-01を満たす | 未達 |
M5の達成をもって最終ゴールの到達とみなす。
8. KPI体系
8.1 実績KPI(何を自動化したか)
| 指標 | 説明 |
|---|---|
| 自動化した業務の数 | 分類AからCへ移行した業務の件数 |
| 削減した作業時間 | 週あたりの削減時間 |
| 自動生成したレポート・下書きの数 | 累計件数 |
| 人間の確認・修正が不要だった自動処理の割合 | 出力をそのまま採用できた比率 |
| オーナーの介在なしで完了したタスクの割合 | 最終ゴールに直結する指標 |
8.2 ノウハウKPI(何を学んだか)
| 指標 | 説明 |
|---|---|
| AIの誤判定パターンの数と類型 | どこで、どう間違えたかの分類 |
| 改善したプロンプト・仕組みの数 | 累計件数 |
| あえて分類Eにした業務とその理由の数 | 自動化しないと決めた判断の記録 |
| 自動化を試みて人間へ戻した業務の数と理由 | 検証結果としての失敗の記録 |
| 評価カテゴリの判定を後から修正した回数 | 判定基準そのものの精度向上を測る |
8.3 発信KPI(何を伝えたか)
| 指標 | 説明 |
|---|---|
| 連載記事数 | 累計本数 |
| 公開した構成図・仕組みの数 | 累計件数 |
| 記事経由の反応 | コメント、問い合わせ等 |
ノウハウKPIには、失敗を数える指標を意図的に含めている。うまくいった話だけを並べても、判断力の証明にはならないためである。
9. 進行のルール
9.1 タスク処理フロー
すべてのタスクは、要件定義書3.3に定める9ステップ(起票、影響度・リスク評価、実施方針決定、承認、実施、エビデンス記録、検証、完了報告、振り返り)に従って処理する。
とくに第2ステップのAI評価カテゴリ判定は、着手前に必ず実施する。判定を省略したタスクは、結果が良くても本プロジェクトの成果として数えない。
9.2 Phaseの進め方
| 順 | 実施内容 |
|---|---|
| 1 | Phase開始時に、対象タスクを個別へ分解する(段階的詳細化) |
| 2 | 各タスクにAI評価カテゴリと自動化分類を付与する |
| 3 | 実装し、実行ログを残す |
| 4 | Phaseの完了条件(4.3)を判定する |
| 5 | 実践編の記事として公開する。誤判定と手戻りもそのまま書く |
| 6 | 評価カテゴリと自動化分類の妥当性を見直し、本計画書を改版する |
9.3 移行の原則
自動化は業務単位で段階的に切り替える。一括切替は行わない。切替前後で同一の成果物が得られることを確認してから手作業を廃止し、手作業の手順は記録として残していつでも戻せるようにする(NFR-401からNFR-403)。
10. 現在地
10.1 完了していること
- Phase 0の全タスクが完了し、Phase 0を完了と判定した
- 要求分析書、要件定義書、プロジェクト計画書の3文書を公開済み
- 課題12件、要求24件、機能要件24件、非機能要件26件、受入基準8件を定義済み
- マイルストーンM0を達成
10.2 止まっていること
Phase 1の対象決定(WBS 1.1、未決事項OPEN-01)がオーナーの判断待ちで、この1件がPhase 1以降のすべてをせき止めている。本書の作成時点で、これが唯一のクリティカルパス上の未決事項である。
10.3 直近の予定
| 順 | 実施内容 |
|---|---|
| 1 | Phase 1の対象を決定する(案Aまたは案B) |
| 2 | 決定に応じてPhase 1のWBS(5.3または5.4)を確定し、本書を改版する |
| 3 | Phase 1の各タスクにAI評価カテゴリを判定する |
| 4 | 実装に着手する |
11. 前提条件・制約条件
要求分析書8章のPRE-01からPRE-05、およびCON-01からCON-06を継承する。計画上とくに影響が大きいものを以下に再掲する。
| 番号 | 内容 | 計画への影響 |
|---|---|---|
| CON-01 | オーナーは平日日中に稼働できず、作業時間が夜間と週末に限られる | 期日を置かず完了条件で管理する(4.1) |
| CON-02 | AIの利用枠が時間以外のボトルネックになる | 素材追加1件あたりの処理を1日分の枠に収める(NFR-201) |
| CON-06 | 関与する人間は1名のみ | 保守が1名で成立する複雑度に収める(NFR-303) |
12. 変更管理
本書は完成した計画ではなく、進行に応じて改版される文書である。以下の場合に改版する。
| 契機 | 改版内容 |
|---|---|
| Phaseの完了 | 状態、マイルストーン、現在地を更新する |
| 未決事項の決定 | 該当箇所を確定内容へ書き換え、決定理由を残す |
| Phaseの順序変更 | 4.2、4.5、5章を組み替える |
| 自動化を人間へ戻す判断 | 該当タスクの状態と理由を記録する。取り消し線で消さず、判断の履歴として残す |
改版のたびに改訂履歴へ追記し、何をなぜ変えたかを追えるようにする。計画が変わったこと自体を隠さないことを方針とする。
13. 未決事項
要求分析書9章および要件定義書11章の未決事項を継承する。本計画で追跡する未決事項を以下に一覧化する。
| 番号 | 未決事項 | 影響範囲 | 決定者 |
|---|---|---|---|
| OPEN-01 | Phase 1で最初に自動化する対象(案Aまたは案B) | Phase 1以降のすべて | オーナー |
| OPEN-02 | 素材追加の頻度目標を維持するか見直すか | Phase 1の作り込み度合い | オーナー |
| OPEN-03 | 利用者フィードバックの受付経路 | Phase 2 | オーナー |
| OPEN-04 | 描画性能の許容閾値 | Phase 1、Phase 3 | Claudeが計測しオーナーが承認 |
| OPEN-05 | 3Dモデル化に用いる外部サービスの自動連携可否 | Phase 1(案A) | Claudeが調査しオーナーが承認 |
| OPEN-06 | 各媒体への配信を自動実行するか下書き生成までに留めるか | Phase 3 | オーナー |
| OPEN-07 | 週次運用レポートの配信先 | Phase 1(案B)またはPhase 2 | オーナー |
| OPEN-08 | 回帰テストに用いるテスト基盤の選定 | Phase 1 | Claudeが案を作成しオーナーが承認 |
| OPEN-09 | 素材候補の調査に用いる情報源と取得経路 | Phase 1(案A) | オーナー |
以上