« 2006年10月22日 - 2006年10月28日 | トップページ | 2006年11月5日 - 2006年11月11日 »

「アート・オブ・プロジェクトマネジメント」読書感想文【まとめ】

アート・オブ・プロジェクトマネジメント ITプロジェクトのマネジメントにおいて、本書はまさに宝の山といえる。

 一回の探索では持ちきれないほどのアイディアがザクザクと手に入る。しかも、ひとつひとつの宝が、著者の経験に裏打ちされ、考え抜かれているため、一回読みでは消化不良を起こす。それぞれのフェーズで読み返すことで、順番にモノにしていくやり方が良いかと。

 このエントリでは、自分の振り返り読みのために、読書感想文エントリの目次と、次に読むべき本・サイトのをまとめた。わたしだけでなく、誰かの参考にもなればイイナ!

その1

  ・オーバービュー


その2
 1章「プロジェクトマネジメントの簡単な歴史」からの考察

  ・PMにとっての最重要ツール
  ・アート ―― 技芸と呼ぶ理由
  ・ホワイトボード地獄


その3
 2章「スケジュールの真実」および、
 3章「やるべきことを洗い出す」からの考察

  ・何のための開発プロセスか?
  ・見積もり確度を上げる2つの質問
  ・スケジュールを機能させるためにするべき8つのこと


その4
 4章「優れたビジョンを記述する」からの考察

  ・シンプルにすると、本質が見える
  ・正しい疑問を持つ
  ・なぜビジョンが重要なのか


その5
 5章「アイディアの源」および、
 6章「アイディアを得た後にすること」からの考察

  ・優れたPMは質問の達人
  ・「見える」懸案一覧は強力なツール


その6
 7章「優れた仕様書の記述」からの考察

  ・仕様書など書く必要がないと信じているプログラマ
  ・何をもって「正しい」とするのか(わたしの場合)
  ・仕様書について犯す最大の過ち


その7
 8章「優れた意思決定の行い方」からの考察

  ・意思決定の重要度を決める
  ・意思決定をふり返る(死者とドーナッツ:Death and Doughnuts)
  ・メリット・デメリット表に、ひと工夫


その8
 9章「コミュニケーションと人間関係」および、
 10章「メンバーの邪魔をしない方法」からの考察

  ・歩き回るマネジメント
  ・コミュニケーションにおける銀の弾丸
  ・目からウロコ!→「優れた電子メールを誉める」


その9
 11章「問題発生時に行うこと」からの考察

  ・問題発生時に行うべき8つの手順
  ・「責任を取る」とは何か?
  ・パフォーマンスとプレッシャー


その10
 13章「ものごとを成し遂げる方法」からの考察

  ・ものごとを成し遂げる方法1 ―― どのように、成し遂げるのか?
  ・ものごとを成し遂げる方法2 ―― いつ、成し遂げられるのか?


 なお、以下の章は、消化(昇華?)できるまでマネジメントの経験値が足りない。実践を通じて確かめてみよう。

 12章「リーダーシップが信頼に基づく理由」
 14章「中盤の戦略」
 15章「終盤の戦略」
 16章「社内の力関係と政治」

 以下、本書を通じて知った読むべき本およびサイトを挙げる。冒頭のカッコ()内は本書で初出の頁数。あくまでも「わたし」にとって読むべき本・サイトなので、ご注意を…

  • (p.12)トム・ピーターズの「完璧なプロジェクトマネージャの追求」(英語)[URL]:マネジメントにおいて、どのバランス感覚が重要となりうるかを考察している
  • (p.74)ワインバーグ「要求仕様の探検学」[amazon]:設計に先立つ品質の作りこみ。要求仕様の洗い出しと文書化を行う手法を身につけることができる
  • (p.107)著者のブログより、「批判の言い方、言われ方」(英語)[URL]:批判の「言われ方」の方が重要。感情に支配されず自分をオープンにすることが建設的な議論になるための鍵だという
  • (p.139)「アイディアのまとめ方」(英語)[URL]:洗い出されたアイディアの可能性を検証し、有効性によって分類し、方向付けを行うためのテクニック
  • (p.145)著者のブログより、「UIプロトタイピングの技芸」(英語)[URL]:プロトタイプにおける魔法の呪文なぞ、存在しない。それでも、UIプロトタイピングにおいて、ちょっとした経験・コツが確かにある。経験を得るまでの時間短縮のために
  • (p.215)「対話テロリズム」(英語)[URL]:対話において卑劣な発言が実例とともに分類されている、コミュニケーションにおけるアンチパターン。ここにある行動・発言は絶対に避けるようにしたい。
  • (p.264)「アンチパターンカタログ」(英語)[URL]:マネジメントや開発におけるアンチパターンがwikiでカタログ化されている
  • アポロ13(p.268)「ハーバード流交渉術」[amazon]と、「無理せずに勝てる交渉術」[amazon]の両方必読。交渉テクニックは否が応でも自己流から脱却しないと、いつまでたってもトライ&エラー&後悔の連続だろうから
  • (p.326)「アポロ13」[amazon]:どうしようもない状況、限られた時間、非常に高いリスク、疑わしい解決策にさらされたとき、優れたプロジェクトマネージャは何を考え、どう行動するかを知ることができる「好例」だそうな、読むべ
  • (p.422)「権力に翻弄されないための48の法則」[amazon]、「人を動かす」[amazon]、「影響力の武器」[amazon]:後2冊は再読だけれど、も一度読む。仕事本として、こんなん読もうとするのは、パワーを意識するお年頃なのかもしれないな

