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を基盤にする
Development ProcessとMethod
SimpleModelingでは、開発メソッド (Development Method)を、Essence Kernelに対して選択されたPracticeの組み合わせとして定義します。
Development Processは、この開発メソッドに、Process Flow、成果物、役割、AIエージェント、自動化、ライフサイクルを加えたものです。
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 |
基準となるMethod View
CozyとCNCFを用いた標準的なSimpleModeling Development Processの基点として、次のMethod Viewを定義します。
選択されるPracticeの候補は次の通りです。
-
Use Case Lite Practice
-
Scrum Solo Practice
-
Business Modeling Solo Practice
-
Cloud Native CBD (Component-Based Development) Practice
-
BDD (Behavior-Driven Development) with Use-Case Lite Practice
-
Cozy Environment Setup Practice
-
User Environment Lite Practice
-
CI/CD Pipeline Practice
-
DevOps Practice
-
Security Practice
このMethod Viewでは、AI支援による一人開発を標準的な運用形態として扱います。そのため、Scrum LiteではなくScrum Solo Practiceを選択します。
Process Flow View
雛形として、最小の反復サイクルは次のように定義できます。
-
開発環境を準備する。
-
ビジネス背景と目的を整理する。
-
Use Case Liteで要求を記述する。
-
ユースケースをスライスに分解する。
-
BDDで受け入れ条件を具体化する。
-
ドメインモデルとコンポーネント構造を定義する。
-
コード・テスト・文書を生成する。
-
CI/CDパイプラインで検証する。
-
運用・観測・セキュリティの観点で改善する。
この流れは固定的なウォーターフォールではありません。各Activityは反復的に戻り、成果物を更新しながら進みます。
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 |
スライス単位で機能を生成・検証・統合する。 |
|
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による支援、自動化、意思決定支援を可能にするための基盤です。
- Cloud Native Component Framework (CNCF)
-
Cloud Native Component Framework（CNCF）は、クラウド・アプリケーションを構成するコンポーネントを、単一かつ一貫した実行モデルで実行するためのフレームワークです。 Component / Service / Operation という構造を中核とし、command、server（REST / OpenAPI）、client、script といった異なる実行形態から、同一の Operation を再利用できることを特徴とします。 ログ、エラー処理、設定、配備といったクラウド・アプリケーションに必要な品質属性をフレームワーク側に集約することで、コンポーネントはドメイン・ロジックの実装に集中できます。 CNCF は、文芸モデル駆動開発および AI 支援開発を前提に、「何を実行するか」と「どのように呼び出すか」を分離するための実行基盤として設計されています。
- カーネル (Kernel)
-
任意のソフトウェア開発活動を定義・理解するために必要最小限の概念を含むEssenceの中核要素群。アルファ、アクティビティスペース、能力などで構成される。
- 開発プロセス (Development Process)
-
開発プロセスとは、ソフトウェアの構築・運用・保守に関わる活動全体を指します。 計画、設計、実装、テスト、リリースなどを含み、ソフトウェア開発の一連の流れを体系的に表現する概念です。
- プラクティス (Practice)
-
ソフトウェア開発の特定の側面をどのように扱うかを定義した再利用可能なメソッド断片。複数のプラクティスを組み合わせてメソッドを構成できる。
- UP (Unified Process)
-
UMLを基盤とし、反復型・ユースケース駆動・アーキテクチャ中心のプロセスモデル。Rational Unified Process (RUP) などの派生形を持ち、CBD（コンポーネント指向開発）の実践基盤となる。
- 活動 (Activity)
-
アクティビティスペース内で実行される具体的な行為またはタスク。アルファをより進んだ状態へ移行させるために行われ、通常はワークプロダクトの生成や改良を伴う。
- ワークプロダクト (Work Product)
-
アルファの状態を示す証拠として活動によって生成される具体的な成果物。文書・モデル・コードなど、検証可能な出力を含む。
- アルファ (Alpha)
-
ソフトウェア開発の主要側面（例：機会、ステークホルダー、要求、ソフトウェアシステム、チーム、作業、作業のやり方）を表す進行の軸。各アルファは明確に定義された状態を通じて進化していく。
- 能力 (Competency)
-
特定の活動を効果的に遂行するために必要な人的能力。役割に関連するスキル、経験、知識水準を定義する。
- 開発メソッド (Development Method)
-
開発メソッドとは、ソフトウェアの構造と意味を定義するためのモデルとモデル変換から構成される概念的な枠組みです。 オブジェクト指向設計、ドメイン駆動設計（DDD）、モデル駆動開発（MDD）などが代表的な例です。 開発メソッドは、ソフトウェア開発の「何を」「どのように構造化して」作るかを定義する設計的基盤を提供します。
- CBD (Component-Based Development)
-
CBD（コンポーネント指向開発）は、ソフトウェアを責務・契約・インターフェースを明確に定義したコンポーネント単位で構築・再利用する開発方式です。 コンポーネントは独立性と交換可能性を備え、システムを疎結合に構成することで保守性と再利用性を高めます。 論理モデルでは機能や契約を定義する抽象構造単位として、物理モデルでは実際の実装・デプロイメント単位として扱われます。
- BDD (Behavior-Driven Development)
-
Behavior Driven Development(BDD, 振る舞い駆動開発)とは、システムの振る舞いをシナリオとして記述し、関係者間で共有可能な形で仕様を明確化する開発アプローチである。
- 観測記録 (observation, オブザベーション)
-
Observationは、Phenomenon(現象)の中から記録に値すると判断されたものを保存した記録です。 観測記録はログ、モニタリング、監査、トラブルシューティングの基盤となります。
- コンポーネント (Component)
-
責務・契約・依存関係を明示的に定義し、再利用可能で交換可能な単位としてカプセル化されたソフトウェア構成要素。論理モデルでは抽象構造単位として、物理モデルでは実装・デプロイメント単位として扱われる。
- 妥当性確認 (validation)
-
Validation(妥当性確認)とは、システムや機能が利用目的や要求仕様に対して妥当であるかを確認する行為である。
- CML (Cozy Modeling Language)
-
CMLは、Cozyモデルを記述するための文芸モデル記述言語です。 SimpleModelingにおける分析モデルの中核を担うDSL（ドメイン固有言語）として設計されています。 モデル要素とその関係性を自然言語に近い文体で記述できるよう工夫されており、AIによる支援や自動生成との高い親和性を備えています。 CMLで記述された文芸モデルは、設計モデル、プログラムコード、技術文書などに変換可能な中間表現として機能します。