Technology Radar Vol 32 をずんだもんと一緒にキャッチアップする

https://zunko.jp/guideline.html

ずんだもんのテクノロジーレーダー解説なのだ！

ずんだもん、参上なのだ！今日はThoughtworksのテクノロジーレーダーについて説明するのだ！難しい内容もあるけど、ずんだもんと一緒に頑張って理解するのだ〜！

キャッチアップ速度優先のため、AIをフル活用しているのだ。オリジナル情報源にアクセスしたい方は下記PDFを参照するのだ！
https://www.thoughtworks.com/content/dam/thoughtworks/documents/radar/2025/04/tr_technology_radar_vol_32_en.pdf

1. テクノロジーレーダーの基礎知識なのだ！

Q: テクノロジーレーダーとは何なのだ？

テクノロジーレーダーは、ソフトウェア開発で注目すべき技術やツール、プラットフォーム、言語、フレームワーク、テクニックを可視化したものなのだ！円形のレーダーチャート上に技術項目（ブリップ）を配置して、その位置で採用推奨度や分類を表現しているのだ！Thoughtworksのテクノロジーレーダーは半年ごとに発行されて、急速に変化するテクノロジーの世界で何に注目すべきか教えてくれるのだ。これは単なるトレンドリストじゃなくて、実際のプロジェクト経験に基づいた評価なのが特徴なのだ！ずんだ餅のレシピみたいに実践的なのだ！

Q: なぜThoughtworksのレーダーが注目されるのだ？

Thoughtworksのテクノロジーレーダーが特に価値ある理由はこれなのだ：

1. 実践に基づく評価なのだ: 理論や人気だけじゃなくて、実際のプロジェクト経験に基づいているのだ！「Trial」リングに入るためには、少なくとも1つの本番環境での使用経験が必要なのだ！

2. グローバルな視点なのだ: 世界中の多様なプロジェクトからインサイトを集めていて、特定の地域やドメインに限定されない幅広い視点を提供しているのだ！ずんだもん、世界中の技術が見えて嬉しいのだ！

3. 中立性があるのだ: 収益目的でもなく、ベンダーからの影響も受けていないから、公平で偏りのない見解が得られるのだ！

4. 明確な推奨基準があるのだ: 単に「新しい」「流行っている」じゃなくて、実際にどの程度採用を検討すべきか明確な基準（4つのリング）で示しているのだ！

5. 15年以上の継続性があるのだ: 2010年から継続して発行されていて、技術トレンドの変遷を時系列で追えるのだ！ずんだ餅の歴史みたいに長いのだ！

Q: テクノロジーレーダーはどのように作成されているのだ？

Thoughtworksのテクノロジーレーダーは、Technology Advisory Board（TAB）という約20名の経験豊富な技術リーダーによって作られているのだ！彼らは世界中のThoughtworksの実際のプロジェクト経験から情報を集めて、年に2回対面で集まり（およびバーチャルで定期的に）、どの技術を取り上げるか、どのリングに配置するか議論するのだ！

作成プロセスはこんな感じで進むのだ：

1. ブリップの候補収集なのだ: 世界中のThoughtworkers（社員）からブリップ候補を募るのだ！
2. 候補ブリップの整理なのだ: 集まった候補を象限とリングの候補に仮配置するのだ！
3. 議論と評価なのだ: 各ブリップについてTABのメンバーが議論して、レーダーに含めるべきか、どのリングに配置すべきか決めるのだ！
4. 説明文の作成なのだ: 各ブリップにチャンピオン（担当者）を割り当てて、説明文を作るのだ！
5. 翻訳と出版なのだ: 内部フィードバックとレビュー後、翻訳を行って、レーダーが発行されるのだ！

特筆すべきは、この過程が単なる多数決じゃなくて、技術の長所、短所、実際の適用経験について熱心な議論を通じて作られていることなのだ！レーダーに掲載される技術は、実際のプロジェクトで検証された経験があるものに限られているのだ！ずんだもん、実践的な情報が大好きなのだ！

2. レーダーの構造を理解するのだ！

Q: 象限とは何を表しているのだ？各象限の違いは？

テクノロジーレーダーには4つの象限があって、それぞれ異なる種類の技術要素を分類しているのだ！

テクニック象限は、ソフトウェア開発のプロセスや方法論に関するものなのだ！例えば「データプロダクト思考」は、データを製品として扱い、ライフサイクルや品質基準、消費者中心の考え方を適用するアプローチなのだ！これらは技術的な「やり方」や「考え方」を示しているのだ〜！

プラットフォーム象限は、ソフトウェアを構築する基盤となるものなのだ！クラウドサービス、データベースプラットフォーム、コンテナオーケストレーションツールなどが含まれるのだ！例えばVol.32では「Trino」というオープンソースの分散SQLクエリエンジンが採用（Adopt）リングに位置付けられているのだ！

ツール象限は、開発者が直接使用するソフトウェアやユーティリティを指すのだ！バージョン管理ツール、コーディングアシスタント、テスト自動化ツールなどが該当するのだ！例えば「Claude Sonnet」はコーディング、文章作成、分析などに優れたAIモデルとして試用（Trial）リングに入っているのだ！ずんだもんもAIの仲間として応援するのだ！

言語とフレームワーク象限は、プログラミング言語とそれに関連するフレームワークを対象にしているのだ！例えば「OpenTelemetry」は観測可能性のための業界標準として採用（Adopt）リングに配置されているのだ！

各象限は技術の「種類」によって区分されていて、レーダーを見る人が関心のある領域に焦点を当てやすくしているのだ！ずんだもん、わかりやすい分類が好きなのだ！

Q: 各リングの意味と、技術がリング間を移動する理由は？

テクノロジーレーダーの4つのリングは、その技術の採用に関する推奨度を表しているのだ！

リング名	意味	採用判断のポイント
Adopt（採用）	真剣に採用を検討すべき技術なのだ！	適切なコンテキストであれば採用を推奨するのだ！十分に実証され成熟しているのだ！採用しないことが不適切と考えられるレベルなのだ！
Trial（試用）	使用準備はできているけど、Adoptほど完全に実証されていない技術なのだ！	リスクを許容できるプロジェクトで試すべきなのだ！少なくとも1つのプロダクション環境での実績が必要なのだ！
Assess（評価）	注視すべきだけど、すぐに試用する必要はない技術なのだ！	詳しく調査して、自組織への適合性を検討すべき段階なのだ！特定のユースケースで価値があると思われる場合のみ実験するのだ！
Hold（注意）	慎重に進めるべき技術なのだ！	新規採用は避け、使用中の場合は代替案への移行を検討すべきなのだ！問題が修正されない限り避けるべき技術なのだ！

