続々 いいテストエンジニアになるには ～テストエンジニアの七つのムダ～ 前編
こんにちは。SHIFTにて社内メンバーの能力開発をしている、タカハシです。前回からだいぶ時間が経ってしまいましたが、、、シリーズ『いいテストエンジニアになるには』の、続編かつ完結編、の前編です。
はじめに
一本目は、「教師は五者たれ」にかけた、テストエンジニアの五者論を述べてみました。
二本目は、「プログラマーの三大美徳」にかけた、テストエンジニアの三大美徳を述べてみました。
三本目の今回の数字は「七」です。
みなさん、「七」と言えば何を思い浮かべますか？
七つの海？
七つの大罪？
七つの習慣？
・・・（まあ、タイトルで答え出てるいのですが）
迷いましたが、SHIFTはもともと製造業向けの業務改善コンサル。
やはりこれにします。
七つのムダ。
トヨタ生産方式で有名な、付加価値を生まないムダ、ですね。
一、加工のムダ
二、在庫のムダ
三、造りすぎのムダ
四、手待ちのムダ
五、動作のムダ
六、運搬のムダ
七、不良・手直しのムダ
です。
今回もまた、テストエンジニアの世界に置き換えて考えてみます。
一、加工のムダ
加工のムダ
テストにおける加工とは何か
加工のムダとは、必要以上の仕上げ作業や、本来不要な検査、加工しなくてもよいものを加工することを言います。
例えば、
・エビデンスを必要以上にきれいに整える、
・テストするうえで必要以上のデータを準備する
・無意味なダブルチェック
など、最終成果物やテストの結果には影響が無い（顧客がそこまで求めていない）にもかかわらず、細部にこだわりすぎた加工（作業）はムダです。
もちろん、神は細部に宿る、とも言いますし、細かさ・マメさは大事な要素ではありますが「必要以上に」というのがムダポイントです。
ゴールや目的、顧客が求めているものを必ず意識しましょう。
求められている以上の細かさは、ただの自己満足かもしれません。
二、在庫のムダ
在庫のムダ
テストにおける在庫とは何か
全ての在庫にはそこに存在する理由がないといけません。
その理由がない在庫はムダであり、不要な在庫には不要なコストが発生します。
テストで言えば在庫は「課題」、でしょうか。
そしてそれが放置されることが、不要な在庫と言えるでしょうか。
テストで生まれる主な生産物に、不具合や課題（起票やチケットと呼ばれることも）があります。
え、課題の対応（バグ修正等）をするのは開発者でしょ。
テストエンジニアは関係ないじゃん。
と、思われましたか？
もちろん、課題に対応するのは一般的には開発者であり、また、課題が滞留しないように適切な課題管理をするのはPMの責任かもしれませんが、その在庫（起票）を作ったのはテストエンジニアですよね。その生産物にはきちんと責任を持ちましょう。作って（起票して）終わり、ではありません。
必要性がない在庫を作る（起票する）のは論外ですが、それがすぐ流せるように適切な起票をしておく（つまり、放置されたり、開発者が読み解くのに時間がかかったりするような起票は不適切）、また、不具合等が対応されて戻ってきたらすぐ消化する。そういった、課題（在庫）が滞留しない仕組みづくりに貢献するべきです。
テストエンジニアは不具合を見つけることだけが仕事なのではなく、テスト及び課題解決を通して品質の良いシステムを作り上げることの一翼を担っていることを意識しなければなりません。
三、造りすぎのムダ
造りすぎのムダ
テストにおける造りすぎとは何か
テストのやりすぎ、ですね。
テスト設計で不要なテストケースを作ってしまう、または、テスト実行時に不要なものまでテストしてしまう、といったところでしょうか。
もちろん、より良いテスト、より品質を高めるために、当初予定にはないが追加でテストを行う、ということはあります。
ですが、ここで言いたいのはそういう前向きな理由での「やりすぎ」ではなく、
・前の案件ではやったから（前例踏襲しておけば間違いないですよね？）、
・標準資料にあるから（意味はよく分かっていないですけど、削っていいか分からないので）、
・足りないよりは過剰な方がいいかな（少ないと怒られるからとりあえず）、
といった、よく考えられていない、理由がない「やりすぎ」のことです。
事例や標準化を使うのは効率化という意味では大切なことですが、それをはき違えるとムダが生じることがあります。標準化は、省力化や、経験が少ない人でもある一定水準以上の品質を保つことができるためのものであり、いついかなる時も、思考停止してそのまま適用すればいい、というものではありません。
SHIFTで考える良いテストケースの条件には「必要最小限であること」が含まれています。ただやみくもにやればいいわけではなく、また、不用意に削りすぎることもなく、必要性（実際にはコストとの兼ね合いも重要）を説明できるテスト設計を行いましょう。
四、手待ちのムダ
手待ちのムダ
テストにおける手待ちとは何か
ここはテストの世界でもそのままですね。
手待ちは何も付加価値を生まないので、分かりやすいムダの一つです。
では、どういうときに手待ちになってしまうのか。
多くは準備（段取り）の不備・不足によるものだと思います。
・テスト実行者をアサインしたのに、テスト環境や設計書が出来ていない
・不具合等でテストを先に進められない
など、作業が進められない状況が手待ちを生みます。
もちろん、自社だけでは解決できない理由の時もありますが、それでもやはり一歩、二歩先を見据えて、準備をしておくことが望ましいでしょう。
作業の順序を変える、もしくは別のタスクを実施するなどして手待ちを防ぎましょう。
なお、言わずもがなですが、手待ちにならないように作業スピードを調整する（つまり遅くする）などというのは、もっての外です。
本来手待ちになるはずの状態が隠れてしまうので、さらに問題ですね。
手待ちが発生しそうなら、速やかに管理者等に報告しましょう。
常にコストと付加価値を意識することが大切です。
さて、七つもありますので前編はこの辺にして、「動作のムダ」「運搬のムダ」「不良・手直しのムダ」は後編とします。
★このライターの他の記事を読む
いいテストエンジニアになるには ーテストエンジニアの五者論ー
続 いいテストエンジニアになるには ―テストエンジニアの三大美徳― 前編
続 いいテストエンジニアになるには ―テストエンジニアの三大美徳― 後編
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
執筆者プロフィール：髙橋 朋裕
SIerにてSEとして、主に民間企業向けのシステム開発やパッケージソフト開発を経験した後、2019年にSHIFTに入社。
SHIFTでは、SHIFTグループ社員の人材育成を担う能力開発部門に従事している。主に社員の受入教育を担当しており、年間1000人の新卒・中途社員研修を一手に引き受けている。
■メディア掲載情報
https://www.shiftinc.jp/media/
■SHIFTについて
私たちは品質保証とソフトウェアテスト（第三者検証）のプロ集団です。
《NEW!!》資料ダウンロード／動画視聴ページはこちらから
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/