デスマーチが起きる理由 - ３つの指標

著者： 青い鴉（ぶるくろ）さん @bluecrow2

これは結城浩さんの運用されていた YukiWiki に当時 Coffee 様 (青い鴉（ぶるくろ）さん）がかかれていた文章です。 ただ 2018 年 3 月 7 日に YukiWiki が運用停止したため消えてしまいました。その記事のバックアップです。

今は 404 ですが、もともとの記事の URL は http://www.hyuki.com/yukiwiki/wiki.cgi?%A5%C7%A5%B9%A5%DE%A1%BC%A5%C1%A4%AC%B5%AF%A4%AD%A4%EB%CD%FD%CD%B3 になります。

昔、自分がとても感銘を受けた文章なので、このまま読めなくなるのはとてももったいないと思い、バックアップとして公開しています。

• もしオリジナルの図を保存されていた方いらっしゃいましたら、 Gist にコメントを頂けると嬉しいです
  • http://archive.org/web/ からの図は一番下のコメントを御覧ください
• この記事に対してなにかある場合はこの Gist にコメントをお願いします

この文章に対して私は一切の権利を保持していませんので、この文章の再利用についての質問を頂いても回答はできません。 この Gist はあくまでバックアップ以上の理由はありません。ご理解いただければと思います。

• 2018-05-07  
  • 著者の方が不明だったのですが Twitter とこちらのコメントに著者様からご連絡をいただけました！ とても嬉しいです。著者様のお名前と Twitter ID を明記しました。
  • 図のリンク先がスパムサイトになっているのでコメントを追加し、リンクを無効にしました
  • 図の情報がコメント欄にありますので、もし図が見たい方は一番したのコメント欄を御覧ください

３つの指標

鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ？

スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。

「遅れてすまない」

そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイトボードは真っ白だった。ミーティングは、まだ始まっていなかったのだ。 十数人の同僚たちが私を見つめる中、見慣れない男――背は低く、おせじにもカッコいい奴には見えない――がこちらを見ていることに気づいた。

「あなたがコンサルタントの方ですか？」

私の質問に彼は頷いた。

「その通り。私はジョナサン。君はトム君だったね。すぐ来ると聞いて、君を待っていた。さあ、ミーティングを始めよう。大切なミーティングだ」

彼は矢継ぎ早にそう言うと、中央に戻っていった。何が大切なミーティングだ――席に座って私は思う。こんなものは時間を無駄にしているに過ぎない。

「ミーティングを始めるにあたって、まず現状を確認したい。もらった資料は少し古くなっているからね。誰か、現状を説明してもらえないだろうか」

そう言われて立ち上がったのはアレクサンドだった。少し融通の利かないところはあるが、かなり頭の切れる奴だ。私も一目置いている。

「この販売管理システム開発プロジェクトは、2月の頭から開始しました。当初のプロジェクト完了予定日は、7月末。 つまり、開発期間は6ヶ月と見積もられていました。しかし、今がいつであるかお分かりでしょう。既に10月の半ば……つまり2ヶ月半の遅れが出ています。 早急な……一刻も早い対策が望まれます」

彼の言っていることは、このミーティングに来ている連中ならみんな理解している。理解していないのはあのコンサルタントだけだ。

「一つ質問させてもらいたい。今、『早急な』『一刻も早く』と言ったが、何故なんだね？正確な理由を教えてくれないか」

もう着席するつもりでいたアレクサンドは、突然の質問に少し面食らったようだったが、即座に答えた。

「それは……来年一月からの運用が予定されているからです。運用時にバグが出るといけませんから、最低でも1ヶ月のテスト期間が必要です。 ですから、11月末までには開発フェイズを完了させなければいけません」

それも、みんな分かっていることだ。とにかく時間が足りない。毎日残業しても、まだ足りない。せめて運用が4月あたりに先延ばしになってくれれば、何とかなるのだが。

「状況を整理してみよう。当初は6ヶ月の開発期間を予定していたプロジェクトだが、2ヶ月半もの遅れが出ている。 結論から言えば、これまでに行ってきたであろうマネジメントは、有効に機能していなかったということだ。 誤解を与えないように言っておくが、君たちを責めているわけじゃない。責任だとか、上下関係だとか、そんなことはどうでもいい。 問題は開発の遅れで、我々は解決策を探さなくてはいけない……このミーティングはそのためのものだからね」

私は、資料を眺めるふりをした。馬鹿げたミーティングだ。このプロジェクトを救えるはずが無い。我々は解決策を探さなくてはいけない。 そんなことを言うだけなら誰にだってできる。猿にだって言える。私の上司にだって言えるだろう。……いや、言えないかもしれない。

そんなことを考えていたため、少しの間、彼の言葉は耳に入らなかった。顔を上げると、彼がプロジェクターで何かのスライドを表示するところだった。

『デスマーチ』の現状問題構造ツリー 当時のサイトが無くなってしまいスパムサイトになっています http://www.mikihoshi.com/wiki/index.cgi?page=%A5%C7%A5%B9%A5%DE%A1%BC%A5%C1 「努力、友情、勝利」と書かれたスライドが現れて、彼の御高説が始まるのかと思っていたが、そうではなかった。 表示されたのは、何の変哲も無い付箋紙を矢印で結んだだけの、ツリーだった。上にはデスマーチと書いてある。まさにこのプロジェクトのことだ。

「これは何ですか？」

私の変わりにステーシーが質問した。彼女は知らないことを人に尋ねるのが得意だ。様々な分野の知識を持っている彼女にも、どうやら知らないことがあるらしい。彼はゆっくりと答えた。

「デスマーチの現状問題構造ツリーだ」

「人は、自分が問題を認識していると思っている。全ての前提は頭の中に入っていて、自分は正しい判断をしているのだと信じている。 誰もが自分が一番プロジェクトの役に立っているのだと考えている。 自分が一番難しいモジュールを開発していて、だから一番残業していて、もちろんこのプロジェクトは最大限効率的なのだと信じている。 しかし、私はこう思う。『本当にそうだろうか？』と」

彼が何を言っているのか、最初、よく分からなかった。だが、暗に自分たちの努力を否定されているのだと気づくのに、そう時間はかからなかった。 みんなも同じだったようだ。すぐに、「そんなはずはない」「何を考えているんだ」「俺たちを非難しにきたのか」と野次が飛んだ。

「では、」彼は、小柄な彼は、まるで聞き分けのない学生たちをなだめる教授のような口調で言った。

「確かめてみようじゃないかね？」

「『必要な時に必要なだけのスキルを持った開発者を投入しないと、プロジェクトは遅れる』」彼は言った。そんなこと常識だ。 「これが常識だということは理解してもらえると思う。だが、私がこれまでに見てきたほとんどのプロジェクトでは、 実際にこの常識を尊重してプロジェクト運営が行われているとは言い難い状況だった」

何だって？この常識が守られていない？　言われてみれば……確かにそうだ。

――今、うちの会社で一番問題になっているのは、営業部門だ。とはいっても、今期の営業成績が特に悪かったというわけではない。 大手顧客のほとんどから同じ苦情を言われている、と言えばお分かりだろうか。要するにレスポンスタイムの改善を要求されているのだ。

噂では、速やかに改善しなければ、オーダーを減らすとまで言われたらしい。 まるで脅されているようなものだが、営業部門の業務にかなり時間がかかっていることは否定できない。 そこで、改善計画が持ち上がり、システム部門に話が回ってきたというわけだ。

大量に使われていた紙の書類を減らし、必要な情報全てをデータベースに登録し、情報にどこからでもアクセスできるようにして迅速な営業を顧客に約束する。 そのためにこのプロジェクトは始まった。これっぽっちの人数で、なかなかどうして、社運を賭けたプロジェクトじゃないか。

しかしだからこそ、システムの運用が遅れれば顧客の信用を失い、売上の減少に直結すると言える。

この販売管理システムの開発が始まったとき、私は管理職の連中に、 ユーザ代表と話し合って仕様を決めるSEの数が足りないと不満を言ったことがある。そのとき、彼らは何をしてくれただろう。何もしてくれなかった。

必要な時に必要なだけのスキルを持った開発者を投入してくれなかった。この常識が守られていなかったから、このプロジェクトは遅れたというのか？

もし１月の運用に間に合わなければ、プロジェクトマネージャーの首が飛ぶことは間違い無い。おそらくプロジェクト関係者の昇進の話も無くなるだろう。 そして私も……私は知らずにペンを握り締めていたことに気づいた。

「『管理者は遅れているプロジェクトに必要なスキルを持った開発者を追加することを先延ばしにする』」

一瞬、彼が超能力者でないかと疑った。彼の口から漏れた言葉は、まさに私の考えていたことだったからだ。 その妄想を振り払ってスライドを見ると、彼の持つ棒（どこから引っ張り出したのだろう？）の先には、そう書かれた付箋紙があった。彼の問いかける声が耳に入った。

「『必要な時に必要なだけのスキルを持った開発者を投入しないと、プロジェクトは遅れる』のに、 『管理者は遅れているプロジェクトに必要なスキルを持った開発者を追加することを先延ばしにする』。 これは明らかに矛盾している。こう考えてみよう。『この矛盾は、何故、生まれるのだろうか？』 ……ステートメント（付箋紙）の続きを見てみてくれないか。 『管理者は新たな人員の追加に極めて慎重である』というやつだ。これには同意してもらえると思う。そして、その下にもステートメントがある」

言われて、ステートメントを辿る。すぐに3つのステートメントが目に入った。

『プロジェクト単位でコスト（主に人件費）が集計され黒字or赤字が判断される』 『プロジェクトが赤字であると判断されると追加投資（人員増加）が認められない場合がある』 『プロジェクトが赤字であると判断されると管理者の立場が危うくなる』 最後のステートメントの控えめな表現に、みんなが笑った。吹き出してしまった奴までいる。私も、ここまで控えめな表現は見たことが無い。

みんながステートメントに十分目を通せるだけの時間を置いてから、ジョナサンは口を開いた。

「君たちの会社では、ごく一般的なプロジェクト管理を行っていると思う。 だから『プロジェクト単位でコスト（主に人件費）が集計され黒字or赤字が判断される』にあてはまっているはずだ。 また、『プロジェクトが赤字であると判断されると追加投資（人員増加）が認められない場合がある』にも覚えがあるだろう。 特にルールが無くても、管理者自身がそう決めている場合もある。 そして最後に、『プロジェクトが赤字であると判断されると管理者の立場が危うくなる』だ。特に反論は無いと思う」

その言葉に、みんなが頷いた。もちろんそうだ。みんな常識じゃないか。

「さて、それぞれのステートメントは常識的なことに過ぎないが、下から上に、矢印を辿って読んでみよう。問題が見えてくるはずだ」

本当だろうか？一つ一つのステートメントに違和感は無かったように思うが……私は言われた通りに下から上へと視線を移動させる。 それにあわせるように、ジョナサンはステートメントを読み上げた。

「もし、『プロジェクト単位でコスト（主に人件費）が集計され黒字or赤字が判断される』 かつ『プロジェクトが赤字であると判断されると追加投資（人員増加）が認められない場合がある』 かつ『プロジェクトが赤字であると判断されると管理者の立場が危うくなる』であるとき、 『管理者は新たな人員の追加に極めて慎重である』……ということにはならないかな？」

彼はまた、みんなの理解を待った。

「同様に、もし、管理者から見て『プロジェクト遂行に十分なだけの人員が存在しているように見える』 かつ『管理者は新たな人員の追加に極めて慎重である』とき、 『管理者は遅れているプロジェクトに必要なスキルを持った開発者を追加することを先延ばしにする』」

この因果関係にも異論は無い。

少しの間、沈黙があった。みんな、現状を理解しようと考え込んでいるのが分かる。 一つ一つはたわいもない常識だ。 だが、このステートメントの流れはなんというか、嫌な感じがする。

「ところで、『プロジェクトの人員が増えれば増えるほどコミュニケーション、資料作成ための時間が増え、実質的な開発効率は低下する』という事について考えてみよう。 コミュニケーションや資料作成が無駄だと言っているわけではない、ただ、善悪とは無関係にそういう傾向が存在していることは認めてもらえると思う」

その意見に、みんなが頷いた。 私は、またスライドを見た。こんなに真剣にスライドを見たミーティングは、何年ぶりだろうか。右側のステートメントに目を通す。

「何故だろうか？トム、ツリーを読み上げてくれないか」

いきなりのご指名にいささか狼狽しながらも、私は立った。みんなの顔を見渡して僅かに時間を稼ぎ、その間に考えをまとめる。よし。私は意を決して口を開いた。

「いいでしょう、ジョナサン。『何故だろうか？』との質問ですが、理由はこのツリーを見れば明らかです。 まず、『顧客は納期遅れが不満であり、管理者に絶対の納期厳守を要求する』という当然のイベントが発生します。 私たちのプロジェクトの場合、顧客の部分は営業部門であり、より大局的な視点では経営者であるということになります。 次に、『管理者は慌てて（スキル?を問わずに）開発者をかき集め、遅れているプロジェクトに投入する』ということになります。 これに加えて、『スキル?が低すぎる開発者はスキル?が高い開発者の時間を奪い、明らかに足を引っ張ることさえある』 かつ『一度動員した開発者をプロジェクトのメンバーから除外することは困難』 かつ『プロジェクト内での上下関係は職場の上下関係を反映しており、プロジェクト遂行のために最適化されているとは言い難い』とすれば、 『プロジェクトの人員が増えれば増えるほどコミュニケーション、資料作成ための時間が増え、実質的な開発効率は低下する』ことは明白です」

言い終わって、みんなの視線を一心に集めていることに気づいた。どうして私なんかに注目するのだ？なんとなく気まずさを感じながら、私はそのまま着席した。 やれやれ、こういうのは学生時代だけで十分だ。

「話をまとめてみよう。トムの読み上げてくれたツリーから分かることは、スキルを問わずに『多数の人員を投入すればするほど、プロジェクトは非効率的になっていく』ということだ。それでは納期は守れない」

マネージャー補佐のヨハンが、ジョナサンの言葉に納得出来ない様子で立ち上がった。

「いいや、私は、その前提のほうが間違いだと思うよ。まったくナンセンスだ」

吐き捨てるような言葉に、私は愕然とした。私が読み上げたツリーの内容を、ヨハンはまだ理解していないのだろうか……それとも、理解したくないのだろうか。

ヨハンは言った。

「確かに『管理者は新たな人員の追加に極めて慎重である』が、遅れているならそれをカバーするのは、当然のことじゃないか。人が足りていないからなんだろう？なら、外部から人を連れてくれば良い。これで、『プロジェクト遂行に十分なだけの人員が存在している』」

「実際は、プロジェクト遂行に十分なだけの人員はいません」

アレクサンドが、はっきりとした口調で言った。

「今のままでは何もかも不十分です。特に、Bモジュールの進捗の遅れをカバー出来るスキルを持った開発者が足りていないんです！」

最後のほうは、プロジェクトのメンバー全員が上げた悲鳴のようだった。

「よろしい。つまり、開発者の視点では『プロジェクト遂行に必要となる必須スキルを持った開発者が十分に存在していない』ということだ。 一方、トムの読み上げてくれたツリーから分かることは、スキルを問わずに『多数の人員を投入すればするほど、プロジェクトは非効率的になっていく』というわけだから、 従って、『開発側が求めているのは、少数の高スキル開発者の投入』だということになる。アレクサンド、そうだね？」

先ほどは声を荒げたアレクサンドだったが、今のジョナサンの言葉には満足したようだ。

「ええ、その通りです」

予期せぬ理解者の登場に、彼の声はもう和らいでいた。

「さて、『少数の高スキル開発者の投入』このマネジメントが行えない理由はあるかな？」

ジョナサンはそう言うと、私たちの顔を見渡した。答えたのはヨハンだった。

「理由はもちろんあります。いいですか、人員の投入には、コストがかかります。 高スキルの開発者をプロジェクトに投入するには、非常に多くのコストがかかるんです。 今でさえ赤字ぎりぎりのプロジェクトなんですよ。もしそんなことをすれば、プロジェクトは一気に赤字になるでしょう。 マネジメントの本質は、納期と予算の両方を守ることです。そのバランスが大切なんです。高スキル開発者の追加は一切認められません」

ヨハンは、アレクサンドをちらりと見やった。信じられないほど冷酷な目だった。

開発期間とコストの両方を守るだと？ならばこのプロジェクトの遅れは何だと言うのだ。メンバーの努力が足りないとでも言うつもりなのか。

彼の言葉に、みんながざわめき出した。それを遮るように、ジョナサンが言った。

「よろしい。つまり、管理者の視点では『コスト（人件費）の極端な増加を避けるため、遅れているプロジェクトへの人員追加を行う際には単価の安い低スキル開発者が優先される』。 ……このプロジェクトには確かに矛盾が存在している。開発者にも、管理者にも、どちらにも言い分がある。大きな対立だ」

彼はホワイトボードに図を書き始めた。

「予算と納期、これが矛盾の原因だと、私は思う」

コスト対スループット ? 対立解消図（Cloud） 当時のサイトが無くなってしまいスパムサイトになっています http://www.mikihoshi.com/wiki/index.cgi?page=%A5%B3%A5%B9%A5%C8%C2%D0%A5%B9%A5%EB%A1%BC%A5%D7%A5%C3%A5%C8 「ツリーのほうを見れば、それは明らかだ。プロジェクトに遅れがでないようにしたい、これは顧客と開発者の望むマネジメントだ。 反対に、予算をオーバーしないようにしたい、これが管理者の望むマネジメントだ」

ジョナサンは、対立解消図に『対立』と文字を書き足し、より鮮明に対立関係を伝えようとする。

「だが、管理者の行動方針に関しては疑問が残る。 彼らは始めのうちは予算を重視している。しかしプロジェクトが大幅に遅れていることを顧客に責められると、 予算を無視してでも納期に間に合わせようとして、大量の人員投入を行う。ここで、『予算を守る』という方針を、あっさり捨てているのは何故かね？」

「……私たちがこれまで上手くマネジメントできていなかったのは、この矛盾と関係があるということですか？ もしこの矛盾が解消できれば、マネジメントは上手くいくと？」

ヨハンが、彼をまっすぐ見つめて質問した。

ジョナサンは、冷静さを崩さない。

「予算を守ろうとする考え方は、納期を守ろうとする考え方と、相容れないように思える。二つの方針は矛盾している。真っ向から対立している。 私はそれが、問題の本質だと思う。 しかし、」

ジョナサンは言った。

「考え方が対立しているように見えるからと言って、本当に対立しているとは限らない。大抵は、どちらか考え方の前提が間違っているだけであることがほとんどだ」

そう言って、またステートメントを書き足す。

『プロジェクト単位にコスト（人件費）を集計することは正しい』

しばらく、そのステートメントにみんなの視線が集中した。今の今まで、疑ったことなど一度も無かった。みんな当然の前提と思っていたことだ。 あたりまえの常識だったはずのことだ。これが、間違っているかもしれないとでも言うのだろうか。馬鹿げている。だが、もし、そうだったなら？どういうことになるのだ？

みんな黙ってしまった。

長い沈黙の後、普段はあまり喋らないボブが、躊躇いがちに口を開いた。

「一つ、いいですか」

「私は、会計を専門に学んできました。ですから、コストについてはここにいるみんなよりも多少分かっているつもりです」

会計？ ボブが会計を勉強していたなんて初耳だ。

「続けたまえ」

ジョナサンが言った。

「知っている人も多いでしょうが、コストには、変動費と、固定費があります。これは原価計算の基本的な考え方です。 まず変動費はその名の通り、変動するコストです。変動は生産量に比例する、と定義されています。次に固定費ですが、これは固定しているコストです。 生産量がどれだけ変化しようと、固定費は変わりません。生産量が0でも、固定費は発生します」

「それが？私たちとどう関係があるの？」

ステーシーが言った。

「まあ最後まで聞いてみようじゃないか」

アレクサンドがフォローする。

「変動費は、製品のコストとして製品原価の中に集計されます。製品を作るために使ったコストを製品に集計するのですから、この集計には確かな根拠があります。 一方、固定費ですが、これは製品を作った量に比例して変動したりすることはありません。 マネジメントをどれだけ頑張ったとしても、常に一定額支払われることが決まっているコストです。

ですから、『固定費を製品のコストとして製品原価の中に集計することには、正当な根拠が無い』ということです」

「当然のことだな。固定費を製品コストに割り振ろうとすると、少なからず誤差が出る。

設備投資などをして固定費が大きくなればなるほど、その誤差は増える。 そうやって誤差が大きくなれば一部の製品の原価は高くなりすぎて、製品価格も高くなりすぎ、製品は売れなくなる」

ヨハンが自分の知識をひけらかすように言った。

「常識だ」

私はボブの言う原価計算の話を聞きながら考えていた。ボブの言ってくれたことが、どうプロジェクトのコスト計算に繋がるだろうか。まだ分からない。

「どの業界でも、コストの中でとりわけ多いのが、人件費です。考えてみてください。 アルバイトやパートタイマーなら時間給で雇うことができます。ジョナサンのような一時雇いのコンサルタントも……変動費として扱うことができると思います。 しかし、社員はどうでしょうか。社員の給料は、企業全体で見れば、常に一定額支払われることが決まっているコストです。 ボーナス等で多少上下はしますが、それほど大きく変動するわけではありません。 つまり、社員や長期契約の契約社員・派遣社員に支払うコストは、『人件費は固定費』なんです。 ですから、先ほどの製造業の常識をこの業界にあてはめると、『人件費をプロジェクトのコストとしてプロジェクト単位に集計することには、正当な根拠が無い』 ということになりませんか？」

会議室は、水を打ったように静まり返った。みんな、ボブが言ったことに矛盾が無いかと考えているのだろう。 いや、矛盾を探そうとするよりも、直感を働かせればいい。毎月会社が払う人件費は、プロジェクトに投入した人員の数に比例しない。 当然じゃないか。ボブの言ったことにはどこにも矛盾が無い。ボブの意見は、正しい。

最初に口を開いたのは、なんとヨハンだった。「間違っている」彼は怒りに震えて言った。

「『プロジェクト単位にコスト（人件費）を集計することは間違っている』。ボブの言っていることが正しい。私の使っているコスト計算方法は間違っている！」

自分たちが間違った常識を信じていたのだと、もうみんな理解していた。ヨハンはジョナサンのほうに振り向いて言った。

「どうすればいい？どうすればもっと上手くマネジメントできるんだ！？」

今にも掴みかからんばかりの勢いだった。それでも、ジョナサンはポーカーフェイスだった。小さく、しかしはっきりとした声が、会議室に響いた。

「簡単なことだ。とても簡単なことだ。間違った前提に従っていたなら、前提を変えてみればいい」

ああそうか。私は唐突に彼の冷静さの理由を理解した。ジョナサンにとっては、常識が間違っていることなど、あたりまえのことなのだろう。

「先に進む前に、『プロジェクト単位にコスト（人件費）を集計することは間違っている』という仮定について、もう少し考えてみたい。いいかね？」

みんなが頷くのを見て、ジョナサンは言葉を続ける。

「ボブの説明では、変動費と固定費という用語が使われたが、より原価計算の定義に正確に言うのであれば、直接費と間接費という言い方も出来る。 直接費と間接費は相対的な概念で、ある視点で見た場合にコストの発生と相関を持つか否かによってどちらに分類されるか変わってくる」

「今までのプロジェクトマネジメント手法の大きな間違いは、本来であれば企業全体の間接費として考えなければならない固定的な人件費を、 あたかも直接費であるかのようにプロジェクト単位に集計してきた点にある。『人件費はその大部分が固定費・間接費である』という事実を無視し、 『プロジェクト単位にコスト（人件費）を集計する』とき、『コストの配賦誤差が大きくなりすぎて、正しいマネジメントの障害になる』ということだ」

「一つ、面白い質問をしよう。今まで別の仕事をやっていた雇用済みの人員をプロジェクトに参加させた。企業の支払うコストは、増えるだろうか？」

そう問われて、ヨハンは答えた。

「増えません」

言ってしまってから、自分で言った言葉が信じられないような、苦い顔をしている。

「そうだ。コストは増えない。プロジェクト単位のコスト集計が生み出す『コスト増の妄想』は、こんな基本的なことさえ忘れさせてしまう。 二つ目の質問だ。プロジェクトに参加していたメンバーをプロジェクトから外した。企業の支払うコストは、減るだろうか？」

今度は、私のほうに質問が飛んできた。このくらいの質問になら、答えられる。

「減りません。ただし、そのメンバーがプロジェクトの期間だけ雇われている臨時雇用の人員でなければ、ですが」

「そのとおり。見せ掛けのコスト削減を理由にプロジェクトのメンバーを減らしたところで、『コスト節約は妄想』でしかない。 最後の質問だ。ステーシー、答えてくれないか。 プロジェクトAに参加しているメンバー2人とプロジェクトBに参加しているメンバー1人を交換した。企業の支払うコストは、変わるだろうか？」

ステーシーは流暢に答えた。

「もちろん変わりません」

続けて言う。

「しかし、非現実的です。ジョナサン、私にはあなたの言っていることが机上の空論であるようにしか思えません。 まるで、別のプロジェクトから開発者を引っ張って来ることが出来ると思われているように聞こえますが、そんなことは不可能です。 現実として、高スキルプログラマはどのプロジェクトでも足りていません。頭を下げたって断られるのがオチです。 それなのに……あなたは魔法でも使おうと言うんですか？」

ふと、私はアイスコーヒーを見た。もうすっかり氷は溶けてしまっている。魔法か。そんなものは存在しない。 物理法則は誰にも変えられない。好き勝手に時間を遡ることも出来ない。魔法などというものは存在しない。当たり前のことだ。 当たり前だって？ 私は自嘲する。今日は信じていた常識が崩れた日じゃないか。もしかしたら、魔法だってあるのかもしれない。 しかしどうして、私たちは常識が間違っていることに気付けなかったのだろうか。

私たちに無くて、ジョナサンにあるものは、何だったのだろう。何が違ったのだろう。彼は部外者だった。だから常識の間違いに気付くことが出来たというのか？ いや、違う。この業界には毎年、別の業界からたくさんの人間が流れ込んできているのだ。それは理由ではない。

だとしたら、違いは何だ。あの常識を書いた付箋紙を寄せ集めたツリー。ジョナサンは確か、現状問題構造ツリーと呼んでいた。 あれが、違いなのだろうか。問題の真因を突き止めるのに、あれを使ったのではなかったか。 そしてホワイトボードに書かれた図、対立解消図。前提を考え、正しい判断をするために、あれを使ったのではなかったか。 もし、物理法則を変えずに、現実を今より良くするための手法があるとしたら。ジョナサンが、それを知っているのだとしたら。

「この世界に魔法など存在しないよ。しかし、銀の弾丸（魔法の解決策）が無いわけでもない」

ジョナサンの言葉に、ステーシーは眉をひそめた。

「少し脱線するが、いいかね。ちょっとした御伽噺の話をしよう。狼男を殺す銀の弾丸の話だ」

「まさか……」アレクサンドが呟いた。

私も信じられない。『人月の神話』は読んで知っている。だが、まさか、本当にあるというのか？そんなものが。

「この業界で働くもので知らない人はいないと思うが、『狼人間を撃つ銀の弾はない』とブルックスは書いた。 これは、ソフトウェア・プロジェクトの困難性はソフトウェアの複雑性や人間であるが故の不確定性によるものであり、 技術的なアプローチによる魔法の解決策は無い、という意味だ。この言葉が言われてから、20年以上が過ぎた。 オブジェクト指向の発展により彼の予言の一部は外れたが、その他のほとんどの洞察に満ちた言葉は、 今日のソフトウェア・プロジェクトにもそのまま当てはまっている。もちろん、人月計算も」

「では『銀の弾丸』は、技術的なアプローチではないと？」ステーシーが言った。 「少なくとも……」ジョナサンは小さく笑う。

「ブルックスはそう書いている。銀の弾丸などこの世界のどこにも存在しないのだと宣言しているわけでは、決して無い。 彼はこの業界の絶望を望んでいない。現状の改善を諦めることを推奨するためにあの論文を書いたのではない。 『銀の弾丸』が、技術的アプローチ以外の分野に確かに存在するのだと信じて、あの論文は書かれたのだと思う。 あの言葉は、パンドラの箱の最後にあったものだ。それは一見災厄そのもののように見えるが、その実、希望なのだよ」

そう言って、ジョナサンは少し目を閉じた。

「続けてください」アレクサンドが言った。「技術的なものでなくてもかまいません。もし知っているのなら、教えてください。『銀の弾丸』とは何なのですか」

私は何も言えなかった。『人月の神話』を読んで、あのとき私は自分を笑った。こんな業界にいるなんて、俺はなんて馬鹿なんだろうと。 そして本棚の奥にあの本を突っ込んで、……私は何をしたのだろうか。私は毎日、ただ悪態を吐いていた。考えることもせずに。

ジョナサンが目を開く。

「狼男を殺すという『銀の弾丸』とは何だろうか？ 言葉と実体を結びつけるとき、重要なのは定義だ。 少し英語を知っていれば分かることだが、『銀の弾丸』は『魔法の解決策』の代名詞だ。しかし、そこで立ち止まってしまっては意味が無い。 さらに問うてみよう。 『解決策』とは何だろうか？ それは、問題を解決するための策、アイデア、ひらめき、そういうものだ。 容易には理解できない、複雑にもつれあった事象を整理したり、誰も解けなかった問題を一段上の視点から判断し、結論を出したりすることだ。 通常、『解決策』を行使することによって、良くない現状を改善することが出来る。ただし、条件がある。 『魔法のように劇的に』問題を解決する『解決策』でなければならない。それが、『魔法』の『解決策』、『銀の弾丸』の定義だ」

ホワイトボードに、ツリーが描かれる。

前提条件ツリー

目標 『銀の弾丸＝魔法の解決策』 前提 『魔法の』 前提の前提 『容易には信じられない方法、常識の対極にある方法』 前提の前提 『劇的な効果』 前提 『解決策』 前提の前提 『現状が改善される策、アイデア、ひらめき』 補足 『容易には理解できない、複雑にもつれあった事象を整理する』 補足 『誰も解けなかった問題を一段上の視点から判断し、結論を出す』 「やっぱり魔法じゃないですか」ステーシーが茶化す。

「いや、魔法ではない。 『部外者が問題を解決する過程を無視して結果だけを取り出すから、魔法に見えてしまう』だけだ。例を挙げよう」

「14世紀、あるところに嘘吐き男がいた。彼は若かった。いつも夢を見ていて、口ばっかりで、非現実的な話ばかりを約束して、貴族たちの援助を受けようと必死に駆けずり回っていた。 彼がどんなに壮大な嘘をついていたのか教えよう。『地球を逆向きにぐるりと一巡りして、スパイスの宝庫、アジアに辿り着いてみせましょう！』」

みんなが笑った。コロンブスの話だ。

「彼は、本人が自覚していたかどうかはさておき、アメリカ大陸を発見した――すくなくとも、そこが怪物の待ち受ける海の果てではないことを証明した。 『聞いたかい！あの嘘吐き男が、今まで誰も知らなかった世界があることを発見したんだってよ！』 『へえ、海の果てに出航して帰ってきたのかい！だが、また、どうせいつものホラ話だろう』 『いいや、それがな、女王の前で、持ち帰った宝を見せたらしい』『なんとまあ！』ああ、それはまるで、魔法のような話だ。結果だけを見れば」

私は訊いた。「コロンブスは、自分が正しいと信じていたのですか？」

「もちろん。彼はある天文学者に出会い、地球は丸いと確信していた。 そして丸いのであれば、直径の計算に多少の誤差があったとしても、反対側を回ればいずれ目的地に辿り着く。 彼が考え、実行したことには、どこにも矛盾など無かった。どうしようもないほどの正論だった」

「ならどうして、貴族たちはコロンブスを支持しなかったのかしら？」ステーシーの疑問は、みんなの疑問を代弁していた。

ジョナサンは棒でツリーを指す。

「簡単なことだよ。それが『容易には信じられない方法、常識の対極にある方法』だったからだ」

誰もが納得していた。コスト計算にしたってそうだ。常識が間違っていると言われて、はいそうですかで済むはずが無い。 だとすると……、やはりあのツリーや図は只者ではないということになる。コスト計算に関する私たちの常識を改めさせたのだから。

ジョナサンは棒をスライドさせ、話を続ける。

「コロンブスは、結果が『劇的な効果』をもたらすと分かっていた。当時、新航路の発見は国を挙げての一大事業だったためだ。 そして、新航路の発見はまさに『解決策』だった。『現状が改善される策、アイデア、ひらめき』、それは、『地球を逆向きにぐるりと一巡り』することだった。 さて、ここで一つ質問しよう。これは魔法かな？」

誰も答えない。分かりきった質問に、間違うのが怖いのだろうか。私は答えた。

「いいえ。コロンブスがやったことは魔法ではありません。『銀の弾丸』も魔法ではありません。 しかし、魔法で無いとしたら、一体何と言ったらいいのか……」

「『劇的な結果』だけを取り出したなら、それは『魔法』だ。しかし、やっている本人にとっては、それは魔法ではない。 常識の積み重ねの上に成り立つ、合理的な判断に過ぎないというわけだ。 いわゆる『銀の弾丸』は『劇的な結果』である『魔法の解決策』の代名詞だが、私たちの求めているのは『コロンブスが使った魔法の解決策』ではなく、 『私たちだけの常識外れな解決策を作り出す方法』だ。それこそが『銀の弾丸』と呼ぶに足るものだ。そうは思わないかね？」

みんなが頷いた。もう誰も、銀の弾丸が無いとは思っていないようだ。見つけてやろう。そんな気持ちになっている。

「さて、御伽噺はこれでおしまいだ。楽しんでくれたようで何より。では、現実のプロジェクトに戻ろう。 コスト計算に関する質問は後で受け付けよう。今の問題は『高スキルプログラマが不足している』ことだ。 ステーシー、『高スキルプログラマが不足している』理由を、ぜひ聞かせてくれないかな？」

「ええ、もちろん」

「理由は、『別のプロジェクトも遅れている』ということです。ですから、別のプロジェクトから開発者を引っ張ってくるなんて無理なんです」

その言葉に、私はため息をついた。そうだ。別のプロジェクトも遅れている。そうして結局、振り出しに戻るのだ……本当に？

違う。上手く言葉にならないが……違和感を感じる。まるでバグが残ったソースを見たときのような気分だ。この感覚を無視してはならないと、プログラマとしての勘が告げている。

ふと、ジョナサンの言葉が頭を過ぎった。『本当にそうだろうか？』

「ステーシー、それは違うんじゃないかな」知らずに、私の口が動いていた。「『一番遅れているプロジェクト』は、常に一つだと思う。 だとしたら、比較的遅れていないプロジェクトから開発者を引っ張ってくることが出来ない理由は、ほかにあるんじゃないか？」

「そんなはずは無いわ。いつだってそう言って、別のプロジェクトのマネージャーは開発者の再配置を許可しないのよ」

ステーシーは譲らない。ステーシーはいい加減なことを言ったりしない。別のプロジェクトのマネージャーは本当にいつもそう言っているのだろう。 それでも、何か別の理由があるはずだ。ステーシーが何か言おうとするのを制して、ヨハンがその理由を答えた。

「マネージャーの言い分のことなら私に聞いてくれ。今だから言えるが、『高スキルプログラマの柔軟な活用が出来ない』のは、 『高スキルプログラマ多少余裕が出来ても、マネージャーはそれを隠そうとする』からだと思う。 どうしてそんなことをするのかなんて聞かないでくれよ。今まで話してきたことだ。『プロジェクト単位のコスト集計の悪影響』だよ。 もしプロジェクトに余裕があるなんて知られようものなら、あらゆる方面から圧力がかかる。まったくコスト削減の圧力といったら、凄まじいものだよ。 『メンバーを減らしてコストを減らし利益を上げろ！』この方針に反論などしようものなら、あっという間にクビを切られる」

「でも、『プロジェクトに参加していたメンバーをプロジェクトから外してもコストは減らない』のだから、それは全く理不尽な圧力です。馬鹿げています。 こんな理不尽な状況では、『高スキルプログラマ多少余裕が出来ても、マネージャーはそれを隠そうとする』のも、もっともな話です」

ああ、明日は雪が降るかもしれない。まさかアレクサンドがヨハンを弁護するシーンが見られるとは。 ボブも、何か言いたいようだ。

「他にも理由があります。これはマネジメントとしては些細な問題に見えるかもしれませんが、本人にとっては重大な話です。 通常プロジェクトは、全てが同じ場所で行われているわけではありません。そうすると、プロジェクトを移る場合、当然引っ越しを行う必要が出てきます。 この引っ越しの費用は、どこから出るとお思いですか？今のシステムでは、全部開発者の自腹です。 それだけではありません。引っ越し先に家具が足りていなかったら？インターネット回線が引かれていなかったら？恋人や家族と離れ離れになったら？ 『これは社の命令だ。抵抗は無意味だ』とでも言うのですか？ 現状では、会社を恨みながらも、渋々引っ越しに同意する開発者がほとんどです。 高スキル開発者の中には、こういった待遇が苦痛で、辞めてしまう者もいます。これも『高スキルプログラマの柔軟な活用が出来ない』理由です」

「残業も同じだ。残業で家庭を壊して、自分の身体を壊して、会社のために真面目に働く人間なんているはずがない。 無茶をすれば、高スキルプログラマから辞めていくことになる。それは一年後かもしれないし、明日かもしれない」

私も補足する。まるで言いたい放題だ。 ヨハンも唖然としている。今まで、開発者の負担がどんなに重大な意味を持つか、考えたことも無かったのだろう。ジョナサンが、まるで会話でもするように話した。

「どこだってそうさ。どこだって『マネージャーと開発者の間で、マネジメントとして捉える範囲が異なっている』ものだ。 ここで、『それは経理の問題だ』とか『それは就業規則の問題だ』と責任転嫁するのは簡単だ。 『そんなことをプロジェクトマネジメントの対象と考えるのは非常識だ』と一蹴するのも簡単だ。難しいのは、『変えよう』と考えることだ」

「そうですね」ヨハンは、噛み締めるように繰り返す。「本当にそうです」

「現状のシステムを変えなければ、高スキルプログラマを活用することなんて出来ない。変えなければいけません」

深刻な空気になりそうだった会議室の雰囲気を変えたのは、ステーシーだった。

「思ったのですが、『高スキルプログラマが不足している』理由はそれだけではないかもしれません。 当然ですが、高スキルプログラマの全てが最初から高スキルプログラマだったというわけではありません。 普通のプログラマが、経験を重ねて、高スキルプログラマになるんです。少なくとも、本来はそうあるべきなんです。 ですから、『開発者の教育が思うように進まない』という問題もあるのでは？」

確かにそうだ。もちろん、『教育が大切だ』などという陳腐な台詞は、この業界でも十年以上前から言われている。 だが、実際に短期間で開発者のスキルを上げる方法は確立されていない。上司に命令されて嫌々受ける社員研修制度に至っては、 悪口しか聞いたことが無いほどだ。

ジョナサンが、一つ質問をする。

「開発者の努力不足という個人的な問題は、確かに存在するのかもしれない。 しかし、ここにいる人間は別に努力が嫌いというわけではないはずだ。一体、開発者は何故努力しないんだね？」

誰も答えない。たまりかねて、私が答える。

「『開発者の努力（作業の効率化）が正しく評価されない』からです。もし努力すると、どういうことになるか説明しましょう。

開発者が努力して、作業を効率化したとします。すると、その開発者は普通より早く仕事が終わりますから、少し手が空いた状態になるんです。 ところで、『分業が進んでいる職場では、プログラマがプログラミング以外の仕事をすることは許されない』ため、 他の人の仕事を待つ必要が出てきてしまいます。憶測でコードを書くことも出来ますが……『仕様が決まっていないのにコードを書いても、どうせ作り直し』になります。やるだけ無駄です。 さて、暇そうにしている開発者の元に、次の仕事が回ってきます。開発者はその仕事も片付けます。 ここで、『より多くの仕事が回ってくるようになっても、それに比例するほどには評価は上がらない』点が問題です」

ホワイトボードにペンを走らせながら、ジョナサンが言う。

「仮に、作業あたりの評価 ＝ 評価 ／ 作業量 と定義すると、むしろ作業あたりの評価は下がる、というわけかね」

「そうです。そこにマネージャーがやってきて、手持ち無沙汰になった開発者を注意するんです。 『皆が忙しそうにしているのに、君は何をしているんだね。仕事をしないのならクビだ！！！』 でも実際は、その開発者が一番仕事をしていたりするんです。それは進捗表を見れば誰だって分かることです」

ヨハンが言った。

「『暇そうにしている』『よく手が止まっている』といった『感情的な視点で開発者を評価してはいけない』ということか……」

ジョナサンが、ペンを置いた。見ると、ホワイトボードにはツリーが書きあがっている。これを見れば、問題は一目瞭然だ。

『高スキルプログラマが不足している』の現状問題構造ツリー 当時のサイトが無くなってしまいスパムサイトになっています http://www.mikihoshi.com/wiki/wema.cgi?page=2004071812140030499 全員が、ツリーを凝視した。どこにも矛盾が無いとしたら、この中に一番の問題があるに違いない。

ヨハンが唸るように呟いた。「評価基準だ……全ての原因はそれだ。『人は、自分がどう評価されるかに従って行動する』んだ。 問題は人をそうさせてしまうシステムだったんだ。 ジョナサン、一体何を評価基準として使えばいいんだ。 開発者の経験年数か？開発者のスキルか？だが、そんなことは私には判断できない」

常識に縛られて、本当に簡単なことに気付けないことがある。

「何が分からないのかね」ジョナサンが問う。

分かってしまえば何ということもない、当然の結論に辿り付くことがある。

「ヨハン、『マネジメントの本質は、納期と予算の両方を守ること』だと君は言った。コスト計算の方法は間違っていたわけだが、しかし、残されたものがある。 プロジェクトの成功の本質は、目的は何だね？」

人は、回り道をしながらも、確かにそこに辿り付く。それが人間が持つ力、論理的思考の持つ力だ。

「納期……進捗……開発者を評価するための基準は、進捗への貢献度だ。『経験年数やスキルではなく、プロジェクトの進捗への貢献度こそが評価基準であるべき』なんだ」

驚いたことに、誰からも反論は出なかった。ヨハン自身も訳が分からないようだ。

ジョナサンが口を開いた。

「多くの者が忘れてしまっているようだが、『評価基準は目的を達成するための手段』なのだよ。『間違った評価基準は、目的達成の障害でしかない』。 間違った方針を変えてみることだ。全てのメンバーの努力のベクトルが、真っ直ぐ目標を向くように。それが、真に努力するということなのだよ」

私は思った。目標に沿った評価基準があって、初めて真の努力が生まれる。きっと、そうなのだろう。いや、そうに違いない。 しかし、そんなことが実際に可能なのだろうか？

評価基準として成果主義を導入しようという話は、これまでにも無かったわけではない。 だが、そういう話は役員レベルで何度も潰されてきたと聞いている。

優秀な社員を評価することで大きな格差と妬みが生まれたり、逆に平均的な社員の評価が導入前より下がってしまいやる気が落ちたり、 やり方が変わることで生産性が低下してしまったり、そういう様々な懸念があるためだと説明されているが、彼らの本心など誰にだって分かっている。 要するに年功序列という権益を守りたいだけなのだ。

結局、彼らは『社員を稼働率で評価する』ことに慣れきってしまっている。 彼らが変化を認めるのは、会社が潰れそうになったときくらいだろう。いいや、それでも認めないかもしれない。

「どうやら『成果主義』という言葉を思い浮かべているようだが、それとは少し違う」

見透かしたようなジョナサンの言葉に、私は驚いた。 「何が違うというのですか？」ヨハンは質問する。自分の手の届かないところに答えがあったという苦悩が、ヨハンの声を苛立たせているようだ。

ジョナサンは、無言でホワイトボードを裏返した。ペンが走る。そこに書かれた言葉自体は簡単だった。しかし、その意図を理解するのは容易ではなかった。

『プロジェクトを正しく評価するためのコスト計算』

「答えを性急に追い求めると、『問題は外部にあった』、あるいは、『問題は上司にあった』、という話になってしまうことがある。 これは非常に危険な落とし穴だ。この落とし穴に一度嵌ってしまうと、抜け出すのは容易ではない。マネージャーのみならず、プログラマにも覚えがあることだろう」

もちろん覚えがある。バグをライブラリやOSのせいにしたことは数え切れない。しかし、筋道立てて確認してみると、実は自分のミスだったということのほうが多い。 正しい答えにたどり着くには、焦りは禁物だ。

「とりあえず、中途半端になってしまったコスト計算の話に戻ってみよう。全員に、重要な定義を知ってもらう必要がある。 さて、ヨハン。君に質問だ。『プロジェクトを評価する方法は、プロジェクトの損益（利益または損失）である』というのは、正しいかな？」

「もちろんです」ヨハンは答えた。沈黙するジョナサンに少し不安になったのか、言葉を足す。「それ以外にプロジェクトを評価する方法などありません」

「では、」私は、ジョナサンが何と言うのか、なんとなく想像がついていた。 彼は楽しそうに笑うと、まるで理解の足りない学生たちに言い聞かせる教授のような口調で言う。

「確かめてみようじゃないかね？」そしてまた、常識が一つ変わっていくのだ。

「『プロジェクトを損益（利益または損失）で評価する』。これが、ヨハンの言うプロジェクトの評価方法だ。多くの企業ではこの評価方法を使っている。 しかし、多数決というのは正誤を決める方法ではない。重要なのは、根拠となる前提と、期待した結果が、実際にあるかどうかという点だ」

プロジェクトを正しく評価するためのコスト計算 ? 対立解消図（Cloud） 当時のサイトが無くなってしまいスパムサイトになっています http://www.mikihoshi.com/wiki/wema.cgi?page=2004072316135912619 私は考える。また、この図だ。常識を打ち破るのは、容易ではない。だが、この対立解消図の前には、間違った常識は生き残れない。

「『プロジェクトを損益（利益または損失）で評価する』という方針を採用した場合、当然だが『損益を算出するためにプロジェクト単位にコスト（変動費と固定費）を集計する』ことになる。 そうだね？」

「ええ、そうです……分かりましたよジョナサン。認めます。『プロジェクトを損益（利益または損失）で評価する』限り、人件費などの固定費をプロジェクトに集計することは 避けられない。しかし、『固定費のコスト集計には正当な根拠が無い』ですし、『コストの配賦誤差が大きくなりすぎて正しい判断ができなくなる』わけですから、 ここに矛盾が生まれていることになります。『プロジェクトを損益（利益または損失）で評価する』という方針を強く強制すればするほど、 固定費の配賦誤差が生み出す悪影響が顕在化し、『正しくプロジェクトを評価する』という目的が達成できるかは怪しくなっていく……ということですね」

「そうだ。それが従来のプロジェクト・マネジメントが抱える方針制約だ。間違った方針のもとで努力すればするほど、状況はどんどん悪化していくことになる」

ステーシーが身を乗り出して質問した。「別の方法があるのですか？」ジョナサンは答えない。そのかわり、指で頭を何度か叩く。

自分で考えろ、ということなのだろう。みんなも考えている。何が正解なのか。固定費の配賦誤差は避けられない。方針が間違っている。つまり……。

アレクサンドが呟いた。「本当に、誤差だらけの損益を計算する必要があるのかな？」途端に、みんなが自分の意見を言い合った。もちろん、私も参加する。 にわかに、会議室が騒然となった。

「何で誤差を含む損益を使うのかしら。そんなの間違ってるわ」「固定費があるから誤差が生まれるんだ」 「たぶん、計算式が間違っているじゃないかな」「計算式って、損益 = 売上 - 費用（変動費 + 固定費）ってやつだろ？これが間違いなのか？」 「どこがマズいんだろ？」「今までの話を聞いてなかったのか？ 固定費に決まってるだろ」「だいたい、固定費ってマネジメント不能なんだろ」 「マネジメント不能だっていうなら、固定費についてはマネージャーじゃなくて経営者が考えればいいんだ」 「固定費を計算式に入れる根拠って無いんじゃないか？」「どうせマネジメント不能なんだから、固定費を無視して評価してみればどうかしら？」 「そうだ。プロジェクトに関連する変動費だけを考慮すればいい」

こんなに意見を出し合ったのは、ひさしぶりだ。みんなの意見が次第に収束していく。最後に残ったのは、あまりにもシンプルになった、新しい計算式だった。

売上 - 変動費 「完璧だ」ヨハンが言った。「完璧とはどういうことですか？」ボブが質問する。「分からないのか？これなら固定費の配賦誤差が入る余地なんて一切無い。だから、判断を間違える可能性が無くなる。 『正しい判断が出来る』評価方法だ。これは、完璧に目的に沿った評価方法なんだよ」

ヨハンが興奮して説明している。正しい方針というものは、こんなにも単純なことなのだろうか。

パチパチパチ

満面の笑みを浮かべて、ジョナサンが拍手をしている。

「よくやった。君たちは自分たちで答えを見つけ出した。矛盾を解決する方法を探し出して、今までは考えもつかなかった方針を見つけ出したのだ。本当に素晴らしい」

褒められて悪い気はしない。確かに、自分たちは答えを出したのだから。

「ジョナサン、この計算式の結果に名前はあるのですか？ 固定費や間接費を考慮していない以上、これは損益ではありません。これは何と呼べばいいのですか？」

ステーシーは自分が知らない定義に出会って、少し困惑しているようだった。ジョナサンに、みんなの視線が集まる。

「売上から変動費を引いた結果を、スループットと言う」

スループット = 売上 - 変動費 「これこそが、本来マネージャーがマネジメントすべきものだ。『マネジメントの目的は期間あたりのスループットの最大化である』と言い換えてもいい」

ヨハンの眼は輝いていた。無理も無い。ようやく、自分のやるべきことを見つけたのだ。 開発者に恨まれながら、自分がやっていることが本当に正しいのかと悩む必要は、もう無い。 マネジメントの正当性は、それが目的に沿っているかどうかで判断すればいい。 今、目的と手段が確かに繋がったのだ。

「どうしても『売上』でなければならないのですか？」ステーシーの質問に、ジョナサンが答える。

「いい質問だ。定義が『売上』となっているのは、必ず『納品』までを考慮しなければならないためだよ。 仕掛品や完成品の在庫をどれだけ作っても、『納品できなければマネジメントが成功したとは言えない』からね」

確かにそうだ。だが、耳慣れない言葉に、私は思わず聞いていた。「在庫とは？この業界に在庫なんてありませんが？」

私の言葉に、ジョナサンは悲しそうに首を振る。そして言った。

「いいや、在庫の山はあるのだよ。残念なことに、それこそ山のようにあるだろう。ものづくりをしている業界で、納期遅れが起きている職場で、現場に在庫が無いなどと考えるのは大きな誤りだ」

「『在庫』とは、将来納品するために存在する、作りかけの未完成品や納品前の完成品のことだ。 そのままでは納品できないもの、全てが在庫だ。

例えばIT業界での『在庫』とは、『書きかけのコード』『未テストのコード』『別のコードの完成を待っているテスト済みのコード』 『完成していても顧客に納品されていないコード』を指す。もちろん、『完成していても顧客に納品されていないドキュメント』も在庫だ」

ジョナサンの言葉を聞くうちに、私のマシンの隣に何かが山のように積みあがっているのが見えてきた。 何だろう。そうだ、あれは、私が書いてきたコードだ。毎日残業して、その中に価値があると信じて作り出してきたコードだ。 あれが全て、在庫だというのか？ 現時点では顧客に納品することができない、スループットに繋がっていない、在庫だというのか。 頭を振って、妄想を追いやろうとして、気付く。いや、違う。在庫の存在は妄想ではない。

簡単なことだ。コードは目に見えない。だから、私たちはそれが在庫だと正しく認識できていなかったのだ。なんということだろう。

顧客の視点で考えてみれば、それがよく分かる。書きかけのコードや、未テストの機能は、顧客の視点ではほとんど価値が無い。 機能が完成したと私が叫んでも、未テストの機能にお金を払ってくれるような都合の良い顧客はいないのだ。 機能がテストを通って、確実に動作すると保証されて、初めて在庫は価値に変わるのだ。 その点では、IT業界は製造業と何の違いも無い。まさに、未テストのコードは在庫なのだ。

「在庫、ですか。在庫というのは倉庫に入っているものだと思っていましたが、 パソコンの中にも在庫はあるというわけですね」 ボブの言葉に、ジョナサンは頷く。

「『在庫』はスループットを生み出す前の状態であり、将来的にスループットに変わる可能性はあるが、 しかし、現時点ではスループットにはなっていない。これがどういうことか、わかるかね？」

「つまり……開発者の稼働率を上げるために今すぐ必要でない作業を行わせても、在庫を増やすことにしかならない。 見た目の効率を重視したマネジメントでは、スループットを増やすという目標は達成できないということですか？」ヨハンが尋ねる。

「そのとおり。プロジェクト・メンバー全体の生産能力は一定だと仮定しよう。すると、『在庫を増やすために生産能力を使い過ぎると、相対的にスループットを減らす結果になる』。 これはマネジメントの目標に反した行動だ」ジョナサンの言い分はシンプルだ。だが、ステーシーが疑問を口に出した。

「『必要になるまで、作業の開始を遅らせる』ということは理解できます。 しかし、それでは開発者の手が空いてしまいます。その開発者の時間が無駄になるのでは？」ステーシーが疑問を口に出す。

「それは違う。開発者の余剰生産能力はいわば自然発生したセーフティー・バッファー（安全のための緩衝）なのだ。 開発者にさしあたって必要の無い在庫を作らせることでセーフティーを削り、生産能力をバランスさせてしまうと、前工程に発生した遅れをカバーするための時間的余裕が無くなってしまう。 作業のフローは非常に脆く壊れやすい状態になり、実際にフローは滞る。その結果、スループットに破壊的な影響を及してしまうのだ」

「そうじゃないかと思ったわ」ステーシーはため息を吐く。「思い当たることだらけだもの」

「ところで、この『在庫』をスループットに変えるためのコストを『経費』という。 『顧客に納品する目的でないもの』は、全て経費だ。 よく在庫と誤解されるのだが、『顧客に納品する目的でないコード』『顧客に納品する目的でないドキュメント』なども『経費』に含まれる。 目に見える経費、というわけだね」

「てっきり経費というのは、紙に印刷されたものだと思っていましたよ」ボブが冗談を飛ばし、アレクサンドがそれを受けた。「これからはメジャーで測らないとな」

みんなが笑う。ジョナサンも楽しそうに笑った。

「さて、『在庫』『経費』『スループット』の３つの指標がある。 マネジメントの手段は明らかだ。『在庫を減らし、経費を減らし、スループットを増やす』。これが、マネジメントの全てだ」

「たった、それだけなのですか？」 ヨハンは、簡単には認められないようだ。 彼は勉強家だ。ずいぶんと努力をして、マネージャーになったのだと聞いている。答えが簡単に手に入ることに、慣れていないのかもしれない。

「そう、たったそれだけだ。この３つの指標の他には、何も必要ない。 注意して欲しいのは、これらの指標の一つだけを改善しようとすると逆効果になってしまうということだ」

「『コスト削減』は逆効果なのですか？そんなはずは無いと思います」 ヨハンの反論に、ジョナサンは答える。

「その内容はともかく、『コスト削減』を行おうとするマネージャーは多い。 だが、『在庫を減らすこと』と『スループットを増やすこと』を蔑ろにしていては、効果的なマネジメントを行っているとは言えない。 それどころか、『コスト削減を重視しすぎて、在庫を増やし、スループットを減少させてしまう』ケースもある。 例を挙げよう。

社員に休憩時間を与えず、残業をさせて稼働率を上げる。マネージャーは時間当たりの人件費を節約したように錯覚する。 しかし実際には、企業が支払う金額はこれっぽっちも減ってはいないし、むしろ残業代などで増えている。コスト削減は妄想だ。

開発者にひたすらコードだけを書かせて稼働率を増やし、マネージャーは開発の効率を上げたように思い込む。 これも実際には、在庫が増えただけだ。生産能力を在庫の作成と管理に振り向けたわけだから、スループットは激減している。

これほど非効率的なマネジメントは無いよ」

「しかし、この業界ではみんなそうしているのでは？」「なら、みんな間違っているんだろうね」笑いの消えたみんなと対照的に、ジョナサンは心底楽しそうだ。

ジョナサンは話を続ける。「定義上当然のことだが、『スループットが減ると利益も減る』。 これを改善しようとまたマネージャーが『スループット無視のコスト削減』、あるいは自滅的な『稼働率向上戦略』に向かえば、 在庫増加、スループット減少、利益減少の破壊的な悪循環が発生することになる」

「最後には、わけもわからず倒産ってわけか」アレクサンドがぽつりと呟いた。

この業界の倒産件数は、年々増加傾向にあるという。多くのベンチャー企業が生まれては消え、大企業の採算悪化も珍しくない。 それは、正しいマネジメントが行われていなかったからなのだろうか。コスト削減だけを重視して、スループットを見失っているからなのだろうか。

「スループットを増大させるには、『書きかけ・未テストのコードを減らし（在庫削減）、分納などで納品を早める（スループット増加）』ことが最良だということになる。 しかしそのためには、『スループットが大きく増えるのであれば、経費が多少増えても良い』という、考え方の転換も必要になる」

コスト増！今までの私たちにとっては禁句だった言葉だ。遅れているプロジェクトに払う金など無いと、何度遠まわしに宣言されたことか。 だが信じられないことに、ヨハンは何も言わずに考えているようだった。しばらくして、ヨハンが口を開いた。

「コスト至上主義からスループット至上主義への転換が必要、ということですね。両者はまるで違う。天動説と地動説くらいに違う……。 ですが、『これ以上の経費削減は無意味だ』という気持ちは、私にもありました。 僅かの経費に執着して、利益を生み出す別の要因を見落としているのではないかと、いつも考えてきました。 確かに、見落としていました。『スループット』、『在庫』……経費削減と同様に、いや、それ以上に、重要な視点です。 考え方を変えるには時間がかかるかもしれませんが、見落としていたものを見つけたからには、最大限努力しましょう」

私は、自分がヨハンを誇らしい気持ちで見ていることに気付いた。彼なら、正しいマネジメントを実践するに違いない。

未テストのコードという在庫を減らすのに、テスト駆動開発が有効だと私が提案したら、聞き入れてくれるだろうか。 開発の効率を上げるために、テスト・サーバーがどうしてももう一台必要なのだと説得したら、決断してくれるだろうか。 たぶん、ヨハンならやってくれるだろう。

「さて、時間だ」ジョナサンが、時計を見て言う。

「今日はもう行かなければいけない。ヨハン、また何かあったら連絡をくれたまえ。『経費』は増えるかもしれないが、『スループット』を増やすことは保証しよう」

最後のはジョークのつもりだったのだろうか。ジョナサンは笑いながら、会議室を後にしたのだった。

（ここで、一区切り）

デスマーチとは

予定の開発期間を過ぎても、まだまだ終わらないプロジェクトのこと。 エドワード・ヨードンは、著書の中でデスマーチの定義として４つの項目を挙げています。

１．与えられた期間が、常識的な期間の半分以下である。

２．エンジニアが通常必要な半分以下である。

３．予算やその他のリソースが必要分に対して半分である。

４．機能や性能などの要求が倍以上である。