AI時代のSimpleModeling開発プロセス

従来プロセスの問題

従来の開発プロセスでは、要求、設計、実装、テストといった工程が定義されているものの、それらは主に人間が解釈し実行する前提で設計されています。

このため、プロセスは仕様書やガイドラインとして存在する一方で、実行そのものはコードや個々の判断に委ねられる構造になります。

その結果、プロセスは存在するが実行されない、あるいは実装と乖離するという問題が発生します。

AI時代においては、開発プロセスそのものがAIによって実行される、あるいはAI支援によって進行することが前提となります。

この前提の変化により、従来のように人間の解釈に依存したプロセスでは不十分となり、プロセスはAIが理解し、実行できる形式で定義される必要があります。

Essenceの位置づけ

SimpleModelingでは、開発プロセスを明確に定義するための基盤として、Essence Frameworkを採用します。

Essence Frameworkは、ソフトウェア開発におけるプロセスを、共通の概念体系によって記述するための理論的枠組みです。

Essenceは以下の要素で構成されます：

これらの要素により、開発プロセスは個別の手法に依存せず、構造として定義可能になります。

SimpleModelingでは、このEssenceの枠組みを用いて、UP (Unified Process)（Unified Process）やCBD (Component-Based Development)（Component-Based Development）といった具体的な方法論を整理し、一貫したプロセスモデルとして統合します。

ただし、Essence自体はプロセスを記述するための枠組みであり、それ自体が実行されるものではありません。

そのため、定義されたプロセスをどのように実行するかという観点が別途必要になります。

AI時代におけるUPとCBD

AI時代におけるUP（Unified Process）の再解釈については、📄 AI時代におけるUnified Processの再解釈で議論しました。本記事では、その要点のみに絞ります。

UPは、反復・漸進とユースケース駆動により、開発を実行単位（スライス）で進めるプロセス骨格を提供します。

CBD（Component-Based Development）は、システムをコンポーネント (Component)として構成し、境界と構造によって品質を担保します。

SimpleModelingでは、この構造をCML (Cozy Modeling Language)（Conceptual Modeling Language）によって記述し、CozyによってCNCF上で動作するプログラムへと変換します。

さらに、このCBDの構造はCNCF（Cloud-Native Component Framework）によって実行基盤上に実現され、コンポーネントの境界が実行時にも一貫して維持されます。

これにより、UPによるプロセス、CBDによる構造、CMLによる記述、Cozyによる生成、CNCFによる実行が統合され、実行可能な開発プロセスとして成立します。

記述から実行へ

従来の開発プロセスは、仕様やモデルとして「記述」されるものであり、それ自体が直接実行されることはありませんでした。実行はあくまでプログラムに委ねられ、プロセスと実装の間には明確な断絶が存在していました。

SimpleModelingでは、この関係を再構成し、開発プロセスを実行可能な構造として扱います。すなわち、プロセスは単なる記述ではなく、実行の対象となります。

この変換により、従来はプログラムのみが担っていた実行対象が拡張されます。まず、CBDにより定義されたコンポーネントはCNCF上でそのまま動作します。これは従来技術の延長線上にあるものです。

さらに、AI時代においては、ユースケース自体が実行可能な単位として扱われるようになります。アプリケーションはコンポーネントだけでなく、ユースケースのレベルでも動作する構造となります。

そして最終的に、開発プロセスそのものも実行対象へと拡張されます。これにより、システム・ユースケース・開発プロセスのすべてが、統一的に実行可能な対象として扱われるようになります。

SimpleModelingの中核構造

SimpleModelingでは、記述されたプロセスとモデルを実行可能にするために、BoK・Cozy・CNCF・SKILLの4つの要素が統合されたアーキテクチャを採用します。

それぞれの役割は次の通りです：

BoK：文芸モデル (literate model)として知識と要求を記述する
Cozy：BoKをCMLに変換し、実行可能なプログラムを生成する
CNCF：生成されたコンポーネントを実行し、システムとして動作させる
SKILL：開発プロセスを実行可能な形で定義し、実行を制御する

このアーキテクチャにより、記述（BoK）・生成（Cozy）・実行（CNCF）・プロセス（SKILL）が一貫した構造として接続されます。

これにより、前節で述べた「記述から実行への変換」が具体的なシステムとして実現されます。

ユースケース実行モデル

SimpleModelingにおいて、ユースケースは単なる要求記述ではなく、実行の単位として扱われます。これは生成AIの登場によって初めて実現可能になった新しい領域です。

従来の開発では、ユースケースは設計や実装のための入力にとどまり、直接実行されることはありませんでした。本モデルでは、AIの解釈能力を前提として、ユースケースそのものがシステムの振る舞いを直接表現し、実行対象となります。

これにより、アプリケーションはコンポーネントの集合としてだけでなく、ユースケースの集合としても動作する構造を持ちます。

この構造は、前節で示した「実行対象の拡張」を具体化したものであり、コンポーネントに加えてユースケースが実行可能な対象として位置づけられます。

ユースケースは、その内部で定義された操作や状態遷移を通じてシステムの振る舞いを構成し、実行時にはこれらが一貫した単位として扱われます。

SKILL：プロセス実行メカニズム

前節までで示したように、SimpleModelingではユースケースが実行単位として扱われます。さらに一歩進めて、SKILLは開発プロセスそのものを実行可能にする仕組みであり、これもまたAIの登場によって成立した新しい領域です。

SKILLは、この実行方式を担う要素であり、ユースケースを実行可能な形へと変換し、その実行を制御します。

