プレリリースプログラム起点の品質改善 - ドキュメントテスト編

こんにちは、アドビ株式会社研究開発本部で Quality Engineer をやっている@YusukeKikutakeです。
本記事では、アドビの Quality Engineer がアドビ製品の品質向上にどのように関わっているかを紹介したいと思います。今回は、プレリリースプログラムの問題報告から始まった品質改善の話をしたいと思います。

はじめに

まず、私は 3 年前にアドビに入社し、Adobe InDesign, Illustrator, XD といった開発プロジェクトにアサインされてきました。入社前は日系企業で QA マネージャーをしたり、外資系企業では 10 年以上勤務し QA リードとして日本語だけではなく多言語のテスト計画、設計、実施を担当しておりました。当時はアドビ同様に US に本社を持つ会社に勤務していましたが企業向けアプリのみを開発・販売している会社でした。新機能や機能拡張のフィードバックは定期的に実施される顧客とのレビューで収集することがありましたが、その顧客は主に US 企業で日本ではあまり重要でない機能についての議題も多かった印象があります。このことから、どのように日本のお客様の意見を聞き、魅力的な品質を届けるためにはどのようなテストをすればよいかといった課題を持っていました。

プレリリースプログラム

入社してまもなく、アドビにはサポートコミュニティだけではなくプレリリースプログラムという、デザイナーや開発者など様々なバックグラウンドをもつ経験豊富なお客様に参加いただき、リリース前の製品に対するフィードバックをもらう場があることを知りました¹。また、プレリリースには参加しているお客様の意見や問題をまとめて製品チームに報告する プレリリースコミュニティ―マネージャー(以降 PCM と表記) という役割の方がいて、その方の活躍によりプログラムの運営がスムースに行われています。今までは様々な使い方をしているお客様の意見を収集することにさえ苦労していたので、なんてありがたいプログラムなのだろうと率直に思いました。

私の入社は 8 月でしたが、アドビでは 毎年 10 月に行われる Adobe MAX というイベントに合わせてメジャーバージョンがリリースされます。そのため、入社後は大忙しでした。プレリリースプログラムでは、MAX 後にお客様アンケートを実施し、PCM が結果を分析して私や製品チームに共有します。これにより、お客様からの良い意見も悪い意見も幅広く目にすることができました。Quality Engineer としての通常のテスト業務はありますが、こういったアンケートをもとに、お客様の意見を製品に反映させ、信頼を獲得し、満足度を上げるためにはどのような品質改善が必要になるかを考えるのも私の仕事です。

最初の改善

私の部署では製品によって、PCM との定期的なミーティングを実施しています。私は開発側の情報共有をし、PCM からはお客様からの問題共有があります。
そこでの報告に、従来からアドビのユーザーガイドといったオンラインドキュメントに、

• 誤訳や文法エラー
• ドキュメント内の用語がソフトウェア UI の用語と翻訳不一致があり操作に混乱が発生
• リンク切れやリンクの飛び先の誤り

といった問題の報告がありました。

当たり前品質

さて、テストの仕事は基本的にテスト計画や設計をしてあらかじめやることを決定してから実行しますが、リソースは有限なのですべてを実行することはできず、かつどこから手を付けるべきか、優先付けが必要になります。グローバル展開している企業では、オンラインドキュメントを機械翻訳して掲載しているだけの企業もありますし、ソフトウェアの品質を最優先にして、ドキュメントに対する品質は優先されないという話を聞くことが多くあります。ただ日本企業ではどうでしょうか。恐らくドキュメントの品質にも力を入れていると思いますし、それが当たり前だと思います。

品質管理の業界では、「狩野モデル」という品質と顧客満足度の関係を表したモデルがあります。当たり前のことが実施されたとして当たり前なので顧客満足度は上がりませんが、実施されないと顧客満足度は不満足になる傾向になることがわかっています。他国で重視されずとも、日本のお客様に対する顧客満足度を考えた場合、ドキュメントテストは必須と考えるべきなのでは考え、テスト計画や他チームとの調整を行いました。

テスト計画・設計

