拾い読みメモ「インストラクショナルデザインの理論とモデル」

学び方や教え方といったことにも興味がある私は、書店で教育系の棚を眺めに行くことがある。しかしこの分野の知識体系はほとんど持ち合わせていないため、ランダムに本を手にとってパラパラとめくったりしながら、その時の気分で何かが目に留まるのにまかせる。ある時ふと『インストラクショナルデザインの理論とモデル』という書名が目にとまり、購入した。

分野的に私には知識ベースが足りないのと、本が各論ではなく全体像を示すことが目的(と私は解釈した)なこともあり、詳細を議論できるほどに読み込めていないが、流し読みして気になった点をメモとして残しておく。

インストラクショナルデザインの理論とモデル: 共通知識基盤の構築に向けて

インストラクショナルデザインの理論とモデル: 共通知識基盤の構築に向けて

  • 作者: チャールス・M.ライゲルース,アリソン・A.カー=シェルマン,Charles M. Reigeluth,Alison A. Carr‐Chellman,鈴木克明,林雄介
  • 出版社/メーカー: 北大路書房
  • 発売日: 2016/02/12
  • メディア: 単行本
  • この商品を含むブログを見る
 

この本では、現在でもさまざまな研究が続けられている「教授理論(instructional theory)」をとりまく、最新の状況が体系的にまとめ上げられている。

 

私がとりわけ興味を抱いたのは、14章「教授理論のアーキテクチャ」あたりの内容だ。教授理論というのは複数の理論群の総称で、実体としては独自に発展した個別の理論、および理論とは呼ばないが経験的に実施されているものも含めていくつもある。 それらの特性を評価するための道具としていくつかの提案があるのだが、以下の2つが気になった。

  • 設計理論とドメイン理論との区別
  • 教授理論の設計レイヤー

設計理論とドメイン理論との区別

上に書いたように、教授理論としてはさまざまなものがある。それら個別の理論は、技術や能力をよりよく教えるという大きなゴールを共有している。そうであるなら、個別の理論の何らかの側面に着目することで、1つの世界観のもとで語ることができるのではないだろうか。

この本では、個別の教授理論と、教授理論の設計問題を議論するためのフレームワークとしてのID(Instructional Design)理論とが区別されており、後者を設計理論と呼んでいる。これに対して前者の個別の教授理論は、ドメイン理論と分類している。

理論群に対してこのような区別を提示することは、とても重要だと思う。これによって、個別のドメイン理論の設計的な特性を論じることができるようになるし、次に述べるレイヤーのようにより整理された視点・概念を個別のドメイン理論の設計に持ち込んで進化させていくことにも役立つはずだからだ。

なお、設計理論の必要性について、この本ではハーバート サイモンの人工物の設計科学の議論を引いて、次のように説明されている。

サイモンは、特定の適用にかかわらない、独立した一般的な「人工物の設計科学(design science of the artificial)」の設立についての議論を投げかけた。彼は設計理論家に対し、「設計の科学、つまり知的に堅強で、分析的であり、部分的に定型化可能で、さらに部分的に経験主義的な、教授可能な設計プロセスに関する理論の体系を発見すること」を要求している。

人工物の設計、とても深遠なテーマだと思う。

教授理論の設計レイヤー

私はソフトウェアエンジニアなので、レイヤーという言葉にはとても馴染みがある。それが教授理論の設計という分野でも使われていることに素直に驚いた。しかし、レイヤー概念はソフトウェアの問題に固有であるはずはなく、設計活動のあるところなら必然的に適用しうるだろう。この本ではギボンズの記述として以下の6つの教授理論のための設計レイヤーが紹介されている。

  • コンテンツレイヤー(content layer)
  • 方略レイヤー(strategy layer)
  • メッセージレイヤー(message layer)
  • 管理レイヤー(control layer)
  • 表現レイヤー(representation layer)
  • メディア論理レイヤー(media-logic layer)
  • データ管理レイヤー(data management layer)

