SESEのキャリア

プロジェクトが炎上するのはなぜ?逃げ方も解説【結論は見積もりが甘い】

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

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

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

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

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

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

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

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

どうすれば逃げられるかといえば・・・。

時間が過ぎる(プロジェクトが終わる)のを待つしかありません(汗)。

スポンサーリンク

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

炎上プロジェクトの特徴

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

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

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

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

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

チラッと言った

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

よほど簡単な画面でない限り、これがテスト込みで3日で終わるのって奇跡に近いですよね(笑)。

見る人が見れば、

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

となるのですが・・・。

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

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

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

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

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

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

逆に言えば、しっかりと

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

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

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

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

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

結果として、個人レベルで激務・残業の嵐。

全体的に見れば、プロジェクトの炎上状態になります。

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

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

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

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

の二つがあります。

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

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

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

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

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

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

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

PG工程らへんで、基本設計に戻ったり、詳細設計で大幅な修正が出ると目も当てられません。

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

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

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

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

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

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

です。

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

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

必要なドキュメントはいいんですよ。

「多いなぁ(´▽`*)」と思いながらも、しぶしぶ(?)書きます。

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

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

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

炎上はプロジェクトの問題であることが多い。逃げる方法は実質ない

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

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

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

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

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

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

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

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

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

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

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

そのプロジェクトがひと段落したのは、半年後。

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

プロジェクトの炎上

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

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

ひよこSEの場合、別のところに行って、ヒマになりました。時間が解決してくれる可能性は大です!

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

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

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

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

炎上プロジェクトの特徴

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

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

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

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

なので、あくまでプロジェクトの問題です。時間が過ぎるのを待ちましょう。

それでほとんどの場合は、問題なしのはず。

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

転職エージェントは、全員が全員ではなくとも、仕事中に堂々と電話してきたりする非常識な担当者もいるので大変です(「SEがつまらないのはなぜ?全6ステップで解決を目指す【改善がカギ】」という記事にも書きましたが、実際にされました)。

今すぐは、転職する気がない人も多いと思うので、放置できる、MIIDAS(ミイダス)リクナビネクストに登録して「いい求人があったら応募しようかな~」的なスタンスで待ちつつ乗り越えるしかないですね。

スポンサーリンク

▼この記事がいいと思ったら、下の画像をクリックしてくれたら励みになります!

にほんブログ村 IT技術ブログ システムエンジニアへ
スポンサーリンク
ひよこSEのつぶやきブログ

コメント

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