« 「プロジェクトはなぜ失敗するのか」(伊藤健太郎) | トップページ | 第11章:プロジェクトリスクマネジメント(その1) »

第10章:プロジェクトコミュニケーションマネジメント(その2)

ここでは、プロジェクトコミュニケーションマネジメントをまとめます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

keywords
 ・コミュニケーションの方法
 ・コミュニケーションをコントロールする
 ・コミュニケーションの阻害要因
 ・ミーティング、打ち合わせ、会議
 ・コミュニケーションチャネル
 ・実績報告
 ・完了手続き

コミュニケーションの方法(p.121)
試験に出るが経験で答えても大丈夫。不安なら以下のリストを押さえておく。ワタシの場合、"e-mail"だけ違っていた(w

コミュニケーションの側面


  • 書面、口頭、聞くことと話すこと
  • プロジェクト内部と外部(顧客、マスメディア)
  • 公式(報告書、レビュー)と非公式(メモ、コーヒーブレイクミーティング)
  • 縦方向(組織の上下でする)と横方向(同僚と)

コミュニケーションの方法


  • 公式/書面 : 複雑な問題やプロジェクト計画を表現するときに使う。時間・距離的な隔たりを超えて伝えるときに使う
  • 公式/口頭 : プレゼンテーション、スピーチ
  • 非公式/書面 : メモ、e-mail、ノート
  • 非公式/口頭 : ミーティング、会話

仕事相手が異なる言語・文化背景を持つ場合がある。誤解が生じないように「口頭よりは書面で」「非公式よりは公式に」するべき

コミュニケーションをコントロールする
試験に出てくるネタとしては…


  • プロジェクトマネージャは全てのコミュニケーションをコントロールできるか? → あたりまえだが、不可能
  • プロジェクトマネージャはコミュニケーションをコントロールするべきか? → Yes、全てをコントロールすることは不可能だが、やるべきである。でないと、誤解やミスディレクション、拡大解釈が生じることになる
  • プロジェクトマネージャがコミュニケーションに使う時間は何パーセントか? → しつこく書いてきたのは、試験に出るから。プロジェクトマネージャはおよそ90%の時間をコミュニケーションに費やす

コミュニケーションの阻害要因
いわゆる「バカの壁」というやつですな。「使えないアイディアだ」といった、会話が萎えるセリフは多々ある。それでも話を続けなきゃ、給料もろてる限り。代表的な萎え台詞は以下の通り


  • 「… … で、何が言いたいワケ?」
  • ぶっちゃけありえない
  • 「問題ありません」

試験には「コミュニケーションの阻害要因を挙げよ」という形式で出る。代表的な阻害要因は以下の通り

  • ノイズ(物理的な意味でも心理的な意味でも)
  • 距離(物理的な意味でも心理的な意味でも)
  • 不適切なエンコード(複雑な問題を電話で伝える等)
  • 「ぶっちゃけありえない」と言うこと
  • 敵意
  • 言語
  • 文化

ミーティング、打ち合わせ、会議
いきなり脱線。会議は取捨選択して出る。しょうもないのは出ない(睡眠をとるために出る会議は除く)。「出ない」と明言し、優先順の高い理由をつけて出ない。徹底的に出ない。これを続けると、しようもない会議に貴重な時間をとられることが無くなる。お試しあれ、ただし鋼の決意と非難轟々をやり過ごす鉄面皮が必要…

体力知力時間を浪費するだけで何も決定しない無意味な会議を有意味にするために、何をすればよいのか? を考えることがポイント…っつっても皆知ってるよなぁ(Ritaもそう言ってる)


  • 開始時間、終了時間を決め、それを守る
  • 会議の目的を明らかにする
  • 予め議事進行をスケジュールし、アジェンダを配っておく
  • アジェンダに従って進める。そこからぶれない
  • 参加者のそれぞれの「会議での役割」を確認する
  • その会議に必要な人に参加してもらう。評論厨房はご退出願うのではなく、最初から参加させない
  • 議事録を記録し、配布する

コミュニケーションチャネル
チームに3人いたら、自分以外の2人とコミュニケーションをする。2ちゃんねるだ。他のメンバーも同様。この場合、いくつのチャンネルがあるか? 答えは3チャンネル

公式だと次の通り
n人のチャンネル数は→→n(n-1)/2

当然、メンバーの数が増えるほどチャンネル数は増える。プロジェクトマネージャはコミュニケーションのコントロールに努めなければならない…コントロールなんて不可能なのだが、それでも努力は必要ナリ

練習問題
4人チームに1人追加したら、コミュニケーションチャネルはいくつ増えるか?

  a. 1
  b. 4
  c. 6
  d. 10

答えはb. 「いくつ増えるか?」という問いなので、5人のコミュニケーションチャネルではないことに注意

実績報告(p.122)
「報告」そのものがコミュニケーションツールといえる。ステークホルダー間でこの情報は共有されなければならない←言い換えると共有できるレベルまで噛み砕かれていなければならない。実績報告には以下の情報が含まれている


  • 状況報告 : プロジェクトの現況報告。ネットワークダイアグラムのココ!とか、マイルストーン○○のアウトプット作成中といった報告
  • 進捗報告 : プロジェクトがどこまで進んでいるかを報告。このとき実績/計画の差異も説明する。ガントチャート(バーチャート)の棒を塗りつぶすと進捗度合いがよくわかる。ドキュメント作成なら [20枚/150枚] (実績/計画)といった数で示すと分かりやすい
  • 傾向分析 : 実績が改善しているか悪化しているかを判断するため、プロジェクトの結果を時系列に分析した報告。バグ収束率と試験チェックリスト消化率を折れ線で示すグラフが一般的
  • プロジェクトの見通し : 現状、傾向から今後のプロジェクトが改善していくのか悪化していくのかを報告
  • アーンドバリュー : プロジェクトの実績についてスコープ、コスト、スケジュールの観点を統合して予実差異を示す。「時はカネなり」という言葉がひしひしと伝わる

完了手続き(p.125)
プロジェクト計画書で計画されたものを終わらせること。プロジェクト成果物が最終的に受け入れられるものであることを検証し、プロジェクトを終わらせる全ての事務手続きを行う

  • プロジェクトの終了時
  • プロジェクトの仕事や契約業務が終結する前に、その期限が満了した時。タイムオーバーというやつね
  • プロジェクトのそれぞれのフェーズ終結時に(設計フェーズ、開発フェーズ、実装フェーズなど)

どんなプロジェクトであれ、終わるときにはプロジェクト完了手続きが必要。そう、首尾よく目標を達成した場合だろうと、デスマの最中にトドメを刺された場合であろうと。

問題は契約がからむ場合。対顧客とであれ、対発注先であれ、対調達先であれ、契約の完了手続きを行ってから、プロジェクトの完了手続きを行う←テストに出る。どんな風に出るかというと、プロジェクト完了手続きにはどのような作業があるか? という問い。これを知らないと「契約完了の手続き」を選択してしまってミスになる。プロジェクト完了の手続きの作業には、「契約完了」の手続きは存在しないことに注意

プロジェクト完了手続きは、以下の作業を行う


  • 成果物の確認 : すべての成果物が計画どおりにできたかをチェックする。要求したとおりで、かつステークホルダーを満足させる成果物ができているかを確認する
  • 会計上の完了手続き : 最終的な支払を行い、かかった費用全てを記録する
  • 教訓(lessons learned) : うまくいったこと/いかなかったことを分析する。そしてもう一度同じプロジェクトを行うと仮定して、何を行うべきなのかを記録する(二度と着手しない、という結論に達するかもしれないがw)。顕在化したリスクへの是正措置は教訓として使える。PMBOKにおいて「教訓」は、コントロールプロセスのアウトプットと、プロジェクト終結フェーズでのアウトプットのどちらにも出てくる
  • 情報を更新する : プロジェクトそのものの履歴情報を更新する。さらにメンバーのスキル履歴と経歴も更新されるはず→人事管理情報として
  • 最終実績報告 : プロジェクトが最終的に成功したのかどうか、プロジェクトが果たした成果を最終的に記録する
  • アーカイブ : プロジェクトに関連する全ての情報(ファイル、設計書、ドキュメントetc)をアーカイブする。次のプロジェクトのために

プロジェクト完了手続きの結果、次のアウトプットがある


  • プロジェクトアーカイブ : ガイシュツ
  • 教訓 : ガイシュツ
  • プロジェクト完了の公式な受け入れ : 顧客、スポンサー、あるいは他のステークホルダーに対し、プロジェクト成果物を公式に受領したしるし→オフィシャルにサインをもらう。たとえどんな「成果物」であったとしても。…たとえどんなに冷たく別れても~おまえはオレには最後のオンナ~…この「公式な受け入れ」が無い場合は、プロジェクトが完了したことにならない。そういう意味では、失敗したプロジェクトというよりも、完了してないプロジェクトがいかに多いことか
  • リソースを解放する : 全ての人的資源を解放する。チームを解散し、それぞれの機能部門へ戻す。あるいは適切な部門へ配置換えをする

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PMP試験対策の目次に戻る
--

|

« 「プロジェクトはなぜ失敗するのか」(伊藤健太郎) | トップページ | 第11章:プロジェクトリスクマネジメント(その1) »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 第10章:プロジェクトコミュニケーションマネジメント(その2):

« 「プロジェクトはなぜ失敗するのか」(伊藤健太郎) | トップページ | 第11章:プロジェクトリスクマネジメント(その1) »