こんにちは、Developer eXperience Squad の大坪です。このチームができてから2年が経ちました。当初とはミッションや考え方が変わってきていたり、より具体的な成果が出たりしているので2年という節目で現状のスナップショットを取ろうと思います。前回の記事は下です。

WHY より早く/より安全なプロダクト開発

Developer eXperience Squad のミッションは「エンジニアがより早く/より安全にプロダクト開発ができる環境」をつくることです。速度と安全性がキーワードになりますが、それぞれについて説明します。

より早く

より早いとは当然開発速度の話ですが、より具体的には「作りたいものに集中できる」という環境のことを指しています。なにか機能を作りたいときに、実装量が多くなることが見込まれたり、気をつけることが多かったり、そもそもどのようにすればそれが実現できるのかを調べるのに時間がかかってしまっては作りたいものに集中ができません。Wantedly のエンジニアにとって「作りたいもの」とはプロダクトそのものなので、何をすればプロダクトが良くなるのかを考え実験することにエネルギーを割くべきで、コーディングを含む実装自体に取られるエネルギーは最小化されるべきです。

より安全に

より安全にとは「プロダクトに問題を埋め込む可能性が低い」という環境のことを目指すことを意味します。「より早く」の話に通じますが、人は安心できないときに時間を使ってしまうと考えています。速度と安全性はトレードオフのように感じてしまい、安全性に振ってしまうことが多いという印象です。例として、大規模な手動テストが必要になる PR を merge するまでに不安だからという理由で時間を使ってしまった経験は誰しもあるのではないかと思います。仮に絶対に問題が起こることはないという環境があるとすれば、そこでの開発はユーザーに対して安定したプロダクトを提供できるだけでなく改善の速度を上げることができます。

HOW 良い技術基盤で達成する

上記に示したミッションを技術で解決するのが Developer eXperience Squad が日々目指していることです。社内でプロダクト開発を早くするライブラリの開発や基盤を作っています。このセクションでは Developer eXperience Squad がどのようにしてこのミッションを解決しようとしているかを書きます。

夢は世界を変える新しいフレームワーク/基盤を作ること

優れたテックカンパニーは優れた社内基盤を作って公開してきた、というのが筆者の持論です。この気持を募集タイトルにもしています。

例としては Google の社内基盤 Borg を前身とする Kubernetes、Facebook のフロントエンドを支える React、Amazon の計算資源抽象化で始まったAWS 等があるでしょう。ここで上げた例では技術領域 / 公開の仕方 / 公開に至った背景に様々なパターンがありますが、公開前に各社の開発体験が世界の一歩先を行っていたことが伺えます。彼らが Big Tech になれたのはこの未来の先取りができたからだと筆者は考えています。

Developer eXperience の目指すところもこれです。つまり社内の開発を徹底的に見直してプロダクトそれ自体に集中させるために本質的でないところを基盤として抽象化してそれを公開していくこと、そしてその技術的な優位性をもって会社を成長させていくことです。最も大事なところは「良い抽象化をする」というところであり、世界の一歩先を行くことや、それを公開するというステップは目的として目指すべきことではないかもしれません。しかしながら「どう見ても公開したら多くの人が欲しくなる」というレベルのものを作りたいという意味では良い基準になるので目指すべきところだと思っています。

「プロダクトにとって最も良い開発手法」を「最も楽な開発手法」にする

User Experience を考えるときにプロダクト開発者はユーザーではなくプロダクトを改善します。例えばユーザーが思い通りにプロダクトを使ってくれなかったときに「ユーザーの勉強不足だ」などと言うことはないでしょう。

これは Developer eXperience でも同じです。社内のエンジニアが自分たちの思ったとおりに開発をしてくれなかったら基盤や仕組みの改善を考えていきます。例えば「みんながテストを書いてくれない」という状況であればテストを書きたくなる体験を届けるべきです。「良くない実装が散見される」という状況であれば「良くない実装がやりにくい」環境を届けるべきです。

