プロダクトマネージャがアジャイル開発に取り組む際のポイント

プロダクトマネージャがアジャイル開発に取り組む際のポイント

先日、メンバーズエッジカンパニー主催でアジャイル開発をテーマにしたウェビナーを開催しました。
Sansan株式会社 Eight事業部でプロダクトマネージャとしてご活躍されている片芝亮友さんをお招きし、「プロダクトマネージャがアジャイル開発に取り組む際のポイント」というテーマで登壇していただきました。

多くの方にご参加いただき、非常に好評だったウェビナーの内容をほぼそのまま記事にまとめていますので、都合が合わなくて参加できなかったという方もぜひご覧ください。

アジェンダ

  1. 片芝さんのご経歴
  2. Sansan株式会社と各プロダクトのご紹介
  3. チームとプロセス
  4. 意識しているポイント
  5. Q&A

片芝さんのご経歴

2015年にSansan株式会社 Eight事業部にご入社されて今年で6年目。
もともとはビジネスサイド出身で、インサイドセールス、オペレーション、カスタマーサクセスなどを担当され2017年からプロダクトマネージャとしてEight Career Designの開発に携わってこられました。

Sansan株式会社とプロダクトのご紹介

Sansan株式会社は今年で設立13年目。法人向け、個人向けのアプリケーションを展開しています。主なサービスは法人向けサービスのSansanと個人向け・アプリのEightの2つです。

Sansanは社内にある全ての名刺を集約しビジネスプラットフォームとして活用できる法人向けクラウド名刺管理サービス。

Eightは250万人が利用する、無料の名刺管理を軸として、ユーザー同士がつながることができるビジネスネットワークアプリケーションです。
※Eightの開発にはメンバーズエッジのチームも関わらせていただきました。

また、片芝さんがEight事業部の中で直接携わっているEight Career Designは、Eightの中の転職市場に現れない優秀な人材にアプローチをして採用につなげることができる、ダイレクトリクルーティングサービスです。大手メーカーからITスタートアップまで幅広い企業がサービスを利用しています。

チームとプロセス

チーム構成

Eight Career Design開発メンバーの現在のチーム構成はこのようになっています。

  • Product Manager: 1
  • Designer: 1
  • Engineers(Front: 3/Back: 1): 4 ※うち1名がスクラムマスター
  • Quality Assurance: 1
  • Data Analyst: 1

プロダクトマネージャの職務範囲

片芝さんの職務範囲は下記のとおりです。

企画段階

  • 事業計画を元にした施策立案
  • 各施策の優先度決定・関係者との合意
  • 要求の決定
  • ポンチ絵の書き起こし
  • DesignerとのPrototype作成・洗練

開発段階

  • 仕様の伝達・調整・決定
  • 進捗管理とScope調整

これまでと課題

アジャイルになるまで

片芝さん:僕がプロダクトマネージャになったのは2年半前ですが、Eight事業部では3年前からスクラム導入をはじめていました。自分が入ったときには一部アジャイルになっていましたが、僕自身はアジャイルについては知識がない状態からスタートしています。

当初はスクラムをやっているとはいえ、チームが完全にアジャイルとして動けていたわけではなく、形だけだったかもしれません。このころはまだ明確な仕組みはなく、決まっていたのはスプリントは1週間単位というところだけ。意識の上だけで回していたふしが多くて、うまくマネージできていなかったかもしれません。

課題

片芝さん:開発状況の進捗が不明瞭で誰も全体を知らない状態となってしまい、開発しっぱなしで単なる反復となってしまう状況が続いていました。日々課題が積もる中でしっかりと向き合っていって、自身もアジャイルを勉強し、チームとしても議論してプロセスに落としていきました。

プロセス

チームではスクラムを導入しており、スクラムの5つのイベントを中心に据えて回しています。各イベントの詳細は下記のとおりです。

  • Daily
    • Daily Scrum:タスク共有や相談、進捗共有など。毎朝10時から15分
  • Weekly
    • Refinement:今後の施策の共有と議論し、開発可能な状態に持っていく
    • Planning:毎週月曜に実施。前週Sprintのリリース物・Velocityを確認し、今週の優先度・内容を決定
    • Retro:Teamの振り返り。良かったことや課題の共有と次のアクションの決定
  • Monthly
    • リリース分析:リリース物の効果測定・考察・次の施策の決定

※Backlogの管理はGoogleスプレッドシートで行っているとのことで、実際のツールも見せていただきながらご説明いただきました。施策を一覧化し、日付でプランニングの幅を決めて管理されているそうです。

片芝さん:リリース分析はSlackを使っています。
データアナリストがリリース分析をSlackチャンネルに投稿して共有し、僕がそれを見て考察と次回アクションをチームメンバーに共有します。Slackのチャンネルで共有することで、いつでも好きなときにデータを見ることができます。これらの取り組みにより、当初アジャイルもどきと感じていた体制は改善されました。

Daily ScrumとPlanningにより、開発状況の不明瞭さはなくなり、進捗も管理できるように。単なる反復だったスプリントが、リリース分析とRetroにより振り返りを行いながら次のスプリントに活かしていくことができるようになりました。