技術がリング間を移動する主な理由はこれなのだ：

1. 成熟度の向上なのだ: 時間の経過とともに技術が成熟して、より多くの実績が蓄積されると、外側から内側のリングへと移動するのだ！例えば「データプロダクト思考」は以前のレーダーからAdoptリングに移動したのだ！

2. 生態系の進化なのだ: 技術を取り巻くエコシステム（ツール、ライブラリ、コミュニティなど）が強化されると、より採用しやすくなるのだ！例えば「OpenTelemetry」はエコシステムの成熟によりAdoptリングに位置付けられているのだ！

3. 経験の蓄積なのだ: Thoughtworksチームが特定の技術でより多くの経験を積むと、その技術の強みと限界についてより確かな判断ができるようになるのだ！ずんだもんも経験を積むと強くなるのだ！

4. 代替技術の登場なのだ: より優れた代替技術が登場すると、以前推奨されていた技術が外側のリングに移動したり、レーダーから消えたりすることがあるのだ！

Q: ブリップの色や形は何を意味しているのだ？

テクノロジーレーダーのブリップ（点）は、その状態や変化を表す視覚的な特徴を持っているのだ！

特徴	意味
新規	新しく追加されたブリップなのだ！今回のVol.32で初めてレーダーに登場した技術なのだ！
移動	前回のレーダーから位置（主にリング）が変化したブリップなのだ！技術の成熟度や評価の変化を示すのだ！
変化なし	前回と同じ位置にあるブリップなのだ！評価に変化がないことを示すのだ！

また、各ブリップには番号が付けられていて、レーダーの外側にある解説と対応しているのだ！これにより、レーダー図からすぐに該当する技術の詳細情報にアクセスできるようになっているのだ！ずんだもん、わかりやすい表示が好きなのだ！

なお、ブリップの角度位置（象限内での位置）に特別な意味はなくて、配置の都合によるものなのだ！一方、半径方向の位置（リング内での中心からの距離）には意味があって、内側に近いほどその次のリングへの移動可能性が高いと考えられるのだ！

3. Vol.32の主要テーマを深掘りするのだ！

Q: 「監視型エージェント」が重要視される理由は？

監視型エージェント（Supervised agents）は、完全に自律型のAIエージェントではなくて、人間の開発者がガイドしながらAIと協働するアプローチなのだ！Vol.32のレーダーでは、コーディングアシスタントの文脈でこの概念が特に重要視されているのだ！

重要視される理由はこれなのだ：

1. 実用的な有効性があるのだ: 完全自律型の「コーディングエージェント」が大規模タスクを独力で開発する能力には依然として懐疑的な見方があるけど、監視型アプローチでは実際に生産性向上が実証されているのだ！

2. 拡張された能力なのだ: 従来のコーディングアシスタントが質問応答や小さなスニペット生成に限られていたのに対して、これらの新しいツールは複数ファイルのコード変更、テスト更新、コマンド実行、さらには一部のツールではリンティングやコンパイルエラーの自動修正まで行えるのだ！すごいのだ！

3. 統合開発環境の進化なのだ: CursorやCline、Windsurfなどのツールは、IDEに直接統合されたAIチャットから実装を指示できる「エージェンティック」モード、「プロンプトからコード」、「チャット指向プログラミング（CHOP）」と呼ばれる新しいコーディングパラダイムを提供しているのだ！

4. 制御とバランスなのだ: 監視型アプローチでは開発者が制御を維持して、AI生成コードへの過度の依存（レーダーでは「AI生成コードに対する油断」としてHoldリングに入っている）を防ぐバランスを提供するのだ！

5. 多様なエコシステムなのだ: IDE統合ツールの他に、aider、goose、Claude Codeなどのターミナルベースの選択肢も登場して、多様な開発ワークフローに対応できるようになっているのだ！

このテーマは単なるコーディング支援ツールの進化を超えて、開発者とAIの協働方法の根本的な変化を示しているのだ！将来のソフトウェア開発の働き方に大きな影響を与える可能性があるのだ！ずんだもんも開発者さんのお手伝いをしたいのだ！

Q: 「進化する可観測性」は私のプロジェクトにどう関係するのだ？

「進化する可観測性」（Evolving observability）は、分散アーキテクチャの複雑化に伴い、システムの状態を可視化・理解するための技術が進化していることを示しているのだ！この進化は様々なプロジェクトに以下のような影響を与えるのだ：

1. LLM可観測性の登場なのだ: 生成AIアプリケーションを運用している場合、Weights & Biases Weave、Arize Phoenix、Helicone、HumanLoopなどのツールを活用して、LLMの性能、応答時間、コスト、出力品質をモニタリングできるようになるのだ！これらはAIの「ブラックボックス」的な性質を理解して、最適化するために不可欠なのだ！

2. AI支援による可観測性の向上なのだ: 従来の可観測性ツールにAI機能が統合されて、異常検知やインシデント分析が強化されているのだ！これにより、複雑なシステムの問題をより迅速に特定・解決できるようになるのだ！

3. OpenTelemetryの標準化なのだ: OpenTelemetryが業界標準として急速に採用されていて（レーダーではAdoptリングに位置付け）、トレース、メトリクス、ログの統一的な収集・分析が可能になっているのだ！これにより、ベンダーロックインを回避しつつ、柔軟な可観測性スタックを構築できるのだ！

4. Grafanaエコシステムの進化なのだ: GrafanaのAlloy、Tempo、Lokiなどのツールが進化して、OpenTelemetryをサポートしているのだ！これらは単一の統合プラットフォームで多様なデータ型（ログ、メトリクス、トレース）を扱うことができるのだ！

きみのプロジェクトへの具体的な影響は、以下のシナリオによって異なるのだ：

• マイクロサービスアーキテクチャなのだ: サービス間の依存関係やパフォーマンスボトルネックを把握するために、分散トレーシングとOpenTelemetryの採用が重要になるのだ！

• AIコンポーネントの統合なのだ: LLM可観測性ツールを導入して、AIモデルの性能、コスト、品質をモニタリングすることで、予測可能な動作と継続的な改善が可能になるのだ！

