TAKESAKO @ Yet another Cybozu Labs

■ERP5

Pythonで書かれたオープンソースERP

■ERPの概念

ERP = Enterprise Resource Planning
短いプロジェクトで3ヶ月、長いもので1年から3年

典型的な会社
　開発部
　人事部
　経理部
　販売部
　マーケティング部
→各部署でたらい回し、情報共有がされていない

ERPフレームワーク
　人事管理(HR)
　会計管理(Accounting)
　生産管理(PDM)
　顧客管理(CRM)
Webパブリッシング(CMS)
　紙：カタログ、パンフレットも
オンライン取引(eCommerce, eProcurement)

→データの重複は悪、同期の手間がかかるし、システムも複雑になる

■ERPの最近の潮流

オープンソース
　カスタマイズ性能
　ベンダーロックインからの解放
　コスト削減効果

ベストプラクティスの提唱←→実際の業務はそれぞれのやり方がある

Webベース
　ユビキタス
　ファイアウォール
　インターネット

日本では気付きにくいが、世界には回線事情がとても悪い会社もある
衛星回線、パケット遅延0.5秒、入力タブの移動で2秒かかる製品も？

■ERP5とは

ERP5はシミュレーションベースのERP
　会計ベースはシステムのずれに弱い
　出荷、一日遅れで届く、検品すると数が違う

ERP5は…
　事実だけを1次データベースに保存する
　2次データベースはMySQLを併用して高速化

導入実績：
　服飾産業、航空宇宙産業、中央銀行、病院、政府機関、地方自治体など

通貨の発行管理、窓口業務の管理、紙幣の追跡、入院・医療行為の管理など
といったニッチな複雑な業務もERP5のフレームワーク上で構築

アパレル業界(ERP5の最初の顧客)では
　大きさ、色、デザイン、バストサイズなど...多次元データの商品を扱う

雑誌での評価

Decision Informatique（フランスの経営者向けIT雑誌）
　ERP5が最優秀賞を受賞
Computerwoche（ドイツで最も有名なIT雑誌）
　ERP5を特集、infoterra 偵察衛星写真の販売業務でERP5を採用(SAPと比較)
　ユニログノジカCMS、ヨーロッパで第3位のコンサルティング会社

■なぜOSSがビジネスになるか？

Nexedi（研究開発）
　　パートナー（インテグレーション）
　　　　　顧客（利用、メンテナンス）

プロジェクトの複雑度
　＝ワークフロー＋文書＋カテゴリ＋インタフェース

プロジェクトの期間
　＝意思決定が行なわれてから現場で利用できる
　　水準に達するまでの経過時間

お金はある？時間はある？
　　　　↓
　1. Do it yourself　（お金はないけど時間がある）
　2. トレーニング　　（→OSSビジネス）
　3. コンサルティング（→OSSビジネス）
　4. No Way　　　　　（お金も時間も全然ない）

■ERPの技術的特異性

ミッションクリティカル
　止まるとヤバイ
データの種類が多い
　50～300が普通
データ量が多い
　1000取引／日でも一年で30万取引
　国民全員だと数十億のオブジェクト数
　ちなみにヒトゲノムは4GB
書き込みが頻繁
　キャッシュ効率やスケーラビリティの問題

■技術面から見たERP5

99% Python（残り1%は主にC）
　オブジェクト指向（後付、2.2ぐらいからマシに）
　メタプログラミング（データ種が多い、クラスの動的自動生成）
　　Lisp?(括弧が多い) Ruby?(大規模開発には向いていない)
Zopeベース
　オブジェクト・データベース(ZODB)
　Through The Web(TTW)、ユーザにとってウケがいい
　Productによる拡張

キャパシティの計算などがCで書かれている
javaで書かれているのもあるけどgcjでコンパイル

■ZSQLCatalog
　Zope Product
　　Zopeの機能を拡張
　ZCatalog互換
　　Zopeの標準機能からの以降が容易
　　オブジェクトのインデックス化
　リレーショナル・データベースを利用
　　MySQL（単純に非常に速いから）

■O/R Mappingの問題点

Document
　ID:1023
　Title:Hoge
　Content:Fuga
変更に弱い(Author:Okujiを追加)
ALTER TABLE はテーブルロックがかかる
テーブル数が多い場合、レコード数が10億とか、業務が止まる

列が多過ぎ
　性能低下、システムの制限
ロックの粒度が粗過ぎ
　数学的厳密性ゆえの宿命
表が多過ぎ
　ロジックの分散、システムの制限

InnoDBはインデックスをロック、対象データの前後のレコードもロックする場合も

■オブジェクト・データベース

ID:1023
Serialized Data:0x821203FD678

欠点：検索がそのままではできない
　→ZSQLCatalogによる解決

データベースを1次のZODBと2次のMySQLに分ける

Zope←オブジェクトデータ→ZODB
ZODB←遅延評価→MySQL
MySQL←検索→Zope

■ZSQLCatalogの利点

変更に強い
検索が速い
必要最小限の列で十分
少数の表で十分
低速なインデックス作成を後回しにできる
複数のデータベースを持つことによって
使いながらインデックスを作り直すことができる
（Hot re-index）

■興味のある方は…

詳細は http://ERP5.org で。ソースコード、RPM、Live CD をダウンロードできます。