私の実体験をもとに炎上案件でどのような対応をしていたかをつらつらと書きます。
炎上しないための案件の進め方や、同じように炎上案件と戦っている方の立ち回りに役立てられればと思います。
また、現在も進行中の案件のため、必要に応じて情報をアップデートさせていただこうと思います。
案件概要
とあるシステムリプレースで、汎用機系から、LAMP構成（FW=Laravel）に変更する。
仕様は現行踏襲だが、連携方式の変更、画面をレスポンシブデザインに変更、業務上発生しない処理、機能は廃止する。
私の立ち位置
進行案件の途中（製造単体フェーズ）から参画（他7名のメンバーも参画）。
SE・PGとして3ヶ月、それ以降（9ヶ月）はPLの役割で立ち回っていました。
※親会社メンバー（PL）が多忙により、PL補佐に変更となり、途中から私がPLになりました。
プロジェクトメンバーは、以下の構成でした。
- 私の所属のメンバー：8名（PG：8名）
- 私の所属の親会社メンバー：7名（PG：5名、PL：1名、PM：1名）
- 外部ベンダー1社（親会社発注）
内製チームは、バッチ機能を中心で、画面機能を一部担当していました。
外部ベンダーは、画面機能のみを担当していました。
参画時の案件状況と対応
開発機能数、工数
状況
- 開発機能数の全体数が明確になっておらず移行対象機能が不明確
- 作業タスクのレベルが荒く、実作業が不明確
- 作業タスクの工数見積がされていない
対応
- システム全体の機能の洗い出し及び、PMへ移行対象機能の決定するように調整
- 開発以外の移行計画等の作業タスクを明確化
- 現行ソースのSTEP数からマイグレーション工数見積し、スケジュール提示およびリスケ調整
- リスケ期間圧縮のための人員調達の調整
- 現行踏襲でも仕様変更があれば設計フェーズを必ず設定
予防策
- 開発見積段階で、移行対象を明確にした上で開発工数を見積
- リプレースで発生しうるデータ移行計画タスクの明確化
- PJ管理では、タスクの単位を最小にし、期間、工数を管理
開発方針
状況
- クラス設計不足で、継承親クラス、子クラスの開発が進捗が停滞
- 当初から参画しているメンバーには、FWを熟知していない（＝テックリード可能な人材不在）
- 最新化されていない現行の詳細設計書ベースの開発（＝最新でないため、品質担保できない）
対応
- クラス設計を早期対応し、継承親クラス、子クラスの開発を推進
- 私がテックリードとして、メンバー教育を推進
- 現行ソースコードをトレースしてマイグレーション（現行ソースコードの読み方は私の方で教育）
予防策
- クラス設計は製造フェーズまでに完了
- FWを十分熟知したメンバーの参画もしくは、案件前教育でFWを十分理解
- ドキュメントは常に最新化
- リプレースにおいては現行ソースコードを解読して新システムの言語へのマイグレーションも検討
仕様変更
状況
- クラシカルなデザインからレスポンシブルデザインへの変更点が未確定
- データ連携をミドルウェアを使用せずにファイル転送に変更するが設計未着手
対応
- ポイントになる要素の新旧対比表作成（最終的にはエンドユーザー説明にも活用を目的）
- データ連携ミドルウェアの仕様調査および拡張性がある設計（DI等）、開発を推進
予防策
- 要件定義フェーズにて、新旧仕様対比表を作成
- 仕様変更部分の設計は、設計フェーズで完了
炎上案件でのメンタリティー
私自身、ここまで酷い案件は初めてでした。
それだけに、この状況を立て直したら、相応の評価がされて自身の昇格にも繋がると考えていました。
また、誰もがダメだろうと思われている中で、見返してやろうと強い気持ちも持つようにしていました。
さらに、炎上案件はなかなか体験できることではないため、私自身の成長にも繋がると考えて取り組んでいました。
炎上案件での成果
効率化意識向上
本案件以前から効率化意識を持って作業していましたが、
タスクの遂行順序、メンバーの作業割振など
いかに効率良く作業を進めるかより一層意識するようになりました。
メンバースキルの認知力
各メンバーのアウトプットに対するコスト、品質、必要に応じてコードチェックを行い、
開発スキルを理解することに努めることで認知力が高まった。
それによってメンバーの最適な作業割振にも活かすことができた。
案件推進力
立場上、多くのメンバーから質問、課題が来ることもありましたが、
スピード感を持って判断を下すことを意識して回答していました。
それにより開発の手を止めないということを意識して取り組みました。
時には、判断に悩むことがありましたが、悩みに悩むよりもまずは決断することを大事にしていました。
開発と結合が同時並行できるように、結合テスト実施順序を意識した開発順序を設定していました。
また、結合テストで外部ベンダー対応待ちになる場合は、データメンテで先の手順の確認を進められるよう調整。
リプレースにおいて、品質担保を確認するために効率的なのは、新システムと現行システムで同じデータを発生させ、処理ごとに更新テーブルの際を確認することと考え、実践しておりました。
それにより、テストでどの段階で問題があるか、またデータを見なければ気づけない問題にも気づくことができた。
反省点
本来、案件を進めるとともに、各メンバーの仕様理解、スキル向上も図って行きたかったが、
案件を進めることが最優先と考え、スキル向上を狙った作業の割り振りができなかった。
最後に
本投稿を読んでいただいた方々の少しでも助けになり、
炎上案件が少なくなっていけばと思います。