アート・オブ・プロジェクトマネジメント(9)

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

9章 コミュニケーションと人間関係

コミュニケーションの重要性については，昔も今も変わりありません．しかし大きく違うのは，今やコミュニケーションの速度や量ではなく，質と有効性が問題となってきている点です．また，共同作業を行うメンバー間に，効率的かつ健全な人間関係が必要とされているということです．

だからといって，PMは，ゲーム番組の司会者のような外向性や卓越したユーモアのセンスが必要なわけではありません．

コミュニケーションと人間関係が重要であることと，あなた自身とチームにはさらなる向上の余地があるということを認識する必要があります．

コミュニケーションの基本モデル

コミュニケーションにおける最もシンプルなフレームワークは，5つの基本的な状態で構成されています．

1. 送信済み
2. 受信済み
3. 理解
4. 合意
5. 有益な行動への変換

コミュニケーション上のよくある7つの問題

コミュニケーションが破綻する理由はいくつもありますが，注意すべきは，チームにおいてこういった問題のある行動がとられるのは多くの場合，マネージャ自らそういった行動をとっているか，他のメンバーの行動を看過していることが原因となっているということです．

• 前提
• 明確さの欠如
• 聞く耳を持たない
• 指示
• 問題のずれ
• 個人攻撃/人格攻撃
• 嘲笑，冷やかし，非難

｢聞く耳を持たない｣について．誰かがあなたに話しかけている最中に，電子メールを読むなどして，視線を向けないといったことはありませんか？｢問題のずれ｣について．ひょっとしたら，相手は他の意思決定に関して何らかのわだかまりを抱いているのかもしれません．

プロジェクトマネジメントが大変なのは，こういったコミュニケーションの問題を理解できたとしても，どの振る舞いを改めるべきかという判断は極めて主観的なものとなり，すぐには改まらないこともあるからだとし，次の重要な示唆を述べています．

相手があなたとの人間関係にどれだけ投資しているかに関わらず，あなたはプロジェクトマネージャとして，すべての人間関係に投資しなければならないのです．

役割の定義

プロジェクトマネージャの実力は，チームメンバーとの人間関係で評価されるといっても過言ではありません．PMの頭の回転がどんなに速くても，また知識がどれだけあったとしても，PMとしての価値は人間関係を通じて，そういった特性をいかにうまくプロジェクトに適用するかにかかっているのです．
他のメンバーの価値をさまざまな方法で増幅することこそがPMの役割だと認識しなければならないということを意味しているのです．

で，それをいかにして行うのか？という疑問の答は，人間関係というものの理解に隠されていると述べています．そして人間関係を向上させる最も簡単な方法が，役割の定義，つまり暗黙の前提を明確化するということであると説明しています．

本書を読んでいて，確かに！と非常に同感を覚えた部分が以下です．

PM，リーダー，マネージャという役割は最も曖昧なものであり，他の人々から最も前提を置かれやすいものとなっています．
つまり，あなたが彼らと初めて会う際には，彼らが過去に接してきたPMのイメージすべてがあなたに投影されることになるわけです．

PMという立場であっても，メンバーという立場であっても，この指摘はいつも頭にいれておくべきだと痛感しました．

解決策は簡単です．共に働く人々(プログラマ，テスター，マーケティング担当者，クライアント，上司)を交えて，それぞれの役割を明確にすることです．本書では，次の3点を明確にしてくださいと書かれています．()内は例です．

• あなたが責任を持つべきこと (PMが行うこと)
• 双方が責任を持つべきこと (双方が行うこと)
• 他の人が責任を持つべきこと (プログラマが行うこと)

支援する

｢あなたがベストを尽くせるようにするには，私はどんな支援をしたらいいだろうか？｣

このシンプルかつ強力な質問の3つの効果が以下です．

1. あなたの話しかけている相手が，現在のプロジェクトでベストを尽くせるかどうかを見極めることができます．また，その障害となるものがあるかどうかも知ることができるはずです．
2. 作業担当者に対し，自らのパフォーマンスに対する評価と，自らがプロジェクトに対して貢献できることを洗い出すためのフレームワークを与えることになります．
3. 作業品質を改善する上で，双方ができることについての議論が可能になります．｢ベストを尽くす｣という観点から議論のフレームワークを定めることで，作業担当者に対して，非難されていると感じさせたり，自らの仕事が十分でないと感じさせたりすることを避けることができます．

メンバーにベストを尽くしてもらう8つの方法

