Technology Radar についてはここにまとめている。
この記事では次のことがわかる。
- 今号のテーマ
- 各カテゴリーごとの Adopt / Hold / ピックアップを紹介
- ピックアップは将来的に影響がありそうなものや面白そうなものを選んでいる
- 個人的な思いなども書いているので参考に
その他のまとめ
今号のテーマ
Coding assistance antipatterns: コーディング補助のアンチパターン
GitHub Copilot など、コーディング向けのツールが提案してくるコードは一見良さそうに見える。特に、入力と出力が決まり切った関数や単純なテストケースにおける自動テストなどはそのまま使えるものも多い。
ただし、長期的にコードベースの健全性を保つためには、あくまでひとつの提案として受け止め、エンジニアがすべてをわかったうえできちんと式の細部まで決定する必要がある。
というのも、依然として開発はチームでなされるものだからだ。いくらツールの補助を得たとしてもひとりで開発できる分量はプロダクトして十分とはいえない。チームという文脈において、自分が書いたコードのチームに対する説明責任は自分にある。生成してもらったコードだから代案とどちらが良いか判断できない、という状況ではエンジニアは名乗れないだろう。
個人的にも、あくまでコーディングを補助するツールは自らの理解を補ったり、最初の取っ掛かりを得るためのものとして割り切ったほうが良い、という感じている。
このテーマではこういったツールを使う際は、自動テストやアーキテクチャー適合関数、ペアプログラミングなどによるコードベースの品質担保も同時に実施したほうが良いと書かれている。
Rust is anything but rusty: Rust は全く錆びつかない
Rust 最高、というテーマ。主に実行速度面でのメリットが取り上げられているようだ。
所有権について理解ができれば、メモリー管理の効率の良さも含めて良い選択肢になるだろう。
The gradual rise of WASM: WASM の段階的な台頭
WASM が徐々に使えるようになってきたというテーマ。
Rust だけでなく、 C++ などすでに幅広く使われている言語で書いたものもブラウザー上で実行可能な環境が整ってきた。
古くは Emscripten を用いてゲームをブラウザー上で動かすなどもされてきたが、ここまでの苦労をせずともアーキテクチャーとして検討可能となってきた。
The Cambrian explosion of generative AI tools: 生成 AI ツールのカンブリア爆発
生成 AI に関連するツールが数多く登場していることをカンブリア爆発になぞらえたテーマ。
過去数回の Technology Radar でも生成 AI 関連のツールが blip としてたくさん載っていたが、それらの登場は必然で、この傾向もしばらく続くだろうと述べられている。
Techniques
Adopt
1% canary: 1% のカナリア
既存ユーザーの 1% 程度のセグメントに次期バージョンのソフトウェアをリリースし、影響や反応を見ることらしい。
これは A/B テストなどと目的が違う。モバイルアプリや IoT 、車載組み込みのソフトウェアなどが対象であり、安全にバージョンアップやその後の運用ができることを確かめるためのものであるということだ。
基本的にモバイルや組み込みはアップデート難度が高い。失敗した場合文鎮化する可能性もあるし、アップデートに伴ってデータ変換が必要な場合は再入可能としておく必要もある。それでも OTA アップデートなどが使える場合など、昔に比べたら難度は下がっているが、回収コストなどが発生する可能性も考えると甘く見ないほうがいい。
1% canary はこういったリスクをある程度減らしてくれるテクニックだ。
Component testing: コンポーネントテスト
UI コンポーネントにおける、テストサイズ小での自動テストを推奨する blip 。
ブラウザーベースの描画テストはわかりやすいが、不安定で時間もかかる。 Chromium を使ったビジュアルリグレッションテストも成熟してきた感じがあるが、 CI ごとに変更が意図的かどうかの確認をしなければならないことには賛否両論あるだろう。というわけで最初から意図を織り込め、実行時間も短いテストサイズ小に切り分けたほうがメリットも多いという主張のようだ。
コンポーネントのテストをテストサイズ小へ収めるために、どう書けばいいのかわからない場合は次が参考になるだろう。
Continuous deployment: 継続的デプロイ
continuous delivery: 継続的デリバリーと混同されがちだが、明確に次の違いがある。
- 継続的デリバリーはデプロイパイプラインが自動化されていること
- 継続的デプロイメントはすべての変更が自動的に本番リリースされること
実はこの号で Adopt 入り。全組織が適用すべきプラクティスだとする根拠が最近得られたのだろう。
が、実現までは非常にハードルが高い。意図した変更であることを自動的に確認できなければならない、品質を自動的に担保できなければならないなど、エンジニアだけでなく多くの方の協力がなければ実現できないからだ。
Retrieval-augmented generation (RAG)
前回も Adopt だったが、引き続きの登場となる。
ThoughtWorks 内でもいろいろ使われているようで、 LLM ベースで何か作る際は RAG をまず検討するのが良いらしい。
Hold
Complacency with AI-generated code: AI が生成したコードへの満足
今号のテーマにもあった通り、 AI が生成したコードを全面的に信用してはならない。提案されたコードを理解するにも、量が多いと難しいため使うところは弁えると良いだろう。
Enterprise-wide integration test environments: 企業全体の統合テスト環境
いわゆるマイクロサービスで構築されたプロダクトにおいては、すべてのサービスにおけるテスト環境を永続的に確保しておくことはひとつの選択肢だった。が、それは開発効率の悪化につながるという blip 。
モノリスやモジュラーモノリスであれば環境をすぐに作れるようにしやすいため、あまり問題にならない、はず。
LLM bans: LLM 禁止
当初 LLM に入力したプロンプトなどを学習データとして用いる懸念があったため、一律使用を禁止した企業もあっただろう。また、生成された内容が著作権やライセンスに違反していないかというリスクを許容できるかどうかについても十分検討する必要があった。
最近ではそういった疑念が払拭されつつある。例えば Microsoft は GitHub Copilot ユーザーの法的リスクを軽減する姿勢を打ち出している。
あくまでツールなのでメリットとデメリットを比較して使用するかを決めればよいが、一律で使用を禁止するフェイズではなくなってきたということだろう。 LLM を使わない場合、業務効率が「落ちる」という感覚になってきた。
ツールを提供している企業が「秘密情報を適切に取り扱っている」と言うなら信用するしかない状況なのは LLM に限らず同じ状況だろう。 Google Workspace には秘密情報を山ほど集積しているわけだし…。
Replacing pair programming with AI
コーディング用の LLM を用いることをペアプログラミングとは呼べない、という blip 。
そもそもペアプログラミングやモブプログラミングには次のメリットがある。
- ひとりでは手に余る課題へ、複数の思考とコラボレーションによって対応できる
- 課題解決の経験をチームメンバーと共有できる
- 片方のチームメンバーからその他のチームメンバーへ、スキルトランスファーできる
- 役立つツールやプロダクト固有の事情などを教えあえる
が、 AI とのみ会話していると最初のメリットの半分くらいしか享受できない。
そもそも違うものとして捉えた方が良いということになる。
ピックアップ
LLM as a judge: 評価者としての LLM - Trial
LLM を使って LLM の出力内容の妥当性を評価しようという試みらしい。
LLM の応答はハルシネーションが含まれていても一見妥当に見えるため信用しきれていない現状だ。ツールとしてのコストの低減には、少なくとも情報の正確性が必要だという感覚は誰しも持っているだろう。
こういった課題を LLM を使って解決しようというアプローチがある。 LLM の評価観点やその手法と結果がまとめられている。
自分で RAG を組んだときなどにこういった評価手法を使ってみるのも良いだろう。
Using GenAI to understand legacy codebases: レガシーコードベースを理解するために生成 AI を使う - Trial
コーディング補助用の LLM が数多く利用できるようになったが、それに限らず生成 AI 全般を既存コードの理解に役立てようという blip 。
メインフレームのリバースエンジニアリングの例が紹介されている。確かにここまで大規模なものであれば、有用だろう。コードグラフの生成や設計ドキュメントを RAG として組み込むなどが紹介されている。
現在でも GitHub Copilot Chat は関数内部でやっていることの要約などを生成してくれるが、コードグラフ生成などはツールの使い方の紹介に留まっている。これらをシュッと出してくれるようになればより有用になっていくだろう。
AI team assistants: チームアシスタント AI - Assess
生成 AI は現在、個人をエクステンドする用途のツールが多いが、これをチームを補助するものとして仕立てようとする向きがある。
Slack で議論して決めたルールがドキュメントのどこにも載っておらずコードレビューで「実は…」というやりとりを経験した方もいるだろう。そういったことを防ぎ手戻りを少なくする可能性がある。
Unblocked も参照のこと。
Platforms
Adopt
なし。
Hold
なし。
ピックアップ
LangFuse - Trial
LLM ベースのアプリの開発基盤。 LLM 部分のオブザーバビリティやトレーサビリティ、評価をサポートしている。コスト追跡も可能なようだ。
Qdrant - Trial
Rust で書かれたベクターデータベースとベクター類似検索エンジン。速そう。
クライアントは様々な言語に対応しているので組み込みやすい気がする。
Unblocked - Assess
unblocked はコードベースや各ツールに散らばった情報を集約して、プロダクト開発の文脈に関する質問に答えてくれる SaaS 。
AI team assistant も参照のこと。
Tools
Adopt
Bruno
開発用の API クライアント。シンプルだが、通信内容を保存できるので十分実用的。個人的にはけっこう使いやすく感じている。
K9s
Kubernetes 管理用の CLI 。
SOPS
機密情報の暗号化 / 複合をするための CLI 。アプリで使用している各種 API キーなどの秘密情報を暗号化して、安全に扱えるようにするためのもののようだ。各 IaaS の KMS のマスターキーを使える。
Visual regression testing tools
特定のツールというより、ビジュアルリグレッションテストツール全般のハナシのようだ。 Technique じゃないのか…？
VRT ツールの最有力は Chromatic だろうか。
Storybook と親和性が高く、フロントエンド開発を効率化してくれる。
Wiz
脆弱性スキャンツールのようだ。コンテナーイメージや IaC に対してもスキャンできる。
Hold
CocoaPods
iOS 開発におけるパッケージマネージャーだったが、 8 月にメンテナンスモードとなったことがアナウンスされた。今後は Swift Package Manager を使うようにとのこと。
とはいえ、 React Native や Flutter などモバイル開発である程度シェアのあるフレームワークでは未だ使われている。内部では徐々に切り替えが進んでいるようだ。
ピックアップ
pgvector - Trial
PostgreSQL 拡張のベクトル類似性検索エンジン。
ColPali - Assess
PDF から RAG に組み込むための埋め込みベクトルを生成するツール。各省庁から出ている情報を RAG へ組み込みたいときに重宝しそう。
difftastic - Assess
文法を考慮したうえで diff を生成してくれるツール。自然な差分になる。現在使われている言語はあらかた網羅されているようだ。
Rspack - Assess
Rust 製の Webpack 互換バンドリングツール。速い。
Languages & Frameworks
Adopt
dbt
ELT パイプラインを構築するためのツール。 Volume 29 から引き続きの Adopt 。
Testcontainers
実際に近いテスト環境を構築できるツール。
Hold
なし。
ピックアップ
なし。
Discussion