はじめに
こんにちは。株式会社immedioのimmedioチームでエンジニアリングマネージャー（EM）をしています。
弊社では、商談獲得自動化サービス「immedio（イメディオ）」を提供しています。問い合わせから5分以内にアプローチできれば商談化率は8倍に向上するという業界課題に対し、2024年7月には3.5億円のシリーズA調達を実施するなど、おかげさまで急成長を続けています。
プロダクトのエンジニアをやっていると顧客からよく聞くフィードバックがあるように思います。たとえば「開発スピードが早い」「UIが使いやすい」「機能が豊富」などなど。
immedioにおいては 「開発スピードが早い」 というのはめちゃくちゃフィードバックとしてもらいます（ちなみに前職は「UIが使いやすい」でした）。
下記記事はimmedioではなくimmedio Boxという別プロダクトの導入事例ですが、すでに導入いただいていたimmedioの開発スピードを信頼して、immedio Boxも導入していただいた事例です。
今回は、EM視点から見た、なぜimmedioチームの開発が速いのかについて詳しく書いてみたいと思います。組織づくりや開発体制に興味のある方の参考になれば幸いです。
「最速で『こと』を成す」Values文化の浸透
全社的なスピード重視の価値観
弊社には「最速で『こと』を成す」というValueがあります。これは単なるお飾りではなく、全社的に早いことに価値を置いており、組織全体がその価値観に沿って行動しています。そして、それに沿って動くことで周りからも賛美される文化が根付いています。
元も子もないのですが、おそらくこれが最も効いている要因かと思います。 組織文化として定めているならそりゃそうだと思うかもですが、ただ単純に定めているだけではなく、Valueが根付くように全社的に工夫もしているので、その紹介もできればと思います。
価値観を強化する仕組み
Value Star表彰制度では、半期に1回、Valueを体現したメンバーがValue Starとして表彰されます。開発チームからも受賞者が出ており、スピードを重視した行動が組織全体で称賛される仕組みになっています。
また、Collaを利用したSlackのキャンディ制度として、Valueと紐付けた称賛制度があります。日常的に「素早い対応ありがとう！」といった感じでキャンディが贈られ、この即座のフィードバック機能により、「最速で『こと』を成す」文化が継続的に強化されています。
キャンディの例
「価値ラベル」を使い、必要なものに絞って開発
地に足のついた議論を可能にする仕組み
弊社チームの開発時は、PdMが全てのタスクに「価値ラベル」と言われるものを付与します。これはimmedioのコアバリューを言語化したもので、現状は3種類あります。
「商談数が増える」「商談の質が上がる」「誰にでも使いやすい」の3つです。それらが4段階のレベルで分けられています。下記は前クオーターの成果として発表したものです。まだ3段階でしか分けられてなく、かつ途中から運用し始めたので、完全には実態は反映できていませんが、参考までに。
商談数(I)、商談の質(Q)、使いやすさ(D)
価値ラベルがもたらす効果
この仕組みによって、以下の効果が得られています：
- タスクにあげる際に、PdMが改めてそのタスクがどれくらい必要なのかを吟味する時間が必ずできる
- メンバーが、そのタスクにどれくらいの価値があるのかがなんとなくわかる
これが明示的になったことによって、必然的に、本当に必要のあるものに開発が絞られ、最小のパワーで最大の成果を出せる体制ができてきたと感じます。
これにより、開発チーム全体が「なぜこれを作るのか」「どれくらい重要なのか」を共通認識として持てるようになります。結果的に、無駄な工数を削減し、本当に顧客価値につながる開発に集中できています。
また、エンジニアにとっても、自分が取り組んでいるタスクの価値が明確になることで、モチベーションの向上にもつながっていると感じています。
価値ラベル導入の背景
元々は「この機能は本当に必要なのか」というところの議論が、ステークホルダー間で地に足のついていない議論となることがちょくちょくありました。「結局これはどれくらい必要とされていて、他のタスクとはどれくらい違うのだろう」というのがわからないところが課題としてありました。
タスクについての「価値」をステークホルダーに考えさせ、それを自分たちが納得できる仕組みが欲しいと感じ、この価値ラベルという仕組みに行き着きました。
このラベルの選定にあたってはPdMだけでなくCSとも協力し、顧客が実際にimmedioに感じていただいているフィードバックをもとに作成しました。そのため、実態に沿ったラベルの選定ができました。
運用をしていて、ラベルの根拠をPdMに問うことを忘れてしまっていたり、まだまだこのラベルを使いこなせてない時を感じる時もあるのですが、上記のように良い効果が得られたので、導入してとても良かったなと思います。
フロー効率を重視したチーム体制
一人のエンジニアが全部やる
前提として、弊社の採用は「フルスタックエンジニア」であって、つまりタスクに必要なことは一気通貫で一人のエンジニアがやることになっています。なので特定のタスクをやる際、フロントエンドやサーバーサイドなどで区分けしたりはしていません。
それぞれの領域で分かれていると、それぞれの専門性を深く掘り下げることができ、高いレベルで品質が考慮されていくとは思うのですが、あえてそれはせずに、一人のエンジニアが全て行うことで、一つのタスクをデリバリーする過程におけるコミュニケーションのラグを減らしています。
集中状態を阻害しないこと
私たちのチームはフロー効率を重視した働き方をしています。一つのタスクを終わらせるのに障害となる要素は極力排除するように努力しています。
MTGの最小化について、私はMTGを極力減らして、作業できる時間をできる限り確保するようにしています。この方針により、エンジニアが「作る時間」に最大限集中できる環境を実現しています。
問い合わせ対応の集約として、CS職からの問い合わせは基本全て私が受けて対応しています。そのため、通常メンバーには差し込み作業は発生しません。
実は、弊社においては毎日かなりの量の問い合わせが来ます。最近では、一日に10件来たこともあります。一つ一つの問い合わせも、慣れてないと原因調査に時間がかかるものが多く、問い合わせの難易度・量ともにとてもハイレベルです。
直近数ヶ月の問い合わせ件数。週10件以上は最低ある状態
これらの対応は、全て私が壁となってメンバーへの差し込みを防いでいます。とはいえこの点についてはすごく課題に感じており、そもそもの問い合わせ量を減らすため、ヘルプサイトの移行プロジェクトを今は進めています。
障害対応の集約では、アラート対応やバグ対応も全部私がやっています。これもメンバーに作業に集中してもらえる環境を作るためです。
流石に私がお休みの日だったりすると代わりに対応してもらっていますが、通常はメンバーに差し込みタスクは発生しません。
なぜここまでするのかというと、私自身が差し込みタスクがすごく嫌だからです。
例えば、アプリケーションのバグ調査で、ここがこうなって、こうなるから、ここがこう動く、という風にコードを解読し、ライブラリの仕様も把握し、コードの奥深くまで潜り込んでいる時に、突如Slackでメンションされたりするのは、ゲームがすごくいいところなのにインターホンを鳴らされて中断させられるようなもので、すごくストレスに感じてしまいます。
だからこそ、作業に必要のないものは極力気にしなくて良いように心がけて環境づくりをしています。
最速デリバリーを実現する自動化体制
週末や休日以外はいつでもリリース可能
組織によっては週一の決められた時間にデプロイというような仕組みにしているところもあると思いますが、弊社は週末を除いては、レビューやPdMチェックが終わったら、基本いつでもリリースして良いようにしています。リーダーへの確認も不要です。具体的には、mainブランチに開発ブランチがマージされたら、自動でデプロイが走るようになっているので、作業したメンバーがやることはPRのマージボタンを押すだけです。
このような仕組みにしているのは、最速で顧客に価値を届けることにこだわっているからです。いち早くリリースして顧客からフィードバックをもらえるようにすることで、いち早くそのフィードバックを取り入れた改善ができるようになります。このスピードこそが弊社のValueですし、またアジャイルの基礎だと思っています。
内部品質改善の組織的取り組み
毎スプリントでの技術負債対応
プロダクトの内部品質（=技術負債）に対しては、積極的に改善を進められる体制を作っています。内部品質を高めることで開発スピードが上がるというのは、プロダクトのエンジニアであれば実感として理解していただけると思います。
具体的な体制としては、毎スプリントごとにエンジニア側で起票したタスクをスプリントに上げる定例を行っています。例えばReactのバージョンを上げたりが典型例です。
このようにしてあげられた技術負債は、通常のプロダクト開発と並行して行われます。基本的にプロダクト開発の優先度の方が高いですが、並行してうまく進められるよう、タスクのアサインは私が調整しています。
大規模アーキテクチャ移行の継続的実行
より大きな技術負債の解消の代表例として、弊社のAPIのアーキテクチャの移行が挙げられます。これはもう2年前に始まり、そこから地道に進めているものです。
元々は弊社のAPIの実装において、アーキテクチャも何もない状態で、各々が好きに実装しているカウボーイコーディング的な状態でした。どこに何が実装されているのかもよくわからないし使いづらいという状態で、コーディングするにはあまりにも辛い状態でしたが、ここに課題感を感じた弊社CTOが改善を提案し、チーム全体でそれを地道に進めてきました。
現状は80%程度完了しており、もう間もなく完全移行というところです。この継続的な改善により、開発効率は大幅に向上しています。
私としては、最初から技術負債のない完璧なコードはないと思っており、大事なのは改善していける姿勢や体制だと思っています。その体制があるからこそ、今の開発スピードにつながっているのかなと考えています。
まとめ
特に私が好きなのは、「価値ラベル」による価値駆動開発です。「商談数が増える」「商談の質が上がる」「誰にでも使いやすい」という3つのコアバリューを4段階で評価し、全てのタスクに付与することで、本当に必要なものに絞って開発を進めています。これにより、PdMは改めてタスクの必要性を吟味し、エンジニアはそのタスクの価値を理解して取り組むことができています。
また特に私が大事にしたいと思っているのは、エンジニアが最も価値を発揮する「深い集中状態」を守る仕組みです。差し込みタスクをできる限り排除し、MTGを最小化し、エンジニアが「作ること」に専念できる環境を提供しています。この「開発者ファースト」な作りが、弊社の開発スピードの根幹にあると言えるかもです。
Discussion