Software Quality Assurance（品質保証）の取り組み - MONEX ENGINEER BLOG │マネックスエンジニアブログ

こんにちは。システム開発三部開発推進グループ長の竹中です。
開発推進グループでは、システム開発プロジェクトの推進をサポートするような業務にあたっています。
SQAやPMOとしてプロジェクトに参画したり、PMやエンジニアがプロジェクトを進めやすくするべくプロセス改善に取り組んだり、結合テスト環境の整備・運用を行ったりなどなどです。
今回の記事では、その中でもSQAのシステム開発プロジェクト内での取り組みについて紹介します。

SQAって？

Software Quality Assuranceの頭文字をとってSQAとしています。日本語にすると「ソフトウェア品質保証」です。
単純にQAでもあるのですが、Question & AnswerのQAと紛らわしいので、意識的にSQAと呼ぶようにしています。

過去のMONEX ENGINEER BLOGにも度々登場していますが、当社ではシステムを内製開発しています。その体制や仕組みの成熟に伴って、SQA部門を2020年4月に立ち上げ、ここ2年ほど取り組んできています。
SQAはテストケースを作って、テストを実施して、結果を報告するというテスト活動だけではなく、システム開発プロジェクトの様々な場所で"テスト"を意識した活動を行います。

SQAをプロジェクトに投入するには、当たり前ですが、その分のコストが必要です。
プロジェクトの特性に応じて活動内容を取捨選択し、その費用対効果をしっかり出していくことの意識が大事です。

効果やねらい

当社でのSQAの活動により得ようとしている効果やねらいをいくつか紹介します。

上流工程での欠陥検出、不具合埋め込み防止（シフトレフト）

当社の基幹システムの開発はウォーターフォール型で進められます。ウォーターフォールというと、開発工程とテスト工程を対応させたＶ字モデルを目にします。
SQAを参画させるときには、このＶ字モデルにもうひとつSQA活動のＶ字を重ねたＷ字モデルの形をイメージします。
上流工程からエンジニアの活動に寄り添ってテスト設計者の目線でレビューをし、質問を投げかけ、目を向けられていなかった点、すなわち、そのまま見落としていたら、テスト工程で検出していたであろう欠陥を早期にあぶり出す（シフトレフト）ことを目指します。

エンジニアがテストのことを考えながら要件定義・設計をすればSQAいらなくないか？という考えもあります。
それはそう。なのですが、作ることと検証することの逆方向のベクトルをぶつけると、出力が小さくなります。ひとりの頭の中でそのせめぎ合いをするのは、疲れてしまいます。
作る人は作ることに集中する。検証する人は検証することに集中する。「いいシステムを作る」という同じゴールを向いてそれぞれのベクトルをすり合わせて、より高みへ昇る。そんなイメージです。（伝われ）
ただし、エンジニアが要件定義・設計を進めると、テストのことも考えたものができている、という形を目指したプロセスやフォーマットの改善も開発推進グループの職務のひとつです。

なお、欠陥を早期に検出するとどんないいことがあるのか、については、過去のMONEX ENGINEER BLOGで語られていますので、是非そちらをどうぞ。

blog.tech-monex.com

テスト設計や実施をエンジニアから引取る

Ｖ字モデルに従うと、結合テストのインプットは基本設計になります。
基本設計工程の終了後、エンジニアで製造（詳細設計～実装～単体テスト）をしている間に、SQAで結合テストの計画・設計・実装を並行して進めることで、プロジェクト期間全体の短縮を図ります。
また、エンジニアだけでテスト実施を行う場合、テスト実施と不具合改修を同じリソースで行うことになり、想定以上の不具合があるリスクに備えてバッファを多めに積むこともあると思います。
SQAもテスト実施に参加させることで、エンジニアリソースの有効活用に繋がります。
テスト実施時のみ、テスターを追加投入して体制を厚くすることも考えられますが、SQAは上流工程から参画してプロジェクト内容をしっかり理解しているため、キャッチアップが不要だったり、テスト手順の範囲外にある欠陥に気づきやすいという利点もあります。

