はじめに

この記事を見ていただいてる方々は、普段IT業界で何らかの形で携わっている方が多いと思います。その中でよく耳にする言葉に"炎上"や"デスマーチ"がありますが、そのような状況下で品質保証(以下QA)として、当時の"炎上中"の問題点を振り返り、自分なりにどのような立ち回りができればよかったかを記載して、皆様の今後の品質保証活動の何らかのアクセントになっていただければ幸いです。
※業界や会社は特定されないように記載しますので、情報不足な点がありましたら申し訳ございません。

ここで用いてる"炎上"とは、よく使われる意味合いとしてはプロジェクトの運用開始間際までの期間が逼迫した状態で、予算も人手も足りずに休日出勤の連続や徹夜に近しい状況が続く意味合いで使われることが多いと思います。

ただ本記事では運用開始間際の状態だけでなく、運用開始以降も炎上状態が続いたため、その不具合対策を含めた全期間を対象とした意味合いで使用しています。
※対外的には収束の宣言をするまで約１年、自社内でも収束したという判断をされるまでに２年間以上の時間を要しました。

簡単な経歴

私は2010年頃より新卒で入社して以降、SESのQAとして金融系、公共系を担当。また、転職を機に自社開発のWebやAPP系と様々なソフトウェア開発の品質保証としてプロジェクトに携わせていただきました。その中でも一番どうにもできなかったプロジェクト経験をこの場をお借りして記載されていただければと思います。

教訓

長い記事になりますので、この経験において自分の中で得た教訓を最初に記載します。
タイトルの品質保証のあり方は、以下のことを守るための役回りができることが非常に大切だと感じました。

テスト完了していますか (全量できていますか)
スケジュール管理はちゃんとされていますか
　※担当者へのアサイン、フォローアップ体制含む
プロジェクト内で意思疎通は取れていますか
　※一部の人だけが知ってることで話が進んでいませんか
開発プロセスは周知徹底されていますか
様々な約束事はちゃんと守られていますか
チェックポイント/フェーズゲートが機能していますか
※願望込みの報告があったりしませんか
属人性が高い状況に陥っていませんか

本当に1つ1つはプロジェクトを進めていく上で、基本的なことだと思います。
ただ大規模になるほど綻びが解けたときの影響は大きく、修正も難しくなることを知りました。そのため早め早めのキャッチアップを心掛けて対応していくことの大切さを改めて認識した経験となりました。

プロジェクトの規模感

前置きが長くなり、申し訳ありません。自分がどのようなプロジェクトに配属されていたかをご紹介させていただきます。

開発期間：約２年
開発人数：自社開発担当の3サブシステムで最大で120名在籍
　　　　※自社が30～50名+BPでの構成
　　　　※他サブシステムは他社様も参画されていました
参画時期：結合テスト開始時点
　　　　※運用開始日の4カ月前

期待されていた役割

自分に期待されていた当初の役割としては、テスト実行よりも自社開発部分における設計書やテストケースのレビュー、不具合の定量評価を期待されていました。
※品質保証としての参画は1名のみであったため、その中で少しでも新規不良の作りこみを防ぐ施策を実施することが目的でした。
※参画当初よりテスト工程での設計不良が多かったため、設計品質が低くその改善も期待されていました。

ただ早々に開発タスクの積み上がり具合から、業務が回らない状況に陥り、1人でも増やすためにとのことで、支援に回るようになり、立ち位置としてはPMOのような役割になっていました。詳細については後述します。

炎上中の状況

詳細に流れを記載するとキリがないため、どのようなトラブルが発生していたかをざっくりと記載します。

運用開始前

結合テスト開始頃にプロジェクトに参画しましたが、様々な要因により以下のようなトラブルが日々発生していました。
　・テストが進まない(特に仕様未確定箇所に加え、画面周り、データ移行)
　・不具合件数が減らない(前工程で発生した不具合を修正できないまま次工程へ)
　・スケジュールが不透明(不具合の対応優先順位も特にない)
　・有識者の不足　(仕様に詳しい人が極一部しかいない)

特に開発遅延によりテストが進まず、不具合件数が減らないことが致命的な問題となっており、運用開始直前までテスト工程の不具合が収束傾向が見えないままでした。
※テスト消化曲線を描くと、以下の典型的な深刻型に該当する状態でした。

制限事項とした内容はありますが、何とか残不具合件数は0件として運用開始を迎えました。

参考：https://monoist.itmedia.co.jp/mn/articles/1002/18/news101.html

参画人数はこの頃は自社の領域では50～60名ほどでした。

運用開始以降　

何とか運用開始を迎えましたが当初よりデータ移行関連でのトラブルが多発し、合わせてプログラムの品質、プロジェクトの問題も浮かび上がってきました。
大きくは以下の通りになります。

