予定

なぜソフト業界にだけデスマーチが顕著に現れるのかをお話ししました。他の 業界とは違って、この業界では不可能がないからです。

軍の行軍に例えて言えば、普通の業界なら高い山や海、広い川があって「今の 装備ではこれ以上進むことができない」という状況が存在します。そこで立ち 止まって、基礎技術を研究するなり対策を考えるなりします。しかしソフト業 界はだだっ広い平原のはるか遠くに目的地が見えているようなものです。とに かく歩きさえすればいつかたどり着けます。が、いくら歩いてもちっとも近づ いた気がしません。「この距離を徒歩で進むのは無理なのでは？やっぱり馬が 必要だったのではないか」と言っても「弱音を吐くな。前に進めばいつかは着 く。ほら、目的地は見えてるじゃないか」と言われておしまいです。その結果 「前に向かって歩く」以外の選択肢を考えることができなくなってしまいます。

この問題を解決するには、量の問題を質の問題に転換しなくてはなりません。 「できるけど非常に時間がかかる」ということを「できる」ではなく「できな い」に分類することです。ソフトの世界では、時間さえかければできないこと はありません。

ここでは、プロジェクトの予定について話をします。予定とはつまり、やるこ ととやらないことを分け、いつまでにやるかを決めることです。そして、予定 にない事はたとえできる事であってもやらないことにします。

目標の設定

まず、一切の主観を排除した、客観的な目標を定めることが必要です。客観的 な目標とは、そこに到達した時に「間違いなく到達した」と言えることです。 状況によって目標が動かないことです。

プロジェクトの始めに、まず目標を立ててください。そして開発が終わりに近 づいたら、責任感のない怠け者になって、自己弁護をしながら現状を常に良い 方へ解釈するのです。「ほら、これでもう当初の目標は達成しているよ。そん な機能はもとから目標になかったのだから、付け加える必要なんてない」と。 もし、これに対して「こんな考え方ではろくでもない製品になってしまう」と 思うようでしたら、それは考え方が悪いのではなく、目標の立て方が悪いので す。目標がろくでもないから、目標を達成しただけでは「ろくでもない製品」 になってしまうのです。「素晴らしい製品」を目標に掲げれば、当初の目標を 達成しさえすれば素晴らしい製品が出来上がります。

「お前は製品をちょっとでも良くしようという気がないのか！」と言う人は、 目標を自分で遠くに動かしているのです。こんなことを繰り返している限り 目標には決して到達できません。「製品を少しでも良くしよう」という考え方 はソフトウェアでは害悪です。他のモノと違って、ソフトウェアは時間さえ かければいくらでも良くなるからです。キリがありません。

客観的な目標を設定しないプロジェクトでは、プロジェクトの終了はリーダの 胸先三寸です。リーダが進み続ける限り行進はどこまでも続きますし、「行進 やめ！」という号令をかけさえすればそこがゴールになります。プロジェクト 開始時点で見えている目標は遠くの山々であり、そうした山々は近くに到着し てみると見えなくなってしまいます。すると見えない「目標」を捜してさまよ い歩き、ついに力尽きて倒れた時に「ここが目標だったということにしよう」 と勝手に納得して行進をやめます。「目標地点＝力尽きた地点」という定義な のですから、力尽きないで目標に到達することは不可能なのです。

例えば、知り合いの外国人に「一番東京らしい所へ連れていってくれ」と言わ れたら、いったいどこへ案内しますか？皇居？丸の内？新宿？浅草？渋谷？そ れとも秋葉原？どこも東京を語る上では重要なスポットですが、このうちのど こが一番「東京らしい」ということはありません。一番東京らしい所を隅々ま で捜し回って、へとへとになって宿に戻ってきてから、ふと考えます。「そも そも東京らしさっていったい何だったんだろう」と。へとへとになって探し回っ てはみたものの、結局のところ何を探していたのかすら自分でわかっていない ということがよくあります。そんなことで見つかるわけがありません。

まとめます。なによりもまず客観的な目標を立てましょう。漠然とした目標だ と、そこに近付いた時にどこが本当の目標なのかがわからなくなります。

なぜギリギリまで働かないか

デスマーチは、特に締切が近付いてくると激しくなります。いつもは少しの残 業だけで済んでいたものが、だんだん休日出勤になって、徹夜になって、泊ま り込みになって……と、仕事が増えていきます。そうなるごとに「ああ、こう なる前に始めのうちからやっておけばよかったなぁ」と後悔します。しかし後 悔はまったく役に立たず、これが何回でも繰り返されます。なぜかというと、 デスマーチになるような組織はもともと「始めのうちからやっておく」ことが 不可能だからです。

