.svg)
.svg)
.svg)
.svg)
.svg)
先日、メルカリのカスタマーリライアビリティプラットフォームのエンジニアリングヘッドであるMohan Bhatkar氏と、Blamelessの共同共同創業者であるAshar Rizqi氏との対談が行われました。そこでは、部門の壁を取り払いつつ規模を拡大する方法、日々直面している刺激的な課題、エンパワーメントの文化を根付かせることなどが語られました。その中から主な洞察や、短く編集した対談の一部をご紹介します。
主な焦点
- 会社規模が何倍にも成長する中でもメルカリが組織の連携を保っている秘訣は何か→メルカリは、ビジネス、プロダクト、エンジニアリング間で、顧客満足度に関連する主なビジネスゴールの足並みを揃えるべく「キャンプ」というチーム構造を採用している。
- メルカリが取り組んでいる刺激的な課題は→Mohan氏は次善の策ではなく、拡張性のある解決策を提案しチームのモチベーションを高めることに最も刺激を感じている。
- エンパワーメントの文化を根付かせる→メルカリではキャンプという独自のチーム構造を採用している。キャンプとは経験豊富なソフトウェアエンジニア、プロダクトマネージャー、エンジニアリングマネージャーによる、会社のビジョンの特定の部分を専任する自律型グループ。この体制により、一貫して信頼性と革新のバランスを維持することができ、チームがより迅速に革新や価値をもたらすことができる。
- アーキテクチャチームは部門間の障壁を取り払う上でどのような役割を果たすのか→各キャンプを代表する連絡係が定期的にアーキテクチャチームと会って話すことにより、足並みを揃えることができる。
- チームメンバーが幸せで仕事に熱中できる環境を作る→メルカリでは従業員を顧客と同じくらい重要視することにより会社への帰属感を高めている。また、メルカリでは全ての従業員に平等にチャンスを与えることを大切にしている。
- Blamelessのどのような点がメルカリのビジョン、プロセス、文化とマッチしているのか→Blamelessはメルカリによる、（インシデント対応など）SREのベストプラクティスに沿った拡張性と反復性のあるプロセス構築、ならびに、継続的な改善のための適切な評価基準蓄積をサポートしている。
Ashar: Mohanさん、お会いできて光栄です。あなたは興味深い経歴をお持ちですね。インドから日本に移り住み、日本語を学び、テクノロジーの世界に足を踏み入れています。そこから素晴らしい経験とキャリアを積まれています。その経緯について詳しくお話いただけますか？
Mohan:この分野で仕事を初めて今年で10年になります。とても長い日々でした。当時、私は大学で電子工学を学んでおり、情報工学を学んでいたわけではありませんでした。大学で工学を学び始めた頃から、常にコーディングに夢中でした。
電子工学よりも関心があったのです。実際、大学で学ぶ分野自体を変更しようかと思ったほどです。しかし一度専攻や分科を選択してしまうと、変更するのはそう簡単ではありません。電子工学を学び続けながらも、C++やデータベースなど、プログラミングの基礎も学びました。大学の最終学年になった時点で知っていたのは、インドのソフトウェア企業やインドで設立し、アメリカに拠点を置くソフトウェア企業のみで、日本のソフトウェア企業は知りませんでした。
そんな時、日本のソフトウェア企業が採用のために私の大学にやってきました。私の通っていた大学はマハーラーシュトラ州でトップクラスの大学でした。このようにして、これまでまったく知らなかった楽天と、日本という国について知ることになりました。楽天はソフトウェアエンジニアを探していました。そして私は様々なプラットフォームを扱う日本最大手のインターネット企業である楽天に興味を持ちました。
私は元々電子工学部出身で、基礎的なプログラミングの知識しかなかったため自信がありませんでしたが、テストを受けたところ、採用されました。非常に貴重な体験だったため、私にとって最高の思い出です。
ソフトウェアサービスの大半は日本語で提供されているため、採用後、日本語を学ばなければなりませんでした。そのため、日本語を学びながら、ソフトウェアエンジニアとして働き始めました。そして楽天のトラベル部門向けのサービス開発を担当しました。楽天トラベルは、日本最大手のオンライントラベルサービスです。トラベル部門では、ホテルやバス乗り換え、車のレンタル、フライトの予約などのサービスを日本の顧客に提供しています。同時に、外国人が日本に来て観光を楽しめるよう、10ヶ国語以上に対応したインバウンドサイトも立ち上げました。
4年間ソフトウェアエンジニアとして働き、複数の予約プラットフォームを開発したあと、トラベル部門のテックリードになりました。その後、エンジニアリングマネージャーになりました。楽天トラベルでは8年間という大変長い期間この役職を担当しました。その後、メルカリに移りました。
メルカリに転職した主な理由は、自分にとって快適な場所から抜け出し新たな環境で自分の力を試してみたいと思ったからです。メルカリは既に大きな大企業だった楽天とは違い、まさに成長中の、進化を続ける環境でした。
メルカリの歴史を振り返ってみると、日本で最初のユニコーン企業の一つでした。ほんの短い期間で非常に大きな規模まで成長しました。そのことにずっと関心があり、その環境の中で自分がどれだけチャレンジができるか、どのようなことを学べるか試してみたかったのです。1年間メルカリでエンジニアリングリーダーとして働いたところ、期待通りの場所であることが分かりました。自分自身やお客様、そして会社がよりよくなるように日々新しいことに挑戦するのは大変刺激的です。
私はメルカリのカスタマーリライアビリティチームのエンジニアリングマネージャーを務めました。メルカリの従業員数はこの2年間で急激に増加し、会社の規模も何倍にも成長しました。これほどの規模になると、以前までのやり方や体制ではうまくいかなくなっていきます。そこで、会社は今年の上旬から、これまでの縦割りの体制ではなく、ビジネス、プロダクト、エンジニアリングの連携をより強める方針を固めました。
そして、組織のキャンプシステムが考案されました。キャンプとは経験豊富なソフトウェアエンジニア、プロダクトマネージャー、エンジニアリングマネージャーによる、会社のビジョンの特定の部分を専任する自律的グループです。私もキャンプの一つのエンジニアリングヘッドを務める機会がありました。
私は現在、カスタマーリライアビリティエンジニアリングキャンプの責任者です。メルカリはお客様同士が自由に売買できるマーケットプレイスを提供する、CtoCのプラットフォームです。BtoCではありません。そのため当然お客様がどのような行動をとるかをコントロールすることができません。基本的にはお客様全員が公正で、不正を働かないことを前提としていますが、同時に、全ての利用者の皆様にとって安心で安全なプラットフォームを提供しなければなりません。私はこれがカスタマーリライアビリティエンジニアリングの役割だと考えています。お客様同士が各々商品を販売し取引をしていますが、そこに利用規約の違反は発生していないか？違法なものが取引されていないか？取引は安全な方法で行われていて、他者に害を及ぼしていないか？…これらを確認しなければなりません。
私たちのチームではルールとAI技術を利用したモデレーションプラットフォームを利用して、取引を背後で監督し、カスタマーサポートチームがユーザーへの問い合わせや苦情を解決したり削減したりするサポートをしています。
もう一つの課題は、いかに使いやすさを損なうことなくお客様に安全性を提供できるかです。セキュリティを強化したいのであれば、多要素認証など様々な対策が考えられます。あらゆるところでユーザーの行動を制限することも可能です。しかし、これではユーザーフレンドリーではありません。この双方のちょうどよいバランスを取ることが重要です。お客様がカスタマーサポートへお問い合わせをしやすい状態が構築できていると思います。
Ashar: Mohanさん、ありがとうございます。非常に興味深いお話でした。私はプログラミングが大嫌いでした。C++を考案したのは私の大学の教授だったのですが、彼があまり好きではありませんでした。私は大学時代、ハードウェアと電子工学が学びたかったので、あなたと真逆でした。その情熱を貫いたことは素晴らしいですね。私は仕方なくソフトウェアを学んだのですが、今では大好きです。
企業の文化とバリューについて、もう少しお話を伺いたいと思います。メルカリのお話の中で少し触れられていたかと思います。ご自身のお仕事について説明された際に非常に興味深いことをおしゃっていました。「お客様によりよいサービスをお届けするために、企業のバリューに紐づいたキャンプという制度を採用することになった」と仰っていましたが、もう少し詳しくお話しいただけますでしょうか？これほど急成長している企業の中で、自ら行動しバリューを貫くというのは非常に素晴らしい成果のように感じます。
Mohan:メルカリにきて非常に感銘を受けたのは、自分自身に強く紐づいた3つの主要なバリューを掲げていることでした。1つ目は「Be a Pro（プロフェッショナルであれ）」というものです。従業員一人一人がプロフェッショナルとして行動することが求められています。そのため、真のプロフェッショナルにふさわしい専門的な知識レベルを身につけ、スキルアップをはかるために各々が努力をします。
2つ目のバリューは「Go Bold（大胆にやろう）」です。こちらは最も興味深いバリューだと思っています。大胆であるということは新しいことに挑戦するということ。失敗しても構いません。メルカリの歴史を振り返ってみると、この6年間でたくさんの事が起こりました。日本でメルカリというマーケットプレイスを立ち上げた後、アメリカにも展開し、成果が得られました。その後イギリスでも展開しましたが、残念ながらこちらはうまくいきませんでした。
プロダクトエンジニアリング、ビジネス、経営陣が一丸となって取り組んだ事業でしたが、時にはうまくいかないこともあります。しかし、だからといって挑戦をやめるべきではありません。次はうまくいくように工夫する事が重要です。昨年は当社のCtoCマーケットプレイスと連携した決済プラットフォームをローンチしました。現状、そちらはうまくいっています。Go Boldというバリューには、失敗は避けられないものだという意味も込められています。失敗は避けられませんが、だからといって再度挑戦することをやめてはいけません。
3つ目のバリューは「All for One（すべては成功のために）」です。チームで力をあわせる事が重要です。たとえ自分がエキスパートであっても、一人では大きな仕事は成し遂げる事ができません。なんでも知っているわけではないのですから。従業員はこれら全てのバリューを非常に重要視しています。
キャンプシステムはこのバリューから着想を得たものです。以前はビジネス、プロダクト、エンジニアリング、モバイル、ウェブ、バックエンド、プラットフォーム部門がそれぞれ縦割りになっており、連携ができる体制になっていませんでした。それぞれが四半期毎のOKRを設定しようとしていましたが、ばらばらでした。そこで、All for Oneの考えのもと、全員が協力して、お客様にどんな価値を提供すべきかを考えることにしたのです。
全てのマーケットプレイスアプリケーションの業務を網羅するプロダクト開発キャンプが8つ以上存在しますが、これらが一つのチームとして力を合わせて業務を遂行しています。
Ashar:本当に素晴らしいです。非常にユニークな取り組みですね。メルカリのバリューとチーム編成のお話に大変感銘を受けました。どれほど会社の規模が大きくなり変化しても、バリューが道標になるということですね。
それがバリューのよいところです。一度バリューを定めて、従業員がそれを自分のものにすると、リスクを背負って何かを決断する際の後押しになり、重要なフレームワークから外れることなく、素早く行動を取ることができるようになります。
カスタマーリライアビリティエンジニアリングキャンプのリーダーとしての日々の業務の中で、最も刺激的なことはなんですか？また、最大の課題はなんですか？メルカリのシステムは複雑ですが、ユーザーが利用規約に違反していないかどうかをどのように管理しているのでしょうか？Facebookのように、大勢のモデレーターを雇って、投稿のモデレーションをさせるというわけにはいかないでしょう。
Mohan: カスタマーリライアビリティエンジニアリングキャンプのヘッドとしての私の一番の責任は、チームメンバーの向かっている方向が会社のビジョンやミッションと合っているかどうかを確認することです。私たちのキャンプのビジョンは、誰もが安心安全に利用できる信頼性の高いマーケットプレイスを構築することです。全てのキャンプは、それぞれのビジョンを掲げています。また、年間のロードマップを作成し、それにしたがってお客様にサービスを提供するよう努めています。
私の役割はチームの足並みが揃っていて、お客様に価値を提供できているかどうかチェックすること。私は、チーム全体に明確な目標と方向性を示した上で、バリューをしっかりと生み出せるよう、可能な限りのリソースを提供するようにしています。とはいえ、いつも計画通りに行くとは限りません。そんな時は都度深掘りして、何がいけなかったのかを検証しなければなりません。そこからどのような教訓が得られ、次にどのように活かせるかを考えるのです。
日々の問題への解決策や改善の方法を考えることはとても刺激的です。さらに刺激的なのは、次善策ばかり考えているわけにはいかないということです。スケールを拡大できるだけでなく、費用対効果もよいソリューションを考える必要があります。これは私の主な責任でありながら、最も刺激的なことでもあります。
主な課題…これは簡単なことではありません。ベストを尽くすしかありません。チームの状況を理解しなければなりません。本当によいものを提供するためには、「人」が鍵になるということを忘れてはいけません。人、プロセス、そしてテクノロジー。この3つが揃う事が重要です。エンジニアリングのリーダーとして、日々の業務にあたる上で私はこの3つのバランスに注意しています。
メルカリは急成長しています。昨年までうまくいっていたやり方が次の年にはもううまくいかなくなることがあります。繰り返しになりますが、大規模に展開できる費用対効果の高いソリューションを考えなければなりません。私の直面している最も大きな課題の一つは開発の速度と信頼性のバランスです。これはマネージャーやリーダーが共通して抱えている課題でしょう。どちらかに力を入れると、どちらかが疎かになりがちです。
そのため、スピード感を持ちながら、品質を維持する方法についていつも考えています。昨年からメルカリでは、採用、オンボーディング、プロダクト開発、連携、メンバーシステムの成長など、組織内の様々な要素の規模の拡大を試みてきました。具体的な方法でうまくいったものの一つは、全てのチームにおけるアジャイルの導入です。
サービスの提供に関していえば、以前は締め切り重視のアプローチ、もしくはウォーターフォールモデルのアプローチを採用していました。しかし組織自体が変わったことに伴い、アプローチも変更しました。インシデント管理、SLO管理など、信頼性の面に関しては、まだその域には達していません。とは言っても、ベストを尽くしています。お客様に高品質な価値をお届けできるようにこれらを特定のチームにも導入しています。
Ashar:あなたが考えている、もしくはチームに根付いている企業文化の指針などはありますか？それを達成するためのツールが存在しなかったとします。先ほど深く考えるということを仰っていました。エンジニアリングヘッドとして、チームが正しい決断をする後押しをできるように、根付かせたいと思っている企業文化の指針やプラクティスはありますか？その中でうまくいったもの、うまくいかなかったものがあれば教えてください。
Mohan:2018年の頭から、テクノロジーの面だけではなく、組織の面でも、社内に様々な変化が起こり始めました。テクノロジーにおける変化の一つは、他社でも盛んに見られたマイクロサービスアーキテクチャへの移行です。
それ以前はCtoCマーケットプレイス全体が単一のモノリシックアプリケーション上で実行されていました。当社の最高技術責任者とエンジニアリングメンバーの一部がマイクロサービスへの転換を決断したため、移行を開始しました。まずは、モノリシックアプリケーションからコンポーネントを抽出し、マイクロサービスの構築を開始しました。ところが、その作業を行う際、皆が一から作り直すことになっていました。これはあまり現実的でスケーラブルな方法とは言えません。
しばらくして、何か問題が発生していることに気がつきました。そのため、ステージ毎に振り返る必要がありました。昨年、1年かけてプラットフォームチームを設立しました。プラットフォームチームにより、プロダクト開発チームの全員がプラットフォームを利用できるようになったため、全てやり直したり、一から構築したりする必要はなくなりました。
プラットフォームチームはソフトウェア開発の全てのフェーズを担当します。また、アプリケーションを構築するために必要な全てのツールやキットを提供します。このプラットフォームを作成して本当によかったです。でなければ、何度も同じ失敗を繰り返すところでした。
これに関しては、これまでのところ非常にうまくいっていて、とてもよい決断をしたと思っています。その下にはインフラチーム、クラウドベースチーム、可観測性プラットフォームを抱えています。一方、その上には構築、テスト、デプロイ、運用のサポートを提供する専任のチームが存在します。
このアーキテクチャをエンジニアリング部門にも導入しました。アーキテクトチームの役割は最適な技術的ソリューションを提供したり、プロダクト開発チームと事業や顧客の具体的なニーズに基づいてどのようにシステムを応用できるかを協議したりすることです。その一方で、同時にどのようなリライアビリティのゴールに向けて努力をするべきでしょうか？このサービスはお客様にとって非常に重要です。リライアビリティのゴールはチームが安定した、安全で、信頼性の高いシステムを提供することを目指しています。
それに加えて、彼らと協力して、プロダクトを提供するプロダクト開発チームがいます。
Ashar: Blamelessでも最近同じような取り組みをしました。当社でも社内にプラットフォームチームを立ち上げました。当社では早くから他の開発チームが大規模、迅速、効率的に、そして、スキルを持って業務に当たることの重要性を感じていました。
アーキテクチャチームはとても興味深いですね。アーキテクチャチームは時に非常に縦割りの組織になってしまい、情報が一方向にしか流れていかないことがあります。設計者がトップに立ち、プロダクト開発チームに指示を出すという構図です。チームが協力して作業を進めるためにどのような工夫をしているのでしょうか？その秘訣はなんですか？
Mohan:そのような状況が起こり得るフェーズはどの会社にもあります。アーキテクチャチームは縦割りになってしまい、他のチームは何を目指しているのか分からなくなってしまいます。メルカリでもそのような状況が起こっていたかもしれません。
しかし、メルカリには全てのシステムがアーキテクチャのレビューを受ける自動プロセスが存在します。設計者が提案をします。新しいシステム提供の際、全ての従業員の納得が確認されます。特定のサービスの決まった信頼性レベルを達成するために必要な協力体制です。このようにして、具体的に、重要なサービスを協力により実現しています。
組織という単位ではアーキテクトチームを設立しましたが、それに加え、各キャンプ、またはアーキテクトチームと仕事を進める各チームには連絡担当を置いています。これを当社ではアーキテクトチャンピオンと呼んでいます。その担当者はアーキテクトチームと定期的な打ち合わせを行い、キャンプとの橋渡しの役割を担います。アーキテクトチャンピオンがアーキテクチャのガイドラインやアップデートなどをチームに伝えます。
Ashar:とてもよいアイデアですね。先ほど、リライアビリティのゴールがあると仰いました。システムのレベルでは、プロダクトエンジニアが自分の意見を述べ、それを受けてプロジェクトマネージャーがそれを整理しコーディネートする。リライアビリティのゴールに焦点を当てることで従来のアーキテクチャチームの縦割りの特性を打ち消しているのですね。
チームがメルカリへの熱意を保つためにしていることはありますか？チームエンゲージメント、従業員の保持、キャリアアップなどについてもう少し詳しく教えてください。
Mohan:社内全ての従業員に平等に機会を与えることを心がけています。従業員が満足していれば、物事を前進させることができます。メルカリでは従業員のことをお客様と同じくらい重要視しています。会社の規模が大きくなるにつれ、問題も増えてきます。
新型コロナウィルスなど、会社が向かっていく方向が全く分からなくなるような事態も起こります。そのような時だから、従業員こそ最大の資産であるという事実を大事にするのです。全ての従業員に等しく機会を与えることが必要です。
当社では全ての従業員が「ソフトウェアエンジニア」であると考えています。これは、全ての従業員がソフトウェアに精通すべきだと言いたいわけではありません。誰もがiOSやAndroid、バックエンドなどを開発できるわけではありません。それは不可能です。ここで言いたいのは、もしもエンジニアリングに関して何か試したいことがある人がいたとしたら、たとえ経験や専門性がなかったとしても挑戦することを阻むべきではないということです。
挑戦する機会は誰に対しても開かれているべきです。最終的なゴールはお客様や会社に対して何らかの利益をもたらすことです。そのやり方やアプローチは問いません。これが会社やエンジニアリング部門の考え方であり企業文化です。
チームエンゲージメントに関しては、私が非常に感銘を受けたのはチーム単位のビジョンとミッションです。会社や部門、キャンプレベルのみならず、チームレベルでもビジョンとミッションが存在します。例えば、5、6人のチームだったとしても、チームのビジョンとミッションを定めています。また、それを達成するためのロードマップも設定しています。
例えば、当社にはカスタマーサポート従業員のための社内ツールを開発しているチームが存在します。彼らは実際のお客様向けのプロダクトの開発には一切携わっておらず、同僚であるカスタマーサポートのメンバーに対するプロダクトのみ開発しています。彼らのビジョンとミッションは自動化によりカスタマーサポートにおける仕事の効率と生産性を改善することです。
さらに、全てのチームにはキャンプレベルの決まったミッションもあります。全てのキャンプレベルのミッションは、会社レベルのミッションに繋がっています。個別のビジョン一つ一つが会社、もしくはお客様に対する実際の最終ゴールと結びつくように気をつけています。
しかし、これは簡単ではありません。従業員全員が会社とのつながりを実感するのは不可能です。そのため課題もあります。現在与えられている仕事にモチベーションを持って取り組めない人もいるかもしれません。エンジニアリングマネージャーとして、また、その従業員の上司として、問題を細かいところまで見ていく必要があります。チーム内でどんなことが起こっているか？モチベーションに関する問題は発生しているか？技術的な課題、過程に関する課題は発生しているか？そしてそれらの問題点を解決する努力をしなければなりません。
全ての従業員に成長の機会を与えるということに関しては、当社は非常にオープンです。何かに挑戦したいという人がいたら、決してノーとは言いません。必ず「何ができるか考えてみよう」と言うのです。そこでノーと言えば、その従業員はモチベーションを失ってしまうでしょう。このようにして、チームの熱意を保っています。彼らが小さな問題点に目を向けるのではなく、より大きなミッションと紐付けて考えられるようにしています。
Ashar:お話をありがとうございました。非常に共感しました。急成長をして規模が大きくなると、ビジョンやミッションが不明瞭になってしまうことがよくあります。より細分化したアプローチを取ることが重要ですね。全てのチームが各々ミッションを持つことで、帰属意識と会社とのつながりを感じられるでしょう。リーダーシップを取る立場の人にとっては、ミッションがより可視化され、決断を下す上でも役に立ちますね。
Blamelessとの連携についてももう少し詳しくお話いただけますか？Blamelessはどのような点でメルカリのミッションとフィットしているか、またこれまでのチーム内でどのような影響があったか、テクノロジーリーダーとしてのご意見をお聞かせください。
Mohan: Blamelessとの関係はとても素晴らしいものです。「Blameless（欠点のない）」と言う言葉自体が、企業文化の鍵となる部分をよく表しています。最高技術責任者と執行役員はいつも、非難されるべきは人ではなく、システムやプロセスだと言っています。
ちょうど1年前にBlamelessを紹介されました。カスタマーサポート、決済プラットフォームの担当者、モバイルエンジニア、バックエンドエンジニア、インフラチームなど、社内の様々な部署と話して、全てのインシデント管理に関連する問題点を集約しようと考えました。問題の要点をまとめようとしていました。
当社の最高技術責任者からBlamelessの紹介を受け、デモを依頼し、Morgan氏（Blamelessの担当者）とお会いしました。2019年の最後の四半期に、概念実証を行いました。当社の最高技術責任者、VP、私自身を含めたメンバーがオンボーディングセッションを受け、デモを実施していただいたところ、Blamelessが当社の抱える問題の大半を解決できるということが分かりました。
その後、セキュリティ、決済プラットフォーム、クライアント、モバイルなど様々なチームにおいて次の四半期をかけて概念実証を行いました。次の四半期には公式な実証を行いました。Blamelessの担当者が東京にやってきて、10チーム、100人を超えるメンバーに対して対面での研修を行いました。
前四半期には、メルカリ全社のインシデント管理ツールとしてBlamelessを導入することを決定しました。そしてこの四半期に入って、導入を開始しました。Blamelessを600人以上のメンバーが新たに導入するには時間がかかりますが、今のところ大変順調です。
しかし、新型コロナウィルスの影響で、会社全体での展開に伴う対面での研修が実施できませんでした。そこで、個人で完結でき、分かりやすい動画の研修コンテンツを準備することにしました。また、従業員が試すためのサンドボックスも用意しました。今のところ、このアプローチはとてもうまくいっていて、着実にチームの研修とプロセスの確立は進んでいます。
Blamelessの最大の利点は、当社のインシデント管理プロセス全体を整理するための適切な構造になっているというところです。以前は、Googleフォーム、Googleドキュメント、JIRAを利用していたかと思います。複雑で、これらのツールから評価基準を抽出することは一切できませんでした。
Blamelessでは、インシデントに関連するあらゆる事柄を評価できます。物事は評価しなければ改善できません。Blamelessを導入することで、インシデントに関連する重要な事柄を評価できるステージに突入しました。これでMTTAやMTTR、障害報告やフォローアップアクションにかかった時間、お客様へ影響を及ぼした時間をどれだけ削減できたかを検証することができます。このような検証を今後一層強化していきたいと考えています。
この記事をお楽しみいただいた方はこちらもご覧ください。
・Instacartのインフラストラクチャ担当ヴァイスプレジデントの考えるリーダーシップとイノベーションについて
・IterableでBlameless導入により重大なインシデントが43%減少
