SE 仕事とキャリア

プロジェクトが炎上するのはなぜ?長期化した場合の逃げ方も解説!

どうも!ひよこSE(@PiyoOct)です。

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

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

いつ終わるんやねん( `ー´)ノって感じですよね。

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

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

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

少なくとも、SEやプログラマーの能力不足じゃない!

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

スポンサーリンク

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

炎上プロジェクトの特徴

SEが激務なのはなぜ?3つの理由を詳しく解説【ほぼPJの環境のせい】」という記事でも書いていますが、開発プロジェクトでは、

「登録」ボタンを押して、画面の入力内容をDBに登録。そのあと帳票出力する機能の実装とテストを3日でやっておいて!

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

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

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

よほど簡単な画面でない限り、ぶっちゃけ、「画面の入力内容をDBに登録。そのあと帳票出力する機能」って奇跡に近いですよね(笑)。

見る人が見れば、

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

となるのですが・・・。

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

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

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

自分だけでなく、周りもそうなっているなら、間違いなくこれです、、、。

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

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

逆に言えば、しっかりと

  1. プログラミング:1日
  2. レビューと修正:1日
  3. 入力値と期待値を記載したテスト項目作成:1.5日
  4. 単体試験:1.5日
  5. 合計:5日

※これでも画面によっちゃあ、きついなぁ、、、(;´∀`)。

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

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

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

結果として、個人レベルで激務・残業の嵐。全体的に見れば、プロジェクトの炎上状態になります。

スポンサーリンク

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

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

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

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

の二つがあります。

課題を先延ばしにしちゃって手戻り発生⇒炎上

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

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

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

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

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

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

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

まぁ、残課題がある状態で、次工程の見積もりをするなら、

  1. それが解決される見通しであること
  2. 残課題の分まできっちりと見積もる

の2つは大前提ですよね。

管理するドキュメントが多い⇒修正も大がかりになって炎上

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

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

です。

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

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

必要なドキュメントはいいんですよ。「多いなぁ(´▽`*)」と思いながらも書きます。

ただ、トンデモプロジェクトにあたると、目的が似たり寄ったりの「ダブってるやんけ(*´ω`*)」みたいなドキュメントをいくつも書くことを求められたりします。

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

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

炎上はプロジェクトの問題であることが多い。逃げるには待つ一択

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

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

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

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

あと一日で、「単体テストとテスト結果のレビューを終わらせる」みたいな、どう考えてもおかしかった状態もしばしば・・・

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

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

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

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

ぶっちゃけ、上に挙げた

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

2は割と少なかったけど、1と3は当てはまってましたね・・・。

そのプロジェクトがひと段落。

次のプロジェクトもこんなんだったら、やめたるぞっっ!おるぁぁぁ!!!!

プロジェクトの炎上

って考えていたら、割とホワイトなプロジェクトに参画することになったので。

「まぁ、こんなものか」となりました。

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

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

「プロジェクトが炎上するのはなぜか?」と聞かれれば、見積もりが甘いからです。他に理由がありません。

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

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

炎上プロジェクトの特徴

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

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

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

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

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

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

転職エージェントは、全員が全員ではなくとも、仕事中に堂々と電話してきたりする非常識な担当者もいるので大変です(実際に、されました)。

オファー型の求人サイトで、どんな求人があるか確認するスタンスのほうがおすすめです!

【オファーを待つ(無料)】MIIDAS(ミイダス)

コメント

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