Design It! 読みましたか？（よい本ですよ！） Design It! ―プログラマーのためのアーキテクティング入門 ”設計スキルを成長させたいプログラマーに向けたアーキテクティングの入門書です。ソフトウェアアーキテクチャの基礎とデザイン思考の考え方から始まり、ソフトウェアアーキテクトとして、チームと共に優れたソフトウェアを作り上げていく方法を包括的に解説します。本書を読むことで、適切なステークホルダーを特定してニーズを理解する方法、アーキテクチャ上重要な要求に基づいて技術やアーキテクチャを適切に選択する方法、アーキテクチャを軽量かつ効果的に評価する方法、チームのアーキテクト力を高める方法などを学べます。モダンなアーキテクチャ設計のための実践的な手法が詰まった本書は、より良いプログラマー、技術リーダー、そしてソフトウェアアーキテクトになるために必携の一冊です。” ソフトウェア開発のアジャイル化が進み、ソフトウェアは生き物としてますます頻繁な変更にさらされるようになった。 アジャイルとアーキテクチャの民主化 アジャイル開発のアーキテクチャに対する基本スタンスは、最初に先読みをしすぎた設計(BDUF = Big Design Up Front)をしないということだ。設計に大きな先行投資をせず、動くソフトウェアを維持しながら進化させていく。アーキテクチャはこの繰り返しによって立ち現れてくるもの、実験と実装とユーザフィードバックの結果として「収穫」されるものである。中心となるユーザ価値から作りはじめ、イテレーションを繰り返しながら全体設計が現れてくる、というのだ。これは、これまでの大きな先行設計がかえってシステムを複雑にし、結局作らなくても良い汎用構造や複雑なメカニズムを作ってしまうというリスクを下げている。さらに、アーキテクトと呼ばれる神様が実装をせずに机上で架空のかっこよい構造を作り出してしまうことも避ける。アーキテクトとプログラマという構造ではなく、アーキテクチャを民主化した。ソフトウェアの機能は実装して動くとを確認しつつ、追加や変更を受け入れながら、リファクタリングによって内部の重複部分を取り除いていき、コードベースの成長にしたがって必要だった抽象構造が現れてくる、、、はずだ。 しかし、本当にそうだろうか？アジャイルとアーキテクチャ論は何度も議論になることがあった。特にリファクタリングの繰り返しによってのみ、アーキテクチャは本当に現れるのだろうか。それは現在意図している機能だけから作られるものだろうか。リアクタリングで扱い切れないような大きな変更はどう扱うのだろう。アーキテクチャは現在作ろうとしているソフトウェアの機能や非機能だけでなく、過去の経験や知見からもヒントが得られるのではないか。アーキテクチャは選択する、ものでもあるはずだ。BDUF は良くないとしても、NDUF(No Design Up Front)はあまりにもリスクが高い。私たちには、ENUF(Enough Design Upfront)をを作る活動、そしてそれを共有、維持、変更する活動が必要だ。 アーキテクチャとソフトウェア工学、パターン 本書は、この議論について現実的な視点で、アーキテクチャを作り出すための指針について書かれている。参考文献のリストやSEI/IEEEが定義するアーキテクチャへの言及を見れば、筆者が過去のソフトウェアエンジニアリングの要所を押さえていること、かつ、アジャイル方法論の発展の経緯や歴史についても造詣が深いことがうかがわれる。 本書の中で私が特に気に入っているのは、過去に特定され、名前が付けられているアーキテクチャーパターンが紹介されていること(7章)だ。アーキテクチャパターンを知っておくことは、最初の入り口を選ぶ時に大きな道しるべとなる。これらに縛られることは危険だが、発想の種を多く持つことはアーキテクトとして重要だ。そしてもう一つ、具体的になアクティビティが目的とともに紹介されていること(パート3全体)。このパートだけでも本書の価値がある。人の活動としてアーキテクチャづくりにアプローチしており、アーキテクトの道具箱として活動が具体的に紹介されている。アーキテクチャづくりはHow-Toとして書けるものではない。ステークホルダーとの必要なアクティビティを通して形作られていく。あるいは、それらのアクティビティそのものが創発的な合意形成であり、アーキテクチャだとも言えるだろう。 アーキテクチャとビジネス文脈 大切なことは、最良のアーキテクチャは、その文脈によって変わるということだ。文脈なしにアーキテクチャは成立しない。このことを強く思い出させる印象的なエピソードを１つ紹介しよう。Twitter は最初 Ruby on Rails で開発されたが、2009年ころからJVM(Java VM)ベースのアーキテクチャに移行し、レスポンスとスケーラビリティを改善した（O’Reilly OSCON Java 2011: Raffi Krikorian, “Twitter: From Ruby on Rails to the JVM”）。これは、大きくアーキテクチャを変更した商用アプリケーションの例だ。これは、最初のRuby On Railsの選択が間違っていたということではない。スタートアップでは、ビジネスとしてプロダクトが軌道に乗らない限り、資金は集まらない。twitter が最初からJVMを採用したとしたら、現在の成功はなかっただろう。スタートアップの段階では、Ruby on Rails の選択が素早いアプリケーションの構築とユーザーフィードバックに必要だったのだ。 アーキテクチャとコミュニティ（人） さらに、このアーキテクチャ変更に影響を及ぼしたのは、スケーラビリティなどの非機能要件だけではない。JVM 移行理由には、「より幅広いコミュニティからエンジニアを集められる」という「人」や「チーム」の観点も含まれていた。現在JVM上で動く言語が多くなっているため、様々な現代的言語が使えるようになり、このテクノロジをベースに使うことでコミュニティに発信し、それらが得意なより多くのエンジニアを参加できるようにするという狙いもあったのだ。アーキテクチャの設計もしくは選択には、こういった多様な視点の「文脈」が影響を及ぼす。スタートアップとして開発するのか、最初から多くのユーザーベースを扱うことが分かっているのか、では話が全く違ってくるし、実際に開発するエンジニアにはどのようなコミュニティに属するのか、にも影響される例だ。 […]