目次

イントロダクション
プロジェクト初期段階
プロジェクト計画段階
プロジェクト実行段階
プロジェクト終結段階
AI/LLM プロジェクト特有の考慮事項
実用的なツールとテンプレート
参考リソースとリンク

イントロダクション

プロジェクトマネジメントの重要性

プロジェクトマネジメントは、限られた時間・予算・人的リソースの中で、品質を維持しながら目標を達成するための体系的なアプローチです。特にIT業界では、要件の変更、技術的課題、ステークホルダー間の認識のずれなど、多くの不確実性に対処する必要があります。

効果的なプロジェクトマネジメントにより以下のメリットが得られます：

プロジェクトの成功率向上
リソースの効率的な活用
リスクの早期発見と対応
ステークホルダーとの良好な関係構築
チームメンバーのモチベーション維持

日本のIT開発現場における特有の課題

詳細な仕様書と計画を重視する文化
「暗黙の了解」によるコミュニケーション
変更に対する柔軟性とドキュメント重視のバランス
多層的な承認プロセス
ベンダー管理と責任分界点の明確化

プロジェクト初期段階

プロジェクト憲章の作成

プロジェクト憲章は、プロジェクトの公式な開始を宣言し、プロジェクトマネージャーに権限を与える文書です。

プロジェクト憲章テンプレート

プロジェクト名: [プロジェクト名]

プロジェクトの背景と目的:

現状の課題
解決すべき問題
期待される効果

プロジェクトのスコープ:

含まれるもの
含まれないもの
制約条件

主要マイルストーン:

要件定義完了: [日付]
設計完了: [日付]
開発完了: [日付]
テスト完了: [日付]
本番リリース: [日付]

主要ステークホルダー:

スポンサー: [氏名・役職]
プロジェクトマネージャー: [氏名]
主要メンバー: [氏名・役割]
関連部門: [部門名・責任者]

予算概要:

人件費: [金額]
ハードウェア/ソフトウェア: [金額]
外部委託費: [金額]
予備費: [金額]

成功基準:

[具体的で測定可能な基準を列挙]

承認:

プロジェクトスポンサー: [署名]
部門責任者: [署名]
プロジェクトマネージャー: [署名]

ステークホルダー分析

ステークホルダー分析は、プロジェクトに影響を与える、または影響を受ける個人やグループを特定し、その関心事と影響力を評価するプロセスです。

ステークホルダー分析マトリックス

ステークホルダー	役割/部署	関心事	影響力（高/中/低）	期待	コミュニケーション方法	頻度
[氏名]	[役割]	[関心事]	[影響力]	[期待]	[方法]	[頻度]

ステークホルダーマッピング

影響力と関心度に基づいて、ステークホルダーを4つのカテゴリに分類します：

高影響力・高関心: 密接に管理（定期的な面談、詳細な報告）
高影響力・低関心: 満足させる（主要な意思決定に関与）
低影響力・高関心: 情報を提供する（進捗報告、会議に含める）
低影響力・低関心: 監視する（一般的な更新情報のみ）

要件定義プロセス

要件収集手法

インタビュー:
- 主要ステークホルダーとの1対1または小グループでの対話
- 開かれた質問と構造化された質問の組み合わせ
- 議事録作成と確認
ワークショップ:
- ファシリテーターが主導する共同セッション
- 参加者: エンドユーザー、ビジネス代表者、技術チーム
- ユーザーストーリーやユースケースの作成
観察:
- 現在のワークフローや業務プロセスの直接観察
- 「暗黙知」の把握に効果的
プロトタイピング:
- 早期のフィードバックを得るための簡易モデル作成
- 特にUI/UXの要件に有効

要件文書テンプレート

1. はじめに

目的
対象読者
用語定義
参照文書

2. システム概要

現行システムの説明（既存システムの場合）
新システムの目的
ユーザープロファイル

3. 機能要件

機能カテゴリ別の詳細要件
優先順位（Must/Should/Could/Won't）
ユーザーストーリーまたはユースケース

4. 非機能要件

パフォーマンス要件
セキュリティ要件
可用性要件
スケーラビリティ要件
保守性要件
互換性要件

5. 外部インターフェース要件

ユーザーインターフェース
ハードウェアインターフェース
ソフトウェアインターフェース
通信インターフェース

6. データ要件

エンティティ関連図
データディクショナリ
データ変換要件
データ保持要件

7. 制約条件

規制遵守要件
ハードウェア制限
ソフトウェア制限
その他の制約