このレイヤーを用いることで、個別の教授ドメイン理論が持つ特徴をレイヤーごとに調べ、比較することができる。さらに、教授を設計する場合にも、レイヤーごとに問題を分割して検討することが可能になると思われる。

ドメイン理論の設計レイヤーの話の起点として、スチュアート ブランド の建築設計のレイヤーの話が紹介されている。これは、次の6つのレイヤーでまとめられたものだ。

  • 敷地
  • 構造
  • 外装
  • サービス
  • 空間計画
  • 什器等

これを見ると、設計レイヤーとは単に表層的な内部・外部関係から導かれたものではなく、興味関心や役割の違いが反映されたものと見ることができる。つまり、個々のレイヤーがそれぞれ建築設計のサブドメインなのだ。

同じ章でさらに、ブランドの建築設計におけるレイヤー意識の影響として次の6つの要点が紹介されている。

  • 各レイヤーは、異なる進度で成熟し、変化する。しかし、それらは相対的に独立し、他の個別レイヤーに非破壊的な変化を許容する範囲で設計され、接続されうる。
  • レイヤーによる設計は、それゆえに適応性があり、永続する人工物を創出することができる。
  • 「敷地」から「什器等」へのレイヤーの系列は、設計と建築の両方にあてはまる一般的順序である。さらに、それは異なるレイヤーそれぞれの経年速度と関連がある。
  • それぞれのレイヤーには、それぞれに異なるアジェンダや設計ゴール、そして解決し統合すべき問題があり、異なる設計スキルセットが要求されることを示す。
  • 建築の力学―レイヤー間ならびにレイヤー内の変化の速度は、緩やかに変化する構成要素に支配される。速やかに変化する構成要素は、それらに「随伴」する。
  • いくつかのレイヤーを一緒に埋め込むことは一見効率的に見えるが、究極的には、変化がだんだんと破壊的になるにつれて、建築物の寿命を短くする。

この6つの要点のうちの5つめ、緩やかに変化する要素に支配されるという建築の力学が特に気になった。これは、ソフトウェアの設計でいえば、パッケージの安定依存の原則(SDP: Stable Dependencies Principle)安定する方向に依存せよと同じだ。建築では現実世界との相互作用が強いので、より顕著にこのような傾向があるのだろう。

 

機会があれば以下の本を読んでみたい。

システムの科学

システムの科学

  • 作者: ハーバート・A.サイモン,稲葉元吉,吉原英樹
  • 出版社/メーカー: パーソナルメディア
  • 発売日: 1999/06/12
  • メディア: 単行本
  • 購入: 17人 クリック: 204回
  • この商品を含むブログ (54件) を見る
 
How Buildings Learn: What Happens After They're Built

How Buildings Learn: What Happens After They're Built

 

 

オブジェクト指向でなぜつくるのか(第2版)を読んだ

平澤章著『オブジェクト指向でなぜつくるのか』第2版を読んだ。初版は2004年、私が読んだのは2011年に改版された第2版。著者の平澤氏は『レガシーコード改善ガイド』や『リファクタリング』の翻訳にも携わった方だ。それらの本の専門的な内容・文体と比べると、本書はかなり平易な文章で書かれており、また、文字もやや大きめで読みやすいため、サクサクと読んでいける。 

オブジェクト指向でなぜつくるのか 第2版

オブジェクト指向でなぜつくるのか 第2版

 

著者である平澤氏は、オブジェクト指向技術とその周辺事情を実際に体験している。その著者により、一歩引いた視点から、技術としてのオブジェクト指向の基礎がバランスよく、やさしく語られている。

「一歩引いた視点」「良いバランス」という評には私の主観が多分に含まれるのだが、好印象を持ったことには違いない。世に出ているオブジェクト指向の解説本では、まるでオブジェクト指向が万能の銀の弾丸であり、それさえマスターすればすべてがうまくいくかのように導入されるものを見かける。また、対比として「手続き型プログラミング」を引き合いに出し、オブジェクト指向と手続き型プログラミングとを善悪の二極対立のように仕立て上げているものも、悲しいかなよく見かける解説になってしまっている(それは果たして解説と言えるのだろうか・・・)。

