開発・デザインの品質チェックにAIを入れる。UXとバグの早期検知

不具合や使いにくさは、見つかるのが遅いほど直すコストが上がります。
設計の段階で見つかれば数分で済むものが、実装後なら数時間、公開後なら数日かかります。
公開後に見つかった場合は、影響を受けた人への対応まで必要になるからです。

今回は、UXのチェックとバグの検知をAIで早い段階に前倒しする設計を整理します。
品質を組織でそろえる全体像のほうはAIアウトプットの品質を組織でそろえる。標準化とレビュー体制にまとめてあります。

不具合は、見つかる場所が変わるだけで桁が変わる

コストの構造を整理しておきます。
自社ではどの段階で見つかることが多いでしょうか？

設計の段階で見つかれば、設計書を直すだけなので数分です。
実装の途中なら、コードを直して数十分です。
レビューで見つかれば、直して再レビューで数時間です。

公開後なら、直して再公開して影響を受けた人に対応するので数日かかります。
同じ一件でも、見つかる場所によって桁が変わります。

「公開後に見つかったものが最も多い」という組織が、確かにあります。
レビューする人の時間が取れないので形式的な確認になってしまうのが、工程が薄い理由です。
だから、レビューの前に機械的な検知を入れます。
レビューアの負荷を下げて、設計の妥当性のような判断が必要な部分に時間を回すという分担です。

観点は3つ、バグがいちばん検出しやすいのに見落とされる

観点は3つに分かれていて、それぞれ性質が違います。
自社はどの観点がいちばん弱いでしょうか？

UXの観点は使う人が目的を達成できるか、その途中で迷わないかを見て、ユーザビリティの観点は押しにくい、読みにくい、分かりにくいといった操作しやすさの問題を見ます。
バグの観点は、動作の誤りと、想定外の入力への対応を見ます。
UXとユーザビリティには判断が入りますが、バグには機械的に検出できる部分があります。

なかでもUXの観点は、最も早く検知すべきです。
設計の段階で分かるうえに、後から直すのが最も難しいからです。
逆にバグの観点は、最も検出しやすいのに最も見落とされます。
正常な操作だけを確認して、想定外の入力を試さないまま通してしまうからです。

入力欄に空欄や極端に長い文字列を入れる確認は、数分で終わります。
ただ、その数分が工程に入っていないことが多いのが実情です。

観点ごとに検知のやり方を変える

3つの観点は、それぞれ聞き方も見方も違います。
どう分ければ、機械にきちんと働いてもらえるでしょうか？

UXの観点では、画面や設計について使う人の視点で問題を挙げさせます。
そのときに使う人は、「初めて使う人」「急いでいる人」「操作に慣れていない人」というように具体的に設定します。
「この画面を初めて見る人が、〇〇をしようとしたときに迷う箇所を挙げてください」という形で、目的を指定するのが要点です。

「使いやすいか」と聞くと、抽象的な指摘しか返ってきません。
主要な目的を3つ設定してそれぞれで試すと判断に時間がかかる箇所が見えてきて、エラーではなく迷う箇所が、ここでは最も価値のある指摘になります。
UXの分析をディレクション側の型に組み込む話はディレクター・PMのAI活用を型にする。指示・差分確認・UX分析にまとめてあります。

ユーザビリティの観点では、文字が読める大きさか、押す部分が押しやすい大きさか、色の区別がつくか、情報の量が適切か、操作の順序が自然かの5つを見ます。
数値で確認できるものは、数値で決めておきます。
「文字は14px以上」「押す部分は44px以上」というように基準を決めれば、外れているものを一覧で出せるので個別に見るより速くなります。

情報の量と操作の順序には基準が置けないので、ここは人が判断します。
デザイン側の型そのものはデザイナーのAI活用を型にする。トンマナ統一と素材加工で扱っています。

バグの観点では、「この入力欄で、想定外の値として試すべきものを挙げてください」と依頼して一覧を作らせ、それを試します。
出てくるのは、空欄、極端に長い文字列、記号や特殊な文字、全角と半角、負の数、ゼロ、非常に大きい数といったところです。
エラーになったときの表示も、あわせて確認します。
エラーが出ること自体は問題ではなく、エラーの内容が使う人に分からないことのほうが問題です。

過去に問題になった入力は、一覧として蓄積しておきます。
自社固有の落とし穴が集まるので、この一覧が最も価値のある資産になります。

セルフチェックからレビュー工程、リリース基準まで3段階で回す

導入は段階を踏みます。
どこから手を付ければ、無理なく回るでしょうか？

最初は作った本人によるセルフチェックで、レビューに出す前に3観点で確認します。
時間は10分に収めます。
UXの確認3分、ユーザビリティの確認3分、想定外の入力の確認4分という配分です。

