はじめに

さて、第一回目は、こんなタイトルで始めます。
はい、そうです、すいません。タイトルは 、あの有名な”Do Androids Dream of Electric Sheep?”のパクリです、ごめんなさい。
それにしても…ブレードランナーの第一作目は衝撃的だったなぁ…
そして、今時の流行りにちゃっかり乗っちゃってます、はい。

これから書く内容は、2023/4/22 に、ソフト開発軽量化技術検討会で行ったライトニングトークで話した内容を元に最近思っている事をまとめたものです。当日使った資料は、Slideshare から公開しているので興味のある人はご参照ください。

お題の背景

「0. マガジンをはじめるにあたり」でも書いていますが、IT システム開発の基盤となる（はずの）現実世界をデータ化し概念モデル化するのって重要だよね…という事で、30年来継続して体験を通じて獲得してきた知識（Knowledge & Experience ねw）を元に、「Art of Conceptual Modeling」で教本的に概念モデリングの基本をまとめて公開しているわけです。
そして、1990年半ばに「Art of Conceptual Modeling」のベースになっている Shlaer-Mellor 法（現在は eXecutable & Translatable UML）を実践レベルで使いこなせるようになった時点から30年近くこの技法に関する啓蒙活動を、陰に日向に継続してきました。
気がつけば、2020年代は Digital Transformation とか Digital Twins の実現・実践が至上命題化している時代です。DX、DT と言わないまでも、旧来のリレーショナルデータベースを活用する IT システムを構築する時でさえ、IT システムとして実現したい現実世界の側面をデジタル化するには現実世界の様々なモノ・コト・役割といった概念群をデータ化し、組織化する、つまり概念のモデリングは必須なはずで、「Art of Conceptual Modeling」に類するモデリング技法は、もっと脚光を浴びて、みんなが競って習得に走ってもいいはずなんですが、そんな兆しは残念ながらありません。Deep Learning の台頭から始まった AI ブームでさえ、学習の為には大量のデータ群が必要で、そのデータ群は当然何らかの形でモデル化されたものであるはずで、学習対象のデータ群だけでなく、出来上がった AI を活用する側でも当然活用の為の概念群を整理した概念モデルが必要なのは間違いないでしょう。

流行らないのはなんでだろう？…
「Technique of Transformation」で解説している自動生成技術も含め、Shlaer-Mellor 法系のモデリング技法を実践レベルで使いこなせるのは、日本では、ほぼ、1990年代後半からともに活動している好きモノ達とそのごく少数の周辺の人達だけです。
一番大きな理由は、ソフトウェア開発に関する実装技法がものすごく進化をし続けていて、やれ、概念モデリングだの、アーキテクチャだの、設計技法だの、うるさいことは言わなくても、なんとなく適当にだらだらとプログラミング的な行為をしていると、ある程度運用でカバー可能なレベルの品質・性能のソフトウェアが出来てしまう…というソフトウェア開発の特性にあるのでしょうけれど。
そんな思いを抱きつつ、改めて、「Art of Conceptual Modeling」を眺めると、

• ドメイン？　…難しいよね…

• データの観点で？　…小難しいよね…

• イベント駆動的な考え方？　…めんどくさいよね…

• データフロー的な考え方？　…何それ？…

というのが、一般的なソフトウェア技術屋さん達の素直な感想なのかもしれません。むしろ、ソフト屋さんよりも、ビジネスプランナーとかの方が理解が早いのでは？なんても思う次第。

基本を正しく理解して、パターンを覚えればそんなに難しくはないんですけどね。。。

翻って、自分の習得過程を振り返ってみて、また、習得している同年代の人達のことを思い出してみると、その人たちは誰かが育てようと思って育てられたのではなく、勝手に育った人達なのでした。つまり、そもそも、育てようと思って育てられるものではなく、各自のモチベーションによって育つものなんだという事です。
つまりは、先達にできる事は誰かが育つために必要な肥料を供給する事だけだと…
じゃぁ粛々とドキュメント作成していくか…

しかし、リレーショナルデータベースを使う場合も含め、Digital Twins を実践するには、やはり、概念モデルが必要なのは間違いなく、のんびりと、実践できる人がいつか育って現れるまで待つなんて悠長なことは言っていられない時代に今はなっているというのが私の今の見解。
まぁ1案件2000万円ぐらいで概念モデルの作成、私が請け負ってもいいんだけどね（何様だ私？w）

Chat GPT（Open AI）の可能性

で、漸く本題です。今流行りの Open AI 系の Chat GPT を斜め右上くらいから眺めつつ、こんなことを思いました。

”これ活用したら、概念モデルを自動生成できるんじゃね？”

