SE 仕事内容とキャリア

プロジェクトが炎上するのはなぜ?

毎日、ほぼ終電帰りなくらい、忙しい。

SEの皆さん、いつもお疲れ様です。この記事を書いているひよこSE(@PiyoOct)も、プロジェクトの炎上の経験があります。

プロジェクト炎上する主な理由は、主に3つです。

  • 見積もりが甘い
  • 課題を先延ばしにした
  • ドキュメントがやたらと多い

最大の理由は、見積もりの甘さ。正直、これが6~7割を占めているんじゃないのかなっていう気がしています。

どうすればいいかといえば、時間が過ぎる(プロジェクトが終わる)のを待つしかありません(汗)。

スポンサーリンク

プロジェクトがする炎上の最大の理由は見積もりの甘さ

プロジェクトの炎上

SEが激務になる3つの理由と5つの解決策を現役SEが解説」という記事でも書いていますが、開発プロジェクトでは、

検索画面の実装とテストを3日でやっておいて

みたいな、めちゃくちゃな見積もりからスケジュールが引かれるのはしょっちゅうです。

めちゃくちゃなスケジュールが引かれた裏側で、具体的に何が起こってるのかが知る由もありませんが、「このくらいでできるよね?」と誰かに言われて、「はい」って言ってしまったパターンだろうなとは思います。

見積もりの根拠がなんとなくなのが一番危ない

よほど簡単な検索画面でない限り、ぶっちゃけ、「検索画面のPGと単体テストが3日で終わる」って奇跡に近いですよね(笑)。

見る人が見れば、

できるかっ!こんなスケジュールで

となるのですが・・・。

「なんとなくこれくらいでできるだろう」みたいな適当な線引きで開発スケジュールを組まれると、個人レベルでは激務になります。

見積もりの根拠がない状態、、、。本当に引いたスケジュールで終わるかは考えてられていません。

それが、1つや2つならまだしも、他の機能でも続くとプロジェクト全体のスケジュールが遅れて、炎上状態に。

見積もりの根拠があれば、大幅に狂うことはないはず

おそらく、具体的にどんな作業が必要なのかあまり深く考えてないのだとは思うのですが・・・。

逆に言えば、しっかりと

  • プログラミング:1日
  • レビューと修正:1日
  • I入力値と期待値を記載したテスト項目作成:1.5日
  • 単体試験:1.5日
  • 合計:5日
    ※これでも画面によっちゃあ、きついなぁ、、、(;´∀`)。

みたいに、完全に正しいかは別問題にしても、「見積もりの根拠」があれば、大幅にスケジュールが狂うことはないはずですけどね。

具体的な作業をイメージできなきゃ、スケジュールは引けないですよね。

「なんとなくこれくらい」というスタンスのプロジェクトに当たると、必要な工数分のお金がもらえていない状態で頑張らないといけません。

結果として、個人レベルで残業の嵐。全体的に見れば、炎上状態になります。

プロジェクトが炎上する理由は他に2つ

見積もりの甘さ・根拠のなさだけではありません。

プロジェクトが炎上する理由は他にも考えられて、

  • 課題を先延ばしにしちゃったパターン
  • 管理するドキュメントがやたらと多いパターン

の二つがあります。

課題を先延ばしにしちゃった

次に多いのが、課題を先延ばしにしちゃったパターン。

例えば基本設計のフェーズで、

帳票に出す「〇〇」って項目は、どこから取得するんだろう。どのテーブルにもそんな項目ないけど?

とりあえず課題にあげときましょう!

適当なスケジュールのもと、そもそも時間がない状態が続くと、「とりあえず課題にあげておく」みたいな先延ばしが平然と行われる状態になります。

1番最悪なのは、「やっぱできませんでした」となって、手戻りが発生することです。

PG工程らへんで、基本設計に戻ったりすると目も当てられません、、、。

まぁ、残課題がある状態で、次工程の見積もりをするなら、それが解決される見通しであること、残課題の分まできっちりと見積もるのは大前提ですよね。

管理するドキュメントがやたらと多い

よくあるドキュメントの一部を挙げると、

  • 機能・帳票一覧
  • ER図
  • テーブル定義書
  • 機能設計書
  • プログラム設計書

です。

ただでさえ、多いですよね(*´ω`*)。

※どれも運用開始となれば、必要になるドキュメントです。批判してるわけじゃなくて、単純に数が多いってことです。

プロジェクトによっては、目的が似たり寄ったりの「ダブってるやんけ(*´ω`*)」みたいなドキュメントが求められたりします。

すると、ちょっとした修正をするのにも、あれもこれも修正して、大がかりな作業になったり、、、。

まぁ、管理するドキュメントがやたら多いっていうのも、見積もりのときに考えとかないと(潜在的な遅延リスクとして考慮しないと)ダメなんですけどね・・・。

あくまでもプロジェクトの問題である場合が多い

ここまでの話を見て、察しがついているかもしれませんが、あくまでもプロジェクトの問題であることが大半です。

【体験談】初めて参画したプロジェクトは残業続きだった

管理人自身、一番初めに参画したプロジェクトは、ほぼ22~23時帰りでした。(今は、割と楽なプロジェクトにいます)

スケジュールが全然間に合っていないので、基本的には誰も帰りません。

あと一日で、PGと単体テストを終わらせるみたいな、どう考えてもおかしかった状態もしばしば・・・

メンバーのうちの一人が、

そうだ!今日は、観たいテレビがあったんだった!

みたいに思い付き(?)で、たまにスッと定時に帰って、うまいこと乗り切っていた状態です(;´∀`)。

毎日まともに23時まで残っていたら、どうにかなってしまいます(笑)。

ぶっちゃけ、上に挙げた

  • 見積もりが甘い
  • 課題の先延ばし
  • ドキュメントがやたら多い

全部当てはまってましたね・・・。

「次のプロジェクトもこんなんだったら、そのときは考えるかも」っていうときに、割とホワイトなプロジェクトに参画することになったので、「まぁ、こんなものか」となりました。

ひよこSEの場合、いつのまにか、ヒマになってました。時間が解決してくれるかも。

まとめ:プロジェクトが炎上するのは見積もりが甘いから

プロジェクトが炎上するのは見積もりが甘いからです。他に理由がありません。

  • 課題を先延ばしにした
  • 管理するドキュメントがやたら多い

という点も補足的に説明しましたが、図にするとこんな感じ。

炎上プロジェクトの特徴

それぞれのフェーズで、どんなタスクがあってそれにどのくらいの日数がかかるのか、見積もりの根拠がない

なんとなくでスケジュールを決めてしまった。

その上に積み残された課題も山積みで、ドキュメントの管理も煩雑(はんざつ)。

ほとんどのプロジェクトでは、管理がきちんとされているので見積もりが甘いなんてことは少ないですが、少数(管理人の経験からして2~3割)のプロジェクトでは、「なんとなく」がまかり通っている気がします。

結論は、時間が過ぎるのを待ちましょう。それでほとんどの場合は、問題なしのはず。

もし、会社が受注するプロジェクトの半分以上が炎上案件なら、管理人は逃げます。



コメント

タイトルとURLをコピーしました