「アート・オブ・プロジェクトマネジメント」読書感想文（その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％の生産性向上 　　　　　　だけで平坦化してしまうのはなぜですか?

　【回答】

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

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

　本書に書いてあることは本質的なものばかり。自分で気づいて実現できているものは「何をあたりまえな」と感じるかもしれない。そうでないものは、「分かっちゃいるけど、できていない」と思うだろう。

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

■歩き回るマネジメント

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　第8章「優れた意思決定の行い方」で響いたことをまとめる。

■意思決定の重要度を決める

　何かの決定をしなければならないとき、わたしのツールは2つある。

　　・緊急度と重要度マトリックス[参照] 　　・メリットとデメリット表（D.カーネギー「道は開ける」で知った）

　言い換えると、この2つしかない。すべきことを重要度と緊急度の軸にあわせて位置付けを行い、相対的に重み付けするやりマトリックスと、あることを実行する/しないを決定する際、そのメリットとデメリットを左右に並べて評価する表の、2つ。無いよりはずっとマシだけど、いかんせん心もとない。

　本書ではもっと本質的に考え、「意思決定の際の重要度は、何を評価基準にすればよいか」という問題に対し、「7つの問いかけ」の形で答えている。先の「優れたPMは質問の達人」と一緒。ただし、問いかける先が自分であることがミソ。

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

　最重要なのは1だろ。言い換えると「いったい何を意思決定する必要があるのか? 意思決定しなければならないのは、その問題か?」になる。

　例えば、「今まで見つけた50個のバグ全てを修正している時間がない」という状況だとしても、本当の問題は「バグの優先順位付けを行う基準がない」だったりする。1はさらに、たたみかけるようにして、この問題の原因は何か? これは独立した問題か? それとも他の領域に影響を与える問題なのか? これは誰の問題なのか? …と続く。

　つまり、決めるべきことをこうした質問責めにすることで、問題をふるいにかける。しぶとく生き残ったものが真の問題で、質問に負けたものが低い優先度というように、かなり機械的にこなせそうだ。

■意思決定をふり返る（死者とドーナッツ:Death and Doughnuts）

　著者によると、意思決定のスキルを向上させる2つの方法があり、ひとつ目は実際に意思決定を行うこと、二つ目は行った意思決定をふり返ることだという。二つ目はやっていなかったナリ。

　この「ふり返り」は、戦闘機のパイロットだとデブリーフィング（debriefing）セッション、医者だと死者とドーナッツ（Death and Doughnuts）というのだそうな。手を施したが助からなかった患者について、ドーナツを食べながら議論するのが語源らしい。

　チームであれ、自らであれ、ふり返る思考をレビューするための良い質問集がある。自分のために引用しておく。

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

■メリット・デメリット表に、ひと工夫

　正式に何と呼ぶか知らないので、「メリット・デメリット表」と名付けている。本書では「長所と短所の一覧表」と訳されているが、まったく一緒。わたしはD.カーネギーで知ったけれど、ベンジャミン・フランクリンまでさかのぼるらしい。

　書き方はいたってシンプルだ。白紙（ホワイトボード/ノート）の上に、「問題」「目標」を書いて、それを成し遂げるためにすべきことを左側に羅列する。そのToDoについて、長所と短所を書きだす。こんなカンジ…

　問題：プログラムリーダーのAさんが入院した（復帰は絶望的） 　目標1.スケジュールを遅延させない2.品質を確保する

To Do候補	メリット	デメリット
機能Aの廃止
機能Bの廃止
機能Cの廃止
顧客に決定させる
何　も　し　な　い

　ポイントは、最後に「何もしない」を付け加えること。これにより、何もしないことによってどういう影響が起きるかをプラス・マイナスの両面から考える機会を得られる。

　「何もしない」ことで、問題は放置され、悪臭を放ったり迷惑をかけたりするかもしれない。その一方で、問題に取り組んだ結果、確実に失うことになる「時間」「マンパワー」を温存することができる。問題を先送りせよとは言っていない。「何もしない」選択肢も考慮に入れた上で、問題に取り組め、ということだ。学校教育の影響で、解答欄には必ず何か書かなければいけないと思っていると、強力な選択肢「何もしない」を忘れてしまうかもしれない。

　本当に「何もしない」かどうかは置いといて、選択肢に含めて考えてみてはいかが。

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

　夢中本として一気読み。文庫版で8巻、9巻、10巻と息つくヒマなし。

　インテリに手厳しい塩野節も嫌味にならない程度に抑制されている… というのも、塩野氏がだいすきなユリウス・カエサルの話だから。書くほうも夢中になって書いたであろうと。

　「自称」シロウトの塩野氏が好きで書いているのだから、彼女の趣味が爆発している。この巻に至るまで、好き/キライが人物描写の端々に現れていて微笑ましかったのが、ユリウス・カエサルになると俄然筆致が変わっている。やっぱ出来た男より惚れた男だな ── 要するに、とてつもなく面白くなっている、ってぇことだ。

　サブタイトルの通り、カエサルがルビコン川を渡るまでの物語。ルビコン渡河までは、さらに二つに分かれている。「ガリアの前」の8巻と、「ガリア戦記」の9、10巻の構成だな。だから、面白いところだけ読みたいなら、いきなり9巻から手をつけてもいい。

■ガリアの前

　ガリアの前、つまりガリア戦記の前のカエサルは、とてつもない浪費家だったそうな。最終的に国家予算級に至った借金の理由として、愛人たちのプレゼント代があるそうだ。自ら選んだ高額な品を女たちに贈るので評判だったらしい。その甲斐もあってか、カエサルは女にかなりモテたらしい。しかし、モテた理由として高額なプレゼントは必ずしもあたらない。なぜなら、と著者は想像する…

　カエサルは、モテるために贈物をしたのでなく、喜んでもらいたいがために贈ったのではないか。女とはモテたいがために贈物をする男と、喜んでもらいたい一念で贈物をする男の違いを、敏感に察するものである（8巻p.124）

　塩野氏からのメッセージ「男たちへ」を髣髴とさせる一文だな。ちなみに「男たちへ」はオンナゴコロが分からない男ども（わたしを含む）にとって、女を理解するための最高文献だと断言しよう。男であれ、女であれ、「女の気持ちは男には絶対に分からない」と平気で口にする前に、本書を手にしてみればいかが? と思える名著ナリ。

　また、ローマを手中にするぐらいの権力者となったカエサルも、愛人と正妻をめぐってのスキャンダルにまみれていない（らしい）。なぜか、ここでも塩婆の筆致は鋭い。

　史実による限り、どうやらカエサルは、次々とモノにした女たちの誰一人とも、決定的には切らなかったのではないかと思われる。つまり、関係を清算しなかったのではないかと。（中略）例えば、妻同伴のカエサルが夜会の席か何かで以前の愛人と顔をあわせたとする。同じ階級に属しているのだから、出会う確率も高かったはずである。そのような場合、並みの男であれば、困ったと思うあまり、意に反して知らん顔で通り過ぎたりする。ところがカエサルだと、そうはしない。妻には、少し待ってとか言い、どうなることやらと衆人が見守る中を堂々と以前の愛人に近づき、その手をやさしく取って問いかける。「どう、変わりない?」とか。女は無視されるのは何よりも傷つくのだ（8巻p.209）

　太字化はわたし。なにか辛い思い出でもあったのだろうかと拝察。「男たちへ」にも男遍歴がにじみ出ているが、彼女の男性観が辛辣であればあるほど、カエサルというスーパースターへの思慕がくっきりと見えてて面白い。

■ガリア戦記

　もちろんこれはスゴ本。2000年前に書かれたにもかかわらず、今でも文庫で改版を重ねている、という事実ひとつとっても、いかに凄い本か分かるだろう。元老院へのレポートの体裁を取っているが、ガリアの地へ攻め込んだ将から見たドキュメンタリーとしても読める。

　ただ、一点ひっかかるところがある。一人称の"レポート"であるにもかかわらず、「わたし」の代わりに「カエサル」と三人称で記述している。慣れればなんということもないけれど、なぜそんなことを書いているか分からなかった。

　わたしなんかが評するよりも、キケロと小林秀雄がこうレビューしている。以下、「ローマ人の物語」から孫引き。

キケロ（前51年記）

　これらの巻は全て、裸体であり純粋であり、人間が身につける衣服にも似たレトリックを、完全に脱ぎ捨てたところに生まれる魅力にあふれている。カエサルは、歴史を書こうとする者に史料を提供するつもりで書いたのかもしれないが、その恩恵に浴せるのは、諸々のことをくっつけて飾り立てた歴史を書く馬鹿者だけで、思慮深く賢明な人々には、書く意欲を失わせてしまうことになった

小林秀雄（後1942年記）

