プロジェクト管理技法?

プロジェクトマネジメントとは

システム構築におけるプロジェクトマネジメントとは、システム構築プロジェクトを計画された通りに遂行させることです。言い換えるとQCD（品質、コスト、納期）を計画通りに終わらせる事とも言えます。つもり、どのようにマネジメントをすればいいのでしょうか。プロジェクトマネジメント技法として代表的なPMBOKがあります。 PMBOKをプロジェクト活動に適用すればプロジェクトマネジメントが可能となります。

PMBOKとは PMBOK（Project Management Body Of Knowledge）とは「プロジェクトマネジメントの知識体系」です。プロジェクトマネジメントに必要なプロセスが定義されており、各プロセスには目的や概要、インプット、アウトプット、ツールと技法が体系的に定義されています。また、従来のQCD達成にとどまらず、管理項目などを含めた全体最適を目的としています。 PMBOKの歴史は古く、1987年にPMI（Project Management Institute：PM協会）から発表され、現在はPMBOKガイド第７番（2021年）となります。 PMBOKガイド第７番では、これまでのプロセスベースの考え方から大きく変わり、プロジェクトマネジメントの原理・原則について掲載しています。

PMIとは PMBOKガイドの原文は英語で、日本語のほか多くの言語に翻訳させておりPMIが監修を行って発行されていいます。現在では国際的標準マネジメント技法としてPMBOKが広く活用されています。また、PMIはプロジェクトマネジメント・プロフェッショナル（PMP）の資格確定も行っており、プロジェクトマネジメントを広く普及させる活動もしています。

PMPとは PMPとは、プロジェクトマネジメントの認定資格です。試験でPMBOKガイドに定められた用語が採用されており、概念やプロセスの目的・活動に関するインプット情報、ツール・技法、アウトプット情報が出題されます。出題内容はPMBOKガイドのみではなく、マネジメントスキルやPMIの倫理限定も出題されます。また、受験申請の条件もあり、プロジェクトマネジメントの学習実績とプロジェクトマネジメントの指導・監督の経験も必要となります。 PMP以外にも、CAMP（Certified Associate in Project Management）試験もあります。 CAMPはプロジェクトマネジメントの実務経験は不要です。プロジェクトメンバや経験の凄いプロジェクトマネージャー、学生を対象にしたもので、経験や知識の度合いを図ることを目的にしています。

PMBOKのメリット現在ぼPMBOK（第６番）では10個の知識エリアと５つのプロセスで分類されています。知識エリアをマネジメントと読み替えてもいいでしょう。

５つのプロセスはプロジェクトの開始から終結までの流れ（立上げ、計画、実行、監視・コントロール、終結）、10個の知識エリアは場合、スコープ、スケジュール、コスト、品質、資源、コミュニケーション、リスク、調達、ステークホルダーとなっており、計49のプロセス（手順／処理）があります。 PMBOKでは、プロジェクトの状況により実施するプロジェクトを選択することを推奨しています。小規模プロジェクトなどでは必要なプロセスを選択すればよいということです。それは該当プロジェクト用に仕立て直すという意味合いでテーラーリングとも言われています。また、マネジメントとして何をやるべきか、何をやらないのか、漏れはないかという観点でのチェックリストとして活用できます。

PMBOK活用の注意点プロジェクトマネジメント技法として優れたPMBOKですが、プロジェクトを推進する「人」に関しては、あまり触れられていません。プロジェクトを推進するのはPM（プロジェクトマネージャー）やPL（プロジェクトリーダー）です。推進する人にどのような能力（スキル）が必要なのかは触れられていないです。さらにプロジェクトメンバも人です。プロジェクトは人の集まりです。いかに思い通りに動かない人を思い通りは動いたてもらうか、これがプロジェクト推進の神髄と言っても過言ではありません。経験豊富なＰＭ／ＰＬであれば、これまでの経験や人との関係でうまく推進できるでしょう。しかし経験の凄いＰＬがどうでしょう。プロジェクトの中には様々な人がいます。年長者、声の大きい人、無口で何を考えているかわからない人、技術力が高い人などです。さらに視野を広げると利用部門や発注者など多くの人が変わります。プロジェクトを成功させるためには、プロジェクトマネジメント技法の習得だけではなく、ヒューマンスキル（対人能力）も重要だということです。

PMBOKの計画プロセス計画プロセスとは、その名の通りプロジェクトの計画を立てることです。つまり、システム構築プロジェクトであれば、システム構築の実作業を行う前に実施しておくべきことです。計画プロセスは全ての知識エリアにおいて計画を実施する必要があります。では、計画を行うとはどういうことでしょうか。

