« 2006年10月 | トップページ | 2006年12月 »

PMP試験対策 5.3 解答のポイント

 ここでは、間違えやすいポイントを挙げる。

――――――――――――――――――――――――――――――――

 PMBOK2000版の「ひっかけ問題はこう出る/こう答える」[参照]とほとんど同じだが、その後の勉強でわたしが気づいたことを加筆し、自明だと判断したところは削除してある。

  1. 「…以外は何か?」や「…でないのは何か?」などの設問。酷いのになると、「PMが最後にするべきものは何か?」とくる。もちろん「最後にする=一番やっちゃいけない」と読み替える
  2. 「正しい」答えと「ベストな」答えの二つに迷うことがあるかもしれない。そのときは「ベストな」を選ぶこと。もちろん、このベストは、「プロジェクトマネージャが選ぶベストな」という意味で選ぶ
  3. 正しいことを言っているんだけど、設問に答えていない選択肢がある。もちろんダミー
  4. 「完全に」とか「必ず」を含む選択肢は、まず間違い。代わりに「おそらく」「一般的に」を含む選択肢は、正解に近いといえる
  5. 正しいことを言っているんだけど、設問に答えていない選択肢がある。もちろんダミー
  6. 「組織のプロセス資産」に注意。これは、あちこちで出てくるにもかかわらず、そのプロセスで必要としている側面によって中身が大幅に変わってくる。例えば、スコープ計画プロセスでのインプットでは、「組織の方針や手順」「過去の教訓」とあるが、品質計画でのインプットだと「母体組織の品質方針」「過去のデータベース」となる
  7. PMは「プロアクティブ」でなければならない。試験ではこの「プロアクティブ」という単語はそのままでてこない。PMは先見の明を持ち、問題を事前に捉え、早期に変化を察知し、先行して手をうつもの
  8. PMはバランスが肝心。制約3要素「スコープ」「スケジュール」「コスト」の間のトレードオフを図りながら結果を出すことを「品質が良い」という。よくある「スコープ盛りだくさん=金メッキ」や「バグが少ない」ことは、品質が良いと言わない
  9. リスクに注意。「リスク」というとネガティブな意味にとられがちだが、PMI ではチャンスも含む。プロジェクトの目標にプラスまたはマイナスの影響を与える不確実な事象を指す。PMはプラス要素を最大化し、マイナス要素を最小化することが肝要だと説く

――――――――――――――――――――――――――――――――
PMP試験対策【まとめ】

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

PMP試験対策 2.1プロジェクトマネジメント・プロセス

 ここでは、単一プロジェクトのプロジェクトマネジメント・プロセスについて説明する。マネジメントプロセスは、プロジェクトをまわす手順だと把握しておけばよい。

――――――――――――――――――――――――――――――――

■プロジェクト成功の定義[p.37]

 「プロジェクトが成功する」とは、どういうことか? PMIはプロジェクト成功の定義を謳っている。よく言われる、品質・納期・コストを守るでは不十分で、以下のように定義される。


  • プロジェクト目標を満たすために必要なプロセスを選択する
  • 要求事項をみたすように成果物の仕様と計画を調整する
  • ステークホルダーのニーズ、要望、期待に応じた要求事項を満たす
  • スコープ、タイム、コスト、品質、資源、リスク等の競合する要求のバランスをとって、高い品質のプロダクトを生成する

■プロジェクトマネジメントプロセスのカテゴリ[p.38]

 ふたつある。構造化モデルとオブジェクト指向のカテゴリに近い分け方で興味深い。

  • プロジェクトマネジメント・プロセス:プロセス(手続き)指向のマネジメント。統合された目的(立上げ、計画、事項、監視、終結)へ向けて実行することで相互に関連するプロセス群
  • 成果物指向プロセス:プロジェクトの成果物の仕様を決めて、それを作るためにどうすればよいかを具現化するやり方

いずれの場合でも、考慮するべきプロセスを選ぶ際、PMBOKガイドを利用して、必要にあわせてカスタマイズしなさい、という。これを「テーラーリング」と呼んでいる。

■プロジェクトマネジメント・プロセス[p.40]

 [p.40]の図が全て。ただし、次のことが忘れがち→マネジメントプロセスは、フェーズ内でも回るし、プロジェクト内でも回る(プロジェクト全体を示した図だけではないことに注意!)。プロジェクトマネジメントプロセスのピラミッド[p.69]を見ると分かるが、フェーズで少なくとも1度は回っていると考え、フェーズごとに回転していると理解する。

 プロジェクトマネジメント・プロセス群は、プロジェクト・フェーズではない(←超重要)。よくあるひっかけが「終結プロセスに入った。プロジェクトはもうすぐ終わるか?」といった設問。フェーズの終わりでも「終結プロセス」は存在するため、答えはNOになる。例えば、「要求仕様の抽出を行う」フェーズがあるとすると、「要求仕様書の引継ぎ」が終結プロセスで行われる。でも開発は続くヨどこまでも、次のフェーズになるだけで、プロジェクトは終わらない。

■プロジェクトマネジメント・プロセス群の攻略の前に

 個々のプロセスの話に飛び込む前に、そのプロセスが全体のどこに位置しているのかを考えながら理解する。いきなり細かい話になるので、全体とのつながりが見えにくくなり、「結局どうしてそのプロセスが必要なんだっけ?」と考えるようになる。

 そうならないためには、[p.70]の一覧表と、[p.337]から始まる付録F「知識エリアの要約」が役に立つ。一覧表は、そのプロセスが、立上げ、計画、実行、監視、終結のどの群に配置され、知識エリアのどこに位置しているかが一目でわかる。また、「知識エリアの要約」は、初めてPMBOKを読む人が目を通すには最適の資料だと思う。たった5ページに凝縮されており、「結局ソコで何すんの?」という質問に明確に簡潔に答えているから。

――――――――――――――――――――――――――――――――
PMP試験対策【まとめ】


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

