社内向けのプロダクトを作るときにPdMが考えていること
キャスターでプロダクトマネージャー（PdM）をしているkoyoです、こんにちは。先日買ったカモメファンが可愛すぎて今年の夏は乗り切れそうです。上下左右首振りかつ静音で可愛い扇風機なのでオススメです。
さて、私がフリーランスで関わっているキャスターのプロダクトチームでは、bosyuをはじめとする外部向けのプロダクト以外にも、いくつかの社内向けのプロダクト（それも結構規模の大きいもの）を作っています。
社内向けとはいえ、常時数百人以上が使うものであり、かつ、業務要件もわりと複雑なので、外部に公開しているSaaSと同じくらいの力をかけて作っていたりします。
外部向けのプロダクトの話はよく見かけるのですが、社内向けのプロダクトの話はあまり読んだことがないので、今日は「社内向けのプロダクトを作るときにPdMが考えていること」をお伝えしていきたいなと思います。
事業を形式だけでなく肌で理解する
社内向けのプロダクトの成否を分けるのは事業理解です。なぜこの事業をこの会社がやっているのか、短期的な目標は何か、中長期的な目標は何か、といった大きな話の部分から、日々どのような業務を行なっていて、そのボトルネックは何で、どんな人が関わってて、、、みたいなミクロな話の部分まで、PdMとしてはそれらを全てを最大限理解する必要があります。
そのためにも、その事業を実際に体験することが大切です。知るためには体験することが一番の手段なので、可能な限りその事業を体験してみると良いでしょう。
体験が難しかったとしても、事業側の人との会話を増やしたり、Mtgに出席させてもらったり、Slackのチャンネルに勝手に入ったりと、その事業を肌で感じることのできる状況作りができれば良いかなと思います。
私自身もCASTER BIZ recruitingのリクルーターの役割を体験させていただいたり、日々Slackでの情報のやり取りをウォッチさせていただく中で、だいぶと業務理解は深まってきています。多分そろそろ採用担当もやっていけると思います。機会があればプロダクトサイド専任のリクルーターなんかが出来ると面白いかなと思っています。
ドッグフーディングは正義
相当特殊な業務ではない限り、ドッグフーディングできる環境を作れると理想です。
例えばですが、上述のCASTER BIZ recruitingでは、いわゆる採用管理システム（ATS）のような社内向けプロダクトを作っています。
その上で、キャスタープロダクトチームの採用活動はプロダクトチームのみで行なっていることもあり、自分たちで作ったプロダクトを自分たちで使う、、といったことを実現できています。
それゆえに、「こうしたらいいよね」とか「もっとこうしたら楽になるよね、、、！」といったことや、「XXさんが言ってたこれって確かに辛いよなあ。。」みたいなことも体感としてわかるので、より良い解決策を見つけやすくなっています。
エンジニアコワクナイヨ運動
ここ、すごく大事です。
いわゆる業務側の人の多くは、エンジニアやプロダクト開発に関わる多くの人のことを怖いと思っています。私自身いくつかの会社でお仕事をさせていく中で、ほぼどの会社でもそんな感じの印象を持たれているようでした。
よくある話は下記のようなものです。
・エンジニアさんはめっちゃ忙しそうで声がかけづらい
・声をかけても反応が怖いから勇気がいる
・なんかめっちゃ難しい話ばっかりされるから質問しづらい
・なんか凄そうだから恐れ多い。。。
・っていうかなんかすごい。。
エンジニアからすればコードを書いて何かを生み出すことは日常的な行為ですが、他の人から見ると「魔法を使う」ヨクワカラナイ人なんですよね。それゆえに、必要以上の尊敬を得ていたり、不必要な業務上の摩擦が生み出されています。
そのため、エンジニアコワクナイヨ運動が非常に大切です。
そこでキャスターのプロダクトチームでは下記のような活動を行なっています。
uwa-チャンネル
・プロダクトを使っていてうわああああってなった時に気軽に書き込むSlackのチャンネル。書き込むとめっちゃ褒められる。uwa-の由来は過去に手伝っていたCOUNTERWORKSさんのuwa-駆動開発から。
めっちゃ雑談するよ運動
・とりあえず雑談系のSlackのチャンネルで意識的に雑談する。めっちゃ無駄な話。美味しいカレーの作り方とか。
また、私個人としては、話しかけるハードルを可能な限り下げることを目的にあえてピエロを演じることを意識しています。
・朝起きれないアピール
・特に意味のない絵文字の連打👺👺👺
・とりあえず草を生やすｗｗｗｗｗｗｗｗｗ
とかは戦略的にやっています。戦略的です。
それとは別に、「ちょっとしたことでも感謝を伝える」だとか、「バグ報告とかにも大げさにありがとうを伝える」とか、「なんでもいいので気づいたら報告してください！！」なんてことは意識的に伝えるようにしています。
そうそう、えんださんの名言置いておきますね。
使いづらいは最高のフィードバック
@enda531
もしこれを読まれた業務側の方がいらっしゃれば、今日からは遠慮なく「使いづらい！！」とエンジニアやPdMに言ってみてください。きっとその日からどんどん使いやすくなっていきます。
要望に答えている感 is 大事
エンジニアコワクナイヨ運動によってフィードバックを気軽に行なってくれるようになったとしても、フィードバックした内容がプロダクトに反映されるといった体験が行われない場合、徐々にフィードバックの量が減っていってしまいます。
そのため、フィードバックしていただいた要望に答えている感を出すことは非常に大切です。
具体的には下記のようなことを行なっています。
簡単な対応はあえて優先順位を無視して爆速対応する
要望として上がった内容がコードを数行変える程度の簡単な内容であれば、他のタスクの優先順位をちょっと無視して、あえて爆速対応します。目標感は1時間以内とかでしょうか。そうすることで、「言えば改善してくれる！」という空気感が一気に醸成されます。
リリースの報告は定期的に出す
改善した結果を伝えなければ、多くの場合改善されたことに気づかず、「エンジニアの人たち何やってるんだ。。。」みたいな不穏な空気が生まれていってしまいます。そのため、ちょっとでも良いので進んでいる感を出すために、「ちょっとしたリリースでも定期的に報告する」ことを意識しています。
誰が対応した機能かを明確にする
リリースの報告を行う際は「エンジニアのXXさんが対応してくれたよ！！！神！！！」みたいなことを、あえてバイネームで伝えるようにしています。そうすることでエンジニアがより身近に感じられたり、その機能で困った時はXXさんに聞けば良いんだ、、、ということを暗に示しています。
要望に応えられない場合の説明は丁寧に
フィードバックに答えられない場合は、きちんと理由を説明して納得してもらうことを心がけています。技術的なこと、優先順位的なこと、理由は様々ですが、「そんな理由だったらなんかしょうがないよねー」と思ってもらえるような説明をしている（つもり）です。お互い人間なので、一定のしょうがない感が大事だと個人的には思います。
現場の人たちを心から頼る
私たちプロダクト側の人間がプロダクトづくりのプロだとしたら、ドメインエキスパートは間違いなく現場の人たちです。
これでもかというくらい頼りましょう。正しい質問ができれば、圧倒的な深さの知識でそれらに応えてくれるのが現場の人たちです。正しい情報が集まらないと嘆くなら、自分たちの質問の引き出しを増やしましょう。きっと、より良い情報が集まって、自分たちで考えるよりももっと良いプロダクトが作れると思います。
社内向けも楽しいよ！
社内向けのプロダクトとか、ぶっちゃけ地味です。CtoCのイケてるプロダクトの方が、なんかイケてる感あって楽しいなと思うのは本音の部分であったりします。
他方で、ユーザーとの距離が圧倒的に近いという最大のメリットがあります。なんでも気楽に聞けるし、チャーンがあるわけでもないのでかなり踏み込んだ話をしても特に問題ありません。その上で、今すぐ聞ける、、、というのはかなり大きなメリットです。
また、プロダクトづくりを通して事業の売り上げや効率化に貢献出来るということは、社内プロダクトならではの話だと思います。自分たちの作った機能で業務効率が20%改善されるとか胸熱ですよね。
そんなこんなを考えながら日々遊んでいます。楽しく一緒に遊んでくれる人を探していますので、お気軽にフォローでもしてください！
いいなと思ったら応援しよう！
