遷移図の次は、フォームの中身
前回のH-03では、画面から画面への経路を遷移図として設計しました。今回はその経路の中でも、利用者が最も手を動かす場所であるフォームの中身を設計します。フォームは作ろうと思えばいくらでも項目を足せますが、足すほど利用者は離れていきます。だからこそ、何をどう聞くかを設計として先に決めることが、完了までたどり着けるアプリの分かれ目になります。
このスライドのポイント
- H-03では、画面から画面への経路を遷移図として設計した
- 今回はその経路の中で、利用者が最も入力する場所＝フォームの中身を設計する
- フォームはいくらでも項目を足せるが、足すほど利用者は離れる
フォーム設計の6要素
フォーム設計とは、次の6つの要素を決めることです。1つ目は項目、つまり何を聞くか。2つ目は必須項目か任意項目かの区別で、必須項目とは無いと処理が成立しない項目、任意項目とは無くても進められる項目です。3つ目は初期値で、これは最初から入力欄に入っている値のことです。4つ目は形式、G-04で見た入力部品のどれを使うか。5つ目は補足説明、例や単位の案内。6つ目は送信条件、何が揃えば送れるかです。この6つを決めることが、フォーム設計そのものです。
このスライドのポイント
- ①項目: 何を聞くか
- ②必須項目・任意項目: 無いと処理が成立しない項目が必須、無くても進める項目が任意
- ③初期値: 最初から入力欄に入っている値
- ④形式: G-04で見た入力部品のどれを使うか
- ⑤補足説明: 例・単位などの案内
- ⑥送信条件: 何が揃えば送信できるか
丸投げが生む「離脱するフォーム」
この6要素を決めずにAIへ「申請フォームを作って」と丸投げすると、どうなるでしょうか。多くの場合、項目が多すぎて、しかも全部が必須で、初期値も無いフォームができあがります。これは利用者が途中で離脱してしまう典型的な形です。項目を1つ増やすごとに、最後まで入力してくれる割合は下がっていきます。フォームは足し算ではなく引き算で設計する、という感覚を持つことが必要です。
このスライドのポイント
- 6要素を決めずにAIへ「申請フォームを作って」と丸投げすると起きること
- 項目過多・全部必須・初期値なしのフォームができあがる
- 項目を1つ増やすごとに、完了率は下がる
- フォームは足し算ではなく引き算で設計する
設計とは、項目設計表を埋めること
フォーム設計の中心にあるのは、項目設計表です。表の列は、項目名・必須か任意か・初期値・形式・補足の5つ。行は聞きたい項目の数だけ並びます。設計するとは、この表のすべてのマスを埋めることだと考えてください。頭の中で「なんとなく良い感じのフォーム」を思い浮かべるのではなく、表という形にすることで、項目の抜けや過剰がその場で目に見えるようになります。
このスライドのポイント
- フォーム設計の中心にあるのは項目設計表
- 列は「項目名／必須か任意か／初期値／形式／補足」の5つ
- 行は聞きたい項目の数だけ並べる
- 設計する＝この表のすべてのマスを埋めること
経費申請フォームで考える
具体例として、経費申請フォームを考えます。日付の欄は、多くが今日の申請ですから、初期値を今日に設定しておけば、利用者はそのまま触らずに済みます。区分の欄は、自由入力ではなく選択式にして、よく使う区分を上のほうに並べます。金額の欄は数値の入力欄にして、円という単位を添えます。ここで最も強い設計の原則は、聞かなくて済む項目は聞かない、ということです。初期値で埋められる項目を利用者に入力させない工夫が、完了率を大きく左右します。
このスライドのポイント
- 日付: 多くが今日の申請なので初期値を今日に。触らずに済む
- 区分: 自由入力ではなく選択式にし、よく使う区分を上に並べる
- 金額: 数値の入力欄にして「円」の単位を添える
- 最強の原則: 聞かなくて済む項目は聞かない
技術サンプル: 経費申請の項目設計表
こちらが、経費申請フォームの項目設計表です。日付は必須で初期値を今日に、区分は必須で選択式、金額は必須で数値入力、領収書は必須でファイル添付、備考だけを任意にしています。この表の読み方で大切なのは、表そのものがAIへの指示書になるという点です。曖昧に「フォームを作って」と頼むのではなく、この表を渡して、表のとおりに作り、表に無い項目は追加しないでください、と伝えます。AIへの質問例は、まさにその一文です。
このスライドのポイント
- 種別: table
- 目的: 経費申請フォームの項目を、設計として確定する
- サンプル本体:
「便利」と「必須」を混同しない
混同しやすいのが、「聞けると便利」と「聞かないと処理できない」の違いです。前者は作り手の都合であり、後者こそが必須項目の本当の定義です。たとえば経費申請で、部署名を聞ければ集計に便利だと感じるかもしれません。しかし、それが無くても申請という処理自体は成立するなら、それは必須項目ではなく任意項目です。必須項目を乱発してしまう原因の多くは、この「便利だから」という作り手都合の混入にあります。
このスライドのポイント
- 「聞けると便利」＝作り手都合
- 「聞かないと処理できない」＝必須項目の本当の定義
- 例: 部署名は集計に便利だが、無くても申請は成立する→それは任意項目
- 必須の乱発は、この作り手都合の混入から起こる
バイブコーディングでの確認点
AIがフォームを作ってきたら、項目ごとに一つずつ確認してください。この項目は本当に必須ですか、これが無いと処理が止まりますか、と問うのです。AIは指定がなければ、多くの項目を安全側に倒して必須にしがちです。必須の印が並んだフォームを見たら、その一つ一つに、無いと処理が成立しないという根拠があるかを人間が確かめます。任意でよい項目を任意に戻すだけで、利用者の負担は目に見えて軽くなります。
このスライドのポイント
- AIが作ったフォームは、項目ごとに一つずつ確認する
- 確認の言葉:「この項目は本当に必須ですか。無いと処理が止まりますか」
- AIは指定がなければ、多くの項目を安全側に倒して必須にしがち
- 任意でよい項目を任意に戻すだけで、利用者の負担は軽くなる
まとめと次回
最後に一問一答です。必須にしてよい項目の基準は、何でしょうか。……答えは、それが無いと処理が成立しないこと、です。便利だからという理由は、必須ではなく任意の側に置きます。30秒でまとめます。フォーム設計とは6要素を項目設計表に落とすことであり、聞かなくて済む項目は聞かない、必須は最小限にとどめる、これが完了率を守る鍵でした。次回のH-05では、入力されたミスをその場で知らせるバリデーションへ進みます。関連資料は「フォーム設計パターン50」と「AIアプリ要件定義シート」です。
このスライドのポイント
- 一問一答:「必須にしてよい項目の基準は？」
- 30秒まとめ: フォーム設計＝6要素を項目設計表に落とす。聞かなくて済む項目は聞かない。必須は最小限に
- 次回H-05: 入力ミスをその場で知らせるバリデーションへ
- 関連資料: 「フォーム設計パターン50」「AIアプリ要件定義シート」
