HOME > 開発者向けBLOG > Sencha Blog >  JavaScript フレームワークを選ぶ前に問うべき4つの質問

Technology Note 開発者向けBLOG

Sencha Blog

JavaScript フレームワークを選ぶ前に問うべき4つの質問

こんにちは、ゼノフィnakamuraです。

この記事は、US Sencha社ブログ 4 Questions to Ask Before Choosing a JavaScript Framework を翻訳したものです。

4 Questions to Ask Before Choosing a JavaScript Framework 過去5年間、 Web でもネイティブでもテクノロジーは爆発的な進化を遂げました。ライブラリ、フレームワークやツールの頻繁なリリースにより、開発者にはアプリケーションを作る上でたくさんの選択肢が存在します。しかし、デザインパターンやマイクロライブラリスタックの活用は、大企業アプリ開発の生産価値を上げてきたでしょうか?

私はここ数年間、直接 Sencha の企業顧客とふれあう機会がありましたが、頻繁に聞かれることは、Sencha と他に複数存在する Web アプリ開発ツールとをどう比較すればよいか、ということです。AngularJS、Ember、などの一般的な (しかし限定された) ライブラリは進化を遂げ、開発者は莫大な数のツールから選ぶことができます。その結果、複数の専門的なサードパーティーライブラリを、完全にカスタマイズしたスタックができてしまうことが多々あります。

これらの単独のライブラリと、結果的にカスタマイズされたスタックは、非常に有能である可能性を秘めていますが、 企業ソフト開発の需要に応えるためには、現実にはほとんどの機能性を異なるソースからかき集めたり、社内でそれを作ったりしなければならず、有能なメンテナーのチームも必要です。

詳しく学ぶには、近日行われるウェビナーに参加してください。

企業ソフト開発での JavaScript の ROI を分析する

Tuesday, 10/14 at 10:00am PDT (日本時間 10/15 (水) 午前02:00)

To learn more, join us for our upcoming webinar - Analyzing the ROI of JavaScript in Enterprise Software Development

Sencha は長い間 HTML5 の素晴らしさに気づいていました。そして、企業内で開発される強力な Web アプリケーションに特化した機能性に溢れた、完全に統合された商品を作る事に力を注いできました。Ext JS は、今なお進化しつづけているフル装備 JavaScript フレームワークとして、企業 Web アプリの要望に応えるために丁寧にエンジニアリングされています。これは、もちろんサードパーティのアドオンを必要とせずにです。

新しいプロジェクトに取りかかる前に、自分に次の 4つの疑問を投げかけてみてください :

  • どうすれば開発チームをより生産的にできるだろうか?
  • 寿命の長い企業アプリケーションの開発にどれくらいの時間や努力が必要かを、正確に見積もれるだろうか?
  • 開発者たちは、会社のアプリケーションポートフォリオを越えて、エンドユーザーのデバイスやプラットフォームが何であろうと、コードを再利用することができるだろうか?
  • アプリケーションのライフサイクルの期間とエンドポイントにあるデリバリープラットフォームに費やされる長期的なメンテナンスに必要とされるものを正確に予測できるだろうか?

それぞれの質問をひとつずつ詳しく分析していき、なぜ Sencha Ext JS フレームワークが AngularJS の様なサードパーティーライブラリーに任意のソリューションを積み上げたものより、優れているかを見ていきましょう。

どうすれば開発チームをより生産的にできるだろうか?

どんな会社も、従業員がどうすればより生産的になれるかを知りたいと思っていますし、ソフトウェア開発ではなおさらです。

HTML5 の大きな利点の1つは、Web 開発者が共通したスキルを持っているということです。つまり、パワフルでインタラクティヴなアプリケーションを様々な環境で作れるということです。HTML5 が共通となる技術であるという事実にもかかわらず、現実では人気のライブラリやツール間ではフラグメンテーションが起きていて、開発者を常にトレーニングするのが難しくなっています。

Modern Web Stack Criteria
(大きな画像を見る)

上記の表をご覧ください。企業アプリが必要とするであろう様々な機能がまとめられています。AngularJS などの人気のあるアプリケーションライブラリのほとんどはこういった機能の一部しか実装していません。つまり、そういった機能が社内や組織内で開発して管理されない限り、開発者 (または代理人や企業) は足りない機能を、サードパーティーソフトウェアのコンポーネント (依存関係) を組み合わせて作りあげなければいけないのです。

A functionality map showing the broad feature set of Ext JS 5 compared to Angularjs' smaller subset of features
(click to enlarge)

このアプローチでは、そういったサードパーティーライブラリがどれも独立して配信されていて、それぞれ独自のリリースサイクルとベストプラクティスがあることを忘れてはいけません。複数の異なるライブラリを、ひとつの高度にカスタマイズされたアプリケーションスタックにまとめると、スタックに渡る個々の機能の統合がされていないことが浮き彫りになることが多々あります。また、二つのアプリケーションスタックが全く同じではないにで、ドキュメンテーションも不完全になりがちです。

