はじめに
こんにちは、ビズアシスタントオンライン（以下、ビズアシ）というサービスのエンジニアをしている山田です。
みなさんこちらの記事はきっともう読んでくれてますよね？
そうです。ビズアシはPO（プロダクトオーナー）と愉快なエンジニアたちのパーティーでプロダクト開発に携わっています。
少し前に山あり谷ありの冒険をひとつ終え、ついにタイムカードアプリをリリースした私たちですが、なんと7月に現POが産休に入ります！
その間わたくし山田がPO代理を務めさせていただくこととなりました。 5月半ばから引き継ぎが始まり、まだ一ヶ月程のぴよっこPOです。右も左も分かりません、、、
当記事はそんなぴよっこPOの奮闘記、、、ではなく、頭の中の話になります。
PO代理を引き受けた経緯
なんでエンジニアなのにPOやることにしたの？ という疑問がきっとあると思います。
端的に言うと、 開発は手段のひとつ、何を達成するかが先にあるのであって、その部分を見たい、知りたい、興味ある と思っていたからです。
元々前職では営業職をやっており、異動という形でエンジニアになりました。 何を売っているかを理解した上で開発業務に携わっていたということや、各部署に散らばっている同期からよく話を聞いていて、興味関心がたんに開発業務だけという感じではなく、事業全体に向いていたというのが、背景としてありました。
とはいえ、クラウドワークスに転職して以降は、事業部のことをよくは知らないまま開発業務に携わっていて、それはそれで性格的には向いているなあと改めて思うこともあり、やりたいことよりできることで貢献するという観点だと、やっぱりエンジニアで生きるのが良いのかなーとも思ったりもします。
まあ、ひとまずやってみよう！ やってみた後にちゃんと振り返って、今後のキャリアを考える糧にしよう、そんな風に今は考えています。
これからどうしていこう
いまはぴよぴよ現POの後ろをついてく形で、産休に入られた後も従前の通り業務を遂行できるようになろう、というところを第一に動いています（そういうつもりです）。
ただこうして執筆する機会をいただき、「そもそもPOとは？」という疑問をそのままにしてはおけないな、ということでここでしっかり理解しておきたいと思います。
POってなに？
PO（プロダクトオーナー）とは、スクラムにおける一つの役割とされています。 スクラムガイドには以下のような形で定義してありました。
プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。
ニュアンスは分かりますが、「プロダクトの価値の最大化」というのは、少し難しいですね。 プロダクトが誰にどういうふうに使われるかを理解しないと、プロダクトの価値を最大化させることは出来ないと思います。 あくまでプロダクトに対してのみ責任を持つ、というのはそれはそうですが、その実、事業全体のことをある程度理解してないといけないですね。
プロダクトオーナーは、プロダクトバックログの管理に責任を持つ 1 人の人間である。プロダクトバックログの管理には、以下のようなものがある。 - プロダクトゴールを策定し、明⽰的に伝える。 - プロダクトバックログアイテムを作成し、明確に伝える。 - プロダクトバックログアイテムを並び替える。 - プロダクトバックログに透明性があり、⾒える化され、理解されるようにする。
上記の作業は、プロダクトオーナーが行う場合もあれば、開発チームが行う場合もある。いずれの 場合も、最終的な責任はプロダクトオーナーが持つ。
何をやるかと、その優先順位を決め、全員に公開する、ですね。 端的で分かりやすいです。
プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重し なければならない。これらの決定は、プロダクトバックログの内容や並び順、およびスプリン トレビューでの検査可能なインクリメントによって⾒える化される。
プロダクトオーナーは 1 ⼈の⼈間であり、委員会ではない。プロダクトオーナーは、多くのス テークホルダーのニーズをプロダクトバックログで表している場合がある。ステークホルダー がプロダクトバックログを変更したいときは、プロダクトオーナーを説得する。
これはPOを置くということはそうなるよね、というところなんですが、このあたりが守られてないとどうなるか考えてみると、言わんとすることがより一層理解できるような気がしました。
- 各人から「なるはやで！」って仕事を押し付けられる
- エンジニア個人宛に依頼が来たりする
- でもチームに展開されず、握り潰されたりする
- あるいは勝手に引き受けてしまい、残業する羽目になる
などなど。「勝手なことしないで！！」って言いたくなりますね。
そっか〜。POなんとなく分かった（気がする）！
気づいた課題点
POの役割をざっくり理解したところで、ひとつ大きな課題がありそうだなと思うに至りました。
何を開発するか、優先順位を決める指針って何だろう？ ということです。
現状だと、各チームからプロダクトへの要望を出してもらい、その中から何をどの順番でやるか？というボトムアップ的なバックログの決め方をしています。
ひとつひとつの要望に対して、たしかにこれはやった方がいいなとは思うのですが、いざやると決めたものを並べると、その背景に一貫した思想があるかよく分からず、果たして価値を最大化するように意思決定ができているのか自信がないです。
事業部全体で目標なりを決めて、それを達成するためには？という視点でトップダウン的にやることを決める、という方法を取った方が良いのかなという気がしています。
これはまだ十分に吟味されていない素人目線の意見でしかないので、POやマーケ関連の勉強をした上で咀嚼する必要があるなと感じています。
どこかで壁打ちお願いしようっと。
現状の整理
ではもし仮に明確な指針を立て、それに基づいてバックログの管理をしようとなると、業務知識が全然足りていないと認識しています。
- そもそもビズアシってなんだろう？
- 提供する価値は？
- 強みは？
- 目指すものは？
- 今はどういう課題があるんだろう？
分からないことだらけです、、、
それでもPO業務に関わる中で、断片的にではありますが、少しずつ情報が入ってきてはいます。 いずれそれらを線にする必要があるのですが、一旦自分なりに大事そうだなと思ったものをいくつか挙げてみます。
未だ「点」でしかないので、脈絡がないように見えるかもしれません、、、
「ビズアシは吉野家」
これはビズアシの事業部長の言葉で印象に残ったものです。 吉野家の良いところというと、早い！お手頃！それでいて美味しい！というのがあると思います。
ビズアシは誰かに業務をお願いしたいが、採用するのはコストがかかりすぎる、そこまではできない、というクライアントさんに対して、クライアントさんの要望に合致する、業務を引き受けたいアシスタントさんを探すところから、稼働開始後までをサポートします。
たしかに採用するよりはコストは抑えられ、また求人を出して面接して採用するという手間も省けるので、早いです。 さらに、業務経験やスキルがある方がアシスタントとして入るため安心です。
これはすごく分かりやすくて、なるほどなーと思いました。
ビズアシの価値を高めようと思うと、「より早く提供するには？」「コストを上げずに品質を追求するには？」といった指針を作れそうです。
複数のお客さん
ビズアシというサービス自体、業務を依頼するクライアントさんと業務を遂行するアシスタントさんという二種類のお客さんがいます。 そしてプロダクト開発的には、そこに事業部のメンバーも加わり、三種類のお客さんに対してシステムを提供する形になります。
少し前に、当社の別サービスであるクラウドログのプロダクトチームの勉強会に参加したのですが、クラウドログだとプロダクト = サービスであり、お客さんも大きく一種類なので、事業部の指針を少しは決めやすく、かつその指針をそのままプロダクト開発の指針に落とし込みやすい側面がありそうだなと思いました。
反面、ビズアシは三種類のお客さんの誰を優先するかとかも考える必要がありますし、事業部の指針に対して、ではプロダクトはそこにどう貢献するのが良いか、一度噛み砕いて考える必要も生じてくるでしょう。
またこれは極端な例で、基本的には双方win-winになるようにという話ではあるのですが、アシスタントさんとクライアントさんの利害が対立してしまう場面もなくはありません。 バランスを取りながらサービスを提供するのも少し大変そうだなと思った次第です。
まだまだ未発展
ビズアシで稼働中のアシスタントさんのフォローを担当するチームでは、激重スプレッドシートで契約を管理してたり、クライアントさん向けのシステムがなかったり、まだまだプロダクトが入れる余地がたくさんたくさんあります。
営業さんが手動で対応をしているのを見ては、なんとかしてあげたい！！！そう思うことばかりです。
ビズアシはフロンティア！！！まだまだこれからだぞ！
今後が楽しみです。心からそう思います。
まとめ
つらつら書いてしまった結果、手記のようになってしまいましたが、ぴよっこPOはこんなことを考えてるよってお話でした。
7月からは新生？パーティーでの冒険がはじまりますが、温かく見守っていただけると幸いです。 まずはスライムから。
We're hiring!
クラウドワークス社では、様々なポジションのエンジニアを募集しております。 ご興味のある方は、ぜひご連絡ください！
