Facebook x

ジャンル

第20回 隣のQAに聞く
隣のQAに聞く 2024.01.22
x hatenabookmark

「ソフトウェアにおける品質保証は、製品の開発が続く限り終わらない改善活動」株式会社リクルート 内藤 史郎 氏

執筆: Qbook編集部

ライター

「ソフトウェアにおける品質保証は、製品の開発が続く限り終わらない改善活動」株式会社リクルート 内藤 史郎 氏

様々な現場でQA業務に携わっている方々の「声」をお届けする『隣のQAに聞く!』。社会のデジタル化が急速に進み、教育現場ではタブレットやパソコンなどを利用したネット環境下で勉強を行うオンライン学習サービスの普及が進んでいます。

株式会社リクルートが運営する『スタディサプリ』は、小学校高学年から大学受験生まで、実力派講師陣による4万本以上の講義動画を利用することができるオンライン学習サービスです。個人の利用はもちろん、高校を中心に自治体や学校単位でも活用されており、現在は全国の高校2,109校で導入されています。(2023年3月末時点)

日本のオンライン学習サービスをリードする同社では、どのようにQA組織が運営されているか、気になるエンジニアの方も多いのではないでしょうか?そこで本記事では、同社の内藤史郎さんにQAのミッションやQA組織を動かすポイントをお話しいただきました。

今回インタビューを受けてくださった方

231121_face.png
内藤 史郎 氏

株式会社リクルート

キヤノン株式会社、楽天グループ株式会社での品質保証担当の経験を経て、2020年にリクルートへ入社。現在は『スタディサプリ』の品質保証を担当している。

もくじ
  1. 自分らしく学び、生きられる世の中を実現する
  2. 目的を言語化して繰り返し伝えることで組織に文化が定着する
  3. 悪い意味での「品質の門番」にならないことが大切
  4. 自分が情熱を持って改善に挑み続けられるかどうか

自分らしく学び、生きられる世の中を実現する

リサイズ②.png

――はじめに、QA業務に携わるようになったきっかけを教えてください。

最初は社内SEとして商社で開発の業務をやっていました。しかし将来のことを考えた時に一般的なIT+αで専門性を身に付けたいと思いまして。ちょうどその頃、某企業のシステムトラブルが大きなニュースになっており、「あれはなぜ起きているのだろう」と興味を持って調べていたときに、ソフトウェアの品質保証ということ専門職を知り興味を持ちました。
そのタイミングでソフトウェア品質保証を体系的に学習してJSTQBなどの資格を取り、QA業務に携わるようになりました。

社会人2年目までは独立度の低い開発の中での開発・品質保証の毛色が強かったと思いますが、その後は徐々に独立度の高い品質保証を行なってきました。
経歴は大きなところでいうとキヤノン、楽天、リクルート(『スタディサプリ』)にて比較的大規模なプロダクトを経験しています。

キャリア的な話をすると大規模な開発のみに従事していた印象を持たれることが多いのですが、実はそれだけではなく、セキュリティソフトやドライバなどの小規模なミドルウェアに対する品質評価業務にも従事してきました。

――現在、リクルートで担当されている事業・サービスについて教えてください。

我々は「EdTech」に位置付けられる教育アプリケーションを開発していて、私は国内向けに『スタディサプリ』海外向けに『Quipper』と呼ばれるオンライン学習サービスの品質保証の業務を担当しています。

『スタディサプリ』の事業ミッションは「自分らしく学び、生きられる世の中を」で、経済的・地理的な理由から発生する教育環境格差を解消し、すべての人たちに学ぶ機会と楽しさを提供したいという想いが、私たち『スタディサプリ』のルーツになっています。

目的を言語化して繰り返し伝えることで組織に文化が定着する

リサイズ⑤.png

――事業内でのQA/品証業務の位置づけ・ミッションを教えてください。

品質保証に対するミッションの定義は、保証対象とする品質特性に対する責任を持ち、開発ライフサイクルの早期に不具合を検出し修正を行うこと、そして、スキル・プロセス・ツールを考慮した組織の能力の向上を図り、品質保証ライフサイクルにおける20%の生産性向上を行うこと。また、インシデントマネジメントをはじめとする品質保証活動の組織横断の標準化をすることです。

――サービス品質を改善していくために、工夫しているポイントはありますか。

プロジェクトの規模に応じてアーキテクチャ段階からのQAの参画(シフト・レフト)や後工程でのリグレッションテストの導入・実施を確実にしています。

――これまでの失敗談やそこからどのように挽回したのかお教えください。

利害関係者に対して、非機能の要件や試験に対する説明をしたことがあったのですが、非機能要件に係る品質保証が重要だという理論としては組織で共通理解を持てていたものの、実作業として何をすれば改善できるのかという共通認識が取れていませんでした。

そこで、当時開発チームは機能適合性以外の品質特性の要件定義・試験に対する知見に乏しかったことから、パイロットプロジェクトを定義して非機能要件に係る品質保証施策の実施方法を徐々に広めていくアプローチを試してみたところ、これが適していました。

この経験から、一度に新たな取り組みを展開すると現場の混乱や議論が発散することもあり、私の肌感から「取り組みに対する必要十分な説明」「必要十分なハンズオン」「アフターフォロー」のステップをしっかり踏んでいく必要があると確信しました。

さらにパイロットプロジェクト全体を通して、常にその目的を言語化して繰り返し伝えることで、組織に文化が定着するということも、この経験で学んでいます。

