mcpField
E
evaluating-new-technology

evaluating-new-technology

github.com/refoundai開発1.4k1.6k 回インストール15 週間前に更新
リポジトリ

evaluating-new-technology について

新興技術を評価するための、プロダクト・技術リーダー向けスキルです。課題の特定や成熟度の確認から、内製と購入の検討、モジュール化までを支援します。

主な機能

  1. 01課題起点の評価
  2. 02技術成熟度の確認
  3. 03内製と購入の検討
  4. 04モジュール化と適応性
  5. 05技術に関する前提の再検証

活用シーン

  1. 01新技術の本番利用可否の評価
  2. 02内製とベンダーツールの比較
  3. 03技術変更への備え
  4. 04AIの能力に関する前提の検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/refoundai/lenny-skills --skill evaluating-new-technology

インストール後、Claude Code で/evaluating-new-technologyを入力して読み込まれたか確認します。

同梱ファイルreferences/guest-insights.md

詳細

新しいテクノロジーを評価する

GoogleからShopifyまで、さまざまな企業で重要なテクノロジーの意思決定を行ってきた22人のプロダクトリーダーのフレームワークを使って、新興テクノロジーの評価を支援します。

支援の方法

ユーザーからテクノロジーの評価について相談された場合:

  1. まず課題を確認する - ツールについて話し合う前に、解決しようとしている課題を明確にします
  2. 成熟度を評価する - そのテクノロジーがユースケースに十分対応できるほど安定しているかを判断します
  3. 構築と購入を検討する - 二者択一を迫るのではなく、適切な組み合わせを見つけられるよう支援します
  4. 変化に備える - 状況は変化するため、モジュール性を考慮して設計します

基本原則

ツールは課題を解決するものであり、その逆ではありません

Austin Hay:「私がいつも言っている格言があります。ツールは課題を解決するためのものにすぎません。マーケティングテクノロジストやビジネステクノロジストが抱える問題は、ツールにばかり注目してしまうことです。」システムやツールを選ぶ前に、課題と関係する人々を必ず明確にしてください。

構築か購入かではなく、構築と購入

Austin Hay:「構築か購入かではなく、構築と購入です。構築と購入なら、どちらも成功できます。」標準的な機能の90%には購入したツールを使い、ビジネス独自の「優れた」10%を構築します。

金額だけでなく、思考に必要な余力も評価する

Dhanji R. Prasanna:「ベンダーのツールを社内で構築したものに置き換えて得られる節約やコスト上のメリットは、失われる思考の余力を考えると、おそらく割に合いません。」ベンダーのツールを再現するのではなく、技術面の余力をコアコンピテンシーに集中させます。

前提を常に更新する

Aparna Chennapragada:「1年前にはモデルにできなかったこともありました。数か月前に試したときの印象、つまり前提は更新する必要があります。赤ちゃんが1か月で15歳になったようなものです。」そのテクノロジーに何ができるかという前提を、数か月ごとに再検証します。

抽象化レイヤーに投資する

Asha Sharma:「個々のテクノロジーに縛られず、入れ替えができるプラットフォームやアプリサーバーのようなレイヤーに本当に投資する必要があります。」AIスタックの進化に備えて、モジュール性に投資します。

AIのガードレールは機能しない

Sander Schulhoff:「AIのガードレールは機能しません。GPT-5をだますことに十分な意欲のある人なら、そのガードレールにも対処できてしまいます。ガードレールのプロバイダーが『すべて検知します』と言うのは、まったくの嘘です。」AIセキュリティベンダーの主張には懐疑的になりましょう。

自分でツールを使う

Dhanji R. Prasanna:「これらのツールをぜひ自分で使ってみてください。自分たちのワークフローがどう変わるかについて、多くを学べます。」新しいツールで具体的かつ個人的な課題を解決し、その真の強みを理解します。

コンテキストがAIの価値を左右する

Jeanne Grosser:「この分野全体がまだ始まったばかりなので、エージェントの力を引き出すうえでは、独自の専門的なコンテキストやコンテンツ、ワークフローが重要になることがよくあります。」AIエージェントでは、購入するより社内で構築するほうがうまくいくことがよくあります。

ユーザーを支援するための質問

  • 「このテクノロジーで、具体的にどのような課題を解決しようとしていますか?」
  • 「このテクノロジーは本番環境で使えるほど安定していますか。それとも、まだ実験段階ですか?」
  • 「構築する場合と、ベンダーとの関係を維持する場合とで、思考に必要な余力のコストはどう違いますか?」
  • 「このテクノロジーに何ができるかという前提を、最後に検証したのはいつですか?」
  • 「より優れたものが登場した場合、どのように置き換えますか?」
  • 「このツールを実際に使って、自分で現実の課題を解決したことはありますか?」

よくある間違いとして指摘すべきこと

  • ツールへの偏り - 課題を解決できるからではなく、以前使ったことがあるという理由でツールを選ぶ
  • 構築か購入かという二者択一の考え方 - 90%を購入し、戦略上重要な10%を構築する機会を逃す
  • 古くなった前提 - そのテクノロジーが6か月前にはできなかったことを根拠に意思決定する
  • ベンダーロックイン - 将来の柔軟性を確保する抽象化レイヤーなしに、特定のツールに賭ける
  • セキュリティに関するマーケティングを信じる - 「すべて検知できる」と主張するAIガードレールベンダーを信じる

詳細

22人のゲストによる27の洞察については、references/guest-insights.mdをご覧ください。

Related Skills

  • AI Product Strategy
  • Building with LLMs
  • Platform Strategy
  • Vibe Coding

コメント