※この記事は、『ベリサーブ アカデミック イニシアティブ 2020』の講演内容を基にした内容です。

品質組織の移り変わり

はじめに、背景となるサービスや品質組織についてご紹介すると、当社は不動産情報ポータルサイトを中核にさまざまな事業を行っています。Webサービス開発を中心に複数のプロジェクトが常時並行しており、月のリリース件数は200件を超えています。プロジェクトごとの人数は数名～数十名と幅広いのですが、ディレクター・デザイナー・エンジニアを基本構成とし、我々、品質に関する支援組織のメンバーも必要に応じて各プロジェクトに参加しています。それでは、品質組織について少しご説明します。

１．品質組織の歩み

２．品質組織の役割

我々にはいくつかのミッションがあります。まずは、開発全体を通じてストレスの少ない効率的なプロセス・環境を作ること。また、 QAやUX、セキュリティなどの専門領域からその開発チームにおける不足を補うためのサービスを提供すること。さらに、品質レベル向上の前提となる教育や啓蒙にも取り組んでいます。品質という文脈において、あらゆることを考え、企て、実践する中で、組織の構成も最適な形へと進化してきたということになります。

QAの変化

QAは、本番障害の発生率低減を目的に、日々プロジェクトや開発現場に寄り添って活動しています。具体的には、テストの最適化や支援、包括的なリスク低減のための情報確認、現場にフィットしたテスト関連ツールの開発・自動化などが挙げられます。開発プロジェクトにおけるテストは、開発チーム内で実施することを基本として、 QAによる支援はテスト技術の不足を補う視点で決定しています。また、教育・啓蒙としての活動では、新卒者に対してテスト関連の研修を実施し、組織のテスト文化を育てるような取り組みも行っています。

１．テスト計画のタイムリーな作成と提供

QAの発足時から継続して行っているサービスの一つに「テスト計画コンシェルジュ」があります。これは、開発現場に対してテスト計画の作成を支援もしくは代行するサービスです。

テスト計画は、開発チームでテストの方針の共通認識を持つためにあるものなので、素早くタイムリーに作成することが大切です。テスト計画コンシェルジュでは、テスト計画の立案とチーム内での議論、合意形成を短時間のミーティングで実行します。

図2は、テスト計画コンシェルジュの役割と効果のイメージです。左側のように、テスト方針が曖昧なまま進んでいくと、目的に相応しくないテストを作成したり、逆に不足したりということが起こり得ます。テスト計画を素早く作成することで、この上下のブレ幅を抑制し、テストの効率化とプロダクトリスクの低減に貢献するのがテスト計画コンシェルジュの狙いです。

２．テストの可能性を追求

図3は、DevOpsのプロセスとテストの考え方を示したものです。ウォーターフォールの開発モデルでは、テストの工程としてシステムテストが重要視されがちですが、QAの目的である本番障害の発生率低減を考えた際には、あらゆるプロセスにテストの可能性があると認識し、どこでテストをするべきかを常に思考し続ける必要があります。

３．開発に対してQAが先回りして動く

図4は、プロジェクトに対するQAの活動を示したイメージになります。

1. ①まず、同時に進行するすべてのプロジェクトで、開発に先んじて企画の段階からリスクを分析します。
2. ②開発側からテスト計画の依頼が来た場合は、テスト計画コンシェルジュがサポートします。
3. ③システムテストが終了し、間もなくリリースというタイミングで、 QAがテストの不足などをチェックします。
4. ④チェックした結果、必要に応じて探索的テストを実行してリスクをケアします。
5. ⑤プロジェクトによっては、QAが企画から運用の段階まで伴走してサポートする場合もあります。

このように、QAは常に開発と並行、もしくはそれに先んじて動き、成果物の品質確保とリスク低減に努めています。

４．DXへの対応と課題

最近のトピックスとして言及したいのが、DXへの対応です。DXとセットで語られるものとして「2025年の崖」問題がありますが、経済産業省のDXレポートではその対策として「DXシナリオ」も提示されていて、技術的負債を解消し人材や資金を新たなデジタル技術の活用にシフトしていく必要がある、と論じています。我々ユーザー企業においては、DXの変革と普段の業務を同時に進める必要があるわけで、QAが担う役割は大変難しいものになると感じています。

技術的負債の解消という文脈では、通常の開発業務とは異なる要望が出てきます。具体的な例で言えば、「データベースをAからBに置き換えたい。当然、サービスは止められません。どんなテストをしたら良いですか」、「モダンなアーキテクチャに刷新したい。影響範囲は不明ですが、もしかすると全部かもしれません。必要なテストは何ですか」、開発現場からは、こんな形のリクエストがQAに投げかけられてきます。

こうした要望に対して、どんなテストをすれば良いのか、いかに品質を担保すれば良いのか、我々QAは答えを持ち続けていなくてはならないのです。DXを推進する中で、現場では改善への意欲が日増しに高まっています。新しいことがどんどん始まり、粛々と状況は変化しています。QAはこの変化に食らいつき、テストを改善し続けなくてはなりません。「効率的なテストは何か？」「どのようにテストを実践すれば良いのか？」という問いに対して最適な解を考え、現場が必要とするサポートができないと、まさに2025年の崖を転げ落ちることになります。このような課題に対して大きな責任を担うのが、テストやQAの分野なのだと感じています。

５．QAとしてどう成長し何を実現すべきか

QAは施策を検討する際、チームにフィットしたテスト戦略であるか、という観点を持つことも大事になります。「こうあるべき」を押し付けるのではなく、チームの構成や成熟度に合わせたテストを考え、実践できるようサポートすることを心掛けています。近年は、開発側もスクリプトテストだけでなく探索的テストも実施しているので、これらに対する評価やフィードバックなども求められてきています。