プロダクトマネージャとして意識しているポイント

片芝さんが意識しているポイントは3点です。

  1. 目的はくどいほどに
  2. 聴く、観る、やってみる
  3. 役割と主導を決め、巻き込む

目的はくどいほどに

片芝さん:アジャイル開発はかなりのスピード感が求められます。遅れのないようにしないといけませんが、「何をするか」という部分だけに焦点が行きがちになるケースが多いと感じます。

自分自身がそうなるとチーム全体が「そもそもこの施策はなんのためだっけ?」状態になります。チーム全体が目的に対して迷子になるケースがはじめはありました。今でも個々の施策においてはなる場合があります。だからこそ目的は意識しすぎるほど意識しています。

アジャイルソフトウェア開発宣言」内の「アジャイルソフトウェアの12の原則」冒頭に、「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。」とあります。アジャイル開発では”いかに目的を持って開発していくか”という視点がとても大事だと感じています。

具体的にはいわゆるゴールデンサークル理論に則り、「まずなぜそれをする必要があるのか」「どういったアプローチをとるのか」「そして何をするのか」というレベルからチーム内で共有しています。

開発チームだけでなく営業サイドとも、コンセプトの定期的な見直しや短期目標の振り返りなど、忘れていても立ち返ることができる仕組みをつくっています。

聴く、観る、やってみる

片芝さん:EightはBtoBのサービスですが、自分は新卒入社で人事部門の経験もないためペルソナがまったくわからないという大きなディスアドバンテージを抱えながらの開発となりました。その状態のままでプロダクトに向かっているとリリースのためだけの開発になりがち。自分がペルソナではないからこそ、能動的に機会を取りに行くことを意識しています。

聴く―顧客訪問への同行や顧客の声の聞き取りを行っています。顧客の声を共有できるスレッドをSlackにつくり、そこの投稿を起点にビジネスサイドメンバーとコミュニケーションをとっています。

観る―顧客とのサービス利用会を開催しています。社内にユーザーを呼んで、困っているポイントや使いにくいと感じている機能などを確認しています。新しい施策があるときはプロトタイプをリリース前にお披露目し、ユーザーの声を反映していく動きをとっています。

やってみる―自分がユーザーになってみるという意味で、ビジネスサイドも巻き込んで週に1回スカウト大会を実施しています。模擬的ではなくて各自に役割を決めてしっかりスカウトし、実際に候補者との面談まで行っています。

使い手になることで機能の使い勝手が手触りある形で実感でき、プロダクトチーム全体としてユーザーになれることで視座が上がると感じています。

役割と主導を決め、巻き込む

片芝さん:プロダクトマネージャは開発チームのハブとなる部分なので、業務が集中しがち。参画当初は全部一人で進めようとして完全にパンクしていました。ただでさえ業務・思考量が多い職種なので、全部自分でやると思考や整理に時間が使えない状態に陥ります。

そこで、現在は目的にもっとも適任な人を任命し巻き込んでいくようにしています。

例えば、顧客の声の聞き取りは営業に、サービス利用会はカスタマーサクセスに、社内スカウト大会は採用したい各ポジションに一番近い仕事をしているメンバーに、といった具合です。

Q&A

Q. 1週間サイクルはかなり早いと思いますが、2週間サイクルなども検討されましたか?

A.一番最初は2週間でやっていました。1週間に変えた理由は大きく2つあります。

月~金曜のサイクルが心理的にメリハリをつけやすいということと、MVP(Minimum Viable Product)と向き合う環境を仕組み的に作りやすいというメリットがあるためです。

Q. レトロスペクティブをどのように実施しているか、実例を踏まえてご教示いただけますでしょうか。

A. 現在は、オンライン上でできることを前提としてCacooというツールを使って行なっています。(オンラインで記入・共有できるホワイトボードのようなもの)

振り返り自体はKPTを採用し、Keep・Problem・Tryの軸で「継続すること・解決したい課題と改善策・トライしたいこと」を共有しています。

進め方としては、事前に各メンバーが事前に共有事項を洗い出ししておきます。レトロスペクティブの場ではすぐできる改善策か時間がかかる課題かの判断をし、すぐできる改善策はその場で決定。大き目の課題に対しては各メンバーで投票して、投票が集まった課題に対してさらに掘り下げていきます。「そもそも何でこれが課題だったのか」とか、「解決するためにどこと連携していつまでに何をすべきか」といった詳細を決めています。

また、翌週に前週の振り返りとして課題への対処がどこまで進んだかを確認し、レトロスペクティブのPDCAを回しています。

Q. 月ごとの分析はどのような観点で実施されていますか?また、分析はPMの意思決定にどのように貢献していますか?

A.分析は月次で行なっているため、前月のリリース分析を行なう以降にリリースした施策を僕とデータアナリスト2人で洗い出して、分析する観点をまずざっと決めていきます。そこからデータアナリストに分析を進めてもらいます。でてきた結果をSlackで共有してもらい、その後は僕が考察をまとめてチーム全体で次の施策について議論を行ないます。

特に定量から来る意思決定においては、分析はものすごく貢献しています。

