コレオグラフィ: 開発者が参加・離脱しやすいアーキテクチャを考える

Cotoami のアーキテクチャを、どのような体制、あるいは場を作って開発したいのかという観点から考えてみたい。いわゆるコンウェイの法則に沿ったシステムデザインである。

現状のシステム、つまり Oinker.me のアーキテクチャは以下のようになっている。

oinker

Grailsフレームワークを利用して実装されたアプリケーションサーバーが中心となり各種サービスの連携を計る、いわゆるオーケストレーション (orchestration) モデルのアーキテクチャである。

マイクロサービス本でも指摘されているように、オーケストレーションは素直なアーキテクチャではあるが、システムを拡張する度に指揮者となるサービスに手を入れる必要がある。例えば、現状 Oinker の検索エンジンは壊れているのだが、この修正を誰かに頼みたいと思ったら、まず指揮者となるサービス(Grailsアプリケーション)について理解してもらう必要がある(「え、今更Groovyを勉強しないといけないの?」)。これは指揮者が肥大化すればするほど骨の折れる作業になる。

多くの組織で開発言語を統一しようとするのは、おそらくこのオーケストレーションの仕組みに起因している。メンバーが同じ言語や環境に習熟していないと共同開発が難しくなるのである。

しかし、新しいものを生み出そうとする場合、様々なレベルにおいて多様性を損なう事は長期視点で考えるとマイナスになると筆者は考える。システムデザインにおいて「一貫性」は抗い難い誘惑だ。しかし、システムや組織が進化するためには、多少のいびつさを許容しなければならない。そのいびつさを許容する仕組みが、最近耳にする事が多くなって来た「コレオグラフィ (choreography)」モデルのアーキテクチャにあるのではないかと考えている。

ThoughtWorksのサイトに、オーケストレーションとコレオグラフィの違いを表す図が紹介されている。

オーケストレーション:

Dependency graph in a real world orchestrated microservice project
Dependency graph in a real world orchestrated microservice project

コレオグラフィ:

Dependency graph illustrating the concept of a fully choreographed set of microservices
Dependency graph illustrating the concept of a fully choreographed set of microservices

コレオグラフィアーキテクチャによって、システムを構成する各サービスの連携が疎結合に保たれ、かつ、非同期の連携なので全てのサービスが同じ負荷に耐えなくても良いというおまけも付いてくる。システムに新たな機能を追加する場合に参照するのは、指揮者となるサービスではなく、システムの拡張点となるイベントである。追加機能の起点となるイベントだけに着目すれば良いので、イベントを受け取れる限り、どのような言語・環境でサービスを開発しても良い。既存システムを変更せずに機能を追加出来るのはもちろん、いらなくなった機能を捨てたり、新しい言語で実装し直したり、ということも容易になる。

と、ここまではあくまでWebや書籍でかじった知識で書いている机上の空論に過ぎないので、この考えがどれぐらい有効なのかはまだ分からない。Cotoamiプロジェクト上で検証して行きたいと思う。

今のところの感覚では、イベント駆動という連携が、RESTのような従来型の連携に比べて複雑なのは明らかで、だからこそ、コレオグラフィは同じ言語で実装された統一的なプラットフォームの上で実現するという流れが強いように感じる。だけども、それではサービスの多様性を実現するための疎結合という理想からは離れてしまう。おそらくこの辺にコレオグラフィの辛みがあるのかもしれない。

あまり意識されないかもしれないが、言語やプラットフォームを統一するのは、それはそれである種の密結合である。今は目眩を覚えるほどの多様性が言語やフレームワークにある時代である。その多様性の中で独自性を得ようとするエンジニアの力を借りるために、この密結合はデメリットとして働くのではないかと今のところは考えている。

組織やチームの話を追いかけると、プログラミングは基礎教養なんだって話に辿り着いてしまう件

まさにそんな感じの話がInfoQで紹介されていた。

