画面を見せて「普通に使えますよね」と確認したのに、あとでだいたい揉める
こんにちはあるいはこんばんは
システム開発では、完成前の画面を利用者に見せることがある。
申請内容を入力する。
登録ボタンを押す。
上司が承認する。
処理が完了する。
実際に操作してもらうと、仕様書を読んでもらうだけでは出てこなかった意見が出てくる。
「この項目名は少し分かりにくいですね」
「このボタンは右側にあった方が使いやすいです」
「一覧には受付日も表示してほしいです」
意見を反映して、もう一度画面を見せる。
そして最後に聞く。
「この形なら、普通に使えそうですか」
利用者は画面を見ながら答える。
「はい。普通に使えると思います」
画面も見せた。
実際に操作もしてもらった。
指摘された部分も修正した。
だから、認識はそろったはずだった。
それでも、本番が近づくと話が変わることがある。
確認したのは画面で、確認していなかったのは使えなくなる場面だった
利用者に見せたのは、申請を登録し、承認し、処理を完了するまでの流れだった。
正しい内容を入力する。
決められた順番で操作する。
予定していた担当者が処理する。
画面は問題なく動いた。
けれど、実際の仕事はいつも予定どおりには進まない。
入力途中で別の仕事が入る。
登録後に間違いへ気づく。
承認する人が休んでいる。
そこで利用者から言われる。
「入力途中の内容は残らないんですか」
「承認する人が休みなら、代理の人が処理できますよね」
「間違えて登録したら、普通は直せますよね」
開発側から見ると、そこまでは仕様に書かれていない。
利用者側から見ると、業務で使うなら当然できると思っていた。
どちらかが嘘をついているわけではない。
ただ、お互いが考えていた「普通」の範囲が違っていた。
早く見せることと、深く確認することは同じではない
プロトタイプ開発やアジャイル開発では、早い段階で利用者に画面を見せられる。
文章だけで仕様を確認するより、実際の画面を触ってもらった方が、認識のズレは見つけやすい。
プロトタイプやアジャイルが悪いわけではない。
むしろ、早く確認できることには大きな価値があると思う。
ただし、早く見せることと、深く確認することは同じではない。
画面が具体的になると、利用者の視線は目に見える部分へ向かう。
項目名は分かりやすいか。
ボタンは押しやすいか。
一覧に必要な情報が表示されているか。
どれも大切な確認だと思う。
ただ、その画面を誰が、いつ、どんな状況で使うのかまでは、画面を普通に操作しているだけでは見えにくい。
画面を確認したことと、業務が続けられることを確認したことは、同じではない。
画面があるからこそ、確認した気になる
文章だけの仕様書を読んでいるときは、お互いにまだ曖昧な部分があると警戒しやすい。
けれど、実際に動く画面を見ると、少し安心する。
形になっている。
操作もできる。
利用者から意見も出た。
その意見も反映された。
ここまで進むと、まだ確認していない部分まで、確認できたような感覚になる。
画面が具体的になるほど、確認できた部分は増える。
その一方で、画面に映っていない条件まで、確認したような気になってしまう。
「普通に使えますよね」という言葉が危ないのは、曖昧だからだけではない。
お互いが同じ意味だと思ったまま、会話を終えられてしまうからだと思う。
利用者の「普通」には、仕事を続けられることまで含まれている
開発側が考える「使える」は、決められた機能が正しく動くことになりやすい。
入力できる。
登録できる。
承認できる。
結果を確認できる。
一方で、利用者が言う「普通に使える」には、機能が動くことだけではなく、少し予定外のことが起きても仕事を続けられることまで含まれている場合がある。
途中で作業を中断しても、続きを始められる。
担当者が休んでいても、別の人が処理できる。
操作を間違えても、必要なところまで戻せる。
利用者にとっては、それらも特別な機能ではない。
毎日の仕事を止めないために、普通に必要なものなのだと思う。
「問題ありませんか」では、問題は出てこない
画面を見せながら、
「この画面で問題ありませんか」
と聞いても、多くの場合は「問題ありません」と返ってくる。
まだ起きていない問題を、その場で想像するのは難しいからだ。
「普通に使えますか」と聞くのも同じかもしれない。
普通という抽象的な言葉に対して、利用者も抽象的に答えるしかない。
必要なのは、普通ではなくなる場面を置くことだと思う。
たとえば、画面を操作してもらいながら聞いてみる。
「ここまで入力したところで別の仕事が入ったら、内容は残っていた方がいいですか」
「承認する人が今日いなかったら、この仕事は明日まで止めても大丈夫ですか」
「登録後に間違いへ気づいた場合、本人が直しますか。それとも管理者へ連絡しますか」
こう聞かれて初めて、利用者も実際の仕事を思い浮かべられる。
画面を操作してもらうだけではなく、その画面で困る場面を一つずつ試してみる。
そこで初めて、お互いの「普通」の違いが見えてくる。
早く作るより、早くズレる
プロトタイプやアジャイルの価値は、最初から正しいものを作ることではない。
お互いの認識が違うことを、修正できる段階で見つけることにある。
早く作ることより、早くズレること。
ズレが早く見つかれば、画面も仕様もまだ直せる。
完成後に、
「そんなつもりではなかった」
と言い合うより、ずっと小さな手戻りで済む。
だから、プロトタイプを見せた後に確認すべきなのは、
「この画面で問題ありませんか」
だけではない。
途中で作業を止めたらどうなるのか。
予定していた人がいなければどうするのか。
操作を間違えたら、誰がどこまで戻すのか。
普通という言葉を禁止する必要はない。
ただ、その普通が崩れる場面を、手戻りが小さいうちに試してみる。
SEの仕事は、画面を早く見せることだけではない。
お互いの「普通」が違うことを、早く見つけることなのかもしれない。
あなたの職場では、
「普通にできると思っていた」
という言葉から、仕様のズレが見つかったことはないでしょうか。
用語について
プロトタイプ開発
完成前に簡易的な画面や試作品を作り、利用者の意見を確認しながら仕様を固める進め方
アジャイル開発
機能を小さな単位で作り、利用者からの確認と改善を繰り返しながら開発を進める考え方
関連して書いた記事
業務フローを描くだけでは、顧客はまだその中を歩いていない
