見出し画像

開発組織とアジリティ [前編] ~ 事業における変動への適応 ~

tobb422

メダップでは掲げているビジョンは変わらないものの、そこに向かうための手段は常にアップデートしています。
そして、こうした変化が激しい環境に開発組織を適応させるために、アジリティ高くやっていこうと奮闘しています。

アジリティを言い換えると、組織の機動力だと考えており、
アジリティの高さは、開発組織が状況に応じて素早く対応ができる組織であるかを表しているといえます。

今回は、開発組織がこうしたアジリティ(変動への適応力)を高めるために具体的にどういった取り組みをしているのかを書き起こしてみました。
(書いてみるとめちゃくちゃ長くなっちゃったので、今回は前編/後編の2部構成でいきます)

変動のパターンを理解する

変動に対して、どう適応していくかを考える前に、
開発組織につきまとう変動(状況の変化) のパターンについて整理しておきます。
変動は大きく分けて2パターン存在するかなと考えています。

1つめが事業における変動で、事業戦略の変更等により優先すべき開発項目が変わるケースです。

そして、2つめが実際に機能を開発する中で発生する変動で、仕様やデザイン変更により開発するものが揺れるケースです。

それぞれのケースでその変動への対応策は変わるため、この2分類それぞれについて整理していきたいと思います。

事業におけるアジリティを高める

スタートアップ(特にシリーズAまでのPMF達成前等)では、1, 2ヶ月で事業の様子が劇的に変わる！ということも少なくないと思います。
メダップでも実際にこの半年間でどの機能を優先して開発するかは、随分動きましたw

こうして日々状況が変わる中、その変化に開発組織がどう適応していくかは、なかなか難しい問題だなーと思います。

メダップでは、下記2点にフォーカスしてなんとか頑張っています。

・週次で行われる事業MTGで開発バックログの確認を実施する
・リリースを最小単位にまで小さくする

・週次で行われる事業MTGで開発バックログの確認を実施する

メダップが運営しているサービス「foroCRM」では、毎週各チームのマネージャーが集まるMTG(メンバー参加歓迎)を実施しており、そのMTGにおいて開発チームからバックログのシェアがされています。

バックログを見ながらシェアしている主な内容としては、「取り組んでいる」, 「リリース予定」, 「次取り組もうとしている」と各バックログのステータスです。
その中でも特に、「次取り組もうとしている」バックログアイテムに関しては、本当に次これに着手することで問題ないか？を毎週確認するようにしており、Biz − Dev の双方で常に認識の齟齬なく開発が進められる状態を作っています。

すべてのバックログにはポイントが振られており、開発着手された後、おおよそどれくらいでリリースにまで至りそうかを過去の実績から算出できるようにしているため、現在の事業の状況や開発進捗具合を鑑みて、随時優先度を見直すようにしています。

週単位で最新のバックログになっているので、開発組織としても次どういったバックログに取り組むかが明確な状態で開発を進めることができます。
次回のバックログでこの辺りを着手することになるから、いまからキャッチアップをやっておこうなど、スムーズに次のバックログに入ることができる体制になっているかなと思います。

・リリースを最小単位にまで小さくする

開発組織では、バックログアイテムごとにリリースを行っているのですが、このバックロアイテムの大きさはなるべく小さくすることを心がけています。

バックログアイテムが大きく、リリースまでに1, 2ヶ月かかるものだと次の優先度を組み替えていったとしても、そのバックログアイテムをリリースできないことには先に進めません。
(メダップでは、このバックログをかんばん形式で管理しており、WIP制限を付けています)

刻々と変わっていく優先順位に速やかに対応するためにもCSチーム等とやり取りしながら、どのレベルであれば機能を絞って小さくしてもユーザーが価値を損なわいかを考えて、できる限り小さな単位でリリースできるようにしています。

大体の流れとしては、バックログアイテムで要求されていることを明確にした後、開発陣がCSチームや事業責任者とコミュニケーションを取りながら、ここまで作るとこれくらいの工数がかかる、この機能を別の形に代替すれば工数を劇的に減らすことができるなどを提案した上で、ユーザーにとっては価値が損なわれないギリギリのラインで必要最小限の機能をリリースすることを心がけています。

上記2点を意識することで、日々変わっていく事業戦略に対応する形で開発を進められていると思います。
事業の変動に適応する開発組織を作るためには、他職種のチームからの協力が必要不可欠であり、そこを上手く協調しながらバックログを作れていることはメダップが強さかもしれません。(全職種、開発への理解がめちゃくちゃ高いです)

前編まとめ

前編では、どういった変化に適応していく必要があるのかを整理するために
変動について整理しました。
またその上で、事業における変動に適応するためにどういった取り組みをしているかを書き起こしてみました！

小さなバッチサイズで開発を行うことは、当たり前のことかもしれませんが、実際に運用で実現することは難しいのかなと考えています。
その理由としては、やはり他チームとの協調しながらバックログアイテムを形作っていくことが求められるからです。
メダップの開発組織では、バックログのカンバンを開発で完結せず、事業全体で確認するものとした上で、バックログアイテム一つ一つをなるべく小さな単位で出せるよう一丸となってユーザーにとって必要な必要最小限の機能を定義する過程を作れていることは非常に強みになっていると感じています。

後編では、実際に開発をしていく中で発生する仕様, デザイン変更といった変動にどう適応しているのかをまとめていきたいと思います。
今回は、開発チームを越えてバックログを作っていくことの重要性がテーマでしたが、次回は開発メンバーが自律的に開発を進められる仕組みについて触れられるといいなと思っています！

開発メンバーを絶賛募集中なので、こうした開発組織作りにもご興味いただける方、プロダクト開発が大好きな方、ぜひぜひ私にご連絡ください〜！