業務オントロジー入門 第2回｜業務から「もの」を切り出す 〜マスタ・出来事の記録・関係・言葉の決め方〜

設計書を集めても、型にはならない

「業務の型を作るなら、まずデータベースの設計書を集めればいい」

多くの方が、そう考えていると思います。

でも、それでは型にならないと私たちは考えています。

設計書は「どう保存するか」の都合で書かれているからです。型は、業務の言葉から作ります。データ設計に見えて、実際には「会社の言葉を決める」作業です。

前回、業務オントロジー（業務の型）は「もの・関係・状態・業務操作」の4つでできていると説明しました。今回はその名詞の側、ものと関係を決める方法を扱います。

この記事は、業務オントロジー入門シリーズ（全7回）の第2回です。シリーズの一覧はこちら。

まずは、材料をどこから取るかから考えます。

業務の説明から、名詞と動詞を抜き出す

いちばん単純で、よく効く方法は、業務マニュアルや担当者の説明から、名詞と動詞を抜き出すことです。

受注業務の説明文を1つ置いてみます（説明のための例です）。

顧客から注文書が届くと、営業担当が受注を登録する。1件の受注には複数の商品を含めることができ、商品ごとに数量と単価を記録する。登録後、経理が顧客の与信枠を確認し、枠内であれば営業担当が受注を確定する。枠を超える場合は保留とし、上長の承認を得れば確定できる。承認の記録は監査のために残す。確定した受注は倉庫に出荷指示が出され、出荷が完了すると請求書が発行される。

名詞を拾うと、顧客・注文書・営業担当・受注・商品・数量・単価・経理・与信枠・上長・承認・出荷指示・請求書。

動詞を拾うと、登録する・確認する・確定する・保留にする・承認する・出荷を指示する・出荷を完了する・請求書を発行する。

迷うのは、「承認」「点検」「返品」のような、名詞としても動詞としても使われる言葉です。

判断の基準は、その出来事について、後から問い合わせる必要があるかです。

誰がいつ承認したか、どんなコメントを付けたかを後で確認する。それなら「承認記録」をものにし、「承認する」を業務操作にします。

承認済みかどうかだけ分かればよい。それなら「承認する」という操作が、受注の承認状態という項目を書き換えるだけで足ります。

この説明文には「監査のために残す」とあるので、承認記録はものになります。

注文書は、受注の元になる書類なので、受注に添付する項目にします。営業担当・経理・上長は、ものではなく、次回の業務操作の権限として現れます。

抜き出した名詞は、2種類に分かれます。

「もの」には、長く居るものと、起きた記録がある

顧客や商品は、比較的長く存在し、項目がときどき更新されます。マスタと呼ばれるものです。

受注や出荷、請求は、ある時点に起きた出来事の記録です。日々大量に増え、原則として過去の分は書き換えません。トランザクションと呼ばれます。

型では、どちらもものとして扱います。ただし、設計の考え方が違います。

マスタは「今どうなっているか」を保てばよいことが多い。出来事の記録は「いつ、誰が、何をしたか」が本体で、後から見返せることに価値があります。

実務で迷うのは、両方の性質を持つものです。

受注は、出来事の記録です。でも、受け付けてから出荷まで、状態が変わり続けます。

このような対象は「状態を持つもの」として設計します。状態の決め方は、次回の主題です。

ものの候補が出そろったら、1つずつ確かめることがあります。

「1件が何を表すか」を言えるか

ものを決めるとき、私たちが一番大事にしている問いがあります。

「何が1つ増えると、1件増えるか」

受注なら、注文書が1通届くと1件増える。受注明細なら、注文書の中の商品が1種類増えると1件増える。これが言えるものは、ものとして立てられます。

言えないものの典型が、分析用に結合した表です。

ダッシュボードのために、「受注×明細×顧客×商品」を1枚の大きな表にしてあることがあります。集計には便利です。

でも、これをそのままものにすると、1行が何を表すのか（受注なのか、明細なのか）が曖昧になります。

「受注を確定する」という操作を実行するとき、どの行を更新すべきかも決まりません。