　ジュリアス・シイザアに「ガリア戦記」といふものがあるのは承知してゐたが、最近、近山近次氏の翻訳が出たので、初めて、この有名な戦記が通読できた。少し許り読み進むと、もう一切を忘れ、一気呵成に読み了へた。それほど面白かった。といふより、もつと正確に言ふと、ただ単にロオマの軍隊が、中途で休んでくれなかつたが為である。勿論、別して読後感といふ様な小うるさいものも浮かばず、充ち足りた気持ちになつた。近頃、珍しく理想的な文学鑑賞をしたわけである

　太字化はわたし。夢中本、一気本、徹夜本、スゴ本、のあらゆるラベルで賞賛してよし。間違いなく面白い本として強力にオススメできるが、ここである問題が生じてくる。

　それは、カエサル著「ガリア戦記」と、塩野七生著「ローマ人の物語　ユリウス・カエサル編」と、どちらを先に読むか、という嬉しい問題のこと。いわゆる「読んでから見るか見てから読むか」に近いかも。

　前者は一人称で描いたガリア戦記。簡潔、明晰かつ洗練された文体で書かれたラテン散文の傑作といわれている。史書として一級品なだけでなく、面白い本としても一級品。

　後者は、いわば「神の目」で見たガリア戦記になる。「神の目」だから、敵方の動向だけでなく、カエサルの戦略の真相へ想像が至ったり、「そのころローマでは…」から始まる政敵のきな臭い動きが語られたり、そうはさせじとカエサルの長い手の話が語られたり… 眠れぬ夜を保証しよう。

　わたしの場合、カエサル→塩野の順番だった。塩野本のおかげで、より複眼的に背景を知ることができた。しかし、いきなり「ガリア戦記」に取り組むと、その簡素さ（というか素っ気の無さ）にとまどうかもしれない。だから、塩野本でウォーミングアップするというテもある（文庫8巻では、ガリアに行く前の話から書き起こしているからね）。反面、激しくネタバレになってしまう、というデメリットがつきまとう。

　ユリウス・カエサルの頭の中には、「ガリア戦記」が地理上の記述ではじまっているのが象徴するかのように、当時知りうる限りの正確なガリアの地勢がインプットされていたのではないかと思う。中部ガリアという将棋盤を前に、相手の手を読む確かさは、彼に、持てる力の効率的な運用を可能にした（10巻p.82）

　叙述は正確を期した。自らの誤りも正直に記し、敵側の理由も公正に記述した。カエサルは、正確に書くことこそ自分の考えをより充分に理解してもらえる、最良の手段であると知っていたからである。意識的な嘘が一つでもあれば、読者は他のすべてを信用しなくなるからだ。また、自分を一人称単数で語らず、カエサルと三人称単数で記していることも、叙述に客観性をもたせたいとする彼の意図に基づいていた（10巻p.147）

　カエサルの鬼神のごとき軍略の秘密が明かされている。さらに、「ガリア戦記」の主語がなぜ「カエサル」なのかという謎に答えている。このように、「ガリア戦記」を読んで疑問に思ってたことが次々と「塩野史観」によって解明されてゆくのは、読んでて心地よい（ホントかどうかは、別として）。塩野氏による新訳「ガリア戦記」を激しく希望！

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

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

■仕様書など書く必要がないと信じているプログラマ

　第7章「優れた仕様書の記述」は、こんな一文から始まる―― 「私は昔、仕様書など書く必要がないと信じているプログラマと議論したことがあります」―― 議論の顛末は予想通り。おそらく、このblogを読んでいる全員がこの話をしたことがあるに違いない。各人がどういう結論を持っていようとも、本章から新たな気づきが得られるはずだ。

　なぜなら、「優れた仕様書とは何か?」について徹底的に考え・実践してきたことが記されているから。目の前の仕事にとって仕様書が必須/邪魔の話をしているのではなく、もっと本質的なことが書いてある。コードから仕様書を生成するツールとか、仕様書を書く上でのテクニック集といったものは、無い。根っこの部分「そもそもプロジェクトにおける仕様書の目的は?」とか「仕様書によってできること/できないことは何か?」について非常に明解に応えている。

　では、プロジェクトにおける仕様書の目的は何か?

1. 正しいものの構築を保証する
2. プロジェクトの計画フェーズを締めくくるマイルストーンを提供する
3. プロジェクトの過程で踏み込んだレビューや各個人からのフィードバックを可能にする

　「それなら○○で代替できるじゃねぇか?」というツッコミは可能だ。しかし、著者は続けてこう記している―― こういったことは非常に重要であり、仕様書作成以外のプロセスでその全てを同時に実現することは難しいのです。私が仕様書作成を指示している最大の理由はここにあります ――（太字化は、わたし）

■何をもって「正しい」とするのか（わたしの場合）

　仕様書をどのように考えているかは、各人の仕様書にまつわる思い出したくも無い経験に基づくだろう。わたしの場合は1.だ。曖昧な資料で質問はのらりくらりとかわし、イザとなれば独自解釈でねじ曲げてくるオレオレ仕様に泣かされた黒歴史があった。

　その結果、仕様をフリーハンドにさせてはいけないという理由で、仕様書を重視している。ただし、カンペキに精緻なものである必要はなく（そんな時間はない）、軽重をつけている。どこに重点をおくか? それは、「正しい」ものを保証させる必要があるもの。後々「正しさ」が議論されるようなところ。

　例えば、状態遷移、インタフェース（システムの境界）、ロール（の定義）、業務エラーの定義（エラーの場合の業務フロー）あたりが、後々「言った/言わない」「正しい/正しくない」で戦いになっている。画面の紙芝居なんかよりも、このあたりをエビデンス化しておかないと泣きをみる。

　また、仕様書として含めるかどうかは立場によるが、性能保証、品質保証関連は、名前はともあれ必ず書き起こしている。そのパフォーマンスを何をもって保証しているのか? にかかわるところは、よくちゃぶ台返されるから。大切なのは、ちゃぶ台を返したんだよ、という事実を見える化すること。エビデンスがないと、ひっくり返される「ちゃぶ台」が存在しないことになる　→　つまり、インパクトがでかいにも関わらず顧客のフリーハンドになるからだ。

■仕様書について犯す最大の過ち

　それはレビューとフィードバック。仕様書について誤った考え方が間違ったレビュー・フィードバックの場を提供し、結果うんこ仕様書を量産することになる。

　仕様書について人々が犯す最大の過ちは、公式のレビュー会議を開催するまで内容のフィードバックを得ようとしないことです。レビューは確認と洗練を行うための場であり、たたき台の検討と最終決定を同時に行うための場ではありません

　レビューの場が読書会になったり、誰かの独演会（お伺い会?）となったりするのは、ひとえにPMの責任だろう。少なくとも事前に一読を要求することで、通して読めば分かるような質問としてきたり、重箱の隅をつつくような事態にはならない。つまり、最初の数ページに時間をかけすぎて、後は駆け足になるようなこともなくなるはずだ。

　どれぐらい公的な場にするかは企業風土によるが、どこまでフィードバックを得るべきかはPMがどれぐらい準備しておくかによる。著者はこうも述べている―― 「優れた仕様書は、シンプルです。仕様書とは本来、コミュニケーションの一形態なのです」

　さて、冒頭の仕様書不要論をぶったプログラマと本書の著者が至った結論は次の通り。

　何らかのドキュメントによって、チームが抱える本当の問題を解決でき、開発プロセスを加速させ、品質の高い成果物を生み出せる可能性を高めることができる（そしてチームを混乱させることなく改訂できる）のであれば、そのドキュメントが何と呼ばれようとも、どのようなレイアウトであろうと喜んで使うと言ってくれました。その後、私は上司のところに戻り、彼との議論をかいつまんで説明し、了解を取り付けました。六法全書のような厚さがあった仕様書のひな形は、お払い箱となったのです。

　ん、わたしも同意。問題はドキュメントにあるのではなく、ドキュメントありきにするプロセスにある。

火事になる前に読んでおきたい「火事場プロジェクトの法則」

　問題プロジェクト・失敗プロジェクト・デスマプロジェクト ── 呼び名は沢山あれど、振り返ったとき、ああすればよかった、こうすればよかったという反省や後悔（?）は、これまた沢山ある。

　「あの営業連中のコトバを鵜呑みにしなければ…」
　「新技術に手を出す範囲を限定しておけばよかった」
　「もっと顧客に張り付いて仕様を搾り出しておくべきだった」
　「なんであのとき、SOSをださなかったのか！なんで問題を放置したんだ！」
　…

　過去のプロジェクトを眺めたとき、問題点はいくらでも出てくる。おそらく携わった人の数だけ出てくるだろう。

　それにもかかわらず、これから出くわしたとき、どうすればよいかは、分からない。なぜなら、どんな問題に遭遇するか分からないから。プロジェクトが特殊性、一時性をもつように、それにまつわる問題も同様に、特殊性をもつ。したがって、その解決策は、常にその問題専用の解法でしかない ──