ローマ人の物語V「ユリウス・カエサル――ルビコン以後」の読みどころ

 ずばり、クレオパトラを攻撃する塩野ばあちゃんの筆さばきですな!

 恨みでもあるのか、チクチクといたぶり、要所要所でこきおろす。「いとしのカエサルタン」の下半身を牛耳ったのがシャクに障るのかもしれないが、2000年も前の話だから勘弁してやれyo! と思いながら読む。

■クレオパトラ vs カエサル

 エジプトの内乱を平定するためにやってきたカエサル。彼を自陣に取り込みたいクレオパトラにとっての起死回生の策が面白い。ガードの固いカエサルのもとへ侵入(夜這い?)するために、ふとんにもぐりこんで召使に運ばせるクレオパトラ。ふとん+美女の絶好のシチュは誰だって(*´д`*)ハァハァできる艶話。

 しかし、塩野ばあちゃんは手厳しく、こう断じている。

 要するに、カエサルには、たとえ愛人関係に進まなかったとしても、クレオパトラの軍事上の劣勢を挽回してやる理由は多かったのである。恋愛が介在することで左右できるほど、国際政治は甘くない。また、カエサル自体が、愛しはしても溺れない性格だった(11巻p.291)

 当時はそんな言葉はなかったにせよ、合理主義が服着ているようなカエサルのことだから、確かにそのとおりだったかもしれないけれど、ミもフタもないね。同じオンナなんだから、もうちょっと手加減してやれよと思うのだが、続けてこう追い込む。

 ただし、クレオパトラのほうがそれを、自分の魅力のためであったと思い込んだとしても無理はなかった。女とは理(ことわり)によったのではなく、自分の女としての魅力によったと信じるほうを好む人種なのである。それに、女にそのように思い込ませるなど、カエサルならば朝飯前であったろう(11巻p.291)

 そんなばあちゃんに、このサイトをオススメしよう→「カエサルハァハァ…」。カエサルタンへの愛が満ち溢れている。

 自分で作り上げた「カエサル像」を眺めてはホレボレする、そんなばあちゃんが目に浮かぶ。んで、その「像」に反するような説に耳をふさいで曲げて否定する。うん、わかるよ。二次元萌え歴もずいぶんになるわたしには痛いほど分かる。

■クレオパトラ vs アントニウス

 カエサル亡き後、ローマの頂点としてエジプトにやってきたアントニウス。彼の攻略は、カエサルのときよりもカンタンだったそうな。どうやら、クレオパトラの方が一枚上手だったらしい(と塩野氏は書いている)。

 「クレオパトラは美人ではなかった」という話を聞いたことがあるが、どこまで本当だろうか。2000年も前のことだから、誰もハッキリしたことは言えないだろう。しかも、当時の「美人観」が今とかなり異なっていることは、千年前の日本絵巻を見れば明らかだ。

 それでもクレオパトラが美人だった方がネタとして面白いから、(真偽はともあれ)そうなっているのだろう。わたしも支持する、だってハァハァできるから。ローマの権力者をマタにかけ、世界のはんぶんを奪った傾城の美女が見た天国と地獄、というだけで面白くないワケがない。

 塩野氏の「もっと自由に歴史を読んでいい」コトバに結構モウを開かされている。「ローマ人の物語」が好きなのは、史実への忠実度からではなく、話として面白いから。著者が自分のことをシロウト呼ばわりして、歴史家にはご法度の「もしも…」を乱発して好き勝手に書いているから、こんなに面白い歴史(みたいな物語)が読めるんだ。

 にもかかわらず、根拠を出さずに「クレオパトラは美人ではない」を前提に話を進めてくるところにアレっとなる。「美人ではなかったと思う」とハッキリ言やいいのに、こんな風に書いてくる。これはこれで詭弁の見本のようなもので面白い。

 それにしてもクレオパトラは、絶世の美女ではなくてもそう思わせる技(わざ)に長じ、頭は良く機知に富んだ女であったことは確かだが、ほんとうの意味での知性にも恵まれていた女人であったのか?(13巻p.171)

 太字はわたし。フツーに読むと、「知性に恵まれていたのか?(いやない:反語)」になる。続けて、クレオパトラの外交面での現状認識不足、ローマ人の文化への無知があげつらわれる。

 しかーし、冷静になって読むとさりげなく「美女ではなくても」と入っている。この、前提に主張を含ませて、主文で議論を展開するやり方は「悪魔の詭弁術」あたりで学べる。噛み付く奴は主文「頭悪かったんちゃう?」に喰い付いてくるから、前提の「美人じゃなかったんちゃう?」は同意済みと受け取られる詭弁テク。

 もっと面白い詭弁がある。主張の前後がつながっておらず、通常「後ろ」に真意がくる日本語文なのに、「前」に本当の気持ちが込められている。

 私も女だから、女の浅はかさなどという表現は避けたい。だが、決定的な一歩を踏み出したときのクレオパトラは三十二歳である。若いがゆえの経験不足という、弁解さえもできない(13巻p.174)

 太字化はわたし。ローマの覇権をめぐって、アントニウス vs オクタヴィアヌスの対立が深まる状況で、クレオパトラはアントニウスに就く(ホレ、あの"アントニーとクレオパトラ"だね)。これが彼女の破滅への道とつながるわけだが、見所は塩野ばあちゃんがこいつをどうやって料理しているかというところ。

 「だが」の前後が繋がっていない。「若さゆえの過ち」→「だが」→「当時は32歳だから経験不足という弁解ができない」なら通じるが、あえて(?)「女の浅はかさ」としている。なぜか? それは、この後さんざんクレオパトラこきおろして、最後にこうつなげているからだ。

 しかも、エジプト女王の「浅はかさ」は、アントニウスのパルティア遠征をも狂わせてしまうことになったのである

 つまり、クレオパトラの「浅はかさ」が破滅を招いたことにしたかったため、ここで出しても違和感がないように露払いしているという罠。彼女が歴史を狂わせたことは事実だけれど、失敗の起因はことごとく彼女にされてしまっている。なんでもかんでも彼女のせいにしちゃいかんだろ… ツッコミながら楽しく読めた。



ローマ人の物語11ローマ人の物語12ローマ人の物語13

――――――――――――――――――――――――――――――――――
「ローマ人の物語」の読みどころ【まとめ】に戻る

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

「ローマ人の物語」を10倍楽しく読む方法:「プルターク英雄伝」と比べ読むと…

プルターク英雄伝 「ローマ人の物語」だけを読んでいくと、塩野史観というかカエサル萌え心にあてられて辟易するかもしれない。2000年も前に死んだ男にここまでイれコんでいるのを見ると、ちきゅうのおとこに飽きたところなのかなー、と思ったり。

 そして、「ローマ人の物語」だけを読んでいると、塩野氏が飛ばした(軽く触れた)ところが気になってくる。例えばクレオパトラのくだり。軍事的な劣勢を挽回すべくカエサルを色香でローラクしたとかしないとか… このあたりは、パスカルの「クレオパトラの鼻がもう少し低かったら歴史が変わっていた」が有名だが、塩野氏は「据え膳喰っただけ」とニベもない。しかも、下半身でコントロールされなかった事実として、カエサルの遺言でクレオパトラとの子に言及していないことをあげつらう。

 ううむ、ここはひとつ、底本として著名なプルターク英雄伝をひいてみる。ガードの固いカエサルに遭うために、クレオパトラが一計を案じるところ…

 ── クレオパトラは小船に乗り、夕闇にまぎれて王宮に近きあたりに上陸した。彼女はいかにして人目にふれず宮中に入るべきかとほうに暮れていたが、やがて一計を案じ寝台のふとんにもぐりこみて、召使がこれを運びあげてなにげなきさまに宮門を通り抜け、シーザーの居間に持ち込んだ。シーザーはまず彼女のこの大胆なる機転を見て敬服し、次には彼女の社交ぶりの魅力に征服させられたので ──

 夜這いはコソコソしているけれど、ふとんに入って堂々と突破するなんてステキ!しかも、カモネギならぬ、ふとん美女なら多くを語るまでもなかろう。こんな面白いエピソードをイヤイヤ触れる塩野氏… おばあちゃんながら、かわいいぞ。

 というわけで、ローマ人を語るなら避けて通れない「プルターク英雄伝」は名著と誉れ高い …が、岩波文庫で全12巻は読めねぇ。そんなものぐさなわたしにうってつけの「プルターク英雄伝」のまとめ本があった。コンパクトにまとめられてて訳も平易なんだけど、塩野ローマにハマっているわたしからすると英語読み(シーザー)に違和感を感じる。以下、気になったのを対比してみる。やっぱり「カエサル」で読みたいねっ

  • カエサル → シーザー
  • スッラ → シラ
  • キケロ → シセロー
  • ポンペイウス → ポムペイ
  • カト → ケートー

 これを併読しつつ、塩野氏が書いていなかったところを意地悪く読むのも愉しい。

――――――――――――――――――――――――――――――――――
「ローマ人の物語」の読みどころ【まとめ】に戻る

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

「ハッカーズ」はタメになるよ

ハッカーズ 常識の斜め上を行くハッカーたちの告白。おもしろい、おそろしい。

 DNS逆引きやポートスキャン、キーロガーといった、なつかしい技が紹介されている。今となっては本書どおりに『活用』するのは危険きわまりないが、ハッカーたちの考え方はとても参考になる。

 ハッカーたちはスゴ腕のプログラマ、というわけではない。プログラミング技術よりもむしろ、人間の弱点を探す技術(というか思考方法)が優れている。つまり、ネットワーク管理者やシステム開発者の思考プロセスに入り込み、彼らと同じ目でコードやインタフェースの振る舞いをたどりながら、穴を探り出す。例えばネットワークの「設定ミス」や、暗号化や乱数発生モジュールの「手抜き」を嗅ぎつける。

  • ネットワークの境界『だけ』注目しすぎて、イントラネット内はザル状態
  • 機器のログイン名・パスワードがデフォルトのまま("administrator"というアカウント名、"password"というパスワード)
  • OSやソフトのセキュリティパッチあててない
  • anonymous そのまんま(誰かふさげよ!)
  • ゾンビサーバー!

 その「穴」を探り出す発想が常人の斜め上を行っている。もちろん、自動化や解析のためにコードを書くことはあるけれど、それは必要だからDIYしているにすぎない。warezをコンビニで買ってきて自己満足に浸るねとらん厨房とかなり違う。

 ボーイングやホワイトハウス、あるいはマイクロソフトのイントラネットに侵入するやり方は想像つく。しかし、カジノにあったスロットのROMから吸い上げ→逆アセンブルは見当がつかない(エミュ自作?)。ハードウェア、ソフトウェア、ソーシャルエンジニアリングの三面からアタックを仕掛けられたらひとたまりもないだろな…

 その地道さに呆れるばかりではなく、彼らの発想がスゴい。例えば、

  • そのアカウントの正しいパスワードを探すのではなく、"password"でヒットするアカウントを探す
  • 設計思想にのっとったハッキング── OK、わたしが従業員だとしたら、システムに対してどんなリクエストを出すだろうか ってね。ユーザーの操作が合法か非合法か見分けるのは難しい。なぜなら、流れているデータに合法も非合法もないから
  • 「わざわざそこまでやる奴はいないだろう」って開発者が言うたびに、わざわざそこまでやる奴がフィンランドあたりに現れるんだ

欺術 ハッキングテクニックなんてしらない良い子(?)のわたしにも、気づきがたくさんあった、と報告しておこう。warezのftpよりもメジャーな奴を使うほうが監視の目をくぐり抜けやすいとか(名前勝ち、というやつ)、マイナー機器(ルータ/サーバ)ほどreadme.txtや詳細やマニュアルが/tempあたりに落ちてやすいとか、防ぐほうからするとドキッとすることが書いてある。

 ソーシャルエンジニアリングに限定したネタなら、同著者の「欺術─史上最強のハッカーが明かす禁断の技法」あるいは、以前のエントリ「USBメモリを用いたソーシャル・エンジニアリングあたりがオススメ。

 ご利用は、やめておけ。

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

PMP試験対策 1.2プロジェクト・ライフサイクル

 ここでは、プロジェクト・ライフサイクルについてまとめる。

――――――――――――――――――――――――――――――――

■ プロジェクト・ライフサイクルの特性

 あたりまえだが、プロジェクトはいくつかのフェーズに分割される。どのように、いくつに分割されるかはプロジェクトによって異なるが、システム開発でいうならば、大きく、設計/製造/テストに分けられる

 もちろん開発手法によって種々の分け方・呼び名があるし、あるフェーズを繰り返しているところもあるだろうが、そうした分割したフェーズの集合体をプロジェクト・ライフサイクルと呼んでいる。

 [p.21:PMBOK] の図のポイントは以下のとおり。絵で見ると一発なので絵を見よ。

プロジェクトの開始時プロジェクトの中間プロジェクトの終了時
要員数やコストは少最大急激に落ち込む
リスク最大徐々に減っていくリスク最小(→完成)
変更(手戻り)コスト極小徐々に増えていく変更コスト極大
ステークホルダーの影響力大影響力はだんだん減っていく影響力はほとんど及ばない

 プロジェクトの初期はリスクが極大のため、そもそもそのプロジェクトを実施するべきか否かを調査することがある。これをフィージビリティ・スタディと呼ぶ

■ プロジェクト・フェーズの特性

 フェーズの特性としておさえるべきところは、要素成果物(仕様書、プロトタイプ、サービス)の完成や承認により特徴付けられる。通常、フェーズ終結時のレビューは、現在のフェーズを終了させ、次のフェーズ立上げの承認を得る意味を持つが、フェーズの完了が次のフェーズの開始を意味するわけではないことに注意。

■ プロダクト・ライフサイクルとプロジェクト・ライフサイクルの違い

 [p.24:PMBOK]の図が全て。

■ プロジェクト・ステークホルダーとは

 プロジェクトに積極的にかかわっている人、プロジェクトからプラス・マイナスの影響を受ける個人や組織、プロジェクトの目標や成果物にプラス・マイナスの影響を及ぼす人[p.25:PMBOK]

 ステークホルダーとプロジェクトの関係図は、ちょっと変わっている。「プロジェクト・スポンサー」の位置付けがヘンなのだが、理由があるに違いない。スポンサーは、ステークホルダー、マネジメント・チーム、プロジェクト・マネージャと境界を接しているが、より広く接している「スポンサー」と「マネジメント・チーム」と密接に関係しているとか。

■ 組織構造

 [p.28:PMBOK]の図が全て。補足として、マトリックス型は二人の上司(プロジェクトのマネージャと機能部門のマネージャ)に報告義務があるとか、弱いマトリックス型だとプロジェクトマネージャの役割は調整役となるとか(調整役の方が格上)


  • プロジェクト調整役(Project Coordinator)
  • プロジェクト促進役(Project Expeditor)

――――――――――――――――――――――――――――――――
PMP試験対策【まとめ】


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

「ハマースミスのうじ虫」は読者を選ぶ逸品

ハマースミスのうじ虫 極上のミステリ… ただし読み手を選ぶのでご注意。

 ひとくちに「ミステリ」といっても窓口も奥行きも幅広なので、自分の経験で手をつけると失敗する(「けいざいがく」と一緒だねッ)。ともあれ、最近のジェットコースター型ミステリが好きな読者は止めておいたほうがいい。ダン・ブラウンよりコーネル・ウールリッチが好き、という人向け。

 展開は派手さもなく淡々としている。渋~い英国ミステリとでもいえばよいのか。amazonレビューはこんなカンジ…(太字化はわたし)

 風変わりな趣味の主キャソン・デューカーは、ある夜の見聞をきっかけに謎の男バゴットを追い始める。変装としか思えない眼鏡と髪型を除けばおよそ特徴に欠けるその男を、ロンドンの人波から捜し出す手掛かりはたった一つ。容疑者の絞り込み、特定、そして接近と駒を進めるキャソンの行く手に不測の事態が立ちはだかって…。全編に漲る緊迫感と深い余韻で名を馴せた、伝説の逸品

 登場人物が読んでる本やワインネタがいちいち鼻につく。読み手の教養レベルが試されているかのような小道具が出てくるたびに、英国ってのはやっぱり階級社会なんだなぁとつぶやく。後でこれが物語の基本柱になっていることに気づくのだが、まさか計算して書いたわけでもあるまい。

 情景描写に独特の緊張感があり、読むことの快楽を味わえる(解説では「一本筋が通っている」と表現してた)。この緊張感、最初は羽音のように小さいものだが、話が進むにつれだんだん増幅し、最後の追い込みのトコなんてワーンと響くようだった。

 面白いのは主人公のキャソン。若くして成功した上流階級の経営者。金だけでなく容姿端麗で女受けも良い。ルックスだけでなく教育も折り紙付き(オックスフォード卒)。しかも独身。

 義憤に駆られて謎の男を追いかける「いい人」なんだけど、その熱中っぷりがスゴい。金あるなら誰かにやらせりゃいいのに、あるいはヤードがいるでしょ、というわたしのツッコミを尻目に、執念に近いほどのモーレツぶりで追い詰める。ラストに近づくほど犯人が気の毒に思えてくる。

 心理描写のうまさに感心しながら読了し、解説で著者の履歴を知ってびっくり&納得する。本書に読者を驚かすような仕掛けがあるとするなら、解説だな。

── とここまで書いてきて、解説文にある読後の「余韻」ってなんぞや? と思う。

 ラスト数行のちょっと意外な"補足"のことを指しているんだろうなぁ… と考えて、今になってようやく気づいた。どんでん返しとまではいかないけれど、唐突な感じのするラスト数行は、本書が生まれる理由だったんだな。どうりである場面で人称に違和感を覚えたわけだ。さらに、食べたものや飲み物の名前を克明に書いていたのは備忘の意味だったんだね。いずれにせよ、虚栄心が犯罪を産み、同じ虚栄心によって滅ぼされる犯罪者は、とてもユニークだから、このゲス野郎のことは何度も思い出すだろう。そう、彼が望んだように

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

PMP試験対策 1.1フレームワーク

 ここでは、プロジェクトマネジメントフレームワークについてまとめる。プロジェクトマネジメントそのものの『定義』の話。

――――――――――――――――――――――――――――――――

■ PMBOKガイドの目的

 第一の目的:プロジェクトマネジメント知識体系のうち、良い実務慣行(good practice)と一般的に認められている部分を特定する。「良い慣行」が"best practice"でないところがミソ。つまり、選択肢中に「唯一の」「最も」「ベストな」が出てきたら疑ってかかる。

 他の目的として、共通用語集、PMBOK知識体系の入り口、PMP育成の参考書といった位置付け。つまり、この分厚なPMBOK3版は入門書(guide)なんだよと言っている。

■ プロジェクトとは何か

 1.有期性(スタートポイントとエンドポイントがある)
 2.独自の(unique)プロダクト・サービス・所産(result)
 3.段階的詳細化(proguressive elaboration)でだんだん詳細化される

 いっぽう、定常業務は業務が継続して反復的に行われるトコがミソ。

 また、プロジェクトは戦略計画を達成する手段の一つとして、市場需要、組織ニーズ、顧客の要求、技術進歩、法的な用件を考慮した上で決定される。

 いつから燃えてるのか分からない火事場に放り込まれ、当初メンバーは逃げ出して「何を作るのか」はアイマイなまま、段階的にスコープが拡大していく(スコープクリープというらしい)―― プロジェクトの定義から最も遠いところで働く。

■ プロジェクトマネジメントとは何か

 プロジェクトマネジメントとは、プロジェクトの要求事項を満足させるために、知識、スキル、ツールと技法をプロジェクト活動へ適用させること。「要求事項」は、必ずしも顧客の要求事項だけに限らないところがミソ。

 具体的には、要求事項を特定し、目標を確立し、品質・スコープ・タイム・コストの競合する要求のバランスをとり、ステークホルダーがそれぞれ抱える関心・期待に応えるために、仕様・計画を適用させる ―― 上司に読ませてやりたい orz

■ プロジェクトマネージャとは

 プロジェクトマネージャとは、プロジェクト目標を達成する責任を負う人のこと。プロジェクトの実行責任者であり、失敗したときは説明責任がある。チームをアシストし、ステークホルダーの対立を解消する人でもある。制約三条件のバランスをとりながら、プロジェクトをファシリテートする人

 制約三条件として、スコープ、タイム、コストがある。品質は含まれない。プロジェクトの品質はこの3要因のバランスを取ることによって決まる。つまり不具合ゼロのシステムを期限通りサービス開始できたとしても、予算を大幅超過してたら、プロジェクトとしての品質は悪い、ということやね。

■ ポートフォリオ、プログラム、プロジェクト、サブプロジェクト

 ネストはこんな感じ。定常業務はプログラムの配下にぶら下がるところがミソ。

  ポートフォリオ
   └プログラム(複数のプロジェクト、定常業務含む)
      ├プロジェクト
      │ └サブプロジェクト
      └定常業務

■ プロジェクトマネジメントに必要な専門領域

 [p.13:PMBOK]の図を参照。PMBOKだけではない。適用分野の標準・規制、プロジェクト環境(文化・社会的環境、国際環境、物理的環境)、一般的なマネジメントスキル、人間関係のスキルがあるそうな。PMBOKはプロジェクトマネジメントを行うために必要な専門領域の『一部』であるところがミソ。

■ PMOとは

 プロジェクト・マネジメント・オフィスのことで、複数のプロジェクトを一元管理し、プロジェクト間の調整を図る… とあるが、リアルは単なるテンプレ屋だったり火消し屋衆の寄せ集めだったりするので要注意。

――――――――――――――――――――――――――――――――
PMP試験対策【まとめ】


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

悪魔の詭弁術

詭弁論理学 「わたしと仕事、どっちが大事? はなぜ間違いか」の紹介エントリ[参照]でオススメいただいた詭弁本をいくつか。容易に悪用できるので、詳細はカンベンな。

 詭弁術の実例は、fj や 2ch でさんざ見てきたので今さら感もあるのだが、こうして体系的に見せられるとなかなか興味深い。このテのは昔も今も変わらないもんだなぁ…

 まず qinmu さんにオススメいただいた「詭弁論理学」は、よくまとまっている。ナントカの一つ覚えのように主張を繰り返す小児強弁型、相手=悪、だから、自分=正しいとする二分法、論点のすりかえ、主張のいいかえ、ドミノ理論(風が吹けば桶屋)と、誰でも一度は聞いたことがある詭弁術が紹介されている。強弁が強盗なら詭弁は詐欺だという主張にナットク。例は多少が古めかしいが、中身は全く現役だ、今夜もどこかの板で議論されているハズ…

 そういや、2ch の詭弁のガイドラインに詭弁の特徴15条があったので貼り付けておく。2ch とセガBBS が詭弁の応酬の練習場だったなぁ(ずいぶん遠い目)… 今はblogで旺盛だねッ

■ 詭弁の特徴十五条

  1. 事実に対して仮定を持ち出す
  2. ごくまれな反例をとりあげる
  3. 自分に有利な将来像を予想する
  4. 主観で決め付ける
  5. 資料を示さず自論が支持されていると思わせる
  6. 一見関係ありそうで関係ない話を始める
  7. 陰謀であると力説する
  8. 知能障害を起こす
  9. 自分の見解を述べずに人格批判をする
  10. ありえない解決策を図る
  11. レッテル貼りをする
  12. 決着した話を経緯を無視して蒸し返す
  13. 勝利宣言をする
  14. 細かい部分のミスを指摘し相手を無知と認識させる
  15. 新しい概念が全て正しいのだとミスリードする

論理で人をだます法 もう一つ。cyclolith さんに教えていただいた「論理で人をだます法」は、邪悪だ。これは、相手を貶めるためのありとあらゆる口技が紹介されている。網羅性はピカイチで、使われたことも、使ったこともあるに違いない。

 相手の主張の是非なんか一切問題にしない。主張の力を貶め、相手の人格を攻撃し、的外れの例を持ち出してそれをこきおろし、聞き手の感情に訴え、単純な構図に押し込み、関係のない話題へもっていき、質問には質問を返し(カウンタークエスチョン)、論点をあいまいにするための手段が徹底的に実例つきで紹介されていて、まさに悪用厳禁。

 さらに、その実例がいちいちうなずけるのよ、わたしもよく使うから、その威力は知っている。書くと丸分かりだけど、話し言葉として上手に「使う」やり方は、本書が非常に参考になる。

■ 悪魔の詭弁術

  • みんなやってるよ── バンドワゴン・アピール
  • ご存知のとおり、この問題のそもそもの原因は… ── 決め付け
  • 逆に教えてくださいよ、ぜひ── 質問に質問を返す(カウンタークエスチョン)
  • 主張を証明できないなら、その主張は嘘だ
  • ぜったい対まちがいないよ── 憶測にすぎない話を、事実であるかのように話す
  • 言っていないことを言ったことにする、そしてそれを攻撃する── わら人形テク
  • 「すべて」と「一部」を混同し、一部でもってすべてとするテク(○○人はみんな△△だ!)
  • 質問のすりかえ、そしてすりかえた質問に答えるテクニック←悪用厳禁!

 特に最後のやつは、わかりやすい例を用いており、今すぐ使える詭弁テクだな。そして、もっと非道なのは、詭弁を見つける手段までは紹介してくれてても、それをなんとかして、切り返す・切り崩す・話を元に戻す方法はぜんぜん書いていないところ。つまり、相手をホンキで貶めようとするならば、ある種のテクニックを使えば、かなり容易だってこった。

 ご利用は計画的に。

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

PMP試験対策【まとめ】

PMBOKガイド3版 PMP試験対策の入口へようこそ。

 PMP対策のための一連のエントリは、ここにリンクを貼り、(わたしを含め)読者のお役に立てるようにする。コンテンツも無いのにいきなり【まとめ】を作ったのは、自分を追い込むため。さらに宣言する→2007.1 中にPMP資格試験を受験し、合格する

このシリーズの目的

  • PMP試験に『わたしが』合格する(2007.1) 合格しますた(2007.1.20)
  • PMP試験対策で勉強したことを整理するために書く

(わたしを含む)このシリーズを読む人のための注意事項

  • PMBOKガイド3版がベース
  • Rita 本は2000年版がベース(したがって、古い)
  • あくまで『わたしの』理解なので、誤りがあるかもしれない。読み手は参考程度に留めておいたほうがよいかと
  • まちがいじゃね? ツッコミ歓迎
  • PMBOK3を持っていることが前提(のつもりで書くので、2000版との違いだとか、インプット/ツール/アウトプット一覧とか、どこかに載っていそうなものは割愛)
  • 参照方法[p.40:PMBOK]と書いたとき、PMBOKガイド3版の40ページのこと(無料の pdf は[ここから入手]できるが、登録が必要なのと英語なのでご注意)
  • pdf(英語)、ペーパーバック(日本語)、ペーパーバック(英語)全て同じページ番号なので、原著にあたるとき便利かも
  • 前回[参照]と異なり、網羅性は追及しない。採れるところはPMBOKガイドでおさえ、ヤヴァそうなところはこのblogで徹底的につぶす
  • オタネタ禁止(できれば)

このシリーズは、たぶん、次のような構成になる。

――――――――――――――――――――――――――――――――

1. まず全体を把握する
 1.1 フレームワーク
 1.2 ライフサイクル

2. プロセスから整理する
 2.1 プロジェクトマネジメント・プロセス
 2.2 立ち上げプロセス
   2.2.1 「立上げ」の目的とやっていること
 2.3 計画プロセス
   2.3.1 「計画」の目的
   2.3.2 「計画」でやっていること(スコープ)
   2.3.3 「計画」でやっていること(タイム)
   2.3.4 「計画」でやっていること(コスト)
   2.3.5 「計画」でやっていること(リスク)
   2.3.6 「計画」でやっていること(品質、コミュニケーション、人的資源)
   2.3.7 「計画」でやっていること(調達)
 2.4 実行プロセス
 2.5 監視・コントロールプロセス
 2.6 終結プロセス

3. 計算問題は確実に取る
 3.1 アーンド・バリュー
 2.2 クリティカルパス
 3.3 コミュニケーション・チャネル
 3.4 三点見積り
 3.5 IRR [p.146:Rita]
 3.6 ペイバックピリオド
 3.7 BCR(利益コスト率)
 3.8 機会コスト
 3.9 サンクコスト

4. 『わたしが』覚えるべきこと

5. おまけ
 5.1 PMP試験対策(PMBOKガイド2000版対応)シリーズの入口
 5.2 なぜPMP試験は難しいのか?
 5.3 解答のポイント
 5.4 PMP受験報告
 5.5 「PMP試験実践問題」はアラ探ししながら読むのが正しい
 5.6 PMP試験の準備(わたしの場合)


――――――――――――――――――――――――――――――――
履歴
2006.11.10追加 PMP試験対策 1.1 フレームワーク
2006.11.14追加 PMP試験対策 1.2 プロジェクト・ライフサイクル
2006.11.21追加 PMP試験対策 2.1 プロジェクトマネジメント・プロセス
2006.11.30追加 PMP試験対策 5.3 解答のポイント
2006.12.15追加 PMP試験対策 2.2 立ち上げ
2006.12.17追加 PMP試験対策 2.3 計画
2006.12.19追加 PMP試験対策 2.3 計画
2006.12.27追加 PMP試験対策 2.3 計画
2006.12.30追加 PMP試験対策 2.3 計画
2007.01.05追加 PMP試験対策 2.3 計画
2007.01.24追加 PMP試験対策 5.4 おまけ
2007.01.29追加 PMP試験対策 5.5 おまけ
2007.02.02追加 PMP試験対策 2.3 計画
2007.02.08追加 PMP試験対策 5.5 おまけ

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

なぜPMP試験は難しいのか?

PMBOKガイド3版 語弊があるのでこう言い換える── 「なぜわたしはPMP試験対策を難しいと感じたのか」ってね。2年前に始め、投げ出した受験勉強で、少なくともこの疑問に答えられるようになったので、書く。再起動の意思を込めて。

■ 範囲が膨大

 試験対象はPMBOK3、すなわち、プロジェクト・マネジメント知識体系ガイド第3版なんだけど、A4版で400ページある。たっぷり文字が詰まっているので、初めて開けたときは正直ひるんだ。

 しかし、見方を変えるとここからしか出ない、とも言える(プロフェッショナル責任は別)。PMBOKガイド+問題集+αで、合格ラインの勉強時間の目安は、およそ120時間だという。もちろんこれより短い時間で合格した人もいるし、もっと長い時間をかけても不合格だった人もいる。それでも、最低でもこれぐらいやれるようにスケジュールを組みなおそう。

■ アタマに入ってこない

 PMBOKは「知識体系」なので、実践での適用とは異なった順番で説明されている。たとえば品質マネジメント。「品質計画」「品質保証」「品質管理」のそれぞれのプロセスは、異なるフェーズで実施されるプロセスであるにもかかわらず、8章プロジェクト品質マネジメントにてひとくくりで説明されている。「品質マネジメント」に特化して、

 1. 計画プロセスで品質計画を立てる
 2. 実行プロセスで品質を保証をする活動を実施する
 3. 監視プロセスで品質管理を行う

 のように書いてあり、それぞれのプロセスでの相互依存関係で語られていない。体系的なものにするために、それぞれのプロセスから摘出しているわけ。これがアタマに入ってこない最大の理由。

 プロセス順に考えると、「品質計画」に先行するプロセスは「WBS作成」で、後続するプロセスは「スケジュール作成」だ(p.47:PMBOK)。その結果、

 1.WBSを作成する
 2.(WBSを元に)品質計画を立てる
 3.(品質計画を元に)スケジュールを作成する

 この順番で作業が進む。流れが納得できるし、何よりもそのプロセスのアウトプットが、後続プロセスのインプットになることが理解できる。だから3章のプロセス相互作用図を見ながら、プロセス順にインプット→ツール→アウトプットを押さえるべし

■ なぜ『正解』なのか納得できない

 ためしに問題を解いてみると、ボロボロの結果になる。『正答』なる選択肢を見ても納得できない。なぜそれが正解なのか理解できないし、説明はPMBOKガイド○ページ参照とあるだけ。実際のプロジェクトではそれは『正解』からは程遠い選択肢なのに…

 それは、解く姿勢が間違っている。アンタのプロジェクト経験談を訊いているわけではなく、PMIなら何を推奨するか、と問うているわけなのよ。典型的なのは、対立の解決手法。以下の手法のうち、最も妥当なものに○、もっとも不適当なものに×をつけるなら、どうなるだろうか?


  • 強制:業務命令、執行指示×
  • 撤退:意見を取り下げて、相手に従う
  • 鎮静:同意できない点は目をつぶって先送りする
  • 妥協:ギブアンドテイク

 答えは反転文字で書いた。現場で対立が昂じてきてどうしようもないほどヒートアップしたとき、「○」で記した解決策はありえない。少なくともわたしの経験では、むしろ「×」で記した方が有効だった。

 だから、自分の経験で回答しようとすると、間違いなく間違える。だから真偽はともかくガイド通りに答えるのが吉。

 さて、ネットに向かって宣言することで自分を追いやってみるとしよう ── PMP対策の勉強を再開する。合格期限は、2007.1 とするってね。短期決戦のため、以前のように勉強の軌跡を記す余裕はないだろうけれど、自分が学んだことを整理する場として、このblogを使ってみるつもり(誰かの役にたつとイイナ!)。

⇒以前のPMP対策シリーズ:プロジェクト・マネジメント・プロフェッショナル資格試験対策(※注:PMBOK2000版)

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

「ローマ人の物語」を10倍楽しく読む方法:カエサルはこの順に読むべし

 塩野七生「ローマ人の物語」は自信をもってオススメできるんだけど、いかんせん緩急というか浮き沈みが激しい。

 書き手がノっている巻は措クニアタワズという言葉がピッタリするぐらい本を閉じさせてくれない。そうでないところは飛ばしてしまっても一向に問題ない。重要なポイント―― ローマ人の気質というか本質にかかわるエピソードは繰り返し書いてくれているので、読み落としの心配はいらない。

 それでは、このblogの読者さまに美味しいトコ取りをしていただくため、カエサル編の読み順をご紹介。西洋史の全ての時代からトラックバックを打ち込まれている巨人、ユリウス・カエサルを『楽しく』読む順番といってもいい。

塩野七生 著
  ローマ人の物語 8巻 ユリウス・カエサル ルビコン以前(上)
  ローマ人の物語 9巻 ユリウス・カエサル ルビコン以前(中)
  ローマ人の物語10巻 ユリウス・カエサル ルビコン以前(下)
  ローマ人の物語11巻 ユリウス・カエサル ルビコン以後(上)

ユリウス・カエサル著
  ガリア戦記
  内乱記

ローマ人の物語9巻結論:上記を、次の順番で読むと相乗効果を楽しめる。後を引くので、夜更かしにご注意、徹夜コースかも。
  9巻→10巻→ガリア戦記→11巻→内乱記

■ 「ガリア戦記」まで

 まず塩野本。8巻はカエサルの生い立ち~出世する前までの話なので、スッ飛ばしてOK。読みどころは著者からカエサルへの恋慕の情なので、つき合う気がないなら9巻から始めて良し。事実関係を知りたいならば、Wikipediaのガイウス・ユリウス・カエサル[参照]にある「生い立ち~政治キャリアのスタート」を読めば良いかと。

 次にカエサル本。「ガリア戦記」も「内乱記」も名著との誉れ高く、名著にありがちな小難しさ&物量は無いため、これまた自信をもってオススメできる。あの小林秀雄をして「もう一切を忘れ、一気呵成に読み了へた。それほど面白かった」と唸らしめるほど面白いと言えば伝わるだろうか。ただし、「ガリア戦記」「内乱記」とも簡潔かつ明瞭、極限まで装飾を殺ぎ落とした100%筋肉質の文章なので、とっつきにくいかもしれない

ローマ人の物語10巻 さらに、「カエサル」という一人称で全てを見通しているため、戦略・外交・諜報活動の因果関係が見えにくい。当時の勢力図や政敵との関係、文化的背景といったバックグラウンドを知っていれば、そのスゴさが分かる。外交戦であれ、戦場であれ、カエサルが打った神のような一手に背筋が凍る思いをするためには、その背景を知る必要が出てくる

 そこで塩野本の登場、9、10巻はガリア戦記を中心に、政治的・文化的な背景を補完している。当時のガリア~ローマを俯瞰するかのように書いてくれている。「物語」の名にふさわしい、いわば神の目で追いかけてくれる。そのため、「○○であることは知るよしもなかった」とか「もし△△ならば、死なずにすんだだろう」といったものすごく思わせぶりな書き方をしてくれちゃっている(読ませ上手だねッ)

ガリア戦記 すると、「ガリア戦記」が是が非でも読みたくなる。「おいおい塩野さん、あンたが自由に評するのは勝手だが、カエサル本人は何て言ってんだ?」という疑問がおさえきれなくなってくる。

 はちきれるほどの読欲を「ガリア戦記」は受け止めてくれる。塩野氏がやったように、裏読みもしたくなる。元老院への報告書の体裁を取った戦記モノを超えて、カエサル本人のためのプロパガンダとして読めてくる(で、ファンになるにちがいない)。

■ 「内乱記」まで

 ルビコン前が「ガリア戦記」なら、ルビコン後が「内乱記」だろう。「ガリア戦記」はその名の通り、ガリア遠征でのカエサルの戦いの記録であり、「内乱記」もこれまた名前どおり、カエサル vs ポンペイウスの死闘を描いた内戦の記録となる。

ローマ人の物語11巻 どちらも簡潔明瞭な文体ながら、「ガリア戦記」と「内乱記」は、書き手の気持ちが違う。ローマの外側へ拡張する意志と、内側を改革しようとする意志の違いになるのか。この「ガリア戦記」と「内乱記」を書いた意志(というか、動機)は、塩野氏が11巻でこう言い切っている

「内乱記」は「ガリア戦記」とちがい、全編を通して流れる主調音は、敵に対するカエサルの軽蔑である。憎悪も怨念も復讐心も、自分は相手よりは優れていると思えば超越できる。憎悪や怨念や復讐欲は、軽蔑に席をゆずる

 これも、本当かァ? とつぶやきながら「内乱記」を読みたくなってくる。カエサルは捕えた敵将を殺すことなく解放し、その敵将がリベンジしにくるといった、諸葛孔明と孟獲みたいなことがあったらしい。7度逃がしたかは別として、敵味方が入り乱れているので、いきなり「内乱記」を読むとわけわからなくなる。11巻で予習しておこう。

 なぜカエサルは「内乱記」を書く気になったのか。11巻で塩野氏が読み解いているが、「内乱記」そのものを読みながら再考すると面白い。

 なぜ「内乱記」を書いたのか? "あの"カエサルが後世の判定に委ねるといったしおらしいことを考えるはずがない。「ガリア戦記」ですら同時代を意識して書いている。つまり、元老院の許可なくガリアで戦争を始めたことの弁明や、執政官に立候補するためのプロパガンダの意図が透けて見える。いわんや「内乱記」をや。

内乱記 だから、この疑問は、次に置き換えると明白になるかもしれない──「なぜカエサルはルビコン川を渡って、祖国に弓を引いたのか」。市民同士が戦いあうのを避けたいと願い、あらゆる手段で平和交渉に努め、妥協と譲歩を重ねたにもかかわらず、自分の業績を無に帰しめるばかりか、名誉を陥れようとする「政敵」がいる。奴らのおかげで、盟友ポンペイウスまで敵対するようになってしまい、この内乱が勃発したのだ。だから、その責任は奴らにある、とローマ世界に訴えたいがため、ペンを取ったに違いない ――

 世界史は必修でなかったわたしが、こんな風に考えるきっかけをつくったのは、もちろん「ローマ人の物語」のおかげ。歴史家が唱える史実に囚われず、もっと自由に読んでもいい、とする塩野氏に感謝。

――――――――――――――――――――――――――――――――――
「ローマ人の物語」の読みどころ【まとめ】に戻る


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

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

 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)

« 2006年10月 | トップページ | 2006年12月 »