「PoCと本番開発は何が違うの？」

新しいシステムやサービス、技術を導入するときに、PoC（Proof of Concept）という言葉が使われることがあります。

PoCとは、新しいアイデアや技術が実際に実現できるのかを、小規模な検証によって確認することです。

いきなり本格的なシステム開発やサービス導入を始めるのではなく、まず小さく試して、技術的な実現可能性や期待する効果を確認します。

プロジェクトマネジメントでは、大きな投資をする前に不確実性を減らし、その後の意思決定につなげるための活動としてPoCが重要になります。

一言でいうと

PoCとは、本格的に開発・導入する前に「本当に実現できるのか」を小さく検証することです。

PoCは英語のProof of Conceptの略で、日本語では一般的に「概念実証」と呼ばれます。

例えば、AIを使った新しい業務システムを開発するとします。

いきなり全社向けのシステムを開発するのではなく、まず一つの業務だけを対象にAIを導入して、

• 技術的に実現できるか
• 期待した精度が出るか
• 業務時間を削減できるか
• 実際に利用者が使えるか

などを確認します。

これがPoCです。

PoCの目的

PoCの主な目的は、本格的な開発や導入を行う前に、不確実性を減らすことです。

特に、新しい技術や前例のない取り組みでは、計画段階では分からないことが多くあります。

PoCによって実際に試してみることで、机上の検討だけでは分からない問題を発見できます。

技術的に実現可能か確認する

新しい技術を利用する場合、理論上は実現できても、実際の環境ではうまく動作しない可能性があります。

PoCでは、実際の環境に近い条件で技術的な実現可能性を検証します。

期待する効果が得られるか確認する

技術的に動作したとしても、業務上のメリットがなければ本格導入する意味がありません。

そのため、

• 作業時間を削減できるか
• コストを削減できるか
• 品質を向上できるか
• 利用者の満足度を高められるか

なども検証します。

本格導入の判断材料を得る

PoCの結果をもとに、

• 本格開発へ進む
• 別の方法を検討する
• 追加検証を行う
• プロジェクトを中止する

といった意思決定を行います。

つまりPoCは、単に「試してみる」だけではなく、次の意思決定につなげるための検証でもあります。

PoCの具体例

AI導入プロジェクト

例えば、問い合わせ対応をAIで自動化するプロジェクトを考えます。

いきなり全社の問い合わせをAIに対応させるのではなく、まず過去の問い合わせデータを使って小規模な検証を行います。

例えば、

• 100件の問い合わせをAIに回答させる
• 正しい回答の割合を測定する
• 人間が回答した場合との時間を比較する
• 利用者から評価を受ける

といった検証を行います。

その結果、十分な精度と効果が確認できれば、本格導入を検討します。

新しいシステム開発

新しい技術を使ってシステムを開発する場合もPoCを実施できます。

例えば、

「既存システムと新しいクラウドサービスを連携できるか」

という点が不明であれば、全機能を開発する前に、重要な一部分だけを連携させて検証します。

これによって、早い段階で技術的な問題を発見できます。

IoTプロジェクト

工場にIoTセンサーを導入する場合には、一部の設備だけにセンサーを設置して、

• 必要なデータを取得できるか
• 通信は安定するか
• データを分析できるか
• 設備の異常を検知できるか

などを検証できます。

PoCの進め方

PoCは、単に試作品を作るだけでは十分ではありません。

「何を確認するためにPoCを行うのか」を明確にすることが重要です。

1．検証したい仮説を決める

まず、PoCで何を確認したいのかを明確にします。

例えば、

「AIを利用することで、問い合わせ対応時間を30％削減できる」

という仮説を設定します。

2．成功基準を決める

次に、PoCが成功したかどうかを判断する基準を設定します。

例えば、

• 回答精度90％以上
• 対応時間30％削減
• 利用者満足度80％以上

などです。

成功基準がないと、PoCを実施した後に「結局、成功したのか失敗したのか」が判断できなくなります。

3．検証範囲を小さくする

PoCでは、最初から大規模に実施する必要はありません。

むしろ、必要最小限の範囲で検証することが重要です。

検証範囲を小さくすることで、時間やコストを抑えながら不確実性を確認できます。

4．検証を実施する

実際に技術や仕組みを動かして、設定した仮説を検証します。

この段階では、理論上の検討だけではなく、できるだけ実際の利用環境に近い条件で試すことが重要です。

5．結果を評価する

あらかじめ設定した成功基準と実際の結果を比較します。

例えば、

このように、結果を客観的に評価します。

6．次の意思決定を行う

PoCの結果をもとに、次の方針を決定します。

• 本格導入する
• 条件を変更して追加検証する
• 別の技術を検討する
• 導入を中止する

PoCの重要な成果は、検証結果そのものだけではありません。

「次にどうするのかを判断できる情報を得ること」もPoCの重要な目的です。

PoCとプロトタイプの違い

PoCと似た言葉にプロトタイプがあります。

プロトタイプとは、製品やシステムの試作品です。

一方、PoCはアイデアや技術が実現可能かどうかを検証することを指します。

ただし、PoCのためにプロトタイプを作ることもあります。

つまり、PoCとプロトタイプは対立するものではありません。

PoCと本番開発の違い

PoCと本番開発では、目的が異なります。

PoCで重要なのは、本番システムと同じ完成度のものを作ることではありません。

必要な検証を、できるだけ少ないコストで実施することが重要です。

PoCを実施するメリット

大きな投資をする前に問題を発見できる

本格開発を開始してから技術的な問題が発覚すると、大きな手戻りが発生する可能性があります。

PoCによって早い段階で問題を発見できれば、損失を抑えられます。

技術的な不確実性を減らせる

新しい技術は、実際に動かしてみなければ分からないことがあります。

PoCによって実際の環境で検証することで、不確実性を減らせます。

意思決定の材料を得られる

「できそう」という感覚ではなく、実際の検証結果をもとに本格導入の判断ができます。

関係者の合意形成に役立つ

PoCの結果を共有することで、技術部門、利用部門、経営層などの関係者が同じ情報をもとに議論できます。

PoCで注意したいこと

目的を決めずに始めない

「とりあえず試してみよう」という理由だけでPoCを始めると、検証結果をどのように判断すればよいのか分からなくなります。

最初に「何を確認したいのか」を明確にしましょう。

成功基準を明確にする

成功基準が曖昧だと、PoCの結果が良かったのか悪かったのか判断できません。

できるだけ測定可能な基準を設定することが重要です。

PoCそのものが目的にならないようにする

PoCを何度も繰り返しているうちに、「検証すること」自体が目的になってしまうことがあります。

PoCはあくまで次の意思決定をするための手段です。

PoCの成功＝本番導入の成功ではない

PoCでは技術的に動作していても、本番環境では別の問題が発生する可能性があります。

例えば、

• 大量のデータを扱うと性能が低下する
• セキュリティ要件を満たせない
• 運用コストが想定以上になる
• 利用者が実際には使いにくい

といった問題です。

そのため、PoCの結果をそのまま本番環境に適用できるとは限りません。

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

PoCについては、「不確実性を減らすための検証」という点を押さえておきましょう。

特に新しい技術や未知の領域を扱うプロジェクトでは、最初から詳細な計画を立てても、前提が崩れる可能性があります。

そこで、まず小さく検証して、

• 技術的に実現可能か
• 期待する効果が得られるか
• どのような問題があるか

を確認します。

その結果をもとに、本格開発に進むか、計画を変更するか、プロジェクトを中止するかを判断するという考え方が重要です。

PM道場のワンポイント

PoCは「いきなり本番を作らず、小さく試す」ための仕組みと考えると分かりやすいでしょう。

例えば、新しい料理を100人分作るとします。

いきなり100人分を作るのではなく、まず少量を作って、

• 味は問題ないか
• 材料は足りるか
• 調理方法に問題はないか

を確認します。

問題がなければ、本格的に100人分を作ります。

PoCも同じです。

「本当にできるのか？」を小さく試してから、大きな投資を行う。

これがPoCの基本的な考え方です。

プロジェクトマネージャにとっては、PoCを実施すること自体よりも、何を検証し、その結果をどのような意思決定につなげるのかを設計することが重要です。

関連用語

• プロトタイプ
• フィージビリティスタディ
• リスク
• リスク分析
• リスク対応
• 意思決定
• 合意形成
• 受け入れ基準
• 品質メトリクス
• ステークホルダーエンゲージメント

まとめ

PoC（Proof of Concept）とは、新しいアイデアや技術が実際に実現できるのかを、小規模な検証によって確認することです。

PoCの主な目的は、

• 技術的な実現可能性を確認する
• 期待する効果が得られるか確認する
• 本格導入前に問題を発見する
• 次の意思決定に必要な情報を得る

ことです。

PoCを実施するときは、

「何を検証するのか」

「何をもって成功とするのか」

「結果をもとに何を判断するのか」

の3点を明確にすることが重要です。

PoCは、本番開発を小さく始めることではありません。

