個品のエンタープライズシステムの仕様を他の発注者と共通化して、コストを下げようという話は、現れては消えてしまうという循環を繰り返しているのではないだろうか。委託/受託開発であり、仕様の一部を共通化するというものだ。受注者（ベンダ）が類似のシステムを水平展開する話はよく聞くものの、発注者が仕様を共通化する話がなかなか表に出てこないのは、その難しさにあるのではないだろうか。
エンタープライズシステムと呼ばれる業務に使うシステムでは、業務部門の要望を情報システム部門がとりまとめて、全体の整合性をとりながら発注することがほとんどだ。業務部門が必ずしもシステムに詳しいとは限らないので、どこをシステム化してどこを人間系とするのかを定義したり、他のシステムとのやりとりを整理したり、他の業務で必要となる事前条件や事後条件等、整合性を取ったりするのも非常にたいへんな作業だ。
ただでさえ忙しいのに、そこを更に他社との業務の共通部分を検討し、共通仕様を作るよう調整しろ、というのはかなり難しい。無数の例外処理、出力形式があり、そもそも本当に共通化できるのかも明らかでないし、その効果も明確ではない。
共通部分がサブシステム等1つの構成要素に集約できれば、効果もありそうだが、共通仕様はあるものの点在しているために、要求仕様くらいしか共通化できないということであれば、効果も薄そうだ。
もし、そこそこの大きな粒度、かつ、他社とも共通化でき、Dependency Injectionで対処できるような部分が多く発見されるようであれば、専門の部隊を持つこともできるのではないだろうか。共通化できる部分はビジネス的には、非競争領域といえるところにあると思う。明らかな部分は、パッケージ、準パッケージ化が進んでいると思われるが、残されている部分が多くあるのではないかと思う。ベンダが横展開している部分はある程度共通化できるはずだ。業務の共通化、イレギュラーの抽象化による共通化（個々にみると異なるがテンプレート化できるようなイレギュラーの発見と共通化）等、を実施していく。
たとえば、鉄道会社では他社と車両を共通化して、車両提供会社にコスト圧縮をお願いする事例もあるそうだ。ご自身のシステムを他社のシステムと共通化できるとするならば、どこだろうか。
Special
- PR -
富士通元社長の山本卓眞氏が残した次代へのメッセージ
Facebook就活はもう古い？
東北をコットンの生産地としてブランディングしたい──リー・ジャパン・細川取締役
東北から始まるイノベーション
貧困国の雇用を創出する印刷屋、丸吉日新堂印刷の挑戦