この点、『オブジェクト指向でなぜつくるのか』は大きく異なる。機械語から始まり、プログラミング言語そのものに対して見出されたその時の問題を解決する仕組みとして、プログラミングパラダイムが発展してきた。手続き型からオブジェクト指向へも、プログラミング言語の発展の自然な流れとして解説される。

また、この本ではたびたび「オブジェクト指向の限界」や「万能ではない」といった戒めが垣間見える。7章の後にあるコラムでは、「オブジェクトの向こう側」と題し、平澤氏の経験として、オブジェクト指向でなんでもやろうとしすぎてしまうことの失敗や、オブジェクト技術の中心はあくまでプログラミング言語であることなどに気づいたと告白されている。私には、平澤氏が現場での実践から得たフィードバックから、遂にたどり着いた言葉のように思えた。

 

最後に個人的に良いと思った点と、イマイチだと感じた点を列挙しておく。

良い

  • 機械語から順にプログラミング言語/技術の発展の延長としてオブジェクト指向が位置づけられている。
  • オブジェクトは現実世界そのままを写し取るのではない等、含蓄のある記述が散見される。

イマイチ

  • 追加された関数型の章含め、後半のパート(モデリングや設計等)は説明の仕方に納得感がない。
  • モデリングパートが、結局オブジェクト指向アプローチ前提になってしまっており、「なぜ?」に答えてくれない。

 後半部分はテーマの網羅性のためか、章ごとの内容が私には不満の残るものだった。欲を言うならば、網羅性を捨ててどれかワンテーマだけでも、前半と同じようにその技術の成り立ちをたどるスタイルで語ってくれていたら、なぜという疑問を晴らせたように思う。

しかし全体としては読みやすくバランスの良いオブジェクト指向技術の解説書だ。オブジェクト指向技術をある程度身につけた中・上級技術者は、自分の経験や実感と比較しながらこの本を読むことで、オブジェクト指向技術に対する認識を安定したものにできるだろう。

 

ドメイン駆動設計 実践のための原則を4つ考えてみた

 『エリック・エヴァンスのドメイン駆動設計』(以下DDD本と呼ぶ)の原著出版から十数年が経過した今、DDD本に書かれている内容は、吟味されアップデートされるべき時が来ている。このアップデートに盛り込みたい内容を、4つの原則という形で考えてみた。

なお、以下では「EvansのDDD本の内容」と「ドメイン駆動設計というコンセプト」は重なる部分があるにせよ、それぞれが指す対象は異なるものだとしている。この違いは本文中で触れるが、表記として「DDD本」は本を指し、「ドメイン駆動設計」はコンセプトの方を指すようにしている。

DDD本とドメイン駆動設計

DDD本では、ドメイン駆動設計というコンセプトが導入された。ドメイン駆動設計というコンセプトは、ソフトウェアエンジニアの一般教養といえるほど、今ではその価値が認められている。同様のアイデアは、EvansがDDD本を執筆した時代ですら、すでに先人たちが口にしてきていたことだと思う。たとえそうだとしても、このコンセプトをドメイン駆動設計と名付け、著書としてまとめあげてソフトウェアエンジニア界にもたらしたことには、とても大きな価値があるだろう。

DDD本には何が書かれているのか?

DDD本に書かれている内容を、一歩ひいた立ち位置でまとめると次のようになる。

  • Evansがドメイン駆動設計というコンセプトを明に暗に思い浮かべながら、実務で取り組んだ成功/失敗エピソード 
  • Evansが自分の手持ちの技術スタック(=オブジェクト指向分析・設計・実装)と、ドメイン駆動設計というまだ明確にはなっていないコンセプトをミックスし、実務で試す中で生まれてきた、ビジネスドメイン向けのEvans流アプローチ(モデルのビルディングブロックや、いくつかのパターン)

