システム開発のプロジェクトが炎上する理由【犯人は?原因は?】

[ この記事を全て読んだ場合 ] 約 2 分間
○ 記事にPRが含まれることがあります。

システム開発を炎上させている犯人は?

 

先ず、言っておこうと思うのが、
これは、一例に過ぎないので、
プロジェクトが炎上する理由
は、他にいくつもあるとは、思います。

 

以後、お読み下さる方は、
そんな感じで、確かに、
そういうのもあるね。
と共感して頂ければ、幸いです。

 

プロジェクト経験の少ない
若いエンジニアの方は、
活用出来そうであれば、
参考までにして下さい。

 

未熟者が工数を決めるSIer

 

時々、聞く
「某プロジェクトは、何十万人月」
あれ、どうやって、
出しているんですかね、汗?

 

何か、もう、全く根拠のない
数字にしか見えないです。

 

正直、ここ10年くらいの
プロジェクトって、
どれも規模が大きすぎるものは、
本当に工数を見積もりにくいと
実感しています。

 

その中で、請負元が、
結構ザックリと工数を
決めてしまうというのが殆どです。

 

尚且つ、本当に多いのが、
開発経験のないプロパーが、
よくわからないまま工数を決める点。

 

この「嘘でしょ?」
って事が本当に多いです……

 

何故、そういうことが多いのか、
それは、日本のIT請負の
構造にも関係します。

 

お客さんからシステムの
依頼がある場合、
お客さんは、基本的に
大手IT企業にシステムを頼みます。

 

しかし、大手だけの社員では、
開発が無理な規模のため、
下の子会社や孫会社、
その会社に紐づく、協力会社に
開発をお願いしていきます。

 

そのため、請負元の大手は、
スケジュール管理を
することばかりになってしまい、
実際のプログラミングでの
開発に携わることが少ないです。

 

いわゆる「外注管理」というものです。

 

それは、大手に入社すれば
新卒から始めるものなので、
毎日毎日、スケジュール管理、
それ関係の資料作成で終わります。

 

そのため、大手のエンジニアは、
設計書をつくることも少なければ、
開発もしない、テストもしないので、
エンジニアとしてのスキルが磨かれません……

 

勿論、教育が、
しっかりした大手であれば、
そんなこともないでしょう。

 

しかし、自分が現場として入った、
大手のH社、I社、N社等は、
少なくとも、そうではありませんでした。

 

そんなエンジニアとして、
腕を磨くことの出来ない環境で
育ってしまった人材が、
会社に長くいるだけで、
そこそこ昇進してしまう。

 

そして、今度は、上の立場に成って、
自らがやったこともない
開発工数を組むのです。

 

本当に、恐ろしいことですよね。
これが、プロジェクトが炎上する訳の
一つでもあります。

 

ただでさえ、難しくなってきている
大規模システムの工数。
それを、何の根拠も経験もない人間が決める。
下に何百人ものエンジニアがいるのに……

 

この構造を変えていくのは、
本当に難しいことでしょう。

 

上に意見を言えるだけのスキルを磨こう

 

では、上で述べたように、
業界全体の構造を
直していくのは、時間が掛かる。

 

そこで、もうひとつ、
よくあるパターンが以下のようなことです。

 

これも、自分が多くの
プロジェクトに携わって、
非常に多かったパターンなので
書いてみました。

 
プロパーが要件定義の期間を決めない。守らない。
 

これは、どういうことかと言うと、
基本的に、ざっくり
カットオーバー(納期)が決まると、
そこに合わせて、

要件定義
設計
開発
テスト

といったように、
各フェーズの期間も決めていきます。

 

この「要件定義」という、
お客さんの要望を
聞いてまとめるフェーズ。

 

勿論、ここの要望がまとまらなければ、
どのようなものをつくるのか、
どういった業務をシステム化するのか等、
決まらないので、設計も開発も出来ません。

 

SIerでは、やはり、
開発手法で「ウォーターフォールモデル」
を使う現場が多いので、
この「要件定義」が始めに来て、
ここでスケジュールが押してしまうことが、
よくあります。

 

それは、プロパーが期間内で上手に、
お客さんからの要望をまとめることが
出来ないところもありますが、
それプラス、最もタチが悪いのは、

 

要望を聞く期限を決めない。
要件定義フェーズ後も
お客さんからの要望を聞き続ける

 

というところです。

 

請負元のプロパーとしては、
やはり、お客さんに気に入られたいというのもあり、
また、開発経験も少ないので、
勝手に、このくらいの変更なら、
すぐに出来るだろうと判断して、
要件定義フェーズ後も、
お客さんからの要望を
納期を後ろに下げずに入れてきます。

 

もう、この段階で、
かなりヤバイ現場です。

 

何故ならば、上っ面では
簡単に変更出来そうなイメージでも、
バリバリ開発をやってきた
エンジニアから言わせると、

カレーのルーを入れてかき混ぜた時点で、
シチューにつくり変えろ。

レベルのことも多々あるからです。

 

こうなると、確実に予定は崩れます。

 

プロパー側も自分の非を認めて、
人月費を上げるから、
残業、休日出勤で、
何とか対応してくれと
泣きついてくることもありますが、
物理的に無理な場合は、
それでも無理です。

 

こうなると、協力会社のエンジニアも
巻き添えをくらい、
雰囲気の悪い現場だと、
多くのエンジニアがノイローゼになり、
少しずつ来なくなります。

 

自分も、そういう現場に
何回もいたことはあります……

 

次の日から急にプ
ロジェクトリーダーが来なくなるとか(笑)
昨日まで、あんなに声を張り上げて
頑張っていたのに。
いや、それが、最後の灯火だったのでしょう。

 

なので、
お客さんに気に入られたいからと、
取って来た要望を、
すぐに受け入れない、
きちんと意見を言うことが
大事になってきます。

 

でもこれは、若い方は難しいでしょう。
恐らく出来るのは、
この現場をクビになっても、
次に移って食べていけるからいいや
といったエンジニアだとやりやすいです。

 

自分も前の会社の出されていた現場では、
バリバリ言いまくっていましたが、
若い時は出来ませんでした。

 

周りに、そこまで
ハッキリ言う人もいなく、
逆に気に入られて、
どんどん言って下さいと
頼まれるくらいでしたが、汗

 

それは、それで、
ヤバイ流れだと思います。
請負元がしっかりしていればいいだけなので。

 

なので、はじめから、
そんなにガンガン意見を
言いなさいというわけでもないです。

 

何が、プロジェクトを
炎上させている原因になっているのか
見極める能力を養って、
それがわかるようになってきたら、
先ずは、上司を通してみたりとか、
ふっきれたなら、プロジェクトマネージャーに
直接、言ってみるとか……

 

頼まれたことをただやるSE(エンジニア)になる
というわけではなく、
プロジェクトを見渡して、
意見を言いながら
プロジェクトを進行出来る
SEになった方が良いと思います。

 

そういうSEは、
現場でコアメンバーになりますが、
あまりに真面目にやり過ぎると、
ノイローゼになり、
ぶっ壊れてしまう危険も多いです。

 

頑張り過ぎず、しっかりと!
それが、大事だと思います。

 





コメントを残す