「アート・オブ・プロジェクトマネジメント」読書感想文(その9)問題が起きたとき、その人の真価は試される。プロジェクトに問題はつきものだから、いつも試練の日々といってもいい。わたしの場合、カッと頭に血が上って、あとは血がたぎる限り情熱的に(感情的に、とも言う)問題に取り組む。本当は最後のセリフ「できない理由を聞いているのはなく、どうすればできるかを教えて欲しいのです」を真っ先に言い出す。関係者全員を集めて(電話会議に呼び出して)話をさせれば打開策が出るはずだと駆けずり回る。後知恵なんだけど、↑は全部誤り。分かっててもやってしまう。ここでは11章「問題発生時に行うこと」で知った「わたしが」身に付けておくべきことを考察する。手順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、ワインバーグ、デマルコが同じことを言っている。わたしも同意見で、最もシンプルな真実は以下の通り(デマルコ「デッドライン」より)。答えが見つからないときは、問題を変えてみよう。(哲学はなぜ間違うのか)本は読まなくても書評を書くことはできる。