私たちは、限られた資源を最大限に活用し、利用者（ユーザー）が求めるシステムを、高い品質で、決められた期限までに作り上げることが求められています。無計画にプロジェクトを進めるのではなく、成功させるのための計画を立ててプロジェクトを進めることが大切です。スコープ・マネジメント計画プロセスでの「スコープ」知識エリアでは、４つのプロセスが定義されています。・スコープ・マネジメントの計画・要求事項の収集・スコープの定義・WBSの作成スコープとは、要求事項の範囲と、成果物や作業の範囲のことです。つまり、要求者（ユーザーや利用者、発注者）の要求事項をどの範囲まで対象とするのか。その要求事項をシステム化するために、どういう成果物が必要で、そのためにどういう作業が必要なのか、を明確にするということです。不十分なsスコープ・マネジメントスコープが不明確・合意できない状況では、多くんの場合がトラブルもしくはそれに近い状況になっています。例えば要求事項をのスコープが合意されない状況でプロジェクトが進み、設計がや製造のフェーズになって「この機能が足りない」、「この画面が無いと業務が回らない」といった追加要求が発生した場合、トラブルの元となります。また、作成する成果物が不明確だった場合は、「この計画書が無いと製造ができない」ということで、新たな成果物を作成することになります。計画していない要求事項や成果物を対象にするということは、計画したリソースでは対処できないということです。このような対象は私自身も経験がありますし、周りのプロジェクトでもよく見られる対象です。スコープは、プロジェクト活動の範囲です。この範囲が変更するということは、コストや納期を守らないことを意味します。逆にコストと納期を守ろうとすれば品質を犠牲することになります。つまり「QCD（品質、コスト、納期）を守らない＝トラブルになる」とも言えるでしょう。プロジェクト活動においてスコープは、それほど重要なものだということをご理解ください。スコープ・マネジメントの計画プロジェクト活動の範囲を定めるものであり、プロジェクト活動中に計画範囲を維持しているかどうかを判断する拠り所となります。また、プロジェクト計画書やRFPに記述されたプロジェクトの範囲をより詳細化することを目的としています。プロジェクト・スコープとして、システム開発のみか、それとも導入やシステム利用教育、データ移行も対象とするのか。ここで大切なことは、「実施しないことは何か」を明確にするということです。要求者は「やってくれると思ってた」、受託者は「対象外のつもりだった」ということがあってはスコープが合意できたと言えません。そして、要求事項のスコープ（範囲）が変わったときにはどのような対応を行うのか、なども明確にします。要求事項の収集要求事項の収集は各社様々な方法を活用させていますが、代表的なものは要求者からのインタビュー（打合せ等）になるでしょう。その際に業務フォローを活用したり、ユースケースを活用したりして、スコープの認識を合わせることが大切です。スコープの定義プロジェクト計画の中核業務であるスケジュール計画、資源計画、費用計画を設定するための基本法情報となるものです。・プロジェクトのアウトプットとなる全ての成果物を明確にする・成果物を作成するために必要な作業構造を概要レベルで構造的に把握する・概要レベルの作業要素ごとに役割を決定する WBSの作成 WBS（Work Breakdown Structure）はその各の通り、必要となる作業（Work）をトップダウン的に分析（Breakdown）し、階層構造（Structure）で表したものです。プロジェクトに必要な全ての作業を洗い出し、抜け漏れが無いようにしなけれななりません。「必要な全ての作業」ですから要求者の作業、受託者の作業の全てを洗い出すことが望ましいです。導入作業やデータ移行、システム利用教育などは忘れがちなので注意が必要です。また、プロジェクトリーダーが実施するマネジメントに関する作業も洗い出すようにしましょう。このあとWBSをもとにスケジュールを計画します。マネジメント作業もWBSで明確にしておかないと、スケジュール化されなくなり、想定外の時間を費やすことになってしまいます。スケジュール・マネジメント計画プロセスでの「スケジュール」知識エリアは、５つプロセスが定義されています。・スケジュール・マネジメント計画・アクティビティの定義・アクティビティの順序設定・アクティビティの所要期間見積もり・スケジュールの作成スケジュール・マネジメントは、スコープ・マネジメントで定めた要求事項範囲の成果物作成や作業をいつ・誰が、どれだけの時間を掛けて行うのかを具体的にします。