『システムの科学』を読み解く (1) – 人工物の本質はインターフェースである

『システムの科学』という本をご存知だろうか?

ノーベル経済学賞の受賞者、ハーバート・A・サイモン氏によるシステム論の古典的名著、ということでその筋では有名な本であるらしい。初版が出版されたのが1967年というパーソナルコンピューティングの黎明期に当たる時代で、筆者が所持しているのは、改訂が重ねられて1996年に出版された第3版の邦訳本である。

システムの科学
システムの科学

原著のタイトルは『The Sciences of the Artificial』といい、『システムの科学』というよりも『人工物の科学』といった方がより原題に近いように思われるが、邦訳で前者を選択した経緯については訳者あとがきで説明されている。

「システムの科学」と言っても、何の話なのかぴんとこない人もいるかもしれない。「システム」とは、ある特定の目的を達成するように、複数の要素(部品)が組み合わさって出来たものだ。つまり「システムの科学」とは、今日「デザイン」と呼ばれているものの仕組みを、あらゆる学問分野の知見を総動員して論じたものだと言えば分かりやすいだろうか。

邦訳本のカバーには以下のような紹介文が書かれている。

「人工物の科学はいかに可能であるか」
本書は必然性ではなく、環境依存性 —「いかにあるか」ではなく「いかにあるべきか」— に関与するデザインの諸科学、すなわち人工物の科学(The Sciences of the Artificial)の本質を明らかにし、その可能性を問うものである。

筆者は10年以上前に、上の紹介文に惹かれてこの本を購入してみたはよいものの、難しくて最後まで読み通す事が出来なかった。何度繰り返し読んでもぼんやりとした感覚的な理解(分かったつもり)以上のものは得られなかったのである。最近、この本の存在を思い出して久しぶりに読んでみたら、相変わらず難しいとは感じるものの、当時よりも格段に理解出来るようになっていた。更に言えば、いくつかの事柄については腑に落ちるようになっていることに気づいた。

『システムの科学』で議論されていることの多くは、ソフトウェア開発者、あるいはプログラマが日常的に遭遇する問題とほぼ重なっている。ただちょっと異なるのは、その辺の技術書と比較して少しフレンドリーさに欠けているというぐらいである。というわけで、この連載では数回に分けて、この難解な本をソフトウェア開発の現場で役に立つような形で読み解いて行きたいと思う。

人工物とは何か?

そもそも人工物とは何か? 人が作ったものである、以上。

で終わってしまいそうであるが、それだけだと何の役にも立たない。辞書を引いてみると、対義語は「自然物」とある。人工物と自然物の違いは何だろうか?

『システムの科学』は自然科学の話から始まる。自然科学とは、この世に存在する事物を「分析」して、一見複雑に見える現象の背後にある、単純な法則を見つけ出そうとする学問分野だ。分析によって見つけた法則は一体どこから来たのだろうか? 例えば、万有引力の法則は、そのようなものが存在する事は説明してくれるが、それが何故存在するかについては説明してくれない。自然科学においてはそれらの法則がただそこにあると認識するだけである。

一方、人工物には存在理由がある。つまり「目的」が存在するのが人工物の特徴だ。

自然界にある法則を組み合わせて目的を達成しようとする。その時に生み出されるものが人工物である。サイモン氏は、このような人間の営みに科学的な解析を施して背後にある法則を探ろうと試みる。これが「人工物の科学」である。

人工物の本質はインターフェース

あらゆる人工物に共通する特徴は何だろうか? サイモン氏によれば、目的の達成というプロセスは、以下の三つの要素の関係によって成り立つという。

  1. 目的(ゴール)
  2. 人工物の特性
  3. 人工物が機能する環境

この三つの要素の関係を踏まえて人工物を表現したのが以下の図である。

outer-inner

とても単純な図である。人工物とそれが機能する環境は「インターフェース」という境界で区切られる。人工物の内部を「内部環境」と呼び、外側を「外部環境」と呼ぶ。