　── これは、本当だろうか?

　確かに、プロセス、方式、メンバー、リソース、ビジネス環境によって問題の原因は違って見えるかもしれない。しかし、実際にシステム開発プロジェクトが破綻するとき、どこかで見たような/聞いたような/読んだようなスメルを放つのはなぜだろうか? それは、プロジェクトで顕在化する問題は人に因るからだ。

　システムは人がつくるもの。だから、システム開発の問題は、人の問題。これは、デマルコ著「デッドライン」[参照]で気づかされたが、本書ではもっと体系立てて、4つの切り口で捉えている。

　　・バードビュー（鳥瞰・俯瞰）
　　・コミュニケーション（情報と意思の伝達）
　　・エモーション（相手を思いやる気持ち）
　　・フィードバック（後悔でなく反省）

　この4つの視点から、プロジェクト失敗の症状と原因を見通している。ともすると、どれかに拘泥しがちだが、バランスよく配分されている。この視点を使えば、PMだけでなく、誰でもプロジェクトのヘルスチェックができ、症状の裏側にある本当の原因を探ることができる。

　さらに、「人の問題」とした瞬間、誰か（安請合営業、無理難題顧客、無能上司、技術馬鹿）を悪者にしてしまえば済む、という落とし穴が待っている。しかし、本書では「誰か」を探して非難するよりも、まず自分ができることは何か? を問いかける。この姿勢は見習いたい、というか見習うべき（→わたし）。

　デスマ対策を謳った書籍は多かれど、開発現場の視点からここまで明快に解き明かした本はないだろう。失敗プロジェクトから「脱出」したり、「間違いだらけ」と論評したりする本は、それなりに参考になるものの、「ボクのせいじゃないモン」という言い訳がこうばしい。その一方で、本書からは「人の問題」≒「それは自分の問題かもしれない」と謙虚に向き合おうとしている。

　プロジェクトが火に包まれるとき、本どころではない。寝る時間どころか、うんこしている時間すらないんだぜ！だから、そうなる前に読んでおきたい。仕事に追い詰められると、正気が保てなくなる。「おまえのバグだゴルア！」と殴りあうこともある（わたしじゃないよ！）、あるいは、「わびるならそこで死んでみろ！」と顧客に罵倒されることもある（わたしじゃないよ！）。悪臭にまみれて殺伐とした中、くじけそうなとき、本書は心の支えになってくれるかもしれない。根性論は禁物なんだけど、再読することで勇気がわいてくるかも。

　… というわけで、いまのうちに読むのが吉。

嫁とKanon

　結論：結婚のおかげで、より深く自分を知ることができる。ただし、カミングアウトは離婚されない程度に留めておきたい。つまり、ヲタ趣味はほどほどにってこった。

　自分の嗜好についてこれほどセキララに暴かれているのは、結婚という場においてのみ。自室どころか、居場所は座布団の上でしかないリーマンパパにとって、プライベートな空間なんて、あるはずがない。

　二人暮らしのときは嫁さんが、子どもができると子どもが、いつもくっつきたがるので、うっかりエロ本なんて見てられない。やれやれ寝静まったとエロビデオを見てたら嫁に見つかった ―― なんて微笑ましい話では断じてない。深夜 25:00 、コソーリ点けて「おおっ」「うわっ」「さすが京アニ」と感嘆符をまき散らしながら鑑賞していると、いきなりドアが開いて、

「何やってんの?」

　詰問口調の嫁（←てっきりエッチビデオだと思ったらしい）

　精神的にはズボン半分おろしている状態だったので、人生史上かつてないほど慌てふためくわたしを軽く睨むと、嫁さんの目線はテレビへ。

　　　　　　　♪足元に風～ 光が～舞った～

「何コレ?」

　　　　　　　日常にだけ～積もったぶんの奇跡が～♪

… あ、アニメ

（盛大なため息をついた後）「もう遅いから寝なさい」

… はい

　リモコンを手にする。100メートルを35秒で全力疾走するあゆの勇姿が消える。さぞかし怒られるだろうかと首をすくめていると、何も言わずに寝入っている。

　翌日、子どもが寝静まって嫁さんと二人のときに、再生する。バレたからにはもういいや、という気持ちがあったのかもしれない。で、嫁さんの感想 ――

• これはあなた好みではない
• どうせ女の子が病気になるか死ぬかするんでしょ（←観鈴ちん）
• あんたの好みは、気が強くってツンツンした女の子でしょ（←ハルヒ様）
• プリキュアなら右のほうでしょ（←ほのか嬢、および舞ちゃん）
• こんなタレ目のふわふわしたアニメは好みじゃないでしょ（い、いや、それは違う…後半は怒涛の展開となるぞ）

… よく把握しておられます、さすがです。

　ああ、どうしてこんなアホだんなと一緒になってしまったんだろう… とブツブツ言い出す。いいじゃん、オレが幸せなんだからというと、光速で睨まれる。

　しかし、嫁さんは気づいていないのだろうか? もちろん笑ってる顔が一番だが、二番目にかわいいのは、軽く睨んだ猫目であることに。オレはこの目に陥落したんだと告白してもふざけていると受け取られるので、沈黙は金。

　惚気さておき、ただいま完全に名雪モード。第1話だけで9回くり返し観ている。さすが京アニ、恐ろしいまでのクオリティ。あの"止め絵"に命が吹き込まれていると思ってくれてよろし。最大の心配「アゴ」は杞憂であったことに胸をなでおろす（前作は酷かったね）。

　名雪とあゆの分岐をどう折り合いをつけるかが、次の心配。遙と水月のように、どちらかを選ぶことは、もう一方は選ばれなかったエンディングへ向かうことになる。思い出せ、ここでは等価交換の原則が適用されるのだ→「何かを得るためには同等の代価が必要になる」

　あるいは、等価交換の原則は視聴者に適用されるのかもしれない。脳裏をよぎった売り方は、あのね商法。

　　1. 全員分のストーリーを個別シナリオの分岐点まで放映
　　2. 個別のシナリオへは、それぞれDVDを買って頂戴

あるいは、

　　1. 名雪シナリオをメインに放映（前作の名雪は不憫すぎる）
　　2. あゆのシナリオは、それぞれDVDを買って頂戴

　とりあえず、ひとさし指をたてて小首をかしげながら、「…だよっ」とする名雪は脳内嫁に決定だぁっと心の中でケモノのように叫ぶ―― リアル嫁が浴びせる鋼の視線のもと、小動物のようにぶるぶると震えながら。

　そういや嫁さんが言っていた、

この舞台は、富山市だねー

　な、なぜ分かる?

路面電車とか街の雰囲気とか、街を見下ろすような場所があるとか

　いや、違う、今回の聖地は、札幌ナリ。なまら語が出てくるかとヒヤヒヤしながら観ている。期待・出来・満足感を全て充足しているのは、EVA以来。さすが、20世紀のガイナックス、21世紀の京アニと言われるだけある。

「いい親」が子どもをダメにする

　何をもって「いい親」とするかによるが、センセーショナルなサブタイトルにもかかわらず、著者の言い分はかなり同意できた。

　はやりの育児法を鵜呑みにして、子どもとトモダチになろうとする親がいる。そもそも育児書なんか読み漁ってないで、周囲（特に自分の両親）に相談しなさい、と主張する。著者はかなりのご年配であることを念頭に読むといいかも。

　最初に強く頷いた箇所はここ↓

　全ての基本は夫婦の関係。（理想的には）夫婦が互いに信頼しあい、愛し合っている家庭であることが、子育ての最初の一歩。もちろん事情により片親の場合もあるが、それではダメということではない。「理想的には」を頭につけたのはそのため

　「子どもへのまなざし」[参照]で知ったが、子どもを家庭の中心に据えて、両親が子どもに寄りかかっている、いびつな関係がある。

　それは、子どものことを一生懸命に考えすぎた母親が陥る罠だそうな。わが身を犠牲にすることが、あるべき子育てだという観念に囚われて、結婚生活そのものを犠牲にした結果、子どもの巣立ち同時に人生の意味を見失う ―― 「空の巣症候群」という。子どもが巣立った直後の離婚率が高いのも頷ける。

　次に強く頷いた箇所はここ↓一歩間違えると「地雷」だけれど、このテーマはわたしも嫁さんと何度も話し合った。

　両親共に外で働くことを決意し、子どもを保育所へ入れることによって、家族の力は弱まる。親も子も無用なストレスにさらされることになる。共働きの理由にお金が挙げられるが、正当な理由でなくなりつつある。というのも、妻の収入のほとんどは、世帯にかかる課税率の上昇（妻の収入を加えることによって、世帯の課税区分が上階層へランクアップする）、保育費、医療費、被服費、交通費、そして食費の増加（共働きの家庭では、夫婦のどちらかいっぽうしか働いていない家庭に比べて、外食の機会がかなり多くなる）によって、ほとんど消えていく

