「本番環境に反映されたプログラムは、このバージョンで合っていますか？」

プロジェクトでは、このような確認が必要になる場面が数多くあります。

もし成果物のバージョンや変更履歴を適切に管理できていなければ、古い設計書をもとに開発したり、誤ったプログラムをリリースしたりするリスクがあります。

こうした問題を防ぐために重要なのが構成管理（Configuration Management）です。

この記事では、構成管理の意味や目的、変更管理との違い、実務での活用方法までわかりやすく解説します。

一言でいうと

構成管理とは、「成果物の内容・バージョン・変更履歴を管理し、常に正しい状態を維持するための仕組み」です。

構成管理とは

構成管理とは、プロジェクトで作成される成果物（設計書・プログラム・テスト仕様書・マニュアルなど）を識別し、その変更履歴やバージョンを管理する活動です。

PMBOK®では、構成管理は統合変更管理を支える重要な仕組みの一つとされています。

「何が」「いつ」「誰によって」「どのように変更されたのか」を明確にすることで、成果物の整合性を保ちます。

構成管理の対象

構成管理の対象は、ソースコードだけではありません。

プロジェクトでは、さまざまな成果物が管理対象となります。

• 要求事項
• 設計書
• WBSや各種計画書
• ソースコード
• テスト仕様書・テスト結果
• マニュアル
• リリース資材
• 設定ファイル

プロジェクトの成果物全体を適切に管理することが、構成管理の目的です。

構成管理で実施する主な活動

これらを継続的に実施することで、成果物の信頼性を維持できます。

構成管理と変更管理の違い

つまり、変更管理が「変更してよいか」を管理する仕組みであるのに対し、構成管理は「変更した結果を正しく管理する」仕組みです。

実務ではこんな場面で活用される

例えば、障害が発生した際に、「本番環境にはどのプログラムがリリースされているのか」をすぐに確認できなければ、原因調査に時間がかかってしまいます。

構成管理が適切に行われていれば、対象のバージョンや変更履歴をすぐに確認でき、問題の切り分けや復旧を迅速に進められます。

また、複数人で開発を行うプロジェクトでは、最新版の成果物を全員が共有できるため、古い資料を使って作業してしまうリスクも防げます。

よくある勘違い

構成管理はGitなどのツールを使うことではない

GitやSubversionなどは構成管理を支援するツールです。

構成管理の本質は、「成果物を識別し、変更履歴や状態を管理する仕組み」にあります。

ソースコードだけ管理すれば十分ではない

設計書やテスト仕様書、マニュアルなどが更新されていなければ、成果物全体の整合性は保てません。

構成管理では、プロジェクト全体の成果物を対象として管理することが重要です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、変更管理や品質管理と関連付けて構成管理を理解することが重要です。

午後試験では、「成果物の版数管理をどのように行ったか」「変更後の成果物の整合性をどのように確保したか」といった内容を説明できると評価につながります。

構成管理は、成果物の品質と信頼性を維持するための基盤となる活動です。

PM道場のワンポイント

構成管理とは、「最新版を管理すること」ではなく、「正しいものが最新版であることを証明できる状態」を維持することです。実務では、「最新版はこちらです」というメールが何通も届き、どれが本当に最新なのか分からなくなることがあります。また、設計書だけ更新され、テスト仕様書が古いままというケースも珍しくありません。

構成管理が適切に行われていれば、「どの成果物が最新か」「どの変更要求によって更新されたのか」「誰が承認したのか」をすぐに確認できます。

優れたプロジェクトマネージャは、成果物そのものだけではなく、「成果物の信頼性」まで管理しています。

関連用語

• 変更要求
• 変更管理
• 統合変更管理
• 成果物（Deliverable）
• ベースライン
• スコープベースライン
• 品質管理
• 構成監査

まとめ

構成管理とは、成果物の内容・バージョン・変更履歴を管理し、常に正しい状態を維持するための仕組みです。

変更管理と組み合わせることで、変更の妥当性だけでなく、変更後の成果物の整合性も確保できます。

重要なのは、「最新版を保存すること」ではなく、「誰が見ても正しい成果物を利用できる状態」を維持することです。

