【怪文書２】積極的な技術選定と消極的な技術選定
こんにちは。ぬこすけです。
※この記事を読む前にまずはuhyoさんの「積極的な技術選定と消極的な技術選定」をお読みください。
本日、 uhyoさんが次のような「積極的な技術選定と消極的な技術選定」という記事を公開しました。
私はこの記事を読んで目から鱗でした。
積極的な技術選定と消極的な技術選定について、今まで言語化できていなかったものが言語化された気がします。
そして、uhyoさんの記事を読んでインスピレーションを得たのは、「積極的な技術選定と消極的な技術選定をベースに、組織によってとりうる技術選定が違うのではないか」ということです。
uhyoさんの怪文書をさらに怪文書にさせていただきます。
なお、この記事で言う技術選定とは、プロダクト開発初期における技術選定だけでなく、運用フェーズにおける技術選定（例えば一部のライブラリをリプレイスする）といった意味合いも含んでいます。
我々がとりうる技術選定
まずはこの図を見てください。
はい、 怪文書ですね 。
怪文書なので 1 つ 1 つ丁寧に説明していきます。
まず、縦軸と横軸に「内的」と「外的」というワードが出てきます。
これは「エンジニア組織内部」と「エンジニア組織外部」と捉えてください。
エンジニア組織外部は、例えば営業や企画などのビジネス部門や会社そのものなどエンジニア組織以外がこれにあたります。
縦軸と横軸には「変数」というワードもあります。
変数は「エンジニア組織にとって好条件を総合的にパラメータ化したもの」です。
数値として出せるものでもないので概念的なものとして捉えてください。
これを前提に「内的変数」と「外的変数」をそれぞれ説明していきます。
横軸の「内的変数」とは「エンジニア組織内部の観点で好条件のパラメータ」です。
エンジニア組織内部の観点で好条件とは、例えば次のような例が挙げられるでしょう。
- エンジニアの人数
- つよつよエンジニアの人数
- ドキュメントやリポジトリなど過去作成したストックの量
例えば、エンジニアの人数が多く、かつつよつよエンジニアの数も多いのであれば、相対的に内的変数が高いということになります。
一方で縦軸の「外的変数」とは「エンジニア組織外部の観点で好条件のパラメータ」です。
例えば次のような条件です。
- 営業や企画などのビジネスサイド側の圧力
- 技術ブランディングの圧力
- 会社のエンジニアに対する投資
例えば、ビジネスサイドの圧力が小さく、技術ブランディングの圧力も小さいのあれば、相対的に外的変数が高いということになります。
補足すると、ビジネスサイドの圧力が小さければ、仕様や納期がエンジニア側でハンドリングしやすく好条件です。
あるいは技術ブランディングも小さければ、エンジニア主体で技術選定できるので好条件です。
さて、uhyoさんの言う「積極的な技術選定」と「消極的な技術選定」というのは図で言うと「正方向の矢印」になると思っています。
内的変数と外的変数が高ければ「積極的な技術選定」、内的変数と外的変数が低ければ「消極的な技術選定」を取るべきです。
例えばつよつよエンジニアがたくさん在籍しており、ビジネスサイドの圧力もなく納期も自由に決められる場合は「積極的な技術選定」をすべきでしょう。
一方で少数の新卒エンジニアしかおらず、「今月にプロダクトをリリースしてください」とビジネスサイドに言われることが多い場合は「消極的な技術選定」にせざるをえません。
「積極的な技術選定」をすべきでしょう。
「消極的な技術選定」にせざるをえません。
あえて すべき と せざるをえない と表現しました。
筆者が考える望ましい技術選定というのは、まず技術のみを勘案して理想的な技術選定（積極性100%）を考え、その後に現実を見て、妥協として消極的な要素を混ぜ込んでいくというものです。
uhyoさんの記事を引用させていただきました。
先ほど、「積極的な技術選定」と「消極的な技術選定」というのは図で言うと「正方向の矢印」になると述べました。
技術選定においては基本的に 右上から積極的な技術選定をし、妥協をしながら左下の消極的な技術選定に移っていく のではないでしょうか。
理想を考えるなら積極性100%な技術選定でしょう。
しかしながら、エンジニアのリソースや納期などエンジニア組織内外の要因から現実は100%を実現するのは難しいです。
ある程度妥協しながら「消極的な技術選定」に移っていくのではないでしょうか。
エンジニア組織内外の要因により右上から左下へ技術選定の方針が切り替わる中で、筆者はいくつか技術選定の種類があると思うのです。
冒頭にあげた図を再掲します。
それぞれについて説明します。
①最強な技術選定
これは エンジニア組織内外の要因が好条件の場合にとりうる技術選定 です。
天才エンジニア集団がたくさん在籍、会社もエンジニアにどんどん投資し、エンジニアの裁量もかなり大きいケースです。
ですが、この選定が実現できるケースは稀でしょう。
Google に代表される某有名テック企業が 最強な技術選定 を行っているのではないでしょうか。
②先見の明ある技術選定
エンジニア組織内部の観点では好条件ですが、外部の観点では好条件ではない場合にとりうる技術選定 です。
例えばエンジニア側はリソースは潤沢ですが、「今月納品なのでよろしくぅ！」というビジネス側の圧力が強いケースです。
本当は採用したい技術はあるが、外的要因でやむなくエンジニアは妥協の技術選定を行います。
が、将来的な技術のリプレースや新規導入を見据えます。
例えば新規プロダクトの開発初期は技術選定を妥協をせざるを得ない部分が出るでしょう。
しかしながら、ただ妥協をせず、将来的なリプレースを見据えてスイッチングしやすい技術選定をします。
時間を経てプロダクトの運用フェーズになり、ビジネス側の要求も落ち着いたらリプレースをすることで ①最強な技術選定 に近づけます。
③学びながら技術選定
エンジニア組織外部の観点では好条件ですが、内部の観点では好条件ではない場合にとりうる技術選定 です。
例えば仕様や納期などはエンジニア主体で決められますが、本来とりうるべき技術スキルにエンジニアが追いついていないケースです。
このようなケースでは例えば定期的に勉強会などを開いてエンジニアのスキルを上げる、つよつよエンジニアを採用するなどしてエンジニア内部を好条件にして行き、期を見て技術のリプレースや新規導入をして ①最強な技術選定 に近づけます。
④負債まみれの技術選定
エンジニア組織内外の要因が好条件でない場合にとりうる技術選定 です。
とりうる選定というか、 もうとらざるをえない技術選定 です。
このケースはかなり追い込まれた状況でしょう。
エンジニアリソースも潤沢でなく、外的な圧力も大きくてどうしようもないです。
①最強な技術選定 へ近づけるのは難しいでしょう。
まとめ
uhyoさんの「積極的な技術選定と消極的な技術選定」にインスピレーションを得て、エンジニア組織内部/外部の観点から我々がとりうる技術選定を考えました。
賛否両論あるかもしれませんが、 1 つのかとして優しい目で見てもらえればと思います。 by ぬこすけ
Discussion