SRO（Scrum Reference Ontology）について

最近、AIの文脈で「オントロジー」という用語を目にする機会が増えています。
個人開発でスクラム文献の LLM Wiki を構築するにあたり、オントロジー調査を実施しました。その際、論文 From a Scrum Reference Ontology... を発見しました。
関心を持ったため Gemini Notebook にPDFを取り込んで内容を解読しました。本記事では、その概要と興味深かったポイントをまとめます。

---

オントロジーの理解について

個人的に以下のようなものであると理解しています。

• データ（概念）のつながりを明確にしたデータモデル。
• OWL(Web Ontology Language)や、RDFS(Resource Description Framework Schema)といった形式で記述される。

LLM Wiki の構築にあたりオントロジーに注目したのは、概念の分類定義が存在することで情報整理が容易になると考えたためです。
この用途では、ryuzeeさんのサイトからダウンロードできる、Scrum Guide Reordered（日本語版）の用語が参考になる気もしています。

• Scrum Guide Reordered（日本語版） | Ryuzee.com

論文の概要

以下、Gemini Notebook にまとめてもらった概要です。

• Gemini Notebookのまとめ

この論文は、**アジャイル開発（Scrum）で使われる複数のツールを連携させ、データを活用した意思決定をスムーズにするための仕組み**について書かれています。

ざっくりまとめると、以下の3つのポイントに分かれます。

### 1. 開発現場が抱えていた課題
- Scrum開発では、タスク管理（Azure DevOpsなど）や作業時間の計測（Clockifyなど）、コード品質管理など複数の異なるツールが併用されます。
- ツールごとにデータの形式や用語の意味（概念定義）が異なるため、データを統合するには手動での二重入力やスプレッドシートでの集計作業が必要になり、データを活かした素早い意思決定の妨げになっていました。

### 2. 提案された解決策（Scrum参照オントロジー：SRO）
- Scrumにおける役割、プロセス、バックログ、成果物などの概念や関係性を体系的に定義した共通モデル**「Scrum参照オントロジー（SRO）」**を開発しました。
- このSROをツール間の「共通言語（橋渡し）」として利用し、Azure DevOpsとClockifyの間でデータを自動的に同期・統合してダッシュボードに表示するシステムを構築しました。

### 3. 実証実験とその成果
- ブラジルの政府系IT機関（Prodest）の実際のソフトウェア開発プロジェクトでこの統合システムを運用しました。
- データの自動連携により手作業や転記ミスが削減されたほか、過去の作業データを元にした作業見積もりの誤差が**24%から7.3%へと大幅に改善**するなどの効果が確認されました。

---

SRO のオントロジーについて

以下は、論文内で記載されているオントロジーをMermaid.jsで可視化したものです。

Mermaid.jsでのサブオントロジーごとの可視化

SRO（Scrum Reference Ontology）では、Scrumを以下の5つのサブオントロジーごとに図を分割していました。
それぞれのサブオントロジーごとに、Mermaid.jsで図を作成したものが以下になります。
サブオントロジーの関係まで含めて可視化してもらうと、図が複雑になりすぎたので、サブオントロジーごとに分けて作成しました。

---

1. 🟦 Scrum Process Subontology（プロセス）

プロジェクト全体からスプリント、各セレモニー（イベント）への流れと依存関係を表しています。

---

2. 🟨 Scrum Stakeholders Subontology（関係者・役割）

チーム構成、担当者、および特定の役割（Role）への割り当て関係を表しています。

---

3. 🟧 Scrum Stakeholders Participation Subontology（責任・参加）

誰がどのプロセスやセレモニー、タスクの責任者（is in charge of）であり、参加（participates in）するかを表しています。

---

4. 🟩 Product and Sprint Backlog Subontology（バックログ・要件）

ユーザーストーリーの構造、受入条件（Acceptance Criteria）、計画タスクから実行タスクへの分解を表しています。

---

5. 🟪 Scrum Deliverables Subontology（成果物・Done判定）

タスクから生み出される成果物と、受入条件による判定（Done / Not Accepted）、および成果物の統合構造を表しています。

サブオントロジー間の関係

前回のサブオントロジー間および基盤ネットワーク（SEON）の依存関係図に、各サブオントロジーとSEON層を色分けしたMermaid.jsダイアグラムを作成しました。 実際の図は、サブオントロジー内の概念に対して、個別に関係性が定義されています。
論文内の図表で表現されているので、正しい関係性を知りたい方はそちらを参照されることをお勧めします。
大体の関係性という意味で以下の表現で間違っていないとは思っています。

