プログラマの思索

ソフトウェアの本質的な問題とは何だろうか？
僕は、「ソフトウェアの複雑さをどのようにして手なづけるか？」という問題だと思う。
以下、ラフなメモ書き。

【1】問題提起

ソフトウェアをインタプリタのように、書いては動かし、というやり方で作っていく時は楽しい。
しかし、じきに、行数が大きくなり、ソースファイルを分割して、クラス設計していくうちに、どんどんソフトウェアは肥大化し、複雑になっていく。
大人数で開発し始めると、当初の設計思想や開発の規律からズレ始める。

ソフトウェアの複雑さをどのように手なづけて、制御していくべきか？
その問題を幾つかの観点から考えてみる。

【2】単純な解決法～間接層を設ける

一つの塊で実装するのではなく、分割する。
その時に、間に「間接層」を入れる。
例えば、DAO、サービス層かな。
ダイクストラの下記の言葉を思い出す。

another level of indirection
「もう一段の間接参照」を導入すると、コンピュータのほとんどの問題は解決できる。

ポインタを制する者はプログラミングを制する: プログラマの思索

florigenの日記

複雑さを間接層に押しこむことでスッキリするが、じきに複雑さは手に負えなくなる。

【3】DOAの発想

DOAでは、全システムのデータベース層を一元化する方針。
この最たる例がERP。
データを一元化すれば、データ保守がやりやすくなるし、データの精度も高くなり、データを再利用しやすくなる。
つまり、複雑さをデータ層に押しこむ。

この発想を推し進めたのが渡辺幸三さんの三機能モデル。
「業務層(ユーザの業務フロー)とデータ層(DB)に複雑さを集約し、機能層(システム)は複雑にしない」という方針。
データを重視するからこそ、データ入力やデータ保守を行う業務を複雑にしてでも、データの精度を上げる方向へ持っていく。
下手にシステムの機能をリッチにして、どんなデータでも入力できるようにすると、データの精度が落ちてしまう。

しかし、データの一元化を推し進めたERPの導入は、今となっては負の遺産に近い。
ERPのパラメータを覚えるのが業務SEの仕事みたいになり、業務設計のノウハウが消えてしまった。

また、ERPは業務の標準化を押し付けるために、独自の業務を行うユーザ企業にはフィットしない場合がある。
結局、ERPを単なる帳票出力システムとしてしか使えない事例も多い。
逆に、ERPをカスタマイズしすぎて、VerUpなどの保守コストが増えるデメリットもある。

【4】OOAの発想

OOAでは、部品オブジェクトを作り、再利用する方針。
いわゆるコンポーネント設計。
複雑さをコンポーネントに押し付けて、外部から必要なAPIを使う。
カプセル化、情報隠蔽の発想。

例えば、.NETのDLLやJavaのJar、Warのようなコンポーネント。
Javaでは、EJBがその理想に近かったのではないか。

しかし、部品の再利用は難しい。
ビジネスオブジェクトのような粒度の高い部品はなかなか作れない。
ソフトウェアプロダクトラインが「コア資産」という概念で、再利用できるコンポーネントを生み出そうとしたが、共通の原則を見出しにくい。

また、一つのシステムを作るために、コンポーネントをつなげるノリの部分の開発が難しいのだ。
ノリの部分がコンポーネントよりも大きなソースになってしまいがち。

他にSOAのように、複数のシステムをEAIのようなツールでシステム連携し、サービスと見なして統合する手法もあった。
しかし、システム連携の開発が正直難しいのだ。
「ドメイン駆動設計」でも、「顧客・供給者の開発チーム」パターンや「順応者」パターン、「腐敗防止層」パターンなど、色んな手法を使わざるをえない。

結局、フレームワークのような開発基盤しか、再利用できるシロモノは作れなかったように思える。

例えば、アジャイル開発の戦略では、優れたフレームワークを開発基盤として用いて、アーキテクチャをできるだけ固定化しておき、フレームワーク上の薄いロジック層をアジャイルに開発していく。
つまり、要件や仕様というスコープ変更に重点を置き、アーキテクチャのリスクをフレームワークで無くしておいた方が、アジャイルに開発はしやすい。

他に、継続的デリバリーはどうか？
継続的デリバリーは、あくまでも開発プロセスのリードタイム短縮に焦点を置いているのであり、ソフトウェアの複雑さを解消しようとする方法ではないと考える。

