【THE NOVEL開発の舞台裏 第1回】出店判断を支えるAIは、どう決めてきたか？―― 438回の会議に見る「顧客の声を要件に変える」開発プロセス

こんにちは。THE NOVELのPMを担当している合同会社InkFieldの越口です。

プロダクトの仕様がどのような意思決定の末に決まっているか、利用者様にお伝えすることは難しく、仕様によっては懐疑的な思いを持ってしまうかと思います。透明性を高めることが信頼につながると考えています。大切なことは、どんな問いから始め、何と何を比べ、なぜそう決め、必要なときにどう見直したのか――その過程を説明できることです。

THE NOVELでは、その過程を会議・文字起こし・録画としてすべて残してきました。本コラムでは、開発の舞台裏を公開する理由と、「お客様や営業の声が、どのように機能の要件へ変わっていったのか」をご紹介します。

438回・390時間45分という数字が、示すもの／示さないもの

THE NOVELに関する予定を集計すると、会議は438回、合計390時間45分にのぼりました（8月24日時点）。文字起こしは326本あり、そのうち324本を録画と照合できています。

もっとも、この数字を「開発量の多さ」の証明として使うつもりはありません。会議の回数や長さは、そのまま品質や生産性を証明するものではないからです。

会議の種類	回数・時間	役割
全体定例	232回・191時間45分	事業、お客様の利用場面、UX、データ、実装上の制約を横断して確認する場
開発定例	337回・290時間15分	実装へ落とし込む段階の課題や進め方を詰める場
要件レビュー	59回・58時間30分	要件の不足・矛盾・例外条件を洗い出す場（※「何を作るか」の定義に抜け漏れや矛盾がないかを点検する会議）
AI定例	42回・42時間	分析機能の使い方と、技術的にどこまで実現できるかをすり合わせる場

同じ「会議」でも、そこで解くべき問いはまったく異なります。この内訳が示しているのは、THE NOVELの開発が単一チームの作業ではなく、領域を横断した意思決定の連続だったということです。そして326本の文字起こしは、「なぜその機能を先にしたのか」「なぜこの要件としたのか」「どの制約を受け入れたのか」を後から確かめるための材料として残しています。

記録は、ただ決定事項を残すためではなく、必要な見直しを可能にするために残す。これがTHE NOVELの基本姿勢です。

営業・顧客の要望を、そのまま実装しない ―― 「声」を要件に翻訳するプロセス

お客様や営業担当から届く声は、プロダクト改善のもっとも重要な入口です。しかし、言われた内容をそのまま作ればよい、というわけではありません。声が要件になるまでには、いくつもの確認が必要になります。

まず、最初に行う最もオーソドックスな分岐は、「不具合なのか、追加のご要望なのか」です。当初の仕様に含まれていたはずの動作が欠けているなら不具合ですが、仕様になかった操作を求めるものなら追加要望です。分類が違えば、優先度も担当も見積もりもリリース計画も変わります。
ある会議では、一度「要望」として整理したうえで、本当にその扱いでよいかを関係者へ改めて確認していました。この一手間は、声を弱めるためではなく、後の認識違いを減らすためのものです。

次に起こるのは、言葉の転記ではなく「翻訳」です。たとえば「契約内容を変更したい」というご要望だけでは、実装はできません。操作するのは誰か、反映は即時か、管理画面で何を選ぶのか、既存のデータへどう影響するのか――こうした点まで分解して、はじめてシステムの振る舞いになります。
実際、案件の内容を画面で確認する会議では、表示対象・全選択・戻る操作・データがない場合のスキップといった、抜けていた条件をその場で補っていました。一つの画面に見えても、業務の言葉を「例外を含む画面の動き」へ変える作業が必要なのです。

こうした「声を業務の言語に翻訳する」作法は、技研商事インターナショナルが商圏分析のコンサルティングを通じて長年担ってきた仕事そのものでもあります。お客様の漠然とした困りごとを、分析できる問いへと組み立て直す。その蓄積が、THE NOVELの要件定義にも流れ込んでいます。