本格的な投資を行う前に、不確実性を減らし、より良い意思決定をするための検証と考えると分かりやすいでしょう。

関連記事

• プロトタイプとは？
• リスクとは？
• リスク分析とは？
• リスク対応とは？
• 意思決定とは？
• 合意形成とは？
• 受け入れ基準とは？
• ステークホルダーエンゲージメントとは？

よくある質問（FAQ）

Q. PoCとは何ですか？

A. PoCはProof of Conceptの略で、日本語では「概念実証」と呼ばれます。新しいアイデアや技術が実際に実現できるのかを、小規模な検証によって確認することです。

Q. PoCの目的は何ですか？

A. 本格的な開発や導入を行う前に、技術的な実現可能性や期待する効果を確認し、不確実性を減らすことが主な目的です。

Q. PoCとプロトタイプの違いは何ですか？

A. PoCは「実現可能性を検証すること」が目的で、プロトタイプは「製品やシステムの試作品」を指します。PoCのためにプロトタイプを作ることもあります。

Q. PoCと本番開発の違いは何ですか？

A. PoCは実現可能性や効果を検証することが目的であり、本番開発は実際に利用するシステムや製品を完成させることが目的です。PoCでは本番環境と同じ完成度は必ずしも求められません。

Q. PoCでは何を検証しますか？

A. 技術的な実現可能性、期待する効果、性能、操作性、運用上の問題など、プロジェクトで不確実な事項を検証します。重要なのは、PoCを始める前に「何を確認したいのか」を明確にすることです。

Q. PoCの成功基準は必要ですか？

A. 必要です。成功基準を設定しておくことで、検証結果を客観的に評価し、本格導入や追加検証、中止などの意思決定につなげやすくなります。

「知識エリアやプロセス群とは何が違うの？」

PMBOK^®第7版を学んでいると、パフォーマンスドメイン（Performance Domains）という言葉が登場します。

パフォーマンスドメインとは、プロジェクトの成果を効果的に実現するために、相互に関連する活動や領域をまとめたものです。

PMBOK^®第7版では、プロジェクトマネジメントを次の8つのプロジェクト・パフォーマンス・ドメインに整理しています。

• ステークホルダー・パフォーマンス・ドメイン
• チーム・パフォーマンス・ドメイン
• 開発アプローチとライフサイクル・パフォーマンス・ドメイン
• 計画パフォーマンス・ドメイン
• プロジェクト作業パフォーマンス・ドメイン
• 納入パフォーマンス・ドメイン
• 測定パフォーマンス・ドメイン
• 不確実性パフォーマンス・ドメイン

この記事では、それぞれのパフォーマンスドメインの意味と役割、従来の知識エリア・プロセス群との違い、実務での活用方法について解説します。

一言でいうと

パフォーマンスドメインとは、プロジェクトの成果を実現するために重要となる活動や領域をまとめたものです。

第6版までのPMBOK^®では、「どのプロセスを実施するのか」というプロセス中心の考え方が強くありました。

第7版では、そこから考え方が大きく変わり、「プロジェクトで良いパフォーマンスを実現するためには、どのような領域に注目すべきか」という視点で整理されています。

パフォーマンスドメインとは

パフォーマンスドメインを理解するうえで重要なのは、単なる「作業項目の一覧」ではないということです。

PMBOK^®第7版では、プロジェクトを成功させるためには、決められたプロセスを順番に実行するだけでは不十分だと考えます。

プロジェクトの状況に応じて、ステークホルダー、チーム、計画、成果物、不確実性など、さまざまな側面を適切にマネジメントする必要があります。

そのために整理されたのがパフォーマンスドメインです。

8つのパフォーマンスドメイン

1．ステークホルダー・パフォーマンス・ドメイン

ステークホルダー・パフォーマンス・ドメインは、プロジェクトに関係するステークホルダーと効果的に関わるための領域です。

プロジェクトには、顧客、スポンサー、プロジェクトメンバー、経営層、ユーザー、ベンダーなど、さまざまなステークホルダーが存在します。

それぞれの期待や関心は異なるため、単純に情報を提供するだけでは十分ではありません。

ステークホルダーを特定し、期待や影響力などを理解したうえで、適切にエンゲージメントすることが重要です。

「誰と、どのように関わるのか」に注目するパフォーマンスドメインと考えると分かりやすいでしょう。

2．チーム・パフォーマンス・ドメイン

チーム・パフォーマンス・ドメインは、プロジェクトチームを構築し、協働して成果を生み出せる状態を作るための領域です。

プロジェクトでは、個々のメンバーが優秀であっても、チームとして機能しなければ十分な成果を出せません。

そのため、チームの育成、リーダーシップ、協働、コミュニケーション、コンフリクトなどが重要になります。

「チームとしてどのように成果を出すのか」に注目する領域です。

3．開発アプローチとライフサイクル・パフォーマンス・ドメイン

このパフォーマンスドメインは、プロジェクトに適した開発アプローチやライフサイクルを選択し、適切に適用するための領域です。

プロジェクトには、予測型、適応型、アジャイルなど、さまざまな開発アプローチがあります。

すべてのプロジェクトに同じ進め方を適用するのではなく、プロジェクトの特性や要求事項、環境などに応じて適切なアプローチを選択することが重要です。

つまり、「どのような進め方が、このプロジェクトに適しているのか」を考える領域です。

4．計画パフォーマンス・ドメイン

計画パフォーマンス・ドメインは、プロジェクトの実行に必要な計画を作成し、継続的に調整するための領域です。

プロジェクトでは、スコープ、スケジュール、コスト、資源、品質、コミュニケーション、リスクなど、さまざまな計画が必要になります。

ただし、計画は一度作ったら終わりではありません。

プロジェクトの状況が変化すれば、計画も必要に応じて見直します。

「どうやってプロジェクトを進めるのか」を考える領域です。

5．プロジェクト作業パフォーマンス・ドメイン

プロジェクト作業パフォーマンス・ドメインは、プロジェクトを実際に実行し、プロジェクトの作業を適切に進めるための領域です。

プロジェクトマネジメントの活動だけでなく、成果物を作るためのプロジェクト作業そのものも対象になります。

資源の調整、コミュニケーション、調達、変更への対応、問題の解決など、プロジェクトを動かしていくためのさまざまな活動が関係します。

「計画したプロジェクトを実際にどう動かすのか」という視点で考えると分かりやすいでしょう。

6．納入パフォーマンス・ドメイン

納入パフォーマンス・ドメインは、プロジェクトの成果物を適切に納入し、期待される価値を実現するための領域です。

プロジェクトでは、単に計画された作業を完了するだけではなく、顧客や利用者にとって価値のある成果を届けることが重要です。

そのため、要求事項や受け入れ基準、品質、成果物の検証・妥当性確認などとも関係します。

「何を作るか」だけでなく、「それによってどのような価値を届けるのか」という視点が重要です。

7．測定パフォーマンス・ドメイン

測定パフォーマンス・ドメインは、プロジェクトのパフォーマンスを測定し、状況を把握して、必要な意思決定につなげるための領域です。

プロジェクトが計画どおりに進んでいるのか、成果が期待される状態に近づいているのかを、適切な指標を使って確認します。

例えば、進捗、コスト、品質、成果物の完成状況などを測定することが考えられます。

重要なのは、単に数字を集めることではありません。

測定結果を分析し、必要な対応や意思決定につなげることが重要です。

8．不確実性パフォーマンス・ドメイン

不確実性パフォーマンス・ドメインは、プロジェクトを取り巻く不確実性や変化に対応するための領域です。

プロジェクトでは、将来何が起こるかを完全に予測することはできません。

例えば、技術的な問題、要求事項の変更、市場環境の変化、自然災害、組織変更など、さまざまな不確実性があります。

そのため、リスクや課題を管理し、変化に対して柔軟に対応することが重要になります。

「予測できないことにどう備え、どう対応するのか」という領域です。

パフォーマンスドメイン同士は独立していない

8つのパフォーマンスドメインは、それぞれ独立した領域ではありません。

むしろ、相互に関連しながらプロジェクトの成果に影響を与えるものとして捉えることが重要です。

例えば、ステークホルダーから要求事項が変更された場合を考えてみましょう。

要求事項の変更は、計画に影響します。

計画が変われば、プロジェクト作業にも影響します。

さらに、納入する成果物やスケジュール、コスト、チームの作業にも影響する可能性があります。

そして、その影響を測定し、必要に応じて不確実性への対応も行う必要があります。

このように、パフォーマンスドメインは「個別に管理する8つの箱」ではなく、相互に関連するプロジェクトの活動領域として理解することが重要です。

パフォーマンスドメインと知識エリアの違い

パフォーマンスドメインと知識エリアは、似ているように見えますが、考え方が異なります。

簡単に言えば、

知識エリア＝「何を管理するか」

パフォーマンスドメイン＝「成果を出すために、どのような領域に注目するか」

という違いがあります。

パフォーマンスドメインとプロセス群の違い

