Hatena::ブログ(Diary)

おおたに6号機blog このページをアンテナに追加 RSSフィード

2008-06-27(金)

[]フレームワークジレンマ 07:36 フレームワークのジレンマを含むブックマーク

フレームワークを作っている人にはいつもあるひとつのジレンマがあるんじゃないでしょうか。

それは機能追加によるフレームワーク肥大化です。

ユーザさんから言われた機能・自分達のチームでこれは良い!と思って入れた機能など

理由はそれぞれですが、フレームワークが形になってからの機能追加は進む一方です。

機能が増えればそれだけ故障箇所が増えるのと一緒です。また想定しない使い方をユーザさんが

してくる場合もあるでしょう。

自分もこのような機能追加は正しい・求められているんだとずっと思っていました。

今でも間違ったことだと思ってるわけではありません。

ただし、それには大きな前提があることにちょっとだけ気づいたのです。

それは、

最初に開発されたフレームワークの機能は十分に検討され、

厳選されたミニマルセットな機能以外はあってはならない。

という前提です。書いてみれば当たり前で拍子抜けされるかもしれませんが、

なんとなく実感できずにいたことが始めて実感できたような気がします。


どうしてもフレームワークを開発していると、誰かの期待に・要望に応えてあげたいという

気持ちが出てしまい、機能過多になりがちです。少なくとも自分はそうです。

しかし、それはフレームワーク意味の原点と比べると正解とはいえないんじゃないかなと思うのです。

フレームワークの原点は「制約を与えることによって、ある特化した領域で効果を出す仕組み」だと

思っているので、これにあてはめるとその制約が厳選されて洗練されていない限り、

ユーザさんの要望に応えて機能追加しても基本線がぶれるだけで、

結果として誰もおいしくない状況になってしまわないかなあと危惧してるのです。

しかし自分などは超人でもエスパーでもないので、どのような基本線でどのような制約が正しいのか、

一回作ってみないとまったくわからないです。

なのでそのまま素直に実行すると、

ひとまず作る

 →そのまま出来上がったものをテストしてリリース

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



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

ひとまず作る

 →必要そうな機能と付け足していく

  →ある程度固まったら、今度は機能を削っていく

   →削りに削って最後に残った厳選されたものだけをリリース

    →順次ひいた部分からタイミングを見計らい適切に足しこんでいく。ただし緩やかな進化と後方互換を保って。


まだボコボコの理論(特に後半)ですが、「一回作ってみて、そこから機能を増やすことではなく削ることで価値を出す」、

これが注目してほしい点です。もしかしたら、開発版と安定版でやっているOSSなどは

こんなことをしているのかもしれないですね。だとしたらどなたか指摘もらえると嬉しいです。

機能を厳選する、この作業を意識的に「削る」という行為で補い、明確に意識しなくてはいけないポイント

作ってあげるのが特徴です。副次的な効果としても、「削る」という行為が入るため、コードがあらかじめ「足しひきしやすい構成」になったりしないかなあという期待もあります。


またこの方法だと必然的に緩やかな進化にならざるを得ないと思っています。

他の方の感覚がどれくらいを緩やかと感じるのかというのはあるのですが、

急激に機能が追加されてユーザの要望に応えていくことは、削るという作業が

ひとつ多い分出来にくいように思うわけです。

その代わりに各リリース意味づけ(と名前付け)をしてあげることで、

ある程度ロードマップを出すことが出来ます。

削った機能も削るというより今は外すという感覚に近く、また後ほど足しこむのです。

いつ足しこむか、はリリースプランを立てて、このタイミングで足そう、というのを

マッピングします。

テーマが絞れており、リリースプランがある方が開発する方もユーザさんも安心するんじゃないでしょうか。

また、開発ブランチを幾つか切る事である程度機能を先取りすることもできます。

なぜなら必要そうな機能の付け足しで既に機能はあるからです。問題はどのタイミング改善されリリースされるか、だけの話なので。


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

ボウルにざると、固く絞ったさらしの布を重ね(または、さらしの袋を開く)「(4)」を入れる。

布の縁を集めるようにして包み、ねじって口をしっかり閉じ、ぎゅっと絞り、しっかりこし取る。

熱いので、厚手のゴム手袋などを使用する(やけどに注意!)。絞り出したのが豆乳、残ったのがおから

http://www.itsudemoyumewo.jp/tsukurikata.htm

搾り出した豆腐は本質として売り物になり、残ったおからもそれはそれで立派に食べれる。

これがなかなか良いモデルかもなあと、ふと思ったきっかけでした。


課題はそれでユーザさんの要望にきちんと応えれるのかが最も考えるべきところですね。

