エンジニアのための技術選定のポイントとやり方

チームで開発をするとき、技術選定をすることがあります。どの技術を使うべきか、説明責任もともなうので、よく悩みます。自分の中で判断基準を明確にもっておくために、技術選定のポイントについてまとめてみました。

この記事では技術選定とはなにか、なぜ技術選定をするのか、技術選定のポイントを書いていきます。技術選定をするときの参考材料になればうれしいです。

ぜに/Hiroki Zenigami

Webエンジニア&プロダクトマネージャ←プログラミング教育で起業←東大院←熊本高専。共著に「現場で使える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でWebアプリケーションとしてつくります。PMF達成後にパフォーマンスが重要なポイントが見えてきて、かつネイティブアプリ化のニーズが出てきたときに、APIとしてGo、フロントエンドにTypeScript+Reactを選びます。

こういったように、事業のフェーズによって技術選定をする上での評価するポイントを柔軟に変えていくといいと思います。

事例: Twitter

TwitterはもともとRuby on Railsで書かれていましたが、JavaやScalaといったJavaVMに移行しました。この理由として、ユーザからのリクエストがふえた結果、非同期処理やVMの性能などがより重要になってきたため、としています。

事業のフェーズによって解決すべき課題が出てきたときに、これまでの評価軸とは視点を変えて技術を選定する必要があることがわかる事例ですね。

参考：Twitterが、Ruby on RailsからJavaVMへ移行する理由