インターコムがエンジニアチャットを発表

公開: 2022-05-06

私たちは、私たちの製品と機能、そして私たちが興奮している発売についてすべてあなたに話しました。今、私たちはあなたを舞台裏に連れて行き、それを実現する人々の仕事を紹介します。

何年にもわたって、私たちはポッドキャストで多くのことをカバーしてきました。毎週、Inside Intercomを使用した製品管理、設計、サポート、およびマーケティングの世界についての洞察を提供します。業界のリーダーがCXを使用してScaleでビジネスを成長させる方法を探ります。また、Intercomの共同創設者であるDesTraynorとIntercomの製品担当SVPであるPaulAdamsの世界を紹介します。彼らは、優れた製品の構築方法に関する最新の考えを共有しています。

そして今、完全に異なる何かのために。初めて、エンジニアチャットをリリースします。これは、エンジニアリングに関するすべてのことに関する社内ポッドキャストです。以前はインターコムのシニアプロダクトエンジニアであるジェイミーオスラーが7年以上ホストしていましたが、現在はプリンシパルシステムエンジニアのブライアンスキャンランがバトンを手に取り、チャットを続けています。

今週は、ジェイミーとブライアンの他に、次の人からも連絡があります。

インターコムの元シニアプリンシパルエンジニア、マイクスチュワート
パトリック・オドハティ、インターコムの元シニアセキュリティエンジニア、現在はオソのエンジニア
インターコムの共同創設者、Ciaran Lee
研究開発をサポートするインターコムのシニアカウンセル、ミーナポリッシュ

曖昧性解消のプロセスとこれまでで最悪の停止から、スピードへの執着、法務チームとエンジニアリングチームがどのように連携できるかまで、エンジニアチャットはインターコムのエンジニアリングプロセスの裏側を垣間見ることができます。

時間に余裕がない場合は、次の点に注意してください。

曖昧性解消、つまり各問題の広いソリューションスペースを絞り込むプロセスは、あいまいなプロジェクトに適しているだけではありません。エンジニアリングや製品管理の構築プロセス全体に使用できます。
アルゴリズムとシステムの中核はデータモデルです。システムの技術設計に取り組むときは、常に最初にデータモデルを理解するようにしてください。
インフラストラクチャの自動化は、かなり深刻な失敗につながる可能性があります。これらの問題は誰にとっても楽しいものではありませんが、他の盲点を探し、より堅牢なシステムを構築するために使用できます。
デフォルトの動作ケイデンスは実行する必要があります。スタートアップが速度に妥協しないことが重要です。次の四半期ではなく今週何かできることがあれば、それに飛び乗ってください。
法務チームは研究開発を遅らせるためにそこにいません。彼らの優先事項は、会社が成長し、複雑さが増すにつれて、法律の範囲内でそれを継続することを確実にすることです。

私たちの議論を楽しんでいるなら、私たちのポッドキャストのより多くのエピソードをチェックしてください。 iTunesでフォローしたり、Spotifyを使用したり、選択したプレーヤーでRSSフィードを取得したりできます。 以下は、エピソードの軽く編集されたトランスクリプトです。

Liam Geraghty：こんにちは。InsideIntercomへようこそ。リアム・ゲラティです。あなたが定期的にリスナーであるならば、あなたは私たちが製品管理、デザイン、スタートアップ、そしてマーケティングの世界からのメーカーと実行者にインタビューすることを知っているでしょう。他にも2つのポッドキャストがあります。IntercomonProductでは、Intercomの共同創設者であるDesTraynorとIntercomの製品担当SVPであるPaulAdamsが、成功する製品を大規模に構築する方法と、ScalebyIntercomで最新の考えについて話し合っています。顧客との関係を通じて成長を促進します。

私たちが作ったことを絶対に知らなかったポッドキャストの1つは、エンジニアチャットと呼ばれるものです。これは、Intercomの内部ポッドキャストだからです。ここでは元シニアプロダクトエンジニアのジェイミーオスラーが主催しました。各エピソードで、ジェイミーは座って、エンジニアリングに関連するさまざまなトピックについてさまざまな人々と話をしました。