プロセス群も、パフォーマンスドメインとは異なる考え方です。

つまり、PMBOK^®第6版までの考え方では、プロセスを「プロセス群」と「知識エリア」という2つの軸で整理していました。

一方、第7版では、より成果や価値、状況に応じた適用を重視する考え方へ変化しています。

パフォーマンスドメインは「何をすればよいか」のチェックリスト

パフォーマンスドメインを実務で活用する場合、8つを単純に暗記する必要はありません。

むしろ、プロジェクトを見渡すためのチェックリストとして使うと分かりやすくなります。

• ステークホルダーは適切に関与しているか？
• チームは協働できているか？
• このプロジェクトに適した開発アプローチを選択しているか？
• 計画は適切か？
• プロジェクト作業は順調に進んでいるか？
• 必要な成果物や価値を納入できているか？
• プロジェクトの状況を適切に測定できているか？
• リスクや不確実性に対応できているか？

このような視点でプロジェクトを確認することで、特定の管理項目だけに偏ることを防ぎやすくなります。

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

パフォーマンスドメインを学ぶ際には、8つの名称を覚えるだけでは不十分です。

重要なのは、それぞれがプロジェクトの成果にどのようにつながるのかを理解することです。

特に、PMBOK^®第6版までの「プロセスを実行する」という考え方との違いを理解しておくと、PMBOK^®第7版の考え方を整理しやすくなります。

第7版では、プロジェクトの状況に応じて適切なアプローチを選択し、価値や成果を実現することが重視されています。

そのため、

「決められたプロセスを実行したか？」

だけではなく、

「その活動によって、プロジェクトとして適切な成果を生み出せているか？」

という視点が重要になります。

PM道場のワンポイント

パフォーマンスドメインは、「プロジェクトを成功させるために、どこを見ればよいか」を整理したものと考えると分かりやすいでしょう。

例えば、プロジェクトが遅れているときに、単純にスケジュールだけを見るのではありません。

ステークホルダーとの認識が合っているのか、チームに問題がないのか、計画そのものに無理がないのか、プロジェクト作業に問題がないのか、不確実性が影響していないかなど、さまざまな視点から原因を考えます。

これがパフォーマンスドメインの考え方です。

つまり、「どのプロセスを実施したか」よりも、「プロジェクトとして適切な成果を生み出せているか」に目を向けます。

PMBOK^®第7版を理解するうえでは、このプロセス中心から成果・価値中心への視点の変化を押さえておくことが重要です。

関連用語

• PMBOK^®ガイド
• プロセス群
• 知識エリア
• プロジェクトマネジメント原則
• ステークホルダー・エンゲージメント
• チーム
• アジャイル
• スクラム
• リスクマネジメント
• 測定
• 価値

まとめ

パフォーマンスドメインとは、プロジェクトの成果を効果的に実現するために、相互に関連する活動や領域をまとめたものです。

PMBOK^®第7版では、次の8つのパフォーマンスドメインが定義されています。

• ステークホルダー・パフォーマンス・ドメイン
• チーム・パフォーマンス・ドメイン
• 開発アプローチとライフサイクル・パフォーマンス・ドメイン
• 計画パフォーマンス・ドメイン
• プロジェクト作業パフォーマンス・ドメイン
• 納入パフォーマンス・ドメイン
• 測定パフォーマンス・ドメイン
• 不確実性パフォーマンス・ドメイン

第6版までのPMBOK^®では、知識エリアやプロセス群によってプロジェクトマネジメントを体系的に整理していました。

一方、第7版では、プロセスを実行することそのものよりも、プロジェクトを通じて価値や成果を実現することに重点が置かれています。

そのため、パフォーマンスドメインは、PMBOK^®第7版の考え方を理解するうえで重要なキーワードです。

関連記事

• PMBOK^®ガイドとは？
• プロセス群とは？
• 知識エリアとは？
• プロジェクトマネジメント原則とは？
• ステークホルダーエンゲージメントとは？
• リスクマネジメントとは？
• アジャイルとは？
• スクラムとは？

よくある質問（FAQ）

Q. パフォーマンスドメインとは何ですか？

A. プロジェクトの成果を効果的に実現するために、相互に関連する活動や領域をまとめたものです。PMBOK^®第7版では8つのパフォーマンスドメインが定義されています。

Q. パフォーマンスドメインはいくつありますか？

A. PMBOK^®第7版では8つです。ステークホルダー、チーム、開発アプローチとライフサイクル、計画、プロジェクト作業、納入、測定、不確実性の8つがあります。

Q. パフォーマンスドメインと知識エリアの違いは何ですか？

A. 知識エリアは「何を管理するのか」という専門領域による分類です。一方、パフォーマンスドメインは、プロジェクトの成果を実現するために重要となる活動や領域をまとめたものです。

Q. パフォーマンスドメインとプロセス群の違いは何ですか？

A. プロセス群はプロセスの目的による分類で、立上げ、計画、実行、監視・コントロール、終結の5つがあります。パフォーマンスドメインは、プロジェクトの成果に関係する活動領域を整理したものです。

Q. パフォーマンスドメインは第6版にもありますか？

A. 「パフォーマンスドメイン」という構成はPMBOK^®第7版で導入されました。第6版までは、主に知識エリアとプロセス群によってプロジェクトマネジメントを整理していました。

Q. パフォーマンスドメインは順番に実施するものですか？

A. いいえ。8つのパフォーマンスドメインは、順番に実施するプロセスではありません。それぞれが相互に関連しながら、プロジェクトの成果や価値の実現に貢献します。

「PMBOK^®のプロセスごとに、インプットやツール、アウトプットを覚えないといけないの？」

プロジェクトマネジメントを学んでいると、インプット・ツール・アウトプット（ITTO）という言葉が登場します。

ITTOとは、プロジェクトマネジメントの各プロセスについて、何を使って、どのような方法で作業を行い、その結果として何を作り出すのかを整理した考え方です。

PMBOK^®第6版までのプロセスベースの考え方を理解するうえで重要な概念でした。

この記事では、ITTOの意味や3つの構成要素、具体例、覚え方、プロジェクトマネージャ試験でのポイントについて解説します。

一言でいうと

ITTOとは、プロジェクトマネジメントのプロセスにおける「インプット（入力）」「ツールと技法（処理方法）」「アウトプット（成果）」を整理したものです。

簡単に表すと、

インプット → ツールと技法 → アウトプット

という関係になります。

例えば、ある資料をインプットとして受け取り、会議や分析などのツールと技法を使って処理し、新しい計画書などのアウトプットを作成する、というイメージです。

ITTOの3つの要素

ITTOは、次の3つから構成されています。

1．インプット（Input）

インプットとは、そのプロセスを実施するために必要となる情報、文書、計画、データなどです。

例えば、プロジェクトのスケジュールを作成するのであれば、作業内容や作業期間などの情報が必要になります。

そのプロセスだけで突然結果が生まれるわけではなく、前のプロセスで作られた情報や、プロジェクトを取り巻く環境などをインプットとして利用します。

つまり、インプットは「このプロセスを実施するために何が必要なのか」と考えると分かりやすいでしょう。

2．ツールと技法（Tools and Techniques）

ツールと技法とは、インプットを利用して、目的のアウトプットを作るために使用する方法や手段です。

例えば、

• 専門家の判断
• 会議
• データ分析
• データ収集
• 意思決定
• コミュニケーション
• 見積もり
• ファシリテーション

などがあります。

つまり、ツールと技法は「インプットをどのように処理するのか」を表しています。

3．アウトプット（Output）

アウトプットとは、プロセスを実施した結果として作成・更新される成果物や情報です。

例えば、

• プロジェクト・チャーター
• プロジェクトマネジメント計画書
• スコープ・ベースライン
• スケジュール
• リスク登録簿
• 変更要求
• 教訓登録簿

などがあります。

つまり、アウトプットは「このプロセスを実施した結果、何ができたのか」と考えることができます。

ITTOの基本的な流れ

ITTOを理解するには、料理に例えると分かりやすいでしょう。

• インプット：材料
• ツールと技法：調理方法・調理器具
• アウトプット：完成した料理

プロジェクトマネジメントのプロセスも基本的には同じです。

必要な情報をインプットとして受け取り、それを適切なツールや技法によって処理し、その結果としてアウトプットを作ります。

この関係を理解すると、ITTOを単なる暗記項目として捉える必要がなくなります。

ITTOの具体例

例えば、PMBOK^®第6版の「リスクの特定」というプロセスを考えてみます。

リスクを特定するためには、プロジェクトに関するさまざまな情報が必要になります。

それらをインプットとして利用し、専門家の判断やデータ分析、会議などのツールと技法を使ってリスクを特定します。

その結果として、リスク登録簿などが作成・更新されます。

つまり、

プロジェクトに関する情報

↓

分析・会議・専門家の判断など

↓

特定されたリスクを記録した情報

という流れになります。

これがITTOの基本的な考え方です。

