「他業種に学ぶ」カテゴリーの「翻訳者として伸びる人、伸びない人: 自分と翻訳を切り離せてますか？」という記事では、ソフトウェア開発の現場の話を通して翻訳の現場を客観的に眺められないかということを試してみました。
どうやら、QAというフェーズに、本来負うべきではない過剰な役割が期待されてしまうのも、翻訳とソフトウェア開発の現場で共通する問題のようです。
体重計に乗ったとしてもその人の体重が減らないのと同様に、テストをすることが、ソフトウェアの品質を改善したりしません。テストはソフトウェアの品質レベルを知る手段ですが、ソフトウェアの品質を保証する手段ではありません（スティーブ・マコネル『ソフトウェアプロジェクトサバイバルガイド』）。
体重計に乗ることにより、体重が減る効果はゼロです。つまり、何回体重計に乗っても体重は減りません。単に体重がわかるだけです。ソフトウェアのテストでも同じであり、単にソフトウェアの品質がわかるだけです。
スティーブ・マコネルの孫引き部分も含めてこちらの本からの引用です。
技術評論社
売り上げランキング: 386,743
実際には、テストによって品質を上げていると思われるかもしれませんが、そうではないのです。体重計に乗っても体重は減りませんが、自分の体重を知って、ダイエットや運動などをすることで、結果として体重が減るのです。
同様に、ソフトウェアのテストにより、ソフトウェアの品質が分かり、多くの悪い部分（つまり不具合）を発見して、それらの悪い部品を改良する（つまり、不具合の原因であるバグを修正する）ことにより、結果として品質が向上するのです。
そして、もう一つ、QAの主たる目的をスコアの測定に置くうえで重要なのは、納品物の品質は定められた「要件」に対して測られるべきであり、「完璧さ」に向けてなされるべきではないという点だと思います。
ビジネスとして実行できる品質保証は、欠陥をゼロにすることが目的ではなく、欠陥率を一定の割合以下（たとえば千、三つ）に抑え込むことのはずです。
さらにもう一点重要なのは、翻訳プロジェクトを管理するPMが、スコアが一定以下のときに取りうる打ち手を確保しているか、また初期段階からこまめに品質チェックを行っているかという点です。
特に、プロジェクトマネジャーが、「機能が正しく作りこまれてコーディングされていること」よりも「最初に決めたコーディング期間が予定どおり終了すること」を優先したプロジェクト管理を行うと、コンパイルが終わったというだけで、 機能を全部正しく作りこんでいなくても「コーディングが終わった」と担当者は報告しがちです。
この「納期優先」の感じ、どこのローカライゼーションの現場やねんというくらい既視感があります。
以前に上のような記事を書きましたが、特に、これから増えていくであろう、ノンネイティブのPMやクライアントが自分自身で納品物の品質を測定できない状況では、「スコアを出す」し全員で共有するというQAの役割が大きくなっていくと思います。
そうした中でのやり取りで、「QAは品質を測定するけれど、改善するためのものではない。改善できたとしても微々たるもの」であるとか、「Q（品質）、C（コスト）、D（納期）は相関してるから、このQの設定で対応できるのはここまで」だとか、翻訳者の側でもきっちり主張できることが大切になってくるのかなと思っています。
