お疲れ様です。このページに来ているということは、今まさにプロジェクトが炎上中なわけですね？
なぜこんなにプロジェクトは燃えるんでしょうか。きついですよね。死にたいですよね。胃袋ギュンギュンしますよね。とてもわかります。
焦らないでください。まずは深呼吸。冷静が一番です。
さぁ、スケジュールもリソースも限られています。僕の言うとおりに整理していけばあなたはこの大火事を乗り切ることができます。一緒にこの大火事を沈下させましょう。
Contents（目次）
現状のタスクをすべて書き出す
まずは現状の整理です。
A4ぐらいの紙とボールペンを用意してください。ホワイトボードでもいいです。
いま見えているタスクをとにかく箇条書きにしましょう。
できるだけ細分化して書くのがおすすめです。
プロジェクト管理ツールを使っている場合は、その番号とタイトルを書き出すと良いでしょう。
ポイントとしては、かかる工数や難易度、スケジュールなどは一旦気にせず、とにかくすべてのタスクを紙に書き出しましょう。
もう完全にテンパっちゃってる場合はチームのメンバーや上司と一緒に、手伝ってもらうとGood。
多少時間がかかるかもしれません。でも、この作業は時間がかかっても頑張りましょう。
私の経験上、この30分や1時間の作業が、1日、一週間、1ヶ月もの余裕を生んでくれたことが何度もありました。
各タスクの工数をエンジニアやデザイナーに確認する
書き出したタスクの中で次の２つについて、エンジニアやデザイナーに工数を確認します。
この時の確認ポイントは次のポイントで聞きましょう。
この時もできるだけエンジニアやデザイナーと膝を突き合わせて対面で話すことが大事です。
「そんなことより作業時間をくれ」と言われるかもしれませんが、ここは頑なに打ち合わせの時間を持ちましょう。
「やらなくて良い作業を見つけられるかもしれないのでお願いします」とか言うと効果的です。
各タスクのすべての工数を書き出す
デザイナーやエンジニアに聞いた工数をタスクの横に書きましょう。
細かく書くとめんどくさいと思うので、「すぐ終わる」「半日」「1日」「2－3日」「1週間」とかその程度でかまいません。
見積もり表を作るわけではないので、ここには時間をかけないでください。「大」「中」「小」とかでもいいです。
期限までに終わってないと致命的なことだけに印をつける
どんなに期間がかかっても、致命的なことはやらないといけません。致命的なことがもう期間的に間に合わなければスケジュール変更をする必要がありますし、この判断がとても重要です。
判断基準は次のように考えましょう。
シンプルに言えば、訴訟を起こされるかどうかで考えてください。やばい裁判沙汰だ！と思うようなことはなんとかやるしかありません。
致命的なタスクをまずエンジニアとデザイナーに依頼する
印をつけた致命的なタスク一覧をエンジニアとデザイナーに見せてください。
「この致命的なタスクは遅かれ早かれ絶対にやらなきゃいけないので、順番はおまかせしますがやってください」と依頼しましょう。
工数が小さくてすぐにできるものからやってもらってもいいと思います。
致命的なものに着手してもらっている間に、webディレクター側は少し時間が稼げます。
やらなくても困らないタスクは削除する
次にやらなくても困らないタスクを削除しましょう。
redmineやBacklog、書き出したタスクの一覧を見ると次のような種類のタスクがあることに気づくはずです。
いいですか？全部無視してください。これらのタスクはもう炎上しちゃってる状況では一番後回しにするべき課題です。
無視するのが現実的に難しい場合は、あとで述べるようにフェーズわけをしてリリース後に改修すれば許されることが多いです。
「あとでやるんだけど、ごめんそれいまじゃないんで」と現場＆お客さんに伝えます。
クライアントに確認＆取捨選択してもらう
ここまで整理できていれば、よっぽどのモンスタークライアントでない限り状況を察してくれます。
ここで大事なことをいうので覚えておいてください。
「お客さんが一番一番困るのは、プロジェクトが完了しないことよりも現状が把握できないこと」です。
これは確実にいえます。向こうもお仕事でやってるわけで、スケジュール通りにうまくいかないことがあるのなんて百も承知です。
でも現状の課題が見えてないのが一番困るんです。対応のしようもないし、お客さんの社内や上司、仲間に説明ができない。
ここでここまでの整理が役に立ちます。
上記をお客さんに見せます。
「スケジュール的に厳しい状況で、すべてのタスクを完了するのが難しい状況です。優先度をつけてみたので認識があっているか確認してください」
というと、まぁ怒られはすると思うんですが、タスクの整理は手伝ってくれると思います。
2つ注意点があるので気をつけましょう。
1つ目は、火に油を注がないためです。
2つ目は、「確かにそれもやったほうがいいよね」とタスクが増えることを防ぐためです。
一時的なリソース追加を上司に依頼する
ここまで来たらやらなければいけないことと優先度は全てはっきりしている状況なはずです。
一時的にリソースを追加できないか相談をしましょう。
依頼する際は、もともとのリソースでは足りないタスクが何なのか明確に伝えることが必要です。
ここでも整理したタスク表が役に立ちます。緊急時です。整理した表をそのまま見せてもいいでしょう。
緊急リソースの人たちに対応してもらうのがオススメのタスクは次のようなものです。
仕様をよく知っている人が致命的なタスクの対応に集中できるようにリソース配分を行うのがポイントです。
大きいタスクをやる人と小さいタスクをやる人に分ける
あとはやるだけの状況になったら、大きい工数担当の人と小さい工数のものをたくさんやる担当の人を分けます。
工数が必要な作業に集中できますし、タスクの数も効率的に減らしていくことが可能です。
フェーズわけをする
ここまで整理しましたが、間に合わないものはどうやっても間に合いません。
最終手段はタスクの優先度にあわせてフェーズわけをすることです。
例えば主要な機能はリリース日までに対応し、その微修正は1週間後、2週間後、1ヶ月後にリリースするというやり方です。
ウォーターフォール開発の一番の問題点は、仕様の変更やスケジュールの遅延を吸収しづらいという点です。
サービス全体を考えた時にすべての機能が重要というわけではなく、主要な機能が予定通りにリリースされていれば問題ないはずです。
主要な機能と微修正をフェーズわけするところまで整理できれば、もうプロジェクトは炎上してないはず！！