現場の使いやすさを、要件にする ―― 「次に何をすればいいか分からない」を拾う

利用者視点は、完成後に付け足すものではありません。THE NOVELの会議では、非エンジニアの視点が、要件を決める途中に何度も入ってきました。
ここでいう「非エンジニアの参加」とは、専門知識のない人が感想を述べることではありません。誰が、どの端末で、どの順番に操作し、何につまずくのかを定義することです。

ある受け入れ確認では、表示されたエラーメッセージが利用者にとって不親切で、「次に何をすればいいのか分からない」という問題が挙がりました。機能が止まるかどうかだけで判定すれば、軽微な要望に見えるかもしれません。しかし、利用者が自力で復旧できない表示は、問い合わせや作業の中断につながります。この問題は、その場の感想で終わらせず、Backlog（※対応予定の課題リスト）へ登録され、開発案件化されました。

また開発定例では、店舗開発の現場で使われる可能性のあるノートパソコンの画面解像度が論点になりました。高いスペックを前提にすれば実装は整理できますが、現場の担当者が必ずしも高性能な端末を使うとは限りません。

チームは現象をすぐに「バグ」と断定せず、回避経路・最低利用条件・改修の優先度を確認したうえで、その時点では「要望」として管理する判断をしました。障害・仕様・改善要望を区別して記録すること自体が、後で見直せる開発のために欠かせません。

競合との違いは、機能の数ではなく「出店判断の現実」から始まる

メンバーインタビューでは、「THE NOVELは他のツールと何が違うのか」を聞きました。話の中心になったのは、派手な機能の数ではなく、利用者が迷わず分析を始められることでした。

「おすすめ変数セット」の存在

THE NOVELには、人口、世帯、所得・消費、周辺店舗など、分析に使えるデータが数多くあります。ただ、項目を並べて「自由に選んでください」とするだけでは、どこから手をつければいいか迷う担当者も少なくありません。

商圏分析に慣れた方であれば自分で変数を選べますが、すべての利用者がそうとは限らない。そこで用意したのが「おすすめ変数セット」です。技研商事インターナショナルが長年の商圏分析や売上予測案件で試行錯誤してきた知見をもとに、業種をまたいで使いやすい変数をまとめました。これはAIが考えた正解ではありません。今までの実務のなかで何が売上の違いを説明しやすかったかを積み重ね、分析の出発点として組み込んだものです。

モデルに対する"納得感"を得られる設計

一方で、おすすめ変数セットをそのまま押しつけるつもりもありません。売上を説明する変数に納得できなければ、いくら精度が高くても、社内の出店判断には使いにくいからです。利用者が変数を見直し、重回帰分析と機械学習の結果を比べられるようにしているのは、モデルに対する"納得感"をしっかりと得られるようにするためです。

多くの店舗開発では、学習に使える既存店が何万店もあるわけではありません。限られた店舗数でも、現場が慣れ親しんだ考え方と新しい分析手法を行き来しながら、結果を説明できることが重要です。

THE NOVELが目指しているのは、人の代わりに判断を行うAIではなく、人が判断の根拠を確かめられるAIです。

すべての競合ツールを網羅的に比較した結論ではありません。それでも、「商圏分析のノウハウ」が詰め込まれている点、分析過程を見える化できる点、最後の判断は人に残す点――この三つを一つの流れとして実装していることに、THE NOVELらしさがあると考えています。

判断を説明でき、見直せることを大切にする

THE NOVELができるまでに積み重ねた438回・390時間45分。その意味は、会議の多さではなく、お客様の業務・UX・データ・技術の間で行われた判断を、後からたどれることにあります。

私たちが目指すのは、「間違えない開発」を装うことではありません。なぜそう決めたのかを説明でき、新しい事実が見つかれば見直せる開発であること。その過程を開いていくことが、THE NOVELへの信頼をつくる第一歩になると考えています。

次回は、その中核である商圏分析の知見を、AIとレポートへどう落とし込んだのかをご紹介します。

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