見出し画像

デザインシステムチームとQAエンジニアの取り組み：kintoneのユーザー体験を最高にするために

blindsoup

この記事は、CYBOZU SUMMER BLOG FES '24 (Design Stage) DAY 4の記事です。

kintone Design Systemチームは、kintoneの「ユーザー体験を最高にする」をミッションに活動しています。その手段のひとつとして、kintone Design Systemを開発・運用・啓発しています。

この記事では、ユーザー体験を最高にするために、kintone Design Systemチームから働き掛け、QA（品質保証）エンジニアが実施している試験の観点を拡充した活動を紹介します。



なぜkintone Design SystemチームがQAエンジニアに働きかけるのか

kintoneとして一貫して提供したいユーザビリティ・アクセシビリティの品質をQAエンジニアが試験することで、プロダクト全体の品質向上につながるためです。これにより、ユーザー体験の向上が期待できます。
サイボウズのQAエンジニアは、プロダクトの品質に責任を持ちます。機能ごとにテストケースを作成します。テストケースをもとに試験を行い、不具合がないか、仕様を満たしているか確認します。試験で問題が見つかった場合は、修正タスクを積み増す。
QAエンジニアは個々の機能の仕様を漏れなく試験します。一方で、機能単位ではなく、プロダクト全体として一貫して提供したいユーザビリティやアクセシビリティの品質があります。
ユーザビリティ・アクセシビリティについては、一律に試験観点が決まっているわけではなく、QAエンジニアの裁量によって異なる状況でした。そこでkintone Design Systemチームの出番です。
kintone Design Systemチームは、フロントエンド・デザイン・アクセシビリティなど、それぞれの領域に専門性を持つメンバーが集まるクロスファンクショナルなチームです。kintone Design Systemとして、ひいてはkintoneとして提供したいユーザビリティ・アクセシビリティの知見を持っています。
その知見をQAエンジニアに共有し試験観点を拡充することは、kintone Design Systemチームのミッションとリンクした活動です。

活動の概要

QAエンジニアが実施している試験をいくつか追加しました。下記に一例を示します。

  • 十分なコントラストが確保されているか

  • マウスと同等の操作をキーボードで行えるか

  • 色に依存した表現になっていないか

これらはWCAG(Web Content Accessibility Guidelines)の観点です。

これらの観点がユーザー体験にどのように影響するのでしょうか。

たとえば、コントラストが低い画面。kintoneは農地や工場など屋外で閲覧・操作しているユーザーがいらっしゃいます。屋外では強い太陽光にさらされたり、反対に曇りや雨で暗かったりと環境が大きく変わるため、コントラストが低いと視認しにくくなります。また、高齢の方で視力が低下しているユーザーも、コントラストが低い画面は見えにくいです。

例えばキーボード操作ができないパーツ。kintoneは大量のデータを登録することがあります。データ入力ではマウスを使うよりキーボードで作業が完結したほうが効率的です。また、マウスが使えない・使いにくい状況や身体的制約がある人は、キーボードのみで操作しますから、マウスに依存した操作があるとkintoneを使いこなせなくなってしまいます。

このようにWCAGの観点のうち、ユーザー体験を大きく左右するものについて、QAエンジニアの試験観点を拡充する活動を行いました。

もちろんデザイナーが情報設計する段階からこれらの観点も検討するのですが、100%検討しきれるわけではありません。どうしても人間なので漏れが出てしまいます。

そこでQAエンジニアが考慮漏れを試験で検出し、デザイナーにフィードバックします。そうすれば、今すぐ直すのか、デザイン改善issueとして積むのかなど、次のアクションにつなげられます。

なぜやるのか

やるべき絶好のタイミングだったからです。

上述した観点の試験は、今までも一部実施されていました。しかし一律の基準があるわけではなく、いくつかある機能開発チームの裁量によって異なる状況でした。

しかし、下記に示すkintone開発を取り巻く状況の変化があることから、このタイミングで一律に試験観点をアップデートすべきだと考えました。

kintone開発を取り巻く状況の変化：

  • フロントエンドの刷新

  • デザインシステムの活用

  • デザイン組織の活用

1. フロントエンドの刷新

kintoneは大規模なフロントエンドの刷新を進めています。

フロントエンドを刷新する過程で、新たな問題を生み出さないためにも、QAエンジニアが確実に問題を検出できる状態にしておきたいです。

また、フロントエンドの刷新は、より良くするチャンスでもあります。多くの画面に影響する問題や情報設計から見直さなければならない問題はどうしても手を入れにくくなります。新たに刷新する画面では、既存のページよりも、改善しやすい状態にあります。

例を挙げると、色やアイコンを他のページと統一して一貫性を担保する、コントラストが確保された色を適用する、といった改善が行いやすいです。

2. デザインシステムの活用

フロントエンドの刷新においては、kintone Design Systemを活用しています。
kintone Design Systemは、デザインの一貫性・効率性・スケーラビリティを高めるための共通コンポーネント・デザイントークン・ドキュメントを含みます。

kintone Design Systemについて、詳しくは以下記事を参照ください。

kintone Design Systemの活用で、改善がしやすい環境が整いつつあります。

例えば、kintone Design Systemができる前は、コントラストの問題を認識していても、手を入れにくい状況でした。kintone Design System活用後は、デザイントークンを整備することで、コントラストを改善しやすい状態になりました。