また、助けが必要な場合はどうすればよいでしょうか? Google は AngularJS 開発を押し進めているかもしれませんが、サポートは提供していませんし、企業へのタイムリーで献身的なサポートもありません。他のサードパーティー JavaScript ライブラリでも大体同じです。

このアプローチで会社が直面する問題には以下のものがあります。

  • Adequately training their developers across all of the moving pieces 動作する全てのピースに渡る開発者への適切なトレーニング
  • 多くの内部アプリケーションに対して、サードパーティの最新リリースの依存体系をテストする
  • 企業レベルでのサポートを見つける

この「ルード・ゴールドバーグ」的なアプローチ (訳注: 簡単なことをわざわざ複雑な方法で解決しようとすること) は時間をかけて生産性を減らします。しかも、予想より速い場合が多いです。 大きな開発チームはたいていは二つのエリア (アップデート、ドキュメンテーションそして内部のカスタムフレームワークのメンテナンスをまかせられたチームと、顧客やエンドユーザーと関係する実際のアプリケーション開発を行っているチーム) に別れてしまうため、開発や IT 組織の全体の効率は下がってしまいます。

それに比べ、Sencha Ext JS フレームワークは表のほとんどの機能を含んでいます。これらの機能は Ext JS 上で完全に統合されていて、開発者がアプリケーションを継続的にデザイン、開発、そしてデプロイすることができます。そして、世界規模で行われているトレーニングサポートプロフェッショナルサービスチームは、あなたの組織が必要な時にトレーニングやサポートが受けられることを保証し、更なるリソースを提供する準備もできています。

寿命の長い企業アプリケーションの開発にどれくらいの時間や努力が必要かを、正確に見積もれるだろうか?

破綻するソフトウェアプロジェクトや予算案の多くは、予測の失敗が原因であることは誰もが知っていることです。この問題の大部分は範囲の定義付けが下手なことですが、IT マネージャーはソフトウェアを書くためのツールに関しては目をつむりがちである。

どんなライブラリもツールも完璧ではありませんし、誰かが使用されているツールの全てを知っているというような状況も非現実的です。これらの事実を、プロジェクトが必要とする依存体系と照らし合わせてみると、いかにプロジェクトの予測マトリックスが複雑になるかがわかります。

簡単な演算式を与えるだけで、現実世界ではいかに依存するものが多いと問題が多いかがわかってきます。各依存関係が90%信頼できる因子とし、それらがシリーズとして存在してるとすると、因子の数で掛けるだけでアーキテクチャ全体の信頼度をみることができます:

(Dependency A = 0.9) x (Dependency B = 0.9) = 0.81 //or 0.9^2
 
(Dependency A = 0.9) x (Dependency B = 0.9) x (Dependency C = 0.9) = 0.729 //or 0.9^3

平均値は 90% (独断的かもしれませんが) ぐらいでしょうが、数学的な根拠は残っています。そして、依存するものが多ければシステムの信頼度が指数関数としても低下することがはっきりわかります。そして、そういった信頼度の低下は、機能を届けるまでの遅延、テストやメンテナンス時間の増加、更なる開発リソースの割当てへと変換されてしまいます。これは直接コストの増加に繋がり、上司から悪い意味での注目をたくさん浴びる事になり、これはどんな開発者も嫌がることでしょう。

フレームワークを AngularJS を使って自分で作ると決めた場合、その瞬間あなたのチームはいくつもの外部依存関係が発生するということになります。カスタマイズされたアプリケーションスタックは、AngularJS、jQuery、Bootstrap、Grunt、などを使う事になるでしょう。組織内で開発されてメンテナンスされているコードを除いてもこんなにもあるのです。小さなプロジェクトをや簡単なアプリケーションや Web サイトを作るチームにとってはいいかもしれませんが、企業レベルとなると潜在リスクやそれに伴う結果は明白になってきます。チームが大きかったり、地理的に様々な場所で開発が行われる場合、そしてたくさんのアプリケーションに当てはまる大きなコードベースをメンテナンスしなければいけない場合は、そういったことがより顕著に現れるでしょう。

Ext JS の様なフル機能が備わったフレームワークは、より依存関係が少なくなります。これは単純にフレームワーク自体が機能性をたくさん持っているため、サードパーティライブラリを必要としないからです。そして信頼性を高める因子は、依存関係を持つものよりもはるかに多くなります。これはExt JS がたくさんの機能を持っているだけでなく、各機能がフレームワーク内での互換性を保証しているためです。サードパーティーインテグレーションを必須とするポイントが少ない点からも、フル機能のフレームワークを使う事で将来の開発がより簡単で単純になることは、簡単に予測できます。

