デスマーチ回想：送迎付き平社員への道
デスマーチ・プロジェクトも終わり、私はのんびり残務を進めている。工場の方は慌ただしい。先日も取締役が走り回っていた。
「おはよう怜ちゃん！」古参の社員は私を「怜ちゃん」と呼ぶ。
「今日はこれから、君が魂を込めて作った装置を○○台納品だよ！」
「おはようございます。お疲れ様です」私は苦笑しながら頭を下げる。
苦笑が混じったのは「魂を込めて」という言い回しが大仰だったからだ。そこまではしていない。傍からはそう見えたかもしれないが、違う。
芸術作品ならともかく、「魂」なる言葉は産業機器にそぐわない。産業機器のファームウェア（制御ソフトウェア）は情念よりも理知の産物で、クールに作らねばならない。また「魂を込める」という姿勢は「エゴの発露」に繋がる。これは産業機器はもとより、アート以外の商品開発に決してプラスにならない。
もっとも矜持として、成果物の仕上がりに「工芸」の美しさを求めたい。しかし「デスマーチ」と言う状況に、そのような時間の余裕は無い。
「デスマーチ」と言う言葉を広めたのは情報技術の先達者エドワード・ヨードンであり、彼の著書「デスマーチ ソフトウェアプロジェクトはなぜ混乱するのか」に、その定義が記されている。通常のプロジェクトに比べて、期間が半分以下、人数が半分以下、予算が以下、仕様が倍以上……の何れかに該当すると、そのプロジェクトはデスマーチだと言う。
確かにその辺りで「努力での対処」が限界を迎える。たとえば「人数が半分」の場合、担当者1人あたりの仕事量は通常の倍になる。これは厳しい。
計算してみよう。法律を度外視し、1人で2倍の仕事をする計画を立ててみる。通常の仕事量は1日あたり8時間、1週間あたり5日間。それを拡張し、1日あたり仕事に12時間使う計画が、果たして成り立つか？
結論、困難。「3週間（21日間）で1日だけ休む」と言う計画になる。3週間ならともかく、数ヶ月続くプロジェクトなら、担当者が倒れる。
私が遭遇したデスマーチは、まさに「通常より必要な人数が半分以下のプロジェクト」だった。ファームウェア担当が私だけだったのである。プログラミングだけではない。ソフトウェア設計、仕様書作成、設計会議の答弁、デバッグ、評価……の全てを1人で担当する。
見積もり時点では、ソフトウェア技術者を1.5人投入する予定だった。専任は私のみ、もう1人がプロジェクトの別のアプリ開発と兼任する計画である。客先が提示した要求仕様やスケジュールもまともだった。予算も「湯水のように出せませんよ」と釘を刺されたものの、必要ならば出た。
問題は客先の担当者に「仕様の盛り屋」がいたことである。
開発キックオフ後に仕様が拡張された。設計会議は長引き、スケジュールを圧迫した。ファームウェア開発の兼務担当者が担う別アプリも仕様が膨らみ、兼務の話が消えた。仕様の拡張が収まった頃、私は工数を再計算した。開発関係者一同が真っ青になった。拡張されたファームウェア仕様を開発の残期間で始末するには、担当者1人は少な過ぎた。定義通りのデスマーチの始まりである。外部協力者を探すことを含めて、関係者たちがが増員に奔走することになった。
ところで、プロジェクト管理では「工数」を「人月」という単位で表す。
「工数（人月）」＝「人数（人）」×「期間（月）」であり、「人数（人）」と「期間（月）」は交換可能と考える。つまり「工数」が定められ、「期間」の延長が出来ない場合は、「期間」の代わりに「人数」を用いることができる。ファームウェア要員の増員は、この計算に由来する。
ここでもう1冊、同じく先達者のフレデリック・P・ブルックス,Jr.の「人月の神話」を開いてみよう。ブルックスは「人と月が交換可能になるのは、多くの作業者の間でコミュニケーション（意思疎通）を図らなくても、作業が分担できる場合だけである」と説き、「システム・プログラム開発には当てはまらない」と指摘している。
さて、プログラム開発の援軍は来たが、彼等に指示できる者は私だけだった。私の仕事が増えた。同じ頃、客先と仕様書についての検討会議が行われることになり、私は終日出ずっぱりとなった。私のプログラミングは完全に停止した。
それを察したのか、客先の偉い人が私の上長に尋ねた。コントになった。
「プログラミングの担当は？」「春摘です」「仕様書の修正は？」「春摘が行います」「設計会議で喋るのは？」「春摘です」「増員した技術者に指示するのは？」「春摘です」「……お宅には春摘さんしかおらんのか！？」
さらにパニックになった関係者一同は、総力戦とばかり、ソフトウェア評価の工程に総務やら他部門のパートさん達も動員することにした。作業指示、質疑応答の担当はもちろん私だった。既に破綻が見える。私には、私にしか出来ないソフトウェア評価の予定もあったが、当然のごとく停止した。同時期、増員のプログラマが作成したコードに多くの問題があることが分かった。その手直しが出来るのも……言うまでもなく私しかいない！
私の無茶苦茶な状況を見かねた社長が、一つの提案を出してきた。
「春摘を朝と晩、送り迎えをする。我々一同は手伝うことが出来ない……ならば、出来ることをすべきだ。誰もしないなら僕がする」。
恐縮して断ろうと思ったが、頭の中で何かが「それが最適解だ」と囁いた。車を使えば通勤時間を1時間弱短縮できる。つまり睡眠時間が増える。体力も温存できる。私のパフォーマンスが上がる。足を引っ張る要素が全くない。
「朝は道が混むので」と固辞し、夜だけ送って貰うことにした。
かくして「運転手に送って貰える待遇の平社員」と言う、なんとも奇妙な立場になった。運転手は社長を含めた重役たちである。三か月ほど送って頂いた。開発の山を越えた後「もう大丈夫ですから」と遠慮することにしたが、効果はあった。心身にダメージが残らず、最後まで駆け抜けられた。
会社の倉庫から製品がどんどん吐き出されていく。ずいぶんさっぱりした倉庫を眺めていると、会社の長老が声をかけてくれた。「3年弱、よう頑張ったな。身体は大丈夫か？」「ええまあ、なんとか」私は笑って言った。
【参考文献】
・「デスマーチ 第2版 ソフトウェアプロジェクトはなぜ混乱するのか」
著：エドワード・ヨードン／日経BP社（2006年）
・「人月の神話」
著：フレデリック・P・ブルックス,Jr.／丸善出版（2014年）