社内ツールを作るときに気を付けたいこと

数年前の先輩が残した偉大なエクセルマクロが支配している職場を経験したことはありますか。 当時は偉大だったマクロも、気づけばそのマクロが動かせなくなるからシステム更新ができない そのマクロを使うためにデータ変換するマクロができたり

どうしてそうなった

理由は明快、そのマクロを作った人がど素人で、それを使う人もど素人だから

少し、話を変えて、人はなぜプログラムを組もうとは全く思わないのに、 エクセルマクロは、ちょっとやってみようと思ってしまうのでしょうか。

エクセルの功罪の最たるところは、「インターフェース」と「データ保持」が同時にできてしまうところ A3に=A1+A2と書けてしまうところ。 A1, A2はインターフェースなのにA3は計算フローが含まれており、 また計算フローを流すためのデータ保持にもA1, A2が使われます。 見た目に単純なこの仕組みが、広義な「プログラム」として見たとき 極めて複雑で難解な仕組みで成り立っていることを理解せねばなりません。

情報処理、特にプログラミングを習ううえで最も基本的なこととして習うことがあります。 Program = Data + Algorithm この構造を明確にすることが、保守性・再利用性を維持し、柔軟な処理系を産み出すことができるんです。

ある測定器から取得したデータがCSV形式で次のようなものであったとしましょう。

測定日,2018年10月4日 測定者,田中太郎 測定器,V3 サンプリング周波数,20ms

センサー1[V],センサー2[Vp-p],センサー3[A] 3.2,1.2,0.002 3.1,1.5,0.004 …

このデータを見たときに、「入力データ構造の定義」を始められる人がど素人とそうでない人の違いです。 その「データ構造の定義」をおろそかにし、処理系（Algorithmなど）から手を付けようとする人はど素人です。

まず、純粋な測定データとメタデータに分けましょう

メタデータ 測定日: 2018年10月4日 測定者: 田中太郎 測定器: V3 サンプリング周波数: 20ms

測定データ センサー1[V],センサー2[Vp-p],センサー3[A] 3.2,1.2,0.002 3.1,1.5,0.004 …

しかしこの測定データにはまだ測定データのメタデータが含まれています。 これを分離します。

測定メタデータ 1: { 名前: センサー1 単位: V } 2: { 名前: センサー2 単位: Vp-p } 3: { 名前: センサー3 単位: A }

測定データ 1: 3.2,1.2,0.002 2: 3.1,1.5,0.004 …

他にも測定データにはサンプリング時間を振ってあげたほうがいいですし、センサーのVが本当にセンシングした物理量（歪や温度など）として何かを明示したほうがいいでしょう。

こうやって定義したデータ構造を、今度はどの形式を使って記述してやるかが次の課題です。

この内容、今ならXMLかJSONで定義するのが妥当でしょう。こればっかりは昨今のトレンドを追いかける必要がありますが、そろそろ定着して来たと思います。

それなら最初のCSVでいいじゃないかと考えると人もいると思います。注目すべきは、データがコンピュータも含めて誰もがわかりやすく使いやすい構造と形式で保持されているかです。

最初のCSVでは、測定器ごとにデータフォーマット定義書が別途必要であり、そこに不足分（センサーが示す物理量など）をテキストで別途保存しなければなりません。言い換えれば、如何に暗黙知を減らしたデータとして完結できるかかもしれません。

試しにJSONで記載してみるとこんな感じでしょうか ※見易さのために一部JSON形式から逸脱しています。

{ environment: { date: '2018-10-04', person: '田中太郎', machine: 'V3', configure: { samplingFrequency: '20ms' } }, data: { header: [{ name: 'センサー1', unit: 'V', }, { name: 'センサー2', unit: 'Vp-p', }, { name: 'センサー3', unit: 'A', }], body: [ [3.2,1.2,0.002], [3.1,1.5,0.004], ... ] } }

いかがでしょうか。まだまだ手を入れたところは多いでしょうが、拡張、修正、変換するのも容易です。 測定器が新しくなったり、別の測定データと連携した分析をしたいときも、統一的なデータ構造をもとに着手できそうじゃないですか？

実際にいろんなプログラムやマクロ作るときに、内部的に同様のことをしていることがほとんどです。 しかしそれがいろんなタイミングに散らばり、メモリ上にしか存在しないため、処理系はどんどん複雑になり、リファクタリング、リニューアルしようとしてもゼロから始めることになってないでしょうか。

一度、普遍的な形に噛み砕いて、それをマスターデータとして扱っていきましょう