技術選定するときに考えていること

はじめに

仕事やOSS開発を通して組織的な開発における技術選定に携わらせていただく機会があります。
それぞれ背景が異なるものの考えていることの共通点は多いので私が技術選定で考えていることをアウトプットしてみます。

考えていること

1. 要求を満たせるか

まずは問題を解決できるかです。
特定の問題を解決できるソリューションにはいくつもの候補があります。
ただし、プログラミング言語など汎用的な技術は、どの選択肢をとってもある程度のことはカバーできるため選定の意思決定に大きく影響を与えないケースもあります。
要求にはライセンス、セキュリティなど見えにくいものも含まれます。

2. 変化に強いか

技術に対する変化は早くて大きいので持続可能であるかは重要です。

例えば、

• ソースコード自体の品質
• 依存ライブラリとバージョン
• メンテナンスチームの活動量
• コントリビューター人数
• IssueやPRの数、内容、open/closeの比率
• star数やその増加傾向

などです。

ライブラリは、メンテナンスが停止した場合や自分たちの利用がエッジケースである場合に変更リクエストが出せるか、受け入れられるかが重要です。
最近では、React Server Componentや新興分散DBのサポートなど、パラダイムチェンジを伴う技術進化にどれだけ追従しているかも重要な要素になっています。

3. 周辺を取り巻く環境

多くの場合、特定のプログラミング言語やライブラリ単体ではシステム全体の構築はせず、複数の技術要素を組み合わせる事になります。
例えば、Webアプリケーションの場合は、ルーティングレイヤーのフレームワークやデータベースアクセスなど複数の技術を組み合わせて構築することになります。
そのため、周辺のライブラリとの組み合わせや、サポート状況の過去、現在地点と未来予測などの時系列を加味した視点が必要です。

4. メンテナーの思想や設計方針

特定の問題を解決するライブラリが複数存在するのは、それぞれの設計方針や思想、メンテナーのバックグラウンドが異なるためです。
どのアプローチ方法が自分たちの問題解決にフィットしているか見極める必要があります。
例えば、その技術がデファクトスタンダードに対して全く異なる視点で問題解決にチャレンジしているのか、あるいは実行速度や内部品質などを目的としたリライトなのか、といった点などです。

5. コミュニティ

実際に開発を行っているコントリビューターだけでなく周辺のコミュニティも重要です。

OSSは広く使われることでフィードバックを得て改善が行われ、さらに広く使われるサイクルが生まれるため周辺のコミュニティの存在は必要不可欠です。
具体的には、技術要素が属するカテゴリやコミュニティの大きさ、利用事例などが指標になります。

6. 組織ケイパビリティ

採用した技術を使いこなし最終的に利用者にポジティブな変化をもたらせる事が重要です。

選定した技術を扱うのは関わる開発者全員であるため組織にその技術を扱う能力があるかも重要な基準です。開発者に現在その能力が不足している場合にはギャップを埋める事ができるか、実現可能な計画があるかという観点も考慮する必要があります。

7. 新規コントリビューターの参加

該当するスキルを持つエンジニアの開発参加が増えることも重要です。

開発対象に興味を持つエンジニアにとってスキルギャップが障壁とならず、新しくキャッチアップするとしても理解が容易か、関心を得られるかどうかも重要な観点です。

また、技術的なブランディングも新規コントリビューターの参加に影響を与えます。特定の技術領域での認知を獲得することでエキスパートがその領域に深掘りし、他の開発者も知見を得る好循環が生まれます。そして、それらは将来の期待にも繋がります。

一方で、コアの技術選定が不十分であると不信感や実現可能性への不安を繋がるリスクがあります。
ソフトウェア開発組織におけるコアである技術選定に一貫性がない場合や、理由もなくレガシー技術を維持している、問題があるにもかかわらず放置されている場合は新規コントリビューター参加の障壁になってしまいます。

8. 成果物の開発予測との親和性

最終的に作りたいアウトプットとの整合性も重要な観点です。

例えば、とにかく機能を豊富に揃えたソフトウェアを作る場合、技術的なトラブルが少なく不確実要素が少ない技術選定が重要です。
一方、継続的な改善を行うソフトウェアを作る場合は、コード量が増えてもメンテナンスが容易で内部品質を維持しやすい、維持する構造を持たせ易い技術選択が適切です。

9. 個別の選定が全体に与える影響具合

個別の選定がシステム全体に与える影響具合も重要な観点です。

例えば、Webアプリケーションにおけるルーティングフレームワークやデータベースアクセスなど、変更が難しい技術であれば、安定性や情報量が意思決定に大きく影響します。
一方、個別機能に特化したライブラリなど、変更が容易な技術であれば、チャレンジングな選択肢を採用することも可能です。

10. 未来予測

機能比較の星取り表だけでは比較しきれないものがあると考えています。
選んだ選択によって「遭遇するであろう課題」と「享受できるであろう恩恵」が全く別な選択があるので、業界トレンドや過去からの変化、今後の方向性から予測をした上で「どっちの世界線に行きたいか？」の決断も必要だと考えています。

自分の意思決定の軸

技術選定はここでは書いていない要素も含めて様々な因子が絡み合い、それぞれ抽象的な内容で、想像で補う要素も多くあります。自分でコントロールできないことも多分にある不確実の高い意思決定です。
こうした状況で八方塞がりにならないよう自分なりの意思決定の軸を定めています。その軸として、以下の2つを特に大事にしています。

ここで書いていない要素も含めて様々な因子が絡み合います。それぞれ抽象的な内容でかつ想像で補う要素も多いです。さらに自分でコントロールできないことも多分にあるため技術選定は不確実の高い意思決定です。
こうした状況で八方塞がりにならないよう自分なりの意思決定の軸を定めています。その軸として、以下の2つを特に大事にしています。

1. 正解がない問題に対して決断を正解にしていく姿勢と努力

大切なことは「その意思決定は正しいか？」ではなく「意思決定したことを正しいものにしていく覚悟はあるか」と言うことになるのだと思います。

Ref: https://medium.com/@guro/採用担当の幸せな一日-ef28e6468308

「その意思決定が正しいかどうか」ではなく、「意思決定を正しいものにしていく覚悟を持てるか」は技術選定に限らず、様々な分野において大事にしている考え方です。
そのための覚悟や自信を持つためには、次に述べる自分の中で「ポジションや軸を明確に置く」ことが不可欠だと考えています。

2. 自分のポジションや軸を明確にする

意思決定にとことん向き合い自分の立ち位置や考えを明確にすることで、その後の結果を学びに変え熟練へと繋げることができます。
逆に、熟考する事を止めて場当たり的な判断をしてしまうと、どの部分で考えが変わったのか、どの点で先読みが外れたなどを把握できず、次につながる効果的な学びが得られないため熟練へと繋がりません。

以下は、私が意思決定において重視している具体的な方針です。

• 無駄な逸脱を避けるため業界標準にフィットしている場合はデファクトを積極的に採用
• 新しいアプローチで大きな恩恵が期待でき、自分が改善にも参加できる技術であれば発展途上であっても積極的に採用する。ただし撤退や代替手段も考慮する。
• 大きな成果が得られる見込みがない技術は採用しない
• 人は学習し成長する事を前提として「慣れているから」「今そうだから」という理由だけでは採用しない

これらの方針を軸に、結果に向き合いながら調整していくことが意思決定の質を高めると考えています。

おわりに

こうしてみると改めて技術選定の楽しさ、大事さ、難しさを感じますね。
今後も学びとアウトプットの機会は大事にしていきたいです。