ユーザーの思いを汲み取り、論理モデルに落とし込む
システム開発の作業を困難なものにする大きな要因として挙げられるのが、開発側とユーザーの間のコミュニケーションギャップだ。それはシステムの仕様を決める段階から発生しており、「要求仕様」を引き出すことと「要件定義」自体を行うことを混同しているケースも多いと赤氏は指摘する。
「要求」とはユーザーが情報システムで実現したいことであり、「要件」とは要求を踏まえて情報システムに落とし込むべきもの。開発側としてはどうしても要件定義を急ぎがちだが、まだ要求が明確でない段階で要件定義を進めようとしても歪みが生じ、1つ1つの機能が無駄に膨らんでしまう。 要求と要件を整理するためには、最初の上流工程が重要となる。システム開発を川の流れに例えれば、ユーザーが本当にやりたいこと、つまり「要求」が源流であり、そこから流れ出す思いを汲み取って整理し、下流への流れを作るのが上流工程の役割といえる。
また、赤氏は上流工程について「システムのプロと業務のプロとの間で相互翻訳作業を行う工程」とも表現し、単にシステム屋（開発側）が業務屋（ユーザー）の言葉を翻訳するのではなく、相互に理解し合うことが大事だと強調。その際、「おもてなしの心がとても重要になる、お互いを思いやる気持ちがなければ相互理解は難しい」と述べた。
さらに、上流工程を「論理モデルを作成する工程」と捉え、上流工程のアウトプット（成果物）は「何を作るか」を明確にした論理モデルであり、それは「下流工程のインプットとして役立たなくては意味がない」とした。
リポジトリによる一元管理で3つのモデルの精度を高める
続いて赤氏は、上流工程における「翻訳の元ネタ」として使うモデルについて説明。まず、ビジネスの静的側面をデータモデル、動的側面をプロセスモデルで表す。そして、静的側面と動的側面の交点を、CRUDマトリクスで表現する。下流工程ではいろいろなモデルを使う必要が出てくるが、上流工程においては、この3つのモデルの精度を極限まで高めることを赤氏は重視している。それは、最小の管理（成果物）で最高の成果を得るためだ。また、データモデルもプロセスモデルも、「トップダウンで骨組」を作り、「ボトムアップで肉付け」することを原則とすべきだという。
データモデル、プロセスモデル、CRUDマトリクスを、例えばExcelやVISIOなどでそれぞれ作り、手作業でブリッジするという方法で管理することもできないわけではないが、規模が大きくなればなるほど、手作業の管理では無理が生じる。Xupper IIを活用すれば、これらをリポジトリにて一元管理し、わかりやすい形にまとめることが可能だ。赤氏はその点を、「これだけきちんと一元管理できるツールは、なかなか存在しない。まさにケン・システムコンサルティングの企業コンセプトでもある『究極の生産性と品質向上の追及』を実現してくれるツール」として、高く評価している（図1）。
データモデル作成のポイント
ビジネスの静的側面を表すデータモデルは、トップダウン中心でリソースモデルを、ボトムアップ中心でイベントモデルを作る。
リソースモデルについては、ビジネスルールから作るのが基本だが、データモデルパターンの活用も有効だという。例えば、ビジネスルールなどがうまくまとまらない場合に、トップダウンモデリングの一環（代わり）として使用することができる。また、データモデルパターンと自社のモデルとの差異に着目し、それが明らかな「強み」なのか、あるいは、慣習など理由不明なもので「改善すべきポイント」なのかを判断するといった使い方も可能だ。
業務の流れの中で発生するイベントモデルについては、業務フロー（ビジネスフロー）や業務の流れを表す画面イメージから抽出し、項目として落とし込んでいく。
データモデル作成の留意点として、赤氏は、各エンティティの存在価値が明確になっていること、所属するフィールドの1つ1つに対しての「5W2H」が明確であることなどを挙げた。フィールドの“価値”がきちんと認識されていれば、格納されたデータの価値は増大する。ちなみに「5W2H」とは、通常の「5W1H」に「HowMany（量）」を加えたものだ。
データモデルを現場のユーザーに理解してもらうためには、「目に見えるもの」を提示することも必要だ。データモデルを現場のユーザーに見せても、おそらく理解できない。そこで、マスタ登録画面イメージや、フィールド一覧としてのエンティティなどを切り出し、提示して1 つ1つ確認していくといった地道な作業が求められるのだ。
現場のユーザーを業務フローの世界に巻き込む
ビジネスの動的な側面を表すプロセスモデルには、Xupper IIの業務フロー（ビジネスフロー）を使用する。業務フローを使う最大のメリットは、シンプルに「わかりやすさ」だという。
プロセスモデル作成において赤氏が最重視しているのは、現場の強みを最大限に生かすことだ。それには、現場のユーザーの視点に立って業務を表現すること、そして、その表現を共有することが求められる。
そこで重要となるのが、ストーリー性だ。設計者は「ストーリーテラー」としてプロセスモデルを作成し、「物語」（ストーリー）を「主人公」であるユーザーと共有する。そうすることによって、ユーザーを業務プロセスの世界に巻き込んでいく（図2）。
利用部門の担当者に業務フローを遂行する「主人公」の視点に立ってもらうためには、図（BFD）の内容に引き込む工夫が必要となる。赤氏は、そのコツを2つ紹介した。
1つは、これから共有すべき業務の前提を伝えること。言い換えれば、物語の状況、背景をきちんと理解してもらうことだ。詳細な状況設定をすることで、新業務フローのイメージを具体的に持ってもらえるので、仕様の漏れなども見つかりやすくなる。
もう1つは、業務フローの内容を説明する際に、業務の流れを表す線を赤ペンなどでたどりながら話すこと。ユーザーが業務の流れを具体的にイメージできるように、順を追って説明し、一緒に物語（ストーリー）を共有して作り上げていく。
赤氏は他に留意点として、各プロセスに対して役割を明確に定義しておくこと、データモデル×プロセスモデルの最小粒度をきちんと管理しておくことなどを挙げるとともに、まとめとして「天高く舞う鳥の視点を持ちつつ、地べたを這って泥臭く仕様を固めることを両立しなければならない」とし、セッションを結んだ。
ケン・システムコンサルティング株式会社 http://www.kensc.co.jp/
