(注記：9/13、いただいた翻訳フィードバックを元に記事を修正いたしました。)

半年ごとに”今一番ホットな”フレームワークが新たに登場しては、私たちは興奮に沸き返ります。

誇大広告を信じてはいけません。

フレームワークの寿命 はプロジェクトの成功を左右するほど重要な要素です。フレームワークを選ぶ際、テクノロジにおける多くの意思決定者は納得のいく選択をするために、コミュニティの大きさ、人気、大企業によるサポートの有無などを基準にしています。しかし実際は、こうした要素によって寿命が決まるわけではありません。

最初は勢いがあったのに、徐々に弱まり、最終的には線香花火のごとく儚く消えてしまうようなフレームワークを選んでしまうと、書き直しに無駄な時間を費やしたり、チームの士気を下げたりする原因となります。本記事は、そうした残念な結果を回避するヒントをまとめたものです。

本記事では以下のことを示したいと思います：

1. アプリケーションを成功させるためには、その寿命が長くなくてはならない （ パート1a ）
2. アプリケーションの寿命を長くするためには、長寿命であることが示されているフレームワークを選択しなければならない （ パート1b ）
3. フレームワークの寿命を予測する最も良い方法は、過去の傾向を調査することである （ パート2 ）
4. 寿命を予測するための確かな根拠として過去の実績を調べる場合、CanJS、JavaScriptMVC、およびBitoviのオープンソースのスタックがすばらしい選択肢を提供している （ パート3 ）

コンテンツ

1. なぜ寿命が重要なのか？
2. フレームワークを評価する方法：重要事項と不必要事項
3. 過去に見る寿命：Bitoviのオープンソースのスタック

なぜ寿命が重要なのか？

なぜフレームワークの寿命が重要なのかを説明する前に、なぜアプリケーションの寿命が重要なのかを先にお話しする必要があります。

アプリケーションの寿命

SPA開発の際の典型的なライフサイクルに関しては、正確な調査があるわけではありませんが、これまでがどうだったかというところをソフトサイエンス的見地から得た私の見解を具体的な数字と共に挙げてみたいと思います。この推測は、Bitoviでの10年にわたる経験で得た知識に基づいています。

主張：

1. ほとんどのアプリケーションはローンチに1年ほどかかる
2. 1年目と2年目の間は、失敗、あるいは資金不足のために、プロジェクトが中止される可能性が最も高い時期である
3. 2年目の壁を越えたプロジェクトは、儲けがある限りは生き残り、通常それは少なくともトータル5年ほどとなっている

初期の頃は、「このプロジェクトは成功するか？」という壁が立ちはだかりますが、多くのアプリケーションは以下の期間ならば生き残れると言えます：

• 新たな競争相手が引き継ぐまで
• そのアプリケーションの需要がなくなるまで
• テクノロジが進化して、選択した実装が時代遅れになり、新しいプラットフォームへの書き直しが必要になるまで

私たちはテクノロジにおける意思決定者として、プロジェクトが難関を越えられると仮定して計画を立てていかなくてはなりません。

私たちは1年ではなく、5年以上のタイムスケールで考える必要があるのです。

プロジェクトの開始時は、希望に満ちた目を輝かせて、5年先までを見据えます。

注釈：
縦軸：チームの作業速度
横軸：プロジェクト開始からの経過年数
左から：開始はここ/最終的に到達したいのはここ

最初にして最も重要な意思決定：どのテクノロジ・スタックを使用するか？

限られた時間の中でテクノロジに関する意思決定を行う場合、良いフレームワークと悪いフレームワークを見極められるかどうかが非常に重要なポイントになると言えます。プロジェクトが成功するか、失敗するかを決めてしまう可能性があるのです。

フレームワークの寿命

JavaScriptのフレームワークは数年先まで生き残れるのかと言うと、これまでの実績はひどいものです。生き残れないもの、つまり失敗に至るフレームワークは2つの種類のいずれかに該当する傾向があります。ここでは、それらを爆弾（すぐに爆発する）と線香花火（勢いが徐々になくなっていく）と呼ぶことにしましょう。

