1. 既存システムを廃棄しERPを導入，すべてのアプリケーションの基盤とする。
2. 画面とドキュメントをたどり，既存システムの仕様を解読する必要に迫られた。
3. 遅れを取り戻すため，要件定義の最中に一部機能の実装を開始。

　「開発当時の担当者が退職してしまったので，既存システムの仕様が全く分からなかった。開発を委託していたベンダーの協力も得られなかった。その結果，新システムの要件定義に予想外の時間がかかってしまった」。

　2005年2月，中小企業向けERPパッケージ「SAP Business One」をベースに，顧客管理システムを開発・稼動させた岡本昌子氏（信和総合リース 情報システム部）は，こう振り返る。同氏はプロジェクトを通して，既存システムの仕様を確認する作業に明け暮れる日々を経験していた。

　会計事務所や金融機関を相手にコンサルティングや業務のアウトソーシングを手掛ける信和総合リースは，顧客管理と会計の各システムを2005年1月までに稼働させる予定だった。開発を担当したパーソナル情報システム SAPコンサルティング部 課長 辻本和寛氏は，「SAP Business Oneの導入期間は，今回のような規模であれば2カ月で十分」という。実際，信和総合リースでも実装は苦労しなかった。だが，それ以前の作業で遅延が発生した。

　結果的に，顧客管理システムを2005年2月に稼働させ，会計システムは3月以降に検討を開始することになった（図1）。

図1●ERPパッケージ導入プロジェクトの計画
図1●ERPパッケージ導入プロジェクトの計画
顧客管理システムは2005年2月に稼働，会計システムは2005年3月に検討開始というスケジュールに変更した。要件定義に手間取ったことが原因だ
[画像のクリックで拡大表示]

「Access」から「SAP」に移行

　このプロジェクトの主な目的は，問題が山積みとなっていた既存システムの弊害を完全に取り去ることにあった。それは，データベース・ソフトのMicrosoft Accessをベースに開発した顧客管理システムである。

　併せて，これまで会計事務所に丸投げしていた会計システムを新規に開発する。自前のメール・サーバーを持ち，メール・アドレスの体系も整備することにした。

　このうち最大の問題は，顧客管理システムにあった。既存システムは，機能を2台のPCサーバーに分割して運用していた。1台はLAN上に設置してパソコンからアクセス可能，もう1台はLANから切り離されたスタンドアロンで運用しており，相互に連携していない。そのため両方のPCサーバーは，必要なマスター・データなどを重複して保持している（図2）。

図2●既存システムの問題点
図2●既存システムの問題点
「運用が煩雑」「セキュリティが甘い」「障害対策がない」など，既存システムは問題が山積みだった。ERPパッケージにリプレースすることで，こうした問題の一掃を図った

　「2重入力が必要になる上，データを更新するタイミングがルール化されていなかった。最新データが欲しくても，それがどちらにあるのかも分からず，営業担当者が探すのに苦労していた」（岡本氏）。

　セキュリティもないに等しい状態だった。Accessにはアクセス権限の設定機能がなく，だれでも自由に閲覧や更新ができる。データのバックアップも取っておらず，障害があったら手の打ちようがなかった。信和総合リースは，これらの問題をERPパッケージ「SAP Business One」の導入で一掃しようと計画した。

システムの振る舞いを逐一確認

　問題は，要件定義の段階で発生した。この作業だけで，当初の稼働予定である2004年11月下旬までかかってしまったのである。

　要件定義は，まず現行業務と既存システムの分析から始めた。作業は，システムとドキュメントの両方を細かく見ていく形で進められた。

　しかし，そこに落とし穴があった。既存システムの開発担当者は既に退職していたため，システムの内部に精通した人が社内にだれもいなかった。当時の開発ベンダーに協力を仰いでみたが，「分からない」と断られてしまった。一方で，設計ドキュメントの内容がかなり不明瞭だった。これでは分析作業は進まない。当初はその重大さに気付いていなかったが，岡本氏は営業企画部の藤井美幸氏とともに，“既存システムの解析”で苦労することになる（図3）。

図3●既存システムから仕様を読み解く
図3●既存システムから仕様を読み解く
既存システムの振る舞いを一つずつ確かめながら，不明瞭なドキュメントと突き合わせて仕様を確認した
[画像のクリックで拡大表示]

　とにかく既存システムの機能を調べなければならなかったので，手探りで作業を進めた。まず，Accessで開発したシステムの画面上でボタンを一つずつ押していく。「どういうインプットに対してどういうアウトプットがあるかを逐一チェックする」（藤井氏）。次に，そのデータが格納されているテーブルを調べる。「テーブルの構造やコードの定義がどうなっているかを調べた。中には壊れているとしか思えないモジュールもあった」（藤井氏）。

　調べた結果を，ドキュメントやソースコードと照らし合わせて検証していった。ドキュメントは分厚いバインダ4冊に上る。膨大な作業である。

　前任者によるドキュメントは，第三者から見てきれいに整理されているとは言い難かった。書かれている内容は，マニュアルっぽいもの，議事録，コードの説明などで，それらが入り交じっていた。この情報をシステムの振る舞いと突き合わせ，参考になりそうな部分を一つずつ抜き出す作業が続いた。

　「各機能に対する分かりやすいマニュアルがない。データ項目の属性も明記されていない。そのため，各データ項目がどういう意味や役割を持っているかをロジックと比較しながら調べていかなければならなかった」（岡本氏）など，作業は困難を極めた。

　既存システムの利用者に実際の処理方法についてインタビューすることも交えながら，ベンダーと一緒に仕様を解読し，ロジックを再構築していった。旧コードを廃止して新コード体系を設計しようとしていたら，突然そのコードがキー・コードであることが分かり，システムへの影響を考えて棚上げにせざるを得なくなることもあった。