はじめに
旅が大好きな、いしだぁぁです！
私は、現在ソフトウェアテストとはかけ離れたアノテーション（詳細は後述）に関わるプロジェクトに従事しており、ソフトウェアテストの経験は浅いですが、JSTQBのFL取得に向けた学習を行っています。
ソフトウェアテストを勉強していくうちに、アノテーションの作業プロセスは、ソフトウェアテストプロセスと類似していることが分かりました。
アノテーションの作業プロセスに、ソフトウェアテストプロセスを応用すれば、よりよいプロジェクトになれるのでは、とそう考えました。
まずは、ソフトウェアテストプロセスの良いところをどのように取り入れていけばよいのかと考えたとき、最初に頭に浮かんだのは「学ぶことは、模倣から始める」です。
「模倣」は、否定的に見られがちですが、個人的には、ただ真似るだけではなく、その中から工夫も改善も自然と生まれ、重要な要素であると考えています。
このテックブログを通して、アノテーションのようなソフトウェアテスト以外のプロジェクトでも、ソフトウェアテストの様々な仕組みや技法を知ることによって、プロジェクト成功への近道となるヒントがもらえるのではないか、と感じていただければ幸いです。
アノテーションとは！？
「アノテーション」と聞くと、あまりなじみがなく、遠い存在だと感じる方が多数いらっしゃるかもしれません。
私もその中の一人でした。
アノテーションとは、英語で「注記・注釈」という意味であり、ITの分野では、対象となるデータの一つひとつに、タグやメタデータと呼ばれる情報の付与を行う作業です。
アノテーションの対象となるデータには、以下の３種類があります。
- 画像＆動画データ
- 音声データ
- テキストデータ
より詳しく言うと・・・アノテーションとは、AI開発のプロセスにおける必須の通過点であり、機械学習に使われる教師データを作成する工程を指しています。
教師データって！？
例えば、みかんの画像があったとします。 この画像を「みかん」とAIに認識させるためには、みかんの画像に「これはみかん！！」という情報を付与してAIに学習させる必要があります。学習用の画像それが教師データです！！この教師データをたくさん作り学習させることで、AIがみかんを認識できるようになります。
しかしながら…AIにみかんの画像だけを学習させればいいというわけではなく、同時に例えば「りんご」との違いも認識する必要があります。AIにみかんだけの画像ばかり学習させてしまったら・・・りんごの画像を見せたときに、りんごをみかんと認識してしまう可能性があります。そのため、りんごのデータも学習させる必要があります。そうすることで、AIはみかんとりんごの特徴の違いを認識できるようになります。
このように教師データを使った機械学習によって形作られたAIは・・・実は、ビジネスや日常生活等のあらゆる場面に潜んでいます。
「これは便利だ！」、「すごい・・・技術が進歩している！！」と思っていたそこのあなた。
それらのモノにはアノテーションを使った学習済みAIが組み込まれている可能性があり、ビジネスや日常生活などで直面する問題を解決する手助けとなっているかもしれません！
アノテーション作業自体はとてもシンプルですが、AIの教師データとなり、その品質がAIの動作に大きく影響を与えます。AIが正しく動作するように、一枚一枚丁寧に作業してあげる必要があります。ですので、日々我々は「重要な役割を担っているんだ！」という使命感を持って作業しています。
ソフトウェアテストとアノテーションの作業プロセスについて
書籍『ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応』（以下「ソフトウェアテスト教科書」と称する）に出会う前までは、アノテーションの作業プロセスについて深く考える機会がありませんでした。
ソフトウェアテストを勉強していくうちに、アノテーションの作業プロセスは「実行前作業」「実行時の作業」「完了作業」「全体を通して行われる作業」の4つに分類され明確になるのでは・・・と気付きました。さらに、アノテーションの作業プロセスには、ソフトウェアテストプロセスとの類似点があることにも気付きました。
何を隠そう、私はソフトウェアテスト教科書に出会う前までは・・・事前準備や納品等の事後作業もすべて「作業実行」に含まれると思っていました。つまり、アノテーションの作業プロセスは、「作業実行」1つのみであるというのが、私の最初の考えでした。お恥ずかしい限りです・・・
それでは、両方のプロセスの全体像を見ていきましょう。
ご覧の通り、両方とも「実行前作業」「実行時の作業」「完了作業」「全体を通して行われる作業」の4つに分類することが可能です。
私が現在担当しているプロジェクトについて、ソフトウェアテストプロセスと同じように整理することができました。
ソフトウェアテストとアノテーションのプロセスの類似点について
つぎに両方の類似点に着目していきましょう。
| プロセス/作業内容 | ソフトウェアテスト | アノテーション |
| 実行前作業 | テスト計画（開始基準の設定） ・テスト目的の決定＆共有 ・テスト範囲の決定 等々 |
作業前準備（開始基準の設定） ・作業目的の決定＆共有 ・作業範囲の決定 等々 |
| 実行時の作業 | ・実行レポートへの反映 ・欠陥レポート作成、反映 等々 |
・実行レポートへの反映 ・欠陥レポート作成、反映 等々 |
| 完了作業 | ・テスト結果の報告 > 実行レポート提出 > 欠陥レポート提出 ・テストウェアの整理 |
・作業結果の報告 > 実行レポート提出 > 欠陥レポート提出 ・改善活動 > 各レポートの整理整頓 等々 |
| 全体を通して行われる作業 | ・進捗管理 ・終了基準等の達成状況の確認 ・進捗レポート作成＆提出 等々 |
・進捗管理 ・各メンバーの目標値の達成状況の確認 ・進捗レポート作成＆提出 等々 |
ご覧の通り、プロセス内の作業内容にも多くの類似点があることがわかりました。
多くの類似点の存在を知ったことで、今ではプロジェクトでうまくいかないことがあったら、ソフトウェアテストプロセスや作業のやり方・良いところを模倣して参考にすればよいのだ！という安心感を持って進めることができています。
応用事例の紹介
それでは、実際にソフトウェアテストプロセスを、アノテーション作業プロセスに応用してみると、どのような効果が得られたか、いくつか応用事例を紹介します。
応用事例１「開始基準」の応用
ソフトウェアテスト教科書には、このように記載されています。
💡 開始基準
「開始基準が満たされないままにテスト活動を開始すると、難易度が上がり、テスト時間が増え、コストも増え、リスクが高まります。」
アノテーションは、画像が驚くほど大量にあります。画像が何万枚もある中で、どこから作業を始めればよいか、どこまで作業をすればよいか、といったような迷いが出ないように事前に入念な準備が必要となります。
特に初めて作業するデータに着手する時は、開始基準の設定に多くの時間を費やすようにしています。例えば、トレーニングに要する時間や相互チェックの実施方法、頻度を事前にお客様と相談して決めておく必要があります。
| トレーニングに要する時間 | どれくらいできればよいか どこまでやるか |
| 相互チェックの実施方法 | 全量チェックか、サンプリングチェックか どのくらいの頻度でやるか |
これらを考慮せずに作業を進めてしまうと、予想以上に工数がかかったり、手戻りが発生したりしてしまうという大変な思いをしたことがありました。
作業を円滑に進めるためには、開始基準を明確化し、お客様としっかり連携を行いながら、チーム内の情報共有を行うことがとても重要であると、毎回実感しています。
応用事例２「工数に影響する要因（人の特性）」の応用
ソフトウェアテスト教科書には、このように記載されています。
💡 テスト工数に影響する要因（人の特性）
テスト工数を見積もるためには、テスト工数の見積りに影響を与える要因を知っておく必要があります。考慮もれによるテスト工数の見積り誤りを防ぐためです。 見積りに影響を与えるものとして、テスト対象であるプロダクトの特性、開発プロセスの特性、人の特性、テスト結果などが挙げられます。
人には得意分野や不得意分野があり、それぞれの能力や実力には個人差があります。そのため、実際の作業に入る前に、各メンバーが十分にトレーニング期間を設けて、各メンバーの能力と実力を正確に把握することが必要となります。
各メンバー同士も作業に必要なスキルや知識を共有できますし、作業管理者も各メンバーの能力と実力に合わせた作業分担やスケジュールを立てられるようになります。
以上のように、工数に影響する要因として人の特性を把握することが、工数見積りの精度向上につながる重要な要素であると、毎回実感しています。
応用事例３「欠陥マネジメント」の応用
ソフトウェアテスト教科書には、このように記載されています。
💡 欠陥マネジメント
欠陥は、検出時点から分類、修正、最終確認まで、きちんと追跡しなければなりません。その対策が終了するまでマネジメントできなければなりません。
欠陥をマネジメントするためには、発生したすべての欠陥を記録しなければなりません。
アノテーションミスを見つけることは重要ですが、それらをきちんと管理していかなければなりません。以前は適切に管理できておらず、記録が見つからない、同じ失敗を繰り返すなんてことがありました。今は記録を取り比較することで、優先順位を付けられますし、ミスの記録を参照することによって、将来的なミスの予防につなげられるようになっています。アノテーションミスの記録を残し活用することがとても重要であると、毎回実感しております。
以上、応用事例を３つ紹介しましたが、ソフトウェアテストプロセスを応用することで、 作業の効率が上がり、他の作業に割ける時間が増えるなど、様々な効果が生まれました！ 同時に、「学ぶことは模倣から始める」ということが大切であるとひしひしと感じました。
おわりに
最後になりましたが・・・
今のプロジェクトをよりよいものにしていきたいという思いから始まった挑戦
☝ ソフトウェアテストプロセスの他分野への応用
「学ぶことは、模倣から始める」 「物事の上達は、模倣にあり」
うんうん、模倣だっていいさ。
まずは、模倣してみることから始めて改善に役立てたいと考え、ソフトウェアテスト教科書を読み込んで、とことん模倣してやろう！という気持ちで改善活動をスタートしました。
この改善活動によって、ソフトウェアテストプロセスとの類似点があるという新たな気付きや、模倣から始まり改善に役立てたという新発見をもたらしました。そして、応用事例で紹介したように様々な効果が得られ、業務改善に役立てることができました。
今回の学びは、ソフトウェアテストプロセスの中から、模範となるものを見つけて、そこから模倣して、改善に役立てるのが、私にとってプロジェクト成功への近道であるとわかったことでした。
教科書は読んで終わりではもったいないです！！
ソフトウェアテストプロセスの良いところを模倣して、改善活動してみませんか？ ひょっとしたら、ビジネスだけではなく日常生活シーンでも改善に役立って、心豊かな生活のヒントをもらえることがあるかもしれませんよ！？
今回の活動を通して、「他分野へのソフトウェアテストのプロセスの応用」が利くということがわかりましたので、今後も試行錯誤を繰り返しながら改善活動を継続していきたいと思います。
皆さんもぜひ、模倣から始めて、新しいことに挑戦してみてはいかがでしょうか。
追伸
2月末、JSTQB認定テスト技術者資格 Foundation Level試験を受けてきました～さて、結果はいかに！？
次回、試験結果・・・それとソフトウェアテスト経験が浅い私の勉強の進め方も紹介するので、お楽しみに♪
