はじめに

技術選定の際の情報取集の観点や具体的な手順について紹介します。社内の後輩に話す機会があったため、よい機会なので整理してみます。

ある特定の技術的な課題を解決する際、その選択肢が複数ある場合 があります。
例えば、アーキテクチャのレベルであれば複数のクラウドサービスの構成について、アプリケーション全体のレベルでの言語やフレームワークについて、また特定の課題についてのライブラリについて。
そうした場合には、どの手段を利用するかについての意思決定が必要になります。
今回は特にライブラリのレベルに着目してポイントを紹介していきます（一般的には各レベルでの選定に応用が効くと思います）。

そもそもライブラリは必要なのかという点を考える

はじめに、自分で実装するという手があることを思い出しましょう。「ライブラリを選ばない」という選択肢があるということです。多くの場合ライブラリが解くべき課題にジャストフィットすることはなく、ライブラリの採用は解くべき課題以上の機能・負債をもたらします。
またいつかメンテされなくなる可能性もあります。ライブラリが背負う技術的な負債は自分が担当するプロダクトも背負うことになります。自分で実装し、テストを書き、メンテをするというコストのほうが、ライブラリを採用しライブラリ全体のメンテをするコストよりも小さい可能性があるということです。
長持枕にならずということで小さな課題は自分で解決するほうが結果として保守しやすいプロダクトにつながる可能性があります。

技術的な要素の検討

ライブラリの採用に当たっては、どのような技術が利用されており、どのような課題を、どのように解決しているのかについて把握しておくことが重要です。いかにいくつか具体的な観点を取り上げます。

解くべき課題を解決することができるか

当然なのですが、解くべき課題を解決できることが第一です。また、できるだけシンプルにライブラリを利用するだけで解決できるとよいです。ラップするようなコードを重ねに重ねて解決できるとすると、その分手間も負債も大きくなります。

ライブラリの設計思想は明確か

設計思想が明確なライブラリを利用するほうが望ましいです。明確な設計思想があるライブラリには複数の利点があります。第一に、解くべき課題とのフィット度合いが明確になりやすいです。
第二に、利用者目線として理解がしやすいです。ある機能を理解したときに、別の機能を把握する時間が短くなり、その理解も有機的になります。
第三に、ライブラリに機能が追加されるときに方向性がブレにくくなります。長期的に利用しやすいライブラリになるということです。

ライブラリの設計思想を知るためには、ランディングページやGitHubのREADME、Docsなどを読むとよいでしょう。
思想が明確なライブラリほど、その特徴を強調するものなので、これらの公開のドキュメントによく表現されています。

例えば、React向けのルーティングライブラリであるTanstack Routerは以下のようなページを作っており、TypeScriptの型推論を効かせ開発者体験を如何に改善するか、そのライブラリ設計についてかなりの紙幅を割いています。

手前味噌ですが、簡単にその思想を紹介している記事を書いています。

APIなどは(ある程度)安定しているか

ライブラリのステータスをある程度確認すべきです。特に新進気鋭のα版のライブラリなどはインターフェースなどの破壊的変更が行われる可能性があります。
特に商用のプロダクトなどでは留意すべきでしょう（もしくはその破壊的変更に付き添う覚悟をする）。

ベンチマークスコアはよいか

処理が高速であるか、ライブラリが軽量であるか、など他ライブラリとの比較情報・ベンチマークスコアについては多くのライブラリが自ら取り上げいることが多いため、参考にするとよいでしょう。

周辺的な要素の検討

純粋に技術的な要素以外にも実際に開発を進めていくうえで参考になる情報はたくさんあります。以下の観点を見ていくよいでしょう。

コミュニティ・メンテナンスは活発か

issueのやり取りの活発さやリリース頻度を見ることは重要です。かなり大きめのフレームワークやライブラリであればDiscordのサーバなどのコミュニティを持っていることがあるため、それらを覗いてみるのもよいでしょう。
リリース頻度が少ないライブラリは枯れていて課題に対して必要十分だからという可能性もありますが、人が離れ問題が放置されているだけの可能性もあります。
例えば大量にissueがたてられているのに、リリースは全くされないライブラリはメンテナンスを放置されている可能性があります。

