近年、この2つの一見相反する言葉はグローバル社会のいたるところで見聞きするようになった。非IT産業の世界では、日本は古来、欧米の文化、技術を積極的に取り入れつつも、日本的な文化を器用にミックスして残してきた。ではITの世界ではどうであろうか?
こちらも日本語変換をはじめ、日本ならではのユニークなソフトウエアが、グローバル標準の基盤上に構築された例は少なくない(残念ながらOSやハードウエア基盤は欧米発が標準となったが)。日本固有のビジネスモデルへ日本発のソフトウェアを適用することはグローバルでの競争優位をもたらす。とりわけ製造業における各種ノウハウは優れたものが多い。また、マネジメントスタイルにも日本独自の強みがある。日本式の“帳票“などは網羅性と緻密性を同時に兼ね備えた優れたものだ。
このようにITの多様性についてはグローバル標準(ITでは米国標準に近いが)と”日本という多様性”の共存がベンダーの努力のおかげで成立している。では対象範囲をぐっと狭めて、一企業の業務アプリケーションではどうであろうか。ERPのアドオン、カスタマイズで原型を留めなくなり膨大な開発保守コストを招いたり、ERPがフィットしない独自のビジネスモデル部分を手作業で行なって非効率を招いたり、どうも日本のオリジナリティーとの共存が上手くいっていないケースをよく見聞きする。
本来、多様とは“様式や傾向が様々に分かれること”を言っており、本質や原理が異なることではない。本質は同様でも様式が異なれば人間が受け取る価値が変わってくるという事だ。会計の汎用モデルに基づいたERPの原理、原則は万国共通であり日本のビジネスにもフィットする。しかし会計に辿り着くまでの業務プロセスや、そこから派生する情報管理においては、強みとしての日本の独自性があり、これをソフトウェアにどう落とし込むかが最大のポイントとなる。その為にはERPのアーキテクチャーモデル(特にデータアーキテクチャとアプリケーションアーキテクチャ)を知ることである。もしも開示されていなければ、パッケージの入出力から分析すれば良い。
パッケージ派かスクラッチ派かの論争に決着をつけるつもりはない。それこそ多様性を尊重すれば、どちらも共存していて良い。要は自社のビジネスモデルの強みを正しく理解すること。加えて、パッケージの標準モデルを知る事に尽きる。結果、厳選されたアドオンを施したり、パッケージのフィット率が悪い場合はスクラッチ開発にするなど、正しいアプローチでビジネスの強みをシステムに反映できるのだ。
「そんな当たり前のことを今さら!」と思われる読者の方も多いと思われるが、要件定義工程での“単純ユーザヒアリング”の果てに膨大なアドオン、カスタマイズを施してしまう例は枚挙にいとまがない。このような事になる元凶は何であろうか?自社ビジネスのコア/ノンコアが分かる”社員”がプロジェクトに参画していないからである。先日いみじくも、あるベテランCIOが「1980年代の開発はユーザ出身者が集まった情シス組織だったので要件定義の間違いは起こりえなかった」と言っていた。また、私の前職の会社では、30年前の開発方法論にあった“エンドユーザのプロジェクト参画がプロジェクト発足の必須要件“を今でも守っている。
多様性と標準化はITの世界ではどちらに偏ってもうまくゆかない。両者のバランスは、自社ビジネスのコアコンピタンスとは何か、標準プロダクトとはどのようなものか?の熟知によってはじめて成り立つ。そしてこの融合がシームレスになった時、多様性のもたらす新たな付加価値が生まれる。