はじめに
immedioというBtoB SaaSプロダクトのチームのエンジニアリングマネージャーを始めてから、もう１年半ほどになります。そろそろこのチームで私がやってきた事をまとめる頃合いかと思い、記事にしてみようと思います。
immedioという組織に興味がある方や、BtoBのセールステックのEM業に興味がある方の参考になれば幸いです。
People Management
定期的なエンジニアイベントの開催
隔月程度の頻度で、チームメンバー間の人間関係をなめらかにすることを主な目的としたイベントを企画しています。ただこれはimmedioチームに限った話ではないので、エンジニア全体での開催としています。
例えば、ペアプログラミングイベントでは、普段協働する機会の少ないメンバー同士がペアになり、互いの知識やアプローチを学び合う場を作っています。これによって、日常業務では見えなかった他メンバーの思考プロセスや技術的視点を共有でき、チーム全体の相互理解が深まっています。
ペアプロだけではなく、他にもいろいろな会を企画しています。
- The Model読書会
- 価値観共有会（価値観9ブロック）
- AIだけで業務を進める会
難しいのは、一回３時間ほど取るので、人間関係構築という目的の側面だけ押し出すと、どうしても業務に直結せず、参加するモチベーションになりづらい点です。なので業務に直結しそうで、かつみんなでワイワイできるテーマを選び、参加しやすくしています。
週１で1on1
1on1を週１でやるようにしています。この場の主な目的は、人間関係の構築とメンバーの成長支援です。成長支援をするのは、メンバーが成長を感じられることでより組織へのエンゲージメントが高まると考えているからです。平たくいうと、会社でもっと活躍してもらえるように、支援をしているということです。
具体的には、その週にうまくいったことやいかなかったことを言語化してもらい、それを各自で吸収し成長につなげられるよう促しています。また、適度に雑談を交えることで、業務だけでは見えないメンバーの個性や関心事を知る機会にもなっています。さらに、もしベロシティが落ちていることに気づいた場合は、この場で原因を探り、サポートの方法を一緒に考えます。
私は1on1の場を学びの機会と捉えています。そのためには自分の考えていることの言語化が必要不可欠ですし、言語化をすることで、自分の考えが整理され、糧になっていくと考えています。
Project Management
immedioチームでは、フロー効率を高めることを大事にしています。ただフロー効率だけが高くても、それが価値のあるものでなければ、時間を無駄にして終わるというリスクにも対処する必要があります。なので、どこに価値があるかを見極めつつ、最短でできるルート取りを常にするように心がけています。
スプリントゴールなし
スプリントゴールは設定していません。過去スプリントゴールを設定して運用していた組織にいたこともありました。ただ一般的にスプリントゴールを1つに絞ると、ゴールにそぐわないタスクに対してメンバーのモチベーションが生まれにくいと感じていました。そのため、あえて明確なゴールを定めず、各タスクの価値自体に焦点を当てる方針を取っています。これにより、どのようなタスクにも同等の重要性を感じてもらい、全体的な取り組みの質を維持することを目指しています。
例えば、immedioチームでは、「商談の質を上げる」「商談数を上げる」「使いやすい」という３つの軸での価値を定義して、それぞれのタスクがどの価値に紐づくのかをPdMにラベル付けしてもらっています。この３つの価値は、今までのimmedioの運営によって導出された価値で、元々はCSからフィードバックされてきたものをプロダクトチームでブラッシュアップしたものです。
リファインメントにおいてこれら３つの価値のどれに紐づくかを議論し、価値が薄いのであれば優先度を下げるようにしています。
これにより、一つ一つのタスクの価値が可視化され、かつ価値が期待されないタスクについては自然と優先度を下げられる仕組みを作ることができました。
デイリースクラムなし
また、デイリースクラムを実施しないという決断も行いました。デイリースクラムの本来の目的はスプリントゴールの達成に向けた調整ですが、ゴールを設定していない以上、検査する対象がありません。そうなると純粋な進捗管理と相談事の共有の場になりますが、進捗管理はマネージャーが知りたいもののメンバーにとっては共有するモチベーションが低い、相談事についてはGatherで日常的に話しかけられる環境が整っている、というメンバーからの声があり、不要と判断しました。
一日15分とはいえ、一週間で1時間以上となるミーティング時間を削減することで、メンバーの集中作業時間を確保しています。
ただ、そうは言っても、このデイリースクラムがないことによって頭を悩ませることもちょくちょくあります。例えば、1on1の場でタスク相談を受ける機会が多いことです。上で言っていることと矛盾するようですが、相談事はGatherでいつでも話しかけられるようにしているとはいえ、自分が予定で離れていたりして話しかけられず、定期的な場の流れで話したい時もあるようです。その結果1on1の時間が業務の相談の時間になる時もあるので（メンバーがそれで良いなら大丈夫ですが）、やっぱり「朝会」の存在意義はあるよなあ、と感じます。
レトロスペクティブはKPTではなくYWT
レトロスペクティブでは、YWT（やったこと・わかったこと・次やること）をベースに振り返りをしています。少し前まではKPTだったのですが、KPTだと、何かを知ったときやわかるようになったとき、それを共有することがしづらいと感じていました。どうしてもK(Keep)のニュアンスだと、何かをできるようになった、とか、事実ベースになってしまって、自分の思いを言葉にする機会がない、と感じることが多くありました。
もちろんKPTは優れたフォーマットで、レトロスペクティブといえばKPTというぐらいに浸透しているのは理解していますが、それでもやっぱり、学びを大切にしたい、という思いが強くありました。
YWTはそれをやる上ではわかりやすく、優れたフォーマットだと思い、現在はこちらを使用しています。YWTにしてからは、メンバーの意見もより表出するようになった実感があり、こちらにして良かったなと思っています。
認識の共有会
週１で、チームで認識を揃える会を開催しています。これは毎回自分が特定の議題を上げて、それについてみんなで議論することで、認識を合わせる事を目的としています。例えばチームで共有しているWorking Agreementsを全員で眺めたり、アジャイルの思想について勉強したり、です。
これをやろうと思ったのは、自分の考えとメンバーの考えの相違を感じることがたまにあったからです。例えばストーリーポイントの付け方にしても、ポイントが個人の技量を反映するべきかどうか、メンバー間でも曖昧な点がありました。この状態を放っておくのはリスクだと感じ、この会を開催するに至りました。
結果、開催して良かったと感じています。アジャイルについて話したときは、メンバー的も知らなかったこと多く、勉強になったというようなリアクションがありました。またデイリースクラムがない分、話す機会もないので、定期的に話せること自体が嬉しいです。
Platform Management
エンジニアの開発者体験をよくするためには、堅牢で効率的な開発基盤が不可欠です。immedioは本当にPlatform Mangementの歴史と言っても過言ではないぐらい、開発基盤の改善をプロダクト開発と並行して進めてきました。ここについては今までやってきたこと（成果）をベースにして話そうと思います。
GCEからCloud Run & Cloud Storageへ
immedioのプロダクトの歴史の話になりますが、ここは特にimmedioチームの中で頑張ってきた成果とも言えるので、長めに話します。
immedioは最初GCEインスタンスで立ち上がっていました。具体的には、概ね下記のように変遷しています。
- APIサーバー(GCE） & フロントエンド（GCE）
- APIサーバー（Cloud Run） & フロントエンド（Cloud Storage）
- APIサーバーとフロントエンドをまとめてCloudRunで管理
まずGCEからCloud Runへ移行したのは、インスタンス管理による内部構成のブラックボックス化とデプロイフローのしんどさです。例えばログの仕方を修正したいとなっても、ログを拾うAgentの設定がGCEの中にあり、どこにあるのか、どう変えれば良いかがわかりません。デプロイについても、コードのデプロイならまだオートメーションできますが、Webサーバーやそれが依存するライブラリ、OSバージョンの更新など、インフラに関わるデプロイはとてつもなく辛いです。コンテナ化（Cloud Run）したことで、それがなくなりました。またフロントエンドもCloud Storageで管理するようになり、業界でよく見かける直感的なインフラ構成になりました。
高いSLA要求
ただCloudRunとCloud Storage管理にすると、別の問題が出てきました。それは、フロントエンドとバックエンドのデプロイタイムラグによって、落ちることがあるという問題です。例えばAPI側で変更されたレスポンスに、フロントエンドが対応しておらず、落ちてしまうというようなことです。これぐらいは目を瞑るサービスもあるかとは思うのですが、immedioだと顧客サイトにタグを入れてもらう関係上、顧客サイトを止めることとなるので、非常に高いSLAが求められました。ビジネスサイドのメンバーとも話しましたが、ここで落ちるのは許容できないという判断となりました。
対応する方法はいろいろありました。例えばデプロイ時に、デプロイをすることによってタイムラグ問題が起きるかどうかを確認して、起きる場合は、後方互換性を担保してリリースするということでした。ただこれをやる場合はエンジニアが考えることが常に一つ増えるため、できれば仕組みで解決したいところでした。
そこでこれを解決するために、APIサーバーとフロントエンドをまとめて１つのCloudRunで管理するようにしました。１つのサーバーで管理して、デプロイするときにバチっと切り替えます。そうするとフロントエンドもバックエンドも全体が切り替わり、落ちる確率は非常に低くなります（それでも完全に落ちない訳ではないですが、確率は下がります）。
これによってエンジニアが考えることは増えず、ビジネスサイドのメンバーも満足できる結果となりました。
CI/CD環境の最適化
CI/CD環境の最適化も進め、mainブランチにマージされるとデプロイが即座に実行される仕組みとなっています。上述の仕組みもあって、いつでもリリースできる体制を整えています。
目的はフロー効率を高めるためで、PdMのOKがもらえ次第すぐにリリースをして、少しでも早く顧客にデリバリーできるようにしています。
Observabilityの導入
Observabilityの3本柱であるLog、Trace、Metricsを導入しました。
Log, MetricsについてはGoogle Cloudのネイティブの仕組みを利用しています。特にLog Explorerは個人的にとても使いやすく、ログ調査時に重宝しています。
TraceについてはOpen Telemetryを利用して、Honeycombで確認できるようにしてます。Google CloudのCloud Traceはかなり使いづらかったので、移行しました。Honeycombの技術選定については下記のsumirenさんの記事を参考にしています。とても参考になりました。
バックエンドアーキテクチャの刷新
インフラ方面ばかりですが、アプリケーション側も力を入れて技術負債を解消しています。
当初、API側のアーキテクチャには思想がなく、各々が好き勝手に作っていた状態でした。割と無法地帯だったと思われます。私が入社した当初も、ここはだいぶ辛いところでした。
CTOの方がここに特に課題感を感じ、本格的にバックエンドアーキテクチャの刷新が進みました。今のimmedioはライトなクリーンアーキテクチャという感じで作られています。
もちろん、「じゃあ明日からこのアーキテクチャでやってね」となったとしても、既存のコードの移行が終わらない限り、アーキテクチャの刷新はできません。古いコードが残ったままでは、その部分のメンテコストは大きいままですし、古いアーキテクチャと新しいアーキテクチャがあるために新規のエンジニアも混乱します。
なので、新アーキテクチャ移行を、プロダクト開発と並行して進めることになりました。とはいえすでに数百ファイルはあるコードを全て新アーキテクチャに移行するのは、膨大な時間を取ります。ただこれについては時間をかけて移行する価値があるとチームで判断しました。
具体的には、例えば「管理画面側のuser関連APIの移行」タスクを自分が切って、それをエンジニア（主に副業メンバー）にアサインするという形で行っています。
現在進行形なのは、まだ全ての移行作業が終わっていないからですね。もう１年以上、コツコツと移行作業をしており、現在の進捗は70%というところです。
ただこの甲斐あって、今のimmedioのAPI側のコードはとても書きやすいものになっています。開発者体験としては、自分が入社した当初とは比べ物になりません。とても快適です。
その他
このほか、immedioチームでは様々な技術改善をしてきています。ここには書ききれないので、主要なものを以下にまとめます。
- MySQL -> PostgreSQL移行
- RLS(Row Level Security)実装
- データ分析基盤（アナリティクス）の移行
- 旧ルーター移行
やっていること
Platform Managementとして継続的にやっていることも、こちらで話そうと思います。
テックバックログの運用
テックバックログとは、immedioのチームメンバーが、技術的に課題だと思っている事を挙げられるバックログで、通常のプロダクトバックログとは切り離されて考えられています。ここに上がっている議題を定期的に精査して、タスクとして上げます。優先度はプロダクトバックログ発のタスクよりは下がってしまうので、基本的には手が空いたタイミングでの着手となりますが、特に優先度を上げるべきと判断したものについては、プロダクトバックログ発のタスクより優先されることがあります。
例えば直近だと、入社してすぐのメンバーが、スタイリングがcss moduleとCSS in JSが混在しているのをわかりづらく思い、それを起票しました。チームの合意を経て、そのタスクはTo Doに移され、現在は少しずつ移行していっています。
Product Management
Product Managementはどちらかというとプロダクトマネージャー（PdM）の領域ですが、エンジニアリングマネージャーとして私も積極的に関わっています。特に注力したのは、仮説検証サイクルの構築です。
仮説検証サイクルを回すためのWicle
Wicleを導入してユーザーの行動分析ができる環境を整えました。
例えば、新機能Aをリリースした後、それが実際にユーザーにどのように使われているのか、期待通りの効果を生んでいるのかを定量的に分析できるようにしました。
これは、自分たちがリリースした機能が、どれだけ顧客に使われているのかを検証していくサイクルが必要だと感じたからです。どれだけフロー効率が高くとも、「1.そもそもリリースされたことが知られていない」「2.リリースされた機能の価値が伝わっていない」「3.リリースされた機能は、特に顧客が求めていたものではない」などの要因で、リリースした機能が使われないことがたまにありました。フィードバックがもらえず、プロダクトの進化が停滞するリスクや、要らない機能をメンテするコストは、なんとかして対応しないといけません。
Wicleが導入されたことにより、「作って終わり」ではなく、継続的に機能の有効性を検証し改善していくサイクルが確立されつつあります。
現在は、新機能リリース時の顧客への効果的な通知方法について、PdMと共に検討を進めています。ユーザーに新機能の存在と価値を適切に伝えることで、機能の活用率を高め、開発した価値を最大化することを目指しています。
ちなみにこのWicle、めちゃくちゃ使いやすく、最近触ったプロダクトの中では特にイチオシです。導入がとても簡単で、タグをHTMLに入れるだけです。それだけでユーザーがどのボタンをいつクリックしたのかを記録してくれます。例えば、新規機能にまつわるボタンが、どれだけクリックされたのかが簡単に集計できます。HTML要素にidの指定したりとかも必要ありません。
ユーザーサポートも充実しており、チャット上で連絡したら、夜にもかかわらず10分ほどで返信したのには驚きました。どんなサポート体制なんだ。。
まとめ
今回記事を書いていく中で、自分が下記を大事にしているのに改めて気づきました。
- Fail Fast
- 「早く失敗する」ことで学びを得るきっかけを作る
- 技術的側面においては、品質の問題に気づくきっかけ
- 人間的側面においては、成長のきっかけ
- プロダクト的側面においては、仮説検証のきっかけ
- 「早く失敗する」ことで学びを得るきっかけを作る
- 考える事をいかに少なくするか
- 考えることが多い状態が、集中を阻害し、フロー効率を阻害し、Fail Fastできなくしている
- 無駄な事を考えず、一つに集中できる状態を作りたい
- 学びの最大化
- 学びを得たとしても、本人や組織に還元できなければ意味がない
- そのための意識づくりと土台づくり
Discussion