Scott Berkun『アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法』

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

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


プロジェクトマネジメント…もう自分にとっては鬼門だよなあ。全然あいかわらずできてない…と落ち込んでいるわけですよ。どうやったら自律的にできるのだろう。自律的なチームを作りたい、と思っているけど、それが放任になってしまってうまくいかない、ということの多いことよ…。
検死するべき、というのが最後の方に書かれているけど、それがまったくだよね。「どうやって失敗したのか」を考えなきゃだめだよなあ。
以下、メモ。

p.3-4
プロジェクトマネジメントの過去事例によって得られた重要な3つの教訓:

  1. プロジェクトマネジメントとソフトウェア開発は神聖な芸術ではない。
  2. 作業をよりシンプルな視点から見ることで、よりパワフルに、より集中できるようになる。
  3. シンプルは簡単ということではない。

p.12-15
プロジェクトマネジメントにおけるバランス感覚:
エゴ/非エゴ、独裁/委譲、曖昧さの許容/完全性の追求、口頭/文書、複雑さの容認/簡潔さの支持、焦り/忍耐、勇気/恐れ、信者/懐疑論

p.17「
最初のうちはプロジェクトが順調に進んでいたため、上司は私が何をやっているのか気付いていませんでした。しかし、私がチームよりもチェックリストとプロセスに時間を割いていることを知った時、大きな赤旗(警告サイン)を振ったのです。ある日、彼は私の部屋に入り、室内のすべての壁に貼られた、滑稽なほど巨大なチェックリストと表を見た後、私を座らせてドアを閉めました。そして、「スコット君、こういったものも悪くないが、君のプロジェクトってーのは君のチームそのものなんだよ。チェックリストではなくチームをマネジメントするんだ。このチェックリストがチームのマネジメントに役立つのであれば、それは素晴らしいことだ。しかし、君のやり方ではすぐにチェックリストのマネジメントをするために君のチームを使うことになるだろう」と言ったのです。」

p.45-47
スケジュールを機能させるためにすべきこと:

  • マイルストーンの長さはプロジェクトの不安定さに見合ったものとする。
  • ビジョンに対しては楽観的に、スケジュールに対しては懐疑的に。
  • 設計に力を注ぐ。
  • 追加/削除を議論するためのチェックポイントを計画しておく。
  • 計画の哲学をチームに伝えておく。
  • 問題領域におけるチームの経験を見極める。
  • 共同作業に対するチームの自信と経験を測る。
  • リスクへの取り組みは早めに行う。

p.84-87
優れたビジョンに備わる5つの品質:

  • シンプル
  • 意図重視(目標駆動)
  • 統合
  • 閃き
  • 覚えやすい

p.114-116
創造的な問題解決のために行える質問は3種類:

  • 焦点合わせの質問:作業を遂行するうえで重要もしくは有益な、あるいは中核となる何かが欠如していることを相手に気づかせることができる。
  • 創造的な質問:今まで考慮の大将となっていなかったおのの、探求すべき方向を指摘する質問。
  • 修辞的な質問:不誠実な質問に分類されるものであり、文字通りの答えを期待することなく発せられる。子どもをしかるときの、「グレープフルーツを一箱食べちゃうなんて、何考えてるの!?」のように。

p.388
マイクロソフトでは「ウォーチーム」(war team)に、チームでのあらゆる意思決定のコントロール権限を与える。
期限が近づいてきた段階で、チームリーダーからなる少人数のグループが権力を一手に掌握することになる。

p.395
サマリー:

  • 大きな期限は、小さな期限の集合体でしかない。
  • どのようなマイルストーンにも3つの期限がある。設計の完了(仕様書の完成)、機能の完成(実装の終了)、マイルストーンへの到達(品質保証と洗練作業の完了)。
  • 期日に間に合わせることは、飛行機の着陸とよく似ている。どちらも長い、ゆっくりとした着陸進入が必要になる。そして、大掛かりな整備を必要とすることなく、すぐに再び離陸できる準備を整えられるような着陸を行う必要がある。
  • プロジェクトを追跡するためには、どの要素を測定するのかを決定しておく必要がある。一般的な要素としては、日々のビルド、バグ/欠陥のマネジメント、アクティビティチャートがある。
  • プロジェクトレベルの調整を行うため、コントロールにおける要素を洗い出しておく必要がある。一般的な要素としては、レビューミーティング、トリアージ、ウォーチームがある。
  • 終盤の大詰めはゆっくりとした退屈なプロセスとなる。ここでの難問は、リリースを満足のいくものに保ちつつ、変更のスコープを狭める。
  • 今こそ検死プロセスを開始すべき。うまくいったことと、うまくいかなかったことから教訓を得て、あなたとチームの糧にする。