同じ事実は1か所にだけ保存する。これは、データベース設計で正規化と呼ばれる考え方の、いちばん大事な部分です。型の設計でも、ものの切り出し方の基準として、そのまま生き続けます。

ものが決まったら、ものとものをつなぎます。

関係は「何対何か」を決める

関係には、「何対何か」があります。設計の誤りの多くは、ここで起きます。

多対多の間に現れる実体は、業務上、重要なことが多いです。

受注明細、配属、契約。どれも、2つのものをつなぐだけでなく、数量や単価、期間のような固有の項目を持ちます。

単なるつなぎの表として扱わず、独立したものとして名前を付けるかどうかを検討します。受注明細は、「受注を確定する」操作が金額を合計する対象なので、ものとして立てます。

もう1つ、ものにするかどうかで迷う対象があります。

「あれ」と指して話すか

住所、金額、期間。これらは、ものなのか、ものの項目なのか。

判断の問いは1つです。「この対象について、後から『あれ』と指して話すことがあるか」。

あるなら、ものです。IDで区別し、項目が変わっても同じものとして追いかけます。

ないなら、項目（値）です。値が同じなら同じもの、変えるときは丸ごと置き換えます。

住所は、普通は値です。顧客の届け先住所が変われば、新しい住所に置き換えるだけです。

でも、配送拠点として管理し、拠点ごとに配送実績の履歴を追うなら、「拠点」はものです。

同じ言葉でも、業務の使い方で答えが変わる。だから、型は設計書ではなく、業務の言葉から作ります。

その業務の言葉が、揺れていることがあります。

言葉は、1語1義にそろえる

同じものを「受注」「注文」「オーダー」と呼び分けている組織は多いと思います。

逆に、同じ「出荷」という言葉が、倉庫を出た時点を指す人と、顧客に届いた時点を指す人がいることもあります。

業務の担当者と、システムを作る人が共通に使い、会話・文書・データ定義のすべてに同じ形で現れる言葉。これを、ソフトウェア設計の分野ではユビキタス言語と呼びます。このシリーズでは「社内共通語」と呼びます。

型のものの名前、項目の名前、業務操作の名前は、社内共通語そのものです。

業務の型を作ることは、社内共通語を確定させ、データに結びつけることだと言い換えられます。

やることは地味です。揺れを1つずつ潰して、1語1義にする。

「出荷とは、倉庫から商品が出た時点を指す。顧客に届いた時点は『納品』と呼ぶ」。こう決めて、用語集に書き、型の名前に使います。

ただ、全社で1つに決められない言葉もあります。

部門で意味が違うなら、範囲を分けて対応表を作る

「商品」は、営業にとっては価格と仕様の組み合わせです。物流にとっては、サイズと重量を持つ荷物。経理にとっては、勘定科目に紐づく品目です。

全社で1つの巨大な「商品」を作ろうとすると、すべての部門の要求を1つに詰め込むことになります。誰にとっても使いにくいものになり、合意はいつまでも取れません。

ソフトウェア設計では、1つのモデルと言葉が一貫して成り立つ範囲を決め、範囲の外では同じ言葉が別の意味を持ってよい、と考えます。このシリーズでは「意味の範囲」と呼びます。

業務の型は全社共通の層を目指すので、この問題に突き当たります。全社で共通にするのはIDと中核の項目だけにし、残りは部門ごとの範囲に分けます。実務では、3つに分けて考えます。

全社一枚岩のモデルを目指さない。これは、型作りが止まる最大の原因を避けるための原則です。

ここまでの方法は、業務マニュアルや説明文を材料にしていました。でも、マニュアルには書かれていないことがあります。

付箋で出来事を並べると、書かれていないことが出てくる

マニュアルから名詞と動詞を抜き出す方法は、書かれていないことを見つけられません。

さきほどの受注の説明文には、「取り消し」が出てきません。実際の業務では必ずあります。

これを見つける方法として、業務に関わる人が集まり、業務で起きる出来事を付箋に書いて時系列に並べるワークショップがあります。イベントストーミングと呼ばれ、アルベルト・ブランドリーニが2013年に公に紹介しました。

