Intercom の製品原則: 最大の顧客価値を提供するための小さなステップの構築

大きな変更は理解しにくく、デバッグも困難です。

Intercom では、複雑な変更を一連の小さく制御されたわかりやすい手順で提供します。 小さな変更は簡単に構築でき、レビューも迅速に行えるため、お客様により迅速に価値を提供できます。

これは、当社の製品原理を探求するシリーズの 7 回目の投稿です。 ここでは、Aidan が当社のエンジニアリング原則である「小さなステップで構築する」について説明します。

誰もいつもそれを正しく理解しているわけではありません

間違いは、世界中のすべての企業のすべてのチームで発生します。 いつでもうまくいくわけではないことを受け入れたら、次の 2 つの方法のいずれかで調整できます。

• 作品を出荷する前に間違いを修正し、作業を検証または確認する手順を実行してください。
• 自分が間違っていることを許容し、間違いから学び、すぐに調整して修正してください。

すでに何週間も変更に没頭している場合は、多くの場合、間違いを犯す余地はほとんどありません。 これにより、変更を出荷するときの予期せぬ事態を回避するために、検証に頼ることになる可能性があります。 検証にはそれなりの役割がありますが、何かを実際にデプロイする代わりにはなりません。 出荷前に実行する必要がある検証が多ければ多いほど、反復または次の機能に進むまでに時間がかかります。最終的には遅くなります。

変更を発送する際は、次のことを管理することを目指しています。

• 影響を受ける変数の数:変更中に影響を受ける変数が多いほど、変更のどの部分が問題を引き起こしたのかを突き止めるのが難しくなります。 各ステップのサイズを縮小することで、フィードバック ループを強化し、必要に応じてより迅速に学習および調整できるように準備します。
• 変更のサイズ: 変更のサイズを縮小することで、各変更の爆発範囲も縮小します。 変更をテストすることは重要ですが、事前の検証で把握できることは限られています。 小さな変更により、目標を段階的に達成することに注意を向けることができ、各変更が完璧であることを確認することにあまり気を配ることはありません。
• どの顧客が変更を経験するか:機能フラグに依存して、本番環境での変更を検証し、段階的に顧客にリリースします。

この機能がお客様の問題を解決するかどうかは、実際に手にしていただくまでわかりません。 小さなイテレーションを出荷するというこのコミットメントは、Intercom のもう 1 つの原則である「学習するために出荷する」にすぐに結びつきます。

複雑さの管理

複雑なシステム内に構築することは困難です。 大きな変更でバグが発生したり、肥大化した機能が的を射ていない場合、特定の問題を特定するのは困難です。 小さなステップを踏むことで、検証、変更、先へ進むことが容易になり、強固な基盤の上に構築していることを確信できます。

大きな変更には、多くの仮定が含まれます。

• 変更が顧客のワークフローにどのように影響するかについての外部の想定。
• 変更のさまざまな部分がどのように相互作用し、相互に依存するかについての内部的な仮定。

外部の仮定を確認するために最善を尽くすことはできますが、多くの場合、変更を出荷して検証または調整する方がより迅速で堅牢です。 内部の仮定は、複雑さが忍び寄る可能性がある場所です。変更が大きくなり、すべてが相互に依存する複数のビルディング ブロックを包含する場合、それらを一緒にテストすることは危険です。 これらを段階的にリリースし、一方を他方の上に構築し、その影響を監視する方がはるかに安全です。

耐久性のあるスピードが勢いを増す

スピードは素晴らしいですが、耐久性と信頼性の高いスピードはゲームを変えるものです。 大きな変更を出荷するということは、一連の小さくて迅速なイテレーションと比較して、成功するために多くのことが必要であり、驚きのリスクが高いことを意味します。

「小さな変更を出荷し、学習し、反復するというタイトなサイクルが、強い勢いを生み出します」

小さな変更を出荷し、学習し、反復するというタイトなサイクルが、強力な勢いを生み出します。 これにより、最初から正しく行う必要がなくなり、より迅速な意思決定が促進され、ミスの爆発範囲が縮小されます。 さらに、作業をより小さな単位に分割することは、エンジニアが作業を並行して進めることができることを意味し、チームは全体としてより速く動くことができます.

