アーカイブ動画

PM/PLは、品質をどうマネジメントすべきか

バルテス株式会社
テスト・アライアンス事業部 事業部長　石原 一宏氏

最初に登壇した石原氏はソフトウェアテスト業務に30年以上携わってきており、セミナー講師、書籍の執筆など多方面で活躍する業界の第一人者だ。

「人・リソースが足りない」「テストの漏れや抜けに悩んでいる」「効率的に品質を確保したい」「手戻りが多い」など。石原氏はまずソフトウェア開発の現場においてよく聞く悩みを紹介した。

リソースが足りない中で、品質を確保しなければならないといった、ある意味矛盾していることを指摘した。これらの悩みはPM/PLに限らず、領域問わず多くのエンジニアに共通していると言えるだろう。

「優秀なPM/PLは、こうした一見矛盾する品質をうまくマネジメントしている」と石原氏は語る。実現に向けて品質だけを見ているのではなく、コストやデリバリーも意識した中で工夫して品質を上げているからだ。

結果として品質がアップし、品質が高いために手戻りが減る。結果として限られたコストや納期でも、高品質な成果を出せる。

このような品質をマネジメントするアプローチが「テスト基盤」であり、「要求分析」「機能動作確認一覧表（FV表）」「テストマップ」という大きく3つのアプローチとツールで進める。それらを石原氏は「三種の神器」と表現した。

三種の神器「要求分析」で何をテストするのか

1つ目の神器「要求分析」について解説する前に、石原氏は改めて開発現場で当たり前に目にする「要件定義と要求の違い」を次のように説明した。

「要件とは主語がシステムであり、システムができなければいけないことです。一方、要求の主語は顧客であり、顧客が求めていること。つまり要求が満たされていれば、良い品質だと言えます。従って、まずは要求を分析することが重要です」（石原氏）

顧客の要求は「Must」「Never」「Want」と3つに分けて考える。Mustは必須の機能、カメラであれば写真が撮影できる、車であれば走る・曲がるといった機能。逆にNeverは、絶対に起きてはいけないこと。車であればブレーキが効かないといったことだ。

Wantは付加価値であり、顧客が潜在的に求める要求である。システムに実装できていれば当然、顧客からは品質が高いとの評価を受ける。

石原氏は電子レンジを対象とした参考例を示し、それぞれの要求を挙げていく上でのポイントを説明。当たり前の品質、MustとNeverについては、Mustだけを考えるのではなく、Neverもセットで考えることが重要だと語った。

例えば「発火・爆発」というNeverを考えたからこそ、温度センサーならびに自動停止機能がMustとして浮かび上がってくるからだ。

「MustとNeverをセットで考える手法は、テストエンジニアはもちろん、保守に携わるエンジニアなどにとっても大事な考え方です。仕事の幅を広げるためにも、ぜひ抑えておきたいポイントです」（石原氏）

もうひとつのフレームワークとして、石原氏はソフトウェア品質の評価に関する国際規格、ISO9126を取り上げた。まず大事なのは「機能性」「信頼性」「使用性」の3つを満足させることである。以前からある国際規格ではあるが、今でもこの3本柱は崩れていない。

ちなみに石原氏たちがテストを行う際に参考とする仕様書では、機能性のMustしか書かれていないことが多く、非機能要件や、準正常系・異常系を含めると、テストしなければならない全体の30％も書かれていればいい方だという。

要求分析を行う際に使うドキュメントも紹介しながら、「機能性」「信頼性」「使用性」といった顧客にとっての品質に加えて、「効率性」「保守性」「移植性」といった作り手側の品質にもこだわって確認していくことが、要求分析の重要な考え方だと伝えた。

「仕様書に書かれていようがなかろうが、テストする必要があります。アジャイル開発でバックログを作成する際にも有効的な考え方でもあります」（石原氏）

ここからはバルデスに入社する以前から、金融系システムの開発に携わっていたキャリアを持つ畠山塁氏にバトンタッチ。畠山氏は現在も引き続き金融案件領域を手がけており、品質マネジメントの他、冒頭で紹介したコンサルティング業務などにも従事している。

バルテス株式会社
エンタープライズ品質サービス事業部 東日本ソリューション部
金融ソリューションサービスグループ 副部長　畠山 塁氏

畠山氏は石原氏の説明を踏まえ、実際に現場で要求分析をどのように進めているのか。金融機関の申し込みサイトの実例で説明した。

実際にはチームの複数メンバーで、新人からベテランまでが集まって取り組んでいるが、「これこそがポイント」だと畠山氏は強調する。人により気づく観点が異なるからだ。石原氏の説明に重なるが、機能性要求以外の非機能性についても仕様書に書いていないからといってテストしなくてよいのではない。

