antena ap pm

ひろゆきさんには、お忙しい中わざわざ、いらしていただいたにもかかわらず、私が以下の点で至らなかったため、博之さんご本人に、そして、多くの視聴者の方々に不快感をもたらしてしまったことを、心から、お詫びします。

・ホスト役であるにもかかわらず、持論にこだわりすぎ、ひろゆきさんから話を上手に引き出せなかったこと
・議論の途中で、「こりゃだめだ」といったような、議論を投げ出すととらえられるような言動を行ったこと
・「夫婦げんか」のような、不適切な比喩を使ったこと

すべて、私の経験不足と能力不足に基づくことですので、真摯に反省をして、次回以降のデキビジその他の仕事で、今回の問題点を踏まえて、改善をしていきたい所存です。

通常のプロジェクトマネジメントでは通常、休日・病欠・庶務・休憩といったプロジェクトに直結しない活動はスケジュール計画からは除外され、プロジェクトに直結した時間のみが計測の対象となる。しかし、実際のプロジェクトではこれらの時間を明確に区分することは難しく、たとえば（ジョエル・スポルスキの例えを挙げると）「上司の釣りの話を聞かされる憂鬱な時間」をスケジュールから除外するのは望ましいことでもない。

こういった問題を避けるために、エビデンスベーススケジューリングでは、特定のタスクを完了するために実際に経過する時間のみを計測と見積もりの対象としている。そして、担当者の過去の見積もりを元にモンテカルロ法を適用して担当者の見積もりの信頼度を高めることを行っている。

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

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

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

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

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

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

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

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

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

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