---

🎨 色分けの凡例と関係性の解説

1. SRO内部（5つのサブオントロジー）

   • 🟦 Scrum Process（ブルー）: スプリントやセレモニーといったプロセス構造の核。
   • 🟨 Scrum Stakeholders（イエロー）: チームメンバーやプロダクトオーナーなどの役割構造。
   • 🟧 Scrum Stakeholders Participation（オレンジ）: 誰がどのイベントの責任者（is in charge of）かという関与関係。
   • 🟩 Product and Sprint Backlog（グリーン）: ユーザーストーリーやタスク計画などの要件系。
   • 🟪 Scrum Deliverables（パープル）: 成果物と受入条件によるDone判定系。

2. SEON上位オントロジー（破線枠）

   • 🟡 EO（組織）: 企業やプロジェクトの役割モデル（イエロー系破線）。
   • 🟢 SPO（プロセス）: ソフトウェア開発プロセスやアクティビティの基本モデル（グリーン系破線）。
   • 🔴 RSRO（要件）: 要求や要件成果物の抽象モデル（ピンク系破線）。

1-1. 関係性の主な種類

• 構造・分類関係（Taxonomical & Whole-Part）:
  • 継承・排他分類（is-a）: 上位概念と下位概念の関係や排他関係を示す。
  • 全部分関係（Whole-Part）: composed of など。例えば Sprint は Ceremony や Task で構成され、User Story は Epic に分解される。
• 関与・責任関係（Participation & Responsibility）:
  • is in charge of（責任） / participates in（参加）: 特定のイベントやアクティビティにおける役割ごとの実行責任や参加関係を規定する。
  • allocated via（割当）: 人物がチームメンバーシップを介して特定の役割（Product Owner Role 等）に割り当てられる関係を示す。
• 因果・生成・実現関係（Causality, Creation & Materialization）:
  • causedBy（因果）: 計画された意図的タスク（Intended Task）が実際の実行タスク（Performed Task）を引き起こす関係を示す。
  • produces / materializes（生成・実現）: タスク実行が成果物（Deliverable）を生成し、成果物がユーザーストーリーを具現化する関係を示す。
  • in compliance with / evaluated by（評価）: 成果物が設定された受入条件（Acceptance Criterion）に適合しているかを評価・判定する関係を示す。

1-2. 記述ルールと記法

• OWLの標準語彙: W3C仕様の語彙を用いて記述する。クラス間の非重複性（owl:disjointWith）、要素数制限（owl:cardinality）、プロパティ特性などを定義できる。
• UML概念モデル表記: 図上で関係名、多重度（1, 2..* 等）および分類制約（{disjoint, complete} 等）を用いて構造ルールを明記する。
• 一階述語論理（FOL）の公理（Axioms）: UMLやOWLの構文だけで捉えきれない複雑なルールを、数論理式で厳密に定義する。例として「実行タスクの成果物は、必ずスプリントバックログのユーザーストーリーに紐づく」などが挙げられる。

---

2. OWL仕様の表現力による現実世界モデリングの妥当性

論文では、一階述語論理（FOL）の公理に該当するモデル表現はOWLのみで完結せず、Pythonコードによる外部実装で解決したと述べられています。

• Gemini Notebookの回答

結論として、OWLの仕様単体では現実世界（参照オントロジー）の完全なモデリングとしては事足りません。

* **OWLの制限とトレードオフ**:
  OWLはWeb上での分散性や計算可能性（自動推論の決定可能性）を保証・維持するために設計されており、一階述語論理（FOL）の表現力を意図的に制限した記述論理（Description Logics）を基盤にしています。そのため、複数変数が複雑に連鎖するビジネスルールや因果関係（`causedBy` など）をOWLのみで直接表現することには限界があります。

* **SROでの解決アプローチ**:
  SRO論文では、現実世界を厳密に記述するモデルを**「参照オントロジー（FOLの公理を含む）」**として構築し、計算・実装の段階ではこれを**「情報モデル（Information Model）」**へと変換した上で、PythonやSQLAlchemy（ORM）を用いたデータベース（SRO Database）およびアプリケーション側のバリデーションロジックとして実装・補完しています。

OWLで表現できない制約ルールをコード化やMarkdown化以外で扱う手法として、W3Cの SHACL 1.2 Rules が活用できます。
OWLとSHACLを併用することで、FOL相当の表現や制約チェックを実現可能です。

参考

以下、SHACLについて記載されたQitaやZenの記事になります。