今日、私たちはあなたにインターコムのエンジニアリングのすべてに音の窓をもたらします。これまでで最悪の停止の話から、法務チームとエンジニアリングチームがどのように連携することができるかまで、ショーから最高の部分を取り上げました。まず、曖昧さ回避：意味や解釈をより明確または確実にするために、類似したものと意味を区別する行為またはプロセス。インターコムの元シニアプリンシパルエンジニアであるマイクスチュワートは、2020年10月にジェイミーとその言葉について、そしてなぜ彼が仕事でそれをそんなに使うのかについて話しました。ジェイミーです。

ずっと下の曖昧性解消

ジェイミー・オスラー：少し毛羽立っていて、成功の意味とアプローチの最善の方法に関してあまり明確に定義されていないプロジェクトにアプローチすると、素晴らしい結果が得られるのを見てきました。これは、曖昧さ回避と呼ばれることもあります。あなたがそれを言うとき、あなたが何を意味するのか教えていただけますか？

マイク・スチュワート：うん。曖昧さ回避。インターホンに来る前はあまり使わなかった言葉で、ここに来てからずっと使っています。以前は以前に使っていたはずなのに、いい言葉ですね。毛むくじゃらのプロジェクトや曖昧なプロジェクトだけではありません。これは、エンジニアリングをはるかに超えて、PMが物事を理解するために行う多くのことへと進む、構築プロセス全体の一部としての非常に一般的な動詞だと思います。

「あなたには広い解決スペースがあります…それは証拠と決定と呼びかけに基づいてそれを終わらせるプロセスです」

プロジェクト前の状態に戻ると、明らかに私たちにはチームがあり、彼らには所有権の領域があり、彼らは彼らの周りのロードマップを理解していますよね？チームは私たちのマーケティング/エンゲージメント/アウトバウンド/表面積全体に責任があり、その中で成功することを所有しています。それはあいまいな問題です。その中で私たちがどこに座っているのか、そして私たちができるすべてのこと、そして私たちがそれらを行うことができる方法を理解し、それらを絞り込んで（おそらく100パーセントではないかもしれません）、そのソリューションスペースを閉鎖してより緊密にし、エンゲージスペース内で実行できるすべてのことの中で、これらは最も重要であると私たちが考えるものであり、顧客が最も多く、最も高い投資収益率を求めているものです。これは曖昧さ回避のプロセスです。あなたは広い解決空間を持っており、その解決空間内で行くことができる多くの異なる場所のどこに行くべきかについて曖昧さを持っています、そしてそれは証拠と決定と呼びかけに基づいてそれを終わらせるプロセスです。

私がエンジニアリングプロジェクトでそれを演じるとき、パイプラインのいくつかの段階で同じ種類のものがあります。アプリを構築してメッセンジャーに埋め込むことができるパブリックプラットフォームを備えた新しいメッセンジャーを構築することを決定すると、それが意味するすべてのさまざまな形、それがどのように現れるかについてのソリューションスペース全体があります。そしてそれをどのように構築できるか。曖昧さ回避は、あなたが考えている曖昧さが次のようになるまでずっと下がっています。「特定のインターフェイスを備えたiFrameを埋め込みたいと思っているので、開発者は前後に移動します。実際にそれを実装し、技術的に設計し、それを実行するためのコードを記述しますか？」これらはさらにズームインされたレベルです。あなたはまだそこで曖昧さを乗り越えています。ですから、曖昧性解消は製品開発プロセス全体にあると思います。

「私はこれを、銀河の点として地球に至るまでズームし、人間のスケールとマイクロスケールに至るまでの宇宙のビデオの1つだと考えています。」

ジェイミー・オスラー：あなたはそれも本当に絞り込んでいます。多分あなたはそれを少し明確にすることができます。

Liam Geraghty：マイクには、曖昧性解消のプロセスを視覚化する優れた方法があります。

マイク・スチュワート：うん。私はこれを、銀河の点として地球に至るまで、そして人間のスケールとマイクロスケールに至るまで、さまざまな桁数の宇宙のビデオの1つと考えています。これらの各レベルには興味深い構造があります。同様に、物事がますます明確になるにつれて、各ズームレベルにも興味深いあいまいさが存在すると思います。