| | コメント (4) | トラックバック (4)

「アート・オブ・プロジェクトマネジメント」読書感想文(その10)

アート・オブ・プロジェクトマネジメント PMのミッションは、プロジェクトを完遂させることだ←アタリマエなことなのだが、そのために何をしなければならないか、という話題になると多様な方法論に割れる。ここでは、本書から学んだものごとを成し遂げるための2つの方法を考察する。

■ものごとを成し遂げる方法1 ―― どのように、成し遂げるのか?

 優先順位付けによってものごとが成し遂げられる

 プロジェクトマネジメントで最も忌避すべきことは、誤った作業にリソースを費やすこと。プロジェクトの目標や、作業の優先順位が混乱すると、進捗に遅れが生じ、最重要なリソース、すなわち時間が無駄に費やされることになる。いま、何をしなければいけないか、「その作業の重要度」について全員が同じ認識をもっていないと成功はおぼつかない。

 では、この「重要度」は何によって決定されるのか? その作業に「重要」とラベルを貼っただけでは何の意味も無い。怒り狂った顧客のキメ台詞「全てが最優先!」がいかに愚かしいか知っているならば、説明するまでもないだろう。

 なぜ「重要」なのか、という疑問に答えるとき、「この問題の解決の方が、○○の解決よりも重要」という言い方になる。つまり、重要度は相対的なものになる。だから、「何のもまして重要」なものは1つしかないし、「最重要課題」の数も1。

 この重要度を見極めて優先順位づけすることが、PMの仕事の本質といってもいい。PMの重要な仕事と言われている「コミュニケーション」は、このリストを作成するためにある。何を優先させ、何を優先させないかを決めるのだ。

 ほとんどのプロジェクトにとって、次の3つの順序付き一覧表こそが重要だろう。それぞれ順にブレークダウンされているはずだ。この他に、バグ一覧、要求一覧はあれど、以下のどれかに落とされて始めて、プロジェクトが回ることになる。この一覧表を優先順位づけることで、ものごとは成し遂げられる。

  • 目標の一覧表
  • 機能の一覧表
  • 作業項目の一覧表

 優先順位のおかげで、作業すべき項目や議論の焦点から副次的なパラメータが取り除かれる。どんなに議論が紛糾したとしても、収束させるために集中するべき焦点を絞りこむことが可能となる。煮詰まった議論をリフレッシュするために効果的な質問があるので引用する。

  • 私たちが解決しようとしている問題は何か?
  • 複数の問題がある場合、どれが最も重要なのか?
  • この問題は私たちの目標とどう関係しており、どのように影響するのか?
  • 目標に見合うようにこの問題を解決する最もシンプルな方法は何か?

 PMは優先順位付けマシンとなるべし、と著者は断言する。プログラマやテスタと対話し、彼らが抱える懸案について耳を傾け、副次的な要素を取り除き、彼らが作業しなければならないことに集中させよという。メンバーが自分の重要な作業に集中させることこそが、PMの存在価値なのだから、そのために優先順位付けマシンとなるべし、というわけ。

