できるプロダクトオーナーの仕事術【前編】

“Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.”

By George Smith Patton, Jr

“どうやるかを教えるな。何をするかを教えろ。そうすれば思いがけない工夫をしてくれるものだ。”

アジャイル開発におけるプロダクトオーナーは、プロジェクトの舵取り役と言ってもいい重要なロールである。システムの構築は開発チームに委ねつつ、全体の方向性と将来のリリースに向けた取り組みを決定し、創造するビジネス価値の最大化が求められる。
言い換えれば、良質なシステムを構築することと同時に、ビジネスに寄与する価値あるものとして創造しなければならないということである。もちろん、これを実現することはプロジェクトメンバー全員のミッションであって、プロダクトオーナー一人で実現するものではないが、舵取りを担う役割として大きな意味を持つのがプロダクトオーナーと言える。
そのためには、業務の理解、システムの理解、ステークホルダーとの連携、チーム内の意思疎通など、様々な知識とスキルが必要であり、また多くの判断を適切に実施しなければならない。

本稿では、最も重要なタスクであるプロダクトバックログの作り方を中心に解説し、プロダクトオーナーのあるべき姿を探ってみたい。

スプリントを開始する前に、プロダクトオーナーはバックログの作成に着手する。

多くの場合、この時点では要件を全て洗い出し、詳細に定義することはできないため、ウォーターフォール型のように要件一覧や機能一覧を作ろうとしてもうまくいかない。
最初に必要なことは、”何を作るか？” ではなく、 “何をしたいか？” を明確にしていくことである。
例えば、製品の販売管理を扱うシステムであれば、以下のようなストーリーが挙げられる。

これらは、機能を説明するのではなく、業務での利用シーンを洗い出し、システムのユーザーがどのような振る舞いを行うのかを列挙すればよい。 　振る舞いを書き出すことで、構築したいシステムがどのような使われ方をするのかが明らかとなり、作りたいシステムが明確になってくる。 ・ストーリーにシステムのイメージを重ねる 　利用シーンがある程度明らかになってきたら、ストーリーにシステムの実装イメージを重ねていく。これも機能を説明するのではなく、振る舞いをシステム利用シーンとして具体化していく。 　先程の例であれば、

といった形になる。 それぞれを個別のバックログとして作成し、さらに詳細に具体化していく。最終的には、画面の入力フィールドやボタンまで落とし込めるのが望ましいが、必要に応じ開発チームやITの知見がある人の協力を得ながら作成すればよい。また、開発チームが成熟している場合は、詳細な落とし込みを行わなくても要件を理解し、開発できる場合もあるが、できあがったシステムの受け入れをすることもプロダクトオーナーの役割なので、十分な実装イメージを自身でも持っておくほうが、認識齟齬を避けられる。 　プロダクトオーナーは、これを繰り返してスプリントを進めていく。重要なものを優先して詳細化し、1-2スプリント分の詳細化は常にできているようにしたい。

開発が進んでいくと、当初想定から計画差異が生まれてくる。途中で要件の追加や変更があったり、開発ボリュームが想像以上であったり、逆に開発スピードが速く予定よりも早く進むこともある。この場合、プロダクトオーナーは、リリース計画の見直しを行う。開発するバックログを管理し、リリース日を決定する責任を持つプロダクトオーナーは、状況に合わせて、リリース日程の変更やリリースまでに実装する機能を調整し、全体の整合性を図る。

この時、プロダクトオーナーは開発することだけを考えるのではなく、ビジネス価値を意識したリリースを計画しなければならない。リリースすることがビジネスにとって大きな意味を持つのであれば、多少機能を削ってでもリリース日程を守ったほうがよい。一方で、十分な機能が実装されていなければ、業務への貢献ができない場合は、リリース日程を調整してでも、機能の実装を死守すべきである。

自社プロダクトオーナーを強化したい場合は、こちらをご覧ください。

次回は後編として、非機能要件、品質向上、リリース計画において、プロダクトオーナーがプロダクトバックログ作成時の留意点を紹介する。

できるプロダクトオーナーの仕事術【後編】

こちらは「できるプロダクトオーナーの仕事術」の後編になります。最も重要なタスクであるプロダクトバックログの作り方を中心に解説し、できるプロダクトオーナーになるための基本の仕事術を続...　続きを読む