自由と責任を開発チームにもたらしたら開発速度が上がった話

ストックマークの開発体制は、プロダクトの成長フェーズに合わせて、2021年夏に大きく進化しています。本エントリでは、何が課題でどう進化したのか？を紹介いたします。本エントリを読むことで、スタートアップの開発体制で発生する課題と、その解決方法の1つを理解できます。

サマリ

• 開発チームのパフォーマンスが最大化できていなかった
• 開発チームに自由と責任を委譲し、より自律的な行動を促進した
  • スクラムを辞めて、カンバンを主軸とする開発へ
• その結果、開発スピードが大きく向上し、より迅速にアウトカムを提供できるように

どんな課題が存在していたのか？

大きく分けて、開発チームに関する2つの課題が存在していました。

課題1: リソースの偏り

ストックマークの以前の開発体制(〜2021年8月)では、Anewsの開発チームは大きく分けて、 以下の2つが存在していました。

1. 情報収集機能を開発するチーム
2. コミュニケーション機能を開発するチーム

それぞれのチームが、常にパフォーマンスを最大化できていれば良いのですが、実際には片方のチームがビジーであり、もう片方のチームの負荷が軽い時期がある、などの状態が発生していました。

また、Slackなどで情報同期・可視化はしているものの、一部の仕事が重複しているケースもありました。

課題2: 余剰リソースが一時浮き

新しい価値を開発をすすめる場合に、プロダクトマネージャが主導権を握っており、開発チームが自律的に新価値開発を実施できていないケースがありました。

もちろん、機能の内容や優先度はプロダクトマネージャが責務を担っている点は自然ですが、プロダクトマネージャとの調整をしないと、一時的にリソースが浮くケースがあったのです。

Anewsというプロダクトは急速に成長を遂げている真っ只中であり、新価値を高速に提供するのが重要なフェーズです。そのため、ここまで述べた2つの課題は早急に解決する必要がありました。

どのような解決方法をとったのか？

課題2冒頭で述べた、主導権を開発チームに移しました。言葉だけだとわかりにくいので、Before/Afteを簡易Value Stream Mapで説明します。

最大の違いは、Push型のフローから、Pull型のフローに変更したという点です。すなわち

• Before: プロダクトマネージャが起点となり、Push型で開発を進めていた
• After: 開発チームが自律的にバックログから開発項目を取得して開発をすすめる

というように変更しています。技術的なメタファーを使うと、バックログを起点とした、PubSub型と捉えていただいても良いです。

バックログ以降についての意思決定については、開発チームに委ねられています。プロダクトマネージャとスケジュールなどの概要を合意してあるため、あとは開発チームがバックログを確認しながら自律的に開発を進めています。

今回の開発体制での想定課題

開発体制によって、全ての課題が解消されるわけではありません。むしろ、いくつかの想定課題もあります。

• 開発チームの責務が増えるため、責務をおっている部分の問い合わせがある場合に、開発チームへの割り込みが増えてしまう
• スケジュールを開発チームに任せるので、開発全体が遅れる可能性がある
• プロダクトマネージャと開発チームが分断されるため、コミュニケーションが疎になる可能性がある

1つ目の問い合わせについては、組織マネージャという役割をおいて対応しています。組織マネージャは、開発チームのリソースの集中について判断し、開発パフォーマンスを最大化することに責務を負います。スクラムにおける、スクラムマスタの役割を一部になっているような形になります。

2つ目については、スケジュールのアラートを出す、遅れるときは開発チームとマネージャでお互いに指摘しあえるような環境を作ることで対応しています。

3つ目については、潜在的な課題ではありますが、プロダクトマネージャともコミュニケーションが十分取れており、現時点では顕在化していません。プロダクトの成熟フェーズにあわせて、価値を早く創造する仕組みを優先しています。（なお常に開発体制も進化しており、エンジニア主体の価値創造も今後は増える予定です。一緒に進めてくれる方を募集中です！）

結果どうだったか？

定性的な指標ではありますが、プロダクトオーナーからのコメントとして「開発が早くなったね」がありました。また、プロダクトオーナー以外のメンバーからも、開発チームの速度についてのポジティブコメントが増えています。

おわりに

チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

アジャイル宣言の背後にある原則の1つです。今回の開発チームの体制見直しは、まさにその一例であり、さらに言えば組織学習で言及される「ダブルループ学習」を開発チーム自ら引き起こした事例といえます。すなわち、「そもそもこの開発フローがベストなのか？」という問いを起点に、高次の学習を進めた形になります。

ストックマークの開発チームは、もちろん開発チーム自体でふりかえりを進めて、パフォーマンスを高めるためにふりかえりを進めています。これらは主にシングルループ学習であり、これ自体の価値もあります。しかし、事業フェーズが高速に変化するスタートアップにおいては、シングルループ学習のみならず、ダブルループ学習が効果的なケースもあります。

ストックマークのValueの1つは、「仕組を革新する」です。今後も、自社の仕組を革新し続けていき、お客さまと一緒に進化のドラマを作り続けていきます。

興味を持っていただけた方は、採用ページもぜひご覧ください！