これを超えると工程が重くなって、飛ばされます。
検出された箇所を一覧で出させれば全体を見直す必要はなく、指摘を全部直す必要もありません。
判断は本人がするものの、読むこと自体で次から意識が変わります。

作るもの3件を2〜4週間で試して、レビューでの指摘が減ったかを確認します。
セルフチェックが回ったら、工程に組み込みます。
やることは2つあり、3観点のチェックを通してからレビューに出すことを条件にするのと、レビューアが機械的な指摘をしないことです。

検出できる指摘は、直さずに作成者へ戻します。
レビューアが文字の大きさや誤字を指摘している間は、設計の妥当性を見る時間が減るからです。
レビューアが見るのは、設計の妥当性、要件との整合、リスクの3つに絞ります。
レビューの時間と指摘の内容を記録しておくと、機械的な指摘が残っているならセルフチェックが飛ばされていると分かります。

複数の目で見る工程そのものは公開前レビューを複数の目で行う。ペルソナ別レビューを工程に入れるにまとめてあります。

最後に公開の条件に入れ、確認する項目として3観点を置き、文字の大きさや押す部分の大きさ、コントラストは数値で決めて判断が入らない形にします。
蓄積した想定外の入力の一覧は、全部試すことを必須にします。
基準を満たさない場合は、公開しないと決めます。

ただ、緊急時は承認を得て公開し、後から直す期限を決めるという例外の手続きも用意しておきます。
手続きがないと、基準そのものが黙って無視されるようになるからです。

四半期に一度、公開後に見つかった問題から基準を追加します。
内製環境の権限まわりの整え方は内製環境の権限設定をどう整えるか。安全と速度を両立させるで扱っています。

人のテストとは役割を分ける

ここで線を引いておきます。
機械的な検知は、人のテストの置き換えではありません。
人とAIでは、何が向いているのでしょうか？
機械的な検知が向くのは、数値で判定できる基準、想定外の入力の洗い出し、文字や色の確認、一覧の網羅性といったところです。

一方で人のテストが必要なのは、目的を達成できるか、操作の流れの自然さ、実データでの動作、複数の操作を組み合わせた場合の挙動です。
なかでも実データでの動作が最も重要で、ダミーのデータでは検出されない問題があります。

実際の桁数や文字数、想定していなかった表記の揺れが入って初めて崩れる箇所があるからです。
複数の操作を組み合わせた場合も同じで、個別の操作は正常でも順序によって問題が起きることがあります。
検証用のデータをどう用意するかは本番データを使わずに検証する。ダミーデータを作る文化をつくるにまとめてあります。

実際に使う人にテストしてもらうのが最も確実で最も見落とされるからこそ、機械的な検知で時間を作り、その時間を人のテストに回すのが、今回の話の目的そのものです。
つまずきやすいのは7つです。
「使いやすいか」と抽象的に聞く、ユーザビリティの基準を決めない、想定外の入力を試さない、レビューアが機械的な指摘をする、セルフチェックに20分かける、リリース基準に例外を作る、人のテストの時間を削る、というところです。
どれも、目的を指定して、数値で基準を決めて、一覧を蓄積して、作成者に戻して、10分に収めて、例外の手続きを用意して、機械的な検知で作った時間を人のテストに回せば防げます。

機械的な検知とリリース基準を組み込んだAIワークフローの実装も、当社のAI伴走支援で、現場の担当者と一緒に手を動かしながら進めています。

早く見つければ安く直る。この一点に尽きる

不具合は見つかるのが遅いほど直すコストが上がります。
設計の段階なら数分、公開後なら数日です。

観点は3つあり、UXは目的を達成できるか、迷わないかを見ます。
最も早く検知すべきで、後から直すのが最も難しい観点です。

ユーザビリティは、数値で基準を決められます。
バグは、最も検出しやすいのに最も見落とされます。

UXは目的を指定します。
「使いやすいか」ではなく「〇〇ができるか」で聞き、「迷う箇所」が最も価値のある指摘になります。

ユーザビリティは数値で基準を決めて、外れているものを一覧で出します。
バグは想定外の入力を挙げさせて実際に試し、過去に問題になった入力を一覧として蓄積します。
進め方は3フェーズあり、セルフチェックは10分に収め、レビュー工程ではレビューアが機械的な指摘をしません。

リリース基準は、数値で決めて例外の手続きを用意します。
人のテストが必要なのは、実データでの動作と操作の組み合わせです。
機械的な検知で作った時間を、そこに回します。

まずは直近で作ったものについて、想定外の入力を挙げさせて試してみてください。