本番稼働からしばらくして、クライアントから動作確認の報告が届いた。丁寧に試してくれた形跡のある、具体的な報告だった。不具合が二件、要望が一件、それに気になる点が一つ。作った側の試験では見えなかったものが、使う側の目には最初の数日で見えている。ありがたい報告である。一つずつ応えていった。
押しても、何も起きない
一件目は、区分で絞り込んだまま配信ボタンを押すと無反応、というものだった。原因は、絞り込み条件の受け渡しで、数値の並びを別の形式と取り違えて処理していたこと。内部でエラーが起きていたのに、画面には何も返していなかった。絞り込みを外すと配信できる、という報告の観察とも符合する。修正と同時に、どんな異常でも必ず画面に日本語の説明を返すよう、処理全体を包み直した。押しても何も起きず、説明も出ない。そういう沈黙する機械が、一番悪い。
公開に見えて、開けない記事
二件目は、配信した記事のリンクが開けないというもの。調べると、CMS上でいったん公開された後に非公開へ戻された記事で、APIが返すデータからは公開中の記事と見分けがつかない。そこで、記事のページが実際に表示できるかを、取り込むとき・巡回のたび・配信ボタンを押した直前、の三段構えで確かめる仕組みにした。開けない記事は自動で対象から外れて画面に印が付き、再び公開されれば自動で戻る。誤って配信されてしまった当の記事は履歴を整理し、実際の公開後に改めて承認待ちへ入るようにした。
時刻を決めて、予約で送る
要望は、配信時間の指定だった。管理画面に予約配信の欄を設け、日時を指定すると、承認済みの記事をその時刻に自動で配信する。予約の一覧と取り消しもできる。設計で一つ決めたのは、対象を予約した時点で確定させることだ。予約の後に承認した記事は含まれない。後から中身が変わる予約は事故のもとになるからで、この決めは画面の確認メッセージにも明記した。
写真のない記事に、顔を作る
最後の一つは、写真のない記事の見栄えだった。無地に近いカードでは寂しい。そこで、情報紙のロゴを使った定型のカード画像を作り、写真がない記事にはこれを敷くことにした。写真付きの記事と並んでも見劣りしない。実際に送らずにメッセージの形式だけを検査できる仕組みで、受理されることも確かめた。
四つの対応を終えて、再確認をお願いする報告を送った。机上の試験をどれだけ重ねても、実際に使う人の報告に勝る試験はない。動かして、使ってもらって、直す。この往復こそが、仕組みを本物にしていくのだと思う。