関連記事

• 変更管理とは？
• 変更要求とは？
• 成果物（Deliverable）とは？
• ベースラインとは？

よくある質問（FAQ）

Q. 構成管理とは何ですか？

A. 成果物の内容・バージョン・変更履歴を管理し、常に正しい状態を維持するための仕組みです。

Q. 構成管理と変更管理の違いは何ですか？

A. 構成管理は成果物の状態や版数を管理する活動、変更管理は変更要求を評価・承認し、変更の実施可否を判断する活動です。

Q. 構成管理の対象はソースコードだけですか？

A. いいえ。設計書、要求事項、テスト仕様書、マニュアルなど、プロジェクトで管理すべき成果物全体が対象になります。

The post 構成管理（Configuration Management）とは？変更管理との違いを初心者向けにわかりやすく解説 first appeared on PM道場.

しかし、「反省会と何が違うの？」「失敗を書くだけではないの？」と思う方も少なくありません。

教訓（Lessons Learned）は、成功や失敗の経験を次のプロジェクトへ活かすための重要な資産です。

この記事では、教訓（Lessons Learned）の意味や目的、実施するタイミング、実務での活用方法までわかりやすく解説します。

一言でいうと

教訓（Lessons Learned）とは、「プロジェクトで得られた経験や学びを整理し、次のプロジェクトで活かすための知識」のことです。

教訓（Lessons Learned）とは

Lessons Learnedは、プロジェクトの中で経験した成功や失敗、その原因や改善策を整理し、組織の知識として残す活動です。

PMBOK®では、教訓は組織のプロセス資産（Organizational Process Assets）の一つとして位置付けられています。

単なる記録ではなく、「次回どのようにすればより良い結果になるか」を明らかにすることが目的です。

なぜ教訓が重要なのか

同じような失敗を繰り返すプロジェクトは少なくありません。

例えば、毎回「レビューが遅れた」「要件変更が多かった」という問題が発生していても、その原因や対策を共有しなければ、次のプロジェクトでも同じことが起こります。

教訓を残すことで、組織全体のプロジェクトマネジメントを継続的に改善できます。

教訓の具体例

重要なのは、「何が起きたか」ではなく、「次にどう活かすか」をまとめることです。

教訓と振り返りの違い

振り返り（Retrospective）と混同されることがありますが、それぞれ目的が異なります。

アジャイル開発では振り返りを繰り返し行い、その結果を教訓として蓄積することもあります。

教訓はプロジェクト終了時だけではない

PMBOK®では、教訓はプロジェクト終了時だけでなく、プロジェクトの途中でも継続的に収集することが推奨されています。

問題が発生した直後や重要なマイルストーンの後に記録しておくことで、より実践的な知識として活用できます。

実務ではこんな場面で活用される

例えば、設計フェーズで「レビュー前にチェックリストを使ったことで指摘件数が半減した」とします。

これを教訓として残しておけば、次のプロジェクトでも同じチェックリストを活用でき、品質向上につながります。

逆に、「設計レビューが遅れた」という事実だけを記録しても、改善にはつながりません。

よくある勘違い

教訓は失敗だけを書くものではない

成功した取り組みも重要な教訓です。

「うまくいった理由」を整理することで、成功を再現しやすくなります。

教訓は記録するだけでは意味がない

教訓は、次のプロジェクトで活用されて初めて価値があります。

共有しやすい形で蓄積し、必要なときに参照できる仕組みを整えることが重要です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、「プロジェクト完了後の振り返り」や「組織への知識共有」が論点になることがあります。

午後Ⅱ論文では、「今回の経験をどのように次のプロジェクトへ活かしたか」を説明できると、継続的改善の視点を示すことができます。

PMBOK®でも、Lessons Learned Register（教訓登録簿）を活用し、プロジェクト全体を通じて教訓を蓄積することが推奨されています。

PM道場のワンポイント

教訓とは、「何が起きたか」を記録するものではなく、「次にどう行動するか」を決めるものです。「レビューが遅れた」というのは事実です。しかし、それだけでは教訓ではありません。

