ひよっこPOの1年目奮闘記 ～こんなこと大事にしてたってよ～
こんにちは！
株式会社クラウドワークスのPO（プロダクトオーナー）をしている あんみな です。
この記事は クラウドワークスアドベントカレンダー2020 17日目の記事 としてQiitaにも公開している（しかも見やすいと思われる）ので、よろしければQiitaでLGTM👍いただけると嬉しいです！
この記事を書こうと思った背景
私は27歳で2回目の転職、同時に営業職から未経験でPOに転身しました。
当時、自分がやりたい仕事に挑戦できることに心からワクワクしつつも、知らない世界に飛び込むことへの不安を少なからず感じていました。
自分にできるのかな、失敗したらどうしよう、みんなに迷惑をかけたら申し訳ない・・・と。
そんな当時の気持ちを思い出し、
・ビジネスサイドから開発サイドへのキャリアチェンジに興味がある・したけど不安という方々に、
・「意外と何とかなるもんだね」「自分もできるかも」と感じて頂き、
・挑戦の1歩を踏み出しやすくする
ことができればと思い、この記事を書かせていただきました。
ここでは、POにチャレンジした1年目の成長記録として、個人的に大事にしていたことをいくつかピックアップしています。
私の経験は会社や対象となるプロダクト、チームの性質等に依る部分が大きく再現性が低いため、内容をそのままトレースするというよりは、ゼロスタートから1年間でここまで気づきを得ることができた私の経験を通じて、少しでも背中を押すことができたらとっても嬉しいです！！！
はじめに
前提となる、私の経歴・業務内容・チームの体制はこんな感じです。
# 経歴
2016年卒、社会人5年目のうどん県出身PO。
・1社目：広告代理店で法人営業（1年6ヵ月）
・2社目：転職エージェントで法人営業兼キャリアアドバイザー（2年）
・3社目： クラウドワークスでPO（2年目） ←いまここ
27歳にして未経験POでクラウドワークスにジョインした動機は、
・3年半営業職を経験し、プロダクトを生み出す側に回りたいと思ったこと
・そのためにはビジネスサイドの経験をもって開発サイドに繋ぐポジションが適当と感じたこと
入社前の開発に関する知識は、
・「JavaScriptやRubyは書けないけどなんとなく知っている」
・「ウォーターフォールとアジャイルがあるんだなー」
程度でした。
# やっていること
冒頭で株式会社クラウドワークスのPOと自己紹介しましたが、私が担当しているのは同社のいちプロダクトである クラウドテック というフリーランスエージェント事業です。
「労働市場のバイアスを取り除き、選択肢の最大化を図る」
を事業ミッションとして掲げ、様々な働き方を希望されるフリーランスの方々の支援をしています。
私自身はプロダクトチーム（対して、営業やキャリアアドバイザーといったフロントラインを以下「事業部」と呼びます）に所属しており、クラウドテックのユーザーサイト・管理画面等の機能・施策全般における、
・機能開発・修正等の要件定義
・プロダクトチームのタスクプランニング
・想定効果試算・実績管理
等々の業務をしています。
# 体制
所属しているプロダクトチームの構成は以下。
・マネージャー：1名
・PO：2名（自分+1名）
・エンジニア：3名
・デザイナー：1名
多少の増減・入れ替えはありましたが、1年を通して大体こんな感じでした。
また、クラウドワークスは（コロナ前から）フルリモート・フルフレックス勤務のため、稼働場所・稼働時間は個人の裁量に任されています。
それに伴い、チーム内での完全同期的な会話（全員出社して会議室で話す等）はほぼなく、主なコミュニケーションは
・Slack
・GitHub Issue上のコメント
・Zoom、Google Meetなどのビデオ通話
で行っています。
その中で、朝会（30分）とプランニング（1時間）をそれぞれ週1回、振り返り（1時間）を月1回というペースで行っています。
では前置きはこれくらいにして、ここからはマネージャー・先輩PO・チームメンバーからのアドバイスや成功・失敗体験から学んだ「ひよっこPOが1年目で大事にしていたこと」をその効果と併せて箇条書きにしていきます。
あえて但し書きをしておくと、以下に書くことは私自身、未だ100%できているわけではありません。
（お恥ずかしながら、体感3～4割です。）
ただ、意識した時とそうでない時では明らかにパフォーマンスが変わります。
差し込み対応やトラブル時には、目の前のタスクを片付けることに意識が向いて「ごちゃごちゃ考えている暇はないのだ！！」と魔が差すのですが、振り返るとやっぱり以下のことは最低限押さえておいた方が長い目で見て幸せなのだと毎回気づかされます。
①役割を意識すること
# タスク分解ができる
POは前提で述べたような不確定要素の多い段階から課題の解像度を上げていくプロセスに携わるため、チームメンバーは勿論、事業部やマーケティング部などの別部門と常に連携が発生します。
その点、業務範囲の境界線があいまいになりやすい役割とも言えます。
POの役割を意識することで、例えば技術やデザインの具体的な表現や、施策の先にある事業部の詳細なオペレーションなどはそれぞれの部門のタスクとして切り分け、ボールを渡すことが可能になります。
# リリース目途の精度が上がる
前述のとおり、役割の違いを意識できれば、各タスクを専門領域とする部門にボールを渡すことができます。
するとタスクの見積もりはPOが行うよりも精度の高いものになります。
餅は餅屋の考え方です。
結果、各部門が算出した制度の高い工数見積もりからプロジェクト全体のスケジュールを引くことができるため、プロジェクトのリリース目途もおのずと現実的なものになります 。
また、進捗が遅れた場合も各部門から事実を回収できるため、遅延の原因究明が容易になり、リリーススケジュールの引き直しにおいても精度を高めることができます。
②課題感から認識を合わせること
# 使われない機能の実装を予防できる
クラウドテックでは、事業部がTrelloのカードに課題感を記載し、プロダクトに上げられる仕組みになっています。
その際、例えば「管理画面の●●項目の入力選択肢に、××と△△を増やしてほしい」のような手段ベースでカードが上がってくることも少なくありません。
（声を上げて頂くことは非常に非常にありがたいです！！）
ただこの場合、あくまで現行のオペレーションを効率化する手段であり、（クラウドテックの事業部は常にオペレーションの改善を行っている素晴らしいチームという前提で）オペレーションの変更ひとつで使われない機能と化してしまう可能性があります。
課題感の認識から合わせることで、オペレーションへの最適化ではなく、課題のソリューションとしての実装を考えることができるようになります。
# 手戻りが少なくなる
課題感が分からない状態だと、実装に取り掛かった後に仕様の不明点があった際、細かい確認の出し戻しが頻発します。
また、リリース期限が決まっているプロジェクトで心理的負担から無意識で思い込みや憶測で実装を進めてしまった場合、課題感が分かっていれば大幅な期待値とのずれは発生しにくいですが、そうでない場合は博打となり、品質の担保が難しくなります。
その点、課題感が分かっていれば理想との差分も認識でき、「ここはこうした方がベターだな」と機能リリース後のイメージをもって実装に落とし込む ことができます。
それにより、仕様の詰め切れていない箇所がある場合、早期に検知したり、仕様の決定自体をプロダクトチームに任せてもらったりすることが可能です。
結果「事業部の思っていたものと異なる機能」となってしまうリスクを軽減し、手戻りを防ぐことができます。
# エンジニア・デザイナーからアイデアが出やすくなる
課題に関する解決策は一通りではありません。
さらに、技術的な実現の可能性は、実装者であるエンジニア・デザイナーが一番よく理解しています。
エンジニア・デザイナーに課題感を共有することで、現実的な表現方法の範囲で解決策を提案したり、それぞれが仮説に基づいてたたきを作ったりすることができ、結果的に事業部やPOが考えていた仕様よりもより良い機能となることが多々あります。
# エンジニア・デザイナー自身がプロダクトへの貢献を認識できる
「エンジニアやデザイナーから見て、自分の作ったものがプロダクト全体にどう影響を与えているのか、どれくらいの成果をもたらしたかが見えづらい」という意見は、メンバーからよく聞こえてきていました。
そこで、プロダクトチームでは各Issueについて大元にある課題感の調査・ヒアリングを行い、各機能実装後の想定効果（売上総利益）を金額換算しました。
・業務効率化の機能 ：1作業当たりの工数 × 件数 × 対応人員数 × 人件費
・業績upに繋がる機能 ：（例）登録者数 × 決定率 × LTV
といった数式です。
これにより、（保守・運用・リファクタリング系のIssueは換算が難しいものの）機能追加・修正系の実装がプロダクト全体にもたらす効果を定量化することができました。
また、実際にエンジニア・デザイナーからも「これは効果が大きいから優先的にやりましょう」といった貢献度の実感に基づいた意見をもらえるようになりました。
こうした実装の貢献度（＝影響や成果）を可視化するには、ただ仕様を固めるだけではなく、課題感の共有が必須となります。
③ミーティング時はドキュメントを前提とすること
# ミーティングの生産性が上がる
前述のとおり、プロダクトチームの普段のコミュニケーションは非同期が前提となっています。
その中で発生するプランニングやIssueについての個別相談などといったミーティングは、アサインメンバーの時間枠を押さえて行う貴重な同期的コミュニケーションの場です。
ある程度方向性がまとまりやすい課題やチーム内で完結する疑問点はメッセージやその場のSlackコールで解決できます。
反対に、事業部のメンバーもアサインする必要がある時や課題の粒度が大きい場合は上記のミーティングを活用し、ブレスト的なアイデアの発散や、各部門からの課題共有・リスク出し・仕様確定等を行います。
このような特性から、事前にドキュメントベースでアジェンダ（課題背景、話したいこと、今日のゴール、事前に見えているタスク、参考資料等）を共有することで、
・本題から話すことができ前提説明の手間がかからない
・参加者が事前に考えを整理しやすくなる
・過去実装の仕様などを調査するリードタイムが確保できる
といったメリットが生まれ、ミーティング中は意見出しと整理に集中できます。
# 内容が散らかりにくい
ブレストや粒度の大きい課題を扱う特性上、話が広がりすぎて「あれ？結局どうすればいいんだっけ？」と収拾がつかなくなることがあります。
またプロダクトチームと事業部の人員を同じミーティングにアサインする場合は前提の認識から大きな相違がある場合も少なくありません。
そのため、ミーティングは事前共有のドキュメントベースでゴールを意識しながらファシリテーションを行うことで進行上の散らかりを防ぐことができます。
また、スプレッドシートやIssueのURLなど、別紙や補足となる情報も全てドキュメント内に記載することで、「いつどのSlackチャンネルで資料もらったっけ？」とSlack迷子になることもありません。
しかもアサインメンバー全員が同じ情報にアクセスできるため、仮に数日後にアイデアが思いついた際にも非同期でコメントを残すことができます。
このような点で情報の散らかりも防ぐことができます。
④出来るだけ小さくリリースすること
# バグの発生原因の究明・ロールバックがしやすい
アジャイルの開発手法をとっているためそもそも一つひとつのリリースの粒度はそこまで大きくありません。
ただ以前はGitHubのRelease PR一つにつき10以上のIssueが紐づいている状況でした。
そうするとバグの発生原因の特定や、機能ロールバックを同じ単位で行う必要がありました。
クラウドテックのプロダクトチームは人員が少ないため、 バグ修正やロールバック対応などで時間を取られていると、通常の開発の進捗に大きく影響します。
こうした背景もあり、エンジニアの提案をもとに
・毎日朝と昼の2回リリースを行う
・加えて必要な時に適宜リリースを行う
という運用を固めました。
現在はRelease PR一つにつき平均1～2 Issue、多くとも5 Issue以下となっており、バグの原因究明やロールバック関連対応にかかる時間を5分の1程度に抑えることができています。
# やったことが分かりやすい
細かなリリースにより、Issueのクローズ頻度が高まります。
そのため、リリース待ちのIssueが抜けなくて体感的に疲弊したり、1週間前にレビューでLGTMになっていたIssueがまだリリースされておらず急いでリリースする、といった現象がなくなりました。
また以前の運用の場合、一度にリリースする機能が多いため、事業部に周知する工数を鑑みPOが抜粋して事業部へのアナウンスを行っていました。
現在はリリースされた機能をエンジニアからリアルタイムでSlackに投稿することができているため、事業部から見てもやったことが分かりやすい体制に近づいていると感じます。
（エンジニアの皆様いつもありがとうございます！）
# 振り返りの接点が増える
これは 2 の副次効果ですが、月1回の振り返りの際にその1ヵ月でリリースした機能を洗い出しやすいため、各機能について振り返る接点を持てるようになりました。
（以前は各々の記憶が頼りでした・・・）
また「課題感から認識を合わせること」の項で紹介した定量換算の運用においても、目標と実績の差分が明確になり、「来月はこの想定実績●円の機能をリリースして差分を埋める」といった会話ができるようになっています。
そういった意味では、「細かくリリースし振り返りを積み上げることで、チームの成長機会が増えている」と言い換えることもできます。
まとめ
以上が、この1年間を通して私が大事にしてきたことです。
振り返ると、先輩POの見よう見まねでIssueの作成やプランニングをしていた1年前は「やりかたは本当にこれで合っているのか？」と 「正解か不正解か」の物差しで仕事を進めていました。
しかし、「良いプロダクトのために自分に何ができるか？」を考えられるようになった今、改めて少しずつ成長を感じることができています。
今後は体感3～4割のところから再現率を安定させること、また上記のやり方を疑い続けて常にベターを目指すことを意識して、次の1年もさらなる成長をしていきたいと考えています！
最後に
株式会社クラウドワークスでは クラウドテックのエンジニア を募集しています！
こんなひよっこPOの成長を全力で支えてくれた素晴らしいマネージャー、先輩PO、エンジニア、デザイナーと一緒に良いプロダクトを作っていきたい！と感じて頂けましたら、是非是非ご応募ください！
今回は「ビジネスサイドから開発サイドへのキャリアチェンジに興味がある・したけど不安」という方々に向けて書かせていただきましたが、そういった方がご活躍を積み、いつか一緒に働ける未来が来ることを心から楽しみにしています！
この記事が気に入ったらサポートをしてみませんか？