フレームワークとは
設計思想の観点を大事にして考えると、フレームワークとは設計思想の柔軟性を犠牲に、チーム内の設計思想を調整・統一するコストを下げる働きを持つ仕組みである。
便利機能を抽象化して車輪としたライブラリと異なる点は思想の強制性である。
設計思想がないとき
共通認識となる思想がないシステムをチームで作るときは、何を実装するにしても設計・実装の方針が合わないことがある。
例えばReact + Reduxを使って状態をどこで管理するかというありふれたテーマですら、実装する内容によって状態の持ち方で議論になる。*1
たしかに議論を繰り返してチーム内での認識を徐々に揃えていけば最小のコミュニケーションコストで「いい感じ」に開発していくことは可能なのだけども、この時にできあがっているのは属人化された暗黙知でできたチームである。当然チームとしてのスケーラビリティなんてものはない。
例えばDDDを読む
私は読んだのだけども、一人で読んだら意味がなかった。ちゃんと業務で時間を取ってチーム全員が咀嚼できるまで読書会をして初めて意味がある。
しかし、読書会ですら書いてある内容の解釈を巡って暗黙知を育てていく過程があることは自明で、これは別の意味で「フレームワーク」を導入したことになる。
チーム全体で実装されるコードとしては何らかの合意された思想に基づいた、コードとしてのフレームワークには依存しない「よい設計」の成果が出てくるのだが、これもまたスケーラビリティには難がある。
言語化でも銀の弾丸にならない
チーム内の思想を言語化してドキュメントに落とし込めばよい。よいのはよいが、読書会で解釈の補強をする議論が必要なことと同じように言語化されたもので暗黙知を網羅することは難しい。*2
当然無いよりは相当マシではあり何もないよりはスケールするはずだが、人の流動に弱い点には代わりがない。
フレームワークと生産性のトレードオフ
フレームワークは何故必要なのかに立ち戻ると、「コミュニケーションコストを下げるために少ない人数（一人）で作ったほうがよいのでは」という仮説が出てくる。
しかし、常人の100倍の生産性を持った設計・実装スキル抜群の超人が居たとしても、思想の統一された集団には長期的に勝ち目がない。
ここで言う「統一された思想」とはコードとしてのフレームワークでもよいし、何らかの読書会で議論を重ねた結果でもよい。
よって、営利活動として収益を求めて競争をする限りにおいて組織はあったほうが強いし、組織内ではフレームワークが効率化に寄与するのである。*3
安いフレームワーク
そして、「コードとしてのフレームワーク」と「チームで議論した結果のフレームワーク」のどちらを重視するかという問題が残るが、これは各組織の現実に合わせて解く問題である。*4
作るシステムの規模が大きく関わる人が多いのならば後者の議論を行うコストが相当高くなるし、関わる人間が少なくてすむ要件のシステムを作るのなら他人の作ったフレームワークの制約は不便なものになる。*5
最も基礎的なフレームワーク
勉強・教養と呼ばれるものになる。例えば「計算量の計算ができるかどうか」「計算機で命令が実行される仕組みを知っているか」など。
ここまで書いて気づいたが、思想と知識を峻別する意味はないような気がする。思想が古くなり広範な合意が得られれば知識である。
こうした古典と呼ばれる知見は、より望ましい「チームで議論した結果のフレームワーク」を下支えする基盤であり、つまり古典の勉強は重要というありふれた結論が得られる。
そして、古典を無理やり教えてくれるのが大学であり、ちゃんと学んだ結果の学位は強いのである……。*6
おわり。
