なぜソフトウェア開発方法論を再構築するのか

第1回の全体像: Domain Modelを実装へ接続されたworking abstractionとして扱います。

ソフトウェア開発の歴史は、抽象化の歴史として捉えることができます。

抽象化が進むたびに、人間が担当する仕事は上位へ移ってきました。機械語を直接並べる代わりに、高級言語で型や関数を記述します。共通処理を毎回実装する代わりに、ライブラリを利用します。アプリケーション全体の制御を一から組み立てる代わりに、フレームワークが提供する構造の中に固有の処理を配置します。

この変化は、人間が細部を考えなくなったということではありません。細部を安定して扱う仕組みが生まれたことで、人間がより上位の問題に集中できるようになったということです。

ドメインモデルは以前から存在していました。しかし、多くの場合、それは実装とは直接結び付かない、問題領域に対するViewでした。Javaなどのオブジェクト指向言語、設計規約、コード生成によってドメインモデルと実装を対応させる試みは行われてきましたが、その変換の多くは人間に依存し、モデルと実装の間には大きな乖離が残っていました。

AIの登場によって、ドメインモデルは、人間が主に扱う新しいworking abstractionになりました。ここでworking abstractionとは、実装への実現経路を持ち、開発を実際に前へ進められる抽象という意味です。AIはドメインモデルを解釈して実装へ変換し、実装に必要な詳細を補完します。さらにTextusが実行基盤を提供することで、ドメインモデルから実行可能ソフトウェアへ至る経路を構成できます。これにより、ドメインモデルは、実装から切り離された分析資料ではなく、実装に接続されたソフトウェア開発上の抽象として機能します。

成功した抽象化には、常に下位層へ到達するための信頼できる実現手段があります。

高級言語は、機械語を不要にしたわけではありません。コンパイラが高級言語を機械語へ変換するため、人間が機械語を直接記述する必要がなくなりました。フレームワークも、実行処理を消したわけではありません。ランタイムが共通の制御を引き受けることで、開発者はアプリケーション固有の問題に集中できます。

したがって、抽象化は、抽象的な表現を作るだけでは成立しません。その表現から実行可能なソフトウェアへ到達する経路が必要です。抽象化と実現は、ソフトウェア工学を支える一組の仕組みです。

SimpleModelingでは、ドメインモデルを問題領域に対するViewであり、人間が主に扱うworking abstractionとして位置付けます。AIはドメインモデルを実装へ変換し、必要な実装詳細を補完します。Textusは、その結果得られるソフトウェアの実行基盤を提供します。この組み合わせによって、ドメインモデルから実装と実行へ至る経路を構成します。

AIは、プログラムの生成、修正、テスト、リファクタリングなどを支援し、実装作業の多くを担えるようになりつつあります。

しかし、これはプログラミングそのものが消えることを意味しません。生成されたソフトウェアは、最終的にはプログラミング言語、ライブラリ、フレームワーク、ランタイムによって構成され、実行されます。変わるのは、プログラミングの存在ではなく、人間がその作業へ関与する位置です。

AIへ実装を依頼する場合、人間は、何を作るのか、どの制約を守るのか、どの責務をどこへ置くのか、何を正しい結果とするのかを示す必要があります。コードの各行を直接指定する代わりに、実装の前提となる意味と構造を与える仕事が重要になります。

このときAIは、ドメインモデルから実装への変換と、実装に必要な詳細の補完を担います。この働きによって、ドメインモデルが実装へ接続されます。

この意味と構造を表現する活動 (Activity)がモデリングです。

ここでいうソフトウェアモデリングは、図を描くことだけではありません。問題領域をどのように捉えるか、ソフトウェアの各要素がどの責務を持つか、処理がどのように進むか、知識をどのように構造化するかを、異なるViewから明確にすることです。ドメインモデルは、このうち問題領域に対するViewです。

