Zenn
🐙

技術選定をする際の4つのポイント

2022/09/27に公開
#
技術選定
tech

はじめに

私が技術選定をやってきた中で、ここを気をつけているというポイントをまとめてみます。

技術選定という作業に正解はないと思いますが､自分がやってきたことの備忘録として残しつつ､誰か第三者のご意見をいただけたら良いなという意味合いで残しています｡

技術選定をしていく上で4つのチェックポイントをベースに技術選定をしていっています｡

チェックポイント

  1. 解決したい課題を理解する
  2. 組織のバッググラウンドを理解する
  3. 選定する技術の市場を理解する
  4. 選定する技術のボトルネックを理解する

1.解決したい課題を理解する

基本的に技術を選定するときは「この技術でなにかやりたい」ではなく、ビジネス課題の解決等の理由があるはずです。

その課題を正しく理解して、本当に必要な技術要件を洗い出していくことが重要だと考えます。

その課題を解決するために必要な技術要件を以下の視点を踏まえて洗い出していきます。

  • マストで使わないと実現できない技術はあるか？
  • 最低限のスペック構成はどのくらいなのか?
  • 開発の規模感はどのくらいになるのか?
  • 作っておしまいなのか、長期的に機能を追加開発していくなのか?
  • スピード感が優先されるのか?

では上記の視点を踏まえて、いくつかの例を元に技術選定に必要な要素をあげてみます。

例えば

  • レジなどの専用のPCに組込むシステムの作成
  • 簡易なLPサイトの作成
  • ユーザーが日常的に利用するサービスの作成
  • 動画配信サービスの作成

マストで使わないと実現できない技術はあるか？

⇒ レジなどの専用のPCに組込むシステムの作成の場合

PCの組み込みアプリにする場合は､ electron や .NET のようなPCアプリケーションを構築できる特定の言語がマストになる

⇒ 簡易なLPサイトの作成の場合

簡易的なLPであれば､必ずしも React とかを使う必要はなさそうなので､LPを実現できればある程度何でも良さそう

最低限のスペック構成はどのくらいなのか?

⇒ 簡易的なLPサイトの作成の場合

静的なLPを公開するだけに､スペックもりもりなVMサーバーを自前で構築してデプロイする必要があるのか?

簡易的なLPなので Heroku とかのサーバーレスサービスにデプロイで十分そう

⇒ 動画配信サービスの作成の場合

動画の場合はストリーミングサーバーが必要になる等､ある程度負荷に耐えられるサーバーを自前で構築する必要がありそう

作っておしまいなのか、長期的に機能を追加開発していくなのか?

⇒簡易なLPサイトの作成の場合

簡易なLPのためにSSGに対応したフレームワークはオーバースペックなので､プレーンな HTML と CSSで良さそう

しかし､LPを複製してSEO施策を打っていくようなLPの場合はCMSを用いた SSG に対応しているフレームワークが必要そう

⇒ ユーザーが日常的に利用するサービスの作成の場合

機能が徐々に増えていくことが予想されるので､ある程度ルールのしっかりした大規模なフレームワークを採用したほうが良さそう

スピード感が優先されるのか?

⇒ スピード感優先の場合

とりあえず､早く動くものができる フルサーバーレスなインフラ構成やフレームワークを採用すると良さそう

⇒ 品質優先の場合

VMから作って､ k8s を使ってサービスをデプロイするようにして､開発言語も静的型付けできっちりと固めたフレームワークを採用したほうが良さそう

解決したい課題に応じて､必要な技術要件というのは変わって来ると思います｡

このときに､｢本当にそれは必要なのか?｣ この視点がとても重要だと考えております｡

技術ファーストになってしまうと､いざ売上を作るときに瞑想しがちなのでビジネスの課題から考えることができると良いですね｡

2.組織のバックグラウンドを考える

基本的にアプリケーション開発というものは個人開発を覗いては､会社等のどこかの組織に属して開発をしていくことになると思います｡

チーム開発をしていく上で､新しい技術を採用していく際に､その組織でうまく運用をできるかを考える必要があります｡

まったく組織にゆかりのない技術を採用してしまう

例) AWS をメインで利用している組織で GCP を採用する

基本的な部分は同じなのでどちらでも同じようなことはできますが

  • AWSで培ったナレッジをGCPでそのまま活用できない
  • 掛け持ちで担当するエンジニアのコンテキストスイッチの切り替えが必要になってしまう

のようにデメリットが目立つ形になってしまいます｡

GCPでしか実現のできない機能を使う必要がある等の特定の理由がない限りは､すでにゆかりのある技術を使うと幸せになれると考えます｡

オーバースペックな技術を採用してしまう

例) 全員がPHPしか経験がない中で､Scalaを採用する

｢保守性を上げるために動的型付けではなく､静的型付けの言語を採用しよう!｣となった場合でも､ Java の経験がないのに Scala を採用してしまうと学習コストが圧倒的に高くなりすぎてしまい結果的に｢やっぱできない｣となる未来が想像できます｡

