なぜデスマーチは起こるのか？プログラマーの進捗管理で文系ビジネスパーソンができること

●プロジェクト失敗の理由
1.進捗管理を週単位で行っていた
2.進捗状況の報告に対し、「予定通りです」という回答を許容してしまった
3.割り込み仕事の詳細を確認しなかった
4.新人のプロ介のスキルを確認していなかった
5.プロ男の言うなりに「リファクタリング」を許してしまった
6.作業優先順位が間違っている

週単位の進捗管理では
ダメな理由

失敗の理由1を見てみましょう。
週単位の進捗管理は危険です。
プロジェクト開始時点はそれでもいいかもしれませんが、実作業に落とし込めたら早急に週二回、できれば毎日の進捗管理に変えるべきです。

人は「来週」と言われると「すぐだな」と思ってしまうのですが、実際には一年間はわずか52週間しかありません。
「それは来週」と言った時点で、一年の2％もの時間をロスしてしまうのです。

プロジェクトの長さにもよりますが、たとえばスマートフォンのアプリ開発の場合、三ヵ月や六ヵ月の短納期になることもしばしばあります。三ヵ月だとすると12週。一週間の重みは8％にもなります。

このような曖昧、かつおおらかな時間感覚は緊張感を麻痺させます。
進捗管理においては作業をどのくらい細かく分けるかという粒度が重要になりますが、一週間、つまり土日を除いた五日では、作業単位として大きすぎます。
プログラマーは週単位のほうが自分の自由度が増えてラクなので、週単位の作業単位でも特に文句は言いませんが、実際にはこれでは破綻します。

私は作業粒度のひとつの目安として、通常の作業は一時間、四時間（半日）、八時間（一日）のどれかに落とし込むようにしてもらいます。
一日単位の作業に分解できない場合、作業者が作業内容を正確に把握できていないのではないかということを疑ったほうがいいと思います。
頭のなかで作業の具体的な内容がイメージできていれば、一日単位まで具体的な作業に落とし込むことは十分可能です。これを毎日確認するのです。

確認のミーティングでは、「半日かかると思った作業が一日かかってしまいました」とか、「一時間で終わると思った作業に二時間かかってしまいました」など報告をし合います。

ここで重要なのは、遅れていてもプレッシャーを与え過ぎないことです。
遅れていることにプレッシャーを感じると、プログラマーは自然と遅れを隠すようになってしまいます。
進捗管理の現場では、むしろプログラマーが積極的に作業の遅れを報告するような空気を作らなければなりません。そうしないとあとで「やってると思っていたのに！」という事態が容易に発生してしまいます。

その他の失敗の理由2～6についてはここでは省略しますが、興味のある方は拙著『文系でも知っておきたいプログラミングとプログラマーのこと』をご覧ください。
進捗管理は文系ビジネスパーソンの役目であり、腕の見せ所です。ここをしっかり抑えて、プログラマーからの信頼を獲得しましょう。