8. 添付資料

画面モックアップ
レポート形式
プロセスフロー図

プロジェクト計画段階

WBS（作業分解構造）の作成

WBSは、プロジェクトの全体スコープを管理可能な作業パッケージに分解するためのツールです。

WBS作成のステップ

プロジェクトの最終成果物を特定する
- システム全体、モジュール、ドキュメント等
主要な成果物をフェーズや機能領域に分解する
- 要件定義、設計、開発、テスト、展開等
各フェーズをさらに詳細な作業に分解する
- 例: テスト → 単体テスト、結合テスト、システムテスト、受入テスト
作業パッケージレベルまで分解する
- 1人が責任を持ち、10-80時間程度で完了できる大きさ
WBS辞書を作成する
- 各作業パッケージの詳細説明、担当者、所要時間、前提条件等

WBSの例（IT開発プロジェクト）

1. プロジェクト管理
   1.1 プロジェクト計画
   1.2 ステークホルダー管理
   1.3 リスク管理
   1.4 進捗管理
   1.5 変更管理

2. 要件定義
   2.1 現状分析
   2.2 ユーザー要件収集
   2.3 機能要件定義
   2.4 非機能要件定義
   2.5 要件レビュー・承認

3. 設計
   3.1 アーキテクチャ設計
   3.2 データベース設計
   3.3 UIデザイン
   3.4 API設計
   3.5 設計レビュー・承認

4. 開発
   4.1 開発環境セットアップ
   4.2 モジュール1開発
      4.2.1 コーディング
      4.2.2 単体テスト
   4.3 モジュール2開発
      4.3.1 コーディング
      4.3.2 単体テスト
   4.4 コードレビュー

5. テスト
   5.1 テスト計画策定
   5.2 テストケース作成
   5.3 結合テスト
   5.4 システムテスト
   5.5 性能テスト
   5.6 ユーザー受入テスト

6. 展開
   6.1 展開計画策定
   6.2 ユーザーマニュアル作成
   6.3 運用マニュアル作成
   6.4 トレーニング実施
   6.5 本番環境へのデプロイ

7. プロジェクト終結
   7.1 最終成果物の引き渡し
   7.2 レッスンズラーンド
   7.3 プロジェクト評価
   7.4 プロジェクト文書のアーカイブ

スケジュール管理

ガントチャートの作成手順

タスクリストの作成
- WBSの作業パッケージをベースに
- タスク名、期間、先行タスク、担当者を明確に
依存関係の特定
- 終了-開始（最も一般的）
- 開始-開始
- 終了-終了
- 開始-終了
クリティカルパスの特定
- プロジェクト全体の期間に影響するタスク群
- 余裕時間のないタスク列
リソースの割り当て
- タスクごとに必要なリソースを特定
- リソースの過負荷を避ける調整
マイルストーンの設定
- 主要な成果物の完了点
- ステークホルダーへの報告ポイント

スケジュール作成のための見積もり手法

アナロジー見積もり
- 過去の類似プロジェクトのデータに基づく
- 簡易だが、プロジェクト固有の要素を見落とす可能性
パラメトリック見積もり
- 統計的関係に基づく
- 例: ファンクションポイント法、COCOMO II
三点見積もり
- 楽観的（O）、最も可能性の高い（M）、悲観的（P）
- 期待値 = (O + 4M + P) / 6
- 標準偏差 = (P - O) / 6
ボトムアップ見積もり
- 各作業パッケージを詳細に見積もる
- 時間がかかるが最も正確

リソース計画と割り当て

リソース計画のステップ

必要なスキルの特定
- タスクごとに必要なスキルセットをリスト化
- スキルマトリックスの作成
利用可能なリソースの評価
- 社内リソースのスキル・稼働状況確認
- 外部リソースの必要性検討
リソース割り当て表の作成
- タスク別、週別または月別の割り当て
- リソースの負荷平準化
リソースヒストグラムの作成
- リソースの過負荷または未活用の視覚化
- リソースのピーク時期の特定

RACI表（責任分担表）

タスク	プロジェクトマネージャー	アーキテクト	開発者	テスター	顧客
要件定義	A	C	I	I	R
アーキテクチャ設計	A	R	C	I	C
開発	A	C	R	I	I
テスト	A	I	C	R	C
展開	A	C	R	C	I

R = Responsible（実行責任者）
A = Accountable（説明責任者）
C = Consulted（相談先）
I = Informed（報告先）

リスク管理計画

リスク管理のプロセス

