事例で学ぶビジネスモデリング（6）
ビジネスモデリングの使いどころ
〜IT技術者のための戦略・業務分析入門〜

ウルシステムズ
シニアコンサルタント 村上歴
2006/1/27

前のページ｜1｜2｜3｜次のページ

---

◆2. プロジェクト作業内容

◇2-1. 事前準備

　 プロジェクトを開始して最初に実施したのは、関係各社（計8社）へのヒアリングである。通常のプロジェクトでは1社のお客さまの社内で、関連部署にヒアリングをすることが多いのだが、今回は取引先を含めた多くの社外関係者からの意見を聞く必要があった。このようなプロジェクトでは、それぞれの関係者の立場も異なるし、1社内のようにトップダウンで意見調整してもらうわけにもいかない。作業の目的や進め方については、各社にスムーズに協力いただくための調整作業が必要だった。

　各社別のヒアリングに際しても、何度もヒアリングする機会があるわけではないので、事前準備は的確に行っておく必要がある。何を聞き出さなければならないか、こちらがどこまで分かっていて何が分かっていないか、を説明するために、ヒアリング項目シートや各種の説明資料を準備した。こういった資料は成果物ではないが、今回のプロジェクトではこれらの資料についても社内で入念なレビューを実施し、聞き出したい項目に漏れがないか、ヒアリングの結果どういう成果物を作るかを、チーム内でかなり厳密に共有した（*2）。

（*2） ITコンサルタントのホンネ（その2）

それだけの事前準備をしたにもかかわらず、ヒアリング先ではさまざまな立場の人がそれぞれの興味について話をするため、ともすれば先方の苦労話、体験談でほとんどの時間が過ぎてしまうことがよくある。そういった話の中に重要なヒントが隠れていることもあるので見過ごせないのだが、将来の構想をヒアリングする場面において、現状のささいな苦労話で盛り上がってしまうような場合には、失礼にならないようにこちらの聞きたいことを確認しなければならない。これは意外と苦労する。

◇2-2. ビジネスモデリングの勘所

　今回のヒアリングでは、得意先／取引先とやりとりする情報をどのように作成し、どのように解釈するのか、という業務の流れを確認することが重要だった。このため、事前に準備した資料を用いるだけではなく、必要に応じてその場でフローをホワイトボードなどに図示していく必要があった。

　このとき注意したのが、「あいまいな図を描かない」ことと、「表記の厳密さにこだわらない」ことである。矛盾しているようであるが、筆者は業務フロー記述上のポイントはここにあると考えている。

　あいまいな図では、その場では分かったような気がしてしまうが、後から不明点が出てくることが多い。矢印がデータなのか、単なる業務のつながりなのか、描いた側とユーザーで認識が異なるまま現状確認が進んでしまう（*3）。

（*3） ITコンサルタントのホンネ（その3）

打ち合わせ中によく分からない図が出てきても、取りあえずは「それでいいです」というユーザーも多い。筆者もユーザーの立場だったら、そう答えるかもしれない。従って、「いいです」といわれても、具体例を挙げて確認するなどして、本当に理解されているか少し疑ってかかるのも手である。

　そのため、図を記述する側は、ユーザーに意識させなくとも、同じ記号は同じ意味しか表さないようにして、示している内容を明確にすることを意識しておく必要がある。記号の規則が明確に定義されているUMLモデリングに慣れていると、そもそもあいまいな図が気持ち悪く見えてしまうため、この点はあまり心配する必要がない。

　厳密な表記を追求しようとすると、ユーザーには分かりにくくなる。例えば、1本の発注に対して、数本の出荷があることもあれば1本の出荷しかないこともある。こうしたことを厳密に表現しようとすると、図は複雑になり、読む側もどこが重要であるかをつかみづらくなる。いいたいことの重点が、発注がいくつにも分かれて処理されることではなく、発注から入荷までの全体の流れを伝えることであれば、ここは不正確であっても思い切って図は単純にするのがよい。後は言葉で補足すれば、読み手も重要なポイントから順に理解していくことができる（*4）。

（*4）ITコンサルタントのホンネ（その4）

筆者自身も「適当な図」をうまく描けなくて、相手になかなか理解してもらえなかった経験がある。厳密な図を描こうとしてしまうエンジニアの習性を吹っ切れるようになるまでにはかなり時間がかかった。

　このように、入念な事前準備や図の表現方法の工夫などを重ねながら、各社の現状での受発注の流れや、（一見分かっているようで実は違う意味で使っているような）さまざまな用語の意味、いま感じている問題点、などについて情報収集を行うことができた。

