こんにちは、やまさんです!!
![](https://yama0120.com/wp-content/uploads/2020/09/necchusyou_face_boy5-min.jpg)
連日続く徹夜。
倒れていく周りのSE。
プロジェクトが炎上すると本当に悲惨です・・・
やまさんも炎上プロジェクトに
参加していたことがあります^^;
なぜプロジェクトは炎上してしまうのでしょうか。
この記事ではプロジェクト炎上の理由と
回避策ついて話をしていきたいと思います。
Contents
炎上プロジェクトの主な特徴
![スーツを着た男性がクエスチョンマークを指さしている](https://yama0120.com/wp-content/uploads/2020/09/turn-on-2925962_1920-1-min-2.jpg)
プロジェクトが炎上する主な理由は4つです。
- 極端な短納期
- 工数、予算の圧倒的不足
- 想定外のIT技術的な問題の発生
- 仕様変更、仕様追加が多発
それぞれ詳しく見ていきましょう!!
極端な短納期
プロジェクト開始前には営業さんが
お客さんから案件を取ってきます。
このとき、ムリに案件を取ろうとして
極端な短納期を約束してしまう
ケースがあります。
お客さんはたいてい複数の会社から
見積りを取っているんですよね。
コンペってやつです。
このとき、営業さんが案件を取りたいあまりに
SE側の意見を聞かずに短納期を
約束してしまうことがあるんです。
結果、SEは反対したけど、営業さんが
受注してしまってやるしかない状況に・・・
なんてことがあったりします。
このケースの根本原因は人間関係や
会社組織の文化です。
スキルや技術とは違うところの話なので
根が深いのです・・・
工数、予算の圧倒的不足
![イスに座って悩むビジネスマン](https://yama0120.com/wp-content/uploads/2020/09/838993_m_-min.jpg)
これも”極端な短納期”と同じで
営業さんとSE側の意見を聞かず、
営業さんがムリに案件を
取ってきたケースで多いです。
根本的には社内での営業と開発部門の力関係や
その会社の社風などが原因です。
なお、SE側の見積り誤りが
原因のこともあるんですが、
多くの開発は過去に似たようなプロジェクトが
存在します。
過去に行った類似プロジェクトを参考にすれば、
SE側が見積りを大きく外すようなケースは
かなり少ないです。
なので、こちらも根本原因は
人間関係や会社組織の文化にあります。
想定外のIT技術的な問題の発生
プロジェクト進行中に技術的な問題が
発生してしまったパターンです。
この場合、解決のための作業量が大きくなり
炎上してしまいす。
このケースは業務システムよりは
基盤システム側で発生することが多く、
例外的なことをやろうとした場合に
よく発生します。
仕様変更、仕様追加が多発
![ゴミ箱からはみ出る丸めた紙ごみ](https://yama0120.com/wp-content/uploads/2020/09/dastbox_3876512_l-1-min-1.jpg)
プロジェクト後半で仕様変更や仕様変更が多発。
それでも納期はズラせなくて
炎上するパターンです。
炎上プロジェクトはこの仕様変更、
仕様追加多発によるケースが大半を占めます。
仕様変更や仕様追加が多発する理由は
いろいろあるんですが、
たいていはプロジェクトマネージャー(PM)
プロジェクトリーダ(PL)の力不足です・・・
プロジェクト前半の要件定義工程段階で
システム導入の目的と達成条件を
お客さんから聞き出せていないのです。
たいていの会社ではPM、PLはSEとして
結果を出した人が昇進という形でなります。
ただ、SEで優秀だったとしても
PM、PLになって優秀であるかはまた別です。
SEで求められる能力とPM、PLで
求められる能力が違うんですよね。
SEはITスキルのレベルが高ければ、
大抵の場合、仕事がデキると言われます。
一方で、PM、PLはSEよりも
高いビジネススキルが必要とされます。
ビジネススキルが低く、プロジェクト前半で
システム導入の目的と達成条件をお客さんと
共有できていない場合、そのプロジェクトは
開発後半で炎上してしまいます。
炎上プロジェクトの回避策
![炎を消すために放水する消防士2人](https://yama0120.com/wp-content/uploads/2020/09/firefighters-115800_1920-1-min.jpg)
人間関係が原因のことも・・・ ひどい場合は転職も検討
極端な短納期や工数、予算の圧倒的不足で
プロジェクトが炎上している場合の
解決策ですが、個人で解決するのは
難しいケースが多いです。
根本原因は営業と開発部門の
コミュニケーション不足や
会社の社風ですから・・・
営業と開発部門のコミュニケーション不足は
ストレート言うと仲が悪いってことです^^;
営業はもちろん受注し売上を上げたいので
「短納期、低原価で達成できますよ!」
とお客さんに言って、他社との競争を
優位に進めたいです。
一方でSEは充分な開発期間と豊富な原価で
安全に開発したい。
想像がつくかと思いますが、
営業とSEの重要視するところが
真逆なんですよね。
この問題は個人で解決するのが難しいです。
人間関係も社風もたくさんの人の価値観から
出来上がっています。
それを個人の力で変えるのはかなり難しい。
あまりにもひどい環境、ひどい会社の場合は
改善を目指すより、異動を希望したり、
場合によっては転職を検討した方がいいでしょう。
精神が病んでからでは遅いです。
自分の身を守ることが第一優先に考えましょう。
導入実績のある製品、技術を使う
![タブレットのグラフを見ながらペンで確認して分析する姿](https://yama0120.com/wp-content/uploads/2020/09/digital-marketing-1725340_1920-1-min.jpg)
実のところ、想定外のIT技術的な問題の発生で
プロジェクトが炎上するのは
かなりレアと言えます。
”炎上プロジェクトの特徴”の方で解説した通り、
このケースは基盤システムで発生することが
大半です。
さらに基盤分野の特徴として、
基盤分野は業務システムと違い
どこの会社に行っても似たような
システムになることが多いです。
※そのため基盤SEは転職しやすいと
言われています
なので、解決のためのノウハウが
社内やハードベンダーにあったり
Googleなど検索エンジンで調べれば
たいていは解決するんですよね。
なお、新製品を導入した場合などは
検索エンジンなどで調べても情報が少なく
解決が難しい場合があるので、
導入実績があるハードやパッケージを
導入するようにしましょう。
お客さんとシステム導入目的と達成条件を共有する
仕様変更、仕様追加が多発して
炎上を防ぐ方法はシンプルです。
- システム導入目的と達成条件をお客さんから聞き出す、
- お客さんにシステム導入目的と達成条件を決めてもらう
これしかないです。
ただ、お客さんがシステム導入目的と達成条件を
最初から決めているかは別の話です。
プロジェクトを受注後でも目的と達成基準が
固まっていないお客さんも多いです。
そういったお客さんの場合、
プロジェクト初期の段階でPM、PLを中心に
目的と達成基準を固めていく必要があります。
あなたがSEの場合、参画している
プロジェクトの目的と達成基準は
明確でしょうか。
明確でない場合、PMやPLに聞いてみて
ちゃんと決めれていない場合は
すぐにお客さんと確認するように
動くことをおすすめします。
システム導入の目的と達成基準を
決めるには論理思考が役立ちます。
以下の記事で詳しく解説しているので、
ぜひ読んでみてください!
まとめ
![PCゲームに勝利して大喜びする男の子と女の子](https://yama0120.com/wp-content/uploads/2020/09/children-593313_1920-1-min.jpg)
プロジェクトはなぜ炎上するのか、
炎上を回避するにはどうすればいいのかについて
解説しました。
炎上プロジェクト回避できるスキルを
現場で発揮できれば間違いないく”デキるSE”
として認められ、
周りからの評価が劇的に変わるでしょう。
炎上回避に役立つのはITスキルではなく、
ビジネススキルであることが大半です。
このブログではSEに役立つビジネススキルの
情報を発信していくので、
ぜひ他の記事も読んでみてくださいね!
それでは!
いつになったら炎上が終わるんだろ・・・