プロジェクトを推進するものは？
前回（「第5回 後で後悔しないための品質マネジメント」で品質マネジメントを解説した。その極意は、タイトルにも含みがあるように先手、先手のアプローチにある。つまり、何か問題が起こってから対処するのではなく、問題に発展しそうなことを未然に察知し、その芽を摘んでいくことである。プロジェクトの状況が厳しくなるとどうしても問題が次から次へと発生し、その対応に追われ、後手後手の対応となってしまいがちである。そんな中でもせめてプロジェクト全体をコントロールするプロジェクトマネージャは、常に1歩、2歩先を見据えて行動できるようにしたい。
これまでの連載では、スコープ、時間、コスト、品質という基本的なマネジメント領域について解説してきた。これらはPMBOK以前のプロジェクトマネジメント（PM）でも重要視されてきた領域である。だが、これらをうまくコントロールするだけでプロジェクトを円滑に推進できるかといえば、プロジェクトはそれほど単純なものではない。
実際にプロジェクトを推進するのは「人」である。プロジェクトに携わる「人」の持てる力を最大限に引き出すことがプロジェクト成功への近道であり、プロジェクトマネージャに求められる重要な責務の1つである。このことは、例えば、スポーツの世界においても監督が変わった途端に好成績を挙げるようなケース、または、その反対のケースが見受けられることでもお分かりいただけるだろう。
PMBOKにおいても「人」は重要な要素として扱われており、「人」と関連の強い知識エリアとして「組織（人的資源）」と「コミュニケーション」に2章が割かれている。その中で今回はまず、「組織（人的資源）マネジメント」について解説する。
では、まずPMBOKにおける組織（人的資源）マネジメントの定義を確認することにしよう。
組織（人的資源）マネジメントとは
PMBOKには、「組織（人的資源）マネジメントは、プロジェクトに関与する人々を最も効果的に活用するために必要なプロセスからなる」とある（表1）。
| プロセス | 主要成果物 | 説明 |
|---|---|---|
| 組織計画 | ・組織（体制）図 ・役割（責任）分担表 ・要員マネジメント計画書ほか |
プロジェクトにおけるチームおよび個人の役割、責任、報告関係を明確にする。 |
| 要員調達 | ・プロジェクトメンバーのアサイン ・プロジェクトチーム名簿 |
必要な人的資源を実際にプロジェクトにアサインし業務遂行可能な状態にする。 |
| チーム育成 | ・業務遂行能力の向上 ・業績評価への基礎情報 |
メンバー個人の育成とチームとしてのパフォーマンスの最大化を両面からアプローチする。 |
| 表1 PMBOKにおける組織（人的資源）マネジメント | ||
つまり、組織（人的資源）マネジメントとしてなすべきことは
- 誰が何をして誰が何を決定するか、および、誰が誰に何を報告し誰から何の報告を受けるかを明確にする。
- 要員計画で必要とされた要員を調達・手配しプロジェクトにアサインする。
- 個人として最大限のパフォーマンスが発揮できるようナビゲートするとともに、チームまたはグループとしても最大限のパフォーマンスを発揮できるようにする。
という3点に要約される。
以下では、「組織計画」「要員調達」「チーム育成」という3つのプロセスにおける実践的な勘所を紹介しよう。
チーム単独ではプロジェクトは進まない
あなたの部署に2つのシステム開発案件がある。その2つのプロジェクトは共に設計フェイズが無事終わろうとしており、開発フェイズにおけるプロジェクト体制と役割を検討している（表2）。
| 主な作業 | 想定アサイン メンバー数 |
|---|---|
| 詳細設計・開発 | 7名 |
| 単体・結合テスト | |
| データ移行設計 | |
| データ移行プログラム開発 | |
| 開発・テスト環境構築・維持 | |
| 本番環境準備 | |
| システム運用設計 | |
| 表2 プロジェクトの前提 | |
さて、2つのプロジェクトではそれぞれ体制案が出来上がり、メンバーに説明しているようだ。その様子をのぞいてみることにしよう。
矢見雲マネージャの発言
「こんな感じかな（図1）。あとはスケジュールを見ながら細かいところは各リーダーでよく話し合って決めてよ」
「じゃあ、あとはよろしく頼むよ」
出来杉マネージャの発言
「開発フェイズからの体制はこのような形で進めようと思う」（図2）
「今回は規模もそれほど大きくはないが、やはりチーム横断的に調整が必要なタスクは多く見られると思う」
「まず開発・テストに必要な標準文書やテンプレートの作成と展開だが、以前のプロジェクトでも担当してもらったこともあり、今回はAさんに兼務という形でお願いしようと考えている」
「あと、特にテーブルや項目の変更などを管理するデータベース（DB）管理とデータ移行については、各チームの独断で勝手にやるとプロジェクト全体に迷惑をかけることになりかねないので、「DB管理／移行チーム」として切り出した。リーダーのCさんを中心にコミュニケーションをよく取って進めてほしい」
「じゃあ、みんなで力を合わせて頑張っていこう」
このケースでは、「組織計画」においてプロジェクト体制を編成する場面を取り上げている。上のケースで矢見雲マネージャと出来杉マネージャの違いは、ご覧のとおりDB管理／データ移行チームを個別に切り出している点と開発標準の作成・展開について言及している点である。ただし、ここでいいたいことは、DB管理やデータ移行は個別にチームを切り出しましょう、ということではない。
プロジェクト体制を編成するうえで重要なことは、「プロジェクト全体で調整しながら進める必要がある領域を識別する」こと。そして「その領域に必要な要員を割り当て、円滑に進むような仕組みを作っておく」ことである。
プロジェクト全体で調整しながら進める必要がある領域として、DB管理とデータ移行、および、開発／テスト標準の作成と展開を挙げたが、このような手当てをしておかないと各チームや個々のメンバーが他チームや他メンバーへの影響を顧みずに勝手なことを行う事態が発生する。
例えば、DB項目の定義を変更したところ、ほかのチームへの影響が考慮されていなかった、ということはよく聞く話であろう。このようなことから作業の手戻りが発生しプロジェクト全体が混乱に陥り、さらに悪化するとチームやメンバー間で対立に発展することへとつながる恐れがある。もっと深刻になると結果としてプロジェクトマネージャへの不満や不信感が増大してメンバーのモチベーションの低下を招いてしまいプロジェクトがまわらなくなることもあるのでプロジェクトマネージャとしては十分に留意したい。
1つ付記しておくと、プロジェクトの規模が大きくなればなるほどプロジェクト全体で調整しながら進めることは増大する。チーム間の調整を例に挙げると開発の中でも機能やサブシステムなどが何チームにも分かれていれば、ユーザーインターフェイスの共通化はどうする／マスターメンテナンスはどうする／共通機能や共通処理はどうする／コード体系はどうするなどの多くの問題が発生する。大規模プロジェクトで多くの時間を費やす要因の1つは、このような問題をプロジェクト全体として調整して整合を図ることではないだろうか。プロジェクトが大規模の場合は、特に留意してくれぐれも後手後手の対応にならないようにしたいものである。
Copyright © ITmedia, Inc. All Rights Reserved.