QCは”全員の自分ゴト”。組織改革が生んだ、品質向上の仕組み化

私はQC活動全体の推進や調整を担う立場として、個別のグループには所属せず、サービス開発部に身を置いています。役職としてはQC（品質管理）Service Leadです。なお、担当名で使う言葉はQCではなくQAとしています。ややこしいですが「QAエンジニアが、QCを担当している」というのが現状ということになるでしょうか。

テスト内容には、チェックの質や量にどうしてもバラつきが発生しますから、グループを超えてそれを統一していけるように、レビューやドキュメントの整備、新規参画者への教育などを手がけています。

現在Productivityグループに所属し、システム全体を通して行うE2E（End to End）テストや、性能検証で利用するデータセットの設計、各種性能検証の実施などを行っています。

また、他のメンバーが躓かずにテストが実施できるよう、QAエンジニアの育成にも携わっています。

私はオペレーショングループに所属しています。社内で発見される各機能のバグだけでなく、新機能リリース後にお客様からのご指摘で発見される「市場バグ」に対して、漏れなくテストを行って問題を取り除くのがメインの業務ですね。

また、最近はProductivityグループと連携して、修正や新たな機能開発によって別の箇所にバグや不具合が起きないよう、デグレードを防止するためのテストケース作成も行っています。

ディレクターとして新機能の企画・開発のプロジェクトマネジメントをする中で、機能のリリースに向けて、所属しているEmployeeグループのQAエンジニアに直接依頼をして、コミュニケーションを取りながら品質テストを進めています。

所属の違う堀内さんと渡辺さんにも、新たなテストケースを作る際に内容のチェックをお願いしたり、どういった観点でテストをすべきかというアドバイスをいただいたりしています。

15年ほど前の新卒の就活中からQAエンジニアに興味がありました。

というのも当時、ITエンジニアの求人は増えていたものの、オフショア開発で東南アジアに開発業務が委託されたり、ITエンジニアの過酷な労働状況からネット上で「デスマーチ」と言われたりしていて。

近い将来、その多くが海外に出ていくのではないか、と感じました。そこで、できるだけ珍しいスキルを身に着けて日本に残れるようにしようと考えて、面接時に「QAエンジニアをやりたい」と伝えたら「すごく珍しいね」と言われたのが記憶に残っています。

僕の見立てでは今頃、日本にITエンジニアがほとんどいなくなっているだろうと思っていたのですが、実際は全然そんなことないですね（笑）。

もともとWebデザイナーを目指し、HTMLコーディングや画像の切り出し、加工といったアルバイトをしていました。そんな中、勤めていた会社でシステムの検証業務をたまたま担うことになり、やってみたらけっこう褒められたんですよ（笑）。

その会社では、実際に検証業務を専門にした先輩がいて、開発というよりも「検証一筋」でやっているのが、私の眼にすごくかっこよく映りました。他にライバルもいなかったので、その道を目指してみようと決めたんです。

私はゲームプランナーになりたくて新卒でベンチャー企業に入社し、ソーシャルゲームやブログサイトなどの企画をしていました。でもこれらの仕事は、どちらかというと「0から1を作り続けていく」ような進め方で、自分には向いていないと感じていたんです。

そうした中、たまたま見つけたQAエンジニアの求人になんとなく興味が湧いて。転職はうまくいったものの、正直、何もわからないままキャリアがスタートしました。

そうですね。そして私の場合、実際にやってみると、「プロダクトに対しこういう関わり方が、自分にはすごく向いているかもしれない」という発見があり、やりがいをどんどん感じるようになりながら今に至ります。

QCを本格的に始めた頃は、実施すべきテストに抜けや漏れが生じてしまうこともありました。これはどこの企業でも、まず最初にぶつかる壁だと思いますが、ナレッジの蓄積や改善の繰り返しで、ある程度はカバーできるようになってきています。

次にぶつかるのが、逆に「サービスに不備があってはならない」という気持ちから必要以上にテストを増やしてしまうことです。私たちも1年前ごろ、その傾向にありました。

しかし本来、プロダクトや組織が大きくなったからといって、その分だけ手数を増やす必要はないはずです。むしろ技術と経験によって、テストを効率良く、最小限に留める方向に進むべきではないでしょうか。

