TL;DR

現在の文脈において、なぜデスマーチが起きてしまうのかを３名のソフトウェアエンジニアへのインタビューを基に社会学のアプローチを用いて考察した書籍。

ソフトウェア開発はデスマーチが起こりやすい性質がある

IT業界ではよくある話としてのデスマーチですが、その原因についてあまり考えてこなかったということもあり、読んでみました。 本の中では主に著者がソフトウェアエンジニアに対して行ったインタビュー内容とその考察が記されているのですが、インタビュー内容はうなずきながら読むことができ、また著者が社会学の博士課程を通じて専門としていることもあり、そのインタビュー結果を解釈するプロセスが勉強になりました。

僕が特に面白いと感じたのは、__ソフトウェア開発はデスマーチになりやすい性質がある__という著者の視点です。 本の中でも述べられているように、エンジニアはそもそも「ソフトウェア開発」はどういったプロセスなのかを考えることはあまりありません。確かに僕もただ作りたいと思っているものをコードとして書き出すということをしているわけですが、この作業は__抽象的な要求を具体的なものとして落とし込むプロセス__だと著者は考え、その性質がデスマーチを起きやすくしていると考察しました。

確かに業務を考えてみると、仕様書や口頭でソフトウェアに関する要求を理解し、実際はそれを微妙にコードで調整しながら、お互いの認識に合う落とし所となるプログラムを作成していきます。 つまり、ソフトウェアが完成するまで具体的な仕様は決定せず、時間やコストの見積もりはかなり困難であることになります。例えば、あるライブラリの機能を使ってソフトウェアを作る際に、そのライブラリの仕様が変わる、ドキュメントと実際のコードに差異があったということを経験した方は少なくないでしょう。 その結果、開発に見積もり以上の工数がかかるのは現場のエンジニアの能力以前に、ソフトウェア開発の性質となります。

そのために、製造業的な見積もりし、限られた納期を伸ばすという想定がなされないまま、仕事が依頼され、エンジニアは死の行進へと向かいます。

遊び感覚のソフトウェア開発もいつまでも遊びではいられない

インタビューを通じて、さらにわかったのはデスマーチに陥る理由はエンジニア側にも存在するとしています。特に若い頃から遊び感覚でプログラミングを行ってきたエンジニアは、仕事は遊びの延長であり、長時間ソフトウェアを書くことを苦にしないという方が多くいます。 しかし、そうしたエンジニアも次第に年齢を重ねるに従って、自身の健康や家族との時間を過ごしたり、両親の看病するなど様々な外的要因によって徐々に開発や勉強にかけられる時間が減るという問題が出てきます。

そのようなプレッシャーの中で先の見通しにくいソフトウェア開発は、肉体的にも、精神的にも、エンジニアを追い詰め、最終的に燃え尽きてしまうということが起こってしまうのです。

この本は単純にデスマーチは__人・時間が足りないから起こるという結論で済まされがち__なところを、上記のようなソフトウェア開発の性質やそこに携わる人や組織の観点からより深く分析をしており、またその分析手法も社会学の方法を取り入れて出来るだけ客観的に試みているところが面白く感じました。

関連書籍

ソフトウェア開発では 人数を増やしても仕事は早く終わらない、むしろ長期化する恐れがある ということを世に主張した言わずと知れた著作です。 20世紀中頃まで一般的に行われていた産業では仕事を細分化して、大勢の人に割り当てれば仕事も早くこなすことができていました。しかし、近年、ソフトウェアに代表されるように、作るものが複雑化するに従って、人数が増えてもプロダクトの説明や教育に時間がかかり、また仕事を細分化するのが難しいなかで、プロダクトマネージャーはどうしたらよいのかを知ることができます。

個人的には、ソフトウェア開発は手術みたいなもので、プロジェクトマネージャとしての正しい方針はまずプロジェクトの性質を見極め、設計1/3、実装1/6、テスト1/4、統合・実地テスト1/4という割合で時間を配分し、手術と同様、執刀医、副執刀医を決めて、その二人を補助するように他のプログラマを配置すると良いという発想が斬新でした。