リスクの特定
- ブレインストーミング
- チェックリスト
- 過去のプロジェクト経験
- SWOT分析
リスクの分析と評価
- 影響度（1-5）
- 発生確率（1-5）
- リスクスコア = 影響度 × 発生確率
リスク対応計画
- 回避: リスクの原因を取り除く
- 転嫁: リスクを第三者に移す
- 軽減: 影響または確率を下げる
- 受容: リスクを受け入れる
リスクのモニタリングと制御
- 定期的なリスクレビュー
- 新たなリスクの特定
- 対応計画の有効性評価

リスク登録簿テンプレート

リスクID	リスク説明	カテゴリ	影響度 (1-5)	確率 (1-5)	スコア	対応戦略	対応アクション	担当者	ステータス
R001	[説明]	[カテゴリ]	[影響度]	[確率]	[スコア]	[戦略]	[アクション]	[担当者]	[ステータス]

プロジェクト実行段階

進捗管理手法

アジャイル/スクラム方式

スクラムの主要イベント:

スプリント計画
- タイムボックス: 8時間（4週間スプリントの場合）
- 目的: スプリントで何を行うかを計画
- 成果物: スプリントバックログ
デイリースクラム
- タイムボックス: 15分
- 目的: 進捗の確認、障害の特定
- 3つの質問:
  - 昨日何をしたか
  - 今日何をするか
  - 障害はあるか
スプリントレビュー
- タイムボックス: 4時間（4週間スプリントの場合）
- 目的: 完成した成果物のデモと検証
- 成果物: レビューされた成果物、次のスプリントの方向性
スプリントレトロスペクティブ
- タイムボックス: 3時間（4週間スプリントの場合）
- 目的: プロセス改善の機会を特定
- 成果物: 改善計画

アジャイルプロジェクト管理ツール:

Jira
Trello
Azure DevOps
GitLab
Redmine

カンバン方式

カンバンボードの基本構造:

ToDo: これから着手するタスク
進行中: 現在作業中のタスク
完了: 完了したタスク

カンバンの原則:

仕掛品の制限（WIP制限）
フローの最適化
プロセスの可視化
明示的なポリシー
フィードバックループ

ウォーターフォール方式の進捗管理

EVM（アーンドバリューマネジメント）
- PV（計画値）: 計画された作業の予算
- EV（獲得値）: 完了した作業の予算
- AC（実績値）: 実際にかかったコスト
- SPI = EV / PV（スケジュール効率指数）
- CPI = EV / AC（コスト効率指数）
マイルストーン管理
- 主要マイルストーンの達成状況
- マイルストーントレンドチャート
S曲線分析
- 計画進捗と実績進捗の比較
- 差異分析とトレンド予測

品質管理プロセス

品質保証活動

レビュー
- 要件レビュー
- 設計レビュー
- コードレビュー
- テスト計画レビュー
テスト戦略
- 単体テスト（開発者自身）
- 結合テスト（テストチーム）
- システムテスト（テストチーム）
- ユーザー受入テスト（エンドユーザー）
- 非機能テスト（性能、セキュリティなど）
品質メトリクス
- 欠陥密度（kLOCあたりの欠陥数）
- 欠陥発見率・修正率
- テストカバレッジ
- コードの複雑度
継続的インテグレーション/継続的デリバリー（CI/CD）
- 自動化されたビルド
- 自動化されたテスト
- 自動化されたデプロイ

テスト計画テンプレート

1. はじめに

テストの目的
テスト対象範囲
テスト戦略概要

2. テスト環境

ハードウェア構成
ソフトウェア構成
テストデータ

3. テストレベル

単体テスト計画
結合テスト計画
システムテスト計画
受入テスト計画

4. テスト種別

機能テスト
性能テスト
セキュリティテスト
互換性テスト
回復性テスト

5. テストスケジュール

テスト実施タイムライン
マイルストーン

6. テスト実施体制

役割と責任
リソース計画

7. テスト成果物

テストケース
テスト報告書
欠陥管理

8. リスクと対策

テスト実施上のリスク
緩和策

チームコミュニケーション戦略

コミュニケーション計画テンプレート