たとえば、コードを記述して「コードの概念は何ですか。このコードをどのように構成すればよいですか」と理解する場合、手法は異なります。「ねえ、これをどのように技術設計すればいいのか」と考えているときとは対照的です。そして、データモデルと可動部分、ソリューションとロードマップは何ですか？それがすべて曖昧さ回避である限り、私はそれを非常に抽象化しています。あなたが攻撃しているのは何であるか、そしてどのズームレベルで私の頭の中で最も重要な原則であるかについて非常に慎重になります。そして、それはエンジニアが非常に自然に曖昧性解消のより深いズームレベルに夢中になり、何かを構築する方法を理解することができる場所です。

データモデルと一体になる

Liam Geraghty：これらすべてを具体的な例と結び付けるために、Jamieがこれを紹介します。

Jamie Osler：課金システムがZuoraにデータを送信する方法と、状態が2つの間で同期されていることを確認する方法を調べたとき、現在のシステムがどのようにデータを送信したかを理解して、そのようなものを取得できるようにする必要がありました。現在のシステムの曖昧性解消を行い、それをコアとなるアイデアと原則に分解し、それらのどれが今後関連するかを確認します。その一環として、Zuoraによる料金プランデータの経時的なモデリングがどのように機能するかを調査したドキュメントを作成しました。そして、それは多くの人がそのレベルでは掘り下げなかったものだったと思います。それが役に立つと思ったきっかけは何ですか？そして、いつその調査を行うべきか、いつ行わないべきかを知っていますか？

マイク・スチュワート：ええ、確かに。私たちが以前に話していたズームレベルに関しては、これは私にとって、そのハイレベルなハイテクデザインのズームレベルにぴったりです。要約すると、請求では、「ねえ、私たちはこれら2つのシステムを持っていることをかなりしっかりと理解しています。独自のRailsアプリがあり、この外部Zuoraシステムがあります。少なくとも、かなりの将来にわたって、これら2つのシステムを使用する予定であることを私たちは知っています。その制約を変更するつもりはありません。私たちはそれらの2つに多くを構築しているので、離れることは現実的ではありません。 2つのシステムを同期させる必要があり、それらを相互に一致させる必要があります。これらの問題はすべて、相互に一致させることができないことに起因するため、それらを解消する必要があります。それが使命だと私たちは理解しました。

「データモデルから独立したアルゴリズムを考案することはできません。そして、システムや製品の機能について話し始めるときも同じことが言えると思います。」

そして、それを達成する方法はどのような技術的解決策であるのかということでした。技術の面では、私が技術設計とこのような高度な技術設計またはシステム設計フェーズについて考えるとき、私がほとんどいつも行うことはモデルに行くことです。あなたが理解しようとすることができる表面積がたくさんあります。重要なことはたくさんあります。たとえば、コード構造はどうですか、何が動き回っているのか、どのワーカーがいるのか、何をしようとしているのかなどです。ただし、システムのコアコンセプトである基本的な概念は、ほとんどの場合、実際のデータベースのデータモデルと同じです。データベース内のそれらのスキーマ、サードパーティ内のパブリックスキーマ、またはそれらが何であれ。これらは、関連するデータモデルのコアコンセプトです。そして、有名なコンピューター科学者の中には、アルゴリズムの中核はデータモデルであるという感情をはっきりと表明している人もいます。データモデルから独立したアルゴリズムを考案することはできません。そして、システムや製品の機能について話し始めるときも同じことが言えると思います。データモデルは、あらゆる設計の基本です。

したがって、この状況で、請求に着手したときに最初に行ったことは、独自のデータモデルを理解することでした。あなたと私にとって、ジェイミー、そこに着陸するのは野生の西のようだったからです。ほとんどのインターコムのように、私たちはこれの内部を見たことがありませんでした、それは勇敢な新しいフロンティアでした。したがって、まず最初に、「ねえ、これらすべてのテーブルが私たち自身のシステムに関係しているのは一体何なのか」を理解する必要がありました。サンフランシスコの前のチームの助けを借りて、比較的早くその理解に到達し、そのメンタルモデルを構築しました。

「データモデルを完全に理解していない限り、技術設計を進めることに抵抗はありません」

