個人的に技術選定について想いを馳せた記事です。

技術選定と妥協

最近とても技術選定について悩んでいます。技術選定とは常にジレンマを伴い、各エンジニアの感情がぶつかり合うセンシティブなトピックです。

技術選定が「悩む価値のある問題」であるのは明確で、サービスそのものの市場領域を選ぶときほどではないけど、開発組織が長期に渡って健全にワークするか、というのを決める、非常に重要かつ長期にわたる問題だからです。

加えてこれは個人的な話ですが、僕は自分のエンジニアとしての性格なのか、「ビジネスとしてうまくいくスピード感があるのか、明確な課題があってそれを解決しているのか」という意見は前提にしつつ、ある程度技術的新規性に重きを置きがちなタイプという自覚があります。

なので、僕個人は技術選定となると、新規技術の導入に逸る気持ちを意識して抑えなくてはならないことが多いです。ただ別にそこまでネガティブな感情を覚えてはいません。チーム開発の効率が下がったり、ビジネス設計とシステム設計のゴールが一致しないまま、サービスが儲からないのが一番渋いのは知っています。

技術選定と学習の投資対効果

さて、今まではここまででよかったのですが、これからはそうもいかないな、と思い始めました。プログラミングだけに没頭するわけにはいかなくなり、より一層技術への投資対効果を意識し始めたからです。この場合、各個人あるいは僕自身がどういうポリシー、評価軸に基づいて技術選定をしているのかを、より明らかにしなければ、「いかなる場面でも時間を最適に使いつつ新技術を学ぶ」ことはできません。

個人の時間は自由に、こうした評価軸に縛られず勉強するのが良い...というのは、エンジニアとしてキャリアを積み続けたい場合の一つの解ですし、僕もそう思っていました。

ただ、僕個人がそこまでエンジニアで居続けることへの執着がない、というより積極的に距離を置こうと考えている事情があり、歳を重ねるごとに技術に対する時間の投資対効果を自問するようになりました。また、ちょうど在籍している企業で以下のようなブログ記事が公開されていたこともあるでしょうか。（宣伝）

そういう背景があって、ここ数日「チーム・個人両面から技術選定をどのようにするべきか」を考えていました。

技術選定以前

何かを選定するには、根拠となる評価軸が必要です。この評価軸ですが、様々な記事などを拝見したところ、細分化せずに書くと、

・UX向上
・売り上げ貢献
・開発生産性向上

のいずれかないし複数を重視している印象があります。

そして、あくまでこれらの目的の実現が第一で、「手段の目的化をしていない」というのが全ての技術選定にあるべき前提とされているようです。

ただ、新規技術の導入で生産性が下がったり、UXが下がってしまう例をそこまで知らないため、個人的には「これらの目的にどれだけ繋がっているか」は評価軸としてあまり意味をなしていないと思います。

もちろん、環境要因でこうしたことを意識的に唱えていかないといけない事例もあると思いますし、その経験もありました。しかしそれは「魅力的な技術群の中から選出する困難さを評価軸によっていかに解決するか」ではなく、「どんな姿勢で技術に向き合い、ある程度下調べした上で候補を並べているか」という、最終選定以前の候補列挙の段階の話なので、ここでは取り扱わないこととします。

なお、そもそもの適切な候補を列挙するためには、「各個人が時流に乗っかった技術を、実際に導入せずとも、資料をさっと読むなどして、概要だけでも知っておく」ということで大方解決する気がします。

技術選定の評価軸

実際の評価軸の話に移ります。細分化すると、以下のようになります。

サービス要件の担保

サービスの大前提となる要素が担保できているかどうかです。具体的には、

・セキュリティ要件
・結果整合性（特にストレージ）
・サービスの実現可能性（そもそもこれがないと実現できない的な）

などが当てはまります。FinTech系のサービス運用だとこの辺がかなり重要になってくる印象があります。

経済性

売り上げが上がるかどうか、損失が抑えられるかです。具体的には、

・サーバー代節約
・人件費節約

などです。１つ目はバックエンドの話ですが、人件費に関しては、フロントとバックエンドの両方に共通しており、「クロスプラットフォームフレームワークを選ぶか」「いずれのPaaSを選択するか」がこれに関わってきます。