リスクベースドテスト、リスク分析

リスクベースドテストは、欠陥を開発中に摘み取りきれず、本番に流出した場合のリスクが高い箇所にウェイトを置いてテストを実施していく考え方です。
逆説的には、リスクが低い箇所のウェイトを軽くすることによる時間や費用のリソース効率化を目指す考え方でもあります。
当社でのプロジェクトのいくつかでリスクベースドテストに取り組んでみた経験からすると、テスト実施における効果は限定的でした。
高リスク箇所のテスト実施順を早め、低リスク箇所は後に回すといったような、テストスケジュールを策定するときのインプットになります。
また、何らかの事情でテストスケジュールが逼迫し、テスト実施箇所を削ったり、他で代替したりする検討が必要になったときに、すでに低リスク箇所がわかっているので候補を探す手間がなくなる、といった効果は得られました。
ただし、SQAなしに、エンジニアのみでテスト設計・計画を行うときに感覚的に行えていたことを、論理建てて説得力のある成果物で補強できた程度だったかなと感じています。
これは、当社でのシステム開発を内製化しているため、ユーザ（業務担当やエンドユーザ）の感覚を比較的近いものとして持てているということも理由のひとつかもしれません。

リスク分析の流れをもう少し具体的に紹介します。
要件や基本設計での記載粒度のそれぞれにおいて、そこに欠陥があり、テストで摘み取れず、本番に流出した場合にどういった被害があるのか、その発生可能性と影響度はどの程度か、というのを想像して可視化していきます。
例えば、前日に受注した注文データを夜間のバッチ処理で集計して社外の取引先にデータ連携するような要件があったとします。
集計の基準はどうするか、社外取引先へのデータ連携のインタフェースはどうなるか、そのタイミングは、などなど機能設計していくにあたって詰めることはたくさんあります。そこは、エンジニアに頑張ってもらいます。
その傍らでSQAでリスク分析を行います。想定できるリスクには「社外取引先にデータ連携がされないリスク」や「連携したデータの内容が誤っているリスク」などがありますね。
発生可能性は、データ連携の経路は既に稼働中のものを利用したり、材料になる注文データが既に稼働中のシステムや運用で入力されるものであれば、低いとできそうです。
新しい経路を敷いたり、手作業での注文データ入力を新しい画面で行う新規運用を始める、とかだと、発生可能性は高いと置くべきです。
影響度についてはいろいろな評価の仕方がありますが、サービス・業務がどの程度止まるか、復旧にどの程度の時間をかけられるか、というのを軸にすると考えやすかったです。
数時間で復旧しなければ業務が立ち行かなくなるなら影響度：大、翌日朝までに復旧できればよければ影響度：中、1週間程度余裕があるなら影響度：小、などです。
こうして、要件・基本設計の記載粒度それぞれに発生可能性と影響度の掛け算で決めたリスクの高低をつけていきます。

先に「テスト実施における効果は限定的」と書きました。一方で、SQAのテスト中心という目の向け方からナナメに一歩踏み込んで、プロジェクト管理としてリスク対策を考えることに繋げることで、かなりの効果と発展可能性を感じています。
全部に対してひとつひとつ対策を検討すると時間がいくらあっても足りないので、リスク：高のものだけでも実施推奨です。
リスクは排除すべきものではなく、上手にコントロールすべきものです。
開発中のテストを重点的に行うことで発生可能性を低減させるのもリスク対策ですし、再送手順や復旧手順を予めしっかりと準備することで影響度を小さくするのもリスク対策です。
営業時間中に早期検知できるようチェックバッチを設けるといったような運用上の要件や必要な機能が浮かび上がってくる効果も期待できます。
連携したデータの取引先での用途を深掘って確認することで、実はそんなにクリティカルなものではなかったり、利用するまでの期間に猶予があったりなどが判明した場合は、リスクを許容する（発生してから何とかできる）のも立派なリスクコントロールです。他の優先度の高い課題にリソースを割けますね。