拾って落とすエンジニア活動ログ

各種技術や周辺知識のTIPS、振り返り

スクラムとアジャイルの現場でPOをもやっと引き継いだ感想

ここ1年くらい、スクラムチームの中でプロダクトオーナーを担当しています。

yb300k.hateblo.jp

上記みたいなことをしていた3年前にはスクラムチームのかけらにも参加していませんでしたが、縁ですね。

基本的には社内利用システムのプロダクトオーナー（以下PO）なので、システムの内容については触れませんが、気づいたことの共有です。

 

スクラムチーム参加～今までの大きな流れ

  1. システムの立ち上げから関わっていた上司からPOを代わりにやるように言われた
  2. システム利用ユーザー拡大

それぞれのタイミングで、こうしておけばよかったを振り返ります。

 

１．初心者POの立ち上がり時の注意

途中からメンバーとして横に居て会議体に参加していたこともあり（あまり役割は明確ではなかったがあえていうならPO補佐？）、それほど引継ぎらしい引継ぎもなく、スクラムのイベントでしゃべる人が上司から自分に変わりました。

早いうちにやっておけばよかったこと

  • プロダクトの目的・価値について知る

引継ぎ当時は「バックログに順位をつけて開発チームに渡すのがPO」「プロダクトの仕様を決める人」というレベルの知識しかありませんでした。

（たぶん、あるあるだと思います。引き継がれる人、要注意）

バックログのリストもあるし、ユーザーの要望もどんどん出てきていたのでこれを管理し続ければよいのだな・・・と思っていたら、あとで「開発していることが小さすぎる」と指摘を受けました。

企業の中で、企業のビジョン・ミッションに直結しているプロダクトのPOであればわかりやすいと思いますが、社内利用システムになると、おそらく企業のビジョン・ミッションそのものではなく、コストを下げるとか、品質を上げるなど間接的に貢献するものになっているはずです。

「利用している従業員の満足度を上げる」というのが目的であれば、ユーザーの要望を実現することがプロダクトの価値になりますが、それは目的ではありませんでした。

インセプションデッキの形にでもなっていればわかりやすかったのでしょうが、それもなかったです。作ったほうがいいけど、結構パワーいりますよね・・

 

優先順を付ける基準が明文化されておらず、優先順位付けに恐ろしく時間がかかり、とにかくやってみては開発チームに伝えるスプリント計画の場で前任者に違うといわれることが繰り返されました。

目的・価値の話ともつながりますが、目的・価値あってのバックログの優先順だなと後で気づきました。目的・価値が明文化されておらず、その合意形成に時間がかかるのであれば、当座の作業の時間を減らすというために、先に優先順位の基準ガイドを作るのもいいかもしれません。

なお、自分のところでは、いったん「利用者が事故・ミスを起こしやすい挙動や、顧客に影響の出る恐れのある不具合修正」を優先１とし、その後「ステークホルダーにコミットしている大きな機能拡張の実装」を優先２とする・・・といったざっくりした基準を作りました。

ずいぶん粗いですが、ないよりずっとマシになりました。

なお、BacklogというSaaSをうちのチームでは使っているのですが、この課題優先順メンテツールを作ったことは、POのイライラ減及び作業時間短縮に貢献しました。

 

  • プロダクトオーナー研修に行く

ScrumBootCamp は読んだことがありました。が、そんなもんです・・・スクラムチーム全員そんなレベルでやってました。社内システムだし、、小さいシステムだし、、でも、行くと気づきがありますし、相談仲間も増えます。ちょっとお高いですがぜひどうぞ。

ちなみに、自分は Scrum.Incの認定プロダクトオーナー研修に行きました。

アギレルゴコンサルティングの研修と迷いましたが、開発部署の方でもスクラム熱がもりあがっていて、Scrum.Incのスクラムマスター研修を受講してきてよかったと評判になっていたのと、開催スケジュール見合いで、Scrum.Incにしました。

研修から帰ってくると、ここは違うところだな（それが絶対に変えなくてはいけないことかどうかは、状況次第ですが）ということに気づくことができます。知らないと気づくことができません。

例えば、POが実装方法にまで口を出すとか、スクラムマスターがA君これやってB君にはこれと割り振るとか、仕様が詰まっていないから優先順位1位だけど決まるまで後回しとか・・・・

気づいたことに対して、トップダウンなPOなら原理主義的に「すべて研修通りにやれ！！」という手もありますし、「研修ではこうだが意見は聞く、ベストな方法を見つけよう」とか対応策はいろいろです。

本も研修も重い！ならスクラムガイドをみんなで読むのもいいでしょう。

勉強会もいいきっかけになりました。

アジャイルチームを支える会　https://agileteam.doorkeeper.jp/

プロダクトオーナーシップ研究会　https://postudy.doorkeeper.jp/

 

Web上にもいい記事があります。Qiitaやはてなブログで「アジャイル」や「スクラム」で検索するとたくさんあります。

 

２．利用ユーザー拡大とプロダクト目的の更新

ステークホルダーとの合意に基づき利用組織を拡大し、そのためにプロダクトの機能拡張を行いました。

事前にやっておけばよかったこと

  • 利用開始後の開発スケジュールをユーザーに共有

新規参加した利用者から「こんなに早く機能が変わっていくなんて運用がまわらない」という声が上がるようになりました。 

新しく参加してきたメンバーは、これまでフルスクラッチ、ウォーターフォールで作られたシステムを使っていたメンバーで、要件定義に1か月、開発に1か月、テストに1か月、といったスケジュールで動いていた人々です。2週間で出した要件が本番リリースされるということは想定外だったそうです。

また、チャットツールで簡単な周知を流してリリースという流れにも違和感があったようです。

相談の結果、SPRINTは2週間でまわすが、新規利用メンバの運用に影響が出る機能については周知会で共有し、テストが完了した後＝1か月単位リリースに変更しました。（おかげで開発チームはリリースの管理が煩雑になりました）

このやりとりで相当精神力を削られたので、利用ユーザーに開発スケジュール・コミュニケーション方法を伝え、ルールを握れておけばよかったと思います。

といっても大きなリリース前にはどうしても利用機能のテストや修正でバタつくので、なかなかその後の話なんてできないのですが・・・

 

  • プロダクト目的の更新

新しい利用ユーザからの機能要望に「このシステムはそういう使い方をするものではないです」という回答をすることが増えてきました。

また、仕様の複雑化を避けたい開発メンバーに対して「こういう機能を実装しないと新しいユーザーが使えない」という話をすることも増えました。

これが結構時間とられています・・・

POを引き継いだ時にも目的・価値の話がでてきましたが、大きな機能拡張や、ユーザー拡大のタイミングでも見直す必要があります。

企業として方針が変わった（「コスト」から「品質」へのシフトや、このシステムをこう活用して売上拡大に使うぞ等・・・）とか、大きな事故があり注目されているとか、ステークホルダーが異動したとか、連携システムが増えたとか、そういったタイミングでプロダクトの目的・価値が、引きずられて変わっていることがあります。

そのたび握りなおす、共有する、ということをしていきたいと思います。

 

まとめ

プロダクトオーナー引継ぎ後にぶちあたった壁は　プロダクトの目的・価値　の話ばかりでした。今後POを引き継ぐときには明文化からやろうと思います。

残念なことに曖昧なシステムを既に引き継いでしまったPOの方は、対症療法的に手を打って時間を稼ぎながら、問題の根っこに手を付けていきましょう。

 

参考になれば幸いです。