Sansan Tech Blog

Sansanのものづくりを支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信

もし Sansan のプロダクト開発マネージャーがドラッカーの『マネジメント』を読んだら

はじめに

こんにちは! Sansan 事業部プロダクト開発部の神原です。スノーボードの季節がもうすぐで、うずうずしております。

プロダクト開発部は法人向け名刺管理サービス Sansan の開発・運用がミッションであり、 2019 年 10 月 20 日時点でエンジニアが 74 名、全体では 95 名のチームです。 Sansan はその売上規模からしても product/market fit はでき、 growth ステージにあるプロダクトであり、組織だと言えると思います。いかにして成長し、スケールするのかが最大の課題です。

私はそこで副部長の役割を担っています。「副部長」って何だか分かりづらいですが、要は組織のマネージャーです。本稿では、 growth ステージにある組織のプロダクト開発マネージャーが、マネジメントについて考えていることの一部をご紹介します。

マネジメント / マネージャーとは

ドラッカーかく語りき

突然ですが、マネジメント / マネージャーとは何でしょうか?何となく分かるようで分からない言葉です。これまでの上司の顔は思い浮かぶけれど、彼ら / 彼女らの責務や仕事は何だったのかよく分からない、そんな感じではないでしょうか。

そういう場合は原典にあたるのが一番です。早速、「マネジメント」の発明者と言われているピーター・ドラッカーの『マネジメント: 基本と原則』を見てみましょう。

マネジメント[エッセンシャル版] - 基本と原則

マネジメント[エッセンシャル版] - 基本と原則

『マネジメント』では、マネージャーとは「組織の成果に責任を持つ者」であるとされています。

また、マネージャーには2つの役割と5つの仕事があると説かれています。

2 つの役割:

  1. 部分の和よりも大きな全体を創造する: 特に人的資源のあらゆる強みを発揮させるとともに、あらゆる弱みを消さなければならない。
  2. ただちに必要とされているものと遠い将来に必要とされるものを調和させていく

5 つの仕事:

  1. 目標を設定する
  2. 組織する
  3. 動機づけとコミュニケーションを図る
  4. 評価測定する
  5. 人材を開発する

「人こそ最大の資産である」ともあります。そして、そのために不可欠なものとして以下が挙げられています。

  1. 生産的な仕事
  2. フィードバック情報
  3. 継続的学習

生産的に仕事ができているという実感があり、自らの成果についての情報が得られ、継続的な学びを得られる環境において、人は自らの仕事、集団、成果について責任を持つようになるということです。それこそが「人を活かす」ための基盤であり、マネージャーはこの基盤を提供することに責任を持ちます。

マネジメント完全に理解した

やはり原典にあたるのは大事ですね。ありがとうドラッカー先生、マネジメント完全に理解した。思わず "easy to learn, hard [or almost impossible] to master" という一文が脳裏を去来します。

この "easy to learn, hard [or almost impossible] to master" というのは良いゲームのデザイン原則として語られた言葉なのだそうです。ドラッカー先生が言っていることと今私が向き合っている現実を照らし合わせた時、マネジメントも良いゲームに似ており、何を達成すべきかは分かるけれど、どうしたら良いかはそう簡単には分からないし、マスターする = 完璧にやるのはほとんど不可能だと感じます。

ここからは、ドラッカー先生が言っていることを受けて Sansan のプロダクト開発マネージャーがどう考えているか?という話をしようと思います。上記の通りマスターなど到底できない題材なので、答えなどではなく、あくまで現時点での私の考えに過ぎないことをご了承ください。それでも、どこかの誰かに対して何らかのインプットになると信じて、恥を忍んでアウトプットするものです。

成果とは何であるか

マネージャーとは「組織の成果に責任を持つ者」であるが故に、マネージャーの仕事の各論に入る前に最も重要な問いが「組織の成果とは何であるか」だと言えます。自明なようでいて、考えれば考えるほど難しい問いがこれです。

我々はプロダクトを開発し、運用する組織なのだから、より良いものをより低コストで開発し、運用することが組織のミッションであり、成果である。これは自明に思えます。ところが、「より良いもの」とは何なのか?低コストとはどういう期間における何のコストのことを指すのか?などと考えていくと、難しさが増していきます。