ITTOはプロセス同士をつなぐ

ITTOを理解するうえで特に重要なのが、あるプロセスのアウトプットが、別のプロセスのインプットになるという関係です。

例えば、あるプロセスで作成された計画書が、次のプロセスで利用されることがあります。

このようにプロセスは独立しているわけではなく、アウトプットとインプットを通じてつながっています。

そのため、ITTOを理解すると、プロジェクトマネジメントのプロセス全体がどのようにつながっているのかを理解しやすくなります。

ITTOとプロセス群・知識エリアの関係

ITTOは、プロセス群や知識エリアとは異なる概念です。

例えば、「リスク・マネジメント」という知識エリアの中に複数のプロセスがあります。

それぞれのプロセスには、インプット、ツールと技法、アウトプットがあります。

このように、

知識エリア → プロセス → ITTO

という構造で考えると、PMBOK^®第6版までの体系を整理しやすくなります。

ITTOは暗記するべき？

ITTOについて、よくある疑問が「すべて暗記する必要があるのか」ということです。

結論として、ITTOを単純に丸暗記することはおすすめしません。

プロセスごとのインプット、ツールと技法、アウトプットをすべて暗記しようとすると、非常に多くの項目を覚える必要があります。

それよりも、

「このプロセスでは何をするのか？」

をまず理解することが重要です。

そのうえで、

• 何を材料として使うのか
• どのような方法で処理するのか
• その結果、何を作るのか

と考えると、ITTOの関係を自然に理解しやすくなります。

ITTOを理解するための覚え方

「何を使って、どうやって、何を作る？」と考える

ITTOを覚えるときには、次の3つの質問に置き換えると分かりやすくなります。

• 何を使う？ → インプット
• どうやって処理する？ → ツールと技法
• 何ができる？ → アウトプット

この3つを意識するだけでも、ITTOの意味を理解しやすくなります。

アウトプットから逆算する

「このプロセスでは何ができるのか？」を考える方法も有効です。

例えば、リスク登録簿がアウトプットになるのであれば、そこにはリスクを特定するためのプロセスが必要だと考えることができます。

アウトプットからプロセスを逆算すると、プロセス同士のつながりも見えてきます。

実務と結び付ける

ITTOは、実務に置き換えると非常に分かりやすくなります。

例えば、「リスク登録簿を作る」という作業を考えた場合、過去の資料やプロジェクト計画などを確認し、会議や分析を行い、その結果としてリスク登録簿を作成します。

これだけでも、ITTOの基本的な考え方を実感できます。

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

プロジェクトマネージャ試験では、PMBOK^®の用語やプロセスについて問われることがあります。

ただし、ITTOを単純に暗記するだけでは、実際のプロジェクトの問題に対応しにくくなります。

重要なのは、

「なぜこのプロセスが必要なのか」

「このプロセスでは何をインプットとして使うのか」

「どのような活動を行い、何をアウトプットするのか」

という流れを理解することです。

特に記述式の問題では、単語を知っているだけではなく、プロジェクトの状況に応じて、どのような活動を行うべきかを説明する力が重要になります。

現在のPMBOK®との関係

ここは注意が必要です。

ITTOは、特にPMBOK^®第6版までのプロセスベースの考え方と強く結び付いています。

PMBOK^®第7版では、従来のプロセス中心の構成から、プロジェクトマネジメントの原則やパフォーマンス領域を中心とする構成へ大きく変更されました。

そのため、第7版以降のPMBOK^®を理解するうえで、ITTOを従来と同じ形で暗記することを中心的な学習方法とするのは適切ではありません。

一方で、

「何をインプットとして受け取り、どのような活動を行い、どのような結果を生み出すのか」

という考え方自体は、プロジェクトマネジメントの実務でも有用です。

よくある勘違い

ITTOは単なる暗記項目ではない

ITTOは、プロセスを理解するための構造として捉えることが重要です。

「このプロセスでなぜこのインプットが必要なのか」「なぜこのアウトプットが生まれるのか」と考えることで、プロセスの目的を理解できます。

ツールと技法は道具だけを意味するわけではない

「Tools」という言葉から、ソフトウェアなどの道具をイメージしがちですが、ITTOにおけるツールと技法には、専門家の判断、会議、分析、意思決定なども含まれます。

アウトプットは必ず新しい文書とは限らない

アウトプットには、新たに作成される文書だけでなく、既存の文書や計画、記録などの更新も含まれます。

PM道場のワンポイント

ITTOは「プロセスの仕事の流れ」を表していると考えると分かりやすくなります。

例えば、仕事を依頼されたとき、いきなり成果物を作るわけではありません。

まず必要な情報を集め、その情報を分析したり、関係者と話し合ったりして、最終的な成果物を作ります。

プロジェクトマネジメントのプロセスも同じです。

「何を受け取り、どう処理して、何を生み出すのか」

この視点で考えると、ITTOは単なる試験対策の暗記項目ではなく、プロセスを理解するための非常に分かりやすいフレームワークになります。

特にプロジェクトマネージャ試験では、ITTOを丸暗記するよりも、プロセスの目的と、その前後のつながりを理解することを意識するとよいでしょう。

関連用語

• PMBOK^®ガイド
• プロセス群
• 知識エリア
• プロジェクトマネジメント・プロセス
• プロジェクト・チャーター
• プロジェクトマネジメント計画書
• リスク登録簿
• 変更要求
• 教訓登録簿
• 専門家の判断

まとめ

インプット・ツール・アウトプット（ITTO）とは、プロジェクトマネジメントのプロセスについて、

• インプット：何を使うのか
• ツールと技法：どのように処理するのか
• アウトプット：何ができるのか

という3つの観点から整理する考え方です。

ITTOを理解すると、各プロセスが単独で存在しているのではなく、あるプロセスのアウトプットが、別のプロセスのインプットになるというプロセス同士のつながりも理解できます。

ただし、ITTOをすべて丸暗記することが目的ではありません。

「何を使って、どう処理し、その結果何を作るのか」というプロセスの流れを理解することが重要です。

なお、PMBOK^®第7版ではプロセス中心の構成から大きく変更されているため、ITTOは主に第6版までのプロセスベースの考え方として理解しておくとよいでしょう。

関連記事

• PMBOK^®ガイドとは？
• プロセス群とは？
• 知識エリアとは？
• 要求事項とは？
• 要求事項トレーサビリティマトリクス（RTM）とは？
• リスクマネジメントとは？
• リスク登録簿とは？
• 変更要求とは？
• 教訓登録簿とは？

よくある質問（FAQ）

Q. ITTOとは何ですか？

A. ITTOは、Input（インプット）、Tools and Techniques（ツールと技法）、Output（アウトプット）の頭文字を取った言葉です。各プロセスで「何を使い、どのように処理し、何を作るのか」を整理したものです。

Q. ITTOはすべて暗記する必要がありますか？

A. ITTOをすべて丸暗記することはおすすめしません。各プロセスの目的を理解し、「何を使って、どう処理し、何を作るのか」という流れを理解することが重要です。

Q. ITTOのインプットとは何ですか？

A. プロセスを実施するために必要な情報、文書、計画、データなどです。前のプロセスで作成されたアウトプットがインプットとして利用されることもあります。

Q. ITTOのツールと技法とは何ですか？

A. インプットを利用してアウトプットを作成するための方法や手段です。専門家の判断、会議、データ分析、意思決定などが含まれます。

Q. ITTOのアウトプットとは何ですか？

A. プロセスを実施した結果として作成・更新される成果物や情報です。計画書、リスク登録簿、変更要求などが代表的な例です。

Q. ITTOは現在のPMBOK®でも重要ですか？

A. ITTOは特にPMBOK^®第6版までのプロセスベースの考え方と強く結び付いています。第7版では構成が大きく変更されたため、現在のPMBOK^®を学ぶ際には、ITTOの丸暗記よりもプロジェクトマネジメントの原則やパフォーマンス領域、そして実務での適用を理解することが重要です。

ら

「プロセス群とは何が違うのだろう？」

プロジェクトマネジメントを学んでいると、知識エリア（Knowledge Areas）という言葉が登場します。

知識エリアとは、プロジェクトマネジメントのプロセスを、管理する対象や専門領域によって分類したものです。

PMBOK^®第6版では、プロジェクトマネジメントを次の10の知識エリアに分類していました。

• プロジェクト統合マネジメント
• プロジェクト・スコープ・マネジメント
• プロジェクト・スケジュール・マネジメント
• プロジェクト・コスト・マネジメント
• プロジェクト品質マネジメント
• プロジェクト資源マネジメント
• プロジェクト・コミュニケーション・マネジメント
• プロジェクト・リスク・マネジメント
• プロジェクト調達マネジメント
• プロジェクト・ステークホルダー・マネジメント

この記事では、10の知識エリアの意味や役割、プロセス群との違い、現在のPMBOK^®との関係について解説します。

一言でいうと

知識エリアとは、「プロジェクトマネジメントの何を管理するのか」という専門領域ごとにプロセスを分類したものです。

