１．炎上プロジェクトは後を絶たない
2022年現在でも、「炎上プロジェクト」というのが後をたたないのだなとソフトウェア関係者のTweetをみていて感じます。
私は20年弱、ソフトウェア業界にいますが、「炎上」というのは昔からあって、今では少しは減っているのかと思っていますが、
どうもそうではないのだなと思います。
昔は、「デスマーチ」といっていたように思います。最近は、SNSの影響か、「炎上」と表現することの方が一般的な気もします。
以下の記事に、炎上経験のアンケート結果がありますが、4割ぐらいの人が経験ありと回答しています。
私も幾度となく経験してきました。
２．炎上プロジェクトは日程計画がおかしい
炎上を定義すると、端的には、「日程に間に合わない」ということがいえると思います。
日程を死守しようとして、人を投入したり、休出・残業をすることで、プロジェクトの進行がギスギスして問題も吹き出すことが炎上の実態だと思います。
つまり、炎上になる要因はいろいろあれど、計画された日程がおかしいということが大きく影響していると思います。
では、なぜ計画された日程がおかしいのでしょうか？
３．日程計画の誤り
（１）計画とは？
「計画」とは、物事を進めるために事前にやるべきこと決める行為です。
たとえば、以下のようなことを決定します。
・目的（どういう状態になったら達成か？）
・目的までのタスク項目とその内容
・タスクの順序
・タスクの工数（かかる時間・日数）
・タスクの日程（期限・工期）
・タスクの担当
計画を端的にいえば、目的までのタスクの順番、担当、日程を決めていくことです。
（２）タスクの洗い出しが肝心
目的が決まれば、タスクの洗い出しが重要です。
何をすべきか決めないと、担当、工数、日程も決められません。
タスクの洗い出しについては、プロジェクトに関する作業について知見があれば、より細かく挙げていくことができます。
事業年数の長い会社や経験者はこうした知見があるので、タスク列挙はしやすいのだと思います。（ちゃんとノウハウを蓄積していれば）
特に、ソフトウェア開発は、工程（要件定義、外部設計、内部設計、製造、テスト、移行、リリース、運用）が決まっているので、やることの大枠は一般的に共有されていると思います。
問題は、各工程内のより細かいタスクの列挙になっていきますが、これはプロジェクトごとに決まるし、
最初からはわからないことが多いです。
とはいえ、計画は立てないと行き当たりばったりになるので、明確にわかるところは決定して、
工数の決定の際に、もしかしたら発生するかもしれないタスクを見積もることになると思います。
（３）工数（消化時間・日数）は想定した担当のスキルに依存する
タスクがわかれば次は、誰がどれだけの工数（時間・日数）で対応できるのか見積もります。
よく工数を見積るときに、「誰がする」ということを考えずに、決めることがありますが、これは日程が狂う一つの要因だと思います。
ベテランがするのと新人がするのとでは、同じタスクでも当然工数は変わります。
よって、タスクを誰が対応するのか想定して、その担当に応じた工数を見積もるべきだと思います。
あまりハイパフォーマンスな人を想定すると、当然、工数は小さくなるのでプロジェクトの期間が短くなって、
炎上する可能性が出てきます。
ただ、多くの現場では、実際は新人から中程度の人をアサインすることが多いのに、ベテランがやったときの工数で見積もっている事が多い気がします。ハイパフォーマンスなベテランがプロジェクト内に多数いることはあまり考えにくいです。
流石に、新人を想定して見積もると、おそらく「プロとしての仕事」としては扱ってもらえないので、契約前なら失注するでしょう。
新人ですらパフォーマンスを上げられる仕事の進め方を備えている会社や組織であれば、それでも比較的少ない工数で見積もることはできると思います。
でも、多くの会社は属人的なので、やはり新人は新人なりのパフォーマンスしかでない気もします。
ちなみに、最適な工数の算出方法とかもあるそうです。
（４）工期を見積もる：１日のプロジェクト対応時間が重要
タスクごとの工数がでたらこれを合計して、これを担当人数や消化工数で割れば工期がでます。
よくやるのは、単純に1人の1日の対応時間と担当人数で工数合計時間を割り算し、日数や月数に変換すると思います。
工期（日数） = ( タスク合計(時間) / 1人1日あたりのプロジェクト対応時間 ) / 担当人数
工期（月）= 工期（日数） / 1ヶ月の稼働日数
このとき、1人の1日あたりのプロジェクト対応時間の設定が重要です。
単純に8時間としてしまうことが多いかと思います。
ただ、実際、プロジェクトそのものに残業せずに、8時間も充てられるでしょうか？
多くの場合、難しく、8時間よりも短い気もします。
もちろん、マネージメントやコミュニケーションなどの純粋な開発タスク以外も見積もっているならよいと思いますが、当該プロジェクトだけに従事することができるでしょうか？
つまり、実際には、1人が1日あたりプロジェクトに従事する時間は、他の作業のことを考慮して決定する必要があります。
たとえば、工数が160時間のプロジェクトがあったとします。これを、8時間フルで1人で対応した場合と5時間で対応した場合の差を見てみます。
160時間 / 1日8時間対応 / 1人 = 20日
160時間 / 1日5時間対応 / 1人 = 32日
単純な計算ですが、12日の差がでます。12日といえば週休2日でいえば、半月分工数にあたります。
つまり、こうして１人あたりのプロジェクト対応時間を多くしていることがかなりズレがでてくるわけです。
残業や休出する理由は明白ですね。
それから、ベテランと新人という消化工数の違いも考慮しないと工期を実態に即して見積もるのは難しいです。もし、新人の想定消化工数が少ないなら１日のプロジェクト対応時間を下げる必要があります。つまり、無駄な時間は実際の時間としてカウントしないということになります。
当然消化工数が少ないので、工期は長くなります。
（５）日程の決定：工期見積もりの前にできるわけがない
日程の決定は、往々にして計画に先行する企画のときに決まっていることがあります。
ただ、工期が決まらない限り、または、見積もらない限り、具体的な日程は決められないと思います。
開始日と終了日は大体の目星はついていると思いますが、それが妥当化は工期を見積もって最終的に決める必要があります。
そして、工期を決めるには、タスク、担当などを決めておく必要もあります。
個人的には、日程を企画の時点で決めてもよいですが、工期がわからない以上は変更する可能性は高いという認識はもつべきだと思います。
ただ、世の中には、なぜか工期がわからないのに、開始日と終了日が決まっていることがあり、さらにいえば、開始日だけは後ろにずれてプロジェクトがはじまることがあります。
もう、炎上しない方が奇跡のような状況が世の中には未だにたくさんあります。
4. まとめ
（１）日程計画がずれる要因
計画、特に、工期を見積もる過程を記載しましたが、改めてまとめみます。
・タスクの列挙が不十分
・タスクごとの工数見積もり時に想定担当のスキルが高い（実際のメンバーはそれより低い）
・１人あたりの１日のプロジェクト対応時間が多目に設定されている（実際はもっと少ない）
・工期見積りを度外視して日程を決めている
つまり、計画された日程自体がそもそも机上の想定の時点で、実態から乖離していることが日程のズレにつながるのだと思います。
とは言え、上記の原因を取り除こうとしても、やはり日程はずれるのがつきもの。
要は、そのズレの幅をどれだけ小さくするか、ずれた場合にどのように対応策をとるかが重要なのだと思います。
アジャイルの発想は、このズレを想定し、その後の対応を考えるものだと思います。
（２）日程のこまめな評価で炎上を防止する
これは本論とは直接関係ないのですが、ソフトウェア開発の現場では、WBSをつくって細かく作業日付を決めることが多いと思います。
ただ、よくズレます。とくに、先になればなるほど。
このとき、日程の調整が必要になります。
各タスクの工数自体がブレないとするなら、工数から算出した工期で間に合うか間に合わないかの妥当性をだして、
早めに、日程がずれるのは予測できると思います。
あとは、消化工数をみれば、見積もりの妥当性も評価できます。
細かい日付を逐次調整するのは時間の無駄なので、工数と工期をもとに、決まった期日に間に合うのか間に合わないのか評価し、
その時点で間に合わないなら、早めにタスクの進め方や工期の変更をした方がよいと思います。
炎上するプロジェクトは、こうした途中での工期の妥当性評価がなく、なぜか、根拠のない日付の調整ばかりをしています。
そして、なぜか工数に基づく日付の調整ではなく、期日にあわすように日付を変えています。
つまり、状態の隠蔽をしているわけです。
そして、ひどいまま期日を迎えて、大炎上となるわけです。
定期的に、工数・工期をもとに、日程の評価をしていくことが、炎上防止につながると思います。
ずれるのが問題なのではなく、それを放置することが問題なのだと思います。