chot Inc.

ちょっと株式会社 社員ブログ
Blog
  • ホーム
  • ブログ
  • じゃあ結局どういう基準で技術選定すればいいんだよっ

じゃあ結局どういう基準で技術選定すればいいんだよっ

カルチャー
じゃあ結局どういう基準で技術選定すればいいんだよっ

SHARE

という、開発者の皆様にとって避けては通れない技術選定問題。日々新しい技術やツールが飛び交い続ける世の中でエンジニアされている皆様は、常にどの技術を使っていくべきかの悩みに苛まれているかと思います。私も常に悩んでおりましてですね...

はい、shinoyuでございます(`・ω・´)
CTO大喜利はネタが早々に尽きてしまいまして閉店中です😇

技術選定。弊社でも常に悩みながらやっております🤔
んどん楽しそうなフレームワークやツールが共有されつづける現在、どれが使うのがベストなんだっけ?を、いろんな方の技術記事や、公式サイトをガン見したりして考えております。気になるものを社内でさわさわする会みたいなことを不定期に実施して、メンバーも含めみんなで体験したりする場を設けたりもしてたりしますね。
それだけ考えることが多いわけですけれども、技術選定の結果次第で開発が楽になったり、地獄になったりするわけです。さらに開発チームだけではなく、事業戦略にも大きく絡んできたりもするひじょーに大事なものだったりもします。

今日はこの技術選定という内容について、私がCTOという立場からどのような選定基準を持っているかについて書いていきたいと思います。

開発者が思う基準と、会社が要求する基準は異なる

はい。まずはこれですね。私もまだコードを現場で書いている身なので、当然一番要求したいことは「いかに気持ちよく開発できるか」につきるのでは?と思っております。言語自体もそうだし周辺ツールがどれだけ揃っているかも大事です。
私自身慣れという意味ではRailsを使うことが多いのですが、個人的にはTypeScriptの体験が良いんですよね。型前提で組まれている言語はやっぱりよいのです。実行前にエラーを検知できることは幸せであるぞ人類。周辺ツールも便利なものが結構揃っていますしね。大事。

さてその一方で、会社視点から見た時の技術選定は「事業価値を最大化する」ために行われます。そりゃあエンジニアリングで利益を出す事業をしているので選定基準もそうなるのですが、その中でも特に重要だと思うのが「属人化せずに安定して開発をし続けられる」ことです。主に開発者の確保観点によるものですね。

ちょっと前まではRailsやっていれば安心!だったのが、最近では、新規はRailsじゃなくてGo!みたいなものが増えてきておりまして...これもトレンドなんですかねー。流れ的にそのうちRustとかでてきそう。弊社で受ける開発案件は新規開発が多く、技術選定をこちらにおまかせしてもらえることばかりでそこまでの実感はないのですががね。その関係もありまして、十分な知識を備えたRailsのエンジニアの確保が難しくなってきました。

会社で使っている技術が触れる人を揃えられないと事業の拡大スピードが落ちます。1人の人間がどれだけ質のいい多くのコードを書けるような状況であっても、結局、事業の馬力は人の数で決まります。人員イズパワー。特にうちみたいな小さな会社だと嫌でもそうなる。そしてそういう会社は往々にして人の回転が早い。弊社もなるべく心地のよい会社にして長く努めてもらおうとはしておりますがそれでも退職する人は出る。となると、引き継ぐ人を採用することが必要になるのです。

その状況で人を採用できないとなると、その技術選定は「事業価値を最大化する」ためにはなっていないことになります。自分の好きな言語やフレームワークを採用した結果、人が採用できなくて詰む、みたいなことは容易に起こりえちゃうんですよね。エンジニアとしては辛いところです(Nim人口もっと増えろ)

モダンな技術 VS 枯れた技術

よくTwitterワールドで語られがちなこの2つ。技術選定をする上でも切っても切れないテーマです。モダンな技術を使えなければIT企業にあらず、みたいな極端な考え方をされる方もまれに見ますが、開発者基準だとその観点で会社選ぶのもありでしょう。

しかし事業としてやっていくのであれば、いかに小さな労力で、売上につなげることができるかが最重要です。モダンも枯れもない、利益になるのがすべて。なので枯れた技術中心にして売上を上げている会社もあるわけですね。未だにCOBOLとかOS/2みたいな環境で仕事している人がいるのはそういうことです。結果それがその会社にとって儲かる事業だからやっている。

モダンじゃないから遅れている会社ということにはならないのです。それぞれの会社の事業戦略によって適する技術は異なる。ただそれだけの話なんですよね。

さて、利益になることがすべてという話をしましたが、もちろんそこにも評価軸がございます。利益を大きくするためには売上上げて、コストを小さくする。なので技術選定の基準も以下のような点が重視されます。

  1. 開発するものに対して要件を十分満たせているか(セキュリティ要件含む)
  2. 要求以上のユーザー体験を生み出せるものか
  3. 動作パフォーマンスが軽快で無駄なコストを産まないか
  4. 利用コストが低く、他より少ない費用で利用できるか
  5. 改修や切り替えをするコストが高くならないか
  6. 他の案件に転用しやすい作り方ができるか


一言で言えば、簡単に非機能要件込みで要件満たせて、改修や転用のコストが低いものを選びましょうというわけです。ここで言うコストとは、その言語やフレームワークそのもの自体の使いやすさとか、それを利用し慣れているかを含んだものになるので、会社として慣れた技術を使うことが大事なイメージはできるかと思います。

とはいえ、同じ技術にこだわって開発し続けることが常にベストというわけではありません。やはり技術の進化に応じて適切な技術を適宜更新していく。そういうことも必要なのです。1つの方法に依存することなく、常に最適なものを追い続ける。技術選定とは以降のバージョンアップも含めて長く考えることになってきます。

結論: エンジニアの開発体験と事業戦略とのバランスを取って最適な技術選定をすればいいんだよ

会社にとっての技術選定は、それが利益につながるかどうかで判断されます。しかし、エンジニアが楽しく高い生産性を生み出しながら働くためには、開発体験を良くすることも考えなければなりません。ひたすら辛い開発手法を用いて仕事してもけっして効率上がらないのです....私自身もコードを書く人間なので辛さはよく分かる。🥺

たかが技術選定、されど技術選定。1つのプロジェクトだけでなく会社の戦略にも大きく影響してくる。開発体験と会社の利益の両軸がそろって初めて技術選定は大きな価値を生むのです。今のベストな手法はなにか。常に意識して最良の選定をできるようにしていきたいですね。

shinoyu

CTO兼人事なエンジニア

1986年生まれの35歳。組み込みからキャリアを始め、モバイルゲーム開発、ECサービス、広告系のエンジニア経験しつつ、プロダクトマネージャーやエンジニアマネージャー、人事、インサイドセールスなどをやっていたよくわからない生き物。 今は自社プロダクトの開発頑張りつつ、クリエイターが働きやすい会社組織をつくるのをやってます。

関連記事

Copyright © 2022, chot inc.