外部環境と内部環境がうまく噛み合って人工物が期待通りの振る舞いをするとき、その人工物は目的を達成することになる。ここで重要なのは、人工物が期待通りの振る舞いをするとき、そこに関わっている条件は外部環境と内部環境のほんの一部分に過ぎないという事だ。その目的を達成するために必要な、最低限の条件を表すのが「インターフェース」という両環境の接面であり、ここに人工物の本質が現れることになる。

interface

例えば、移動手段としての車について考えてみよう。この場合、外部環境で目的の遂行に関わって来そうなのは、移動範囲の地面の状態、という条件がまず思い浮かぶ。そして、内部環境として車輪の存在を前提にすれば、地面の状態にあった車輪の素材と形状、そしてそれを楽に駆動させる何らかの仕組みがあれば、移動という目的には事足りる。このように考えると、移動手段として車を捉えた場合、我々が一般に思い浮かべる車のほとんどの要素はその目的とは関係のない事が分かる。

外部環境が決まれば、そこに適応しようとする人工物の目的から鑑みて、内部環境の知識はほとんどなくともその人工物の振る舞いを予測することが出来る。逆に言えば、この合目的な振る舞いを維持する限り、内部環境はどのようなものでも良いということになる。例えば、飛行機と鳥は、同じ環境において「空を飛ぶ」という共通の目的を持ちながら内部環境は全く異なる。

今、「鳥」という例を出したが、実は人工物でなくても、何らかの状況に適応していると見なし得るすべてのものについて上の図式が当てはまることに注意したい。その意味で、『システムの科学』で展開されている内容は「何らかの状況に適応していると見なし得るすべてのもの」についての考察であって、人工物に限った話ではない。それが邦訳者が「システム」という言葉を選択した理由だろうと思う。

さて、ここまで読んで頂けたプログラマの方々には、このような人工物の捉え方に比較的親近感を感じる方が多いのではないだろうか? というのも、この人工物の捉え方はオブジェクト指向のモデルとほぼ一致するからである。ということは、オブジェクト指向の「オブジェクト」というのは、人工物あるいは「何らかの状況に適応していると見なし得るすべてのもの」のメタファーだと言って差し支えないように思える。

プログラマは、ミクロのレベルで、インターフェースのデザインという問題に日常的に向き合っている。この試行錯誤によって身についたノウハウはマクロのレベルにも応用出来るはずである。プログラムだけでなく、プロダクトや組織のデザインもサイモン氏のモデルによれば本質的には同じ構造になっている。注意しなければならないのは「目的」を誤らないということだけである。

コンピュータは最も純粋な人工物

『システムの科学』には、機械のように物理的な人工物だけでなく、組織や社会といった実体のないものまで、ありとあらゆる人工物が登場する。その中でもコンピュータは「記号システム」という特殊な存在として紹介されている。

記号システムとは、記号(文字やマークなどの物理的パターン)を処理するシステムで、記号を保存したり、変更したり、出力することが出来る。一般的には「情報処理システム」と呼ばれるものである。コンピュータだけでなく、人間の脳も記号システムだと言える。

記号システムは、記号が表現出来る範囲において、どのような外部環境にも適応する事の出来るアメーバのような究極の「適応システム」である。先ほど紹介した人工物のモデルで言えば、インターフェースをどのようにも変更出来るシステムだということになる。まさに人工物のモデルをそのまま体現したかのような純粋な人工物だ。

昨今のITの世界に目を向ければ、あらゆるものがソフトウェア化していく時代である。一昔前はハードウェアの領域だったものの多くが、今ではソフトウェアとして表現され、操作されるようになっている。つまり、世の中の多くのものが記号で表現・操作出来るようになってきた。思えば、ガラケーからスマホへの移行も、インターフェースのアメーバ化として捉えられる歴史的な出来事だった。そう考えると、『システムの科学』のような、人工物に関する抽象的な議論の重要性というのは、かつて無いほどに高まってきていると言えるのではないだろうか。

