はじめに

マネジメントをするということは、みんなの先頭に立って道を切り開き、障害物を取り除き、敵の盾となり、進むべき方向を指し示し、チームのメンバーが最大限の力を発揮できるようにすることでしょう。兵たちの後方に立って全員突撃と叫ぶ将校ではなく、俺に続けと先頭を駆け抜けるリーダーになりたいものです。

#43：いつもうまくいきません

プロジェクトの失敗はリーダーのせいである。プロ野球の負け試合の責任は監督3割、選手7割と言われているが、ソフトウェア開発では、プロジェクトリーダー7割、メンバー3割と言っても過言ではない。

プロジェクト期間の鉄則

プロジェクトの組み立てによっては、成功の確率は宝くじの当選確率に等しい。計画からボトルネックを探し出して消しておくこと。

G.M.ワインバーグ、『⁠コンサルタントの道具箱』

#44：私たちの責任～責任の背負い方

自分の失敗責任は最小化し、他人の失敗責任を最大化するような人は自己の成長もリスクの回避も無理だろう。失敗の現実を直視できない人のリスクは高くなる。失敗の原因を他者や物に求める人のリスクは高くなる。

サービスについて

私たちはいいサービスを受けてもいないし、提供してもいない。品質が落ちているのもサービスが悪いのもあたりまえと、たいしてがっかりすることもなくなっている。サービスは落ちるところまで落ちているのだ。上に立つ者は何もしないし、商品は用をなさない。最初からきちんとやっていればこんなことはしなくてすむのだ。私達は「サービス経済」の中で暮らしているのに、サービスはなされていない。でも誰も気にもしない。

「私の担当じゃありません」というわけだが、実際、誰の担当でもなくなっている。

ピーター・グレン、『⁠それは私の担当ではありません』

#45：精神主義ではどうにもならない

期限のない約束は白紙手形。期限が明らかでない仕事を請けるということは、期限について依頼者に全権を委任したということだ。10分後に完成してくれと言われても反論はできない。金額欄が空白の手形にサインしたようなものだ。

やればなんとかなる？

やってみなければわからない、やればなんとかなる、という楽天主義に支えられていた日本軍に対して、ソ連軍は合理主義と物量で圧倒し、ソ連軍戦車に対して火炎瓶と円匙（えんし；シャベル）で挑んだ日本軍は戦闘組織の欠陥を余すところなく暴露したのである。作戦目的があいまいであり、中央と現地のコミュニケーションが有効に機能しなかった。情報に関しても、その受容や解釈に独善性が見られ、戦闘では過度に精神主義が誇張された。

野中郁次郎等共著、『⁠失敗の本質⁠』⁠、ノモンハン事件

#46：カラスの勝手な人たち

手順抜きは手抜きと言うこと。たまの息抜きは生産性を向上させるが、手抜きは品質を低下させ余計に手間がかかる。

ヒトが世界を解釈する三原則

• ヒトは、同じ環境にいても、それにおのおのの意味を見出し、それぞれが別の環境世界に住んでいる
• ヒトは、与えられた環境で、最も苦痛の少ない状態で生きようとする
• ヒトには、自分を中心とした世界があるという思い込みがあり、それに気づかない

大井玄、臨床医

#47：人は必ずミスをする～リスクは人にあり

リスクは人にあり、モノやカネ自体にはない。実はあなた自身が最大のリスクなのだ。

事故原因の80％はヒューマンエラーが原因と言われている。

ジェームズ・リーズン

すべての失敗はヒューマンエラー（人的要因が主因となる失敗）である。

畑村洋太郎

#48：どこまでも譲れるものではない

「スレッシュホールド（threshold⁠）⁠、閾値（しきいち⁠）⁠」という言葉がある。ON/OFFの境となる境界線のことだ。この線を超えるとONと認識され、下回るとOFFと認識される。ON状態を正常領域、OFF状態を異常領域としてみると、正常領域にも異常領域にも領域の幅がある。

仕事の業務品質を保つための正常領域における複数の条件を一つずつ外していくと業務品質は段々と低下して異常領域に近づく。そしてある最後の条件を外した時に異常領域に陥ることになる。この最後の条件だけは外すわけにはいかない。業務品質も製品品質もどこまでも譲れるものではない。

根拠のない楽観性

新しいものがうまくいくことなどないのだが、今度は違うのではないかという期待はいつもある。

G.M.ワインバーグ、『⁠コンサルタントの道具箱』

#49：それでもやめられない悪習慣

悪しき習慣を断ち切ること

事故はあってはならないことですが、万が一起こってしまったら、それは自分たちの悪しき習慣を断ち切る機会として活かしていくことも大切だと思います。

吉川廣和、DOWAホールディングス 会長

おわりに

プロジェクトの管理問題は大きく分けて次の二点に集約されます。

• プロジェクト管理の全体像を理解していないこと
• プロジェクト管理の実行の方法を理解していないこと

要するに何を（What）どのような方法（How）で実行してよいのか理解できていないところに問題の真因があります。この問題は開発実務における、確定された要求仕様（What）に基づいて設計・製造・評価（How）を行う場面においても同様の問題を引き起こしています。

プロジェクト・マネジメントにおいて何を実行すべきかがわかっていなければ、実行段階に進めないことは当たり前で、何を（What）すべきかを最初に理解しておくことが最重要なことだと言えます。