例えば、以下のExcelをJavaScriptで扱うライブラリは、かなりのissue(しかもBug報告)があるのに、更新が止まってしまっています。

公式ドキュメント・APIリファレンス・実装例は充実しているか

ライブラリのメンテナーではない人にとって、ライブラリを理解する手がかりは公式ドキュメント・APIリファレンス・実装例になります。
これらが充実していればいるほどライブラリへの理解が早まり、利用しやすくなります。ライブラリを利用していて壁にぶち当たったときに、どのように解決するべきかについても目途を立てやすくなります（特に実装例）。

利用者が多いか

使っている人が多いライブラリはそれだけで使っている先人が多く、ナレッジがたまりやすいです。デファクトスタンダードなライブラリを選択する利点はそこにあります。
QiitaやZenn、Stack Overflowなどの非公式なフォーラムで自分が直面するのと同じ課題をすでに解決している先人たちの教えに接することができる可能性が高まるということです。

例えば、JavaScript/TypeScriptであれば、npm trendsなどを利用することで各ライブラリのダウンロード数やStar数などの情報を一覧してみることができます。

例： angular vs react vs vue

例：date-fns vs dayjs vs moment

ライセンス種別

特にオープンソースのライセンスはプロダクトの性質と関連する可能性があるため要確認です。

調査手順

以下では、上記の観点を踏まえて、より具体的にどのような調査・検討をすればよいかについて説明します。

0.解くべき課題を明確にする

自分が向き合うべき技術的な課題を明確に言語化しましょう。何をどこまで解決していればプロジェクトとしては嬉しいのかを明確にしておきましょう。
ふわっとした問題意識のままライブラリを採用してしまうと、開発がかなり進んだタイミングで大きな壁に直面してしまう可能性があります。

1.ググって断片情報を集める

調査の足掛かりとして断片情報を集めます。「どのようなライブラリが存在するか」を把握する作業です。
例えば、「JavaScript 日付ライブラリ」などで検索して上位に出てきたサイトのライブラリ名などを抑えておきましょう。
ここではあえて検索ワードを緩めにしておくのがよいと思います。あまりに具体的な内容を検索しても検索ヒット件数が少なくなりすぎる可能性があります。広く浅く情報収集をしましょう。
注意点として、それぞれのライブラリの位置づけを理解しているとは思えない低質な比較サイトなども検索では上位に出てくることがあります。
あくまで次のステップで調査・検討をするための断片情報の収集だと割り切って調査をすることが重要です。

生成系AIのWebサーチ機能を利用するのもある程度有効だと思うのですが、「よい検索結果を出すためのプロンプトを書くためには、ライブラリへの知識が前提になるのではないか」と思うと、自家撞着感も覚えます。

2.技術的な要素についての情報を収集する・プロトタイプを作成する

1.で集めた断片情報をもとに、技術的な観点からの調査を行います。
ここでは、対象のライブラリの公式ドキュメント・APIリファレンス・実装例などを調査します。
また、0.で明確にした課題を解決するプロトタイプを作成してみるのがいいでしょう。コードを書いて見るとライブラリへの理解が深まりますし、ライブラリを利用するにあたっての注意点なども明確になります。

3.周辺的な要素を収集する

ある程度技術的に採用してもよいライブラリについては周辺的な要素の調査を行います。GitHubのライブラリのリポジトリやnpm trendsなどを利用して調査を進めましょう。

4.最終的な意思決定をする

最後に、上記の収集した情報をもとにどのライブラリを選択するかの決定をします。シチュエーションによってどのポイントを重視したかは異なると思いますが、どの点をどの点より優先して決定したのかといった意思決定理由を明確にし、チームメンバーに共有できるとよいでしょう。

おわりに

本稿ではライブラリ選定において重視すべき観点について紹介しました。「そもそもライブラリを使うのか？（自分で実装するほうがいいのではないか）」、「ライブラリの設計思想を始めとする技術的な観点での情報の収集」、「（コミュニティやメンテナンス頻度など）周辺的な観点での情報の収集」が重要であり、ライブラリの選定ではそれらを踏まえた総合的な判断が求められています。