技術選定の基準は、結局「チームが維持できるか」だけでいい

2021年の夏、不動産会社の新規WEBサービス構築に、初期メンバーとして参加した。

物件検索サイトの集客を増やすために、街の情報——お店や娯楽スポット——を登録して発信する、街情報検索サービスである。

初期メンバーというのは、いい響きである。

要件定義から入り、システム構成も決められる。

つまり、技術を白紙から選べる。

エンジニアにとって、これほどのごちそうはない。

そして、これほど危険な瞬間もない。

今日は、技術選定の話をしたい。

若い頃の私の選定基準

白状すると、若い頃の私の技術選定には、邪心が入っていた。

基準は、こうである。

この案件で選んだもの

さて、街情報サービスの構成を決める番である。

私が選んだのは、PHPとLaravel、フロントはTypeScriptとReact、インフラはAWSの標準的な構成だった。

正直に言えば、面白みのない選択である。

当時すでに、どれも枯れ始めた定番だった。

もっと尖った選択肢は、いくらでもあった。

でも、選ばなかった。

理由は三つある。

一つ。チームの過半数が、PHPなら書けた。

二つ。人が入れ替わっても、LaravelとReactなら市場から補充できる。

三つ。困ったとき、情報が大量にある。

唯一の冒険は、フロントにReactを入れたことだった。

当時のチームには、React経験者がほとんどいなかったのである。

だからこの選定には、セットの義務が付いた。

私がサンプルを作り、メンバーにレクチャーして回ることである。

技術を選ぶ人間が、その技術の先生になる。

選定と教育はセット。

これは以来、私のルールになっている。

選ぶだけ選んで、あとはチームで頑張って、は選定ではない。

丸投げである。

基準を一つにまとめると

技術選定の記事を読むと、評価軸がたくさん出てくる。

性能、開発効率、エコシステム、学習コスト、将来性。

全部正しい。

正しいが、30年分の経験でまとめると、結局一つの問いに集約される。

「自分が明日いなくなっても、このシステムは生き続けられるか」

今のチームで書けるか。

書けないなら、習得の投資はできるか。

人が辞めたら、補充できるか。

5年後、この技術はまだ息をしているか。

障害の夜、検索して答えは見つかるか。

すべて、この問いの言い換えである。

システムの寿命は、平気で10年を超える。

その10年の間、作った人間がずっといる保証は、どこにもない。

だから技術選定とは、性能の比較ではなく、自分がいなくなった後の世界の設計なのである。

初期メンバーの仕事は、最初にいるからこそ、最後まで見届けられない。

その自覚から、選定は始まると思っている。

尖った技術を選んでいい場所

こう書くと、「じゃあ一生定番だけ使うのか」と言われそうである。

そうではない。

尖った技術には、選んでいい場所がある。

撤退できる場所である。

システムの端っこ。

小さなツール。

失敗しても、切り捨てて作り直せる部分。

そこで新しい技術を試し、筋が良ければ、少しずつ中心に近づける。

いきなり心臓に入れないだけである。

あとは、POCのような、そもそも捨てる前提のコード。

私が新技術で遊ぶのは、もっぱらこの領域である。

遊びと本番を分ける。

書いてみれば当たり前だが、白紙の構成図を前にすると、この当たり前が揺らぐのだ。

白紙は、人を試すのである。

AI時代の技術選定

最後に、この話の現在地を少し。

AIが開発に入ってきて、技術選定の景色も変わりつつある。

学習コストの壁は、確かに下がった。

知らないフレームワークも、AIに聞きながらなら、かなり書ける。

情報の少なさも、AIがある程度補ってくれる。

では、マイナーな技術を選びやすい時代になったのか。

私は、逆だと思っている。

AIは、学習データが多い技術ほど、うまく書く。

定番のフレームワークのコードは、驚くほど正確に生成する。

マイナーな技術では、古い作法を平気で混ぜてくる。

つまりAI時代には、「AIが書き慣れているか」という新しい重力が加わったのである。

定番は、ますます書きやすく。

マイナーは、相対的にもっと不利に。

技術の寡占が進む懸念はあるが、選定する側の判断としては、シンプルになったとも言える。

チームが維持できるか。

その「チーム」に、いまはAIも入っている。

人間のメンバーと、AIのメンバー。

両方が書ける技術を選ぶ。

基準は昔から、何も変わっていないのである。