次に、私たちが攻撃するのが遅すぎたと思う次の主要な部分は、「私たちが掘り下げているシステムであるZuoraのデータモデルを本当に理解しましょう」でした。あなたが話していた努力は、私が基本的にコンソールを起動し、Zuoraでデータモデルを手動で突いて、何かを変更し、何が起こったかを確認するためにいくつかのコマンドを実行し、そしてある種を探索したのはたぶん1週間かそこらの時間だったと思いますデータモデルを理解するためのブラックボックススタイルのそして、それを理解した結果、次のように言うことができます。「ねえ、この大きなモデルのスタックがあります。本当に重要なものはここ、葉のすぐ下にあります。それらは、データの内臓を保存する料金プランや料金セグメントなどのようなものです。」そして、コアコンセプトとデータモデルを正しく理解したら、構築を開始し、システムの設計を開始できます。そして、このようなレプリケーションシステムについて話すときは特にそうです。その基本的な仕事は、あるデータモデルのセットを確実にシャッフルし、それを別のデータモデルのセットで意味的に同等のものに変換することです。

それを見失わないためのあなたの最初の質問は、いつそれをすべきかをどうやって知るのですか？私にとって、それは本当に単純なことです。データモデルを完全に理解していない限り、技術設計を進めることに抵抗はありません。そして、その原則に深く従わなかったために私が燃えた場所の1つをお話しします。後で、Salesforceに来て、Salesforceが大きくて大きな世界であるというコアコンセプトとデータモデルについてある程度理解しました。ですから、時間のプレッシャーがたくさんありました。また、Zuoraの場合と同じようにデータモデルを深く理解することはできませんでした。チームの全員にも同じことが言えたと思います。同じレベルのデータモデルの深さには到達しませんでした。その結果、何か良いものを作ったと感じますが、1年後、これらのデータモデルをさらに詳しく調べた後、次のように気づきました。 Salesforceと自社のシステムの間の翻訳を正しくマッピングしていなかったため、知識不足を修復するためにさらに多くの作業を行う必要があります。」

ジェイミー・オスラー：それはとても便利です。それはあなたがプロジェクトを明確にする方法についての素晴らしいチャットでした。

マイク・スチュワート：ジェイミー、素晴らしいチャットだったと思います。ここで役立つコンテンツが得られたと思います。

Jamie Osler：ハッシュタグコンテンツ。

見事に悪い停止の明るい面

Liam Geraghty：今年の初め、Facebook、WhatsApp、またはInstagramのユーザーであれば、10月の停止を覚えていることは間違いありません。これは、Facebookの歴史上最長の世界的な停止でした。それはすべて、彼らの側での誤った構成変更に帰着しました。したがって、停止は誰にとっても楽しいことではありません。特に嫌いなのは、インターコムのプリンシパルシステムエンジニアであるブライアンスキャンランです。

ブライアン・スキャンラン：私は停止が嫌いです。それが、私が自分のキャリアをそれらと戦うことに捧げてきた理由です。

Liam Geraghty： 2020年11月、ブライアンはジェイミーと彼らについて話をするために腰を下ろしました。

ブライアン・スキャンラン：停止が好きな理由、停止に惹かれる理由、または停止に時間を費やす理由の1つは、これまでのキャリアにとってかなり良いことだったからです。そして、それは私がそれに興味を持ち、それらを実行し、それらについて考え、それらの一部であり、そしてそれらをフォローアップすることに関与することに決めたからです。

Liam Geraghty： Brianは、Intercomでのいくつかの注目すべき停止を思い出しました。

「Elasticsearchが空であることに気付いたとき、ビンで病気になりたいと思ったことを覚えています。私は「ああ、これはとても悪い」のようでした」

Brian Scanlan：私が関わった最もトラウマ的な停止の1つは、実際には停止中にそこにいなかったにもかかわらず、2019年1月のElasticsearchの大規模な停止でした。

Liam Geraghty：そこにいたのは、当時ここにいた上級セキュリティエンジニアのPatrickO'Dohertyでした。

Patrick O'Doherty： Elasticsearchが空であることに気付いたとき、ビンで病気になりたいと思ったことを覚えています。「ああ、これはとても悪い」と私は思った。

ブライアン・スキャンラン：これは特に素晴らしいものでした。 40歳の誕生日に友達と飲み物を飲んでいたので、そこにはいませんでした。まるで金曜日の夜のようでした。また、金曜日にコードを本番環境に出荷することを恐れていないため、金曜日の夜にVPCAWSにサブネットを追加するプルリクエストを承認しました。

ジェイミー・オスラー：飲み物の合間に？

