プロジェクトの歩き方「熊とワルツを」
https://gyazo.com/1669f47c1d75eaed14ab6cb7ef1bf728
2003/12/23
トム・デマルコ (著), ティモシー・リスター (著), 伊豆原 弓 (翻訳) 日経BP
――――――
トムとティモシーによる「熊とワルツを」は、ソフトウェア開発におけるリスク管理の方法を指南する本である。
出版は2003年。
1990年代におきたIT開発の教訓をもとに、ゼロ年代以降の後続プロジェクトへの警鐘を鳴らしている。
それにしても、ゼロ年代当時の「IT技術における先端的テーマ」を、2024年の人間が見返すと、実に牧歌的に見えること！
特に1点目のHTML、Java、～の部分
2点目のユーザーについては、デザイン思考の導入により、若干、改善？
3点目のセキュリティの話は、今も昔も変わらない（むしろ問題はより高度化している）
https://gyazo.com/22c641912d085a087eca92c5f84b50e7
これを見ながら、10年代、20年代の日本で何が起きたかを考えると、メリルリンチの再演がほとんどである。
メインフレーム→クライアント・サーバ、という図式が、クライアント・サーバ→クラウド、に置き換わっただけである。
いや、IaaSでなくSaaSだ、とか、そういうことをごちゃごちゃいう人もいるかもしれないが、本質はそこではない。
問題は「全く新たなビジネス形態の出現」に手をこまねき、後発の立場で追う立場に甘んじてきた、ということである。
ただまぁ、それは、日本や日本人だけがそう、というわけでもない。
おそらく、現状に甘んじるという生存形態は、国籍も時代も問わないのである。
ゆえに、技術は変化しても、本書で問題提起されている問題は、まったくもって、いまも変わらない。
たとえば、デンバー国際空港で起きたような失敗事例は、いくら技術が進化しても、減りはしないのである。
https://gyazo.com/25e7b0233a5cbaa6e2edd48321b65fb8
本書の白眉は、依頼された請負業務の完了期日を、確率的に扱う、というコンセプトである。
これはソフトウェア開発プロジェクトのリスクの本質を、極めて正確に洞察した見方である。
いや、ソフトウェア開発に限らず、未知の要素が多い、請負的なプロジェクトでは、広く適用できる。
（要素技術や制作プロセス、顧客との対話方法等が十分に既知である、ルーチンワーク的な取り組みには不要である）
https://gyazo.com/fac3af054db25ef75b1bc9795af2e941
上図の考え方で、開発成果物全体をざっくりと語ることは、ものの見方としては有効だが、実践的ではない。
ゆえに、本書は「先見的インクリメンタル開発」を提案する。
開発リスクを低減するために有効なのは、スコープを小さくすること、である。
ただし、もっとも核心的（同時に、革新的な）部分を最優先せよ、ということがミソである。
https://gyazo.com/449958735f0e4d29ea452e8d33ccd814
ただし、「あらかじめ、設計をほぼ完全に行っておく」が、まぁ、最大の困難ではある。
IT成果物を「価値」の観点で議論できる発注者が少ないし、技術的なリスクをちゃんと理解しているベンダも少ない。
ゆえに、本書の先見的インクリメンタル開発は、やはり、どこかこう、理想のための理想論、というところは否めない。
＊＊＊
さておき、本書はまさに、ウォーターフォールからアジャイルへの転換が叫ばれた時代の、申し子的な本だと言える。
ただし、顧客探索（開発）型の、いわゆるリーンスタートアップ的なアジャイル（≒スクラム）の本ではない。
あくまで、一定以上の規模を持つ事業主体や顧客の存在を前提とした中規模以上の開発を、素早く、という意味である。
そういう意味では、どちらかというとコンカレントエンジニアリングのIT版、と言ったほうが近いかもしれない。
ちなみに、PMBOKが第七版で、アジャイルに日和った、という揶揄がしばしば聞かれるが、本書を読んで、もしかしたら、PMBOKはむしろウォーターフォールを、正統的に、積極的に進化させようとしていた、ということだったのかもしれない、と、思った。（PMBOK第七版から、なんちゃってアジャイル系の要素を取り除いたら、本書そのものになるんじゃない？）
ただまぁ、この本がウォーターフォールの本なのかアジャイルの本なのかを争うことには、本質的には、意味はない。
なぜなら、本書から受け取るべきメッセージは、そんな表層論よりも、はるかに普遍的なものだから。
本当に期日が大事なら、よりハイレベルな階層のリスク管理をちゃんとやれ、そして早く着手せよ
「適切な管理」に対して尻込みするな、「適切にみえる管理」で、ごまかすな
あらゆる人間活動をむしばむ近視眼的な思考と、戦え
では、近視眼的な思考とはなにか？それは以下の通りである。
やればできる思考
失望させたくないという感情
バラ色のシナリオが色あせることを許きない圧力
不確定性を口に出すことに対する恐怖
（実際にはとうに手に負えなくなっていても）事態を掌握しているように見せかける必要
政治的権力によって現実を打破したいという誘惑
＊＊＊
それにしても、本書は本当に気の利いた言い回しがたくさんあって、強い親近感を覚える。
●誰でもリスクを無事にかわして喜ぶことはある。しかし、リスクをかわす計画を立てるのは、よい戦略とは言いがたい。
●製品の仕様書をあいまいに作ることはできるが、製品をあいまいに作ることはできない。
●参加者に、「このプロジェクトの勝利条件で、ほかの人の勝利条件と矛盾すると思われるものはありますか」とたずねるとよい。対立が見つかれば、それは潜在リスクである。
●皮肉なことに、多くのプロジェクトは、マネジャーが「早く始める」というはるかに重要なリスクから逃げたために、納品が遅れるというリスクを背負わされるのだ。
●企業にとって最大のリスクは、価値にかんするリスクである。すなわち、価値の低いプロジェクトに無駄な労力をつぎ込み、価値の高いプロジェクトを逃して機会コストを負うことである。
●阻害要因とは、やればできる思考、失望させたくないという感情、バラ色のシナリオが色あせることを許きない圧力、不確定性を口に出すことに対する恐後、（実際にはとうに手に負えなくなっていても）事態を掌握しているように見せかける必要、政治的権力によって現実を打破したいという誘惑、あらゆる人間活動をむしばむ近視眼的な思考などだ。これらの力は強力である。一見思慮深い人をも、適切な管理に対して尻込みさせ、かわりに「適切にみえる管理」に走らせる力がある。
最後に、個人的な注釈をひとつ。
「IT革命に乗り遅れるな、素早くチャレンジし、的確にリスクを攻略しよう、ライバルを出し抜け、競争に負けるな」という本書の基調をなす世界観には、反省は必要ではないか？ということを、思う。CGIだ、PERLだといっていた世界から、クラウドだ、GOだvueだPythonだ、ブロックチェーンだ生成AIだ、デザインシステムだマイクロサービスだという世界に移行して、果たして誰が幸せになったのか？
部分的にはなにかが効率化し、楽になったかもしれないが、それは、カーペットのシワを別の場所に移しただけではないのか。
そういう問題を、正しい順番で、まともに考えようとしないから、諸問題が、いつまで経っても片付かないのではないか。（自治体システム標準化とか。ほんとに、なにやってんだというITプロジェクトは増えこそすれ、減らないのは、一体なぜなんだ？という問題が、本当の問題である）
ちなみに、冒頭の「シュワブ」のその後は、非常に立派な成績を残したそうである。
この実績は、シュワブのリスクの扱い方が、とても優れており、かつ長期的に継承できている可能性を示唆している。
「チャールズ・シュワブの経営理念と事業戦略」（野村資本市場研究所）
https://gyazo.com/24a992b751e15d487243e33a05a7b6d1
https://gyazo.com/fd028c90d80dbce03af3b7b47dd847bb