顧客からシステムの要望を聞くとき、最初から「この画面をこう変更してほしい」「この機能を追加してほしい」と具体的に話してもらえるとは限りません。
私もアプリSEとして顧客と話す中で、「今の画面が使いにくい」「こういうことができないか」といったところから、具体的な変更内容を詰めていくことがありました。
そのようなとき、私は話を聞くだけで仕様を決めるのではなく、
- 現行システムを実際に確認する
- 必要な機能と不要な機能を整理する
- 画面から見えない処理は資料を確認する
- 現行と変更後を比較する
- 必要に応じてモックを作る
といった方法を組み合わせながら認識を合わせていました。
ここでいう「モック」とは、完成したシステムを作る前に、画面の見た目や項目の配置などを確認するための仮の画面です。
この記事では、顧客の要望が曖昧だったときに、私がどのように現行システムを確認し、変更内容を具体化していたのかを実務経験から紹介します。
まず現行システムを実際に確認していた
要望が曖昧なとき、私はまず現行システムを確認していました。
顧客に実際の画面を見せてもらいながら、
「どこが操作しにくいのか」
「今はどのように使っているのか」
といったことを聞いていました。
画面を見ながら話すと、言葉だけでは分からなかった使い方が見えてくることがあります。
また、新しい機能を追加することだけを考えていたわけではありません。
現行システムにある機能について、
「この機能は必要ですか」
と確認し、不要であれば変更後のシステムから削除することもありました。
システム変更というと機能を増やすイメージがありますが、実際には使われていない機能を整理することもありました。
IPAの「ユーザのための要件定義ガイド 第2版」では、「要望と要求の切り分け」として不必要な要望を検討対象から外すことや、現状業務を把握・理解することがポイントとして示されています。
画面から見えない処理は資料を探して確認していた
現行システムを確認しても、画面だけですべてが分かるわけではありません。
利用者から見えるのは画面上の動きですが、その裏では別の処理が動いていることがあります。
そのような部分については、既存の資料を探して確認していました。
画面だけを見て新しい仕様を考えてしまうと、裏側で行われていた処理を見落とす可能性があります。
そのため私は、顧客から聞いた内容、実際の画面、既存資料を組み合わせながら、現在のシステムがどう動いているのかを確認していました。
PowerPointで現行と新規を比較することもあった
変更内容を具体化するときには、PowerPointを使って現行システムと変更後の案を比較することもありました。
単に、
「今はこの画面です」
「変更後はこの画面です」
と見た目だけを比較するわけではありません。
現行システムについて、
- どの部分で機能面を優先しているのか
- 安全面ではどのような考慮をしているのか
- エラーが発生したときにどのような動作をしているのか
といった点も整理していました。
特にエラー時の動作については、現行でどのような処理や対応をしているかを洗い出し、変更後にはその一部を自動化できないか検討することもありました。
こうして現行と変更後を並べて見ると、「何を変えるのか」だけでなく、「何を残すのか」「どこを改善できるのか」も話しやすくなりました。
モックを見せると顧客の反応がかなり変わった
画面の変更を伴う場合など、言葉だけでは認識を合わせにくいことがありました。
そのようなとき、私は実際にWebブラウザで見られる程度のモックを作ることがありました。
見た目は実際のWeb画面に近くても、画面遷移や本物の処理は動かない“張りぼて”です。
ただ、ボタンや入力項目の位置、画面全体の見え方などは具体的に確認できます。
私の経験では、このモックを見せると顧客の反応がかなり変わりました。
それまで要望をうまく言葉にできていなかった人でも、実際の画面を見ると、
- ここをこうしたい
- これはいらない
- こんな機能はないか
といった質問や修正案が一気に出てくることがありました。
口頭や文章だけで話していたときには出なかった内容が、画面を見せることで具体的になることがあります。
私にとってモックは、完成品に近いものを見せるためというより、顧客から具体的な意見を引き出し、認識を合わせるための道具でした。
デジタル庁の「DS-671.1 ユーザビリティ導入ガイドブック」では、ワイヤーフレームやペーパープロトタイプに加え、HTMLレベルまで組み上げた静的プロトタイプをブラウザで確認して検証する方法が紹介されています。
デジタル庁「DS-671.1 ユーザビリティ導入ガイドブック」
まとめ：曖昧な要望は、確認できる材料を増やしながら具体化していた
顧客の要望は、最初から完成した仕様として出てくるとは限りません。
私も実務では、現行システムや既存資料を確認し、現行と変更後を比較しながら、要望を具体化していました。
特に言葉だけでは認識を合わせにくい場合、実際に画面として見られるモックを用意すると、顧客から具体的な質問や修正案が出やすくなると感じていました。
最初に聞いた要望だけで仕様を決めるのではなく、確認できる材料を増やしながら認識を合わせていくことを意識していました。
