人員不足は採用だけでなく「戦力化」にも課題がある　フルリモート下のプロダクトマネジメント組織立ち上げ戦記

山口氏の自己紹介

山口隆広氏：ユニファ株式会社の山口と申します。よろしくお願いします。時間もないのでサクサクといきたいなと思っています。

今日は「フルリモート下において、プロダクトマネジメント組織をどうやって立ち上げたらいいのか」という話ができればと思っています。そのため、個人のプロダクトマネジメントスキルのような話はしません。資料が64ページくらいになっちゃいるので、かいつまんで話していきます。

改善についての話をすると前の人をメチャクチャ否定してしまう感じになってしまいますが、その時にはその時なりの正しさがあるので、（前の人を）特に否定するものではありません。

資料が多くなりすぎちゃったので、「おまけ」というページの説明はしませんが、後でぜひ見てください。

自己紹介としては「お父さんなんだな」というところだけ見てもらえればと思います（笑）。あと、人間中心設計専門家でもあります。

同時に8プロダクトを出さなければいけない背景

今回は「ルクミー」という保育のICTのサービスを取り上げていきます。このサービスは2021年の9月にリリースされたものです。

保育施設に子どもが通っているとわかると思いますが、連絡帳などの管理業務がいろいろあります。（スライドを示して）「ルクミー」というサービスでは、オレンジのマークを付けたところ全部を新しく作っています。同時に8プロダクトというのは、実際このぐらいの規模感になってきます。

実際に中を見ていくと、連絡帳1つとってもWebを作らなければいけないし、アプリも作らなければいけないしで、プロダクト数でいうと、2桁作っているのが現実です。

こういうのを見ると、「少しずつやればいいんじゃないですか」「選択と集中ができていないんじゃないですか」と感じると思います。でも実際の園の運用って、1つだけICT化できればいいという話じゃありません。「連絡帳がA社、登降園がB社……」とバラバラになっちゃうと、結局はアカウントが多すぎてつらく、保護者にも説明できなくなってしまうので、できる限り1つにまとまっていることが実は大事です。これが同時に8プロダクトを出さなければいけない背景になっています。

「本当にこの会社に入って良かったんだっけ」というカオス状態からスタート

というわけで具体的な話をしていければと思います。僕はPM部という部署に所属して、部長代理をしています。PM部はPdMとQAがいる部署になっていますが、僕自身はPO（Product Owner）ではなくて、開発本部の副本部長がPOをやっている体制になっています。そのため、僕の役割としてはピープルマネジメントが中心です。

もともとは部長をやると思って入社はしていなくて、プレイヤーとして入社したので、「仕事をいっぱいやるぞ」と言って、どんどん仕事を取っていきました。でも、2020年7月末に「実は当時のMGR（Manager）が退職するので……」という話になっていて、結果的に9月ぐらいからMGRになりました。

（スライドを示して）右のグラフがけっこうひどいことになっていますが、「ルクミー」を出す時にはどうしようもない感じでした。そして今はだいぶ平和が訪れているというのが、これまでのタイムラインや仕事のやり方です。

着任直後にあったことですが、ベテランの人がたくさん辞めたり、毎月開発部で誰か辞めたり。あと、PdMとして入ったら「PdMって何ですか？」「うちにPdMとかないので、もうやめてくれませんか」みたいなことを言われて、「ダメか……」という感じになっていたんです。

「本当にこの会社に入って良かったんだっけ」というカオスな状態になっていたのが、この当時の話です。

HCDサイクルを組織開発に当てはめてわかる大事なこと

急にぜんぜん違う話をしますが、HCD（Human Centered Design）サイクルという、人を中心にした開発サイクルみたいなものがあります。

これをプロダクト開発のサイクルに当てはめると、ユーザー観察をして、ユーザーのAs IsやTo Beを見ていくところで、ユーザーの調査（をし）、モデル化をして、仕様を作って、プロトタイピングを行い、ユーザーの要求と合っているか合っていないかを確認する手順をぐるぐる回すことになります。

