開発組織とアジリティ [後編] ~ 機能開発における変動への適応 ~
前編では、変動のパターンと事業におけるアジリティについてまとめました。
この後編では、機能開発の中で発生する変動(仕様やデザイン変更による開発の揺れ戻し)に対してどう適応しているのかについて書き起こしてみたいと思います。
(書いてみて、ちょっと論点ずれちゃったかもな〜って不安に思っていますw)
機能開発における変動について
最初に前提を壊すような事を言ってしまうのですが、そもそも開発に着手してから仕様やデザインを変更するといったことはないほうがいいと考えています。
開発が手戻りになる原因ですし、想定しているスケジュールや開発工数も変わってきてしまうので、こうした変動は0であることが最も理想の状態なのかなと思います。
(宣伝になってしまいますが、この変動が0であると、組織としては効率性が高い状態を築くことができるという話を、前回まとめているのでよければご覧ください → 開発組織と効率性のマトリックス)
ですが、現実はそこまで簡単なことはなく....
開発着手後でも仕様の考慮が足りなかっただとか、仕様が増えたためにデザインを修正する必要があるだとか、様々な理由で開発する対象が揺れ動くと思います。
開発組織としては、こうした開発対象が揺れ動きに対して、素早く適応して開発を進めていく能力が求められます。
(変動自体を如何にしてなくしていくか？については、また別の機会にまとめてみようと思います。)
機能開発におけるアジリティを高める
前述したとおり、機能開発を進める中で発生する変動に対して、開発組織は上手く適応していく必要があります。
現在の私の解像度では、機能開発におけるアジリティを高めるためには実際に開発を進めるエンジニアがどれだけ自律的に動くことができるかが重要だと考えています。
そのため、機能開発におけるアジリティの高さ ≒ エンジニアが自律的に動くことができる環境のレベルと捉えることもできるかもしれません。
上記の概念を前提として
メダップでは下記2点の仕組みを構築することで、アジリティを高めようとしています。(≒ エンジニアが自律的に動ける環境を構築しています！)
・バックログアイテムごとに開発オーナーを決める
・バックログアイテムごとにキックオフを実施する
・バックログアイテムごとに開発オーナーを決める
メダップの開発組織では、開発バックログを用いて新規機能やシステム改善を管理しています。
そして、各バックログアイテムが開発工程に入るタイミングで、そのバックログアイテムに対する"オーナー"を決めるようにしています。
オーナーは、PdMから機能の概要をシェアしてもらった上で必要となる開発工程のガイドラインを洗い出します。ある程度、リリースまでのプロセスが明確になったタイミングで、他の開発メンバーを集めて、キックオフを実施します。(ここに関しては後述します)
実際に開発に入った後も、想定していたプランニング通りに進捗しているかや、開発をしていく中で見つかった考慮漏れの仕様, デザインをPdM, デザイナーに相談しにいくのもこのオーナーが受け持つ体制を取っています。
もちろんオーナーだけがその担当したバックログアイテムの開発をするわけではなく、チーム全体で機能開発を推し進める文化ではありますが、このオーナー制を取ることで、開発途中で発生し得る停滞しがちなボール(仕様確認やデザイン修正依頼, ..etc)が、なめらかに動くようになったかなと思います。
オーナー制を取るようにしてから、開発組織全体でみても開発メンバーが自らPdM、デザイナー、時にはCSチームのメンバーに積極的に働きかけ、機能開発を前進させる文化が醸成されつつあるように感じています。
オーナーを中心に開発メンバーが主体性を持って、他のチームに働きかけに行くので、自ずと変動があったとしても素早く適応できる体制が構築できつつあります。
(開発バックログの例)
・バックログアイテムごとにキックオフを実施する
先程も少し話に出しましたが、オーナーがリリースまでのプランニングをし、いざ開発を始めよう！というタイミングで、他のメンバーを集めてキックオフを開きます。
キックオフでは、なぜこの機能を作るのか？といったユーザーの課題の理解や何を作るのか？といった要件定義, 振る舞いの確認, そしてリリースプランニングでおおよその開発工程を把握することを目的としています。
このキックオフを通して、オーナーではないメンバーもバックログアイテムに対してのオーナーシップが高まり、積極的に動ける状態が作りやすくなったと思います。ただカンバンになるチケット単位で作業をするのではなく、バックログアイテム全体を通してのストーリーを把握できるようになるため、何を優先すべきかや足りていないチケットなどを自らが考えて、より高い納得感を持って開発に着手できるようになってきました！
こうして1人1人が開発対象への納得感がある状態を保つことで、いざ仕様変更やデザイン変更があったとしても、素早く背景を読み取り、対応に向けて動くことができます！
(そもそも仕様が足りていないとか、デザイン考慮漏れかもといったことをエンジニアが発信してくれます)
後編まとめ
後編を通して、機能開発で発生する変動に適応するために取り組んでいることを書き起こしてみました！
機能開発におけるアジリティを高めるには、開発メンバーが実際に開発する機能に対して納得感を持ち、自律的に動ける環境を構築することが非常に重要です。
そこでメダップではその手段として、バックログアイテムのオーナー制と、バックログアイテムごとのキックオフを取り入れています。
もちろん、デイリーMTGで状態の可視化をすることで全体の状況が把握でき、そこからお互いに支援し合うことも多くあり、大切だと思います。
ですが、それだけではまだ変動への適応としては不十分で、こうして自律的にチームのために動くためにも自分たちが取り組んでいることへの納得感や解像度が高くないと不可能だと考えています。
全体まとめ
開発組織のアジリティについて、前編/後編とそれぞれ書いてみました。
メダップでは、アジリティはスタートアップにとっては非常に重要な概念だと考えており、そこに対して高められる仕組みを常に考え、実践しています。
今回書いた内容もまだまだ組織として発展途上の中で出している現時点での取り組みにしか過ぎないので、ここから半年, 1年, ... と改善を回していきたいと考えています。
こうした強い開発組織作り全般に興味ある方はもちろんですが、
この回を通じて重要なポイントとしてあげた
・開発チームを越えてバックログを作っていくこと
・メンバーが自律的に動ける開発体制を作っていくこと
に対して興味をお持ちいただける方はぜひ私にご連絡ください〜！
開発メンバー絶賛募集中です！！！