ナレッジ
【連載】概念モデリングを習得しよう:概念モデリングとは(第1回)

「問題」とは何か?
読者の皆さん、こんにちは。
Knowledge & Experience代表の太田寛です。
筆者はマイクロソフトで技術系エバンジェリストを務めるなど、30年以上にわたりソフトウェア開発に従事してきました。その知見やノウハウを基に、現在はビジネスにおけるテクノロジー活用を、概念モデリングやアーキテクチャなどで支援しています。
さて、本連載では「概念モデリング」を解説します。概念モデリングは、日々皆さんが遭遇する現実世界を、理解し、記述し、共有するための方法論です。
読者の中にはITソリューションや機器の組込み制御といったソフトウェア開発に携わっている方も多いと思います。最近ではローコード、ノーコードのテクノロジーを使ったビジネスアプリケーションの開発も一般化してきているため、各自のビジネス上の課題を解決するアプリケーション開発に勤しむ、ソフトウェア開発の専門家ではない、いわゆる ITワーカーと呼ばれる人たちも多数いることでしょう。
ソフトウェア開発において、最も重要なことは何でしょうか?
それは、開発対象を理解することです。開発対象の理解が不足、あるいは、間違っていれば、出来上がったソフトウェアが期待通りの価値を生み出しません。価値を生み出さないばかりか、その開発にかかったコストは無意味になってしまいます。エンタープライズレベルの IT ソリューションであれば、不出来なソフトウェアを使うことで多数のユーザーが不利益を被るという、計り知れない損害をもたらすことにもなります。
ITソリューションをはじめとするビジネス向けのソフトウェア開発においては、顧客へのより良いサービス提供、新規顧客開拓や社内業務の効率化など、ビジネス上の問題解決が主目的です。制御ソフトウェア開発では、モーターの回転数や温度・湿度など、物理現象が直接的な制御対象になります。ただし、そのソフトウェアが組み込まれる機器が顧客において何のために使われるのかまでを考えれば、対象となる問題は、ビジネス向けソフトウェアの場合と同様であると考えてよいでしょう。
ここで、「問題」という用語の意味を明確にしておきましょう。もちろん、クイズ番組の「さて問題です」という、聞かれた側が回答をしなければならないような問題のことではありません。問題とは、“現状の姿”と“あるべき理想の姿”の間のギャップのことです。そのギャップを埋めるために取り組むべきことが「課題」です。
ビジネスにおいては、販売経路や業務プロセスの現状と目指したい理想の状況とのギャップが問題です。制御システムであれば、現状の制御が生み出す状態と、あるべき理想の物理現象の状態のギャップが直接の問題で、そもそもの問題が、現在、市場に出ている機種の使用状況と理想的な使用状況のギャップということになります。
ビジネスや制御用のソフトウェア開発などと、大上段に構えなくても、私たちは仕事や日常生活において、「この意味の無いレポートいつ書く?」とか「今日のご飯は何にする?」とか「今度の週末何をする?」、「このクーラーそろそろ買い替え時?」などなど、さまざまな問題を設定して、その課題を解決しながら生きています。問題を正しく理解することは、日々のより良い生活を送るためにも必要なのです。
ここまで来て、次のように思われた読者がいるかもしれません。「そんな意識高い系じゃないから、問題なんかないよ。だから、この記事はここで読むのをやめよう」と。
確かにその場合、現状と理想の姿が一致しているため、問題は抱えていないのかもしれません。しかし、108の煩悩を抱えているといわれるわれわれ人間は、要らぬお世話を焼くおせっかいな人がいたりと、生きている限り、ユルければユルいなりの現状と理想のギャップはあるもの。そのようなギャップを埋めたいと思われている読者は、この先を読んでください。
ギャップを「記述」する
ソフトウェア開発に限らず、日常の生活においても問題を理解することの重要性をここまでお話してきました。
繰り返しになりますが、問題は現状の姿とあるべき理想の姿のギャップであり、故に問題を理解するには、まず、現状の姿と、あるべき理想の姿の2つを正しく知る必要があります。
日常の個人的な問題の場合、それほど厳密に突き詰めることはありませんが、他者との協業が必要な業務計画の策定や仕事の遂行、ITソリューションや制御ソフトウェア開発の場合は、誰か1人だけが脳みその中で問題を理解しているだけでは不十分であり、活動に関与するステークホルダーたち全員が問題を共有し、理解しなければなりません。
そのためには、現状の姿とあるべき理想の姿を「記述」することが重要です。
大抵の場合、チームの中の誰か1人、あるいは数人が担当者に任命され、担当者が2つの姿を理解した内容を記述して、関連するステークホルダー全員に共有することになるでしょう。その際、担当者それぞれが好き勝手に思いつくままに記述すればよいというものではありません。そんなやり方では記述した本人たちさえ3カ月も経てば、内容を理解できなくなってしまいます。この記述するという行為は、他者が理解可能な形式で表現されなければなりません。
対象世界の姿を、ある形式に従って記述することを「モデリング」、その過程で作成されて、出来上がったものを「モデル」と呼びます。大勢の人たちの間で誰かの理解を共有できるよう、何をモデル化するか、どのような形式で記述するかを規定することを、「モデリングの方法論(Methodology)」と呼びます。
「え? 何が問題かだなんて、方法論とか大げさな話をしなくても、生成系AIに聞けば回答してくれるんじゃない」などと、思われてはいませんか?
生成系 AI に適切な問いを発するには、その問いの背景になっている姿への適切な理解が必要です。それが無ければ、理解可能な適切な出力を得ることはかなわないでしょう。生成系 AI を使うためにモデリングが不必要であることの理由にはなりません。
前置きが長くなりましたが、モデリング方法論として活用できるのが、「概念モデリング」です。第1回目の本稿では、概念モデリングそのものの説明ではなく、概念モデリングを理解・習得するために必要な基礎知識を解説します。
概念モデリングとは
概念モデリングは、以下のモデルから構成されるモデリング方法論です。本稿では最初の項目を説明します。
- モデル化対象を規定するドメイン(意味の場)
- 概念情報モデル(Conceptual Information Model)
- 概念振舞モデル(Conceptual Behavior Model)
- ドメイン間の対応付け
本論に入る前に、概念モデリングの由来を紹介します。
概念モデリングは、1990年初頭に提唱された「Shlaer-Mellor法」という組込み制御ソフトウェア開発方法論をベースにしています。Shlaer-Mellor法は、開発対象をモデル化し、出来上がったモデルの妥当性を検証し、検証済みのモデルを実装技術に合わせてコードに変換するという体系を持つ、モデル駆動型開発の先駆けと言える方法論です。
当初独自の記法を使っていましたが、モデル記法がUML(Unified Modeling Language)で標準化された後は、UML表記に対応しました。それにより、現在、xtUML(Executable & Translatable UML)という名称になっています。提唱者は、Sally Shlaer氏(故人)とSteve Mellor氏(現在Industrial Internet Consortium CTO)のお二人で、xtUML は今も世界中で利用されています。xtUML に関するさまざまな情報は、https://xtuml.org にて公開されています。
筆者は、OA 機器メーカーに勤務していた時代、OA機器制御ソフトウェア開発で、Shlaer-Mellor 法の導入を試み、実際にこの方法論で開発、自動生成されたプログラムコードが搭載された OA機器のリリースに成功しました。その後、活動を通じて得たプラクティスを全社に展開しようとしましたが、時代が早過ぎたのか、いろいろとあって退職しました。
その後、縁あって、2006年に世界最大の IT 企業であるマイクロソフトに転職し、前半は技術の普及啓発を担当するエバンジェリストとして、後半は、技術者への普及啓発活動を継続しながら、お客様の実プロジェクトへ新しい技術を導入支援する Global Black Belt(技術スペシャリスト)を担当しました。
ご存じの通り、マイクロソフトは目まぐるしく新しい技術やサービス、プロダクトをリリースする会社です。筆者自身の技術領域の幅を、組込み機器からPC、スマートフォン、クラウドへと広げていく中で、新しく出てくる技術の迅速なキャッチアップに、Shlaer-Mellor法のモデリング技術は大変役立ちました。お客様への新規技術導入においても、明示はしませんでしたが、陰ながら Shlaer-Mellor法を活用し、案件の迅速な理解と、適切なアーキテクチャや使い方を提供し続けることができました。
この過程を通じて、Shlaer-Mellor法は、組込み制御系だけでなくビジネス系のIT開発でも十分威力を発揮すること、そして、この方法論において、中心的な役割を果たすオブジェクト情報モデルは、単なるプログラムコードのお絵描きモデルではなく、オントロジー(概念意味論)的なモデルであることを再認識していました。
そんな中、マイクロソフトは、2020年の暮れに、「Azure Digital Twins」というデジタルツイン向けのサービスをリリースしました。
まさにShlaer-Mellor法のモデリング技術がベストフィットするサービスであり、さらに言えば、Shlaer-Mellor法流のモデリングが無ければ使いこなせないサービスであったことに、大変驚きました。驚きついでに世の中を見渡せば、Smart City や電力の発・送・配電といった、複数のプレーヤーが協業するようなビジネス領域では、既にオントロジーを記述する共通モデルが国際標準化されているではありませんか。
また、ビジネスのイノベーションの核心といわれているデジタルトランスフォーメーション(DX)の喧伝の状況を横目で眺めていました。DXはビジネスに関わる事項がデジタル化されていなければ達成は不可能です。“ビジネスに関わること”=“あるべき理想の姿”であり、それをデジタル化するということは、“あるべき理想の姿”をモデル化することと同義です。つまりは、DXを推進するには、モデリング技術が必須であることは間違いないと、Azure Digital Twins のリリース以前から考えていました。
マイクロソフトを飛び出した理由
ようやく時代が私に追いついてきたか……と思った反面、モデリングに対する技術者の取り組みやスキル状況を、日本だけでなくワールドワイドで見渡してみると、筆者がモデリングに取り組んでいた2000年代初頭とさほど変わっているようには見えません。Shlaer-Mellor法に関していえば、2000年初頭までは何冊か翻訳本(そのうちの1冊は筆者も翻訳に参加)が出版されたものの、それ以降は1冊も刊行されていません。さらには、他の技法も含め、90年代から2000年代初頭にかけて盛り上がっていたモデリングや開発方法論に対する熱量もあるようには思えません。
「このギャップは何だろう? みんな大丈夫か? これは、オントロジー系のモデリング技法の普及が必要だろう」
これが筆者の偽らざる心境です。誰かがやらねば……ということで、2022年にマイクロソフトを退職し、概念モデリングの普及啓発を始めた次第です。
本稿で解説する概念モデリングは、Shlaer-Mellor法をベースに、制御系ソフトウェア開発だけでなく、IT ソリューション開発、さらにはさまざまな問題解決に資するよう、筆者の30年以上にわたる経験(少なくともリーチした技術者1万人以上、支援プロジェクト200以上で培いました)を基に、今時の IT技術水準も考慮しつつ、拡張、再構成、再定義を行い、2年間かけてまとめたものです。
ただ、30年以上といっても、しょせんは実務の片手間での経験に過ぎません。モデリング技術のバックグラウンドを整えるために、フッサールやヘーゲルの現象学、フレーゲの論理学、ウィトゲンシュタインの言語哲学、マルクスガブリエルの新実存主義などを拝借して、モデリング体系を構成する諸概念を吟味し、数学の基礎付けで使われる圏論を基に検証した結果も、概念モデリングに取り入れています。
概念モデリングは一般用語でもあります。しかしながら、具体的かつ厳密に編まれ、かつ、実践的なプラクティスがあって一般的に普及している概念モデリング技法が、今現在見当たらないことと、Shlaer-Mellor法をベースにしてはいるものの、まったく同じではないということで、この名前を筆者は採用しています。
そういう意味では、筆者が解決するべき問題は、
- 現状の姿 → 筆者の概念モデリングは、一般名詞の概念モデリングの一種である
- 理想の姿 →概念モデリングといえば、“Art of Conceptual Modeling”
のギャップであると言えます。
この連載では、ソフトウェア開発の専門家でなくても理解できるよう、なるべく平易に概念モデリングを解説していこうとの思いで執筆します。
より詳細な解説は、
- “Art of Conceptual Modeling”
- “概念モデリングチュートリアル集”
- “Technique of Transformation”
- “SaG Modeling for Real World”
に詳しく書かれているため、そちらを読んでみてください。他にも、筆者はnote(https://note.com/kae_made)でソフトウェア設計やエンジニアリングに関する記事を公開しています。全てのコンテンツの内容を紹介したビデオも公開しているので、ご覧いただければ幸いです。
次回は、概念モデリングの具体的な活用方法についてお話ししていきます。
この記事は面白かったですか?
今後の改善の参考にさせていただきます!