これを組織開発に当てはめていくと、1on1をして、As Isの不安があるならば、「だったら採用基準変えましょう」「評価制度作りましょう」という提案をして、最終的に成果が出ているか、採用育成数が増えたかをみんなで確認するサイクルになっていきます。つまり、「よくよく考えてみるとプロダクトも人も一緒ですよね」というところで、無理やりモチベーションを上げていきました。

もともとカオスなことはけっこう好きで、人間中心設計専門家のスキルも活かせるところがあったので、この際おもしろそうだからやってみようと思い、実際にやってきたのがこの話になっています。

まず、「ユーザー観察しましょう」なんて言っているのですが、リモートなんで人と会わないんですよね。そもそもリアルで会った人がいなくて、開発のMGRにも入社して1年半で初めて会ったので、「どうしよう……」という状態でした。

さらに、ふだん要件定義をしていても何の話をしているのかまったくわからない状態だったので、いかに早くキャッチアップするかが大事なポイントとしてありました。

組織のことを知るために行ったこと

というわけで、「組織のことを知りたい編」という話をしていければと思います。

まずやったことは、Slackに（ある）100（個の）チャンネル（に）入りました。「え⁉」と感じると思いますが、みなさんTwitterは何千人もフォローしているじゃないですか。なので大丈夫ですし、100チャンネルを見ていくと、みんながやっていることがなんとなくわかるんですよね。

リモート化（された影響）で、だいたいSlackで話がされているので、1on1をしても、「あの話大変そうだね」という話をすると、「何で知ってるんですか？」というように引き出しが増えていきました。

あとは、ユニファ株式会社ではConfluenceという社内Wikiを使っているので、すべての更新がフィードで見られます。Slackはフローなのでちょっと追いきれませんが、Confluenceであればストックになっているので、これを見ることで、過去の経緯がわかります。

過去のリスペクトができていない発言をしないためには、何をしたらいいのかがここからわかるので、「社内のGoogleのようで素敵だな」ということでよく使っていました。

あとは、なんだかんだで人です。入社する時に会った人や、明確な肩書きはないけれど「この人はきっとキーマンなんだろうな」という人を捕まえたり。10人ぐらいでリモート会議をしても自己開示してくれることはないので、一人ひとり話すことを多くしたり。

メンバーに関しても、「何か嫌なことがあったら全部マネ会（マネージャー会議）で大ごとにするのでぜひ言ってね」と話をして、課題を全部吸い上げていました。

結果的に、こんな組織課題があることは把握できました。「人が足らない」「PdMって何ですかとなっている」「みんな辞めていくのでネガティブになっている」などです。4つ目はもはやどうしようもないんですが「信頼残高がぜんぜんない」と。

2ヶ月前に入社してきて、急にMGRになって「余計なことをしそう、困る」という雰囲気があったので、これを何とかして解決しなければいけないなということは、この時点でありました。

「おかしいな、俺はモノを作りに来たんだけどな……」という思いはありつつ、モノを作るためには組織を作らなきゃいけないので、このあたりをがんばろうと取り組んでいます。

人員不足課題の分析

次は、課題の分解と施策の検討が始まる話になります。

人員不足が何かというと、採用が足りないだけに見えるんですが、実際は「その人を育てて戦力化する」ところまでが足りないんですよね。分解すると、母集団が足りないという話もあるし、育成期間がかなり長いとか。オンボーディングなどで言われるやつです。

戦力化は、アサインが下手だから力が発揮できないという話もあるので、これを全部なんとかしようと思いました。

採用ですが、先ほどもお話したとおり、社内で言われているPdMの役割が全員違うということがあります。社長に聞くと「PdMはミニCEOだ」という話をしていますが、開発チームに聞くと「開発ディレクターがいればいいので」という話をされて、ぜんぜん違うと。

あとは、実は僕が入ったタイミングぐらいで、トップダウンで社内のディレクターがPdMになるようにと言われて、「何ですかそれ？」と混乱が起きていたので、より「PdMとか要らないんですけど……」みたいな空気になっていました。

