以前に韓国の大手電子会社から依頼するコンサルに参加したことがあります。厳密に言えばそちのDTV(Digital TV)のQチーム(そこでは品質管理チームをこうよんでいます)から依頼をもらったので依頼の主な内容は
「テスト・プロセスの効率化を通じてテストの業務量を減らす」
のです。
インタビューなどを通じて状況を見るとDTVの様々な新型モデルは大勢にQチームに押し寄せてますが10個以上の開発チームを１チームが担うのが大変なので日程遅延などがよく発生するそうです。
我が「コンサル・チーム」が出した解決案は「Early Testing(初期てすと)」でした。これのために開発チームのごとにQチームのメンバーが参加して設計段階から参加すべき。これが主な報告書の内容でした。
今考えるとそれは失敗のコンサルでした。報告書が採択されなかったからです。振り返るとその方法は次のリスクがありました。
１。開発チーム：品質チーム（Qチーム）の比率が多：１。
２。開発初期に参加できるような関連知識の低さ。
特に１番目は当時の結論にたいしてとっても大きいハドルでした。品質メンバーさんが数多いな開発ミーティングなどで参加する余裕が全然ありません。２番目は何とか教育で解決できそうと思います。
この解決案が「初期テスト」であれば品質チームが単独にできる役割が狭いので不可能です。開発サイクル中でこの「初期テスト」が進行されるべきですが組織仕組みの問題でそれができなければ開発メンバーがやるべきです。もし開発者がこんな活動が負担されたら別のテスト専門メンバーを雇ってそのメンバーが開発サイクルないでテストをすべきです。
もしこうすると品質チームの役割がなくなるかと思う人がいるかも知りません。今私の考えは品質チームの役割は「最終チェックリスト」の遂行と「開発チームのテスト結果の十分さのチェック」です。開発からもらうテスト結果の十分さを検討し、最終チェックリストをチェックしてリリースすれば改善ができるかな。そのため開発とテストは分離されるのではなくて一つのサイクルで運営しなければならないし最終チェックはそのならではの役割を再定義すべきです。
当時上のようなことを考え出せなかった理由は僕の能力レベルが低かったからかもです。上の話は如何に「仮説」ですので「こうしてください」などは言えません。
でもこの間スタートアップスとかIT企業を中心で今までの話に近い方法で運営する開発チーム長をよく見ています。開発メンバーが開発し、テストコードを下請けする場合もあったし（もちろんリリース前にチェックリストでリリーステストは行います）開発メンバー自分でテスト＋自動化をする場合もよく見てます。最初のDTVケースはHW中心なので適用するにはちょっと組織的な問題がありそうです。
結局テスト・プロセスの改善するためには何か組織的な変化がもたらさなければならないです。開発＋テストの方向で行くのが正しいと思います。