サイト再構築プロジェクトで最初に苦労したこと

 はじめにKINTOテクノロジーズ（以降KTC）で社内システムのPdMをしている小林です。KTCに入社後は[KINTO ONE](【KINTO】新車のサブスク、トヨタから|フルサービスのカーリース (kinto-jp.com))のサイト再構築プロジェクトにアサインされ、PjM、テスト推進、移行推進を担当しました。アサインされた時にはすでにプロジェクト開始から1年が経過し、開発は完了しており、結合テストを実施してリリースするという局面でしたが、このあと様々な課題にあたることになります。今回はテスト推進担当として最初に遭遇した課題についてご紹介します。
 サイト再構築プロジェクトとはKINTOのメインサービスであるKINTO ONE 新車のECサイトをリニューアルする内製開発プロジェクトです。アーキテクチャおよびデータ構造を全面的に見直し、開発生産性を高めることを目的としており、関連するプロダクトやサービスは20以上、ビジネスサイド、開発サイドの窓口担当者は合わせて50名ほどの規模でした。
 まずは状況把握私が入社したのは2022年2月です。まずは週次定例会に参加し状況を把握しつつ、テスト推進や移行推進を実施するという立ち位置でのスタートです。
入社する少し前の2022年1月中頃から内部結合テストが開始されていました。数日程度の遅延はあるものの順調との報告がなされており、この時点では内部結合テストの完了は2022年5月末の予定でスケジュールに違和感は無し。内部結合テストの計画は開発者が作成し、開発に携わっていないメンバーで構成されたテストチームがテストケースの作成と実施を担当するといった理想的な状況でした。
 最初の課題内部結合テストは7つにフェーズ分け進める計画でしたが、2月後半に内部結合テストの進捗に陰りが見え始め、3月最初の報告では1週間遅れとなりました。

このとき後続テストフェーズに影響がある不具合が10件以上あり、修正だけで１週間程度かかる苦しい状況であることがわかりました。このまま計画通りに行けるのか感覚を確かめるため、開発者に状況をヒアリングしたところ以下のような話が出てきました。
単体テストの終了条件がわからない
結合テストの開始条件がわからない
内部結合テストの内容が想定と異なる
開発者がまとめていた資料にはどのようなテストを実施するか記載はあるものの、確かに開始条件や終了条件に関する記載はなく、その手の情報は方針書や計画書にあるだろうと探しますが見当たりません。なるほど確かに。。
想定していたテスト内容について、開発者がまとめていた資料では「一通りの画面遷移を通してテストを行う」と記載があり、テスト項目として以下のような記載がありました。
正しいデータを入力した際に、正しい画面表示・遷移がなされるか
DBに正しくレコードが作られているか
途中で処理を中断した際のデータは回復可能か
この内容からストーリーをベースにしたテストを想定しているように見え、テストチームが用意したテストケースとも合致しますので、何が混乱のもとになったのか考える必要が出てきました。

ふと開発者がまとめた資料を見るとテストの実行方法について以下のように記載されていることに気づきます。
ブラウザごとにテストを実施する（画面テストと同様）
DBについてはDBの値を直接SQLで確認する
単体テストで実施した画面テストと同様との記載。この記載では単体テストと同様のテストをフロントエンドとバックエンドを結合して実施するように見えます。なんとなく混乱の原因がわかりました。認識齟齬のない計画の重要性が感じられる課題です。
 課題への対応テストを止めず無理に進めても遅延が拡大する可能性があるため、この課題への対応は「2週間内部結合テストを止めること」でした。この対応により次のような効果が得られます。
 開発サイドのリカバリが可能テストを止めることにより修正に時間を使うことができ、遅延リカバリが可能となりました。また修正に注力することができるため品質が上がります。開発者とテストチームはテストが進まないストレスから解放されます。
 品質管理方針と品質評価基準の整理が可能テストを止めることにより、内部結合テストのみならずテスト全体の方針や基準の整理が可能となり、以下の内容を周知することができました。
各テストフェーズで確保すべき品質を品質管理方針として定める
各テストフェーズでの品質評価基準を定める
後付けでの方針と基準の提示でしたが、開発者は受け入れてくれました。この柔軟性がKTCの良いところですね。内部結合テストは無事回り始めました。
 その後その後も様々な課題が出てきます。他案件との関係でスケジュール変更が発生した際には、品質強化テストを追加したりと、状況に応じて品質を上げるよう計画を見直しつつ、外部結合テスト、他案件の後追い取込、QAテストを実施し、2023年8月に無事リリースを果たしました。

規模の割にリリース後の障害が少ないと言われています。しかしながら障害が発生すると少なからず業務影響がでてしまいますので、今後もより品質を高められるよう、できることを考えていきたいと思っています。
 最後に今回の経験から、次の2点が重要と考えています。
認識齟齬の無い計画
品質管理方針および品質評価基準の設定

開発者に任せるにしても何かあった際の道標として、計画、方針、基準はきちっと整備すべきと思いました。
また今回課題への対応について気を付けた点は、いずれの対応も開発者に作業指示を行わないという点です。サイト再構築プロジェクトでは詳細設計から内部結合テストまでを開発者に任せる方針としていました。これはプロジェクトの方針であり守りたかった部分です。そこもなんとか守れたかな。
以上、サイト再構築プロジェクトで最初に苦労したことのご紹介でした。