1. (メンバーの)アドバイスに従う
2. 煽る/命令を下す
3. 意欲をかき立てる
4. 障害を排除する
5. 各自の役割を思い起こさせる
6. プロジェクトの目標を思い起こさせる
7. 教示する
8. 頼む

Scott Berkun は，過去に見てきた優秀とは言えないマネージャやリーダーは，メンバーにベストを尽くしてもらおうとして，特定のアプローチや手法に依存しすぎていたと書いています．

メンバー固有のトリガーを見つけ出し，そのスイッチをオンするということは，本当に難しいことだと身をもって実感しますね．でもあきらめずに，あの手この手と試行錯誤してその人のトリガーを探し出すことこそ，マネージャの使命なんだと思います．

参考文献

• 言葉のテロリズム http://www.vandruff.com/art_converse.html
• ｢エクセレント・リーダー - 超優良企業への情熱｣
• ｢The Satir Model: Family Therapy and Beyond｣
• ｢7つの習慣｣
• ｢リーダシップ・エンジン｣

アート・オブ・プロジェクトマネジメント(10)

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

10章 メンバーの邪魔をしない方法

人々が不快になる5つの理由

1. ~は私のことを無能だと思っている
2. ~は私を信頼していない
3. ~は私の時間を浪費させる
4. ~は私に対して敬意を払わずマネジメントを行う
5. ~は私に馬鹿げたことを聞かせたり，読ませたりする

これらは，人々が作業プロセスを毛嫌いする理由にもなっています．

プロセスは，ルール，ガイドライン，フォーム，手続き，制約といったさまざまな名前で呼ばれており，正しい目標を念頭に置いている限り，関係者全員に利益をもたらすものとなると説明しています．

優れたプロセス

プロセスの存在意義や解決すべき問題が検討されず，漫然とプロセスを実施しているだけで，そのメリットを享受できていないという場合が少なくないと指摘しています．

問題の原因

• 権限を持っている人が問題の原因 ： プロセスが馬鹿げていたにも関わらず，チームの努力によってプロジェクトが成功したという事実から目を背け，その馬鹿げたプロセスこそが成功の原因であるとする
• 以前使ってうまくいったから，今回も使う

しかし，たいていの場合は，プロセスというものが人の作業方法と人同士のやり取りを体系付けるもの，つまり非常に有機的なものであることが原因となっていると述べています．

優れたプロセスを生み出す秘訣は，以下の2つを組み合わせて考えることです．つまり，2つが交わる部分を見つけ出すことが優れたプロセスにつながるということです．

• 一般的にチームを効率化させること (一般的な性質)
• このチーム/プロジェクトをひと味違ったものにすること (このプロジェクト独特の性質)

優れたプロセスの持つ効果・属性

• 進捗を加速させることができる
• 問題を避けることができる
• 重要な作業の可視化，測定が可能となる
• プロセスの変更，除去を行うためのプロセスが提供される
• プロセスによって影響を受ける人がそのプロセスを支持するようになる

僕が重要だと思うのは，最後の項目です．なるべくメンバー自身がやる気を出すようなプロセスをつくるのがベストです．その秘訣は，プロセスの構想からメンバーを巻き込んでおくことです．さらに，メンバーにさまざまなアイデアを出してもらい，それをなるべく均等に採用したプロセスを作り上げていくことです．

下層から行うプロセスのマネジメント

あなたより強い権力を持った人たちが，納得できないプロセスを強要してきた場合の，対処法です．

1. そのプロセスからチームを守る
2. そのプロセスに対して反旗を翻す
3. そのプロセスを無視する

僕が使う順番は，まず3．無視します．意味のないプロセスについては，その後進捗など聞かれない場合が多いので大抵これで一件落着となります．もし聞かれた場合は，1．メンバーの手を煩わせないように，自分で適当に報告します．その報告で納得されない場合は，2．納得いくまで｢なぜ必要なのか？｣｢本当に必要なのか？｣ということに関して議論します．本当はこんなもっとも無駄な労力は使いたくないのですが…

参考文献

• ｢The Facilitator's Fieldbook｣
• ｢Mining Group Gold｣

アート・オブ・プロジェクトマネジメント(8)

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

8章 優れた意思決定の行い方

メタ意思決定のための7つの質問

すべての意思決定の実施に先立ち，どの意思決定に時間と労力を投資すべきかを考える，｢メタ意思決定｣のスキルはとても重要です．そのために，意思決定の重要度を評価するための質問を列挙しています．

