※今回の記事は基本的に自分用の備忘録です。
VBAの学習における知識の依存関係の整理を試みた。
試みたというのは、お世辞にも成功したとは言えない為である。
書籍でプログラミングを学ぶ際は、ふつう1ページずつ読み進めていく。
これに対して、実際の知識体系は必ずしもシーケンシャルに整理できるわけではない。
たとえばオブジェクトを正しく理解しようと思ったら、中身がどうなっているのか知る必要がある。つまりオブジェクトの知識はクラスの知識に依存すると考える。
クラスはモジュールなので、前提としてモジュールの知識が必要になる。また、プロパティ・メソッドの理解には前提として変数とプロシージャの理解が必要になる。
そんな風に整理していった結果。。こうなった。
知識の依存関係をある程度表すことができたかなとは思うけれど、見て分かりやすい図ではないし、実際のところはこれより更に複雑だと思う。相互依存もあるはず。
VBAに限らず、知識の依存関係というのは有向グラフになっていて、その学習順序は巡回セールスマン問題を抱えているのではないかという着想を得た。
きちんとグラフを定義して、その最適経路を求めれば、最も効率の良い説明順序が求められるだろうか。
理解度の整理(追記)
ただ実際のところクラスを知らなくてもオブジェクトは使えてしまうんだよなぁ…と考えてたところ、「そうか、これは理解度の問題だ」と気づいたので追記。
理解度を図るバロメーターについてもざっくりと整理してみた。
たとえば以下のように知識Bが知識Aに依存していたとする。
知識Bを単体で学習したとき、知識Bの理解度が1、知識Aを学んだ場合、知識Bの理解度は2になると考える。
逆に、知識Bを学んだことで、より知識Aの理解が進むということも考えられる。何等かの関係がある2つの知識がその理解において完全に一方通行であるとは考えにくい。※ただし矢印を両向きにすると分かりづらくなるのでグラフ上は、より強い依存関係のある方を採用する。
つまり知識Aを単体で学んだ場合に比べ、知識Bを合わせて学んだ場合、知識Aの理解度も2になると考える。
サンプルとして知識A～Dの依存グラフとその最大理解度を描いてみた。
その知識自体を学習したときに1、関連する項目を学習したときに項目ごとに1レベル上がるという整理。
厳密に言えばその知識自体の学習と、依存元の学習と、依存先の学習で、それぞれその知識に入ってくる経験値って違うんだろうな。
でもシンプルに整理したほうが活用はし易いのでそれは置いておこう。
なんでこんなことを考えているのか(追記2)
なんでこんなことを考えているかというと、発端としては私がブログ記事を書く際に、「この記事を読むには知識Aと知識Bが必要です。」という風に、依存関係をライブラリの参照設定のように書けたら、わざわざ毎回同じような説明を書かなくても済むなぁと思ったから。
↓この先、妄想の世界なので注意。
要は知識のモジュール化である。
知識のモジュールはフォーマットだけ決めておいて、誰でも代替モジュールを作れるようにする。決められたヘッダの付いたパワポ1枚とかでも良いし、ブログのようなメディアの記事1本を1モジュールとしても良い。
学習する人は、ジェネリック医薬品のように、自由に代替モジュールを選んで学習することができる。変数はAさんのモジュールで学習し、関数はBさんのモジュールで学習する。オブジェクトは複雑なのでAさんのモジュールをメインにしつつもBさん、Cさんのモジュールで知識を補完するなど。
既刊のVBA書籍を買ってきてバラバラに切り刻んでモジュール化する手もあるか。。でも著作権がある以上オープンな場に出せないから自由に参照させるってわけにもいかないし、書籍の場合は前後で依存関係を考えて編纂されてるので切り出した単品をモジュールとするのは無理があるか。。
ということで今のところアイデアを温めているだけ。何も作る予定はない。
以上、そういう学習方法があるとおもしろそうだなぁという妄想でした。
