読者10人と考えた「Excelレガシー」再生への道：ITpro

いきなり脱線して、レガシーをどうするかから離れて遺産を残さずに資産を残すにはどうしたらいいだろう、というところに問題意識が集中してしまったので、そこだけ書きます。というのも、自分は Excel レガシーには困ってないからです。ということで世迷い言を言ってる可能性はありますが、そこら辺を踏まえて読んでください。

個人的にはですが、Excel VBA は絶対にやんないっすね。分からないからとか、やれと言う上司がいないからというのもあるわけですが、やはり危険な匂いがプンプンするからです。これは別に内部統制がどうとかで最近言い始めたわけじゃないです。それは

データとアプリが一体化していいのはパーソナルユース限定

だと思うからです。iTunes とかね。

基本的なスタンスは、専門性の高くない人が個人で頑張って Excel を活用することまでは否定しないが、システムを専門にする人間は作っちゃダメ、という形。これは、専門性の高くない人ならそれほど大規模なものは作らないだろうから、というのと、そこまで禁止するとお互いにギスギスして仕事しにくいからです。難しいのは作り込み終わった Excel アプリを直したくなってしまうケースなんですが、これも手を出さないようにしてます。

どうしても必要ならExcel の外にひっぺがして別なものを作ります。この際は当然データ構造も明確に定義しますし、アプリ側も保守が可能であることを前提にフツーに作るわけです。

こういうのは Excel じゃないものに当てはめてみればすぐに分かるんじゃないかと思います。例えば細かい sh スクリプトが何本も絡むようなものって、組んでる最中は早いんですけど、あとで大変だなと思うわけですよ。そしたらこれはもうちょっと高級なスクリプト言語にして一本化すべきだなとか、ライブラリにすべきだなと思いますよね。スクリプト言語にすればドキュメンテーションも楽になることが多いですし。

もちろんシステムを専門にしない人には基本的にその辺の嗅覚がないわけですから、頑張り過ぎちゃった場合には大変なものが残ることはあります。Access とかね。

で。

ちょっと思ったのは、あえて EUC の分野にも構成管理やコミュニケーション、ドキュメンテーションの重要性を持ち込んじゃうのはどうだろう？ というか恐らくですけど、シスアドの教科書には構成管理はともかく残りの二つは載ってると思うんですよね。Excel などのマクロを組み始めるというのはすでにシスアドの世界に足を踏み込んでいるものと看做して、検定や参考書にその世界の知識、ノウハウも載せていくべきなんじゃないでしょうか。

いや難しいのはよく分かりますよ？ ただ、アプリを作った場合はその後の責任も考えるようにしましょうという、雰囲気や流れは作っておくべきじゃないかなと思うわけですよ。むかーしワタシ表計算検定なるものを受けたことがありまして、当時は Lotus1-2-3 のマクロだったわけですけど、その試験ではやはりマクロが組めるかどうかで話が終わってるわけです。恐らく現在の検定も似たようなもんじゃないかと思うんですけど、ここに、

マクロを組む際、あるいは組む前に注意すべきこととして、

• そのブックはみんなが使いますか？
  • みんなが使う場合はどういう作業ができたらよいか、どういう機能がほしいかをまずみんなで相談しましょう
• あなたはいつまでその作業に関わりますか？
  • それは引き継ぎ可能ですか？
  • マニュアルや内部動作の資料をちゃんと作っておきましょう¹
  • 具体的な残し方

てな辺りを、もう試験内容として組み込んでしまうべきなんじゃないかと思ったわけです。

いやまぁ、現存してる Excel レガシーには何の効果もないですけど、今後ね、今後どうしたらいいかというときに、少しはマシになるんじゃないかな、とね。

……。

だから先に書いたでしょ！ 話ずれてるって！ べつに Dan メソッドじゃないよ！