またこれについては説明を繰り返しても、今すぐ使いたい!って言う人も勿論いるわけで

なかなか理解を得るのは難しいよなあと思います。

また、足しひきしている間に機能がバグる可能性も十分にあります。

仕様を明確にし、テストを繰り返し、サンプルを作成して、確認をきっちり行う必要があります。


で、まとめるとフレームワークジレンマに対して、解決策を提示できてるわけではないですが、

初期に開発し持っている機能から厳選し削りに削りぬくこと・その後も各バージョンアップテーマ

あたえ緩やかな進化をたどることで、もしかしたら少しは効果があるかもしれないと考えたのでした。




P.S.ちなみに正式版である1.0以降はどんな方法がよいかまだ見えてこないです。

それはそれで別の戦略が必要だと思います。

kensir0ukensir0u 2008/06/27 20:08 沢山の人に使ってもらう、ニーズを満たすという意味では機能追加は必須だと思います。
肥大化を避けるためには機能を細分化してそれを上手くジョイントできるような仕組みを設けると良いのではないでしょうか?Eclipseだってプラグイン方式ですし。

shot6shot6 2008/06/27 20:24 機能追加はユーザさんのニーズを満たすために必須だと勿論思いますよ。
ただその追加の仕方とタイミングというのは、自分はじっくり考えた方が
いいんじゃないかなあと思ってるってことです。
気持ち的には、すぐに修正して、すぐにリリースしたくなるんですけどね^^;

で、肥大化をさけるためにプラグイン形式というのも大いにありだとおもいます。
ただ、前提としてコア部分はミニマルセットであることが重要だなあというのを
感じた次第です。

kensir0ukensir0u 2008/06/28 00:36 それだと、極論としてJ2EEやJavaEEでいいじゃんってことになりますねw
ということで、まずは細分化の粒度をある程度方向づけする必要がありそうですね。
それが機能単位なのかなんなのかはわかりませんが。

あと、ユーザーの性質による部分もあると思います。
最適なものを作りたいなら1から作るべきですし、それだと時間が足りない場合は
スクラッチで作ったりしますし。スクラッチ(スクラッチ部分のテストが発生)するのがめんどくさいかつ、最適でなくて問題ないシステムであるならばフルスペック(スクラッチがないため連携テストの必要がない)のフレームワークもって来たりしますし。

かなり難しいのですが求められている重要なポイントを汲み取りその機能が最高レベルであればユーザーも増え、おのずと必要な追加機能は他者、有志でつくられていくと思います。で、追加機能がある程度標準的に使われだしたらそのうちコアに取り込むというスタンスでいいんじゃないかなと思います。

あと、機能の肥大化って当初の設計では予測していなかったほころびが発生しやすいのも事実ですが、学習コストの増加も否めないと思います。

ちょっと違うのですがOSにソフトをインストールする、アンインストールする。
で、ユーザーが最適なPCにする。この辺にもヒントがありそうな気がします。

kensir0ukensir0u 2008/06/28 00:47 >ちょっと違うのですがOSにソフトをインストールする、アンインストールする。
で、ユーザーが最適なPCにする。この辺にもヒントがありそうな気がします。

OSの部分に関してもですね、Windows2000からXpに変わったときなんですがWindows2000の支持が高かったように思います。同様にXpからVistaへの時もそうなのかなと・・
自分としてはXpで満足ですし、2000にファイアーウォールあればそれで満足するのかなとも思ったりします。

TomatoTomato 2008/06/30 00:53 非常に素晴らしい考察だと思います。

> kensir0uさん
> Eclipseだってプラグイン方式ですし。
shot6さんの言うように、「フレームワークの原点は「制約を与えることによって、ある特化した領域で効果を出す仕組み」」と考えると、なんだって足していければいいってことでもないと思います。

Eclipse等の様に汎用性が求められるものと、Webフレームワークの様な比較的小さな「とんがった思考」により作られるものでは、埋めることのできない違いがあると思います。
Seasar関連のプロジェクトはもともと生産性に比重を置いたプロジェクトが多いと思うので、ある領域に特化した汎用性の低いものが多いのは仕方ないことと思います。

当然ユーザのニーズを満たすのも重要なんだけど、フレームワーク(製作者)の志向性から言って、ニーズを受け入れられないことだって大いにあるものですよね。

従来のJavaEEな汎用的な考えの人は、この考え方が受け入れられない人も多い気がします。

個人的にshot6さんには、再びフレームワーク開発のリーダを務めて欲しいと考えます。
(ぜひ、とんがったやつをサンドボックスでもいいので)

Connection: close