机上SEモダンIT演習#02 - データカタログ大事あるいはExcelはあくまで個人用

「紺屋の白袴」的に、インフラはモダンだけどエンドユーザのコンピューティングがモダンとは言い難い環境でやり過ごしてきた机上SEの私が、世間のコンピューティングに追いつくために少しずつ勉強しているログ。

唐突だけどその昔Lotus/Notesという素晴らしいグループウェアがあって、エンドユーザーコンピューティングの普及の間違いなく立役者のひとつだったと思う。Notesがそうなった要因のひとつは、エンドユーザーデベロップメントの入門しやすさだったと思う。けして簡単じゃないけど、いじりやすいインターフェースだった。

一方で、Notesがネガティブだったところは、ロジック(アプリケーション)とデータがワンセットだったこと。昨今、ロジックとデータを分離するのはITアーキテクチャの基本中の基本、初歩の初歩だけど、Notesは原則ロジックとデータはニコイチ。そのことで、あるアプリケーションが保有するデータを使って別の処理を作りたい、となった際に入り組んでしまうのは避けられなかった。様々なデータ連携ツールも存在したけど、それ自体が複雑性。

で、現代におけるLotus/Notesは、僕はExcelだと思ってる。

Excelは非常に手軽でかつ優れたアプリケーション。その手軽で優秀であるが故に、「属人化」を招きやすいアプリケーション。エンドユーザーコンピューティングの第一歩ではあるけれど、ロジックとデータが密結合するので、使い回すためには、Excelの機能そのものと、固有特定のExcelワークブック上で作り込まれているロジックの両方を理解しなければならず、勢い垣根ができる。

個人的にいちばん嫌ってるのはvlookup信仰で、今どきExcelならJOINも簡単にできるのになんでvlookupを必須のスキルみたいに言い続けるのかなと思うわけです。なぜvlookupを忌み嫌うかと言うと、「値の取得元になるExcelを誰かが変更したら崩れてしまうから」。

簡単な売上集計シート

vlookupではない例だけど本質は同じなので。
こんな大元シートがあったとして、自分は東日本2所属だから、東日本2に関する売上だけを集計するシートを準備しようと、

=SUMIF([別ブック.xlsx]売上集計シート!B2:B100,"東日本2",[別ブック.xlsx]売上集計シート!E2:E100)

みたいなSUMIFを定義しておいたとする。

ところがある日、大元シートの管理者が、

「製品カテゴリの列があったほうがフィルタするのに便利だな」

と、「製品名」と「売上」の間に、

勝手に変えられたシート

「製品カテゴリ」の列を追加。これでもうさっきのSUMIFは(一旦)機能停止に。

これのそもそもの元凶は、「列・行番号でデータを指定する」こと。ほしいのは「部署名」と「売上」なんだから、「部署名」と「売上」でデータを取ってこれればよいわけで、データベースにとっては当たり前のこと。今どき、Excelでもテーブル定義できる。

でもそのとき問題になるのは名前。売上ひとつとっても、「売上」と記述している人もいれば、「売上高」だったり「Rev」だったり「Revenue」だったり、人によって組織によってバラバラで統一されてない。売上だったらなんとなく名前を見れば「Rev」でも欲しいデータだとわかるけど、データによっては名前見ても欲しいデータかどうか判断つかないケースもあるし、そもそも欲しいデータがあるのかどうかもわからないことも考えられる。

なので、全社統一の「データカタログ」が必要になります、という話になるんだけど、全社統一の「データカタログ」は事ほど左様に重要大事なので、これを実現するツールは非常に高価。それ以前に、一足飛びにデータカタログを言うより、データ共有をExcelで行うこと自体を見直す必要がある。そもそも本当に元データをExcelで管理していることは少ないと思っていて、Excelデータ自体が別のデータベースからのエクスポートデータだと思う。それなら、そのExcelで共有するのではなく、大元データベースの改善を行うべき。

「そうは言っても」というところだけど、Excelで共有することによって、そこに既得権益が発生して、その結果、業務効率が落ちている部分があることはけして少なくはない。