次にドキュメントテストといえど、テスト計画と設計をきちんとやります。ドキュメント内のコンテンツすべてを細かくテストする余裕はないため、アドビ内のドキュメントプロセスの理解や、現状のドキュメントの品質調査、かつプレリリースからの報告を参考に、テスト対象の選定²、テスト項目の決定³、テストスケジュール、バグの報告方法といった必須項目をまとめます。また、今後他のメンバーがテストするときにテスト結果にばらつきが発生しないよう、ドキュメントテストプロセスを標準化し、見える化を考えながら Wiki にまとめ関係者に共有しました。

他チームとの調整

さて、テスト計画・設計は終わり、実行するために他チームとの調整や連携が必要になります。アドビではドキュメントの翻訳は協力会社である翻訳会社が実施していることから、修正も協力会社が対応することになっています。

1 つ残念だったのが、本来ドキュメントは公開前にレビューや問題の修正が行われるものですが、協力会社の作業とのコンフリクトや、問題修正による公開遅れを引き起こすため、ドキュメントテストは公開後に実施してほしいとの意見があり、これは不本意ながら承諾することにしました。現在ドキュメントテストは、公開後に実施し、問題報告を行っています。協力会社の作業状況によりますが早ければ数日で問題が修正されページに反映されます。

テスト実行

実際のテストですが、テストプロセスを決めているため、テストの進め方をどうすればよいかといったところに労力を使わなくてすむため、迷うことなく実行できます。手動でテストを実行しており、ただこつこつ対象ページに対してテスト実行、バグ報告、修正確認の繰り返しです。

テストをしながら思ったことが、はじめは製品知識のない人でもこのテストが実行できるようプロセスの標準化を整理しましたが、ソフトウェアとドキュメント間での翻訳不一致を見つけるには、新機能を理解していて、かつ当然アプリ側の操作確認が必要になるため、ある程度製品に精通した人ではないと効率的にテストが実行できないということが改めてわかりました。

テスト評価

バグの数を製品やバグの分類ごとにカウントし、バグ曲線を描いたり、バグの傾向を調べ、今後改善につながるアクションを検討します。ドキュメントの品質は決して翻訳者のスキルに依存するわけではなく、

• 原文の英語が正しくフォーマルに書かれている必要
• 翻訳スタイルガイドをわかりやすく改訂したり理解してもらう
• 用語集の登録
• 翻訳メモリーのクリーンアップ

といった作業が翻訳不統一の改善につながることがわかり、現在一部アクションにつなげています。

まとめ

以上、プレリリースプログラムの問題報告からはじまった品質改善の取り組みの 1 つを紹介しました。お客様の報告に感謝しつつ、魅力的な品質を届けられるよう引き続き品質改善を行いたいと思います。その他にも翻訳品質改善、翻訳修正からビルドに取り込まれるまでの時間短縮などの取り組みがあります。機会があれば、ブログで紹介したいと思います。

また、私の所属するアドビ株式会社研究開発本部では、通常の日本語ロケールの製品テストや、先日公開されたばかりの「InDesign で修正された日本語翻訳」のページ公開といった取り組みも主体的に行っています。

本記事で紹介したプレリリースプログラムの参加方法ですが審査はありますが、参加の申し込みはこちらからできます。


最後までお読みいただきありがとうございました。

1. すべてのアドビ製品や言語で実施されているわけではありませんが、アドビの主要な製品に関しては日本語プレリリースプログラムが設置されています。 ↩

2. 主なテスト対象ページはリリースごとに追加・更新される「修正済みの問題ページ」と「新機能ページ」に限定。過去のページは問題の報告があれば対応するが、膨大な量のためテスト対象外とした。現在テスト対象製品は InDesign、Illustrator、Illustrator on iPad。 ↩

3. テスト項目は、1.翻訳の正確さ、2.ソフトウェアとドキュメント間での翻訳不一致、3.リンクエラーの 3 つにフォーカスし、英語版と日本語ページの不一致や、ブラウザや OS の違いにより発生する表示上の問題などの項目はテスト対象外とした。実際のテスト計画書ではテスト対象、対象外を細かく定義しています。 ↩