図3 現状業務分析のポイント（クリックすると拡大）

◇2-3. 現状分析結果と解決のための具体案

　続いて、収集した情報を分析する段階に入る。各社の結果を並べてみると、確かに「いろいろ違う」ことがよく分かる。

　今回のポイントは、物流センターの位置付けのややこしさだった。一例を挙げると、小売である○○スーパー専用の物流センターを、卸である△△食品が運営している。そして卸はセンター業務を、物流業者である○×ロジスティクスに業務委託している。このようにいろいろなプレーヤが集まって1つの業務を形作っているのだが、各企業から見ると自社の外でのやりとりについては知らない、という状況である。これが各社微妙に異なる役割分担であったりするため、全体を統一できるモデルを作ることは非常に困難であることも分かってきた。

　これについて工夫したのは、企業の役割を商流・物流の観点から大きく4つに分けたことである。商流は商取引であるので、当たり前のことだが、買い手と売り手の2つの登場人物がいる。一方、物流に関しては、これも当たり前のことだが、出荷元と出荷先の2つの登場人物がある。現在のサプライチェーンでは、1つの企業がこれらの役割を複数担っていたり、ほかのプレーヤに見えない一部の業務を代行業者に委託していたりするため、全体として複雑に見えている。今回は、この4つの役割の間で、取引を完了させるために必要な情報交換とはどうあるべきか、という観点から統一モデルの構築を行った。

　また、商流と物流のプレーヤを分離したことで、流通業界における企業間の情報交換は、大きく受発注・物流・決済の大きく3つの業務グループに分割することができ、それぞれがいくつかのパターンを持つ、という形で整理することができた。

図4 流通業界のプレーヤを商流・物流のアクタに分離した（クリックすると拡大）

　また、企業間取引を効率化する場合の大きな問題として、各社が個別にいろいろな改善努力を行った結果、全体としては個別対応の山になってしまっていることがある。例えば、小売が入荷検品を省力化しようとして、バーコード付きのラベルを貼って、機械で検品する仕組みを導入しようとすると、卸側ではそのラベルの出力や貼り付けが発生する。そのうえ、このラベルは各小売業者で異なっていたりして、ここにもまた新たな個別対応が発生する。

　そこでこうした個別対応に対処するため、さまざまな業務フローを「基本フロー」と「拡張フロー」の組み合わせで対応する、というアイデアを採用した。このアイデアの具体的な内容は、以下のとおりである。

　基本フローとして上記の3業務グループ×数パターンを定義する。基本フローだけでは対応できない企業ごとの独自ルールを、拡張フローとして、その基本フローに対する差分だけを追加する（*5）。フローにかかわらない個別対応部分（独自のメッセージフォーマットや、ラベル、伝票、帳票レイアウト）については、拡張フローの一部分を個別の対応プログラムに振り分ける。

（*5） ITコンサルタントのホンネ（その5）

オブジェクト指向の世界では継承として知られる考え方だが、今回のプロジェクトではまさに「具体的には違うが、抽象的には同じ」という業務上の個別対応を整理することが課題だったため、継承の概念がうまく適用できた。このように上流工程においても、システム開発の技術やノウハウが応用できるケースは意外と多い。

図5 基本フローと拡張フローの例（受注に関する一部のみ抜粋）（クリックすると拡大）

　このようにして作り上げたプロトタイプモデルに対して、ヒアリングの結果を順次適用し、モデルとして不足がないかどうかを確認していった。実際の情報交換の流れに合わせて見ていくと、このプロトタイプモデルのままではうまく現実に適合しない部分、冗長な部分、逆に表現が不足している部分があることも分かってきた。

　出荷指示については、実際には、社内の情報システムとして受注データがそのまま物流センターで参照されており、出荷指示というデータを企業間で交換しないこともあった。しかし、このような場合も仮想的に出荷指示が交換されていると見なすことで対応できた。

　このような検証を重ね、最終的には、システムの仕様としてそのまま利用できる統一ビジネスプロセスモデルを作り上げることができた。

2/3

INDEX
事例で学ぶビジネスモデリング（6） ビジネスモデリングの使いどころ
	Page1 ◆ 1. プロジェクト開始まで
	Page2 ◆2. プロジェクト作業内容
	Page3 ◆3. エピローグ（業務の全体像を把握することの重要性）

IT Architect 連載記事一覧