プログラマのデスマーチのお話

ネットで読めるデスマーチ

ネットで読めるプログラマの悲惨なデスマーチの話としては、「ブラック会社に務めているんだが俺はもう限界かもしれない」が挙げられるだろう。「まとめ」とかのキーワードで検索すれば、そういうブログが出てくると思う。

上記は「ブラック会社に務めているんだが俺はもう限界かもしれない」と思った男が2ちゃんねるに相談として体験を書き込むところから話が広がっていく。特徴的な人物が多数登場して物語を盛り上げる様や、印象的なエピソード、そして事細かい会話、流れるようなストーリー、それぞれは読み物として純粋に面白いが、逆に読み物としていささか完璧すぎる気がする。

私が思うに、上記のお話は創作だろうと思っている。この話からはデスマーチがどのように大変だったか、という技術っぽい話がまるきりないのが、実体験としてはとても不自然に思える。加えて、登場人物の会話ややりとりが多数書かれているが、記憶を掘り起こして書いたにしては、あまりにも事細かいと思う。多少色を付けているにしても、だ。

これは単純に勘だが、この話を書いている人はプログラマに近い立場の人間ではあると思う。登場人物も、実在の人物をモデルにしているのだと思う。それによる絶妙なリアリティと物語の面白さが相まって、ここまでまったのではないかと思う。(たしか、書籍化、映画化もされていたはずだ)

まあ、創作だから良いとかダメとか言うつもりはもちろんない。ただ、創作であれ、実話であれ、あの話はデスマーチを正確に表現していない、とは思う。これも、だから良いとか悪いとか言うつもりはなくて、ただ単に、正確に表現していない、と思うだけ。

私が思う、デスマーチの悲惨さがよく伝わる、ネット上で読める読み物は「軍曹が語る(YRP常駐)」である。これも2ちゃんねる発のお話で、携帯の組み込みソフトを開発する技術者として派遣された一団の行く末をチームリーダーの視点から描いている。これも、同キーワードで検索すればネットで読める。

この話は、先の「俺はも限界かもしれない」と同じくデスマーチを扱った話ではあるが、かなり毛色の違う話に仕立てられている。なによりも、この話にはとてもリアリティがあるのだ。脚色はあるにしても、大体が実話だろうと思う。私がそう思う理由は、私自身の経験とも合致するところが多いから。

というわけで、いくつか印象に残っている共通点、また、逆に共通していない点をあげて考察してみたい。

デスマーチ現場に追加人員をいきなり放り込む

フレデリック・ブルックスが「人月の神話」で記したように、遅れているプロジェクトへの人員の追加は更にプロジェクトを遅らせるだけである。それは、プロジェクトメンバー間のコミュニケーションの複雑さはn^2のオーダーで膨れ上がるからである。

すべてのパターンでこれが成り立つとは私は思っていないが、そう断言していいくらい、多くの場面でこの法則は正しいと思う。

しかしながら、経験則でそうであったとしても、いくら偉い人が警鐘を鳴らしたとしても、これは多くの管理者には受け入れがたい事実である。なぜか。これには2つの理由があると私は思う。

1つ目は、世の中の作業の殆どが、人手をかければかけるほど早くこなせるからである。引っ越しであれ、掃除であれ、ライン作業であれ、ほとんどの作業にこの法則が当てはまる。だから、ソフトウェア開発にもこれが当てはまると思ってしまう。

2つ目は、古来よりソフトウェア開発は「人月」という単位でプロジェクトのボリュームを管理してきたからである。これは現代でも半ば常識と言ってもいいほど固着している。でもこれが常にいい方法ではない、ということも周知されてきて、昔からいろいろなメトリックが考えだされてきたけど、それを実用レベルで使いこなせる管理者は少ない気がする。

というわけで、多くの管理者は、自分が担当するプロジェクトが遅れた時に、まずは予算の許す限り、つまり、粗利分を犠牲にして、追加人員を投入しようとする。「YRP常駐」でも、筆者が派遣された先はプロジェクトが遅れに遅れきって、バグを量産する室の悪いプログラムだけが残り、前任者はすでに逃げた後だった。また、デバッグ要員を集めるために、態度の悪いバイトまで雇い入れるというような描写もあった。こういうやり方をする管理者を私も今まで何度も見た。

私の拙い経験から言わせてもらうと、やはりこういうやり方で上手く行った試しがない。まず新しく入ってきた人たちに、仕様や背景を説明し、システム固有の用語やビジネスルールを説明しているだけでかなりの時間が取られる。

いやいや、そんなもんはドキュメントとしてまとめられているはずであって、人が説明しなければならないという事自体がおかしい、という人もいるかもしれない。が、少なくとも私はそのような理想的なドキュメントが整備されているプロジェクトを見たことがない。ひどいのだと、客先に提出するユーザーマニュアルをソフトウェア仕様書として開発しているケースもあった。(付け加えると、それをおかしいとも思わない人たちが大勢いるということも、問題である)

で、そういうことを口で説明して、何度も何度も説明して、質問攻めにも対処して、ようやく分かってもらえて、実装してもらうと、大量のバグが出る。説明しきれないことや、暗黙的な仕様があったりするからだ。これを仕事を頼んだ側の視点から見ると、「こいつは仕様を理解していない」「常識的に考えればわかるのに、言われたことしかやってない」などと思う。対して、頼まれた側の視点から見ると、「情報がまったく足りない」「エスパーじゃないんだから暗黙的な仕様まで想像できない」などと思う。コミュニケーションがまったく上手くとれていない。

