同じ三つの道具から、三つの製品が生まれる

OpenAQ、Sensor.Community、Grafana。

この三つの名前を Agent に渡すと、データを取り込み、形式を統一し、グラフを表示するという、一見完成した案が簡単に得られる。データ源と可視化ツールのあるほぼすべての企画に当てはまる。実際の仕事を決める部分はまだ語られていない。

OpenAQ はほぼリアルタイムおよび過去の大気質データとメタデータを提供する。Sensor.Community は貢献者による環境センサーネットワークで、Grafana はデータの問い合わせと表示に使う。それぞれ既存の能力があるが、その組織の仕方で別の製品になる。OpenAQ API、Sensor.Community、Grafana の基本

ToWowの過去の候補記録には、データ変換、差異プローブ、大気質図集という三経路があった。当時はいずれも資料に根拠を持つ未検証の設計だった。本稿は候補に沿って、どの製品を選ぶと次の仕事がどう変わるかを分析する。

利用者はすでに分析方法を持ち、別形式の入力を毎回手で処理したくないのかもしれない。まず必要なのは安定した変換結果だ。

取り組むべきはフィールドの対応付けになる。測定対象をどう表し、時刻にどの規約を使い、元の出所をどう残し、欠けたフィールドをどう扱うか。元のフィールドが変換先に対応箇所を持たない場合、その情報をどこに置いたか説明しなければならない。

最初の確認可能な成果は小さくてよい。入力例、それに対応する変換結果、フィールドごとの対応説明だ。利用者はプログラムの意図を推測し直さずに、その結果を自分の次の工程へ持ち込めるべきだ。

価値は繰り返しの接続作業を減らすことにある。既存コネクターや短いスクリプトと比べるのが適している。同じ入力を正しく変換し続けやすいのはどれか、出所が変わったらどれだけ修正する必要があるかを比べる。

こちらの利用者は、両側のデータをすでに持ち、どの差を調べるべきか知りたい人だ。

必要な中間成果は比較表かもしれない。次の表は架空のフィールドによる設計説明で、各プロジェクトの実際の API 形式や観測ではない。

この表はグラフだけでは決まらないことを残している。「なぜ一緒に比較するのか」だ。差が出たとき、数値自体によるのか、時間、位置、機器、処理の違いによるのかを問い直せる。

まず一地点の短期間だけ扱い、生の記録、対応付けの過程、対応できなかった理由を残せばよい。初回の目標は、一人の利用者が調査すべき観測を見つけられることだ。全データを利用者が再び整える必要があるなら、比較表は主な仕事を引き受けられていない。

Grafana への接続は表示の選択であり、比較可能な関係を定義することがプローブの中心だ。比較表を先に整え、普通の表で見るだけでも、方向の有用性を試せる。

図集の読者はデータ経路を保守する人でも、異常を一件ずつ調べる人でもないかもしれない。ある地点のある期間に、どんな変化が起きたかを理解したい。

出力可能な一枚のスナップショットには、地点、期間、測定対象、単位、出所、図を理解するための説明が必要だ。保存した画像を元システムから切り離して見ても、何を記述しているか分かるべきである。

これは可視化の構成を変える。標準ダッシュボードは操作する人が条件を切り替えるのに向く。他人が読む図集には、作者による視点の選択、見るべき変化への注記、原記録への入口が必要になる。スクリーンショットは納品の一部で、説明もその一部だ。

一地点、一つの時間窓から始めて対象読者へ渡せる。何を読み取り、どこで質問が必要かを観察してから、操作機能や範囲を増やすか決める。ページやグラフの数より、一度の正確な理解のほうが目的に近い。

三経路は排他的ではないが、同時に着手する必要もない。アダプターは反復可能な変換、プローブは調査可能な対応、図集は独立して読める説明をまず作る。コード、データ、利用者に求めるものは三つとも違う。

過去の実行では、その後三プロジェクトの文書スナップショットの一覧を作り、バイト数、行数、見出し、ハッシュを集計した。終えたのは資料準備で、観測データはまだ得ていない。したがって三経路の次の検証はいずれも、実入力と対象利用者から始めるべきだ。過去の成果物の詳細は出所記録に残している。

生成システムの候補提案は、ここまで具体的であってほしい。最初に何を渡し、誰がそれで何を進め、どんな反応で方向を変えるのか。そのとき初めて、道具の名前の列が進められる仕事になる。