■ものごとを成し遂げる方法2 ―― いつ、成し遂げられるのか?

 あなたが「ノー」と言う時に、ものごとが成し遂げられる

 わたしにとって、ここからは未踏領域。わたしが「ノー」と言うたびに、「ノーという理由を教えろ」というツッコミが入り、あとはナゼナゼ論法で論破される… んで、「イエス」と言ったほうが話が早いので、その場は「イエス」で言いぬけて、あとは体力気力魚心水心でやってきた(イエスの奴隷やね)。

 しかし、著者によると、「あなたが「ノー」と言わなければ、優先順位は決定できないのです。(中略)あなたが「ノー」と言えなければプロジェクトをマネジメントすることはできないのです」。するべきことと、やった方がよいことを分け、どのリスクをテイクする(負う)のか決めて、誰がそれを引き受けるのかを判断(指示)する。全て「ノー」というべき瞬間が待っている。何かを優先してする、ということは、それ以外のものをやらないでおくことと等しい。本書には、「ノー」の言い方まで紹介されている。

  1. 「ノー、それは我々の優先順位に合致していません」
  2. 「ノー、時間ができた場合にのみ行います」
  3. 「ノー、あなたが<不可能なことをここに入れてください>を行ってください」
  4. 「ノー、次のリリースで考えます」
  5. 「ノー、絶対ダメです」

 1と2は使うことがあるが、それは優先順位表ができたからこそいえる「ノー」。3つ目の「ノー」は、厳しいツッコミ(というか罵詈雑言)を浴びせられ、「もういいです、わたしがやります」に変わること多し。最後の理由無し「ノー」は言えない…

 本書のかなりの部分までは、自分の経験に照らし合わせて強くうなづくことができる。「気づき」よりも「確かめ」に近い。しかし、マネジメントの部(12~16章)になると、、これから場数を踏むことになる(?)状況が混ざっている。本書の後半はくり返しひも解くことになるだろう。

 「読書感想文」シリーズはここまで。本書から得た「宝」を自分の経験と照らし合わせ、まとまりのないまま書いた。本書が単なるTips 集でないことは、あらためて言うことでもないだろう。ノウハウ集でもないはずだ。システム開発の現場で考え抜かれた「宝」が沢山埋まっている。だから、もっと志の高い人が読むならば、さらに得るものがあるだろう。

| | コメント (2) | トラックバック (1)

「アート・オブ・プロジェクトマネジメント」読書感想文(その9)

アート・オブ・プロジェクトマネジメント 問題が起きたとき、その人の真価は試される。しかも、プロジェクトに問題はつきものだから、いつも試練の日々といってもいい。

 わたしの場合、カッと頭に血が上って、あとは血がたぎる限り情熱的に(感情的に、とも言う)問題に取り組む。本当は最後のセリフ「できない理由を聞いているのはなく、どうすればできるかを教えて欲しいのです」を真っ先に言い出す。とにかく関係者全員を集めて(電話会議に呼び出して)話をさせれば打開策が出るはずだと駆けずり回る。

 後知恵なんだけど、↑は全部誤り。分かっててもやってしまう。ここでは11章「問題発生時に行うこと」で知った「わたしが」身に付けておくべきことを考察する。

■問題発生時に行うべき8つの手順

  手順1:気を落ち着かせる
  手順2:プロジェクトに関係のある問題を評価する
  手順3:もう一度、気を落ち着かせる
  手順4:適切な人材を会議室に呼ぶ
  手順5:選択肢を探求する
  手順6:最もシンプルな計画を作成する
  手順7:実行する
  手順8:結果のふり返り

 内容は推して知るべし(p.254に説明がある)。わたしが誤っているのは、手順7からいきなり実行するところ。ぶっちゃけ手順7→5→7→5をくり返している。「走りながら考えよう、結果は後からついてくる」やり方は、上手くいくこともあるが、失敗する場合の方がはるかに多いことに、いいかげん気づけ!→わたし

 まだある。プロジェクトに火がついたとき、人を追加することがいかに危険であるかは、知っているにもかかわらず、手順4を忘れてしまう。関係者を集めて話をさせれば、解はおのずと見出せるという激しい誤解のもと、どれだけ不毛な時間と体力を費やしたことか。

 「ビジョナリーカンパニー2」にある一節「適切な人をバスに乗せ、不適切な人をバスから降ろす」が心に響く。これは経営戦略を決めるときの話なんだけど、どっちへ転ぶか分からない問題解決の場合も、同じことが言える。不適切な人がいる限り、解決までの道のりは長い(ひょっとすると、たどり着けないかもしれない)。

 やってはいけない悪手をわざわざ選んでいるとしか思えない。11章は折にふれて読み返すことになるだろう。