DDD本にはエピソードが豊富に書かれている。特に、さまざまな理由によってモデルが変化していく過程が綴られているのは特徴的だし、DDD本の面白いところでもある。個人的なお気に入りを1つ挙げるならば、深いモデルの章で紹介される船荷証券のエピソードだ。何しろ、最初の時期に考えていたモデルの要素は、最終的にはまったく不要になる話で、読めば読むほど、その最初の時期はなぜそんなことになってしまったのかというような疑問が次々と湧いてくる。Evansが言う「深いモデル」の「深さ」とは一体何なのかを考えていく契機にもなった。

DDD本に書かれているEvans流アプローチで紹介されるのは、汎用的な概念・パターンが多い。これらは一見すると、さまざまなドメインに対して適用可能に思える。エンティティやリポジトリといったパターンを使い、ある程度うまく機能するシステムを作れるケースは、現在でも多くある。また、仕様パターンの提案や、仕様パターンをリポジトリやファクトリと協調させる設計などは、形はそのままでは無いにせよ、アイデアとしては今でも有用だ。このように、Evans流アプローチにも学びどころはある。

しかし、ビジネスドメインに的を絞っても、Evans流アプローチには弱い点がある。その弱点をこの記事では趣旨とだいぶズレてしまうため述べないが、Evans流に一点張りするのは危険だということだけ触れておく。

DDD本には何が書かれていないのか?

DDD本を、ドメイン駆動設計のコンセプトを的確に伝えるための書物として見た場合、率直に言って重要なことが書かれておらず、適切ではない。重要だが書かれていないことがあるのだ。

DDD本ではドメイン駆動設計というコンセプトに対して、その1つの実現形態であるEvans流のモデリングと設計のエピソードがパターン形式で綴られている。しかし、これだけがドメイン駆動設計に当てはまる手法というわけではない。

どんなアプローチも万能ではなく、必ず射程が存在する。Evans流アプローチの射程は、贔屓目にいってもビジネスドメインであり、SoR(記録系のシステム)ドメインであり、また、エンティティを中心に形作られるドメインだろう。

世の中には、これに当てはまらないドメインが多数ある。また、無理に当てはめると機能しないシステムができあがってしまうようなドメインも多数ある。グラフの探索機能や行列計算ライブラリ、機械学習のためのフレームワークなどは、エンティティやリポジトリ、値オブジェクトといったパターンを単純に当てはめることが難しかったり、無理に当てはめると失敗しそうなドメインとして分かりやすい。

このようなドメインに取り組む場合でも、ドメイン駆動設計というコンセプトは役立つはずだ。ドメイン駆動設計というコンセプトは、あらゆるドメインの問題に取り組む際に有用だからだ。しかし、このようなコンセプトの本質的な内容を知りたくても、DDD本に書かれているエピソードからは、フワフワした輪郭としてしか浮かび上がってこない。DDD本には明確には述べられていないのだ。

まとめると、次の2つが明確な形では書かれていないことになる。

  • ドメイン駆動設計というコンセプト
  • ドメイン駆動設計というコンセプトと、その1つの実現形態であるEvans流アプローチとの関係性およびその位置づけ

この2つの欠点を補うようなアップデートがDDD本になされるか、または新たな書籍が執筆されるべき時だと思う。そんなささやかな期待を持ちつつ、私はこの記事で、DDD本の2つの欠点を補う内容を4つの原則にあらわしてみた。 

どうすればドメイン駆動設計を学べるのか?

核心を述べよう。どうすればドメイン駆動設計を学べるのか? この問いに対する私の答えは「ドメイン駆動設計を学ぼうとするな。ドメインについて学べ。」だ。多くの先人達も同じことを言われている。私はこのことをもっと強調したい。これは、ドメイン駆動設計を学ぶ際に必ず心にとめておかなければならない原則なのだ。

ドメイン駆動設計を学ぶ際に心にとめておく原則

ドメインについて学ぶ > ドメイン駆動設計を学ぶ

