【THE NOVEL開発の舞台裏 第3回】「使えるAI」「導入する価値」は、どう確かめる？

UXは、ウォークスルーで磨かれる

こんにちは。THE NOVEL^®のPM（プロジェクトマネージャー）を担当している合同会社InkFieldの越口です。

画面の使いやすさは、デザイナーが完成案を提示し、最後に承認すれば決まる――というものではありません。THE NOVELの会議記録を見ると、要件を考えながら画面にし、画面を見て要件へ戻り、名前や導線を修正する往復が繰り返されています（※ウォークスルー：要件と画面を行き来しながら検証する進め方）。

ある全体定例会議では、画面の見え方について三つの案が用意され、参加者がFigma（※デザインを共同で確認・編集できるツール）を開いて比較しました。MacとWindowsで見え方が異なること、想定利用者にはWindows環境が多い可能性も話題になっています。ポイントは、好みだけで決めなかったことです。複数案を同じ場で見て、利用環境という制約を共有し、次の試作へ進める案を選ぶ。判断時点の材料と、次に精度を上げる工程が分かれていました。

要件レビューでは、データ一覧とデータ編集に似た画面が現れ、一方では共有や複製ができ、もう一方ではできない状態が議論されました。機能を減らせば実装は単純になりますが、利用者が画面を行き来する回数は増えます。反対に似た画面を二つ残すと、「自分は今どこにいて、何ができるのか」が分かりにくくなります。「似ているのに挙動が違う」ことが混乱の原因になる――この論点が明確になり、その後の画面設計を見直す材料になりました。

用語の検討も、UXの一部として扱っています。名称は最後の飾りではなく、画面に現れる概念と利用者の理解をつなぐ要件です。見せる情報が固まらないうちに用語だけを決めると、説明と操作がずれてしまう。だからこそ、画面レビューが終わった後に、案内すべき言葉を洗い出す方針を置きました。

この往復は、一見すると手戻りに見えます。しかし、文章だけでは気づきにくい操作の矛盾を画面で見つけ、画面だけでは説明できない利用目的を要件へ戻すための、大切な検証なのです。

採用しなかった案にも、理由がある ―― 仕様の取捨選択と優先順位のつけ方

開発の品質は、実装した機能の数だけでは測れません。実際の開発では、案を減らす、別のフェーズへ移す、仕様を簡素化する、要件を詰め直す、といった判断が頻繁に起こります。

たとえば二要素認証（※パスワードに加えてもう一つの手段で本人確認するしくみ）の要件レビューでは、初期案で認証アプリと電話番号の両方を設定でき、電話番号も複数登録できる想定でした。変更案では、認証方法をどちらか一つに絞り、電話番号も一つにする検討をしています。ただし、入力した番号が正しいか確認するため、登録時に認証コードを入力する手順は追加しました。一律に機能を削ったのではありません。選択肢の数は減らし、誤った番号を登録しないための確認は増やす。実装量と安全上の必要条件を、分けて判断したのです。

ご要望の扱いにも、複数の種類があります。ある全体定例会議では、要望チケットを一件ずつ見ながら、すぐ実施するもの、仕様検討へ進めるもの、別フェーズで吸収するもの、当面見送るものを分けていました。同じ「見送り」でも、不要と判断したもの、時期を移したもの、要件を詰める必要があるものは異なります。理由を区別して記録しなければ、後から再検討するときに判断の前提が失われてしまいます。

そして、すべてを同時にはできないからこそ、優先順位を具体化します。「重要」「普通」というラベルだけでは足りません。複数の高優先度項目の中で、なぜ一つを先にするのか、他はどの時期へ送るのかを言葉にする。案の採否は、要望の強さだけでなく、工数・リリース順・既存フェーズとの重複を合わせて決まります。見送りを「消去」ではなく「保留」として記録に残すからこそ、状況が変われば見直せるのです。

お客様の「期待」を、開発側が代弁しない

ここから先は、導入をご検討いただく段階の話です。製品の価値は、機能一覧だけでは決まりません。お客様が導入前に何を確かめたかったのか、試した結果どの判断が変わったのか、業務に取り入れる際に何が障壁になったのか――これらは、開発側が代わりに答えられない問いです。

トライアル（※本格導入の前に試しに使っていただく期間）の検討では、すべての企業が共通環境を使う案と、必要に応じて企業別の環境を用意する案が話し合われました。プロジェクトへメンバーを招待できるか、他社の情報が見えない状態をどうつくるか、本契約へデータを引き継ぐか、どこまでの機能を使えるようにするか。単にログインできれば「試せる」わけではないのです。複数人で試す業務なのか、実データに近い状態が必要なのか、試用後のデータをどう扱うのかによって、トライアルの設計は変わります。

私たちが避けたいのは、好意的なコメントだけを集める姿勢です。開発側が「価値だ」と考えたことと、お客様が「業務判断に使えた」と評価したことは、同じではありません。期待と評価を同じ言葉にせず、開発側の仮説・用意した条件・お客様本人の評価を分けて示す。期待が満たされなかった点も省かない。それが、私たちの考える誠実さです。

POC（概念実証）で、何を確かめるのか ―― トライアルとの違い

導入検討の中核が、POC（※Proof of Concept＝概念実証。本格導入の前に、目的の達成可能性を実データなどで検証すること）です。

最初の全体定例会議では、POCで顧客に何をしてもらうか、実施期間をいつにするか、顧客データを扱う際に何を説明するかが議題になりました。機能を渡すだけでは、何を評価したのかが曖昧になります。利用できる範囲、準備するデータ、支援体制、評価方法を先に揃える必要がある。会議では、お客様自身がモデルを作成して検証することに加え、プロジェクト側も同じデータで試行し、比較や評価を支援する案が説明されました。POCを単なる操作体験ではなく、お客様と開発側が判断材料を増やす共同検証として設計しようとしたのです。ここには、分析コンサルとしてお客様に伴走してきた技研商事の姿勢が表れています。

POCとトライアルは、明確に区別しました。POCは、データやモデルを使って評価し、導入判断へつなげる検証。トライアルは、まず触っていただく入口。対象・支援・預かるデータ・評価方法が違えば、同じ成果指標で扱うことはできません。

また、POCではお客様のデータを外部環境へお預かりする可能性があります。そのためNDA（※秘密保持契約）だけでなく、どのような安全対策を説明するか、社内承認に必要な書面は何か、利用状況をどう把握するか（ログの有無と可視化）まで議論しました。POCの評価は、製品機能だけでなく、データ管理・アカウント発行・利用状況の把握まで含む、運用全体の設計だったのです。

価値を先に宣言せず、確かめられる範囲を示す

「使えば価値が分かります」と、開発側から先に語ることは簡単です。しかし私たちは、そうしません。お客様が導入前に持っていた問い、POCで見た指標、想定と異なった点、判断の理由――これらは、お客様本人の言葉を確認して初めて書けることだからです。結果が期待どおりでなかった項目も含め、確認できた範囲で示す。

磨き、削り、確かめる。THE NOVELの信頼は、価値を先に宣言することではなく、何を検証し、何がまだ分からないかを区別できることから生まれると、私たちは考えています。

（本シリーズ・完）

電話によるお問い合わせ先：03-5362-3955（受付時間／9：30～18：00 ※土日祝祭日を除く）
Webによるお問い合わせ先：https://www.giken.co.jp/contact/