コミュニケーション項目	目的	頻度	形式	参加者	責任者	成果物
プロジェクトキックオフ	プロジェクト開始の共通理解	プロジェクト開始時	対面/Web会議	全ステークホルダー	PM	キックオフ資料、議事録
ステータス会議	進捗確認、課題共有	週次	Web会議	コアチーム	PM	進捗報告書、議事録
ステアリングコミッティ	重要決定事項の承認	月次	対面/Web会議	経営層、PM	スポンサー	決定事項記録
技術検討会	技術的課題の解決	必要に応じて	対面/Web会議	技術チーム	アーキテクト	技術検討書
日次スタンドアップ	日々の進捗確認	日次	対面/チャット	開発チーム	スクラムマスター	-
全体メール	全体への情報共有	隔週	メール	全関係者	PM	メール本文

効果的なコミュニケーション手段

同期コミュニケーション
- 対面会議
- Web会議（Zoom, Teams, WebEx）
- 電話
非同期コミュニケーション
- メール
- チャット（Slack, Teams, Chatwork）
- 課題管理システム（Jira, Redmine）
- ドキュメント共有（Confluence, SharePoint）
情報共有の原則
- 必要最小限の関係者に
- 明確で簡潔な情報
- 適切なタイミング
- 適切なチャネル

変更管理プロセス

変更リクエストワークフロー

変更リクエストの提出
- 変更の説明
- 変更の理由
- 優先度
- 期待される影響
影響分析
- スコープへの影響
- スケジュールへの影響
- コストへの影響
- リソースへの影響
- 品質への影響
変更の評価と決定
- 評価基準
- 承認者
- 決定プロセス
変更の実装
- 実装計画
- 変更後の検証
変更の記録とコミュニケーション
- 変更履歴の更新
- 関係者への通知

変更リクエストフォームテンプレート

変更リクエスト ID: CR-[連番]

提出者: [氏名]

提出日: [日付]

変更タイプ:

要件変更
スケジュール変更
範囲変更
リソース変更
その他

変更の説明:
[詳細な説明]

変更の理由:
[理由]

優先度:

高（プロジェクトの成功に不可欠）
中（重要だが緊急ではない）
低（あれば好ましい）

影響分析:

スコープへの影響: [説明]
スケジュールへの影響: [説明]
コストへの影響: [説明]
リソースへの影響: [説明]
品質への影響: [説明]
リスクへの影響: [説明]

代替案:
[代替案があれば記載]

決定:

承認
条件付き承認
却下
保留

決定理由:
[理由]

承認者: [氏名]

承認日: [日付]

プロジェクト終結段階

成果物の検証と受け入れ

受け入れ基準

機能要件の充足
- 全ての要件が実装されている
- 要件通りに動作する
非機能要件の充足
- パフォーマンス基準を満たす
- セキュリティ基準を満たす
- 可用性基準を満たす
品質基準の充足
- 重大な未解決の欠陥がない
- テスト合格率が基準を超えている
ドキュメント完備
- ユーザーマニュアル
- 運用マニュアル
- システム設計書
- テスト結果報告書

受け入れテストプロセス

受け入れテスト計画の作成
- テスト対象
- テスト環境
- テストシナリオ
- 合格基準
受け入れテストの実施
- エンドユーザーによるテスト
- 運用担当者によるテスト
欠陥の報告と修正
- 欠陥の重要度評価
- 修正計画の策定
- 修正確認テスト
受け入れ判定
- 合格
- 条件付き合格
- 不合格

最終受け入れ文書テンプレート

プロジェクト名: [プロジェクト名]

検証期間: [開始日] 〜 [終了日]

検証実施者: [氏名・役職]

検証項目:

項目	合格基準	結果	備考
[機能1]	[基準]	[合/否]	[備考]

未解決課題:

最終判定:

無条件受け入れ
条件付き受け入れ
再テスト後受け入れ
受け入れ不可

特記事項:
[特記事項]

受け入れ承認:

顧客代表: [署名]
プロジェクトマネージャー: [署名]
品質保証担当: [署名]

レッスンズラーンド（振り返り）

レッスンズラーンドミーティングの進め方

準備
- 参加者の選定
- 事前アンケート
- 場所・時間の確保
ミーティングの進行
- ファシリテーターの指名
- グラウンドルールの設定
- 非難や責任追及をしない
テーマ別ディスカッション
- うまくいったこと
- 課題となったこと
- 次回に活かすべきこと
アクション策定
- 組織として改善すべき点
- 具体的なアクション

レッスンズラーンドレポートテンプレート

プロジェクト概要:

プロジェクト名
期間
成果
チーム構成

うまくいったこと:

分野	内容	理由	今後への提案
[分野]	[内容]	[理由]	[提案]

課題となったこと:

分野	問題	原因	対策提案
[分野]	[問題]	[原因]	[対策]