では、爆弾と線香花火について説明する前に、このコンテキストにおける寿命とは何かを定義しましょう。

フレームワークの寿命とは何か？

寿命とは…

『チーム★アメリカ ワールドポリス』の ベストシーン より引用。

JSフレームワークのコンテキストでは、寿命は以下を意味します：

1. 信頼性 。フレームワークから後方互換性をなくしてはいけません。さらに、新バージョンをリリースする際はいつも、明確なアップグレード・パスをユーザに提供する必要があります。新たなメジャーリリースでは、APIの互換性を損ねる変更やより良くなった新しい方法などが含まれることでしょう。しかし、もしあなたがアップグレードの準備をするときには、アプリケーションのアップグレード手順を説明する簡単なガイドを用意するべきです。
2. 一貫性のあるイノベーション 。Webの様相は30秒ごとに変わっています。唯一、変更されるという点だけが変わりません。満を持してリリースした最初のバージョンでは、変更が必要な箇所が全て明らかになっているということはないからです。そのため、最善の手法や基準、ブラウザが変更されていくことに対して、フレームワークが対応できることの方がはるかに重要です。そうすれば、3年後に古くなったテクノロジに手を焼くということを避けられます。
3. 実証済みの実績 。年単位のタイムスケールで将来のことを話しているので、どのテクノロジが上述の1および2の条件を満たすのかを知ることは、なかなか難しいものです。これを理解する良い方法としては、それらの実績を見てみるというものがあります。それは全く新しいものでしょうか？　時間の経過と共にどう実行されていくのかを少し静観していたいと思うかもしれません。数年は経っているものでしょうか？　それなら、これまでにどう実行されてきたのかを振り返ってみましょう。

爆弾に賭ける

爆弾とは、チームの作業速度を突然の失速へと導くフレームワークのことです。プロジェクトは完全に失敗するか、あるいは後方互換性のない新しいバージョンをリリースすることになるか、どちらかです。いずれにせよ、実用には書き直しを余儀なくされることでしょう。

Angular 2.0 に賭けている方なら、私が言わんとすることがお分かりいただけることでしょう。 GWT や、 batman.js でもいいですよ。

注釈：
縦軸：チームの作業速度
横軸：プロジェクト開始からの経過年数
左から：スタート時の学習曲線/プロジェクト失敗、あるいは後方互換性のないバージョンをリリース/書き直し/新しい学習曲線

線香花火に賭ける

線香花火ならば、プロジェクトの突然の失速までの期間がもっと長くなります。このようなフレームワークは、長い間よく分からない中途半端な状態で放置されることになります。コミットレベルやニュースでの表明が減少していくに伴い、じわじわと勢いを失っていきます。そして、このフレームワークはまだ使えるのかしらと悩んでいるユーザを置いてきぼりにするのです。かつてはSPAを構築するためのモダンなアプローチに見えていたフレームワークも、そのイノベーションはゆっくりと止まってしまうのです。

注釈：
縦軸：チームの作業速度
横軸：プロジェクト開始からの経過年数
左から：スタート時の学習曲線/安定版、変更なし/待機中、なぜまだアップデートされないのか？/モダンなスタックと比べるとアプリが古くなった印象、チームの士気も低下/深刻に待機中、アップデートはどこへ？/ああもう、もっとモダンな新しいスタックを選ばなくては

良いフレームワークに賭ける

最終的に、良いフレームワークに賭けることになれば、目先の間だけではなく構築したSPAのその先5年以上という長い間、恩恵を受けることができます。作業速度は継続的に上向き傾向となり、開発チームのみんなはハッピー、生産性も高まり、仕事は淡々と済ませていけばいいという状態が続きます。

注釈：
縦軸：チームの作業速度
横軸：プロジェクト開始からの経過年数
左から：スタート時の学習曲線/新バージョンがアップグレード/新しいメジャーバージョンがリリース/マイナーバージョンの後の学習曲線、速度はツールとチームが良くなるに伴い上がり続ける

