「社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について」の資料が素晴らしい

「社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について」の資料が素晴らしいのでメモ。
以下はラフなメモ書き。

【参考】
hideakihalさんはTwitterを使っています: "このアジャイル開発のノウハウはすごい。/ 社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove http://t.co/pSVThDbN3b @SlideShareさんから"

村田 こーへいさんはTwitterを使っています: "なるほどー勉強になりました/社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove http://t.co/5KeLg5YyhF @SlideShareさんから"

社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove from Itsuki Kuroda

【0】自社サービス開発案件に対し、アジャイル開発とリーンスタートアップを適用した経験事例。

【1】当初はわずか4～5名のチームが数十名のチームに膨れ上がり、リードエンジニア(事実上のサブリーダー)がボトルネックになって、チームが回らなくなる問題があった。
よくある伝言ゲーム、身がないたくさんの会議、など。

そこで、スクラムを取り入れて、複数の小さなチームに分割し、プロダクトオーナーチームとスクラムチームを形成するようにした。
つまり、リーダー制度を廃止した。
他にも、バグのトリアージ、リリースカレンダーなどを取り入れて、定期的にリリースできる仕組みを取り入れた。

こういう話を聞くと、すごく同感する。
最近は、プロジェクトリーダーという役割がボトルネックになっている気がする。
プロジェクトリーダー一人で全員のスケジュール・コストの管理をするのは至難の業で、たくさんの労力がかかる割には、意思決定がすごく遅い。

アジャイル開発がスムーズに回るチームにいると、プロジェクトリーダーのロールの人は、管理の役割からプロダクトオーナーの役割に自然に移っていく。
チームはいつまでに何をリリースすべきか、というプロダクトバックログを常に保守するようになっていく。

すると、プロダクトオーナーのスキルは、単純な管理だけでなく、経営や戦略と言ったもう一段階上の高い視点の意思決定が要求されるようになる。

【2】しかし、スクラムを取り入れたからと言って当初の課題であった「成長スピードの鈍化」が改善されなかった。
プロダクトバックログに起票されるタスクが本当にやるべきことなのか？
そのタスク（機能）をリリースしたあとの効果はタスク（機能）毎にわかるのか？

無駄な機能をたくさん作ってリリースしても、売り上げにつながっているのか？

そこで、リーンキャンパスやリーンスタートアップのBuild→Measure→Learn、顧客開発モデル、MVPを適用して、スクラムの各タスク(機能追加) の効果(結果)を正しく計測していった。
そこから得られた結果を元に、ビジネス仮説をブラッシュアップして、サービスを成長させた。

この話を聞くと、やり方がうまいなーと思う。
特に印象深いページは、P.82のリーンキャンパスの絵。

P.82には、リーンキャンパスの9つのエリアごとにMVPの機能を作って「構築→計測→学習」のプロセスを実行し、MVPの効果を評価検証するようにもうけている。
つまり、リーンキャンパスというビジネス仮説を評価検証した後、プロダクトバックログへその内容を反映してブラッシュアップし、製品開発のサイクルを早めている。

リーンキャンパスは僕も書いた経験があるが、書いてみると色々ブレインストーミングできるし楽しい。
しかし、その仮説が本当に正しいのか、という実証データは、リーンキャンパスだけでは分からない。
やはり実際に製品をリリースして試して、結果が得られなければ分からない。

でも、P.82のリーンキャンパスの絵を見ると実際に実行してみて、その結果を反映して色々試している。
この辺りのノウハウが公開されているのはすごいと思う。