具体的には、ユースケースはSKILLによって解釈され、システム上で実行可能な操作（Action）の集合へと変換されます。

これらの操作は、CNCF上で実行されることにより、ユースケースで記述された振る舞いが実際のシステムとして動作します。

さらに、SKILLはユースケースの実行だけでなく、開発プロセスそのものの実行も担います。これにより、ユースケースの実行と開発プロセスの実行が同一の仕組みで扱われるようになります。

この構造により、SimpleModelingではプロセス・ユースケース・システムのすべてが一貫して実行可能な対象として統合されます。これは従来のソフトウェア開発には存在しなかった、AI時代特有の実行モデルです。

まとめ

本稿では、AI時代における開発プロセスの再構成として、SimpleModelingの開発プロセスを提示しました。

従来の開発プロセスは記述として存在し、実行はプログラムに委ねられていましたが、SimpleModelingではプロセス自体が実行可能な構造として扱われます。

この変換により、実行対象はコンポーネントからユースケース、そして開発プロセスへと段階的に拡張されます。特に、ユースケースおよび開発プロセスの実行は、生成AIの登場によって初めて成立した新しい領域です。

また、BoK・Cozy・CNCF・SKILLの統合により、記述・生成・実行・プロセスが一貫した構造として接続されます。

これは単なる開発手法ではなく、AIが直接扱うことのできる実行モデルであり、今後のソフトウェア開発の基本構造になるかもしれません。

参照

サイト内

📄 AI時代におけるUnified 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 支援開発を前提に、「何を実行するか」と「どのように呼び出すか」を分離するための実行基盤として設計されています。
作業体系 (Way of Working): チームが作業を組織化し遂行するために用いるプラクティスと規範の体系。チームの学習や適応に伴って進化する。
開発プロセス (Development Process): 開発プロセスとは、ソフトウェアの構築・運用・保守に関わる活動全体を指します。計画、設計、実装、テスト、リリースなどを含み、ソフトウェア開発の一連の流れを体系的に表現する概念です。
アルファ (Alpha): ソフトウェア開発の主要側面（例：機会、ステークホルダー、要求、ソフトウェアシステム、チーム、作業、作業のやり方）を表す進行の軸。各アルファは明確に定義された状態を通じて進化していく。
活動 (Activity): アクティビティスペース内で実行される具体的な行為またはタスク。アルファをより進んだ状態へ移行させるために行われ、通常はワークプロダクトの生成や改良を伴う。
ワークプロダクト (Work Product): アルファの状態を示す証拠として活動によって生成される具体的な成果物。文書・モデル・コードなど、検証可能な出力を含む。
能力 (Competency): 特定の活動を効果的に遂行するために必要な人的能力。役割に関連するスキル、経験、知識水準を定義する。
プラクティス (Practice): ソフトウェア開発の特定の側面をどのように扱うかを定義した再利用可能なメソッド断片。複数のプラクティスを組み合わせてメソッドを構成できる。
UP (Unified Process): UMLを基盤とし、反復型・ユースケース駆動・アーキテクチャ中心のプロセスモデル。Rational Unified Process (RUP) などの派生形を持ち、CBD（コンポーネント指向開発）の実践基盤となる。
CBD (Component-Based Development): CBD（コンポーネント指向開発）は、ソフトウェアを責務・契約・インターフェースを明確に定義したコンポーネント単位で構築・再利用する開発方式です。コンポーネントは独立性と交換可能性を備え、システムを疎結合に構成することで保守性と再利用性を高めます。論理モデルでは機能や契約を定義する抽象構造単位として、物理モデルでは実際の実装・デプロイメント単位として扱われます。
コンポーネント (Component): 責務・契約・依存関係を明示的に定義し、再利用可能で交換可能な単位としてカプセル化されたソフトウェア構成要素。論理モデルでは抽象構造単位として、物理モデルでは実装・デプロイメント単位として扱われる。
CML (Cozy Modeling Language): CMLは、Cozyモデルを記述するための文芸モデル記述言語です。 SimpleModelingにおける分析モデルの中核を担うDSL（ドメイン固有言語）として設計されています。モデル要素とその関係性を自然言語に近い文体で記述できるよう工夫されており、AIによる支援や自動生成との高い親和性を備えています。 CMLで記述された文芸モデルは、設計モデル、プログラムコード、技術文書などに変換可能な中間表現として機能します。
文芸モデル (literate model): 文芸モデル（Literate Model）は、モデル構造と自然言語による語り（構造化文書）を統合した「読めるモデル」です。文芸的プログラミング（Literate Programming）の思想をモデリング領域に拡張し、構造（モデル）＋語り（構造化文書）を一体化することで、人間とAIの双方が理解・操作できる知識表現を実現します。「Literate Modeling（文芸的モデリング）」という発想自体は、これまでにも一部の研究者や開発者によって試みられてきました。しかし、それらは主にドキュメント生成やコード理解の支援にとどまっており、モデルと言語・語り・AI支援を統合した体系的なモデリング手法として確立されたものではありません。文芸モデル（Literate Model）は、SimpleModelingがAI時代に向けて新たに体系化・提唱したモデリング概念です。文芸的モデリングの思想を継承しつつ、 AI協調型の知識循環とモデル生成を可能にする知的モデリング基盤として再構成されています。文芸モデルは、単なるモデル記述技法ではなく、人間の思考過程や設計意図を語りとしてモデルに埋め込み、 AIがそれを解析・再構成して設計や生成を支援するための枠組みです。