一般社団法人 全国個人事業主支援協会

COLUMN コラム

お久しぶりです。ツナかふぇ こと 武田です。

前回に書いたように、前回参画したウォータフォール開発案件の炎上原因の詳細を書いていきます。


  • 要件定義フェーズ~基本設計フェーズ間に再見積もりの工程が存在しない

要件定義、まさしく読んで字の如く、お客さんがシステムに期待する挙動を固めるフェーズです。

当然、打合せが続く内に、当初想定しなかった機能を求められる事もあります。

新しい機能が増えればシステムの価格も上がります。会社の利益が増えるのは喜ばしい事です

が、何故か工数も人も増えませんでした。
納期はがっちり固定されており、ガントチャートが組み変わる形跡は欠片もありませんでした。

要件定義の後の再見積もりは必須フェーズです。それが無いなど、お客さんが纏めてきた要件を精査していないも同然です。

再見積もりが無いプロジェクトは必ず燃えます。


  • PMがマネジメントを放棄している

そんな事ある? と疑いたくなりますが、実際に起きました。

業務仕様の矛盾を指摘しても、遅延を報告しても、メンバーがバックレても動かない。

挙げ句の果てには卓上のスマホで業務中に遊んでいる、というとんでもないPMと出くわしたのがこの案件でした。

何の為にそこに存在しているのか、本当に不明でした。

社内政治でわざと炎上させる為に置いてあったとしか思えません。メンバーはただただ被害を被るばかりです。


  • レビュー工程が機能していない

実装手法や仕様の抜け漏れチェックを行うフェーズであり、工数に余裕が無いとき、最もお座なりになる工程です。

指摘点に『実装手法』『仕様』がないレビューは無意味です。本フェーズは間違ってもコメントやインデントを指摘するフェーズではありません。

形骸化したフェーズほど不毛なモノはありません。そんな暇があるのなら一行でもコードを書いた方が良いです。


  • メンバーの開発手法が個人に依存している

納期が足りなくなると相談する時間が無くなり、『とにかく間に合わせないと!』という雰囲気から開発手法が個人任せになりがちです。

メンバーの技術力は均一ではありません。かならず担当者によってコーディングにはムラがあります。
そのムラを取り除為の継承クラス・インタフェースといった『実装を縛る』機能です。

どの言語にも開発効率や保守性を上げる技術があるのに、納期の観点からそれらを使用しないのは、後々現場も経営の観点からも首が締まります。

Utilクラスの存在も周知されず、『この処理ここでも書いたな…』という事も起こりがちです。

保守性の無いコードが技術負債として残るのを避ける為にも、メンバー無いで技術的な情報は共有を図らなければなりません。


  • 結合試験~総合試験の発生しうる業務フローのテストケースが足りていない

テストケースが足りない原因は主に2つあります。

・試験仕様書作成者が業務フローを取りこぼす
・要件定義時の業務フローの記述が曖昧

原因が後者の場合、そもそも要件定義フェーズが終わっていなかった、という事です。
前述した『再見積もりフェーズ』を実施しなかった際の負債はこのフェーズでのしかかってきます。

正直、この段階でそれらが顕著である場合、1メンバーとしてはプロジェクトを脱退する方向で調整します。無理な計画に付き合う義理はありません。

前者はヒューマンエラーにより発生するものです。試験仕様書は運用フローを元に作成するモノなので、それを元に仕様書のダブルチェックは必ず行いましょう。
単体テストはともかく、基本的に結合レベルの試験は仕様書にもレビューが存在しなければなりません。


  • ガントチャート上に調査工数が含まれていない

どうしてもシステム的に必要だが、実装手法をどうするか、という問題は、開発には少なからず付きまとう問題です。

必然的にその手法に関する『調査』の工数が必要になるのですが、それを考慮しない線を引くPMは割と見かける印象です。

ガントチャートはどうしてもPMの恣意が入るモノなので、公開された予定はメンバー全員で確認を取りましょう。

公開直後の指摘を逃したら、基本的に後戻りはできません。


  • 外部連携先のシステムのインタフェース情報に誤りがある

外部公開されてる情報と、実際の挙動が異なる、だと…?

実装・テストフェーズに大きな遅延をもたらす上、公開先の担当者とのコミュニケーションコストまでかかる、という最悪な炎上原因です。

にも関わらず、相手は仕様書を欠片も直す気配は無く、遂に最後まで仕様書と実際の挙動の齟齬は解消されませんでした。

おまけに、周囲の意見を聞いてみると、この事象は他の現場でも珍しくないというのです。

はっきり言いますが、こんな状態で金を取るのは詐欺です。
よくもまぁこの不完全なAPIを世の中に出したものだと、怒りを通り越して感心してしまいます。

ナメた態度の担当者には、頭越しに上層部同士で会話をしてもらうのが効果的です。実際、これで向こうの担当者が一度変わりました。(結局仕様書は直りませんでしたが…)

もう二度と○○○の外部APIは使いません。


  • 総括

と、今回の経験をつらつらと書き連ねていきましたが、これはウォーターフォールに限った話ではなく、アジャイル開発やスクラム開発でも十分に起きうる話です。

ただ、『納期から逆算してフェーズ毎の期間を固定してしまう』ウォーターフォール開発モデルでは発生しやすい事象だと思っています。

というより、最初の計画通りにウォーターフォール開発モデルでの開発工程が正常に終了したケースを私は知りません。
私自身、今回の例を振り返っても、皮算用で全ての工数を見通すなど、到底無理な話なのではないかと思っています。

友人のエンジニアが零した『ウォーターフォールは人類には早すぎる』というのは、非常に的を得た言葉だったように思います。

The following two tabs change content below.
関東圏の29歳ITエンジニア。自社開発、受託開発、SESを経て、業界経験6年半でフリーランスに転身。 設計…ER/ロバストネス/クラス図/シーケンス図 実装…java8~/spring/mybatis/SQL/html/css/jQuery/thymeleaf/bootStrap

この記事をシェアする

  • Twitterでシェア
  • Facebookでシェア
  • LINEでシェア