取りに来るのか、送るのか

新しい庁舎が秋に開く。その入口にデジタルサイネージが付く。そこへ「今日の会議」を出したい、という話が来た。

会議室の予約はグループウェアの中にある。誰が何時にどの部屋を押さえたか、全部入っている。だから画面に出すこと自体は難しくない。難しいのは、誰も更新しないようにすることである。

貼り紙をやめてサイネージにしたのに、毎朝誰かが手で打ち込んでいるなら、意味がない。紙が画面に変わっただけだ。

誰も触らない、を先に決める

決めたのはこうである。

予約する人は、いつもどおり会議室を押さえる
出してよい会議だけ、チェックを一つ入れる
あとは何もしない

チェックは会議ごとにした。予約ごとではない。一つの会議で三つの部屋を同時に押さえることがあるからで、部屋ごとにチェックを入れさせると、二つ入れて一つ忘れる。忘れた部屋だけ画面に出ない。そういう間違え方を作ってはいけない。

チェックを触れるのは、予約した本人と、予定を登録した本人と、管理者だけにした。他人の相談や面談を、勝手に入口の画面へ出せてしまってはまずい。画面でボタンを押せなくするだけでなく、サーバ側でも同じ判定をしている。画面だけで守ると、画面を通さない経路で破られる。

問題は渡し方であった。

サイネージの機械が何を読めるのか、この時点で分からない。相手はまだ選定の途中である。分からないまま作るしかない。

考えられるのは二つだった。

送る。グループウェアのサーバが、ファイルサーバの共有フォルダへ CSV を書き出す。サイネージはその共有を見に行く。

取りに来る。サイネージの側が、決まった URL を叩いて CSV を受け取る。

この二つは、通信の向きが逆である。前者はサーバ側に共有をマウントする必要があり、書き込みの権限が要る。後者はサーバ側に何も要らないかわりに、サイネージの側に「取りに行く仕掛け」が要る。

決まっていないので、両方作った。

片方は無駄になる。それは分かっていた。分かっていたが、どちらかに賭けて外したときの作り直しのほうが高い。作りは同じで、出口が二つあるだけだ。同じ関数が CSV を組み立て、片方はファイルに落とし、片方は URL の応答として返す。中身も文字コードも同じものが出る。

そして、この判断はすぐ効いた。

共有をマウントして試した人から、遅いと連絡が来た。原因はまだ分からない。だが遅いという事実だけで、送る方式には影が差す。CSV の書き出しは予約の保存と同じ処理の中で走るから、共有が遅ければ予約の登録そのものが待たされる。サイネージのために予約画面が重くなるのでは、本末転倒である。

取りに来る形が残っていたので、逃げ道はある。原因が分からないままでも、方式を替えれば前へ進める。

予約の時刻と、会議の時刻は違う

作っている途中で、思い込みが一つ壊れた。

最初は予約の時刻をそのまま出していた。会議室を 12時半から 17時15分で押さえてあれば、画面にもそう出す。当然だと思っていた。

実データを眺めていて気づいた。同じ会議の予定は、13時から 17時であった。

当たり前である。会議室は準備と片付けを見込んで長めに押さえる。机を並べる時間、資料を配る時間、終わってから片付ける時間。予約の時刻はその全部を含んでいて、会議そのものの時刻ではない。

来庁者が入口の画面で見たいのは、会議が何時に始まるかである。設営が何時に始まるかではない。

そこで、出すのは予定の時刻に変えた。ただし例外を一つ置いた。一つの会議で二つ以上の部屋を押さえている場合は、予約の時刻を出す。そういう予定は「二日間、各庁舎」のような通し時間になっていることがあり、部屋ごとの実態を表さないからである。

これは仕様書からは出てこない。実際に入っているデータを見ないと気づけない類である。私は三十年この業界にいるが、いまだにこれをやる。画面を作る前にデータを見る。分かっているつもりで、忘れる。

二つのきっかけで書き直す

更新のきっかけは二つにした。

予約が動いたとき。登録・修正・削除、会議名の変更。そのたびに書き直す。当日の予定が変わったのに画面が古いままでは、貼り紙より質が悪い。

