概要
顧客にとって役に立つソフトウェアを開発するには、モデリングが重要だと言われています。モデリングによってソフトウェアの価値が高まると言われています。
モデリングとは一体何でしょうか。
単にUMLでクラス図を描くだけでしょうか。
本記事は、ドメインモデルの考え方についてなるべく容易に理解できるよう、ゲームを題材に解説を試みたものです。
留意
本記事では実在の製品を例に挙げて解説していますが、モデル図等はあくまで筆者の私見、個人的な推測であり、実際の製品開発で考案されたモデルとは異なるであろうことにご留意願います。 また、「ドメインモデル的な見方をすればこのようなモデルとなるのでは」と私個人が解釈した内容であることにもご留意願います。
ドメインモデルとは何か
「モデル」と言っても文脈により様々な解釈がありますが、本記事ではドメイン駆動設計に登場するドメインモデルに従います。ドメインモデルならびに関連する概念について、以下のように定義します。
- ドメイン：ソフトウェアで解決したい対象の領域。問題領域と呼称する。
- ドメインモデル：問題領域の解決のために、物事の特定の側面を抽象化したもの。
堅苦しい表現でちょっと分かりにくいですね。
以降、ドメインモデルについて、ゲームを例に解説していきます。
「問題領域とドメインモデルは切っても切り離せない関係である」ことに注意して読み進め願います。
ゲームにおけるドメインモデルの例
対戦格闘ゲーム
カプコンさんのストリートファイターシリーズでもおなじみの対戦格闘ゲーム。
体力ゲージがあり、体力がゼロになったらKO。1ドットでも体力が残っている限りピンピン動き回るので、一発逆転を賭けた緊張感のある対戦が魅力のジャンルとなっています。
さて、ゲームに登場するキャラクターをモデルとして考えてみます。
モデリングするとき、現実世界のモノをモデルとして落とし込むことが見受けられます。
対戦格闘ゲームのキャラクターは、**現実世界の人間そのものを表現したモデルと言えるでしょうか？**現実世界と異なる要素を以下に列挙してみます。
- どんなにダメージを受けても、1ドットでも体力が残っている限りピンピン動き回れる。
- キャラによりジャンプ速度が異なる。
- 床と水平に等速直線運動で飛翔するスモウレスラーなどといった、重力を無視した必殺技がある。
体力について考えてみましょう。
現実世界での格闘は、動き回っていると徐々に疲れて、動きが鈍くなっていきます。ダメージ受けて負傷した場合、負傷部位を動かせなくなることもあるでしょう。
疲労や負傷による動きの鈍化をモデル化し、システムとして実装するとどうなるでしょうか。
時間経過や被ダメージでキャラを思い通りに動かせなくなり、とても一発逆転できるようなゲームにはならないと想像します。
ジャンプ速度も同様です。
格闘ゲームの世界ではキャラによって重力加速度が違います。
しかし現実世界では物の重さに関係なく同じ重力加速度が働き、同じ速さで落下します。
キャラがみな同じジャンプ速度では、個性が薄れてしまうでしょう。
物理法則を無視した各種必殺技も、現実ではありえない軌道により戦術に幅を持たせたり、視覚的な面白さの演出に貢献しています。
物理法則を大真面目に適用した必殺技だと、もはや「普通の人がケンカしてるだけのゲーム」になってしまうでしょう。
ところで先に「問題領域とドメインモデルは切っても切り離せない関係である」と書きました。
対戦格闘ゲームで解決したい問題領域とは何でしょう？
「最後まで一発逆転の可能性のある緊張感や駆け引きを楽しみたい」
「魅力的な必殺技で対戦を演出したい」
ではないでしょうか。
この問題領域においては、疲労や負傷、現実世界の物理法則といった要素は問題解決の役に立たないどころか、逆に邪魔になってしまうと考えられます。
ゲームとしての魅力を高めるために、疲労や負傷、現実世界の物理法則といった現実世界の側面は切って捨てられています。そして体力を「体力ゲージ」という分かりやすい形で抽象化されています。
また、ジャンプ速度に関係する重力加速度も、キャラの個性を引き出すために「キャラにより加速度が違う」といった、似て非なるモデルとして表現されています。
メタルギアソリッド3
対戦格闘ゲームとは異なる形で体力を表現したゲームとして、コナミさんのメタルギアソリッド3(以下MGS3)を挙げます。
MGS3は過酷な密林や山岳地帯の奥地にある敵陣へ、敵に見つからないように潜入するサバイバル潜入ゲームです。
体力はライフゲージ、スタミナゲージの他、切創や火傷といった状態異常として表現されています。
ライフゲージはゼロになるとゲームオーバーで、対戦格闘ゲームと同じです。
スタミナゲージは主人公の満腹度のようなもので、ゲージ減る（＝空腹になる）とライフゲージの回復が遅くなったり、パンチ力が弱くなったり、手がブレて銃の照準が合わなくなったり、潜入活動に支障をきたすようになります。
敵からのダメージの受け方によっては負傷することがあり、ナイフで斬られた場合は切創、火炎攻撃を受けた場合は火傷したりと、状態異常が発生します。
対戦格闘ゲームでは切って捨てられている空腹感や負傷がモデル化されていますね。
これによってMGS3はつまらなくなっているのでしょうか？
モデリングする上で重要な問題領域を考えてみましょう。
対戦格闘ゲームと同じ「最後まで一発逆転の可能性のある緊張感や駆け引きを楽しみたい」でしょうか？
MGS3では、空腹になった場合、密林に生息するヘビや魚を捕まえて食べ、スタミナゲージを回復します。
火傷を負った場合、蜂の巣から取れるハチミツを使って治療します。
このように、MGS3では自然環境にあるものを駆使して過酷なサバイバルミッションを楽しむゲームとなっています。
つまり、「過酷なサバイバルミッションを楽しんでもらう」という問題領域を解決するために、体力をライフゲージ、スタミナゲージ、火傷などの状態異常という形にモデル化していると推測します。
問題領域が異なると、モデリング対象となる概念が異なるのです。
ミニ四駆
ビデオゲームではないですが、現実世界でモデル化したものとしてミニ四駆を挙げます。
ミニ四駆は模型メーカータミヤさんが開発した、電池で動く手のひらサイズのモデルカーです。
ミニ四駆には性能アップのための各種カスタマイズパーツを豊富に取り揃えており、モーターやギア、タイヤを換装して走行速度を向上したり、ローラーを装着してコーナリングに強くしたりなど、カスタマイズ性を楽しめる製品となっております。
ミニ四駆は本物のレーシングカーをそのまま表現したものでしょうか？違いますね。
動力源はエンジンではなくモーターですし、ドライバーの居住空間やハンドルやブレーキもありません。フロントバンパーには現実のレーシングカーではありえないローラーが装着されています。実際のレーシングカーとは全く構造が違います。
対戦格闘ゲームやMSG3の例で挙げたように、問題領域が異なると切って捨てる概念が違ってきますし、モデリングの仕方が全然変わってきます。
ミニ四駆が対象としていると考えられる、「車のオモチャを改造してレーシングを楽しみたい」問題領域においては、ドライバーの居住空間など現実のレーシングカーの構造は、問題解決の妨げになる概念として切って捨てられているとみなせます。
ポケットモンスター
同じ概念でもゲームの形式により全然違うモデルの例としてポケットモンスターを挙げます。
ポケモンは様々な種類の架空生物を育成して戦わせる、言わずと知れた超有名ゲームです。
ポケモンは各種シリーズとなっているRPGとしてのゲームの他、カードゲームとしても販売されています。
RPGとカードゲームとではポケモンを表現するモデルが全然違います。
RPGとしてのポケモン
RPGでは、敵のポケモンと戦い、経験値が上がることでレベルアップします。レベルアップに伴い、使える技が増えたり、より強力なポケモンへ進化したりします。成長という概念が経験値、レベルアップ、進化という形でモデル化されているのが特徴です。
また、技はそれぞれ使用回数としてPPが決められており、PPが残存しているだけ技を使用できます。
カードゲームとしてのポケモン
カードゲームでは、ポケモンの絵が描かれたカードを場に出して勝負します。
RPGとは異なり、使える技はカードそれぞれで固定です。技の使用には、必要な分だけエネルギーカードを場に出す必要があります。技の一部にはコイントスにより効果が左右されるものがあり、例えばピカチュウのアイアンテールの効果は「ウラが出るまでコインを投げ、オモテの数 x 20ダメージ」となっています。
進化に関しても、進化元のポケモンカードに進化先のポケモンカードを重ねることで進化する仕組みになっています。
RPGに登場する経験値、レベルアップといった成長を表現するモデルは登場しないですし、技の使用回数を表現すPPも登場しません。
ポケモンという同じ題材や概念でも、問題領域が違うとモデルの表現方法が違ってくるのです。それぞれの問題解決に特化したモデルとして表現されています。
ドメインモデリングで必要な考え方 途中まとめ
ここまで出てきた考え方を一旦まとめます。
- ドメインモデルとは、問題解決のために物事の特定の側面を抽象化したものである。
- ドメインモデルは現実世界を正確に表現したものではない。
- モデリングの前に、ソフトウェアが対象とする問題領域を必ず定義すること。
- 現実世界の要素について、問題領域の解決に貢献しない側面や邪魔になる要素は切って捨てること。
- 問題解決の役に立ちそうな要素は、ソフトウェアの価値を高めるよう抽象化したり、現実世界とは似て非なる挙動を解決手段として備えたモデルとして設計すること。
- 同じ概念でも問題領域が異なるとモデルの表現方法が異なる。各問題領域の解決に特化したモデルを設計すること。
Webサービスに当てはめて考えてみる
ゲームを例にドメインモデリングの考え方を説明してきましたが、ここからはゲーム以外のWebサービスを例に、ドメインモデリングの考え方と照らし合わせながら解説していきます。
状況によって役に立たないモデルの例 履歴書
ある状況では役立っても、別の状況では役に立たなくなるモデルの例として、求人サービスの履歴書を挙げます。
日本の履歴書を現実のフォーマットに即してそのままモデル化すると、以下のようになります。
日本においてはこれで良いかも知れませんが、これがアメリカだと役に立たないばかりか大問題に発展する恐れがあります。
顔写真や名前は人種差別に繋がる恐れがあり、不問としているそうです。
また、年齢や性別、婚姻に関しても同様で、「雇用差別禁止法」により記載不要とのことです。
「アメリカにおいては」顔写真、名前、年齢、性別、婚姻は問題解決の役に立たない、かえって邪魔になる要素となるのです。
逆に学業成績や課題活動、推薦状など、能力を表現する要素を重要視するそうです。
「アメリカにおける就職活動」の問題領域を解決する履歴書モデルは、以下のような設計になるのではないでしょうか。
このように役に立つモデルを設計するには、アメリカの就職事情や社会問題を熟知している必要があります。ドメイン駆動設計では、問題領域に関して詳しい知識を持っている人をドメインエキスパートと呼びます。
ドメインエキスパートとともにモデリングしていくことが肝要です。
再び日本の履歴書の話に戻りますが、かねてから日本は新卒至上主義や年齢等での足きりが問題視されています。履歴書をサービス上で表現する以前に、履歴書のフォーマット自体に課題がある可能性があります。そもそも履歴書こそ、人物像を抽象化したモデルなのですから。
「日本ではこのフォーマットの履歴書が普通だから…」と何の考えもなしにそのままモデル化してしまうのではなく、「就職活動に本当に役立つ履歴書はどうあるべきなのか」によく思慮を巡らせ、必要な側面のみをモデル化し、システムに落とすことで、就活生や採用側企業にとってより価値のあるサービスになるのではないでしょうか。
この考えは履歴書の例に限らず全てのモデリングにおいて重要であり、問題の本質に迫ることが良いモデルの設計に貢献します。
特徴的なモデルの例 Twitterのリツイート
かなり特徴的なモデルの例としてTwitterのリツイートを挙げたいと思います。
Twitter登場以前、SNSなどで誰かに何かを伝え広めたいとき、文章そのものや、記事のURLを貼り付ける方法が主流でした。
Twitterでは「人に何かを伝え広める」行動概念をフォロー、リツイートという特徴的な概念で表現しています。その機能は皆さんご存知の通り、自分がリツイートしたツイートが自分のフォロワーのタイムラインに表示されるものであり、良くも悪くも話題性のあるツイートほど次々にリツイートされて拡散する仕組みとなっております。リツイート数の表示も、どれだけ話題性があるのかを表現するバロメータとなっております。
今でこそTwitterは当たり前のように使われていますが、リリース当初「フォロー？？」「リツイート？？」と、新たに登場した概念に戸惑った方が多かったのではないでしょうか。
「この人の話は面白いから注視しておこう」とか「面白い話を得たからみんなに広めよう」という行動は、遥か大昔から人間社会の営みとして存在していたでしょう。しかしその行動をフォロー、リツイートと呼んでいた人はいたでしょうか？
思うに、「人に何かを伝え広たい」問題領域を解決するために、現実世界における「誰かを注視する」「話を人に広める」行動を、現実世界にはないフォロー、リツイートというモデルに落とし込み、仕組み化したものがTwitterなのではないかと推測します。これは上のドメインモデリングの考え方で挙げた
- ドメインモデルは現実世界を正確に表現したものではない。
- 問題解決の役に立ちそうな要素は、ソフトウェアの価値を高めるよう抽象化したり、現実世界とは似て非なる挙動を解決手段として備えたモデルとして設計すること。
を如実に体現していると私は見ます。
現実世界にあるものをそのままモデル化するのではなく、現実をベースに新たに概念を発明してモデル化するのがイノベーションの第一歩だと思います。
まとめ
ソフトウェア開発では、本当に解決したい問題が何なのか本質を見失い、自分たちが何を作っているのか分からない、顧客に訴求する機能にならない、ということがしばしばあるのではないでしょうか。
そういうときこそモデリングを通じて状況を整理し、顧客にとって価値のあるモデルを設計することが大事だと考えます。
以上、ドメインモデリングに必要な考え方をまとめます。
- ドメインモデルとは、問題解決のために物事の特定の側面を抽象化したものである。
- ドメインモデルは現実世界を正確に表現したものではない。
- モデリングの前に、ソフトウェアが対象とする問題領域を必ず定義すること。
- 現実世界の要素について、問題領域の解決に貢献しない側面や邪魔になる要素は切って捨てること。
- 問題解決の役に立ちそうな要素は、ソフトウェアの価値を高めるよう抽象化したり、現実世界とは似て非なる挙動を解決手段として備えたモデルとして設計すること。
- 同じ概念でも問題領域が異なるとモデルの表現方法が異なる。各問題領域の解決に特化したモデルを設計すること。
- 良いモデルに落とし込むために、問題の本質を突き詰めること。
- 現実世界にあるものをそのままモデル化するのではなく、現実をベースに新たに概念を発明してモデル化することも検討すること。