Technical Information
ウェブサービス開発における品質改善の取り組み 2020
経済産業省は平成30年9月に『DXレポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~』(DXレポート)という報告書をまとめています。※1
このレポートでは、DX(デジタルトランスフォーメーション)の重要性と共に、既存システムの複雑化・ブラックボックス化などに代表される技術的負債をそのまま放置しておくと2025年以降、最大12兆円/年(現在の約3倍)の経済損失が生じる可能性がある。すなわち、 2025年の崖という問題を提起しています。このような背景のもと、株式会社LIFULLにおいてもさまざまな品質改善の取り組みを行っています。本稿では、Webサービスの開発現場のQAマネージャーという立場から、当社の品質に対する考え方や取り組みについてご紹介します。
※1:https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html
株式会社LIFULL
テクノロジー本部 品質戦略部
品質改善推進ユニット
ユニット長
中野 直樹 氏
※この記事は、『ベリサーブ アカデミック イニシアティブ 2020』の講演内容を基にした内容です。
品質組織の移り変わり
はじめに、背景となるサービスや品質組織についてご紹介すると、当社は不動産情報ポータルサイトを中核にさまざまな事業を行っています。Webサービス開発を中心に複数のプロジェクトが常時並行しており、月のリリース件数は200件を超えています。プロジェクトごとの人数は数名~数十名と幅広いのですが、ディレクター・デザイナー・エンジニアを基本構成とし、我々、品質に関する支援組織のメンバーも必要に応じて各プロジェクトに参加しています。それでは、品質組織について少しご説明します。
1.品質組織の歩み
図1は、当社の品質組織の移り変わりを表しています。品質組織が設置されたのは約10年前に遡ります。現場のニーズや我々の戦略に合わせて組織は徐々に変化し、QAの独立をはじめ追加・分割・統合を経て、現在は一番右のオレンジ色の箱で示した五つのチームで構成されています。QAチームもこのうちの一つに属しています。本講演の内容は、2017年頃からの活動が中心となります。
2.品質組織の役割
我々にはいくつかのミッションがあります。まずは、開発全体を通じてストレスの少ない効率的なプロセス・環境を作ること。また、 QAやUX、セキュリティなどの専門領域からその開発チームにおける不足を補うためのサービスを提供すること。さらに、品質レベル向上の前提となる教育や啓蒙にも取り組んでいます。品質という文脈において、あらゆることを考え、企て、実践する中で、組織の構成も最適な形へと進化してきたということになります。
QAの変化
QAは、本番障害の発生率低減を目的に、日々プロジェクトや開発現場に寄り添って活動しています。具体的には、テストの最適化や支援、包括的なリスク低減のための情報確認、現場にフィットしたテスト関連ツールの開発・自動化などが挙げられます。開発プロジェクトにおけるテストは、開発チーム内で実施することを基本として、 QAによる支援はテスト技術の不足を補う視点で決定しています。また、教育・啓蒙としての活動では、新卒者に対してテスト関連の研修を実施し、組織のテスト文化を育てるような取り組みも行っています。
1.テスト計画のタイムリーな作成と提供
QAの発足時から継続して行っているサービスの一つに「テスト計画コンシェルジュ」があります。これは、開発現場に対してテスト計画の作成を支援もしくは代行するサービスです。
テスト計画は、開発チームでテストの方針の共通認識を持つためにあるものなので、素早くタイムリーに作成することが大切です。テスト計画コンシェルジュでは、テスト計画の立案とチーム内での議論、合意形成を短時間のミーティングで実行します。
図2は、テスト計画コンシェルジュの役割と効果のイメージです。左側のように、テスト方針が曖昧なまま進んでいくと、目的に相応しくないテストを作成したり、逆に不足したりということが起こり得ます。テスト計画を素早く作成することで、この上下のブレ幅を抑制し、テストの効率化とプロダクトリスクの低減に貢献するのがテスト計画コンシェルジュの狙いです。
2.テストの可能性を追求
図3は、DevOpsのプロセスとテストの考え方を示したものです。ウォーターフォールの開発モデルでは、テストの工程としてシステムテストが重要視されがちですが、QAの目的である本番障害の発生率低減を考えた際には、あらゆるプロセスにテストの可能性があると認識し、どこでテストをするべきかを常に思考し続ける必要があります。
図3:DevOpsのプロセスとテストの在り方
3.開発に対してQAが先回りして動く
図4は、プロジェクトに対するQAの活動を示したイメージになります。
- ①まず、同時に進行するすべてのプロジェクトで、開発に先んじて企画の段階からリスクを分析します。
- ②開発側からテスト計画の依頼が来た場合は、テスト計画コンシェルジュがサポートします。
- ③システムテストが終了し、間もなくリリースというタイミングで、 QAがテストの不足などをチェックします。
- ④チェックした結果、必要に応じて探索的テストを実行してリスクをケアします。
- ⑤プロジェクトによっては、QAが企画から運用の段階まで伴走してサポートする場合もあります。
このように、QAは常に開発と並行、もしくはそれに先んじて動き、成果物の品質確保とリスク低減に努めています。
4.DXへの対応と課題
最近のトピックスとして言及したいのが、DXへの対応です。DXとセットで語られるものとして「2025年の崖」問題がありますが、経済産業省のDXレポートではその対策として「DXシナリオ」も提示されていて、技術的負債を解消し人材や資金を新たなデジタル技術の活用にシフトしていく必要がある、と論じています。我々ユーザー企業においては、DXの変革と普段の業務を同時に進める必要があるわけで、QAが担う役割は大変難しいものになると感じています。
技術的負債の解消という文脈では、通常の開発業務とは異なる要望が出てきます。具体的な例で言えば、「データベースをAからBに置き換えたい。当然、サービスは止められません。どんなテストをしたら良いですか」、「モダンなアーキテクチャに刷新したい。影響範囲は不明ですが、もしかすると全部かもしれません。必要なテストは何ですか」、開発現場からは、こんな形のリクエストがQAに投げかけられてきます。
こうした要望に対して、どんなテストをすれば良いのか、いかに品質を担保すれば良いのか、我々QAは答えを持ち続けていなくてはならないのです。DXを推進する中で、現場では改善への意欲が日増しに高まっています。新しいことがどんどん始まり、粛々と状況は変化しています。QAはこの変化に食らいつき、テストを改善し続けなくてはなりません。「効率的なテストは何か?」「どのようにテストを実践すれば良いのか?」という問いに対して最適な解を考え、現場が必要とするサポートができないと、まさに2025年の崖を転げ落ちることになります。このような課題に対して大きな責任を担うのが、テストやQAの分野なのだと感じています。
5.QAとしてどう成長し何を実現すべきか
QAは施策を検討する際、チームにフィットしたテスト戦略であるか、という観点を持つことも大事になります。「こうあるべき」を押し付けるのではなく、チームの構成や成熟度に合わせたテストを考え、実践できるようサポートすることを心掛けています。近年は、開発側もスクリプトテストだけでなく探索的テストも実施しているので、これらに対する評価やフィードバックなども求められてきています。
また、技術情報のアップデートも欠かせません。Webサービスの分野には新たな技術が次々と登場してきますが、こうした開発における優れたプラクティスを、理解した上でサポートする必要があります。その他にも、UI/UX・ユーザビリティ・アクセシビリィ・セキュリティ・パフォーマンスといった、専門分野のテストを支援するためにも、常に新たな知識のインプットが必要です。
SET誕生からQEへ
2018年、QAから派生する形でSET(Software Engineering in Test)チームが誕生し、後にセキュリティエンジニアリングチームと一体になってQE(Quality Engineer)というチームになりました。 QEでは、テストや脆弱性診断の自動化、ツールの開発や導入などを実施しています。
1.自動テストツールの導入
テストの自動化については、10年前に品質組織が発足した時点から運用を開始しています。「Bucky」という自動テストツールを社内で開発し、テスト運用などの効率化に活用しています。
このほか、「Gazo-san」という画像差分検出ツールも開発しています。これらは2つともOSS化していますので、興味があれば是非試してみてください(図5)。
重要なのは、コストパフォーマンスの良いテストが運用されている環境を作ることです。プロジェクトで活用しやすいツールにするために、改修・改善を日々続けています。OSS化についても、さまざまな人が開発に携われるので、長い視点で見ればツールの改善スピードを上げるための一助になると考えています。
https://github.com/lifull-dev/bucky-management
Gazo-sanhttps://github.com/lifull-dev/Gazo-san
図5:「Bucky」と「Gazo-san」
2.Developer eXperienceの改善
図6は、CTO協会が公開しているDX Criteriaという資料の引用ですが、DXの実現に必要な改善項目を示しています。この中のシステムに関する部分には、継続的インテグレーション(CI)や継続的デプロイ(CD)、セキュリティシフトレフト※2 などが含まれています。 QA・テスト・開発のすべてを理解した上で、それをけん引していく人が必要なわけで、QEの役割はこれに該当します。
ただサービスを改善するだけでなく、開発プロセスの中でチームと協力し、効率化を促進していくということです。同じ資料の中に「2つのDX」、Digital TransformationとDeveloper eXperience (開発者体験)というものが出てきますが、後者を改善することも重要だと考えています。
現在、QEのけん引により、1.ソースコード品質の可視化、2.CI/CDのパイプラインの整備、3.早い工程で手戻りの原因をなくしていくセキュリティシフトレフトという3つについて重点的に取り組んでおり、開発プロセスの最適化や自動化によるフィードバックループの高速化を目指しています。
図6:CTO協会が公開しているDX Criteriaの一部
※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リサーチャーがこれを支援しています。
1.ユーザー体験の最適化
図8は、UXピラミッドと呼ばれるもので、UXの品質評価を階層的に表現しています。UXリサーチャーはこうしたモデルを参考に、サービスを単に実用性の面だけでなく、心地良い体験になっているかどうかというところまで評価を行っています。
前述のDX Criteriaの中には、デザイン思考というカテゴリがあり、ここにはユーザビリティテストをはじめ、ユーザー体験に関わる要素が含まれています(図9)。これを見ると、正直なところエンジニアやQAにとってはあまり得意ではない分野が多いと感じられます。品質の向上という目的は同じでも、アプローチや考え方が全く違うので、専門知識を持つUXリサーチャーの支援によって、課題の発見や問題解決がよりスムーズに進められるようになります。
図8:UXピラミッド
図9:CTO協会が公開しているDX Criteriaの一部
2.探索的領域へのシフト
図10は、ダブルダイヤモンドと呼ばれる課題解決モデルで、UXの改善プロセスを示したものです。ユーザビリティテストは、主に右側の「サービスを作って提供する」という段階での評価になります。ただし、サービスを提供する前提には解決すべき課題というものが必ずあるはずで、それを発見することを我々は探索的リサーチと呼んでいます。まず正しく課題を見つけ、サービスがその課題を解決するものになっているかを検証する、つまり、左側へともっとシフトして、探索的リサーチの領域を広げていきたいと考えています。
図10:ダブルダイヤモンドと呼ばれる課題解決モデル
3.DevOpsサイクルの精度向上
図11は、DevOpsの開発モデルを示したもので、中央にあるフィードバックループ※3 を高速かつ適切に回していくことが、品質向上のカギとなります。我々の組織で言うと、QEチームが開発プロセスの最適化・自動化によってこのループを高速に循環させていきます。一方、UXリサーチャーはユーザーファーストの観点からサービスを評価し、次の課題を適切に分析して、ループ1回の精度を上げていきます。この精度の向上が、結果的には、よりスピーディーなサービス改善にも有効で、そのためのリサーチを行っています。
図11:DevOpsの開発モデル
※3:開発チームからのプロダクトのデリバリーと、ユーザーからのフィードバックのサイクル。フィードバックループを高速に回すことで、仮説検証を用いて、プロダクトの改善を迅速に行うことが期待できる。
おわりに
品質への取り組みは、各支援領域においてまだまだ広がっている状態です。直近4~5年は、「2025年の崖」問題を回避するためにさらなる品質改善の仕組みが必要になってくると思っています。技術的負債に足を取られず開発に集中するためには、より最適な技術の提供やプロセスの改善、新しい時代のニーズに合ったサービスデザインを行うための支援や、DXの実現を後押しする力が必要になってきます。
今後の展望としては、二つの軸が必要と考えています。一つは、開発チームのメンバーがそれぞれの仕事に対してきちんと納得感を持てる環境を作ること。自分たちのプロセスや組織を気に入っている人は生産性が高いということは、統計データでも示されています。
もう一つは、そうは言っても、理想の状態と現状には常にギャップがあることを理解し、それを埋めるための努力を続けていくことです。その際には、品質組織のメンバーがそれぞれの専門領域の視点を持ち寄り、継続的な改善を行うことが必要です。この二つの軸が、ハイパフォーマンスな開発プロセスと環境を整備する上で重要になると考えています。
この記事をシェアする