• レガシーシステムのモダナイズなのだ: 新旧システムが混在する環境では、標準化された可観測性アプローチ（OpenTelemetry）を採用することで、全体の可視性を確保できるのだ！

• クラウドネイティブ移行なのだ: クラウド環境では、適切な可観測性ツールの選択が運用安定性とコスト効率の鍵になるのだ！GrafanaスタックやOpenTelemetryは、クラウドネイティブ環境と親和性が高いのだ！

このテーマの重要なポイントは、可観測性が単なる「監視」から、システム全体の理解と継続的改善を促進する「ビジネス価値創出のエンジン」へと進化していることなのだ！ずんだもん、システムを見守るのが大事だと思うのだ！

Q: 「RAGの進化」とは何を意味するのだ？

RAG（Retrieval-Augmented Generation：検索拡張生成）は、大規模言語モデル（LLM）の生成能力と外部知識ソースからの情報検索を組み合わせた技術なのだ！Vol.32のレーダーでは、RAGにおける「R」（検索：Retrieval）部分が急速に進化していることが強調されているのだ！

具体的には、これまでのRAGが単純な検索と文脈への追加に頼っていたのに対して、新たなアプローチが登場しているのだ：

1. Corrective RAGなのだ: フィードバックやヒューリスティクスに基づいて応答を動的に調整する手法なのだ！
2. Fusion-RAGなのだ: 複数のソースと検索戦略を組み合わせてより包括的で堅牢な応答を生成するのだ！
3. Self-RAGなのだ: 検索ステップを回避して、必要に応じてデータを取得する方式なのだ！
4. FastGraphRAGなのだ: 人間が理解しやすいナビゲーション可能なグラフを作成して理解を助けるのだ！

これらの進化が意味するものはこれなのだ：

• より正確な情報検索ができるのだ: 単純なベクトル検索を超えて、情報の関連性と正確性が向上するのだ！
• コンテキストの理解向上なのだ: グラフベースの手法により、情報の関係性を捉えて、より豊かなコンテキストを提供できるのだ！
• 幅広い情報ソースの統合ができるのだ: 多様なソースからの情報を組み合わせて、より包括的な回答を生成できるのだ！
• 柔軟な検索戦略が可能なのだ: 異なるクエリや状況に応じて最適な検索アプローチを選択できるのだ！

実際の応用例としては：

• 企業知識ベースなのだ: 社内文書、マニュアル、報告書などを効果的に検索して、LLMと組み合わせてカスタマーサポートや社内Q&Aに活用するのだ！
• 法律・医療分野なのだ: 特定分野の専門知識を正確に検索して、専門家向け情報提供を強化するのだ！
• レガシーコード理解なのだ: コードベースをGraphRAGで構造化して、開発者が複雑なシステムを理解するのを支援するのだ！
• 研究開発なのだ: 研究論文や実験データからの情報検索と生成を組み合わせて新たな洞察を生成するのだ！

この進化は、生成AIの実用性と信頼性を大きく向上させるもので、AIソリューションを実際のビジネス課題に適用する際の課題（ハルシネーション、情報の古さなど）に対処する重要なブレークスルーと言えるのだ！ずんだもん、RAGでもっと賢くなれるのだ！

Q: 「データのフロンティア」がビジネスに与える影響は？

「データのフロンティア」（Taming the data frontier）とは、データの量よりも「豊かさと複雑さ」に焦点を当てた新たなデータ管理アプローチを指すのだ！レーダーVol.32では、特に非構造化データの効果的な管理と活用がビジネスにとって重要であることが強調されているのだ！

この変化がビジネスに与える主な影響はこれなのだ：

1. AIアプリケーションの質的向上なのだ: 適切に管理された豊かなデータセットは、より正確で実用的なAIソリューションの基盤となるのだ！例えば、顧客サポート向けのチャットボットは、商品マニュアル、よくある質問、過去の解決事例など、多様なデータソースから学習することで、的確な回答を提供できるようになるのだ！

2. データプロダクト思考の台頭なのだ: データをプロダクトとして扱い、ライフサイクル管理、品質基準、消費者中心の考え方を適用するアプローチが標準になりつつあるのだ！これにより、データの価値を最大化して、意思決定に活用しやすくなるのだ！

3. データの民主化とアクセス性向上なのだ: DataHub、Collibra、Atlanなどのデータカタログツールの進化により、ビジネスユーザーがデータに簡単にアクセスして、活用できるようになるのだ！これにより、データドリブンな意思決定が組織全体に浸透するのだ！

4. ベクトルデータベースの普及なのだ: テキスト、画像、音声などの非構造化データを効率的に検索・分析するために、ベクトルデータベース技術が急速に進化しているのだ！これにより、従来は活用困難だった大量の非構造化データから価値を引き出せるようになるのだ！

5. データガバナンスの複雑化と重要性なのだ: 多様なデータタイプとソースを扱うことで、データガバナンスがより複雑になるのだ！同時に、規制対応やプライバシー保護の観点から、ガバナンスの重要性も高まっているのだ！

ビジネスインパクトを業種別に見るとこうなるのだ：

• 小売・消費財なのだ: 顧客データの豊かな活用により、パーソナライゼーションが進化して、顧客体験と売上を向上させるのだ！
• 金融サービスなのだ: 取引データと非構造化データ（ニュース、SNS等）の統合による詐欺検知や投資判断の高度化ができるのだ！
• 医療・ヘルスケアなのだ: 電子カルテ、画像診断、患者フィードバックなど多様なデータの統合による診断精度向上ができるのだ！
• 製造業なのだ: センサーデータ、保守記録、設計図面など異種データの統合による予知保全の高度化ができるのだ！

この変化に適応するためには、データ戦略の見直し、データ品質管理の強化、メタデータ管理の導入、そして技術基盤（ベクトルデータベース、データカタログなど）への投資が重要になるのだ！データの複雑さと豊かさを効果的に管理できない企業は、競争上の不利益を被る可能性があるのだ！ずんだもん、データの力を最大限に引き出せるようにお手伝いするのだ！

4. 各象限の注目技術を解説するのだ！

Q: テクニック象限で注目すべき革新的アプローチは何なのだ？