沢山の記事、様々な場所で、Chat GPT が会話的な文面を理解して質問に答えてくれたり、サンプルコードを生成してくれることが喧伝されているじゃないですか。実際に使ってみると、明らかに

「生成された回答が正しいかどうかは置いておいて、こいつ、入力した文面のコンテキストをある程度理解（理解っておかしいかな）してるっぽい」

コンテキストを理解するのは、概念モデリングの”ドメイン定義”と”概念情報モデル作成”に相通じるものなので、うまくカスタマイズ？トレーニング？か何かをすれば、ビジネスに関わるシナリオや文書、絵、図面を入力すると、”概念モデル”を自動生成してくれるんじゃないかと思った次第。”モデル”というと絵に描かれた図面を思い浮かべる人もいるかと思いますが、「Technique of Transformation」で解説している通り、SQL 文法ライクな SYNTAX で概念モデルを記述する事は可能であり、つまり、テキストで概念モデルを記述できる、イコール、少なくとも AI が概念モデルを記述したテキストを生成すればよろしい。Azure Digital Twins の場合は DTDL のテキストを生成すればよろし、ってことですね。

あれこれ考えると、概念モデルが実践レベルで使いこなせる人を育てるより、概念モデル自動生成 AI を開発したほうが、世の為、私の為ではないかと思った次第

先ずは、無料の Chat GPT に聞いてみた

無料で使える Chat GPT がいきなりテキストや絵から概念モデルを生成できることはありえず、きっと、そのベースになっている Open AI をトレーニングすることになるんだろうなと思いながら、概念モデルからの自動生成について Chat GPT に対して見解を聞いてみることにした次第。

以下、実際の私と Chat GPT と私のやり取りを、解説を加えながら、紹介していく事にします。

昨年公開した”Art of Conceptual Modeling” の内容が Chat GPT の学習に反映されている筈がないので、とりあえずは、そのベースとなっている Shlaer-Mellor 法について、Chat GPT がどの程度の回答を出すか質問してみました。うんうん、最後のセンテンスがちょっと気になるが、まぁまぁの回答ですね。
早速、自動生成の可否について質問してみました。

なるほど。ある程度予想していた回答が出てきました。ここからオジサンどんどん突っ込んでいきます。

”大量の正解データ” という回答に曖昧性を感じたので、そこを確認したわけです。ほぼ鸚鵡返し的な感じで、

”正解データ” ＝ ”クラスとリレーションシップ”

が確認されたわけです。しかし、”Art of Conceptual Modeling” の ”ドメインと IT システム構築” で解説している様に、Shlaer-Mellor 法には ”ドメイン” という考え方があって、例え同じビジネスシナリオを元にモデリングを行っても、ソフトウェア構築に必要な様々な ”ドメイン” の観点毎に、それぞれ全く異なるクラス群とリレーションシップ群が抽出されることになります。
そうすると、「正解のクラスとリレーションシップって何？ 」という事になるわけです。そこを聞くと、なんというか、私の質問を再構成したような、微妙な回答が来ています。

まぁ…そんなレベルだろう…

どのぐらいのデータセットが必要なのかを具体的な数字を挙げつつ試しに聞いてみたら、こんな回答。

Chat GPT の回答の 3番目、4番目の回答が私の琴線に触れてしまったので、どんどん突っ込んでいきます。

Chat GPT が、「古い開発手法だから現代では役立たない」的な回答を生成したので、おいおい、待てよと。
”Art of Conceptual Modeling” で解説している”概念情報モデル”は、Shlaer-Mellor 法の”オブジェクト情報モデル” をほぼそのまま採用しています。
Shlaer-Mellor 法自体は、1980年代後半から1990年初頭にかけて確立された開発手法で、提唱された時から既に30年以上経っていて、変化の速いソフトウェア開発技術から見れば確かに古いんだけど。
この記法は、リレーショナルデータベースの数学的基礎になっている、リレーショナルセオリーをベースに定義されたものです。
例えば、数学の微分積分の記法は、17世紀から18世紀にライプニッツによって確立されたもので、200年以上前のものですよね。だからと言って、微分積分を古い算法という人はいませんよね。
なので、古い開発手法だから現代では役立たない」的な考え方は間違っているんじゃないの？ってことです。実際、私の経験上では、現実世界のほとんどの主題領域は、概念情報モデル化が可能で、データモデルの記述力と記法のシンプルさ厳密さにおいては、代替できるモデリング技法はない、というのが現時点での私の結論。
で、そこを突っ込んだわけですが、Chat GPT さんも、微妙に私に気を使いながらも果敢に私に反論してきます。

ここで私が気になったのは、

