この記事について
連載「AI時代にIT業界に求められるスキルや人材は何か」で進めている、AquaDraftの運用をAIで自動化するプロジェクトの成果物です。実際に作成した要件定義書(文書番号 ADO-RD-001)を、体裁を変えずそのまま公開しています。本文が「である調」なのは、社内で使う設計文書の様式に合わせているためです。
プロジェクトの経緯はAI時代にIT業界に求められるスキルや人材は何か -実践編 #1-をご覧ください。
この文書の上位にあたる要求分析書(ADO-RA-001)もあわせて公開しています。
全体スケジュールとタスク一覧はプロジェクト計画書(ADO-PP-001)にまとめてあります。
連載「AI時代にIT業界に求められるスキルや人材は何か」で進めている、AquaDraftの運用をAIで自動化するプロジェクトの成果物です。実際に作成した要件定義書(文書番号 ADO-RD-001)を、体裁を変えずそのまま公開しています。本文が「である調」なのは、社内で使う設計文書の様式に合わせているためです。
プロジェクトの経緯はAI時代にIT業界に求められるスキルや人材は何か -実践編 #1-をご覧ください。
この文書の上位にあたる要求分析書(ADO-RA-001)もあわせて公開しています。
全体スケジュールとタスク一覧はプロジェクト計画書(ADO-PP-001)にまとめてあります。
目次
文書管理情報
| 項目 | 内容 |
|---|---|
| 文書番号 | ADO-RD-001 |
| 文書名 | AquaDraft Ops Automation 要件定義書 |
| 版数 | 1.0 |
| 作成日 | 2026-08-20 |
| 最終更新日 | 2026-08-20 |
| 作成者 | Claude(実行・分析担当) |
| 承認者 | プロジェクトオーナー(やまかず) |
| 承認状態 | 未承認 |
| 機密区分 | 公開(WordPress上で公開管理する。秘匿値・個人情報は記載しない) |
| 上位文書 | ADO-RA-001 要求分析書 |
| 関連文書 | ADO-PL-001 企画書 |
改訂履歴
| 版数 | 日付 | 改訂者 | 改訂内容 |
|---|---|---|---|
| 1.0 | 2026-08-20 | Claude | 初版作成。要求分析書(ADO-RA-001)の要求REQ-001からREQ-024を要件へ展開 |
1. はじめに
1.1 本書の目的
本書は、要求分析書(ADO-RA-001)で確定した要求事項を、実現すべき要件として定義することを目的とする。
本書は「何を実現するか」を定義するものであり、実装方式の詳細は基本設計以降で取り扱う。
1.2 適用範囲
要求分析書1.2に定める範囲と同一とする。
1.3 対象読者
要求分析書1.3に定める対象と同一とする。
1.4 用語定義
要求分析書1.4の用語定義を継承する。本書で追加する用語を以下に示す。
| 用語 | 定義 |
|---|---|
| 素材マスタ | 素材の名称、カテゴリ、特徴、追加日等を保持する構造化データ。告知文および記事生成の唯一の材料元となる |
| 通し回帰テスト | 起動から保存までの操作の流れを最初から最後まで再現し、既存動作の破壊を検知するテスト |
| フォールバック | 自動処理が失敗した際に、業務を止めないために切り替える代替手段 |
| エスカレーション | 自動処理では判断できない事象を、オーナーの判断へ引き上げること |
1.5 要件IDの体系
| 接頭辞 | 対象 |
|---|---|
| FR-1xx | 機能要件(素材管理) |
| FR-2xx | 機能要件(品質・開発) |
| FR-3xx | 機能要件(監視・レポート) |
| FR-4xx | 機能要件(発信) |
| FR-5xx | 機能要件(記録・トレーサビリティ) |
| NFR-1xx | 非機能要件(可用性) |
| NFR-2xx | 非機能要件(性能・拡張性) |
| NFR-3xx | 非機能要件(運用・保守性) |
| NFR-4xx | 非機能要件(移行性) |
| NFR-5xx | 非機能要件(セキュリティ) |
| NFR-6xx | 非機能要件(システム環境) |
非機能要件の分類はIPA「非機能要求グレード」の6大項目に準拠する。
2. システム化の方針
2.1 基本方針
業務単位でAIの信頼度を評価し、評価結果に応じた自動化の度合いを適用する。評価と適用は着手前に必ず実施し、判定結果を記録する。判定は運用実績に基づいて見直す。
2.2 AI評価基準(カテゴリ別)
すべてのタスクは、着手前に以下の4カテゴリのいずれかに判定する。
| カテゴリ | 判定基準 | 該当例 |
|---|---|---|
| 高信頼 | 正解が一意に定まる、または機械的に検証可能な作業 | コミットログ要約、アクセス集計、定型レポート生成、既存素材との差分抽出 |
| 中信頼 | 複数の妥当な出力がありうるが、誤りがあっても被害が限定的で、人間が容易に検知・修正できる作業 | 改善案の下書き、告知文・記事の下書き、課題の起案 |
| 低信頼 | 誤りの影響が大きい、または正解の基準自体が曖昧な判断 | 優先順位の決定、公開可否の判断、障害原因の断定 |
| 自動化禁止 | 誤りが致命的、または倫理・セキュリティ上のリスクを伴う | セキュリティ関連の変更、本番反映、外部公開の最終判断、素材のクオリティ判定 |
2.3 自動化分類
評価カテゴリを受けて、各業務に以下の5段階を適用する。
| 分類 | 運用 |
|---|---|
| A | 完全自動化。人間の確認なしで実行してよい |
| B | AI補助。AIが下書き・提案・集計を作り、人間が確認・仕上げる |
| C | 条件付き自動化。通常は自動だが、一定条件を超えたら人間に判断を仰ぐ |
| D | 人間確認必須。AIは材料を用意するだけで、実行判断は必ず人間が行う |
| E | 自動化しない。常に人間が担う |
2.4 評価カテゴリと自動化分類の対応
| AI評価カテゴリ | 適用する自動化分類 |
|---|---|
| 高信頼 | A |
| 中信頼 | B |
| 低信頼 | CからD |
| 自動化禁止 | DからE |
上記は目安であり、業務ごとの個別事情により調整する。調整した場合は理由を記録する。
3. 業務要件
3.1 業務別の適用分類
| 業務ID | 業務 | AI評価カテゴリ | 自動化分類 | 適用理由 |
|---|---|---|---|---|
| BIZ-01 | 素材追加 | 工程により異なる(3.2参照) | 工程により異なる | 判断工程と作業工程が混在するため工程単位で判定する |
| BIZ-02 | 不具合修正 | 中信頼(検知は高信頼) | AからB | 検知・再現は機械的に可能。修正内容はレビューを要する |
| BIZ-03 | UI改修・機能追加 | 中信頼 | B | 実装はAI、採否はオーナー |
| BIZ-04 | 課題・改善案の管理 | 中信頼から低信頼 | BからD | 材料の集約はAI、優先順位の意思決定は人間 |
| BIZ-05 | 告知(SNS) | 中信頼 | BからC | 素材マスタからの生成は自動、配信実行は条件付き |
| BIZ-06 | ブログ記事作成 | 中信頼 | B | 下書きはAI、公開判断は人間 |
| BIZ-07 | アクセス解析の確認 | 高信頼(取得・集計)、低信頼(対応判断) | AからC | 取得・集計はA、異常後の対応要否はCでエスカレーション |
| BIZ-08 | 本番反映 | 自動化禁止 | D | 失敗時に取り返しがつかない。既存ルール |
| BIZ-09 | 運用状態の把握 | 高信頼(集計)、中信頼(解釈) | AからB | 集計はA、解釈コメントの付与はB |
| BIZ-10 | セキュリティに関わる変更 | 自動化禁止 | E | 常に人間が担う |
BIZ-08およびBIZ-10は、本プロジェクトの方針(人間の関与を可能な限り削減する)の例外として固定する。ここを自動化した場合、失敗時に復旧できず、検証そのものが成立しなくなるため、人間を残すこと自体が合理的な判断である。
3.2 素材追加業務のTo-Beフロー
現行13工程(要求分析書3.3)に対する、実現後の担当と分類を以下に定める。
| 工程No | 工程 | To-Be担当 | 評価カテゴリ | 自動化分類 | 備考 |
|---|---|---|---|---|---|
| 1 | 人気素材の調査 | Claude | 中信頼 | B | 情報源は自動取得が可能かつ規約上許諾された経路に限定する |
| 2 | 既存素材との差分抽出 | Claude | 高信頼 | A | 素材マスタとの機械的な突き合わせ |
| 3 | 追加対象の選定 | Claude | 低信頼 | C | 優先順位ルール(人気の網羅、次にタイプ違い、その後ニッチ)に従い自動選定。オーナーの割り込み指定がある場合はそれを優先 |
| 4 | 参考情報の収集 | Claude | 中信頼 | D | 取得元の規約遵守を必須とし、経路はオーナーが承認したものに限る |
| 5 | 画像生成の試行 | Claude | 中信頼 | B | |
| 6 | クオリティ判定 | オーナー | 自動化禁止 | D | 品質の根幹に関わる判断。承認必須(REQ-017) |
| 7 | 3Dモデル化 | Claude | 中信頼 | B | 外部サービスの自動連携可否は未検証(OPEN-05) |
| 8 | モデルの受け渡し | 廃止 | — | — | 素材マスタへの登録に統合し、工程として消滅させる |
| 9 | モデルの圧縮 | Claude | 高信頼 | A | |
| 10 | AquaDraftへの実装 | Claude | 中信頼 | B | |
| 11 | 動作確認 | Claude | 高信頼 | A | 通し回帰テスト(FR-201)による自動確認 |
| 12 | 本番反映 | オーナー | 自動化禁止 | D | 承認必須(REQ-018) |
| 13 | 告知 | Claude | 中信頼 | BからC | 素材マスタから各媒体向けに生成し配信 |
現行はオーナーが9工程を担っている。実現後にオーナーへ残る工程は、工程6(クオリティ判定)、工程12(本番反映の承認)、および工程4の経路承認の3点となる。工程8は素材マスタへの統合により消滅する。
3.3 タスク処理フロー(標準)
すべての業務は、以下の順序で処理する。日本のIT運用現場における変更管理・インシデント管理の流れに準拠する。
| 順 | ステップ | 実施内容 |
|---|---|---|
| 1 | 起票 | トリガーの発生を記録する(コード更新、アクセス異常、改善のヒント、その他業務の発生) |
| 2 | 影響度・リスク評価 | AI評価カテゴリを判定する |
| 3 | 実施方針決定 | 自動化分類(AからE)を決定する |
| 4 | 承認 | 3.4の承認ルールに従う |
| 5 | 実施 | |
| 6 | エビデンス記録 | 実施ログを残す |
| 7 | 検証 | 完了確認を行う |
| 8 | 完了報告 | 6.2の報告要件に従う |
| 9 | 振り返り | 評価カテゴリ・自動化分類の妥当性を見直す |
3.4 承認ルール
| 自動化分類 | 承認の要否 | 承認者 |
|---|---|---|
| A | 承認不要 | — |
| B | Claudeが下書きを作成した後に承認 | オーナー |
| C | 通常は承認不要。条件超過時のみエスカレーション | オーナー(条件超過時のみ) |
| D | Claudeが起案し、実行判断を承認 | オーナー |
| E | 起案から実施までを担当 | オーナー |
4. 機能要件
優先度は要求分析書5.1のMoSCoW法に従う。
4.1 素材管理
| 要件ID | 機能 | 内容 | 対応要求 | 優先度 | 分類 |
|---|---|---|---|---|---|
| FR-101 | 素材マスタ管理 | 素材の名称(日英)、カテゴリ、特徴、サイズ、追加日、モデル情報を構造化データとして保持し、追加・更新できる。告知文および記事生成の唯一の材料元とする | REQ-002 | Must | A |
| FR-102 | 素材候補の調査 | 規約上許諾された情報源から、候補となる素材の名称と参照情報を収集し一覧化する | REQ-001 | Must | B |
| FR-103 | 既存素材との差分抽出 | 収集した候補と素材マスタを突き合わせ、未実装の素材を抽出する | REQ-001 | Must | A |
| FR-104 | 追加候補の優先順位付け | 抽出結果に対し、人気の網羅、タイプ違いの網羅、ニッチの順で優先順位を付与し、1回あたり1件から3件を選定する。オーナーの割り込み指定を優先できる | REQ-001 | Must | C |
| FR-105 | 素材制作の支援 | 参考情報の整理、画像生成の試行、3Dモデル化の実行を支援する | REQ-001 | Must | BからD |
| FR-106 | クオリティ判定の承認受付 | 生成物をオーナーへ提示し、承認・却下を受け付け、結果を記録する。承認なしに後続工程へ進めない | REQ-017 | Must | D |
| FR-107 | AquaDraftへの組み込み | 承認された素材を圧縮し、AquaDraftへ実装し、素材マスタへ登録する | REQ-001 | Must | AからB |
4.2 品質・開発
| 要件ID | 機能 | 内容 | 対応要求 | 優先度 | 分類 |
|---|---|---|---|---|---|
| FR-201 | 通し回帰テスト | 起動、素材配置、レイアウト操作、保存、読み込みまでの一連の流れを再現し、既存動作の破壊を検知する | REQ-005 | Must | A |
| FR-202 | 回帰テストの自動実行 | コード変更および素材追加を契機に回帰テストを自動実行し、結果を記録する | REQ-005 | Must | A |
| FR-203 | 描画性能の自動計測 | 素材追加のたびに描画性能を数値で計測し、素材マスタへ記録する。閾値を下回った場合は報告する | REQ-012 | Should | C |
| FR-204 | 稼働監視・不具合検知 | 公開環境の稼働状態および実行時エラーを定期的に確認し、異常を検知する | REQ-006 | Must | A |
| FR-205 | 利用者フィードバック受付 | 利用者からの不具合報告・要望を受け付け、記録する経路を提供する | REQ-007 | Should | B |
4.3 監視・レポート
| 要件ID | 機能 | 内容 | 対応要求 | 優先度 | 分類 |
|---|---|---|---|---|---|
| FR-301 | 解析データの定期取得 | アクセス解析および検索パフォーマンスのデータを定期取得し、保持する | REQ-008 | Must | A |
| FR-302 | 異常値検知 | 取得データに対し、既定の基準で異常値・急変を検知する | REQ-008 | Must | A |
| FR-303 | 週次運用レポート生成 | 期間内のコード変更、素材追加、テスト結果、アクセス状況、検知した異常、未処理の課題を集約したレポートを自動生成する | REQ-010 | Must | AからB |
| FR-304 | 即時通知 | 異常検知時およびテスト失敗時に、内容と発生時刻を即時にオーナーへ通知する | REQ-011 | Must | A |
| FR-305 | 週次通知 | 正常時の情報は即時通知せず、週次運用レポートに集約してオーナーへ届ける | REQ-011 | Must | A |
4.4 発信
| 要件ID | 機能 | 内容 | 対応要求 | 優先度 | 分類 |
|---|---|---|---|---|---|
| FR-401 | 媒体別告知文の生成 | 素材マスタから、媒体ごとの形式・言語・文字数に合わせた告知文の下書きを生成する | REQ-003 | Must | B |
| FR-402 | 素材辞典記事の下書き生成 | 素材マスタから、既存フォーマットに沿った素材辞典記事の下書きを1素材1本で生成する | REQ-003、REQ-013 | Should | B |
| FR-403 | リリースノートの生成 | 期間内のコード変更と素材追加から、リリースノートの下書きを日英で生成する | REQ-013 | Should | B |
| FR-404 | 告知配信の実行管理 | 素材追加を契機に、対象媒体への配信を実行し、実施状況を記録する。未配信の媒体を検出できる | REQ-004 | Should | C |
4.5 記録・トレーサビリティ
| 要件ID | 機能 | 内容 | 対応要求 | 優先度 | 分類 |
|---|---|---|---|---|---|
| FR-501 | タスク起票と評価記録 | 発生したタスクを起票し、AI評価カテゴリと自動化分類の判定結果を必ず記録する | REQ-014 | Must | A |
| FR-502 | 実行ログの保持 | すべての自動処理について、実行日時、対象、結果、失敗時の理由を記録し、後から追跡できる形で保持する | REQ-015 | Must | A |
| FR-503 | 判定見直しの記録 | 評価カテゴリまたは自動化分類を変更した場合、変更前後と理由を記録する | REQ-016 | Must | A |
| FR-504 | 成果物の公開管理 | 本プロジェクトの成果物をWordPress上の記事または固定ページとして公開・更新する | REQ-021 | Must | D |
| FR-505 | 課題・改善案の下書き生成 | 開発ログ、検知した異常、利用者フィードバックから、課題および改善案の下書きを生成し記録する | REQ-009 | Should | B |
5. 非機能要件
5.1 可用性
| 要件ID | 要件 | 対応要求 |
|---|---|---|
| NFR-101 | 自動処理の仕組みはAquaDraft本体と分離し、自動処理の停止が本体の稼働に影響しないこと | — |
| NFR-102 | 自動処理が失敗した場合のフォールバックを業務ごとに定義し、業務が停止しないこと | REQ-023 |
| NFR-103 | データ取得に失敗した場合も、週次運用レポートは欠測を明示したうえで生成されること | REQ-010 |
| NFR-104 | 自動処理の失敗そのものを検知できること。失敗が沈黙のまま放置されないこと | REQ-006 |
5.2 性能・拡張性
| 要件ID | 要件 | 対応要求 |
|---|---|---|
| NFR-201 | 素材追加1件あたりの自動処理が、AI利用枠の1日分に収まること | REQ-022 |
| NFR-202 | 回帰テストの1回の実行時間が、夜間の稼働時間を圧迫しない範囲に収まること | REQ-005 |
| NFR-203 | 素材数の増加に対し、告知文生成および記事生成の処理が破綻しないこと | REQ-003 |
| NFR-204 | 素材追加により、AquaDraftの描画性能が既定の閾値を下回らないこと | REQ-012 |
| NFR-205 | 告知の対象媒体を追加できる構造とすること。媒体追加時に素材マスタの変更を要しないこと | REQ-003 |
5.3 運用・保守性
| 要件ID | 要件 | 対応要求 |
|---|---|---|
| NFR-301 | すべての自動処理の実行ログを保持し、任意の処理について実施経緯を追跡できること | REQ-015 |
| NFR-302 | AI評価カテゴリおよび自動化分類の判定と、その見直し履歴を記録できること | REQ-014、REQ-016 |
| NFR-303 | 自動化の仕組みは、オーナー1名で保守できる複雑度に収めること。保守にオーナー以外の人手を前提としないこと | CON-06 |
| NFR-304 | 異常時は即時、正常時は週次で報告されること。正常時の即時通知は行わないこと | REQ-011 |
| NFR-305 | 定型作業の手順を文書化し、Claudeが同一の手順を再現できること。手順を都度考案しないこと | — |
5.4 移行性
| 要件ID | 要件 | 対応要求 |
|---|---|---|
| NFR-401 | 手作業から自動処理への切替は業務単位で段階的に行うこと。一括切替を行わないこと | — |
| NFR-402 | 切替前後で同一の成果物が得られることを確認してから、手作業を廃止すること | — |
| NFR-403 | 自動化前の手作業手順を記録として残し、いつでも手作業へ戻せること | REQ-016 |
| NFR-404 | 既存の記事投稿基盤、ソースコードリポジトリ、アクセス解析基盤を置き換えないこと | PRE-04、PRE-05 |
5.5 セキュリティ
| 要件ID | 要件 | 対応要求 |
|---|---|---|
| NFR-501 | 秘匿情報(APIキー、パスワード、トークン等)をAIへ送らず、ログにも出力しないこと | REQ-020 |
| NFR-502 | 秘匿情報は環境変数ファイル等で一元管理し、文書・記事・スクリプトへ直接記載しないこと | REQ-020 |
| NFR-503 | 本番反映は自動化せず、必ずオーナーの承認を経ること | REQ-018 |
| NFR-504 | セキュリティに関わる変更を自動化しないこと | REQ-019 |
| NFR-505 | 成果物をWordPress上で管理し、個人アカウント配下のクラウドストレージに外部アクセス経路を作らないこと | REQ-021 |
| NFR-506 | 外部サイトの利用規約に反する自動取得を行わないこと。取得の可否が不明な経路は使用しないこと | CON-03、CON-04 |
| NFR-507 | 公開する成果物に、個人情報および秘匿情報を含めないこと | REQ-020 |
5.6 システム環境
| 要件ID | 要件 | 対応要求 |
|---|---|---|
| NFR-601 | 自動処理は、オーナーのローカル環境および既存の実行基盤上で動作すること | — |
| NFR-602 | 新規の有償サービスを導入する場合は、事前にオーナーの承認を得ること | — |
| NFR-603 | AquaDraft本体の技術スタックを変更しないこと | 7.2(対象外) |
6. 運用要件
6.1 運用体制
| 役割 | 担当 | 権限範囲 |
|---|---|---|
| プロジェクトオーナー・最終承認者 | オーナー | 本番反映の可否、公開判断、素材のクオリティ判定、セキュリティ関連の最終判断 |
| 実行・分析・自動化設計 | Claude | 業務分析、自動化の設計・実装、レポート生成、下書き作成、AI評価カテゴリの判定 |
本表は分業のための体制表ではなく、現時点で人間側に残っている役割の棚卸しである。プロジェクトの進捗に伴い、オーナーの担当範囲が縮小することを進捗の指標とする。
6.2 報告要件
| 区分 | タイミング | 内容 |
|---|---|---|
| 即時報告 | 異常検知時、回帰テスト失敗時、自動処理の失敗時 | 事象、発生時刻、影響範囲、暫定対応の要否 |
| 週次報告 | 週1回 | 期間内のコード変更、素材追加、テスト結果、アクセス状況、検知した異常とその後、未処理の課題、AI評価カテゴリの判定実績 |
正常時の情報を即時通知しない。通知の頻度が高すぎると確認されなくなり、報告の目的が失われるためである。
6.3 例外処理・エスカレーション
| 事象 | 対応 |
|---|---|
| 自動処理が失敗した | フォールバック(NFR-102)へ切り替え、即時報告する |
| 分類Cの条件を超過した | 処理を停止し、オーナーへエスカレーションする |
| 判断が評価カテゴリの想定と異なった | 処理を停止し、判定の見直し(FR-503)を起票する |
| 外部サービスが利用不可になった | 該当工程を手作業へ戻し、代替手段を検討する課題を起票する |
7. 制約条件・前提条件
要求分析書8章のPRE-01からPRE-05、およびCON-01からCON-06をそのまま継承する。
8. スコープ外
要求分析書7.2に定める対象外項目をそのまま継承する。加えて、本書では以下を要件化しない。
| 項目 | 理由 |
|---|---|
| 多人数運用を前提とした権限管理 | 関与する人間はオーナー1名のみであり、権限分離の必要がない(CON-06) |
| 障害時の自動復旧 | 本番反映が人間の承認を必須とするため、自動復旧は成立しない(NFR-503) |
| 素材の自動公開 | クオリティ判定と本番反映がいずれも承認必須であり、公開までの全自動化は行わない |
9. 受入基準
本プロジェクトの各段階は、以下を満たした時点で完了とみなす。
| 基準ID | 受入基準 | 対応要件 |
|---|---|---|
| AC-01 | 素材追加1件について、オーナーの関与がクオリティ判定と本番反映の承認に限定されていること | FR-101からFR-107 |
| AC-02 | 通し回帰テストが自動実行され、失敗時に即時報告されること | FR-201、FR-202、FR-304 |
| AC-03 | 週次運用レポートが人手を介さず生成され、オーナーへ届くこと | FR-303、FR-305 |
| AC-04 | すべてのタスクにAI評価カテゴリの判定記録が存在すること | FR-501 |
| AC-05 | 素材追加1件から、対象媒体分の告知文と素材辞典記事の下書きが生成されること | FR-401、FR-402 |
| AC-06 | 秘匿情報がログおよび公開成果物に出力されていないこと | NFR-501、NFR-507 |
| AC-07 | 任意の自動処理について、実行ログから実施経緯を追跡できること | FR-502、NFR-301 |
| AC-08 | 自動化を見送った、または人間へ戻した業務について、判断理由が記録されていること | FR-503 |
AC-08は他の基準と性質が異なる。自動化の達成度ではなく、判断の記録が残っていることを問うものであり、本プロジェクトの目的(判断力を実績として示すこと)に直接対応する。
10. トレーサビリティマトリクス
| 要求ID | 対応する要件ID | 充足状況 |
|---|---|---|
| REQ-001 | FR-102、FR-103、FR-104、FR-105、FR-107 | 充足 |
| REQ-002 | FR-101 | 充足 |
| REQ-003 | FR-401、FR-402、NFR-203、NFR-205 | 充足 |
| REQ-004 | FR-404 | 充足 |
| REQ-005 | FR-201、FR-202、NFR-202 | 充足 |
| REQ-006 | FR-204、NFR-104 | 充足 |
| REQ-007 | FR-205 | 充足 |
| REQ-008 | FR-301、FR-302 | 充足 |
| REQ-009 | FR-505 | 充足 |
| REQ-010 | FR-303、NFR-103 | 充足 |
| REQ-011 | FR-304、FR-305、NFR-304 | 充足 |
| REQ-012 | FR-203、NFR-204 | 充足 |
| REQ-013 | FR-402、FR-403 | 充足 |
| REQ-014 | FR-501、NFR-302 | 充足 |
| REQ-015 | FR-502、NFR-301 | 充足 |
| REQ-016 | FR-503、NFR-302、NFR-403 | 充足 |
| REQ-017 | FR-106 | 充足 |
| REQ-018 | NFR-503 | 充足 |
| REQ-019 | NFR-504 | 充足 |
| REQ-020 | NFR-501、NFR-502、NFR-507 | 充足 |
| REQ-021 | FR-504、NFR-505 | 充足 |
| REQ-022 | NFR-201 | 充足 |
| REQ-023 | NFR-102 | 充足 |
| REQ-024 | 未展開 | 未充足(優先度Could。本版では要件化しない) |
REQ-024を除くすべての要求が要件へ展開されている。REQ-024は優先度Couldであり、本版では要件化を見送る。
11. 未決事項
要求分析書9章のOPEN-01からOPEN-04を継承する。本書で新たに発生した未決事項を以下に追加する。
| 番号 | 未決事項 | 決定期限 | 決定者 |
|---|---|---|---|
| OPEN-05 | 3Dモデル化に用いる外部サービスの自動連携可否(FR-105、工程7) | 該当機能の設計着手まで | Claudeが調査しオーナーが承認 |
| OPEN-06 | 各SNS媒体への配信を自動実行できるか、下書き生成までに留めるか(FR-404) | 該当機能の設計着手まで | オーナー |
| OPEN-07 | 週次運用レポートの配信先(記事、通知、その他) | Phase 1の設計着手まで | オーナー |
| OPEN-08 | 回帰テストに用いるテスト基盤の選定 | Phase 1の設計着手まで | Claudeが案を作成しオーナーが承認 |
OPEN-01に対する推奨
要求分析書OPEN-01(最初に着手する対象業務)について、本書の分析結果を踏まえた推奨を以下に示す。最終決定はオーナーが行う。
推奨: 素材追加業務の自動化(FR-101からFR-104)を先行させる。
理由は3点である。
- 課題の影響度が最も高い。ISS-001は影響度「高」であり、かつ現在の主業務である
- 素材マスタ(FR-101)が他機能の前提になっている。告知文生成(FR-401)、素材辞典記事生成(FR-402)、描画性能の記録(FR-203)はいずれも素材マスタを材料元とするため、先に構築すると後続の設計が単純になる
- 週次運用レポート(FR-303)は集約先であり、集約対象が存在しない段階で構築しても報告する内容が乏しい
ただし、検知の欠落(要求分析書4.2 系統2)は最終ゴールに対する直接の阻害要因であるため、通し回帰テスト(FR-201)を素材追加自動化と並行して整備することを推奨する。素材追加を自動化しながら動作確認を人手に残すと、自動化した分だけ確認の負荷がオーナーへ集中し、かえって悪化するためである。
以上