こんにちは。livedoor のディレクター・菊地です。今回は、聞いただけで身が震える「デスマーチ」について書きます。「デスマーチ」状態でディレクターがやるべきこと、ディレクターがやっちゃいけない禁忌（タブー）について触れてみたいと思います。
■「デスマーチ」とは？
そもそも、自社案件で上記のような要素を持ち合わせたプロジェクトがスタートすることはほとんどありませんが、ここでは、先天的にデスマーチ要素が盛り込まれている案件ではなく、「余裕のあるスケジュールを組んだけど、あるフェーズで途端にデスマった！」というケースを想定して書きます。
■突然デスマーチ状態に突入しちゃった！ まずやるべきことは？
いったん冷静になりましょう。そしてミーティングです。「話してる暇があったら手を動かしたいんだけど……」。多くのエンジニアにはそう言われますが、パニック防止のため、そこはあえて意思疎通の場所を作ってください。
・残タスクの整理
各スタッフの残タスクを見やすいように整理整頓してください。BTS に数百個のタスクが残ってる状態で「納期割りそうなので急いでください」なんて言われると、冷静さを保てないスタッフはプライオリティを無視して片っ端から手をつけようとするかもしれません。そういった事態を防ぐ意味でも、ディレクターが作業の順番やペンディングしても良いタスクを洗い出してあげます。
・スケジュールの見直し
ここでのスケジュールは、タスク単位のスケジュールの事です。どこかで進行を妨げているタスクがあれば、重要度を精査した上で作業の順番を入れ替える等します。絶対にリスケ不可能な作業は、そうであることを明確にします。何がどこまでできていて、誰がどの部分で待たされているかなど、ディレクターはタスクの相関関係を把握しなくてはいけません。そのうえで、エンジニア同士の円滑なリレーションを支援することが大事です。そのためには、まず手を動かしているエンジニアの言葉を聞くことが大事です。余計な仕様は切り捨てる覚悟も必要です。
勘違いしてしまいがちですが、その場でリリース日の延期を提案するのは絶対に止めましょう。受注案件であればまず許可は下りませんし、そもそもクライアントからの信頼が低下します（伺いを立てるレベルでもダメです）。自社案件であっても、延期を決めた途端にユルい空気が流れますし、何も考えずそういう提案をするディレクターはまず評価されません。
■プライオリティの低いタスクを放置しない
たとえ余裕を持ったスケジュールを組んでも、たとえ十分なスタッフが配置されていたとしても、油断しているとリリース直前で「あれ？ これ終わらなくね？」と目が点になります。タスク毎のスケジュール管理が曖昧だと必ずそういう事態を引き起こします。
プログラマー 「ここプライオリティ低いから後でいい？」
ディレクター 「あ、もう全然いいっすよ全然あとあとで」
〜1か月後〜
デザイナー 「ここなんも出ないんでコーディング始められないんスけど」
ディレクター 「あれ？なんで？？」
プログラマー 「お前が後で良いっつったじゃん。後でっていつよ」
ディレクター 「……」
※ちなみに上記はいちばんひどい例です。
基本的にエンジニアは自分のタスクは自分で管理してますが、それにおんぶにだっこではディレクターの存在意味がありません。プライオリティの高低に関わらず、ひとつのタスクを曖昧にすると必ずほかの作業に影響がでてきます。複数人で開発している場合はなおさらです。やむを得ない事情で作業工程を変更する場合は、必ず影響するほかのスタッフとその担当場所を把握しておきましょう。そして、必ず変更したタスクのエンドを決めて周知してください。基本的過ぎることですが、ディレクターがここの仕切りを軽く見るとリリース直前で徹夜が多くなります。
タスクスケジュールについては櫛井の記事が詳しいので参考にしてください。『4つのステップで作る webサイト開発のスケジュール作成』
■エンジニアの周りをうろちょろしない
作業に没頭しているエンジニアを最もイライラさせるのは、落ち着きのないディレクターの突っ込みではないでしょうか。普段の状況ならまだしも、納期に追われている状況で、ディレクターの無邪気な言葉はエンジニアのハートを深くえぐります。下記のような行動は慎むべきでしょう。
・どうでもいい事で話しかける
[22:15:39] kikuchiの発言: 終わりました……？
[22:40:52] kikuchiの発言: あのー、進捗どうでしょうね？
[23:35:17] kikuchiの発言: 今作業されてます？
[23:35:20] engineerの発言: yattemasu
話したくないんです。気づいてあげてください。
・急に余計なことを思いつく
[0:40:11] kikuchiの発言: あ、思いついたんですが。
[0:45:59] engineerの発言: hai
[0:46:20] kikuchiの発言: ○○の部分、××した方がいいかもしれませんね！
[0:47:51] kikuchiの発言: △△も取り入れるとPV上がりそう！
[0:47:58] engineerの発言: それ今の私に言ってどうにかなります？
仕様策定の段階で言ってください。
・今まさに修正中の画面を指差して「バグだ！」と叫ぶ
誰が今どこを触っているか把握してください。
・パーテーションの上から覗く
そこに必ずエンジニアはいます。どこにも行ったりしません。
※すべて新人のころの私が実際にやりました。本当にごめんなさい。
ガリガリとコード書いている途中の人に、さほど重要でもない事を話しかけるのは止めましょう。作業が始まってから余計な会話を交わさなくて済むように、前述の MTG が必要なのです。作業の方向性が決まったら、あとはエンジニアを信頼して、ディレクターは耐えて自分の仕事に没頭しましょう。
■なんとか間に合った！ その後は？
短期間で作業量を凝縮して立ち上げたサービスですので、バグがたくさんあったのではせっかくの努力も報われません。リリースした直後は通常より念入りにデバッグしましょう。エンジニアもテスターも相当疲弊しきった状態で作業を進めていたので、通常ならあり得ない判断ミスをしているかもしれません。個々のスタッフの責任に依存するのではなく、プロジェクトを統括する立場として、リリースから数日は責任を持ってチェックしてください。
また、今回は「突発的にデスマーチ・プロジェクトに変化した場合」について書いています。その原因はディレクターの采配ミスに因るところが大きいと思います。プロジェクトを振りかえって原因と対策を洗い出し、次の仕事に生かせるようにしましょう。あくまでモチベーションは上向きで。そしてプロジェクトのメンバーとは良好な関係を保つべく、互いの健闘を称え合いましょう。打ち上げの幹事もディレクターの仕事です（と、勝手に思っています）。
いかがでしたでしょうか？「デスマーチ」本当に恐ろしい出来事ではありますが、実際に直面したときに慌てるだけのディレクターでは信頼されません。危機感全開な事態にこそ、ディレクターの真価を発揮すべきではないでしょうか？
■「デスマーチ」とは？
この言葉を広めたエドワード・ヨードン（Edward Yourdon）氏は、著書「Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects」（1997年）の中で、デスマーチ・プロジェクトの定義として次の項目を挙げている。
1. 与えられた期間が、常識的な期間の半分以下である
2. エンジニアが通常必要な人数の半分以下である
3. 予算やその他のリソースが必要分に対して半分である
4. 機能や性能などの要求が倍以上である
※参考：＠IT情報マネジメント用語事典
そもそも、自社案件で上記のような要素を持ち合わせたプロジェクトがスタートすることはほとんどありませんが、ここでは、先天的にデスマーチ要素が盛り込まれている案件ではなく、「余裕のあるスケジュールを組んだけど、あるフェーズで途端にデスマった！」というケースを想定して書きます。
■突然デスマーチ状態に突入しちゃった！ まずやるべきことは？
いったん冷静になりましょう。そしてミーティングです。「話してる暇があったら手を動かしたいんだけど……」。多くのエンジニアにはそう言われますが、パニック防止のため、そこはあえて意思疎通の場所を作ってください。
・残タスクの整理
各スタッフの残タスクを見やすいように整理整頓してください。BTS に数百個のタスクが残ってる状態で「納期割りそうなので急いでください」なんて言われると、冷静さを保てないスタッフはプライオリティを無視して片っ端から手をつけようとするかもしれません。そういった事態を防ぐ意味でも、ディレクターが作業の順番やペンディングしても良いタスクを洗い出してあげます。
・スケジュールの見直し
ここでのスケジュールは、タスク単位のスケジュールの事です。どこかで進行を妨げているタスクがあれば、重要度を精査した上で作業の順番を入れ替える等します。絶対にリスケ不可能な作業は、そうであることを明確にします。何がどこまでできていて、誰がどの部分で待たされているかなど、ディレクターはタスクの相関関係を把握しなくてはいけません。そのうえで、エンジニア同士の円滑なリレーションを支援することが大事です。そのためには、まず手を動かしているエンジニアの言葉を聞くことが大事です。余計な仕様は切り捨てる覚悟も必要です。
勘違いしてしまいがちですが、その場でリリース日の延期を提案するのは絶対に止めましょう。受注案件であればまず許可は下りませんし、そもそもクライアントからの信頼が低下します（伺いを立てるレベルでもダメです）。自社案件であっても、延期を決めた途端にユルい空気が流れますし、何も考えずそういう提案をするディレクターはまず評価されません。
■プライオリティの低いタスクを放置しない
たとえ余裕を持ったスケジュールを組んでも、たとえ十分なスタッフが配置されていたとしても、油断しているとリリース直前で「あれ？ これ終わらなくね？」と目が点になります。タスク毎のスケジュール管理が曖昧だと必ずそういう事態を引き起こします。
プログラマー 「ここプライオリティ低いから後でいい？」
ディレクター 「あ、もう全然いいっすよ全然あとあとで」
〜1か月後〜
デザイナー 「ここなんも出ないんでコーディング始められないんスけど」
ディレクター 「あれ？なんで？？」
プログラマー 「お前が後で良いっつったじゃん。後でっていつよ」
ディレクター 「……」
※ちなみに上記はいちばんひどい例です。
基本的にエンジニアは自分のタスクは自分で管理してますが、それにおんぶにだっこではディレクターの存在意味がありません。プライオリティの高低に関わらず、ひとつのタスクを曖昧にすると必ずほかの作業に影響がでてきます。複数人で開発している場合はなおさらです。やむを得ない事情で作業工程を変更する場合は、必ず影響するほかのスタッフとその担当場所を把握しておきましょう。そして、必ず変更したタスクのエンドを決めて周知してください。基本的過ぎることですが、ディレクターがここの仕切りを軽く見るとリリース直前で徹夜が多くなります。
タスクスケジュールについては櫛井の記事が詳しいので参考にしてください。『4つのステップで作る webサイト開発のスケジュール作成』
■エンジニアの周りをうろちょろしない
作業に没頭しているエンジニアを最もイライラさせるのは、落ち着きのないディレクターの突っ込みではないでしょうか。普段の状況ならまだしも、納期に追われている状況で、ディレクターの無邪気な言葉はエンジニアのハートを深くえぐります。下記のような行動は慎むべきでしょう。
・どうでもいい事で話しかける
[22:15:39] kikuchiの発言: 終わりました……？
[22:40:52] kikuchiの発言: あのー、進捗どうでしょうね？
[23:35:17] kikuchiの発言: 今作業されてます？
[23:35:20] engineerの発言: yattemasu
話したくないんです。気づいてあげてください。
・急に余計なことを思いつく
[0:40:11] kikuchiの発言: あ、思いついたんですが。
[0:45:59] engineerの発言: hai
[0:46:20] kikuchiの発言: ○○の部分、××した方がいいかもしれませんね！
[0:47:51] kikuchiの発言: △△も取り入れるとPV上がりそう！
[0:47:58] engineerの発言: それ今の私に言ってどうにかなります？
仕様策定の段階で言ってください。
・今まさに修正中の画面を指差して「バグだ！」と叫ぶ
誰が今どこを触っているか把握してください。
・パーテーションの上から覗く
そこに必ずエンジニアはいます。どこにも行ったりしません。
※すべて新人のころの私が実際にやりました。本当にごめんなさい。
ガリガリとコード書いている途中の人に、さほど重要でもない事を話しかけるのは止めましょう。作業が始まってから余計な会話を交わさなくて済むように、前述の MTG が必要なのです。作業の方向性が決まったら、あとはエンジニアを信頼して、ディレクターは耐えて自分の仕事に没頭しましょう。
■なんとか間に合った！ その後は？
短期間で作業量を凝縮して立ち上げたサービスですので、バグがたくさんあったのではせっかくの努力も報われません。リリースした直後は通常より念入りにデバッグしましょう。エンジニアもテスターも相当疲弊しきった状態で作業を進めていたので、通常ならあり得ない判断ミスをしているかもしれません。個々のスタッフの責任に依存するのではなく、プロジェクトを統括する立場として、リリースから数日は責任を持ってチェックしてください。
また、今回は「突発的にデスマーチ・プロジェクトに変化した場合」について書いています。その原因はディレクターの采配ミスに因るところが大きいと思います。プロジェクトを振りかえって原因と対策を洗い出し、次の仕事に生かせるようにしましょう。あくまでモチベーションは上向きで。そしてプロジェクトのメンバーとは良好な関係を保つべく、互いの健闘を称え合いましょう。打ち上げの幹事もディレクターの仕事です（と、勝手に思っています）。
いかがでしたでしょうか？「デスマーチ」本当に恐ろしい出来事ではありますが、実際に直面したときに慌てるだけのディレクターでは信頼されません。危機感全開な事態にこそ、ディレクターの真価を発揮すべきではないでしょうか？
コメント
コメント一覧 (1)