ERPの落とし穴part1～SW開発ではない。要求開発だ！

今まで数々のERP開発に携わってきたけれど、正直楽しかったと言う印象はあまりない。
開発者が想像するソフトウェア開発とは何か違う。

そんな時に梅田弘之さんの「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」を再読して、ERPについて色々と感じるものがあった。
ERPの落とし穴やポイントについて考えたことをメモ。

【1】ERP開発はソフトウェア開発ではない。要求開発だ！

ERPは基幹系業務システムのためにある。
その開発スタイルは正直ソフトウェア開発ではないと直感している。
開発者がイメージするソフトウェア開発は、問題やタスクをプログラミングやサーバー構築などの技術で解決していくこと。
その作業は大変だが、やりがいはある。

しかし、ERP開発では、顧客から要求を収集し、要件として定義して後続の設計作業に落とし込む作業期間が非常に長い。
開発できる段階になれば、正直楽なものだ。
実際は、要件定義に非常に時間がかかっている。何故なら、顧客の要求を全て聞き出して、更に整合性のとれた要件にまとめるのは至難の業だからだ。

ここで中核となる人物はいわゆる業務SE。
プログラムは書けないけれど、業務にとにかく詳しい人を指す。
彼らは、ExcelやWord、PowerPointを駆使して、システムのイメージを作り出す。
要求をまとめて要件に確定するのが彼らのお仕事。
彼らの開発スタイルは、ソフトウェア開発ではない。要求開発だ。

萩本さんが提唱する要求開発は、おそらくこの部分で最も威力を発揮するのでは？と思ったりする。

プログラミングを得意とする開発者から見れば、業務SEは顧客との駆け引きがうまいが要件をきちんとまとめられなければ、口先だけじゃないか！と思ったりもする(笑)

【2】システムの外部接続が多い。外部接続のI/Fがリスク要因になる

ERPを導入する時の注意点の一つとして、ERPへ取り込むデータを外部システムからもらったり、逆に外部システムへデータを送る機能を要求開発で早めに洗い出すことがあげられる。
外部システムへ接続する要件は頻繁にあり、それはリスクが高い。
何故なら、ERPの要件定義だけでも大変なのに、外部システムの仕様まで抑えないといけない上に、接続テスト環境を準備するのも大変だからだ。

よくある例は、メインフレームの会計システムへERPで作ったデータを送信する時があるだろう。
ERPでは会社の日々の業務を支援するが、取引で発生したお金のやり取りは、外部の会計システムへ連携するパターン。

外部接続が難しい理由の一つは、接続のタイミング。
日次夜間なのか、月次なのか、年次なのか、リアルタイムなのかタイミング情報を収集し、ERPの業務データと整合性を取らねばならない。
この作業は業務を知らなければ結構難しい。

外部接続で使う技術の例としては、HulftとEBがあげられるだろう。

Hulftはメインフレームとオープンシステムの間でよく使われる接続プロトコルで、日本ではよく使われている。
集配信サーバー上にHulftファイルと言うバイナリファイルを送り、取り込んでもらう。
APIも技術もかなり枯れているから、実装は難しくない。
だが、要件定義がしっかりしていないと、HulftファイルのI/F定義書通りにデータが作られていなかったりする時があるので、接続テストで泥沼にはまる時がある。

EBは、エレクトロニック・バンキングの略で、銀行振込や入金の作業を自動化する接続プロトコル。
日本の銀行は全銀協という団体に属していて、銀行番号と支店番号がユニークに振られている。
全銀TCP/IPという接続プロトコルを使って、銀行の当座預金から入出金する。
最近は、請求業務だけでなく、出張旅費の仮払精算や給与振込でも使われるようだ。

全銀フォーマットというテキストファイルに入手金情報を書いておけばいいから、この技術もかなり枯れている。
しかし、要件定義がしっかりしていないと、どのDBから入出金情報を取得するか、どのタイミングで入出金するかという所で泥沼にはまる。

【3】品質要求の中でも移植性が重要視される

ERPは既存のパッケージ製品や既存のシステムをカスタマイズして作る時が非常に多い。
既存のパッケージ製品があるならば、同じ物を一からスクラッチ開発する必要もないし、コスト削減になる。
何よりも、既に運用されているから品質も担保されている。

従って、既存のシステムをそのままコピペする作業が非常に多くなる。
しかし、元々のシステムが移植性を考慮していない設計になっているともう大変。無駄な機能まで取り込んでしまい、システムが膨れ上がる。
だからこそ、品質要求の中でも移植性が非常に重要視される。

移植する作業方法としては２パターンある。
一つは移植元のライブラリはいじらず、I/Fのラッパーを作って動かす手法。
もう一つは、移植元のライブラリを若干修正して移植先へ移す手法。

前者は、Cobolの時代から行われてきた手法で、このやり方を使える状況ならばできるだけ使った方がいい。
I/Fの仕様さえ抑えれば、ラッパー部分だけ作る作業はそれほど工数がかからない。
しかし、結合した時に性能が悪くなる場合があるので、非機能要件に注意した方がいい。

後者は、特に組込製品でよく発生する手法。
心臓移植などと同様で、既存ライブラリをそのまま移植先へ持っていける状況はそう多くない。
移植元のライブラリを若干修正して、移植先の環境に合わせる時が多い。
しかし、この手法を使うと実装工数よりもテスト工数が増えるし、修正時に別のバグを入れ込む危険も出てくる。
又、移植元のライブラリがバージョンアップしたら、移植先にも同様に取り込む必要があり、その作業が非常に難しくなる。
移植先に合わせて修正しているから、マージ作業が大変なのだ。
ERPでは、このやり方を実施してデスマーチにはまる時が多い。

後者については、パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)にあるベンダブランチという構成管理技術を使えば、問題を改善できるだろうと思う。
つまり、移植元のライブラリはベンダブランチとしてバージョン管理し、移植先のシステムへ取り込む時にマージ作業をバージョン管理ツールを使って補完すればいい。
MercurialやGitなどの分散バージョン管理を使っていれば、ベンダブランチからtrunkへのマージ作業は楽になるだろう。

part1ではERP開発の開発プロセスや技術に関して、考えをまとめてみた。
他にも書きたいことは後で書く。