hikoharu's blog

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

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

昨日に引き続きプロダクトオーナー研修２日目 色々良かったが、中でも勘違いしていた部分を正すことができて、有意義だった

これまでしていた勘違い

アジャイル開発は仕様は最低限しか決めない。INVESTを満たすユーザーストーリーだけを決めて、どういう画面、機能で実現するかは開発者に任せられている。ドキュメントはあくまで最低限で不明点は会話で解決する。プロダクトバックログの役割の一つとしても会話を自然に促すというものがある

正しいこと

スプリントバックログに入ってREADY状態（エンジニアが着手可能）になるものはデザイン含んだ仕様、受け入れ条件、完了条件が明記されている。 ここにあるストーリー、タスクはPOと意思疎通なしで進められることが理想でもし会話が必要になったら、それはPO、チームのリファインメントが甘かったということ

勘違いの原因

プロダクトバックログとスプリントバックログを混同していた。確かにあいまいな状態で会話により進めていくのはあっているが、それはスプリント対象外のタスクにおいてのみ 「仕様が全部決まらないと作れないとか、これだとウォーターフォールじゃん」と思うかもしれないが、アジャイルの真髄は全体像が決まりきっていなくても、ビジョンを分解して部分的に進めて積み上げられるところにある

POのセンス

アジャイルの真髄はビジョンの分解と積み上げ。分解してどうやって積み上げてプロダクトを作っていくかがPOのセンスが問われると思った

  • ユーザーにとって最も価値のある機能、MVPは何か
  • フィーチャー、エピック、ストーリーは構造的にユーザーストーリーマッピングで整理されているか
  • インターフェイスを意識して、各機能の依存は十分に考えられているか

内容のサマリー

プロダクトバックログ、スプリントバックログ、READYの定義は上でも書いたとおり あと細かいが - チームにデザイナーがいる場合:デザイン完了してREADY状態 - ミドルウェアやサードパーティ何使うかの選定:Howの部分なのでチームメンバーがやる

あとPOの手前に事業としてマネタイズ、KPIどうするというプロセスがあるが、そこはビジネスアナリストが専門でやる。誰がスクラム的に担当になるかわかっていなかったのでスッキリした。

dailyScrumはとりあえず進捗が見えづらい時、意思疎通で問題が起きている時のカンフル剤、あととりあえずアジャイルだしやってみるかというのでこれまでやってきたが、理想的なのはオールブラックスのハカ。士気を上げてチームでゴールに突進するという意思を統一すること。これまでdaily割とのそのそやること多かったのでここは反省。。。

プランニングポーカーやる時にPOは加わってはいけない、あくまで仕様、要件を説明する係。あと細かすぎる資料、ドキュメントが増えるとポイントは上がる傾向にあるので注意

ユーザーストーリーマッピングはスクラムの最初にやるもの

  • プロダクトビジョン
  • コンポーネントゴール
  • フィーチャー
  • エピック
  • ストーリー

の順に分解されていく。直近の部分は細くして、未来の部分は割と適当にビジョンだけだったりする。 またスクラムの最初でとりあえずざっくりエピックにポイントをPOの独断でふってポイントの全量を出す。 大体わかると思うが、超あてずっぽう。とはいえ仮説でも出すことが重要 大体３イテレーションくらいやるとズレがわかってくる。そこで再度見直しを行って、正確なバーンダウンチャートが見えてくる。

アジャイルとウォーターフォールの違いは色々あるがしっくりきた表現は計画に対する誠実さ。ウォータフォールはあたかも未来が正確に見積もれているふりをする。 ただスクラムが全面的にいいというわけではなく、結構組織を選ぶ。導入が大変というのもあるし、スクラムに必要な正直、誠実、透明、イノベーションへの意思を持っていないとうまくいかない。

内容はかなり満足 ただプロダクトを考えてチームでユーザーストーリーマッピングしてみようという割と大きめのワークがあったが正直微妙だった

  • 時間短いし、６人とかで遠慮しながらマッピングしても全然スピード感でない
  • プロダクト考えるというところで、本質とは違う奇抜なアイデア出し的な方にそれてしまうことがある

参考

研修のスライドの中で紹介があって、ただただ最高だった