「デスマーチ」読んだ

悲しみの連鎖を断ち切りたい人におすすめします。

はい。「デスマーチ」。エドワード・ヨードン著で本屋さんに行けばだいたい、デマルコ本と並んでますよね。

デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか

わりと前々から読みたいと思っていたんですが、なかなか優先度低くて買ってすらなかったんですが、去年一年を通して読むべきだなーと実感したので、タイミング良くKindle本のセールの時期だったのもあり買いました。

目次こんなんです。

第1章 はじめに
第2章 政治
第3章 交渉
第4章 デスマーチ・プロジェクトの人々
第5章 デスマーチ・プロセス
第6章 プロセスのダイナミックス
第7章 クリティカルチェーンと制約条件の理論
第8章 時間の管理
第9章 進捗の管理と制御
第10章 デスマーチのためのツールと技術
第11章 シミュレーションと「戦争ゲーム」

感想とかは正直読めとしか言いようがない。この本を読んでいると「ああ、あの時そういう選択肢もあったんだな」っていうのが、思い浮かんでちょっとやるせない感じになる。などと、書いていても仕方ないので少しだけ感想を書く。

そもそも本書における"デスマーチ"とはなにか。著者の定義では「デスマーチ・プロジェクトとは、『プロジェクトのパラメータ』が正常値を50%以上超過したもの」だそうで、具体的には「プロジェクトのスケジュールを常識的に見積もった期間の半分以下に圧縮したプロジェクト」とか「通常必要な人数の半分しかエンジニアを割り当てないプロジェクト」とか「予算やその他の必要資源が半分に削られたもの」という条件のもの。そこからすぐに現れる影響として、生産効率を2倍にしたり、作業時間を2倍にするように言われると…。どこかで聞いたことありますよね。…はぁ…。

普通に考えて作業時間を2倍にするということは、通常1日に8時間働く計算だったとしても16時間労働になるわけでして、あー嫌だ嫌だ。16時間なんて働きたくない…。つまりはそういう状態のプロジェクトをデスマーチ・プロジェクトというわけです。というか、もう定義するまでもなくデスマーチといえば、ああ残業しまくっててひどいんだなーって普通に思いますよね…。

著者曰く「デスマーチ・プロジェクトは、常態であって、例外ではない」らしく、これが冒頭にずばっと書いてあって「じゃあ、この本で言いたいことってなんなんだよ！」って思うわけなんですが、「デスマーチ・プロジェクトが避けられないなら、それから生き残るにはどうしたらよいか？成功の機会を増やすには何をすべきか？どこで妥協すべきか？自分のやり方が受け入れられなければ、いつ辞めて職探しをすべきか？」というのを本書では述べられています。

この本読んで大事だなって思ったことは幾つかあって、特にそう感じたのは「政治」「交渉力」「トリアージ」このあたりかなーと。
プログラマというより、一般的な(?)エンジニアの大多数が「政治」を嫌うと思います。偏見もありますが、そんな気がしています。だけど、アジャイルだー、リーンだー、とか言って実現するためには社内政治に勝つ或いは、社内政治に長けた人を味方に付ける必要があると思います。まぁそもそもそこから逃げるというのも選択肢のひとつでしょう。なんにしても現実のプロジェクトで戦うには政治力ないし、政治に長けた味方というの必要だと感じました。で、政治に長けているだけじゃなくて、どこまでなら譲れるか或いはなには譲れないかというのをやりとりして、トレードオフしていく交渉能力というのも政治の世界では必要だと感じた。時間削るなら人を増やしてくれ、みたいな、そういうのを上手くやるのもひとつのスキルだし、本気でプロジェクトを成功に導きたいならこういう面でも努力必要だろうなーって。Twitter見ていると「プログラマに非技術的なことを求めるのはそもそも組織として間違っている」っていう人がいるし、これは正論だと思うんだけど「プログラマだから非技術的(政治とか)に無関心でいいか」というのは違うと思うです。僕はね。

えっと、後は「トリアージ」という概念を初めて知ったんだけど、これは日々何かしら知らないうちにやってると思います。例えばゲームとかで回復薬が僅かのときに、誰に使うのが一番効果的かーみたいなのを考えてたりするのはトリアージだと思う。

古典的なウォータフォール型ライフサイクルか、最近のスパイラル型やプロトタイピング方法論にかかわらず、方法論には微妙で表面に出てこない仮定がある。その仮定とは、「人は、完了予定日までに、どうにかしてすべてを仕上げる」である。

これですね。どんなにアジャイルだー、スクラムだーなんて言っても人がやれる仕事量は限界がある。それを現実的に見積もった上で、なにかを切り捨てないといけない。*1なのでシステムの要求項目を「やらねばならぬ」「やったほうがいい」「やれればやる」と3つに分ける、トリアージ・スタイルというものがあるのを学んだ。これは実際に使えるかどうかはひとまず置いておくとして、今後プロジェクトに参画していく上で重要だと個人的に思った。

本の中ではプロジェクト・マネージャーかくあるべきというふうに多くを書かれていて、プログラマに関係ねーじゃんっていう話もだいぶあります。というか、大部分はPM層に向けて書かれていると言っても過言ではない気がしていますが、ただそこから何を得るかもまた読む人次第だろうと。

まぁそんなわけで年末からスキマ時間に読んでいた本をなんとか読破しましたよっと。

*1:もし何も切り捨てなくていいなら、それはきっとデスマーチではないはずだから