先日、某飲食サービスで出前を頼もうと、Webフォームを入力している時のこと。メニューを入力し、個人情報の半分を入力し終えた頃、問題が起こった。
住所が自由入力でなくプルダウン選択入力で、該当の番地までは出るが号が候補に無いので住所登録ができず注文を断念したのだ。
（お腹が空いていたので）これはあんまりだと思って、興味の赴くまま何気なく住所補完入力サービスへのリクエストを見てみた。内部処理は分からないが、エリアコードから成るパラメタに応じて、静的なリソースから候補となる丁・番地・号をインクリメンタルに絞り込み検索しているようだった。
「正確な客の届け先住所を受付/保全できない」というのは、受注システムとしては業務遂行に関わる欠陥だが、より一般的に、
想定される選択肢が無く、処理が中断させられる
このような問題への対策方針として、やや型式張った用語に、Graceful degradationというのがある。気になった方は調べてみて欲しい。
今回は、注文する人の住所が（その時点で取得できる候補として）あるか無いかに応じて処理が中断されることが問題になり、そのような対策としてしばしば自由入力を導入する。以下は同様の問題をはらんでおり、補完入力自体は便利だが、自由入力の選択肢を設けることで回避される:
- 屋号・会社名称
- 年号
- 住所
さて（システム）業務要件とは、業務を遂行するための前提や、その前提の上でシステムが満たすべき性能や提供すべき機能 (またはそれを定めたもの) のことを言う。
「住所を記録する」という基本的と思われる業務でも、利便性、処理効率、開発コスト削減に目を遣り過ぎると、要件が満たせなくなる場合がある。
分解して詳しく説明すると、
利便性は、今回の場合自動補完UIのユーザビリティのこと。操作性の簡略化、入力ミスの回避の点で便利だが、候補に無い場合が考慮されていないのであれば問題となる。
処理効率は、自動補完UIのお陰で住所の正当性確認が事前にできているとして良い（自動補完機能の動作が正常である前提）ので、入力者 / システムを提供するオペレータ双方にとって、目視で確認する負担が減る。しかし上記に書いたように、自動補完UIが完璧であることを前提とするには行政的な面でもハードルがあり、最近まで登記上存在しない番地にできた建造物への対応はハードルがある。この場合、目視の手間を敢えてかけることでサービス業務としては完全性が高まる。
開発コスト削減は、実際には何を開発コストと見做すかによって増減が変わるのだが、今回の（非常に簡単な）調査で分かったのは、
- 設計・開発担当者が異常系ユニットテストをしていないように見える
- 要件の確認が不十分であるように見える（自動補完は本当に必要だったか、の検証は十分だったか？）
- 番地探索データベースの信頼できる更新方法を選択していないこと（私のマンションが築三年なので、少なくとも三年はアップデートされていないはず）
少し話は変わって、私が行政手続きの電子化をできるだけ早く完備して欲しいと思いながら ― 業務要件が完全に表現されたシステムという意味での品質保証の観点で ― それが如何に難しいかを考えると、蛇行運転になっても、高くついたとしても、無理もないと考えてしまう。
それはシステム開発を進行するにあたってのトレードオフをぼんやり感じ取ってしまうからで、時間を優先させてしまえば品質を犠牲にする、という誰でも想像する一般論の話というよりも、1億人超ユーザを対象にしたシステムで検討すらされない要件が後からポロポロ噴出することを実感を持って恐れるからである。