外部のユーザーがログインして動くWebアプリケーション開発の2回目です。前回に続き、食品事業に取り組む参加者がゲスト講師として進行を担い、各参加者がこの1週間で組み立ててきたアプリケーションを画面共有しながら、その場で設計とUIを改修していきました。
作り始める前に5つの条件を言語化し、2週間で使い始める
ワークに入る前に、ゲスト講師から「AIにアプリを作らせる前に、人間側で言語化しておくべき5つの条件」が提示されました。
- 誰が使うか（例：寮の入居者と管理会社、店舗の管理者と一般顧客）
- 何に困っているか（このアプリがあることで、現場のどんな手間や壁が解消されるか）
- 2週間のタイムリミット（開発が2週間を超えると、本来何に使いたかったのかを見失うため、2週間で一度使い始める）
- 必要な項目（名簿や物件情報など、最初に取り込むべきデータ）
- 最低限使える完成の条件（見た目は粗くても、これだけ動けば現場で使えるという最小ライン）
これらを最初の指示文に当てはめ、「まず必要な画面と操作の流れを短く提案してください。不明点があれば作る前に確認してください」とAIに渡すところから始めます。
ここで強調されたのは、「アプリの使いやすさの95%は全体設計で決まり、表面の色合いやアニメーションは最後の5%に過ぎない」という原則でした。ゲスト講師自身、一度作ったアプリをさらに良くしようとして、上位モデルのAIに「使いづらい部分を洗い出して、もっと使いやすいアプリに改良して」と丸投げしたところ、大量のトークンを消費した挙句に画面が複雑化して使い物にならなくなり、すべて元に戻したという失敗談を共有しました。AIに全体の要件定義を丸投げせず、誰が何のために使うかは人間が握る必要があります。
不動産の現地・役所調査をスマホ1台で完結させるアプリ
続いて、不動産事業に取り組む参加者が、わずか2日間で形にした「不動産調査アプリ」の実画面を披露しました。すでに地域の業界団体の集まりでも知人に画面を見せ、「完成したら自社でも使いたい」という声が出始めているものです。
不動産の売買では、役所の各課を回って法令上の制限を調べる「役所調査」と、現地で道路幅や境界標を測る「現地調査」が欠かせません。従来は雨の日でも紙の資料とボールペン、長い巻尺を持って2人1組で記録し、事務所に戻ってから重要事項説明書や調査報告書にまとめ直していました。また、大手と違って研修体制のない中小の不動産会社では、新人が役所に行っても何から調べればいいか分からず1日がかりになり、賃貸専門だった経営者が売買案件で調査手順に迷うといった現場の課題があります。
参加者が作ったアプリは、この調査業務をスマートフォン1台で完結させる仕組みです。
- 自治体ごとに回るべき役所の窓口と必要書類が一覧で分かり、クリアするとスタンプが貯まる
- 現地で境界標や外観の写真を撮り、道路幅などを音声でそのまま入力・保存できる
- 重要事項説明書の作成に必要な全89項目のうち、どこまで埋まっていて何が未完了かが一目で分かる
- 集めた情報を、各社が使っているAIにそのまま貼り付けられるテキスト形式でコピーできるほか、紙の台帳保存文化に合わせてPDFの調査報告書としてワンタップで出力できる
- 取引上は極めて重要でも、見つけて当たり前とされ誰にも褒められない調査上の発見を「お手柄」として記録・カウントし、担当者のモチベーションを高める
まずは法人単位の複雑な権限管理ではなく、個人の調査担当者にフォーカスし、身近な同業者へ月額980円ほどで提供していく構想が語られました。
ボタンは動詞にし、最終的に下のナビゲーション自体をなくす
この不動産調査アプリの画面を見ながら、全員でUIの徹底的な「引き算」を行いました。
最初の画面では、画面下部に「ホーム」「窓口」「写真」「まとめ」「私」という5つのタブが並んでいました。これに対してゲスト講師は、2つの改善点を挙げました。
1つ目は、説明を聞かなくても何ができる場所か直感的に分かるよう、ボタンの言葉を名詞ではなく「報告する」「案件を作る」といった動詞にすること。また、AIが気を利かせて勝手に配置した「続きから」という重複ボタンは、案件名をタップする動作と行き先が同じで混乱するため、即座に削除しました。全員が頻繁に使うわけではない「プロフィール」も下部タブから外し、画面右上のアイコンへ移しました。
2つ目は、タブの統合です。画面をリアルタイムで改修しながら講師がユースケースを整理していくと、さらに本質的な構造が見えてきました。このアプリでユーザーがやることは「調査情報の入力」と「報告書の作成」の2つですが、どちらも必ず「どの物件（案件）か」に紐づきます。つまり、下に「入力」や「報告」の独立したボタンを作っても、押した後に必ず「案件を選ぶ」手順が発生してしまいます。
であれば、画面下部のナビゲーションバー自体を丸ごとなくし、トップ画面に「進行中の案件一覧」と「新しい案件を作る」ボタンだけを置く。そして各案件カードの中に「入力する」「報告書を出す」のボタンを並べるのが最も迷わない——という結論に至りました。
モード切り替えをやめ、現場で分かる順番に入力欄を並べる
入力画面の設計でも、現場目線での引き算が行われました。
当初は、詳しい案内が出る「新人モード」と、素早く入力できる「先輩モード（またはヒントモードのON/OFF）」を切り替えるボタンが上部に置かれていました。しかし、パソコンやスマートフォンが苦手な年配の経営者層が使うことを考えると、モードの切り替え自体がハードルになります。また、新人であっても項目によって知っていることと知らないことは異なります。
そこで、「モード切り替え」のボタン自体を廃止しました。入力項目は全員共通で並べたうえで、専門用語の項目名をタップしたときだけ、その項目の解説や役所で聞くべきポイントが小さなタブで表示される仕組みに変えました。これなら、ベテランがど忘れしたときにもその場ですぐ確認でき、画面からボタンをもう1つ減らせます。
さらに、入力欄を並べる順番も「現場の建物の前に立った瞬間に分かっていること（案件名や物件種別など）」を一番上に置き、「後から測ったり役所で調べたりしないと分からない詳細な数値」を下へ並べる階層構造に整えました。
アプリケーションは「計算機」に徹し、自分のオントロジーとは切り離す
講義の終盤、学習事業の事務局が取り組んでいる「講師スケジュール・給与計算ダッシュボードのデータベース移行」を共有しました。Googleカレンダー上の約300件の授業データをデータベースへ移行する作業を進める中で、実務上の重要な疑問が2つ上がりました。
1つは、「データベースにアクセスするたびにAIのトークン（課金枠）が消費されるのか」という点です。これについては、AIにプロンプトを投げて推論させる時以外はトークンを一切消費しないため、データベースからデータを引っ張って表示したり、複雑な検索や給与計算を行ったりする分には何度アクセスしてもコストはかからないことが確認されました。
もう1つは、さらに本質的な問いでした。「これまで自分のパソコンのオントロジーでは、『何月何日にこういう事情で授業を振り替えた』という曖昧な経緯もAIが全部覚えて気を利かせてくれていた。しかし、新しく作ったWebアプリ1本にしようとすると、そうした細かい文脈が拾えなくなってとてもやりづらい」という悩みです。
これに対する講師の答えは明確でした。「外部の人が使うアプリケーションと、自分が使うオントロジーは、完全に別物として切り離さなければいけない」という原則です。
- オントロジーと自分専用ダッシュボード：自分のパソコン上で育てた「自分専用の相棒」。あらゆる文脈や経緯を含めて、経営者自身の意思決定を助ける場所。
- 外部向けWebアプリケーション：講師や生徒、顧客など、複数の人がログインして使う「出張所」であり、単なる「計算機」。
もし自分が育てた便利なオントロジーをそのまま外部の講師や顧客にも使わせようとすると、システムが複雑になりすぎて破綻するだけでなく、全員の給与データが見えてしまうといった重大な情報漏洩につながります。
だからこそ、外の人が触るアプリケーションは極限まで機能を削り、「振替希望日」や「実施報告」といった確定した事実だけを入力してもらうシンプルな計算機（出張所）にとどめます。そして、データベースに集まった確定データを、事務局自身が毎朝自分のパソコンのオントロジーと専用ダッシュボードに取り込み、AIと一緒に全体の管理や判断を行う——この2段構えの役割分担で全員の認識が一致しました。
この日の到達点
講義の締めくくりに、ゲスト講師と講師の2人がこの日の原則をひとことでまとめました。
「オントロジーは『意思決定をするため』のツールであり、アプリケーションは『ユーザーが意思決定しなくても（迷わなくても）使えるようにするため』のツールである」
画面からボタンと選択肢を引き算し、使う人の意思決定の数をどれだけ減らせるかがアプリ設計の核心です。次回の最終回（第21回）に向けて、各自が引き算の設計を反映したアプリケーションを本番環境へデプロイし、仕上げを行います。
この勉強会について
経営者向けのAX実践スクールとして、SOVREN Frameworkを使った実践を毎週行っています。教材はSOVREN Frameworkで全文を無料公開しています。