例えば、スケジュールについて管理するプロセスをまとめたものが「プロジェクト・スケジュール・マネジメント」です。

知識エリアとは

プロジェクトには、さまざまな管理対象があります。

例えば、

• プロジェクト全体をどう統合するか
• 何を作るのか
• いつまでに作るのか
• いくらかかるのか
• どの程度の品質にするのか
• 誰が作業するのか
• どのように情報を共有するのか
• どのようなリスクがあるのか
• 外部の会社から何を調達するのか
• 関係者とどのように関わるのか

これらの管理対象を整理したものが知識エリアです。

つまり、知識エリアは「プロジェクトマネージャが何について管理する必要があるのか」を整理するための分類と考えると分かりやすいでしょう。

PMBOK®第6版の10の知識エリア

1．プロジェクト統合マネジメント

プロジェクト統合マネジメントは、プロジェクト全体をまとめ、各活動を統合する知識エリアです。

プロジェクトでは、スコープ、スケジュール、コスト、品質、リスクなどを個別に管理するだけでは不十分です。

例えば、スコープを変更するとスケジュールやコストにも影響します。

このような各要素の関係を考慮しながら、プロジェクト全体として整合性を取ることが統合マネジメントの重要な役割です。

2．プロジェクト・スコープ・マネジメント

スコープ・マネジメントは、プロジェクトで実施する作業の範囲を管理する知識エリアです。

「何を作るのか」「何を作らないのか」を明確にし、プロジェクトの成果物と作業範囲を管理します。

代表的な考え方として、要求事項、WBS、スコープ・ベースラインなどがあります。

スコープクリープを防ぐためにも重要な知識エリアです。

3．プロジェクト・スケジュール・マネジメント

スケジュール・マネジメントは、プロジェクトの作業をいつ実施するのかを管理する知識エリアです。

作業を特定し、順序を決め、期間を見積もり、スケジュールを作成します。

プロジェクト実行中には、実際の進捗を確認し、遅延が発生していれば必要な対応を検討します。

4．プロジェクト・コスト・マネジメント

コスト・マネジメントは、プロジェクトに必要な費用を見積もり、予算を設定し、管理する知識エリアです。

代表的な考え方として、コスト見積もり、予算、コスト・ベースラインなどがあります。

また、EVM（アーンド・バリュー・マネジメント）を利用して、コストやスケジュールのパフォーマンスを分析することもあります。

5．プロジェクト品質マネジメント

品質マネジメントは、プロジェクトや成果物に求められる品質を確保するための知識エリアです。

品質を計画し、品質保証を行い、品質を管理します。

レビュー、テスト、品質メトリクス、不具合管理など、さまざまな活動と関係します。

「完成してから品質を確認する」だけではなく、プロセスの中で品質を作り込むことが重要です。

6．プロジェクト資源マネジメント

資源マネジメントは、プロジェクトに必要な人や物などの資源を管理する知識エリアです。

特に人的資源については、チームの育成、役割分担、チームマネジメントなどが重要になります。

プロジェクトでは「誰が何をするのか」を明確にすることが、円滑な実行につながります。

7．プロジェクト・コミュニケーション・マネジメント

コミュニケーション・マネジメントは、プロジェクトに必要な情報を、適切な相手に、適切なタイミングと方法で伝えるための知識エリアです。

プロジェクトでは、情報が存在するだけでは十分ではありません。

必要な人が必要な情報を受け取り、理解できる状態にすることが重要です。

コミュニケーション計画や情報配布、コミュニケーションの監視などが関係します。

8．プロジェクト・リスク・マネジメント

リスク・マネジメントは、プロジェクトに影響を与える可能性のある不確実性を管理する知識エリアです。

リスクを特定し、定性的・定量的に分析し、対応策を検討します。

また、プロジェクト実行中にはリスクを監視し、新たなリスクが発生していないか確認します。

リスク登録簿、定性的リスク分析、定量的リスク分析、リスク対応、コンティンジェンシープランなど、多くのプロジェクト管理活動と関係します。

9．プロジェクト調達マネジメント

調達マネジメントは、プロジェクトに必要な製品やサービスなどを外部から調達するための知識エリアです。

例えば、外部のベンダーにシステム開発を依頼する場合などが該当します。

RFP、契約、ベンダー選定、契約後のベンダーマネジメントなどと関係します。

10．プロジェクト・ステークホルダー・マネジメント

ステークホルダー・マネジメントは、プロジェクトに関係するステークホルダーを特定し、適切に関与してもらうための知識エリアです。

ステークホルダーには、プロジェクトスポンサー、顧客、プロジェクトメンバー、経営層、ユーザー、ベンダーなど、さまざまな関係者が含まれます。

それぞれの期待や関心を理解し、適切にエンゲージメントを行うことが重要です。

知識エリアとプロセス群の違い

知識エリアとプロセス群は、どちらもPMBOK^®第6版までのプロジェクトマネジメントを理解するうえで重要な分類です。

例えば「リスク・マネジメント」は知識エリアです。

一方、リスクに関するプロセスが「計画プロセス群」や「監視・コントロール・プロセス群」に分類されることがあります。

つまり、

知識エリア＝「何について管理するのか」

プロセス群＝「そのプロセスはどのような目的で行うのか」

と整理すると分かりやすいでしょう。

知識エリアとプロセス群は組み合わせて考える

知識エリアとプロセス群は、それぞれ独立して覚えるよりも、組み合わせて理解すると分かりやすくなります。

例えば、リスク・マネジメントという知識エリアには、リスクを計画するプロセス、特定するプロセス、分析するプロセス、対応するプロセス、監視するプロセスなどがあります。

このように、

「リスクについて、プロジェクトのどの段階・目的で、どのような活動を行うのか」

という視点で整理すると、プロセス全体を理解しやすくなります。

第7版以降との違い

知識エリアについても、PMBOK^®第7版では大きな変更がありました。

第6版までは、10の知識エリアと5つのプロセス群によってプロジェクトマネジメントを体系的に整理していました。

一方、第7版では、従来のプロセス中心の構成から、12の原則と8つのプロジェクト・パフォーマンス領域を中心とした構成へ変更されています。

そのため、現在のPMBOK^®を学ぶ場合には、10の知識エリアを「最新のPMBOK^®の中心的な構成」として扱わないことが重要です。

ただし、スコープ、スケジュール、コスト、品質、リスクなどの考え方自体が不要になったわけではありません。

これらは現在のプロジェクトマネジメントにおいても重要な管理対象です。

知識エリアを覚えるポイント

10の知識エリアは、単純に名称だけを暗記するよりも、「プロジェクトで何を管理するのか」と関連付けて覚えると理解しやすくなります。

• 統合：プロジェクト全体をまとめる
• スコープ：何を作るのか
• スケジュール：いつ作るのか
• コスト：いくらで作るのか
• 品質：どの品質で作るのか
• 資源：誰・何を使って作るのか
• コミュニケーション：どう情報を共有するのか
• リスク：何が起こる可能性があるのか
• 調達：外部から何を調達するのか
• ステークホルダー：誰と関係するのか

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

例えば、新しいシステム開発プロジェクトを担当するとします。

まず、プロジェクト全体を統合しながら、必要な機能をスコープとして整理します。

その後、スケジュールとコストを計画し、必要なメンバーや設備などの資源を確保します。

品質基準を決め、関係者とのコミュニケーション方法を整理し、リスクを特定します。

外部ベンダーが必要であれば調達を行い、顧客や経営層などのステークホルダーとの関係も管理します。

このように考えると、10の知識エリアは単なる試験用の分類ではなく、プロジェクトを多面的に管理するためのチェックリストとしても利用できます。

よくある勘違い

知識エリアはプロジェクトの順番ではない

10の知識エリアは、プロジェクトを「1番から10番まで順番に実施する」というものではありません。

それぞれの知識エリアはプロジェクトのさまざまな場面で関係します。

すべてを個別に管理すればよいわけではない

プロジェクトでは、各知識エリアが相互に影響します。

例えば、スコープを変更すると、スケジュールやコスト、品質、リスクなどにも影響する可能性があります。

そのため、各知識エリアを個別に見るだけでなく、プロジェクト全体を統合して考えることが重要です。

第7版でも10の知識エリアがそのまま使われているわけではない

第7版ではPMBOK^®の構成が大きく変更されています。

したがって、試験対策や学習では、どの版を前提としているのかを確認することが重要です。

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

プロジェクトマネージャ試験でPMBOK^®の考え方を理解する際には、10の知識エリアを単なる暗記項目として覚えるのではなく、それぞれが何を管理する領域なのかを理解することが重要です。

特に、次の関係を整理しておくとよいでしょう。

• スコープ＝プロジェクトで何を実施するか
• スケジュール＝いつ実施するか
• コスト＝いくらかかるか
• 品質＝どのような品質を確保するか
• リスク＝不確実性をどう管理するか
• ステークホルダー＝関係者をどうエンゲージするか
• 統合＝それらをプロジェクト全体としてどう調整するか

