« 雑記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


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

« 雑記070710 | Main | 雑記070712 »