Tachyon iPaas 車輪の再開発を抑える。そして、ビジネスモデルを磨き上 げることによって、確かな価値を創出する。 

サービスが目指すところ 

車輪の再開発を最小限に抑える 社会にとって重要なこと DX系Saasやツールは、CRUD処理にがベース で事業付加価値をつけていくことになる。 コアなビジネスロジックに集中することで社会全 体での価値の総量を効率的に増やしていく。 お客様にとって重要なこと サービスを利用するdeveloperはお客様にのみ 向いていれば良いのです。 Tachyonのコンテンツの入出力のコードが使い にくいなどどいった些細な問題は、要望は私た ちに丸投げして、とにかくあなたたちが顧客のこ とのみ考えてください！ developerさまの精神衛生はTachyon teamが 全力でサポート致します。 

全てはビジネスロジックに集中するため 社会にとって重要なこと 私たちは、プログラミング言語の表現力は、現実 世界を表現するのに十分であると感じていま す。 ビジネスロジックに集中し、コードで自身のビジ ネスを表現することに全力を注ぎましょう。 Tachyonはその助けになるはずです。 お客様にとって重要なこと お客様自身のビジネスロジックをより洗練させる 必要があります。 developerも自身のビジネスをより深く探求し、 知り、学ぶことが必要です。 その学習プロセスを経てビジネス持続性の根幹 となる「深いモデル」を見つけることができると信 じています。 

世の中にたくさんある便利なSaasとAPIレベルでネ イティブ統合していく。 現在は、人間がいろいろなツールを現実世界で統合している。そのため、ツールの導入コストが比較 的高い。 そうではなく、アプリケーション上で設計段階から統合していくことによって、統合をスムーズに、低いコ ストで行うことができる。 

サービス構成イメージ 

コアなビジネスロジックをお客様自身で実装・表現して頂き、それ以外の基本的な機 能をすぐに利用可能な状態で提供します。ペイメントや Tachyon iPaas on Google Cloud ユーザー管理 CRM ユーザー管理 CRM コアな ビジネスロジック含む アプリケーション Githubから 自動デプロイ コンテンツ管理 CMS コンテンツ管理 CMS お客様が実装・管理 認証認可 BFF フロントエ ンド 認証認可 

Tachyon 事業フェーズとニーズやコスト感に応じて、ユー ザー管理のコアエンジンを選ぶことができる。 ➔ Tachyon CRM(比較的安価に利用可能) ➔ Hubspot ➔ Salesforce をサポート予定です。お客様のニーズにお応じて 他のサービスにも対応します。 Saleforce Hubspot ユーザー管理 CRM ユーザー管理 CRM Tachyon CRM 自由にCRMのコアエ ンジンを選択 

Tachyon 事業フェーズとニーズやコスト感に応じて、コンテンツ 管理のコアエンジンを選ぶことができる。 ➔ Tachyon DB ➔ Tachyon DB high performance ➔ Firestore ➔ Supabase ➔ お客様自身のDB をサポート予定です。お客様のニーズにお応じて他 のサービスにも対応します。 Firestore Supabase ユーザー管理 CRM コンテンツ管理 (CMS) Tachyon DB CMSのコアエンジンを パフォーマンス要件に 応じて選択可能 Your DB Elasticsearch 

ビジネスロジックとは 

ビジネスロジックとは、 あなたのチームやビジネスそのもの。 

ビジネスロジックとは、ソフトウェアのコアとなる論理的ルールのことです。 コンテンツ管理 CMS コンテンツ管理 CMS ユーザー管理 CRM ユーザー管理 CRM アプリケーション ビジネスロジック エンタープライズビ ジネスロジック SDK SDK お客様が作成された アプリケーション 

DDD for discovery 

DDD for discoveryの探求に取り組んでいます DDD（ドメイン駆動設計）はビジネスモデルそのものが存在している前提のモデルをより深めるために はかなり効果的であると言えるでしょう。しかし、よりアイデアのシードに近いモデルで機能するのかは 少し疑問です。単に工数が肥大するだけの可能性があります。 単なるCRUD処理の組み合わせたモデルから、深いモデルを含むビジネスモデルとして蒸留させてい けば良いのでしょうか？ 我々は、そのような課題が残る領域を ”DDD for Discovery”と定義して探求します。 

0to1プロセスでDDDを実践しようとすると... ● bounded contextってどこで区切れるんだっけ？？ ● 後々のことを考えて、contextはmodular monolith構成で作っていく？ 

この最初の2.5%を発見するためのデリバリが必要です。 

想定ユースケース 

Usecase.1 とりあえずMVPを用意したい！ まずMVPを最速で用意します。その後、ユー ザーリサーチをしながらプロダクトをボトムアップ で洗練させていくことができます。 プロダクト例）toCビジネス プロセス例 ターゲットユーザー・ペルソナを定義 →ユーザーストーリーマッピング →ユースケースを前提 →ドメインモデル定義 →Tachyonの必要な機能を選択 →実装 

Usecase.2 ある特定のドメインの経験・知識があり、その新規 事業として ドメイン知識が豊富にある方に、方法は重要で はありません。 ある程度固まっているビジネスモデルをコードに 落とし込むだけで、すぐに事業の垂直立ち上げ を検討できます！ プロダクト例）自身で仮説検証済みの垂直統合 型Saas(toB)プロダクト プロセス例 ターゲットユーザー・ペルソナを定義 →ユースケースをリストアップ →ドメインモデル定義 →Tachyonの必要な機能を選択 →実装 

Usecase.3 すでにあるコード資産を利用して、オペレーションコ ストの削減 垂直立ち上げされたベンチャーのプラットフォー ムには、セキュリティリスクに不安があります。 顧客にとって最重要な部分を見極めるために、 運用に対する肩の荷をおろして、ビジネスロジッ クにリソースを集中できます。 本当にあなたのソフトウェアはあなたのビジネス を表現できているか、いま向き合いませんか？ プロセス例 ➔ モデルと入出力を切り離す ➔ 永続化部分の要件を整理 

プロダクトロードマップ 

ペイメント context 

システム構成 

Tachyon cluster developer Namespace CRM Namespace Architecture Developers End Users Elasticsearch namespace Cloud Load Balancing Authority Namespace Authority service Pod Envoy proxy Pod developer app Pod CMS service Pod Elasticsearch StatefulSet CRM service Pod Core service build Cloud build commit External SaaS Providers アクセス制御 認可 CRM DB Cloud SQL