チームで開発をするとき、技術選定をすることがあります。どの技術を使うべきか、説明責任もともなうので、よく悩みます。自分の中で判断基準を明確にもっておくために、技術選定の観点についてまとめてみました。
この記事では技術選定とはなにか、なぜ技術選定をするのか、技術選定の観点を書いていきます。技術選定をするときの参考材料になればうれしいです。
この記事は、エンジニアの方、とくに開発をリードされている立場の方を想定して書いています。また、個人で開発している方にも参考になるかと思います。
テクニカルライター。元エンジニア。共著で「現場で使えるRuby on Rails 5」を書きました。プログラミング教室を作るのが目標です。
システム開発における技術選定とは
この記事でいう技術選定とは、その名のとおり「どんな技術を使うかを選ぶこと」です。領域はインフラやサーバーサイド、フロントエンド、また種類としては言語やフレームワーク、ミドルウェアなどが対象になります。
この記事ではライブラリの選定基準については書いていません。これについては「ライブラリの選定基準」で詳しく書いていますので、あわせてご覧ください。
なぜ技術選定をするのか
技術選定の目的は「事業価値を最大化するため」だと考えています。技術選定というと、ついシステム要件を満たすために決めてしまいがちです。もちろんこれも必要ですが、選定の観点という意味では一部でしかありません。
企業において、開発は事業を運営するために行います。OSSの場合は「事業」を「ソフトウェア」に置き換えられると思いますが、使う技術は事業に大きく影響します。たとえば、技術を使える人の採用コストだったり、運用コストなどが分かりやすい例です。
どの技術を使うかは自由度がとても高い一方で、選択を間違えると長期的にみて事業に大きな損失を与えることもあります。そのため、技術選定をする上では基準を設けるべきといえます。
技術選定の観点
それでは、技術選定の観点を次に書いていきます。観点を「機能」「人」「信頼性」「経済性」の4つに分類しています。お互い重複する要素もありますが、検討しやすいようにしています。
1. 機能
技術の機能面については大きく次の3つがあります。そもそもの前提条件となる観点が多いです。
番号 | 観点 | 備考 |
---|---|---|
1 | 要件を満たせるか | 要件を満たす上で必要な機能をもっているか |
2 | ユーザー体験 | 基準以上のユーザー体験を提供できるか |
3 | パフォーマンス | 基準以上のパフォーマンスであるか |
2. 人
技術を使う人に焦点をあてた観点です。個人的にはほかの評価軸を満たしつつ、いかにメンバーのモチベーションが高い技術を選択できるか、が大切だと思っています。
番号 | 観点 | 備考 |
---|---|---|
1 | 人材流動性 | 技術を使える人が転職市場にどれくらいいるか |
2 | 学習コスト | 技術を使えるようになるのにどれくらい学習の必要があるか |
3 | 開発規模 | 開発者の人数に適しているか |
4 | 習熟度 | メンバーはその技術にどれくらい習熟しているか |
5 | モチベーション | メンバーはその技術を使うモチベーションが高いか |
3. 信頼性
技術の信頼性についての観点です。コストがかかるものほど信頼性についての説明責任が問われてくると思うので、しっかり判断したいところです。
番号 | 観点 | 備考 |
---|---|---|
1 | 信頼性 | 機能は安定して提供されるか |
2 | セキュリティ | セキュリティ要件を満たせるか |
3 | メンテナンス | 機能は継続的なメンテナンスを期待できるか |
4 | 利用実績 | 機能は十分な利用実績や事例があるか |
4. 経済性
コストなどの経済性についての観点です。スイッチングコストについてはデータベースなど低いレイヤーに行くほど乗り換えづらいので、慎重に評価したいところです。
番号 | 観点 | 備考 |
---|---|---|
1 | 利用コスト | 利用するのにどれくらい費用がかかるか |
2 | スイッチングコスト | 機能を乗り換えるのにどれくらい費用がかかるか |
3 | 開発生産性 | 開発効率はどれくらいか |
事業のフェーズによる技術選定
技術選定をするときは、事業のフェーズによって評価軸を変えることが重要になってきます。事業を立ち上げて、最初にめざすのはProduct Market Fitです。つまり、市場に求められるプロダクトにすることです。このPMF達成までは、なによりも開発スピードが求められます。
PMFを達成したら、プロダクトの価値がユーザーに受け入れられたということになります。経済的にも持続可能であることが評価できました。このタイミングでは、開発スピードから安定性などに評価軸を移していきます。
開発スピードがはやいといわれる技術にRuby on Railsがあります。たとえば、PMFまではRailsでウェブアプリケーションとしてつくります。PMF達成後にパフォーマンスが重要な観点が見えてきて、かつネイティブアプリ化のニーズが出てきたときに、APIとしてGo、フロントエンドにTypeScript+Reactを選びます。
こういったように、事業のフェーズによって技術選定をする上での評価する観点を柔軟に変えていくといいと思います。
TwitterはもともとRuby on Railsで書かれていましたが、JavaやScalaといったJavaVMに移行しました。この理由として、ユーザーからのリクエストがふえた結果、非同期処理やVMの性能などがより重要になってきたため、としています。
事業のフェーズによって解決すべき課題が出てきたときに、これまでの評価軸とは視点を変えて技術を選定する必要があることがわかる事例です。詳しくは「Twitterが、Ruby on RailsからJavaVMへ移行する理由」をご覧ください。
まとめ
技術選定は、事業価値を最大化するために行います。技術選定をする際は、なぜそれを使うかという理由をもっておく必要があります。これは、機能、人、信頼性、経済性を基準に行うやり方があります。技術選定は事業のフェーズによって評価軸を変えることで、事業価値の最大化につながっていきます。