続・技術選定に関する私の考え

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

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


技術選定の【自由度】

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

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

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

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

① 世の中の技術を集める

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

② Lv1〜4に分類する

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

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

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

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

Lv 具体例
Lv1 jQueryなど
Lv2 HTML5など
Lv3 React, Vue.jsなど
Lv4 WebAssemblyなど

③ 自社の導入技術がどのレベルなのかを見定める

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

④ 自社の目指すべきレベルを決める

③で見定めたレベルが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つの分類のどこにいて、どこを目指すのかを決めると良いです。「今はレイトマジョリティにいるので、アーリーマジョリティを目指すと。」いったように。

JavaScriptとWeb開発に関するInfoQトレンドレポート

【組織が技術選定する対象】

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

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

大きな予算確保が必要になるもの

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

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

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

IT監査に対応する上で必要なもの

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

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

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

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

所感

​ 自分の中で考えていることを明文化するタイミングがなかなか無かったので、今回のブログ執筆を機にまとめてみました。
書き出すことで私の中で整理できたことも多くよい機会でした。締め切り駆動アウトプット最高。

弊社のコンテキストによるところが多い部分もあるかもしれませんが、参考になれば幸いです。