無視なスケジュールは立てない担当者に作業を割り当てる際には、担当者の能力や生産性なども考慮する必要があります。経験の凄いメンバや能力が十分でないメンバに難しい作業を割り当てると見積もった工数・期間では完了できない場合が多いので以下の点に考慮が必要です。 ‐　経験の凄いメンバには所要時間を1.5～２倍にする ‐　サポートメンバを付ける ‐　難易度の高い機能要件や作業の場合は所要時間や期間の余裕を十分に持たせる ‐　利用するDBや開発言語がメンバにとって未経験のものであれば、教育や学習時間の考慮をする仮にメンバの１人が計画した期日通り完成できなかった場合、それは遅延となりそのメンバの後続作業も遅れます。他メンバの作業にも影響する可能性があります。当然のことながら後工程にも大きく影響する可能性が高くなります。大切なことは、無理なスケジュールを立てない、出来るスケジュールを計画するということです。スケジュール・マネジメント計画スケジュール・マネジメント計画書を作成します。計画書では以下の内容を明確にする必要があります。スケジュールの計画・策定標準以下の内容を考慮に設定します。・生産性基準精度の高い生産性基準を適用・全体スケジュールの単位分画と単位ごとの計画・評価工程や成果物に対して、承認者や実施者を明確にする（TRM：Task Reponsitory Matrix） TRMの例

TL：タスクリーダ・日程計画の多段化大日程（月レベル）、中日程（週レベル）、小日程（日レベル）など粒度を分ける。これにより全体進捗を見るときは大日程で、詳細進捗は小日程で、という使い分けが可能・マイルストーンの明確化日程別の成果物完成時間やイベントなどを明確化進捗管理の方法・管理指標の明確化各工程の進捗状況を計る指標を明確にします（設計書完了数、プログラム完成数、テスト消化率、バグ発生数と解決数、など）・期限管理と消化率管理予定・実績の定量的把握を行うための管理方法を取り決めます（50/50法や各社独自の進捗率定義等）監視・コントロールプロセス実施の方針および手順・進捗管理の徹底日々進捗実績登録、短期サイクル（週単位など）での進捗ミーティング、進捗状況書作成（定量的・具体的な現状把握、遅延状況、問題発生状況など）を決めます・遅延・問題発生時の迅速な対策・対応遅延や問題が顕在化したとき報告ルートや報告資料等を明確にするとともに、問題種類ごとの対応策方針を明確にしますアクティビティの定義アクティビティの順序設定アクティビティの所要期間見積もり WBSをブレーキダウンした最下位レベルの成果物を生き出す作業項目をワークパッケージと呼び、ワークパッケージを完了するために必要な作業のことをアクティビティと呼ぶ。

ワークパッケージ毎に必要となるアクティビティの洗い出しを行い、アクティビティの実績順序を明確にするとともに、各アクティビティの所要時間の見積もりを行うスケジュールの作成スコープ・マネジメントで作成したWBSと定義したアクティビティ（順序設定、所要期間見積もり済み）により、プロジェクトとしてやることが明確になりました。それをスケジュール管理ツール（Excelやタスク管理製品など）で明文化します。アクティビティ毎に担当者の割り当てを行い、開始日・完了日も明確にする必要があります。コスト・マネジメント計画プロセスでの（コスト）知識エリアは、３つプロセスが定義されています。・コスト・マネジメントの計画・コストの見積もり・予算の設定コスト・マネジメントは、スコープ・マネジメントで定めたWBSおよびスケジュール・マネジメントで定めたアクティビティを実行するための費用を算出します。

コスト見積もりは難しい見積もりを正確に行うことは困難です。例えばこれから要件定義を始めようとするタイミングで見積もりを行った場合、プロジェクトが終了した時点での実績値と比較すると大きな乖離ができることが多くなります。要件定義はシステムとしてどのようなシステム機能が必要となるのかを具現化する工程です。要件定義を行う中で「この機能が必要、こんな画面があれば業務効率が上がる」などの理由でシステム機能数は増減します。すなわち不確実な状態を見積もっているということです。

特に見積もりを一人を行った場合、私の周辺ではこの傾向が多いように感じます。人によって感じ方受け止め方は様々です。一人の目線で見積もりをすると見逃しや認識違いが発生するためだと思っています。しかしながら、予算確保のためには見積もりは必要不可欠です。出来る限り正確な見積もりを行うためには以下に留意することをお勧めします。・複数名が各々見積もりを行い、全員で精査する・過去の類似プロジェクトでの生産性などを活用するコスト見積もりは上流工程になればなるほど実態との乖離幅が広がる可能性があると言われています。この特性を表すのが「不確実性コーン」です。