　共働きによる収入増と、それにともなう精神的・肉体的な負担を天秤にかける。「共働きなら収入は倍」なんて甘いこと考えていたのは、もう何年前になるだろうか。世帯への課税率の上昇はまさに「ランクアップ」というべきで、思わず目を見張る毟りよう。国は違えども現実は一緒ってことか。

　さらに激しく頷いたのは、ここ↓「しつけ」についてお悩みの方は、ぜひ第2章を読むべし。

　しつけとは何か。流行の子育て法を推進する人が書いた本を読みすぎた親たちは、しつけの成功の鍵は、適切な手立てを選んでうまく使えるかどうか──つまり、しつけとは技術であると思い込んでおり、犬猫のブリーディングと同様の「テクニック」でもってうまくいくものだと考えている

　しつけの最初の一歩は、トイレトレーニングだったり、食卓での振る舞いだったりするため、畜生のしつけと子どものしつけを同一視する親が出てくる。本書はもう少し成長した幼児～児童に対し、「自分の感情をコントロールする」「礼儀正しく振舞う」「出されたものは文句をいわずに食べる」ことを、どうやって身に付けさせるかが書いてある。読めば、「うまくしつけができなくて困っている」「どうやってしつけてよいか分からない」といった悩みそのものが本質的に誤っていることが分かる。

　さらに続けて、しつけの上手な親の例を挙げている。今から数年間、わたしは以下をくり返し読んで忘れないようにしないと。

　子どもをコントロールしようとしたら、必ず失敗する。そもそも、子どもを思い通りにすることなんて不可能なことだから。しつけの上手な親は、子どもをコントロールすることはせず、自分にできること、すなわち子どもとの関係をコントロールしようとする

　子どもは物事の必要性と自分の欲求を混同しやすいため、子どもに何が必要で何が必要でないかは、親が決める。親は子どもにとって必要なものを、子どもが望んでいるかどうかに関係なく、すべて提供し、いっぽうで、子どもがどんなに必要だと主張しても、親の判断に合わなければ、わずかしか提供しない。子どもとの関係をコントロールするために親が決めることは、次のようなこと

• 親が子どものために何をし、何をしないか。たとえば、子どもの宿題のうち、どんなことなら手伝い、どの程度まで手伝うか
• 物質的な面で、子どもに何を与え、何を与えないか。つまり、子どもの生活水準を決定するということ。それは必ずしも親の生活水準と同じである必要はない
• 家の中で、子どもが従うべき規則。たとえば、何時に就寝し、夕食に何を食べるか、どんなお手伝いをするかなど
• 子どもが悪いことをしときに、どんな罰をどのように与えるか

　最後に。著者に言わせると、わたしもしばしば、子育ての目的を忘れてしまう親の一人らしい。子育ての本当の目的は、子どもを大人に育て上げることだ。わたし自身、自分育てだとか共育とかヌルいことを言っていたことがあった。しかし、ゴールを忘れてはいけない。わが子がこの社会で生きていけるよう、ちゃんとした大人として独立して生きていけるようにすることが、わたしの親としての役目なんだねッ。

　… ここで、その最終目的を忘れてしまった親に育てられて成人したブーメランキッズの話題にしてもいいけれど、今宵はここまでにしとうございます。

• 子育ての基本原則その一　――子ども第一ではなく家族第一(何が一番かをはっきりさせる)
• 子育ての基本原則その二　――しつけに必要なのは、罰ではなくコミュニケーション。信頼関係を結ぶことではなくリーダーシップ
• 子育ての基本原則その三　――子育てとは人を大切にする心を育てること。自尊心を育てることではない
• 子育ての基本原則その四　――大切なのは礼儀を教えること。技術を習得させることではない
• 子育ての基本原則その五　――大切なのは責任感を育てること。よい成績をとらせることではない

箱

　復刊されますた（via:揮発性メモ）。いやー、めでたい。原題が "LEADERSHIP AND SELF-DECEPTION / GETTING OUT OF THE BOX" で、訳者が同じ人なので、「箱 ―― Getting Out Of The Box」と中身は一緒のはず。

　本書は、巷に数多にあふれている自己啓発本のタネ本。成功本における「地上最強の商人」や「道は開ける」であったり、マーケティング・交渉術における「影響力の武器」と一緒。新刊出しては印税稼ぐ人は、これらの種本をネタにして、せっせと今風の味付けをするという仕掛け。味付けが違うだけの新刊をたくさん読むくらいなら、原液をそのまま読んだ方がずっと効く。

　永らく絶版状態となっており、せどらーどもの暗躍を見るにつけ（中古価格 8,000円！）、苦々しく思っていたけれど、ようやく定価で買える。本屋にあほほど積んである啓発本は、本書の二番煎じ三番煎じと思ってよし。これからは大声で言える、そいつ読むならコレ読めよ！ってね。

　本書はまなめさんのおかげで出会うことができ、2005年のNo.1スゴ本、いいや、わたしの考え方をグルりと変えてしまった凄まじい一冊となった。

　わたしの感想は[ここ]、ネタバレ抜きで書いてある。「自分がいかに自分自身にウソをついて生きてきたか」が、ものすごく明解に理解できる。それだけでなく、そこ（箱）から脱出するシンプル＆パワフルな方法を身につけることができる。

　素直に読んで、自分につく嘘 ―― 自己欺瞞の罠（箱）に気づいた瞬間、目の前がガラッと砕け散るかも（碇シンジ君の『ボクはここに居てもいいんだ！』のようなやつ）。高額な自己啓発セミナーを受けるよりは、本書を読むほうがよっぽど投資効果が高いナリ。amazon紹介文は以下のとおり。

　身の周りの人間関係は実はすべて自分が原因で引き起こしていることに気づかせてくれる『自分の小さな「箱」から脱出する方法』。本書を読み進めるうちに家庭や職場での人間関係を深め十分な成果を出せる環境を作る方法を学べる

ローマ人の物語III 「勝者の混迷」の読みどころ

　勢いのある「ハンニバル戦記」から一転、あれほど著者が忌避した世界史の教科書のような停滞ぶり。ポエニ戦役を勝ち抜いた後、ローマに訪れた内紛と混迷の時期がだらだらと書かれている。

　好き嫌いが激しいのか、ローマ史上では超重要な人物、マリウス、スッラ、ポンペイウスの書き込みは淡々としており、著者の思い入れはさしてないことが分かる。分かりやすい書き手なので安心して読める。この調子だと、カエサルは弾けるんじゃないだろうかと予想する（←的中！）。

　「勝者の混迷」の読みどころは、出来事の分析ではなく、塩婆史観を愉しむところにある。つまり、"自称"シロウトの「～ではないか」「もし～ならば」から、ローマだけでなく、それを語る人をどう評価しようとしているのかを推理するワケだ。このへん↓が、たいへん面白かった。

■ローマ人と義理人情（文庫版6巻p.167）

　ローマ人が創り出した法の概念と、義理人情は矛盾するではないかといわれそうだが、私の考えでは、思うほどは矛盾しない。法律とは、厳正に施行しようとすればするほど人間性の間に摩擦を起こしやすいものだが、それを防ぐ潤滑油の役割を果たすのが、いわゆる義理人情ではないかと考える。法の概念を打ち立てたローマ人だからこそ、潤滑油の重要性も理解できたのではないか。

　マリウス、スッラ、そしてポンペイウスもカエサルも、義理人情の重要性を理解した男たちであった。彼らと兵士たちとの関係を、近現代のほとんどの研究者たちが「私兵化」であると一刀両断して済ませるのは、その人々が人間関係における義理人情の重要さを解さない、いや解そうともしない欧米のインテリだからである

■ローマ人と奴隷（文庫版7巻p.103）

　はじめに断っておかねばならないが、イエス・キリストは、人間は「神」の前に平等であると言ったが、彼とは「神」を共有しない人間でも平等であるとは言ってくれていない。それゆえ、従来の歴史観では、古代よりは進歩しているはずの中世からはじまるキリスト教文明も、奴隷制度の全廃はしていない。キリスト教を信ずる者の奴隷化を、禁止したにすぎない。だから、ユダヤ教信者を強制収容所に閉じ込めるのは人道的には非でも、キリスト教的には、完全に非である、と言い切ることはできない。アウシュヴィッツの門の上にかかげられてあったように、キリスト教を信じないために自由でない精神を、労働できたえることで自由にするという理屈も成り立たないではないからである

　「欧米のインテリ」たちによっぽど酷い目にあったのか、目の仇にしている。現代にいたるまでの史家たちの積み重ねによって、今わたしたちの手に残っているのだから、もう少し謙虚になってもいいじゃないかと。そうした歴史家たちをまとめてバッサリ斬っているところは、小気味いいと感じるより不気味思えてくる。

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

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