Q. PDMとして、施策の優先順位は何を軸に決定しているのですか?

A.大きく分けて2軸あります。

事業インパクトを出せるもの(売上)、ユーザー価値を最大化できるものか、という2軸で決定しています。

背に腹変えられぬものがある場合は最優先にして進めていきますが、既存機能でユーザを困らせているものなどがあればそちらを優先的に、という形で優先度を決定しています。

優先度をただ決定するだけでなく、事業部長や営業・CSなど含めて認識合わせをしています。

Q. スクラムマスターはチーム内に不在でしょうか?

A.スクラムでは、スクラムマスターは専任であることが一般的かと思いますが、うちのチームでは4名いるエンジニアのうち1名がスクラムマスターを兼任しています。

兼任することで負荷が生じる場合はレトロスペクティブできちんと拾い上げ、課題解決していきます。

Q. 1Weekのプロセスの具体的な曜日を教えてください。

A. 月~金曜日のスプリントなので、月曜日にプランニング、水曜日は翌々週以降の施策を決めるリファインメント、金曜はレトロスペクティブ、という流れになっています。

月水金にMTGをなるべくまとめて、火・木は開発に集中できるようにしています。

Q. 事業計画をもとにどのように施策検討しますか?施策のKPIの設定方法、KPIを達成できるロジックの作り方など教えてください。

A.僕自身もこのメソッドは模索中で、「ひたすら考えてやっています」というのが回答になります。事業計画としては今期の売り上げ目標などが降りてくるので、そこから因数分解し、課題やボトルネックを洗い出して施策を考えていきます。

KPI設定は、どういう結果をもたらしたら施策が達成したと言えるのか?というのを一つ一つ考えながらログ設計に落としたり、プロトタイプに反映していくという流れになります。

あとは、胆力。ひたすら向き合って考え続けるというのが何よりもベースになるのではないかと。ものすごくしんどい部分でもありますが、PDMの面白さでもあると思っています。

Q. PDMとして施策の優先順位は何を軸に決定しているのですか?

A.事業インパクトを出せるもの(売上)、ユーザー価値を最大化できるものなのか、という2つの軸で決定しています。

背に腹変えられぬものがある場合は最優先に進めていきますが、既存機能でユーザーを困らせているものなどがあればそちらを優先的に行ないます。

特に意識しているのは、しっかりと周りと連携しながら決めていくというところ。自分自身がこういう優先度で行きたいと決めた上で、事業部長や営業、カスタマーサクセスと2軸がずれていないか、違和感があればなぜそうしたのかというところを握りにいったりと行動しています。いかにステークホルダーと連携しながら多方面からレビューを入れていけるかが大事だと考えています。

Q. スクラムに慣れていない入社者に対してどうやって慣れさせていくのか、取り組まれている工夫があれば教えてください。

A.受け入れはOJTメインになっています。チームメンバーも8名と少ない状態なので、受け入れマニュアルなどを整備するよりもお互いを開示して、相手を知り、何でも話せる絆をつくることからはじめています。

Q. 業務上でPMとエンジニアの軋轢はありますか?ある場合はなぜ生まれますか?

A.現在は軋轢はなくいい感じにできていると思っています。

ただ、過去は課題感が生まれていたことが結構ありました。なぜ生まれるか、ですが、やはりお互いを理解できていないと、PMから施策を押し付けられる側、という認識を開発側から持たれてしまうので・・・。「仕様を理解してないのに企画してる」と思われてしまうみたいなことは、あるあるですが、一部ありました。

あとは、事業成果のプレッシャーからそちらに寄りすぎてしまって別のところに負債が出てしまったり。プロダクトと一番近くで向き合ってくれているデザイナーやエンジニアだからこそ、軋轢が生まれてしまうことがありました。

これに関しては、アジャイルの仕組みも含めレトロスペクティブの振り返りを行ない、目的からしっかりと説明して背景を共有する、フィードバックをリファインメントで設けるといった取り組みにより今は解消されています。

おわりに

アジャイルを導入したものの、うまく浸透せず「なんちゃってアジャイル」になってしまっているといった声はよく聞かれます。試行錯誤しながら現在の体制・仕組みをつくり上げ、アジャイルで成果を出されている片芝さんのチームの事例はこれからアジャイルを導入する、現在導入しているがうまくいっていないという方にとっては非常に参考になるものだったのではないでしょうか。現在、悩まれている方はぜひご自身のチームに取り入れてみてください。

アジャイル開発について基本的なことが知りたい方はこちらの記事も参考になると思います。

アジャイル開発のノウハウをオンラインセミナーでも発信中

メンバーズグループでは、アジャイル開発に関する様々なオンラインセミナーも開催しています!無料で誰でもご参加いただけるので、ぜひどうぞ!

採用情報

メンバーズエッジで最高のチームで最高のプロダクトを作りませんか?

最高のプロダクトをつくる 最高のチームで働く

在宅でも、地方でも、首都圏でも。多様な働き方で最高のチームをつくり、お客様のプロダクトパートナーを目指します。アジャイル開発を通じ、開発現場の第一線で活躍し続けたいエンジニアを募集しています。