　・不具合、想定外データから生成された膨大な数の異常データの修正作業
　・止まらないユーザからのインシデント報告
　・守られない(守れない)スケジュールによりお客様への不信感
　・修正時の影響範囲の考慮漏れによる新たな修正作業の発生
　・有識者(※)の不足　※原因の追究や、修正方針の正しさを判断できる人
　・指示系統の混乱

特に1か月過ぎるまで常に尋常じゃないほどの発生しており、対応するために人員追加も座席数の限界を超えるまで行い、自社の領域だけでもピーク時で120名(※)ほどになりました。

それでも発生件数＞解決件数は下回らず、収束傾向が見えない状況が続きました。

そして新たな問題が発生したこともあり、人員追加は対策としての特攻薬にはなりませんでした。

　・追加要員のスキルのアンマッチ
　・仕様理解に時間を要する
　・リーダの業務過多の影響で、追加人員のコントロールができていない
　※実際に過労でドクターストップかかった方が数名いらっしゃいました。
　・当事者意識・責任感の違い
　・人員を管理する人の不足　(事務業務)

収束までの道のり

運用開始から3か月過ぎるまでは、目の前のインシデント対応に追われていて、プロジェクト内を改善させるような取り組みが全然できない状況でした。誰しもが漠然とした"やばい","終わりが見えない"の感情を抱えて日々を過ごしていた状況になりました。

その中でもやっとプロジェクト内のプロセス改善が少しずつされていきました。

　・情報連携不足の解消　※chat toolの導入
　・役割の明確化　※組織の体制表作成＆明文化
　・レビューの徹底、※修正漏れ、誤りの防止
　・不具合の一元管理化　※Excel複数ファイル運用からBTSの導入
　・不具合分析～解決までのプロセス確立
　・スケジュールの運用改善　※フォーマットの改善、周知徹底フローの改善
　　etc…

細かいレベルの改善をあげればキリはありませんが、全員で少しずつ少しずつしていきました。

その甲斐もあってか、運用開始から半年を過ぎた頃に解決件数≧発生件数の収束傾向が見え始めました。

見え始めましたが・・新規案件の追加対応、山は越えたということで人員も少しずつ減らし始めたこともあり、その後も対応は日々続き約2年かけての障害対応が終わりました。
※このときにやっと所謂"保守"フェーズへと移行できました。
※発生した本番障害件数の記載は避けさせていただきます。

自身の業務内容

蛇足的な内容になりますが、自分はこの状況下でよく言えば幅広く業務を任されました。大きく携わっていた点は下記になります。

　・スケジュールの進捗管理 + PMへの状況報告
　　残不具合の対応状況をPMへ1件1件事細かに対策状況を報告する必要がありました。
　・スケジュール作成 + フォロー対応
　・不具合管理
　・主に自社側の人員追加時等の事務作業
　・データ修正のパッチ対応

当初はQAとしての役割を期待されていましたが、状況的にテストで新たな不具合を見つけても、開発側にはそれを修正する余力がないため、その役割を必要とされませんでした。
如何にして円滑に開発側タスクを進められるか、開発者は調査や不具合の修正に集中できるかを求められてこのような形になりました。

結果としてPMOのような役回りとなりましたが、スケジューリングの難しさ(※)、そのフォローアップの大変さを身をもって経験できたことは非常に良かったです。
※残3桁を超えた不具合の内容をみて、優先度を考慮して1か月以上先までの線を引くイメージになります。状況が状況だけにリスケの嵐となりました・・。

学びや大切だと感じたこと

様々なことを経験させていただきました。

特にPMOのような役回りになっていたため、開発部署の部課長以上の方と共に一緒に仕事をすることが多かったです。そこでの度々発せられた問題の解決策や、やり取りの中での思慮の深度は非常に参考になりました。

また、改めて何事も経験だと感じました。過去にPMOの方と一緒に仕事をさせていただいたこともあり、自分の役割のイメージは掴めていましたが、実際にやると大変でした・・。

そして無茶振りに動じない精神は他の方よりも持てるようになったと思います。未経験の業務内容を度々依頼されましたが、周りに協力を得ながら進められ、結果的にどうにかできるの精神を保てるようになりました。

最後に

このような大規模プロジェクトの大混乱の中で、自分ではどうしようもできないことがたくさんありました。
冒頭の教訓に記載させていただいた通り、いま皆さんの携わっているプロジェクトで似たようなことは起きていないか今一度確認していただき、改善に向かうようにしていただけますと幸いです。

もし炎上ないしはそれに近しいことが起きてしまった以上、QAとしては被害を最小限に留めること、その再発防止に努めることも大切な役割だと考えています。

ここまで長文につきあっていただきありがとうございました。