人間の中心的な仕事がプログラミングからモデリングへ移るというのは、人間がコードを一切書かなくなるという意味ではありません。開発全体を成立させるために、人間が直接設計すべき主対象が、コードの記述からモデルの構成へ移るという意味です。

AIが実装を高速化すると、モデルの曖昧さや矛盾も高速に実装へ伝わります。構造が不明確であれば、AIは局所的には動くコードを生成できても、システム全体の責務や整合性を安定して保つことができません。

一方で、目的、用語、責務、境界、実行規則が明確かつ一貫してモデル化されていれば、AIはその構造を解釈し、実装、検証、修正を進めやすくなります。ただし、明確性と一貫性は、モデルが現実の業務や要求に対して妥当で正確であることを意味しません。AIは、明確に記述された誤ったモデルも忠実に実装します。

そのため、ソフトウェアの品質は、モデル化の品質にこれまで以上に強く依存します。

モデリングがソフトウェア開発の新しいチョークポイントになります。

これは、単にモデリングが重要になるという主張ではありません。AIによって実装能力が広く利用可能になるほど、開発結果の差を生む場所が、実装量から、何をどのようにモデル化するかへ移るということです。

SimpleModelingでは、モデルの正確性は一度に確定できるものではないと考えます。用語集、ユースケース、BoK (Body of Knowledge)、ドメインモデルのメタモデルを共通基盤として、ドメインエキスパート、開発者、AIが協業し、反復的にドメインモデルの精度を高める仕組みを用意します。

三者は、この共通知識を基にドメインモデルを構成し、ユースケースによって業務上の妥当性を確認します。発見した不足や矛盾をBoK、用語、制約、モデルへ反映し、AIが実装を更新します。このサイクルを繰り返すことで、モデルと実装の精度を高めます。

ドメインエキスパートは業務知識とモデルの妥当性を確認し、開発者はモデルの構造、制約、実現可能性を確認します。AIはBoKを参照し、知識の整理、矛盾や不足の発見、モデル化を支援します。AIが単独で正しいモデルを生成するのではなく、3者の協業と反復によってモデルを継続的に改善します。

既存のソフトウェア工学には、オブジェクト指向、デザインパターン、ドメイン駆動設計、CQRS、知識グラフ (knowledge graph)など、多くの有用な技術があります。AIによって、これらの価値が失われるわけではありません。

ただし、人間が直接扱う抽象化レベルが変われば、個別技術の位置付けと使い方を改めて整理する必要があります。技術を一覧にした知識体系だけでは、どの技術を選び、どの設計判断を固定し、どのような順序で開発するかを決められません。

必要なのは、既存技術をモデリングという軸から選択し、相互の役割を定め、抽象から実行可能ソフトウェアへ到達する開発方法として統合することです。これが、ソフトウェア開発方法論を再構築する理由です。

SimpleModelingは、AI時代に新しく現れた個別技術を集めることを目的としません。既存のソフトウェア工学知識をモデリング中心の視点から選択し、具体的なソフトウェア開発方法論として構成します。

Literate Model-Driven Cloud-Native Development with Object-Functional Paradigms for the AI Era

SimpleModeling.orgでは、このキャッチフレーズのもと、文芸モデル駆動、クラウド・ネイティブ、オブジェクト関数パラダイムの三つを方法論の軸とします。

また、モデルを作ること自体を最終目的にはしません。ソフトウェア工学に必要なのは、抽象化と、その抽象を実行可能ソフトウェアへつなぐ実現経路の両方です。シリーズ全体を通して、SimpleModelingがこの経路をどのように構成するかを説明します。

SimpleModelingのモデル中心という方向性は、AIの登場によって始まったものではありません。CML (Cozy Modeling Language)、DSL (Domain Specific Language)、Literate Modeling、実行可能モデルを通して、以前からModelからExecutable Softwareへの経路を追求してきました。

次回は「SimpleModelingが目指してきたもの」として、その歴史的な連続性と、AIがKnowledgeからModelへの変換をどのように補完するのかを説明します。