「レビュー対象を事前に分割し、レビュー時間を30分以内にする」「レビュー前日にセルフチェックを実施する」といった具体的な改善策まで整理して初めて、次のプロジェクトで活かせる知識になります。

優れたプロジェクトマネージャは、過去を分析することよりも、「未来のプロジェクトが成功するための仕組み」を残すことを重視しています。

関連用語

• プロジェクト終結
• プロジェクトライフサイクル
• ナレッジマネジメント
• 継続的改善（Continuous Improvement）
• プロセス資産（OPA）
• 品質マネジメント
• リスクマネジメント
• レビュー

まとめ

教訓（Lessons Learned）とは、プロジェクトで得られた経験や学びを整理し、次のプロジェクトへ活かすための知識です。

失敗だけでなく成功事例も整理し、「なぜそうなったのか」「次にどうするか」を明確にすることが重要です。

教訓を組織の資産として活用することで、プロジェクトマネジメントの品質を継続的に向上させることができます。

関連記事

• プロジェクトライフサイクルとは？
• 品質マネジメントとは？
• リスクマネジメントとは？
• ナレッジマネジメントとは？

よくある質問（FAQ）

Q. Lessons Learnedとは何ですか？

A. プロジェクトで得られた成功や失敗の経験を整理し、次のプロジェクトで活かすための知識や教訓のことです。

Q. 教訓はプロジェクト終了後だけに作成するものですか？

A. いいえ。PMBOK®では、プロジェクト中も継続的に教訓を収集・記録することが推奨されています。

Q. 良い教訓を残すポイントは何ですか？

A. 「何が起きたか」だけでなく、「なぜ起きたのか」「次回はどう改善するのか」まで具体的に整理することです。

The post 教訓（Lessons Learned）とは？プロジェクトマネジメントでの意味や活用方法をわかりやすく解説 first appeared on PM道場.

そのため、

• 誰に情報を伝えるのか
• 何を伝えるのか
• いつ伝えるのか
• どのような方法で伝えるのか
• 問題が発生したとき、誰に報告するのか

といったことを事前に決めておくことが重要です。

これらのコミュニケーションの方針や方法を整理したものが、コミュニケーションマネジメント計画書です。

コミュニケーションマネジメント計画書は、単なる「連絡方法の一覧」ではありません。

プロジェクトに必要な情報を、必要な人へ、必要なタイミングで届けるための仕組みを設計するための文書です。

一言でいうと

コミュニケーションマネジメント計画書とは、プロジェクトにおける情報の「誰に・何を・いつ・どのように伝えるか」を定めた計画書です。

例えば、

• 週次の進捗報告は誰に行うのか
• 課題が発生した場合は誰に報告するのか
• チーム内の情報共有には何を使うのか
• 会議の議事録をどこに保管するのか
• 緊急時にはどのように連絡するのか

などをあらかじめ決めておきます。

これによって、「誰に報告すればよいのか分からない」「必要な情報が共有されていない」といったコミュニケーション上の問題を防ぎやすくなります。

コミュニケーションマネジメント計画書とは

プロジェクトでは、プロジェクトマネージャ、チームメンバー、顧客、スポンサー、経営層、外部ベンダーなど、多くのステークホルダーが関わります。

それぞれが必要としている情報は異なります。

例えば、プロジェクトマネージャは詳細な課題やリスクを把握する必要がありますが、経営層はプロジェクト全体の進捗や重要な問題を把握できればよい場合があります。

そのため、全員に同じ情報を同じ方法で伝えるのではなく、相手に応じてコミュニケーションを設計する必要があります。

コミュニケーションマネジメント計画書は、そのための基本的なルールを整理したものです。

なぜコミュニケーションマネジメント計画書が必要なのか

情報共有の漏れを防ぐ

プロジェクトで発生する問題の中には、「問題そのもの」ではなく、必要な情報が必要な人に伝わっていなかったことが原因となっているものがあります。

例えば、進捗が遅れているにもかかわらず、プロジェクトマネージャへの報告が遅れたとします。

その結果、対応が後手に回り、納期に間に合わなくなる可能性があります。

あらかじめ「どのような状況になったら誰に報告するか」を決めておけば、このような情報共有漏れを防ぎやすくなります。