フレームワークの寿命に関する見解については、これまで述べてきたような事態が実際すぐにはっきりと表れるわけではありません。しかし、グラフの下の面積（値＝速度×時間）として値（つまり、成し遂げた仕事量）で考えてみましょう。1年目はほぼ変わらず、2年目も多少の違いが生じた程度なのに対し、5年目になるとかなり差が出てくるのが分かります。

なお、線香花火や爆弾を選択して初期にささやかな利点があったとしても（人気があってエキサイティングな新しいテクノロジというだけで、最初はチームの士気を高めてくれるでしょう）、そうしたものはすぐに廃れてしまいます。

多くの時間とお金、それにデベロッパの士気を無駄にするはめになってしまうので、寿命が重要というわけです。

SPA開発の歴史は短いですが、これらの失敗を避けるためのサインが出ている場合でさえ、爆弾や線香花火に賭けてしまうというパターンを度々見てきました。

フレームワークを評価する方法：重要事項と不必要事項

寿命をはっきりと示すフレームワークを求める際、確かな指標になるものが1つだけあります。それは過去のパフォーマンスです。フレームワークのサインには、次のようなものがあります。

良いサイン

1. 5年以上存在している（多くのデータがあれば傾向を評価できる）
2. 毎年デモンストレーションされており、一貫して向上している

悪いサイン

1. 前のバージョンに後方互換性がない
2. イノベーションにかかる期間が長い

これはJavaScriptフレームワークの寿命を独自に視覚化したものです。この図の中には、あなたが避けたいであろう多くのフレームワークの例（ここにないものも多くあります）が出ていますが、賢い賭けの区分に入るものはそれほど多くありません。

*注釈：
縦軸：イノベーションの継続性
横軸：リリースからの時間
左上：新しい流行
(AngularJSの次のバージョンには後方互換性がない)
右上：賢い賭け
(ExtJSは有料のみ)
左下：ウィークエンドプロジェクト
右上：停滞
(GWTの次のバージョンには後方互換性がない)
*

重要でないもの

フレームワークの選定は、いくつかの一般的な基準に基づきます。次の図は典型的な選定基準を表しています。

実際のところ、非常に短期間においては、この中のどれもがそれほど重要ではありません。私たちは5年以上のタイムスケールで考えていることを思い出してください。

これらの選定基準の大部分はまやかしで、フレームワークの寿命を探るという真の目的から選定する者の意識をそらします。作り上げられた神話を一掃してみましょう。

1. フィーチャー・アドバンテージの神話

オープンソースのプロジェクトの特徴は、驚くほどコピーが簡単なことです。

Reactの仮想DOMはすばらしいアイデアでした。とても優秀なので、CanJSにこのアイデアが導入され、 仮想DOM と サーバサイドレンダリング が追加されました。

フレームワークがイノベーションを続ける限り、フレームワーク間で機能が等価になるタイムラグは比較的短い期間になります。

継続するイノベーションは現行の機能セットよりも重要です。

2. 巨大なコミュニティの神話

オープンソースのプロジェクトのコミュニティは気まぐれなことで有名で、新しく話題になるフレームワークにすぐに飛びつきます。ここ数年JavaScriptのコミュニティは、BackboneからAngularへ、そしてReactへと、すぐさま群がりました。

人気のテクノロジを選ぶことは、名声をつかんだからといってMiley Cyrusと結婚するようなものです。あなたは3年後、自分の決断を後悔することになるでしょう。

熱心なコアチーム（たとえ小さくても）は、継続的な改良は神話よりも重要であることを証明してきました。

3. 大企業の神話

大企業に維持されることはテクノロジ選択において大きなアドバンテージになると、多くの人が言うのを聞きました。これは根拠のない話です。

大企業にサポートされれば、フレームワークがお払い箱にならないというわけではありません。信頼されている大企業が、多くのデベロッパたちがかなりの時間を費やしたプラットフォームを駄目にしてしまうという明確な例がたくさんあります。