■優れたPMは質問の達人

　筆者は「優れた質問は優れたアイディアを惹きつける」という。では、優れた質問とは何か? ここでは5章で紹介される、アイディアを生み出す方法から、「質問」に焦点を絞って考察する。

1. 焦点合わせの質問
2. 創造的な質問
3. 修辞的な質問

　まず「焦点合わせの質問」から。プロジェクトのどんなフェーズであろうとも、質問者が誰であろうとも、最もパワフルな質問がある。わたし自身、ミーティングで必ずする質問。自問も含めると、一日に何回、この質問をすることやら。その「質問」は、反転表示で以下に記す。ドラッグの前に、ちょっと考えてみて欲しい↓

　解決しようとしているのは、どのような問題なのだろうか?

　仕様書の記法について議論しているときも、不具合の正体を見極めようとしているときも、「問題の本質を定義しなおす」行為は、ホウレンソウ並に基本動作となっている。ものすごく重要なので、わたしの手帳の第一ページ目に大書きしてある（ちなみに次の行には、「頭にキたときは、呼吸することを思い出せ」と書いてある）。

　なぜなら、皆の注意を議論の本質へ向ける唯一の質問だからだ。ともすると、表層に拘泥し、因果関係や責任論の不毛地帯へ迷い込むことがある（とってもしばしば！）。事実関係や各人の思いはよく分かり、議論が深まった気分になるが、穴を掘る場所が違っていたら目も当てられない。この罠から逃れるための質問が↑のやつ。

　例えば、システムの不具合の場合を考えてみる。解決しようとしているのが、以下のどれかによって、議論はずいぶん違ってくるだろう。

• 不具合の事象そのもの
• 不具合の原因
• データ汚染部位の除去
• 不具合の再発防止
• 責任所在の追及とオトシマエ
• 追加費用の手当て
• 対策のスケジュール調整

　こいつをいっぺんに語ろうとするから収拾がつかなくなる。いちどに一つずつ、問題の定義を行いながら段階を踏むことで、驚くほど効率的に進めることができる。優れた質問は、議論の触媒となる。だから、「ちょっとマテ、今すぐ決めなきゃいけないのは、データ汚染範囲を拡大させないようにする方法じゃなかったっけ?」と具体的に振ってもOK。あるいは、「○○とは、結局△△のことですね?」と焦点を言い替えるのも良い。"って結局"メソッドは質問のフリをした議論の軌道修正テクでもあるし。

　次の「創造的な質問」は、ちょっと思い浮かばなかった。著者は、「創造的な質問とは正反対に、今まで考慮の対象となっていなかったものの、探求すべき方向を指摘する質問」と述べている。わたしの経験と照らし合わせても、こうした質問はしてこなかったため、自信を持って紹介できない。興味のある方は本書を読んで欲しい。

　最後の「修辞的な質問」―― これは邪悪な質問だという。どう邪悪かというと、次の例を見て欲しい。

• おいおい、私の話はそんなに退屈か?
• バグとか不具合とか、表現のしかたがそんなに気になるかね?
• あっはっはっは、どこへ行こうというのかね?
• 左舷、弾幕薄いよ、なにやってんの!?

　これらは、質問の形をした非難や嘲笑であるため、最も避けるべきだという。質問者の意図ばかりに注意がいってしまい、考えるべき焦点がおろそかになる。このテの質問が、いかに相手を傷つけるかは、子どもができて初めて分かった。今までどれほど酷いこと言ってきたか、恥ずかしいなり。家庭でも職場でも、修辞的な質問を避けるよう、ものすごく気を使っている。

■「見える」懸案一覧は強力なツール

　激しく同意。著者は、仕様書作成フェーズやや、イテレーションの端境期で使っているようだ。懸案一覧のTipsは次の通り。

• 懸案事項とは、意思決定を行う、もしくは答えを見つける必要があるものとして洗い出されたものの、まだ手をつけられていない項目のこと
• 懸案事項の一覧は、本質的には疑問の一覧
• 行う必要のある全てのことが、優先順位付けされていなければならない
• ホワイトボードが望ましい。ウェブサイトで公開すると、まず見てくれない
• 誰かがオフィスにやってきて、進捗状況を尋ねた場合、傍らのホワイトボードの一覧を指差して「あればまさに状況をあらわしています。あの一覧から項目が全てなくなれば、仕様書作成を完了することができます」←【超重要】

　この詳しいテクニックは、6.7「懸案事項の一覧」から学び取ることが出来る。同じことをここで書いても意味がないので、ここでは、わたしが最も使う（使ってきた）懸案事項一覧について述べる。

　それは「課題管理表」と呼んでいる。一緒じゃんという莫れ、懸案を優先順位別に並べたものとは一味違うなり。必用なのは、複数のホワイトボードと書記役の若手数名。

　いわゆる懸案一覧と最も違うのは、アタマに「問題」が付くところ。「サーバ初号機のレスポンス性能問題を解決する」とか「リリース直後のトラブル対応」といった"お題"がある。

　そして、その「問題」を課題へブレークダウンしていくわけ。必ずしもロジックツリーの形をとっていなくてもいいが、個々の課題の総体が問題の全体となるようことに気を配る←つまり、モレヌケがないか見張る。

　課題はたいてい、不具合の形をとる。故障票からの転記/お客さまご指摘/現場からの問い合わせを簡潔に記し、課題を担当する人・チーム、解決までの期限、クリア条件を記す。クリア条件とは、「その課題が解決したことをどうやって知るのか/測るのか/分かるのか」のこと。

• 今発見された不具合
• 仕様モレだとわかった事象
• 実装されていない仕様（理由はともかく）
• 次のリリースで回復する（はずの）バグのうち、知らされていないもの
• この期に及んで顧客が言い出した「あるべき姿」
• 未確定のバグ

　課題（直すべき内容や不具合）は書けるが、担当が書けない場合は、その課題をさらにブレークダウンする必要がある。あるいは、期限が書けない場合は、「いつまでにこの期限を決める」を書く。あるいは、期限を決めるために必要な作業/議論/情報を書く。

　そうしておいて、各個撃破していくわけだ。全ての課題をクリアすれば、元の問題は解決するはず。ファーストインのスタック形式だから、優先順位別にソートしない（できない）。だから重要度別に朱色を使ったりポストイットで"修飾"する。

　課題をホワイトボードにまとめる最大の理由は、「問題を問題化する」ことにある。問題を、コレ、と指差すことができる。非常によくあることだが、問題は、それを抱える人と同一視される場合が多い。あるいは、その問題について詳しく説明できる人や、その問題を伝えてきた人のものとして白眼視される。これまで、何人のプログラマが「当事者」として扱われてきたことか。事象の本質から分かっている分、自分のせいでもない不具合の原因を自分が書いたプログラムで対応させられたりする（自分の分は仕様どおりであるにもかかわらず！）。

　これを回避するために、問題をホワイトボードに「転記」する。問題があるというとき、その場所を指差すのが人からボードに移るわけだ。つまり

you vs me

の人対人の対決から、次のようにする。

problem to us ( you and me )

その「問題」は、ホワイトボードに全部書いてあるというわけ。

　火を噴くプロジェクトに落下傘部隊よろしく投下されたとき、わたしが最初にすることは、この課題一覧を作ること。問題は目に見えているが、課題は断片化されている。各人の頭の中や仕様書に書いたメモ、共有されていないメールにバラバラになっていて、おのおのそいつを抱えて走り回っている（あるいは走りつかれている）。それを、「ここさえ見ればその問題の全てが囲い込まれている」に注目させる。

　その結果、おのずと問題を抱える人や、解決のアイディアが出せる人が、そのボードの前に集まってくる。

　あとは書記役が不在にならないように交代させながら、24時間体制でこのボードをメンテナンスする。これにより、すくなくともこのプロジェクトが何を問題としており、どうやって対処しようとしているかがリアルタイムで分かるようになる。困憊したらボードの傍らにダンボール敷いて寝てればよろしい「課題が追加されたら起こして」と言い残して。

「わたしと仕事、どっちが大事?」はなぜ間違いか

　タイトルで惹かれて一読、これはイイ！　これは使わせてもらおう。

　ロジカルシンキングやMECEといった論理的思考ツールは、確かに仕事に使えるまで砥いできたが、肝心の議論に役立ってはいない。あ、いや、「自分の考えを的確に表現し、相手に理解させる」ツールとしては有効だけど、

　・議論が紛糾したとき
　・自分の結論へ誘導したいとき
　・自分の主張に言いがかりとつけられたとき

　これっぽっちも役に立たない。「おまえの意見はよく分かったが ──

　── そんな話はここでは通用しないよ」
　── SEにはカネのことなんか分からないんだ」
　── 他の人もみんなそうじゃないと言っているよ」