ドメイン駆動設計というコンセプトは、詰まるところ設計技法そのものではない。これについては、twitterでsugimoto_kei氏の次のtweetでも言われている。

ドメイン駆動設計について学ぶな、DDD本を読むな、とまで言うつもりはない。 しかし、ドメイン駆動設計というコンセプトで表される設計活動を学んで実践し会得するには、実際にドメインの問題と向き合って格闘するのが一番なのだ。それ以外に身につける方法はないとも言える。それに加え、自分が向き合っているドメインの問題は、どのように分析できるのか、どのようにモデル化できるのか、どんな設計が使えるか、、、こういったことを考えるヒントは、DDD本にしかないわけではない。むしろDDD本から離れて、そのドメインに向き合った先人たちの考えたことを素直に参考にした方がよい場合が多い(もちろん、技術の進歩というエッセンスは自分で加える必要があることは言うまでもない)。そうして、ドメインの問題の解決に没頭することが、ドメイン駆動設計であるとも言える。

DDD本に書いてあるEvansのエピソードは、そんな没頭の合間に、自分の向いている目線を確かめ、気持ちを再びドメインに引き戻すためのリフレッシュ材料として読めばよいのだ。

しかし、これだけでは結局「ドメイン駆動設計」というコンセプトが何なのか分からない。「ドメインに向き合っていれば自然と身につく」なんて言われても、その経験がないうちに納得できるはずがないし、「間違ったドメイン駆動設計」が存在し得ないようなら、コンセプトとして持ち出す意義も納得できない。ドメイン駆動設計のコンセプトを、日々の活動レベルで使っていくためには、実践者が自分の進む方向を自ら見出していけるような、分かりやすい指針があるとよい。これを3つの原則として表してみた。

ドメインモデルに取り組むハート

 ドメインモデルに取り組むハートの3原則

1. ドメインモデルとは、開発者=設計者が創り出すものだ

2. ドメインの問題にウェイトを置こう

3. ドメインを見る目、解決策を見る目を養おう

ドメインモデルは、開発者=設計者が自ら創り出すもの、というのが私の考えだ。設計は、大なり小なり何らかの解決の仕組みを創り出すプロセスであって、そこにクリエイティブなマインドは欠かせない。ドメイン駆動設計では、このクリエイティブ・マインドを、ドメインモデルにおいて発揮することになる。ドメインモデルのモデリングと設計は、外から与えられた要件をなぞるだけの行為ではないのだ。 

そして、ドメインモデルにクリエイティブに取り組む際、設計者の先入観が邪魔になることがある。どういうことか。開発者=設計者は、問題を理解するためのスタート地点として、必然的に「手持ちの技術」 で捉えようとしてしまう。その「手持ちの技術」は自分の手足のような存在、さらに言えば空気のような存在なので、あえてそれを使っているとは意識しない。問題のスタートから少しでも理解が進んで何らかの形が見え始めると、空気として存在している手持ちの技術が、その問題の解決に適しているのかを疑おうとしなくなってしまうのだ。

しかし、大事なのは、ドメインの問題をより上手く解決することだ。これを達成するためには、理解が進んで出来上がってきた形を疑うことだけでなく、ときには最初に用意した手持ちの技術さえ疑ってみる必要がある。この疑いは、慣れていないととても苦しい行為だ。なぜなら、自分自身のスキルや成果を否定するように感じるからだ。だが、ドメインの問題を解決することにウェイトを置くという共通理解があれば、余計な不安を抱えることもなくなる。自信を持ってスタート地点のはしごを外せるようになる。それに加え、自分にはまだ未知の技術だとしても、ドメインの問題をより上手く解決しそうだと客観的に判断できれば、学んで採用していける。

このようなドメインモデルに対する取り組みでは、開発者=設計者の「ドメインを見る目」を育てなければならないが、それと同時に、あらためて「解決策=技術を見る目」も育てなければならない。この2つの目は、ドメインに取り組む開発者にとって、どちらも欠かせない両輪なのだ。

