聞かれることが多いのでまとめる。プロジェクト開始時〜運用中まで、幅広い期間で使えることを想定している。具体的に A と B どっちがいい？というようなものでなく、より抽象化した項目でまとめている。
ポイントは 4 つ。
- 課題を解決できるか？
- チームメンバーが扱えるか？
- ROI が妥当か？
- 組織目標に沿っているか？
これらは制約として効いてくる。
実情にあわせて、これらをよりブレイクダウンした項目を作り、具体的な技術との星取表など作ると、自ずと選択肢が絞られてくるはずだ。
複数残った場合は好みで選ぶと良い。逆に言うと、絞る前の段階で感情的な判断を挟む余地はない。
最後にこれらをどう見極めるかも記載している。
課題を解決できるか？
まずはコントロールが可能な範囲、例えばプロダクトの課題解決などを考えるべきだ。その技術ができること、できないことをしっかり把握する必要がある。
注意として、ドキュメントに「◯◯ ができる」という記載があっても鵜呑みにしないこと。 ◯◯ という言葉の理解が異なったり、可能だが限定的であったりすることがもある。自分で素振りするのが確実だが、時間がかかる部類の技術もあるため実際に使った方のハナシや記事を参考にすると良い。
また、非機能要件もチェックすること。セキュリティ、速度、スケールするかなどはどういった技術であっても見た方が良い。
そもそも解決すべき課題なのか？
それは解決すべきものなのか、まず考えると良い。
- ユーザーニーズを間違って捉えていた
- その仕様は必要なくなった
- 別の表現に使うことによって課題がなくなった
- 今やらなくて良い
こういった状況もあるので、明確に課題を捉えてから解決に当たると良い。
チームが扱えるか？
開発はチームでするものなので、チームメンバーのことを考えたうえで選定すべきだ。
学習に負荷がかかりすぎないか？
まず確認すべきは学習のための時間を業務時間で確保できるかだ。業務時間外でのキャッチアップはメンバーへの負荷が高すぎる。
最もコスパが良いのは、プロダクトコードベース上での経験による学習だ。そのため、コードベースに組み込みやすく、経験するための時間が妥当であることを確かめると良い。日常的に実施する業務に組み込めるような技術だと最適。
困ったときに質問できる環境を用意しやすかったり、解決のためのリソースが豊富であることも学習負荷を下げることに寄与する。質問時にコンテキストを共有しやすいか、という点も考慮すると良い。環境を作らなければならなかったりすると手軽に質問できない。画面共有やスクリーンショット共有で足りるのであればコストも低い。
運用に負荷がかかりすぎないか？
ダブルチェックが必要など複数名であたらなければならないタスクが発生するような技術は運用負荷が高い。
長時間の拘束も同様だ。個別の作業は短時間でも、確認のために人間が必要だったりすると張り付かなければならない。
判断力を消費してしまうものは地味にコストが高いので気をつけること。 yes/no を打ち込まなければならないなど、半自動化にとどまっているものや、結果が flaky で信用しきれない場合も判断力を消費してしまう。
精神的な負荷も考慮するとよいだろう。同じようなコードを何度も書かなくてはならず DRY を実践しづらいなど、つらみを感じるものは比重を下げて良い。
精神的な負荷についてはひとによって程度が異なる。 A さんにはつらいことでも B さんは軽々やってしまうこともある。チームとして価値を出すので、大多数のメンバーが負荷を感じないのであれば採用するのはアリだ。ただし、つらみを感じる方へのサポートはきちんとすること。
将来のチームメンバーがすぐキャッチアップできるか？
新規メンバーがすぐにキャッチアップできるかどうかも大切だ。これは世間の一般的な感覚においていかれないようにする必要があり、ある意味でコストが高い。 X や Zenn などの技術コミュニティでの議論を見て感覚を養うと良い。
まず何よりも一般的な開発者のメンタルモデルから大きな乖離がないこと。受け入れられづらいものは「そうはならんやろ」というものが大半だ。自動テストが書きづらかったり、スタックトレースの中身を見ないと処理が成功したかどうかがわからないなど。
たまにイノベーティブな技術は飲み込むのが難しいこともあるが、実は既存技術の思想の一部を変更しただけであったり、環境が追いついて理想を実現可能になったりしたものであることが多い。 Rust の所有権は C++ でも思想としてはあったし、 LLM を可能にしたのはニューラルネットワークの実用化だが、これもクラウドコンピューティングによる計算資源の集約の結果だ。
また、学習コストが低い技術は大体次が整っている。
- サッと動かすためのドキュメントがわかりやすく、アクセスしやすい位置にある
- Getting Started という節にまとまっているなど
- 動かすためのコストが低い
- コマンドひとつで大体準備が整うなど
人類は環境と経験から学ぶところが大きいので、容易にそれらにアクセスできるもののほうがコストは低い。
ROI が妥当か？
今までに挙げてきたものと重複する部分もあるが、この項目はより組織としての判断という色合いが強い。技術を選択する、ということはそのままその技術への投資という意味だ。
業務時間で学習することを前提とする以上、そのための時間的、金銭的コストが発生する。それを組織として支払えるかがまずひとつ。
既存技術との同時運用期間が出てくる場合、それを許容できるかについても判断しなければならない。コストやメンバーへの負荷などを見ていくと良い。
また、今までと異なる技術スタックで組もうとした場合の切り替えコストも考慮しなければならない。 Vue.js で組んでいたものを React に切り替えるなどは単純に再実装が必要となる。
ライフサイクルは十分長いか？
あまりにライフサイクルが短いものだと十分なリターンを得ることができない。
開発主体の過去の実績を見るとよいだろう。 Google は技術プロダクトの廃止が多く、なくなったとしても現存コミュニティや代替でなんとかできそうかなども見ると良い。
組織目標に沿っているか？
その技術が課題だけでなく、組織の各種目標に合致しているかも確認する必要がある。
- プロダクト目標
- チーム目標
- プロジェクト目標
- 組織目標
例えば「安定して稼働できるチームになる」という目標がある場合、学習コストや運用コストが低いものの比重が高くなるだろう。組織が CO2 排出目標へのコミットを掲げている場合、非機能要件の一部として、それについても妥当かの判断をすることになる。
また、場合によってどれが上位かは異なるが、最上位からアラインするように考えると良い。ただ、これらの目標間に矛盾がある場合、非常に厄介だがまずその矛盾をなくすように動くのが良いだろう。
これらを見極めるために
以上で述べてきた観点は、即座に検証できるものばかりでもないことに注意しよう。
特に運用についてはあるていどの期間使わなければわからないことが大半だ。エッジケースを処理できない、実は意外と金銭コストがかかる、些細だと思っていた制限が実はクリティカルだった、など。
これはもう、実際の運用によって洗い出すしかない。そのためにサイドプロジェクトなどで積極的に小さく投資をしていくのが良いだろう。ここ一番でミスらないための先行投資と捉えると良い。
個人が普段から素振りするのもひとつの選択肢だが、それに甘えるべきではない。逆にこれができる方は仕事ができるわけなので、自分が成長したいときには考えておいても良いだろう。
適切な選択をするために、チームの状態を把握する必要があることもわかってもらえたはずだ。チャットを含めて普段から会話し、把握に努めることが重要だ。また、メンバーの仕事ぶりをしっかり観察することでそれぞれの苦手な分野がわかってくる。使えるものはすべて使おう。
最後に、当事者になることが一番解像度を上げてくれる。 OSS など、開発がオープンになっているのであれば自分でコントリビュートしてみよう、ということだ。簡単に素振りできるような導線が見当たらない場合にそこを整備するなど、時間がなくてもできることは多い。
Discussion