1. この意思決定の中心にはどういった問題があるのか？
2. この意思決定がプロジェクトに影響を及ぼす期間はどのくらい続くことになるのか？また影響の大きさはどの程度になるのか？
3. この意識決定が間違っていた場合，どれだけの影響が出るのか，またどれだけのコストがかかるのか？その結果によって，他のどういった意思決定に影響が波及するのか？
4. この意思決定にどれだけの時間をかけることができるのか？
5. この種の意思決定を以前に行ったことがあるのか？
6. 誰が専門家の視点を持っているのか？これは本当に自分が行うべき意思決定なのか？
7. 誰の承認が必要なのか？意思決定を行う前に誰のフィードバックが必要となるのか？

僕が最も重要だと思うのは，1番目です．緊急度という側面のみにとらわれず，しっかりと重要度を判断し，問題の本質を見極めるということです．そのための質問を引用しておきます．

• • この問題の原因は何か？
  • これは独立した問題なのか？それとも他の領域に影響をあたえる問題なのか？
  • この問題によって影響を受けないのはビジョンにおけるどの目標か？
  • この意思決定は仕様書やビジョンのドキュメントですでに行われたものなのか？
  • もしそうであれば，それを今また再考する適切な理由はあるのか？

重要でないことを重要視してはいけない

『決断の法則』のおける，意思決定に用いる2つの基本手法を引用し，説明しています．

• 単独評価 ： 最初に見つかった妥当な選択肢を受け入れる
• 比較評価 ： 意思決定に先立ち，複数の選択肢を評価する

すばらしい解決策とそこそこの解決策の違いがあまり重要でない場合は単独評価が有効であり，その状況が「無差別の領域｣にあると表現しています．そして無差別の領域を早期に察知し時間を節約することで，より時間をかけるべき意思決定に注力できると述べています．

メリット・デメリット表の8つの注意点

比較評価で用いられる，｢長所と短所の一覧表(メリット・デメリット表)｣を効率的に利用するための注意点を8つあげています．

1. ｢何もしない｣という選択肢を必ず含めておく
2. あなたは，判っているということを，どのようにして判っているのか？
3. 厳しい疑問を投げかける
4. 反対意見に耳を傾ける
5. 選択肢の組み合わせを考慮する
6. 関連する観点をすべて含める
7. 紙やホワイトボードに書き始める
8. 安定するまで洗練する

｢何もしない｣という選択肢は忘れがちですが重要ですね．僕の経験から，”よくみかける悪い例”として次の2つをよく見かけます．

• 各項目の粒度が揃っていない．(包含関係を無視して項目が列挙されている)
• 項目が抜けている．(背反する事象がない)

決定する勇気

正しい選択を知ることと正しい選択を実行することには大きな違いがあります．

と述べたうえで，次のことは常に念頭に置いておいてくださいとアドバイスしています．

意思決定というものは勇気の要る作業です．というのも，プロジェクトにとっての最善の意思決定は，メンバーの不評を買うことも多く，チームの中核メンバーを動揺，あるいは失望させ，ものごとが悪い方向へと進んだ際にはあなたが針のむしろに座ることになるためです．
こういった重荷は，リーダーシップを発揮しようとするすべての人が負うものです．意思決定はリーダーやマネージャが行う作業の中核を占めるため，優れたリーダーになろうとするのであれば，勇気を持って意思決定を行う必要があるのです．

また，Scott Berkun は，自らの経験から，｢勝利をもたらす選択肢のない意思決定もある｣，さらに｢優れた意思決定でも悪い結果をもたらすことがある｣とも述べています．非常に参考になります．

意思決定のレビュー

意思決定のスキルを向上させるには，2つのことを実践する必要があります．

• あなたにとって難しく，一所懸命に取り組まなければならない意思決定を経験する
• あたなの意思決定の結果に注意を払い，その評価を行う

その評価(レビュー)で使用することができる質問集が以下です．

• その意思決定は核となる問題を解決したか？
• その意思決定をより迅速化できるような，より優れたロジックや情報はあったのか？
• ビジョンのドキュメント，仕様書，要求定義書はその意思決定に役立ったのか？
• この意思決定はプロジェクトの進捗に役立ったのか？
• 鍵となる人々をプロセスに参画させ，意思決定の支援をさせることができたか？
• この意思決定が他の問題を引き起こす/防止するということはあったのか？
• 振り返ってみた場合，この意思決定の最中に気にしていたことは正しいことだったのか？
• 正しい決定を行うだけの十分な権限があったのか？
• この意思決定によって学んだことをプロジェクトの他の部分にどのように適用できるのか？

参考文献

• ｢Serious Games｣
• ｢10日で学ぶMBA｣
• ｢決断の法則 - 人はどのようにして意思決定するのか？｣
• ｢統計でウソをつく法｣