の2センテンス。「いやいやいや…いうほど”多くの開発者や企業によって”は使われてないよ。欧米は知らんけど特に日本は」というは脇に置き、なんというか、”開発手法”と実際に使える”実装技術”が混同されているなと。

”Art of Conceptual Modeling” と ”Technique of Transformation” で詳しく解説している様に、Shlaer-Mellor 法は、モデリングだけでなく、作成したモデルから、ソフトウェアへの非機能要件に合致するソフトウェア一式を自動生成する為の技術体系も併せ持っています。今の名称が、”eXecutable & Translatable UML” であるのもこれに由来しています。
この観点からすると、Chat GPT が挙げてきた4つはどれも、Shlaer-Mellor 法の技術体系とは直接比較が不可能なものばかり。

なので、

それぞれ4つについて、反論したわけです。その回答からするに、やはり、Chat GPT が想定している”開発手法”と、私が考えている”開発手法”の意味が違うと推察。
で、ちょっとした変化球を投げてみる

ふーむ。やはり違う。つーか、幾つかは既に「それ開発手法じゃねーしって言ってるよね」的なものもあって、私はちょっとイラついていたりします（苦笑）
概念モデリングをやっていると、言葉の定義がすごく気になる人になってしまうという副作用があり、じゃぁ”従来の開発手法”って何なのよという感じもあるけれど、一通り、「それって所謂”開発手法”ではないよね」と反論しつつ、更に”現代的な手法”なるものを聞いてみた。

駄目だこりゃ。。。とばっさり切り捨てても良いのですが…
”デボッポス”＝”DevOps” ね、あと、”コンテナ化”については、それらの基本概念と、それを実践するための仕組み・道具は分けて考えた方が良くて、例えば、コンテナ化は、そもそもコンテナとは何ぞやとかそのメリットとかコンテナ化する時の指針等の話と、実装技術なら Docker や K8s とかサーバーレスの話とか。他の項目でも、本質と実現方法それぞれがあって、それを区別せずに会話するとちぐはぐになるはず…等と思いながら、回答を眺めてました。

しかし、このやり取りによって、普段漠然と使っている”開発手法”に対して、自分がどんな定義をしているか、という事がだんだん鮮明になってきたのも事実なんですね。これって、ソクラテスの問答法じゃない？

このまま続けても、Chat GPT から新たに有用な情報は得られないなという事で、このトピックは一旦やめて、Open AI 系のサービスの外部サービス連携を聞いてみた。

結構イラついてますね。苦笑。この辺りは、やはりやってみるのが早いので、近々、Open AI 系のサービスで実際に試してみることにします。多分、このマガジンの記事で今後取り上げることになると思うので、乞うご期待。

で、またしつこく「開発手法」について話を蒸し返します。これ…相手が人間だったら絶対嫌われる奴w。

Chat GPT は色々と挙げてくれました。方法論戦争盛んな90年代後半から2000年代前半ならいざ知らず（いやぁこんなあけすけに指摘したら超絶恨まれて大変なことになったなぁきっと）、これだけ知ってるのは大したもんだと。AI なんで当たり前かｗ。

自分の中での”開発手法”の定義がだいぶ明確になってきた私。さらに続けて…

と、ここまでやり取りをしてきて、ふと、「あれ？自分、イベントとかセミナーでなんだかしつこく絡んでくるオヤジ化してない？」と気付く。
マイクロソフト時代、エバンジェリストとしてプレゼンテーションやっているとき、偶にそういう方いましたから。問答 その11. の Chat GPT の回答が、それまでの流れと若干違って、そういう絡まれ方をした時の大人な回答っぽく感じたんだよね。それ本当だったら Chat GPT すげーな。大人だ…知能テスト解かせたら当然すごいIQ叩きだすんでしょうね。知能指数は1300～とかｗ

で、聞いてみた。

これに関しても、大人な回答が返ってきた。

ここまでの問答を振り返ると、私自身が思っている”開発手法”とは

• ソフトウェア開発に必要な工程が網羅されている

• 各工程で作成するべき成果物が決まっている

• 成果物を書くための記法が用意されている

• 記法は数学的基盤に基づいたセマンティクスとシンタックスを持っている

• 工程間の順序は成果物を介したデーターフローとして定義されている

が揃っている事なんだなと。
加えて、様々な問題領域のソフトウェア開発に適用できるためには、特定ベンダーの特定ツールやサービス技術に過度に依存しない事もまた重要。
更には、この Digital Transformation の時代、記述したモデルは全てプログラマブルに系統的に基本要素の部分まで取り出せる必要があるでしょうね。そうしないと、工程の自動化が出来ないから。