ドメインの問題をより上手く解決するという基準に立つと、この2つの目が常に問われ続ける。その目の中には、ドメインの問題に適合するかどうかを判断するための論理力や、必要な時に必要なことを学んで取り入れていける柔軟性も含まれる。とてもハードルが高く聞こえるかもしれないが、これらの技術は、ソフトウェアエンジニアにとって普遍的に役立つ。 

さいごに

ここに述べた4つの原則が、私が『エリック・エヴァンスのドメイン駆動設計』から学んで得たことだ。もちろん、DDD本だけからこのような理解が得られたわけではない。多くの本を読み、先輩方や仲間との議論や対話、さまざまな試行錯誤の結果として得られたものだ。このような経験は私にとっては言葉にできないほど有益だったが、これだけの労力と時間を世の中の多くのエンジニアに強いるのは、良いことではない。ドメイン駆動設計のコンセプトの伝え方、そして何よりドメイン駆動設計というコンセプト自体は、今後もっと洗練されるべきだろう。そうすれば、ドメイン駆動設計のコンセプトが薄れるのではなく、蒸留されたエッセンスとして後世に伝わっていく。

この4つの原則が、今この瞬間にも生まれてくるドメインの問題を上手く解決するモデルを創り出す一助に(間接的にでも)なれば幸いだ。

 

ソフトウェア開発者の世界観を考える

ソフトウェア開発者の勉強会などに参加すると、最初に持ち時間一人30秒くらいの全員自己紹介タイムがあったりする。「好きなプログラミング言語は?」だとか「使っているフレームワークは?」など、勉強会の参加者層に対して比較的通じやすいお題が都度用意されたりもする。

そんな自己紹介のお題として「あなたのソフトウェアシステムに対する世界観は?」なんて出される勉強会があったら面白い、と思うのは少数派だろうか。

私の尊敬するエンジニアの先輩方は、必ずと言ってよいほど溢れんばかりの世界観をお持ちだ。システム観、モデル観、設計観、設計者観。そう呼べる何かが話す言葉の端々から滲み出ていて、興味をそそられずにはいられない。

しかし果たして、私自身はどんな世界観でもってソフトウェアシステムを眺めているのだろうか。自己紹介でネタにできるほどの世界観を持ち合わせてはいないのかもしれない。自分の世界観を客観的に考えるためにも、今持っている感覚から一歩引いて、いくつかの軸から有り得そうな世界観を想像してみることにしよう。

あらかじめ断っておくと、以下でとりあげる軸は、私が自分の考えを見つめるためにでっち上げたものであって、決してソフトウェア工学で議論されてきた用語などではない。

ドメイン

ソフトウェア工学の中にドメイン工学という分野がある。また、ソフトウェアの設計パターンとしてのドメインモデルという用語がファウラーの書籍でよく知られるようになった。エヴァンスのドメイン駆動設計以降、ドメインというのはソフトウェア開発におけるメジャーな概念になった。しかし、ドメインという言葉に託しているイメージは人それぞれかなり異なっているようだ。その異なり方を分析してさまざまな軸を洗い出すのも有益だと思うが、ここでは2つだけとりあげてみる。

ドメインの個数(または粒度)

ソフトウェアシステムには、いくつのドメインがあるのか? またはその裏返しとして、どのような単位をドメインと呼ぶのか?

  • 単一ドメイン的世界
    1つのソフトウェアシステムは、1つのドメインに対応すると見ている。システムとして機能する1つの固まりが、ドメインである。
  • 複数ドメイン的世界
    1つのソフトウェアシステムは、複数のドメインに分解できると見ている。ドメインによって浮かび上がる対象の粒度や抽象度は様々。

ドメインという言葉の指す対象の粒度としては、複数ドメイン的世界よりも、単一ドメイン的世界の方が大きいものとなっている。複数ドメイン的世界観では、かなり小さな対象でもドメインと呼ぶ。

コアドメイン