特に重要なのは、「知識エリアはプロジェクトマネジメントの何を管理するのかを分類したもの」という点です。

PM道場のワンポイント

知識エリアは「プロジェクトマネージャの仕事のチェックリスト」と考えると理解しやすくなります。

プロジェクトを担当したときに、「スコープは大丈夫か？」「スケジュールは？」「コストは？」「品質は？」「リスクは？」と確認していけば、プロジェクトを多面的に見ることができます。

ただし、ここで注意したいのが統合マネジメントです。

各知識エリアを個別に管理するだけでは、プロジェクト全体として最適な判断になるとは限りません。

例えば、スコープを増やせば顧客満足度が上がるかもしれませんが、スケジュールが遅れたり、コストが増えたりする可能性があります。

そのため、プロジェクトマネージャには、各知識エリアを個別に管理するだけでなく、全体への影響を考えて調整する力が求められます。

「何を管理するか」が知識エリア、「それらをどうつなげるか」が統合マネジメント。

この視点を持つと、知識エリアを単なる暗記ではなく、実務で使える知識として理解できます。

関連用語

• PMBOK^®ガイド
• プロセス群
• プロジェクト統合マネジメント
• スコープ・マネジメント
• スケジュール・マネジメント
• コスト・マネジメント
• 品質マネジメント
• 資源マネジメント
• コミュニケーション・マネジメント
• リスク・マネジメント
• 調達マネジメント
• ステークホルダー・マネジメント

まとめ

知識エリアとは、プロジェクトマネジメントのプロセスを、管理する対象や専門領域によって分類したものです。

PMBOK^®第6版では、次の10の知識エリアに分類されていました。

• プロジェクト統合マネジメント
• プロジェクト・スコープ・マネジメント
• プロジェクト・スケジュール・マネジメント
• プロジェクト・コスト・マネジメント
• プロジェクト品質マネジメント
• プロジェクト資源マネジメント
• プロジェクト・コミュニケーション・マネジメント
• プロジェクト・リスク・マネジメント
• プロジェクト調達マネジメント
• プロジェクト・ステークホルダー・マネジメント

知識エリアを理解すると、プロジェクトマネージャがプロジェクトのどのような領域を管理する必要があるのかを体系的に整理できます。

また、プロセス群と組み合わせて考えることで、「何について」「どのような目的で」管理するのかを整理できます。

なお、PMBOK^®第7版では構成が大きく変更されているため、10の知識エリアは主に第6版までのプロセス中心の考え方として理解しておくとよいでしょう。

関連記事

• PMBOK^®ガイドとは？
• プロセス群とは？
• プロジェクト統合マネジメントとは？
• スコープとは？
• スケジュールとは？
• コストとは？
• 品質マネジメントとは？
• リスクマネジメントとは？
• コミュニケーションマネジメントとは？
• ステークホルダーエンゲージメントとは？

よくある質問（FAQ）

Q. 知識エリアとは何ですか？

A. プロジェクトマネジメントのプロセスを、何を管理するのかという専門領域によって分類したものです。PMBOK^®第6版では10の知識エリアが定義されていました。

Q. PMBOK^®第6版の10の知識エリアとは何ですか？

A. 統合、スコープ、スケジュール、コスト、品質、資源、コミュニケーション、リスク、調達、ステークホルダーの10の知識エリアです。

Q. 知識エリアとプロセス群の違いは何ですか？

A. 知識エリアは「何について管理するのか」による分類で、プロセス群は「どのような目的のプロセスなのか」による分類です。

Q. 知識エリアは現在のPMBOK^®でも使われていますか？

A. PMBOK^®第7版では、従来の10の知識エリアを中心とする構成から、12の原則と8つのプロジェクト・パフォーマンス領域を中心とする構成へ変更されています。ただし、スコープ、スケジュール、コスト、品質、リスクなどの管理対象そのものが重要でなくなったわけではありません。

Q. 知識エリアは順番に覚える必要がありますか？

A. 知識エリアはプロジェクトの実施順序ではありません。それぞれが相互に関係しながらプロジェクト全体を管理するため、何を管理する領域なのかを理解することが重要です。

「立上げ、計画、実行、監視・コントロール、終結とは何が違うのだろう？」

プロジェクトマネジメントを学んでいると、プロセス群（Process Groups）という言葉が登場します。

プロセス群とは、プロジェクトマネジメントのプロセスを、プロジェクトを進めるうえでの役割や目的によって分類したものです。

PMBOK^®第6版では、プロジェクトマネジメントのプロセスを次の5つのプロセス群に分類していました。

• 立上げプロセス群
• 計画プロセス群
• 実行プロセス群
• 監視・コントロール・プロセス群
• 終結プロセス群

この記事では、5つのプロセス群の意味や関係、第7版以降との違いについて解説します。

一言でいうと

プロセス群とは、プロジェクトマネジメントのプロセスを、その目的や役割によって分類したグループです。

PMBOK^®第6版では、49のプロジェクトマネジメント・プロセスを5つのプロセス群に分類していました。

プロセス群とは

プロジェクトでは、プロジェクトを開始するだけでなく、計画を立て、作業を実行し、状況を確認・調整し、最後にプロジェクトを終了させる必要があります。

これらの活動を整理したものがプロセス群です。

5つのプロセス群を簡単に表すと、次のようになります。

イメージとしては、

「始める → 計画する → 実行する → 確認・調整する → 終わらせる」

という流れで考えると分かりやすいでしょう。

5つのプロセス群

1．立上げプロセス群

立上げプロセス群は、プロジェクトやフェーズを正式に開始するためのプロセス群です。

プロジェクトの目的や概要を確認し、プロジェクトを正式に開始します。

代表的な活動として、プロジェクト・チャーターの作成やステークホルダーの特定などがあります。

つまり、

「そもそも、このプロジェクトを始めてよいのか。そして、誰が関係するのか」

を明確にする段階です。

2．計画プロセス群

計画プロセス群は、プロジェクトの目標を達成するために、どのようにプロジェクトを進めるのかを決めるプロセス群です。

例えば、次のような計画を作成します。

• スコープ
• スケジュール
• コスト
• 品質
• 資源
• コミュニケーション
• リスク
• 調達
• ステークホルダー

プロジェクトを成功させるための「設計図」を作る段階と考えると分かりやすいでしょう。

3．実行プロセス群

実行プロセス群は、プロジェクトマネジメント計画書に基づいてプロジェクト作業を実施するプロセス群です。

例えば、

• 成果物を作成する
• チームをマネジメントする
• コミュニケーションを実施する
• 品質を保証する
• ステークホルダーと関係を築く
• 調達を実施する

といった活動を行います。

計画を実際の行動に移す段階です。

4．監視・コントロール・プロセス群

監視・コントロール・プロセス群は、プロジェクトの進捗や実績を確認し、必要に応じて是正措置や変更を行うプロセス群です。

例えば、

• スケジュールの遅延を確認する
• コストの超過を確認する
• 品質を確認する
• リスクや課題を監視する
• 変更要求を評価する
• 必要な是正措置を行う

といった活動を行います。

ここで重要なのは、監視・コントロールは「実行が終わってから行うもの」ではないということです。

実行と並行して継続的に行われることがポイントです。

5．終結プロセス群

終結プロセス群は、プロジェクトやフェーズを正式に終了するためのプロセス群です。

成果物を正式に受け入れてもらい、契約を完了し、プロジェクトの記録を整理するなど、プロジェクトを終了するための活動を行います。

また、プロジェクトで得られた教訓を整理し、組織の将来のプロジェクトに活用できるようにすることも重要です。

5つのプロセス群の関係

5つのプロセス群は、単純に一方向へ進むだけではありません。

特に重要なのが、監視・コントロール・プロセス群が、プロジェクトの実行と並行して行われるという点です。

例えば、計画に基づいてプロジェクトを実行しているときに、スケジュールの遅延が発生したとします。

監視・コントロールによって遅延を把握し、原因を分析します。

その結果、計画を変更する必要があれば、変更要求を行い、承認された変更を計画に反映して実行します。

つまり、

計画 → 実行 → 監視・コントロール → 必要に応じて計画や実行を調整

という循環が発生します。

プロセス群と知識エリアの違い

PMBOK^®第6版を理解するうえで、プロセス群と知識エリアの違いを理解しておくことが重要です。

例えば、「リスク・マネジメント」という知識エリアの中にも、計画、実行、監視・コントロールなど、複数のプロセス群にまたがるプロセスがあります。

したがって、

プロセス群＝「いつ・どのような目的で行うプロセスなのか」

知識エリア＝「何について管理するプロセスなのか」

と考えると整理しやすくなります。

プロセス群と第7版の違い

ここは現在のPMBOK^®を学ぶ際に注意が必要なポイントです。

PMBOK^®第6版では、プロジェクトマネジメントを49のプロセスと5つのプロセス群、10の知識エリアという構造で整理していました。