最近ようやく、適切な箇所に必要なだけテストを実施し、サイクルを素早く回していく動きへと、QAエンジニア全員の意識がシフトし始めました。

サービスが大きくなり、携わる人が増えていけば、どれだけテストをしても多少のミスが生じてしまうのは仕方がないことです。それよりも、起きてしまったことに対し、いかに素早く周知して対応できるか、そして繰り返さないための改善ができるか、が重要です。

その一環としてProductivityグループで始めたのが、インシデントを防ぐためのE2E（End to End）テスト実装です。

E2Eテストを自動化し、私たちの工数をかけることなく最低限の検証を実施できるようにしているんです。

機能が追加・改修される度に手動で全体をテストするのは、膨大な時間がかかります。そのため、リリース候補ブランチとリリース直前ブランチを対象に、自動化したE2Eテストを実行しています。将来的には、性能検証の部分まで自動化を広げていく予定です。

開発担当者全員に対して、テストの流れや技法を伝えました。QAエンジニアでなくてもテスト実施まで行えるような状態を目指してのことです。思っていたよりも、モチベーション高く取り組んでもらえました。

その後、QAエンジニアは各グループに専属となったので、全員がテストを行う形ではなくなっています。ですが、検証は以前より明らかにスムーズにできるようになっているんですよ。テスト関連の知見や情報を共有したことで、グループ内の品質への意識が向上した結果、効率的に進められるようになったというわけです。

当社では、人に依存しない仕組み化を目指しています。そのため、情報共有ツールにConfluenceを活用しており、社内で「既存仕様がどこにも書かれていない」「誰に聞けばいいのかわからない」といった事態はほぼありません。内容を最も深く理解しているQAエンジニアが必ず書き残すよう、フローを整備し、執筆ルールを定めています。

常に最新の仕様が記録されているのは、他企業と比べても胸を張れる点だと思いますね。

今回の組織改革は、アジャイルな開発組織に向けてマイクロサービス化を推進し、各チームで要件定義から開発、テストまで完結できるようにするという大きな動きの中の一つの取り組みでした。

グループ内にQAエンジニアが入ることで、テストに対する意識が芽生え、全員が品質保証を自分事として捉えられるようになりました。

以前までQAグループは独立していたので、私を含め「テストはQAグループが頑張るもの」という認識でいたところがあります。

そのため新体制に移行した直後は、一時的にテストの品質が下がり混乱した部分もありました。

しかしそういった経験を経て、ディレクターや開発エンジニアも、真剣にテストに関わっていく必要があることに気づきました。

お客様に何を届けたいのか常に考えるディレクターだからこそ「ここにバグが起きてはダメだから重点的にテストする必要がある」と気づいたり、開発エンジニアだからこそ「実装上この処理は重くなりやすいから性能テストが必要かも」とわかることがあります。それぞれの目線で積極的にQAエンジニアとコミュニケーションを取ることで、グループ全体で品質管理を行えるようになりました。

みんなが「当たり前品質」を意識し、「魅力的品質」に注力できれば、よりよいプロダクトになります。そうなるとQAエンジニアは、QCだけでなく、プラスαで開発やテストの自動化、プロジェクトマネジメント、お問合せ対応などの付加価値が求められるようになっていくでしょう。

各グループにQAエンジニアが配置されているため、横のつながりが希薄になっています。QCの知見をお互いに共有できるよう、自分から情報を拾いに行ったり、わからないことがあれば相談できるコミュニティの形成は今後必要になっていくと思います。

一見、品質管理は地味に思われがちですが、どんなに高機能なサービスでも頻繁にサービスが停止したり、品質管理の観点で機能リリースの遅れが続けば、お客様からの信頼は得られません。今後もこれまで以上に全員が品質管理の意識を高めていくことが必要不可欠です。

私たちは、QAエンジニアだけでなく、グループ全体で品質管理を重視しています。そういった活動はあまり認知されていない部分ではありますが、私たちの活動を知ってもらえれば今まで以上に「カオナビ」について、多くの方に「安心感」を与えられると信じています。