改善アクション:

アクション	担当	期限	進捗確認方法
[アクション]	[担当]	[期限]	[確認方法]

総括:
[プロジェクト全体の評価と今後への提言]

プロジェクト文書化と知識移管

文書化すべき項目

プロジェクト計画文書
- プロジェクト憲章
- プロジェクト計画書
- WBS
- スケジュール
要件・設計文書
- 要件定義書
- 基本設計書
- 詳細設計書
- データベース設計書
- インターフェース設計書
テスト文書
- テスト計画書
- テストケース
- テスト結果報告書
運用・保守文書
- 運用マニュアル
- 保守マニュアル
- 障害対応手順書
プロジェクト管理文書
- 進捗報告書
- 議事録
- リスク管理表
- 課題管理表
- 変更管理表

知識移管計画テンプレート

移管対象:

システム運用
アプリケーション保守
データベース管理
ユーザーサポート

移管先チーム:

[チーム名/部署名]
[担当者]

移管スケジュール:

移管準備期間: [日付]〜[日付]
移管実施期間: [日付]〜[日付]
移管後サポート期間: [日付]〜[日付]

移管方法:

ドキュメントベースの知識移管
ハンズオントレーニング
シャドウイング
Q&Aセッション

成功基準:

[具体的な基準]

リスクと対策:

AI/LLMプロジェクト特有の考慮事項

データ収集・管理の特殊性

データ要件定義

データの種類と量
- テキストデータ（構造化/非構造化）
- 画像データ
- 音声データ
- 時系列データ
- 必要なサンプル数
データの品質基準
- 完全性（欠損値の許容範囲）
- 正確性（エラーの許容範囲）
- 一貫性（矛盾の許容範囲）
- 適時性（データの鮮度）
- 多様性（バイアス防止）
データ前処理要件
- クレンジング（ノイズ除去、外れ値処理）
- 正規化/標準化
- 特徴抽出
- データ拡張
データプライバシーとセキュリティ
- 個人情報の取り扱い
- 匿名化手法
- アクセス制御
- データ保護対策

データ管理計画

データ収集方法
- 既存データの利用
- 新規データの取得（クローリング、API等）
- ラベリング方法（内製/外注）
データバージョン管理
- バージョニング手法
- データリネージの追跡
- 変更履歴の管理
データストレージと処理基盤
- ストレージソリューション
- 処理インフラ（オンプレミス/クラウド）
- スケーラビリティ要件
データガバナンス
- 責任者と役割
- ポリシーとガイドライン
- コンプライアンス対応

モデル評価指標

評価指標の選択

分類タスクの指標
- 精度（Accuracy）
- 適合率（Precision）
- 再現率（Recall）
- F1スコア
- AUC-ROC
- 混同行列
回帰タスクの指標
- MAE（平均絶対誤差）
- MSE（平均二乗誤差）
- RMSE（二乗平均平方根誤差）
- R²（決定係数）
生成タスクの指標
- BLEU（機械翻訳）
- ROUGE（要約）
- Perplexity（言語モデル）
- 人間評価（主観評価）
特化指標
- レイテンシ
- 推論速度
- モデルサイズ
- メモリ使用量

モデル評価プロセス

評価データセット作成
- トレーニング/バリデーション/テストの分割
- クロスバリデーション戦略
- 時系列データの特別な扱い
ベースラインの設定
- 単純モデルの構築
- 既存システムの性能
- 業界スタンダード
モデル比較手法
- A/Bテスト設計
- 統計的有意性テスト
- 複数指標の総合評価
継続的評価
- モニタリング指標
- 性能劣化検出
- 再トレーニング基準

倫理的考慮事項とコンプライアンス

倫理的フレームワーク

公平性と非差別
- バイアス検出手法
- 公平性指標
- バイアス緩和戦略
説明可能性と透明性
- モデル解釈手法
- 決定プロセスの説明
- ドキュメント化要件
プライバシーとデータ保護
- 差分プライバシー
- 連合学習
- データ最小化原則
安全性と堅牢性
- 敵対的攻撃への耐性
- フォールバックメカニズム
- 安全対策

コンプライアンスチェックリスト

法規制対応
- GDPR（EU）
- CCPA（カリフォルニア）
- 個人情報保護法（日本）
- AI特有の規制
業界標準とガイドライン
- IEEE倫理ガイドライン
- 業界別AI倫理原則
- 組織内ポリシー
ドキュメント要件
- モデルカード
- データシート
- 倫理的影響評価
継続的モニタリングと監査
- 定期的な倫理審査
- 実運用でのモニタリング
- 是正措置プロセス