一方、第7版では、プロセス中心の構成から、プロジェクトマネジメントの原則とパフォーマンス領域を中心とした構成へ大きく変わりました。

そのため、現在のPMBOK^®を学ぶ場合には、「5つのプロセス群＝現在のPMBOK^®の中心的な構成」と考えないことが重要です。

ただし、プロジェクトマネジメントの基本的な流れを理解するうえでは、5つのプロセス群は現在でも非常に分かりやすい考え方です。

プロセス群を覚えるポイント

5つのプロセス群は、次の順番で覚えると分かりやすいでしょう。

立上げ → 計画 → 実行 → 監視・コントロール → 終結

ただし、「監視・コントロール」は実行後に一度だけ行うものではありません。

実際には、プロジェクトの実行中に継続して状況を監視し、必要に応じて調整します。

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

例えば、新しいシステムを開発するプロジェクトを考えてみます。

まず、プロジェクトの目的や関係者を整理し、正式にプロジェクトを開始します。

次に、必要な機能、スケジュール、予算、リスクなどを計画します。

その後、実際に開発作業を進めます。

実行中は、進捗やコスト、品質などを確認し、計画との差異があれば必要な対応を行います。

最終的に成果物が受け入れられ、必要な手続きを終えたら、プロジェクトを正式に終了します。

この一連の流れを整理するための考え方がプロセス群です。

よくある勘違い

プロセス群は必ず順番に一度ずつ実施するものではない

5つのプロセス群は、プロジェクトを理解するための分類です。

特に実行と監視・コントロールは並行して行われ、必要に応じて計画を見直すこともあります。

監視・コントロールは問題が起きたときだけ行うものではない

監視・コントロールは、プロジェクトの状況を継続的に確認する活動です。

問題が起きてから確認するのではなく、計画との差異を早期に把握し、必要な対応を取ることが重要です。

プロセス群と知識エリアは同じではない

プロセス群はプロセスの目的・役割による分類であり、知識エリアはプロジェクトマネジメントの専門領域による分類です。

両者を混同しないように注意しましょう。

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

プロジェクトマネージャ試験でPMBOK^®の考え方を理解する際には、5つのプロセス群を単なる暗記項目として覚えるのではなく、それぞれの役割を理解することが重要です。

• 立上げ＝プロジェクトを正式に開始する
• 計画＝プロジェクトの進め方を決める
• 実行＝計画に基づいて作業を行う
• 監視・コントロール＝実績を確認し、必要に応じて調整する
• 終結＝プロジェクトやフェーズを正式に終了する

特に、「監視・コントロールは実行と並行して行われる」という点は重要です。

PM道場のワンポイント

プロセス群は「プロジェクトをどのように動かしていくのか」を理解するための地図です。

実務では、計画を作ったらそのまま計画どおりに進むとは限りません。

実行してみると問題が発生し、監視・コントロールによってその問題を発見し、計画を修正することがあります。

そのため、プロセス群を、

「立上げ → 計画 → 実行 → 終結」という一本道

ではなく、

「計画して、実行して、確認して、必要なら修正する」

という循環を含む仕組みとして理解することが重要です。

なお、PMBOK^®第7版では構成が大きく変わっているため、試験や実務で利用する際には、どの版の考え方を扱っているのかを確認するようにしましょう。

関連用語

• PMBOK^®ガイド
• 知識エリア
• プロジェクトマネジメント・プロセス
• プロジェクト・チャーター
• プロジェクトマネジメント計画書
• スコープ
• スケジュール
• コスト
• リスクマネジメント
• 変更要求
• 監視・コントロール
• 終結

まとめ

プロセス群とは、プロジェクトマネジメントのプロセスを、その目的や役割によって分類したものです。

PMBOK^®第6版では、次の5つのプロセス群に分類されていました。

• 立上げプロセス群
• 計画プロセス群
• 実行プロセス群
• 監視・コントロール・プロセス群
• 終結プロセス群

プロセス群を理解すると、プロジェクトマネジメントの活動を「プロジェクトのどの段階で、何のために行うのか」という視点から整理できます。

特に重要なのは、監視・コントロールが実行後に行われるのではなく、プロジェクトの実行と並行して継続的に行われるということです。

また、PMBOK^®第7版では構成が大きく変更されているため、5つのプロセス群は主に第6版までのプロセス中心の考え方として理解しておくとよいでしょう。

関連記事

• PMBOK^®ガイドとは？
• 知識エリアとは？
• プロジェクト・チャーターとは？
• プロジェクトマネジメント計画書とは？
• スコープとは？
• スケジュールとは？
• コストとは？
• リスクマネジメントとは？
• 変更要求とは？
• 終結とは？

よくある質問（FAQ）

Q. プロセス群とは何ですか？

A. プロジェクトマネジメントのプロセスを、その目的や役割によって分類したグループです。PMBOK^®第6版では、立上げ、計画、実行、監視・コントロール、終結の5つに分類されていました。

Q. 5つのプロセス群とは何ですか？

A. 立上げプロセス群、計画プロセス群、実行プロセス群、監視・コントロール・プロセス群、終結プロセス群の5つです。

Q. プロセス群と知識エリアの違いは何ですか？

A. プロセス群はプロセスの目的・役割による分類で、知識エリアはスコープ、スケジュール、コスト、リスクなど、プロジェクトマネジメントの専門領域による分類です。

Q. 監視・コントロール・プロセス群はいつ行いますか？

A. プロジェクトの実行と並行して継続的に行います。プロジェクトの実績を確認し、計画との差異があれば必要な対応や調整を行います。

Q. PMBOK^®第7版にも5つのプロセス群がありますか？

A. PMBOK^®第7版では、第6版までのプロセス中心の構成から、原則やパフォーマンス領域を中心とした構成へ大きく変更されています。そのため、第6版までの5つのプロセス群を現在のPMBOK^®の中心的な構成として扱うことは適切ではありません。

• 令和4年度秋期 プロジェクトマネージャ試験 午後Ⅱ
  
  問題冊子はこちら
  
  出典：IPA 独立行政法人 情報処理推進機構

※掲載している問題冊子へのリンクおよび試験問題の著作権は、IPA 独立行政法人 情報処理推進機構に帰属します。最新情報はIPA公式サイトをご確認ください。

対応する知識エリアはリスクマネジメント。マイナスの影響を与える脅威だけではなく、プラスの影響を与える機会の両方を論じる必要があります。対応戦略の分類も知識として必要です。リスクを「機会」と「脅威」に分け、それぞれに対して対応策を検討する力が問われています。

この記事では、どのように論述していけばよいか要点を分析しましたので、その解説をします。

結論：機会と脅威は分けて、それぞれに対策を書く

この問題の論じ方はシンプルです。

• リスクは機会と脅威がある
• それぞれに対して対応策を検討する

さらに以下の流れで書きます。

• 変更要求
• 影響分析（リスク特定）・機会と脅威の分類
• それぞれの対応策
• 計画変更

このそれぞれを関連性をもって論じることで、プロジェクトマネジメントの力をアピールできます。

設問アは「QCDで定量的に書く」

以下3点について説明します。

• ①システム開発プロジェクトの概要と目的
• ②計画変更の背景となった事業環境の変化
• ③プロジェクトチームの外部のステークホルダから実行中に受けた計画変更の要求内容

①プロジェクト概要と目的は具体的、定量的に

プロジェクトの概要と目的について説明しますが、具体的に定量的に説明しましょう。QCDの観点で説明すると良いです。この後、計画変更の要求内容について説明しなければならないので、この時点で定量的に説明できると納得感を与えられる論述ができます。

例：

• 品質：応答時間2秒以内
• コスト：予算1000万円
• 納期：6ヶ月

ポイント

• 必ず定量的に書く
• 後の比較につなげる

②事業環境の変化は比較で書く

事業環境の変化ですが、顧客ニーズや競合、法規制や技術革新、経営戦略や人事異動、為替変動や災害・パンデミックなど、様々なものがあります。具体的に変化前後を比較して説明しましょう。これもQCDの観点でまとめるとわかりやすいです。

例：

• 顧客ニーズ
  • 変更前：標準機能重視
  • 変更後：個別カスタマイズ要求増加
• 競合
  • 変更前：競合なし
  • 変更後：新規参入で短納期化

コツ

• 変化前後を書く
• QCDへの影響を意識する

③計画変更は具体的に書く

計画変更について論じます。どの計画がどのように変更になったのか具体的に説明しましょう。QCDの観点で、定量的に変化前後をわかりやすく説明することが重要です。さらに計画変更による二次的な影響にも触れられるとさらに良いです。

例：

• 納期：6ヶ月 → 5ヶ月
• コスト：1000万円 → 1200万円
• 品質：機能追加で複雑化

さらに以下も書きます。

• 二次影響（品質低下リスクなど）

設問イは「機会と脅威を分けて対策を書く」

計画変更の要求を受けて策定した以下3点について説明します。

• ①機会を生かす対応策
• ②脅威を抑える対応策
• ③確定させた計画変更の内容

