柔軟性

デスマーチというと、しっかりした組織がなく慣れ合いで成り立っているよう な組織を連想しがちです。しかし多くの場合それは違います。むしろ、しっか りと管理され、やれ開発工程だ何だとうるさい大企業の方が危険です。

なぜしっかりとした大組織の方が危ないのかというと、柔軟性に欠けがちだか らです。立ち止まったり、柔軟に方向を変えたりする能力を失いがちです。中 の人にとって、追い立てられるままに前に歩くことしかできない組織だからで す。

規約遵守

開発の時にコーディング規則や要作成書類などの様々な規約を設けるのは悪い ことではありません。しかしそれはすべてソフト開発にとってプラスに働くも のでなくてはいけません。しかし、「ソフト開発にプラスになるからルールを 守る」ではなく「ルールを守れと言われたから仕方なく守る」になりがちです。 ルールを作る部署はそれを守る部署より力関係が上である場合が多く、それが 問題をいっそうこじらせます。

せっかく作ったルールが守られない時、ほとんどの場合、ルールを作った部署 なり人が高圧的に「ルールを守れ」と押し付けます。人々がルールを守らない のは、そいつがバカだからだと思っています。これは間違いです。ルールが守 られないのにはそれなりの訳があります。

まずすべきは「なぜこのルールを守れないのか」を調査することです。この時、 「なぜルールを守らないんだ。申し開きをしてみよ」という態度ではいけませ ん。ルールを義務としてとらえてはどうしても押し付けになってしまいます。 ルールは守らせるのではなく、自発的に守りたいと思ってもらうことが大切で す。

ルールが守られないのは、そのルールが良くないからです。ルールを守るより、 ルールを守らない方がスムーズに開発できるからです。だから、「なぜルール を守らないのか？」ではなく「このルールのどこが良くないと思いますか？」 と聞かないといけません。ルールが守られなかったならば、そのルールはどこ か悪いのだという前提に立たなければなりません。

守ろうと思わなければ守れないようなルールは、実際の開発では使いものにな りません。実際の開発ではそんな暇はないし、うっかりミスを防ぐことができ ません。ルールや規約というものはあくまで開発の助けになるものであり、開 発の妨げになるようなものであってはいけません。

規約を守らない本当の理由の一つに「面倒だ」という理由があります。これは ルールを義務としてとらえるととても口では言えない理由です。しかしルール を作る側にとってはこれは重要な情報です。「面倒だ」というのは、その手間 が現に開発の妨げになっているということです。守るのが面倒なルールは問題 です。「面倒でも守れ」と言うのではなく、面倒でなくなるような方法を考え なくてはなりません。

似たような話にライブラリの話があります。「プロジェクトのために基礎ラ イブラリを開発した。標準化のためにはこれを使え」と命令するのは間違いで す。その中身ではなく、命令するのが間違いなのです。基礎ライブラリを用意 したのなら、わざわざ命令しなくても皆が「便利だ」と喜んで使ってくれるは ずです。皆が使わないのであれば、それはそのライブラリがクズだからです。 強制しないと使ってもらえないようなライブラリは捨ててしまうべきです。

開発ステージと仕事内容

特に大企業では、一つのプロジェクトにある一定の人数を割当て、そこに「仕 様作成者」「設計者」「コーディング」というように役割も割り当てます。こ れは間違ったやり方です。

なぜなら、開発の時期によって必要な仕事の種類が変わってくるからです。最 初は見積もりや計画、仕様作成の仕事が多く、それからだんだん設計、コー ディング、テストへと仕事の内容が移り変わってきます。だから、ある人にあ る固定的な役割を割り当ててしまうと、その人の仕事量にムラができてしまう ことになります。

本来なら、プロジェクトの初期では人はあまり要らないので少人数で始め、開 発が進むにつれてだんだん人を増やしていくべきです。しかし多くの場合は部 署ごとにプロジェクトが割当てられ、それが硬直化してしまっているせいで、 開発の初期段階から一定の人員が割当てられてしまいます。これでは暇になる 人と忙しい人にムラができてしまい、効率的ではありません。

