「デスマーチ」の著者 エドワード・ヨードン氏が亡くなったそうなので、追悼記念に書き下しておく。ちなみに、ツイッターでも書いたけど「デスマーチ」は「終わりなき行軍」を意味するので、現在の短納期（半年ぐらい）のプロジェクトは当てはまらないと思う。そういう場合は、すでに精神が「デス」か「Dead」してしまう場合が多いので別なラベリングが必要だろう。「お前は既に死んでいる」…でもいいけど、意味が違うから別なのを考えよう。
「デスマーチ」を手に取った頃
私が「デスマーチ」を知ったのは、まだ阿佐ヶ谷に住んでいたころだから一人暮らしで寝て起きて渋谷だったか新宿だったかに通っていたころだ。20年前になると思う。DoCoMo のプロジェクトで i-mode の前身を作っていたころだ。いまでこそ i モードを知っている人は少なくないけど（つーか、終わっているから知らない人のほうが多いかも）当時、なんだかわからない2,3年目の新人が、なんだかわからないプロジェクトのまま、なんだかわからない新宿の地下で毎日仕事をしているのは、いま考えればちょっと精神が病みそうな感じだったのだと思う。だが、会社員としてのプログラマをやりつつ、流行りだしたインターネット＆ホームページ作りをやりつつということで、仕事と自分の将来を折り合いが付くか付かないかのぎりぎりのところだったと思う。
そういう頃に、プログラミング（当時は VB や C++ が主流）の技術のあれこれとともに、いつ果てるともない仕事の流れに漂っている感じ、朝会社に行く昼を食べる夕方に夜食を少し食べる10時頃に新宿を出る、という毎日を続けていた。合間にプログラミング＆テスト＆不具合直しを繰り返して、自分の担当の仕様をあれこれ考えてやっていても、多少プログラミングの腕に自信があるぐらいではどうしようもない量の仕事（プロジェクト自体にかかわっているのは、自社で30名弱、他社も入れれば200名ぐらいだろうか）があって、徒労感がひどい状態だった。でも、まあ、こういうのが「仕事」かもしれないと思ってやっていたころだ。
ふと、阿佐ヶ谷の本屋でいつもの技術書コーナーじゃなくて（当時はコンピューターの本はたくさん棚に並んでいたのだ）、なにかちょっと読みものっぽいコーナーを見た。「人月の神話」を買った前後だったか覚えていないのだが、「デスマーチ」という薄い本（日経BPのは分厚いけども、当時はもっと薄かった）があった。日経BPのほうでは挿絵を削られてしまっている（と思う）のだが、当時の本には、行軍のイラストが書いてあった。
ある意味、それだけで私は「デスマーチ」という本は十分だったのである。
見えない現象に名前を付けるということ
タイトルを失念したが、細野不二彦の漫画に「子供に見えない恐怖に名前を付けて克服できるように教える」というシーンがある。もともと現象なり恐怖なりはそこにあるものだけど、それを認識するためにはなんらかの「認識する」行為そのものが必要となる。それが「名前付け」であり、認知学の基本だったりする。現象学を紐解けば、シニフェ/シニフィアンという対応がとられているのがわかる。
いつ終わるともわからないプロジェクト、完成がいつかわからないプロジェクト、毎日忙しいけれどそれがいつ忙しくなくなるのかがわからないプロジェクトが2,3年続けば、それは「デスマーチ」プロジェクトと言ってよい。当時は、プロジェクトの成功率が 30%程度（日本の成功率が高いのは、「失敗したと認めない」からだ）だった。もっと厳密に「成功率」を考えれば、
- 当初、計画した期間でプロジェクトを終わらせる
- 当初、計画した予算（人員）でプロジェクトを終わらせる
- 完成時に、当初の要望を満足できる形で製品が完成される
のが「成功」と言えるだろう。もちろん、もっとゆるゆるにして「ほぼ成功」とか「一部成功」なんてことも言えるけど、きちんと計画駆動（ウォーターフォール）するのだったら、成功の定義ぐらいきちんとして欲しいところだ。まあ、カウボーイプロセスも似た感じではあるけれど。
そういうものを曖昧にしたまま、「仕事」だからというスタイルでずるずるとソフトウェア開発をしていると、それは「デスマーチ」だ。目標もゴールも予算もなにもない。ただ「行軍」だけが目的化してしまった状態だ。
その渦中にいると、なにでこうなっているか分からないのだが、一度「デスマーチ」という名前付けをしてしまうと、一方で「デスマーチではない状態とは何か？」がわかってくる。いくつか「デスマーチではない状態」を列挙してみれば、
- 納期が決まっている（それが不可能であっても、動かない納期がある）
- 予算が決まっている。予算がなくなれば、プロジェクト自体が死ぬので、デスマーチも止まる。
- タスクが決まっている。クリアすべきタスク／機能がわかっていれば、それさえ作ってしまえば、いつでもプロジェクトを終わらせられる。
という状態がある。なので、2000年頃からスタートした Web 開発の場合、短納期であることが多いので「デスマーチ」にならない。その代り「デス」＝「即死」してしまうことはある。
ヨードンとデマルコ
実は、エドワード・ヨードン氏は数学者で（だったよね？）数学的なアプローチでソフトウェア開発プロセスを組み直そうとしている。構造化分析とかシステムダイナミクスとかそれだ。一方で、がちがちの管理主義者だったデマルコ氏だが一変して「ピープルウェア」を提唱している。このあたりは（今思えば）両者ともコンサルタントの立場から離れないという感じで、あまりプログラミングそのものには介在しないような感じなのではあるが、「ソフトウェア開発」というもの自体が「営利活動」である間は、経営／雇用／被雇用／外注などの普通の会社と変わらないものが出てくる。そこのあたりはドラッカー言うところの、何処に「顧客を創る」かだ。
おそらく、そのあたりで SAP などの BI（ビジネス・インテリジェンス）ブームに乗ってしまったと思うのだが、この二人がプロジェクト・ナビゲーターを作っていた頃の講演を聞きにいったことがある。
当時の私は、会場で手を挙げて質問をするのが趣味だったので、数学者としてのヨードン氏に質問をした。「TOC（制約理論）を応用した CCPM をどう思われるでしょうか？」。私のほうは TOC にハマっていた頃で、CCPM を自分の会社に応用できればいいかと思っていろいろ考えて、同時に XP をはじめとするアジャイル開発界隈にも顔を出していた頃だった。彼の答えの雰囲気としては、「TOC は非常に素晴らしい／興味ある理論だけども…」という感じだった。まあ、そりゃそうだ。一方で「プロジェクト・ナビゲーター」を売り出していこうとしたところで、TOC/CCPM の話をされたらあまり良い気はしなかったのだろう。
プロジェクト・ナビゲーターの最大の欠点は？
その講演があったのは10年前ぐらいだろうか。アジャイル開発が盛り上がっていた頃でもあって、管理側と開発側の対立が顕著になっていた頃だ。むろん、アジャイル開発をする場合には、スクラムプロセスのように管理と開発が一体にならないとダメなのだが、もともと管理側の人間からすれば「人を管理する」に徹するほうが分かりやすかったりする。少なくtも、管理側の人間からすれば、管理するのが楽なのだ。あたりまえだけどそういう視点がある。このあたりはワインバーグの「ライト、ついてますか」にもあって、「管理者になれ、被管理者になるな」ってのがある。
私が、BI が胡散臭いと思っているのは（今の BI はわからないが、当時の BI は非常に胡散臭かった）、現状だけを眺める、いわば工場のラインを上から眺めるだけの仕事になっているからだ。そのラインで働いている人のことを全然考えていない。というか、そのラインで働いている人を「バカ」だと思っているか、そういう制限された能力しかない（少なくとも、管理者を超える能力や、管理者が想像もできないような能力は思いもよらない）というのが前提になっている。だから、ラインで働いている人は、飛び抜けて出来ても困るし、もちろん飛び抜けてできなくても困る。そういう「ソフトウェア・ファクトリ」（昔の Microsoft のスローガンだ）の視点でしか見ない現象である。以前は、こういう会社を憎んでいた私でははあるが、いやいや今だだと旧態依然でやってくれたほうが相対的に自分に利益になることが分かったので放置である。だって「仲間」じゃないんだもん。
でもって、「ナビゲーター」の話に戻ると、それは株のデイトレーダーと同じように開発プロセスを見ることを目的としている（ヨードンは「デイトレード」という名称を使わなかったけど、絵柄はそっくりだ）。確かに、経営的な視点とかマクロ的な視点とかであればいいのだが、どうもそういう尻馬に乗っているスタイルは私は好きではない。いや、もっと積極的に言えば、尻馬に乗るぐらいだったら、馬自体の能力をもっと引き出したらどうだろうか？ってな具合だ。
「ナビゲーター」は現状を数値化して不都合のありそうなところをフォローするように働きかけることができる。いわば、マイナス部分を削っていけば、プラスだけが残る。少しずつ平均を上回るということだ。私も「マイナス削除」の方法をとることはあるけど、それはミクロ的なレベルだ。けれど、マクロ的にマイナスの削除をするということは、人を部品として切り捨てるということになる。あるいは、人を標準化するということになる。
もちろん、CCPM も含めて「部分最適化」よりも「全体最適化」のほうが効果が大きいことがわかっている。CCPM もプロジェクトナビゲーターも全体を俯瞰するというツールという点では同じだ。進捗状況を、Excel で管理したり、MS Project であれこれとやったり、バーンダウンチャートを作ったりするのも同じだ。全体の俯瞰するためのツールである。が、全体を俯瞰して弱点を見つけたあとに何をするかというのが「プロジェクトナビゲーター」にはない。いや、なかった。弱点を補強するのか、差し替えるのか、または全体をシミュレーションし直すのかという視点がナビゲーターにはない。それは、あくまでも俯瞰するための「図」でしかなくて、ナビゲーションしていない。そうそう、弱点を補強するという形では、ツェッペリが鉄球で馬の癖を大きくする、という方法もあるのだ。
そういう意味でもピープルウェアから外れている感じがするのだが、当時は CMMI ブームでもあったので仕方がないといったところだろう。
再びデスマーチへ？
過去のものが「経験」であるならば、未来に進むためには「予測」や「予知」が必要となる。私たちはソフトウェア界隈の多くの屍（主に大手企業の屍）を乗り越えここに至っている…ような気がするけど、実はそうでもない。豆蔵のボランティアのアレもどうかと思うけど、どちらかといえば、屍になっちゃった人は屍のままで、その臭いを避けて通った人が生き残っている気がする。
かつてデスマーチ撲滅メーリングリスト（でしたっけ、プロセス改善 ML だったっけ？）ってのがあったのだが、廃れてしまった。その第一の理由が、「デスマーチになるような会社を辞めて、転職/独立しちゃった」ので、デスマーチに巻き込まれなくなったんですよね。そうすると、自分のことではなくなってしまうので、あまり興味がなくなっちゃうわけですよ。緊急性が低くなる感じ。
という訳で、某銀行プロジェクトのような大規模デスマーチ予備軍に配属されない限り、あまりデスマーチに出会うことはない。むしろ、冒頭で書いたのだが「デス」の場合が多い。配属 → 即死フラグってのがあまりにもアレなんだけど、そこは要領良く無駄な作業を省くということだろう。超概算見積もりとか、三面図型 CCPM とか、まあ色々避ける手段はある。
[amazonjs asin=”B00F4QOMUO” locale=”JP” title=”デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか”]
[amazonjs asin=”B00I96CJWO” locale=”JP” title=”ピープルウエア 第3版”]
[amazonjs asin=”4320023684″ locale=”JP” title=”ライト、ついてますか―問題発見の人間学”]
