ERPはなぜ難しいのか？～オープンソースERPで業務改革を試したい

SIの受託案件の殆どは、基幹系業務システムの開発・保守だと思う。
業務システムは、Webサービスのような華やかなシステム開発ではない。
それら業務システムは、最終的にはERPを目指しているが、ERPはとにかく難しい。
考えたことをメモ書き。

【元ネタ】
ERPシステム（１）日本式経営との適合性 | 香港★起業★日記

ERPシステム導入が難しい理由（１）縦割り組織の弊害【修正版】 | 香港★起業★日記

ERPシステム導入が難しい理由（２）ガバナンスの問題 | 香港★起業★日記

ERPシステムの導入が難しい理由（３）カスタマイズ依存の問題 | 香港★起業★日記

ERPシステムの導入が難しい理由（４）スイッチングコストの問題 | 香港★起業★日記

【0】ERPは、会社の基本業務をシステム化したもの。
普通は、「購買管理」、「在庫管理」、「販売管理」、「会計管理（財務会計／管理会計）」、「顧客管理」などの機能を含む。
最近は、ビッグデータ活用として、経営分析に使われるBIや、顧客の購買履歴に着目して分析するCRMなどの機能も含まれるだろう。
つまり、ERPを業務の面からもシステムの面からもマスターすると、幅広い業界の商い習慣やITにも詳しくなる利点はある。

しかし、ERPはマスターするのが本当に難しい。
今までの経験から、その理由を考えてみた。

【1】ソフトウェア以外の業務知識、会計知識が必須

ERPは会社の業務をIT化するために、まず業務の内容を知っているのが前提。
コンビニでバイトした経験があるなら分かるだろうが、商品の発注から仕入れ、入出庫、販売、売掛金回収など業務は幅広い。
そして、ERPは最終的には、損益計算書や貸借対照表、キャッシュフロー計算書などの財務諸表を月次で出力するのが基本だ。

そういう業務の経験がないと、どんな仕様で画面や帳票を作ったら、ユーザの役に立つのか、という発想が出てこない。
業務システムでは、毎日、大量のデータを入力しなければならない。
受注や発注の入力画面では、タブキーを使って、キーボードだけでたくさんの種類のデータを大量に入力する。
仕入れ伝票、売上伝票、出張旅費や経費の精算など、お金に関わる業務は、会計監査や内部統制の観点でも、その入力データの完全性や一貫性が求められる。

業務を知らないプログラマが実装すると、ユーザがどんな状況でどのように使うのか、という場面を想像できないから、使いにくい画面UIになってしまったり、会計帳票や出荷指示書では必須の項目が漏れていたり途切れたりして出力される場合がある。
プログラミングだけできる人は、業務システム開発ではあまり役立たないのだ。

だから、販売管理や在庫管理、会計などの知識は自主的に勉強する必要がある。
お勧めは日商簿記の3級、2級だろう。
商業簿記や工業簿記を一通り勉強すると、個人商店や株式会社の経理の仕組みが分かるので、少なくともお金の流れを理解できるようになる。

でも、業務システム開発を自主勉強しようにも、ERPはそう簡単に作ることはできないから勉強しづらい。
現場でどう使うのか、システムはどのような操作が望ましいのか、色々試してみたいのに、机上の勉強しかできないのだ。

業務システム開発がどうしても、プログラミングよりも設計書中心の開発になってしまう理由は、そういう面もあるからだろう。

【2】アーキテクチャが複雑

業務システムは、Webサービスに比べるとアーキテクチャが複雑なのが普通。
複雑なアーキテクチャになってしまう理由はいくつかあると思う。

一つは、業務システムは今もクライアント・サーバー方式が主流だから。
つまり、Webシステムのように、クライアントはブラウザだけという仕組みは採用しにくい。
理由は、発注伝票や受注データのような大量データの入力は、ステートレスな方式設計では使いづらいから。
だから、クライアントアプリを各端末にインストールして、入力UIをかなりカスタマイズするのが普通。

しかし、クライアント・サーバー方式は、Webシステムが主流となった現代のシステムアーキテクチャと相性が良くない。
ビジネスロジックがクライアントにも分散されているので、保守しにくい。
また、クライアントのアプリを一斉にVerUpするための配布方法も一苦労だ。
Webシステムなら、サーバーにデプロイするだけでいいのに、各クライアントに逐一ダウンロードしなくてはならない。
クライアント端末の電源が落ちていたら配布できないし、OSや.NETのバージョンが微妙に違うと正常動作しない危険もある。

2つ目は、ERPと他システムとの外部接続という特有のアーキテクチャが必要なこと。
例えば、EコマースやらCRMやらBIやら、たくさんのWebシステムが乱立してしまったために、ERPとデータをやり取りする仕組みを別途作らないといけない。

外部接続のアーキテクチャとしては、SOAPやRESTのようなHTTP経由のリアル連携もあるし、メッセージキューイングもあるし、FTPやHULFTのようなバッチ連携など種類がたくさんある。
それぞれのアーキテクチャの癖については、下記に書いた。

ERPの落とし穴part3～外部システム連携がプロジェクトのボトルネック: プログラマの思索

外部接続のアーキテクチャでは、耐障害性や性能などの非機能要件がボトルネックになりやすい。
だから、アーキテクチャの検証に十分に労力をかける必要がある。

