TOP＞プロジェクト管理＞ プロジェクト失敗の要因

「即活用！企業システムにおけるプロジェクト管理」 第７回：コミュニケーション管理 著者：システムインテグレータ  梅田 弘之   2005/1/25

1   2  3  4  次のページ

プロジェクト失敗の要因

プロジェクトがうまくいかなかった場合にその失敗要因を聞くと、「コミュニケーション不足でした」という回答が返ってくることが多くあります。この場合のコミュニケーションは、主に「ユーザーと開発メンバー間のコミュニケーション」、「開発メンバー同士のコミュニケーション」、「自社メンバーと協力会社の間のコミュニケーション」に分類されます。    もう少し細かく整理すると、図1のように経営者とのコミュニケーション、PMO（プロジェクト管理専門組織）とのコミュニケーション、ラインマネージャ（自部門／他部門）とのコミュニケーションなどもあります。今回は、プロジェクト失敗の要因として掲げられる"コミュニケーション不足"を回避するための、コミュニケーション管理について考えてみましょう。

図1：プロジェクト管理におけるコミュニケーション

PMBOKのコミュニケーション管理

PMBOKにおけるコミュニケーション管理は、表1のように「コミュニケーション計画」、「情報の配布」、「進捗管理」、「プロジェクト完了手続き」、という4つのプロセスから構成されています。計画プロセスでコミュニケーション管理計画を立て、実行プロセスで情報の配付などのコミュニケーションを実施、管理プロセスで進捗管理や変更管理を行い、終結プロセスでプロジェクトの完了報告を行うという一連の作業内容が定義されています。

管理 エリア プロセス 入力 ツールと 実践技法 出力 Communi cation (コミュニケーション管理) コミュニケーション計画 （計画） コミュニケーションの要求事項 コミュニケーション技術 制約条件 仮定条件 ステークホルダー分析 コミュニケーション管理計画 情報の配付 （実行） 作業結果 コミュニケーション管理計画 プロジェクト計画書 コミュニケーションスキル 情報検索システム 情報配付システム プロジェクト記録 プロジェクト報告書 プレゼンテーション 進捗管理 （管理） プロジェクト遂行要員プロジェクト計画書 配員計画書 進捗報告書 外部関係者のアドバイス 進捗の検討会議 差異分析 傾向分析 アーンドバリュー分析 情報配付のためのツール 進捗報告書 変更要求書 プロジェクト完了手続 （終結） 進捗測定書類 プロジェクト成果物 その他のプロジェクト記録 進捗報告のツールと技法 プロジェクト報告書 プレゼンテーション プロジェクト完成記録 プロジェクト完了 教訓

表1：PMBOKのCommunication Managementの4つのプロセス

コミュニケーション計画プロセス

表1を見て分かるように、PMBOKのコミュニケーション計画には「ステークホルダー分析」が含まれています。ステークホルダーとは"利害関係者"のことです。組織管理で洗い出したプロジェクト体制図に登場するメンバー相互の関係を分析します。ただし、PMBOKのコミュニケーション管理は、ステークホルダーの企業としての立場をあまり考慮していません。プロジェクト参加者を全てメンバーとして考え、単純にメンバー相互のコミュニケーションを対象としているようです。    常駐・派遣型のプロジェクトはこれでもかまわないでしょう。ユーザーと開発メンバー、協力会社が同一の場所に集まってプロジェクトを遂行し、人月ベースで対価を支払う方法なら立場の違いはあまり気にしなくても良いと思います。しかし、請負ベースの開発プロジェクトの場合は、"企業間"の立場を考慮した方がしっくりいきます。    プロジェクトの失敗要因を考えた場合、ユーザーと自社開発メンバーと協力会社それぞれの間でコミュニケーション不足の内容が異なります。また、失敗を防ぐ為の管理ドキュメントテンプレートも、立場の違いにより異なります。そこで弊社のプロジェクト管理手法PYRAMIDでは、図1のようなステークホルダーの立場に分けてコミュニケーション計画を考えるようにしています。    コミュニケーション計画プロセスでは、プロジェクトを遂行するためのコミュニケーションルールを策定します。コミュニケーション計画の例を表2に示します。ここでは3つのステークホルダーの立場に分けてコミュニケーション計画を立てています。計画には、項目別に「誰から誰へ」「いつ」「どういう頻度で」「どういう情報を」「どういう手段で」というような取り決めを盛り込みます。    例えばユーザーとのコミュニケーションの場合は、打合せ議事録はどちらが書くか、質問&回答のやり取りはどうするか、仕様変更の伝達方法はどうするか、仕様書のレビュー方法はどうするか、などの取り決めがこれに当たります。

