2024.12.10
“放置系”なのにサイバー攻撃を監視・検知、「統合ログ管理ツール」とは 最先端のログ管理体制を実現する方法
LTタイトル:失敗から学んだ、1人目PMのDo’s & Don’ts(全1記事)
リンクをコピー
記事をブックマーク
稲垣慶典氏:では始めていきたいと思います。よろしくお願いします。今日は、1人目プロダクトマネージャーとしての経験を通じた「ああしたほうがよかったな」とか「これしないほうがよかったな」というような学びをシェアできればと思っています。
先ほども自己紹介しましたが、稲垣と言います。バックグラウンド的に、プロダクトマネージャーとしてはけっこうビジネス寄りなタイプかなと思っています。
経験はちょっと変わっていて、新卒でディー・エヌ・エーという会社に入り、最初はゲームのプロデューサーという、ゲーム作りをしながら事業のPLも見るみたいなところからキャリアを始めています。その後一転して、ヘルスケア・医療の領域でがん検査のサービスをするプロジェクトや、医療機関を作るプロジェクトに携わったので、領域としては振り幅のある経験をしてきた人間です。
今所属しているのがPharmaXという会社で、名前のとおりpharmacy、薬局をX、DXする会社です。ひとことで言うと、オンライン薬局のサービスを提供・運営している会社になっています。
ポイントは何かというと、今、私自身は本郷にある薬局にいるのですが、薬局と薬剤師を自社で抱えながら、テクノロジーを活用して業務を効率化、もしくは良質化することによって、エンドユーザー向けに付加価値を提供していきましょう、というところです。
そのポイントを軸にしながら、2つの事業を提供しています。1つはtoC向けの事業で「YOJO」という漢方のサブスクサービスを運営しています。もう1つはtoB事業で、事業者さん向けにオンライン薬局を実現するためのコンサルや独自システム提供、オペレーションをフルパッケージで提供するようなtoB事業を展開しています。
もうちょっと各事業について細かく紹介します。toC向けの漢方サブスクのサービスに関しては、LINEを通じて、薬剤師さんを中心とした医療アドバイザーの方とすごく密にコミュニケーションしながら、何十種類もある中から自分に合った漢方薬を購入できるサービスです。薬剤師さんと相談しながら買ったり、日常的に相談できるのがポイントです。
これはなぜできるかというと、全国からリモートで働く薬剤師さんのメンバーが集合して働いてくれていて、かつ、その業務を超最適化した内製の管理システム、業務システムをプロダクトとして開発をしているからです。
その結果、薬剤師さんというめちゃくちゃ貴重な人的リソースをフル活用して、ユーザーからするとびっくりするぐらいLINEで(密に)相談できるという医療体験を提供しています。
このtoC事業で培った知見やシステムの仕組みを、処方箋の薬を取り扱う調剤薬局の業務に転用したのがtoB事業になっています。こちらはすでに某大手企業さまのオンライン薬局事業の裏側をフルフルで支える取り組みを行っていて、パートナーさんと組みながら、かかりつけ薬局体験を広く広げていこうという取り組みになっています。
さっそく本題に移っていければと思います。PharmaXという会社に1人目のプロダクトマネージャーとして入社をして経験した中での学びを共有したいのですが、最初にまとめからで、1人目のプロダクトマネージャーとしての振る舞いや、プロダクトマネジメントを組織にインストールする上でやったほうがいいことが2つあります。
1つは、自分たちをちゃんと知ることかなと思っています。プロダクトマネジメントのあるべき姿というのは、組織やプロダクトによってやはりめちゃくちゃ変わってくるなということを実感したからです。
もう1つが、あるべき姿を模索する上で、巷の知見・手法が最近はいろいろ増えてきたと思いますが、たたき台としてしっかり活用するのが大事かなと思っています。
一方でやらないほうがいいことでいうと、巷の知見をたたき台として入れてみたけれど、それで終わりというのはやはりいけないと思います。それをたたきとして、しっかり自分たちに適合させていくプロセスこそが大事なんじゃないかなというポイントです。
もう1つが、これはプロダクトマネージャーとしての振る舞いという観点で、いわゆる「(プロダクトマネージャーは)ミニCEOだ」みたいな話にあるような、一般論的なプロダクトマネージャーのあるべき姿には、あまりこだわりすぎないほうがいいんじゃないかなということです。
これらはまとめとして言うと、よく言われるような当たり前な話のように見えるので、そのあたりの温度感も伝えられるように、さっそく具体の話をしていこうかなと思います。
前提情報として、入社時のプロダクトチームについて説明すると、いわゆるアーリーステージのスタートアップによくあるような、創業者が実質創業プロダクトマネージャーで、エンジニアとデザイナーがいる小さなチームでした。
少し特殊なのが、ユーザーとチャットをやりとりする薬剤師さんがいて、社内ではペイシェント・サクセス(PS)と呼んでいるのですが、このPSのメンバーもプロダクトチームとけっこう密連携をしてプロダクトを提供していくという部分です。ほかに、専任のプロダクトマネージャーは当時いなくて、副業的な方がいたり、エンジニアがそれっぽい動きをするような感じでした。
チームに入るにあたって個人的に感じていたのが、自分の過去の経験がマッチするようでマッチしなさそうだなという印象があって。もともとtoCや医療・ヘルスケアの領域をやっていたものの、メンバーのタイプやチームの熟練度など、いろいろ違う部分が多そうだなという印象を持ちました。
(スライドを示して)これはまとめとして後づけ的にきれいに整理はしているのですが、そこが違いそうだなという上で、自分たちを把握するために、いくつかの変数に分解をして、それぞれ自分の過去の経験と比較することで違いを明確化してみようと思いました。
世の中の事例や知見を参考する時にも、前提になっているチームと自分たちの違いみたいなものを変数単位で差分を理解することができれば、導入する時の注意点や工夫ポイントが明確になるんじゃないかなと思っています。
そんな感じで、プロダクトマネージャーとしての動きや、どういうプロダクトマネジメントにするか、スタイルにしていくかみたいなポイントを出して、それに基づいて取り組みをしていこうとしていました。
今回は時間の関係で、3つに絞って話そうかなと思います。この3つのポイントは、常にチーム状況を捉え直して、ポイントが増えたり減ったり更新されたり(する)みたいなイメージなのかなと思っています。
具体の話をこれら3つのところに関して言うと、1つ目に当時持った印象としては、プロダクト開発という文脈において、シニアのメンバーがたくさんいるチーム体制ではないなということです。
薬剤師さんみたいな「プロダクトマネジメントって何?」みたいな方も同時にいるチームだったりして、あまり練度が高くない印象があったので、まず型を持ち込んでいこうかなと思って取り組みをしました。
2つ目は、薬剤師さん含めいろいろな職種が混在しつつ、それぞれがプロダクト上の重要な役割を担っていたので、ちゃんと関係者が巻き込まれるような状態にしたいなと思いました。
3つ目が、もともとプロダクトマネージャーという存在がいなかったこともあって、「プロダクトのマネジメントって何だろう?」ぐらいなノリではあったので、役割をちゃんと明確にしていくことを重視しました。
1つ目の取り組みで言うと、先ほどあったように「型を入れよう」ということで、ドキュメントのフォーマット化やインタビューの要件設計のフォーマット化など、いろいろやっていったのですが、なかなか思ったようにいかないというか、「なんかちょっと違うな」ということが起きました。
なんでだろうなといろいろひもといてみると、そもそも根底の考え方の部分で認識が揃っていなさそうだということが見えてきたので、会社でいうバリューみたいなかたちで、プロダクトチームの方針を言語化してみました。
(スライドを示して)まだ完璧に運用できているわけではないですが、例えばこの中にある「最小のアウトプットで最大のアウトカムを出しましょう」という指針は、関係者の中でしっくりきていたので、根底の考え方を揃えるきっかけとして良かったかなと思っています。
2つ目に「巻き込みましょう」ということで、ここに関しても安直に情報量を増やそうとしつこく話したり、「こういう狙いでやってます」みたいなことを話したり、リリースレターというかたちで毎週リリースの背景や内容を共有したりしていました。しかし、これをやっても「なんかちょっと何をやっているかよくわからないです」と言われることがちょくちょくありました。
これもよく考えてみると、「こういう施策です」という内容の単体はわかっているんだけど、文脈があまり伝わっていませんでした。
(スライドを示して)映しているのはタスクの管理というかアクションの管理のNotionの1枚ページですが、「ここでビジネスKPIがこう因数分解されて、それに紐付くイシューはこうで、施策はこうで」というようなことを一元管理して、それをベースにコミュニケーションすることで文脈が伝わりやすくなったかなと思います。
プラスアルファみたいな話でいうと、文脈、上位の目線が揃ってくると、みんながプラスアルファの動きをしてくれるようになりました。
うちでは薬剤師さんがSQLを使って分析する特殊な文化があるのですが、もともとBIチームが布教活動してくれたこともあって、上位の目線が揃うことで、積極的にいろいろなメンバーがプラスアルファの行動をして、「サービスを良くしていこう」「プロダクトを良くしていこう」みたいな動きをしてくれたのがすごく良かったなと思います。
最後に3つ目ですが、役割という話でいうと、やはりプロダクトマネージャーの役割はつくづく曖昧だなと思っていて。役割分担といっても、大きく2つあるかなと思っています。
1つはエンジニア、デザイナーなど、他職種との横の役割分担という話。2つ目は縦の分担で、創業者、事業責任者との役割分担みたいな話が出てきます。ここの縦の役割分担が実は重要、特にアーリーなスタートアップには重要なんじゃないかなと思っています。
そういった文脈もあって、「プロダクトって何だろう?」みたいな定義設計や「プロダクトマネージャーって何なんだっけ?」みたいなことを言語化して、それベースですり合わせる動きをしてみました。実際問題、定義どおりにきれいにはまることはなくて、ケースバイケースで「その意思決定どっちがやるんですか?」とか「どこまで見ていいんですか?」みたいなことが起きがちでした。
このあたり、最終的な解はないのですが、線引きが難しいです。
学びとしては、やはり教科書的なプロダクトマネージャーの「ディスカバリー・デリバリー両方ちゃんとやりましょう」みたいな部分も、それはそれで正しいのですが、固執してしまうと良くないなと思っています。
この話も最初にあったように、「自分たちに合ったやり方を考えましょう」ということが前提で、大事なのは、やはりプロダクトを成功させる確率を上げましょうという部分かなと思っています。
その時に考えなければいけないこととして、自分の中では2つ学びがあります。1つは創業者のほうで、直感に基づくプロダクト作り、創業者の野性的なムーブみたいな部分は、やはり速かったり強かったりすると思っています。
それを考えた時に「どう振る舞うべきなんだろう」という観点と、あとは感情面の話でいった時に、実質創業プロダクトマネージャーである代表と1人目のプロダクトマネージャーの関係は、赤ちゃんに対する親と保育者の関係に似ているなと思っています。
保育者は子育てのプロでもあるけれど、血はつながっていないし、感情的なつながりは親ほど強くない。そういう立場の中で、「どう振る舞うとプロダクトの成功確率が上がるのか?」みたいなところは考えなければいけないポイントかなと思っています。
いずれにせよ、1人目プロダクトマネージャーの振る舞いや「チームにどうプロダクトマネジメントを導入していくか」という話においては、今の、そして自分たちに合ったものを探し続けるみたいな、粘土をこね続けるみたいな営みになるのかなと思っています。
なので、自分たちを捉え続けることをやめてはいけないし、こねこねし続けることをやめてはいけないというのがすごく重要かなと思っています。
というわけで、採用をしていますので、興味ある方はぜひご応募ください。以上です。
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.09
10点満点中7点の部下に言うべきこと 部下を育成できない上司の特徴トップ5
2024.12.09
国内の有名ホテルでは、マグロ丼がなんと1杯「24,000円」 「良いものをより安く」を追いすぎた日本にとって値上げが重要な理由
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.12.10
職場であえて「不機嫌」を出したほうがいいタイプ NOと言えない人のための人間関係をラクにするヒント
2024.12.12
今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは
PR | 2024.11.26
なぜ電話営業はなくならない?その要因は「属人化」 通話内容をデータ化するZoomのクラウドサービス活用術
PR | 2024.11.22
「闇雲なAI導入」から脱却せよ Zoom・パーソル・THE GUILD幹部が語る、従業員と顧客体験を高めるAI戦略の要諦
2024.12.11
大企業への転職前に感じた、「なんか違うかも」の違和感の正体 「親が喜ぶ」「モテそう」ではない、自分の判断基準を持つカギ