フレームワークのジレンマ - おおたに6号機blog

フレームワークを作っている人にはいつもあるひとつのジレンマがあるんじゃないでしょうか。
それは機能追加によるフレームワークの肥大化です。
ユーザさんから言われた機能・自分達のチームでこれは良い！と思って入れた機能など
理由はそれぞれですが、フレームワークが形になってからの機能追加は進む一方です。
機能が増えればそれだけ故障箇所が増えるのと一緒です。また想定しない使い方をユーザさんが
してくる場合もあるでしょう。

自分もこのような機能追加は正しい・求められているんだとずっと思っていました。
今でも間違ったことだと思ってるわけではありません。
ただし、それには大きな前提があることにちょっとだけ気づいたのです。

それは、

最初に開発されたフレームワークの機能は十分に検討され、
厳選されたミニマルセットな機能以外はあってはならない。

という前提です。書いてみれば当たり前で拍子抜けされるかもしれませんが、
なんとなく実感できずにいたことが始めて実感できたような気がします。

どうしてもフレームワークを開発していると、誰かの期待に・要望に応えてあげたいという
気持ちが出てしまい、機能過多になりがちです。少なくとも自分はそうです。
しかし、それはフレームワークの意味の原点と比べると正解とはいえないんじゃないかなと思うのです。
フレームワークの原点は「制約を与えることによって、ある特化した領域で効果を出す仕組み」だと
思っているので、これにあてはめるとその制約が厳選されて洗練されていない限り、
ユーザさんの要望に応えて機能追加しても基本線がぶれるだけで、
結果として誰もおいしくない状況になってしまわないかなあと危惧してるのです。
しかし自分などは超人でもエスパーでもないので、どのような基本線でどのような制約が正しいのか、
一回作ってみないとまったくわからないです。
なのでそのまま素直に実行すると、

ひとまず作る
　→そのまま出来上がったものをテストしてリリース

ということになるわけです。これが今まで自分がやっていたことでした。

しかしそうではなく、本当は正式版（1.0）まではもしかしてこうすべき？と昨日考え付いたのが、

ひとまず作る
　→必要そうな機能と付け足していく
　　→ある程度固まったら、今度は機能を削っていく
　　　→削りに削って最後に残った厳選されたものだけをリリース
　　　　→順次ひいた部分からタイミングを見計らい適切に足しこんでいく。ただし緩やかな進化と後方互換を保って。

まだボコボコの理論（特に後半）ですが、「一回作ってみて、そこから機能を増やすことではなく削ることで価値を出す」、
これが注目してほしい点です。もしかしたら、開発版と安定版でやっているOSSなどは
こんなことをしているのかもしれないですね。だとしたらどなたか指摘もらえると嬉しいです。
機能を厳選する、この作業を意識的に「削る」という行為で補い、明確に意識しなくてはいけないポイントを
作ってあげるのが特徴です。副次的な効果としても、「削る」という行為が入るため、コードがあらかじめ「足しひきしやすい構成」になったりしないかなあという期待もあります。

またこの方法だと必然的に緩やかな進化にならざるを得ないと思っています。
他の方の感覚がどれくらいを緩やかと感じるのかというのはあるのですが、
急激に機能が追加されてユーザの要望に応えていくことは、削るという作業が
ひとつ多い分出来にくいように思うわけです。
その代わりに各リリースに意味づけ（と名前付け）をしてあげることで、
ある程度ロードマップを出すことが出来ます。
削った機能も削るというより今は外すという感覚に近く、また後ほど足しこむのです。
いつ足しこむか、はリリースプランを立てて、このタイミングで足そう、というのを
マッピングします。
テーマが絞れており、リリースプランがある方が開発する方もユーザさんも安心するんじゃないでしょうか。
また、開発ブランチを幾つか切る事である程度機能を先取りすることもできます。
なぜなら必要そうな機能の付け足しで既に機能はあるからです。問題はどのタイミングで改善されリリースされるか、だけの話なので。

なんとなく最初に描いたイメージは、お豆腐を作るときの豆乳を搾り出すところ。

ボウルにざると、固く絞ったさらしの布を重ね（または、さらしの袋を開く）「（4）」を入れる。
布の縁を集めるようにして包み、ねじって口をしっかり閉じ、ぎゅっと絞り、しっかりこし取る。
熱いので、厚手のゴム手袋などを使用する（やけどに注意！）。絞り出したのが豆乳、残ったのがおから。
http://www.itsudemoyumewo.jp/tsukurikata.htm

搾り出した豆腐は本質として売り物になり、残ったおからもそれはそれで立派に食べれる。
これがなかなか良いモデルかもなあと、ふと思ったきっかけでした。

課題はそれでユーザさんの要望にきちんと応えれるのかが最も考えるべきところですね。
またこれについては説明を繰り返しても、今すぐ使いたい！って言う人も勿論いるわけで
なかなか理解を得るのは難しいよなあと思います。
また、足しひきしている間に機能がバグる可能性も十分にあります。
仕様を明確にし、テストを繰り返し、サンプルを作成して、確認をきっちり行う必要があります。

で、まとめるとフレームワークのジレンマに対して、解決策を提示できてるわけではないですが、
初期に開発し持っている機能から厳選し削りに削りぬくこと・その後も各バージョンアップにテーマを
あたえ緩やかな進化をたどることで、もしかしたら少しは効果があるかもしれないと考えたのでした。

P.S.ちなみに正式版である1.0以降はどんな方法がよいかまだ見えてこないです。
それはそれで別の戦略が必要だと思います。