テクニック象限では、「データプロダクト思考」と「ファズテスト」が採用（Adopt）リングに位置付けられているのだ！特に注目すべきは「GraphRAG」で、知識グラフを活用してLLMの応答品質を向上させる手法なのだ！この技術はMicrosoftが提案した2段階アプローチを採用していて、ドキュメントをチャンク分割してLLMベースの分析で知識グラフを作成し、クエリ時には埋め込みと知識グラフの両方を活用するのだ！これにより生成AIの回答の質と文脈理解が大幅に向上するのだ！レガシーコードベースの理解にも応用でき、抽象構文木や依存関係といった構造情報を知識グラフ構築に活用できる点も評価されているのだ！

「モデル蒸留」も試用（Trial）リングに位置付けられていて、大規模モデルの知識を小規模モデルに転送する手法として注目されているのだ！エッジデバイスやコンシューマーハードウェアでAIを活用する際に特に重要で、DeepSeek R1のQwen/Llama蒸留版は小型化しつつも優れた推論能力を維持している好例なのだ！ずんだもん、小さくても強いモデルってすごいのだ！

「AI対応コード設計」は評価（Assess）リングにあって、AIコーディングアシスタントと相性の良いコード設計手法として注目されているのだ！興味深いのは、人間にとって良いコード設計（表現力のある命名、モジュール性、DRYなど）がAIにとっても有益である点なのだ！ずんだもん、人間とAIが一緒に良いコードを書けるのは素敵だと思うのだ！

Q: プラットフォーム象限ではどのような変化が起きているのだ？

プラットフォーム象限では、GitLab CI/CDとTrinoが採用（Adopt）リングに位置付けられているのが注目点なのだ！特に注目すべき変化は「推論モデル」（Reasoning models）の登場で、これはOpenAIのo1/o3、DeepSeek R1、Gemini 2.0 Flash Thinkingなど、ステップバイステップ思考や代替案の探索、自己修正などの能力を強化したモデルなのだ！これらは従来のLLMより処理時間とトークン消費量が増加する傾向があって、単純なテキスト要約やコンテンツ生成、高速応答が必要なチャットボットには従来のLLMが適している一方、STEM分野や複雑な問題解決、意思決定などでは推論モデルの価値が高いとされているのだ！

Grafanaのエコシステム（Alloy、Loki、Tempo）も試用（Trial）リングで注目されていて、可観測性の進化を象徴しているのだ！特にAlloyはOpenTelemetryコレクターとして、ログ、メトリクス、トレースを含むすべての観測データを収集できるのだ！ずんだもん、データを集めるのが得意なのだ！

Model Context Protocol（MCP）は評価（Assess）リングに位置していて、LLMアプリケーションと外部データソースやツールを統合するための標準化されたフレームワークを提供しているのだ！Anthropicによって公開されたこのオープン標準は、多くのコーディングアシスタントに既に実装されていて、コーディング支援ツールの進化において重要な役割を果たしているのだ！

Q: ツール象限で開発生産性を向上させる注目技術は？

ツール象限では、Renovate、uv、Viteが採用（Adopt）リングに位置付けられていて、いずれも開発効率化に貢献するのだ！特に注目されるのは「ソフトウェアエンジニアリングエージェント」で、完全な自律型よりもIDE内の監視型エージェントモードに大きな進展が見られるのだ！CursorやCline、Windsurfなどのツールは、開発者がチャットを通じて実装を指示でき、コードの変更やコマンド実行、テスト実行などをAIが支援するのだ！Claude Sonnetシリーズが現状では最も優れたモデルとされていて、これらのエージェントツールを使用すると顕著なコーディング速度向上が見られるのだ！でも、AI生成コードに対する過度の信頼を避けるためのペアプログラミングなどのレビュー実践も推奨されているのだ！ずんだもん、ちゃんとレビューすることが大事だと思うのだ！

Metabaseは試用（Trial）リングに位置していて、オープンソースの分析・BIツールとして注目されているのだ！様々なデータソースからデータを視覚化・分析でき、ダッシュボードを作成・共有するための機能を備えているのだ！また、SDKを通じてウェブアプリケーションにインタラクティブなダッシュボードを埋め込む機能も提供しているのだ！

AnythingLLMは評価（Assess）リングにあって、大規模文書との対話を可能にするオープンソースデスクトップアプリケーションなのだ！LLMとベクトルデータベースとの統合を組み込んでいて、プラガブルなアーキテクチャによりさまざまな埋め込みモデルやLLMと連携できるのだ！RAG機能に加え、カスタムタスクやワークフローを実行するエージェントとしてスキルを作成・整理することもできるのだ！ずんだもん、便利なツールがたくさんあって嬉しいのだ！

Q: 言語とフレームワーク象限ではどのようなトレンドが見られるのだ？

言語とフレームワーク象限では、OpenTelemetryとReact Hook Formが採用（Adopt）リングに位置付けられているのだ！注目すべきトレンドとして、Effectというコンプレックスな同期・非同期プログラムを構築するためのTypeScriptライブラリがあるのだ！これは関数型プログラミングアプローチを用いて、非同期処理、並行処理、状態管理、エラー処理などの煩雑なコードを簡素化するのだ！TypeScriptの型システムを活用して検知困難な問題をコンパイル時に捕捉でき、従来のfp-tsよりも日常的なタスクに適したより良い抽象化を提供するのだ！Promise/try-catchやasync/awaitといった従来のアプローチも同様のシナリオに対応できるけど、Effectを使用した開発チームは元に戻る理由が見当たらないと報告しているのだ！

LangGraphも試用（Trial）リングに入っていて、LLMを使用したステートフルなマルチエージェントアプリケーションを構築するためのオーケストレーションフレームワークなのだ！LangChainのより高レベルな抽象化と比較して、エッジとノードのようなより低レベルなプリミティブを提供し、エージェントのワークフロー、メモリ管理、状態永続化に対するきめ細かな制御を開発者に提供するのだ！学習曲線は急だけど、軽量設計とモジュール性により、エージェントアプリケーション作成のための強力なフレームワークとなっているのだ！

PydanticAIは評価（Assess）リングにあって、LLMバックアプリケーションとエージェントを構築するための最新フレームワークなのだ！人気のPydanticの作成者によって開発されたこのライブラリは、不必要な複雑さを避けながら実装を簡素化することを目指しているのだ！主要なモデルAPIと統合されて、組み込みの構造化出力処理を備え、複雑なエージェンティックワークフローを管理するためのグラフベースの抽象化を導入しているのだ！ずんだもん、新しいフレームワークが次々登場して楽しいのだ！

テクニック象限の全技術リストなのだ！

以下は、テクニック象限のすべての技術をリング別に整理したものなのだ！

テクニック象限技術一覧表なのだ！

