第39話 混沌
仕事は混沌に陥っていた。
プログラミングの問題ではない。仕様の問題である。
自転車のセンサーには速度・ケイデンス・心拍・トルクの四種類があるが、これらの中には一つのセンサーに複数の機能を持たせたものがある。例えばケイデンスはペダルの回転数を検出するが、タイヤのサイズとギア倍率を入れると速度センサの役割も果たす。
どのセンサーがどの役割を持っているのかは接続開始時に伝えて来る役割情報で判明するのだが、この規格に沿っていないセンサーが存在するのだ。しかもメーカーに寄っては独自規格を立てているものもある。規格自体に強制力がないこともあるが、製作側のやっちゃった感が強い。
そういったセンサーがあらゆる情報を上げて来るのに加え、一時的故障や動作のタイムラグも混ざって、それぞれの信号は気ままに流れたり止まったりする。
こういったとき、いったいどれを選択して取り込めばよいのか?
発注元に訊いてみた。
「いったいどうしたらいいんだろね~」
一番この事情を知っている人がこの他人事のセリフを口にする。お金を払っているのだからそっちでどうにかしてよという大変危険な考え方である。
誰も答えを知らないのなら勝手に作っていいのだろうか?
結局はそうした。
色々試行錯誤した末に、最初に信号を発したセンサーだけを捕まえ、その信号が一定時間途絶えるまではその他の同種信号を完全に無視するようにした。
早い者勝ち方式である。
これだと自転車を止めるたびにスピードセンサーの検出元が切り替わるという現象も起きそうだが、実際にはセンサーの起動速度は個体によってだいたい一定なのでそれほど目まぐるしく変化はしないはずだ。それに表示自体は「速度」だけなので発信元が切り替わってもユーザーは気づかないはずであった。
この方式でクレームは来なかったので良しとした。それも当然だ。これにクレームをつけるならば、正解の仕様を提示する必要が出て来るから向こうも文句はつけられない。
誰しも面倒なことはやりたがらない。強い立場にある者は特にだ。
この最後の難関を突破すると製品がほぼ出来上がった。
最終試験は発注元が引き受けてくれた。
私は前回の病気以来足がおかしくなっていて、自転車に乗ると停止時に派手に転ぶようになっているので、自転車を乗り回すというのはもはやできない。
発注元は幹部以外はすべて自転車乗りだ。一日二時間から四時間は仕事であちらこちら乗り回して試験をしている。年に数度全社員をあげての自転車マラソンレースを開催しているほどだ。
途中の会社の人も同じく数人は自転車を乗るのが仕事だ。こちらも延々と自転車を漕いでいる。
この世を統べているのは自転車様である。
新規登録で充実の読書を
- マイページ
- 読書の状況から作品を自動で分類して簡単に管理できる
- 小説の未読話数がひと目でわかり前回の続きから読める
- フォローしたユーザーの活動を追える
- 通知
- 小説の更新や作者の新作の情報を受け取れる
- 閲覧履歴
- 以前読んだ小説が一覧で見つけやすい
アカウントをお持ちの方はログイン
ビューワー設定
文字サイズ
背景色
フォント
組み方向
機能をオンにすると、画面の下部をタップする度に自動的にスクロールして読み進められます。
応援すると応援コメントも書けます