地に⾜のついたDXを実現するためのメッセージ指向の業務デザイン

⽻⽣ 章洋

⾃⼰紹介

⽻⽣ 章洋（はぶ あきひろ）
1968年⽣まれ

⼤阪府出⾝
1989年、桃⼭学院⼤学社会学部社会学科を中退後、2つのソフトウェア会社にてさまざまな業種・業態向けシステム開発に携わる。
その後、アーサーアンダーセン・ビジネスコンサルティング（当時）に所属。
コンサルタントとして企業改⾰の現場に従事。
さらにその後、トレイダーズ証券株式会社（当時）の新規創業にIT部⾨ディレクターとして、さらにマネースクウェアジャパン株式会社（当時）の新規創業にIT担当取締役として参画、両社にて情報システム部⾨の構築と、⽇本初のリッチクライアント＋OSSによるオンライントレーディングシステムの企画構想から要件定義／設計／開発／運⽤保守までを⾏う。
2006年から2011年まで、国⽴⼤学法⼈琉球⼤学の⾮常勤講師。
現在はエークリッパー・インク代表を務めながら、企業向けにIT化の推進や業務設計の⽀援などを⾏っている。
業務フロー作成ツール「マジカ」やシステム要件定義図法「IFDAM」の作者である。
著書多数。

DX、進んでますか︖• 順調なら、このあとの話は聞かなくてもいいですｗ• DX、ぶっちゃけよぉわからん• でもせっかく上が「DXやろうぜ︕」とか⾔ってるならチャンスよね• とはいえ、効率化とか⽣産性向上とか無駄を無くすとか⾔っても• 具体的に何をどうすりゃいいの︖• 何がどうなったら、そういう結果を出せたといえるの︖• 地に⾜のついたDX＝「システムによって、仕事における⼈間のストレスを撲滅する︕」と定義してみる• まぁぶっちゃけシステムを⼊れたからストレスが増えた、とかありますがそういうのも何とかしようぜ、と仕事のストレスって何だろう︖• 作業のストレス• 難しいとか⾯倒くさいとか→そこで⾃動化︕
RPAとか…去年は「ノーモアコピペ︕ノーモア再⼊⼒︕」
とか⾔ったんですよ• ⼈間関係のストレス︕• ⾔い換えるとコミュニケーション• コミュニケーション＝情報の伝達／共有• 「仕事で必要な情報がきちんと伝わってこない︕」• 気配りや再確認はコスト︕

何故、コミュニケーションが必要になるんだろう︖
やるべき仕事が増えるほど⼈⼿が必要→分業が進む●分業するほど、ひとりずつの役割が明確になる→専⾨化の進⾏●⾃分の仕事に専念することができるので作業効率がアップする何故、コミュニケーションが必要になるんだろう︖
分業が進むほど、それぞれが⾃分の仕事をするために「知らないと仕事が出来ないこと」を伝え合う必要が⽣まれる
何が注⽂できるんだろう︖

何を作ればいいんだろう︖
何を注⽂するんだろう︖

どこに運べばいいんだろう︖

6もしちゃんと情報が伝わらなかったら︖

7

分業するほど情報伝達（コミュニケーション）の必要性が⾼まるが、情報は物理制約を伴わないため扱いが雑になりやすいせいで情報伝達は⾯倒くさいので疎かになりやすい→情報の断絶︕サイロ化／縦割り
何が注⽂できるんだろう︖

何を注⽂するんだろう︖

何を作ればいいんだろう︖

どこに運べばいいんだろう︖

連携プレーが途絶えてしまい、個々の仕事が優れていても意味がなくなる

分業におけるコミュニケーションパスという問題
全体のコミュニケーションパス数＝n(n-1)/2
⼀⽅で⾃分がカバー出来るパス数=(n-1)※ｎは⼈数

2⼈＝1/1本＝カバー率100%

5⼈＝4/10本＝カバー率40%

3⼈＝2/3本＝カバー率67%

9⼈＝8/36本＝カバー率22%