ソフトウェアシステムの中で、重要な部分はどれか? エヴァンスのドメイン駆動設計で、「コアドメイン」という1つのパターンとして紹介された。

  • コアドメイン絶対主義
    ソフトウェアシステムには、最も重要なドメインがただ1つ存在すると考えている。
  • コアドメイン相対主義
    ソフトウェアシステムの開発時期などによって取り上げる部分、つまり開発者が対象として見ている部分がコアである。関わる人たちの意思によってコアが決まる。
  • 非コアドメイン主義
    ソフトウェアシステムを構成する個々のドメインにはそれぞれ意味・役割があり、どれか1つを絶対的に重要視することはない。

エヴァンスのドメイン駆動設計では、コアドメインに最も優秀なメンバーを投入せよ、コアドメインを見つけよ等、コアドメイン絶対主義的に読める表現がある。しかしその一方で、コアドメインは、別のアプリケーションにとっては補助的な汎用コンポーネントになるといった記述もあり、コアドメイン相対主義の雰囲気もある。しかし、どちらかといえばコアドメイン絶対主義なのだろう。

しかし、ヴァーン・バーノンの実践ドメイン駆動設計では、複数のチームが異なる対象を担当する。これはコンテキストが違うというだけでなく、それぞれのチームが作り上げるコアが異なると見ることもできるだろう。したがって、ややコアドメイン相対主義だといえる。

コプリンのマルチパラダイムデザインでは、コアドメインという用語は登場せず、問題ドメインや解決ドメインが大小さまざまなドメインによって構成され、そのどれも等しくドメインと呼ぶ。したがって、非コアドメイン主義だといえる。

他方、伝統的なソフトウェア工学およびドメイン工学ではコアドメインという用語は使われず単にドメインと呼ばれるが、それが指すものはいわゆる業務システムのための仕様群であることが多く、実質コアドメイン絶対主義に近いといえる。

オブジェクト

ソフトウェアシステム開発には様々なパラダイムが使われうる。その中のオブジェクト指向のみに焦点をあてても、とても多くの立場がある。「オブジェクトはどこからくるのか」という考えをよく表す軸を1つ取り上げる。 

オブジェクトの由来

  • 自然オブジェクト主義
    ソフトウェアシステムの概念を構成するオブジェクトは、本来現実世界に存在するモノを写し取ったものであるべきと考えている。
  • 自律オブジェクト主義
    ソフトウェアシステムの概念を構成するオブジェクトは、それぞれ自律的な存在であるべきと考えている。
  • 人工オブジェクト主義
    ソフトウェアシステムの概念を構成するオブジェクトは、現実世界の存在や人間の行動様式、概念を参考にしながらも、ソフトウェアの中でうまく機能するように作られた人工物だと考えている。

オブジェクト指向の発明者であるアラン・ケイの文脈では、メッセージによって自律的に制御されるのがオブジェクトだ。

これとは別に、オブジェクトはあくまで現実世界を写し取ったものであるべきとする立場がある。可能な限り現実世界の有様を忠実に表現したオブジェクト群こそが変化に強くソフトウェアとして有益であるという立場だ。

その反対で、オブジェクトはあくまでソフトウェアシステムおよびプログラムコードの設計パーツとして捉え、さまざまな要請やその時使える技術インフラ、プログラミング言語の機能などから、開発者が作り出すものという立場もある。

 

私の世界観

上に挙げた軸から、私が現在どのような世界観を持っているのかを選んでみると、以下のようになる。

  • 複数ドメイン的世界
  • 非コアドメイン主義
  • 人工オブジェクト主義

今の私の考えでは、ドメインが指す対象の粒度はかなり細かい。エヴァンスの書にあるような「輸送」「販売」などをドメインと呼ぶのは間違いではないにしても、ほとんどの場合、その大きさの単位をそのまま扱うようなことがないので、それを1つの範囲として実感しづらいのだ。もっと細かな業務単位だったり、業務に必要な機構だったりをドメインと呼んでいる。ソフトウェアシステムであれば、コンポーネントくらいの単位だ。リクエスト、レスポンス、コネクション、ステートマシン、ストリーム・・・。それぞれが何か1つの概念で表される固まりをドメインと呼んでいる。

