たとえば、社内の問い合わせ対応を効率化するために新しいシステムを導入する、という想定例を考えてみます。担当者は「チャットボット機能」「FAQ検索機能」「問い合わせ履歴の自動分類機能」など、欲しい機能を一覧にして開発会社に相談することが多くあります。しかし、この進め方には落とし穴があります。機能を先に決めてしまうと、実際に使う人の業務の流れと合わず、完成後に「使いにくい」「結局エクセルに戻した」という事態が起きやすいからです。
要件定義とは、システムに何をさせるか、どこまで対応するかを言語化して関係者と合意する工程です。この工程で最初に固めるべきは機能のリストではなく、「誰が」「どの場面で」「どんな目的で」使うのかという利用者像です。利用者像が曖昧なまま機能を決めると、開発が進んでからの仕様変更や作り直しが発生しやすくなります。
なぜ機能より先に利用者を決めるのか
同じ「問い合わせ履歴を見る」という機能でも、コールセンターの担当者が1件ずつ丁寧に確認したい場合と、管理者が月次で傾向を把握したい場合とでは、必要な画面も操作の手順もまったく異なります。前者は入力のしやすさや検索のしやすさが重要になり、後者は集計やグラフ表示が重要になります。利用者像を決めずに機能だけ決めると、どちらの要求にも中途半端に応える仕様になりがちです。
利用者像を確認する際は、次のような質問が有効です。
この機能は、日常的に使う現場の担当者向けですか、それとも月に数回確認する管理者向けですか。
この一問で、操作の簡単さを優先するのか、情報の網羅性を優先するのかという設計の方向性がかなり絞り込めます。
開発が必要な場合と、既存の仕組みで足りる場合
利用者像を整理した結果、必ずしも新規開発が必要とは限りません。判断の目安を以下に示します。
既存サービスや運用改善で足りる条件として考えられるのは、利用者が少人数で固定されている、操作の手順が単純で変更が少ない、既存のツール（表計算ソフトやグループウェア）で業務の流れを再現できる、といった場合です。この場合は新規開発よりも、既存ツールのテンプレート化やルールの明文化で改善できることがあります。
開発を検討する条件として考えられるのは、利用者の人数や役割が複数に分かれていて権限管理が必要、入力や確認の件数が多く人の手作業では時間がかかりすぎる、既存ツールでは情報の受け渡しに漏れや二重入力が発生している、といった場合です。こうした状況では、利用者ごとの画面や通知の仕組みを設計し、業務全体の手戻りを減らすための開発が選択肢になります。
利用者像を具体化する手順
利用者像を具体化するには、まず業務に関わる人を役割ごとに書き出します。次に、それぞれの役割が「何を達成できれば業務が終わったと言えるか」を一文で書きます。最後に、その達成までにどんな確認や承認が必要かを順番に並べます。この作業は開発会社に依頼する前に、社内だけでも進められます。
このとき、役割ごとの達成条件が曖昧な場合は、次のような確認が役立ちます。
この作業が終わったと判断するのは誰で、何を見て判断していますか。
この質問に答えられない工程は、要件定義の段階で要注意箇所として扱うべきです。システム化しても判断基準が曖昧なままでは、結局は人の確認作業が残ってしまいます。
要件定義を進める際のチェックリスト
以下は、要件定義に入る前後で確認しておきたい項目の例です。社内での準備段階として活用してください。
- 業務に関わる役割（担当者、管理者、承認者など）をすべて書き出したか
- それぞれの役割が、何をもって「完了」と判断しているかを言語化したか
- 利用者ごとに必要な情報と、不要な情報を分けて整理したか
- 現在の業務で手戻りや二重入力が発生している工程を特定したか
- 既存ツールの運用改善だけで解決できる範囲を見極めたか
- 開発が必要な場合、優先して解決したい利用者の課題を1つに絞れているか
- 要件定義の合意内容を、関係者全員が同じ言葉で説明できる状態にしたか
要件定義は機能の棚卸しではなく、使う人の業務を言葉にする作業です。この順序を守ることで、開発後の手戻りや利用の定着不足を減らしやすくなります。利用者像の整理やヒアリングの進め方に迷う場合は、第三者の視点を交えて整理することも一つの方法です。