夏と花火と私の技術選定

こんにちは。夏になると、中高生の茹だる夏休みにひたすら「乙一」の文庫を読んだことを思い出します。 「乙一」の作品は、どれもあっと驚くようなホラーを提供してくれて、今でもたまに読み返します。最も印象が強いのは、棺桶に入れて地中に埋めるストーリーなどが収録されている「GOTH」です。

さて、そんな話は置いておいて、週末なにしてますか？忙しいですか？技術選定してもらってもいいですか？ということで、今日は技術選定について考えていきます。 私なりに、何らかの技術選定を行うときは、こういうことを考えているというのをツラツラと話していきます。

技術選定の定義

本記事における「技術」は、単純に言語のみならず、ライブラリ、フレームワークやインフラ基盤など、開発を行う上で選択肢となりうる全ての技術を対象とします。

また、前提として学術的な技術選定ではなく、より実践的な技術選定について考えます。すなわち、研究などを目的としたものではなく、何らかのサービス・プロダクトを開発する上での技術選定というわけです。

技術選定の目的

さて、出鼻を挫くつもりはないのですが、何らかのサービスやプロダクトを作る時、正直何を使っても作ることはできますよね。 新規の SaaS プロダクトを作る時に、 COBOL を使っても別によいのです。おそらく作れるでしょう。巷では、敬遠されている jQuery を使っても、全然よいのです。動くものを作れないよりは、大いにマシです。

一方で、サービスやプロダクトというのは、ユーザーが付き、継続的に価値提供をしていかなければなりません。さらに、営利組織であれば、そういった価値提供を通じて利益をあげなければなりません。 そういった時に、何も考えず技術選定を行ってしまうと、エンハンスやスケールにおいて、当然の如く壁にぶちあたります。壁を壊すために潤沢なリソースが確保されているならば別に良いですが、リソースのある環境は幻想であり、往々にして人類には余裕がありません。 技術選定というのは、そういった壁にぶちあたることを回避したり、壁にぶちあたったとしても壊さずに軽く飛び越えられるようにする、といった効率的な対処に繋がる大事なプロセスです。

そういう意味で、技術選定の目的は「サービス・プロダクトを継続的に開発するため」であり、この目的を組織的・技術的に掘り下げていきます。 技術的というのはその技術が廃れないかみたいな部分で、組織的というのは採用や教育といったところです

組織的な観点で考える

組織的な観点を端的に言えば「組織が存続・スケールできるかどうか」です。

採用

一番大事な観点です。採用が上手くいかない技術を選定してしまうと、組織としてのスケールが難しくなります。また、エンジニアという職業柄、転職は日常茶飯事でしょうから、スケールできない上にむしろ縮小していくこともあると思います。 採用が上手くいかない技術というのは、例えば、古すぎるあるいは新しすぎる言語・フレームワーク・ライブラリなどです。一方で、シニアエンジニアを採用するという意味では古い（枯れた）言語の方がよいですし、逆に新進気鋭の好奇心旺盛なやる気に満ち溢れたアソシエイトエンジニアを採用するならば新しい言語の方がよいです。このあたりのバランス調整は難しいところで、その時の市場を調査した上で、調整していく必要があります。 上記の話は基本的に言語・フレームワークレベルの話で、ライブラリはあまり影響を受けない話ですね。もちろん、古すぎるライブラリを使うと敬遠されがちではあるので、そこは注意が必要でしょう。

こと SaaS のスタートアップにおいては、とにかく新しい技術を使うべきだと思ってて、フロントエンドにおいては、 React / Vue / Angular と TypeScript を選び、バックエンドは Go, Rust, TypeScript を選ぶというのが唯一解なんじゃないかなと、最近は思っています（超偏見）

教育

組織を構成するメンバーが全てシニアエンジニアで教育が必要ありません！みたいな環境であれば理想ですが、シニアエンジニアが市場に溢れているわけでも、シニアエンジニアを大量に雇える資金があるわけでもないでしょうから、教育は切っても切り離せません。 社内で既に知見のある言語やフレームワークを選ぶか、インターネッツ上に十分な参考資料が存在するか、といったことは教育においてとても重要でしょう。

配置

教育と似たような性質がありますが、社内に知見のある言語やフレームワークで統一し、各メンバーがそれなりに精通していると、配置転換が容易になります。 これは、特定のタイミングや時期によってこの開発に注力しようといったときにリソースを集中させられる、あるいは、保守フェーズに入り開発リソースを引き剥がす際に効果を発揮します。

たまに、採用ページにおいて技術スタックが散らかりきっているケースがあると思います。Ruby, Go, Rust, Java, TypeScript, C# 全て使っています！みたいな。 これはどう考えても組織的にはマイナスで、一採用候補者から見れば「色々な技術を扱える」と受け取れるが、組織的に考えると、その言語・フレームワークの担当者が抜けてしまった場合に大打撃を受けることになるでしょう。

技術的な観点で考える

さて、ここからは技術的な観点で見ていきます。 技術的な観点を簡単に言うならば、「継続的に開発できるかどうか」です。

運営体制