コミュニケーション方法を標準化する

人によって情報共有の方法が違うと、プロジェクト内で混乱が生じます。

例えば、あるメンバーはメールで報告し、別のメンバーはチャットで報告し、別のメンバーは口頭で報告するといった状態です。

重要な情報がどこにあるのか分からなくなる可能性があります。

そこで、プロジェクトとして基本的な共有方法を決めておくことが重要です。

緊急時の連絡方法を明確にする

通常の進捗報告だけではなく、重大な問題や障害が発生した場合の連絡方法も重要です。

例えば、

• 通常の課題：週次会議で報告
• 重要な課題：当日中にプロジェクトマネージャへ報告
• 重大な障害：直ちに責任者へエスカレーション

というように、重要度に応じた連絡方法を決めておくことができます。

コミュニケーションマネジメント計画書に記載する内容

プロジェクトによって必要な内容は異なりますが、一般的には次のような項目を整理します。

すべてを細かく記載する必要があるわけではありません。

プロジェクトの規模や複雑さに応じて、必要なレベルまで詳細化することが重要です。

コミュニケーションマネジメント計画書の作り方

1．ステークホルダーを整理する

まず、プロジェクトに関係する人を整理します。

例えば、

• プロジェクトスポンサー
• プロジェクトマネージャ
• プロジェクトチーム
• 顧客
• ユーザー
• PMO
• 外部ベンダー

などです。

重要なのは、単純に名前を並べるだけではなく、それぞれがどのような情報を必要としているのかを考えることです。

2．必要な情報を整理する

次に、それぞれのステークホルダーが必要とする情報を整理します。

例えば、プロジェクトスポンサーには、

• 全体進捗
• 重要なリスク
• 重大な課題
• 予算状況

などが必要になるかもしれません。

一方、プロジェクトチームには、

• 作業状況
• 課題
• 変更事項
• 今後の予定

など、より具体的な情報が必要になります。

3．共有するタイミングを決める

情報を「いつ」共有するのかを決めます。

例えば、

• 毎日の進捗：デイリースクラム
• 週次進捗：週次進捗会議
• 月次報告：ステアリングコミッティ
• 重大な問題：発生時に即時報告

などです。

すべての情報を定期的に共有する必要はありません。

情報の性質に応じて、適切なタイミングを設定することが重要です。

4．共有方法を決める

次に、どのような方法で情報を共有するのかを決めます。

例えば、

• 定例会議
• メール
• チャット
• 進捗報告書
• ダッシュボード
• プロジェクト管理ツール

などがあります。

ここで重要なのは、共有方法を増やしすぎないことです。

情報共有の方法が多すぎると、「どこを見れば最新情報が分かるのか」が分からなくなってしまいます。

プロジェクトに必要な共有方法を整理し、できるだけシンプルな仕組みにすることが重要です。

5．エスカレーションルールを決める

通常の情報共有だけではなく、問題が発生した場合のエスカレーションルールも決めます。

例えば、

このように、どのような問題を、どのレベルで、誰に報告するのかをあらかじめ決めておくことで、問題を抱え込むことを防ぎやすくなります。

6．計画を関係者と合意する

コミュニケーションマネジメント計画書は、プロジェクトマネージャが一人で決めるものではありません。

必要な関係者と確認し、実際に運用できる内容になっているかを確認します。

特に、報告を受ける側が「その情報は必要ない」と考えていたり、報告する側の負担が大きすぎたりすると、計画どおりに運用できません。

実際に利用する人が無理なく運用できることが重要です。

コミュニケーションマネジメント計画書の例

例えば、システム開発プロジェクトであれば、次のような計画を作ることができます。

このように整理しておくことで、情報共有のルールをプロジェクトメンバー全員で共有できます。

プロジェクトの規模によって計画を変える

コミュニケーションマネジメント計画書は、プロジェクトの規模によって詳細度を変える必要があります。

例えば、5人程度の小規模なプロジェクトであれば、細かいコミュニケーション計画書を作成する必要がない場合もあります。

一方、数百人が関係する大規模プロジェクトでは、