ブライアン・スキャンラン：いいえ、実際には途中でした。当時は地味でした。そのサブネットをAmazon内のネットワークに追加しようとしたとき、私たちが書いた自動化…私たちはTerraformと呼ばれるツールを使用して、AWS内の低レベルのインフラストラクチャを管理し、チームモジュールをたくさん持っていました。これは、AWS内の一連のインフラストラクチャを、適用したいすべての設定やもので単純化するために作成した再利用可能なコードです。

「その時点で、構成が適用されたとき、それは完全に破壊されたか、ネットワークをオフラインにしました」

そのため、この自動化では、追加したいサブネットの説明を非常に熱心に取り入れました。ただし、アプリケーションの時点で、AWSのAPIは、重複するIPサブネットがあったため、または構成されていたサブネットが既存のサブネットと重複しているため、それを拒否しました。そのため、その時点で、Terraformの申請プロセスはあきらめました。止まった。多くの場合、これは完全に合理的なことです。しかし残念ながら、Terraformモジュールを実装した方法では、サブネット上に存在するルーティングテーブルに関するすべての情報が削除され、これらすべてのサブネットの構成中にそれらが再び追加されていました。したがって、事実上、すべてのルートが削除されました。これは、ネットワークがインターネットや他のネットワークに到達する方法を知る方法であり、これは非常に重要です。したがって、その時点で、構成が適用されたとき、それは完全に破壊されたか、ネットワークをオフラインにしました。それはほんの始まりに過ぎません。

ジェイミー・オスラー：つまり、それは悪いことですよね？それは良いことではありません。

ブライアン・スキャンラン：うん。つまり、Intercomは完全にオフラインになりました。そして、ロールバックできるようになるまでに少し時間がかかりました。私たち、つまり私ではありません。この時点で私は飲み物を楽しんでいました。そのため、チームはTerraformプロビジョニングインフラストラクチャに入り、構成変更にロールバックする方法を考え出しました。

「地球上で何が起こったのか、そしてそのデータがどこに送られたのかを理解するのにも、長い時間がかかりました。ここで8時間の停止について話している」

しかし、残念ながら、その間に、他の自動化が開始されました。今回は、AWSが所有していた自動化がいくつかありました。 ChefのマネージドバージョンであるOpsWorksと呼ばれるこのテクノロジーを使用して、Elasticsearchホストを管理します。自動修復と呼ばれるこの機能が組み込まれており、ホストレベルの構成でデフォルトで有効になっています。また、ホストがOpsWorksバックエンドからアクセスできない場合、OpsWorksのワークフローシステムは、問題のホストで問題が発生したと判断したため、問題のホストを自動修復しようとします。 OSがダウンしていて、メモリが不足している可能性があります。何か問題が発生したので、修正してみましょう。そのため、このOpsWorksコントロールプレーンは、ホストを置き換えることでインフラストラクチャ全体を修正することを決定しました。

残念ながら、Elasticsearchを実行していましたが、エフェメラルストレージと呼ばれるものを引き続き使用しています。これはホストベースのストレージです。サードパーティのシステムやホスト外のシステムにデータを保存する、魔法のようなクラウドベースのシステムは使用していません。物理ホスト上にあります。また、物理ホストが破壊されると、データは失われます。そして、それがすべてのElasticsearchホストに起こったことです。すべてのElasticsearchクラスターがすべてのデータを失いました。これは、Elasticsearchの上に大量のインターコムが構築されているためかなり悪いことです。プライマリデータストアではありません。たとえば、ユーザー用のDynamoDBなどの1つのデータストアにデータを書き込み、そのデータをElasticsearchにコピーして検索する傾向があります。そして、それを復元することはできますが、バックアップを介してすべてのデータを取り戻し、以前のバックアップ以降のすべての変更を再駆動する必要があるプロセスには、長い、長い、長い時間がかかりました。また、地球上で何が起こったのか、そしてそのデータがどこに送られたのかを理解するのにも、長い時間がかかりました。ここでは、8時間の停止について話します。

「私たちはただ行っただけではありませんでした。「さて、これら2つの問題についてわかったので、それらを修正しましょう。」私たちは立ち去り、奇妙な状況で私たちを噛む可能性のある他の種類の自動化の分野を探しました。」

