―PdM／PM が会社資産として残すための実務手順 ―
AIプロジェクトは「モデルが動いたら終わり」ではありません。
重要なのは、誰が見ても分かり、引き継げる状態でプロジェクトを保存することです。本稿は、ビジネス実務者（PdM／PM／事業責任者）が主体となってプロジェクトフォルダを設計・運用するための手順を解説します。
本ブログで得られること
- 会社に残すべきフォルダ構成
- 各フォルダに必ず置くべきドキュメントとその目的
- 運用ルール（命名規則、権限、バックアップ）
- 引き継ぎチェックリストとガバナンスの運用方法
- よくある失敗と対策
1. 設計方針（最初に決めるべき考え方）
- 業務ファースト：何のためのAIなのか（誰が何をどう改善するか）を起点にする。
- 可視化・説明責任：判断根拠と意思決定の履歴を残す。
- 再現性：将来の改善や再現ができることを前提にドキュメント化する。
- 運用前提：納品＝終わりではなく、運用・監視・改善までを設計する。
これらの設計方針を書面で固定してからフォルダを作成します。
2. 推奨フォルダ構成
まずトップレベルの名前は「AIプロジェクト_案件名」として下記構成を推奨します。
- 00_プロジェクト概要
- 01_要件定義
- 02_設計
- 03_データ
- 04_モデル
- 05_納品物
- 06_運用
- 99_アーカイブ
各フォルダの役割は次節で詳述します。命名は日本語で統一し、並び順が自然にプロジェクトの時系列（概要→要件→設計→実装→納品→運用→履歴）になるようにします。
3. 各フォルダに入れるべきもの
00_プロジェクト概要
目的：
初めて触る人が1分で理解できる要約を置く場所。
必須ドキュメント：
プロジェクト概要（目的・背景・期待効果）、成功条件（業務KPI）、スコープ（やらないこと明示）、関係者一覧（責任者・承認者・連絡先）、ロードマップ（主要マイルストーン）。
使い方：
キックオフ資料として常に最新版を置く。主要変更は履歴を残す。
01_要件定義
目的：
クライアント/事業側の要求を業務に効く形で固定する。
必須ドキュメント：
業務要件（現状フロー・課題）、AI要件（何を提供するか、提供しないこと）、成功基準（KPI の数値や採用判定基準）、制約（データ・法務・予算・期限）。
使い方：
実装や評価がブレたらここに立ち戻り、判断軸として参照する。
02_設計
目的：
実装チームが迷わず作業できる設計を残す。
必須ドキュメント：
システム構成（図）、入出力仕様（誰がどの形式で受け取るか）、運用前提（バッチ頻度、遅延許容）、UI/レポート仕様（画面や帳票のサンプル）。
使い方：
実装前の合意書。設計変更は差分を明記。
03_データ
目的：
データの由来・定義・問題点を誰でも追える状態にする。
必須ドキュメント：
データ一覧（ソース・更新頻度・保存場所）、データ定義（カラム説明・単位）、前処理ルール（欠損・外れ値の扱い）、データ課題ログ（発見→対応履歴）。
注意点：
個人情報や機微情報の扱いは法務ポリシーに従うこと。
04_モデル
目的：
モデルの選定理由・性能・制約を業務側が理解できる形で残す。
必須ドキュメント：
モデル仕様（目的・入力・出力・想定利用）、評価レポート（評価指標と解釈、限界）、再現手順（誰でも同じ結果をたどるための概要）、依存関係（環境の要点）。
使い方：
モデル更新・再学習の根拠と履歴管理に使う。
05_納品物
目的：
クライアントが業務に取り入れられる形で成果を届ける。
必須ドキュメント：
納品サンプル（出力例）、利用ガイド（業務担当者向け操作・解釈ルール）、受け入れ基準。
使い方：
契約上の検収資料・利用トレーニングに使用する。
06_運用
目的：
納品後もAIが安定して使われるための運用設計を置く。
必須ドキュメント：
日常運用フロー（誰がいつ何をチェックするか）、モニタリング指標（主要KPI・データ品質指標）、再学習計画（トリガー条件、頻度）、障害履歴（インシデントログ）。
運用ルール例：
週次チェックの担当・頻度を明示する（例：毎週月曜に○○が指標確認）。
99_アーカイブ
目的：
過去の判断や旧仕様を保存し、理由を辿れるようにする。
必須ドキュメント：
旧仕様、廃止モデル、過去の議事録・意思決定メモ。
運用：
アーカイブは読み取り専用にする・削除は管理者承認にする。
4. 実務上の運用ルール（PdM/PM が決めるべき事項）
- 保存場所の決定：会社の標準共有領域（例：SharePoint/Google Drive/Box）を使用。コードは別にGit管理する運用方針を明記。
- アクセス設計：編集権限はコアメンバーに限定。閲覧は広め。重要操作（削除など）は管理者承認。
- 命名規則：ドキュメントは「YYYY-MM-DD_内容_vX.Y」の形式で保存。ファイル名に日付を必須化。
- ファイル形式：ドキュメントは Markdown（.md）か PDF、表は Excel。理由：差分と検索性。
- 変更管理：主要ドキュメントの更新は「変更履歴」を残す。大きな設計変更は承認フローを通す。
- バックアップ：重要フォルダは週次でスナップショットを残す。
- オンボーディング：新担当向けチェックリストを整備（後述）。
- 遵守事項：個人情報保護、契約・法務の制約は必ず添付して運用する。
5. 引き継ぎ・オンボーディングチェックリスト（必須）
新しい担当者が来たときの「初日5分チェック」：
- 00_プロジェクト概要の「プロジェクト概要」を読む（目的・KPI・スコープ）
- 01_要件定義の「AI要件」で期待されるアウトカムを確認
- 02_設計の「出力仕様」を確認（納品物の形式）
- 04_モデルの「モデル仕様」で利用上の制約を把握
- 06_運用の「運用フロー」で定常作業を把握（週次・月次の担当）
引き継ぎ完了時は「引継ぎ完了チェックリスト」に担当者名と日付を記録しておく。
6. よくある失敗パターンと対策（実務の教訓）
- READMEだけ作られて中身が空 → 対策：必須ドキュメント一覧を定義し、未完はTODOラベルを付けて週次で消化する。
- データが担当者PCに散在 → 対策：生データは必ず会社クラウドへ。手元にある場合のルールを明示（消去・転送手続き）。
- コードはあるが実行環境が不明 → 対策：依存関係や実行手順は必須欄にする。運用担当が実行できるレベルの要約を付ける。
- 運用ルールがないため納品後放置 → 対策：運用フローを納品条件に含め、検収時に運用トレーニングを実施。
- 誰が意思決定するか不明 → 対策：関係者一覧に「意思決定者」「承認者」を明記し、意思決定フローを図示する。
7. すぐ使える短縮チェックリスト（PdM/PM 用：今すぐやること）
- プロジェクトルート（AIプロジェクト_案件名）を作る（共有領域上）
- 00_プロジェクト概要に「プロジェクト概要」「関係者一覧」「ロードマップ」を置いてチームに通知
- 01_要件定義に「業務要件」「AI要件」を入れてクライアント承認を得る
- 02_設計に「出力仕様」を入れて、業務側とサンプル出力で確認
- 06_運用に「週次チェック項目」と担当者を決める
- 引き継ぎチェックリストを作り、リポジトリに置く
これだけでプロジェクトの透明性は大きく改善します。
8. 提案（PdM/PM の運用改善アクション）
- 毎週の短い「ドキュメント・デッドライン」を設定（例：水曜17:00に週次更新）。
- 月次でドキュメント監査（未完リストを確認・割当）。
- 重要ドキュメントはレビュー承認者を決める（臨時変更は承認必須）。
- 初回納品時に「運用トレーニング」と「操作マニュアル」を必須で実施させる。
9. まとめ（ビジネスでの価値）
フォルダを作ること自体は簡単です。しかし真の価値は、そのフォルダが組織で使われ続け、引き継がれることにあります。PdM／PM は「フォルダ作成者」ではなく「フォルダを生きた資産にする人」。まずは「プロジェクト概要」を完成させてチームに共有することを今日のアクションにしてください。
Data Nexus Science 
コメントを残す