どうもエンジニアリングマネージャーのkobaanです。

オフィスが湯島ということで、初詣は湯島天神に行ってきました！中高生の娘たち用に学業御守りを購入して手渡したら、若干訝しげな顔をしておりました・・・。勉学を頑張るのだ若人よ、これは中年からの警告だ。などとは言ってませんがそう言う思いで渡しています（笑）

エンジニアリングマネージャーとしてACES Meet事業で行ってきたこと

今回は、ACES Meet事業にて私が入社してから実施した取り組みと成果についてお話しできればと思っています。もちろんこれを当たり前に行っている組織も多分にあると思いますが、困っているマネジメントレイヤの方たちの少しでも助力になれば幸いです。

まず、背景とフォーカスしているポイントをご説明します。

小林が入社・選考当時の背景

これは私も聞いている限りになりますが、私が入社する1年ほど前（なので今からで言うと1.5年以上前）から利用者が増加していましたが、複数の障害が重なったこともあり開発計画が立たない状況まで陥ったことがあったとのことです。

ただし、その障壁を乗り越えるべく、事業責任者と当時のエンジニアリングマネージャーが開発・リリースプロセスを整備し、基盤を構築し、開発は安定的に行える状態にまで状態は回復したそうです。

また、開発チームの中に運用・保守に関する観点が根付くまで、教育目的も含めて多少効率が悪い開発になっていたとしても、安全にリリースを行うためのフローを整備することに注力していました。これらの一連の流れは今回の話の礎になっていますので、この事を頭に入れて読んでいただけると嬉しいです。

ここまで読んでいただいた段階で、結構改善してるんじゃないかと思われますが、それでも入社した当初は以下の課題が残っていました。

インシデントに対する強い緊張感
プロダクトの機能追加に対する過剰な慎重さ

入社後に感じたこと

入社前から開発に対する足腰の強さみたいなものは感じていましたが、入社後には開発に対するナイーブさや、品質重視によるチャレンジしにくい空気を強く感じました。

この空気感を変えることが私の最初のミッションだなと感じたことを当時を振り返って思い出します。

何にフォーカスしようとしたのか

まずは、SaaSのようなプロダクトの特性と、我々はPMFに向けてどう言った試合運びをすべきかと言うのを

の流れを汲みながら、プロダクト価値の考え方として以下のような整理をしていました。

（実はもっと幅広に考えていますが、今回は一部だけ抜粋させていただきました。また別記事でお話しできればと思っています。）

そこから目指す戦略を整理し、以下の2つの視点でチームの改善を行いました。

フィードバックサイクルを起点としたワーキングアグリーメントの策定と浸透
リリース頻度の短縮

これらの対応はエンジニアチームだけでなく、Biz（セールス、CSなど）のチームにも思想を共有し、うまく巻き込むことで組織全体の文化として根付かせることを目指しました。それは事業全体を支える文化であることが重要だと考えていたためです。

また、色々と検討していた中で、この２点にこだわった理由としては先述した通り、開発としての足腰が強かったので何か自分から手を加えるというよりも、エンジニアが自律して行動できるきっかけ作りであれば良い、それだけでもっと前に進めると考えたからです。

ワーキングアグリーメントの策定

心理的安全性を確保しながら、不確実性の高いソフトウェア開発を効率化するために、以下のような方針を整理しています。

HRT（Humility, Respect, Trust）
Feedback is Gift
Disagree and Commit

これらを含めた8つのワーキングアグリーメントを設定し、Weeklyで今週のフォーカスしたいアグリーメントを決めたり、振り返りの時に今週のアグリーメントを意識して行なったことなどを確認することで、徐々にチームに浸透させて行った結果、全員が無意識的に認知できるようになったと感じています。

リリース頻度

リリース頻度はDORAの４Keysでも謳われているように、開発生産性としてもプロダクトのフィードバックサイクルを指し示す指標としても重要なファクターです。

ACES MeetはAIによる解析機能などもありますが、表側はシンプルなWebアプリケーションでありながら、２週間ごとの夜間リリースという極力リスクヘッジしたリリースプロセスとなっていました。

まずは毎週リリース、徐々に日次リリースにしましょう！という方針をチームに示したところ、毎週夜間は流石にしんどいですと言う意見が出てきたのを覚えています。（余談ですが実は最近新しいワザを覚えまして、帰納的に考えるのではなく演繹的に考えるというテクを使えるようになっていたので、それを今回は使いましたw）

じゃあお昼リリースにできるにはどうしたら良い？と言う語りかけをしたところ、「難しいですね」じゃなく「なるほど、どう実現しましょうね・・・！一緒に考えましょう！」という前向きな思考になっていただけました。

もちろん前述したワーキングアグリーメントのおかげもあるかもしれませんが、大きくはACES Meetのエンジニアが素直かつ前向きに考えられる性質があり、これがチームの強みだからこそ噛み合って実現できたのだと思っています。

今では、むしろ週次リリースに満足せず、日次リリースに向けて更なる基盤検討を進めているところです。

結果どうだったか

何かツールを入れたり、具体的なプラクティスを導入したりではなく、割と抽象度の高いメンバーを応援するような方針を打ち出すことで様々な施策が生まれた結果、7-9月と、今回の方針が効き始めた10-12月とで比較したときの改善成果としてエンジニアの人数はほぼ変化なしに対して、PR数が1.5倍になりました。

特に、エンジニアがプロダクトに積極的にコミットする雰囲気が醸成され、チーム全体のパフォーマンスが向上したと思っており、定性であってもエンジニアが生き生きとしている組織であることが一番の成果だったなと思っていますし、自分自身が嬉しかったなと思えているところです。

実際PR数に関しては過去記事にもあるように、フィードバックサイクルを重要視する文化を土壌として複数のエンジニアからの自律的な施策が産んだ成果であると思っています。

tech.acesinc.co.jp tech.acesinc.co.jp tech.acesinc.co.jp

また冒頭に述べたように、開発の基礎力があることで取り組みや施策がスムーズに進んだことは間違いなく、そこは私だけの成果ではないと思っています。