ITエンジニアの方は炎上プロジェクトに参画した経験がある方は多いと思います。

さて、そのプロジェクトの何が悪かったのでしょうか？

 

・顧客からの要件変更による手戻り

・設計書の不備・矛盾

・未確定仕様の噴出

・製造品質が低いことによる試験工数の増加(自モジュール、他モジュール)

・技術不足

etc・・・

 

上記以外にも様々な問題があると思いますし、

炎上する場合は単一の要因ではなく、複数の要因が重なって炎上する場合が多いと思います。

 

さて、炎上案件に関わらない・炎上させない事が一番ですが、

残念ながら炎上に巻き込まれる事は少なからずあります。

その時に取れる行動はどんなものがあるでしょうか？

 

あなたがどのポジションに居るかによって取れるアクションは変わると思いますが、

どのポジションでもまずは以下ははっきりさせましょう。

 

◆◆自分の作業責任範囲◆◆

 

契約時、作業開始時に決定した作業範囲を逸脱して作業を積まれていませんか？

まずは自衛のために作業範囲・責任分界点を明確にしましょう。

 

炎上原因が自分や自チーム以外に転嫁出来る部分があれば、交渉の場を設ける事が可能になります。

これで責任感や、高稼働で潰れる事を回避出来る可能性が上がります。

 

上記で上げた原因も確認していくと自責以外がありますので、

キチンと整理して調整を行って正常化のための行動をとりましょう！

————————————————————————–

・顧客からの要件変更による手戻り

→確実に顧客責任のため、追加期間・工数を請求しましょう。

 

・設計書の不備・矛盾

→自身が設計から携わっていたとしても、顧客と設計レビューはしているはずです。

設計漏れや矛盾が検出できなかった要因含めて顧客と再設計の相談をしましょう。

 

・未確定仕様の噴出

→設計やそれ以前の要件定義から観点が漏れている可能性や、

考慮自体をしていない場合があります。

最悪の場合はその機能の開発をあきらめて、

次期開発・別線開発に出来るか相談しましょう。

 

・製造品質が低いことによる試験工数の増加(自モジュール責、他モジュール責)

→不具合傾向から不具合モジュールの設計漏れ等が無いか確認して見てください。

漏れている設計があった個所を対処するための作業量を出して、

正直に相談しましょう。

試験工程まで行っている場合のリカバリは難しいですが、

気付いた時点で相談しましょう。

 

・技術不足

→有識者に参画してもらえる様に調整をかけましょう。

新人・技術スキルアンマッチのメンバーを追加で幾ら入れても

プロジェクトは正常化しません。

その人に技術が付く前にプロジェクトは何らかの形で終ります。

 

————————————————————————–

個人事業主のIT技術者は技術力があるため、

頑張ってしまえば人一倍作業が出来てしまう事が多いと思います。

 

しかし、炎上プロジェクトで頑張りすぎるのは間違っていると思います。

それでは自身が疲弊する事に繋がりますし、周りも併せて高稼働になって潰れていくでしょう。

 

是非責任を確認しあって顧客側にも責任を負ってもらい、

双方で譲り合って正常化をのためのアクションを取って下さい。