【5】最近の傾向

ソフトウェア開発がコモディティ化している現在、ソフトウェアの複雑さをどのように手なづけようとする方向に向かっているのか？
僕はその方向性を知り尽くしていないが、ファウラーの話を読むと、「犠牲的アーキテクチャ」「マイクロサービス」の概念が見て取れる。

Martin Fowler氏の語る“犠牲的アーキテクチャ"

マイクロサービスとSOA

マイクロサービス設計概論

犠牲的アーキテクチャ～リプレースを正当化するアーキテクチャ: プログラマの思索

マイクロサービス～疎結合なアーキテクチャが時代に合っている: プログラマの思索

【5－1】犠牲的アーキテクチャ

システムのアーキテクチャを定期的にリプレースを実施するやり方。
フレームワークや開発基盤を定期的に入れ替える。
複雑さを押し込めるのではなく、複雑さを解消できなくなったら、定期的にリプレースしてしまう。

すごくリスキーなやり方に思えるが、このやり方を採用したい時もある。
ハードの進化、ソフトウェアの技術動向の変化などによって、アーキテクチャそのものの寿命がすごく短くなっているからだ。

例えば、以前はStrutsで作っていたが、StrutsがVerUpしなくなって、順次Railsに入れ替えた。
しかし、アクセス数が多くなり性能要件に問題があるから、Scalaに順次置き換えた、とか。

犠牲的アーキテクチャを採用する場合、どのタイミングで再構築すべきかという意思決定と、再構築の方法が問題になるだろう。
リプレースできるようなアーキテクチャは、どんな構造であるべきか？

【5－2】マイクロサービス

一連の小さなサービスで1つのアプリケーションを開発する手法。
「ドメイン駆動設計」の「境界づけられたコンテキスト（Bounded Context）」パターンや「公表された言語（Published Language）」を使う。
例えば、REST APIとかJSONとか。
マッシュアップが一番の例だろうか。

サービスごとにモデルのコンテキストがあり、サービス同士のI/Fがコンテキストの境界になる。
サービス同士のI/FがREST APIのような「公表された言語」で、やり取りされる。

今は、Google、Amazon、Yahooなど色んなWebサービスが公開されていて、それらを連携するだけで色んなアプリが作れる。
GoogleMapが一番良い例。

Webシステムの機能は、色んなマイクロサービスの集合体に置き換える方式であってもいい。

ビジネス的には、いわゆる外部接続用のI/Fを公開して、たくさんの開発者に使ってもらう方がメリットがある。

マイクロサービスの利点は、他のサービスと独立しているから、デプロイ＆リリースを頻繁にできたり、スケールアウトしやすかったり、障害の影響を最小限に抑えられる点があるだろう。

"Microservices"を読んだ | SOTA

(引用抜粋)
・Microservicesはライブラリを使うが，主要なコンポーネント化はサービスへ分割することで行う
・Microservicesでは，チームはプロダクトを持っていると意識する
・Microservicesはビジネス能力に基づきサービスの分割を行う
・Microservicesアプリケーションは，出来るだけ粗結合であることを目的にする
・Microservicesは適切な場所で適切なツールを使うことを好む
・データの分散管理は更新管理に影響を与える
・Microservicesアプリケーションは，継続的デリバリーや継続的インテグレーションの経験をもつチームによって構築されている
・サービスをコンポーネントとして扱うため，アプリケーションはサービスの障害に耐性のあるように設計される必要がある
・サービスの分割により開発者は変化のスピードを落とすことなく変更をコントロールできる
(引用完了)

マイクロサービスは、Webシステムにおけるコンポーネントとイメージできるのではないか？
だとしたら、マイクロサービスに複雑さを押し付けた反面、マイクロサービスで取得したデータを組み立てるノリの部分の開発が膨れ上がる場合もあるだろう。

つまり、複雑さをマイクロサービスへ押し付ける場合もあれば、マイクロサービスの呼び出し側に押し付ける場合もある。

【6】「ソフトウェアが宿命的に抱える「複雑さ」をどのように手なづけるか？」という問題は、たぶん絶対唯一の回答はないだろう。
ただし、その時代に合った手法と概念が生まれて、特定の状況では問題の一部が解決できる。

今後も問題意識として持っていく。