テーブルから別テーブルへの転記 ③ 配列と連想配列の組合せ ～その８．使い処～
前回は、テーブル間の転記に関するまとめを自作の「集合クラス」に統合
してみた。
infoment.hatenablog.com
今日は、このクラスモジュールの使い処について考えてみる。
１．VLOOKUP関数で充分では？
ユニークな情報をキーに、テーブルから別のテーブルの情報を参照している。
ならば、VLOOKUP関数で充分ではないのか？至極もっともな意見だ。例えば
こんな感じで。
しかし結果は御覧のとおり、エラーが発生する。
なぜなら、テーブルＤに存在しないコードが、テーブルＡに存在するから。
あまり詳しくないが、おそらくテーブルＡとテーブルＤが正規化された関係で
あるならば、問題ないのだろう（表現、あってます？）。
しかしこのケースでは、基幹システムなどが吐き出した最新の注文状況などを
受け取って、それを管理台帳のようなものに転記する場合を想定している。
従って、VLOOKUP関数を使用すればエラーが発生することもある訳で。
そんなもの、基幹システムと連動した別システムでやるべきでは？という
意見もあるだろう。
理屈としては正しいと思うが、
「手が届かない痒い所」
をフォローするために、Excelツールが基幹システムの周りに
「アルテミスの首飾り」
の如く張り巡らされるのは、よくあることで。
（システム改修は、お金と時間が掛かるので）。
そのような場合に、このクラスモジュールが役に立つと思う。
加えて「キー列が必ず１列目とは限らない」問題もある。これはMatch関数と
Index関数の組合せで対応可能なため、このクラスを使う理由としては弱いか。
２．パワークエリを使えないか？
集計（例えばピボットテーブル）に不向きな形の表は、パワークエリを使えば
VBAでなくとも自動成型できる。様々な場面で活躍可能な、非常に強力な機能
だと思う。
しかし例えば、こんなケースではどうだろう。Ａ～Ｇまで７つの営業所があって、
売上に関するデータをExcelで提出してもらうのだが、以下の問題がある。
- 営業所毎に書式がバラバラ。
何度言ってもこちらが提供する書式を使ってもらえない。 - 列の入れ替えなど、予告なしにレイアウトを変えてくる。
そんなもの、営業部門の統括責任者が大鉈振って、全営業所の書式を統一させればいいじゃないか？という意見もあるだろう。
理屈としては正しいと思うが、人は、喉元過ぎれば熱さを忘れる生き物だ。
統括責任者が毎日確認するなら話は別だが、少し時間がたてば各営業所で
帳票が独自に進化し出すのは目に見えている。
そのような場合に、このクラスモジュールが役に立つと思う。
３．テーブルを使用することへの抵抗はないか？
これは、大いにあり得る。特に、次のような使い方と相性が悪いため、反発も
多いと思う。
- セルを結合したい。
- セル内改行したい。
- 同名ラベルを複数使いたい。
結果、残念な名前のラベルが増幅することは目に見えている。
このクラスモジュールは、ラベル名称を目印に転記処理を行っているため、
これは非常に都合が悪い。最大の弱点といっても良い。
これを回避するには、まずテーブル書式の良さを、その本質と多少離れて
いても簡単なところから啓蒙する以外無いかもしれない。例えば、
- 表の右端で改行すると、次の行の左端が自動で選択されますよ。
- 表がシマシマに色付けされるので見易いですよ。
などなど。背に腹は、変えられない。
結局のところ、このクラスモジュールは、理想的でない状態を容認する
駄目なツールなのかもしれない。
それでは次回、そのダメダメな具体例を紹介します。
参考まで。
