「開発者体験（通称「DX：Developer eXperience」）」というキーワードへの注目度が高まっている。

「開発者にとって働きやすい環境や組織文化があり、気持ちよく開発や保守ができるかどうか」を問う言葉だが、開発者の採用や組織づくりの難易度が高まる中で、その改善に取り組む企業が増加しているのだ。

社内に散らばる経営データを一元化する経営管理クラウド「Loglass」を展開し、2022年にはシリーズAラウンドで総額17億円の調達にも成功した株式会社ログラス。

同社では、開発組織が抱える生産性にまつわる課題を解決するための専任部隊「Honeybeeチーム」を2022年11月に設立。創業当時から根付いていた、「LTV first（長期的思考で物事を捉え、顧客に提供する生涯価値を最大化すること）のために、ボトムアップに必要な改善を行い続ける」という文化をさらに進化させている。

同チームが設立直後に掲げたのは、「5年後も高速に高品質な開発ができるための土台を作る」という目標。その実現のために、開発プロセスの整備や自動化、技術負債への取り組みのアップデート、メトリクスの整理など、組織内のボトルネックを発見しては改善することを繰り返し行ったという。

結果として、プロダクト開発チームが開発に集中できる環境が新たな「当たり前」となり、現在はさらに「開発を通じて顧客価値をどれだけ増大させるか」という問いによりしっかりと向き合おうとしている。

今回は、Honeybeeチームのマネージャーである松岡 幸一郎さんと、開発生産性を中心とした改善に取り組む加賀谷 諒さんに、ログラス社における開発者体験への考え方や、具体的な取り組みについて、詳しくお話を伺った。

開発に向き合う上での「ノイズ」はすべて、開発者体験に影響する

加賀谷　私は新卒でヤフー株式会社に入社し、ID連携やプラットフォーム開発に携わりました。その後2022年4月にログラスに入社し、半年間プロダクト開発に関わった後、11月に誕生した組織の横断課題の解決に取り組む「Honeybeeチーム」に異動しました。

現状はHoneybeeチームの中で、開発組織の課題や技術負債といった、日々のプロダクト開発の中ではなかなか手が回らない課題の改善に取り組んでいます。

▼加賀谷 諒さん

松岡　私は日本アイ・ビー・エムとビズリーチを経て、2020年9月にログラスに入りました。当時はまだ正社員のエンジニアは5名ほど、ビジネスサイドは2名ほどの組織でしたね。

入社後は、まずドメイン駆動設計やスクラム開発の導入を行い、その後は組織が拡大する中で、それらをどうスケールさせるかに取り組んできました。そして2022年11月からは、加賀谷さんと同じHoneybeeチームのマネージャーを務めています。

加賀谷　Honeybeeチームが現状行っている活動は、昨今では「開発者体験の向上」という言葉で表現されることも多いかと思います。

ただ、開発者体験という言葉に対して、ログラスとして統一した定義は持っていませんし、「開発者体験を上げる」ことを目標にした活動があるわけではありません。

実際には、「開発の中でこのリードタイムが長いから短くできるように頑張ろう」「なるべく作業は自動化して、本質的な開発に時間を割けるようにしよう」といった目的のために、ひとつひとつ泥臭く取り組んでいます。

ただ、「開発者体験」という言葉について考えてみると、「エンジニアがいかに効率的に、本質的な開発に向き合えるかどうか」にすべてが内包されると思っています。

例えば「コードが汚い」ということは、開発者体験におけるわかりやすい課題のひとつですよね。ですが他にも、アーキテクチャや文化、開発プロセス、評価制度といった、いわば本質的なソフトエンジニアリングを行うにあたって「ノイズ」となりえるようなものはすべて、開発者体験に影響すると考えています。

そう考えると、我々の取り組みを総称した時に「開発者体験を上げる」という言葉にまとめることもできるのかなと感じています。

「LTV first」な開発を目指した結果、横断課題を扱うチームが誕生

加賀谷　ログラスではHoneybeeチームができる以前から、ボトムアップで開発組織をより良くする取り組みを重要視してきました。専門で取り組むチームがなくとも、それこそ創業当時から文化として大切にしてきたと聞いています。