金曜日の遅くに起こったので、これは大きな問題でした。物事を安定させるのに非常に多くの人々が必要でした。私たちはこれらの問題についてある程度知っていました。Elasticsearchクラスターをリドライブまたはリフィルしてスクラッチする必要がありました。私たちは、私たち自身の自動化とAWSでの自動化に潜む危険のいくつかについて知りませんでした。

これに続いて、「さて、これら2つの問題についてわかったので、それらを修正しましょう」というだけではなかったので、これは興味深いことでした。私たちは立ち去り、奇妙な状況で私たちを噛む可能性のある他の種類の自動化の分野を探しました。そのため、Elasticsearchクラスターをさまざまな状態から復元できるようにするために多くのことを行うことになりました。また、遅れたり、同様の災害タイプの状況が発生した場合に、さまざまな時点でデータをElasticsearchクラスターに再駆動できます。そして、全体として、この見事にひどい停止から多くのことを学びました。その後のプロセスは、実際にはかなり良好でした。私たちが学んだことと、その情報をどのように広めたか。

Patrick O'Doherty：誰だったか思い出せませんが、約1時間後、誰かがこの事件を引き起こしてくれたことに感謝しました。これは本当に楽しいインシデント対応になるでしょう。」それが基本的にその要点でした。「ああ、すごい。ここで何かを掘り下げています。」そしてそうだった。 Terraformの使用と、ツールが私たちを傷つける可能性があることを意識しながら、ツールの使用方法に対する一般的な成熟度。動力工具を尊重します。インフラストラクチャのように、動力工具は危険です。彼らは素早く動き、驚いてあなたを捕まえることができます、そして私たちはその日私たちのレッスンを学んだと思います。

ブライアン・スキャンラン：私もこれからインサイドインターコムの話のようになりました。また、私は誕生日にパブにいたので、事件にはいませんでした。よかった。それは完璧な事件でした。

光速で

Liam Geraghty： 2020年12月、私たちが決して忘れないクリスマスです。Intercomの共同創設者であるCiaran LeeがJamieに加わり、スピードと、Ciaranが速く動くことに関心を持っている理由について話しました。

Ciaran Lee：私は非常にせっかちな人です。それは一つのことです。何かを速くしたり、ゆっくりしたりできるのであれば、個人的にはむしろ速くしたいと思います。インターホンは10年後には古い会社のように見えるかもしれませんが、正直なところ、私たちはまだ始まったばかりだと信じています。やることがたくさんあります。私たちはとても野心的です。私たちは、私たちが何になりたいかという写真を見ることができます。これは、インターネットビジネスを持つすべての人が顧客と話すために使用できるこのオールインワンツールです。そして、私たちはそこで表面を引っ掻いているだけです。

私が尊敬しているクールな会社であるStripeから私が本当に気に入っているのは、Patrick McKenzieによる素晴らしいブログ投稿で、デフォルトの動作ケイデンスを実行するように設定していると説明しました。彼らはデフォルトで不快な速さで動き、今から6か月後ではなく、今週はもっと速くできるかどうかを常に尋ねます。そして、私はそれが個人的に本当に好きです。そのような態度は私たちに本当に役立っています。そして、いつも考えるのは楽しいことだと思います。もっと速く行けますか？

「四半期に100％の可用性に達した場合はクールですが、「ねえ、私たちは十分なリスクを負っていませんか？」と自問する必要があるかもしれません。」

ジェイミー・オスラー：あなたがあなたの会社にとって速く進むことを批判的にし、それがあなたがいつもしていることであるなら、あなたはより少なく壊れる傾向があります。

Ciaran Lee：うん。速く動き、許容可能なパラメータの範囲内で物事を壊します。停止しても問題ありません。バグがあっても問題ありません。明らかに、特定のカテゴリのバグを他のカテゴリよりも少なくしたいのですが、可用性の予算があります。四半期に100％の可用性に達した場合はクールですが、「ねえ、私たちは十分なリスクを負っていませんか？もっと速く動くためにもう少しリスクを冒してもいいですか？」あなたはスペクトルの意図的なポイントにいるはずです。そして確かに、私たちには大きな責任があります。私たちにはたくさんの顧客がいて、何十万人もの人々がログインして、毎日受信トレイを使用して顧客と話をしています。動きが速すぎたり、変更が速すぎたりして、使用方法すらわからなくなってしまうようなことはできません。それは間違っているでしょう。制約はありますが、その制約の範囲内で、できるだけ速く移動する必要があります。