　と断言されると、一瞬、どう返していいか言葉に詰まる。議論は黙した方が負け、というルールに従って引き下がらざるをえなくなる。しばらくたって、その「反論」は何の根拠もないことに気づくが、議論はもうあさっての方向へ行っている。

　仕事の場に限らない。この、攻撃するためだけの反論をぶつけられたとき、どう対応していいか分からなくなる。もたもたしていると主張そのものにケチがつく。相手の狙いは正にそこで、主張のロジカルさや明解さなんて二の次だったりする。こんなとき、どうしたらいいか?

　本書では、議論を誘導するためのテクニックが紹介されている。

　【誘導尋問】

• 誤導尋問「お支払いは現金になさいますか、それともカードにしますか」
  
• 誤った二分法「人間は金持ちか貧乏かだ」
  
• 二者択一誤導尋問「私と仕事、どっちが大事?」
  
• 論点のすり替え「『借金を返せ』だと? 信用できないのか！侮辱するな！」

　【詭弁に見えない詭弁】

• 循環論法「AはBである。なぜならば、BはAだからだ」
  
• 事実の信憑性「○○君が××だと言ってたよ」
  
• 誤ったグルーピング「商売人には政治のことは分からない」

　【よく使われる反論のための反論】

• 常套句「そんなのナンセンスだよ」
  
• 見えない多数派「みんなやっているよ。どうして私だけが…」
  
• 自尊心という魔物「まさかそんなレベルの低いこと言わないよね」

　それだけではない、そうした詭弁へ対処するためのテクニックも同時に説明されている。相手の詭弁へ打撃を与える反論術だな。つまり「ああ言えばこう言う」パターンが分かる。簡単なやつなら、口ぐせとして覚えてしまいたいほどシンプルだ。例えば、「常套句」への反論──

　　「そんなの世間では通用しないよ」
　　「それは本質的な議論ではないよ」

　などと、感情的に一方的に議論を打ち切ろうとする相手に対しては、

　　「どういう意見が通用するの? この意見が通用しない理由は?」
　　「では本質的な意見とは何でしょうか? 私の意見との違いは?」

　と理性的に返せばいいし、もっとシンプルに、

　　「世間というのは、あなたの意見のことではないの?」
　　「本質というのは、あなたの意見のことじゃないの?」

とサクっと突いてもいい。嫁さんと口論になったときのトドメとして覚えておこう。

　また、非常に使える「立証責任」を学んだ。命題の正しさを証明するためには100%正しいことを証明する必要があるが、命題が誤っていることを証明するためには、たった一つの反証を挙げればいい。だから、議論では「正しさを証明する立場」=「立証責任」を相手に押し付けた時点で優位になる、というテクニック。

• A 「この動作はバグだ、いますぐ修正してもらおう」
• B 「いいや、これは不具合ではありません。したがって変更するなら追加料金が必要です」
• A 「バグに決まってるだろ。そうでないなら、説明しろ」
• B 「それは筋が違います。不具合だというならば、まずその理由を説明してください。あなたが異を唱えなければ、何も変える必要はないのだから、変えなければならない理由を説明しなければならないのは、あなたです」

　立証責任が行きつ戻りつしているのが分かる。「○○すべきである（ない）」と言った瞬間、そうである理由をキチンと説明しなければならなくなるし、反論する側は、そうでない理由を一つ挙げれば済む。

　さらに高等で、議論でアツくなっている頭には難しいかもしれない（が、使えたら鬼棒）テクニックとして、「飛び火作戦」「そもそも式論法」「門前払いの手法」「言質を取る質問術」が紹介されている。特に「飛び火作戦」と「そもそも式論法」は顧客よりよくヤられる攻撃なので、再読して備えることとする。

　本書が重要なのは、詭弁を弄させて、議論のための議論に陥ることを防ぐため。議論のゴールに全員の目を向けて、ゴールを目指した議論にするため。そうでなく、会議で一目おかれたいとか相手を屈服させたいとか、はたまた一言居士の奴等には、悪魔の手引書となるかもしれない。

「ローマ人の物語」を10倍楽しく読む方法：ローマ人へ質問

　「ローマ人の物語」は長い。完結すれば全15巻におよぶので、読む方も気長に付き合うしかない。だいたい1992年から始まっているので、読む方も書くほうも大変だ。

　だから、それだけ長いと濃淡が出てくる。どれも読み始めたら巻措くあたわず、というワケにはいかない。面白いトコと、そうでないトコが出てくる。例えば「ハンニバル戦記」は独立でオススメ、めがっさ夢中になることを保証する。いっぽう他の巻では「つなぎか? つなぎなんだろっ」と叫びたくなるような箇所もある。

　そんな中、美味しいところを抜き出したのがコレ。しかも「ローマ人になりきっている塩婆が、ローマ人を代弁して回答しますよ」という分かりやすい企画で、ローマおたくの本領がいかんなく発揮されている。

　「悪名高き」代名詞が冠せられるローマの弁護人にでもなったつもりか、読まされるほうは辟易するかもしれない。それでも、「パンとサーカス」「パクス・ロマーナ」といった片言隻句に囚われていたローマ観がガラリと変わったことは事実。リドリー・スコット監督の「グラディエーター」をもう一度観たくなった。あとキューブリック監督「スパルタカス」を観たくなった。

　わたしに響いた問いと答えは次のとおり。「ローマ人の物語」の随所で具体例を見ることができる。

• 【なぜローマが栄華を誇ったか?】
  　⇒ユリウス・カエサルの弁――ローマ人は、他民族から学ぶことを拒絶する傲慢は持ち合わせていない。良しと思えば、たとえそれが敵のものであろうと、拒否するよりは模倣するほうを選んできた
  
  
• 【パクス・ロマーナとは何か?】
  　⇒ドイツの歴史家モムゼンの弁――ローマ人が他民族を支配したのではなく、他民族をローマ人にしてしまったのだ
  
  
• 【なぜローマが滅亡したのか?】
  　⇒「ローマ帝国衰亡史」であまりにも有名なギボンの弁――ローマの衰退は、並はずれて偉大な文明のたどり着く先として、ごく自然で不可避な結果であった。（中略）…ゆえに、人口によるこの大建造物をささえていた各部分が、時代か状況かによってゆらぎはじめるや、見事な大建築は、自らの重量によって崩壊したのである。ローマの滅亡は、それゆえに、単純な要因によってであり、不可避であったのだ。だから、なぜ滅亡したかと問うよりも、なぜあれほども長期にわたって存続できたのかについて問うべきなのである
  

　歴史のタブー「もしも…」を使うために、自らを「シロウト」と呼ぶのはいいとして、歴史家を十羽ひとからげにしてダメ出しをするのは、筆勢ありすぎ。ギボンさえ傲慢の罪に問おうとする塩婆の"オトナ気のなさ"も、楽しみの一つ。

　真贋はおいといて、面白けりゃ万事OKなので、歴史小説と歴史書の間にある本書は読んでて気持ちがいい。「ローマ人の物語」のウォーミングアップとしても良い本だと思う。

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

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

　いまamazonを見たら在庫切れでやんの、ちょっと意地悪な気分になる。

　本書のどのページにもヒントがある。PMな人も、リーダーな人も、ファシリテーターな人も、名前が違うだけで目的はいっしょ。読めば、あちこちに「それ知ってる・ジョーシキ」もしくは「言われて気づいた目からウロコ」のいずれかが埋まっていることだろう。

■シンプルにすると、本質が見える

　これをスゴい本だと感心だけでなく、かなり気に入っている。なぜなら、著者の考え方がものすごくシンプルだから。ひょっとすると、"rule#1 : Be Simple!"という標語が壁に大書きされているのかも、と思うぐらい。

　どれぐらいシンプルに考えているか、次の例で確かめてほしい。

• スケジュールを極限まで簡素化してみると、どのようなプロジェクトでも、その実施期間は、設計、実装、テスティングという3つの工程に分類できます（p.30）
• 極限までシンプルにした計画です。何を行う必要があるのか分からない場合、どうやって行うかを考えるには時期尚早なのです（p.51）

1. 何を行う必要があるのか、に答える→要求定義
2. どうやって行うのか、に答える→設計・仕様書作成
3. 実際に行う→実装

　実際のところ、上記の一つを専門的に取り上げている本が何冊も出ている。しかし、著者はそれぞれのフェーズについて深く学んだ後、全てを考え直している。だから傍目にはものすごく簡単に述べているようでいて、裏の厚みがスゴいのよ。アタリマエじゃん、というのは楽だけど、それをどれだけ基本動作としてやれているかは別物だろう。

　そうした本質的な議論が積み上げられている本として、スゴいのよ。

■正しい疑問を持つ

　ものすごく重要。何のためにプロジェクト計画を立てるのかというと、上で挙げた疑問に答えるため←これに気づいていない「プロジェクト計画書」がなんと多いことか。本質的な議論になっていないかを気づかせるために、正しい疑問はとても重要。いくつか例を引用する。

