【フリーランス・エンジニア向け】火のない所に煙は立たぬ!炎上する可能性が高い開発案件に巻き込まれないようにするために、注意すべき3つのポイント

【フリーランス・エンジニア向け】火のない所に煙は立たぬ!炎上する可能性が高い開発案件に巻き込まれないようにするために、注意すべき3つのポイント

エンジニアとして、いくつかの現場を経験すると必ず遭遇するのが、「炎上案件」だ。
いわゆる、納期やプロジェクトの開発スコープ(範囲)が収集つかなくなり、大量にエンジニアを投入しないと解決できない案件をさす。

今回は、フリーランスエンジニアや駆け出しエンジニアが、できるだけ炎上案件に巻き込まれないための3つの注意すべきポイントについて解説する。

事の発端

今回、なぜ炎上案件に関する記事を書こうかと思ったか?というと、以下のTwitterだった。

なぜ?数億円規模の案件を2人で回してんの?という疑問がわいたので、この記事を読んでいったら面白いほど典型的な「炎上案件」だった。

では、実際どのような案件が炎上するのだろうか?

炎上する案件の特徴

個人的な経験をもとにすると、以下のいずれかの様な案件の場合、大抵炎上することが多い。

  1. PM(プロジェクトマネージャ)が、要求定義や要件定義を十分にできていない
  2. PMが、現場で仕事する(例:プログラミング)前提になっている
  3. 顧客のステークホルダー(意思決定者)が複数いる
  4. プロジェクトに参画する開発メンバー役割分担(詳細はこちらを参照)が不明瞭
  5. プロジェクトの納期が短納期で、かつ受注金額が低い
  6. スケジュールや、マイルストーンの設定が適当すぎる
  7. 参画メンバーのスキルが不足している

実は、炎上しがちなのは、7ではなく1のケースだ。

受注金額が100万円超える規模になってくると、1人もしくは2人で開発するケースが増えてくる。

ましてや、受注金額が億を超える場合、最低でも、

  • PM(プロジェクトマネージャ):プロジェクト全体を管理。予算、納期調整、リスクマネジメント等を担当
  • PL(プロジェクトリーダー):プロジェクトの現場での旗振り役。主に進捗管理やタスク管理、現場における意思決定。
  • SE(システムエンジニア):現場の重要な戦力。設計や技術選定、プログラミング、ソースレビュー、テストを主導。
  • PG(プログラマ):SEと同じく現場の重要な戦力。主にプログラミングを担当。

といったメンバーが最低1人以上必要になってくる。納期によってはSEやPGは2人以上必要だ。

だが、メンバーの要素よりもっと重要なのは、要求定義と要件定義なのだ。

炎上する火種のほとんどはスコープクリープ

要求定義と要件定義、同じように見えて定義することが異なるので、いったん整理してみよう。

要求定義:顧客が求めているものを可視化して、言語化、体系化すること
要件定義:要求定義を元に、顧客が必要としている機能やパフォーマンス等を定義すること

要求定義や要件定義が満足にできていないと、初期フェーズで開発すべきタスクが大きく膨らんでしまい、スコープクリープ(要件が多すぎて、納期内でできる量を大幅に超えてしまうこと)を起こす可能性が高くなる。私自身も、PMやPLとして何度かスコープクリープを起こし、痛い目にあったことがある。

なぜなら、顧客は大規模案件になればなるほど、途中で仕様変更や修正を数多く要求してくるからだ。
(作る機能が多岐に渡れば、顧客から修正要望が多くなるのは自然なことである)

その際に、対応できることと対応できないことをふるい分けし、PMやPLは顧客に説明して納得してもらう必要がある。

では、どのようにふるい分けするのが良いのか?

スコープクリープを防ぐために工夫したこと

私自身、優秀なPMとは思っていないが、少なくとも中規模案件(受注金額が300万~)以上の場合、以下の点に気を付けるようにしている。

  • 顧客が要求する修正の緊急度は高いのか?
    例:)修正しないと顧客の業務が止まり、著しく機会損失を被る場合は優先度を上げて対応する。
  • 修正による影響範囲は軽微か?
    例:)画面のUIの微調整や、マスタのエラーチェック追加等、影響が軽微の修正は対応可能レベルを上げる。

逆に、これらに当てはまらない場合は、顧客に説明して次フェーズや保守フェーズで対応するように調整している。

炎上案件をどう回避するべきか?

PMが上記の様な努力を怠った場合、どうなるか?は、皆さん想像つくだろう。

炎上案件にフリーランスエンジニアが参画してしまうと最悪で、次の案件にアサイン出来なくなったり、体調を崩したりと著しい不利益を被ることになる。

では、どうすれば炎上案件を回避できるのだろうか?

それには、以下の3つの注意点に気を付けるとよいだろう。

  1. PMが、顧客との信頼関係を深く築けているか?
  2. PMが、要件定義の中身を詳細に理解しているか?
  3. プロジェクトの役割分担やステークホルダーが明確になっているか?

もし、上記3つのいずれかに不安を覚えた場合、できるだけその案件に参画しないほうが良いだろう。