目次

システム開発における技術選定とは?観点などを解説します【エンジニア】

本サイトはアフィリエイトプログラムを利用した広告を表示しています

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

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

想定している読者の方

この記事は、エンジニアの方、とくに開発をリードされている立場の方を想定して書いています。また、個人で開発している方にも参考になるかと思います。

著者
Hiroki Zenigami

テクニカルライター。元エンジニア。共著で「現場で使える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

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

事業のフェーズによって解決すべき課題が出てきたときに、これまでの評価軸とは視点を変えて技術を選定する必要があることがわかる事例です。詳しくは「Twitterが、Ruby on RailsからJavaVMへ移行する理由」をご覧ください。

まとめ

技術選定は、事業価値を最大化するために行います。技術選定をする際は、なぜそれを使うかという理由をもっておく必要があります。これは、機能、人、信頼性、経済性を基準に行うやり方があります。技術選定は事業のフェーズによって評価軸を変えることで、事業価値の最大化につながっていきます。

あわせて読みたい

著者
Hiroki Zenigami

テクニカルライター。元エンジニア。共著で「現場で使えるRuby on Rails 5」を書きました。プログラミング教室を作るのが目標です。

スポンサーリンク

ブログをはじめよう

技術ブログの始め方を、たくさんの画像で分かりやすく解説しました。これまでブログをやったことがない人でも、エンジニアにとって重要なブログを今日から始められます。

ブログをはじめる