システムの仕様を決める前に：試作品で確かめる業務の課題
申請画面の項目を何十ページも決めたのに、利用者は必要書類を集められず、画面までたどり着けない。これは架空の企画ですが、仕様書を詳しくする前に考えたい問いを示しています。何を入力させるかを決める前に、申請を始められない理由を確かめる。そのために、どんな試作品を作ればよいのでしょうか。
ここで選ぶのは、仕様書を捨てるか、試作品だけで開発するかではない。何がまだ不明なのかを分ける。利用者がどの順で行動し、どこで迷うか不明なら、試作品を先に使う価値がある。法定の入力項目や既存システムとの接続が既に確定し、利用者の行動を理解しているなら、詳細仕様と実装上の検証へ進める。試作品を万能の正解探しにしない。
この記事の目次
試作品を作る前に、何を確かめるか決める
「このシステムは使いやすいか」という広い問いのまま試作品を見せると、色や言葉遣いへの感想が集まり、重要な業務の失敗を見落とす。例えば、申請者が資料を提出できるか、承認者が例外の理由を読めるか、差し戻し後に修正箇所へ戻れるかを別々に問う。どの問いに対する結果かを記録すれば、直す場所も分かる。
試す相手に答えを教えないことも必要だ。「このボタンから送信してください」と誘導すれば、ボタンの発見しやすさは検証できない。仕事の目的と必要な資料だけを渡し、何を考えてどこへ進んだかを観察する。一方、実際の仕事で受ける上司の指示まで取り除けば、現実の条件から離れる。補助が通常の手順の一部なら、その補助を含めた試験も別に行う。
画面を試すか、技術の成立を試すか
仮に社内の経費申請で、社員が必要な証憑をいつ用意し、上長が何を見て承認するか意見が分かれているとする。入力項目を先に確定すると、前提を誤る危険がある。短い試作品に実際の領収書に似たダミーデータを使い、提出から差し戻しまで試す。ここで見つかった迷いを受けて、仕様の範囲を変える方がよい。
条件を変える。法令や契約で必要な項目、使用する社員の作業順序、既存データとの対応が既に確認できている。残る主な疑問が大量データの処理速度なら、画面試作品を繰り返すより、性能試験へ移る。前者は利用行動を疑い、後者は技術の成立を疑う。同じ「検証が必要」でも、作るものと費やす時間は逆になる。
感想だけでなく、仕事を終えられるかを見る
英国GOV.UKのサービスマニュアルは、実装へ確約する前に複数の案を試し、利用者と共有・検証するよう求める。紙のスケッチと実際に動く画面では検証できることが違う。大まかな流れを相談するならスケッチで足りる。入力やエラーの理解を見たいなら、現実に近い操作が必要になる。一方、その資料は試作品のコードを本番サービスへそのまま使わないよう注意する。
米国のDigital Services Playbookも、利用者の目標・行動を初期から調べ、実際の人で試作品を試し、発見を記録して優先することを勧める。両方とも公的デジタルサービスの実務指針であって、日本の全てのBtoBシステムで試作品が何％の費用を節約するという実験結果ではない。利用者が現実の仕事をする条件を調べ、作るものを早く疑うという方法を借りる。
試作品で「好きですか」と聞くだけでは足りない。実際の申請に近い前提を渡し、必要資料を見つけ、誤りに気づき、最後の結果を確認できるかを見る。参加者の感想と、行動として完了できたかを区別する。依頼した人が同席して助ければ、自力で使えたという証拠にはならない。紙の案を見て操作時間を推定しても、実際の性能を測ったことにはならない。
誰に試してもらうかで、見える問題が変わる
企画担当だけに試作品を見せると、入力する人や差し戻しを受ける人の困りごとが抜ける。頻度の高い利用者だけに聞けば、初回利用者が迷う箇所を落とす。必要な支援を受ける人や特殊な申請をする人も、対象となる仕事に応じて含める。ただし、少数の観察結果から全国の利用者の割合を推定しない。見つけた問題が何か、どの場面で起きたかを記録する。
依頼者が「この案で進めたい」と先に決めている場合、試作品は承認を得る儀式になりやすい。少なくとも比較する別案か、現行のやり方を用意する。どの結果なら案を捨てるかを始める前に決める。結果が悪くても好意的なコメントだけ拾えば、試した意味がない。
画面が動いても、本番で使える証拠にはならない
本番の負荷、個人情報の保護、障害時の復旧、他システムとの境界を、見た目が動く画面だけで証明できない。試作品が利用者の行動を確かめる道具なら、性能や安全性は別の技術検証が要る。「画面で迷わなかった」から採用の全条件を満たしたとは言えない。試作品の狭い成功を、大きな開発契約の成功へ飛躍させない。
逆に、技術面だけ先に作り込み、利用者が必要としない仕事を速く処理できても価値は低い。企画段階では行動の不確実性と技術の不確実性を並べ、どちらが次の意思決定を止めているか見る。答えを得たら次の検証へ移る。試作品を何度も作ること自体を成果にしない。
少数の観察から、利用者全体の割合は推定しない
小さな試験で見つけた迷いや誤解は、設計を直す材料になる。一方、その発生率を利用者全体へ推定するには、対象集団と別の測定が必要だ。需要の規模は購買意向と実際の選択、本番への適用条件はPoC後の判断と分けて検討する。
うまく使われなかったとき、何を戻すか
案がうまく使われなかった場合、説明を追加すれば済むとは限らない。利用者が必要資料を手に入れられないなら、入力画面を磨くより資料の取得経路を変える。承認者が判断できないなら、表示項目の問題か、権限と業務ルールの問題かを調べる。試作品は解決策の微修正だけでなく、企画の前提を捨てるためにも使う。
一方、限られた参加者が初見で迷っても、訓練を前提とする専門作業なら、それだけで中止とは限らない。訓練を受けた人の実際の作業、誤操作したときの回復、教育に要する時間を試す。初回の印象だけで価値を決めず、対象者が現場で責任を持てるかを確認する。
確かめた結果を、仕様へ引き継ぐ
試作品で問題を見つけた後、仕様を詳しくすることは必要だ。利用者が仕事を終える流れ、画面外の手順、例外の扱い、データ項目、権限、試験条件へ落とす。試作品をそのまま仕様と呼ぶと、動かなかった裏側の前提が消える。観察した行動と、設計者が推測した解決策を分けて文書に残す。
編集上の提案は、詳細仕様へ進む前に「いま変わり得る判断」を一つ書くことだ。利用者の流れに不安があり、設計を安く戻せるなら、現実に近い仕事で試作品を試す。行動面の前提が十分に確かめられ、残る不安が性能や運用なら、その検証へ進む。試作品を成功の証明として売るのではなく、誤った企画へ早く気づく手段にする。
冒頭の申請で資料を集められないなら、画面の項目を増やしても解決しない。資料の取得経路を変える必要があるかを確かめ、その結果を業務と画面の仕様へ戻す。試作品を作ったことより、最初の問いに何が分かったかが、次へ進む材料になる。