シャペロンでは LeSS を導入して CTO の役割がどう変化したか？
こんにちは。製薬会社に特化したSaaSを提供している株式会社シャペロンでCTOをしている浅野です。しばらくnoteから遠のいていましたが、また書いていこうと思います。今回のテーマは「アジャイル開発においてCTOの役割がどう変化したか？」です。
シャペロンではちょうど2年前に大規模スクラムフレームワークである LeSS の導入を決断しました。導入からの変遷を書いておくことで、LeSS の導入を検討、もしくは既に運用している会社や、シャペロンに興味を持ってくれている方の参考になってほしいです。
LeSSとは？
LeSSは複数チームでスクラム開発をするためのフレームワークです。他にも目的の近いフレームワークは存在しますが、LeSSはシンプルで拡張性も高いことから最近ではスタートアップやメガベンチャーで採用される傾向にあります。
フレームワークの詳細には踏み込みませんが、この記事に関連するところだけかいつまむとLeSSには以下のような特徴があります。
プロダクトオーナー(PO)は一人で、プロダクトバックログ(PBL)は一つ
複数の開発チームが一つの PBL 上で開発する
開発チーム内にマネージャーはおらず、PO、スクラムマスター(SM)、開発チームをフラットにサポートする役割としてマネージャーが存在する
なぜLeSSを導入したのか？
LeSS 導入前の開発チームの状況は以下のようなものでした。
SMがいない、なんちゃってスクラム
CTOが組織上のマネージャーでありPBLを管理していた。POとは定義されていない
メンバーは10人前後で1チーム体制
この頃はメンバー増加に伴い、会議中の参加者の発言が明確に減ってきていることに強い課題感がありました。チームの肥大化に限界を感じており、複数チーム体制への移行が必要でした。
シャペロンでは「積み上げることに価値がある」というValueがあります。私達がチャレンジしている製薬業界 & エンプラ向けSaaS事業は成長に時間がかかるため価値を着実に積み上げていきたい、という意図があります。組織に投資していくことはこのような事業戦略にもマッチしていたため、LeSSの導入を決断しました。
1年目 / POとして
まずはLeSSの導入に際して、この時初めてCTOがPOという役割を担うと宣言しました。それまで曖昧だったことが今では信じられないですね。
当初の課題だったチーム肥大化はチーム分割を行うことでなんとか解消されました。しかし今度は別の課題が現れます。
プロダクト毎に担当チームを設けた弊害
ちょうどこの頃、シャペロンでは初期プロダクトをベースとした新プロダクトの開発がスタートしていきます。コードベースや機能を共有していることもあり、CTOが 2 つのプロダクトを管理することになりました。
当初は 2 つのチームが新旧それぞれのプロダクトを担当して進めていました。しかし新プロダクトがローンチされ、ユーザーから多くの要望をいただく中で、それらの要望を一つのチームでしか対応できないことがボトルネックになりました。
フィーチャーチーム化を目指す
LeSS ではチーム横断的に行うリファインメントとプランニングが定義されています。一方でその時シャペロンでは、それらのイベントをチーム単位で個別に行っており、LeSS の導入はまだ片手落ちの状況でした。
先程のボトルネックを解消するためフィーチャーチーム化を目指しました。具体的な施策は、LeSS のガイドラインに沿ってチーム横断でのリファインメントとプランニングを導入したことです。
実際に運用が始まったのはぼくがPOを委譲したあとになるのですが、そこから徐々に他のチームも新プロダクトの開発をこなすことができるようになり、フィーチャーチームが徐々に浸透していきました。
2年目 / マネージャーとして
2年目にはPOを委譲する話が持ち上がります。理由はいくつかありますが、最も大きな理由はCTOに権力が集中しすぎていたということです。CTOがPOをやり、組織施策をやり、人事評価も行い、設計や技術的な意思決定も行う状態だったので、窮屈な組織になってしまい、成長できる環境ではありませんでした。
スクラム開発におけるアンチパターンとして 「PO やスクラムマスターがマネージャーとして権限を持つと、チームは顧客ではなく、そのマネージャーに向かって業務をしてしまう」というものがあります。まさにそれが起こっていたと言えます。
POを委譲するちょうど半年くらい前に、新しい専任のスクラムマスターもチームに加わり、新しい体制が始まった時期でした。
POを委譲してみて
基本的には LeSS で示されているマネージャーとしての役割を担うことを目指しました。
マネージャーとして「組織づくり」や「チームのサポート」が主務となり、直接的な顧客への価値提供に関わらなくなったことで、当初は右も左もわからないことがありました。
この辺りの経緯を書き始めると別の記事が一本できてしまうので今回は割愛します。この記事では今の役割を書くにとどめておきます。
新規プロダクト立ち上げ時のチームへのサポート
プロダクトロードマップを除く組織目標の設定
採用、評価などの人事機能
取締役として事業戦略などの作成サポート
業務の大半はスクラムイベントを観察したり、議事録やSlackの議論を読んでキャッチアップし、課題を探しています。施策の実施はPOやスクラムマスターと協力して進めることが多いです。
CTOがボトルネックにならない状態を目指した甲斐もあり、創業以来初めてのサバティカル休暇のようなものも取れました。
今後の役割
開発サイクルの外から時間をかけて組織を観察していると、多くの問題は開発プロセスやプロダクトの提供価値に関するメンバー間の認識のギャップに起因しています。
そこでのマネージャーの役割は組織における共通理解を作っていくこととなります。実際はシャペロンの「ミッション」「戦略」などの抽象度の高い前提をインプットとして、プロダクト部門としてそれらを解釈し、具体的なあるべきを定めて、施策し、検証する、というサイクルまでを構築することになります。
CTOの役割も、現状の個別に発生する問題への対応から、そういった仕組みづくりに移っていくのが良いと考えています。
スクラムマスターを募集しています
ここまで読んでいただきありがとうございます。最後に採用の宣伝をさせてください。
シャペロンでは現在 3 チームでプロダクト開発をしており、対してスクラムマスターは一人しかおらず、人数が足りていない状況です。
チーム内にマネージャーを置かないシャペロンでは、スクラムマスターの役割は非常に広く、ファシリテーションから技術支援や開発メトリクスの提案など、多岐にわたります。
スクラムマスターという役割がフラットな組織とアジャイル開発を維持するには非常に重要な役割である
LeSS をチームビルディング初期から導入している組織はまだまだ少ない
このような点でスクラムマスターとして幅広くチャレンジできる環境になっています。興味のある方は是非、エントランスブックを覗いてみてください！