「仕様書に書かれていることだけでは、どうしてもテスト漏れが出てきます。ですから逆に仕様書にはとらわれない考え方が重要です」（畠山氏）

また、メンバー同士で要求分析を行った場合、コミュニケーションが活発になると同時に、認識が共有されることも大きい。顧客に対しても分析表があることで、同じくコミュニケーションのきっかけとなり、開発チームへの確認といったアクションも取りやすいと、様々なメリットが挙げられた。

三種の神器「機能動作確認一覧表（FV表）」でどうテストするのか

要求分析により様々な要件が出てきたら、テストを行う前に各機能の必要性や目的を考え、テストする内容をブレイクダウンする。これが2つ目の神器「機能動作確認一覧表（以下、FV表）」だ。

石原氏は「機能とは何かを達成するための手段である」と語り、再び電子レンジを例に、FV表の具体例を紹介した。例えば「タイマー機能」であれば、設定した時間だけ電子レンジを動作させることが目的なので、時間が正確である必要性がある。この内容を検証内容欄に書き込んでいく。

さらに、設定した時間だけ「あたため機能」が動作しているかどうかといったテスト内容も見えてくる。問い直しやブレイクダウンといった思考法だが、実際に同フレームワークを導入したことで、石原氏は様々な成果を得たという。

まずは、本イベントのテーマである手戻りが減ったことだ。レビューも楽になる。そして、三種の神器共通のメリットとして、関係者の意思疎通がスムーズになったことを挙げる。

「不完全でも構わないので、三種の神器のようなドキュメントを作成しましょう。そして、そのドキュメントを真ん中に置き、ステークホルダーが集まり議論する。コミュニケーションが楽になり、顧客との認識も揃っていきます」（石原氏）

機能をブレイクダウンしていく際も、Must・Neverの考え方を頭に入れておくとスムーズだ。例えばログイン機能。正しいIDとパスワードでログインできるのがMust、無効なIDとパスワードではログインできない。こちらがNeverとなる。

このような思考でブレイクダウンしていくことで、その先、確認内容においても明確に記載できるからだ。実際、Never系から漏れや抜けが生じることが多いという。

もうひとつ、テストにおいては仕様通りにできることを確認する「Checking」。一方、高負荷をかけるなど意図的に誤作動を誘発する「Testing」。この2つのテストが2大要素であると同時に、両方必ず漏れなく、様々な条件で実施することが重要となる。

ここからは再び畠山氏にバトンタッチし、金融機関の申し込みサイトの事例をもとに、FV表の作り方や成果などを紹介した。

一般的な設計ドキュメントは文字ばかりが並んでいるため、場合によっては把握することが難しいケースもある。対してFV表は、「見やすい」という点もメリットとなる。

機能は以下の「他機関データ連携」を例とした。Must・Neverとブレイクダウン、枝分かれしているのが見て分かりやすい。実際、FV表を用いたことで本案件ではバグが潜んでいることが判明したという。「テスト段階ではなく設計段階で分かったことが大きい」と、畠山氏は成果を強調した。

「テストで使う技法ですが、上流工程で設計技法として用いれば、今回の事例のように早い段階で抜け漏れが判明できるため、修正コストも含めて有効な手法だと言えるでしょう。早い段階の工程から品質を高めていくことは、非常に大事だと思います」（畠山氏）

三種の神器「テストマップ」でテストの全体像を把握する

3つ目の神器「テストマップ」はテスト全体を見える化させ、無駄なテストを減らして省力化させるメリットがある。「完璧なテスト」を行うのは難しいが、必要十分なテストを実施するために使用するのがテストマップだ。

テストの抜け漏れを減らし、テストと仕様がトレースでき、最短でメンテナンスできるといったメリットもある。仕様書もテストベースもメンテナンスされていない派生開発現場では、状況の整理ならびにこれからの導きという意図でも、非常に役立つと石原氏は力強く語った。

「その原理はすごいシンプル」と石原氏は語り、実際のマップも紹介した。横軸に表示などテストの観点、縦軸にチューナーなど機能を組み合わせて、○がついている組み合わせは「テストをした」という証だ。

マップを作成することでテスト計画の立案はもちろん、リソース配分などがスムーズに進む。また、今回「テストしていない」箇所が記録としてわかるのも重要だと石原氏は説明した。

さらにはテストマップを軸に仕様書とテストケースを紐づけることで、メンテナンス漏れを防ぐトレーサビリティの効果がある。アジャイルやスクラム開発においても有効な方法だ。 派生開発など、変更時のテストケースがトレースしやすくなる点もメリットと言える。