項目 ユーザーとの間 自社メンバー間 協力会社との間 打合議事録 自社で作成 打合せ後2日以内提出 提出後4日以内に確認印押下の上1部返却 打合せ後2日以内提出 PL、PMの確認印押下の上ファイリング 協力会社で作成 打合せ後2日以内提出 提出後4日以内に確認印押下の上1部返却 質問＆回答 質問管理票に記入 質問管理票に記入 質問管理票に記入 進捗報告 毎週月曜日にメール 毎月1日に進捗会議 毎朝10時に進捗会議 毎週金曜日に進捗会議 仕様変更 仕様変更依頼書に記入 仕様変更依頼書に記入 仕様変更依頼書に記入 ソース変更   VSSでバージョン管理 変更連絡書を回覧 変更連絡書を提出 レビュー報告書 自社で作成 レビュー後2日以内提出 提出後4日以内に確認印押下の上1部返却 レビュー後2日以内提出 PL、PMの確認印押下の上ファイリング 協力会社で作成 レビュー後2日以内提出 提出後4日以内に確認印押下の上1部返却

表2：3つの立場に分けたコミュニケーション計画の例

ドキュメントベースのためのルールとテンプレート

コミュニケーション管理のポイントは、「ドキュメントに残す」ことです。言った言わないのトラブルにならないように、必ずドキュメントに残すことにしましょう。そんなこと当たり前だと思うでしょうが、では、きちんと実践できているか振り返ってみてください。ついついプロジェクトが忙しくなると、ドキュメント作成の時間も惜しんで口頭ベースでになりがちだと思います。    そのために、きちんとプロジェクト計画プロセスで"ルール"として定め、さらに"ドキュメントテンプレート"を用意しておくのです。

1   2  3  4  次のページ

著者プロフィール 株式会社システムインテグレータ  梅田 弘之 東芝、住商情報システムを経て1995年にシステムインテグレータ社を設立。 常駐・派遣主体の労働集約的な日本のソフトウェア業の中で、創造性にこだわってパッケージビジネスを行っている。 国際競争力のない日本のIT産業が、ここから巻き返しを図るための切り札は「プロジェクト管理」だと信じ、実践的なプロジェクト管理手法「PYRAMID」を自社開発している。

INDEX 第7回：コミュニケーション管理 プロジェクト失敗の要因   管理ツール利用を積極的に推奨   質問管理   プロジェクト完了手続きプロセス

「即活用！企業システムにおけるプロジェクト管理」 第1回 プロジェクト管理力を強化するための具体的プラン 第2回 PMBOKをベースにしたプロジェクト管理の管理 第3回 スコープ管理とスケジュール管理 第4回 コスト管理の構造と見積手法 第5回 品質管理 第6回 組織管理 第7回 コミュニケーション管理 第8回 リスク管理 第9回 調達管理（外注管理）

関連記事 ： 即活用！業務システムの開発ドキュメント標準化 第1回 開発ドキュメント体系と業務フロー 第2回 機能一覧表とI/O関連図 第3回 基本設計書 第4回 詳細設計書（前半） 第5回 詳細設計書（後半） 第6回 単体テスト仕様書＆報告書 第7回 結合テストと総合テスト 第8回 要求仕様書の標準化プロセス

関連記事 ： 即活用！ツールを活用したデータモデリング 第1回 ソフトウェア産業に産業革命を起こすデータモデリング 第2回 ERの基礎知識とツールの活用法 第3回 日本語名の是非とデータ型採用方針 第4回 制約の使い方、Unicode使用可否、明細テーブルの設計 第5回 教科書的ではなく、現場にあったデータベース設計のコツ