つまるところ Developer eXperience を改善するには自分たちが理想的な開発スタイルを示し、なぜ現実となっていないのか、なぜ社内の開発者は今その手法をとっていないのかを突き詰めて考えることが大事です。そういった意味で開発体験をデザインしているという気持ちでいます。言い換えれば開発環境というプロダクトを作っているというメンタルです。

究極目標は1行変更と0秒フィードバック

良い開発体験に近づけるためにまず考えていることが2つあります。それが「必要になる変更の量」と「フィードバックまでの時間」です。

極論として、「どんな機能も簡単な1行で記述できる」と「どんなコード変更も意図通りか0秒でわかる」という環境が仮に用意できたらエンジニアのクリエイティビティを最大限に発揮した最高のプロダクトができるところが想像できます。もちろんいずれも様々な意味で現実的ではありません。しかしながら究極の目標をここにおいて「なぜその究極の目標に今より近づけないのか？」を考えることには意味があります。サービスの成長とともにコードベースのサイズが大きくなると諦めたくなることも多くなりますが、プロダクト開発が永遠に終わらないように開発体験開発も永遠に終わらないものです。「今より良くできることはないか」を突き詰めた先に世界の一歩先を行く技術的優位性が勝ち取れると考えています。

とはいえ現実的に0秒が目標だと極論すぎてして現実にはどうかというと下のブログで夢を見すぎなくてよい現実的な数字が提案されています。手元のコード変更の validation は 5 ~ 15秒、全体の integration test は2時間位が理想だといっています。

WHAT 実際のチームでやること

より高速で安全な開発体験を優れた技術基盤で達成するという構想をここまでで示しました。ここからはより具体的に何をやっているのか/やっていくのかについて書きます。

チーム構成

プロダクトのグロースが一つの技術領域だけで達成されることがないように、開発環境も複数の技術領域、ときには非技術的な手法を用いて作っていきます。プロダクト開発に今足りていないものはなにか？という課題について日々プロダクトを作っているチームよりも良い答えを出すのは簡単ではありません。このため Developer eXperience Squad にはインフラ / バックエンド / フロントエンドそれぞれのスペシャリストが在籍しており、複数の領域に高い専門性を持つメンバーもいます。この高い技術力と複数領域の掛け合わせが基盤開発の原動力になります。

また、時には社内に知見を広めたり、チーム間の連携を増やしてあげることが解決策になることもあるので、プロダクトチーム全体に目を向けてコミュケーションをとっていくという活動も重要です。Wantedly の Developer eXperience Squad においては現時点ではこの部分の活動はまだ大きくありませんが、将来的には担うべき役割の一つだと感難えいるので、組織づくりに専門性を持つメンバーも必要になる未来もあり得ると考えています。

出張

Developer eXperience Squad のメンバーはプロダクトチームとは独立の基盤開発のプロジェクトを持つことが基本ですが3割程度の時間はプロダクトチームに短期的に所属することにしています。これを社内では出張と呼んでいます。これを行う目的はドッグフーディングとリソース配分調整の2点です。

一点目のドッグフーディングに関してはつまり自分たちが作った開発環境で実際にプロダクトを開発して見る経験が大事であるということです。開発環境をプロダクトだと思う気持ちがあれば、触ってみることでプロダクトチームが持っている実際のペインを肌で感じる機会を持つのは極めて自然です。Developer eXperience Squad 内で行う開発では特にUIや通知などのユーザーとのインタラクションが生まれる実装は少なくなるので、実際にやってみることが大事です。実際に触っていないと自分自身が自信を持って決断しづらくなることに加えて新しいものを作ったときの説得力も欠けてしまうので、非常に大事なステップだと考えています。