■「責任を取る」とは何か?

 ドキュメントの表紙に

    [ 作成者:___________  ] と、

    [ 責任者:___________  ] の、

 二つのサイン欄がある。この責任者ってナニする人なんだろうね、とネタにすることはあれど、オチは必ず、責任者が責任取ったことなんて無いね、という結論に至る。

 そもそも、「責任を取る」とはどういうことなんだろうか? システム開発において、何をすれば「責任を取った」ことになるのだろうか?

 本書は、この疑問にも明解に答えてくれる→「責任を取るということは、単に、結果と向き合った上で、状況の解決に対する説明責任を負うということしか意味していない」という。

 これまで、「責任を取って辞任する」とか「責任を取って土下座する」といった、ネガティブな解しか思い当たらなかった。「責任を取る=失敗する」という思考に囚われていたんやね。ネガティブになると猫背になる、なんてこった!

 責任者とは最終的な説明責任を負う者 ―― これでスッキリしたが、だからといって非難や愚弄の嵐から逃れることにはならない。火を消すスキルを獲得したければ、火傷を負う覚悟で炎へ飛び込め、と著者は励ます。鬱に追い込まれ再起不能になるほど心を破壊された人を知っているわたしには、この励ましは空恐ろしく聞こえる。たいていの場合、火がついたプロジェクトの「責任者」はいつのまにかいなくなり、「作成者」が責任を取らされるのだから。

 一方で、頼もしく思えてくる「責任者」の力強いメッセージがある。テンプレとしても使えるので、ここに引用しておこう。

 この事態がどのようにして起こったのか、私には判らない。しかし、そんなことは今はどうでもよいことだ。それは後で心配することであり、その際には、起こったことに対して私が責任を持つつもりだ。とにかく、この事態が実際に起こってしまった以上、今すぐに、X、Y、Zを行う必要がある。X、Y、Zを実現する手段を考え出すために私に手を貸してくれないか?

 むかし、燃え盛るプロジェクトを前に、火消し屋のわたしに向かって、これと全く同じことを言い切ったPMがいる。最後まで逃げない人で、今でも尊敬している。

■パフォーマンスとプレッシャー

 自然のプレッシャー、人工のプレッシャー、ポジティブなプレッシャー、ネガティブなプレッシャーといった様々な議論が取りざたされているが、その適用は経験に裏打ちされたバランス感覚が必要だという。

 興味深いことに、プレッシャーについて、著者であるBerkun、ワインバーグ、デマルコが同じことを言っている。もちろんわたしも同意見で、最もシンプルな真実は以下の通り(デマルコ「デッドライン」より)。

 【質問】

      プレッシャーがプログラマーに与える影響が、6%の生産性向上
      だけで平坦化してしまうのはなぜですか?

 【回答】

      プレッシャーをかけられても思考は速くならない

| | コメント (0) | トラックバック (0)

「アート・オブ・プロジェクトマネジメント」読書感想文(その8)

アート・オブ・プロジェクトマネジメント 本書に書いてあることは本質的なものばかり。自分で気づいて実現できているものは「何をあたりまえな」と感じるかもしれない。そうでないものは、「分かっちゃいるけど、できていない」と思うだろう。

 ここでは、わたしにとって苦手な「分かっちゃいるけど、できていない」コミュニケーションと人間関係について述べた9章、10章の感想を書く。