ここで重要なのは、変更要求→影響分析（リスクの特定）→対応策検討→計画変更の流れを踏まえて、論述することです。

①機会への対応策

機会を生かす対応策としてPMBOK®︎ガイドでは以下の戦略が示されています。

• 活用：確実に実現する
• 共有：他者と協力する
• 強化：発生確率を高める
• 受容：発生時に対応する

いつ、誰が、どうやるのか、具体的な対策を説明しましょう。

②脅威への対応策

脅威を抑える対応策としてPMBOK®︎ガイドでは以下の戦略が示されています。

• 回避：原因をなくす
• 転嫁：外注や契約で移す
• 軽減：影響を小さくする
• 受容：許容する

こちらもいつ、誰が、どうやるのか、具体的な対策を説明しましょう。

書き方（例）

• いつ：基本設計段階
• 誰が：PMとリーダー
• 何を：追加機能の優先開発

③計画変更は対応策とセットで書く

確定させた計画変更の内容は具体的に説明しましょう。それぞれの対応策との関係性を論理的に説明できると良いです。また、計画変更はQCDに影響を与えます。QCDがどのように変わるのかにも触れましょう。

例：

• テスト不足の脅威に対して軽減策を実施
• 要員を2名追加
• 納期を1ヶ月延長

設問ウは「結果を定量的に評価する」

以下2点について説明します。

• ①計画変更の実施の状況
• ②その結果による事業環境の変化への対応の評価

どちらも定量的に論じることが重要です。QCDに関連付けて説明しましょう。

①実施状況

計画変更の実施の状況は、実施したタイミング、実施した具体的内容、効果は想定通りだったか、想定外の効果も現れたか、そしてQCDに対する結果をわかりやすく説明しましょう。QCD に対する結果は定量的に説明することが重要です。

例：

• タイミング：基本設計完了後
• 内容：要員追加、外注化
• 結果：遅延2週間 → 解消

②対応の評価は第三者視点で書く

事業環境の変化への対応の評価は、定量的に論じることが重要です。QCDに対しての評価を説明しましょう。プロジェクトマネージャとしての主観的な評価ではなく、第3者による客観的な評価であるとなお良しです。第3者とは、例えば上位マネジメント、顧客、他プロジェクトのプロジェクトマネージャなどです。

例：

• 顧客：品質向上を評価
• 上位マネジメント：コスト増は許容
• 他プロジェクトマネージャ：対策の再現性あり（他のプロジェクトの参考になる）

ポイント

• 客観的に書く
• 数値を使う

まとめ

• リスクは機会と脅威がある
• それぞれに対して対応策を検討する
• QCDで定量的に書く

この流れで説明できればわかりやすい論文となり、プロジェクトマネジメントの力もよりアピールでき、合格につながるはずです。

プロジェクトマネジメントを学び始めると、必ずと言ってよいほど登場するのがPMBOK®︎ガイドです。

PMP®試験の学習教材として知られていますが、それだけではありません。

PMBOK®︎ガイドには、世界中のプロジェクトで活用されているプロジェクトマネジメントの考え方やベストプラクティスが体系的にまとめられています。

この記事では、PMBOK®︎ガイドとは何か、第6版と第7版の違い、実務でどのように活用できるのかをわかりやすく解説します。

一言でいうと

PMBOK®︎ガイドとは、「プロジェクトマネジメントの知識や考え方を体系的にまとめた国際標準のガイドブック」です。

PMBOK®︎ガイドとは

PMBOK®︎ガイド（Project Management Body of Knowledge）は、プロジェクトマネジメントに関する知識体系をまとめたガイドブックです。

世界中のさまざまな業界やプロジェクトで培われた知識や実践例をもとに作成されており、多くの企業やプロジェクトで共通の指針として活用されています。

PMBOK®︎ガイドは、「この通りに実施すれば必ず成功する」という手順書ではありません。

プロジェクトを成功へ導くための考え方やベストプラクティスをまとめたガイドであり、プロジェクトの特性に応じて柔軟に活用することが前提となっています。

PMBOK®︎ガイドが重要な理由

プロジェクトの進め方は、企業や業界によって異なります。

しかし、プロジェクトマネジメントの基本的な考え方には共通する部分があります。

PMBOK®︎ガイドは、その共通となる考え方を整理した「共通言語」としての役割を果たしています。

• プロジェクトマネジメントを体系的に学べる
• 世界共通の考え方でコミュニケーションできる
• PMP®試験の基礎知識として活用できる
• 実務でプロジェクトを改善するヒントになる

PMBOK®︎ガイドの構成

PMBOK®︎ガイドは複数回改訂されており、現在の最新版は第7版です。

第6版までと第7版では、考え方が大きく変わりました。

第6版までの構成

第6版までは、「プロジェクトをどのような手順で進めるか」というプロセス中心の考え方でした。

• 10の知識エリア
• 49のプロセス
• 5つのプロセス群（立上げ・計画・実行・監視・コントロール・終結）

プロジェクトマネージャが実施すべき活動を体系的に整理した内容となっています。

第7版での変化

第7版では、「決められた手順を実施すること」から、「価値を提供すること」へ重点が移りました。

主な特徴は次のとおりです。

• 12のプロジェクトマネジメント原則
• 8つのパフォーマンス領域
• 価値提供を重視した考え方
• アジャイルやハイブリッド開発への対応

これにより、プロジェクトの状況に応じて柔軟にマネジメントする考え方がより重視されています。

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

PMBOK®︎ガイドは、実務でもさまざまな場面で活用できます。

例えば、プロジェクト計画を立てる際には、知識エリアを確認することで、検討漏れを防ぐことができます。

また、プロジェクトがうまく進まない場合には、PMBOK®︎ガイドの考え方を参考にすることで、改善のヒントが見つかることもあります。

具体的には、次のような活用方法があります。

• プロジェクト計画書のチェックリストとして活用する
• 新人PMやメンバーへの教育資料として利用する
• PMP®試験の学習教材として活用する
• プロジェクト改善の参考資料とする

よくある勘違い

PMBOK®︎ガイドは「手順書」ではない

PMBOK®︎ガイドは、決められた作業手順を示すマニュアルではありません。

プロジェクトの状況に応じて、必要な考え方や手法を選択しながら活用するためのガイドです。

PMBOK®︎ガイドをそのまま適用すれば成功するわけではない

プロジェクトには、それぞれ異なる特徴があります。

そのため、PMBOK®︎ガイドの内容をそのまま適用するのではなく、プロジェクトに合わせてテーラリングすることが重要です。

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

IPAのプロジェクトマネージャ試験では、「PMBOK®︎」という名称そのものを問う問題は多くありません。

しかし、スコープ、スケジュール、リスク、品質、コミュニケーションなど、PMBOK®︎ガイドで整理されている考え方は試験全体を通して活用されています。

また、PMP®試験を受験する場合には、PMBOK®︎ガイドの理解が非常に重要になります。

PM道場のワンポイント

PMBOK®︎ガイドは、「正解集」ではなく、「考え方を学ぶための教科書」です。

実務では、「PMBOK®︎にはこう書いてあるから」という理由だけで進めても、必ずしもプロジェクトは成功しません。

重要なのは、PMBOK®︎ガイドで学んだ知識を、自分のプロジェクトに合わせて活用することです。

優れたプロジェクトマネージャは、PMBOK®︎ガイドを暗記するのではなく、状況に応じて使いこなしています。

関連用語

• プロジェクト
• プロジェクトマネージャ
• テーラリング
• ステークホルダー
• リスクマネジメント
• スコープ
• PMP®
• アジャイル

まとめ

PMBOK®︎ガイドとは、プロジェクトマネジメントの知識や考え方を体系的にまとめた国際標準のガイドブックです。

第7版では、価値提供や柔軟なプロジェクトマネジメントが重視されるようになりました。

実務では、PMBOK®︎ガイドをそのまま適用するのではなく、プロジェクトの状況に応じてテーラリングしながら活用することが重要です。

PMBOK®︎ガイドは「何を考えるべきか」を教えてくれます。しかし、「そのプロジェクトでどう実践するか」はプロジェクトマネージャ自身が考えなければなりません。PM道場では、その「実践する力」を身につけることを大切にしています。

関連記事

• プロジェクトとは？
• プロジェクトマネージャとは？
• テーラリングとは？
• ステークホルダーとは？
• リスクマネジメントとは？

よくある質問（FAQ）

Q. PMBOK®︎ガイドとは何ですか？

A. プロジェクトマネジメントの知識や考え方を体系的にまとめた国際標準のガイドブックです。

Q. PMBOK®︎ガイド第6版と第7版の違いは何ですか？

A. 第6版まではプロセス中心、第7版では価値提供や原則中心の考え方へと大きく変わりました。

Q. PMBOK®︎ガイドは実務でも役立ちますか？

A. はい。プロジェクト計画の確認や、リスク管理、チーム教育など、さまざまな場面で活用できます。