全てのアナリストはソフトウェア開発からテスト思考を学ぶべきだと思う

私は現職にてアナリストを初めてかれこれ一年経ったのですが、その前の職場ではマーケティング関連のソフトウェア開発部隊にてテストリーダーを担っていました。

テストに関する責任者としてバグには人一倍敏感だったと思うのですが、その私が一年経って思うことがあります。

アナリストの皆さん、テストをデータチェックだけだと思って軽んじている。

もちろん、納品までの期間がソフトウェア開発とは決定的に違うことなど、一概に同じ基準を適用することはできないかもしれません。また、私の接している環境だけの弊害かもしれません。
しかし、各アナリストが思い思いの検品項目を考えてチェックし、上司の経験と勘で最終チェックを行う運用は、実は多いんじゃないかと思っています。そしてそこで行われるのはほとんどデータチェック。

データチェックだけをテストと考えたらテストは、そしてアナリスト業務は単調に感じてしまうと思います。現職でもやりがいに関して悩みを相談され、同じ悩みの人は多いのかもしれないと思ったこともあり、私の経験を活かすべくこうして筆をとっています。

前置きが長くなりましたが、『この１冊でよくわかる　ソフトウェアテストの教科書』などをなぞりながら、ソフトウェアテストの手法を参考にしてアナリストの検品手法を整理していきたいと思います。お悩みの方もそうでないアナリストの方も、ぜひ参考にしてください。

なお、私が外部アナリストとして社外のプロジェクトに参加しているため、「クライアントのための分析」を主眼において書いています。「社内用の分析」の場合は適宜読み替えていただけますと幸いです。

1. 「品質」について

そもそも「テスト」とは、「品質」を上げるために行われるプロセスです。この「品質」という言葉ですが、ソフトウェアでは「ユーザーの要求を満たし、ユーザーに価値を提供する度合い」という表現で大まかに定義されます。

つまり、テストとは単にデータの整合性を確認する作業ではなく、「本当にこれがクライアントの欲しいものか？」「クライアントに価値を提供できるか？」といった部分まで確認するプロセス全体を指します。
ちゃんとしたテストの設計・実施は、仕事の成果を向上させるために不可欠なプロセスです。

また、品質には３種類あるとされています。それぞれ「当たり前品質」「一元的品質」「魅力的品質」です。（詳細はGoogleで「狩野モデル」と検索してみてください）これらを元に、クライアントのどの要求から応えるかの優先順位を決めていきます。

2. 「テスト工程」について

テスト工程としては、一般的なモデルとして「V字モデル」というものが存在します。古典的なモデルですが、「仕様確定→開発／分析→報告」などのフローに沿って行う業務では今なお通用する有用なモデルです。

このモデルの特徴としては、「要求定義」「要件定義」「詳細設計」といった上流から下流の分析設計に対して、対応するテスト設計を示していることです。「要件定義」などで分析の仕様を決めてテストするだけでなく、「要求定義」でクライアントの要求を洗い出したものについてもテストが必要だ、と図示しています。

3. 「テスト設計」について

じゃあ具体的に「テスト」って何するんだ？　という話ですが、基本的には「組織ごとにやるべきことは違います」。突き放しているわけではないのです。責任範囲が「分析からパワポのプレゼンまで」であれば広くなりますし、「分析だけ」であれば多少少なくなります。また、インプットデータ、採用モデル、ロジックなどによっても異なります。

ただそれだと学びがないので、一例として、一般的なアナリストがやるべきと思われるテストをお示しします。設計は上から下の順で、実施は下から上の順で行なっています。（実際に私がやっているものです）

・システムテスト（←要求定義）
クライアントの使い方を考えられているか、データから語りやすいか等の確認。グラフの見せ方やレイアウト、プレゼンの内容など。
・機能テスト（←要件定義）
クライアントに依頼されたデータ、そして見たかった結果が揃っているか確認。揃っていない場合、追加でどんなデータ収集・分析を行うか考える。納品する分析仕様書などもここでチェック。
・結合テスト（←基本設計）
分析実行後のデータ確認。データ自体に違和感がないか、他の方法で得た結果と一致しているかなどのクロスチェックを行う。
・単体テスト（←詳細設計）
集計ソフトウェア内集計ノード作成直後のロジック確認。JOIN時にレコード数が膨れていないか等の細かいところをチェック。

4. 「テスト実施」について

テストを実施した後には、それをドキュメントに残すことが必要です。ドキュメントの作り方はそこまで形式張る必要はないと思いますが、各組織でテンプレートがあると実施しやすいだろうと思います。

参考までにですが、私はよくExcelを使います。A~F列など左側にテストケースの内容を記載し、G列から右側に証跡としてデータを記載します。目的はテスト実施し忘れの防止やトラブル時のアリバイなどであり、あまりガチガチなものを作ると作業効率が落ちてしまうので、「後から他の人が見返して理解できればいい」くらいの気持ちで作っています。（理解可能か否かは上司と同僚に確認してもらっています）

さいごに：あなたは「品質マネージャー」

私が思うに、アナリストって結構やりがいを感じづらい職種だと思います。クライアントに直接報告できるならまだいい方で、裏方でずっとパソコンとにらめっこして、集計が間違っている時だけ呼び出されて怒られる、そんな日すらあると思います。

しかし私の前職においてQA（Quality Assessment、テスト）といえばPM（Project Manager、プロマネ）と対等にやりあう重要な仕事でした。その理由は今まで書いてきたように「顧客満足を誰よりも考える仕事」だからだと思います。アナリストも同じです。分析関連の仕事において、他の誰よりも真摯に「品質」に向き合える職種だと思います。

是非みなさんも「品質マネージャー」として社内外と渡り合い、楽しいアナリストライフを共に歩んでいきましょう！