なので、更に詳しく仕様を説明する。場合によって絵を書く。文章にする。そういうことに時間を取られると、自分で実装したほうが早くなる。結果として、追加人員は効率的に働くことができない。

こういう話をすると、またよく言われるのが、「そうやって面倒くさがって説明することを放置するといつまでたってもシステムを理解できる人材が育たない」ということなんだ。しかし、プロパーにならまだしも、いつか居なくなる協力会社社員とかには悪いけど苦労してまで教えたいとは思わない。

だから俺は常々、「最初から必要な人員を投入してくれ」って言ってるんだ。でもそれも理想論であることは重々承知だ。「いや、そうは言っても最初から予算がいっぱい出るわけじゃない」「(作業量に)波のある業務なのにピークの労働力をアサインできない」って言われる。いや、わかるよ。俺が無理なことを言っているのはわかるよ。でも、プロジェクトがやばくなってから追加人員を投入して挽回を図るのだって、同じくらい無理なことなんだって。

狼を撃つ銀の銃弾は無い

これもフレデリック・ブルックスが「人月の神話」で述べたことだ。

ソフトウェア開発プロジェクトでは、なぜか、「画期的な新技術が問題をすべて解決する」と盲信されるケースが多い。人間は自分にとって都合のいい情報を信じたがるので、そういうことが関係しているのかも知れない。これも経験則ではあるが、画期的な新技術があらゆる問題を解決することなど、まず、無い。

「YRP常駐」では、新開発のシミュレーターや、新しいミドルウェアが問題の大部分を解決すると言われていたが、実際、そんなことは無かったというエピソードがある。

私が携わったプロジェクトや、見聞きしたプロジェクトでも、新規に導入する何ちゃらの自動生成ツールが実装工程を大幅短縮するとか、某社の某ツールを導入することでプロジェクトが大幅効率化とか、そういうことが数多囁かれ、そしてすべてのケースで、後にそれらが誇大な評価をされていたということが判明している。

人間関係が希薄

「YRP常駐」では、隣の席の人間であってもメールで会話したりするというエピソードが語られていた。他にも、やけに早口でしゃべる様や、精気の感じられない笑顔などに違和感を覚えたことが書かれている。

これもソフト屋だと結構見受けられると思う。私の経験上からも、こういう人たちは多い。

メールで会話をするというのは、記録に残るので便利という目的があるので、一概に変とはいえないのだけど、それを好む人は多い気がする。また、早口な人と、無理に笑っているような感じの、元気さが感じられない、違和感のある笑顔、笑い声などはよく見聞きする気がする。新入社員として入った時にはすごく違和感を覚えたものだが、もうすでに慣れてしまった。

ホテル暮らし、会社の自分の席がなくなる

これも残念ながらよくある話だ。ソフト開発というのは、意外と場所に制約がある。対象とするハードウェアを外に持ち出せないとか、開発メンバーが一箇所に集まっていたほうが都合がいいとか、セキュリティ上の理由でデータを持ち出すことが禁じられているとか。

我が社でも長期出張でホテルぐらしをするとか、あまりにも長い間客先に常駐しているので席がなくなったとかいう話はよく聞く。

なんの仕事であれ、仕事現場が家と離れていて長らく帰れないというのはあるだろうが、本来は場所の制約が殆ど無く、SOHOだの何だの言われていた業種でこういうことが起こるというのは皮肉であるなあ、と思う。

仕様書が手に入らない

プロジェクトにまともな仕様書が用意されているという現場を私は見たことがない。「YRP常駐」もその例だ。

ただし、「YRP常駐」はちょっと私の経験と違っていて、それは「最新の仕様書が手に入らない」ということである。私の経験上、「仕様書が作られていない」「作ったけどもう無い」「作ったけど改定されてない」というパターンがほとんどだった。「あるけど手に入らない」というケースは見たことがない。3次受け、4次受け、となると、ドキュメントの配布が忘れ去れれてしまうのだろう。ある意味当然だ。プロジェクトの発注がツリー上に各社へ伸びていくならば、n^2のオーダーで配布ルートが増えていくのだから。

ゴリ押しで仕上げる

ひと通りの方策を打って、プロジェクトの炎上が消化できなければ、たいがい、最後は力押しになる。睡眠時間を削って極限の精神状態の中、まさにデスマーチとして行軍することになる。

教科書的には、こうなった時点でプロジェクトは失敗であり、開発機能を削る、予算を追加して納期を伸ばす、プロジェクト自体をキャンセルする、などの方法を決断しなければならない。しかし、これらのいずれかを客先に選択させるというのは容易なことではない。特に、「お客様は神様」という文化がある日本では厳しいだろう。

すると内弁慶で無能なプロジェクトマネージャーが選択できるオプションというのは、せいぜい、開発メンバの尻をムチで叩くことくらいであって、こうしてデスマーチが誕生する。

「YRP常駐」を初めて読んだときは、私は大学生であった。私が志望する業界はこんなにも辛いのか・・・と思っていたが、人間の適応力とは恐ろしいもんで、こんなもんを読んでも「あーよくあるよくある」と思えてしまう。

しかしながら、プロジェクトをこういうふうに失敗させないために日々頑張っている人たちもいっぱいいるので、こういう業界を死亡する人たちは、そういう前向きな人が多いところに就職したらいいんじゃないかな。めっちゃ投げやりだけど。