• 議論の対象となる顧客層をいくつか挙げることができるか? （例えばパッケージなら、学生、プロ、ホームユーザーとなり、業務システムなら、営業、受付、役員となる）彼らのニーズや振る舞いは、どのように違っているのか?
• 私たちは、こういったニーズを満足させ、問題の解決を行えるような、技術や専門知識を持っているのか?
• 洗い出したニーズを満足させ、問題解決を行う上で、私たちの技術や専門技術を活かすことができる、実現性のあるビジネスモデルは存在するのか? （また、利益は予測可能な期限内に投資コストを上回るか?）
• 競合他社は何を行っているのか? 彼らの戦略はどういったものであり、どのように戦っていくことができるのか?

　わたしの経験によると、たいていの場合、これらの疑問に答える時間なんてないし、予備調査もやってない。著者によると、それでもこうした疑問を振り向ける必要がるという。なぜか? その理由は2つあるという。時間がなくても、正しい疑問を呈するべきなのは、

• 優れた疑問の答えを推測するということは、何もやらないよりずっとまし。優れた疑問によって、正しい問題にエネルギーを振り向けられるようになる。推測する時間しか持ち合わせていない場合でも、正しい疑問に対する推測は、誤った疑問に対する推測よりもずっと価値があるから（←要するに、仮説思考）
• 優れた疑問に対する調査を実施していないという事実によって、リーダーやマネジメントに対して警告信号を出すことができるようになるから（←要するに、保険）

　特に2つめが響く。リプレース時に性能調査とリソースの再配分をしていなかったことがある。顧客から予測処理量が提示されていないこともあって、前とおんなじだろうと勝手に考えて見積もったのが運の尽き── 結果は恐ろしいものになった。そのシステムを使うことになる顧客層が増えていたのも関わらず、だ。同様の結果になったにせよ、優れた疑問をしていたならば、少なくとも「警告」を発することはできただろう。

■なぜビジョンが重要なのか

　メンバーが目にする仕様書やWBSよりも以前に作られている（はずの）ビジョンのドキュメントが重要。なぜなら、「なぜその作業が必要なのか」を理由付けているから。これが無いと、その作業が必要な理由を知るためのコストの方が、作業そのもののコストを上回ることになるかもしれない。あるいは、無関心の罠に陥るか。

　本書によると、

1. MRD（市場要求ドキュメント：Market Requirements Document）
2. ビジョンのドキュメント
3. 仕様書
4. 作業分割構成（WBS：Work Breakdown Structure）

　の順に計画レベル間でのフィードバックが働くという。前者が後者を裏づけ、位置づけている。言い換えると、前者をベースとして後者のドキュメントが作成される。最初のMRDはコンサルタントや営業かもしれないが、ビジョンのドキュメントを作るのはPMの役目だ。空疎で有名無実で幼稚な「このプロジェクトとの"びじょん"」は目にしたことがあるかもしれない。そのビジョンは次のどれかに当てはまっていないだろうか?

• 台所の流し台（何でも流せる）型：顧客の能力を最大限まで引き出し、作業を実行できるようにする
• 意味不明型：スケーラビリティのある、性能の高い、多様な顧客を全て満足させる戦略的知的管理ツール
• 超弱気型：最終的には、今までの方法よりも優れたものを考慮できるようになる
• 役員が言った型：役員のビジョンに沿えるよう、全てのリソースを使って実現に邁進する

　また、ビジョンは「見える化」されていなければならないという。スケッチ、モックアップ、チャート等を利用しても、どうしても最終結果をビジュアルなものにできない場合、そのビジョンそのもんが明確になっていない可能性を考えてみるべきだという。

　ビジョンなんて見たことも聞いたこともないよ、という方もいらっしゃるかと。それでも営業からでもコンサル資料でも漁ってみるといい。自分の今の作業につながっていなければ、上記のいずれかになっているかもね。

ゲームで子育て：「まちがい探し」で集中力を上げる

　あいかわらず「ゲーム脳」が大手ふっている。「テレビ漬け」と一緒くたに語られると、それは親の与え方がヘタなんちゃうか? とツッコミを入れたくなる。全てを「ゲーム＝悪玉」論で断じようとする連中には、「おまえなんか、猫のうんこふめ！」という詞を贈ろう。

　ここでは、そんな風に逆らって、子育てに効くゲームを紹介する。

　確かに、子どもに向いていないゲーム── ハッキリ言って、プレイさせてはいけないゲームがある── 野々村病院の人々とか夜勤病棟とかグランドセフトオートとかいわゆるオトナゲーね。さらに、単純アクションやシューティングといった、アタマを使わない指だけのゲームも避けたい。あと、絶対悪ならネトゲだろう、ハマると怖いぞ（別名廃ゲー）。

　しかし、アタマと指を同時にコントロールするものや、小説や映画のようにどっぷりと浸れる世界を味わうゲームなら、どんどんやらせていきたい。自分がハマった作品を（ふさわしい年齢になったら）わが子にも味わわせてやりたい、という気持ちと一緒。

　で、今回はこれ→ Nintendo DS の「まちがいミュージアム」。上の画面と下の画面を見比べて、まちがいに○を付ける、というシンプルなものなんだけど、これが意外とハマる。最初は軽快、だんだんテンポが早くなるBGMと、正答すると「ピコ～ン」と応えてくれるのが妙に良い。

　ハヤリの「右脳が活性化」するかどうかは分からないが、上下の絵の「差」を一瞬で認識して、まちがいの形に近いマルをつける（←これも採点される）を繰り返すうちに、いつもと違うアタマの部分を使ってイイ気分になってくる── って、オトナがハマってどうする！

　わが子の場合、もともと間違い探しが好きで、雑誌の懸賞のやつを見つけてはやっている。「ミッケ！」や「ウォーリー」シリーズも大好きなので、与えた途端に夢中になった。

　良かったのが、タッチペン。子どもとタッチペンの相性は抜群で、マウスにいまいち慣れていなくても、ペンはすぐに使いこなせるようになった。クリック、ドラッグの代わりに、ペンを使って「マルで囲う」「こすり落とす」（←そんな操作で画像を出す問題がある）操作は分かりやすい。子どもが大きくなる頃には、タブレットPCが全盛になるだろうから、今から知っておいて損はなかろう。

　スゴいのがわが子の集中力。やらせ続けるのが良くないことは【我が身をもって実証済みで】明白なので、5分、10分と時間を区切っている。その短時間でものすごい集中力を発揮し、オトナ顔負けの早解きを成し遂げている。すばやく形を認識する能力が何の役に立つかは知らないけれど、意識して集中度を上げるトレーニングになっている。ポイントは、自分の集中力を意識的にコントロールする、というところだねッ

　これまでの「ゲームで子育て」
　　・ゲームで子育て
　　・ゲームで子育て（ポケモン編）

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

■何のための開発プロセスか?

　ソフトウェア開発のプロジェクトマネジメントの話になると、まちがいなく開発プロセスの話になる。そして、（わたしを含めて）みんな好きなんだよなー、今のプロジェクトに適用されていない開発プロセスの話をするのが。曰く、RADのメリット、XPの罠、FDDの将来性… 云々、隣の芝生はナントカというが、少なくとも今よりはマシという希望を味わいたいらしい。

　しかし、本書は個々のプロセス論に拘泥しない。「○○を知りたかったら、△△の書籍・サイトを見るべし」で済ませている（←またその参照先が秀逸なのよ）。著者自身、さまざまな開発プロセスを修得→実践に適用してきた結果、誰もが知っているこの結論に達したからだろう→「銀の弾丸なんて無い」。高価な本に載っていたとか、有名なグルが誉めていたから、という理由だけで、うまく機能しない手続きに盲従しても、最悪の結果しか生み出さないという。わたし自身何度も痛い目にあっているので、激しく同意できる。「○○が最高、他は全部カス」とのたまう某グルを思い浮かべて微笑する。

　著者は、もっと本質的な質問を自分に投げかけている→「何のための開発プロセスか?」。そして、シンプルにこう答えている→「いい仕事ができるよう、チームをサポートし、勇気づけ、手助けするものでなければならない」。そして、スケジュールに影響を与える要素を検証しながら、2章では以下の考察をしている。

• なぜスケジュール通りにすすまないのか
• スケジュールとは確率なり
• 優れた見積もりは優れた設計から生み出される
• スケジュールを機能させるためにすべきこと

　大きくうなずいたのは3つ目、わたしにも似た経験（というかテクニック）を使っているから。まず「優れた見積もりは優れた設計から生み出される」ことは自明だろう。ゴミのような仕様、意味不明な要求が書きなぐられたホワイトボードに基づいて適切な数値を見積もるよう求められた場合、アウトプットを信頼せよというほうが間違っている。ほら、アレだよ、"Garbage In, Garbage Out"というやつ。

