本「デスマーチ 第2版」の紹介。トリアージが特に重要だ！
本
デスマーチ 第2版という本を読みました。
いろいろ思うところがあったので、ちょっと書きます。
デスマーチとは
IT業界に勤めている方は言わずもがなご存知ですよね。
ウィキでは以下のとおり。
デスマーチ (death march) とは、プロジェクトにおいて過酷な労働状況をいう。本来は、コンピュータプログラマのアンドリュー・ケーニッヒ（英語版）によって1995年に示された、コンピュータシステムのアンチパターンのうち、プロジェクトマネジメント上の問題点の1つとして示した言葉である。日本語では、しばしば「デスマ」と略される。
ソフトウェア産業に限らず、コンピュータが関係する一般的なプロジェクト全般で使われるようになってきており、特に納期などが破綻寸前で、関係者の負荷が膨大になったプロジェクトの状況を表現するのに使われる。「死の行進」「死の行軍」等とも呼ばれる。
引用元：ウィキペディア
過去にいくつか体験済みです。
ソフトからハードなもの、かなり理不尽なものまでありました。
デスマーチにパワハラが加わると、もう行き地獄と化します。
生き地獄はさておき、このような悲惨なソフトウェア開発プロジェクトには、トリアージが必要になると、著者は提言されてます。
「トリアージ」という概念
トリアージとは。
ウィキでは以下のとおり。
トリアージ（仏: triage）とは、患者の重症度に基づいて、治療の優先度を決定して選別を行うこと。トリアージュとも言う。語源は「選別」を意味するフランス語の「triage」である。
救急事故現場において、患者の治療順位、救急搬送の順位、搬送先施設の決定などにおいて用いられる。識別救急（しきべつきゅうきゅう）とも称する。
トリアージはまた、病院の救命救急部門（ER）受付や、救急通報電話サービスでも行われている。
引用元：ウィキペディア
ぶっちゃけ、優先順位付けのことですね。
で、この本では、救命救急のトリアージを、IT業界で行っているプロジェクトにも使いましょうと。
P130
- やなねばならぬ（must-do）
- やったほうがいい（should-do）
- やれればやる（could-do）
トリアージによるプロジェクト戦略は明確で、「やらねばならぬ」要求項目に最初に力を集中し、時間が残っていれば「やったほうがいい」要求項目に力をそそぎ、奇蹟が起これば、「やれればやる」要求項目に手をつけるのである。
引用元：デスマーチ 第2版
と、いうように優先順位付けをして、ソフトウェアに実装する機能を限定する。
これにより、仕事自体を減らし、プロジェクトに参画するメンバの負荷を低減する。
そして無事、システム本番稼働にこぎつけましょうと、こう言うことです。
とても理にかなっていますね。みんなが、みんなこう考えて行動できると理想的なんですけど。
フォースな方々大勢いるとそうもいかないのが世の中ですよね。残念。
「そこそこ使える（good enough）」なソフトウェア
P145
もし我々が「やらねばならぬ」要求項目と、妥当な数の「やったほうがいい」要求項目をインプリメントすることができれば、「そこそこ使える（good enough）」と言えるのだ。P147
だが、デスマーチ・プロジェクトでユーザーが真に望むものは、そこそこ安く、そこそこ速く、そこそこ機能があり、そこそこ安定しており、そこそこすぐ使えるものである。つまりこれが「そこそこ使える」ソフトウェアの定義なのである。引用元：デスマーチ 第2版
「そこそこ使える（good enough）」という考え方がgoodです。
なんでもかんでもできるのではなく、キモになるコトがちゃんとできる、ということです。
何かクリエイティブなことをしている時、完成版は「そこそこ使える（good enough）」ものにする。
「やらねばならぬ（must-do）」と「やったほうがいい（should-do）」を盛り込み、「やれればやる（could-do）」はキッパリ切り捨てるということですね。
そうすれば、そこそこ安定して、そこそこ使えるものができあがると。良いこと尽くめじゃないですか。
ソフトウェアに限らず、車だって機能満載フル装備でも、使う機能は限られています。
自動縦列駐車機能があるんで、わざわざ使ってみました。
が、この機能を実行するためのセッティングが複雑で、結局自分で車を操作した方が早かったです。
この機能は、「やれればやる（could-do）」だったかもしれません。
パーキンソンの法則
P175
プロジェクトの安全係数に余裕がありすぎれば、余った時間を使い切るまで引き延ばす、という「パーキンソンの法則」に従うことになる。引用元：デスマーチ 第2版
パーキンソンの法則（パーキンソンのほうそく、英: Parkinson’s law）は、1958年、英国の歴史学者・政治学者シリル・ノースコート・パーキンソン（英語版）の著作『パーキンソンの法則：進歩の追求』、およびその中で提唱された法則である。役人の数は、仕事の量とは無関係に増え続けるというもの。
具体的には、
第1法則：仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する
第2法則：支出の額は、収入の額に達するまで膨張する
の二つからなる。引用元：ウィキペディア
強烈ですよね、パーキンソンの法則。
この法則は、さまざまなプロジェクトだけではなく、実生活でもおもいっきり機能しています。
夏休みの宿題が最終日までずれ込む、冷蔵庫が満杯になる、給料日前にはふところがスッカラカンなどなど。
例を挙げればキリがないほど、我々の実生活に溶け込んでいます。
で、対策です。
第一法則では、期限を切るしかありません。しかも、適切に。期限を切ったところで、それが長すぎれば、ダラダラ対応してしまったり、品質を極限まで高めてしまったりするワケです。ですから、ほどほどに期限を切るのが、重要となります。
第二法則では、天引きです。給料が入ったら、まず、貯蓄額を天引きして、残りを使うようにする。そうしないとお金は無くなるまで消費され続けます。給料の天引きについては、明治の富豪 本田静六の本「私の財産告白」が参考になります。
ちなみに、天引きには触れてませんが、この本に関する記事も書いてます。内容は幸福についてでこちらです。
時間、お金以外のスペースについては、ほどほどでいいんで、ミニマリストを目指すのがいいでしょう。
ミニマリストに関する記事はこちら。
プロセスよりもアウトプット
P192
たとえば、組織のトップがプロジェクト・マネジャーに、「我々は、プロジェクトが期限どおりに完了すること以外には興味がない。プロジェクトの中ならタスクや作業をどのように編成してもかまわない。プロジェクトが成功したら、チームの全員にまとまったボーナスを出す」と言うべきだ。だが、たいていの組織は、支配的な組織文化に染まっていて、プロジェクト・マネジャーはプロジェクトの小さなタスクと作業に分けることを強いられる。しかも、その文化は、個々の従業員の仕事を過剰こ細かく規定し、従業員は個々のタスクを期限どおりに完了することが求められる。現実には、毎回、プロジェクトの成功不成功に関係なく自分のタスクを期限どおりに仕上げるものが報酬を受け、プロジェクトが成功しても期限より遅れて自分のタスクを完成させた者は罰せられていた。P195
別の例を示そう。多くの組織では、作業者の業績はどれほど忙しいかで評価され、マネジャーは作業者を働かせるように管理するのにどれほど忙しいかで評価される。このままの言葉で表現されることはないだろうが、仕事をしているときに、１時間何もしないで机に座っていると、何か悪いことをしているように（または、素直に恐ろしく）感じたことはあるだろう。また初めてマネジャーになりたまたま副社長が作業場所をぶらぶら歩いてきて、自分の部下が何もしないで座っているのを目撃したら、どんなに罪悪感と無力感にさいなまされるか想像してほしい。引用元：デスマーチ 第2版
日本の会社では、一般にアウトプットより、プロセスや仕事の態度が重視されます。
ふだん真面目に仕事していることが美徳とされています。それが仮に、仕事しているフリだったとしてもです。
家庭においても同様ではないでしょうか。
子供の通知表やテスト結果より、普段勉強している姿の方が、親の満足度は高いかもしれません。
子供がずっとスマホで遊んでいたりすると、親はイライラするでしょう。
ここはぐっとこらえて、プロセスではなく、結果（通知表、テスト）で評価したいところです。
まとめ
この本を読んで一つだけ意識してほしいことがあったら、トリアージであると著者は言っています。
それほど、IT業界のプロジェクトでは、優先順位を意識せず、なんでもかんでも機能盛り込みが横行していると言えるでしょう。
パーキンソンの法則、アウトプット重視についても触れています。これらはトリアージを含め、普段の生活でも使えます。知っておいて損はないでしょう。
普段の生活において、うまくいかなかったり、違和感を感じたら、これらにハマっていないか振り返るといいです。
