　その大きな原因の1つは、このシステムがスイッチボックスのボタン押下や人の操作という事象をトリガーに動くイベントドリブンな非同期システムであることです。同じイベントが発生してもシステムの状態によって動作は異なります。開発は頭の中の構想を基に、アーキテクチャ設計のみを行い、コードを書き上げるスタイルを採ったので、イベント受信のタイミング、状態の抽出にヌケ・モレが多数あり、デバッグ中に発生し得るイベントやタイミングが出そろったところで、状態モデルを構築して品質を上げるなどの対策を採りました。

　「最初からきちんと設計すればよいのでは？」という声も聞こえてきそうですが、手動で運用していたプロセスを自動化すると必然的にプロセス自体が変わってしまいますし、そもそも時間もなかったことから事前の完璧な要求分析は不可能でした……。“取りあえず動くもの”を作り、そして、走行時間や難所クリア状況、ターンの進行情報などの確定情報は都度リレーショナルデータベースに格納することにより、プログラムが異常終了してもデータの消失が起こらず、プログラムを再起動すれば正しい復帰ポイントから動く作りにしました。

　走行コースや難所は毎年変更が入り、ルール変更に合わせてシステムを改訂する必用もあり、取りあえず動くものを作って検証しながら作り込んでいくという開発スタイルで、3～4年かけて熟成させてきました。

競技中にはいろいろなことが起こる

　ETロボコンは、2台のロボットがインコース／アウトコースの2本の黒線をライトセンサーでトレースし、コース途中に用意された難所をクリアしながら時間とポイントを競うという、一見単純な競技に見えます。

　しかし、実際に競技をやってみると、直前でロボットが壊れて後回しとか、「一方が別のロボットの走路を妨害して失格になって直後に再レースだったり、妨害された側のロボットが壊れて最終レースに回されたり、スタートの不備で再スタートなどなど……。実はたくさんの競技シーケンスがあるのです。

　全部のシーケンスを含んだ状態モデルの作成を試みた時期もありましたが、このケースでは図で書くよりも、状態変数の洗い出しと決定木の作成、必要なオペレーションの洗い出しと必要なUIの設計が有効でした。

人間は間違える生き物である

　計測システムを導入する以前は、“人手”により、ストップウオッチ計測、記録＆集計、最終順位計算が行われていました。そのため、計測システムでは当初可能な限り機械化・自動化してしまおうともくろんでいました。

　しかし、“人は間違える生き物”です。

　最初の年のスイッチボックスには難所攻略を知らせるスイッチが付いていました。しかし、押し間違えも多く発生し、計測システムの裏画面で修正する羽目になったり（そのとき、Excelアドインによる修正ツールがなく、リレーショナルデータベースのテーブルを直接修正していた（笑））、ロボットの走りっぷりがあまりにも速く、計測担当者が見とれてしまいゴールを記録するスイッチを押し忘れたこともありました。一番すごかったのは、チームの競技順を計測システムに入力後、事前に全ターンの順番を表示しながら複数のメンバーとともに走行順を確認したにもかかわらず、いざ競技が始まってみたら、インコースとアウトコースが反対だった……という笑えない事態もありました。

　われわれはこれらの経験をフィードバックして、過度な機械化や自動化の追求を止めました。その後は、人が関与する部分を減らす、分かりやすいUIにする、手早く正確にデータを修正できる機構を追加する、操作する場所を集中するなどの工夫を加えていきました。また、単にシステムのみを工夫するだけではなく、計測に関わる人達の役割や配置、手順など、競技運営プロセスを計測システムの機械化・自動化の範囲に合わせることも重要です。

　作業を自動化する場合、工数の削減度合いにのみ注目しがちですが、作業の背後に潜んでいるデータや情報を抽出・整理することが重要です。データを見える化することにより、競技経過の分析や表示、他会場との情報共有が可能になります。「人手では工数的に無理だった作業が可能になる」「データを基に新しいアイデアが生まれる」といった点が自動化のメリットであると筆者は考えています。