開発者たちは、会社のアプリケーションポートフォリオを越えて、エンドユーザーのデバイスやプラットフォームが何であろうと、コードを再利用することができるだろうか?

ソフトウェア開発では二つの有名な略語があります。DRY – “Don’t Repeat Yourself” (すでにやったことを繰り返すな) と KISS “Keep It Simple, Stupid” (バカでもわかるくらい簡潔にしろ) 。大半の開発者やアプリケーションマネジャーはこういった言葉を理解していると同時に、誰もがこういったアドバイスに従わないこともわかっています。

例えば、ある程度経験を積んだ開発者なら共通コードパターンを抽出し上位レベルの抽象クラスに入れることで、複数の場所で使えるようにすることは理解しているでしょう。そして、コードの再利用といった問題は小さい尺度では解決していると言えますでしょう。しかし、もし企業内で、非常に大きなソフトウェアチームが複数のアプリケーションを複数のデバイスやプラットフォームで管理しているとしたらどうでしょうか?

実際には、企業内のソフトウェア開発において、大きな尺度でのコードの再利用は未解決なままの状態です。 再利用されているコードを修正する作業は基本的にエラーが発生しがちで、そのため、アプリケーション開発にサードパーティライブラリーを使うアプローチはバラバラのリリースサイクルで、違うチームによって開発された、更新または入れ替えをする必要がああるそれぞれのモジュールにおいて問題を実際に発生させ始めます。

Ext JS はこの問題を標準化したアプリケーション開発プロセスを適用することで解決しています。まずコード自体を整頓し、一貫性のある方法論を提供しています。Ext JS を Sencha Cmd と併せて使うことで、完全に統合された Sencha 製品はチームやアプリ間でのコードの共用が非常に簡単になります。

アプリケーションのライフサイクルの期間とエンドポイントにあるデリバリープラットフォームに費やされる長期的なメンテナンスに必要とされるものを正確に予測できるだろうか?

ソフトウェアメンテナンスは、バグを直すことだけでなく、古いソフトに新しい機能性を拡張することだと言われています。事実、既存のアプリケーションのメンテナンスは、実はソフトウェアコストの40から80%を占めています。

企業ソフトウェアの多くはは、5〜10年 (もっと長い場合も) は使う事を見越してデザインされています。人気のある JavaScript ライブラリは、「モダンブラウザ」をターゲットにしていることを頭に入れて置いてください。そして旧型のブラウザ (主にIE8) はいまだにデスクトップブラウザのシェアの多くを占めていて、それにも関わらず AngularJS や他のライブラリはこれらのサポートを完全にやめてしまっています。

こういった数字を意識すると、開発チームが使用するツールのことを完全に理解しているかが重要になってきます。既存のコードを読んで理解するのに総メンテナンス時間の 30%を費やしていとしたら、アプリケーションメンテナンスが開発自体よりも難しいと結論付けられます。この問題は、アプリケーションをメンテナンスしているチームが時間の経過と共に変わってしまう場合に悪化し、新しい開発者が入ってくるたびに混乱が訪れます。

全ての Sencha アプリケーションは同じデザインパターンや方法論を使用するため、チーム内の開発者は新しい開発に携わりながら、古いソフトウェアのメンテナンスも同時に扱うことができます。Ext JS は古いブラウザ (IE8 を含む) から最新のものまでサポートしているので、貴方のアプリケーションは何年も先まで動く事が保証されています。

結論

AngularJS などの JavaScript ライブラリは確かに Web 開発の世界では使い道はあるでしょう。急激に成長したオープンソースコードは、HTML5 をアプリケーションデリバリープラットフォームとして躍進させ、将来の Web 技術の要となることもより確実になりました。しかし、企業というものは、より長期的で特定されたニーズを持っていて、これはてんでんばらばらなソースからかき集められ、様々なマイクロフレームワークを繋ぎ合わせたものでは対応できません。

Ext JS はこういった懸念事項を、堅牢で強く統合された機能を使って解決します。 30日間の無料トライアルをダウンロードし、企業 Web アプリケーションを作る際に Ext JS を使えばいかに簡単にできるか自分の目で確かめてみてください。

詳しく学ぶには、近日行われるウェビナーに参加してください。

企業ソフト開発での JavaScript の ROI を分析する

Tuesday, 10/14 at 10:00am PDT (日本時間 10/15 (水) 午前02:00)

To learn more, join us for our upcoming webinar - Analyzing the ROI of JavaScript in Enterprise Software Development

補足資料

今回の記事は Ext JS を主に AngularJSと比較しましたが、Sencha は他の JavaScript ライブラリとの比較や分析も行っています。詳しくは最新の whitepaper まで。

PAGETOP