プロダクトオーナー(PO)の考えるべきところ、もしくは「はまりがちな罠」について、いくつかのトピックを思いつくまま書き出してみました。悩めるPOさんの手助けになれば幸いです。
- 序盤戦、中盤戦、終盤戦の戦略
- 一番美味しいアイデアがでる可能性に備えるために
- 引き継ぎにはコストがかかるので人を追加すると遅くなる
- システムは利用者の数に従って情報が増えるので、リリース後が最も大変な時期になる
- システムはハーモニーなので、継ぎ足して別の人を追加すると繋がらない
あ、よければアギレルゴの認定スクラムプロダクトオーナー研修もご検討ください。著名な講師が通訳付きで教えてくれます。
1. 序盤戦、中盤戦、終盤戦の戦略
「序盤で基礎を作って、作るスピードが上がってきたら、重要なところを作り、最後はウリになるものを作りこんでリリースする。」一見、良さそうに見える戦略ですが、これは結構危うい計画になりがちです。ユーザーから見れば、ある程度理解したタイミングで、本当に欲しいものが提示される、というのは購買行動につながりやすいのですが、作り手側の戦略としてはうまくいきにくいのです。なぜかというと、序盤の基礎のところで、本当のウリは意識しておかないと、後付けでつけようとしてもうまく作れない、ということが起こるからです。
プロダクトオーナーとしては、顧客に対しても、開発者に対しても、同じようなストーリー戦略になってしまいがち、というのはわかるんですが、まず、作り手と顧客は別物であるという理解が重要です。作り手には完全情報を提示し、顧客には順を追ってストーリーを提示するように心がけましょう。開発者をびっくりさせても儲かりません。
これは『ユーザーストーリーマッピング』に出てくる画像ですが、横方向がユーザーの使う順序、縦がリリースの順序になっています。これがユーザーストーリーマッピングというもので、プロダクトの全体像を表します。ユーザーの使い方と、構築の仕方をリンクさせて一枚絵にしているところが重要なポイントです。
まず序盤戦の内部リリースでは、技術的にちゃんと動くものができることを確認し、中盤戦でその機能を改善し、終盤戦はリリースのために必要となる、運用面やセキュリティなど、細かなところを調整します。この終盤戦は意外とやることが多く、プロダクトオーナーから見ると「思ったほどスピードが出ない」と考える要因になりがちですが、(技術に詳しくないプロダクトオーナーの場合に特に)中盤のスピードを重視してしまって、終盤のタスクが膨大になってしまっている例をよく見ます。もっと開発者と話し合って、作り手の視点を学ぶ必要があるかもしれません。
現在では、競争がないソフトウェアというのはほとんどないので、同じリソースを投入するならば、賢く使う必要があるかと思います。やるべきことを見える化して、序盤は動くこと、中盤は役に立つこと、後半は問題が出ないことを確認する必要があるかなと思います。「自信をもってリリース可能か？」は作っている開発者にしか判断できません。一方で開発者も経験不足でわからないことも多いので、とにかく出して社会勉強するしかないケースも多々あります。
プロダクトオーナーはまずなによりも、全体戦略を開発者たちに示しておくべきです。そのうえで抜け漏れがないようにプロダクトバックログを整備し続けます。コンセプトだけでなく、周到な構築計画と、柔軟な対応、生き残るためには、すべてが必要になります。
2. 一番美味しいアイデアがでる可能性に備えるために
1番でちゃんと全体像をみて戦略を立てることをお勧めしておきながら、逆のことを言うようですが、実際に一番売れるアイデアが出てくるのは、顧客にフィードバックをもらってからであることは間違いないです。一番賢くなっているのは、時系列的には最後だからです。おそらく、今日思いついたアイデアよりも最良のものを明日思いつきます。ですので、私たちは常に変化に適応できるようにしたい。
そのためには、プロダクトバックログをクリアに運用する必要があります。その新しいアイデアを実現するためには何をあきらめなければいけないか。これがはっきりしていれば、常に新しいアイデアを最優先で実行するためのコストが分かります。一方で、新しいが大したことがないアイデアを優先するあまり、1番で出てきた後半戦をないがしろにして、リリースされるソフトウェアの品質を下げてしまうことになると、障害とクレームに苦しんで全然前に進めなくなるプロダクトが生まれてしまいます。実際、そういうプロジェクトをいくつも見てきました。(私はそういうの作ったことないけど)
早く動けるようにするためには、現状をちゃんと整理して、コードもきれいにしておく必要があります。
『ユーザーストーリーマッピング』より
3. 引き継ぎにはコストがかかるので人を追加すると遅くなる
これはブルックスの法則として有名な話ですが、人員の追加は、その人が活動できるようになるまでに時間がかかり、また、それを教えるためにチーム全体のスピードも一時的に落ちます。ですから、プロジェクトの終盤で人を追加するとか、遅いと思ったのでテコ入れのために人を増やす、というのは、実はもっと完成を遅くしてしまいます。
1.新たに投入された開発者が生産性の向上に貢献するまでには、時間がかかる。
2.人員の投下は、チーム内のコミュニケーションコストを増大させる。
3.タスクの分解可能性には限界がある。
人員の追加に意味がない、というつもりはありません。そこには教育コストがかかる、ということを認識して進める必要がある、ということです。チームが最も賢くなった後半であれば、最も上手に教育できることも間違いないと思います。そのコストを上手に配分していく必要があるでしょう。
以前、引継ぎについて、10年以上悩んだ結果、気が付いたことは「手順は引き継げるが、スキルは引き継げない」です。スキルを引き継ぐためには、作業の背景にある判断基準を学ぶ必要があり、すべてをドキュメント化することは難しい領域です。これは一緒に作業をすることで、長い時間をかけて引き継いでいくしかないかな、と思います。
4. システムは利用者の数に従って情報が増えるので、リリース後が最も大変な時期になる
従来、システムを作るというのは、完成してリリースに向けて作る、という印象だと思いますが、実際に最もユーザーが使うのはリリース後になります。長年プロダクト開発の分野で仕事をしましたが、一番情報量が増えるのは、実はリリース後なのです。ですので、使ってもらいながら、「もっと使ってもらうためには何が必要か」という情報を得ることがビジネス上とても重要なのです。
従来型のプロジェクトだと、リリースしたら人を減らす戦略をとってしまいがちだと思いますが、その結果、ほとんどの業務ソフトウェアが、利用者が使い始めた後に「全然なおせない」という状況に陥ります。これでは役に立ちません。しかも業務はかわっていくのに、ソフトウェアが追いつけないなんて、どこが「ソフト」なんでしょうか。
プロダクトの課金体系がライセンス販売にせよ、サブスクリプション契約にせよ、継続的に支払いを増やしていただくことが、ビジネスにとって有利であることは間違いありません。ですので、実際に使っていただいたお客様の意見を聞いて、もっと使い続けてもらうための施策をうつべきです。本気で使ってくれているお客様のクレームには一切のリップサービスがありません。ですので、こちらも本気で対応をして、信頼を積み上げることが、次の契約につながる、と考えてみましょう。
繰り返しになりますが、本当に大変なのは、リリース後なのです。継続的に問題を解決しない業者を信頼する顧客はいません。
5. システムはハーモニーなので、継ぎ足して別の人を追加すると繋がらない
クラウドベースのオープンシステムが一般的になり、うまく他者を利用することで素早く安くリリースできるようになりました。一方で、顧客から見れば、サービスしているのはあなた(の会社)です。これは運用にとってみれば非常に難しい問題を起こしがちです。「こんな問題が起きてるんですが」「いやうちが作って部分についてはお答えできません」これでは顧客に信頼されません。システム間が接続され、自分が作っていない部分が増えれば増えるほど(つまり効率が高まるほどに)、こうしたクレームがどんどん増える傾向にあります。
では、このクラウド時代に我々はどうするべきなんでしょうか。重要なのは、顧客の代わりになってちゃんと調べるエンジニアを育てておくことです。できることならば、顧客が困る前に、その問題が起きないように作りこみます。これは一朝一夕ではできません。連携するシステムが多くなればなるほど、学ぶべきことが増えていきます。そして、時間がかかります。米国Microsoftの河野通宗さんが、このように語ってくれました。
クラウドって、いろんなサービスの大きな集合体なので、自分のところを（ダウンさせずに）動かし続けるしかないんです。ほかのサービスが一時的にダウンしても、当たり前に動かします。ネットワークが切れたり、毎日どこかが壊れるんです。そういう中でも毎日動かしつづけるためには、テレメトリの運用、あとは、そういうのをあらかじめ全部考えた上での運用方法の確立というのは、絶対に必要です。
ある時点でなにかがちゃんと動いていても、次の週にはもう前提が変わっているんです。なので、完璧というのは世の中に存在しない。どうやってシステムを動かし続けるかには、答えはないんですけど、その中でやり続けることが、すごく楽しい。たぶんご理解していただけると思います。
内製化でエンジニアを育てる価値は、まさにここにあると思います。逆に、どれだけ詳しく見えても、ベンダーのエンジニアはその対象領域の教育しか受けられません。ですので、あなたの問題を解決できるのは、あなたと苦楽を共にしているエンジニアだけなのです。3番の引き継ぎのところでも書きましたが、急には育ちません。
業界には詳しいふりをする人がたくさんいて、困っていると甘い声ですり寄ってきますが、だいたい契約後に幻滅することになります。そんなに都合の良い話はないのだ...というのを学習するタイミングがプロダクトリリース直前だと、もう取り返しがつきません。
プロダクトオーナーは収益性の最後の砦として、ちゃんと責任を取っていくべきロールです。あなたの後ろに人はいないので、ちゃんと判断をしていく必要があります。判断を間違えば、プロダクトの収益性が低下し、チーム全体が危機に陥ります。永続的なものなど何もありませんが、プロダクトオーナーの見識と、戦略が成功のカギになることは間違いないところです。オープンに相談しながら、一つ一つプロダクト仮説を検証して、顧客からの信頼を積み上げましょう。
おわりに
いかがだったでしょうか。プロダクトオーナーの考えるべきところについて、少しケースを挙げてみました。全体の戦略については、繰り返しになりますが、こちらの本をお勧めしたいです。
技術プラクティスや戦術については、監修でお手伝いした本がもうすぐ出ます。チーム戦術から運用までカバーしているので、プロダクトオーナー(PO)にとっても良いガイドブックになると思います。
プロダクトについてはだいたい、馬田さんのスライドを見とけばいい気がします。
