『クリーン・アーキテクチャ』を読んでフレームワーク中心主義からの脱却を考える

　 Hanami に触ってみたことを動機として、『クリーン・アーキテクチャ』を再読した。

　たぶんに漏れず、例の同心円の図ばかり印象深く記憶していたが、改めて精読してみると、この図にはごく軽くしか触れられない。むしろ繰り返し主張され、議論の中心を占めるのは、「決定を遅らせること」というアドバイスである。

アーキテクチャの形状の目的は、そこに含まれるソフトウェアシステムの開発・デプロイ・運用・保守を容易にすることである。それらを容易にするための戦略は、できるだけ長い期間、できるだけ多く選択肢を残すことである。¹

優れたソフトウェアアーキテクチャがあれば、フレームワーク、データベース、ウェブサーバー、その他の環境の問題やツールの意思決定を延期・留保できる。²

　要するに、データ構造とアルゴリズムこそがソフトウェアの中核であって、フレームワークやデータベースなど、具体的なプロダクトやツールについては「その他の詳細」に過ぎないと言い切っている。

　こうした主張は、僕に DeNA と任天堂による「Super Mario Run」リリース時の逸話を想起させた。

　150ヵ国で同時にリリースし、リリース4日で4000万ダウンロードを達成したというモンスターアプリでありながら、バックエンドの構成を決定したのはリリースのわずか3ヶ月前だったという。

「『Super Mario Run』配信当日、そこに“ドラマ”はなかった」というキャッチーな見出しが付けられているが、これも要は、アプリケーションの中核となるビジネスルールはあらかじめ精確に定まっていて、そこにバックエンドを「プラグイン」するような構成になっていたためだろうと推測している。短期間での意思決定とリリースとはいっても、崩壊したプロジェクトのそれとは対極にある。改めて読み返してみても、「決定を遅延させる」という行為の絶好の例であろう。

アーキテクチャを守るためにフレームワークを捨てられるか？

　一般通念を打破しようとする意図があってだろう。6部構成の最終部では、「データベース」「ウェブ」「フレームワーク」のそれぞれが、実際のところソフトウェアの中心どころか、取るに足らない詳細に過ぎない、と断定している。

　「データベースは詳細」、「ウェブは詳細」、とここまではまあ理解できる。「フレームワークは詳細」と言われると、「そんな無茶な」と読まれる傾向があるらしい。というのも、ほかならぬ訳者ですら訳者あとがきにて次のように留保しているためである。

おそらく異論のある方もいらっしゃるだろう。私もすっきりしていない。たとえばウェブアプリケーションを開発するときに、フレームワークを選定しないことがあるだろうか？³

フレームワークから着手しないことが本当に正しいことなのかは、私にはまだよくわからない。本書で紹介されている例は、いずれも現代的なアプリの話ではない。⁴

　とはいえ、「ウェブは詳細」である。「ウェブアプリケーション」という概念自体が、ウェブというデバイスとアプリケーションのロジックをすでに結合させてしまっている、ともとれる。ウェブでも、APIでも、RPCでも、バッチでも、手段に関わらずに常に中心にあるべきロジック、そこから設計していくべき、ということになるのであろう。

　フレームワークとアプリケーションを結合させるのは危険だという主張は説得力がある。実際、われわれは通常フレームワークを従わせることはできず、フレームワークに従わされることになる。これは揺るぎない強制である。

　 Rails を例にとる。 Rails 6 で ActionText と ActionMailbox が追加されたとき、なぜ今になってこれらが機能追加されるのか、まったく意味がわからなかった。どうしてこのフロントエンド隆盛の時代に、こうした機能がビルトインライブラリとして提供されなければならないのか？　と。

　今になって思えば、これは hey.com への布石であったことがわかる。オピニオンリーダーでありトレンドセッターである DHH の手腕に文句はつけられない。hey.com はサーバーサイドレンダリングへの揺り戻しという文脈でも注目されているようだし、フロントエンド疲れもあってそれが新鮮に見えるのも確かである。なにより、この先どういう展開を見せるのだろうとワクワクさせられているのは事実である。

　しかしつまるところ、 Rails とは初めから今までずっと、 Basecamp のプロジェクト向けに最適化されたフレームワークであるということを、改めて認識しなければならないだろう。

　いうまでもなく、 Basecamp 自身が事業を立ち上げるに当たって、 Rails を利用するという選択肢は持たなかった。それどころか、そもそも開発言語に Ruby を選択するのだって、当時は相当にエッジの利いた判断だったのかもしれない。そのような環境から、今や揺るぎないフレームワークに上り詰めたアーキテクチャを生み出して、今の地位を築いている。このことは刮目に値する。

　これを踏まえた上で立ち戻って、自分にこう問いかけてみる。「フレームワークは詳細」というのは無茶な主張だろうか？

　無茶だと言いたくなる。しかしそれは実際には、「フレームワークがないと何もできない」という自分の未熟さを隠すために、議論を遠ざけようとする心の動きの現れではないだろうか？

オマカセからアラカルトへ

　Rails によって御膳立てされた API を使っているだけでは、いつまでも「自分の味」が出せない。「自分の味」などという不安定なものが混入しないように、 The Rails Way という不文律が与えられている、という見方もある。しかしそれではいつまでも与えられているばかりで、進歩がないじゃないか？　という思いで、こんな記事を以前書いた。

オマカセからアラカルトへ - ﾕﾕﾕﾕﾕ (https://jnsato.hateblo.jp/entry/2020/06/07/230000)

　それから、シリコンバレーの Rails エンジニアのアティチュードをひとつの逸話として提示しているこの記事にも、示唆を受けた。

シリコンバレーから失意の帰国をした十年選手のITエンジニア、生き残るため大学院で情報科学を学ぶ - Findy Engineer Lab - ファインディエンジニアラボ (https://engineer-lab.findy-code.io/engineer-lab/why-study-stem)

複雑な現実課題を解決するソリューションには、ありもののライブラリやフレームワークなどというものは存在しません。それぞれが自分の中に持った基礎的な道具を持ち寄って、その場でしか使えない「特別な鍵」を作り出す必要があります。基礎力のない応用はありえないのです。

　フレームワークは便利である。ライブラリも便利である。しかしそれらは詳細に過ぎない。詳細をいくら知り尽くしたところで、現実の問題は得てしてそれよりも遥かに複雑であるはず。

　現実のキャリアとして、フレームワークを拒否して業務を行うというのは難しい。研究職でもない限り不可能かもしれない。それでも、「フレームワークは詳細であり、些細なものである」という『クリーン・アーキテクチャ』の宣言は、これを心に留めるのとそうでないのとではキャリアの行く末すらも左右しかねないほど大きな認識を与えてくれる。

　それはつまり、任意のフレームワークを使いこなそうとしていくら努力しても、ある意味でそれは徒労であるという認識である。

　事業にしても、人生にしても、ありあわせの選択肢で満たせない要求というものは確実にある。既存の枠組み=フレームワークに振り回されるのではなく、より本質的な問題を発見し、取り組む。そういうスタンスをこそ、選択しなければならない。

　そんな思いを、僕は「オマカセからアラカルトへ」という言葉に表した。そしてそれは『クリーン・アーキテクチャ』の再読を通していっそう深められている。