• 組織ごとの情報共有方法
• 会議体
• 報告ルート
• 承認ルート
• エスカレーションルール
• 情報の保管場所

などを明確にする必要があります。

つまり、「計画書を作ること」そのものが目的ではなく、プロジェクトに必要なコミュニケーションを適切に設計することが目的です。

コミュニケーションマネジメント計画書を作るときの注意点

情報共有の方法を増やしすぎない

「情報共有が重要だから」といって、メール、チャット、会議、掲示板、複数の管理ツールなどを大量に使うと、かえって情報が分散します。

重要なのは、共有方法を必要最小限に整理することです。

全員にすべての情報を共有しない

すべての情報を全員に共有すると、情報量が多くなり、本当に重要な情報が埋もれてしまいます。

「誰が何を知る必要があるのか」を考えて、情報を適切な相手に届けることが重要です。

計画書を作って終わりにしない

プロジェクトが進むと、ステークホルダーやチーム構成、プロジェクトの状況が変わることがあります。

そのため、コミュニケーションマネジメント計画書も必要に応じて見直します。

報告しやすい仕組みにする

問題が発生したときに、「原因を完全に分析してから報告しよう」と考えてしまうと、報告が遅れる可能性があります。

重要なのは、問題だと思った時点で早めに報告できる仕組みを作ることです。

例えば、

「問題を認識した段階で一次報告する。原因分析や対策はその後に行う」

というルールを決めておくこともできます。

このような仕組みがあると、プロジェクトマネージャやメンバーが問題を抱え込むことを防ぎやすくなります。

コミュニケーションマネジメント計画書とステークホルダー

コミュニケーションマネジメント計画書を作成する際には、ステークホルダーごとに必要な情報が異なることを意識する必要があります。

例えば、

このように、ステークホルダーの関心や役割を踏まえてコミュニケーションを設計します。

コミュニケーションマネジメント計画書とエスカレーション

プロジェクトのコミュニケーションで特に重要なのがエスカレーションです。

エスカレーションとは、プロジェクトチームだけでは解決できない問題や、上位の判断が必要な事項を、適切な責任者へ報告・相談することです。

コミュニケーションマネジメント計画書にエスカレーションルールを含めることで、

• どのような状態になったら報告するのか
• 誰に報告するのか
• どの方法で報告するのか
• どの程度の緊急性で報告するのか

を明確にできます。

これにより、「誰にも相談せず、問題を抱えたまま時間が経過する」という状況を防ぎやすくなります。

プロジェクトマネージャ試験ではここが重要

コミュニケーションマネジメント計画書については、単に「情報共有の計画書」と覚えるだけではなく、誰に・何を・いつ・どのように伝えるのかを設計するものと理解しておきましょう。

特に重要なのは、

• ステークホルダーごとに必要な情報を整理する
• 情報共有の方法を決める
• 情報共有のタイミングを決める
• 情報の発信者を決める
• 情報の保管場所を決める
• エスカレーションルールを決める
• プロジェクトの規模に応じて詳細度を調整する

という点です。

また、コミュニケーションマネジメント計画書は、作成すること自体が目的ではありません。

プロジェクトに必要な情報が、必要な人に、必要なタイミングで届く状態を作ることが目的です。

PM道場のワンポイント

コミュニケーションマネジメント計画書は、「情報共有のルール」ではなく「情報共有の仕組み」を設計するためのものです。

プロジェクトで問題が起きたとき、原因を分析すると「情報共有が遅れていた」「必要な人に伝わっていなかった」というケースがあります。

しかし、これを単純に「もっとコミュニケーションを取ろう」としてしまうと、会議やメールが増えるだけになってしまいます。

重要なのは、

「誰が、どの情報を、いつまでに、誰へ伝えるのか」

を明確にすることです。

そして、もう一つ重要なのが、問題を早く報告できる仕組みです。

私は、問題を発見したときに、最初から原因分析や対策まで完成させて報告する必要はないと考えています。

「問題だと思いました。まず報告します。原因や対策はこれから分析します」

という一次報告ができる仕組みを作っておけば、問題を抱え込むことを防げます。

