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

今回はオブジェクト指向やサービス指向が謳われる中で、レイヤーは異なるが”業務アプリ指向”という造語をテーマに掲げたい。 先日、某ERPベンダーのフォーラムを聴講する機会があり、戦略の巧みさを痛感したと同時に、アプリって誰のものだったっけ？という疑問を感じざるを得なかった。数ある事例発表もツールやプラットフォーラムの賛美が殆どを占めていたからだ。

その中で唯一、関西の企業で日常業務にBIを活用している生々しい事例発表に遭遇。間違いなくこの企業の情シスメンバーは、どのデータをどう料理したらユーザに喜んでもらえるかを知っている。単純な話だが、今ユーザ企業で自社アプリの複数領域に渡ってこれを言える社員が何人いるだろうか。開発プロジェクトでユーザヒアリングして初めて分かるのではなく常識としてである。 企業システムが巨大化、複雑化しアウトソースが進んだ今日、システムは複数の箱物の複合体としか捉えられなくなっているのではなかろうか。慣れとは怖いもので、自分の役割りと思わなければ中身のブラックBOXが気持ち悪いと思わなくなる。あたかもICチップの中身を語らなくて良いように。

しかし、サブシステムの中身を知っていることは紛れもなく企業内情シス社員の役割だ。そして中身とは、インプットデータ⇒データ処理プロセス⇒アウトプットデータについて明らかにすることだ。

データに言及せず処理の名称だけを語ると例えば「企業間VANまたはWEB入力にて受注処理を行い、同時に在庫の引当を行う。出荷日の到来とともに製品出荷処理がなされ、ここでの債権は月次の請求処理に回される。請求に対しての入金は、、、」という具合になる。これでは業種の特徴も、自社の強みも見えてこない。出来の良いパッケージほど汎化プロセスの適用範囲が広く生産性はアップするが、そこに流れる個別特化データが分かりにくくなる。

皮肉にも汎用アプリケーシヨン層が広くなり個別業務アプリの姿が不鮮明になったのだ。 業務アプリ指向とは、自社の業務になぞらえてシステムを説明できることであり、製品としての汎用システムの効能を説明するベンダーの役割とは真逆である。その為には以下のような成果物が必須となる。一つは図１の如くデータモデルまたはクラス図にて汎化⇔特化関係をきちんと表したモデルとすること。これにより汎化されたパッケージシステムと特化した個別業務の関係を明確化することができる。もう一つは上述したデータ処理プロセスを自社の業務用語で記述する事だ。

図２は私が世の中にパッケージが登場する以前に用いていたデータハンドリング仕様である。この記述はTHモデルで有名な椿正明氏の発明による。ちなみにスキーマの操作のJはJoin（結合）、ＥはExtract（抽出）、ＳはSummry（要約）の意味。さらに自社の業務用語やスキーマの説明を後のシステム部員に残すべくREPOSITORY（2014.5.7バックナンバー参照）に格納する所までやれば合格である。

いずれにしてもブラックBOX化により生産性を向上させた企業システムを、自社の業務側から説明することを怠らないことが肝心である。

※図表はクリックし拡大表示してご覧ください。

※関連記事

• ＲＥＰＯＳＩＴＯＲＹ