「アート・オブ・プロジェクトマネジメント」読書感想文（その9）
問題が起きたとき、その人の真価は試される。しかも、プロジェクトに問題はつきものだから、いつも試練の日々といってもいい。
わたしの場合、カッと頭に血が上って、あとは血がたぎる限り情熱的に（感情的に、とも言う）問題に取り組む。本当は最後のセリフ「できない理由を聞いているのはなく、どうすればできるかを教えて欲しいのです」を真っ先に言い出す。とにかく関係者全員を集めて（電話会議に呼び出して）話をさせれば打開策が出るはずだと駆けずり回る。
後知恵なんだけど、↑は全部誤り。分かっててもやってしまう。ここでは11章「問題発生時に行うこと」で知った「わたしが」身に付けておくべきことを考察する。
■問題発生時に行うべき8つの手順
手順1：気を落ち着かせる 手順2：プロジェクトに関係のある問題を評価する 手順3：もう一度、気を落ち着かせる 手順4：適切な人材を会議室に呼ぶ 手順5：選択肢を探求する 手順6：最もシンプルな計画を作成する 手順7：実行する 手順8：結果のふり返り
内容は推して知るべし（p.254に説明がある）。わたしが誤っているのは、手順7からいきなり実行するところ。ぶっちゃけ手順7→5→7→5をくり返している。「走りながら考えよう、結果は後からついてくる」やり方は、上手くいくこともあるが、失敗する場合の方がはるかに多いことに、いいかげん気づけ！→わたし。
まだある。プロジェクトに火がついたとき、人を追加することがいかに危険であるかは、知っているにもかかわらず、手順4を忘れてしまう。関係者を集めて話をさせれば、解はおのずと見出せるという激しい誤解のもと、どれだけ不毛な時間と体力を費やしたことか。
「ビジョナリーカンパニー2」にある一節「適切な人をバスに乗せ、不適切な人をバスから降ろす」が心に響く。これは経営戦略を決めるときの話なんだけど、どっちへ転ぶか分からない問題解決の場合も、同じことが言える。不適切な人がいる限り、解決までの道のりは長い（ひょっとすると、たどり着けないかもしれない）。
やってはいけない悪手をわざわざ選んでいるとしか思えない。11章は折にふれて読み返すことになるだろう。
■「責任を取る」とは何か?
ドキュメントの表紙に
[ 作成者：___________ ] と、
[ 責任者：___________ ] の、
二つのサイン欄がある。この責任者ってナニする人なんだろうね、とネタにすることはあれど、オチは必ず、責任者が責任取ったことなんて無いね、という結論に至る。
そもそも、「責任を取る」とはどういうことなんだろうか? システム開発において、何をすれば「責任を取った」ことになるのだろうか?
本書は、この疑問にも明解に答えてくれる→「責任を取るということは、単に、結果と向き合った上で、状況の解決に対する説明責任を負うということしか意味していない」という。
これまで、「責任を取って辞任する」とか「責任を取って土下座する」といった、ネガティブな解しか思い当たらなかった。「責任を取る＝失敗する」という思考に囚われていたんやね。ネガティブになると猫背になる、なんてこった！
責任者とは最終的な説明責任を負う者 ―― これでスッキリしたが、だからといって非難や愚弄の嵐から逃れることにはならない。火を消すスキルを獲得したければ、火傷を負う覚悟で炎へ飛び込め、と著者は励ます。鬱に追い込まれ再起不能になるほど心を破壊された人を知っているわたしには、この励ましは空恐ろしく聞こえる。たいていの場合、火がついたプロジェクトの「責任者」はいつのまにかいなくなり、「作成者」が責任を取らされるのだから。
一方で、頼もしく思えてくる「責任者」の力強いメッセージがある。テンプレとしても使えるので、ここに引用しておこう。
むかし、燃え盛るプロジェクトを前に、火消し屋のわたしに向かって、これと全く同じことを言い切ったPMがいる。最後まで逃げない人で、今でも尊敬している。
■パフォーマンスとプレッシャー
自然のプレッシャー、人工のプレッシャー、ポジティブなプレッシャー、ネガティブなプレッシャーといった様々な議論が取りざたされているが、その適用は経験に裏打ちされたバランス感覚が必要だという。
興味深いことに、プレッシャーについて、著者であるBerkun、ワインバーグ、デマルコが同じことを言っている。もちろんわたしも同意見で、最もシンプルな真実は以下の通り（デマルコ「デッドライン」より）。
【質問】
プレッシャーがプログラマーに与える影響が、6％の生産性向上 だけで平坦化してしまうのはなぜですか?
【回答】
プレッシャーをかけられても思考は速くならない
| 固定リンク
コメント