このように新しい技術を採用する際は､今の組織のレベル感や携わってる技術スタックをベースに技術選定をしていくと良さそうです｡

この例だと､ フロントエンドで JavaScriptを書いている人は多そうなので､　TypeScriptあたりから入ると良さそうですね｡

その組織によって､最適な技術要件というのは変わって来ると思います｡

組織の現状や将来性を考慮して､本当に最適な技術選定を行っていくということが重要だと考えます｡

このあたりの組織づくりは､上記以外のしがらみとかも多く大変な部分ではありますが､人材戦略みたいな部分も兼ねて考えれると良いですね｡

3.選定する技術の市場を理解する

技術を採用する際に､その技術の市場を理解することが重要です｡

ここで言う市場とは下記のような視点を指しています｡

  • その技術はどの規模のコミュニティによって支えられているのか
  • リリースされて､どのくらいの期間が経過しているのか
  • その技術を採用している､他の企業はどのくらいいるのか
  • その技術を使うことができるエンジニアがどのくらいいるのか

といったように､その技術がエンジニアの市場でどのくらい流通しているのか?

これを理解して､そこに潜むデメリットやメリットを比較して技術選定することが重要だと考えます｡

メリットとデメリットの例として次のような項目があがってくると考えます｡

デメリット例

採用した技術が数年後サポート終了してしまう

ある程度コミュニティーが成熟していないとメンテナンスが困難になってしまい､その技術のサポートが終了される可能性もあります｡

その際に､新しい技術へのリプレイスが必要などやることが増えてしまうので､市場からある程度の将来性を予想して技術を選定できると良さそうです｡

対応できるエンジニアが少なくて採用コストが高くなってしまう

Scala とかがよく聞く例なのですが､ Scala エンジニアを採用するとなると単価が高くてなかなか人が集まらないので Java エンジニアを採用して教育するみたいなことが必要になってしまったりします｡

それであれば､最初から Java のフレームワークを使ったほうが良かったみたいなことがあったりするので､新規で技術を採用する際はこのあたりの考慮も重要だと考えいます｡

メリット例

バックエンドでもTypeScriptを採用して､採用を一本化する

フロントエンド･バックエンドどちらでも同じ言語を採用できる技術選定をすることで､いわゆるフルスタックエンジニアを採用しやすくなるといったメリットがあったりします｡

ある程度規模の小さいチームとかだと､フロントとバックエンドの垣根なくプロジェクトを進めていくことも多いと思うので採用市場の中にいる TypeScript 経験者で採用ができたりします｡

組織に特定の技術の Main Contributor がいることで組織のブランディングを図る

組織に特定の技術に精通する人物がいるとその技術 = その組織といったイメージを作ることができます｡

これは採用戦略としてかなり有力だと感じており､そこをベースに技術を選定するということもとても良いやり方だと考えます｡

エンジニアの市場は変化が激しく､少し前のベストプラクティスがすでに時代遅れだったりと常にアップデートが必要であると感じてます｡

プロジェクトと市場がうまいことリンクすることでよりプロダクトを飛躍させることができるので､このあたりはキャッチアップを怠らず

4. 選定する技術のボトルネックを理解する

最後に採用する技術のボトルネックを理解するです｡

技術にはメリットもありますが､当然採用した際のデメリットも存在します｡

そのデメリットが今後運用フェーズに入っていくときに大きなボトルネックになってしまわないか?をある程度認識した上でその技術を採用することが重要だと考えます｡

例えば例を上げると

実装は簡単にできるが､機能拡張が困難になる

WordPressとかがよくある例ですが､ある程度テンプレートに沿ってサクサクと実装をしていけるメリットはあるものの､テンプレートで実現できない機能を実装するためには独自の拡張が必要になったりするケースがあります｡

その際､WordPressの管理下から外れてしまうためその部分でバグが発生したりした際に最悪メンテンナンスができないみたいな状況に陥ったりします｡

このように､その技術のボトルネックを理解しないまま使ってしまうと､忘れた頃にどうしようもなくなってしまうような壁にぶち当たる可能性があります｡

そのため､技術選定のうちからその技術のわかりきっているボトルネックをある程度ピックアップしておき､そのボトルネックがなんとかなるものか､もしくはどうしようもないものなのかを事前に把握しておき､それを踏まえてその事業の将来性を加味して技術選定をしていくことが重要だと考えています｡

まとめ

技術選定の際の4つのポイントをまとめてみました｡

技術選定の際は､特定のレイヤーだけではなく､インフラ･サーバー･フロントエンドと全体を見据えた知識が必要になるので､常日頃キャッチアップをしていかないと行けないなと感じております｡

自分のこの考えが､もっと長いスパンで見た際にどんな結果になるかは時間が立ってみないとわからないですが､今後はここの答え合わせというか振り返りも兼ねて色々考えていこうと思っております｡

少しでも､この記事が誰かの役に立ったら嬉しい限りです｡

また､ご意見等があればぜひご気軽にコメントいただけると幸いです｡

Discussion