読者です 読者をやめる 読者になる 読者になる

まるまるこふこふ

数々の次元が崩壊し、全ての生命が塵と化すのを見てきた。私ほどの闇の心の持ち主でも、そこには何の喜びも無かった。

技術採択のときにやるべきこと

初めに

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

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

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

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

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

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

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

採択理由のドキュメント化

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

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

  1. なぜ導入するのか?
    →どういう課題を解決するために導入するのか、あるいはどういう効果を見込んで導入するのか書きます

  2. 類似のライブラリ/フレームワークミドルウェアの調査
    →例えば JavaScriptフレームワークなら、 Backbone とか Angular とか React とか、 色々な種類があります。それぞれのフレームワークについて、特徴やプロジェクト導入に当たってのメリット/デメリットを調査します。

  3. 選定の観点
    →自チームに導入する際のより細かい要件について洗います。「1. なぜ導入するのか?」にて、 大まかな要件については洗えていると思うので、「類似のライブラリ/フレームワークミドルウェアの調査」にて調査した もののうち、どれか一つを選べるレベルには細かい要件を洗います。

  4. 結論
    「3. 選定の観点」で記載した観点に従って、「2. 類似のライブラリ/フレームワークミドルウェアの調査」のもののうち、 どれを選定したのか結論を書きます。

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

採択したいものを使ったプロダクトを1つ作る

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

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

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

その他"必ず"ではないけど"できれば"導入に際してやっといたほうがいいこと

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

フレームワークミドルウェア/ライブラリ自体の実装の理解

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

導入を手伝ってくれるメンバーを自分以外に2名作る

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

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