antena ap pm

僕はまだアジャイルソフトウェア開発の世界にはわりと新参ではあるものの、そこで形作られつつある慣習のいくつかは、政府の政策展開のみならず、様々な他分野に適用できるのではないかと考えている。

４）提案書、仕様書、提案依頼書はなし：タスクの把握にはPivotal Trackerのようなトラッキングシステムを使う。巨大なプロジェクトシートや、開始前に全てを決定しようとするのは避ける。各小規模グループがその領分内でコンテキストを共有すること、そして個々の小パートが正しく動作し、周囲の要素に悪影響を及ぼさないことのほうが重要である。

３）小規模で実施：チームの人数を増やしすぎず、大きな問題は小さな問題に分割する。小さな問題はごく少人数のグループでもこなせるような「階層」もしくは短期間のタスクに分割する。

デマルコは、生産現場のブルーカラー労働者を対象に開発された管理手法は、今日の知識労働には当てはまらないと指摘する。「人間は時間的なプレッシャーをいくらかけられても、速くは考えられない」というリスターの法則を引用し、管理者がプレッシャーをかけることの無意味さを指摘したり、強気のスケジュールや時間外労働が結果的に失敗に終わる理由を述べたりする

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

表1を見て分かるように、PMBOKのコミュニケーション計画には「ステークホルダー分析」が含まれています。ステークホルダーとは”利害関係者”のことです。組織管理で洗い出したプロジェクト体制図に登場するメンバー相互の関係を分析します。ただし、PMBOKのコミュニケーション管理は、ステークホルダーの企業としての立場をあまり考慮していません。プロジェクト参加者を全てメンバーとして考え、単純にメンバー相互のコミュニケーションを対象としているようです。

常駐・派遣型のプロジェクトはこれでもかまわないでしょう。ユーザーと開発メンバー、協力会社が同一の場所に集まってプロジェクトを遂行し、人月ベースで対価を支払う方法なら立場の違いはあまり気にしなくても良いと思います。しかし、請負ベースの開発プロジェクトの場合は、”企業間”の立場を考慮した方がしっくりいきます。

プロジェクトの失敗要因を考えた場合、ユーザーと自社開発メンバーと協力会社それぞれの間でコミュニケーション不足の内容が異なります。また、失敗を防ぐ為の管理ドキュメントテンプレートも、立場の違いにより異なります。そこで弊社のプロジェクト管理手法PYRAMIDでは、図1のようなステークホルダーの立場に分けてコミュニケーション計画を考えるようにしています。

コミュニケーション計画プロセスでは、プロジェクトを遂行するためのコミュニケーションルールを策定します。コミュニケーション計画の例を表2に示します。ここでは3つのステークホルダーの立場に分けてコミュニケーション計画を立てています。計画には、項目別に「誰から誰へ」「いつ」「どういう頻度で」「どういう情報を」「どういう手段で」というような取り決めを盛り込みます。

例えばユーザーとのコミュニケーションの場合は、打合せ議事録はどちらが書くか、質問&回答のやり取りはどうするか、仕様変更の伝達方法はどうするか、仕様書のレビュー方法はどうするか、などの取り決めがこれに当たります。

コース概要
J-SOX法の施行により、プロジェクト・マネジメント計画書相当のドキュメントを要求されるプロジェクトが増えています。また、PMBOK®をもとに計画書を作成したいが、テンプレートは存在していませんかというお問い合わせも頂いています。
このコースでは、PMBOK®に記述されている各種マネジメント計画書を１種づつ作成し、更に統合することで漏れのない整合性のとれたプロジェクトマネジメント計画書作成を目指します。