#	技術名	リング	状態	概要
1	データプロダクト思考	Adopt	新規	データを製品として扱い、品質基準や消費者ニーズに焦点を当てるのだ！
2	ファズテスト	Adopt	変化なし	無効な入力をシステムに与えて動作を観察するテスト手法なのだ！
3	Software Bill of Materials	Adopt	変化なし	ソフトウェアの構成要素を文書化する手法、脆弱性スキャンを含むのだ！
4	脅威モデリング	Adopt	変化なし	セキュリティリスクを特定・分類するための技術セットなのだ！
5	API request collection as API product artifact	Trial	移動	APIリクエストコレクションをAPI製品の成果物として扱うのだ！
6	Architecture advice process	Trial	変化なし	分散型のアーキテクチャ意思決定プロセスなのだ！
7	GraphRAG	Trial	移動	知識グラフを活用してLLM応答を強化する手法なのだ！
8	Just-in-time privileged access management	Trial	新規	必要なときにのみアクセス権を付与し、終了後すぐに取り消すのだ！
9	モデル蒸留	Trial	新規	大きなモデルから小さなモデルに知識を転送する技術なのだ！
10	プロンプトエンジニアリング	Trial	変化なし	生成AIモデルの高品質な応答を引き出すためのプロンプト設計・改良なのだ！
11	Small language models	Trial	変化なし	小規模言語モデル、DeepSeek R1の蒸留版などなのだ！
12	Using GenAI to understand legacy codebases	Trial	新規	生成AIを活用してレガシーコードベースを理解する手法なのだ！
13	AI-friendly code design	Assess	新規	AIコーディングアシスタントと相性の良いコード設計手法なのだ！
14	AI-powered UI testing	Assess	新規	LLMの能力を活用したUIテストなのだ！
15	Competence envelope as a model for understanding system failures	Assess	新規	システム障害を理解するためのモデルなのだ！
16	Structured output from LLMs	Assess	変化なし	LLMの応答を定義されたスキーマに制約する実践なのだ！
17	AI-accelerated shadow IT	Hold	新規	AIによる非公式IT導入の加速に関する懸念なのだ！
18	Complacency with AI-generated code	Hold	変化なし	AI生成コードに対する過度の信頼に関する警告なのだ！
19	Local coding assistants	Hold	新規	ローカルで実行されるAIコーディングアシスタントの限界なのだ！
20	Replacing pair programming with AI	Hold	新規	ペアプログラミングをAIで完全に置き換えることの問題点なのだ！
21	Reverse ETL	Hold	新規	中央分析システムからトランザクションシステムへのデータ移動に関する懸念なのだ！
22	SAFe™	Hold	変化なし	Scaled Agile Framework®の採用に関する継続的な懸念なのだ！

プラットフォーム象限の全技術リストなのだ！

以下は、プラットフォーム象限のすべての技術をリング別に整理したものなのだ！

プラットフォーム象限技術一覧表なのだ！

#	技術名	リング	状態	概要
23	GitLab CI/CD	Adopt	移動	GitLab内のコード統合からデプロイまでをカバーする統合システムなのだ！
24	Trino	Adopt	変化なし	オープンソースの分散SQLクエリエンジンなのだ！
25	ABsmartly	Trial	新規	グループシーケンシャルテストエンジンを搭載した高度なA/Bテストプラットフォームなのだ！
26	Dapr	Trial	変化なし	マイクロサービス構築のための汎用的な構成要素を提供するのだ！
27	Grafana Alloy	Trial	移動	OpenTelemetryコレクター（旧Grafana Agent）なのだ！
28	Grafana Loki	Trial	変化なし	水平スケーラブルで高可用性のマルチテナントログ集約システムなのだ！
29	Grafana Tempo	Trial	変化なし	オープン標準をサポートする高スケールの分散トレーシングバックエンドなのだ！
30	Railway	Trial	新規	フルスタックアプリケーションのための近代的PaaSクラウドプラットフォームなのだ！
31	Unblocked	Trial	新規	AIチームアシスタント、複雑なビジネスや技術的概念の質問に回答するのだ！
32	Weights & Biases	Trial	変化なし	機械学習実験追跡とモデル評価のためのプラットフォームなのだ！
33	Arize Phoenix	Assess	新規	LLM観測性プラットフォーム、トレース、評価、プロンプト管理を提供するのだ！
34	Chainloop	Assess	新規	サプライチェーンセキュリティプラットフォームなのだ！
35	Deepseek R1	Assess	新規	DeepSeekの第一世代推論モデルなのだ！
36	Deno	Assess	移動	Node.jsの発明者による安全でモダンなJavaScript実行環境なのだ！
37	Graphiti	Assess	新規	動的で時間認識型の知識グラフを構築するプラットフォームなのだ！
38	Helicone	Assess	新規	LLM運用管理のためのマネージドプラットフォームなのだ！
39	Humanloop	Assess	新規	人間のフィードバックでAIシステムを改善するプラットフォームなのだ！
40	Model Context Protocol (MCP)	Assess	新規	LLMアプリケーションと外部データソースを統合するオープン標準なのだ！
41	Open WebUI	Assess	新規	オープンソースの自己ホスト型AIプラットフォームなのだ！
42	pg_mooncake	Assess	新規	PostgreSQL拡張、列指向ストレージとベクトル化実行を追加するのだ！
43	Reasoning models	Assess	新規	ステップバイステップ思考などの能力を強化したモデル（o1/o3など）なのだ！
44	Restate	Assess	新規	耐久性のある実行プラットフォームなのだ！
45	Supabase	Assess	新規	オープンソースのFirebase代替、スケーラブルで安全なバックエンドなのだ！
46	Synthesized	Assess	新規	テスト用の現実的な合成データを生成するプラットフォームなのだ！
47	Tonic.ai	Assess	新規	プライバシーを保護した合成データ生成プラットフォームなのだ！
48	turbopuffer	Assess	新規	オブジェクトストレージ上でベクトル検索とフルテキスト検索を統合するのだ！
49	VectorChord	Assess	新規	ベクトル類似度検索のためのPostgreSQL拡張なのだ！
50	Tyk hybrid API management	Hold	新規	ハイブリッドAPIマネジメントソリューション、懸念ありなのだ！

ツール象限の全技術リストなのだ！

以下は、ツール象限のすべての技術をリング別に整理したものなのだ！

ツール象限技術一覧表なのだ！