二点目は「投資に振りすぎない目がほしい」という気持ちの実現です。Developer eXperience Squad は将来投資を行うチームなので、(短期的には)直接的にプロダクトに良い影響を出す責任を持っていません。しかし当然ながらここで「Developer eXperience Squad のメンバーをプロダクトに配置するよりもトータルでメリットがある」ということが言える必要があるわけですが、これを示し続けるのは簡単ではありません。そこで Developer eXperience Squad のリソースを流動的に使えることで勝手にこのバランスが取れることを目論んでいます。プロダクト開発のリソースが不足する場合には Developer eXperience Squad のリソースを借りることができるようにしています。依頼があった場合は「プロダクトのリリース」と「基盤の改善」のどちらを優先するべきかを議論するので、将来投資が過剰/過小であればそこで気付けるということです。この仕組があることで「今作っている基盤は目の前のプロダクト開発と少なくとも同等の価値があるはずだ」という自信が持てるのでチームにとって重要な仕組みだと思っています。

実際にやっていること

Developer eXperience Squad 以外のチームが関わっているものも含まれますが、大きく手を出しているのは下のようなプロジェクトです。

Kubefork
マイクロサービス開発のために必要なコンポーネントのみをコピーする疑似クラスタコピーツールを作っているので日々新機能を導入しています。最近は PR を作るとその PR が deploy された Kubernetes クラスタの URL が勝手にはられるようになって便利になりました。

Feature Flag
任意のサーバーサイド/フロントエンドのロジックをブラウザから request local に書き換える開発用ツールです。新機能をユーザーに露出せずに開発していくのに利用しています。最近では React Hooks も書き換えられるようになって更に便利になりました。

社内ライブラリ開発
未完成のもの/他チームがオーナーのものも含めると、マイクロサービス共通ライブラリ / デザインシステム / 翻訳ライブラリ / テストツール などのライブラリ開発を行っています。もっと公開していく余裕がほしいなと思っているところです。

ツール導入
開発を助ける外部ツールの導入や、その利用を簡単にするツールチェイン作成などを行っています。最近では Percy や Speedcurve の周りを整えたりしています。

コードベースの更新
投資というよりは返済ですが、古くなってきたコードベースの刷新を行っています。最近では古い JS の TypeScript 化、Rails の 完全Webpack 化、デッドコード削除などを行いました。詳細は @qnighy の profile にある blog ポストを読むのが早いかなと思います。

Higher Order Derivatives - 高階微分

Developer eXperience Squad はざっくりいうと開発速度を上げていくチームですが、これはプロダクト価値の一階微分と考えることができます。ここで注目するべきことは、これを上げていくためにはただやるよりも先に自分たちの開発速度を上げるほうが最終的には早いこともあるという事実です。また、プロダクトチームが自分たちの生産性を自分たちで勝手に上げたくなるようになればプロダクト価値が大きくなる速度はどんどん速くなっていくと考えています。これは2,3階微分と考えることができます。この観点を忘れないために、今期のテーマは Higher Order Derivatives としています。

最後にこの考えを自分に強烈に植え付けた Derivative Clicker というゲームを紹介します。やってみると高階微分を改善したくなる気持ちが得られますが、一方で将来投資と目の前の問題のどっちにエネルギーを割くべきかを考えるのは難しいということも実感します。

このゲームが楽しいと思った方は多分 Developer eXperience Squad に向いているのでぜひ話を聞きに来てください。

最後に

色々と書いてきましたがまとめるとつまり Developer eXperience Squad とはより高速で安全なプロダクト開発を支えるために究極の技術基盤を追い求めるチームです。まだ究極の目標と足元でやっていることの乖離は依然として大きいですが、前回ブログでは具体的なプロジェクトではあまり夢のある内容が語られていないことを考えるとこの1年半でチームとして大きく成長したなと実感しています。自分が Wantedly に入社した理由は「技術に強みを持つ会社だ」と思ったことでした。この強みをより強固なものにして Wantedly には強い Developer eXperience Squad があることがプロダクト成長の原動力になったと語られることを目標に今後も成長を続けます。