また、技術情報のアップデートも欠かせません。Webサービスの分野には新たな技術が次々と登場してきますが、こうした開発における優れたプラクティスを、理解した上でサポートする必要があります。その他にも、UI/UX・ユーザビリティ・アクセシビリィ・セキュリティ・パフォーマンスといった、専門分野のテストを支援するためにも、常に新たな知識のインプットが必要です。

SET誕生からQEへ

2018年、QAから派生する形でSET（Software Engineering in Test）チームが誕生し、後にセキュリティエンジニアリングチームと一体になってQE（Quality Engineer）というチームになりました。 QEでは、テストや脆弱性診断の自動化、ツールの開発や導入などを実施しています。

１．自動テストツールの導入

テストの自動化については、10年前に品質組織が発足した時点から運用を開始しています。「Bucky」という自動テストツールを社内で開発し、テスト運用などの効率化に活用しています。

２．Developer eXperienceの改善

図6は、CTO協会が公開しているDX Criteriaという資料の引用ですが、DXの実現に必要な改善項目を示しています。この中のシステムに関する部分には、継続的インテグレーション（CI）や継続的デプロイ（CD）、セキュリティシフトレフト^※2 などが含まれています。 QA・テスト・開発のすべてを理解した上で、それをけん引していく人が必要なわけで、QEの役割はこれに該当します。

ただサービスを改善するだけでなく、開発プロセスの中でチームと協力し、効率化を促進していくということです。同じ資料の中に「2つのDX」、Digital TransformationとDeveloper eXperience （開発者体験）というものが出てきますが、後者を改善することも重要だと考えています。

現在、QEのけん引により、１．ソースコード品質の可視化、２．CI/CDのパイプラインの整備、３．早い工程で手戻りの原因をなくしていくセキュリティシフトレフトという３つについて重点的に取り組んでおり、開発プロセスの最適化や自動化によるフィードバックループの高速化を目指しています。

※2：セキュリティに関する問題がソフトウェア開発ライフサイクルの早い段階で対処されること（出典：“DevOps 技術:セキュリティのシフトレフト”,
https://cloud.google.com/solutions/devops/devops-tech-shifting-left-on-security/?hl=ja#ways_to_improve_security_quality,2021/01/06 参照）

UXリサーチャー

UXリサーチャーは、ユーザーファースト推進チームの中でユーザビリティテストやコンセプト評価を行っており、我々はこれを検証型リサーチと呼んでいます。具体的には、ユーザーがサービスを開発者の意図通りに使えているか、スムーズにサービスを利用できているかを検証しています。

図7は、開発におけるユーザビリティテストの実行ポイントを示したものです。我々エンジニアは、ユーザビリティテストはシステムテストの後半に位置するものと思いがちですが、実際には開発プロセスのさまざまなフェーズにテストの可能性があり、専門家であるUXリサーチャーがこれを支援しています。

１．ユーザー体験の最適化

図8は、UXピラミッドと呼ばれるもので、UXの品質評価を階層的に表現しています。UXリサーチャーはこうしたモデルを参考に、サービスを単に実用性の面だけでなく、心地良い体験になっているかどうかというところまで評価を行っています。

前述のDX Criteriaの中には、デザイン思考というカテゴリがあり、ここにはユーザビリティテストをはじめ、ユーザー体験に関わる要素が含まれています（図9）。これを見ると、正直なところエンジニアやQAにとってはあまり得意ではない分野が多いと感じられます。品質の向上という目的は同じでも、アプローチや考え方が全く違うので、専門知識を持つUXリサーチャーの支援によって、課題の発見や問題解決がよりスムーズに進められるようになります。

２．探索的領域へのシフト

３．DevOpsサイクルの精度向上

図11は、DevOpsの開発モデルを示したもので、中央にあるフィードバックループ^※3 を高速かつ適切に回していくことが、品質向上のカギとなります。我々の組織で言うと、QEチームが開発プロセスの最適化・自動化によってこのループを高速に循環させていきます。一方、UXリサーチャーはユーザーファーストの観点からサービスを評価し、次の課題を適切に分析して、ループ1回の精度を上げていきます。この精度の向上が、結果的には、よりスピーディーなサービス改善にも有効で、そのためのリサーチを行っています。

※3：開発チームからのプロダクトのデリバリーと、ユーザーからのフィードバックのサイクル。フィードバックループを高速に回すことで、仮説検証を用いて、プロダクトの改善を迅速に行うことが期待できる。

おわりに

品質への取り組みは、各支援領域においてまだまだ広がっている状態です。直近4～5年は、「2025年の崖」問題を回避するためにさらなる品質改善の仕組みが必要になってくると思っています。技術的負債に足を取られず開発に集中するためには、より最適な技術の提供やプロセスの改善、新しい時代のニーズに合ったサービスデザインを行うための支援や、DXの実現を後押しする力が必要になってきます。

今後の展望としては、二つの軸が必要と考えています。一つは、開発チームのメンバーがそれぞれの仕事に対してきちんと納得感を持てる環境を作ること。自分たちのプロセスや組織を気に入っている人は生産性が高いということは、統計データでも示されています。

もう一つは、そうは言っても、理想の状態と現状には常にギャップがあることを理解し、それを埋めるための努力を続けていくことです。その際には、品質組織のメンバーがそれぞれの専門領域の視点を持ち寄り、継続的な改善を行うことが必要です。この二つの軸が、ハイパフォーマンスな開発プロセスと環境を整備する上で重要になると考えています。

この記事をシェアする