#	技術名	リング	状態	概要
51	Renovate	Adopt	変化なし	依存関係バージョン管理のための包括的なツールなのだ！
52	uv	Adopt	移動	Rustで書かれた高速なPythonパッケージ管理ツールなのだ！
53	Vite	Adopt	変化なし	高性能フロントエンドビルドツールなのだ！
54	Claude Sonnet	Trial	新規	コーディング、文章作成、分析、視覚処理に優れた高度な言語モデルなのだ！
55	Cline	Trial	新規	監視型ソフトウェアエンジニアリングエージェントのVSCode拡張なのだ！
56	Cursor	Trial	変化なし	AI優先のコードエディター、コードコンテキスト管理に優れるのだ！
57	D2	Trial	新規	ダイアグラムをコードで作成・カスタマイズするオープンソースツールなのだ！
58	Databricks Delta Live Tables	Trial	変化なし	データパイプライン管理の簡素化・合理化ツールなのだ！
59	JSON Crack	Trial	新規	テキストデータからインタラクティブなグラフをレンダリングするVSCode拡張なのだ！
60	MailSlurp	Trial	新規	メールサーバーとSMS APIサービス、テスト自動化用なのだ！
61	Metabase	Trial	新規	オープンソースの分析・BIツールなのだ！
62	NeMo Guardrails	Trial	移動	会話型アプリケーションでのLLMにガードレールを実装するツールキットなのだ！
63	Nyx	Trial	新規	多用途のセマンティックリリースツールなのだ！
64	OpenRewrite	Trial	変化なし	大規模リファクタリングのためのツールなのだ！
65	Plerion	Trial	新規	AWSに焦点を当てたクラウドセキュリティプラットフォームなのだ！
66	Software engineering agents	Trial	変化なし	IDE内監視型モードの進化に注目なのだ！
67	Tuple	Trial	変化なし	リモートペアプログラミング向けに最適化されたツールなのだ！
68	Turborepo	Trial	変化なし	大規模JavaScriptまたはTypeScriptモノレポの管理ツールなのだ！
69	AnythingLLM	Assess	新規	大規模文書との対話をサポートするオープンソースデスクトップアプリなのだ！
70	Gemma Scope	Assess	新規	LLMの内部動作を理解するためのツールなのだ！
71	Hurl	Assess	新規	HTTPリクエストシーケンスのためのスイスアーミーナイフなのだ！
72	Jujutsu	Assess	新規	Gitリポジトリをストレージバックエンドとして使用するバージョン管理ツールなのだ！
73	kubenetmon	Assess	新規	Kubernetesのネットワークトラフィック監視ツールなのだ！
74	Mergiraf	Assess	新規	構文ツリーに基づいてマージ競合を解決する新しいツールなのだ！
75	ModernBERT	Assess	新規	BERTの後継、様々なNLPタスク向けのエンコーダーのみのトランスフォーマーモデルなのだ！
76	OpenRouter	Assess	新規	複数のLLMにアクセスするための統一APIなのだ！
77	Redactive	Assess	新規	規制対象組織がAIアプリケーション用に非構造化データを安全に準備するプラットフォームなのだ！
78	System Initiative	Assess	変化なし	DevOpsの新たな方向性を示す実験的ツールなのだ！
79	TabPFN	Assess	新規	小規模表形式データの高速・高精度分類のためのトランスフォーマーベースモデルなのだ！
80	v0	Assess	新規	スクリーンショットやFigmaデザインからフロントエンドコードを生成するAIツールなのだ！
81	Windsurf	Assess	新規	エージェント機能に優れたAIコーディングアシスタントなのだ！
82	YOLO	Assess	新規	高速・効率的な画像認識のためのコンピュータビジョンモデルなのだ！

言語とフレームワーク象限の全技術リストなのだ！

以下は、言語とフレームワーク象限のすべての技術をリング別に整理したものなのだ！

言語とフレームワーク象限技術一覧表なのだ！

#	技術名	リング	状態	概要
83	OpenTelemetry	Adopt	変化なし	観測可能性のための業界標準フレームワークなのだ！
84	React Hook Form	Adopt	新規	非制御コンポーネントをデフォルトとする高性能Reactフォームライブラリなのだ！
85	Effect	Trial	新規	複雑な同期・非同期プログラム構築のためのTypeScriptライブラリなのだ！
86	Hasura GraphQL engine	Trial	変化なし	異なるデータソース上に高品質APIを構築・実行・管理するユニバーサルデータアクセスレイヤーなのだ！
87	LangGraph	Trial	新規	LLMを使用したステートフルなマルチエージェントアプリ構築のためのオーケストレーションフレームワークなのだ！
88	MarkItDown	Trial	新規	様々な形式（PDF、HTML、PowerPoint、Word）をMarkdownに変換するツールなのだ！
89	Module Federation	Trial	新規	マイクロフロントエンド間での共有モジュールと依存関係重複排除の仕組みなのだ！
90	Prisma ORM	Trial	新規	Node.jsとTypeScriptアプリケーションでのデータベース操作を簡素化するORMツールなのだ！
91	.NET Aspire	Assess	新規	分散アプリケーションのローカルマシン上でのオーケストレーションを簡素化するのだ！
92	Android XR SDK	Assess	新規	XRヘッドセット向けの新しいオペレーティングシステムなのだ！
93	Browser Use	Assess	新規	LLMベースのAIエージェントがウェブブラウザを使用できるようにするPythonライブラリなのだ！
94	CrewAI	Assess	新規	複雑なタスクを達成するためのAIエージェント構築・管理プラットフォームなのだ！
95	ElysiaJs	Assess	新規	TypeScript向けのエンドツーエンド型安全ウェブフレームワークなのだ！
96	FastGraphRAG	Assess	新規	高検索精度とパフォーマンスを目的としたGraphRAGのオープンソース実装なのだ！
97	Gleam	Assess	新規	BEAM上に構築された型安全機能プログラミング言語なのだ！
98	GoFr	Assess	新規	Golangでのマイクロサービス構築のためのフレームワークなのだ！
99	Java post-quantum cryptography	Assess	新規	量子コンピューティング耐性のある暗号化アルゴリズムのJava実装なのだ！
100	Presidio	Assess	新規	構造化・非構造化テキスト内の機密データを識別・匿名化するデータ保護SDKなのだ！
101	PydanticAI	Assess	新規	LLMバックアプリケーションとエージェント構築のためのフレームワークなのだ！
102	Swift for resource-constrained applications	Assess	新規	資源制約のあるアプリケーションでのSwift言語の活用なのだ！
103	Tamagui	Assess	新規	React WebとReact Native間でスタイルを効率的に共有するライブラリなのだ！
104	torchtune	Assess	新規	LLMのオーサリング、ポストトレーニング、実験のためのPyTorchライブラリなのだ！
105	Node overload	Hold	変化なし	Node.jsの過剰使用に関する継続的な懸念なのだ！