　優れた見積もりをするための注意点は7つあげられている（p.41）が、最重要はこれだろう。

　見積もり作業に対してプログラマが消極的である場合、「君が自信を持って見積もりを出せるようになるには、私はどういった質問に答えたらいいんだろうか?」と尋ねるテクニックがあります。彼に具体的な質問を考えさせることにより、彼が感じている恐れや不安に取り組む機会を与え、問題解決の手助けをするわけです

　○○の問題に取り組んでもらうとき、「○○の解決ために、どんな質問がいいだろうか?」という質問をするのは、ものすごく使えるテクニック。「逆に（わたしに）教えて欲しい」というやつ。わたしの場合は、次のとおり。

■見積もり確度を上げる2つの質問

　より正確なスケジューリングの方法として、わたしが使う「質問」をご紹介。作業の見積もりの際、次の「質問」を自分につぶやいたり、メンバーに投げかけたりする。

1. この（暫定的な）見積もりを、もっと確度の高いものにしたい。もう一度見積もってもらうとして、どれぐらいの時間がかかるだろうか?
2. そのために必要な作業、足りない情報はあるだろうか

　ひとつ目の質問の答えが○時間だろうと△日だろうと無問題。着目するべきは、ブレ（プラスマイナス○日）の方。また、そのブレに対し、ふたつ目の質問の答えが大きく影響するなら、その見積もりを信頼するタイミングじゃないってこと。

　このとき、ブレの幅を気にかける。どれぐらいブレの範囲を狭めることができるか? によって、見積もりの確からしさを推定することができるからだ。

　例えば、2～3週間かかります、といっていたのが、14日（±2日）まで確度が上がるのか。あるいは、見積もり作業を再度行っても、たいしてブレが縮めることができないのか。「だいたい～かかります」の「だいたい」がどれぐらい正確な「だいたい」なのかを推し量るわけ。

　そして、最終的に「見積もりやってるよりは実際に作ったほうが早い」という返事が帰ってくるようなら、そこが現時点で最も確度の高い見積もりとなる。ひょっとすると、この返事は、次のような表現になるかもしれない。

　「見積もり作業に時間をかけるよりは、

• 実作業に着手したほうが、確度をあげることができる、
• 実作業からのフィードバックによって、ブレ（±2日）が変わってくる、
• 着手前に分かっている不確定要素は、すべてブレに反映してある、

だから、着手したほうが良い見積もりが得られる」

　一連の「見積もり→計画→実施」の流れだと、1回だけ見積もりになってしまう。見積もりの実施時期にもよるが、1回だけ見積もりでスケジューリングするのは危険な香りが。

　だから、わたしは、上の流れの続きで「実施（一部）→チェック→最初の見積もりへのフィードバック」を行っている。この時点でスケジューリングの差異があったのしても、確度が上がるだけだろう。仮に、一部実施により（スケジュールに影響を与える）リスクが発見できたなら、その時点で見つかったことを喜んだ上で、リスケジュールすればいい。

■スケジュールを機能させるためにするべき8つのこと

　「スケジュールとは確率なり」と喝破されている。たとえば、マイルストーンまでたどり着くために次の二つの作業があり、

　作業Aが期限内に終わらせられる確率：90％
　作業Bが期限内に終わらせられる確率：90％

であれば、確率は90％ではなく、81％になるということ。つまり、作業が積みあがれば積みあがるほど、期限内に終わらせられる確率はドンドン低くなってくる。

　じゃぁどうすればよいか? 著者は「スケジュールを機能させるためにすべきこと」で答えている（p.47）。自分のプロジェクトにあてはめて考えるといいかも。

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

　あえて「お題」だけ並べてみた。立ち読みでもいいから説明を読めば、自分の経験と照らし合わせて考え始めることができるはず。

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

　これは、いわゆるHow to本ではない。プログラミングやテストと同様に、「こんなときは」→「こうする」なんて一問一答形式で答えられるような代物ではない。著者が、マイクロソフトInternet Explorerの開発プロジェクトで直面した問題と、それにどう取り組んできたかが書いてある。まさに宝の山。

■PMにとっての最重要ツール

　プロジェクトは常に一度きりのもので、過去に類似プロジェクトはあっても、同じものは無い。やるたびに変化する不思議のダンジョンのようなものに、どのように取り組んでいけばよいのか ―― 誰もがブチあたるこの難題に対し、著者はとてもシンプルな方法で考える。同様に、本書を著す際に、この方法を適用している。つまり、

　　1.　「重要な話題」に、焦点をあてる
　　2.　「重要な順」に、実行する

　この方法・順番で本書は構成されている。重要な話題から順を追って説明されている。なんだあたりまえじゃないかというツッコミは、わたしも同意。しかし、本書ではこの方法にいたるまでずいぶん考え抜いたことが分かる。

　激しく突き詰めると、PMにとって最重要ツールは優先順位が書かれたホワイトボードだ、と言い切ってもいい。ただ、そのツールにノイズが入ったり、ツールしか見なくなったり、ツールを上手く使えなかったりすることが問題なんだろう。ちょいと飛ぶが、13章でとても重要なことを言っている。

　優先順位づけによって、ものごとが成し遂げられる。特に、あなたが「ノー」という時に、ものごとが成し遂げられる

　おっと先走りすぎた。ここでは、「PMって何なの?」という観点から書かれた1章に絞る。

■アート ―― 技芸と呼ぶ理由

　お題の「アート・オブ・プロジェクトマネジメント」から察するに、なんだかテクニカルな話なんだろうなぁ… と思っていたが、あにはからんや、想像を大幅に裏切ってくれた。「プロジェクトマネジメントは芸術である」（p.13）という理由は、プロジェクトマネージャは"適切な状況下で適切な態度をとる本能"を求められるからだという。

　その具体的な態度を、トム・ピーターズ「完璧なプロジェクトマネージャの追及」/"Pursuing the Perfect Project Manager"[参照]から引いている。

• エゴ/非エゴ
• 独裁/委譲
• 曖昧さの寛容/完全性の追求
• 口頭/文書
• 複雑さの容認/簡潔さの支持
• 焦り/忍耐
• 勇気/恐れ
• 信者/懐疑論者

　状況に応じこれらの"態度"を使い分けるのがミソで、このバランスを上手くとるには、直感や経験が必要だという。確かに。わたしなんざ「相手」によってこれらを使い分けている。気に入った相手や、（その行動を採っても）許される相手、ひどい場合はその日の気分によって態度を変えている（←これは、悪い例なのでマネしないように）。

　メンバーとの距離ではなく、状況に応じて最適な"態度"を採る、こりゃ確かに「技芸」の域だね。ただ、安心してほしいのは、こうしたバランスの取れた人材が見つかることはめったにないそうな。それでも自分の"態度"を一歩引いた観点で観察し、フィードバックすることの重要性は薄れないだろう。

■ホワイトボード地獄

　プロジェクトの極意は、優先順位リストを作成し、ひとつひとつ消していくことだ、ということは大昔どこかで聞きかじった。たぶんWBSのことを指していたんだと思う。

　そのサルマネの結果、お題の地獄に陥ったことがある。つまり、作業リスト、成果物リスト、課題リスト、バグリスト、プロセスチャートをホワイトボードに緻密に書き出し、リストに埋め尽くされた「作戦室」にこもっていたんだ。著者もInternet Explorer 4.0のプロジェクトで似たようなことをやっていたらしい。ただ、彼はわたしよりも優れたボスに恵まれていたようだ。

　最初のうちはプロジェクトが順調に進んでいたため、上司は私が何をやっているのか気付いていませんでした。しかし、私がチームよりもチェックリストとプロセスに時間を割いていることを知った時、大きな赤旗（警告サイン）を振ったのです。

　ある日、彼は私の部屋に入り、室内のすべての壁に貼られた、滑稽なほど巨大なチェックリストと表を見た後、私を座らせてドアを閉めました。そして、「スコット君、こういったものも悪くないが、君のプロジェクトってーのは君のチームそのものなんだよ。チェックリストではなくチームをマネジメントするんだ。このチェックリストがチームのマネジメントに役立つなら、それは素晴らしいことだ。しかし、君のやり方ではすぐにチェックリストのマネジメントをするために君のチームを使うことになるだろう」と言ったのです

　PMはプロセスや方法論に注力するのではなく、チームに注力するべき ── わたしを含め、プロジェクトに関わる全員に太文字でこの事実を伝えたいですな。ある開発プロセスの甲乙をケンケンゴウゴウと議論していた自分が情けない。ついでに○○という手法が一番などと放言していた自分も恥ずかしい。XPでもRUPでもagileでもwaterfallでも、何だって一緒、何のためのプロセスか? を考えなしに適用することは恐ろしい。この観点に立って、著者が根本から考えた結果は10章「メンバーの邪魔をしない方法」にある。そのうちここでも考察しよう。