そのためには、コミュニケーションマネジメント計画書の中で、エスカレーションの基準とルートをあらかじめ決めておくことが有効です。

コミュニケーション能力が高い人に頼るのではなく、誰でも適切に情報共有できる仕組みを作る。

これが、プロジェクトマネージャがコミュニケーションマネジメント計画書を作る大きな意味の一つです。

関連用語

• コミュニケーションマネジメント
• ステークホルダーエンゲージメント
• ステークホルダー
• エスカレーション
• キックオフミーティング
• ファシリテーション
• ネゴシエーション
• 合意形成
• 意思決定
• リスク
• 課題
• デイリースクラム

まとめ

コミュニケーションマネジメント計画書とは、プロジェクトにおいて「誰に・何を・いつ・どのように伝えるのか」を定める計画書です。

その目的は、単純に情報共有のルールを作ることではありません。

必要な情報を、必要な人へ、必要なタイミングで届ける仕組みを作ることです。

作成するときは、

• ステークホルダーを整理する
• 必要な情報を整理する
• 共有するタイミングを決める
• 共有方法を決める
• 情報の保管場所を決める
• エスカレーションルールを決める

という流れで考えると分かりやすくなります。

また、プロジェクトの規模によって必要な詳細度は異なります。

小規模なプロジェクトであれば簡単なルールで十分な場合もありますし、大規模なプロジェクトでは組織ごとの報告ルートや会議体、エスカレーションルールなどを詳細に定める必要があります。

そして、コミュニケーションマネジメントで最も重要なのは、コミュニケーション能力の高い人に頼ることではなく、誰でも適切に情報を共有できる仕組みを作ることです。

特に、問題が発生したときに早期にエスカレーションできる仕組みを作っておくことは、プロジェクトのリスクを小さくするうえで非常に重要です。

「誰に、何を、いつ、どのように伝えるか」を事前に設計する。

これがコミュニケーションマネジメント計画書の基本です。

関連記事

• コミュニケーションマネジメントとは？
• ステークホルダーエンゲージメントとは？
• エスカレーションとは？
• キックオフミーティングとは？
• ファシリテーションとは？
• ネゴシエーションとは？
• 合意形成とは？
• 意思決定とは？
• リスクとは？
• 課題とは？
• デイリースクラムとは？

よくある質問（FAQ）

Q. コミュニケーションマネジメント計画書とは何ですか？

A. プロジェクトにおいて、誰に、何を、いつ、どのような方法で伝えるのかを整理した計画書です。必要な情報を必要な人へ届けるためのコミュニケーションの仕組みを設計します。

Q. コミュニケーションマネジメント計画書には何を書きますか？

A. 対象者、情報、目的、タイミング、頻度、共有方法、発信者、情報の保管場所、エスカレーションルールなどを記載します。ただし、プロジェクトの規模や特性に応じて必要な項目や詳細度を調整します。

Q. コミュニケーションマネジメント計画書は必ず作成する必要がありますか？

A. 重要なのは計画書という形式そのものではなく、プロジェクトに必要なコミュニケーションを適切に設計することです。小規模なプロジェクトでは簡単なルールで十分な場合もあります。

Q. コミュニケーションマネジメント計画書とコミュニケーションマネジメントの違いは何ですか？

A. コミュニケーションマネジメントは、プロジェクトにおける情報の生成、収集、配布、保管などを適切に管理する活動です。コミュニケーションマネジメント計画書は、その活動をどのように行うのかを計画・整理したものです。

Q. コミュニケーションマネジメント計画書にエスカレーションを含めるべきですか？

A. はい。問題が発生した場合に、誰へ、どのような基準で、どの方法で報告するのかをあらかじめ決めておくことで、問題の抱え込みや報告遅延を防ぎやすくなります。

Q. コミュニケーション方法は多いほど良いですか？

A. 必ずしもそうではありません。方法が増えすぎると情報が分散し、どこを確認すればよいのか分からなくなる可能性があります。プロジェクトに必要な方法を整理し、できるだけシンプルな仕組みにすることが重要です。

The post コミュニケーションマネジメント計画書とは？目的・記載内容・作り方をわかりやすく解説 first appeared on PM道場.