これらのステップのうち途中で何かが欠けてしまうと新たな仕組みを導入することが困難になり、最後のリイテレート(繰り返し伝えること)を惜しむと仕組みのみが形骸化してしまいます。新たな取り組みを行う際には何を行い、何が利益となるかを明確にし、最後に熱すぎない程度の情熱を少し注いであげるのが取り組みを成功させる条件になると思っています。

悪い意味での「品質の門番」にならないことが大切

リサイズ④.png

――内藤さんは常に難しい課題に取り組んでおられますよね。どんなとき、QA/品証としての「やりがい」を感じておられますか?

個人としては、まず本番環境へのリリース後に大きなインパクトとなり得る重大な不具合が予定された工期内の早期で取り除くことができた時に、製品品質の向上に貢献できたことを実感し、やりがいを感じますね。

時に生産性向上と品質向上は二律背反の関係と言われることもありますが、リリースサイクルにおいての品質保証がボトルネックにならないよう、いわゆる悪い意味での「品質の門番」にならないことを大切にしています。

品質保証は永久に続くサイクル「永続的な改善活動」です。まずは測定するところから始めて、常に課題を見つけ改善のサイクルを回し続ける。どこかで何かが終わるのではなくずっと続いていくところに価値があるのではないかと考えています。

――業務を遂行する上で個人的に大切にしていることがあれば教えてください。

まず、人対人とのコミュニケーションに気をつけています。メンバーと一緒に仕事をする上で一番気を付けなければいけないことは、メンバーが持っているスキルセットやコンピテンシー、キャラクターそのものを大切にすることだと考えています。
それを無視すると、変なアプローチで相手を傷つけてしまったり、良くない結果になったりするので、それはお互いに避けたいですね。

技術的に気を付けていることは、やはり"思い込み"ですね。これは徹底的に排除しなければいけません。品質保証をやっている以上、推測や仮定はよくない。もちろん、そこがQAの面白いところでもあるのですが、不具合という頂上現象をもとにその原因を調べて(アプリケーションのログやDBの事前事後のデータの変化など)圧倒的に説得力のあるエビデンスを探しに行くことは自主的に気をつけているところです。

自分が情熱を持って改善に挑み続けられるかどうか

リサイズ①.png

――今後、業務を通じて達成したいことなどございましたらお教えください。

我々は機能テストだけではなく、ISO/IEC 25010の品質モデルで定義される品質特性のうち、信頼性と性能効率性の2つについては優先度を上げてきちんとと見ていくぞ、と号令をかけてやっています。他の品質保証に係る技術やノウハウの共有や、非機能要件に係るリグレッションテストも含めた品質を担保していくミッションを掲げて、現在取り組んでいるところです。
また、現在品質に係る測定可能なパラメータがプロジェクトにより異なること、もっとも重要なパラメータである本番環境でのメジャー(メトリクス)が必要十分でないことが課題となっており、品質に係るより多くのメジャー(メトリクス)を可視化し現状のベンチマークを測定しています。具体的な改善活動を始める前に、まず必要十分なメジャー(メトリクス)を取得することを当面の達成したい目標としています。

あとは、これも至上命題だと思うのですが、リリースしたものが本当にユーザーにウケているのかどうか、フィードバックを受けるのが難しいのが現状です。
サイレントクレーマーも多分いると思うので、フィードバックとして何か体系的に取得したり、改善していったりは必要なのかなとは思っています。

――最後に、QA業務にチャレンジしたい方に向けてメッセージをお願いいたします。

ソフトウェアにおける品質保証とは、その製品の開発が続く限り永久に続く継続的な改善活動を意味します。改善を視覚的に理解するためには、まず現在地の測定が欠かせません。今、定性的に何かうまくいっていないことがあるならば、そこには実測値として定量的に測定できる不具合が必ずあるはずです。

現状の課題を数値や図で可視化し、どこに根本的な問題があるのかあるかが把握できたらその施策を検討し、大規模な改善活動を始める前にまずは小さなパイロットプロジェクトから適応を始めてみてください。もちろん、施策適応前のベンチマーク(定量的な初期測定値)の取得も忘れずに。

パイロットプロジェクトが小さければ小さいほど、単純であれば単純であるほどあなたの仮説は正しく機能するはずです。その成功体験は、次により多くの人が関わる大きなプロジェクトへ適応するための自信に繋がります。

最も大切なことは、施策はもとより、あなたが情熱を持って改善に挑み続けられるかどうか。
永続的に続品質改善のサイクルの中で時に想定しない事態が発生したり意図せぬ反対意見が発生したりした時に、その情熱を持ち続けることはとても大変なことです。でも、その情熱があれば必ずあなたを理解し、協力してくれる味方も現れます。

どうしてもうまくいかない場合は、一旦社外に飛び出して横の繋がり(同業者)の知恵を借りてみるとか、例えばJaSSTなどのイベントに飛び込んでみて「そちらの会社ではどうやっているの?」とか質問して新たな風っていうのを入れてみるアプローチもあるのかなと思います。
そういった同業者との対話や他の組織での体験談なども、自身の情熱を持ち続けるためにプラスに働くきっかけになります。ぜひ組織を超えた横の繋がりも大切にしていただければと思います。

隣のQAに聞く
x hatenabookmark

執筆: Qbook編集部

ライター

バルテス株式会社 Qbook編集部。 ソフトウェアテストや品質向上に関する記事を執筆しています。