こんな画面設計は失敗だ

投稿者: | 2021年2月11日

以前参画していたプロジェクトでの話です。この画面設計はダメだ、と言われる典型的な例がありました。今回はそんな画面設計の失敗例を書いてみます。画面設計(≒要件定義)をする際にどこに注意するべきかが見えてくるはずです。

なぜ失敗した画面設計だったのか

その画面を使う人の状況を無視しているからです。画面設計をした中堅SEは画面に使う部品をなんとなく配置して一見それらしい画面設計をしましたが、レビュアーは一目みて「これでは使えない」という判断を下しました。

その画面とは、出荷実績画面というものでした。ここで少しどのような画面なのかを説明しておきます。製造業の基幹システムの案件で開発する出荷実績という画面です。

出荷日が迫ってくると倉庫においてある製品を台車に乗せて集めてきて、段ボールなどに梱包します。配送業者のトラックが来れば載せる前後で、出荷実績を打ちます。出荷実績を打てば、在庫からその数量分が消え、売上が立ちます。

失敗した画面設計は、出荷指示を検索して、実績を打つ対象を選択してボタンを押すだけのものです。(実際にはもう少し検索条件が多いかもしれませんが…)

使えない理由

この画面を使う場面をもう少し考えてみましょう。そう考えれば、この画面が使えない理由がわかってきます。

出荷予定日が近くづくと、おおむね下記のような出荷指示が出ます。梱包するのも手間ですから、当日夕方に配送業者が来るなら前日から出しておくとか、朝までに出しておくなどが必要です。逆に、作業の手が空いたのであれば少し早めに出荷指示をかけて梱包作業をしておいてもいいかもしれません。

一口に出荷場所といっても、そこにはシステムにない運用が隠れていたりします。出荷できるようになり次第なるはやでというお客さんもいるでしょうが、〇月〇日に持ってきてくれといっただろう、早めに持ってくるなというお客さんもいるはずです。(例えば早めに出荷されても、必要になるまで保管する場所を取られてしまうから)

そうなると、今日の分と明日の分は混ざらないように運用されているはずです。出荷指示番号などはバラバラです。

出荷予定日は明日だったけれど、営業担当から電話で「早く」と言われたときに準備ができているなら前倒して出したりもするでしょう。

さて、ここで本日出荷分の段ボールの数が数十個あったら、どうなるんでしょうか。先ほど示したあの画面で、出荷する分を間違えずに選んで、毎日毎日運用できるんでしょうか。

間違えば売上も狂うし、在庫も狂うのですが、正気でしょうか。

ユーザレビューがOKだったとしても…

設計した画面をユーザにレビューしてもらったとしても、そのユーザがシステム開発に慣れていない場合、画面が簡単そうだと「なるほど・・・」だけいってOKのような雰囲気を醸し出します。

しかしいざ運用してみると、使えないという判断を下してきます。この業務を下記のような画面で行うのだとすると、

  • 段ボールに指示書を張り付けておく
  • 出荷前に指示書を剥がす
  • 指示書の番号順に紙をソートする
  • スクロールしながら間違えないようにチェックを入れて出荷する

ということが必要です。毎日です。

出荷予定日で検索できるようにすればよい?

確かにそれも理にかなっています。

ただし、システム上の出荷予定日を出荷業務のために保守しつづけるという前提が守られるのであればです。先ほどのように、前倒しになった場合にその日付を入れる必要があります。結局こちらも、間違えずに毎日入れ続けなければどこかで事故になりえるわけです。

結局どのように解決したのか

出荷場所での段ボールの物理的な管理運用を尊重し、出荷実績を打てるようにします。

出荷指示書を下記のように改めます。この指示書を段ボールに貼り付けて運用しておきます。バーコードのリーダはBluetoothなどでつないで入力できるようにします。

こうすれば、出荷の直前に指示書を回収しつつ、その場で入力していきます。最後に枚数が一致していれば抜けなく売上計上ができます。

おわりに

画面設計は、「外部設計」ともいいます。「外部」とはシステムの外側のことです。システムの外側で、どのような管理や業務、運用がどうされているかを踏まえて、ではシステムではこうしましょうということを整理しなければなりません。

その結果として、アウトプットとして画面設計が決まります。

今回の失敗例のように、システムの外側での運用も考えずにそれっぽい画面設計をすることは、プログラムをコピペで作るのと同じくらい怒られるべきです。