Essence FrameworkによるSimpleModeling Development Processの定義
前回の記事では、AI時代のSimpleModeling開発プロセスを、BoK・Cozy・CNCF・SKILLを中心とした実行可能な構造として整理しました。
本稿では、その開発プロセスをEssence Frameworkを用いて再定義します。目的は、SimpleModelingを単なる開発手順ではなく、KernelとPractice (プラクティス)を組み合わせて構成されるDevelopment Processとして明確化することです。
背景
SimpleModelingは、Unified Process (UP)をベースに、AI時代向けに構成した開発プロセスです。 開発プロセスとは、ソフトウェア開発を進めるための活動 (Activity)、役割、成果物、進行方法を定めた枠組みです。
本稿では、その開発プロセスをEssence Frameworkを用いて定義します。
Essence Frameworkで定義することで、開発プロセスを部品として扱いやすくなります。KernelとPracticeを基盤に整理することで、目的や状況に応じて必要な要素を選択し、組み合わせやすくなります。
また、この整理は、SKILL化を見据えたプロセス・モデル化の土台にもなります。Activity、Work Product (ワークプロダクト)、Role、Automationの対応関係を明示することで、人間が読む方法論にとどまらず、AIエージェントが解釈し支援できる構造として記述しやすくなります。
Essenceを基盤にする
SimpleModelingでは、Essenceの考え方を次のように用います。
| 概念 | SimpleModelingでの役割 |
|---|---|
すべてのMethod Viewに共通する基盤。 |
|
開発中に進化・評価される対象。Opportunity、Stakeholders、Requirementsなど。 |
|
Methodを構成する選択可能な単位。 |
|
Practiceに含まれる抽象的な作業単位。 |
|
Activityによって作成・更新される成果物。 |
|
Activityを遂行するために必要な能力。 |
SimpleModelingでは、PracticeをMethod構成の単位とし、Activityを実行単位、SKILLをActivityを支援または自動化する具体的な手順として扱います。
Development ProcessとMethod
SimpleModelingでは、開発メソッド (Development Method)を、Essence Kernelに対して選択されたPracticeの組み合わせとして定義します。
Development Processは、この開発メソッドに、Process Flow、成果物、役割、AIエージェント、自動化、ライフサイクル (Lifecycle)を加えたものです。
SimpleModelingのPractice Group
Practice Groupは、SimpleModelingで導入する分類概念です。Essenceの標準要素ではありません。
現時点では、次のPractice Groupを想定します。
| Practice Group | 目的 |
|---|---|
Essence Practice Group |
Essenceの参考文献に由来するPracticeを保持する。 |
Solo Development Practice Group |
一人開発に適したPracticeを保持する。 |
SimpleModeling Practice Group |
ツールに依存しないSimpleModelingのPracticeを保持する。 |
SimpleModeling with Cozy Practice Group |
CozyシリーズとCNCFを用いたSimpleModelingのPracticeを保持する。 |
基準となるMethod View
CozyとCNCFを用いた標準的なSimpleModeling Development Processの基点として、次のMethod View (ビュー)を定義します。
選択されるPracticeの候補は次の通りです。
-
Scrum Solo Practice
-
Business Modeling Solo Practice
-
Cloud Native CBD (Component-Based Development) Practice
-
BDD (Behavior-Driven Development) with Use-Case Lite Practice
-
User Environment Lite Practice
-
CI/CD Pipeline Practice
-
DevOps Practice
また、要求記述にはUse Case Lite Practiceを基準として用います。User Story (ストーリー) Lite Practiceは代替Practiceとして扱います。
Process Flow View
Work Product View
Work Product Viewでは、Activityによって作成・更新される成果物を定義します。
代表的なWork Productは次の通りです。
-
Vision and business context
-
Use Case Lite descriptions
-
Use Case slices
-
BDD scenarios
-
BoK documents
-
Cozy domain models
-
Component (コンポーネント) models
-
Generated source code
-
CNCF execution components
-
Test (テスト) cases and test reports
-
CI/CD pipeline definitions
-
Release notes
-
Operation (操作) and security notes
Lifecycle View
Lifecycle Viewでは、Development Processを時間軸上でどのように進めるかを定義します。
SimpleModelingでは、Unified Processのフェーズ構造を参考にしつつ、AI支援の反復開発に適した軽量なライフサイクルとして扱います。
| フェーズ | 焦点 |
|---|---|
Inception |
目的、ステークホルダー、主要ユースケースを明確にする。 |
Elaboration |
アーキテクチャ、ドメインモデル、主要リスクを固める。 |
Construction |
スライス単位で機能を生成・検証・統合する。 |
リリース、運用、観測、改善を行う。 |
まとめ
SimpleModeling Development ProcessをEssence Frameworkで定義することで、開発プロセスをPracticeの集合として構成し、ActivityとSKILLを通じて実行可能な構造へ接続できます。さらに、CNCFを実行基盤として位置づけることで、生成されたコンポーネントを実際に動作するシステムへ接続できます。
この構造により、SimpleModelingは、AI支援による一人開発、モデル駆動開発、継続的な生成・検証・運用を統合するDevelopment Processとして発展できます。
参照
用語集
- BoK (Body of Knowledge)
-
SimpleModelingでは文脈共有の核となる知識体系をBoK (Body of Knowledge)と呼んでいます。 BoKの構築は、知識の共有、教育、AIによる支援、自動化、意思決定支援を可能にするための基盤です。
- Cozy
-
Cozyは、CMLと各種DSLで記述されたModelを解析し、プログラム、設定、文書などの実現成果物へ変換するSimpleModelingのツールチェーンです。
- Cloud Native Component Framework (CNCF)
-
Cloud Native Component Framework(CNCF)は、クラウド・アプリケーションを構成するコンポーネントを、単一かつ一貫した実行モデルで実行するためのフレームワークです。 Component / Service / Operation という構造を中核とし、command、server(REST / OpenAPI)、client、script といった異なる実行形態から、同一の Operation を再利用できることを特徴とします。 ログ、エラー処理、設定、配備といったクラウド・アプリケーションに必要な品質属性をフレームワーク側に集約することで、コンポーネントはドメイン・ロジックの実装に集中できます。 CNCF は、文芸モデル駆動開発および AI 支援開発を前提に、「何を実行するか」と「どのように呼び出すか」を分離するための実行基盤として設計されています。
- シンプルモデリング (SimpleModeling)
-
SimpleModelingは、KnowledgeからDomain Modelを構成し、CMLで形式化し、CozyとAIによって実行可能ソフトウェアへ実現し、Textus上で動作させる、モデリング中心のソフトウェア開発方法論と技術体系です。
- カーネル (Kernel)
-
任意のソフトウェア開発活動を定義・理解するために必要最小限の概念を含むEssenceの中核要素群。アルファ、アクティビティスペース、能力などで構成される。
- 開発プロセス (Development Process)
-
Undefined
- プラクティス (Practice)
-
ソフトウェア開発の特定の側面をどのように扱うかを定義した再利用可能なメソッド断片。複数のプラクティスを組み合わせてメソッドを構成できる。
- UP (Unified Process)
-
UMLを基盤とし、反復型・ユースケース駆動・アーキテクチャ中心のプロセスモデル。Rational Unified Process (RUP) などの派生形を持ち、CBD(コンポーネント指向開発)の実践基盤となる。
- 活動 (Activity)
-
アクティビティスペース内で実行される具体的な行為またはタスク。アルファをより進んだ状態へ移行させるために行われ、通常はワークプロダクトの生成や改良を伴う。
- ワークプロダクト (Work Product)
-
アルファの状態を示す証拠として活動によって生成される具体的な成果物。文書・モデル・コードなど、検証可能な出力を含む。
- ビュー (View)
-
Viewとは、Modelを特定のPurposeとConcernに応じて選択し、理解、判断、検証、利用できる形で投影した表現です。ViewはModelの一部を見せるものであり、元のModelとは別に意味を所有しません。
- アルファ (Alpha)
-
ソフトウェア開発の主要側面(例:機会、ステークホルダー、要求、ソフトウェアシステム、チーム、作業、作業のやり方)を表す進行の軸。各アルファは明確に定義された状態を通じて進化していく。
- コンピテンシー (Competency)
-
コンピテンシー(Competency)とは、特定の活動を効果的に遂行するために必要な、役割に対応するスキル、経験、知識水準です。
- 開発メソッド (Development Method)
-
Undefined
- ライフサイクル (Lifecycle)
-
Lifecycleとは、ある対象が生成されてから終了するまでに、Identityを保ちながら通過するStateとTransitionの範囲です。
- 依存 (Dependency)
-
UMLにおけるDependencyは、ClientとなるModel Elementの仕様または実装が、Supplierとなる別のModel Elementの定義へ意味的または構造的に依存することを表すDirected Relationshipです。
- ユースケース (Use Case)
-
UMLにおけるUse Caseは、対象システムがActorまたは他の利害関係者に観測可能な価値あるResultをもたらすために実行するActionの集合を定めるModel Elementです。
- CBD (Component-Based Development)
-
CBD(コンポーネント指向開発)は、ソフトウェアを責務・契約・インターフェースを明確に定義したコンポーネント単位で構築・再利用する開発方式です。 コンポーネントは独立性と交換可能性を備え、システムを疎結合に構成することで保守性と再利用性を高めます。 論理モデルでは機能や契約を定義する抽象構造単位として、物理モデルでは実際の実装・デプロイメント単位として扱われます。
- BDD (Behavior-Driven Development)
-
Behavior Driven Development(BDD, 振る舞い駆動開発)とは、システムの振る舞いをシナリオとして記述し、関係者間で共有可能な形で仕様を明確化する開発アプローチである。
- セキュリティ (Security)
-
Securityとは、情報と機能を正当な権限に従って保護し、不正な閲覧、利用、変更、破壊、否認を防ぐ性質です。Confidentiality、Integrity、Authenticity、AccountabilityなどのConcernを含みます。
- ストーリー (Story)
-
Undefined
- 観測記録 (observation, オブザベーション)
-
対象の現象を捉えて記録した結果。
- コンポーネント (Component)
-
責務・契約・依存関係を明示的に定義し、再利用可能で交換可能な単位としてカプセル化されたソフトウェア構成要素。論理モデルでは抽象構造単位として、物理モデルでは実装・デプロイメント単位として扱われる。
- テスト (Test)
-
Testとは、指定した条件で対象を実行または評価し、観測した結果を期待する結果やConstraintと比較して、要求または契約への適合を確認する活動とその仕様です。
- 操作 (Operation)
-
UMLにおけるOperationは、関連するBehaviorを呼び出すための名前、型、Parameter、Constraintを定めるClassifierのBehavioral Featureです。Operationは呼び出し契約を定め、MethodなどのBehaviorがその実現を担います。
- 責務 (Responsibility)
-
Responsibilityとは、ObjectまたはRoleが、何を知り、判断し、行い、守るべきかを表す義務です。構造上の情報だけでなく、規則とBehaviorの所有を定めます。
- 妥当性確認 (validation)
-
Validation(妥当性確認)とは、システムや機能が利用目的や要求仕様に対して妥当であるかを確認する行為である。
- モデル (Model)
-
Modelとは、対象を特定のPurposeとConcernに基づいて選択し、理解、判断、検証、構築に利用できる形で表した抽象です。対象そのものではなく、目的に必要な要素、関係、意味を保持する表現です。
- 遷移 (Transition)
-
UMLにおけるTransitionは、StateMachine内のSource VertexからTarget Vertexへ進む有向関係です。Trigger、Guard、Effectなどによって、いつ遷移し何を実行するかを定めます。
- Cozy Modeling Language (CML)
-
CML(Cozy Modeling Language)は、オブジェクト・モデルのうち、プログラム生成と実行へ接続する実行可能モデルを記述するSimpleModelingの形式モデリング言語です。