お久しぶりです。ツナかふぇ こと 武田です。
前回に書いたように、前回参画したウォータフォール開発案件の炎上原因の詳細を書いていきます。
要件定義、まさしく読んで字の如く、お客さんがシステムに期待する挙動を固めるフェーズです。
当然、打合せが続く内に、当初想定しなかった機能を求められる事もあります。
新しい機能が増えればシステムの価格も上がります。会社の利益が増えるのは喜ばしい事です
が、何故か工数も人も増えませんでした。
納期はがっちり固定されており、ガントチャートが組み変わる形跡は欠片もありませんでした。
要件定義の後の再見積もりは必須フェーズです。それが無いなど、お客さんが纏めてきた要件を精査していないも同然です。
再見積もりが無いプロジェクトは必ず燃えます。
そんな事ある？ と疑いたくなりますが、実際に起きました。
業務仕様の矛盾を指摘しても、遅延を報告しても、メンバーがバックレても動かない。
挙げ句の果てには卓上のスマホで業務中に遊んでいる、というとんでもないPMと出くわしたのがこの案件でした。
何の為にそこに存在しているのか、本当に不明でした。
社内政治でわざと炎上させる為に置いてあったとしか思えません。メンバーはただただ被害を被るばかりです。
実装手法や仕様の抜け漏れチェックを行うフェーズであり、工数に余裕が無いとき、最もお座なりになる工程です。
指摘点に『実装手法』『仕様』がないレビューは無意味です。本フェーズは間違ってもコメントやインデントを指摘するフェーズではありません。
形骸化したフェーズほど不毛なモノはありません。そんな暇があるのなら一行でもコードを書いた方が良いです。
納期が足りなくなると相談する時間が無くなり、『とにかく間に合わせないと！』という雰囲気から開発手法が個人任せになりがちです。
メンバーの技術力は均一ではありません。かならず担当者によってコーディングにはムラがあります。
そのムラを取り除為の継承クラス・インタフェースといった『実装を縛る』機能です。
どの言語にも開発効率や保守性を上げる技術があるのに、納期の観点からそれらを使用しないのは、後々現場も経営の観点からも首が締まります。
Utilクラスの存在も周知されず、『この処理ここでも書いたな…』という事も起こりがちです。
保守性の無いコードが技術負債として残るのを避ける為にも、メンバー無いで技術的な情報は共有を図らなければなりません。
テストケースが足りない原因は主に2つあります。
・試験仕様書作成者が業務フローを取りこぼす
・要件定義時の業務フローの記述が曖昧
原因が後者の場合、そもそも要件定義フェーズが終わっていなかった、という事です。
前述した『再見積もりフェーズ』を実施しなかった際の負債はこのフェーズでのしかかってきます。
正直、この段階でそれらが顕著である場合、1メンバーとしてはプロジェクトを脱退する方向で調整します。無理な計画に付き合う義理はありません。
前者はヒューマンエラーにより発生するものです。試験仕様書は運用フローを元に作成するモノなので、それを元に仕様書のダブルチェックは必ず行いましょう。
単体テストはともかく、基本的に結合レベルの試験は仕様書にもレビューが存在しなければなりません。
どうしてもシステム的に必要だが、実装手法をどうするか、という問題は、開発には少なからず付きまとう問題です。
必然的にその手法に関する『調査』の工数が必要になるのですが、それを考慮しない線を引くPMは割と見かける印象です。
ガントチャートはどうしてもPMの恣意が入るモノなので、公開された予定はメンバー全員で確認を取りましょう。
公開直後の指摘を逃したら、基本的に後戻りはできません。
外部公開されてる情報と、実際の挙動が異なる、だと…？
実装・テストフェーズに大きな遅延をもたらす上、公開先の担当者とのコミュニケーションコストまでかかる、という最悪な炎上原因です。
にも関わらず、相手は仕様書を欠片も直す気配は無く、遂に最後まで仕様書と実際の挙動の齟齬は解消されませんでした。
おまけに、周囲の意見を聞いてみると、この事象は他の現場でも珍しくないというのです。
はっきり言いますが、こんな状態で金を取るのは詐欺です。
よくもまぁこの不完全なAPIを世の中に出したものだと、怒りを通り越して感心してしまいます。
ナメた態度の担当者には、頭越しに上層部同士で会話をしてもらうのが効果的です。実際、これで向こうの担当者が一度変わりました。（結局仕様書は直りませんでしたが…）
もう二度と○○○の外部APIは使いません。
と、今回の経験をつらつらと書き連ねていきましたが、これはウォーターフォールに限った話ではなく、アジャイル開発やスクラム開発でも十分に起きうる話です。
ただ、『納期から逆算してフェーズ毎の期間を固定してしまう』ウォーターフォール開発モデルでは発生しやすい事象だと思っています。
というより、最初の計画通りにウォーターフォール開発モデルでの開発工程が正常に終了したケースを私は知りません。
私自身、今回の例を振り返っても、皮算用で全ての工数を見通すなど、到底無理な話なのではないかと思っています。
友人のエンジニアが零した『ウォーターフォールは人類には早すぎる』というのは、非常に的を得た言葉だったように思います。
入会申込
ログイン
