ビジネスサイドのスクラム開発
現組織で素晴らしいし、他の組織でも展開されるべき仕組みとして、「スクラム開発」がある。スクラムは、一般的には開発サイドのやり方で、一つの改善サイクルをスプリントと呼んで少人数で回すことで、計画承認実行のウォーターフォールサイクルよりも仮説検証のスピードを改善できる。いわゆる計画に対する実行のずれの無駄を省くことができる。
インターネット業界では計画をすぐに施策に反映させることができるアーキテクチャになっている。相対的に。それゆえに、ビジネス側の施策も含め、改善すべきテーマ＝バックログを細かく刻み、それを複数のチームが別れて取り組むことでカイゼンの個数を増やすことができるし、さらに良いことには、カイゼンプロジェクトに対してそれぞれのメンバーも意欲を向けられるようになるから、チーム全体としても前向きになっていく。
あらを探すわけではないが、スクラム開発には一定の気をつけなければならないポイントがあるように思われる。それは、長期的な視点だ。
例えば全体で改善すべき課題が非常に大きなボリュームである時に、それを音頭を取ってリーダーがスクラムに落とし込めるのか。「やったほうがいいけど緊急性が低い課題」が、作業量として大きくなり、どうしても後回しになりがちで、仕事を降ったとしても「うちのチームの課題の粒度、不公平じゃない？」とチーム間の不公平に繋がったりする。大手の会社では、「お客様の声プロジェクト」「品質改善プロジェクト」みたいな長期プロジェクトが独立しているし、こういう粒度の高いWF側の指示の仕方もプロダクトオーナー手動で時々織り混ぜるのは、地味に大事な気もする。
強いチーム＝互いに学習し続けるチームにする、という観点で、非常に施策として勉強になるなぁと、思いました。
▼LaplasのBizサイドのスクラム開発
https://www.wantedly.com/companies/lapras/post_articles/128107
▼プロダクトオーナーの役割
