Essence FrameworkによるSimpleModeling Development Processの定義

Created: 2026-04-20

前回の記事では、AI時代のSimpleModeling開発プロセスを、BoK・Cozy・CNCF・SKILLを中心とした実行可能な構造として整理しました。

本稿では、その開発プロセスEssence Frameworkを用いて再定義します。目的は、SimpleModelingを単なる開発手順ではなく、KernelPractice (プラクティス)を組み合わせて構成されるDevelopment Processとして明確化することです。

背景

SimpleModelingは、Unified Process (UP)をベースに、AI時代向けに構成した開発プロセスです。 開発プロセスとは、ソフトウェア開発を進めるための活動 (Activity)、役割、成果物、進行方法を定めた枠組みです。

本稿では、その開発プロセスをEssence Frameworkを用いて定義します。

Essence Frameworkで定義することで、開発プロセスを部品として扱いやすくなります。KernelPracticeを基盤に整理することで、目的や状況に応じて必要な要素を選択し、組み合わせやすくなります。

また、この整理は、SKILL化を見据えたプロセス・モデル化の土台にもなります。ActivityWork Product (ワークプロダクト)、Role、Automationの対応関係を明示することで、人間が読む方法論にとどまらず、AIエージェントが解釈し支援できる構造として記述しやすくなります。

Essenceを基盤にする

Essence Frameworkは、ソフトウェア開発に共通する本質的な概念をKernelとして定義し、その上にPracticeを組み合わせることでMethodを構成するための枠組みです。

SimpleModelingでは、Essenceの考え方を次のように用います。

概念 SimpleModelingでの役割

Kernel

すべてのMethod Viewに共通する基盤。

Alpha

開発中に進化・評価される対象。Opportunity、Stakeholders、Requirementsなど。

Practice

Methodを構成する選択可能な単位。

Activity

Practiceに含まれる抽象的な作業単位。

Work Product

Activityによって作成・更新される成果物。

Competency

Activityを遂行するために必要な能力。

SimpleModelingでは、PracticeをMethod構成の単位とし、Activityを実行単位、SKILLをActivityを支援または自動化する具体的な手順として扱います。

Development ProcessとMethod

SimpleModelingでは、開発メソッド (Development Method)を、Essence Kernelに対して選択されたPracticeの組み合わせとして定義します。

Development MethodDevelopment MethodDevelopment MethodKernelselected Practicesusescombines

Development Processは、この開発メソッドに、Process Flow、成果物、役割、AIエージェント、自動化、ライフサイクル (Lifecycle)を加えたものです。

Development ProcessDevelopment ProcessDevelopment ProcessDevelopment MethodProcess Flow ViewWork Product ViewRole and Agent ViewAutomation ViewLifecycle Viewincludes

SimpleModelingのPractice Group

Practice Groupは、SimpleModelingで導入する分類概念です。Essenceの標準要素ではありません。

Practice Groupは、Practiceを選択しやすくするためのツールボックスです。MethodはPractice Groupを直接合成するのではなく、Practiceを選択して構成します。

現時点では、次のPractice Groupを想定します。

Practice Group 目的

Essence Practice Group

Essenceの参考文献に由来するPracticeを保持する。

Solo Development Practice Group

一人開発に適したPracticeを保持する。

SimpleModeling Practice Group

ツールに依存しないSimpleModelingPracticeを保持する。

SimpleModeling with Cozy Practice Group

CozyシリーズとCNCFを用いたSimpleModelingPracticeを保持する。

Practice Groupは分類であり、所有関係ではありません。必要に応じて、同じPracticeが複数の分類観点から参照される可能性があります。

基準となるMethod View

CozyCNCFを用いた標準的なSimpleModeling Development Processの基点として、次のMethod View (ビュー)を定義します。

SimpleModeling with Cozy Development Method ViewSimpleModeling with Cozy Development Method ViewSimpleModeling with Cozy Development Method ViewKernelselected Practicesusescombines

選択されるPracticeの候補は次の通りです。

このMethod Viewでは、AI支援による一人開発を標準的な運用形態として扱います。そのため、Scrum LiteではなくScrum Solo Practiceを選択します。

また、要求記述にはUse Case Lite Practiceを基準として用います。User Story (ストーリー) Lite Practiceは代替Practiceとして扱います。

Process Flow View

Process Flow Viewは、選択されたPracticeに含まれるActivityを、具体的な開発の流れとして並べたものです。

雛形として、最小の反復サイクルは次のように定義できます。

  1. 開発環境を準備する。

  2. ビジネス背景と目的を整理する。

  3. Use Case Liteで要求を記述する。

  4. ユースケースをスライスに分解する。

  5. BDDで受け入れ条件を具体化する。

  6. ドメインモデルとコンポーネント構造を定義する。

  7. コード・テスト・文書を生成する。

  8. CI/CDパイプラインで検証する。

  9. 運用・観測・セキュリティの観点で改善する。

この流れは固定的なウォーターフォールではありません。各Activityは反復的に戻り、成果物を更新しながら進みます。

Practice・Activity・SKILL

SimpleModelingでは、EssenceのPracticeActivityを、AI時代の実行単位へ接続するためにSKILLを導入します。

Practice to SKILL MappingPractice to SKILL MappingPracticeActivitySKILL

PracticeはMethodを構成する抽象的な単位です。ActivityPracticeの中で実行される作業です。SKILLはActivityを人間またはAIエージェントが実行するための具体的な手順です。

すべてのActivityが完全にSKILL化できるわけではありません。判断・対話・意思決定を多く含むActivityは、人間が主体となり、AIが支援する形になります。

Work Product View

Work Product Viewでは、Activityによって作成・更新される成果物を定義します。

代表的なWork Productは次の通りです。

これらの成果物は、単なる文書ではなく、AIエージェントが読み取り、更新し、次のActivityの入力として利用できる構造を持つ必要があります。CNCF上で実行されるコンポーネントも、この成果物体系の一部として扱います。

Role and Agent View

AI時代のSimpleModelingでは、役割は人間だけに割り当てられるものではありません。AIエージェントも、Activityを実行または支援する主体として扱います。

雛形として、次の役割を定義できます。

役割 責務

Product Owner

目的、価値、優先順位を判断する。

Solo Developer

設計・実装・検証・運用を横断的に担う。

Modeling Agent

要求、BoK、ドメインモデルの作成を支援する。

Generation Agent

モデルからコード、テスト、文書を生成する。

Review Agent

整合性、品質、セキュリティ観点の確認を支援する。

Automation View

Automation Viewでは、どのActivityをSKILLやツールで支援・自動化するかを定義します。

初期段階では、手動で行うPracticeと、SKILLで自動化できるPracticeを併用します。

自動化の対象は、次のように段階的に広げます。

  1. チェックリストとレビュー支援。

  2. モデル (Model)テスト、文書の生成。

  3. CI/CDと品質ゲートの実行。

  4. 運用観測と改善提案。

Lifecycle View

Lifecycle Viewでは、Development Processを時間軸上でどのように進めるかを定義します。

SimpleModelingでは、Unified Processのフェーズ構造を参考にしつつ、AI支援の反復開発に適した軽量なライフサイクルとして扱います。

フェーズ 焦点

Inception

目的、ステークホルダー、主要ユースケースを明確にする。

Elaboration

アーキテクチャ、ドメインモデル、主要リスクを固める。

Construction

スライス単位で機能を生成・検証・統合する。

Transition

リリース、運用、観測、改善を行う。

今後の検討事項

本稿は雛形であり、今後次の点を具体化します。

まとめ

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の形式モデリング言語です。