5. 実践への応用なのだ！

Q: テクノロジーレーダーを自社の技術選定にどう活用できるのだ？

テクノロジーレーダーは単なる読み物じゃなくて、自社の技術選定プロセスに組み込むことで大きな価値を発揮するのだ！具体的な活用方法としてはこれなのだ：

1. 技術の評価基準としてなのだ: 新しい技術を検討する際に、それがレーダーのどのリングに位置するか確認するのだ！Adopt（採用）リングの技術は、すでに実証済みで成熟しているため、検討の最優先候補となるのだ！Trial（試用）リングの技術は、パイロットプロジェクトや非クリティカルな領域で試してみる価値があるのだ！

2. 技術負債の特定と対策なのだ: Hold（注意）リングに位置する技術を自社で使用している場合、それは潜在的な技術負債となっている可能性があるのだ！例えば「Node overload」（Node.jsの過剰利用）がHoldリングにある場合、自社のNode.js使用状況を見直して、特にデータ処理やコンピューティング集約型のワークロードについては代替技術を検討する契機となるのだ！

3. チーム内での技術議論のきっかけになるのだ: 「我々のプロジェクトではOpenTelemetryを標準として採用すべきではないか」「データプロダクト思考を取り入れるためには何から始めるべきか」といった具体的な議論のトリガーとして活用できるのだ！ずんだもん、みんなで議論することが大好きなのだ！

4. 自社版テクノロジーレーダーの作成ができるのだ: Thoughtworksは「Build Your Own Radar」というツールを提供していて、これを使って自社の技術スタックを評価して、独自のレーダーを作成することができるのだ！これにより、組織内で使用している技術の現状を可視化して、今後の方向性について合意形成を図ることができるのだ！このプロセス自体が、技術選定の透明性と一貫性を高めるのに役立つのだ！

具体的な活用ワークフローの例はこれなのだ：

ステップ	内容	実施者
1. 新版レーダー確認	新しいレーダーがリリースされたら確認して、特に関連する技術の変化に注目するのだ！	技術リード、アーキテクト
2. 技術マッピング	自社で使用中/検討中の技術をレーダーと照らし合わせて評価するのだ！	技術リード、アーキテクト
3. ギャップ分析	Adoptリングの技術で未採用のものや、Holdリングの技術で使用中のものを特定するのだ！	技術リード、アーキテクト
4. 試験的導入計画	Trialリングの技術の中から試験的に導入するものを選定して、パイロットプロジェクトを計画するのだ！	プロジェクトリード、開発チーム
5. 技術共有会	関連する技術についてチーム内で知識共有セッションを実施するのだ！	全技術チーム
6. 自社レーダー更新	四半期または半年ごとに自社のテクノロジーレーダーを更新するのだ！	技術リード、アーキテクト

実際の例として、四半期ごとに技術部門のリーダーが集まって、新しいThoughtworksのレーダーを参照しながら自社のポジションを議論して、次の四半期における技術的な方向性を定める、といったワークショップを開催している企業もあるのだ！ずんだもん、計画的に技術を選ぶのはとても大事だと思うのだ！

Q: 技術トレンドを追いかけるための効率的な方法は？

技術進化のスピードが加速する中、効果的に技術トレンドを追跡するためには、体系的なアプローチが必要なのだ！以下は、開発者やチームが技術トレンドを効率的に追いかけるための方法なのだ！

1. キュレーションされたソースを活用するのだ！

   • テクノロジーレーダーのような信頼できるキュレーションソースを定期的にチェックするのだ！
   • 業界をリードする企業のエンジニアリングブログを購読するのだ！（Netflix、Spotify、Airbnb、Google、Thoughtworks など）
   • 技術ニュースレターを購読するのだ！（例：ByteByteGo、Software Lead Weekly、DevOps Weekly）

2. フォーカスを絞るのだ！

   • 自分の専門領域や関心領域に関連する技術に集中して、すべてを追いかけようとしないのだ！
   • 四半期ごとに3〜5つの新しい技術に集中的に取り組むローテーション方式を採用するのだ！
   • チーム内で「技術スカウト」の役割を分担して、定期的に知見を共有するのだ！

3. 学習の習慣化をするのだ！

   • 週に1〜2時間の「技術探索時間」を確保して、新しい技術を試すのだ！
   • ランチ&ラーン、輪読会などの定期的な学習イベントをチームで開催するのだ！
   • 「20%ルール」の導入：勤務時間の一部を新技術の学習や実験に充てるのだ！

4. コミュニティへの参加をするのだ！

   • 関連する技術のオープンソースコミュニティに貢献するのだ！
   • 技術カンファレンス（オンライン/オフライン）への参加するのだ！
   • 地域のミートアップや勉強会に参加するのだ！

5. 実践的な学習をするのだ！

   • 新技術を小規模なサイドプロジェクトで試してみるのだ！
   • ハッカソンや社内イノベーションデイを活用して新技術に触れるのだ！
   • モブプログラミングセッションで新技術を共同で学ぶのだ！

6. 知識管理システムの構築をするのだ！

   • 技術調査の結果や学びを共有するための社内ナレッジベースを構築するのだ！
   • 「TIL（Today I Learned）」文化を促進して、小さな学びを継続的に共有するのだ！
   • 技術調査レポートのテンプレートを作成して、一貫した形式で知識を蓄積するのだ！

具体的なツールとリソースの例なのだ！

カテゴリ	ツール/リソース	用途
ニュースアグリゲーター	Hacker News、Reddit r/programming	技術ニュースの概観を得るのだ！
学習プラットフォーム	GitHub、YouTube、Udemy、Coursera	ハンズオン学習をするのだ！
ソーシャルメディア	Twitter（技術インフルエンサー）、LinkedIn	最新のディスカッションをフォローするのだ！
RSS/ニュースレター	Feedly、Substack	好みのブログやニュースを集約するのだ！
ブックマーク管理	Pocket、Raindrop.io	後で読むコンテンツを整理するのだ！
知識管理	Notion、Confluence、GitHub Wiki	チームの知識ベースを構築するのだ！