また、成果を定義するのであれば定量的な測定が可能であった方が良いですが、我々のような B2B SaaS のプロダクト開発においては、例えば「◯◯機能のパフォーマンスを◯◯ % 良くしたから churn rate が◯◯ % 改善しました」や「××機能を実装したから MRR が××円 up しました」といった分かりやすい話が成立することはまずありません。

ある一定期間の間に churn rate が改善したとして、大抵の場合その結果の要因となる事象がプロダクト内外にいくつもあるためです。例えば customer success 部門の何かの施策が成功したのかもしれないし、政府の何かのキャンペーンによって我々のプロダクトに対する予算がつきやすくなったのかもしれません。更にプロダクト内で見てもその期間の間にいくつもの改善が並行で走っていますから、特定の改善が churn rate の改善にどれだけ寄与したかを証明するのは困難です。

考えれば考えるほど難しいですよね?何らかの答え、公式があるはずだと思って取り組むと、どこまで考えても分からないと思います。私の考えでは、そこに答えや公式はありません。なので、何か確からしく思える拠り所を見つけ、そこに基づいて成果を定義するしかないというのが私の考えです。以下に、我々が拠り所としているものを紹介します。

顧客の課題解決

顧客の顕在化した課題、あるいは潜在的な課題を解決するプロダクトを開発できた時、成果であると考えます。簡単に言えば使いやすいもの、あるいは顧客の生産性を向上させるものです。この前提を置いてしまえば、成果を測定することが可能になってきますね。一見すると当たり前のことであり、プロダクトマネジメントの原則とも言える内容ですが、それだけだと片手落ちになってしまうと考えています。

私たちのサービスは業種・業態や企業規模を問わずありとあらゆる企業 (顧客は営利企業とは限らないので正確には「組織」) で利用されるものです。当然ながら、抱える課題は顧客によって異なるので、 A 社の営業担当者にとって課題解決に繋がるプロダクト改善は B 社のマーケティング担当者にとっては何の意味も持たない、もしくは改悪ですらあるという事態が起こり得ます。もちろん誰かにとって改悪になるようなことは極力避けますが、ターゲットを定めることは重要です。ターゲットを定めずに行ったプロダクト改善 (のつもりのもの) が結局誰の課題も解決しない、というのはプロダクトマネジメントにおけるアンチパターンです。

事業戦略

そこで重要だと考えているのが「事業戦略」との整合性です。事業戦略では、我々の顧客は誰であるかが設定されます。上述したように私たちのサービスはありとあらゆる組織が顧客たりえるものですが、マーケット環境など様々な要因の分析により、顧客セグメント毎の事業的な「力の入れどころ」が設定されます。

事業戦略を是とし、拠り所にすることで、誰の課題を解決すれば良いのかがクリアになってきます。同時に、本当にプロダクトで解決すべき課題なのか?という問いに答えることも可能になってきます。

『マネジメント』にも以下の一文があります。

「顧客は誰か」との問いこそ、個々の企業の使命を定義するうえで、もっとも重要な問いである

「企業の使命」を定義するという一段高いレイヤーの話の中での一節ですが、事業やプロダクト開発の成果を定義するうえでも非常に重要な問いであると私は思います。

NPS

成果を測定するツールとして NPS (Net Promoter Score) を活用しています。「この製品を親しい友人や同僚に薦める可能性は 0 ~ 10 点で表すとどのぐらいですか?」というやつです。

NPS について少し調べると「NPS は業績に直結する指標です」や「B2B でも収益性に高い相関が見られました」といった情報がすぐに見つかります。「銀の弾丸はない」のでそういった情報は慎重に取り扱うべきだと思いますが、 NPS には計測ツールとして非常に優れた性質があります。

それは、何らかの変更がどう顧客ロイヤルティ (NPS 界隈では顧客満足度と区別するためにこう言うのだそう) に影響したのかを測定できるという点です。例えば APM ツールを使えばパフォーマンス改善の結果を測定できますが、それがどれだけ顧客にとって嬉しかったのかは知ることができません。一方で NPS では、「◯◯機能を◯◯することが顧客にとって嬉しいはずである」という仮説を直接検証することができます。

