まあ、日記です。
メニューだけ見たことある
フレームワークの選定というのが、いつの時代も浅いロジックで終わるのは、「ある意味では仕方のないこと」だと言えるのかも知れないと思うようになりました。
「多くのフレームワークに長けた人」なんてほとんど見たことないから
それは自分(jflute)も含めて。
昨今のフレームワークは非常に高度になり、多様な要求の中、フレームワークばかりでもない。複数のフレームワークに詳しくなってる時間もない。
そんな状況で「あれがいい、これがいい」っていうのは、「この店が一番良い！あっちの店は...メニューだけ見たけどなんか美味しく無さそう」とか言ってるのとほぼ同じ。
一回くらい食べに行ったことがあったとしても、お店の魅力も本来一回じゃわからない。いちど美味しく無さそうと思ったら、もしくは、自分にとって美味しくないと思ったら、そのお店の話を詳しく聞こうとは思わないだろうし。好きなお店が一番であることを証明するために、行きたいと思ってないお店に何度も通うわけもない。
実は、比較するだけの知識を持っていない。でも決めなきゃいけないですからね。
フレームワーク選定の専門家？
フレームワークを使ってても、フレームワークの本質や思想、開発と運用時の有益性など、総合的な特性を把握できるわけではありません。
フレームワークを作ってても、他のフレームワークの特性を把握しているわけではありません。どちらかというと、自分のフレームワークの運用に追われて、他のフレームワークの研究の時間がなかなか確保できません。
そして、厳密には、フレームワークに詳しいだけじゃ選定もできません。そのプロジェクトの開発耐性や業務特性などを考慮して、「短期的・中長期的なフィッティング」を考慮しないといけません。それは本当に開発現場の分析を主軸にしてる人、とかじゃないとわからないでしょう。
なので...
フレームワークのユーザーは、フレームワーク選定の専門家ではないし...
フレームワークの開発者も、フレームワーク選定の専門家ではない
でも、そんな人はいないから、関係者の経験から来るアドリブで決めるしかない。
決めるスキルのない人たちで決めようとしてるわけですから、議論だって高度なロジックになるわけがない。
顔と雰囲気で決まるフレームワーク
仮に専門家がいたとしても、大抵のエンジニアは「自分たちで決めたい欲」が強いので、それもなかなか受け入れられないでしょう。
選定の場は、ひた隠しにした欲求にいかに組織的な正当性を付与するかの体裁の競争の場とも言えるから。
そもそも専門家であっても、どのフレームワークが一番良いかって...
厳密には社会実験までしないと証明できない
ですから、ロジックの信頼度をどれだけ得られるかは、技術スキルを遥かに超えた非常に難度の高いものです。
結局、人と一緒で、フレームワークも「顔と雰囲気」で、決められることがほとんど。
しかしながら、それも仕方ないことかな、とも思い始めて...そういう割り切りでいたほうがストレス溜めないだろうか。
jfluteは、適当に決められてるのがすごく嫌でした。それで決められたもので自分も苦しんだことあるし、苦しんでる人たちをたくさん見てきたし。それぞれのフレームワークに特徴があり、それぞれの現場に特徴があり、細かく現場フィットのロジックがある。それをひたすら考えてきたつもりですから。
でも、みんな他のことはあんなに細かく吟味するのに、フレームワークの話になると唐突にアバウト。メリット・デメリットも耳に入らないのはなぜ？と...
でも、厳密には、自分も五十歩百歩だろうしと。色々な現場で仕事して様々なフレームワークに触れて...できるだけ他のフレームワークの話も聞いて...ってやってるつもりでも、足らないなって。人生が三回くらい必要かもですね。そこにボーダーラインがない以上は、どこかで「ある程度のいい加減さ」は許容しないと。
...
そういう意味では、プログラミング言語もフレームワークも、シェアを広げるならプロモーションが命。これは一般の世界と全く同じ。
上手に歌えば大ヒットするわけでもない。エンジニアの世界だから特別なんてことはない。
シェアを広げることがフレームワークの目的ではないけど、ある程度のシェアがないと品質を保てないのは事実。フレームワーク開発者の寂しさとも言えます。
追求してもらえるフレームワーク
そういう前提であれば、
「このフレームワークなら、プライベートでも残業でも、ガンガン追求してくれる人がいる」
そういうことの方が、よりいっそう大切な要素とも言えるでしょう。
「Aが使いたいね、Bが使いたいね」と言うだけ言って、それに対して誰も何もコミットしない...立派な建物の中に、覇気のない飲食街。かわいそうなフレームワーク。そんな寂しい決まり方も多く見かけますから。
会社としては、「より良いかもしれないけど追求する人がいないB」よりも、「追求してもらえるA」の方が良いかもしれません。(人の入れ替えの可能性も考慮はしないとですが...)
個人からすれば、ある意味ではやったもん勝ち。やりきって成功させる意欲があるならWelcomeと。
もちろん、「これがいい！」と言ったからには、その発言にコミットする姿勢が求められる一方で、会社はその姿勢を評価しなければなりません。本来は、特定の人に追求の義務を負わせるのではなく、みんなで分散して追求するべきものですが、それが成り立たないのが現実ですから。
...
もちろん、学習コストの違い、とかもありますが、「追求してくれる人がいない学習コストの低いS」と、「追求してもらえる学習コストの高いT」というのを考えた時に、どこまで影響のある差なのか？
また、いまの時代、どのフレームワークも品質が高くなっているので、AとBどちらでも...
ちゃんと使いこなしさえすれば
どちらを選んでも大抵そこまで大きな支障は出ないでしょう。「Aを選んだからシステムが作れない」なんてことはなく、デザインの違い、価値観の違いはあれど、大きく開発にロスがでるようなものは少ないでしょう。
であれば、
「より良いものを選ぶ」ことよりも「しっかり使いこなす」ことの方が重要
になってきているとも言えると考えるわけです。
【追記】
後に、このようなブログも書きました。
内容はスキルアップ的な話ですが、
ツールの選定においても通じる話です。
=> まず何より、目の前の道具を使いこなしてください
【追記】
さらにこんなブログも書きました。
応援してる "A" にもデメリットはあるよ
もちろん、100%使いこなす必要もありません。ただ、「フレームワークの思想」を理解せず、何を大切にして何の問題を解決しようとしているのか？食い違ったまま使ってるとどこかで無理が生じます。
セキュリティというジョーカー
ただ、Webフレームワークだと、昨今のセキュリティ事故のニュースや、サポート切れなどの話題から、セキュリティというのが大きな焦点になっています。
なので、「使い勝手や生産性とかフィット感」以前に、「セキュリティ的に安心できるか？」の方が優先されて...
if (セキュリティ的に安心できる？) { return そのフレームワーク; }
で、フレームワークの選定終了。というのも多くなってきました。
ただ「安心できる」ってのもなかなか曖昧で...
今まで脆弱性が "0個" のフレームワークと、
今まで脆弱性が "10個" のフレームワークがあって、
次の脆弱性が出る可能性の高いものはどっち？
まあ、前者って思う人がほとんどでしょう。自分もそう考えると思います。ですが、究極わからないですよね。前者の1個目と後者の11個目が出る確率なんて。
その10個の脆弱性の内容も吟味しないと。フレームワークの開発体制とかまで吟味しないと。これはこれで難しく時間のかかる作業でしょう。
多くの人が使ってるから平気？いやいや、多くの人が使ってるもので脆弱性出てます。というか多くの人が使ってるからこそ出てる、とも言えるかも知れませんし。
そこも結局、「顔と雰囲気」で決めるしかないのでしょうか？
大手企業が開発しているから平気？
これは雰囲気ではなくロジックなのか？
いずれにせよ、選定が速攻で終わったとしても、それで「使い勝手や生産性とかフィット感」の話が解決したわけではないので、選んだ後が重要です。
逆に、フレームワーク選定で深く吟味をしてないから、そこを放置したまんま使い始めると、残念なことになりやすいとも言えるでしょう。ちゃんと使いこなすための施策を忘れずに。
使いこなすの積み重ね
なんか湿っぽいエントリになってしまいましたが、希望的なロジックもあります。
みなが「使いこなす」ということを繰り返すことで、より高度なフレームワーク選定に近づいていくと思っています。
好きだろうが嫌いだろうが、目の前のフレームワークを追求していくことで、好きなものが近づいてくるよ。
...
【追記】こんなブログも書きましたよ。
=> 応援してる "A" にもデメリットはあるよ
=> フレームワークの思想、意識して使っていますか？