また、「UX向上」も実際にはかなり売り上げアップに直結するため、経済性の軸に含めてしまう前提で項目を追加すると、

・速度改善性
・バグへの遭遇率の抑制

などが入ってくるでしょうか。「レンテイシ抑制」「フロントの表示速度」「可用性」等が具体例です。

開発生産性

開発チームメンバーの生産性がどれだけ向上するか、です。

・学習コスト（= 概念のシンプルさ、既存ノウハウとの親和性）
・人数規模への適合性
・メンテナンス性
・人的資源の可用性

などがあると思います。

人数規模への...というのは、「マイクロサービス構成にするほどの規模か」「人数少ないけどモバイル両OS対応したい」とかの話が出てきたときに重要になります。

この「学習コスト」が厄介で、あまりに重視しすぎると、手慣れている技術を選べば学習コストを抑制できる一方、別の軸で高い効用を生む技術を候補から外してしまいます。

個人的見解ですが、学習コストなんて多くても１週間程度だし、本来はこれが重要な軸として上がらないくらいには予習しておくのが理想だと考えています。

また、ここには含めませんでしたが、エンジニアのモチベーションが上がり、間接的に生産性が上がるという意味ではここに、

・学習モチベーション

を入れてもいいでしょう。

技術信頼性

サービスが技術と一緒に共倒れしたら問題なので、技術が採用するに足る信頼性を獲得しているか、は重要です。俗にいう技術的負債への懸念の裏返しです。

・本番採用数
・開発母体の安定性
・獲得しているスター数
・誕生からの年数

開発母体の安定性は、「メンテナ規模」「運営母体の経済力」などでしょうか。３番目はちょっとOSS寄りの軸ですね。

僕は結構この軸を気にするタイプで、個人で勉強するときも新しいからという理由で飛びつくことはあまりなく、スター数やその界隈で一定の評価を得ているかどうかに確証が持てない限り手をつけません。（前は違ったのですが、Reactの黎明期に不安定なアップデートに翻弄されて、「この時間の使い方は自分にあっていないかも」と考えたのがきっかけで変わりました。）

技術選定の困難さ

大体の評価軸は上記で網羅できると思うのですが、これだけ明示してもなお技術選定が難しいのは、単に軸が多いからというより、「その軸にどれだけ比重をおくかが、事業フェーズやドメインによって大幅に変わるから」でしょう。

「サービス要件の担保」はどのフェーズでも共通するとして、概ねスモールスタートのベンチャーだと「開発生産性」に比重が高く、逆に運用フェーズのミドルステージだと、「技術信頼性」や「経済性」に徐々に移ってくるかと思います。

そういう事情を考慮せず、単に「生産性が高いから」という理由で選んでしまうと、技術と一緒にビジネス成長が鈍化したり、初期メンバーのノウハウに密に依存してしまったりします。見方によってはそれで回るんだからいいだろ、という考えもありますが、溜まったノウハウの価値が全く違ってくるので、僕は全ての評価軸を吟味すべきと考えます。

自らの置かれているフェーズへの意識と、多くの軸を吟味する努力を怠ると、組織として「事業優先型」ないし「技術志向型」というような偏向性が生まれてしまい、いつか組織の歪みとなって現れます。

まとめ

技術選定以前の話と、評価軸について主観ながら論じてきました。

「課題解決に繋がるか」という議題だけだと、僕たちは「いったいどの課題を解決しているのか」「見逃している軸はないのか」という点を取りこぼしがちです。

こうした政治的な側面にも影響するトピックは、できるかぎり議論が公平になり、その結果が長期的な利益を産むように、「軸の網羅性を上げること」と、「吟味する慎重さを持ち合わせること」の２点に関して、多くの努力を払うべきでしょう。

何より、こうして洗い出したことで、僕はより良い新技術を触る可能性を高められたのかもしれません。しかし、あくまでWeb業界に身を置いてる人間の視点なので、もし足りていない軸があれば、ぜひ教えてください。ご連絡のためのツイッターはこちらです（宣伝）