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

今回のブログでは、よく言われる“システムの見える化“についてお話したい。以前からお伝えしている通り、姿、形のない企業システムを可視化することは困難を極める。この手段としてはEA（Enterprise Architecture）の取り組みがマッチし、BA、DA、AA、TAの各層別の成果物を作成することがベストプラクティスである。しかし、これら全てを完成するには相当な時間を要する。はたして、全ての成果物を完成させないことにはシステムの概略すら知り得ないのだろうか？答えは否である。まずはシステムの全容を、深みはなくとも”掴み”で見る気にさせることが重要である。

最も直観的に全容を見せるには、図１に示した”システム関連図“（（別名：アプリ鳥瞰図）が最適なモデル図であると思われる。このモデルはAA（Application Architecture）の成果物ではあるもののDAの要素も、TAの要素も兼ね備えている。本ブログでは、バックナンバー2014.7.1「AAへの入り口」でもご紹介したこの図について、見せる目的に対しての正しい描き方と、誤った描き方についてご紹介したい。

まず基本的な表記法であるが、図１右下の凡例の通り、プロセスに関してはシステムとそこに内包する数個のサブシステムのみを描くものとする。システムやサブシステムの粒度は、例示のような“全社“をスコープとした場合は、生産管理、受発注、販売管理、会計、営業、人事といったLOB*のレベルが妥当であり20個以内に留めたい。下位にあるサブシステムはLOBをさらに機能別に分解したもので、せいぜい10個以内としたい。ちなみに、極度な大規模複雑系の場合、スコープを”全社”ではなく“1システム“とせざるを得ない場合は、サブシステムをシステムのレベルに置き換えて描くことになる。

次にデータに関しては、凡例にもある通りプロセスを中心に→（矢線）でインプットデータとアウトプットデータを明示すること、すなわち“I-P-O”を描くことが基本となる。さて、ここで最初のアンチパターン①が登場する。プロセス間を繋ぐ矢線がデータでも業務処理順でもなく「何となく何かが関連するだろう」という曖昧な結線である。これでは凡例による説明のしようがない。即ちモデル図として共通の理解を得ることが難しいという事になる。残念ながらユーザ企業で目にするものの大半がこれである。

“プロセス間の連携“はデータ以外で繋がりようがない。問題はシステムがスパゲッティ状態になっている場合に、現行のプロセス間I/Fデータを洗い出すと数10～数100のデータ種別が洗い出され、どう描いてよいか分からないという状況に陥ることである。ここでさらなるアンチパターン②が登場。「システム間I/F一覧表」なる膨大な物理I/Fが淡々と綴られた100ページ近いEXCEL表がそれである。克明に洗い出されたI/Fは、主要なデータも些末なデータも同じレベルで扱われた抑揚のない一覧表と化す。これではシステム構築時のチェックリストにはなれども”見える化“の資料にはなり得ない。図２にアンチパターンの例を示したのでご覧いただきたい。

ではどうすれば良いのだろうか。。。答えは業務知識に立脚し、（人体に例えれば）主な動脈のみに着目し毛細血管は無視するように、主要なデータの流通経路のみを選別する事である。例えば、「生産管理システムから受注システムへは製品の出来高データが渡され（販売用）在庫に加算される。製造原価は工場内の原材料、仕掛品の受払データと会計から渡る各種経費データをもとに算出される。SFAシステムの営業モバイルPCには受発注システムから渡った売上データが表示される。受発注システムで発生した売上データは債権管理システムに渡り請求書に反映され、同時に売掛金残高に計上される。」等々、一般的業務知識をベースに幹となるデータフローが描かれていることである。加えて、主要なデータストック（DB）についても描かれていればさらに良い。

ところで、企業内情報システム部門がアウトソーサに頼らざるを得なくなった今、果たしてシステムプロセスの知識を持ちつつ業務ロジックについても語れる人材が身近にいるだろうか。もしもレジェンドと言われるシステム部員がまだ残っていればラッキーである。その人の業務知識を最大限に引き出すことを考えれば良い。しかし、分業が進んだ今日、EAの層別にプレイヤーが異なり、それぞれ特化した知識しか持ち得ないとすれば、残るはエンドユーザに聞くしかない。中身がブラックBOX化したシステムを、かたよりなく説明できる人間はもはや運用担当者ということになる。

では、これを描ける人間を育成するとなればどうだろうか。私自身の経験からOJTではLOBグランドスラムの達成には20年近くかかり、現代のスピード社会ではそれはあまりにも遅すぎる。例えば、ビジネス・ゲームやMBAの経営学テキストを通じて、アカウンティング、SCM、HR、マーケティング等のセオリーを座学することも近道ではないだろうか。今ではこれらの機会はふんだんに得られるのだから。

最後に、システム、サブシステムの全体配置であるが、実行系システムでは、サプライチェーンの流れに沿って左から右へ流れるように、原材料購買⇒生産管理⇒受発注⇒販売・債権債務管理⇒原価計算⇒会計の順で描くと良い（商社の場合は、生産がないので左端が受発注となる）。さらに計画系システムでは、販売（実績）管理を起点に左側のサプライチェーンの上流（生産、購買）に向けて生産計画、購買計画といったフィードバック情報が←の向きで描かれることになる。このように時系列も意識することで読みやすいモデルとなる。

以前のブログにも書いたが、“正確性とわかり易さは必ずしも一致しない”。モデル図は読んでもらってなんぼのもんである。願わくはITエンジニアの陥り易いアンチパターンに陥らないようにしたいものだ。見える化には”鳥の眼（バーズ・アイ）”が必要である。まずは上空から森を見ることで全容を掴み、その後に木を見て詳細を理解して行けば良いのだ。

※LOB･･･Line of Businessの略。 企業が業務処理に必要とする主要な機能の事。