トレースという観点では、引継ぎやオンボーディングでも効果を発揮すると、石原氏は数多くの利点を紹介し、畠山氏にバトンタッチした。

先と同じく金融機関の申し込みサイトでの事例では、開発を進めていくと、単体テストレベルの不具合が頻発していたという。実施範囲や確認方法がそれぞれ異なっていたからだ。また、テスト箇所が重複していて非効率でもあった。そこでテストマップを導入した。

マップの大枠は石原氏が説明したものだが、「○」ではなく「A・B・C」と重要度により、さらに細分化する工夫を施している。

さらには先の課題解決に向け、単体テストと結合テストの領域を明確に住み分けた。住み分けそのものはテキストベースのドキュメントでも可能だが、マップだからこそ、間違いが限りなく少ないことがわかる。

そして「－」。テストしなかった機能においてはレビュー時に改めて議論したり、マップになっているから俯瞰的に見ることで、同じく新たな気づきなども得た。

例えば、本番で障害が出た際にどこの観点が足りていなかったのか。実際にテストしていなかったのか。次からはテストした方がいいのではと、関係者間で共通の認識を持てたからだ。機能追加、引継ぎに関しても同様で、畠山氏は改めてメリットを次のように話した。

「テストケースの束だけでは理解するだけで時間がかかりますが、テストマップがあれば大枠を掴めるので、非常に有効だと思います」（畠山氏）

【Q＆A】参加者からの質問に登壇者が回答

セッション後はイベント参加者からの質問に、石原氏、畠山氏が回答した。

Q．リグレッションテストはどこまでやるべきか

石原：grep検索機能を使って、改修箇所の関数がどこに分布しているのかを追いかける方法が王道だと思います。お勧めなのはtestingを行い、バグが多発するような地帯が分かったらマーキングしておきます。そして、テストの優先、重点対象であることをメンバー同士で共有することが、1つの有効な方法です。

畠山：データを取りながら、継続的に改善していくといいと思います。バグが出やすいところはテストの頻度を増やす。逆に、何度かテストを行っても出ないところは頻度を落とす。それらをデータとして蓄積し、改善していく方法があります。

石原：改修後にどのあたりに影響が及ぶかは、慣れている方であれば頭の中でマッピングできるでしょう。それをテストマップに落とし込み共有する。結果として、メンテナンスの引継ぎなどもスムーズに進むと思います。

Q．テストマップの「機能」洗い出しの粒度について

石原：私も以前は、縦も横も先が見えないようなExcelを作っていましたが、まずはA4のドキュメント1枚で収まるような粒度から、スタートしても十分だと思います。1枚であればコミュニケーションの道具になるからです。内容としては大項目、中項目程度。そして次のステップで、より粒度の細かいものを作る。2種類でもいいと思います。

日本地図と同じように、全体を見ることのできるものから、都道府県、市町村単位といった感じで、抽象度をブレイクダウンしていくイメージです。

Q．開発者とPM（QA担当）におけるテストの責任範囲は？

石原：可能であればテストの計画段階で、単体テストと結合テストといったフェーズごとに、テストを割り振る計画を作ります。ただ計画も大事ですが、実際に進んでいくと漏れがあったりします。

バグが多い箇所なども出てきますから、そうした情報を開発者に聞くようにしましょう。そしてその際にはテストマップを片手に、印付けなどチェックしていくことも重要です。

畠山：お互いの認識を共有することが一番大事だと思います。認識を共有する際には、具体的にどこまで両者が担うのかを明確にしておきます。単体テストでやるべき範囲は、人によって異なるからです。

Q．品質保証の考え方について

石原：テストを何回行ったなどの定量的なものではなく、定性的な部分が重要だと考えています。まさしく要求分析とFV表による洗い出しです。特にNeverの考え方はリスクベースであり、品質保証における私のベースとなっています。

畠山：何を持って十分なテストとするかは、企業によって基準が異なりますが、やはりテストケースの量だけでは判断するのは危ないと思います。

Q．テストマップの重要度振り分けの観点について

石原：リスクインパクト、発生確率の2つの視点で考え、それぞれ1～3の3段階で優先順位をつけます。そして出た数字を足して5以上であったら、絶対にやるべきテストの「A」とし、3や4であったら「B」とするといいでしょう。

畠山：過去の開発を参考にもします。バグがよく起きている箇所、逆に品質的に安定している箇所で、重要度を分ける考え方です。大きな開発案件では機能ごとにチームが分かれていたり、それぞれ得意・不得意があったりするので、その観点から重要度を分けることもあります。

バルテス株式会社
https://www.valtes.co.jp

バルテス株式会社の採用情報
https://recruit.valtes.co.jp/