設計者が業務要件を把握していない場合に起こること

 先日、某飲食サービスで出前を頼もうと、Webフォームを入力している時のこと。メニューを入力し、個人情報の半分を入力し終えた頃、問題が起こった。

 住所が自由入力でなくプルダウン選択入力で、該当の番地までは出るが号が候補に無いので住所登録ができず注文を断念したのだ。

 (お腹が空いていたので)これはあんまりだと思って、興味の赴くまま何気なく住所補完入力サービスへのリクエストを見てみた。内部処理は分からないが、エリアコードから成るパラメタに応じて、静的なリソースから候補となる丁・番地・号をインクリメンタルに絞り込み検索しているようだった。


 「客の届け先住所を取得/保管できない」というのは、受注システムとしては業務遂行に関わる欠陥だが、より一般的に、

想定される選択肢が無く、処理が中断させられる

このような問題への対策方針として、やや型式張った用語に、Graceful degradationというのがある。気になった方は調べてみて欲しい。
 今回は、注文する人の住所が(その時点で取得できる候補として)あるか無いかに応じて処理が中断されることが問題になり、そのような対策としてしばしば自由入力を導入する。以下は同様の問題をはらんでおり、補完入力自体は便利だが、自由入力の選択肢を設けることで回避される:

  • 屋号・会社名称
  • 年号
  • 住所

さて(システム)業務要件とは、業務を遂行するためにシステムが満たすべき性能や提供すべき機能のことを言う。「住所を記録する」という基本的と思われる業務でも、利便性、効率化、それに開発コスト削減にばかり目を遣ると、足元をすくわれることが感じられるのではないかと思う。もう少し具体的に説明すると、

利便性は、今回の場合自動補完UIのユーザビリティのことだ。確かに便利だが、候補に無い場合が考慮されていないのであれば、却って無い方が良い。

効率化は、自動補完UIのお陰で住所の正当性確認が事前にできているとして良い(自動補完UIが完璧であればね)ので、目視で確認する工数が減る。しかし上記に書いたように、自動補完UIが完璧であることを前提とするには行政的な面でもハードルがあり、最近まで登記上存在しない番地にできたマンション等への対応はできない。むしろ目視の手間をかけることでサービス業務としては完全性が高まる。

開発コスト削減も危うい。今回の(非常に簡単な)調査で分かったのは、

  1. 設計・開発担当者が異常系ユニットテストをしていないこと
  2. 要件の確認が不十分なこと(自動補完は本当に必要だったか、を確認する手間を惜しんだ?)
  3. 番地探索データベースの信頼できる更新方法を選択していないこと(私のマンションが築三年なので、少なくとも三年はアップデートされていないということになる)

 少し話は変わって、私が行政手続きの電子化をできるだけ早く完備して欲しい立場でありながら ― 業務要件が完全に表現されたシステムという意味での品質保証の観点で ― それが如何に難しいかを考えると、蛇行運転になっても、高くついたとしても、無理もないと考えてしまうのである。