また、 NPS 調査ツールを使うと、サービス全体に対する NPS に加えて追加の質問をすることができるし、回答については様々なカットで回答者をセグメント分けして見ることが可能になるので、どこの誰にとってのどんな課題解決を提供するのかを重視する私たちにとって、優れた測定ツールだと考えています。

もちろん他のツールとの組み合わせが重要であることは言うまでもなく、私たちもアクセス解析ツールや APM ツールなどと併用しています。また、ツールというのは時代と共に進化するものなので、 NPS よりも優れたツールの登場を願ってやまないところではあります。

目標を設定する

「成果とは何であるか」は「なぜ (Why)」「何をするのか (What)」に寄った話をしました。それ自体プロダクト開発組織における非常に重要な要素ではありますが、それだけではプロダクト開発組織の成果は最大化しないと考えていて、組織の目標には他の重要要素もバランス良く組み込むように意識しています。

Product delivery

プロダクトマネジメントの用語に "product discovery" と "product delivery" というものがあります。 私の理解では、 product discovery はなぜ・何をするのかにフォーカスしたものであり、それが決まった (仮説を立てた) 後にいかに最適な QCD のバランスでリリースに持って行くか (How) にフォーカスするのが product delivery です。いかに product discovery が上手くとも、それを実現できなければ絵に描いた餅に終わってしまいます。なので、 product discovery と product delivery は同じぐらい重要であり、組織の目標にも両方をバランス良く組み込むべきだと考えています。

短期と長期

前述した『マネジメント』にあるマネージャーの 2 つの役割のうち 1 つに以下があります。

ただちに必要とされているものと遠い将来に必要とされるものを調和させていく

短期的な成果と長期的な成果のバランスを取ること。これは言うは易く行うは難しだと思います。短期的な成果には例えば以下のようなものが該当するでしょう:

  • 重要な xxx プロジェクトと yyy プロジェクトをいついつまでに delivery
  • 組織全体としてこの四半期中に xxx (量の尺度) 分 delivery
  • (上述の) NPS を xxx にする

長期的な成果を得るためには例えば以下のようなことに取り組むことになります:

  • 技術的負債の返済
  • 人材育成
  • 業務プロセスの改善
  • 組織構造の最適化
  • 人材採用

短期的な成果は測定しやすく、長期的な成果は測定しにくい傾向があります。目に見える成果を求めると短期に、理想を求めると長期に目が行きやすいでしょう。ドラッカー先生の言う通り、組織としてどちらかが偏重されている状態は危険であり、マネージャーには両者を調和させる役割があります。

特に、短期的な成果が疎かにされていると長期的な成果まで得られなくなっていってしまうと私は考えています。すなわち、目の前の開発が上手く回っていない、あるいは目の前の開発においてチャレンジングな目標を追いかけていない状態で、人が育つでしょうか?業務プロセスの課題が見つかるでしょうか?ということです。

以上の考えから組織目標には、短期的な成果目標を漏れなく組み込み、長期的な成果のための目標のうち測定が可能で短期的にも追いかけやすいもののみを組み込むようにしています。長期的な成果のための取り組みのうち組織目標に組み込まれなかったものは、目標に組み込む以外の方法で向き合う必要が出てきます。その方法とは、組織設計と業務プロセス設計です。

まとめ

いかがだったでしょうか?本稿では、 growth ステージに入ったプロダクト開発組織のマネージャーが考えていることを、マネジメントの原典であるドラッカーの『マネジメント』に沿って紹介してきました。どこかの誰かにとって、何かのインプットになってくれていたら幸いです。

既に結構なボリュームになったので本稿はここまでとしますが、本稿では全ての前提である「成果とは何であるか」、およびマネージャーの仕事 5 つのうち 1 つを取り上げるにとどまりました。残り 4 つの仕事については、また機会があればその時に…!

マネージャーの 5 つの仕事:

  1. 目標を設定する (本稿で取り上げ済み)
  2. 組織する
  3. 動機づけとコミュニケーションを図る
  4. 評価測定する
  5. 人材を開発する




buildersbox.corp-sansan.com

buildersbox.corp-sansan.com

© Sansan, Inc.