前回は、うちの中の話を書いた。バックアップの監視、出荷ビルドの検証――「守る」管理である。今回はその続きで、出荷した後の話をする。
45年やってきて分かっていることがある。製品は、出荷した瞬間がいちばん若い。そこから何年も現場で働き、現場ごとに事情を抱え、ある日突然「ちょっと変えてほしい」と電話が来る。出荷したら終わり、ではない。むしろ届けた後が本番なのだ。
うちの8chスイッチコントローラーには2つの世代がある。日本の電波認証(技適)を取ったモジュールを使う正式版と、コストを抑えた普及版。事情があって、この二本立ては今後も続く。正式版はすでにお客様の現場で働いているから、勝手に「旧型」にはできない。
スマホ用のアプリは、逆に1本にまとめた。接続時に相手の応答を見て機種を自動判別し、画面の隅に「正式版」「コストダウン版」と表示する。派手な機能ではない。だが現場で効くのはこういう情報だ――いま自分がどの世代の機械と繋がっているのか、一目で分かること。型番、シリアル番号、温度、版数。管理情報こそ、現場の情報である。
出荷後の管理で、私が何十年も続けている型がある。書き込みファイル(hex)には、必ず現場の名前と日付を入れて渡す。ソース一式のzipも同じ名前にする。
理由は単純で、現場は慌てるからだ。トラブルの電話がかかってくるのは、たいてい本番前のいちばん忙しい時間である。そのとき「何月何日の、あの現場の版」とファイル名だけで辿れるかどうかが全てを分ける。バージョン管理の仕組みがどれだけ立派でも、慌てた人間が最後に頼るのはファイル名だ。だから機械が読む管理と、人間が読む管理を、両方ファイルに焼いておく。
AIと組むようになっても、この型は変えない。変わったのは、この型をAIも守るようになったことだ。ビルドの検証も、名前の付け方も、いまは仕組みが憶えている。
ここからは、まだ途中の話を書く。
うちの製品は、開発環境ごとインストールしたPCと一緒にお客様へ渡すことがある。ソースも渡す。それでも今までは、修正はうちの仕事だった。お客様がソースに手を入れるのは、現実には難しかったからだ。
状況が変わってきた。いまは無料で使えるAIでも、ソースを読んで説明し、小さな修正を提案できる。登録さえすれば、である。だったら、配布物の側を変えればいい。
考えているのはこうだ。配布するソース一式の中に、AIが読むための案内を入れておく。この装置は何か、どこを触ってよくて、どこを触ってはいけないか、変更したら何を確認するか。お客様が自分のAIに「この現場のフェード時間を変えたい」と相談したとき、AIが迷わず正しい場所へ辿り着けるように、道を敷いておく。
何を修正したくなるかは現場ごとに違う。だからこれは一度で完成しない。お客様からのフィードバックが来るたびに、配布物の「道」を直していく。出荷後も製品が成長するのと同じで、配布のかたちも成長していく。
なぜそこまでするのか。理由を正直に書く。
私は70歳が近い。この仕事の全部を、いつまでも自分の手で面倒みることはできない。だから10年を目途に、記録とやり方をすべて公開して、私のアカウントが無くなっても大丈夫なところまで準備するつもりでいる。クラウドはいつか消えるから、大事なものはお客様の側へ移し、SSDに凝縮して手渡すことも考えている。
45年やってきた技術屋の、これが義務だと思っている。
腕は隠すものだと言われた時代に育った。だがいま思うのは逆だ。腕は、渡せる形にして初めて残る。AIはそのための、いちばん新しい道具である。
*(付記: 本稿の「配布物にAIの道を開く」は現在進行中の課題で、完成形ではない。連載の常で、やってみた結果はまた記事にする)*