DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

今回のブログでは、“システム化のスコーピング”について取り上げてみたい。4年目を迎えようとしている本シリーズであるが、システムにとって最も重要な前提条件となるSYSTEM SCOPE（システム範囲）について、本題として取り上げていなかったのが不思議なくらいである。当ブログでは、従来の企業システムがこの制約事項のもとに、いかに近年のビジネスモデルの変化に追従できなくなっているか、そして、どうすればこの制約事項の影響をまともに受けてノックアウトされないかについてお話したい。

最近の企業システム再構築案件において、単純なプラットフォームの老朽化やオープン化対応を除く、“あるべきビジネスモデル”に対応する案件の大半は、このSCOPE拡大に相当するものがかなりの割合を占めると思われる（これ以外には、同一SCOPE内での機能拡充などがある）。幾つかの事例を挙げてみよう。まず、会計システムでの2000年3月期の連結決算の義務化。これにより１法人からグループ会社法人群へとSCOPEが拡大し、今やグループ経営は当たり前だ。また、法令起因ではなくM&Aや新規事業進出により、新たなビジネスモデルに対応すべくSCOPEを拡大しなければならなくなったケースも少なくない。さらに、取引のグローバル化やインターネットの普及にともない、必ずしも資本関係のない企業間でデータ交換が活発に行われるようになり、ここでもSCOPE拡大を迫られている。

これらのSCOPE拡大は、初代の企業システム開発時（レガシー企業では1980年代）には到底予想できなかったビジネスの進化が現実となったので致し方ない事である。しかし、ビッグバン再構築にまで至らないようにするシステム設計は可能であった。ここで最も起こりやすい誤解は、「デザインSCOPEとプロジェクトSCOPEの混同」である。もっとも大規模システム構築プロジェクトにおいて、スコーピングの誤りは死活問題である。リスク管理を重視して、ユーザ要件を満たす最小限のSCOPEを描き、段階的構築をしてROIを得て行く事は間違いではない。問題は、このプロジェクトSCOPEの外側にはあたかも世界がないかの如きデザインSCOPEではマズいという事ある。

プロダクトのSCOPEを決めるという事は、システムのコンテキスト（暗黙の文脈）を限定することとなり、SCOPE外のものが出現した際には、識別子が足りない事になる。ここで、ソフトウエアの汎化概念を適用し、（少なくとも１つ）外側のSCOPEを表現することに留意してみる。例えば、当面１法人しか扱わないシステムであっても他の（グループ会社）法人も扱う”可能性”があれば、少なくともデータモデルに“扱い会社コード”なる識別子が必要となる。気の利いたERPパッケージ製品では、マルチカンパニー、マルチランゲージ、マルチカレンシーの３つのマルチ要素は標準のモデルで考慮されている。マルチカンパニー対応では、“扱い会社コード”なるメタ（データ属性）を各エンティティの主KEY要素として予め用意しておくだけで良い。最初のプロジェクトSCOPEが単一会社であれば1社分しかデータが格納されないので、会社による違いは実装には至らないがそれでよいのだ。別の例として、CRMにおける顧客の定義が現状は販売実績が発生した顧客をその範囲としているが、将来のマーケティング戦略を考慮して”見込み顧客”についても予めデータモデル上に設計しておく等が挙げられる。こちらもモデル上で考慮はするが見込顧客に関するプロセスの実装は次期プロジェクトで構わない。さて、上記のデザインSCOPEをプロジェクトSCOPEと同様に扱う誤解は多分にウオータフオール型開発手法（略：WF）を適用した場合起こりやすい。なぜなら、WFにおいては初期の段階でプロジェクトSCOPEを確定することで、中盤以降のフェーズにおけるシステム化範囲のブレを極小化させる事を狙いとするからである。そこでは、システムの柔軟性を担保する“設計の汎化”によるSCOPE拡大が考慮されていなくてもさしたる問題にはならない。特化型設計の課題が露呈するのは、ビジネスモデルに変化が生じた数年先である。そこで、「汎用的ERPパッケージを適用していれば問題ないのでは？」と思われる読者もいるのではないかと思われるが、汎用的デザインは少なくとも柔軟性に寄与するものの、事業別に個別のアドオン、カスタマイズを施しながら別々に導入された企業グループでは、残念ながらそのメリットを活かしきれる結果とはなっていない。

一方でアジャイル型開発では、請負契約に縛られたWFのように、厳格なSCOPEは存在しない。開発途中での少々のSCOPEの変化は準委任契約の期間内であれば少なくとも有である。当ブログで各開発方法論の評価をするつもりはないが、WFで“面白いシステム”が出来上がりにくい背景がここにある。言い換えれば、“デザインSCOPEの汎化による発展的発想の芽を摘む”ことになりかねない。シリーズバックナンバー「2013.12.3 Think big, Start small」のようにはなりにくいのだ。大量生産における生産性向上モデルとしてのWFは、プロダクトよりプロジェクト重視である。余談であるが、最近マスメディアで目に止まった「日本のリーダーはソフトウエアの本質を理解していない」にも相通じるものがあるように思える。ソフトウェア自体の持つ魅力を追求できないという意味において。

※今回はシステムのデザインSCOPEの重要性についてお話しする傍ら、WFの限界についても言及してみました。読者のみなさん、”エンタープライズ・システムだからこうでなければならない”と思い込んではいないでしょうか？当ブログから数回に渡って、「ＸＸＸＸの誤解」シリーズを連載しようと思います。ひとえに読者の皆さんが、ベンダー戦略に基づく表層的な用語に惑わされる事なく、地に足の着いたエンタープライズアーキテクチャの構築に邁進していただきたい一心により。