最小限のやり方は、次のとおりです。

1. 出来事を過去形で書き、時系列に並べる。「注文書が届いた」「受注が登録された」「与信が確認された」「受注が確定した」「出荷が完了した」
2. 各出来事の前に、それを起こした操作と担当者を貼る。「受注を登録する／営業担当」
3. 操作の前に見ている情報を貼る。「与信残高」「受注一覧」
4. もめた所、決まっていない所に目立つ色の付箋を貼る。「保留の基準が部署で違う」

付箋を前に、「その前に何が起きる？」「それは誰が決める？」と問い合うことで、暗黙の業務や部門間の食い違いが表に出ます。

出てきた付箋は、そのまま型の材料になります。出来事の記録はもの、操作は業務操作、担当者は操作の権限、見ている情報は検索や計算、もめた所は「未決」として定義表に残します。

「取り消し」のように、説明文から漏れた動詞を見つけることも、型作りの重要な成果です。

では、ここまでの方法で、受注業務はどこまで決まるでしょうか。

受注業務で試す

さきほどの説明文から、もの・関係・状態の候補を表にします。

ものが7つ、関係が6本。最初の題材として、ちょうどよい大きさです。出荷指示も状態を持ちますが、このシリーズで状態遷移を描くのは受注だけにします。

動詞の側、つまり「受注を確定する」のような業務操作と、受注の状態は、まだ決めていません。次回の主題です。

推進担当が押さえる要点

• 業務オントロジー（業務の型）の材料は設計書ではなく、業務マニュアルと担当者の説明。名詞はもの、動詞は業務操作、「〜の〜」は関係の候補になる
• ものには、長く居るマスタと、起きた出来事の記録がある。両方の性質を持つ受注は「状態を持つもの」
• ものにしてよいかは「何が1つ増えると1件増えるか」で確かめる。分析用の結合表は、そのままものにしない
• 多対多の間に現れる「受注明細」「契約」は、固有の項目を持つ重要なもの
• 言葉は1語1義にそろえ、部門で意味が違うなら範囲を分けて対応表を作る。全社一枚岩を目指さない
• マニュアルに無い出来事は、付箋を並べるワークショップで見つける

名詞を決めると、オントロジーの動詞が見えてくる

ものと関係を決める作業は、データ設計に見えて、実際には「会社の言葉を決める」作業です。

そして、ものを決めると、「それに対して誰が何をしてよいか」という問いが自然に出てきます。

次回は、受注の状態を図に描き、矢印1本ずつを業務操作として定義します。

シリーズの目次

1. 業務オントロジー入門 第1回｜なぜ今、業務に「型」が要るのか
2. 業務オントロジー入門 第2回｜業務から「もの」を切り出す（この記事）
3. 業務オントロジー入門 第3回｜業務操作を定義する
4. 業務オントロジー入門 第4回｜基幹システムは置き換えない
5. 業務オントロジー入門 第5回｜型の上でAIはどう動くか
6. 業務オントロジー入門 第6回｜Palantir、Fabric IQ、SAPはどう違う？
7. 業務オントロジー入門 第7回｜最初の1業務を型にする

関連記事

• 業務オントロジー入門 第1回｜なぜ今、業務に「型」が要るのか：型の4つの要素と、似た言葉との違い
• AIエージェントの権限設計｜オントロジーで「やっていい操作」を定める：業務操作の5つの項目

参考資料

• Eric Evans, "Domain-Driven Design: Tackling Complexity in the Heart of Software," Addison-Wesley, 2003（ユビキタス言語、境界づけられたコンテキスト）
• Alberto Brandolini「Introducing Event Storming」（Ziobrando's Lair、2013年11月18日、https://ziobrando.blogspot.com/2013/11/introducing-event-storming.html （2026年11月1日確認））

Askhubについて

Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型（オントロジー）でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。

この記事で扱った「もの・関係・言葉の決め方」は、製品に依存しない設計の作業です。Askhubの導入では、コンサルタントがこの作業に伴走します。

※Askhubのサービスに関する記載は、2026年11月時点の情報です。