見落としがちなアジャイル開発の肝!分析スピードが開発スピードを左右する
こんにちは、みなさん今日も良いものづくりしていますでしょうか?今日はアジャイル開発で必要な分析力の話をしたいと思います。
1.アジャイル・スクラムについて
IT系でのモノづくりで、近年はアジャイル開発が主流になっています。アジャイル開発とは「アジャイル(agile)」は「素早い」や「機敏」という意味で(名詞形は「アジリティ(agility)」)、従来のウォーターフォール開発などよりも素早い開発という意味です。スクラムの導入は広まっていると思いますが、このアジャイル開発を成功させるためには、プロダクトの状況を把握するKPIダッシュボードの可視化や分析力が不可欠なのですが、開発目線の話のため、あまり語られていないと思い、今日はその話をしたいと思います。
まず、主流の開発方法が「スクラム」という手法ですが、なぜ「素早い」かというと、開発中に発生する様々な状況の変化に対応しながら開発を進めていく手法のため、仕様変更等の出戻りが少なくなり、結果的に早く目的のものを開発できるということになります。
toC向けのネットサービスは、そもそも完成というものがないため、仕様変更が当たり前のようにあるため、このアジャイル・スクラム開発というのが主流になっています。
2.アジャイル開発での分析力
アジャイル開発で実際に開発スピードを上げようとすると、実は、このテストということろの分析が早くできるか?が意外と語られていないですが、重要になります。
通常、アジャイル開発が持ち込まれるtoCのサービスであれば、ABtestが入ります。いきなり100%で大きな変更をするというのは大規模なリニューアルをする場合などを除き、あまりありません。
そして、今のトレンドで言えば、このABtestでいかに速く意思決定できるか?これを考えないとアジャイル開発をして、速く開発しようとしている意味がなくなってしまいます。
さて、ここでみなさんは、このABtestにどれぐらいの時間をかけていますでしょうか?
この時間は統計学的に有意と判断できるサンプル数がないといけません。すでにたくさんのユーザーがいるサービスであれば、1日でほぼケリがつき、翌日にはチームは次のアクションをとって動くというスピード感です。(念のため3日と土日の傾向が違うサービスであれば、土日の動きや特定の曜日も観察しておく)
このスピード感で意思決定を行うために、必要なのが、KPIをABtestごとに見れるダッシュボードです。
YK流のマネジメントでは、以下KPIツリーのダッシュボードを作った後、ABtest用のダッシュボードを作成します。
ABtestを開始し、翌日にABtestダッシュボードをみんなで確認し、予測して次の対策に動きます。
このスピード感で行うから、アジャイル開発というのがウォーターフォールより優れていると言える訳です。この分析に時間がかかっていてはアジャイル開発の本当の効果を引き出せていないことになりますので、この分析を早くするというのをプロダクトマネージャーは知っておいていただければと思います。
アジャイル開発をするときにチーム個人個人の分析力というのを上げておかないといけません。分析力の上げ方は、まず、個人個人がSQLなどの集計ができることが必要です。いちいちアナリシスチームなどに頼んでいると必ずdelayします。SQLの習得の仕方は、以下を参考にしてもらえればと思います。
ただ、SQLができるようになったからといって、分析ができるわけではありません。本来分析は10年ぐらい訓練してできるようになるものです。(と、私は当時の上司に教わりました。)ただ、分析のプロフェッショナルとして生きていく場合の話で、一般的にPDCAを回せるようになるレベルはもう少し早くできるようになると思います。その方法は以下記事しておりますので、こちらも参考にしていただければと思います。
この本質を認識した上で、分析力を高めて、良いアジャイル開発ができるチームにしていただければと思います。
まとめ
いかがでしたでしょうか?皆様のプロジェクトの改善やチームのPDCAの回し方の参考にしてもらえれば幸いです
インスタグラムもしておりますので、フォローよろしくお願いします
この記事が気に入ったらサポートをしてみませんか?