こんにちは、エンジニアリングマネージャーの山口です。

先週に引き続き、技術選定に関して私の考えを書いていきます。
前回の記事では、技術選定を【誰が】【どのように】すると良いのかを書きました。
しかし、技術選定においてどこまでOKなのか。に関しては言及していなかったので、今回はそこから書いていこうと思います。

技術選定の【自由度】

残念ながら制限がない自由は存在しないものです。
それは技術選定においても同様で、制限のもとの自由となります。
よって技術選定の自由度とはどのように制限を設計するかに依存します。

制限をどのように設計するか

組織の現状と将来どうなりたいかによって制限の設計は変わると考えています。

そこで、以下のステップで制限設計してみるのはどうでしょうか。

自社で使っている・いないに関わらず世の中にある技術をリストアップします。
できるだけ多くの技術を洗い出せるとよいです。

①でリストアップした技術をLv1~4に分類してレベル表を作ります。

なお、レベルは以下のようなイメージです。

Lv	イメージ
Lv1	世の中で当たり前に使われている技術、使っていないと危機感を感じるようなもの
Lv2	多くの企業が導入している技術
Lv3	半数の企業が導入している技術
Lv4	1割の企業が使っている先進的な技術

このとき、自社の状況で分類するというよりは、世の中の状況で分類します、また、サーバサイドやフロントエンド、DevOpsといった領域ごとでの分類をするほうが良いと考えています。
例えば、フロントエンド領域の技術をレベルに分類すると以下のようになります。

領域ごとに自社のレベルを判断します。感覚です。

③で見定めたレベルがLv2だった場合、組織としてLv2を維持するのか、Lv3まで引き上げるのか、Lv4までチャレンジするのかを決めます。

現状の組織はLv2で目指すべきレベルがLv3だった場合は、Lv1〜Lv3にカテゴライズされた技術が選定可能になります。
目指すべきレベルがLv4だった決めた場合は、リストアップした技術がすべて選定可能なものとなります。

プロダクト開発チームは、この組織の目指すレベルの中で選定する技術を選ぶことが出来るようになります。

レベル表をgitで管理し、メンバーからPullRequestで変更を受け付けるようにするとよいのではないかと考えています。

先程あげたフロントエンドのレベル表であれば、ES5をLv1に追加するPullRequestや、AngularをLv3に追加するPullRequestが作成される可能性が高いです。
これらを、組織に責任を持つ人がレビューしApproveするかどうかを決めると良いのではないでしょうか。

また、このレベル表は世の中の流れを反映したものになります。
今はLv3に分類される技術だったとしても、1年後にはLv2になっているかもしれません。
このようにレベルを変更するPullRequestもメンバーから提案を受けるような形にすると良いと考えています。

実はこの考え方は、InfoQで公開されているトレンドレポートを見たときに、自社がアーリーアダプターなのか、アーリーマジョリティなのかを考えたときに得た着想です。

したがって、InfoQのレポートを参考にレベル表を作成すると捗ります。
そもそも、トレンドレポートをそのまま使うことも考えて良いと思います。

その場合は、自社をレベルで捉えるのではなく、イノベーター理論の5つの分類のどこにいて、どこを目指すのかを決めると良いです。「今はレイトマジョリティにいるので、アーリーマジョリティを目指すと。」いったように。

ここまではプロダクトチームが技術選定するという軸で書いてきました。

しかし、プロダクトチームの責任を超えた範囲にある技術選定もあります。

たとえば、オンプレからクラウドへの移行、またクラウドからオンプレへの移行を行おうと思った場合、組織として新しく予算確保が必要になってきます。

いろいろな状況次第ではありますが、大きな予算確保が必要になることがあるのではないでしょうか。

この予算確保の動きの中で、その意図を事業責任者もしくは経営へ説明する責任が発生するので、難易度が高くなる傾向があります。

IT監査対応はどうしてもトップダウン施策になるため、組織の責任として行うことになります。IT監査のための仕組みも管理統制の便宜上、共通化することが理想と考えています。

その上で、プロダクト開発チームのパフォーマンスにネガティブな影響を与えない仕組みの構築が組織として行うもう一つの技術選定になると考えています。（組織が専任チームに技術選定を委任するケースもあります）

このコンテキストで行われた技術選定は、例えば以下のような施策になるのではないでしょうか。

Infrastructure as Codeの推進
- クラウドリソースの管理はTerraform、サーバ内の構成管理はAnsible
クラウドリソースコントロールのCI/CD化による管理統制
- DevチームはCode上のリソースを修正しPullRequest
- OpsチームはPullRequestをApproveすることにより反映