 デスマーチ
|
デスマーチ[文書トップ] | ご意見などお気軽にどうぞ ゲストブック |
「デスマーチ」訳して「死の行進」。字面だけでも恐しい感じを受けます。プ ロジェクトが破綻へ向かってどんどん進んでいく様子をこう呼びます。この言 葉の恐しいところは、これが単なる比喩ではないことです。デスマーチがまさ に進行中のプロジェクトでは、過労死や自殺などで本当に死人が出ます。そこ まで至らなくても、うつ病になったり体を壊したりして、あるいは自発的にど んどん開発者が辞めていきます。まさに悲劇です。
しかし、またまた恐しいことに、デスマーチは決して珍しくはありません。開 発者ならば誰でも経験したことがあろうというほどよくある事です。この事が 問題をいっそう難しいものにしています。 ここでは、デスマーチの問題点とそこから抜け出るためにどうすればいいのか を考えてみましょう。
なお、初めに注記しておきます。ここで述べることがらは、最先端のプロジェ クトや高度なプロジェクトにはあまり当てはまりません。○○会社の経理シス テムとか○○倉庫の管理システムといったように、技術的な障壁のなさそうな プロジェクトに当てはまります。
デスマーチとは端的に言えば「もともと破綻する運命にあるプロジェクト」で す。開発期間がもともと必要量より少なかったり、必要な開発者がほとんどい なかったり、もともと無理な性能を要求されていたりする時に起きます。
典型的なデスマーチでは、次の状態にあります。
開発者は、プロジェクトの遅れの原因が突発的な事故やミスではなく、もっと 根本的な所にあると感じている。
現在の開発のやり方はおそろしく非効率で、傷を深めていくだけであるとわかっ ている。
しかし、現状がどうであろうととにかく開発を進める以外に手立てはない。
リーダーの前には問題が山積していて、それを一つ一つ解決するしかな い。しかし、一つを解決している間に別の問題が二つくらい山に積まれてしま う。
プロジェクトは切羽つまっており、一時的な休息も許されない。
チーム内に、ソフト開発とはそういうものだという認識が広まっている。この 状況を改善しようとも思わないし、そういう動きに抵抗する。
デスマーチが恐しいのはこの悪循環にあります。自分たちが死へ向かっている ことがわかっていながら、前に進むことしか許されていないのです。そして最 後に諦めがやってきます。「どうせ前にしか進めないのなら、玉砕して名誉の 戦死をしよう」と。このように人格崩壊に至ると、むしろ喜んで死の沼へ突進 します。とにかく前へ進むことが喜びに変わるのです。こうして狂人に導かれ て隊はどんどん死へと行進していくのです。
デスマーチが本当に恐しいのは、それが洗脳を伴うからです。軍隊で新兵をし ごいて根性を叩き直すのと同じです。軍隊は、人殺しが仕事であり、毎日が殺 すか殺されるかの瀬戸際にあります。まともな精神ではこんな特殊な状況に適 応できません。だから一種の洗脳をほどこして、軍隊の考え方を叩き込むので す。説得や理解ではなく、文字通り「叩き込む」のです。
ソフトウェア開発者も、しばしば洗脳されることがあります。開発者は何日も 徹夜同然で、しばしば会社に泊まり込んで仕事をします。会社は「不夜城」と 呼ばれ、開発者は「企業戦士」であるという自覚が育ってきます。文字通り 「戦士」なのです。この連帯感はまさに軍隊のそれです。なぜこんな生活を続 けられるのかというと、彼らは戦士であり、戦士は通常の市民とは違うからで す。ソフトウェア開発は戦士でなくては勤まらないからであり、逆に戦士であ ることを誇りに思っています。
軍隊式の洗脳と言うのはオーバーにしても、学園祭の準備と言うと共感できる 人も多いのではないでしょうか。学校に泊まり込みで立て看板を書いたり屋台 の台をつくったりして準備するのは、なかなか楽しいものです。そして学園祭 が終わったら楽しい打ち上げが待っています。こんな生活だったら、別に休息 などいらないとさえ思えてきます。
デスマーチで洗脳されると、人は「デスマーチから抜け出そう」という意識を 持てなくなってしまいます。こうした環境について行けない人をどんどんふる い落としながら、ますますデスマーチに向かって進んでいきます。デスマーチ はいったんはまるとなかなか抜け出せない死の沼なのです。
デスマーチが進行すると、そこに適応できない人の士気が低下し、適応できた 人の士気は向上します。この差がトラブルを引き起こします。ハイになった人 にとって、なぜこの期に及んでやる気をなくしている人がいるのかが理解不能 なのです。
冷静に考えれば、士気の低下は当然です。残業続きで休みもロクにとれず、い くら開発してもいっこうに先が見えないからです。士気の低下の一番の理由は 休みがないことではなく、先が見えないことです。そして先が見えない原因は リーダーが近視眼的で、大局的な道筋を示す度量がないからです。「リーダー の無能のせいで自分がこんな苦労をさせられている」と思ってしまうと、士気 はどんどん低下していきます。
デスマーチ的な組織にいると、うまく行くということがありません。「完成し た！やった！」ではなく「はぁ、やっと終わった。今度はもっとうまくやろう」 という体験しかできません。そして、そう思って次のプロジェクトを迎えても、 やっぱりうまく行きません。それが繰り返されると、だんだん自分が嫌になっ てきます。
部下がこんな状態になると、デスマーチに適応している上司は自分なりの方法 で士気を上げようとします。飲みに連れていくとか、ハッパをかけるとか。し かしこんな方法はかえって傷を深めます。部下が欲しいのはそんな精神論では ありません。デスマーチを収束させるための具体的な方策を考えてほしいので す。そんな時に精神論ばかりを唱えても考え方の違いを痛感させるだけです。 結局「この人たちにはまったくついていけない」と辞める原因を作ることにな ります。
「ここで頑張って仕事しても無駄だ」と思われたら、どんな説得も脅しも効を 奏しません。「奴の言うことはデタラメだ」と思われたら、何を言っても本 人の耳には入っていきません。精神論には論理性がありませんから、何を説い ても「体育会系バカが何かわめいている」と思われるだけで、本人の耳には入っ ていきません。
せめて、あまり追い詰めず「価値観が違う」で片付けてあげてください。そう すればせいぜい会社を辞めるくらいで済みます。そうでなければ、おそらく自 殺にまで追い込まれるでしょう。
デスマーチの直接的な原因は明らかです。もともと無理なプロジェクトなので す。本来なら、話があった時に「それは無理です。そんな仕事はお請けできま せん」と言うべきなのです。
無理なプロジェクトが走ってしまう第一の原因は、無理かどうかの見極めがで きないことにあります。つまり先を見通す能力の欠如です。あるいは無理かど うかの判定すらしないこともあります。つまり上から言われたことにノーと言 える機会がないということです。
しかし、無理なプロジェクトをすべて断っていたら仕事がなくなってしまうか もしれません。時には無理を承知で引き受けなければならないこともあるでしょ う。こんな時に必要なのは「無理を承知する」ということです。そして、無理 を通すための手立てを考えます。これはただ「頑張る」というだけではありま せん。言葉は悪いですが「妥協する」ということです。
開発者に「無理だ」と言われたプロジェクトに対して「そこを何とかお願いし ます」と言ったとき、「わかりました。なんとかしましょう」とだけ言われた としたら、何かが根本的におかしいことに気がつくべきです。なんとかできる ということはつまり無理ではなかったということです。「わかりました。その かわり……」と何らかの妥協条件がつかなくてはなりません。
デスマーチは外から見ていると非常に恐しいものです。「あの人たちは過労で 死にやしないか」とヒヤヒヤします。そして実際に死人すら出ます。しかしそ んな戦場を何度も経験してそれでも脱落しなかった優秀な兵士にとってみれば、 これは日常であり、疑問にすら思いません。「戦場とはそんなものだ」で済ん でしまうところに本当の恐しさがあります。
デスマーチは再生産されます。毎回新入社員をしごいてふるい落とし、デスマー チに耐えられるだけの屈強な男を育て上げます。デスマーチを誇りに思うまで に洗脳された彼らは次の新入社員を自分たちと同じように育て上げます。
この仕組みが回っている限り、デスマーチは止まるわけがありません。旗振り 役の人間には止めようという意思がありませんし、止めようという意思を持っ た人間は旗振り役に昇りつめる前に脱落してしまうからです。
まず何より大事なことは「デスマーチを止めよう」という気構えです。おかし いことはおかしいと言うことです。「ソフト開発なんてものは徹夜が当たり前 だ。怠け者は社会人失格だ」なんて言う狂人のたわ言には耳を貸さないことで す。
プロジェクトメンバーが皆徹夜して、会社に何泊もしながらボロボロになって 仕事をしているような所にいると、これは案外難しいことです。プロジェクト のために身を捧げている人に向かって「あんたはバカで無能だ」と言うことだ からです。しかし言わなければいけません。 [1]
しかし、どこの世界にもバカで無能な人間と優秀な人間はいます。なぜソフト 業界だけこうなってしまうのでしょうか。それはソフトウェア開発の特殊性に 原因があります。
ソフト開発という仕事は、個人の能力によって生産性に大きな差が出ます。能 力の低い人と高い人の差は10倍とも言われています。「10倍も生産性が違う」 というのは信じられないかもしれませんが、「ベテランが仕事の片手間に1時 間で書けるPerlスクリプトと同じ処理をするプログラムを作るのに、新米プロ グラマだと1日(10時間)かかる」と言えば、何度か経験することです。あるい は「1日で書いたプログラムのバッファオーバフローがらみのバグ取りに1週間 以上かかる」なんてこともよくあることです。バッファオーバフローなどとい う基本的なバグを決して混入させないベテランなら1日で完成させられるプロ グラムが、バグ取りのために10日かかったということです。開発期間はプログ ラマの腕によって10分の1に短縮されるのです。
ですから、ソフト開発の期間の見積は、他社はまったく当てになりません。 「A社は10日でできると言っていた」といっても、もしA社が最高レベルで自分 の社が最低レベルだったら、自分のところでやったら100日かかるわけです。 ソフト開発では、技術者の質を考えずに単に人月だけで計算すると予想を大き く外れてしまいます。
生産性は人によって、あるいは社によって大きく違うにもかかわらず、ソフト 開発の期間見積もりはたいてい人月で数えられます。これは大間違いです。 「誰の」人月なのかを考えないといけません。
困ったことに、(特に受注ソフトでは)ソフト開発の対価は開発期間で測られて しまいます。B社だと開発に100日かかるソフトをA社が10日でできたとしても、 それに対して同じ対価を支払ってはもらえません。本来ならベテランは新米の 10倍の給料をもらえてしかるべきなのに [2] 、実際にはそんなことはほとんどありません。
こんな状態が続くことで、開発費用のダンピングが始まります。B社で10人月 と見積る仕事は、A社は1人月でできるわけですから、価格競争でB社が勝てる わけはありません。A社が1人月200万円などという非常識な高コストで見積っ たとしても、B社は1人月20万円というあり得ない低コストの見積りを出さざる を得ないのです。A社はちょっとボーナスを我慢するだけでいくらでも見積り を下げることができるのに対して、B社はすぐ労働基準法が問題になるレベル に突入します。
ソフトウェア開発の対価を計算する場合には、人月に単価を乗じて計算しては いけません。あるいはこう計算するなら、単価がとんでもなく高額になっても 驚かないことです。知識と技術と能力の集積に対してお金を払っているのであ り、労働時間に対してお金を払っているのではありません。
ソフトウェア開発が他のモノの開発と違う部分が一つあります。それは、開発 者の能力がすべて「開発時間」あるいは「コスト」に効いてくることです。 もちろん一部の最先端ソフトには例外もありますが、大部分のソフトはそうで す。
普通のモノでは技術者の能力は出来てくるモノの性能に関係します。例えば優 秀な技術者が設計したエンジンは20%効率が良くなるとか、CPUの処理が20%速 くなるといったようにです。しかし、多くのソフト開発ではこうした性能要件 が存在しません。ウェブの買物カゴの処理が20%遅くても誰も困りませんし、 集計処理に今まで3秒かかったものが2秒になってもあまりうれしくありません。 メモリもハードディスクも多少余計に使おうがほとんど困りません。
コンピュータの高速化に対して、我々が本当にしたい処理というのはそれほど 増えていません。CPUの速度はこの10年で100倍になりましたが、従来と同じア プリケーションならば扱うデータ量はそれほど増えてはいません。10年前から 会計処理をPCでやっていたとして、同じ会社で扱う伝票の数が10年で100倍に 増えたなどという景気のよい話はなかなかありません。だから、同じように会 計処理をPCでやるなら、コンピュータの処理速度というのは余りに余っている わけです。
そうすると、ソフトの価値は何で測ればよいのでしょうか。「処理が速い」と か「メモリを喰わない」とか「ハードディスクが少なくてすむ」といった性能 要件がどれも意味をなさなくなった今、関係してくるのは「使いやすさ」とい う漠然とした総合指標を除けば「機能の多さ」と「信頼性」、そして「安さ」 です。「機能の多さ」というのは量の問題ですので、開発期間をかければいく らでも増やすことができますし、信頼性は十分に期間をかけてテストをするこ とで減らすことができます。
つまり、ソフトというのは時間さえかければいくらでも良くなるということで す。「世界最高性能の自動車エンジン」はヘボ技術者をいくら集めても完成さ せられませんが、「世界最高性能のワープロソフト」はヘボ技術者でも時間さ えかければ [3] 完成させることができます。なぜなら、今やワープロソフトの「性能」とは機 能の多さとバグの少なさであり、それ以外のことは問題にはならないからです。 [4]
まとめます。ソフトの価値は開発量だけで測られます。開発量に現れない「質」 の問題はソフトには存在しません。ソフトの場合は他のモノとは違って、時間 さえかければいくらでも良いものが出来てくるのです。
ソフト開発者の能力は、単位時間あたりの開発量だけで測られます。なぜなら、 ソフトには「開発量」以外の付加価値をつけることができないからです。いく ら優秀な人でも、他の人にできないことができるわけではありません。単に他 の人にとって時間がかかることがすぐできるというだけです。
ですから、ソフト開発では能力による差別化がしにくいのです。「それは私に はできない」とは言えません。なぜなら時間さえかければどんなソフトでも開 発できるからです。
ソフト開発ではベテランと新米には10倍の能力の開きがあります。本当はこれ はソフト開発に限らず、どの業界でもそのくらいの開きはあるのです。しかし 他の業界では、その差は「新米にはできないような仕事ができる」という結果 になって表われます。ソフト業界の問題は、新米でも10倍の時間をかければベ テラン並のものが出来てしまうことにあります。
ソフト開発を「人月」で測る限り、徹夜することでその人の能力は向上します。 1日8時間働く人に対して、1日16時間働く人は2倍の能力を持っていることになっ てしまいます。自分の能力を倍増させるには、最先端技術の勉強も何も必要な く、単に倍の時間働けばいいだけです。だから「難しいことを考えないで、と にかく徹夜して仕上げよう」となってしまうのであり、いつまでたっても徹夜 が続くのです。
なぜソフト業界にだけデスマーチが顕著に現れるのかをお話ししました。他の 業界とは違って、この業界では不可能がないからです。
軍の行軍に例えて言えば、普通の業界なら高い山や海、広い川があって「今の 装備ではこれ以上進むことができない」という状況が存在します。そこで立ち 止まって、基礎技術を研究するなり対策を考えるなりします。しかしソフト業 界はだだっ広い平原のはるか遠くに目的地が見えているようなものです。とに かく歩きさえすればいつかたどり着けます。が、いくら歩いてもちっとも近づ いた気がしません。「この距離を徒歩で進むのは無理なのでは？やっぱり馬が 必要だったのではないか」と言っても「弱音を吐くな。前に進めばいつかは着 く。ほら、目的地は見えてるじゃないか」と言われておしまいです。その結果 「前に向かって歩く」以外の選択肢を考えることができなくなってしまいます。
この問題を解決するには、量の問題を質の問題に転換しなくてはなりません。 「できるけど非常に時間がかかる」ということを「できる」ではなく「できな い」に分類することです。ソフトの世界では、時間さえかければできないこと はありません。
ここでは、プロジェクトの予定について話をします。予定とはつまり、やるこ ととやらないことを分け、いつまでにやるかを決めることです。そして、予定 にない事はたとえできる事であってもやらないことにします。
まず、一切の主観を排除した、客観的な目標を定めることが必要です。客観的 な目標とは、そこに到達した時に「間違いなく到達した」と言えることです。 状況によって目標が動かないことです。
プロジェクトの始めに、まず目標を立ててください。そして開発が終わりに近 づいたら、責任感のない怠け者になって、自己弁護をしながら現状を常に良い 方へ解釈するのです。「ほら、これでもう当初の目標は達成しているよ。そん な機能はもとから目標になかったのだから、付け加える必要なんてない」と。 もし、これに対して「こんな考え方ではろくでもない製品になってしまう」と 思うようでしたら、それは考え方が悪いのではなく、目標の立て方が悪いので す。目標がろくでもないから、目標を達成しただけでは「ろくでもない製品」 になってしまうのです。「素晴らしい製品」を目標に掲げれば、当初の目標を 達成しさえすれば素晴らしい製品が出来上がります。
「お前は製品をちょっとでも良くしようという気がないのか！」と言う人は、 目標を自分で遠くに動かしているのです。こんなことを繰り返している限り 目標には決して到達できません。「製品を少しでも良くしよう」という考え方 はソフトウェアでは害悪です。他のモノと違って、ソフトウェアは時間さえ かければいくらでも良くなるからです。キリがありません。
客観的な目標を設定しないプロジェクトでは、プロジェクトの終了はリーダの 胸先三寸です。リーダが進み続ける限り行進はどこまでも続きますし、「行進 やめ！」という号令をかけさえすればそこがゴールになります。プロジェクト 開始時点で見えている目標は遠くの山々であり、そうした山々は近くに到着し てみると見えなくなってしまいます。すると見えない「目標」を捜してさまよ い歩き、ついに力尽きて倒れた時に「ここが目標だったということにしよう」 と勝手に納得して行進をやめます。「目標地点＝力尽きた地点」という定義な のですから、力尽きないで目標に到達することは不可能なのです。
例えば、知り合いの外国人に「一番東京らしい所へ連れていってくれ」と言わ れたら、いったいどこへ案内しますか？皇居？丸の内？新宿？浅草？渋谷？そ れとも秋葉原？どこも東京を語る上では重要なスポットですが、このうちのど こが一番「東京らしい」ということはありません。一番東京らしい所を隅々ま で捜し回って、へとへとになって宿に戻ってきてから、ふと考えます。「そも そも東京らしさっていったい何だったんだろう」と。へとへとになって探し回っ てはみたものの、結局のところ何を探していたのかすら自分でわかっていない ということがよくあります。そんなことで見つかるわけがありません。
まとめます。なによりもまず客観的な目標を立てましょう。漠然とした目標だ と、そこに近付いた時にどこが本当の目標なのかがわからなくなります。
デスマーチは、特に締切が近付いてくると激しくなります。いつもは少しの残 業だけで済んでいたものが、だんだん休日出勤になって、徹夜になって、泊ま り込みになって……と、仕事が増えていきます。そうなるごとに「ああ、こう なる前に始めのうちからやっておけばよかったなぁ」と後悔します。しかし後 悔はまったく役に立たず、これが何回でも繰り返されます。なぜかというと、 デスマーチになるような組織はもともと「始めのうちからやっておく」ことが 不可能だからです。
ちょっと想像してみて下さい。もし万が一、納期の1週間前にソフトが完成し たとしたら、あとの1週間は本当に遊んで暮らせるでしょうか？「まだ納期ま で時間があるんだから、あとちょっと……」ということにはならないでしょう か？もしこうなりそうだと思ったなら、あなたは決して「余裕で完成させる」 ことはできません。なぜなら、余裕を見せるとどんどん目標は遠のいてしまう からです。
自分の負担を減らそうと思ったら、プロジェクトの前半は遊んで暮らすことで す。どうせプロジェクトは納期が来てぶっ倒れるまで終わらないのですし、 (本当の)納期さえ来れば多少の問題点は目をつぶってプロジェクトは終了にな ります。だったら、最初から頑張るのは無駄です。どうせぶっ倒れるのなら最 初のうちに遊んでおいた方がトクです。
デスマーチ的組織にいるなら、余裕はできるだけ見せないようにしなくてはな りません。定時に帰るなどもっての他です。だから、いつまでたっても定時で 帰れるようにはなりません。
デスマーチをなくすには、「残業は偉い」という価値観をなくすことです。残 業はしないに越したことはありません。残業をしている人間は、正規の時間だ けでは自分の仕事をこなせない無能者です。隣の人がどんなに徹夜していても、 自分の仕事が終わったら定時で帰っていいのです。そちらの方がまともな生活 であり、残業続きの方が異常なのです。
プロジェクトの早い段階から密度の高い作業に入れないのには、もう一つ理由 があります。それは、何をすればよいかわからないことです。もちろん最終的 な行き先はわかっています。しかしそれは漠然としてあまりにも遠すぎ、そこ に行くために何をすればよいかがよくわからないのです。
早い段階でする作業は後の仕様変更によって無駄になりやすいという懸念もあ ります。残業を重ねて早目に開発したものが「あ、仕様が変わったよ」という 一言でボツになってしまってはいっぺんにやる気をなくしてしまいます。
なぜこんなことになるかというと、何をしなければいけないかを時間をかけて 理解しようとしないからです。まず、どんなプログラムを作ったらよいかをはっ きりさせることです。わかりやすいところを片っ端から作っていくようなやり 方ではいつまでたっても先が見えてはきません。
細かく具体的な計画をたてましょう。少なくとも朝出勤した時に、今日一 日帰るまでに何をするかが明確に言えるようでなくてはなりません。「もしやっ かいなバグが出て一日で終わらないようだったらどうするんだ」と思う人もい るかもしれませんが、やっかいなバグが出た時のために「残業」という最後の 手段があるのです。やっかいなバグが出なかったら残業をせず定時に帰りましょ う。始めから残業込みで予定を立ててはいけません。
大きなプロジェクトでは、最終的な完成の前にいくつかの予備的な締切を設け ます。「○月○日の時点で××ができていること」という目標をたてます。こ れがマイルストーンです。
マイルストーンを置くことは2つの意味があります。
開発が調子よく進んでいるのか、それとも遅れているのかがわかる。
これから何をしなければいけないのかがわかる。あと何の仕事が残っているの かがわかる。
マイルストーンはあくまで目標であり、本当の締切ではない点に注意してくだ さい。マイルストーンを達成するために無理をするのでは本末転倒です。マイ ルストーンはマラソンで言えば10km地点や20km地点のタイムに相当します。 10km地点のタイムが予定より遅めになりそうだからといって、ここでダッシュ して全力を使ってしまうようなバカげた行いは避けなくてはなりません。
「マイルストーンに間に合わなくてもいい」と言うと、「だったらマイルストー ンなど誰も守らないのでは」と言う人もいるかもしれません。その通り、マイ ルストーンは守るものではなく、普通に開発をすれば自然に達成できてしまう ものです。そうでないとしたら、マイルストーンの設定期間が間違っています。 マイルストーンに向けて頑張るのではなく、最終目標に向けて頑張るのです。 そうしたら自然に守れるようなマイルストーンを設定すべきです。
マイルストーンは客観的でなくてはいけませんが、それがモノ(プログラム)で ある必要はありません。プログラムを順々に作っていくのは悪いやり方です。 そうではなく、まず要求を分析し、仕様を固め、設計をし、それからプログラ ムにかかるべきです。
「客観的な目標を立てるのが大事だ」と言いました。その目標となるのが「仕 様書」です。仕様書とは、何を作らなければならないのかを記述した書類です。
仕様書を書くのを面倒に思う人がいるかもしれません。しかしその理由のほと んどは体裁を気にするから起きることです。仕様書は内部文書であり、体裁を 気にする必要はありません。わかればいいのです。
仕様書は、書いた結果よりも書くという行為そのものに意味があります。つま り、いきなりコードを書き始めるのではなく、まず何を作らなければいけない のかを考えることです。
「ソフトウェア開発では仕様はすぐ変わるから、仕様書は書くだけムダだ」と 言う人もいます。これは実態をよく表していますが、真実ではありません。な ぜ仕様がすぐ変わるかというと、仕様の書き方が悪いからです。確かにすぐ変 わるような仕様書は書くだけムダです。結論は「仕様書を書かない」ではなく 「変更の必要がないようなしっかりした仕様書を書く」でなくてはなりません。
ソフトウェア開発で本当に仕様変更は避けられないことなのか、よく考えてみ て下さい。なぜ仕様変更があるのでしょう？仕様が決まってから次に仕様変更 があるまで、我々はいったい何をしているのでしょう？多くの場合、仕様が決 まってプログラムにとりかかって、おおかた出来たところで仕様の重大な欠点 に気がつきます。もし仕様が決まった時にすぐプログラムにとりかからず仕様 をよく検討したならば、こうした欠点はプログラムを作る前に見つかるはずで す。
プログラムを作っている時に仕様のミスや書き足りない点に気がつくことはよ くあります。これはGUIプログラムで特によく起きます。フォームにボタンや フィールドを配置して画面を作った時点でなんとなく仕様ができたような気に なってしまう人が多いからです。画面デザインだけでは情報が足りなさすぎま す。ほとんどの場合、仕様はあまり深くまで掘り下げられず、「このボタンを 押すと○○を行う」で済まされてしまいます。
本当は「○○」をどうやって行うのかを詳しく書くことが必要なのです。 仕様は絵と文書で記述されるため、どんなあいまいな記述でもできてしまいま す。仕様を詳しく書かないからそこにある大きな論理的矛盾や間違いを発見で きず、プログラムという厳密な記述をして初めて仕様の間違いが発見されるの ようになるのです。
仕様を単に書くのではなく、細かく検討してください。直観に頼るのではなく 論理的な裏付けが必要です。「こんな画面を表示させよう」という時に、「な ぜその画面でなくてはならないのか」という理由付けをします。いろいろと考 えられる他の形式の画面ではなく、なぜその画面なのかという理由です。そし て、単に画面の絵を書いて「○○をする」で終わるのではなく、あいまいさが なくなるまで詳細に書かねばなりません。
仕様を考える際の根本となるのが「何をしたいか」です。例えば「在庫を管理 したい」「業務の損益を計算したい」「エレベータを制御したい」というよう にです。そして、これを具体的に詳細化したものが「アプリケーションロジッ ク」「ビジネスロジック」「ビジネスモデル」といった言葉で呼ばれるもので す。
アプリケーションロジックはよく軽視されます。仕様書を見ると、「はじめに」 の章にある「在庫を管理したい」という一言の次に、在庫管理画面や入力画面 が並んでしまっています。いきなり画面を考える前にしなければならないこと があります。それは「在庫を管理するとはどういうことか」という疑問に答え ることです。
アプリケーションロジックが固まっているなら、仕様の変更は起きるはずがあ りません。「こういうことがしたい。だからこういう画面を作ってこう処理す るんだ」という順番で仕様を作る限り、仕様変更の起きる余地はありません。 つまり、確固たる土台から始め、そこから正しい論理展開で仕様を作っていく ということです。
すると問題は、「こういうことがしたい」の部分が変わるのかどうかになりま す。もし「在庫管理がしたい」が急に「会計処理がしたい」に変わるのなら、 これは単なるクライアントのわがままです。制作中に法律が改正されて消費税 が外税から内税になることもあるかもしれません。しかし逆に、このような例 外を除けば、仕様が途中で変更になることはないはずです。
まず「何がしたいのか」をはっきりさせてください。それがアプリケーション ロジックです。これはUMLではクラス図で表現されます。その後で、「それを 実現するためにはどうすればよいか」を考えます。
多くのプロジェクトでは、仕様書は一人で書きます。これがそもそもの間違い です。このようにすると、仕様書は一人で書けるほどの簡単なものしか出てき ません。それより何より、仕様は成果物に意味があるのではなく、書くことそ のもの、つまり仕様について考えることに意味があるのです。仕様書は、誰か が書いてそれを下々の者に渡すのでは意味がありません。開発に携わる本人が 書かなくてはいけません。
一人で作った仕様には様々な思い間違いや過度の省略が含まれています。例え 最初は一人で作ったとしても、それを多人数で一度レビューすべきです。そし て、仕様書の書き足らないところや変なところを直していきます。
仕様書のレビューがないと、書き足らないところは発見できることもあります が、仕様の間違いは発見することができません。なぜなら仕様は「プログラム をこう作れ」というゴールを決めるものであり、絶対的なものだからです。下々 の者にとっては「正しい」とは「仕様通りである」と同義です。そこでいくら 「仕様が間違っていると思ったら言ってください」と言っても、それが実際に 挙がってくるはずがありません。「仕様が間違っている」というのは彼らにし てみれば言葉の矛盾だからです。
仕様書は、プログラミングというステージに移行する前に、徹底的に見当すべ きです。
仕様が「変更された」と捉えるのは間違いです。変更されたのではなく、今ま で仕様だと思っていたものが間違いだったのです。仕様変更が頻繁にあるとい うことは、今まで仕様だと思っていたものが実は間違いだらけだったというこ とです。
「これでいいかどうかはプログラムを作って動かしてみないとわからない」と 言う人もあるかもしれません。確かに、デザインやユーザインターフェースの 部分で一部そういった事があるのは認めます。しかし大部分はプログラムを動 かしてみなくても少し考えてみればわかります。今までわからなかったのは、 考えてみるということをしなかったからです。
ほとんどの人は、「今考えなくてもそのうちわかるさ」と考えることを放棄し てしまいます。そして後になってわかって大騒動になった時に「ソフトウェア 開発とはこういうものだ」と自分で自分をごまかしてしまいます。ソフトウェ ア開発とはそういうものではありません。「考えるよりまず行動」というのは 良いスローガンにも見えますが、それは愚か者のすることです。
デスマーチというと、しっかりした組織がなく慣れ合いで成り立っているよう な組織を連想しがちです。しかし多くの場合それは違います。むしろ、しっか りと管理され、やれ開発工程だ何だとうるさい大企業の方が危険です。
なぜしっかりとした大組織の方が危ないのかというと、柔軟性に欠けがちだか らです。立ち止まったり、柔軟に方向を変えたりする能力を失いがちです。中 の人にとって、追い立てられるままに前に歩くことしかできない組織だからで す。
開発の時にコーディング規則や要作成書類などの様々な規約を設けるのは悪い ことではありません。しかしそれはすべてソフト開発にとってプラスに働くも のでなくてはいけません。しかし、「ソフト開発にプラスになるからルールを 守る」ではなく「ルールを守れと言われたから仕方なく守る」になりがちです。 ルールを作る部署はそれを守る部署より力関係が上である場合が多く、それが 問題をいっそうこじらせます。
せっかく作ったルールが守られない時、ほとんどの場合、ルールを作った部署 なり人が高圧的に「ルールを守れ」と押し付けます。人々がルールを守らない のは、そいつがバカだからだと思っています。これは間違いです。ルールが守 られないのにはそれなりの訳があります。
まずすべきは「なぜこのルールを守れないのか」を調査することです。この時、 「なぜルールを守らないんだ。申し開きをしてみよ」という態度ではいけませ ん。ルールを義務としてとらえてはどうしても押し付けになってしまいます。 ルールは守らせるのではなく、自発的に守りたいと思ってもらうことが大切で す。
ルールが守られないのは、そのルールが良くないからです。ルールを守るより、 ルールを守らない方がスムーズに開発できるからです。だから、「なぜルール を守らないのか？」ではなく「このルールのどこが良くないと思いますか？」 と聞かないといけません。ルールが守られなかったならば、そのルールはどこ か悪いのだという前提に立たなければなりません。
守ろうと思わなければ守れないようなルールは、実際の開発では使いものにな りません。実際の開発ではそんな暇はないし、うっかりミスを防ぐことができ ません。ルールや規約というものはあくまで開発の助けになるものであり、開 発の妨げになるようなものであってはいけません。
規約を守らない本当の理由の一つに「面倒だ」という理由があります。これは ルールを義務としてとらえるととても口では言えない理由です。しかしルール を作る側にとってはこれは重要な情報です。「面倒だ」というのは、その手間 が現に開発の妨げになっているということです。守るのが面倒なルールは問題 です。「面倒でも守れ」と言うのではなく、面倒でなくなるような方法を考え なくてはなりません。
似たような話にライブラリの話があります。「プロジェクトのために基礎ラ イブラリを開発した。標準化のためにはこれを使え」と命令するのは間違いで す。その中身ではなく、命令するのが間違いなのです。基礎ライブラリを用意 したのなら、わざわざ命令しなくても皆が「便利だ」と喜んで使ってくれるは ずです。皆が使わないのであれば、それはそのライブラリがクズだからです。 強制しないと使ってもらえないようなライブラリは捨ててしまうべきです。
特に大企業では、一つのプロジェクトにある一定の人数を割当て、そこに「仕 様作成者」「設計者」「コーディング」というように役割も割り当てます。こ れは間違ったやり方です。
なぜなら、開発の時期によって必要な仕事の種類が変わってくるからです。最 初は見積もりや計画、仕様作成の仕事が多く、それからだんだん設計、コー ディング、テストへと仕事の内容が移り変わってきます。だから、ある人にあ る固定的な役割を割り当ててしまうと、その人の仕事量にムラができてしまう ことになります。
本来なら、プロジェクトの初期では人はあまり要らないので少人数で始め、開 発が進むにつれてだんだん人を増やしていくべきです。しかし多くの場合は部 署ごとにプロジェクトが割当てられ、それが硬直化してしまっているせいで、 開発の初期段階から一定の人員が割当てられてしまいます。これでは暇になる 人と忙しい人にムラができてしまい、効率的ではありません。
ほとんどのプロジェクトでは、見積もりや計画、仕様作成や管理の仕事が軽視 されています。ひどい所になると、これ全体をプロジェクトリーダーが一人で 行うことさえあります。プロジェクトの最初のこの部分の仕事いかんによって、 プロジェクトがデスマーチに陥るかどうかが決まります。この仕事は片手間に やれるような仕事ではありません。ある程度の人と期間を投入してきちんとや る必要があります。
プロジェクトに携わる人数や役割は流動的でなくてはなりません。そうでない と、実際にはすることのない暇な人が出てきてしまいます。暇なだけならまだ いいのです。忙しい人は、暇な人が憎いのでそういう人に無駄な仕事を割当て てしまいがちです。無駄な仕事とはつまり、仕様変更などが起きて後でもう一 度やり直しになりそうな仕事です。
前述の「仕様変更がある」という問題がまた出てきました。本来なら、仕様が 固まるまでプログラマを呼んではいけないのです。しかし、プログラマが暇な のが憎いとか、客に動くプログラムを早く見せたい [6]
という下らない理由で、固まってない仕様を基にプログラムの作成に入ってし まいます。こんな仕事を押し付けられた方はたまったものではありません。こう ならないように、暇な人はこのプロジェクトとは別の仕事をやってもらう必要 があります。
結論。プロジェクトには必要に応じて人員を自由に入れたり外したりできるよ うにしなければなりません。プロジェクトリーダは、人事権を持つ(あるいは 人事権を持つ人に自由に要請できる)ことが必要です。もし固定メンバーにす るなら、少なくとも仕事の内容を変えなくてはなりません。
硬直化したプロジェクトでは、すべての決定が絶対視されます。開発規約が絶 対視されたり、メンバー構成が絶対視されたりすると今まで述べたような問題 が生じます。同様に、仕様や期日も絶対視すると問題が生じます。
ソフトの場合、開発期間を短縮するには、次のいずれかの方法しかありません。
人員を増やす
作業効率を上げる
作業を減らす
作業効率を上げることが出来ればいいのですが、それもなかなかできません。 ですから、開発期間の短縮のために簡単にできることといったら、作業を減ら す他ありません。つまり、開発期間と作業はトレードオフの関係にあります。
「このままでは納期に間に合わない」という場合、できることは3つしかあり ません。
納期を延ばしてもらう。
機能を削減する。
テスト作業を省略する。 [7]
「納期を延ばしてもらう」「機能を削減する」はともにプロジェクトの変更で す。言い換えれば、前にした約束を破ることです。硬直化した組織では、こう したことは絶対にしようとしません。しようとすると「約束を破ることは絶対 にしてはいけない。信用を無くしてもいいのか」と怒られます。
これに対して、テストの省略は言わなければ、そしてバグが出なければバレま せん。ですから、納期が間に合わない時にはテストが省略されてしまいます。 そして、この事が明るみになった時にもっと信用を落とします。
結局のところ、約束が守れそうにないとわかった時に「約束が守れそうにない」 と言わないことほど信用を無くすことはありません。これは多くの会社の不祥 事を見ていればよくわかります。正直は最良の策であり、本当のことを包み隠 さず言う人は、例えそれが悪い知らせであっても信用を落とすことにはなりま せん。 [8]
「お客様は神様です」という言葉で、クライアントの言うことを何でも聞き入 れようとするプロジェクトは失敗します。それぞれの「言うこと」が小さな改 良の時にこれは起きやすくなります。「このくらいの改良はすぐできます」が 何百も積み重なることで「できません」になってしまうのです。繰り返しにな りますが、ソフト開発では「できない」はありません。しかし、「できる」こ とが積み重なるとそのうち徐々に「残業すればできる」「徹夜すればできる」 「一週間会社に住み込めばできる」に変わってきてしまいます。これがデスマー チです。お客様の言うことを絶対視し、決してノーと言わないことから起こる 悲劇です。
お客様の言うことをすべて聞いていては身が持ちません。だから、要求には優 先順位をつけるべきです。「この機能があると非常にありがたい」から「確か にあるとうれしいけどなくてもあまり困らない」まで順位をつけ、優先順位が 上の機能から実現することです。
この順位には「実現のしやすさ」を加味してはいけません。なぜなら、「簡単 に実現できるけどあまり深い意味はない」仕様はほぼ無限にあるからです。こ うしたどうでもいい仕様が山と積まれて、本当にやらなければいけない抜本的 な改善が後回しになってしまいます。
細かな改善はある程度で打ち切るべきです。いつまでやっていてもキリがない からです。大手会社の有名なソフトウェアを参考にしましょう。「こんな有名 ソフトでもやっていない事なんですよ。うちらのソフトでもやらなくていいで しょう」と言えば、あまり重要でない機能に対してはおおかた納得してもらえ ます。 [9]
ソフト開発で発生したバグやミスに対して、それがどんなに重大なものであろ うと、始末書を書かせてはいけません。ここで言う始末書とは、ミスをした者 に「ミスの結果、こういう事故が起きてしまいました。再発防止のためには何々 をします」と書類を書かせることです。これは組織を硬直化させ、デスマーチ に行き着きます。
まず、ソフト開発でミスは「起きるものだ」という前提に立たなければなりま せん。始末書というシステムは、「本来ミスはあってはならない」という前提 の上に成り立っています。これは「原発は事故は起きない」などという前提と 同じです。前提が間違っているのです。
再発防止のために「これからは気をつけます」「丹念に確認します」とし か書けないのであれば、それが始末書の無意味さの何よりの証拠です。いくら 確認したところでミスはなくなりません。確認したのと別のところからミスが 出るか、あるいは確認自体のミスが出るかするだけです。
「ミスはあってはならない」という前提では、確認とそれに伴うコストを評価 することができません。それは、ミスによる損失を無限大と定義することだか らです。こう定義してしまうと、ミスを避けるためにはどのようなコストを払っ てもいいことになってしまいます。これは間違いです。ミスによる損失はある 有限な値であり、それを避けるためのコストが損失を上回るならばミスは容認 されるべきです。
始末書などという無意味なものを書かせようとすると、開発者はそれに抵抗し ます。つまりバグやミスを認めなくなります。自分ではわかっていてもそれが 露見するまで放置するか、あるいは誰にも知らせずこっそりと直そうとします。 どちらにしろプロジェクトのためになりません。
プロジェクトにミスはつきものです。それに対して責任論や始末書などを押し つけず、「これに対して何か言いたいことはないか？」とオープンに聞くべき です。責められている立場でなければ、当人はプロジェクトのためになる重要 な提案をしてくれます。なぜならプロジェクトの利益は当人の利益だからです。
柔軟性がない組織とは、自分たちの作ったルールに縛られてしまい、たとえそ れが障害になったとしてもルールを変えられない組織です。つまり、現状を変 えることができないのです。そのせいで、デスマーチにいったん入り込んでし まったらそこから抜け出すことができません。
ルールを絶対視すると視点が近視眼的になります。ソフトを完成させるという 最終目標より、ルールを守るという目の前の目標の方が大事になってきます。 その結果、ルールに追いたてられて前に進むことしかできなくなってしまいま す。
開発者は皆、良いソフトを完成させようと頑張っています。それなのに組織の トップがその最終目標よりルールを守ることを優先してしまいます。これがモ ラル崩壊の原因です。組織は一丸となって同じ目標に向かって進むからこそ成 り立ちます。組織の中のだれかが組織の目標より何か他の目標の方を大事にし 始めると、組織は分裂崩壊してしまいます。
デスマーチに陥らないようにする、あるいは抜け出すために、次のことに気を つけましょう。
デスマーチを避けるようにしましょう。デスマーチを仕方のないものとして受 け入れてはいけません。
長時間仕事をするのは無能な人間である証拠です。上司や同僚に付き合って、 しなくてもよい残業をするのはやめましょう。
頑張ることより、いかにサボるかを考えましょう。頑張ることはバカでもでき ますが、考えることはバカにはできません。
価値観は人と違っていてもいいのです。同じ価値観の人間で構成されているの は宗教団体くらいのものです。
完璧なソフトウェアは存在しません。完璧なソフトウェアを作ることは不可能 です。
ソフトウェアはいくらでも完璧に近づけることができます。しかし、「完璧に 近づく」と「完璧になる」は同じではありません。
ソフトウェアの価値は、それがどれだけ役に立つかで決まります。バグだらけ でも便利なソフトの方が、バグがなくて使えないソフトより価値があります。
ソフトウェアの価値は、それがすばやく提供されるほど高くなります。
行きあたりばったりを避け、行動する前にまず考えるようにしましょう。
考えのない行動よりは、考えるだけで行動しないことを尊びましょう。前者は マイナスの結果をもたらしますが、後者の結果はゼロです。
もちろん、行動を起こさないよりは起こした方がいいに決まっています。
議論を重要視しましょう。「こんな所で話し合うより行動を起こした方がよい」 とは言わないようにしましょう。
行動を起こす前に、その行動の目的を定めましょう。走り出す前に、まず走る 方向を決めましょう。
ゴールを決めましょう。「夕日に向かってダッシュだ！」ではなく、ゴールが わかるように白い線を引きましょう。
ゴールに到達したら走るのをやめましょう。
何を作るのかを決めてから作り始めましょう。何を作ったらいいかもわからな いのに何かを作ろうとしないでください。
何かを全部わかったつもりになっているのは、あまりわかっていない証拠です。
実際に動いているものを見ないとわからないというのは、想像力が欠如してい る証拠です。
後になってからわかることもあります。しかしその多くは初めから考えていれ ばわかったはずのものです。
仕様が本当に途中で変わることはほとんどありません。仕様は変わったのでは なく間違っていたのです。
いくら考えてもまったく進展がないのは、実は考えていない証拠です。下手の 考え休むに似たり。
時間は問題を解決しません。考えなければ結論は出ません。
考えるだけでは答えは出ません。正しい方法で考えないといけません。
理由なく直観だけで結論を導かないようにしましょう。正しい前提から正しい 方法で導いた結論は、間違っていることはありません。
試行錯誤で正しい答えは出せます。しかしそれは一番効率の悪いやり方です。
間違いは素直に認めましょう。
間違いを認めた人を責めるのはやめましょう。そんな事をしても何の得にもな りません。
間違いはあってほしくはないものですが、あってはならないものではありませ ん。
費用対効果を考えましょう。たとえそれが良いことであっても多大なコストが かかることならやらない方がいい事もあります。
ルールは目的を達成するためにあるものです。ルールそのものが目的になって しまってはいけません。
悪いルールを守ってはいけません。
ルールが破られるのは、それが悪いルールである証拠です。もちろん、そのルー ルの意味が十分理解されているという前提での話ですが。
不可能なことはどれだけ頑張っても不可能です。
不可能を可能にするには、それなりの理由が必要です。
何よりもまずプロジェクトの成功を考えましょう。行動に対する価値評価は、 それがプロジェクトの成功につながるかどうかで決めるべきです。
無能を悪意にとるのはやめましょう。仕事をやらないのではなく、仕事ができ ないのです。
無能な人に仕事を押し付けるのは無責任です。いくら強制しようと、できない 人にはできないのです。
毎日決められた時間に帰るようにしましょう。それで仕事が終わらなければ、 仕事を割り振った人が悪いのです。
毎日決められた時間は仕事をするようにしましょう。仕事がなかったら他の人 のをもらいましょう。
「今日は無礼講だ」と言わないで、毎日を無礼講にしましょう。
相手がどう思っているかわからない時は、聞いてみるのが一番です。
自分にできないことはできないと認めましょう。
| [1] | もしこれでクビになったとしても、長い目で見ればそれはあなたのためになる でしょう。そのまま死へと突き進むのに比べれば。 |
| [2] | 「ベテラン」というのは単に年の差だけを意味しません。プログラミングにつ いてのスキルは、大学を出て会社に入った時点で既に天と地ほど違います。大 学時代に自分でフリーソフトを作っているような猛者と、適当に論文をでっち 上げただけでほとんどプログラムも書いたことのないような連中を比べてごら んなさい。たとえ同じ情報工学科卒でもです。 |
| [3] | そしてその間に別のチームに追い抜かれなければ、ですが。 |
| [4] | 多くの場合、「使い勝手」すら問題になりません。ワープロに使い勝手を求め るようなコアなユーザは今やごくわずかです。でなければあんなソフトがシェ アをとれるわけがありません。 |
| [5] | もし残業や徹夜を前提とした計画を立てないと間に合わないのでしたら、い くら残業が厳しかろうと何日徹夜しようとそれはデスマーチではありません。 もともとの計画通りであり、順調に行っている証です。 |
| [6] | 客が喜ばないことを実行できないのは、デスマーチが起きるチームの典型です。 動くプログラムを早く見せればその場は喜ばれるかもしれませんが、それから 長いこと紆余曲折があったり進展がなかったりするとかえって不信感を持たれ ます。 |
| [7] | 開発作業には「仕様分析」 「設計」「コーディング」「テスト」などの様々な段階があります。このうち、 分析や設計は省略するとかえって混乱しますし、コーディングはしないとモノ が出来てきません。よって、作業を省略できるとしたらテストを省略すること だけです。 |
| [8] | 正確に言えば、「約束が守れそうにない」という事実を明らかにするのは、信 用が落ちるのではありません。事実以上に過度に評価されていたものが適正に 戻ったというだけです。 |
| [9] | 大昔の話ですが、文字入力のところでバックスペース以外のカーソル移動がで きない言い訳に「MS-DOSでさえできない」がよく使われました。実際、たいし て入力もされない場所にこれを要求される事がしばしば起きました。 |