目的
何故リリース延期となったか私視点のプロジェクト推進状況を記載したいと思います。
背景
情報系の大学を卒業後メーカー系のSIerに入社して現在5年目となります。
開発経験は1年目にスポットで開発の手伝い(テスト)を実施したのみで、2年目から小規模案件の保守運用のPLにアサインされ、1年半従事していたため、システム開発はほぼ未経験の状態でした。
要件定義は私が保守運用の対応している間実施していたため、基本設計からの参画となりました。
プロジェクトの概要
私が保守運用していたシステムの更改案件となり、既存システムではシステム化されていない業務領域も含めたシステム開発の依頼となります。
利用技術
- intramart Accel Platform (ローコード開発)
開発手法
- プロトタイプ開発
体制図
体制は以下のように、チームA以外のチームリーダー(以降TL)を派遣社員が担う形となりました。
私はチームBにアサインされて、要件定義から参画していた派遣社員の下で作業を行うこととなりました。
開発の方針
本開発はローコードツールを利用するということもあり、プロトタイプを作成して客先に提示しながら進めていくプロトタイプ開発が選ばれました。
進めていくにあたり、要件定義で作成した業務フロー図と既存システムや客先管理のエクセルから業務項目を抽出した項目定義書をブレイクダウンした資料を作成・提示することで要件の詳細を確認し、基本設計書の記載とプロトタイプの作成を実施する方針がPLから提示されました。
また、詳細設計は実施せず、プロトタイプで作成した実装をもとにローコードツールから設計書を出力することで設計書は記載しない方針となりました。
基本設計の開始
基本設計では主に以下資料を作成することが決まっていました。
- 画面定義書
- 画面アクション定義書
- 帳票定義書
- バッチ定義書
開発の方針で記載の通り、業務フロー図と項目定義書をもとに資料作成またはプロトタイプを提示することで作業を進めていく方針でしたが、問題が発生します。
項目定義書の破棄
チームBにはチームBのやり方があると発言し、チームBのTLが項目定義書は利用しないことを宣言しました。
この宣言に対し、私は開発方針に反する旨を伝えましたが、最終的にPMの判断で利用しないことが決定されました。
加えて、WBSにはプロトタイプを提示するスケジュールも記載がなかったため、結果的にウォータフォールでの開発と変わりなく作業が進んでいきました。
辛い部分はあなたがやればよいから
基本設計開始から1カ月経たずにプロトタイプ開発の体を成さなくなったプロジェクトですが、私以外の作業者(2名)はintramartを利用して、画面作成を継続します。
一方で、その他に画面アクションやバッチ処理を記載した設計書を書く必要があり、全25ファイルを私一人で対応するよう指示があった際に、チームBのTLから私に対して表題の言葉が発言されました。
また、私が社員ということもあり、客先へのメール送付や電話対応もほぼすべて私が対応することとなりました。
レビューという概念
設計書を作成した場合、チーム内でレビューをしてから客先に提示する必要があると思っていました。
本システム開発では以降設計書を提出するタイミングでレビューされることはありません。
要件の肥大化
チームBと相対する客先のリーダは要件定義に参画していない人でした。項目定義書を提示しなかったことで、業務項目の追加が高頻度で発生しましたが、見積もり条件を提示していないため、結果的に当初想定の1.5倍ほど画面項目が増えることになりました。
基本設計は終わらない
基本設計工程の期間が終了しましたが、客先と設計FIXとはなっていませんでした。
一方で、基本設計工程が終われば詳細設計工程が始まるため、PM、PLは詳細設計を開始するべく、次工程に進んでよいかの判定もないまま準備を進めていました。
これにより客先と自社の基本設計書に対するスタンスに認識齟齬が生じたため、製造、単体テストが始まっても追加要望を受け入れざるを得なくなりました。
詳細設計の開始
詳細設計書はローコードツールで作成したものを設計書出力機能を利用して生成する想定が提示されていたはずです。
しかし、チームBの各作業者は客先要件を理解することができなかったため、画面アクション定義にサーバ処理を記載する方針がチームBのTLから示され、PM、PLも了承しました。
与えられた期間は1週間で、フォーマットや記載粒度も示されない、全て抽象的な対応依頼が来たため、概要だけ記載しましたが、レビューされていない、業務理解もままならない作業者が対応することはできませんでした。
プロトタイプはいつ見せる？
思い出したかのようにPM、PLからプロトタイプをいつ客先に提示するか問い合わせがあり、製造・単体テスト工程の初週に対応することとなりました。
プロトタイプを提示するための端末や環境設定は当然すべて私が対応することとなり、前日動作していないアクションの修正も対応することとなりました。
また、客先提示後の打ち合わせでチームBのTLからプロトタイプ開発のプロトタイプはどこまで作ればよいかわからない、とPLの前で発言がありました。
TL交代の申し出
全体方針から逸脱、チームBの方針もあいまい、プロトタイプ開発はどこまで作成すればよいかわからないとの発言から、私にTLを交代するようPLへ直訴しましたが、PLからの回答はTLにはTLの考えがあると提案を一蹴されました。
製造・単体テスト工程と嘘
詳細設計工程のクローズという概念はありません。基本設計工程と同様に、詳細設計で引いてい期間が終われば、製造・単体テスト工程になりました。
製造・単体テスト工程では、基本設計・詳細設計で作成したプロトタイプをリファクタリングする形で製造を進めていく方針となり、あわせてコーティング規約が示されました。
一方で、チームBのTLはリファクタリングをせずにプロトタイプで作成したものを製造完了として、単体テストの実施を報告しました。
単体テストで5000件の障害が発生
製造が完了していない画面も製造完了でテスト実施したため、10000件の単体テストに対して5000件近くの障害が発生。これをPM、PLに報告せず単体テスト工程完了時にテスト完了と報告していたため、私から直に障害を裏で管理していることを報告。コーディング規約に則していないことも明るみに出たため、コーディング規約を作成した担当者にリファクタリングを依頼して、製造・単体テストをやり直すこととなりました。
このことから4カ月の遅れとなったが、PM、PLも客先にこの状況を報告しませんでした。
※因みにですが、入力チェックが実装されていない場合、「エラーが表示されないこと」というテストは実装されていないから当然OKとなっていたため、純粋に5000件はOKだったというわけではないです。
基本設計書の提出依頼と基本設計のFIX
製造・単体テスト工程の期間が終了となる最終週に客先から設計書提出依頼があり、急遽対応が発生しました。短期間での修正且つ、レビューがされないまま客先に提示することとなったため、客先レビューでの指摘が300件となり、先方から申し入れがされました。
申し入れ後体制増強すると回答しましたが、すぐに体制が強化されることもなく実態として客先に回答して2カ月は何も変わらないままでした。また、指摘取り込みの結果基本設計書のFIXは受け入れ試験開始直前となり、製造・単体テストに指摘内容が取り込まれないまま受け入れ試験を迎えることとなりました。
残3500件の単体テスト障害がある中受け入れ試験へ
コーディング規約に則していなかったため、製造を再度実施していたが、結合テスト未実施且つ単体テスト障害が3500件残ったまま受け入れ試験工程へ移りました。
受け入れ試験になるまで、客先報告はオンスケと報告しており、単体テストの品質評価も実施したと虚偽の報告をPMがしていました。
受け入れ試験に入るため、最後は私が修正、PMが一通りテストすることで品質を高めようとあがきましたが、客先のテストが開始したタイミングで単体レベルの障害がいくつも報告され、品質に関して先方から申し入れが行われました。
リリース延期とPLの交代
客先から品質の申し入れが行われ当初提示していた期間でのリリースが困難となったため、リリース延期を申し入れ。加えて、このタイミングでPLがダウンしたため、体制強化でPMOとして迎え入れていた作業者がPLにアサインされました。
執筆時点の状況
客先対応をPM、内部管理をPLとすることで体制を再構築。加えてチームBのTLに別の社員を割り当てることで、体制強化を実施して、障害の潰しこみ及び品質強化を図っている状況である。
残り3カ月で受け入れ試験可能な状況とする必要があり、一刻の余談も許さないが、すべてが終わった後にこの記事を見返しながら、客観的に分析をしたいと思う。