『システムの科学』を読み解く (2) – 経済学ってそもそも何なのか問題

ビジョンを曇らせる誘惑: 技術偏重、一貫性

James Hague (@dadgumjames) 氏は、少年時代に一世を風靡した『パックマン』などのゲームに影響を受けてプログラミングを始めた。高校時代にはコンピュータ雑誌の常連投稿者として活躍、大学卒業後もゲームプログラマーとしてSNES(海外版のスーパーファミコン)向けのゲームを開発した。当時はアセンブリ言語で開発していた彼も、次第にマンネリを感じて高級言語を物色し始め、丁度その頃オープンソース化された Erlang で関数型プログラミングの門戸を叩いて今に至る。

パックマン from Wikipedia

そのようなキャリアを持つ彼が、長らくプログラマとして活動する内に気がついた事があると言う。それは、いつの頃からか新しいアプリケーションをデザインする時には、技術的・実装的な見地から逆算的に物事を考えるようになり、ユーザーやプレイヤーの観点から完成品を想定することが少なくなっていたということだった。

技術者は長くその専門領域に棲息するうちに、その領域の尺度だけで物事の良し悪しを判断するようになる。技術者のコミュニティでは、そのような尺度の元に序列付けが行われて、個々の技術者にプレッシャーを与え続ける。その結果として、何のためにそのアプリケーションを開発するのかということは脇に置かれ、パフォーマンスやプログラムデザインのような技術的達成が優先的に考慮されるようになる。

Hague 氏がプログラミングを始めた頃、プログラミングは彼のビジョンを実現するための道具に過ぎなかった。しかしそれが、プログラミング自体にのめり込むにつれて次第に自己目的化してしまった。そのねじれを解消するために、もう一度原点に戻ろうという思いがこの The Recovering Programmer というタイトルに込められている。

前回の記事「TDD再考 (8) – 凝集性(cohesion)とは何なのか?」で紹介した論理的凝集と機能的凝集の対立もこの問題と密接に関係している。アプリケーションの目的から考えれば機能的凝集を目指すべきところでも、油断すれば技術偏重に陥り、論理的凝集を優先してしまうことになる。そしてこの問題は Hague 氏だけでなく、このブログでも紹介してきたように、ビジネスと技術の対立を解消すべく現れたアジャイルムーブメントによってもフォーカスされてきた。特にその流れの中で提案されたドメイン駆動設計(Domain-driven design, DDD)は、機能的凝集に集中するための方法論だと考えると分かりやすいかもしれない。

アジャイルが指摘したのは、機能的凝集は動くターゲットであるということであった。それまでのソフトウェア開発で念頭に置かれていたような静止したゴールは存在しない。継続的に効果を得るためには、ユーザーとのインタラクションを重ねて、ユーザーにとって意味のある「文脈」を構築していかなければならない。

デジタルマーケティングの世界で長年活躍してきた Joanna Lord (@JoannaLord) 氏は、ブランドマーケティングの観点から、一貫性への過剰な執着がブランドの機能的凝集(coherence)を損なう要因になり得ると指摘する。

彼女によれば、ブランドの一貫性とは、裏を返せばそのブランドが変化せず、(環境が変わっても)常に同じ体験を提供し続けるときに実現されるものだと言う。コメント欄で指摘されているように、コカコーラのような長い歴史の中でブランドが確立しているようなケースではその一貫性を維持する理由があるが、現代の状況の中で新しいブランドを構築していかなければならない場合、一貫性より機能的凝集を目指さなければ生き残りは難しい。

一貫性というのは分かりやすい価値であるが故に過剰に追求されやすい。そして、一貫性を保とうとすれば、新しいアイデアを試したり、大胆な変更を行う事に対して臆病になってしまう。その結果としてユーザーにとっての価値、つまり機能的凝集が時間とともに失われてしまうことになる。