|
|
Excel VBA 物語
|
７〜８年ぶりにExcelのVBAでちょこっとしたものを作ってみました。 Excel95当時から比べると開発環境ーVBEがすっかり本格的になっており これではVB6.0と遜色ありません。返ってExcel独自の細かいところまで操作が 可能で使い易いではありませんか。成る程、本屋のパソコン関係書籍にVBAに 関するものが増えて来ているのも頷けます。一般ユーザーも（ってワタクシも 一般ユーザーですが…）エクセルの表計算ー＞関数の利用ー＞記録マクロと その修正ー＞VBEによるVBAプログラミングと段階的に難易度が上がるので ついて行き易い面があるのでしょう。Java2SDKでNotePadにプログラムを 書いてそれをJVMでクラスファイルにしてから実行ー＞でDOS窓が開く。 ではちょっとユーザーもしんどいですよね。 エクセルのマクロの場合はメニューから選択する、ツールバーのボタンを 押す、その作業がそのままプログラムになっているから実に分かり易い。 但しコード補完機能は良いとして、あんなに盛り沢山のデバッグ機能なんか 本格的な開発者用で返って一般ユーザーにはうっとおしいかも知れません。 あれでCVSまで付いていれば…。 Aranskも出だしはエクセル95のVBAです。それからC−＞VC＋＋−＞Delphi ー＞Javaー＞Perl,Python,Rubyー＞SmallTalk−＞LISP,SCHEME−＞Haskell ー＞C#ー＞Rebolー＞Curl（Prologは少しだけ）などと渡り歩いてまたVBAに 舞い戻って来た次第です。一旦通り越してまた裏口から入学したような ものです。一般的にフリーソフト派ー＞リナックスやPerl,Rubyなどに興味がある 人々はマイクロソフト嫌いが多い。特にVisualBasicを敬遠する傾向にあります。 「あれだけは止めとけ」とか言いながら、ホスト系以外殆どの人がVBなりVBAから プログラミングをスタートしているところが面白いですよね。勿論ユーザーとして はただの方があり難い。1980円！のオラクル10ｇよりEclipseの方が良い。 でもエクセルよりオラクル10ｇの方が安いってのも何か異常な気がしないでも ない。そもそもEclipseなんかあれで「ただ」じゃ開発ツールヴェンダーが 泣きますよぉ。 それはさておき、裏口から再入学した者しか分からないエクセルVBAに 関して？を少し…。VBAのレッスンではありません。あくまで評論家的 意見ですからして、お間違えのないように。つまり全く実用性はありませんので。 １）VBAをやってる人は報われない？ プログラマー間には純然たる差別が存在します。能力とは別に使用している言語と 仕事の内容に関してであります。CでリナックスなどのOSを開発している。又は 新たな言語やDBを開発している。…とエクセルのVBAで業務の省力化をやって おります。これは雲泥の差であります。プログラマーの間における厳然たる階級 差であります。プログラマーでエクセルのVBAが出来るかどうか？なんて 素人に毛がはえたかどうか程度にしか見られません。 ユーザーの間ではどうか？ EVAやCFROIを活用して経営方針を決定するためのバランスドスコアカードを 検討しております。…とそれをエクセルで作表するためVBAを組んでおります。 雲泥の差であります。経営者はEVAは知っていてもVBAなんか知りません。 「VBA？ヴェンチャービジネスの組合（アソシエーション）かね？」とかね？ はっきり申し上げて職場でVBAなんか組んでる人間は変わり者の単なる便利屋で あります。「これなんとかならない？」とか聞かれて「じゃ、ちょこっと作って みっかぁ。」と言って作ったが最後、死ぬまで面倒を見るはめになるのであります。 （なんらの感謝も尊敬も受けずに…） 従って、馬鹿な人（筆者のような）は除き普通の人はVBAが出来ることなど深く 秘するのであります。自分の仕事を楽にするためにしかその能力を使用致しません。 間違っても「それってVBAで自動化すれば楽なのに」なんてこたぁ金輪際 言いません。せいぜいVBAの掲示板で人の質問に応えることで満足すべきなの であります。 ２）VBAは何故評価されないのか？ そもそも職業とは、A.誰も出来ないことは職業になりません。B.誰でも出来ることも 職業にはなりません。その中間に職業帯が存在し、A.出来ない方向に評価が高く B.出来る方向に評価が低いのは当然であります。 つまりエクセルのVBAは他人からみれば限りなくB.と思われておるのであります。 今やVBAと言えどほぼ普通の汎用言語のファイルアクセスからテキスト処理 までこなすほど範囲は広がっており、他のアプリケーションまで制御出来る能力 があるにも関わらず一般的な評価は自動マクロに毛が生えた程度であります。 さらにWindowsAPIの上にエクセルのアプリが載っており、またその上から VBAが作用するため結構細かいところに神経を使わないと動作が不安定な 部分があります。従って結構経験を要するのであります。 しかしながらその知識がベタだから…って、つまりその場におけるアドホック的な 集積で構造性、重層性がないから、学問的じゃないのです。 何々だからこうだ。と言う理由が無いケースが多い。エクセルやWindowsの ヴァージョンによって違ったりするから系統的に教えられない。職人的な部分が ある。勿論全てのコンピュータ言語で職人技的な部分の無い言語はありません。 しかし、VBAにおいてはそれが認められない。 何故か？ 操作が簡単という宣伝文句と飛躍的な言語能力拡大との間にギャップが存在する という認識がないからです。ピボットテーブルというC++で書けばSay１千Stepの 機能がベタにSelectなんかと一緒に並んでいるからです。 他の汎用言語と違ってシステム寄りの部分が無さ過ぎるのです。「板子一枚下は …」がべったりWindowsとエクセルのアプリに覆われているのです。 そこにVBAの単語がベタに敷き詰められている感じです。その単語、単語自体に 環境や動作が絡み付いている重さがある。ボタンの集積体のようなプログラム です。このボタンは単独ではなんとか動作するが集積した連携操作になると 突然不安定になったりすることがある。それを人知れずコントロールする職人技を 理解する人は少ないのです。 ３）VBAで何故仕事が楽にならないのか？ プログラムは繰り返し定型的に大量の人々が利用すればするほど、仕事に 貢献します。その大量定型データ、多数の利用人員という「おいしい」部分は JavaとかC++とかに持って行かれておるからです。 何故か？ エクセルで作ったらソフト開発会社が儲からないからです。お金にならないのです。 Cと比較すればJavaやC++の開発効率は10〜20倍でしょう。それがエクセルだと 50〜100倍です。またこれJavaで開発しました。と、エクセルで出来てます。 って雲泥の差です。ヴィトンのバッグとスーパーのビニール袋の差です。 ソフト開発会社は手間を食うことと、システムトラブルで食っておられるのです。 従ってエクセルVBAはソフト開発会社から見れば玩具にしか「過ぎないので なければならない。」のです。 正直に申し上げます。業務アプリでエクセルに出来ないことはありません。 （大量なデータ処理には向きませんが、そのロジックやGUI部分など本質的な システム部分に関しては） その言語能力からしてあまりに過小評価されております。 しかし現実は業務アプリに押され、ユーザーが一人、自分の業務を簡便化する ために「こっそり」と頻繁に変化する業務に合わせて使用しておる次第です。 つまりプログラムを組むよりエクセルで都度計算した方が速いかどうか？の 分野でしか利用されてないから仕事が楽にならないのであります。 日本人の「平均」知的レベルは高い。ソフト開発に必要な人材はインドでも 中国でも日本を凌駕するほどおります。しかし今のところは就労人員平均的 にはまだ日本に分があります。日本のオフィスで働く人でエクセルが出来ない 人は珍しいでしょう。それがピボットテーブルになり、関数になり、VBAに なることは必然的な進化です。その時に起こる爆発的な生産性の向上には 計り知れぬものがあるのではないでしょうか？ 目次へコンピュータ言語的に分類すればRuby,Perl,Pythonなどは第4世代言語（４GL）とか VHLL＝VeryHighLevelLanguageとか称されてコードを書く量に比べてその機能性の 高さが評価されております。（処理速度は別にして） さて、エクセルのVBAと比較してみましょう。 エクセルと言う固有のアプリに乗っているため汎用言語に比べて一定の制限は あります。が、しかし、一般業務の実用に供すると言う面でそのパワーは 絶大です。システムのアドミ用特殊コードなんかを除き、一般ユーザーにとって その動作の分かり易さ、コード量の少なさは驚異的です。 一つの単語の影に無数のサブルーチンが機能しております。それらがブラック ボックスとなってユーザーから見えないが故に表面的には簡素な構文になって おるのであります。例えばローカルウィンドで変数をチェックしてみて下さい。 IntやStrはそのままです。しかしオブジェクト変数のプラスマークをクリック した途端にドチャァーと階層構造的にプロパティーが広がります。 その各接点が実はまたドチャァーと階層構造をもっており、言わばドチャァーの 重なりが我々の眼前に展開されておるのであります。 そもそもWindowsはOS自体にGUI機能を取り込んでおります。エクセルはさらに その上にGUIを被せておるのです。つまりGUIがGUIしている程GUI化したのが エクセルです。従ってユーザーにとって見れば極めて具象的、具体的です。 しかしそれを支えるブラックボックスの闇の深さは計り知れないものを 秘めておるのであります。（若干夏向きですが） どのような言語でも業務系のアプリを組んだ経験のある方はそれぞれの アプリでモアァーと立ち上る非合理性を感じておられると思います。 特にそれが何年もメンテされながら使い込まれたシステムだと一瞬吐気を 催す臭気を発します。まさにドブ川のような…。 逆に言えばそのようなドブ的な臭気を発しないシステムは使い物にならないのです。 人間の利害や怨念をたっぷり吸い込んだものでない限りシステムは実用的では ないのであります。 その点エクセルVBAは簡素な構文と語彙で構成されております。このようなドブが 入り込む余地がないのであります。 と、思いますよね？ ところが大違いなんです。せいぜい利用者10人規模のエクセルで構築したシステム の3年後の姿って、ヘドロの山です。出来ないことは無いこと（セルベースで 組めば？）とその簡便さ、一切改造費用がかからないことが逆目に出る訳です。 「なんでこれ動いているの？」その目的も良く分かりません！ 担当者が次々と交代し、その技量に応じて改変、「改悪」が繰り返されるのです。 GUIって究極的に表面上そうなっておれば良いって部分がありますよね？ （JavaやC++でも同じですが…特に） 最悪のケースはなんと言っても、隣の部でも似たようなエクセルのシステムが あるからそれと合体したら「さらに」効率が高まるじゃないかぁ！と訳の分からん 上司が言い出した時であります。ヘドロ山同士の結婚式です。 さすがに誰も仲人として手を挙げなかったので事無きを得ましたが…。 世界のオフィスでこのような麗しい話が本日も繰り返されるのであります。 目次へ
他のコンピュータ言語を使用しているプログラマからVBをやっていると筋が悪く なるから止めろと言われます。そもそもプログラムの筋が良い悪いとは何をもって 判断するのでしょうか？ 抽象的に言えば簡潔で効率的で可読性の高いプログラムを言います。さりながら これには個人的な感性と恣意性が入ります。で、例を挙げてみます。 Range("A65536").End(xlUp).Offset(1).Select これはExcelVBAをやってる人なら誰でも知っている有名なイディオムです。 つまり普通はこうです。 Range("A1").End(xlDown).Offset(1).Select Range("A1").End(xlDown)と書いてその列の一番下の入力済みセルを選びさらに Offset(1)（正確にはOffset(1,0)ですが）して未入力セルを選択する。 ところがこれだと途中で空白セルがあるとその列に入力済みセルが続いていても 無視されるのです。 そこで Range("A65536").End(xlUp).Offset(1).Selectとやって 一番下から逆に上ろうじゃないかと考えた訳ですよね。 この65536ってのはエクセルのシート最終行なんです。ご存知でしたぁ？ 感動的な筋の悪さ、センスの悪さですよね？ せめて Const Bottom As Long = 65536 としてCells(Bottom,1).End(xlUp).Offset(1).Selectとかさぁ。 さらに言えば Dim Bottom As Long Bottom = ActiveSheet.Rows.Count としてCells(Bottom,1).End(xlUp)とか… これならエクセルのシート最終行が増えても（減っても？）関係無い。 それをベチャァーとA65536ってコードに書き込むところがいかにも VBAらしい。65535なら、OKですが…いや10000でも1000でも良いんです実用的には。 律儀に65536って書かなくても。これ65537と一つ間違えてもOut！ですからして。 VBAプログラマって面白いでしょ？ でも筋の良さ気なプログラムもあります。 With Worksheets(1).Columns("B:D"） .Hidden = Not .Hidden End With これはBからDの列が表示されていれば非表示にし、非表示なら表示する プログラムです。プロパティにNotで反対状態を代入している次第です。 Withクローズですっきりまとめているところも好感が持てますよね。 しかしこれなんかは残念ながらほんの少数です。 大部分のVBAプログラマは力がお強い。力技専門です。（力の強い人は オツムが弱いなんて言っておりませんので念の為） 例えば： Sheets("合計残高試算表").Range("A2").Copy Sheets("貸借対照表").Range("F5").PasteSpecial xlValues Sheets("合計残高試算表").Range("A3").Copy Sheets("貸借対照表").Range("F6").PasteSpecial xlValues Sheets("合計残高試算表").Range("A4").Copy Sheets("貸借対照表").Range("F7").PasteSpecial xlValues とまあ延々とコードが続く訳ですよぉ。 簿記の転記を「忠実に」やられる次第です。これって行や列が一つ違うと どうなるの？また延々と修正される訳です。力です。これがVBAの力技なんです。 驚いたことに勘定コードも勘定科目テーブルもありながら、これをやる訳です！ VBAは肉体派です。 そりゃぁ、JavaでもDBコネクションやRMIなんかで決まりきったコードを毎回 書いている奴が居ます。二日酔いの明くる日なんかこれって心地よいのです。 指が覚えちゃってるもんだから頭を使わなくて済む。いかにも仕事やっている みたいでしょ？上記VBAの「転記」よりはましです。ほんの一寸ですが…。 さて、これをさらに煮詰めてみましょう。 せっかく簿記が話題になったので商法の中間配当限度額の規定です。 第二百九十三条ノ五 営業年度ヲ一年トスル会社ハ定款ヲ以テ一営業年度ニ付 一回ニ限リ営業年度中ノ一定ノ日ヲ定メ其ノ日ニ於ケル株主ニ対シ取締役会ノ 決議ニ依リ金銭ノ分配ヲ為スコトヲ得ル旨ヲ定ムルコトヲ得 ○２ 前項ノ決議ハ同項ノ一定ノ日ヨリ三月内ニ之ヲ為スコトヲ要ス ○３ 第一項ノ金銭ノ分配ハ最終ノ貸借対照表上ノ純資産額ヨリ第一号乃至第四号 ノ金額ヲ控除シタル残額ニ第五号乃至第七号ノ金額ヲ加算シタル額ヲ限度トシテ 之ヲ為スコトヲ得 一 最終ノ決算期ニ於ケル資本及準備金ノ合計額 二 最終ノ決算期ニ関スル定時総会ニ於テ積立テタル利益準備金及金銭ノ分配 ノ時ニ積立ツルコトヲ要スル利益準備金ノ合計額 三 最終ノ決算期ニ関スル定時総会ニ於テ利益ヨリ配当シ若ハ支払フモノト定メ 又ハ資本ニ組入レタル額及第二百十条第一項又ハ第二百十一条ノ三第一項ノ決議ニ 依リ定メタル株式ノ取得価額ノ総額ノ合計額 四 前三号ニ掲グルモノノ外法務省令ニ定ムル額 五 最終ノ決算期後減少シタル資本準備金又ハ利益準備金ノ額ヨリ其ノ 資本準備金又ハ利益準備金ノ減少ニ係ル第二百八十九条第二項各号ニ定ムル額ヲ 控除シタル額 六 最終ノ決算期後減少シタル資本ノ額ヨリ其ノ資本ノ減少ニ係ル第三百七十五条 第一項各号ニ定ムル額ヲ控除シタル額 七 前二号ニ掲グルモノノ外法務省令ニ定ムル額 ○４ 会社ハ其ノ営業年度ノ終ニ於テ貸借対照表上ノ純資産額ガ第二百九十条 第一項各号ノ金額ノ合計額ヲ下ル虞アルトキハ第一項ノ金銭ノ分配ヲ為スコト ヲ得ズ ○５ 営業年度ノ終ニ於テ前項ノ純資産額ガ同項ノ合計額ヲ下リタル場合ニ於テハ 第一項ノ金銭ノ分配ヲ為シタル取締役ハ会社ニ対シ連帯シテ其ノ差額、若シ 分配シタル金銭ノ額ガ其ノ差額ヨリ少ナキトキハ分配シタル金銭ノ額ニ付賠償ノ責 ニ任ズ但シ取締役ガ前項ノ虞ナキモノト認ムルニ付注意ヲ怠ラザリシコトヲ証明 シタルトキハ此ノ限ニ在ラズ ○６ 第一項ノ金銭ノ分配ハ第二百九条第一項、第二百二十二条第一項、 第二百二十二条ノ六第一項但書（第二百二十二条ノ十ニ於テ準用スル場合ヲ含ム）、 第二百八十条ノ二十第二項第十一号及第二百九十三条ノ規定ノ適用ニ付テハ利益ノ 配当ト看做シ、第一項ノ一定ノ日ハ第二百二十二条ノ六第一項但書 （第二百二十二条ノ十ニ於テ準用スル場合ヲ含ム）及第二百八十条ノ二十第二項 第十一号ノ規定ノ適用ニ付テハ営業年度ノ終ト看做ス ○７ 第二百六十六条第二項第三項及第五項ノ規定ハ第五項ノ取締役ノ責任ニ、 第二百九十条第二項ノ規定ハ第三項ノ規定ニ違反シテ金銭ノ分配ヲ為シタル場合 ニ之ヲ準用ス 明治32年制定ですからして法律の原文は上記の通りです。 普通は何が書いてあるのかさっぱり分かりません？ 中間配当限度額＝10/11＊（純資産ー資本金ー法定準備金ー金融商品時価評価益 _ ー前期配当金ー前期役員賞与） 長々と書いてありますが、現状の法令解釈からすると上記の数式が言いたい だけなんです。数学的には加減乗除だけです。小学生並の知識であります。 この落差がすごいと思いませんか？ 細かく言えば金融商品時価評価益や法定準備金の定義や範囲などはありますが 突き詰めればこんなことなんです。 これがエクセルのVBAの恐るべきところであります。余分なものを削ぎ落として 数値的な明確なものを突きつけてくるのです。現代人はこれから逃れられない のです。主義主張に関わらず数値的なものに還元される世界に生きている のだからして。 一方雇用は労働は非効率なものからしか生れないのです。 明治32年制定の商法解釈では食えます。それがエクセルの数式になっちゃったら 誰が食えるのでしょう？ 「Sheets("合計残高試算表").Range("A2").Copy Sheets("貸借対照表").Range("F5").PasteSpecial xlValues Sheets("合計残高試算表").Range("A3").Copy Sheets("貸借対照表").Range("F6").PasteSpecial xlValues Sheets("合計残高試算表").Range("A4").Copy Sheets("貸借対照表").Range("F7").PasteSpecial xlValues とまあ延々とコードが続く訳ですよぉ。」 とか 「そりゃぁ、JavaでもDBコネクションやRMIなんかで決まりきったコードを毎回 書いている奴が居ます。」 が無くなれば何人のプログラマが職を失うのでありましょうか？ 数値的な整理された世界を目指しながら、混沌と不条理にしか生きられないのです。 プログラマは自らの生存基盤を掘り崩しながら生活の糧を得ているのです。 だから、力技が好きなんです。非効率に病みつきになるのであります。 End(xlUp)を無意識に避けるために、自らの生存の時間を延長するために 全てを先送りしているのであります。
続きます。 例えば： A）「第二百九十三条ノ五 営業年度ヲ一年トスル会社ハ定款ヲ以テ一営業年度ニ付 一回ニ限リ営業年度中ノ一定ノ日ヲ定メ其ノ日ニ於ケル株主ニ対シ取締役会ノ 決議ニ依リ金銭ノ分配ヲ為スコトヲ得ル旨ヲ定ムルコトヲ得 ○２ 前項ノ決議ハ同項ノ一定ノ日ヨリ三月内ニ之ヲ為スコトヲ要ス ○３ 第一項ノ金銭ノ分配ハ最終ノ貸借対照表上ノ純資産額ヨリ第一号乃至第四号 ノ金額ヲ控除シタル残額ニ第五号乃至第七号ノ金額ヲ加算シタル額ヲ限度トシテ 之ヲ為スコトヲ得 …延々と続く」 B)中間配当限度額＝10/11＊（純資産ー資本金ー法定準備金ー金融商品時価評価益 _ ー前期配当金ー前期役員賞与） C)G2=10/11*(A2-B2-C2-D2-E2-F2) と比較してみて下さい。 A)->B)->C)の順番に抽象度が高まっております。C)を見ただけで、これが 中間配当限度額の式だなんて理解出来る人は少ないでしょう。（まあ、A)も そうかも知れませんが…） 実はA)の背後には企業形態の発展、会計理論、債権者保護の精神とかがドチャァー と詰まっておる次第です。 また一方C)の背後にもエクセルのアプリ、WindowsのOS部分、ハードよりのソフト さらにハードそのものがドチャァーと詰まっておるのであります。 如何でしょう？人間の思考と物質の接点が見えてきたでしょうか？ つまりA)側には人間の大脳神経構造と一体となった記憶＝文化制度構造体があり、 C)側にはその思考形態を「物質化」するハードとソフトの構造体がある訳です。 アラン・ケイが人間の思考のためのツールとしてパソコンを位置付け、Smalltalk 言語を開発しました。（現在はSqueakが有名ですが） エクセルの前にはロータスとかマルチプラン、その前にはWSとしての表計算ソフトが 存在しましたが、現在「最も人間の思考を物質化する、数値化する機能」としては エクセルが一番ではないでしょうか？ つまりシステム側とユーザー側のアドホックな連携としての視点から見ればです。 状況は限り無くC)に収斂しつつあるのではないでしょうか？ C)の背後のシステム側の部分について知ることは、食えます。 A)の背後の会計理論や企業形態論でも、食えます。 しかしC)では食えないのです。小学生並の知能で食える仕事は少ない。 つまりC)でも仕事は進むからです。回りの事務作業の業務引継ぎを見て下さい。 このエクセルのこの黄色い部分に予想値を打ち込めばあとはプリントアウト するだけだから…なんて会話が交わされてないでしょうか？ 最も薄っぺらな部分に仕事が収斂しつつあるのではないでしょうか？ 生体験そのものである行為、現象、経験が喪失し、数値の関係性しか残らない。 その数値が物質化して眼前化する。 何故か？人間の判断や評価が数値化されているからです。 これからは逃れられません。どんなに感動する映画でも観客動員数で評価されます。 イチローも1シーズン当たり257本のヒットを打つかどうかです。 そこまで言うのはさておき、エクセルのメリットでもありデメリットはA)側とC)側 のリンク部分に位置しており簡便な操作で数値（文字列も含みます）を物質化する ことが出来るところであります。 これまでの人間の行為、現象、経験が脱色されて、えーっつ！こんなもんなの？ ー＞G2=10/11*(A2-B2-C2-D2-E2-F2) 無意味化され省力化されて目の前に突きつけられる。立つ瀬が無いのであります。 業務システムの開発が予算をオーバーし納期が遅れトラブルが頻発することが 多いのは、勿論第一はソフト会社が儲けるためであります。出来高を上げないと 収益に繋がりません。 しかし隠れた原因はユーザー側にもあるのではないでしょうか？ そんなに簡単にシステム化されたらこれまで従事していた人々の立つ瀬がない。 直接的には職を失う危険性に曝されます。 現実は両者のニーズが合致してシステム開発はトラブっておるのではないで しょうか？こんだけ金を掛けて、こんだけトラブルが発生する高度なことを やっていたんだ。という自負心と雇用を守るためです。−＞ユーザー側も ベンダー側も。 ベンダー側の営業はユーザー企業の経営者に取り入って、良い事だらけを 喋りまくって受注します。受注したら最後絞れるだけ絞る。これです。 つまり不成功なプロジェクトの噂が多いほどベンダーは儲かる仕組みに なっておる次第です。じゃぁ止めればぁ？って？ そこがヴィトンのバッグと同じなんです。ユーザー企業も何十億、何百億円 かけてIT投資が出来ること。これがステータスなんです。はっきり言えば 結果なんてどうでも良い訳です。人さえ減れば。自然減でも…。 よくIT情報誌にユーザーのシステム開発に対する理解の不足が失敗の要因なんて 書かれています。まずベンダーの営業が誤解するようにユーザーの経営者を 誘導するのが大きいと思います。実務ベースでは考えられないような理想的な ことを喋りまくる訳です。（ベンダーの実務ベースもユーザーの実務ベースにも 噴飯物のストーリーをでっち上げて、これを飛躍的な発想と称される訳ですから 落っこちるのは当たり前です。業界で言う銀の弾丸｛＝有りそうもない旨いこと｝ を撃ちまくる訳です。）真にユーザーの経営層がシステム開発の実体と自らの 企業虚栄心に気付いたら、食えないベンダーが続出します。ユーザーの情報 システム部門も例外ではないでしょう。不能率と非効率と虚栄の上に辛うじて 成立しているという面では官公庁とどっこいではないでしょうか？ つまり排他日本的な「なあなあ」構造によって税金が官から民間に還流する のと同様にユーザーの仕様変更の多さと言う名目でどれだけのベンダーの 非効率性や不具合が隠蔽され人月費用が流出していることか。 このような状況からして第１回で述べましたとおりエクセルは報われないのです。 確かに全世界的にエクセルは売れておりマイクロソフトだけは大儲けして おります、が、エクセルユーザーが報われないのであります。 チョコチョコとエクセルで簡便なシステムを作ったら業務ユーザーにもシステム プログラマにも恨まれるのであります。 何よりも現実の虚飾の仮面を剥ぎ取ってしまうからねぇ、自分にとっても。
さらに続きます。 さて、本ホームページの冒頭に申し上げました通り、コンピュータ言語の人間の 思考や概念形成に与える影響に興味を持っております。 個人的にはこれまでVBや特にVBAには関心が薄かったのです。ご承知のとおり Basic言語そのものがプログラミングの初心者用に作成された言語であります。 文法や構造は単純でオブジェクトにメソッドやプロパティをドットで繋ぐ だけです。また語彙自体の粒度が大きく粗い、従って記憶中心的な部分が多く 自ら工夫する要素に欠ける側面があります。反面GUI親和性が高いし、VBAであれば 特にプログラムが直接アプリに反映します。ボタンを並べる感覚でプログラムが 出来ます。またそれぞれの語彙がブラックボックス化、コンポーネント化されて いるのでその生産性は驚異的なものがあります。 但し関数型言語のように可逆性や再帰性を重視する、言わば思想性にVBAは 欠けます。ゴチャゴチャややこしいこと言わんでも動けばエーヤンという 関西的実利性を感じます。 従って衒学的でスノビズムを極めて重視する社会心理学的Aranskとしてはこれまで VBやVBAを論評しなかった次第であります。 ところが実際にプログラムを組んでみると、 ぐっと迫るものがあるのです。この緊迫感はなんだ？この思考がズルッと物質化して 現前する剥き出しの迫力はなんだ？ 他の言語に比較して極端にVBAはアプリによって制限されています。これは当然 です。それが強みであり弱点でもあります。その制限感、規制感は自由度に匹敵 するものがあります。規制の中の自由にも規制が存在しかつその中に自由が 存在する入れ子感覚はなんだ？ 例えばエクセルはアプリケーションー＞ブックー＞シートー＞セルと強固な オブジェクト階層があります。つまりプログラムは現実を如何にこの階層に 当て嵌めてに形成するかに尽きる訳です。（無茶苦茶単純化して言えばですが…） プログラミングは自らの拡大である。自己複製である。と言います。 VBAの場合は企画提案から要件定義から設計からコーディングからテストから メンテナンスから、そして何より、システムのユーザーまで一人でやります。 「咳をしても独り」です。 そして最小単位であるセル化する作業までするのです。自らのセル化です。 アプリケーションー＞ブックー＞シートー＞セルまでの強固なオブジェクト階層 に自らを位置づける訳です。 何の目的で？ 他者の視線のためにです。自らの思考を他者の視線に供するためではない でしょうか？それを独りで、他者の視線を意識しながら… 勿論他の言語もGUIがありOPがありますから他者視線を意識してはおります。 しかしエクセルVBAほど強固なマトリックス構造（VisiCalcからの表計算の伝統） に縛られているプログラミング言語はありません。 セル化というと引き籠りをイメージして孤立化の印象を受けがちです。 日本人は特にエクセルでも罫線が好きです。表には必ず罫線を縦横にいれます。 安心感があるのでしょうね？そのマトリックス的関係性に。 引き籠りも畢竟、「他者の視線に曝されていない自分という他者視線的」現象 ではないでしょうか？ 少し話しはそれましたが、エクセルVBAはそのセル化した関係性内の自己を 「極めて単純な圧縮された作業（システム部分を極力排除して）」で実現 出来ることが魅力の一つではないかと考察する次第です。 人間は環境と身体の混交体であります。Nullの世界（混沌）と全く対極にある 整理されたマトリックス的世界に一気にジャンプ出来るところにエクセルVBAの 面白さと同時に息苦しさも感じる訳であります。 前回「現実の虚飾の仮面を剥ぎ取ってしまう」と申し上げたのは、人間自体が 混沌とマトリックス世界の中間に位置する現実の虚飾性にしか生きられない 存在であることをエクセルVBAに突きつけられることを意味しております。
続きの最後です。 最初に申し上げました通りエクセルはWindowsOSの上でWindowsAPIを使用して C又はC++言語でアプリが開発されております。マイクロソフトが最近オープン ソースのOffice製品に対抗するため、官公庁にはソースコードを開示する ような対策も採るようです。エクセルのコードが何万行のC又はC++で出来て いるのか分かりませんが、すくなくともVBやVBAでないことは確かです。 そのエクセルアプリケーションからツールバーやメニューと同様に関数機能や マクロ機能が生成されて居る次第です。従ってVBAとはコンピュータ言語では ありますが、エクセルアプリの総体に完全に組み込まれている訳です。 それが、汎用言語と違ってズルッと言語が物質化される感触を生み出すのです。 オラクルのPL/SQLやSAPのAVAP4、PeopleToolなんかも言って見ればアプリ固有の 言語ですからエクセルVBAと同じ位置づけでアプリ無しには成立しません。 しかし、エクセルとは普及度が段違いです。もうエクセルは電卓並みと言っても 良いでしょう。 オフィスや教室での文化制度構造体になっています。つまりエクセル自体が 共通言語化しておる訳です。そのような存在が種としての人間に影響を与えない 訳が無い。知らず知らずに思考や概念が構造化されるのは不思議ではありません。 頭脳負荷が軽減されるのは計算や作図作業だけではなく、思考もパターン化され 単純化し生体験が捨象されます。文化制度構造体としての他者視線が、既に、 常に、エクセルVBAに組み込まれているのです。 「セル化された、他者視線化された、自己を増殖せよ。」と。エクセルのVBAはコンピュータ言語としては再生された、復活した言語なんです。 何度も繰り返しますがエクセルはOSのWinAPIを利用してコンピュータ言語 であるCなりC++で開発されました。 その時点で一旦コンピュータ言語は使命を成就してエクセルのアプリ として縦横のマトリックスの上で死んだのです。それがエクセル関数を経て エクセルアプリがVBAを再度生み出しております。メニューやツールバーボタン の機能が先に作られて、それがVBA言語に写像されユーザーのために再生復活して いるのです。（制御構造や変数、配列などはVBからの流用です。） この復活したVBAにもっともっとユーザー側が近づくことは出来ないのだろうか？ 往々にしてシステム化が進むと論理構造までがブラックボックス化し、人間側の 頭脳が空洞化する傾向があります。システム側はブラックボックス化しても ユーザーにとってメリットはあれデメリットはありません。しかし論理構造まで ブラックボックス化すると人間としての能力自体の衰退を招く危険性があります。 ご承知の通りJavaやC＃のような流行のオブジェクト指向やジェネリック （テンプレート）指向がVBAには「無い」ということがメリットになる可能性が あります。コンポーネント化（部品化）パターン化（デザインパターン）した 出来合いの既製品的特性から自由で有り得るのではないでしょうか？ 最近はオブジェクト指向でない言語の方が少ないぐらいです。 VBも.Netで落城しております。もうCとVBAぐらいでしょう？PHPは落城しましたっけ？ えっ？コボルって…。確かF通さんがオブジェクトコボルとかなんとか作っていた ような…？厳密に申し上げますとCにはC++がありVBAもクラスモジュールが あります。しかし、現実にはCは今もそのまま使用され、VBAのクラスモジュール （継承機能も多態性機能もない）を使用している人は極めて少数です。 OO指向よりもエクセルVBAのシンプルな条件分岐、ループ、ソート、検索等の機能 の方が返って論理構造を明らかにユーザーに示してくれるのではないで しょうか？（再帰も可能ですし…） VBAに関して特に最近興味を抱いておりますのは、Book−＞Sheetー＞Cell (Row,Column)というエクセル独自の階層構造に範囲という概念、つまりRange、 Name、Areaなどを別途構造化して直交させ、JavaのAspect志向というか Tapestry的なプログラムをエクセルで出来ないのかな？と志向しております。 つまり硬構造の階層に柔構造の階層を重ねるイメージです。 創造性の基盤として確固としたフレームワークであるルール、規制が不可欠 であります。同時に強固なフレームワークを突き破るアンチテーゼ的な柔軟性 多様性が必要なことも事実です。 この目的で「範囲」の概念をアドホックな偶発的な要素として取り込んでみたら 如何でしょうか？ご承知の通りRefEditフォームコントロールでエクセルの シート上であればどのような範囲も簡単に取得出来ます。 具体的なプログラム構造の問題になりますが、Range,Name,配列等は比較的分かり 易いのですが、どうも「Areas」という概念はVBA解説本にもあまり記載が少なく 使用例がないようです。 例えば： Sub nandaArea() '"A2:A5""B2:B3""D3:D4"のセルには値が入力済み Dim i As Integer, J As Integer Dim mRng As Range Range("A2:A5").Name = "jo" Range("B2:B3").Name = "jojo" Range("D3:D4").Name = "jojojo" Range("jo, jojo, jojojo").Name = "jooo" Range("A1") = Range("Jooo").Areas.Count '3と表示されます。（範囲が３個と言う意味です。） For J = 1 To 3 For Each mRng In Range("jooo").Areas.Item(J) Cells(i + 2, 10) = mRng.Value i = i + 1 Next mRng Next J '全てのValueが表示されます。 End Sub このようにNameを範囲に指定できます。 また、 Sub nandaArea2() Dim jo As Range Dim jojo As Range Dim jojojo As Range Dim jooo As Range Dim i As Integer, J As Integer Dim mRng As Range Set jo = Range("A2:A5") Set jojo = Range("B2:B3") Set jojojo = Range("D3:D4") Set jooo = Range("jo,jojo,jojojo") Range("B1") = Range("Jooo").Areas.Count For J = 1 To 3 For Each mRng In Range("jooo").Areas.Item(J) Cells(i + 2, 11) = mRng.Value i = i + 1 Next mRng Next J '全てのValueが表示されます。 End Sub このようにRangeにも利用出来ます。 また、（若干しつこいようですが…） Sub nandaArea3() Dim jo, jojo, jojojo, jooo Dim i As Integer, J As Integer Dim mRng As Range jo = Range("A2:A5") jojo = Range("B2:B3") jojojo = Range("D3:D4") jooo = Range("jo,jojo,jojojo") Range("C1") = Range("Jooo").Areas.Count For J = 1 To 3 For Each mRng In Range("jooo").Areas.Item(J) Cells(i + 2, 12) = mRng.Value i = i + 1 Next mRng Next J '全てのValueが表示されます。 End Sub このようにVariant変数に配列を入れても 利用可能です。（Variantにセル範囲を入れると自動的に 配列となって格納されます。） 余談ですが： Sub CellJunban() Dim mRng, mCel Dim i As Integer [a1] = "A1" [a2] = "A2" [b1] = "B1" [b2] = "B2" mRng = [a1:b2] For Each mCel In mRng i = i + 1 Cells(i, 3) = mCel Next [a1:b2].Name = "nRng" i = 1 For Each mCel In Range("nRng") Cells(i, 4) = mCel i = i + 1 Next End Sub 表示： 列C列D A1 A1 A2 B1 B1 A2 B2 B2 このようにRangeと配列ではFor Eachでループした時に 順番が違ってきますので注意して下さい。 なお範囲概念を使用する場合は必ずFor Next ではなく For Each Next構文を推奨します。殆どのケースでFor Each構文の方が高速に 作動します。さらにFor Nextは必ずFor X = スタート値 To 最終値 として始点と限度を予め設定する必要があります。その点 For Each X In 範囲（Collection) は範囲の全ての要素を漏れなく 対象とします。例え範囲が連続していなくても、不定形であろうが一切 関係ありません。 範囲における全てのセルのValue（価値）を連帯するのです。 つまりFor文のように始点と終点を限定する差別的な色彩は皆無です。 範囲がいくつであろうが、例えそれぞれの範囲が無限にセルを含もうが For Each Next構文は個々のセルの価値を拾い続けます。セルが続く限り その歩みが止まることはないのです。 上記までのコードはAreasのItemプロパティを例示するため 敢えてFor文とFor Each文をミックスして使用しております。 今回はそれをFor Each文で統一したコードをご覧頂きます。 また範囲の階層構造や範囲の重複したセルについても ご説明致します。 Sub nandaArea4() '"A2:C5""C5:E8""D3:D5""E2:F5""F5:I6"セルには値が入力済み Dim i As Integer Dim mRng As Range Dim mHani As Variant Range("A2:C5").Name = "jo" Range("C5:E8").Name = "jojo" Range("D3:D5").Name = "jojojo" Range("jo, jojo, jojojo").Name = "jooo" Range("A1") = Range("Jooo").Areas.Count '3と表示されます。（範囲が３個と言う意味です。） For Each mHani In Range("jooo").Areas For Each mRng In mHani Cells(i + 2, 10) = mRng.Value i = i + 1 Next mRng Next mHani '全てのValueが表示されます。ここまでは前回と同じですが 'For Each構文で統一したので随分すっきりしましたね。 'さらに今回Areas hoを追加します。 Range("E2:F5").Name = "ho" Range("F5:I6").Name = "hoho" Range("ho, hoho").Name = "hoo" Range("B1") = Range("hoo").Areas.Count '2と表示されます。（範囲が2個と言う意味です。） Range("jooo, hoo").Name = "jooohoo" 'joooとhooの範囲を合体します。 Range("C1") = Range("jooohoo").Areas.Count '普通は2個と思うでしょう？ 'それが５なんです。階層構造が消えてしまいます。 'そこでBookに登録されるNameの特性が原因と考え '全てRangeに書き換えて見ました。 Dim jo As Range Dim jojo As Range Dim jojojo As Range Dim jooo As Range Dim ho As Range Dim hoho As Range Dim hoo As Range Dim jooohoo As Range Range("A2:C5").Name = "jo" Range("C5:E8").Name = "jojo" Range("D3:D5").Name = "jojojo" Set jo = Range("A2:C5") Set jojo = Range("C5:E8") Set jojojo = Range("D3:D5") Set jooo = Range("jo,jojo,jojojo") Set ho = Range("E2:F5") Set hoho = Range("F5:I6") Set hoo = Range("ho, hoho") Set jooohoo = Range("jooo,hoo") Range("D1") = Range("jooohoo").Areas.Count 'ところがこれも５です。 For Each mHani In Range("jooohoo").Areas For Each mRng In mHani Cells(i + 2, 11) = mRng.Value i = i + 1 Next mRng Next mHani '全てのValueが表示されます。 End Sub 如何でしょうか？ Areas（範囲）概念の階層性と同時にその透明性にお気付きでしょうか？ 上位の範囲によって下位の構造を集約できますが、それよりさらに上位の 範囲に対して透明性が維持されております。つまり中間層によってそれより 下部の構造が隠蔽されることがないのです。ここがオフジェト指向と異なる ところです。最上部から最下位の範囲まで平等であり、各セルの価値が 連帯して漏らさず活かされております。 一方今回C5,F5などセルが重複してAreas設定されております。 つまり一つのセルがマルチレイヤーで自由にAreasに参加しているのです。 明確に区分されたエクセルのオブジェクト階層Application->Book->Sheet ->Cell(Row,Column)から自由になってAreasに主体的にマルチに参加して 他のセルと連帯しています。 何故これほどエクセルのAreasやFor Eachに惹かれるのか？ ご承知の通りAreasはResizeプロパティで自由にアドホックに変更可能です。 つまり確固とした制度基盤の上においても、いや、そうであるからこそ、その 自由度と透明性が高いことが生きるのです。 またFor Eachは上記で述べた通り平等無差別であり全てを漏れなく 救い上げます。 個人の創造性を最大限に発揮すると同時に他者との共感、他者との連帯が 可能だからです。まさに現代のネット世界を象徴しております。 確かにエクセルのVBAに市場価値を多くは求められません。流動性は 若干抑制されます。 しかし個人の創造的な代替不能な思考を重視したい。その多様性を大切に したいのです。またこのような試行錯誤の過程、思考の過程も大事にしたい。 そんな想いを込めてExcel VBAをご紹介致しました。 以上
軽い話題をお一つ、どうぞ。 さて、日常オフィスではエクセルのVBAってどのように使われているの でしょうか？ デジタルデバイドとかややこしい話は置いてといて、基本的にはそれぞれの 職場における人員構成とそこで醸し出される文化に依存している部分が 大きいと思います。 事務作業で他部門から資料をもらってそれをベースにこちらでも資料を 作成することって多いですよね？ 定型的な業務であれば全社システムに入力すれば自動的にアウトプットまで 出来る状況であっても、セミオートマティックな部分って必ず残ります。 常にではないがアドホックに必要な資料でかつ、人間の予想値や判断値及び それらに対する施策とかを網羅的に纏めるようなものです。 で、まあそんな仕事をどのようにしてこなしているのでしょう？ 他部門からエクセルで該当資料を電子メールの添付ファイルで送ってもらう ってところまでは…多分？もう全国的な共通ステップだと思われます。 では、それ以降どうするかをエクセル習熟度別に見てみましょう。 段階その１． 電子メールで受け取ったエクセルファイルをプリンターでアウトプットして、 なんと！紙の上で数字を拾ってそれを電卓で叩いて計算している人を見たこと があります。 またご丁寧にその計算結果を自分のエクセルの表にキーボードで 再入力しておられた。 ウッソー？って思うでしょう。が、しかし 存在されるのです。 確固として日本のオフィスにはそのような「天然記念物」的 エクセルユーザーの方がおられます。 ご本人はこれが最も確実と、もはや信仰？の域に達しておられますからして 決して作業中に声をかけたりなさらないように。 「今まで計算した分、どうしてくれるのよぉ！」って…。 しかし皆様、このような方を決して軽んじたりしてはなりませんぞ。 こんな会社こそソフト開発会社の狙い目！っとかいう意味ではなく、 不思議とこんな人が最も業務に精通していたり、他部門の信頼が厚いことが 多いのです。 何故か？ まずプリントアウトして紙に出すことにより自部門に関する部分だけでは なく、俯瞰的に他部門全体の状況を見ておられるからであります。 また電卓を叩くことにより指の感覚が数字を覚えこむのです。 つまり先月と少し感覚がおかしい？と気付くケースが多くなり、必然的に エラーやミスを発見しやすくなります。 人間工学的に申さば「全身体機能」を動員して仕事をやっておられる次第です。 ただ、作業が遅いのと…自分の計算ミスには気付かないことを除いて…。 段階その２． どうなんでしょう一般的には自分でエクセルのフォーマットを作って それを関連部門に電子メールで配り必要部分だけに入力させる要領の良い タイプが多いのではないでしょうかねぇ？ それを集めて串刺し計算なり関数を使って纏めるんです。 それに自部門の入力部分だけを打ち込んで完成です。 ところ、が、居るんですよね？ 必ず他部門に、そのフォーマットに小計行を入れたり列を勝手に挿入するのが…。 シートに保護をかけとけば良いジャンって？ でもあれってパスワード忘れたり、保護かけたつもりがかかってなかったりして、 あまり信用できないところがあります。 で、件の要領の良い担当者は纏め終わりグラフまで作成した「後に」大抵！ それに気付くのであります。 何故か？ つまり数値を確認してないからです。グラフまで作り終わって始めてその形が オカシイ？と気付くのであります。これも人間工学的に申し上げれば 人間の視覚による形状把握機能は計算機能をはるかに凌駕しているから であります。 で、最初からやり直しぃ〜〜！ 段階その３． お待たせしました。エクセルVBA派の皆さん。 いよいよ、VBAの登場です。 他部門の連中が列を挿入しようが、集計行をいれようが列項目と行項目の 接点が欲しいデータであることに変わりがありません。 ただその位置が動いてしまうから串刺しが機能しなくなるのです。 例えば支店別費用明細から列項目：大阪支店の、行項目：交際費「だけ」を 抜き出すサンプルをご覧にいれましょう。 タイガーズがリーグ優勝した時は全国の企業で一斉に行われる共通作業で あります。（20年に一回程度ですが…） まずはYabaiOosaka Functionを作ります。 Function YabaiOosaka(Field As String, Rgyo As Long, Data As String, _ ColNo As Integer, Optional Ws As Worksheet) As Integer Dim mRng As Range Dim mRowNo As Long Dim mColNo As Integer Dim mWs As Worksheet If IsMissing(Ws) = False Then 'よくこれを日本式にTrueとする人が居ます。 '英語のNoと同じ感覚ですからね。 Set mWs = ActiveSheet Else mWs = Ws End If Set mRng = mWs.Rows(Rgyo).Find(what:=Field, lookat:=xlWhole) If Not mRng Is Nothing Then mColNo = mRng.Columns.Column Else MsgBox "支店名がありません。" Exit Function End If Set mRng = mWs.Columns(ColNo).Find(what:=Data, lookat:=xlWhole) If Not mRng Is Nothing Then mRowNo = mRng.Rows.Row Else MsgBox "費目名がありません。" Exit Function End If getData = mWs.Cells(mRowNo, mColNo).Value End Function VBAをやってる方は比較的良く使うテクニックなんで詳細には 説明致しません。 そしてKutabareTigers Subから呼びます。 Sub KutabareTigers() Worksheets("Kiseki").Activate Range("H2") = YabaiOosaka("大阪支店", 2, "交際費", 1) '支店項目行が2行目、費目列が1列目の場合です。 End Sub 概して関東のプログラマーは理論派が多いようです。従って前々回に ご説明致しました関数型言語などは圧倒的に関東が盛んであります。 上記のFuntion YabaiOosakaも関数です。関数は本来純粋にIOプロセスが 流れ、不純な要素が入りこむ隙が無いことをご説明しましたが ご記憶でしょうか？ ニュートン力学の可逆性を重視したもので「あった」はずです。 ところが関西系のプログラマーときたら「ゴチャゴチャゆうとらんと プログラムは動きゃええんじゃぁ！」とまあ実にマイクロソフト的？な 人々の集団であります。 そこで純粋関西流VBAをご覧にいれます。 まずはEezooOosaka Function から： Function EezooOosaka(Field As String, Rgyo As Long, Data As String, _ ColNo As Integer, Optional Ws As Worksheet) As Integer Dim mRng As Range Dim mRowNo As Long Dim mColNo As Integer Dim mWs As Worksheet If IsMissing(Ws) = False Then Set mWs = ActiveSheet Else mWs = Ws End If Set mRng = mWs.Rows(Rgyo).Find(what:=Field, lookat:=xlWhole) If Not mRng Is Nothing Then mColNo = mRng.Columns.Column Else MsgBox "支店名がありません。" Exit Function End If Set mRng = mWs.Columns(ColNo).Find(what:=Data, lookat:=xlWhole) If Not mRng Is Nothing Then mRowNo = mRng.Rows.Row Else MsgBox "費目名がありません。" Exit Function End If getData = mWs.Cells(mRowNo, mColNo).Value 'なんと、ここまで関東流と全く同じです。名前をEezoo？に変えただけ、 '連中は「真似しぃ」することになんの廉恥心もありませんから。 '「かめへんやんけぇ。」の精神だそうです。 'そして： Dim Yasukatta As Variant Dim i As Variant Dim j As Integer Yasukatta = Array(Now, Field, Data, mWs.Cells(mRowNo, mColNo) _ .Value) On Error GoTo addSheet Worksheets("食い倒れ").Activate For Each i In Kdata j = j + 1 Cells(65536, j).End(xlUp).Offset(1).Value = i Next Exit Function addSheet: Dim cnt As Integer cnt = Worksheets.Count Worksheets.Add after:=Worksheets(cnt) ActiveSheet.Name = "食い倒れ" Resume End Function GoToからErrorまで使いまくって、 べちゃぁ〜とこれですもんねぇ。 関数型言語派が見たら「目ん玉が飛び出る？」 状態遷移を関数の中に書きこみ、かつ： Sub MainenYuushouTigers() Worksheets("NipponIcchaa").Range("T1") = _ getData3("大阪支店", 2, "交際費", 1, Sheet3) End Sub こんなコードで呼ぶ訳です。 「ナ,ン,デ,ス,カ？これは？」と聞けば １．数値確認が支店別、費目別に時系列で可能。 ２．Nowで取得する日時がユニークなのでMainKeyにしてデータベース としても使用出来る。（確かにタイガーズが優勝したら神戸支店を中心に 近畿一円の支店全部の交際費がYabai！） ３．Functionに入れとけばどこのSubから呼ばれても確認漏れがない。 とまぁ〜理路整然と、のたまう次第です。 「要らんよぉになったら、コメントアウトせぇやぁ。」ですって。 う〜ん、成る程関西流も捨てたもんではありません。 確かにこれでコードの透明性は保ちながらかつ取り外しが自在です。 ブラックボックスのコンポーネントを組み上げるプログラミング手法から 関西流のおまけ手法です。 コードから逆にコードを削減（おまけ）する。 明示的にオマケが見える形で簡単に捨てられるような構造にしておく。 関数機能にゆるい結合で状態遷移を組み込んで、見栄えは確かに悪いが 実用的ですよねぇ？ って、結局ぅ…エクセルVBAはぁ…関西流が似合うのかぁ。 目次へ
|