私は、その根底にはログラスが大切にしている「LTV first」というバリューが根強くあると思っています。

▼ログラス社の三つのバリュー（出典：株式会社ログラス会社紹介資料）

加賀谷　「LTV first」自体は、SaaSのビジネスでよく使われるLTV（顧客生涯価値）を最大化することを第一にするという意味です。ログラスでは初期の頃からこのバリューが根付いており、面倒だと思ってもきちんと長期的に価値があることをしよう、という考えが浸透していました。

松岡　ログラス初期のエンジニアメンバーは、以前に所属していた組織で技術負債やコード品質の悪化などに苦しめられた経験から、「ログラスではそうならないようにしよう」という思いを強く持っていました。

その結果、「以前はできなかったけれど、ここではやってやる」といった感じで、保守性の高いコードにこだわり続けたり、ライブラリのアップデートを定期的に行ったりする文化が、この組織には長く根付いていると思います。

ただ、冒頭で加賀谷さんが言っていたように、「開発者体験を上げよう」と考えていたわけではなく、どちらかというと、本当にLTVを高める開発を目指した結果ついてきたものなんですよね。

▼松岡 幸一郎さん

松岡　Honeybeeチームが生まれたのも、この「LTV firstをボトムアップで実行する」文化の進化の過程だと思っています。この文化があったことで、ボトムアップで行う改善がとても増えてしまったので、それを組織全体で効率化するための体制を作ったという感覚です。

加賀谷　実際、チームの数が増えていく中で出てくるさまざまな課題に対して、きちんと工数をかけて改善することが徐々に難しくなってきていました。そこで、今後のプロダクトや組織スケールに向き合い、横断課題にフォーカスする組織としてHoneybeeチームを作ったという背景があると思っています。

ボトルネックを特定し、改善。その繰り返しが目に見える成果を生んだ

松岡　Honeybeeチームの具体的な活動についてお話しすると、まずチームのObjective（※OKRというフレームワークで表現される、いわゆるチーム目標）として、最初に「5年後も高速に高品質な開発ができるための土台を作る」という言葉を掲げていました。

これは、チームに所属している3人がそれぞれ「QA」「インフラ・セキュリティ」「開発者の生産性」と担当領域が異なる中で、それを結びつけるとどこにつながるかな、という話をした上で決めたものです。

加賀谷　その中で、私個人の活動としてチームができて最初に取り組んだのが、リリース周りの改善でした。シンプルに「リリースが辛い、面倒だ」という声がよく挙がっていたので、まずはそこにフォーカスしてプロセスの自動化やフロー整備を行った形です。

基本的には、このようにボトルネックを特定して、改善する。するとまた次のボトルネックが出てくるので、それに取り組む…ということを繰り返し行ってきました。

松岡　加賀谷さんと二人で、いわゆる「制約理論」のような考え方は良いねという話をしていて。

制約理論とは、例えば工場のラインに直列なプロセスがあったときに、ある工程では部品を25個作れるけれど、次の工程では5個しか作れない場合、ライン全体として作れる部品数は5個になってしまう。であれば、ライン全体の制約になっている5個の部分にフォーカスして改善しよう、という考え方です。

※制約理論：Theory of Constraints。サプライチェーンを最適化する手法で、工程のボトルネックとなる工程に注目しスループットを最大化するための考え方。

ひとつの制約がクリアになると、また違う箇所が制約になるので、そこに対して手を打つ。この、価値を出す上でのボトルネックを解消していく動きを加賀谷さんがやってきてくれました。

例えば開発生産性を示すメトリクスであるFour Keys（※）も、その時の制約を示すセンサーと考えて、フォーカスすべき箇所を発見するために活用する。こうした課題への向き合い方は、チームの活動の中で得た発見だったかなと思っています。

※Four Keys：​​Googleが提唱した開発パフォーマンスの指標。詳しくはこちら

加賀谷　メトリクスということでは、チームができたタイミングと同じ時期で「Findy Team+」を契約し、開発チームのパフォーマンスを可視化しました。