合法的なところ

Liam Geraghty：そして私たちはこのエピソードを通してできるだけ速く動いています。次は、インターコム、シニアカウンセル、ミーナポリッシュです。 Meenaは、製品とエンジニアリングに重点を置いた法務チームに所属しています。 2021年1月、MeenaとJamieは、法務チームとエンジニアリングチームがどのように連携できるかについて話し合いました。

「私たちはここで、誰かを遅くすることなく責任を持って行く必要がある場所に到達するために、会社とすべてのクライアントとの一種の行進のロックステップにいます」

Meena Polich：製品を理解することは私たちにとって本当に重要です。私たちが販売しているものを実際に理解していない場合、どのような規制が私たちに影響を与えるのか、または私たちが従わなければならない法律について、どのように会社に助言することができますか？非常に基本的なレベルでは、戦略的な観点から、現在販売しているものだけでなく、販売したいもの、自分自身を位置付けて成長させたい方法を理解する必要があります。そうすることで、法的な観点から監視する必要のあるものの予測を立て始めることができます。そして、私たちがここにいることを確認するだけで、会社とすべてのクライアントとの間に、誰もが遅くなることなく責任を持って行く必要がある場所にたどり着くことができます。より戦術的なアプローチから、会社の価値観と製品を理解することは、顧客やベンダーとの交渉に非常に役立ちます。私たちがやろうとしていることを理解するとき、それは私をはるかに良いレバレッジの立場に置きます。そして、ベンダーに「これをやろうとしているので、あなたがこれをできるようにする必要があります」と説明することができます。

逆に、私が顧客と交渉しているとき、多くの場合、テーブルの反対側の人々は、私と同じくらい技術的である他の弁護士または調達エージェントです。そのため、弁護士として製品が何をするのかを説明することができます。「法律上のリスク管理の観点から、あなたの懸念が何であるかはわかっていますが、プラットフォームが実際にどのように機能するかを次に示します。製品が実際にどのように機能するかを次に示します。そして、それがあなたが心配しているこのリスクを取り除くつもりがない理由です。あなたが心配しているそのリスクを引き起こすことはありません。」

「私の最優先事項は、私がここにいるのではないことを研究開発が理解できるようにすることです。

ジェイミー・オスラー：これは両方の方法で機能すると思いますよね？研究開発が、関心のある分野がどこにあるかについての高レベルの法的概要の種類をよりよく理解している場合、それは彼らが危険またはそれらの法律に違反するであろうことを意図せずに行ったり製品を構築したりすることを避けるのに役立ちます。

Meena Polich：はい、もちろんです。そして、それは、研究開発との法的な関係を構築する際に、取り上げたり、焦点を合わせたりするための最も重要なことです。私の最優先事項は、研究開発が私たちの驚くべき進歩を妨げるためにここにいるのではないことを理解するのを助けることです。私たちのチームは、私たちが成長し、会社のすべての個人が行っていることすべてを監視することが難しくなるにつれて、倫理的にそれを継続し、法律の範囲内でそれを継続することを確認するためにここにいます。そして、可能な場合は、そのリスクを管理しようとします。

これが、設計によるコンプライアンスが非常に重要である理由の1つです。コンプライアンス要件またはコンプライアンスの期待を念頭に置き、それらに向けて設計する場合、多くの場合、設計変更は実際に収益に役立つものになります。リソースの割り当てに関しては初期コストがかかる可能性がありますが、長期的には、超長期的にも、多くの場合、その機能をプッシュしてから6か月から1年以内に、信じられないほどのメリットが得られます。収益の成長と私たちが生み出したリードの種類、そして顧客が私たちを信頼してくれるので顧客を引き付けるという点で。

Liam Geraghty：エンジニアチャットを作成したJamie Osler、新しいホストのBrian Scanlan、そして今日は内部チャットを外部に公開してくれたすべてのゲストに感謝します。今日のショーを楽しんだら、レビューを残したり、ソーシャルについて大声で言ってみませんか。私たちはあなたの考えを見て、聞くのが大好きです。今日は以上です。来週、InsideIntercomの別のエピソードで戻ってきます。

インターホンのキャリア