また、「ミニCEO的な人」を採ったら活躍できるのかというと、実際その人の仕事はなかったようなこともあったので、けっこう辛いと。

求職者についても、今の開発者が何をやっているのかわからないので、ミニCEO的な役割をやりたくて入社しても、それが（自分のキャリアにとって）正解なのかわからないということが起こっていました。

この「ミニCEO」が、今のユニファ株式会社には少し合わないということは現実的にありました。例えば保育施設の話だと、行政にアプローチしたり、教育関係者とこの先の保育についての話をしたり（しつつ）、でも物流も考えなきゃいけない。プロダクトのわかる人が1人だけいてもしょうがないところがあるので、「みんなで手分けしてやるべきだ」という結論になりました。

かつ、社内的には8つのプロダクトを出さなければいけないので、まずそこを何とかしてほしい。PdMとしての期待値がものすごくあったので、まずはそこをやったほうがいいという話になってきました。

（スライドを示して）少し細かいですが、社内で話した内容が書いてあるので、このあたりでおまけとして残しておきます。ぜひ参考にしてみてください。

とはいえ、ずっとPdM的な仕事だけでいいのかというと、そんなことはないですよね。既存のディレクター陣と話していても、「社内外注じゃないので、サービスを大きくしたいんだよね」という話がありました。

そういう話を聞いていくと、事業をグロースさせていくPdMもいる。それはプロダクト軸で考えてもいいし、ミニCEOでなくてもいい。そう考えると、確かに権限が足りない。顧客情報の接点が足りないということがありました。そこをがんばることで、既存のディレクターがPdMとして活躍できる道が描けるんじゃないかとこの時に思いました。

（スライドを示して）結果的に整理したのはこのあたりです。左はマネジメント認識で、「事業リーダーが欲しいです」「PLが書けるPdMが欲しいです」と言っているけど、現場では「開発ディレクションできる人が欲しいです」と言っていて、ぜんぜん違う。

マネジメント認識では前職が企画や営業、コンサルの人を取ろうとしているけど、現場はエンジニアとディレクターを欲しがっていたので、「その基準違いますよ」と言わなければいけない。

ではそれを誰が言うのかというと、部長代理ということで、僕が言いに行きました。

11月なので、入社して4ヶ月ぐらいで、社長や人事の偉い人に「給与に対するレジュメのスペックが強すぎて無理です」という話や、「そもそも考え直しませんか」とお気持ちの資料を出したりしていました。今考えてみるとよくそういうのを受け入れてくれたなと思うんですけど、嫌われようがなんだろうが、これを変えない限りはモノが作れないので、「何とかするぞ！」という気持ちでこの時はやっていました。

僕も弱い人間なので、嫌われるのは嫌だなと思っていて、会社のエンジニアブログには「MGRって嫌われることが仕事なんで」という記事を書いて、逆に社内から反感を買うこともありました。でもそれぐらい背水の陣でやらなければいけないと当時は思っていたんです。

人員不足課題の対策と得られた結果

（スライドを示して）というわけで、細かい話ですが、具体的に求人広告のこんなところを直しました。もともと「PLが書ける人」などと書いていた求人を全部やめたことなどについて、おまけとしてつけました。ぜひ参考にしてみてください。

結果、何が得られたかでいうと、採用基準がブレない。そもそも欲しいPdMが全員違うところがなくなったので、ブレなくなったんです。それができるようになったので、一次面接のコンバージョンも上がったし、書類とぜんぜん違う人が来ることもだいぶなくなりました。

下手すると、他社で活躍したPdMを取りましょうという感じになっていましたが、「今のユニファ株式会社だとちょっと役割が違うので……」という人をちゃんと選考辞退できるようになりました。仮に（その人が）入社してきても、なにかが違うのでタイプマッチしないということが起こりづらくなったのかなと思っています。

あとPdMが何をできる人なのかが決まると、どう育てていったら良いのかもわかるので、今後のアサイン戦略もわかります。結果、採用母集団もなんとかなるし、採用後にどう育成したら良いのかもわかりますし、アサインもわかって最高な状態が生まれました。

（次回に続く）