名も無い組織よりは、名の知れた組織の方が信頼できますよね。旅先では名も無い飲食店に入るのが好きな私でも、技術選定は名の知れた組織の技術を使います。 名も無い組織でも、もちろん素晴らしい技術を提供している可能性もありますが、不安定さ故に急に開発が止まったりすることがあると思います。一方で、知名度の高い組織は、その尊厳や周辺環境への影響を考慮すると、急に開発止めます！みたいなことは起こりにくいはずです。「はず」というのは、往々にして開発止めます！みたいな組織もたくさんあるので、絶対に信頼できるかと聞かれたらそうではないという意味を込めています（保険）

どの組織が開発しているかももちろん重要ですが、組織を構成しているメンバーも重要です。例えば、Twitter や Facebook といった組織自体は信頼できるが、その中に一人も TypeScript に知見のある人がいないのに、TypeScript のフレームワークを作っていたり、とか。 上は完全に例えの話ですが、これ自体は結構よくある話で、他の言語のフレームワークを作っている組織が、別の言語でも似たようなフレームワークを作る時、得意とする言語仕様に則った作り方をしてしまう、みたいなことがあります。

コミュニティ

GitHub 上のコミュニティや、フォーラムの設置など、ユーザー同志あるいはユーザー対運営のコミュニケーションを促すような施策を取っているかは地味に重要です。 テクニカルサポートが無いと解決できない問題も往々にしてあります。GitHub で言えば、Issue や PullRequest に対してウェルカムな空気を作れているか、みたいなところに着目するとよいと思います。

ドキュメント

技術的な観点で最も重要です。これが無いと、なにも始まりません。 ドキュメントと言っても、単純に生えているメソッドと引数を列挙したものでは手元で試してみないとわからないでしょうから、プレイグラウンドが提供されているか、UIライブラリで言えば実際に触れるデモ環境が用意されているか、といったところに着目します。

開発

活発性

コミュニティに通ずる部分ではありますが、どの程度の頻度で追加開発・改善を行っているかは見るようにしましょう。 高頻度も更新に追従するのが大変ではありますが、あまりにも低頻度で更新されている場合はバグがなかなか治らなかったり、夢に見たあの機能はずっと Coming soon でしょう。

健全性

活発性に似ていますが、GitHub であれば、Issue や PullRequest が放置されていないかも見ましょう。 Issue に対応しきれていなかったり、整理されていないケースはたくさんあります。今後、自分たちも Issue として何らかの報告や質問を投げた時、迅速に解決できるかの指標になります。

可読性

ドキュメントやイントロダクション通りに使っているけど、何故か上手く動かない時があるでしょう。もちろん、利用側の問題である事の方が多いですが、利用しているフレームワークやライブラリも人間が作っているでしょうから、バグは存在します。 この時、Issue で投げるのもよいとは思いますが、ソースコードを見にいくのもまた一つ手だとは思っています。その時に、コードが読みやすいか・読みにくいか、あるいは設計が綺麗かそうではないか、というのはすごく重要なことです。

コードを読みにいくのは最終手段とは言え、読みやすいに越したことはないですし、利用しているフレームワークやライブラリがどのように動いているのかを知るのも、利用者にとって良いことだと思います。

依存性

特定のライブラリやフレームワークに内部的に大きく依存しているケースは多くあります。例えば、 React でいうところの Next.js みたいな感じです。 React の開発が止まった時を考えると、果たして Next.js はどうなってしまうのか...？「次回、Next.js 死す！」みたいになることは無いと思いますが、それなりに大きなダメージを受けると思います。React のメンテナンスを Next.js を開発している Vercel が引き継ぐか、取り込むかみたいな話になるとは思いますけど。

もし、React も Next.js も弱小（？）のフレームワークだった場合、上記のようにはならないでしょう。おそらく、React の開発が止まった時点で Next.js の開発も止まります。あるとすれば、有志を集めての開発続行くらいですね。 こういったリスクは、いわゆる OSS では付き物ですが、可能な限り避けたいリスクではあると思います。

拡張性

人の欲望は青天井です。常に欲望は大きく、広がり続けます。 当初は想像していなかったような要求が出てくることは往々にしてあります。そう言った時、最終手段として魔改造できるかも重要な指標だと個人的には思っています。 それは、外から干渉して魔改造するでもよし、ソースコードを丸ごと落として中から魔改造するでもよし。色々な手段があるとは思いますが、魔改造できるかどうかは確認しておきましょう。

触り心地

とはいっても、やはり大事なのは、触り心地ですね。 私は、なんとなく CSS in JS が好きになれません。上手く言語化できないのですが、JS ファイルの中に CSS ファイルが入っているのは違和感があります。おじさんなのかもしれません。

こういった、「なんとなく使いにくい」みたいな感覚は、無視できると言えば無視できますが、確実に精神と肉体を蝕んでいくので、素直に向き合いましょう。

おわりに

技術選定は、開発者の中だけで閉じることではありません。組織とプロダクトの今後の方向性を鑑みつつ、適切に選定していきましょう。

また、とりあえず新しい技術を使えば良い、人気な技術を使えば良いみたいなことは全くなく、地道に調べた情報を相対的・絶対的に評価することが重要です。

以上、久しぶりの投稿は一行もコードを書かずに、これにてドロンです。