ほとんどのプロジェクトでは、見積もりや計画、仕様作成や管理の仕事が軽視 されています。ひどい所になると、これ全体をプロジェクトリーダーが一人で 行うことさえあります。プロジェクトの最初のこの部分の仕事いかんによって、 プロジェクトがデスマーチに陥るかどうかが決まります。この仕事は片手間に やれるような仕事ではありません。ある程度の人と期間を投入してきちんとや る必要があります。

プロジェクトに携わる人数や役割は流動的でなくてはなりません。そうでない と、実際にはすることのない暇な人が出てきてしまいます。暇なだけならまだ いいのです。忙しい人は、暇な人が憎いのでそういう人に無駄な仕事を割当て てしまいがちです。無駄な仕事とはつまり、仕様変更などが起きて後でもう一 度やり直しになりそうな仕事です。

前述の「仕様変更がある」という問題がまた出てきました。本来なら、仕様が 固まるまでプログラマを呼んではいけないのです。しかし、プログラマが暇な のが憎いとか、客に動くプログラムを早く見せたい ^[1] という下らない理由で、固まってない仕様を基にプログラムの作成に入ってし まいます。こんな仕事を押し付けられた方はたまったものではありません。こう ならないように、暇な人はこのプロジェクトとは別の仕事をやってもらう必要 があります。

結論。プロジェクトには必要に応じて人員を自由に入れたり外したりできるよ うにしなければなりません。プロジェクトリーダは、人事権を持つ(あるいは 人事権を持つ人に自由に要請できる)ことが必要です。もし固定メンバーにす るなら、少なくとも仕事の内容を変えなくてはなりません。

プロジェクトの変更

硬直化したプロジェクトでは、すべての決定が絶対視されます。開発規約が絶 対視されたり、メンバー構成が絶対視されたりすると今まで述べたような問題 が生じます。同様に、仕様や期日も絶対視すると問題が生じます。

ソフトの場合、開発期間を短縮するには、次のいずれかの方法しかありません。

• 人員を増やす

• 作業効率を上げる

• 作業を減らす

ソフト開発で特に問題となるのが、単純に人員を増やすことは逆効果になると いうことです。「遅れているプロジェクトに人を投入するとさらに遅れる」と いう諺があります。投入された人が現在のプロジェクトについていろいろと知 り理解するための時間と手間が必要だからです。さらに、人が多くなればなる ほどコミュニケーションがうまくとれなくなり、開発効率が低下します。

作業効率を上げることが出来ればいいのですが、それもなかなかできません。 ですから、開発期間の短縮のために簡単にできることといったら、作業を減ら す他ありません。つまり、開発期間と作業はトレードオフの関係にあります。

「このままでは納期に間に合わない」という場合、できることは3つしかあり ません。

• 納期を延ばしてもらう。

• 機能を削減する。

• テスト作業を省略する。 ^[2]

「納期を延ばしてもらう」「機能を削減する」はともにプロジェクトの変更で す。言い換えれば、前にした約束を破ることです。硬直化した組織では、こう したことは絶対にしようとしません。しようとすると「約束を破ることは絶対 にしてはいけない。信用を無くしてもいいのか」と怒られます。

これに対して、テストの省略は言わなければ、そしてバグが出なければバレま せん。ですから、納期が間に合わない時にはテストが省略されてしまいます。 そして、この事が明るみになった時にもっと信用を落とします。

結局のところ、約束が守れそうにないとわかった時に「約束が守れそうにない」 と言わないことほど信用を無くすことはありません。これは多くの会社の不祥 事を見ていればよくわかります。正直は最良の策であり、本当のことを包み隠 さず言う人は、例えそれが悪い知らせであっても信用を落とすことにはなりま せん。 ^[3]

仕様の優先順位