• Shapes Constraint Language (SHACL) #rdf - Qiita
• オントロジーで AI に業務知識を渡す — AWS の OSS「Context Ontology Accelerator」を試してみた

---

3. SROモデルとスクラムガイドとの乖離に対する解釈

SROのOWLファイルを読み解くと、スクラムガイドの定義と解釈の異なる点がいくつか見受けられます。 主な比較は以下の通りです。

観点	スクラムガイド	SRO（Scrum Reference Ontology）
要件概念	抽象的な PBI（特定の形式を問わない）	User Story（Epic / Atomic に分解）
要件の属性	詳細・並び順・見積り	Importance, Effort, Acceptance Criterion（機能/非機能）
Done判定	人間・チームによる共通理解と判断	成果物が受入条件に適合するかによる Accepted / Not Accepted の機械判定
プロセス構造	イベントの集合（スプリントと4つのイベント）	Product Backlog Definition ＋ 2つ以上の Sprint（依存関係 depends on を含む）
役割と参加	役割ごとの責務と相互作用のガイドライン	属性関係 is in charge of（責任） と participates in（参加） の形式的記述

特に、POに各イベントの is in charge of（責任）が割り当てられ、SMにデイリースクラムの is in charge of が付与されている点には異論が生じやすいところです。 しかし、Azure DevOps等との連携や実現場への適用を踏まえると、こうした形式的解釈も合理的なアプローチと言えます。

SROで「ユーザーストーリー」や「受入条件によるDoneの自動判定」などが具体的に定義されていることと、公式スクラムガイドの記述との乖離は、欠陥ではなく**「目的の違いに伴う役割と抽象度の違い」**として解釈されます。

* **スクラムガイドの目的（人間のための軽量フレームワーク）**:
  スクラムガイドは、人間のチームが現場で柔軟に自己組織化して作業を進めるための**「意図的に不完全な軽量フレームワーク（骨格）」**です。そのため、特定の技法（ユーザーストーリー等）を強制せず、「プロダクトバックログアイテム（PBI）」という抽象的な用語を使用しています。
* **SROの目的（異種ツール統合のための機械可読モデル）**:
  SROは、Azure DevOpsやClockifyといった異種アプリケーション間でデータ構造の意味的衝突を解決し、データを自動同期・集計するための**「共通言語（Interlingua）」**です。システム上で工数偏差の計算や「Done」の客観的判定を自動化するには、PBIを `Requirement Artifact` である `User Story` として具現化・形式化する必要があります。
* **アジリティとの両立**:
  SROによる厳密な形式化は、開発ツールの裏側（ミドルウェア/統合層）で処理されるため、現場のスクラムチームに手動のドキュメント作成負荷やプロセスの硬直化を強制することはありません。スクラム本来の柔軟性を維持したまま、データ駆動型の意思決定を支援できます。

---

考察と感想

論文を踏まえての考察と感想をまとめます。

• 異種ツール間の翻訳レイヤーとしての有用性
  • ツールごとの用語表記の揺れを吸収する中間層として、SRO（OWL）による共通モデルは有効である。完全な用語一元化は難しくとも、自動連携の基盤として大きな価値を持つ。
• DDDのユビキタス言語との親和性
  • ユビキタス言語の定式化にOWLを活用する手法は実用的である。また、SRO構築に使われたSABiO手法の「知識質問（Competency Questions: CQ）」は、ユビキタス言語の辞書作成や要件定義にも応用できる。
• フレームワーク概念の詳細なモデル化
  • 各種 Subontology により、スクラムガイドで抽象化されている領域が明確に概念化されている。一部の責任関係を除けば、現場の実態と大きく乖離していない。
• LLM Wikiにおけるナビゲーションへの活用
  • 概念間の関係性が構造化されているため、LLM Wikiのインデックスやナビゲーションとして活用できる。違和感のある責任関係（Scrum Stakeholders Participation Subontology）を一部調整すれば、十分に実用可能である。
• オントロジー適用領域の適性
  • 個別プラクティスよりも、ScrumガイドやKanbanガイド、法令順守等の標準モデルへの適合性が高い。現場固有表現が多い領域ではモデルが乱立しやすいため、適用範囲の切り分けが重要となる。

SROをベースにして、スクラムプロセスの評価をするAIスキルを作れないかなと、考えております。
SHACL 1.2 Rulesを使ってOWLで表現できない制約を表現できれば、うまくプロセスの妥当性検証ができるのではないかと考えています。
以上です。