小さなステップで構築するには、適切なチーム文化が必要です

小さなステップで構築することは偶然ではなく、意図的な意図と適切な環境が必要です。 私たちのチーム文化とインフラストラクチャ スタックは、小さな変更を迅速にリリースする能力において重要な役割を果たしています。

チームが小さな変更を迅速にリリースすることの重要性に同意すると、ピア レビューが優先され、より迅速に完了します。 小さな変更は理解しやすく、確認しやすいため、各段階でバグが発見される可能性が高くなります。 このチームの理解と緊急性により、プロセス全体がスピードアップします。

「私たちは、変更がレビューされてマスターにマージされたら、自動テストとステージング検証を含め、15 分以内に本番環境に移行できるようにするために多額の投資を行ってきました。」

展開時間が遅くなると、エンジニアは変更を一括処理する傾向が強くなり、結果としてより大きな変更のサイクルが発生します。 変更がレビューされてマスターにマージされると、自動テストとステージング検証を含め、15 分以内に本番環境に移行できるようにするために多額の投資を行ってきました。 これは完全に無人で、変更が反映されるとエンジニアは自動的に Slack 通知を受け取ります。

「小さなステップで構築する」原則を Intercom の Salesforce 統合に適用する

昨年、Intercom と Salesforce との統合をさらに深め、顧客が Intercom の会話から Salesforce ケースを自動的に作成できるようにすることを検討しました。 複雑さはすぐにわかりました。 会話とケースは常に直接対応するとは限らず、多対多の関係でデータを同期することは、エンジニアリングと設計の両方の観点から困難です。 これに加えて、顧客がこの機能をどのように使用したいかには大きなばらつきがあり、顧客が大きく依存している既存の統合に適合する必要がありました。

多くの影響とデザインのトレードオフを検討した後、より信頼性の高い影響をもたらすと思われるものを優先して、プロジェクトを中止しました。 一連の小さなステップではなく、大きな変更としてアプローチしたため、ほとんどビルドしませんでした。

別のアプローチでプロジェクトを再検討しました

営業チームが戻ってきて、この機能がお客様にとってどれほど重要であるかを強調するまでにそれほど時間はかかりませんでした。 今回は別のアプローチを採用し、可能な限り最小のバージョンから始めて、顧客が本当に必要としているものを理解できるようになるまで複雑さの一部を回避しました。

「私たちが一緒に仕事をしたお客様は、チームが反復するペースと、フィードバックに基づいて機能が日々どのように進化しているかを高く評価してくれました。」

別のエンジニアと私は 2 週間で、この機能の最も基本的なバージョンを構築し、顧客と共有することができました。 これは、お客様がすでに使用している既存のワークフローを壊さないように、多くの小さなステップで行いました。 これにより、機能がより具体的なものになり、顧客は製品のギャップと改善について具体的なフィードバックを提供できるようになりました。

顧客がそれを使用するようになると、チームは小さなステップで反復し、すぐに機能をより柔軟にしました. 柔軟性が高まるにつれて、それを使用する顧客の数も増え、ベータ版を急速に拡大しました。

多対多の関係は顧客がこの機能を使用することを妨げないことが判明し、私たちはこの機能を安全に立ち上げることに成功し、この余分な複雑さはありませんでした. 私たちが一緒に仕事をした顧客は、チームが反復するペースと、フィードバックに基づいて機能が日々どのように進化したかを高く評価しました.

小さなステップで構築することは誰にとっても効果的です

私たちが小さなステップで構築する主な理由は、より安全で耐久性のある方法で、顧客の価値をより迅速に提供するのに役立つからです。 しかし、それに加えて、エンジニアとしてはより良い働き方です。 大きな変更をリリースするよりも、最初から正しく動作するかどうかにかかっている場合に比べて、はるかにストレスが少なくなります。また、作業中のものを本番環境にリリースするたびに、定期的にドーパミンが放出されます。

したがって、このブログ投稿の内容で、リスクの軽減と増分価値の提供を最適化するよう説得するものがない場合は、それを行うべきです。その方が楽しいからです。

Intercom での働き方についてもっと知りたいですか? 詳細をご覧ください。