「お客様は神様です」という言葉で、クライアントの言うことを何でも聞き入 れようとするプロジェクトは失敗します。それぞれの「言うこと」が小さな改 良の時にこれは起きやすくなります。「このくらいの改良はすぐできます」が 何百も積み重なることで「できません」になってしまうのです。繰り返しにな りますが、ソフト開発では「できない」はありません。しかし、「できる」こ とが積み重なるとそのうち徐々に「残業すればできる」「徹夜すればできる」 「一週間会社に住み込めばできる」に変わってきてしまいます。これがデスマー チです。お客様の言うことを絶対視し、決してノーと言わないことから起こる 悲劇です。

お客様の言うことをすべて聞いていては身が持ちません。だから、要求には優 先順位をつけるべきです。「この機能があると非常にありがたい」から「確か にあるとうれしいけどなくてもあまり困らない」まで順位をつけ、優先順位が 上の機能から実現することです。

この順位には「実現のしやすさ」を加味してはいけません。なぜなら、「簡単 に実現できるけどあまり深い意味はない」仕様はほぼ無限にあるからです。こ うしたどうでもいい仕様が山と積まれて、本当にやらなければいけない抜本的 な改善が後回しになってしまいます。

細かな改善はある程度で打ち切るべきです。いつまでやっていてもキリがない からです。大手会社の有名なソフトウェアを参考にしましょう。「こんな有名 ソフトでもやっていない事なんですよ。うちらのソフトでもやらなくていいで しょう」と言えば、あまり重要でない機能に対してはおおかた納得してもらえ ます。 ^[4]

始末書

ソフト開発で発生したバグやミスに対して、それがどんなに重大なものであろ うと、始末書を書かせてはいけません。ここで言う始末書とは、ミスをした者 に「ミスの結果、こういう事故が起きてしまいました。再発防止のためには何々 をします」と書類を書かせることです。これは組織を硬直化させ、デスマーチ に行き着きます。

まず、ソフト開発でミスは「起きるものだ」という前提に立たなければなりま せん。始末書というシステムは、「本来ミスはあってはならない」という前提 の上に成り立っています。これは「原発は事故は起きない」などという前提と 同じです。前提が間違っているのです。

再発防止のために「これからは気をつけます」「丹念に確認します」とし か書けないのであれば、それが始末書の無意味さの何よりの証拠です。いくら 確認したところでミスはなくなりません。確認したのと別のところからミスが 出るか、あるいは確認自体のミスが出るかするだけです。

「ミスはあってはならない」という前提では、確認とそれに伴うコストを評価 することができません。それは、ミスによる損失を無限大と定義することだか らです。こう定義してしまうと、ミスを避けるためにはどのようなコストを払っ てもいいことになってしまいます。これは間違いです。ミスによる損失はある 有限な値であり、それを避けるためのコストが損失を上回るならばミスは容認 されるべきです。

始末書などという無意味なものを書かせようとすると、開発者はそれに抵抗し ます。つまりバグやミスを認めなくなります。自分ではわかっていてもそれが 露見するまで放置するか、あるいは誰にも知らせずこっそりと直そうとします。 どちらにしろプロジェクトのためになりません。

プロジェクトにミスはつきものです。それに対して責任論や始末書などを押し つけず、「これに対して何か言いたいことはないか？」とオープンに聞くべき です。責められている立場でなければ、当人はプロジェクトのためになる重要 な提案をしてくれます。なぜならプロジェクトの利益は当人の利益だからです。

まとめ

柔軟性がない組織とは、自分たちの作ったルールに縛られてしまい、たとえそ れが障害になったとしてもルールを変えられない組織です。つまり、現状を変 えることができないのです。そのせいで、デスマーチにいったん入り込んでし まったらそこから抜け出すことができません。

ルールを絶対視すると視点が近視眼的になります。ソフトを完成させるという 最終目標より、ルールを守るという目の前の目標の方が大事になってきます。 その結果、ルールに追いたてられて前に進むことしかできなくなってしまいま す。

開発者は皆、良いソフトを完成させようと頑張っています。それなのに組織の トップがその最終目標よりルールを守ることを優先してしまいます。これがモ ラル崩壊の原因です。組織は一丸となって同じ目標に向かって進むからこそ成 り立ちます。組織の中のだれかが組織の目標より何か他の目標の方を大事にし 始めると、組織は分裂崩壊してしまいます。