« 雑記070710 | Main | 雑記070712 »

2007.07.11

EXCELレガシー

うまいネーミング。下町エレジー(死語)とは違う。
いや、同じか(笑)。

御意見募集、“Excelレガシー”への対処法
読者10人と考えた「Excelレガシー」再生への道

素人なりに考えてみる。

◆可読性
VBAに集約してまともな作法でコードを書いていれば、さほど問題ではないと思う。少なくとも、EXCEL以外のレガシーなシステムと同様の問題。それならば、例えば2007年問題などの枠組みの中で処理すればよい。

一方、セルに関数を埋め込むなど、readableでないものは確かに問題が大きい。基幹的な業務フローの中に、そうした可読性の低いものが組み込まれているとすれば、すぐに直すべきだろう。

◆継承
修正する際の基盤として、EXCELVBAを引き続き使うかどうかはケースバイケースかもしれない。マイクロソフトにはバージョンアップの度に痛い目に合っていると思うなら、別の選択肢もあるだろう。

◆管理
EXCELレガシーをユーザ部門が使う(使わざるを得ない)理由は、情報部門のシステムでは業務上不足があるからだ。単に機能が足りないだけでなく、日々変化する諸事情への対応力が足りないという意味も含む。
この問題は、情報部門に対応を集約している限り避けられないから、やはりユーザ部門である程度EUCをする必要はあるだろう。
管理者としては、自分の部署の業務を詳細に把握して、以下のルールを守らせるといったところか。

◆EXCELレガシーで守るべきルール
より正確には、EXCELレガシーをレガシーでなくす方法。簡単なルールをいくつか守るだけでいい。

○業務フロー自体をモジュール化する。
肝は、「完全自動(black box)は悪」と考えるスタンス。
小さくて抽象度の高い単機能モジュールをつくり、それらを繋ぐことで業務フローを形成する。単機能だからユーザ部門自身にも理解しやすい上に、どれかひとつのモジュールが動かなくなっても、とりあえず人海戦術でカバーしている間に復旧できる可能性が高まる。少なくとも致命傷は予防できる。

○コードは構造的かつ可読に。最低でもコメントはまめに。
古臭かろうが真理は真理。コード書きの基本的な作法だが、守られているのかどうか。EUCでは軽視されているかも。

○説明書
仕様書といわないまでも、入力、参照先、出力とフローの大筋など、動作の流れについての説明書は作る。オペレーションマニュアルとは別に。モジュールごとのものと、フロー全体のもの。

 

なんだかごく一般的なルールばかりだが。
Accessを使ってちょっと複雑にしすぎた過去のケースを振り返ってみて、内心忸怩たるものがある、その反省を込めて。(汗)

いや管理者はたいへんですな。
とヒトゴトのように(笑)。



こわい話しとして、こんな記事も。
【識者の一言】スプレッドシート統制、「連結決算業務」に注意

基幹的業務でこういう方法がまかり通っているのは、情報部門の怠慢以外のなにものでもないだろう。

 

|

« 雑記070710 | Main | 雑記070712 »

日記・コラム・つぶやき」カテゴリの記事

Comments

Post a comment



(Not displayed with comment.)


Comments are moderated, and will not appear on this weblog until the author has approved them.



TrackBack

TrackBack URL for this entry:
http://app.cocolog-nifty.com/t/trackback/7081/15721256

Listed below are links to weblogs that reference EXCELレガシー:

« 雑記070710 | Main | 雑記070712 »