こんにちは！
ourly株式会社 執行役員CTO(@tigers_loveng)の相澤です。
年度が変わり、新しい期が始まりましたね！
弊社は、無事に、3期の目標としていたARRの数字を達成することができ、清々しい気持ちで4期目を迎えることができました。
チームとしても、3期は色々な挑戦ができ、またどれも良い結果に結びついた実感があります。
期初に書いた以下の記事で、3期のテーマを「『開発』チームから『プロダクト』チームへのシンカ」としていました。（去年の今頃はまだ肩書きがEMだったな...）
詳しくは記事を見ていただければ嬉しいですが、ざっくりいうとチームの関心領域と影響範囲を「開発」という事業の中の一作業工程から、「プロダクト」そのものに広げようという意図でのテーマ設定でした。
宣言した以上はきちんと回収せねば、ということで3期どういうことにチャレンジし、今どうなっているのかをまとめたので最後まで読んでいただければ嬉しいです🥺
3期取り組んだこと
3期チャンレンジすることとして、記事の中では以下の図を用いて紹介しました。
主に3つのカテゴリで、4つの施策を実行したのでそれぞれの中身を紹介していきます。
開発フロー全体の見直しと改善
期初時点で、開発フローはPOとエンジニアに閉じたものになっていました。
スクラム開発と名乗って、スクラムイベント(デイリースクラム/スプリントレビュー/スプリントレトロスペクティブ/スプリントリファインメント/スプリントプランニング)を行っていましたが、いわゆるスクラムチームしか介在せず、単純にスプリント期間(1週間)ごとになんとなくなサイクルが回っているだけの状態でした。
顕在化した問題が起きていた訳ではないですが、目標とする「付加価値生産性が高いチーム」になるためには、この開発フローを見直し、改善することが必須だったため、色々と変更点を加えていきました。
全てを列挙して背景や理由を説明していくと長くなりすぎるので特に効果的だったと感じる内容を3つほど紹介します。
スプリント期間を1週間から2週間にする
期初時点ではスプリント期間を1週間で回していました。
ですが、スプリントゴールが達成できなかったり、リリースできる単位でそもそもスプリントゴールが設定できなかったりすることがしばしばありました。
1週間(=5営業日)のうちスクラムイベントで1日は作業ができない日があるため、実質4営業日分のスプリントゴールとなります。
我々はスタートアップということもあり、メインの開発業務以外にも全社的なタスクやMTG、面談／面接などサブタスクが必ずスプリント中に発生しており、その結果作業工数が十分に担保できないままスプリント最終日を迎えてしまうことがありました。
もちろんスプリントゴールの決め方やタスク分解の粒度に問題があった可能性はありますが、当時の状況ではチームの価値提供サイクルとスプリントサイクルがマッチしていないという結論に至りました。
特に、我々の事業フェーズではプロダクトに足りていない機能やアップセルを狙うための新機能の開発がメインであり、それらの機能のリリース単位を1週間単位まで小さくすることがとても難しいというのが上記結論に至った理由です。
単純に改善の機会が半分になる、安易にスプリント期間を伸ばすことはアンチパターンなどの理由で踏み切れていなかったのですが、1週間にこだわる理由もなかったので一旦2週間にして良し悪しを判断することにしました。
結果的には2週間にしたことと、3点目の提供価値ベースでのスプリントゴールを設定するようにしたことで、毎スプリントでリリース(フィーチャーフラグを用いた限定リリースも含む)が可能になりました。
今振り返ると2週間スプリントがちょうど良いように感じています。
スプリントレビューにCSメンバーも参加してもらう
POとエンジニアだけでなく、実際に導入後に使っていただいている顧客に一番近いところにいるCS(カスタマーサクセス)のメンバーにもスプリントレビューに参加してもらうようにしました。
それまでのスプリントレビューはいわゆる進捗共有的な側面が強かったため、わざわざCSメンバーの貴重な時間を使ってまで参加してもらう価値のあるMTGにはなっていませんでした。
チーム全体でプロダクトの解像度をあげるために、1次情報を得ることと、得た情報をもとにディスカッションすることが重要だと考え、CSメンバーにも参加してもらうようお願いしたのです。
スプリントレビューの時間を「プロダクトの最新情報を共有し、プロダクト価値を高めるためにディスカッションする時間」と定義し、アジェンダも以下のように変更しました。
- スプリント成果物レビュー
- プロダクト利活用指標(記事PV数やWeeklyActiveUser数など)の共有
- スプリント内で起きたエラーやシステム負荷の共有
- 新規機能のアイデア/今後のプロダクト戦略など未来の話
スプリントゴールをタスクベースではなく提供価値ベースで設定する
3期途中から、スプリントゴールを提供価値(=ストーリー)ベースで設定するようにしました。
新機能開発時、まず最初に全体的にタスクを洗い出し、それぞれを見積もってからスケジュール(ガントチャート)を作成するというウォーターフォール的アプローチでプロジェクトを進めていました。
そのため、スプリントサイクルとプロジェクトのマイルストーンがそれぞれ別々に管理されることになり、必然的にスプリントゴールは「〇〇APIを実装する」「〇〇画面のxxコンポーネントを実装する」などのタスク単位での設定になりがちでした。
ですが、それだと全てのタスクが完了されなければリリースを行うことができないため、せっかくPRサイクルタイムは縮まっているのに提供価値を増やすことができず、モヤモヤしていました。
そこで機能をストーリーに分割し、そのストーリーをスプリントゴールに設定するようにしました。
狙っていたわけではないですが、ストーリーベースでゴール設定すると不確実性への対処がしやすくなったように感じます。
特に、予期していないことが起きた時にストーリーの中のどの部分は削ってどこまでを完了させようという会話をチームでしやすくなりました。
責務の明確化と権限移譲
今までは基本的に僕かテックリードのどちらかがミッションを持って推進し、メンバーには手伝ってもらうという形式で進めることが多かったのですが、メンバーにもチーム観点でのミッションを持ってもらうようにしました。
具体的には、
- 開発生産性向上
- スキルアップ
の2つの領域のミッションを各メンバーに推進役を担ってもらうようにしました。
開発生産性向上については、2期に振り返りの型化や文化的な基盤作りができたので、そこから更なる改善を行ってもらうことをお願いしました。
そしてスキルアップについては、PRレビューなどの通常業務内でのOJT以外での施策の立案と実行をお願いしました。
結果としての達成可否は期末の評価には使わず、プロセスや取り組む姿勢、推進力を評価するという前提をきちんと伝えた上で、両方とも期末時点での理想状態をトップダウンでメンバーに下ろし、プロセスは任せる形で行いました。
開発生産性向上の取り組みについてはメンバーがテックブログの記事で書いてくれているのでそちらを読んでいただければ幸いです。
スキルアップの取り組みでは主に以下の施策をメンバーが考えて提案、実行してくれました。
- テックブログの開設
- 僕 or テックリードとのペアプロ
- プロダクトで使用している技術を僕とテックリードで解説する勉強会
- 勉強会の様子を録画し、後で見返すことができるようにした
- AWS SAA取得のための相談会
- FEの単体テストについて、書籍の輪読会
フィーチャーフラグの導入
フィーチャーフラグの導入に関しては、以前テックブログの記事でまとめたのでそちらを読んでいただければと思います！
ハード／ソフトスキルのボトムアップ & トップラインを伸ばす
ボトムアップでのスキルアップは、ミッションとしてメンバーに推進してもらったことがそのままやったことになります。
トップラインを伸ばす方は、主にはセキュリティと生成AI活用の面で僕とテックリードが推進役となり、組織内になかった知見やノウハウを蓄積しました。
セキュリティの面では、大企業などセキュリティ要件が厳しい企業向けの対策として以下の施策を社外の方の力も借りながら実行しました。
- AWS Security Hubの有効化
- AWS Guard Dutyの有効化
- IDS/IPSの導入
- ストレージ、サーバーのマルウェア対策
- 不正なアクティビティの検知
- AWS managed rule groupsの有効化
- ...etc
- IDS/IPSの導入
生成AI活用では、僕の業務時間の一部を生成AIのキャッチアップと実験の時間として確保し、実験結果を元に業務効率化やプロダクトに組み込むための可能性検証などを行いました。
例を出すと
- v0とChatGPTでLP生成をエンジニアが介在せずにインハウスで行えるかどうか
- Devinを導入し、活用することで1人あたりの生産性を向上できるかどうか
- プロダクトに溜まった分析データをChatGPTで分析して価値のある示唆を得られるかどうか
この施策で得た知見はテックブログの記事に書きましたが、すでに情報が古くなってしまっているものもあるため、参考にしていただく際にはご注意ください（生成AIの進化が早すぎる...！）
取り組んだ結果どうなったのか
元々どうなれば「プロダクトチームにシンカしたと言えるか」を定量的に置いていたわけではないですが、想定していたプロダクトチーム(としての動き)にはなっているのではないかと考えています。
実際に1年間で何が変わったのかを定量と定性でざっくりまとめてみました。
定量
| 指標 | 2期 | 3期 |
|---|---|---|
| サイクルタイム | 95.1h | 25.6h |
| デプロイ頻度 | 88回 | 164回 |
| リリース頻度 | 14回 | 15回 |
| テックブログ記事執筆数 | ー | 27記事 |
| 社外イベント登壇数 | ー | 14回 |
また、開発生産性向上の取り組みを評価していただき、Findy Team+ Awardを受賞できました！
リリース頻度はほぼ変わっていないように見えますが、チームの人数が少し減っているため1人あたりのリリース回数に直すと2期が1.5回、3期が1.8回となり確実に増えています。
2期のサイクルタイム推移。期末(2期4Q)は66.1h
3期のサイクルタイム推移。2025年3月だけみると驚異の7.2h!！
2期4Qと3期4Qを比較すると主要スタッツは軒並み良化！！
定性
定性面ではプロダクトを中心に考え、ディスカッションできるようになりました。
スプリントレビューの中では当たり前のように、成果物レビューでもっとこうすべきという意見やこの表現の方が良いのでは？という意見が出てきます。
また、スプリントゴールをタスクベースではなく提供価値ベースで置くようにしたことで、自分たちが開発しているものはどのように使われ、どのように価値を発揮するかを考えるようになりました。
既存メンバーがスキルアップしたことで、価値発揮するためのボトルネックがチーム全体のスキルレベルから、プロダクトや事業の解像度をもっとあげることに移り変わってきています。
結果として、自分たちの仕事の軸がプロダクトになり、アウトプットからアウトカムへと興味関心領域が広がってきているのです。
まとめ
色々書きましたが、やはり期初にきちんと方向性を決めて宣言することの大切さを説いて終わろうと思います。
期初に「プロダクトチームになる」と社内外に宣言したからこそ、それが灯台となり、さまざまな物事の意思決定の軸になったことは間違いないです。
宣言がなければミッションとしてメンバーに何かを渡すことも、フィーチャーフラグを導入することもなかったかもしれません。
そして自分だけが意識するのではなく、メンバーに自分が理想としているゴールがどこなのか、なぜこのテーマ、目標なのかをきちんと理解してもらう努力をし、それに対してチームメンバーがみな応えてくれたからこその3期の成果と成長だなと自信を持って言えます。
まだまだ目指す先は高く、遠いですが引き続き4期も気張ってまいりますので、みなさんどうぞよろしくお願いいたします！！
それでは今回はこのへんで。最後まで読んでいただき、ありがとうございました！
Discussion