初めに

新規プロジェクト／既存プロジェクトで、新しく使うライブラリだったり、フレームワークだったり、ミドルウェアを選定してきた経験を通して、採択する段階でこれはしておいた方がいいなという知見が溜まったので、メモ書き程度に記述します。

前提として、技術採択についてある程度メンバーに裁量が任せられている風土があり、かつミッションクリティカルでないシステムに導入する、また自社で事業を行っており、顧客＝ユーザーであるというのがあります。

(この辺の前提条件が違う場合、採択に当たってまた別の観点が必要になってくると思います)

システム要件を満たしているかどうか

なんだかフワっとした言い方になりましたが、例えば Web システムに JavaScript のライブラリを導入する場合に、Web システムが IE8 に対応するという要件ならば、そのライブラリが、IE8 でも動くか調査するということです。

これをやらないと、開発期間の後半になって、システム要件を満たさないことが発覚して、ライブラリの変更及び実装したコードの破棄をするとかいう地獄になります

私の場合、例えば JavaScript のライブラリを導入する際は、Github の issue を見て、ブラウザ依存のバグレポートを検索したりとか、ライブラリを使って簡単なアプリを作ってみて、社内の検証用端末すべてで一通り動くかどうかチェックしたりします。

ライブラリの採択理由について、きちんと文字に起こして社内のwikiなりなんなりにみんなの見えるところに置いておきます。採択に当たっての関係者説得のために書かざるを得ないのが大抵でしょうが、求められなくてもきちんと書いておきます。

ドキュメントを書く際の観点は以下です。

なぜ導入するのか？
→どういう課題を解決するために導入するのか、あるいはどういう効果を見込んで導入するのか書きます
類似のライブラリ／フレームワーク／ミドルウェアの調査
→例えば JavaScript のフレームワークなら、 Backbone とか Angular とか React とか、色々な種類があります。それぞれのフレームワークについて、特徴やプロジェクト導入に当たってのメリット／デメリットを調査します。
選定の観点
→自チームに導入する際のより細かい要件について洗います。「1. なぜ導入するのか？」にて、大まかな要件については洗えていると思うので、「類似のライブラリ／フレームワーク／ミドルウェアの調査」にて調査したもののうち、どれか一つを選べるレベルには細かい要件を洗います。
結論
「3. 選定の観点」で記載した観点に従って、「2. 類似のライブラリ／フレームワーク／ミドルウェアの調査」のもののうち、どれを選定したのか結論を書きます。

これをやらないとプロジェクトが終わった後、導入して良かったのか／悪かったのかが振り返れません

社内向けシステムでも、個人プロダクトでも良いので、採択したいライブラリ／フレームワーク／ミドルウェアを使って、プロダクトを一つ作ります。ToDoアプリレベルではなくて、できれば人に使ってもらえるレベルのプロダクトを作りたいところ。

これをやらないと導入してみたもののよくわからなくて作りきれないというのが発生します

いやご冗談をと思うかもしれませんが、他の人の話を聞くと、たまにあるねん……

上記3つは、必ずやっておいた方がいいことです。以下2つは"必ず"必要なのかちょっとまだ判断しかねていることです

フレームワーク／ミドルウェア／ライブラリ自体のバグを踏んだ際に、原因の特定に時間をかけずに済んだり、フレームワークにパッチを当てるあるいは、フレームワーク自身にバグfix のプルリクを送る等の対処が可能になります。

TED Talk に「How to start a movement」というのがあります。ムーブメントとは３人揃うとそこから加速的に賛同する人が増えるよって感じの話です。

技術導入は、常に「本当にやる必要があるのか？」「やっぱり止めたほうがいいのでは」という周囲の目線に晒されます。一人で導入を進めていると、そういう目線に負けやすいので、そういう時に一緒に戦ってくれる仲間がいると、導入が進めやすいです。