QAエンジニアが問題を検出→kintone Design Systemを改善するというサイクルを繰り返すことで、デザインシステムが成長し、kintoneのユーザー体験が最高になる状態を目指します。

3. デザイン組織の活用

ここ1年で、デザイン組織が大きく変わりました。デザイナーが大幅に増え、マネジメント体制が整いました。それにより、機能開発のデザインの工数が増えるだけでなく、デザイナー起案の改善も進められるようになりました。

QAエンジニアが発見した問題をデザイナーにフィードバックすることで、デザイン改善として着手することができます。上述のkintone Design Systemの改善と合わせて、QAエンジニアが問題を検出してフィードバックすることの重要性が高い状況にあります。

どう進めたか

ここからは試験観点を拡充するためにどう進めたかという話です。

  • kintone Design Systemのドキュメントを拡充する

  • ドキュメントを読み合わせて翻訳する

  • お試しで運用する

1. kintone Design Systemのドキュメントを拡充する

まずは、kintone Design Systemのドキュメントを拡充しました。kintone Design Systemのドキュメントとすることで、QAエンジニアが活用するだけでなく、デザイナーやフロントエンドエンジニアも開発した成果物の品質確認を独力で行うことができます。

ドキュメントには、試験する方法と確認する観点を完結にまとめています。

一例として、「拡大時・縮小時の表示確認」というドキュメントの要点を下記に示します。

  • 試験する方法

    1. ブラウザを200%に拡大する

    2. ブラウザのフォントサイズを2倍にする

  • 試験の観点

    • 1.および2.のいずれかで表示したとき、情報を正しく閲覧・操作できるか

    • 2.の方法で閲覧したとき、文字やコンテナのサイズが追従するか

    • 拡大時によくある問題：

      • 固定要素が画面の多くを占有してしまう

      • 文字やコンテナが拡大・縮小に追従しない

      • 文字が重なったりレイアウトが著しく崩れたりして閲覧しにくい

      • 途中で文字が見切れてしまい、続きを確認する手段がない

      • 画面をスクロールできず、その先にあるボタンを押せない

2. ドキュメントを読み合わせて翻訳する

kintone Design SystemチームとQAエンジニアのメンバーで、kintone Design Systemのドキュメントを読み合わせました。実際に手元で試したり、現状問題が発生している箇所を探したりしました。

その後、kintone Design Systemのドキュメントをもとに、実際にQAエンジニアが試験する際に必要十分な情報をまとめていきました。

  • 試験方法と試験観点（kintone Design Systemのドキュメント）

  • 特定のブラウザで試験するのか、クロスブラウザで試験するのか

  • 試験の対象範囲、試験するタイミング

  • 問題を検出した際のフィードバック先と伝える内容

試験で検出した問題は、軽微なマークアップの修正ならフロントエンドエンジニアに、それ以外はデザイナーにフィードバックすることにしています。ほとんどはデザイナーにフィードバックすることになります。

3. お試しで運用する

実運用してみて、相談事項が出てきたときは、つどチャットで聞いてもらうか、直接試験実施の場に呼んでもらう（SlackのハドルやZoomで話す）ことにしています。

実際に運用してみると、試験手順が実運用に合わない・試験手順が複雑など課題が出てくると思います。

つど振り返り＆改善しつつ定着する支援をしていきたいと思っています。

期待している成果

まだおためし運用をして日が浅いので、ここでは期待している成果をまとめます。

  • ユーザー体験が向上すること

  • デザイナーに知見がたまること

  • 興味をもってくれるQAエンジニアが増えること

1. ユーザー体験が向上すること

上述したようにkintone開発を取り巻く環境の変化で、QAエンジニアが発見した問題を改善しやすい状態にあります。これまで拾い切れていなかった（かもしれない）問題を、QAエンジニアに検出してもらうことで、寄りユーザー体験が向上できることを期待しています。

2. デザイナーに知見がたまること

kintone Design Systemのドキュメントで、デザイン検討時の観点をまとめていつでも参照できるようにしています。

とはいえ、人間なので100%すべてを考慮しきれるわけではありません。どうしても考慮漏れは発生してしまうものです。

そこをQAエンジニアからデザイナーにフィードバックしてもらうことで、デザイナーの知見が高まることを期待しています。

知識として知っているだけでなく、経験として知っていると定着しやすいと思っています。kintone Design Systemのドキュメントはあくまでも知識を提供するものです。デザイン検討した成果物に対して具体的なフィードバックがくると経験としてインプットしやすいと思っています。

3. 興味をもってくれるQAエンジニアが増えること

試験観点の拡充で、WCAG周りの観点に興味関心をもってくれるメンバーが増えることを期待しています。

今までも「こういうスクリーンリーダーの読み上げをするんだけど妥当なのか」など、かなり細かいところまで検証して聞いてくださる方がいました。

興味関心を持ってくれるメンバーが増えると、今回の活動は風化せずに定着すると思っています。

総括

kintone Design Systemチームの取り組みのひとつとして、QAエンジニアの試験観点を拡充し、ユーザー体験を最高にすることを目指す取り組みを紹介しました。

どんなことにも最適なタイミングがあります。

フロントエンドの刷新、デザインシステムの活用など、既存の環境が変わるときはチャンスです。


この記事が気に入ったらサポートをしてみませんか？