Knock、通知基盤をworkflowとpreferencesに分解して開発チームの負債を減らす設計

Chris BellとMike Carboneは、過去に大規模なコラボレーション製品の通知システムを作った経験から、各社が同じ複雑さを繰り返す問題に向き合いました。出典

既製品では解けない通知の複雑さ

通知は送信処理だけでは終わりません。

ユーザーのpreferences、複数チャネル、digest、再送、テンプレートが絡みます。

Knockはこの複雑さをworkflowとしてまとめました。出典

開発者が試せる形へ

quick startとexample app、各言語のSDKを揃え、最初の通知を送るまでの摩擦を下げました。出典

マルチチャネルへ広げる

email・SMS・in-app・push・Slack・Microsoft Teamsを同じ基盤で扱い、顧客ごとの運用へ広げています。出典

今後の課題

通知基盤は便利なほど依存が深くなります。

provider障害、データ移行、規制対応を含めた信頼性が次の勝負になります。出典

持ち帰れる示唆

Knockの道のりは、社内で何度も作られた機能を「単一API」ではなく、運用上の意思決定まで含む抽象化へ変えた例だと言えます。

通知機能は多くのSaaSに必要なのに、チャネルごとのAPI、再送、テンプレート、ユーザー設定を各社が個別実装しがちです。

Knockはこの反復的なインフラをworkflowとpreferencesへ抽象化し、プロダクトチームが顧客体験に集中できる余地を作ります。出典

メールだけでなくin-app、push、Slack、SMSを同じモデルで扱える点が、複数チャネルを必要とするB2B SaaSに刺さります。出典

workflow、preferences、テンプレート、配信ログを一体化したデータモデルが蓄積されるほど、単純なsend APIとの差が広がります。出典

ネットワーク効果は弱いです。

利用者が増えても直接的なユーザー間ネットワークは生まれませんが、SDK・integration・導入事例のエコシステムは間接的に強化されます。

複数チャネルの通知を持つSaaSのproduct engineer、platform team、growth teamが中心です。

単純な一斉メールだけを送る小規模サイトには向きません。

第一に、通知を単発APIではなくworkflowとして設計したことです。

遅延・分岐・digestを同じ構成で扱えます。出典

第二に、SDKとexample appを複数言語で公開し、導入摩擦を下げています。出典

通知を外部基盤へ集約すると、障害時の切り分けとデータ移行が難しくなります。

チャネルごとの配信制約やprovider依存も残ります。出典

また、Starterの月額固定費は小規模な個人開発では過剰になり得ます。

無料のDeveloper tier、quick start、example appで試用を促し、notification infrastructureを内製するコストを伝える構成です。出典

顧客事例と技術ブログで、抽象的な通知論ではなく実装課題を検索流入へ変えています。出典

主要チャネル: content, developer_relations, customer_stories, product_led_growth

インフラ製品は、既存チームが何度も作り直す境界を見つけ、workflow・preferences・observabilityのような共通概念へまとめると価値を説明しやすくなります。出典

日本ではメール・LINE・pushをまたぐ通知設計が複雑になりやすいです。

国内providerと権限・同意管理を組み込んだ日本向けchannel adapterがあれば、海外製notification infrastructureとの差別化になります。