組織のコミュニケーションをうながす適切なモデル

　明治座の業務管理室 室長で、DAMA日本支部の広報担当理事を

務める赤氏。もともとベンダーでプログラマーやSEとして活動し、

その後、ユーザー企業側に移り、情報システム部門や業務改革を担

当。現場の視点にこだわりつつ、上流工程におけるコミュニケー

ションのあり方を追求している。Xupperユーザーとして、これま

でも講演を行ってきたことでもお馴染みだ。

　そんな赤氏が今回掲げたテーマは「騙し絵」を描かないための方

法。具体的には「シンプルで強靭なモデル」をどう作り、活用する

かということだ。赤氏はまず、池波正太郎の小説「真田太平記」や

「旅路」などを引き合いにこう切り出した。

　「『この世のなかは、それぞれの勘違いによって成り立っている』

し、『さまざまな数えきれない色合いによって成り立っている』。開

発やビジネスの現場もそう。勘違いが当たり前のようにある騙し

絵のようなものだ。無意識に騙し絵が描かれていることに気づか

ないまま、後工程に進み、騙し絵のからくりに気づいたときには、

すでに遅いという事態に陥りがちだ」

　そこで大事になってくるのがコミュニケーションだという。そ

して、コミュニケーションを円滑に行うために必要になるのが、シ

ンプルで強靭な業務モデルだ。「業務モデルは理屈よりもわかりや

すさを優先するのがポイントだ。また、データを中心に考えていく

ことが求められる」と赤氏。

リポジトリでデータソースを一元管理するメリット

　赤氏によると、エンタープライズ

アーキテクチャ（EA）やXupper IIな

どのツールも「データ」を重視して

いるのだという。これには理由があ

る。データをきちんと定義しておく

ことで、後工程の品質が確保される

からだ。データ定義を怠ると、たと

えば、ヤードとポンドを取り違えた

結果、航行ミスが起こり、火星探査

機を人為的に爆破せざるをえなく

なったNASAのような事態に陥るこ

とすらある。

　「自然に正しいデータが溜まる仕

組みを構築することが大切だ。その

際のポイントは上流工程からデータ

上流工程で要件を定義する際に、無意識に誤った方向性のモデルを描いてしまうことがある。赤氏はそれを「騙し絵を描く」と表現する。全体を見てようやく騙し絵のからくりに気づくように、後工程に進んではじめて上流で間違いを犯していたことに気づくからだ。赤氏による「無意識に騙し絵を描かない為に～シンプルで強靭な業務モデルを構築する方法～」と題する講演の内容を紹介する。

無意識に騙し絵を描かない為に～ シンプルで強靱な業務モデルを構築する方法 ～

株式会社明治座 業務管理室　室長、DAMA日本支部　広報担当理事　赤 俊也氏事例2

★データモデル ★CRUDマトリクス

★プロセスモデル

リポジトリ

図1：リポジトリにデータソースを集約して一元管理

［第18回Xupperユーザ事例紹介セミナーレポート］

マネジメントの概念をすり込んでおくと

いうこと。そこで、重要になってくるのが

リポジトリだ」（赤氏）

　リポジトリには、作成したデータモデ

ル、プロセスモデル、CRUDマトリックス

などの情報が一元的に集約される（図1）。

リポジトリがあることで、データベースの

フィールドがどのエンティティ、画面で使

われているかを即時に把握できる。これに

より、影響度分析などが容易にできるよう

になる。さらに、成果物を自動的に生成す

るといったことも可能だ。

　赤氏は、「プロジェクトの隠れたコストに

は、コミュニケーションのコストと成果物

作成のコストがある。コミュニケーション

コストはモデルの構築で削減できる。成果物作成のコストをリポジ

トリ搭載のツールを使うことで削減することができる」と解説した。

「氷山の理論」で見る要求と要件

　さらに赤氏は、要求と要件の違いが「騙し絵」を描くことにつな

がりやすいと指摘。要求と要件の違いを「氷山の理論」を使って説

明した。氷山の理論とは「目に見える部分は8分の1程度で、残り

の8分の7は水面下に沈んでいる。氷山の動きの威厳は目に見えな

い8分の7によって保たれている」というヘミングウェイによる考え。

　これについて、「要件として実現されている8分の1で、残りの8

分の7の要求を満たさなければ、氷山の動きの威厳を保つことがで

きない」と考える。つまり、「要求は、ユーザーが情報システムで

実現したいこと。要件は要求をふまえて、情報システムに盛り込む

べきもの。この違いをつかみ、本当に必要なものを要件として定義

していくことが求められる」（同氏）わけだ。

　ここで、要求仕様を引き出すことと、要件定義自体を行うことを

混同してしまうと、ビジネス上のゴールが不明確になる。「不明確

なまま実装フェーズに入ると、いきなりデスマーチが発生する」こ

とになってしまうのだ。

　また、そもそも、ユーザーは要求と要件の違い以前に、ビジネス

要求とシステム要求がきちんと判別できていないケースが多い。

ユーザーが言ったことを真に受けてしまうと、さらなる混乱を招

くことになるわけだ。

　「要求と要件の整理は、最初が肝心だ。源流に極めて近いところ

で始めないと下流への流れをうまく作ることができない。一滴の

水滴が川のうねりを経て、最後には大海に流れ込んでいくイメー

ジだ」（赤氏）

トップダウンで骨組、ボトムアップで肉付け

　では、上流における業務モデリングで大切なことは何か。まず、

赤氏が重視している基本原則は「トップダウンで骨組、ボトムアッ

プで肉付け」だ。「現場の知恵は有効だが、ボトムアップが強すぎ

ると「部分最適」に引っ張られる。間違っても、ボトムアップで

トップダウンを潰すようことはあってはならない」とした。

　モデリングでは、データモデル、ブロセスモデル、CRUDマトリ

クスという3つのモデルについてポイントを説明。データモデルの

留意点は、業務部門に見せても理解できないことを踏まえ、画面イ

メージとエンティティを切り出して、フィールド一覧として提示

するといった見せ方の工夫が必要だとした。

　また、プロセスモデルについては、現場で要求をひろい、現場が

理解できるわかりやすい業務フローを描くことが重要だという。

現場の人間を巻き込むには、現場視点に立ったストーリー性の高

い話で惹きつけるのがポイントだ。また、モデルを作る際には、

5W2H（When、Where、Who、What、Why、How、How many）

をきちんと定義することが重要になる（図2）。

　最後に、赤氏は、「高品質のプロセスにより生成されたデータは、

企業組織の資産になる。天高く舞う鳥の視点を持ちつつ、地べたを

這って泥臭く仕様を固めていってほしい」とアドバイスした。

《業務フロー図》

《プロセス詳細》

When ：実施タイミングWhere ：場所(組織）Who ：担当者What ：対象データWhy ：目的、狙いHow ：実施要領How many ：データ量、時間

★各プロセスに対して5W2Hをきちんと定義する

図2：プロセス作成では、5W2Hを明確に定義することがポイント