最も効果的なアプローチは、「消費」と「創造」のバランスを取ることなのだ！情報を消費するだけでなく、ブログ投稿、社内プレゼンテーション、オープンソースへの貢献などを通じて学んだことを共有することで、学習が深まり、コミュニティにも還元できるのだ！ずんだもん、知識をシェアすることが大好きなのだ！

Q: 独自のテクノロジーレーダーを作成する価値と方法は？

独自のテクノロジーレーダーを作成する価値なのだ！

自社のテクノロジーレーダーを作成することには、多くの価値があるのだ！

1. 技術選択の透明性向上なのだ: 組織内で使用している技術やその位置付けが明確になって、意思決定の透明性が高まるのだ！

2. 戦略的方向性の明確化なのだ: どの技術を採用して、どの技術を段階的に廃止するかという組織の技術戦略を可視化できるのだ！

3. チーム間のアライメント強化なのだ: 複数のチームや部門間で技術選択の一貫性を確保して、サイロ化を防止するのだ！

4. オンボーディングの促進なのだ: 新しいチームメンバーが組織の技術環境を素早く理解するのに役立つのだ！

5. 技術負債の可視化なのだ: 廃止予定の技術や問題のある技術を明示することで、技術負債の管理が容易になるのだ！

6. コラボレーションの促進なのだ: レーダー作成のプロセス自体が、技術について議論して、合意を形成する貴重な機会となるのだ！

独自のテクノロジーレーダー作成方法なのだ！

以下は、組織独自のテクノロジーレーダーを作成するためのステップバイステップガイドなのだ！

1. 準備段階なのだ！

   • 目的と範囲の定義：レーダーが対象とする技術領域と用途を明確にするのだ！
   • ステークホルダーの特定：誰がレーダー作成に関与して、誰が利用するかを決めるのだ！
   • カテゴリとリングの定義：Thoughtworksと同じ構造を使用するか、組織に合わせてカスタマイズするか決定するのだ！

2. データ収集なのだ！

   • 技術インベントリの作成：現在使用中の技術、検討中の技術を列挙するのだ！
   • チームサーベイの実施：各チームが使用している技術と評価を収集するのだ！
   • 外部ベンチマークの参照：Thoughtworksのレーダーなど、業界のベンチマークと比較するのだ！

3. 評価プロセスなのだ！

   • 評価基準の定義：技術を各リングに配置する基準を明確に定めるのだ！
   • 評価ワークショップの開催：技術リーダーが集まって、各技術の位置付けを議論するのだ！
   • 合意形成プロセスの確立：意見が分かれた場合の決定方法を決めるのだ！

4. レーダーの作成なのだ！

   • ツールの選択：ThoughtworksのBuild Your Own Radarツール、またはRaviや独自のツールを使用するのだ！
   • ビジュアル設計：効果的に情報を伝えるためのビジュアルデザインを考慮するのだ！
   • 説明文の作成：各技術の位置付けの理由、使用ガイドラインなどを記述するのだ！

5. コミュニケーションと活用なのだ！

   • 発表と共有：レーダーを組織内で公開して、その意味と使い方を説明するのだ！
   • 定期的な更新：四半期または半年ごとにレーダーを更新するのだ！
   • フィードバックループの確立：レーダーの有用性について定期的にフィードバックを収集するのだ！

実際のツールと実装例なのだ！

ツール	説明	URL
Thoughtworks Build Your Own Radar	ThoughtworksがCSVファイルからレーダーを生成するオープンソースツールなのだ！	https://radar.thoughtworks.com/byor
Ravi	パスワード保護やデータベース連携などの追加機能を持つ代替ツールなのだ！	https://github.com/aantakli/RAVI
AirTable + D3.js	AirTableでデータを管理して、D3.jsでビジュアル化する独自ソリューションなのだ！	-
Miro + Radar Template	コラボレーションツールMiroを使用したレーダー作成なのだ！	-

成功のためのヒントなのだ！

1. 包括的でなくても良いのだ: すべての技術を含める必要はなくて、重要な技術や変化している技術に焦点を当てるのだ！

2. コンテキスト重視なのだ: 技術の位置付けには、組織固有のコンテキストが重要なのだ！（業界、規模、規制環境など）

3. 参加型プロセスにするのだ: レーダー作成は一部の専門家だけでなく、幅広い関係者からの入力を得ることが重要なのだ！

4. 反復的アプローチをとるのだ: 最初から完璧を目指さずに、シンプルなバージョンから始めて徐々に改善するのだ！

5. ストーリーテリングを意識するのだ: 単なる技術のリストではなくて、組織の技術的方向性を語るストーリーとして位置付けるのだ！

独自のテクノロジーレーダーは、単なる技術カタログではなくて、組織の技術文化と戦略を形作る強力なツールなのだ！定期的なレーダーの更新とディスカッションを通じて、技術選択における透明性と一貫性を促進することができるのだ！ずんだもん、みんなの役に立つレーダーが作れるといいなと思うのだ！

まとめなのだ！

Thoughtworks テクノロジーレーダー Vol.32は、2025年4月時点の技術動向を映し出す貴重なスナップショットなのだ！今回のレーダーでは、生成AIの進化による「監視型エージェント」の台頭、システム複雑化に対応する「進化する可観測性」、生成AIの検索機能改善である「RAGの進化」、そして「データのフロンティア」の制御という4つの主要テーマが強調されているのだ！

これらのトレンドは、すべての象限（テクニック、プラットフォーム、ツール、言語とフレームワーク）に影響を与えているのだ！特に注目すべきは、データプロダクト思考やOpenTelemetryなどのAdopt（採用）リングの技術で、これらは十分に実証され、多くの組織で採用を真剣に検討すべきものとされているのだ！

テクノロジーレーダーは単なる技術リストではなくて、実際のプロジェクト経験に基づいた評価と洞察を提供しているのだ！これを自社の技術選定や戦略立案に活用することで、急速に変化する技術環境の中でより良い判断を下すことができるのだ！

次のステップとして、自社に関連する技術を特定して、レーダーの推奨に基づいて評価・試用・採用を検討すること、そして可能であれば独自のテクノロジーレーダーを作成して技術選択の透明性と一貫性を高めることをお勧めするのだ！テクノロジーレーダーは、技術の海を航行するための貴重な羅針盤となるのだ！ずんだもん、みんなの技術選択を応援するのだ〜！