例えばリリース周りや、ビルドやレビューの時間がFindy Team+上で明らかになるので、その数値を見ながら活動していましたね。結果的に、3ヶ月でプルリクエストの作成からレビュー完了までの時間が1/4に短縮されました。

開発側とのコミュニケーションを密に、責務をしっかり切り分ける

加賀谷　他にも、ログラスとして以前から行っていた取り組みについても、現状のフェーズに合わせた見直しやアップデートを行いました。

例えば技術負債の返済については、以前より各チームから一人ずつ担当が選出される形の検討会という仕組みを運用しており、全体の2割の工数を確保していました。

ただチームが増えてくると、どうしても各チーム固有の状況をキャッチアップして全員で議論するのも難しくなってきたので、参加する人数を絞った上で、各チームで自律的に改善できる文化を作ることを我々がサポートできるようにしました。

また、週次で行っていたライブラリのアップデートも、毎週全員の時間を確保するのがもったいなくなってきたので、隔週で済むような仕組みに変えました。

加賀谷　このようなHoneybeeチームの活動の結果として、プロダクト開発側とうまく責務を分担できるようになったので、開発により集中できる体制が作れたという声ももらっています。

松岡　これまでの活動を振り返ると、大事だったことは2点あるかなと思っています。

まずは、プロダクト開発チームとのコミュニケーションを密にしてしっかりと巻き込むこと。というのも、私のこれまでの経験では、横串で改善を担うようなチームを作っても、そのチームの中に閉じて決めたことを開発側に落としていくようなケースも多かったなと。

その反面、Honeybeeチームでは、設立当初から週替わりで各チームのスクラムイベントに入っていくなど、とても密に連携をとっていました。

次に、意識的に責務を切り分けること。例えば「プロダクト開発に集中するため」と言って、技術負債への投資やライブラリのアップデートなどをすべてこちら側で持ってしまうと、どうしても回らないんですよね。

ですので、「これはHoneybeeチームが直接改善するもの」「これはそれぞれのチームが責任と権限を持って改善するもの」と切り分けていくようにしていました。「オーナー決めてこ」というキャッチフレーズをよく使うのですが、そのようにコミュニケーションを取りながら責任を明確にし、権限委譲していったことが、うまくいった要因のひとつかなと思っています。

制約を解消すると、当たり前がアップデートされ、次の世界が見える

加賀谷 　今後は、引き続き開発の生産性も課題としてありつつも、もう少し次のレベルで「開発を通じて顧客価値をどれだけ増大させるか」にフォーカスしたいと思っています。

例えば開発者の生産性を測るとしても、Four Keysのような指標がありますよね。同様に、顧客への価値提供についても、ARRやビジネスの成果指標をうまく活用できるのではないかという話になり、整理を始めています。

正直、顧客価値と開発をどう結びつけるかはとても難しい問いですし、私の頭の中にもまだ具体的なアイディアがあるわけではありません。でも、逆に言うとこうした領域に手が出せるようになってきたことがひとつの成果だと思っているので、ポジティブに捉えてまたイチから頑張りたいですね。

松岡　先ほども少しお話しした制約理論のような形で物事を考えていくと、「制約を解消すると当たり前がアップデートされていく」という感覚があって、個人的にそれが好きなんです。

松岡　例えば今のチームでいうと、最初の四半期では組織を横串で改善して、各チームが開発に集中できる状態を作ることに頭を使っていました。

それが改善された結果、状況や認識が変わり、「そもそも我々は何を作っている（何の価値を提供している）んだっけ？」という問いに向き合っていくような状態になったと。つまりひとつの制約を払ったことで、当たり前がアップデートされて、次のモノが見えるようになったんだなと思っています。

これは、開発者体験にも通ずる話だと思っていて。例えば開発環境が色々と整っても、評価制度がひどかったら、みんなそこへの不満がたまって価値発揮に向き合うどころではなくなりますよね。

評価制度はひとつの例ですが、他にもコードの汚さだったり、チーム間の仲が悪かったり、そういったさまざまなことが制約になりうる。それをしっかりと取り払っていくことが、より良い開発者体験の実現に近づくことだと思っています。（了）