3つ目は、データ移行やシステム移行のような移行作業が別途必要なこと。
ERPを作ったからといっても、マスタデータがなければ、ただの箱に過ぎない。
必要なデータを、過去のレガシーシステムから持ってきて、ERPと言う箱に入れなければならない。
システムを完全にリプレースする案件ほど、DBのレイアウトそのものが当然違うので、データ移行がとても大変になる。
その時の注意事項も下記に書いた。

ERPの落とし穴part5～コード設計の難しさ: プログラマの思索

更に、システムやそのハードウェアをVerUpするだけでも、その作業はかなり気を使う。
業務システムは停止してはいけないから、普通は、パイロット方式で特定の部門に先行導入したり、旧システムと新システムを並行運用したりする。
この辺りも記事に書いた。

ERPの落とし穴part4～システム移行という名のデスマーチ: プログラマの思索

レガシーマイグレーションという名のシステム移行はデスマーチになりやすい: プログラマの思索

移行作業は、リリース後の運用を保証するためにとても重要な作業である。
普通は、事前に入念な計画作りをするのが普通なので、どうしてもWF型開発になりやすくアジャイルにやりにくい。

【3】開発手法はWF型開発が主流

現代のソフトウェア開発は、アジャイル開発の方が最先端で、次々に新しい発想や技術が生まれている。
アジャイル開発は、技術者として勉強して追いかけるのはとても楽しい。

でも、僕の短い経験では、Webサービスや新製品開発にはアジャイル開発はとてもフィットするが、業務システム開発はアジャイル開発に向きにくいように思う。
その理由はいくつかある。

一つは、上記に書いたように、アーキテクチャが複雑なので、どうしても事前に入念な計画作りに力を入れざるを得ず、純粋なアジャイル開発がやりにくい。
外部接続やデータ移行、システム移行などのアーキテクチャ検証プロセスを並行開発するやり方もあるが、アジャイル開発で一番基本的な手法である小規模リリースを実現しにくい。
複雑なアーキテクチャが安定しなければ、そもそも小規模リリースしても品質が安定しないのだ。

もう一つは、設計重視のモデル駆動開発になりがちなこと。
業務システムを机上の設計で、現状の業務とあるべき姿の業務のギャップを見出し、ToBeの業務プロセスをモデル化していく。
そのモデルに従って、プログラミングしていく発想なので、設計書重視の開発スタイルになりやすい。
プログラミングできるよりも、業務を知っていて、その業務をいかにモデル化できるかという能力の方が評価されやすいのだ。

また、業務モデルは会社や業界が違うと、モデルも変わってくるので、DBや設定ファイルなどで動的にパラメータを変えれるようなアーキテクチャにして、できるだけ幅広い業務をカバーできるように設計するのが普通だ。
その理由は、ノンプログラミングでカスタマイズできるようにしたいから。

普通は、ERPをそのまま導入したらおしまいというわけではない。
必ず、機能のカスタマイズは発生する。
ユーザ企業特有の業務は必ずあり、運用で逃げれない業務は必ずある。
そんな業務をIT化するために、ERPのカスタマイズが必要になる。
しかし、ERPのカスタマイズは曲者だ。
馬鹿でかい費用が意外にかかるし、せっかく品質が安定しているソースに手を加えるのだから、機能のインターフェイスやデータに不整合が発生したり、他機能のデグレードが発生したりする危険がある。

だから、モデル駆動で設計すると、どうしてもパラメータが多くなったり、カスタマイズすることで煩雑になりやすく、プログラミングよりもテストする方が工数がかかるようになりがち。

更に、発注者であるユーザ企業は、自力で業務システムを開発する力がないのがほとんどなので、大手SIに受託開発を依頼する場合が多い。
したがって、アジャイル開発が理想とする顧客も巻き込んだ開発スタイルは、たくさんの利害関係者に分散された構造の中では実現しづらいのだ。

スクラムの新しさ: プログラマの思索

【4】「業務知識が必要」「アーキテクチャが複雑」「WF型開発が主流」という悪条件の業務システム開発を何とか改善できないものか？

最近考えているのは、オープンソースのERPを導入することでそれらの問題を別の問題にすり替えて解決できないか、と思っている。
「業務知識が必要」「アーキテクチャが複雑」という問題は、技術者自身のスキルアップで解決できる。
その環境の一つとして、オープンソースのERPを自発的に使って、色々試してみるという手法があると思う。
オープンソースのERPは、受託開発の業務システムよりもシンプルかもしれないが、ERPのエッセンスを勉強することはできるし、よりよいアーキテクチャを実験する環境を提供してくれる。

また、「WF型開発が主流」という問題は、昨今の技術革新によって大幅に緩和されてきつつあると思う。
アジャイルに開発したいのに、今もなおWF型開発にしがみつかないといけない原因は、事前のアーキテクチャ検証や利害関係者との調整に手間がかかっているからだ。

今はサーバー環境というインフラ構築すらアジャイルに開発できるし、外部接続やデータクレンジングなどのデータ移行も、オープンソースのツールやプロトコルをうまく使えば、以前よりも楽に実施できる。

また、ユーザ企業やSIも含めた複雑な体制は、信頼にもとづいた体制づくりでカバーできるだろうと思っている。

【5】今注目しているオープンソースERPは、iDempiere、SugarCRM、OpenERP。

iDempiere(アイデンピエレ) Lab - Topページ - Compiere Distribution Lab

SugarCRM Cloud Hosting, Installers and Virtual Machines.

OpenERP Cloud Hosting, Installers and Virtual Machines.

SugarCRMは以前から、CRMとして着目している。
iDempiereはかなり高機能なERPなので、試してみたいと思っている。

色々考えてみる。