これらの細かなパーツが組み合わさり、折り重なりながらソフトウェアシステムを作る。システムには「仕様」というものがあるが、それは商取引のルールと同じようなレイヤーのものだけではない。たとえば、ユーザー向けの分かりやすいユーザーインターフェイス上で作られる情報群を、システム内部に持っている計算ロジックモデルへの入力を表わす情報ツリーに変換して処理するような機能があるとする。この機能において、システム的に重要なのは、ユーザーが操作する部分の情報の構造だろうか? それとも、内部に持っている計算ロジックやそのための入力情報の構造の仕様だろうか? 後者はユーザーが操作するソフトウェアの表面の仕様と何らかの関係はあるにせよ、ソフトウェア内でそれが表される位置やレイヤーは、どちらかというとソフトウェアの内側にあるだろう。さらに付け足すと、この計算ロジックの処理のための数学的な演算機構は、コンポーネントとして独立して作られている、なんてこともある。

何が言いたいのかというと、どれかをコアと定めることはさほど有益ではないと考えているということだ。

そして、上に挙げた「パーツ」というのは、とても人工的だ。何も無いところからスタートしなければいけない場合を除いて、通常は、目の前に人が作ってきた何かがある。自分たちで作ってきたシステムもそこに含まれる。そこにある問題を解決するための方法を大なり小なり考案しなければいけない。既存のソフトウェアや要望と、開発者が持っているプログラミング言語などの道具、新しい技術などから、解決策が生み出される。解決のための仕組み・モデルは、常に開発者が設計し、作り出すものだと考えている。

 

おわりに

自分が持っている世界観を考えてみるというのは、とても面白いし、そんな世界観を議論しあうような場があれば、是非参加したいと思う。だが、語ったり議論したりするには、いくつもの軸を明確にしておく必要もある。そういった理解の積み重ねが必要だから、難しい。

「語りえぬものについては、沈黙せねばならない。」

と、どこかからお叱りを受けぬよう、ソフトウェア開発者として語りうる地平を地道に広げていきたい。

 

「たとえる技術」を読んだ

せきしろ著『たとえる技術』を読んだ。国語に対するニガテ意識が消えない私が、文章になんとかオリジナリティのあるたとえを入れてやろうと、つい頭をひねってしまうほど、たとえ方の技術がやさしく語られた本だ。

たとえる技術

たとえる技術

 

この本では、「たとえる技術」が、時折クスッと笑ってしまうようなたとえの例とともに語られる。この本を読んで私が強く感じたのは、「たとえって、パーソナルな体験の表現で良いのだ」ということだった。本の中では、共感を得やすいたとえを生むために選ぶと良い題材なども紹介されていたので、一般的にはそのようなたとえ方の技術を磨くとよさそうだとは理解できる。しかし、私はそういった共感を得る技術としての「たとえ方」よりも、そのたとえを作り出す話者の経験などに興味が湧いた。著者せきしろ氏が人生でこれまで見てきたであろう風景、感動したであろう出来事などを想像せずにはいられなかった。そこから作られる、全然おもしろくないたとえ、共感されないたとえ。それでも、何らかの話者の体験が、別の体験とあるポイントで結び付けられた結果として生まれるのがたとえだ。「これとそれを、そんなところで結びつけるのか!」という驚き。世界で初めて塩キャラメルを食べた人が感じたであろう、未知の組み合わせ方の面白さが、私には強く印象に残った。

 

そして、これからは積極的にたとえを使ってやろうという気分はすごく高まった。まるで、ためしてガッテンで「たとえを使うと脳に良い」なんて放送された直後のように、私の中でたとえがブームになっている。

私の国語に対するニガテ意識は、この先まだまだ克服できそうにないが・・・。