現場を極めたITアーキテクトが語る!「成功へ導く極意」TweetPocket今回のブログでは、よく言われる“システムの見える化“についてお話したい。以前からお伝えしている通り、姿、形のない企業システムを可視化することは困難を極める。Architecture)の取り組みがマッチし、BA、DA、AA、TAの各層別の成果物を作成することがベストプラクティスである。これら全てを完成するには相当な時間を要する。全ての成果物を完成させないことにはシステムの概略すら知り得ないのだろうか?答えは否である。システムの全容を、深みはなくとも”掴み”で見る気にさせることが重要である。直観的に全容を見せるには、図1に示した”システム関連図“((別名:アプリ鳥瞰図)が最適なモデル図であると思われる。Architecture)の成果物ではあるもののDAの要素も、TAの要素も兼ね備えている。本ブログでは、バックナンバー2014.7.1「AAへの入り口」でもご紹介したこの図について、見せる目的に対しての正しい描き方と、誤った描き方についてご紹介したい。基本的な表記法であるが、図1右下の凡例の通り、プロセスに関してはシステムとそこに内包する数個のサブシステムのみを描くものとする。いったLOB*のレベルが妥当であり20個以内に留めたい。下位にあるサブシステムはLOBをさらに機能別に分解したもので、せいぜい10個以内としたい。ちなみに、極度な大規模複雑系の場合、スコープを”全社”ではなく“1システム“とせざるを得ない場合は、サブシステムをシステムのレベルに置き換えて描くことになる。次にデータに関しては、凡例にもある通りプロセスを中心に→(矢線)でインプットデータとアウトプットデータを明示すること、すなわち“I-P-O”を描くことが基本となる。ここで最初のアンチパターン1が登場する。プロセス間を繋ぐ矢線がデータでも業務処理順でもなく「何となく何かが関連するだろう」という曖昧な結線である。これでは凡例による説明のしようがない。モデル図として共通の理解を得ることが難しいという事になる。残念ながらユーザ企業で目にするものの大半がこれである。“プロセス間の連携“はデータ以外で繋がりようがない。問題はシステムがスパゲッティ状態になっている場合に、現行のプロセス間I/Fデータを洗い出すと数10~数100のデータ種別が洗い出され、どう描いてよいか分からないという状況に陥ることである。ここでさらなるアンチパターン2が登場。「システム間I/F一覧表」なる膨大な物理I/Fが淡々と綴られた100ページ近いEXCEL表がそれである。克明に洗い出されたI/Fは、主要なデータも些末なデータも同じレベルで扱われた抑揚のない一覧表と化す。これではシステム構築時のチェックリストにはなれども”見える化“の資料にはなり得ない。図2にアンチパターンの例を示したのでご覧いただきたい。すれば良いのだろうか。答えは業務知識に立脚し、(人体に例えれば)主な動脈のみに着目し毛細血管は無視するように、主要なデータの流通経路のみを選別する事である。「生産管理システムから受注システムへは製品の出来高データが渡され(販売用)在庫に加算される。製造原価は工場内の原材料、仕掛品の受払データと会計から渡る各種経費データをもとに算出される。SFAシステムの営業モバイルPCには受発注システムから渡った売上データが表示される。ベースに幹となるデータフローが描かれていることである。加えて、主要なデータストック(DB)についても描かれていればさらに良い。ところで、企業内情報システム部門がアウトソーサに頼らざるを得なくなった今、果たしてシステムプロセスの知識を持ちつつ業務ロジックについても語れる人材が身近にいるだろうか。レジェンドと言われるシステム部員がまだ残っていればラッキーである。その人の業務知識を最大限に引き出すことを考えれば良い。分業が進んだ今日、EAの層別にプレイヤーが異なり、それぞれ特化した知識しか持ち得ないとすれば、残るはエンドユーザに聞くしかない。中身がブラックBOX化したシステムを、かたよりなく説明できる人間はもはや運用担当者ということになる。これを描ける人間を育成するとなればどうだろうか。私自身の経験からOJTではLOBグランドスラムの達成には20年近くかかり、現代のスピード社会ではそれはあまりにも遅すぎる。ビジネス・ゲームやMBAの経営学テキストを通じて、アカウンティング、SCM、HR、マーケティング等のセオリーを座学することも近道ではないだろうか。今ではこれらの機会はふんだんに得られるのだから。順で描くと良い(商社の場合は、生産がないので左端が受発注となる)。いったフィードバック情報が←の向きで描かれることになる。このように時系列も意識することで読みやすいモデルとなる。以前のブログにも書いたが、“正確性とわかり易さは必ずしも一致しない”。モデル図は読んでもらってなんぼのもんである。願わくはITエンジニアの陥り易いアンチパターンに陥らないようにしたいものだ。見える化には”鳥の眼(バーズ・アイ)”が必要である。上空から森を見ることで全容を掴み、その後に木を見て詳細を理解して行けば良いのだ。Businessの略。企業が業務処理に必要とする主要な機能の事。嘉之1982年より協和発酵工業(現、協和発酵キリン)にて、社内システムの構築に携わる。メインフレーム~オープンへとITが変遷する中、DBモデラー兼PMを担い、2013年にエンタープライズ・データHubを中核とする疎結合アーキテクチャの完成に至る。2013年1月よりアイ・ティ・イノベーションにてコンサルタントを務める。社員の声アクセス採用情報ブログ株式会社アイ・ティ・イノベーションは、米国PMI®から公認教育プロバイダー(R.E.P)として認定されております。Inc.)の登録商標です。Provider)です。Knowledge®は、IIBA®の登録商標であり、IIBA®の許可を得た上で使用しています。アイ・ティ・イノベーションまたは各社の商標もしくは登録商標です。