こういう観点からすると、例えば、Chat GPT が挙げた”ウォータフォール”は、工程は網羅されているけど、上流工程で作成する成果物が曖昧ってことになる。”スクラム”は、比較的作成することが明確なので、ギリギリ、開発手法といってもいいかなと。ただし、バックログが自然言語で書くのが私的には微妙。要求を明確にすること自体難しいから、早く実装して確かめるということなので、良いのかもしれないけどね。

別の観点から見ると、”開発手法”もまた、要求や利用可能な実装技術を入力として様々なプロセスが実行されてソフトウェア一式という出力が生成されるという事で、ある意味で、ソフトウェアとして考えることもできるよねと。それを機能で分割するか、データ駆動で分割するかによって、同じ開発手法なるモノでも全く、異なるものに見えることになる訳で。
私自身は、機能的な観点からではなく、データ駆動的な観点からいつも考えているんだなと、気づいた次第。Chat GPT よありがとうw

ここまで書いてきて思い当たった開発手法の新しさと古さの基準は、成果物が（本当の意味での）デジタル化されているか否かでしょうね。その観点からすれば、例え、Agile と言われるプラクティスを採用していても、作成する成果物がデジタル化されていなければ、古典的なやり方という事になる訳です。”概念モデリング”をはじめとする、デジタル化されたその他のモデリング技法や形式記述言語による仕様記述を採用しない Agile で意味のある成果物は、コードだけでしょう。

もう一つの論点として、私の理解している Shlaer-Mellor 法に関わる様々なことは、そもそも、Shlaer-Mellor 法自体の話？それとも、私の経験・体験から色々と知見を加えた結果の Yet Another なのか、という疑問。
明らかに後者だなと、気づき、その辺を踏まえての、

• 「Art of Conceptual Modeling」

• 「Technique of Transformation」

• 「Essense of Software Design」

• 「Practices of Software Engineering」

なんだなと、いう事でした。

ここまで問答を続けて、自分の頭も整理され、Chat GPT の性能も大体わかったので、〆的な問答を続けました。

ふーん。。。

現状の感触

ということで、現状の感触としては、

• 例えば、Azure Open AI 等のカスタマイズトレーニングが可能なサービスを使えば、手間暇かければそれらしいものは出来るかも

• 今のところ、せいぜい、ドメインやクラス、Relationship の候補の抽出のお手伝いぐらいか？

  • あればあったで便利でしょう

気付いたこと（感じたこと）

一連の問答で気付いたことを挙げておきます。

• あたかも、Chat GPT が人であるかのような質問の数々

• 全く間違っているという事でもないが的も射ていない回答の数々

• イベントとかで面倒くさいおやじに絡まれた時の様な反応を Chat GPT が見せたことには驚いた

• 私が考えている、用語の定義を改めて考えさせられた

  • ”開発手法”、”開発技法”とは

  • ”本質”と”実現方法”の区別

• 自分の頭の中の知識体系の良い棚卸になった

実は、この問答スレッドは、Shlaer-Mellor 法に関する二回目の問答のものです。一回目は残念ながらログが残っていなかったので挙げることはできません。ただ、かなり多くのウソをしれっと回答していたのは事実。

最後に

以上で今回の記事は終了です。
Open AI 系を含めこの辺の AI の進化はめちゃくちゃ早いので、折を見てじっくりと色々と試してみようっと。

4/22 の LT では、最後に、”デザイン思考”と”圏論”という二つのキーワードを出して終わりにしました。
Chat GPT との問答を改めて眺めてみると、”デザイン思考”という用語は、Chat GPT の回答で出てましたね。それでか。
実は、4月上旬に、ベイビーワルキューレ２ベイビーを新宿のピカデリに見に行った帰りに、丁度そのころ「デザイン思考2.0」という本を読み始めていて、コクーンタワーの Book 1st に立ち寄って、”デザイン思考”に関する書籍は無いものかと探していて、「デザイン、アート、イノベーション」も見つけていたので、”デザイン思考”が「IoT・Digital Twins 最初の一歩」に書いてちょっと微妙に気になっている部分の解決につながるんじゃないかということで言及。
この記事にも書きましたが、数学的基盤を持つモデリング記法・技法については、それほどきちんと意識したことは無かったなと、思ったのと、リレーショナルセオリー自体、集合論をベースにしているとはいえ、他の数学体系とあまり親和性はないなと感じていて、何かいいものは無いかと見渡していたら、偶然、”みんなの圏論”と”活躍する圏論”という二冊の本を見つけました。今年の二月に出版された比較的新しい本です。どうやら「Art of Conceptual Modeling」を厳密に数学的に記述できるのは、圏論（英語では Category Theory）らしいということで、現在勉強中です。

デザイン思考と圏論については、このマガジンの記事として、ある程度理解が進んだ段階で、そのうち取り上げようと思ってます。