こんにちは、やまさんです！！
連日続く徹夜。
倒れていく周りのSE。
プロジェクトが炎上すると本当に悲惨です・・・
やまさんも炎上プロジェクトに
参加していたことがあります^^;
なぜプロジェクトは炎上してしまうのでしょうか。
この記事ではプロジェクト炎上の理由と
回避策ついて話をしていきたいと思います。
Contents
炎上プロジェクトの主な特徴
プロジェクトが炎上する主な理由は４つです。
- 極端な短納期
- 工数、予算の圧倒的不足
- 想定外のIT技術的な問題の発生
- 仕様変更、仕様追加が多発
それぞれ詳しく見ていきましょう！！
極端な短納期
プロジェクト開始前には営業さんが
お客さんから案件を取ってきます。
このとき、ムリに案件を取ろうとして
極端な短納期を約束してしまう
ケースがあります。
お客さんはたいてい複数の会社から
見積りを取っているんですよね。
コンペってやつです。
このとき、営業さんが案件を取りたいあまりに
SE側の意見を聞かずに短納期を
約束してしまうことがあるんです。
結果、SEは反対したけど、営業さんが
受注してしまってやるしかない状況に・・・
なんてことがあったりします。
このケースの根本原因は人間関係や
会社組織の文化です。
スキルや技術とは違うところの話なので
根が深いのです・・・
工数、予算の圧倒的不足
これも”極端な短納期”と同じで
営業さんとSE側の意見を聞かず、
営業さんがムリに案件を
取ってきたケースで多いです。
根本的には社内での営業と開発部門の力関係や
その会社の社風などが原因です。
なお、SE側の見積り誤りが
原因のこともあるんですが、
多くの開発は過去に似たようなプロジェクトが
存在します。
過去に行った類似プロジェクトを参考にすれば、
SE側が見積りを大きく外すようなケースは
かなり少ないです。
なので、こちらも根本原因は
人間関係や会社組織の文化にあります。
想定外のIT技術的な問題の発生
プロジェクト進行中に技術的な問題が
発生してしまったパターンです。
この場合、解決のための作業量が大きくなり
炎上してしまいす。
このケースは業務システムよりは
基盤システム側で発生することが多く、
例外的なことをやろうとした場合に
よく発生します。
仕様変更、仕様追加が多発
プロジェクト後半で仕様変更や仕様変更が多発。
それでも納期はズラせなくて
炎上するパターンです。
炎上プロジェクトはこの仕様変更、
仕様追加多発によるケースが大半を占めます。
仕様変更や仕様追加が多発する理由は
いろいろあるんですが、
たいていはプロジェクトマネージャー（PM）
プロジェクトリーダ（PL）の力不足です・・・
プロジェクト前半の要件定義工程段階で
システム導入の目的と達成条件を
お客さんから聞き出せていないのです。
たいていの会社ではPM、PLはSEとして
結果を出した人が昇進という形でなります。
ただ、SEで優秀だったとしても
PM、PLになって優秀であるかはまた別です。
SEで求められる能力とPM、PLで
求められる能力が違うんですよね。
SEはITスキルのレベルが高ければ、
大抵の場合、仕事がデキると言われます。
一方で、PM、PLはSEよりも
高いビジネススキルが必要とされます。
ビジネススキルが低く、プロジェクト前半で
システム導入の目的と達成条件をお客さんと
共有できていない場合、そのプロジェクトは
開発後半で炎上してしまいます。
炎上プロジェクトの回避策
人間関係が原因のことも・・・ ひどい場合は転職も検討
極端な短納期や工数、予算の圧倒的不足で
プロジェクトが炎上している場合の
解決策ですが、個人で解決するのは
難しいケースが多いです。
根本原因は営業と開発部門の
コミュニケーション不足や
会社の社風ですから・・・
営業と開発部門のコミュニケーション不足は
ストレート言うと仲が悪いってことです^^;
営業はもちろん受注し売上を上げたいので
「短納期、低原価で達成できますよ！」
とお客さんに言って、他社との競争を
優位に進めたいです。
一方でSEは充分な開発期間と豊富な原価で
安全に開発したい。
想像がつくかと思いますが、
営業とSEの重要視するところが
真逆なんですよね。
この問題は個人で解決するのが難しいです。
人間関係も社風もたくさんの人の価値観から
出来上がっています。
それを個人の力で変えるのはかなり難しい。
あまりにもひどい環境、ひどい会社の場合は
改善を目指すより、異動を希望したり、
場合によっては転職を検討した方がいいでしょう。
精神が病んでからでは遅いです。
自分の身を守ることが第一優先に考えましょう。
導入実績のある製品、技術を使う
実のところ、想定外のIT技術的な問題の発生で
プロジェクトが炎上するのは
かなりレアと言えます。
”炎上プロジェクトの特徴”の方で解説した通り、
このケースは基盤システムで発生することが
大半です。
さらに基盤分野の特徴として、
基盤分野は業務システムと違い
どこの会社に行っても似たような
システムになることが多いです。
※そのため基盤SEは転職しやすいと
言われています
なので、解決のためのノウハウが
社内やハードベンダーにあったり
Googleなど検索エンジンで調べれば
たいていは解決するんですよね。
なお、新製品を導入した場合などは
検索エンジンなどで調べても情報が少なく
解決が難しい場合があるので、
導入実績があるハードやパッケージを
導入するようにしましょう。
お客さんとシステム導入目的と達成条件を共有する
仕様変更、仕様追加が多発して
炎上を防ぐ方法はシンプルです。
- システム導入目的と達成条件をお客さんから聞き出す、
- お客さんにシステム導入目的と達成条件を決めてもらう
これしかないです。
ただ、お客さんがシステム導入目的と達成条件を
最初から決めているかは別の話です。
プロジェクトを受注後でも目的と達成基準が
固まっていないお客さんも多いです。
そういったお客さんの場合、
プロジェクト初期の段階でPM、PLを中心に
目的と達成基準を固めていく必要があります。
あなたがSEの場合、参画している
プロジェクトの目的と達成基準は
明確でしょうか。
明確でない場合、PMやPLに聞いてみて
ちゃんと決めれていない場合は
すぐにお客さんと確認するように
動くことをおすすめします。
システム導入の目的と達成基準を
決めるには論理思考が役立ちます。
以下の記事で詳しく解説しているので、
ぜひ読んでみてください！
まとめ
プロジェクトはなぜ炎上するのか、
炎上を回避するにはどうすればいいのかについて
解説しました。
炎上プロジェクト回避できるスキルを
現場で発揮できれば間違いないく”デキるSE”
として認められ、
周りからの評価が劇的に変わるでしょう。
炎上回避に役立つのはITスキルではなく、
ビジネススキルであることが大半です。
このブログではSEに役立つビジネススキルの
情報を発信していくので、
ぜひ他の記事も読んでみてくださいね！
それでは！
最後に（おまけ）
ボクは新人の頃、部署内でも有名なポンコツエンジニアでした^^;
プログラミングなど、ITに関するスキルが壊滅的だったのです。
ですが、今となっては社内で最短昇格を達成し、ボーナスも6回連続最高評価を達成しました。
こう言うと、なかなかの怪しさですよね（苦笑）
ということで、やまさんのエンジニア人生をプロフィールとしてまとめてみました。
ITスキル壊滅だったボクがどうやってエンジニアとしての活路を見つけたのか、気になる人は見てみてくださいね^^
プロフィールを読んでもらえれば察してもらえると思いますが、ボクはITスキル平凡な凡人SE。
めちゃくちゃプログラミングができるなど、特別なITスキルは持っていないです。
そのためか、昔は
- エンジニアになったはいいものの、IT技術に関して興味を持てない…
- 平凡なITスキルしかもってないのにエンジニアとしてやっていけるのだろうか…
- IT技術を身につけていくだけでエンジニアとして食べていけるのかな…
- 移り変わりの早いITの世界で永遠とIT技術の勉強を続けられる自信が…
このような悩みを抱えていました。
おかげさまで、プロフィールに書いたあるきっかけから↑のような悩みは解決してます。
ですが、実はバリバリのエンジニアの方でも「ITの勉強しない→エンジニア失格」という空気感にしんどさを感じてる人は多いみたいなんですよ…
というのも、「勉強しない→エンジニア失格」の空気感について、こちらの記事でまとめてみたところ、かなり人気なんですよね。
このブログの中でも人気の記事なので、気になった方は一度見てみてください^^
最後まで読んでいただきありがとうございました！！
いつになったら炎上が終わるんだろ・・・