システムの「モグラ」化とは
RFP（提案依頼書）を作成する際に、モグラのように穴の中、陰に潜んで、どこにあるのか、どんな機能があるのか、どんな価値があるのか不明なシステム、プログラムに遭遇することがあります。私はこれを「システムの“モグラ”化」と呼んでいます。
ITの世界では、複雑すぎて解析・保守が困難であり、修正したら他のプログラムにどんな影響を及ぼすのか計り知れないプログラムのことを「スパゲッティープログラム」と呼びます。
ここで言う「モグラ」化したシステムとは、
- 仕様書がなく、プログラムソースを見ない限り仕様がつかめないシステム
- システム製作者や、システム外注担当者が退職してしまい、社内の誰も仕様を理解していないシステム
- 社内の数人が利用しているが、そのシステムの構造、仕組みを、利用者の誰も理解していないシステム
などを指します。
このようなシステムは、基幹システムの一部に潜んでいたり、基幹システムのサブシステムとして存在しているケースがあり、基幹システム更改時に「仕様漏れ」としてトラブルの元凶となります。
「モグラ」化したシステムを見つけるポイント
私の経験では、データベースソフト（Accessなど）を使用したシステムや、表計算ソフト（Excelなど）のマクロを使用した基幹システムに多く見受けられます。こうしたシステムは、比較的構築が容易であるため、社内SEが作成したり、社外に低価格で外注したりして作成されます。
もちろん、これに限らず、その他のソフトウェア、プログラム言語でも遭遇します。
「モグラ」化したシステムを全て見つけ出すためには、社内の業務をどこまで理解しているか、社内業務を理解した人材をシステム更改プロジェクトにしっかりと巻き込めているか、がポイントになります。
システムの「モグラ」化を防ぐために
システムの「モグラ」化を防ぐためには、常日頃から、社内の全システムの概要を記述した「システム全体概要書」、各個別システムの「仕様書」を文書で作成して、システム変更に合わせて、文書も継続的に更新していく必要があります。
「システム全体概要書」については、社内で説明会や勉強会を開催することで、システム担当でない社員でも理解できるレベルを目指します。社内のシステム担当者が突然いなくなったり、異動しても大丈夫なようにしておくことが重要です。
「個別システム仕様書」については、社内や外注先のシステム関係者が理解できる内容を整備することになります。特に、自社オリジナルに開発されたシステムであれば、プログラムの詳細な処理内容やデータベース仕様の文書化が欠かせません。
これらの整備にはそれなりに時間がかかる場合もありますが、常日頃から地道に行っていくことが、将来の基幹システム更改におけるリスクを軽減し、システムの「モグラ」化を防ぐ近道となります。
