hikoharu's blog

エンジニアリング、プロダクトについて考えていること。twitter: @hikoharu06

プロダクトオーナー研修 1日目感想

Sierでなんちゃってアジャイルやったり、スタートアップにアジャイルプロセス導入したり、アジャイルサムライ一通り読んでみたり スクラムとは結構3年くらい付き合ってきたものの、どちらかというと現場の叩き上げで学んできたので一度整理したかった。

というわけでこれ行ってきた

https://scrum.esm.co.jp/

先に前提としてPO,SMの役割について

プロダクトオーナーとは

プロダクトのWhatを扱うもの。Howには決して言及しない。チームメンバーに任せる。 半分の時間は顧客、ステークホルダーと過ごして、半分の時間はチームと一緒に過ごす。 プロダクトマネージャーとの違いは諸説あるが、Scrum Inc曰く本質は同じで、より「プロダクトの全責任はあなたにあるよ」というオーナーシップを意識してPOと呼ぶ

スクラムマスターとは

プロセスを管理する。チームの幸福度、ベロシティの向上が責務 プロダクトオーナーとは基本的に対立する立場となる。POの機能要求をスクラムマスターは管理しなくてはいけない

内容のサマリー

序盤はアジャイル語る上で欠かせないウォーターフォール叩きから入る。計画から逸脱しない前提でやってるけど現実そんなことはおきないという感じ。 新しかったのは化学工場の例え。「工場で行っている化学反応はリアルタイムで微妙に調整しないとコントロールできない。失敗すると爆発してしまう。最初から全部予測なんて無理だろ」と妙に説得力あった。

アジャイル行う上で重要なものは

  • 勇気
  • 集中
  • コミット
  • 尊敬
  • 公開

の5つ。 中でも難しい(特に日本では)のは勇気と公開。 これは日本人の謙虚さ、礼儀という性質の副作用。プロセスの透明性、検査によってアジャイルは実現されるが、上記を欠くと遅延、成果物の品質問題を正直にレポートできない、チームの自己組織化が損なわれる あと日本は根回ししすぎ、これはPOが責任取る覚悟が足りていないから。全部決めて、責任取るべき。別に失敗してもクビにならないんだから、もっとリスクを取るべきと

あと大切なのはスクラムスクラムするという考え方、いわゆるカイゼンというやつ。スクラムやる以上ベロシティを上げるために全力を尽くさなくてはいけない。具体的には以下が有効

  • カイゼン:振り返りをして改善できるポイントは次のスプリントの再優先事項として扱う
  • やり方:集中というやつ。マルチタスク状態にならないように
  • 幸福度:メンバー全員が役割、チームに幸せを感じて働けるように

違和感感じた部分

違和感感じた部分は大体共通していて、いわゆる理想と現実のギャップというやつ

  • PO,SMの役割分担:メンバーとは明確に必要なスキルが分かれているものの、ぶっちゃけ優秀なメンバーを経験してPOになるケースがほとんどだと思う。POがシニアエンジニア、メンバーは新卒とかの構図も普通に多いはず。PO的にはHowに言及したいし、組織としてもPOにSM的役割、またメンバーのマネジメントを求めている時にどうすればいいのか

  • ベロシティの向上:ソフトウェア開発は労働集約なので、基本メンバーが最初から十分なスキルを持っている前提であれば、ベロシティがそんな劇的に上がるイメージはない。上げるとすれば時間か人を増やす。ベロシティはものさしでこなせるタスクの量を決めるもの。SMが使うチームを守るための指標で、それをどういうやり取りで上げていくのかイメージできない

  • メンバーの意識:アカデミックなスクラムではメンバーにタスクがアサインされることはない。メンバーはバックログから勝手に必要なタスクを取っていく。ただ実際には期限、アサインを明確にしないと進まないということからSM権限、あるいは合議でアサインが決まっている。メンバーにそこまでアグレッシブさを求めるのもなと。。。

総じて - 役割全員が十分なスキル、スクラム知識を持っている - なおかつチームに対するビジネス側の圧力がほとんどない(POが十分なスキルを持っているということかもしれないが) - メンバー全員のモチベーションがメチャクチャ高い。労働時間が完全に固定されているか、眼中にない。

という現実にはなかなか揃わない条件が揃った時に成立する部分に違和感を感じた。 ただ仮にこれらが実現できなくても、スクラムのメリットは十分だと思う