「何を・なぜ」が先
アーキテクチャや開発計画を決める前に、誰のどのような切実な課題を解くのか、そして、それを解くことが事業として成り立つのか（収益性・競合環境・実際の需要）を見極めます。技術は目的ではなく、その答えを実現する手段です。
SDTRについて
SDTRについて
AIプロジェクトは、技術がうまく機能していても失敗することがあります——課題が切実でない、事業としての価値が弱い、あるいは利用開始後の継続利用・定着につながらないためです。SDTRの出発点は異なります。技術戦略や機能開発に入る前に、「何を、なぜ作るのか」——顧客が本当に抱えている課題と、それを解くことが事業として成り立つか——から考えます。
考え方
デモではなく、プロダクト
デモで見栄えがしても、実際の利用環境で機能しなければプロダクトとは言えません。評価設計、ガードレール、できること・できないことの明示までが、開発の一部です。
意見より、根拠
本格開発の前に、課題探索・プロトタイプ・検証を行います。
引き継げるように作る
良い仕事は顧客の組織に残ります。特定の支援者への依存を生まず、移管を前提に設計します。
使われてこそ、プロダクト
プロダクトは、使われ、使われ続けて初めて意味を持ちます。利用開始、継続利用、そして定着——それは仕事の「後」ではなく、仕事そのものの一部です。
育てる
SDTRという名前に込めた考え方です。一度のリリースで終わらせず、顧客が自ら運用し、改善し続けられる状態を目指してプロダクトを育てます。
顧客との進め方
- 案件責任者。
- ご相談の窓口を務める本人が、実務も担当します。
- 範囲。
- 有償の案件は、目的、成果物、役割分担、前提条件、（該当する場合は）受け入れ基準、引き継ぎ条件を定めた提案書・個別契約書などの合意文書に基づいて進めます。
- 守秘。
- 非公開の顧客・案件情報は、案件ごとに合意した守秘条件に基づいて取り扱います。必要な場合は、双方が合意した秘密保持契約のもとで対応します。
- AIとデータの取り扱い。
- 顧客から提供された機密情報・個人情報・本番データを第三者のAIサービスで利用する場合は、対象サービスと取り扱い方法について、事前に顧客の書面による承認を得ます。
- 所有と引き継ぎ。
- 成果物と引き継ぎ資料は、契約に定めるとおり文書化します。既存資産、再利用可能な手法、オープンソース、第三者コンポーネントの取り扱いを含む権利関係は、契約で定めます。不要な囲い込みを避け、実務的な移管を目指します。
守秘、データ処理、セキュリティ、知的財産、引き継ぎに関する具体的な義務は、該当する契約に基づきます。
代表について
SDTRは、プロダクトを最初のアイデアからスケールまで導いてきた15年以上の経験を持つ、現場型のプロダクトリーダー、ダニエル・ヒメネスが率いています。国際的なメディアで製品が紹介されたDTCブランドのCPO、AIを活用したFinTechプラットフォームのプロダクト・グロース責任者を務め、応用AI、FinTech、消費者向けビジネスで自ら手を動かしてきました。Automatic Mapping of OWL Ontologies into JavaとTowards HarmonIA: Automatic Generation of e-Organisations out of e-Institutionsの共著者であり、Google Japan / DeepLearning.AI AI Voice Agents Hackathonで優勝、ETHGlobal Tokyoで4つの賞を受賞し、TEDxBarcelonaに登壇しています。東京を拠点とし、英語・スペイン語は流暢、日本語はビジネスレベルです。専門的な支援が必要な場合、SDTRは経験豊富な外部専門家——デザイン、エンジニアリング——を、顧客の事前承認のうえ、案件の守秘・知財・データ取り扱い条件のもとで提案します。
Voice Agents Hackathon 優勝デモ（Google Japan × DeepLearning.AI）LinkedIn