関係者や作業量や取引量が増えるほど情報のやり取りの数が膨⼤になり、割とあっという間にカオス化して⼿に負えなくなる肝は「司令塔」︕• 誰かに、全体を俯瞰的に⾒て采配をふるってほしい• みんな⾃分の役割で⼿⼀杯︕• 全体の状況を把握して、適切な判断をして、適切に指⽰してほしい• ⾃分の仕事に集中させてほしい︕• つまり「司令塔」がほしい︕ 司令塔に仕切ってほしい︕

コミュニケーションを統括してほしい

10

司令塔ありきで業務をデザインする︕
従来の業務フロー⽬⽟焼きできたよ︕

⽬⽟焼き
いっちょ︕

司令塔と各プレイヤーの間のメッセージングを踏まえて業務を考える

メッセージ指向の業務デザイン︕

司令塔ありきの業務フロー

⽬⽟焼き作って︕

⽬⽟焼き
いっちょ︕

⽬⽟焼きできたよ︕

⽬⽟焼き運んで︕
⽬⽟焼き
運んだよ︕

P2PからHub&Spokeへ…って何か⾒覚えが司令塔のデジタル化• とはいえ現実的には、司令塔役に⼈⼿は割けない→そこでシステム化ですよ︕• でも従来の情報システムって• ぶっちゃけ現場の業務の役に⽴つというよりも、管理業務のためでしかなくね︖• システム化しても現場は⼊⼒と操作の⼿数が増える⼀⽅で、全然楽になってる気がしないとかさ

注⽂データ

調理データ

配膳データ
ふむふむ
なるほど各種レポート

司令塔としてのシステム︕• 事後記録とレポーティングのためのシステム(System of Record)からリアルタイムに関係を扱うシステム(System of Engagement)へ

⽬⽟焼き作って︕

⽬⽟焼きできたよ︕

⽬⽟焼き運んで︕

⽬⽟焼きいっちょ︕

⽬⽟焼き運んだよ︕• システム＝プログラムの集合体• プログラム＝データ構造＋アルゴリズム• 【重要】アルゴリズムはデータ構造に従属する︕• データ構造つまりデータモデルが肝︕• 司令塔であるシステムが⾏う「采配する」という業務をデータモデル化する︕

業務のデジタルツインとしてのデータモデル• 司令塔が把握すべき情報＝コラボレーションステート（協業の状態）• コラボレーションステートの構成要素• PlanとしてのToDoリスト（何をどうするのか）• 発動条件ルール（何がどうなったらToDoを⾏うのか）• 司令塔のDoとしての「依頼／指⽰」（「誰某さん、このToDoを⾏ってください」）• ToDoが完了したことを表すチェックリスト（ToDoを完了した"誰某さん"からの完了報告を受けてチェックをつける）

コラボレーションステートを含めたデータモデル
商品

注⽂
する

客席

商品

調理する
配膳する

客席

采配する
注⽂
する

調理する

配膳
する

「采配する」の正しいエンティティ名は︖→「みんなで連携して⾏う⼀連の仕事の集まり」の業務名︕…⾔い換えると「コラボレーションそのものに名前がついてない」問題（実はこれ「プロジェクト」や「案件管理」と根っこは同じ概念なんだけど…）

これを意識して考えることが「メッセージ指向の業務デザイン」の要諦︕

そしてWagby︕• データモデルさえ作れればWagbyの出番ですよ︕• データモデル＋ルールモデルでシステムを構築できる︕• Wagbyならメッセージングをルールとして制御できる︕• データが更新されたら通知（メールなど）ができる• 時間指定ジョブと実⾏条件指定がある• しかもその定義＝設計情報を組織のDNAとして引き継ぎ続けることができる︕• ⼀般的に、データモデルの寿命はプロセスモデルよりも⻑いデータモデリングのインプットとしての業務デザイン• データモデルを作るのもひとつの業務• 業務にはインプットが必要＝「業務デザイン」という材料

業務
デザイン

データモデル…

• 従来のままの業務デザインでは同じことの繰り返しになる• システムを司令塔に据えてメッセージ指向で業務を考えることがDXにつながる︕• メッセージ指向＝ 「デマンド（要求）のエクスチェンジを実現する」

まとめ• 地に⾜のついたDX＝仕事のストレスであるコミュケーションの問題をシステムで解決する︕• そのためにまずは「メッセージ指向の業務デザイン」︕• 実現のためにWagbyを︕