ちょっと想像してみて下さい。もし万が一、納期の1週間前にソフトが完成し たとしたら、あとの1週間は本当に遊んで暮らせるでしょうか？「まだ納期ま で時間があるんだから、あとちょっと……」ということにはならないでしょう か？もしこうなりそうだと思ったなら、あなたは決して「余裕で完成させる」 ことはできません。なぜなら、余裕を見せるとどんどん目標は遠のいてしまう からです。

自分の負担を減らそうと思ったら、プロジェクトの前半は遊んで暮らすことで す。どうせプロジェクトは納期が来てぶっ倒れるまで終わらないのですし、 (本当の)納期さえ来れば多少の問題点は目をつぶってプロジェクトは終了にな ります。だったら、最初から頑張るのは無駄です。どうせぶっ倒れるのなら最 初のうちに遊んでおいた方がトクです。

デスマーチ的組織にいるなら、余裕はできるだけ見せないようにしなくてはな りません。定時に帰るなどもっての他です。だから、いつまでたっても定時で 帰れるようにはなりません。

デスマーチをなくすには、「残業は偉い」という価値観をなくすことです。残 業はしないに越したことはありません。残業をしている人間は、正規の時間だ けでは自分の仕事をこなせない無能者です。隣の人がどんなに徹夜していても、 自分の仕事が終わったら定時で帰っていいのです。そちらの方がまともな生活 であり、残業続きの方が異常なのです。

仕様分析

プロジェクトの早い段階から密度の高い作業に入れないのには、もう一つ理由 があります。それは、何をすればよいかわからないことです。もちろん最終的 な行き先はわかっています。しかしそれは漠然としてあまりにも遠すぎ、そこ に行くために何をすればよいかがよくわからないのです。

早い段階でする作業は後の仕様変更によって無駄になりやすいという懸念もあ ります。残業を重ねて早目に開発したものが「あ、仕様が変わったよ」という 一言でボツになってしまってはいっぺんにやる気をなくしてしまいます。

なぜこんなことになるかというと、何をしなければいけないかを時間をかけて 理解しようとしないからです。まず、どんなプログラムを作ったらよいかをはっ きりさせることです。わかりやすいところを片っ端から作っていくようなやり 方ではいつまでたっても先が見えてはきません。

細かく具体的な計画をたてましょう。少なくとも朝出勤した時に、今日一 日帰るまでに何をするかが明確に言えるようでなくてはなりません。「もしやっ かいなバグが出て一日で終わらないようだったらどうするんだ」と思う人もい るかもしれませんが、やっかいなバグが出た時のために「残業」という最後の 手段があるのです。やっかいなバグが出なかったら残業をせず定時に帰りましょ う。始めから残業込みで予定を立ててはいけません。

マイルストーン

大きなプロジェクトでは、最終的な完成の前にいくつかの予備的な締切を設け ます。「○月○日の時点で××ができていること」という目標をたてます。こ れがマイルストーンです。

マイルストーンを置くことは2つの意味があります。

• 開発が調子よく進んでいるのか、それとも遅れているのかがわかる。

• これから何をしなければいけないのかがわかる。あと何の仕事が残っているの かがわかる。

マイルストーンはあくまで目標であり、本当の締切ではない点に注意してくだ さい。マイルストーンを達成するために無理をするのでは本末転倒です。マイ ルストーンはマラソンで言えば10km地点や20km地点のタイムに相当します。 10km地点のタイムが予定より遅めになりそうだからといって、ここでダッシュ して全力を使ってしまうようなバカげた行いは避けなくてはなりません。

「マイルストーンに間に合わなくてもいい」と言うと、「だったらマイルストー ンなど誰も守らないのでは」と言う人もいるかもしれません。その通り、マイ ルストーンは守るものではなく、普通に開発をすれば自然に達成できてしまう ものです。そうでないとしたら、マイルストーンの設定期間が間違っています。 マイルストーンに向けて頑張るのではなく、最終目標に向けて頑張るのです。 そうしたら自然に守れるようなマイルストーンを設定すべきです。

マイルストーンは客観的でなくてはいけませんが、それがモノ(プログラム)で ある必要はありません。プログラムを順々に作っていくのは悪いやり方です。 そうではなく、まず要求を分析し、仕様を固め、設計をし、それからプログラ ムにかかるべきです。

まとめ

デスマーチに陥るプロジェクトで足りないものの第一は「計画性」です。単に 計画を立てるだけではダメで、守れる計画でなくてはなりません。それも、残 業や徹夜を前提としたものであってはいけません。 ^[1]

計画は客観的でなくてはなりません。「この線を横切ったらゴール」というの が事前にわかることです。そして、ゴールしたらプロジェクトはそこで終了さ せます。