makotan _at_ gmail dot com

画面先行のメリットと罠

この数年時々思ってたことを・・・

画面先行とは

画面設計・画面モックなどをデータモデル・業務フローに先だって設計・確定する事
「ユーザが理解できるのが画面でデータモデルとか業務フローなんて見せても理解できないから」というのが大抵の採用理由
ユーザにとって一番理解しやすいのは画面だし、データモデルとか業務フローを見たところで最終的にどういう物が出来上がるのか理解出来ないといのもある程度までは正しいと思う。
データモデルとか業務フローはシステムの構造の話であって、最終的にユーザが日常的に使うものでも無いしね。

画面先行のメリット

  • ユーザが理解しやすい
  • 意見も出やすい
  • 実装前なので修正も楽
  • 進んでる感じが強く出る

実際に画面しかイメージできないユーザも居るので、画面を作ること自体は必要だと思う

画面限定の罠

画面だけを先行することで、データモデルとか業務フローを考慮していない場合の罠

  • つじつまが合わない
  • いつまでも画面の話だけになって先に進まない
  • ちゃんとデザインされた画面を見ると一瞬これで良いかなって気になる
  • 結果的に正しいデータモデルとか業務フローが洗い出せなくなる

罠に陥る理由

一見仕事に使えそうな画面があることでその改善を言うことは出来る
元々業務に合わない画面をどうやって業務に合わせるか(改善)を中心に話が進む
結果的につじつまが合わない部分が発生する
つじつまを合わせるためにあっちこっちを変更し始めてさらに繰り返す
そして画面修正地獄に落ちる

罠に陥らないためにどうするか

  • データモデルと業務フローは早めに設計する事(可能なら画面の前のヒアリング段階でアウトラインだけは作り上げる)
  • 画面がどうしても必要ならデータモデルと業務フローから導き出したレビューに必要最小限の画面を見せる
    • 話し合いの場には画面と一緒に必ずデータモデルと業務フローを同席させる
    • 修正箇所はデータモデルと業務フローへ反映させてから画面に反映させる事
  • 画面を見せる理由はデータモデルと業務フローのためだと意識すること

最後に

ここ数年いろんな物を見ながらそのたびに思ってて書いてなかったなぁ〜って思ったので書いてみた。