■歩き回るマネジメント

 仕事ができる人は雑談が上手い、と言われるが、わたしがそれを納得するのにずいぶん時間がかかった、大損だと思う。技術力があるとか、プレゼンが上手だとか、確かに大切なものはあるけれど、イザというとき頼りになる人は、必ずといっていいほど雑談が上手い。プロジェクトがトラブルやプレッシャーにさらされるとき、肩書が無意味になるとき、皆の中心にいる人は、最も長く全員と雑談した人であるはず。その人がPMでないならば、PMは最も大切な仕事 ―― コミュニケーションを怠っていることになる。

 本書ではトム・ピーターズ「エクセレント・リーダー」にあるMBWAが紹介されている。MBWAとは、Management By Walking Around 、すなわち、歩き回るマネジメントのこと。これは優れたマネージャがもつ資質の一つだと語られている。普段からメンバと円滑なコミュニケーションを図り人間関係を築くことによって、人や情報に対する投資を行う。うまくいっていることと、うまくいっていないことの両方を知ることができる。

 わたしはこれができていない。閉鎖的というわけではい。あいさつ+αだけで、後は仕事の話に入ってしまう。雑談に"興じている"レベルになると時間の無駄だと感じ始める。そんなヒマあるなら仕事に戻りたくなる(←本当はこれが間違っているのだが…)。だからといって、趣味全開で「名雪ってさぁ…」と語るほどカミングアウトしていないジレンマ。

 まぁ、そこまでさらけ出す必要はないけれど、自分の「」を意識して出るようにしとかないと。」の中に入っている限り、まともなコミュニケーションはできていないことを常に肝に銘じておこう

■コミュニケーションにおける銀の弾丸

 「銀の弾丸」は、ある。それは、次の質問だ→「あなたがベストを尽くせるようにするには、私はどんな支援をしたらいいだろうか?」、これこそどんなピンチのときにも使える質問だ。

 メンバーにベストを尽くしてもらうために、PMはさまざまな働きかけを行う。叱咤激励したり、意欲をかき立てたり、障害を排除したり、目標を思い起こさせたり… しかし、人をコントロールすることは、かなり難しい。だから優れたPMは、自分にできること、すなわち、メンバーとの関係をコントロールしようとするわけだ。

 そのための強力な質問が「目標をあなたが達成するために、私がすべきことを教えて欲しい」になる。著者は、この質問によって次の良いことが起きるといっている。

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

 「がんばれ」は危険な言葉。なぜなら「おまえは頑張っていない」という意味が裏側にあるから。だから、「がんばれ」や「ベストを尽くせ」の代わりに、「そのために"私は"どうすればいい?」で始まる会話がより建設的になる。このパターンはわたしもよく使っているが、もうちょっとヒネっている。

  • 「○○の不具合の解析は、誰がやったら一番ラク?」と、一番分かっている人に訊く
  • 「今からお客さんとこへ交渉に行くんだけど、どこまで詰めたら、○○の見積もりができる?」
  • 「手詰まりなこの問題を、わたしのネゴで○○と△△は動かせる。それ以外に誰(どの技術・部署・チーム)に働きかけたら、あなたの作業が進むだろうか?」

■目からウロコ!→「優れた電子メールを誉める」

 うんこメールがいかに時間の無駄になるかは、あらためて説明するまでもないだろう。

 わたしの場合、うんこメールの from からフィルタリングしてゴミ箱へ直行させている。つまり、そいつのメールは開くどころか、Inbox に入れる価値すらない。その馬鹿は、自分の愚かさを指摘されること無く、せっせとうんこを送りつけている。

 簡潔・端的・明解なメールを書くためのハウツーは沢山ある。本書も多聞に漏れず「良いメールとは」のTips を例つきで紹介している。Tips は(メールの書き方を探したことがある人なら)聞いたことがあるものばかりなので、さらりと流せばよい…が、「優れたメールを誉める」は激しく納得した。

 それは、まずいメールをくさすのではなく、優れたメールを誉めること(返信でね)。PMの最重要仕事はコミュニケーションなので、メンバーの誰よりもメールのやり取りが必要とされるはず。だから、メンバーのメールの質を向上させることが、PMの生産性に直結してくる。しかも、くさすのでなく、誉めることで事態を改善するのだ。

 うんこを送りつけてくる奴に「キミのメールはうんこだよ」と言っても絶対に理解できないだろう。メールは人となりが表れる。本人が自分をふり返ろうとしない限り、メールの質は絶対に向上しないから。

 これは本書を読んで即、実践している。簡単だ、自分が「分かりやすい」「タイムリーだ」「貴重でありがたい」などとプラスに感じたメールに対し、感謝の気持ちを「ありがとう」にプラスアルファして返信する。すぐに効果は見えないだろうが、必ずあるはず。

| | コメント (0) | トラックバック (1)

« 2006年10月22日 - 2006年10月28日 | トップページ | 2006年11月5日 - 2006年11月11日 »