みなさまこんにちは。株式会社ソニー・ミュージックエンタテインメント（以下、SME）のだいきちです。私たちが所属している部門では社内で使用する業務アプリケーション開発・運用を行っており、2024年度は既存業務の効率化・コスト削減を実現すべく要件定義チーム、システムテストチーム、リリース計画チームの3チームに分かれて開発工程の見直しを行いました（詳細は連載の第1回目をご確認ください！）。各チームの担当者がリレー形式でその取り組みを語る本連載、第2回目となる今回は「システムテスト編」としてシステムテストチームの活動についてご紹介します。
これまでの開発体制とチームの目的
連載の第1回目でも記載した通り、私たちの部門ではシステム開発の多くをスクラッチで行っており、開発工程の大半を外部ベンダーに委託しています。開発手法はほぼウォーターフォール型で、要求分析～受入テスト～リリースまでをＶ字モデルで表現されるように上流から順番に進めています。
V字モデルでは各開発工程（図中左）に対応するかたちでテスト工程（図中右）が存在し、それぞれ以下のようなテストを行います。
-
単体テスト：モジュール単位でのテスト
-
結合テスト：モジュール同士でのテスト
-
システムテスト：システム全体を通したテスト
-
受入テスト：ユーザー要求や業務要件に基づく最終確認
この中でこれまで私たちの部門が主導で実施していたのは受入テストだけ。他の3つについては外部ベンダー主導で仕様書の作成やテストの実施を行っていただき、その内容をSMEがレビューする形を取っていました。今回の取り組みは、V字モデルの2層目（要件定義）までをSME主導で進められるようにすることが目的です。そこでチームとしては、システムテストの進め方を見直すことにしました。
浮き彫りになった課題点
まず現状のシステムテストにおける課題について話し合いました。前述の通り、これまでは外部ベンダーのフォーマットに則ってテスト仕様の策定や結果の確認を行っていましたが、確認の粒度については各アプリの担当者に依存していました。また、担当者の知識や経験が乏しく判断が難しい場合は、上長の判断を仰ぐなどの追加工程を踏んでいることもわかりました。さらに、話し合いの中で過去に作成したSME基準の開発標準が存在していたことも判明し、その周知や活用・適切なアップデートがなされていないことが明らかになりました。
ゴールとアクションプランの設定
これらを踏まえた上で、システムテストチームとしては年間の活動方針として、以下のゴールとアクションプランを設定しました。
▶ゴール：
- システムテストの品質のばらつきをなくし、向上させる
テスト項目の網羅性や正確性など、テストそのものの内容・精度に加え、タスク・進捗状況の可視性など、進行管理の容易さもスコープ対象とする
▶アクションプラン：
- 既存開発標準内のテスト工程をもとに新たにテスト標準を作成
- 学習カリキュラムの提供
1年間での取り組み
前述の活動方針を立てた上で、昨年度は上記のようなスケジュールで取り組みを進めました。
以下、実施した内容について説明します。
システムテストについての学習
チームメンバー内での知識や経験に差があったため、テストに関しての共通理解/認識を持つ必要がありました。そこで、開発工程におけるテストについて、IPA（独立行政法人・情報処理推進機構）などの公的機関が提供する資料や技術系専門サイトの情報を用いて自主学習を行いました。また、簡単な内製アプリをターゲットにテストシナリオを各メンバーが作成してみることで、フォーマットによって網羅性が異なることや、要件定義がきちんと定義されていること、アプリ担当者・テストメンバー側でのユーザー業務理解が重要であることなど、机上では見えなかった課題点を明らかにしました。
システムテスト標準テンプレートの作成
SMEとしての開発標準が実際には十分に活用されていなかった現状を踏まえ、担当者の経験レベルに依存せずにテストの仕様策定や結果確認などを実施できるよう、以下の成果物を作成しました。
①テスト計画書：どんなシステムで、どのテストを、何のために行うか/行わないかといった、テスト実施における要件確認、およびテストシナリオの記載やテスト実施状況の管理に利用
②テストスケジュール表：どのテストをどういったスケジュールで実施するか、予実の管理に利用
③不具合管理表：システムテストで発覚した不具合の詳細を記載し、今後の対応方針やタスク管理として利用
これらのテンプレートは、担当者がSMEとして押さえるべきテスト観点や必要な記載項目を明文化したものです。外部ベンダーからSME基準を求められた場合に提出したり、ベンダー側から提供されたテンプレートに対してSMEとしての観点でチェックしたりといった活用を想定しています。
学習のまとめを社内Wikiに記載
学習パートを通して学んだ内容（テストについての概要説明や学習教材など）を新規参画者向けに社内Wikiにまとめました。この際、過去の開発資料フォルダなども記載することで、情報の見落としや属人化を防ぎナレッジ共有の精度を高めるようにしています。また、新たに作成したテスト標準についても同様に添付し、アクセス性を高めることで、開発標準の浸透にも一定の効果が見られました。
実際のシステムテストに使ってみた！
2024年度には全社的に利用しているグループウェアシステムのリニューアル開発が私たちの所属する部門で内製されていました。システムテストチームでテスト計画書を含む各種テンプレートを作成していることもあり、我々システムテストチームがテストを担当することになり、作成中のテスト計画書のテンプレートをさっそく実践投入することになりました。また、それと並行してシステムテスト計画の立案も行いました。
テスト計画書を実際のプロジェクトの中で使ってみたことで、以下のような成果を得ると同時に要改善点が見えてきました。
★成果
- 具体的な案件に用いたことで、各項目をどの程度の粒度で記載すべきかの感覚をつかむことができた。
- テストの目的などを明確に記載することによって、テスト作業がしやすくなったほか、レビュー時にも内容が把握しやすくなった。
- テスト計画の流れや項目がまとまっているため、「次に何を実施するのか」が把握しやすくなり、経験の少ないメンバーでも計画を立てやすくなった。
★要改善点
- 一部の項目にそもそもどう入力すれば良いか理解しづらいものがあり、初めて使う人にはハードルが高いと感じた。
- 今回のプロジェクトは旧システムを新基盤に載せ替えるリニューアルだったため、仕様を記した正式な文書が存在しなかった。そのため本来要件定義工程内で定義・確認される情報が不足しておりテストシナリオの作成に手間取った。また、テスト実施中に旧システムと異なる挙動があった際、新基盤側の制約に起因するものなのか、新しい仕様に基づくものなのかを判断するのが難しかった。
これら要改善点については、システムテストチームが活動を終了する3月までの間に順次修正を重ね、おおむね解決することができています。
活動の振り返りと今後に向けて
昨年度の活動では、業務範囲も経験も異なるさまざまなメンバーが集まる中で、システムテストという共通のテーマに取り組むことができました。業務の合間を縫っての活動ではありましたが、いろんな視点や意見を持ち寄ることで内容にも幅が出て、チームとしても良い学びの機会になったと思います。
活動の成果としては、システムテストの品質のばらつきをなくし、向上させるためにテンプレートを3種類作成しました。その中でも①テスト計画書のテンプレートは、実際のプロジェクトでの利用にもつなげることができ、実用性や改善の方向性を具体的に把握することができました。また、テンプレートの作成を通じて、そもそもテスト計画をどう進めるかや、どういった項目を決めておくと後のプロセスを楽に進められるかなど、普段あまり意識できていなかった観点についてもチームで深堀りできたことが大きな収穫であったと感じています。
残る②テストスケジュール表・③不具合管理表のテンプレートについても改めて内容を精査しながら、プロジェクトでの実運用を通して継続的なアップデートを行っていく予定です。また、開発ルールの変更などが発生した際には、テンプレートを都度見直すことが必要であるとも感じています。
さらに、学習カリキュラムの提供については、他チームでも作成している社内Wikiとの記載内容の表現を統一することでチーム間の理解のずれを減らし、部署全体でのSME開発標準の再認識を促進させたいと考えています。
ここまで読んでくださり、ありがとうございました。次回はリリース計画チーム編となります！お楽しみに！
