品質系社員の現場からのビジビリティー、存在感向上＝成果の見える化のアプローチ

僕がある独立系ベンダーでテスターとしてブイブイ言わせてた頃にお世話になった先輩から、面白いご相談を頂いたので、30分ぐらいで書きなぐった回答（特定可能な部分は改変）。

1. 品質コストから考える 要するに：ビジネスにばっちり貢献してるんですよ

まず実際にバグが出せているか？出せているなら、そのバグがもし市場にそのまま出ていたら、どれぐらいの損失（クレームに対して全社が動くコスト＋ブランド失墜の回復コスト）が発生していたかを推定してみる。それはおそらく利益を簡単に食いつぶしていたはず。このとき、絶対に開発チームを責めない。高度なこと、複雑なことをやっているならバグがでるのは当たり前。多様な価値観に基づいてそれに反する事象を探索するのはテスターの仕事。

品質コストには、予防コスト、検出コスト（テスト）、内部失敗コスト（社内で修正できた）、外部失敗コスト（流出した）の4つがあり、テストをする動機は、外部失敗コスト＞予防コスト＋検出コスト＋内部失敗コスト　だから。単に「儲かるから」やる。ただし、外部失敗が許される製品についてはリリース時ではなく、利用時に品質を向上できるような品質方針＝サービスの可用性、データ破損、セキュリティにリソース全振り を取ることが多い（代表的なのはGoogle、Amazon）。

2. 技術力から考える・テスト技術編 要するに：ちゃんとテスト設計しているならその成果物は技術的にも認められる

ちゃんとテスト設計をしているなら、テストエンジニアがどんなことを考えてテストしているのかを成果物としてチーム全体で共有する。製品や機能、マイルストーンに向けて達成すべき品質と行うべきテストの地図や、機能テストを設計するうえで作った「モデル」（例えばデシジョンテーブルや状態遷移図、テスト観点マトリクスや、CRUDとエフェクトを整理した図、などなどなど）があるはず。モデルを書いてそれをどう効率的に網羅するか？という機能テストの設計はすさまじく創造的で、プログラマからみても芸術的なはず。

実際に、ある処理系のテストを設計するときに浮動小数点の仕様（IEEE754）における数の扱いをクラス分けして利用シーンとの影響で整理した図を書いてレビューを依頼したところ、開発側のエキスパートがえらく感動してくれました。

3. 技術力から考える・CI/CD編 要するに：開発チームに親和性の高い部分で貢献する

CIシステム＋自動テストの開発と運用をテストチーム自身が行う。CIシステムの重要性は開発チームが嫌ってほどわかっているはずだけど、CI/自動テストはある種”サービス”なので、ちゃんと運用するのは難しい。自動テストが伴っていなければ片手落ちなので、いっそテストチームが運用しちゃう。SCMを握れるので、コードメトリクスなんかも絡めて内部品質（保守性）も自動的・PerCommit で診断できるようになるとさらにカッコいい。

4. チームの成長から考える 要するに：プログラマに対するコーチになる

テストチームが発見したさまざまなバグやそのバグが発生する過程を、バグレポートを通じて開発チームが学ぶことで、次のリリースに向けて少し賢くなっている。この少し賢くなるを繰り返すことで、チームがどんどん成長していく。市場からフィードバックも得られるが、概して市場は「遅い」。きちんと学んだ品質エンジニアであれば、開発プロセスやテストプロセスのどこをどう変えるとチームが成長できるか（例えばシステムテストで数値計算のバグが出ているようなら単体テストを教える、コードレビューに同席して生産性を高めるためのファシリテーションをする、製品の品質ゴールに対してリーダーシップを発揮できる、など）を設計できる。テスターの究極の到達点は「コーチ」。プログラマがプロフェッショナルであるなら、優れたコーチの価値を認める。