実用的なツールとテンプレート

プロジェクト計画書テンプレート

1. プロジェクト概要

プロジェクト名
背景と目的
スコープ
制約条件

2. プロジェクト体制

組織体制図
役割と責任
ステークホルダーリスト

3. プロジェクトアプローチ

開発方法論（ウォーターフォール/アジャイル/ハイブリッド）
フェーズ構成
主要マイルストーン

4. プロジェクトスケジュール

WBS概要
ガントチャート
クリティカルパス

5. リソース計画

人的リソース計画
機材・設備計画
予算計画

6. 品質管理計画

品質目標
品質保証活動
品質管理指標

7. リスク管理計画

主要リスク
対応戦略
モニタリング方法

8. コミュニケーション計画

コミュニケーション方法
報告体制
会議体系

9. 変更管理計画

変更管理プロセス
変更承認フロー
変更影響評価方法

10. プロジェクト終結計画

成果物引き渡し計画
受け入れ基準
移管計画

進捗報告テンプレート

報告期間: [開始日]〜[終了日]

1. 全体状況

進捗状況サマリー
スケジュール状況（予定通り/遅延/前倒し）
予算状況（予定通り/超過/余裕）

2. マイルストーン状況

マイルストーン	予定日	実績/予測日	状況	備考
[マイルストーン]	[予定日]	[実績/予測日]	[状況]	[備考]

3. 今期の主な成果

[成果1]
[成果2]

4. 課題・リスク状況

ID	課題/リスク	影響	対応状況	担当	期限
[ID]	[内容]	[影響]	[対応状況]	[担当]	[期限]

5. 次期の予定

[予定1]
[予定2]

6. 支援・判断事項

[支援/判断が必要な事項]

リスク管理表

リスクID	カテゴリ	リスク内容	発生確率 (1-5)	影響度 (1-5)	リスクスコア	対応戦略	対応アクション	担当者	ステータス	最終更新日
R001	[カテゴリ]	[内容]	[確率]	[影響度]	[スコア]	[戦略]	[アクション]	[担当者]	[ステータス]	[更新日]

カテゴリ例:

技術
スケジュール
リソース
要件
ベンダー
経営・組織
外部環境

対応戦略例:

回避
転嫁
軽減
受容

ステータス例:

監視中
対応中
対応済
発生済
終結

課題管理表

課題ID	課題内容	発生日	影響範囲	優先度	ステータス	対応アクション	担当者	期限	更新日
I001	[内容]	[日付]	[範囲]	[優先度]	[ステータス]	[アクション]	[担当者]	[期限]	[更新日]

優先度例:

高: プロジェクトの進行に重大な影響がある
中: 解決しないと一部の作業に影響がある
低: 解決が望ましいが、直接的な影響は小さい

ステータス例:

オープン: 未着手
調査中: 原因分析中
対応中: 解決に向けて作業中
解決済: 対応完了
クローズ: 検証完了

参考リソースとリンク

プロジェクトマネジメント標準・手法

PMBOK（Project Management Body of Knowledge）
- PMI（Project Management Institute）が策定
- PMI日本支部
PRINCE2（PRojects IN Controlled Environments 2）
- 英国政府が開発した方法論
- PRINCE2公式サイト
スクラムガイド
- スクラムの公式ガイド
- スクラムガイド（日本語版）
IPAプロジェクトマネジメント知識体系
- 日本の情報処理推進機構（IPA）による知識体系
- IPA PM知識体系

プロジェクトマネジメントツール

総合プロジェクト管理ツール
- Microsoft Project
- Jira
- Redmine
- Asana
- Trello
アジャイル開発支援ツール
コミュニケーションツール
ドキュメント共有ツール

日本のIT開発プロジェクトに関する参考資料

IPAソフトウェア開発関連ドキュメント
- 共通フレーム2013
- システム再構築を成功に導くユーザガイド
経済産業省ガイドライン
- システム管理基準
- 情報システム・モデル取引・契約書
JISA（情報サービス産業協会）
- DXプロジェクト推進ガイドライン

AI/LLM関連プロジェクトの参考資料

機械学習プロジェクトのベストプラクティス
- Google MLOps ガイド
- Microsoft AI ビジネススクール
AI倫理・ガバナンス
- 日本AI戦略
- AIネットワーク社会推進会議報告書
オープンソースAIツール