プレゼンテーション：開発者エクスペリエンスチームの最適な効率性を実現する

InfoQ ホームページ プレゼンテーション 開発者体験チームの最適効率を実現する 開発者体験チームの最適効率を実現する Fabien Deshayes は、Monzo の開発者速度（Developer Velocity）スquad 背後にある戦略について議論します。彼は「プラットフォームを製品として扱う」というマインドセットを説明し、製品に関する洞察力と経験を持つエンジニアの必要性を強調しています。また、時間、コスト、認知負荷を通じて DevEx（開発者体験）への影響を測定するための具体的なフレームワークを紹介し、規制環境において小規模で焦点を絞ったチームがどのように大きな成果を生み出せるかを実証します。 Fabien Deshayes は Monzo のプラットフォームエンジニアリングマネージャーであり、卓越した開発者体験を実現することでエンジニアの速度を意味ある形で向上させるために開発者体験チームを率いています。Monzo 以前には Spotify でエンジニアリングマネージャーとして働き、オープンソースの開発者ポータルである Backstage の構築に貢献しました。 カンファレンスについて ソフトウェアは世界を変えています。QCon London は、開発者コミュニティにおける知識とイノベーションの普及を促進することで、ソフトウェア開発を強化します。実践者主導のカンファレンスである QCon は、チーム内のイノベーションに影響を与える技術チームリーダー、アーキテクト、エンジニアリングディレクター、プロジェクトマネージャーを対象に設計されています。 Fabien Deshayes: 私たちは何について話そうとしているのでしょうか？私の名前は Fabien Deshayes です。Monzo でエンジニアリングマネージャーを務めています。イギリスからの方なら、おそらく Monzo についてはご存知でしょう。簡単に言えば、私たちはここで運営しているデジタル銀行です。顧客数は 1,100 万人を超えています。これは比較的少人数のエンジニア組織で達成した成果です。私の確認では直近で 412 人でしたが、エンジニアはおよそ 400 名程度です。特に 1,100 万人もの顧客を抱える銀行としては、かなり小規模に見えるかもしれません。しかし、私は私たちを単なる銀行ではなく、たまたま銀行を運営しているテック企業と捉えています。これは、私が Monzo をどのように考え、推論しているかという点に尽きます。 Monzo の Dev Velocity チームについてお話しします。私たちが Monzo で構築した DevEx チームとその成果です。2023 年 12 月、私たちは「Developer Velocity squad（開発者速度ス쿼ッド）」を結成しました。画面に映っているのがそのメンバーたちです。エンジニアが約 3 名と、エンジニアマネージャー 1 名の計 4 名ほどのチームです。このチームは「Experimentation Platform（実験プラットフォーム）」と呼ばれるものの開発に取り組んできました。では、Experimentation Platform とは何でしょうか？簡単な例をお見せしましょう。これは「roundups（端数切り上げ）」という機能の画面です。支払いを行うたびに、その金額を最も近いポンド単位に切り上げて、その差額を投資用プールに積み立てる仕組みです。非常にシンプルで、とてもクールな機能です。すべての数字が丸くなり、直感的に理解しやすくなります。この実験では、2 つのバージョンを用意しました。 左側には、コントロール版があり、これは基本的にその機能が何をするものかを説明するものです。右側には、少しグラフが追加されており、「過去 1 年間に支払った支払いに基づくと、この金額を投資ポットに投入していたはずであり、10 年後にはこれがこの程度の金額に成長したでしょう」と述べています。これは、あなたの資金がどうなるかという物語を語っています。私たちが行ったのは、これらの 2 つの変異体のいずれかを顧客に提示することであり、実験の主な目的は、どちらが最も高いコンバージョン率をもたらすかを特定することです。下部にある「投資ポットを作成」ボタンをクリックする人がどれほどいるのか？これが基本的には実験プラットフォームです。 チームは何を達成したのでしょうか？当初、私たちは古い社内製の実験プラットフォームを持っていましたが、それはまあまあの状態でしたが、特にその上でデータ分析を行うのが非常に困難でした。それを 7 ヶ月で置き換え、その結果、2024 年から 2025 年第 1 四半期にかけて、会社内で実施する実験の数を 70 から 134 と倍増させることができました。また、意思決定までの時間を半分にする成果も上げました。以前は、実験を実行して最適なオプションがどれかを特定し、意思決定に至るまでに 43 日かかっていました。現在はわずか 21 日で済むようになりました。これはこれ以上短くすることはできません。なぜなら、適切な判断を下すためには、依然として一定の期間を曝露（exposure）させ、十分なデータを収集する必要があるからです。 DevEx チームを編成する どうやってそれを成し遂げたのか？それが今日お話しする内容です。このように短い時間で成功に導いたには、3 つの要素があると考えています。まず、優れた開発チームを編成できることです。これについてお話します。次に、非常に影響力のある製品を構築しました。ここでは製品側面に焦点を当て、DevEx 製品のインパクトについてお伝えします。それら一つずつ掘り下げていきましょう。まずは DevEx チームの編成です。 スライドを作成する際、私のチームはスーパーヒーローの集まりだと考え、「DEVEX-MEN」と名付けようと思いました。とても素敵な名前だと思ったのです。 しかしその後、それは包括的ではなく、真実でもないことに気づきました。多様性が必要であり、エンジニアたちはスーパーヒーローではありません。どの企業でも見られる普通のエンジニアと同じです。私たちは、適切なスキルを持つ人々を適切なチームに集め、正しい方法で働かせることに成功しただけです。「ニンジャエンジニア」や「トップスター」「ロックスター」といった存在がいるという事実を神秘化してはなりません。そのようなケースではありません。優れた開発者体験を構築するために、こうした特別な人材が必要なのではありません。必要なのは、適切な人々だけです。 まず、製品に関する洞察力を持つエンジニアを見つける必要があります。これは基本的に、良い判断を下し、迅速な意思決定を行う能力のことです。 基本的に、社内他のエンジニアを顧客と捉える必要があります。彼らがあなたのプロダクトを利用する人々です。本当に顧客として考えてください。また、迅速なトレードオフを行う能力も必要です。速やかに動く必要があります。それは内部ツールを構築しているからといって、ハードデッドラインがないためではありません。あるマーケティングチームが「この日までに新機能をリリースする」と言ったからといって、その理由で素早く動いたり反復したりしないべきだということにはなりません。それでもなお、あなたの取り組みを見て、「過去半年、あるいは四半期に何をしたのか？」と尋ねる人々がいます。どのように速やかに動き、トレードオフの判断を下すかを考える必要があります。 最後に、この意思決定を行い、長期的な視点を持つ必要があります。内部開発者ツールの作業をしているときは直感的ではないかもしれませんが、単に何かをテストしたり、サイドでハッキングしたいだけになるからです。もし成功すれば、それは10年、15年と続くことになります。これらの決定が潜在的に元に戻せるものか、それとも不可逆的なものかを本当に考える必要があります。もし不可逆的なものであれば、それを深く考え抜き、なぜ他の選択肢ではなくこの決定を下したのかについて、十分な根拠を持つ必要があります。あなたのプラットフォームをプロダクトとして捉え、それに伴うすべての結果を考慮してください。 DevEx チームにおいて私が特に重要だと考える2つ目の点は、社内に一定の在籍期間があるエンジニアを特定することです。なぜそう思うのかというと、通常、数年間その会社で働いている場合、過去に一緒に仕事をした他のエンジニアたちとのネットワークが少しはできているはずです。チームに参加し、人々が別のチームへ移動していく中で、自分自身もまた、数年前から現在に至るまで2〜3のチームを渡り歩いてきた経験があるかもしれません。これはDevEx チームにとって無料のユーザー調査の機会をもたらします。再び言いますが、製品を構築する際に顧客について学ぶ必要があるという視点です。 それについて学ぶ最善の方法は、実際に彼らに話を聞くことです。開発者体験（Developer Experience）に問題を抱えているエンジニアを知っている人がいれば、それは素晴らしい機会です。ただ、その人に話しかけるだけで十分です。 また、長く在籍している社員は、よりシニアな立場にある可能性が高く、組織内で達成可能なことについての幅広い野心やアイデアを持っているでしょう。そのような点をすべて考慮し、彼らがこれらのアイデアをチームに持ち込んでくるようにしてください。 ただし、一つ注意点を付け加えます。非常に長い間在籍しているエンジニアがいるかもしれません。もしかすると、特定のチームでその問題に直面した時期があり、そこで停滞していたのかもしれません。その後、あなたの開発者体験（DevEx）チームに移ってきた場合、彼らは非常に強い意見を持ち、「あの問題を解決すべきだ」と考えるでしょう。「実際に現場で見たし、本当に苦痛だった」という思いを持っているかもしれません。 しかし、その問題は特定のチームだけで発生している可能性があり、他のすべてのチームでは起きていないかもしれません。したがって、エンジニアが以前在籍していたチームだけでなく、エンジニア組織全体を視野に入れて考えることが非常に重要です。 最後に、ソフトスキルについてです。あなたは製品を構築しています。その製品を販売する必要があります。マーケティングチームに協力してもらって製品を販売してもらうとは考えにくいです。ましてや、そのために一人でも手伝ってくれる人が見つかるとは思えません。結局、自分自身で販売を行う必要がありますが、販売は難しいものです。自分が何をしているのかを説明し、人々を説得できる能力が必要です。もし優れたソフトスキルを持つ人材が見つかったら、ぜひチームに加えてください。彼らは非常に有用です。 それに関連して付け加えたいことがあります。それは直感に反するかもしれませんが、ソフトスキルが最も優れており、話し方が上手で、聴衆の前でも堂々と話せるエンジニアこそが、エンドユーザーに近い立場にいる可能性があります。彼らがユーザー調査セッションに参加したり、直接ユーザーと対話をしたりすることもあるでしょう。一方で、開発者体験チーム（プラットフォーム担当など）に所属し、社内向けに活動する役割も重要だと考える意見もあります。なぜなら、採用が進まず、人々が製品について語らない限り、開発者体験チームとして成功することはできないからです。 これにより、開発者体験チームにおける理想的な人物像の三つの側面が浮かび上がります。理想を言えば、その真ん中に位置する人材が望ましいでしょう。心配する必要はありません。真ん中にあるためにエンジニアを三人や四人用意する必要はなく、そのような完璧な組み合わせを見つけるのは非常に稀なことだということです。 例えば、Monzo では、私にとってまさに真ん中にある人物を配置しました。優れたソフトスキルを持つ人と、長く在籍している人の組み合わせです。この混合は非常にうまく機能しました。その結果、バランスの取れたプラットフォームと製品を構築し、社内で多くの素晴らしい採用事例を生み出すことができました。また、これらのサークルに属さない人々を一部持つことも全く問題ありません。経験が浅い人や異なる背景から来た人もいますが、それらのスキルを持つ人々に囲まれていれば、成長し、吸収し、これらのサークル内を移動できるようになります。 インパクトのある製品を構築する 完璧な開発者体験チームが整った今、インパクトのある製品を構築する時です。再度強調しますが、ここではプロジェクトでもソリューションでもなく、製品について話しています。まず重要だと思うのは、会社のバリューと整合させることです。なぜなら、それがユーザーに共鳴するためです。Monzo の社内のバリューの一つとして、「Monzo マジック」についてよく話していますが、これがその価値そのものかどうかはわかりませんが、私たちは物事を魔法のようにシンプルにする方法を追求しています。例えば、友人たちと一緒にレストランで食事をしており、請求書を支払い、その後で請求書を分割したい場合でも、モバイルアプリでタッチするだけで済みます。これらの小さなことを非常に簡単にしたいと考えています。この考え方を、私たちの実験プラットフォームでも再現しようとしています。 私たちが行った例の一つは、実験の整理をできるだけ魔法のように簡単に行えるようにすることです。実験プラットフォームや機能フラグ（feature toggles）で働いている方ならご存知の通り、新しいものを作成するのは非常に容易ですが、整理し、コードを削除し、それが安全かどうかを理解することは常にずっと難しいものです。私たちは実験を終えたのでしょうか？私たちが開発者速度チームで行ったのは、小さなアプリと Slack 上のボットを作成することです。このボットはチームに、「ここに整理すべき実験があります」と通知します。どのようにして整理可能だと判断するのでしょうか？すべての評価結果を確認しています。その実験はまだ評価されているでしょうか？はいかいいえか？もし評価されていないなら、おそらく整理可能です。常に評価されているが、常に同じ値を返す場合、それは私たちがすでに

プレゼンテーション：開発者エクスペリエンスチームの最適な効率性を実現する

背景や根拠まで確認しますか？

調べる

選ぶ

サイト