大企業は、多くの競争目標を掲げています。企業独自のテクノロジのプラットフォームでの儲けがないので、プロジェクトが彼らの目的と連携しないと分かると、すぐにプラットフォームは用済みになってしまいます。

その良い例がGoogleです。

「Googleの優先事項が変更されて、あるプロジェクトがもはや優先されなくなる」と知りつつも、テクノロジ・マネージャとしてこれらのプラットフォームの1つに賭けるという厳しいこともありました。

4. 雇用の神話

マネージャの多くは、個人が選んだフレームワークをリストにした履歴書を持参したデベロッパを雇うべきだという間違った思い込みをしています。そうでなければ、会社に効果的に貢献してくれる人材ではないというのです。

これはまったく根拠のない話で、フロントエンドのスキルがどのように求められているかが誤解されていることを示しています。コンピュータサイエンスがアイスのコーンの部分で、JavaScriptがひとすくいのアイスクリームだとしたら、フレームワークの知識はトッピングです。

APIは週末に学べます。モダンなフレームワークでのアプリケーションの作成方法を知れば、デベロッパは別のモダンなフレームワークへの切り替えが簡単にできるようになり、すぐにハイレベルな貢献が可能になります。

デベロッパの履歴書には、その時に流行しているフレームワークが書かれているものですが、それにはあまり意味がありません。

過去に見る寿命：Bitoviのオープンソースのスタック

2007年に JavaScriptMVC はリリースされました。

2012年に、5つのサブプロジェクトに分割されました。その1つが CanJs です。

2015年7月には、新しい DoneJS がリリースされました。次世代のJavaScriptMVCです（もうこの名称は適切ではありませんね）。これはCanJSとStealJS、それといくつかの他のテクノロジの組み合わせで、複雑なJavaScriptアプリケーションを作成するための包括的なフレームワークの構築と結び付きます。

そう、私たちは新たな名前を付け直すエキスパートなのです。

名称は変更されてきましたが、DoneJS、CanJSなどは全てJavaScriptフレームワークの1本の線でつながっており、同じコードベースから出来ています。これらは最近主流のSPAフレームワークの中でも最大の寿命を誇ります。人気コンテストでは決して優勝できませんが、2007年以来、一貫性のある安定した改良で、毎年その寿命の長さを証明しています。

これはハイライトの一部です。

*訳注： クリックして表示 *

2007年に、あなたが携わるプロジェクトがJavaScriptMVCを選んでいたとしたら、それは賢い選択だったと言えます。過去8年半の間、あなたのチームはモダンなアプリケーションのアップグレード・パスを手に入れてきたでしょう。

なぜBitoviのスタックがこのように長い寿命を手に入れたのか、疑問に思うかもしれません。これは今後の記事のトピックなのですが、主な理由は以下のとおりです。

1. ビジネスモデル 。Bitoviのビジネスサービスはこのテクノロジ・スタックに基づいています。サイドプロジェクトや趣味、またはPRのための企業の試みではありません。
2. 企業のクライアント 。私たちのスタックは、何よりも安定性と長い寿命を評価する多数の企業のクライアントに常にアピールしてきました。こういったタイプのクライアントがいるので、賢くて安全なアップグレード・パスを重視してきました。
3. ハードワークと根気強さ 。このような実績は一晩では達成されません。私たちには、Justin Meyerに導かれたデベロッパたちで構成された、小さいけれど熱心なコアチームがいます。9年間、安定してこのプロジェクトを改良してきました。

2015年にテクノロジを選択するなら、DoneJS、CanJSを選ぶのが賢いでしょう。Webの様相はこの8年半で変化したので、一貫性があって安定した改良を期待し続けることができます。

レースに勝つのは、ゆっくりとした堅実さです。

まとめ

ソフトウェアのプロジェクトは数年存続するということを忘れないでください。数カ月ではありません。長続きするテクノロジを選んでください。

2015年にプロジェクトのためのテクノロジを選ぶなら、 寿命を一番重要な要素として考慮すること をお勧めします。