毎晩のバッチ。日付が変わると、出すべき日そのものがずれる。予約に動きがなければ書き直しの機会がないので、連休を挟むと何日も前の内容が残る。だから日付が変わったら必ず一度作り直す。

夜間のバッチは、以前から一つ困っていたことがあった。日次でやりたい処理が出てくるたびに、設置作業をやり直していた。そこで、決まった場所にファイルを置けば実行される形にしてある。今回のサイネージも、そこへ一つ置いただけである。設置の作業も、時刻の設定も、触っていない。

ついでに書いておくと、そこにはもう一つ、古い操作記録を消す処理が入っている。この記録は投稿された内容をそのまま持つので、放っておくとデータベースの大半を占めるようになる。実際、ある利用先では一つの表が 2GB を超えていた。毎晩少しずつ消す。

出さないものを決める

出すものより、出さないものを決めるほうに時間がかかった。

課名は出す。予約者の氏名は出さない。入口の画面に個人名が並ぶ必要はない。どの課の会議かが分かれば、来庁者は行き先を判断できる。

チェックの無い会議は出さない。相談も面談も、既定では出ない。出すために一手間かける形にしてあるので、うっかり出ることがない。逆はまずい。既定で出る作りにすると、外し忘れが事故になる。

庁舎ごとにファイルを分けた。入口の画面に他の庁舎の会議が並んでも、来庁者には関係がない。

そして、その庁舎に会議が一件もない日でも、見出しだけのファイルを書くことにした。これは実装の途中で足した。書かずにおくと前の日のファイルがそのまま残り、サイネージは昨日の会議を映し続ける。空であることを、はっきり伝える必要がある。

一つの庁舎の共有が外れていても、残りの庁舎は書く。まとめて処理して途中で止めると、無関係な庁舎まで巻き添えになる。

化けと、遅さ

フォルダ名は英数にしましょう、とこちらから提案した。

日本語のファイル名は、どこかで化ける。そして化けたとき、共有を経由する途中なのか、受け取る側のソフトなのか、それとも最初から化けていたのか、切り分けができなくなる。名前が読めなければ、どこで壊れたかを追う手がかりごと失う。

先方も同じことを考えていた。ファイル名も英数にした。

中身の文字コードは、まだ決まっていない。相手のソフトが分かっていないからである。ここも設定で選べるようにした。既定は昔ながらの日本語コードにしてある。新しい方式のうち、目印の付かないものは古いソフトが誤認して化ける。確実に読めるほうを既定にしておいて、相手が分かってから変える。プログラムは触らない。

こうやって並べてみると、決まっていないものを設定に逃がしただけの話ばかりである。渡し方、文字コード、出力先、日数、ファイル名。全部、後から変えられる場所に置いた。

現場の仕様は変わる。ファイルサーバも変わるかもしれない、と言われている。変わったときに、こちらが呼ばれずに済むようにしておく。それが一番の親切だと思っている。

AIとの協働作業での学び

今回、AI と組んで良かったのは、両方作るをためらわなかったことである。

人間だけでやっていたら、たぶんどちらかに賭けていた。二つ作れば二倍かかると思うからだ。実際には二倍ではなかった。CSV を組み立てるところは一つで、出口が二つあるだけだった。それに気づいたのは、作りながら中身を並べてみたときである。

もう一つ。実データを見に行くのを、面倒がらなかったのも大きい。予約と会議の時刻が違う件は、テーブルの定義を眺めていても出てこない。実際に入っている行を数十件、目で見て初めて気づいた。ここを飛ばして「予約の時刻でいいだろう」と作っていたら、開庁の日に入口の画面が三十分ずれた時刻を出していたはずである。そして誰も、それが間違いだと気づかない。画面はもっともらしく動いてしまう。

書き終えてから、少し落ち着かない気持ちが残っている。共有が遅い理由は分かっていない。文字コードも決まっていない。サイネージの機械も、まだ来ていない。

さて、うまくいくかどうかは、もう少し先の話である。