「障害物が道をつくる」という考えを最初に言語化したのは、2019年のClassi Angular Nightというイベントでの登壇だった。ここではAngularを学ぶうえで考えてほしい「フレームワークとは何か」ということを話していた。最近このことについてまた考えていたので、あらためて当時話した内容をもとに、ブログにも残しておこうと思う。
制約による誘導
フレームワークと呼ばれるものの目的を抽象化すれば、問題を解決するために選びうる選択肢の中から、ある特定の選択肢を選び取るように、利用者を誘導することだろう。多少のグラデーションがあるにしろ、同じ性質をもっていると思う。そして、その誘導の形式が制約による誘導であることが、フレームワークをフレームワークたらしめる本質的な部分だと思う。
ただ導くだけならば「ベストプラクティス」を教えるガイドでもいい。こうするのが正しい、こうするのは間違っていると、知識によって誘導するやりかたもある。啓蒙による誘導といいかえてもいい。一方、フレームワークと呼ばれるものはそうではない。フレームワークは、その設計者にとって選んでほしくない選択肢を選びにくくすることにより、選んでほしい選択肢を選ばせるのだ。バッドパターンは選びにくく、グッドパターンは選びやすいような、特殊な状況の中に利用者を置くことにより、特定の選択肢を選び取るように導いている。これが制約による誘導である。
障害物が道をつくる
制約による誘導をイメージするのにもってこいなのは街の道路だ。車を思いどおりに走らせるにはどうすればいいだろうか？地面に線を引いて「この線のとおりに走らなければならない」と啓蒙すればいいだろうか。もっといい方法がある。その経路以外を通れないようにしてしまえばいいのだ。障害物を置き、進めない領域を明確にする。道は「障害物のない経路」としてそこに現れる。
渋谷のスクランブル交差点を見れば、横断歩道という「あるべき形」の啓蒙だけでは実効性をもたないことがわかる。最短経路に障害物がないなら、そこが道になるのは自然なことだ。また同時に、これは制約による誘導の限界も示している。最短経路を歩かせたいなら制約は足かせでしかないということだ。制約による誘導にできることは、最短ではないがそれ以外の利点がある「回り道」をあえて歩かせることだ。
フレームワークは常に「回り道」
ソフトウェア開発におけるフレームワークについて考えるときには、フレームワークそれ自体と、それに同梱されているライブラリのことを区別しておかなければならない。フレームワークを採用するということは、なんらかの制約を受け入れることだ。それはフレームワークを採用しない場合と比べて、常になんらかの形で「回り道」である。
もしフレームワークを採用することが近道だと感じられたとしたら、それはそのフレームワークに付随するライブラリによるアウトソーシングの恩恵か、制約によって問題が単純化されているためだ。道路においては、障害物があることで経路が制限される代わりに、「ぶつからないように進む」という複雑な問題を信号機や道路標識などでシステム化できる。同様に、ある種の制約を受け入れることで選択肢が狭まり、特定領域の問題が単純化され、ライブラリによる汎用の解決手段を適用できるようになる。
だから、フレームワークがそれを好まない人にとって回りくどいものであるのは必然的だ。本質的に、あえて回り道をするための道具であり、問題を最短経路で解決するための道具ではない。その代わりに、フレームワークが提供するのはデザインされた道だ。最短ではないが、その道にはかならず設計者のねらいがある。「何を大事にしながら問題を解決したいか」という価値観がそのデザインに宿る。だから、フレームワークの採用には、思想・価値観への共感が重要だ。自分が大事にしているものを同じように大事にしてくれることが感じられるからこそ、あえて回り道をすることを受け入れることができる。