1. 雨宿りとWEBの小噺.fm
  2. Season -No.231 朝活「人の出..
2023-05-19 25:54

Season -No.231 朝活「人の出入りがある前提でチームをどう設計するか? 信頼残高が足りない組織が、持続可能性を高めた「仕組み」」をダラダラ読む回

エピソードをシェアする

Share on X Share on Facebook Share on Threads
spotify apple_podcasts youtube

はい.第231回は


人の出入りがある前提でチームをどう設計するか? 信頼残高が足りない組織が、持続可能性を高めた「仕組み」

https://logmi.jp/tech/articles/327383


を読みました💁


ではでは(=゚ω゚)ノ

  • プロダクトマネージャーカンファレンス 2021
  • ユニファ株式会社
  • ルクミー
  • HCDサイクル
  • 信頼残高
  • 1on1
  • 組織
  • プロダクト
  • PdM
  • 人員不足課題
  • 採用母集団

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

00:05
はい、えー、5月8日月曜日ですね。僕は朝9時7分になりました。今日からついにまた俺の日が明けまして、5月本格的にスタートって感じですね。
はい、おはようございます。エミドキースこと桑原です。えー、では本日も朝活を始めていきたいなと思います。えー、本日はですけれども、昨日前に言った通りですけども、
まあ、その採用前の記事をちょっと読んでいこうかなと思っておりますと。僕もそのToDoに入っていた記事なんですけども、タイトルにあります。
人員不足は採用だけでなく、戦力化にも課題がある。フルリモート化のプロダクトマネジメント組織の立ち上げ先記事ですね。この記事をちょっと読んでいこうと思ってます。
今回の記事は、完全に日本語の記事なんですけど、インタビュー記事になりますね、こちら。ログミーですね。ログミーテックのインタビュー記事になります。
イベントはプロダクトマネージャーカンファレンス2021というのがあったらしくて、そこでのユニファ株式会社の山口さんという方が登壇されていて、その山口さんのお話ですね。
今日は読んでいこうかなと思っております。正確に言うとスピーカーはユニファ株式会社のプロダクトデベロップメント本部、プロダクトマネジメント部の部長代理の山口さんという方です。
登壇当時がその方だけだと今はちょっとわからないですけどね。では早速入っていきたいと思いますが、山口さんですね。ありがとうございます。ご参加いただきありがとうございます。
今から本記事をダラダラと読んでいこうと思っております。では行きましょう。山口氏の自己紹介から入ります。
ユニファ株式会社の山口と申します。よろしくお願いします。時間もないのでサクサクいきたいと思ってます。
今日はフルリモート化においてプロダクトマネージメント組織をどうやって立ち上げたらいいのかという話ができればと思っております。
そのため個人のプロダクトマネージメントスキルのような話はしません。また資料が64ページぐらいになっちゃっていますので回数まで話をするといけないですね。
今日話すことで得られる知見とかスキルというところでいくと、その組織の立ち上げ方のところですね。
概要としてはリリースに間に合う体制を走りながら組み立てる現場に急に飛び込んだとして、まずどこか手をつけるべきか悩みますよねっていう話と、
プロダクト開発でも利用されるノウハウというのを駆使しながらチームとしていつどのように試作を進めていけばよいかというのを話します。
20分で回数まで話をするのでよくわからなかった点とかは後ほど聞いてくださいという感じですね。
改善についての話をすると前の人をめちゃくちゃ否定しますがその時にはその時なりの正しさがあるので前の人を特に否定するものではないです。
資料が多くなりすぎてしまったのでおまけというページの説明はしませんが後でぜひ見てくださいということで前提とした字なんですけど、
本資料は今言ったやつですね。今言った記事をまんま画像に貼られてただけですね。
まず自己紹介ですね。自己紹介は冒頭でどういう肩書きの方かと一応おしゃべったんですけど、人間中心設計の専門家でもあるんですねこの方。
プロダクトマネージャーはPDMをやられていて一時2歳の父です。2021年記事なんて今は4歳の父かなというところです。
もともと企画の人だったんですけど行動もかけるタイプになったプロダクトマネージャーです。
03:05
人間中心設計の評議委員会とかにも所属したりプロダクト開発に関わる技術顧問をやったりすると多岐にか渡って活躍されている方だそうですね。
同時に8プロダクトを出さなければいけない背景というところから入るそうですね。
今回はルクミーという保育のICTのサービスを取り上げていきます。
このサービスは2021年9月にリリースされたものです。
保育施設に子供が通っていると分かると思いますが連絡帳などの管理業務が色々あります。
スライドを示してルクミーというサービスではオレンジのマークをつけたところを全部新しく作っていますのでかなり広い範囲ですね。
連絡帳だったりお便りだったり帳簿管理だったりいわゆるドクメンテーションだったり請求管理だったり登録円だったり投稿円だったりとかその辺のところですね。
保護者向けのアプリだったりというのをやっています。
サービスのところを全部新しく作り直しているところですね。
同時に8プロダクトというのは実際このぐらいの規模感になってくる。
中を見ていくと連絡帳1つ取ってもウェブを作らなければいけなかったりアプリも作らなければいけなかったりとか
プロダクト数でいくと2桁作っているのが現実だということですね。
8サービスですけど現実には複数、2桁のプロダクトを同時に作ってリリースをしようとしていると。
なかなかタフなプロジェクトを進めている感じですね。
こういうのを見ると少しずつやればいいんじゃないですかとか選択と集中ができていないんじゃないですかとか感じると思います。
でも実際の円の運用っていうのは1つだけICT化できればいいという話ではもちろんないです。
連絡帳がA社、投円社がB社というバラバラになっちゃうと結局はアカウントが多すぎてつらくなってきて
保護者にも説明できなくなってしまうのでできる限り1つにまとまっていることが実は大事です。
同時に8プロダクトを出さなければいけない背景にもなっています。
現実とか社会を考えたらそうですよね。
サービスの行動を考えると。
それは確かにそうなんです。
円とか市列の業務とサービスの話ですけど子供を見つつ数多くの事務処理に追われている状況で
連絡帳という話ですね。
全部紙の方が実は楽だったりというところですね。
1つのサービスである程度の業務がカバーできてほしいしサービス間でのデータ共有と活用ができることも必要です。
あとはキッズリーの利用者がルクミンを安心して利用できる担保というのが必要です。
なのでサービスを飛び越えた連携がうまいことできてほしいということですね。
できる限り1つのサービスで解決できるということが円の施設の人だけではなく保護者にとっても分かりやすい。
続いて具体的な話をしていきたいと思いますが
本当にこの会社に入ってよかったんだけというカオスの状態から実はスタートしましたよと。
僕はPM部という部署に所属して部長を代理をしています。
PM部はPDMとQAがいる部署になっていますが
僕自身はプロダクトオーナーPOではなくて開発本部の副本部長がPOをやっている体制みたいなところですね。
そのため僕の役割としてはPMのほうがもちろん中心ですよということでした。
以上の組織図的なところもぺっと画像が貼られていますけどもこれは見てみてください。
もともとは部長をやると思って入社をしていたのではなくて
プレイヤーとして入社をしたので仕事いっぱいやるぞみたいな風に言ってどんどん仕事を取っていきました。
06:00
でも2020年7月末に実は当時のMGR、マネージャーですね。
退職するのでみたいな話になって結果的に9月からマネージャーになりました。
マネージャーをMGRと訳すのは初めてですね。
スライドを示して右のグラフは結構ひどいことになっています。
ルクミーを出す時にはどうしようもない感じでした。
そして今はだいぶ平和が訪れているんですがこれがタイムラインや仕事のやり方ですということで
貼られている画像は左から右に線のグラフが貼られていて
定時業務キャパシティというところとオーバーのところの2つが貼られているんですけど
かなりオーバーしているという感じですね。
2020年7月に山口さんはプレイヤーとして入社して
いろいろ前のめりにキャッチアップしながら物事を進めていた。
この時はまだ定時業務のキャパシティは全然超えていなかった。
7月の末ですね。
マネージャーの方が退職されて引き継ぐことになったという瞬間そのキャパシティを超え始めたよと。
それでもまだ超えてはいるんですけど余裕がないわけではなさそうだと。
同年8月ですね。
7月末から8月に入ってマネージャー会議に入りながらキャッチアップするんですけど
ここでどんどんキャパシティ超えたオーバーの業務が増え始めていって
マネージャー着任と同時にいわゆる使用期間が終了になりましたと。
この時にキャパシティとオーバー分の分量が結構いい勝負し始めてきてて
ルクミーシリーズの正式リリースですね。
時は超えて1年間です。
2021年の9月には定時業務キャパシティの3倍のオーバーワークが入っていますと。
これ単純に定時業務キャパシティを高数1とすると高数4の稼働をしてるっぽいですね。
なんか凄まじいことされてますね。
で、リリース後の改善成長フェーズに入って
元通り定常業務キャパシティプラスちょっとだけオーバーみたいな感じに戻ってきたと。
凄まじい1年間だったんだろうなと思います。
もうすぐ戻りますね。
着任直後にあったことですけど、ベテランの人がたくさん辞めたり
毎月開発部で誰かが辞めたりとか
あとPDMとして入ったらPDMってそもそも何ですかとか
うちにPDMとかないのでもう辞めてくれませんかみたいなことを言われて
正直もうダメかみたいな感じになってたんです。
PDMとかないので辞めてくれませんかって言い方は結構きついですね。
上としては必要だったりこれが大事だろうから
ミッション持ってやってたのにそれを辞めろと下から言われるって
これかなり辛いですよね。
この会社に本当に入ってよかったんだけっていうカオスなメンタルになっていたっていうのが当時の話です。
ベテランの方は既に退職決定されていて
しかも開発部も毎月誰かしらが退職していて
下から先みたいに付き上げがあって
もう人員も足りないしロードマップのアサイン予定という文字とか数字が入ってきて
やばいみたいな感じです。
ちょっと急に全然違う話をしますが
人間中心設計サイクルというようなお話です。
人を中心にした開発サイクルというのが
そのHDにあるらしいんですけどその話をちょっとしようと。
これはプロダクト開発のサイクルに当てはめると
ユーザー観察をしてユーザーのAzizや2Bを見ていくところで
09:00
ユーザーの調査をしてモデル化をして仕様を作って
プロトタイピングを行ってユーザーの要求と合っているか合っていないか
っていうのを確認する手順をぐるぐる回すことになってきます。
これを組織開発に当てはめていくと
Azizの不安があるならば
採用基準を変えましょうとか評価制度を作りましょうという提案をして
最終的に成果が出ているか採用育成数が増えたか
というのをみんなで確認するサイクルになってきます。
つまりよくよく考えてみるとプロダクトも人も一緒ですよね
ということで無理やりモチベーションを上げていきました。
なかなか面白いですね。
ユーザーを見てプロダクト開発を推進しているのであれば
同様の視点プロセスで組織開発も推進できそう
もともとカオスなことは結構好きで
人間中心設計の専門家のスキルも活かせるところがあったので
この際面白そうだからやってみようと思い実際にやってきたのが
この話になっています。
まずユーザー観察しましょうなんて言っているんですけど
リモートなんで人と会わないんですよね。
そもそもリアルで会った人がいなくて開発のマネージャーにも入社して
1年半で初めて会ったのでどうしようという状態でした。
フルリモートのよくある話ですよね。
2年くらい経って初めて去年の新卒とリアルで会いました。
よくありますから。
さらに普段用形定義をしていても何の話をしているのか
全くわからない状態だったのでいかに早くキャッチアップするかが
大事なポイントとしてありました。
これはまあ本当そうですよねオンボーディングじゃないですけど
スタートが肝心なのでここに注力をしたっていうのは
それはいい話なんじゃないかなと思いますね。
次で組織のことを知るために行ったことという話です。
まず①
まずやったことはスラックにある100個のチャンネルに入りました。
100を多いと思うか少ないと思うかは
多分組織によりますけど
皆さんはツイッターは何千人もフォローしているじゃないですか。
なので大丈夫ですし100のチャンネルを見ていくと
みんながやっていることがなんとなくわかるんですよね。
問題はその100のチャンネルに入るだけじゃなくて
この人たぶんちゃんと見られてるんでしょうね。
これを観察するっていうのは結構なエネルギーだと思うので
これはすごいことですね。
リモート化された影響でだいたいがスラックで話がされているので
ワンオンしてもあの話大変そうだねって話をすると
なんで知ってるんですか?みたいな引き出しが増えてきました。
とりあえず余計なチャンネルから抜けるべきみたいな話もありつつですけど
リモートでシンジマネジメントなのに情報を絞っている場合ではないというところで
とにかく片っ端から入ってたって感じですかね。
ツイッターだと思えば100チャンネルぐらい大したことないっていうのは個人の感想です。
うちも社内スラックが完全に社内ツイッターと化している感じがありますので
同じ感じがですね。
何が社内で動いているかっていうのがその代わりに全部流れてくるので把握できると。
発言の多さからキーマンが誰かってのも分かってくると。
出てくる単語の多さとか使われ方からその意味も分かってくるんですね。
何かトラブルが起こっていてもすぐ把握もできますと。
ワンオンであの話ですよねって言える引き出しが増えるのが
このリーダーとしては良い話だったということですね。
あとはユニファ株式会社ではコンフルエンスという社内ウィキを使っているので
全ての更新がフィードで見られます。
スラックはフローなのでちょっと追い切れませんけど
12:02
コンフルエンスであればストックになっているのでこれを見ることで過去の経緯がわかりますと。
いいですね。ツールの使い分けがしっかりしていると。
過去のリスペクトができていない発言をしないために何をしたらいいのかというのが
ここから分かるので社内のGoogleのような素敵だなみたいなことで
よく使ってましたと。
社内ウィキのフィードを結構斜め読んでみると。
スペースの過去ログへの興味が増したりとかですね。
やっていることはウィキペディアをひたすら読むことによる時間泥棒って感じは正直あります。
新人にとって過去の経緯の理解はすごく大事なので
その過去をリスペクトできない発言は相手に聞いてもらえないという背景もあるので
このフィードは逆に言うとすごく助かったという話ですね。
それは本当そうだよね。
結局会社というのは歴史があるのでその歴史とか背景を知った上での発言ができないと
というのは正直あると思うんですよね。
でないとこの人新人だよねとかまだこの人こっちの会社で理解できないよねっていう風に
既存社員を持っちゃうのでそれは本当そうだなと。
あとはなんだかんだ人ですと。
入社する時に会った人とか明確な肩書きはないけれど
この人はきっとキーマなんだろうなみたいな人を捕まえたりとか。
10人ぐらいでリモート会議をしても自己開示してくれることはないので
一人一人話すことを多くしたり。
あとはメンバーに関してもなんか嫌なことがあったら全部マネー会。
いわゆるマネージャー会議で大事にするのでぜひ言ってねと話をして
課題を全部吸い上げていきました。
自分にも影響があったり僕が責任を持たなきゃいけないとか
私が言ったんだってことがバレて
そこによる他者からの目が怖いので
発言したくないっていう人も結構おるんじゃないかなと勝手に思ってるんですよね。
なのでそこを吸い上げていけたっていうのはすごい良い話ですね。
社内文化としてしっかり意見を出すっていうのが
浸透してるんだろうなって良い話だという風に聞こえました。
あとそのリモート化におけるキャッチアップでやったこと3ですが
関連する人とのワンワンを結構やったと。
自分以上いるミーティングで積極的に自己開示をしてくれる人っていうのは
やっぱりエンジニア組織では少ないと思います。なので個別に背景を把握すると。
まあそりゃそうだよね。
自己開示って結構エネルギーいるしさらにリモート化において
余計に出さない人の方が多いと思うんでね。
採用面接時に面談してくれたプロジェクト前任者とまず話してみると。
あとは今何が起こっているのかっていうのをスラックやウィキで把握しつつ
それを特定の個人として思っているかっていうのをまず把握していきましょうとか。
あとは明確な方だけじゃなかったとしても
職種やサービスのキーワーになっている人っていうのが
社内に出ているはずなのでその社内の普通のやり方について聞く。
普通をちゃんと把握するってすごく大事ですよね。
最後で全員が先輩になるPM部メンバーに対しては
何かやりにくいことはないかみたいな
マネージャー会に持って行きますし今ならわからないことを武器に色々着けるんで
みたいなスタンスで変わらない人を拾い上げるってことですね。
ちゃんと下に出ていくっていうのはすごくいい話ですね。
結果的にこんな組織課題があることっていうのは把握できましたと。
人が足らないとかPDMって何ですかみたいなこととか
みんな辞めていくので結局ネガティブになっていますとか
雰囲気がですね。などなど。4つ目はもはやどうしようもないんですけど
信頼残高が全然ないという話ですね。
2ヶ月前に入社してきて急にマネージャーになって
余計なことをしそう困るみたいな雰囲気があったので
これを何とか解決しなきゃいけないってことはこの時点でありました。
これもありそうですよね。まあ仕方ないと思います。
15:01
おかしいのは俺は物を作りに来たんだけどなっていう思いを張りつつ
物を作るためには組織を作らなきゃいけないので
このあたりを頑張ろうと取り組んでいます。本当この視点大事ですよね。
僕建築でも同じような話とかよくしますよね。
大きな建物とかを作るにはそれより大きな枠とか
土台とかが必要になってくるんですよね。
物さえ作ればいいっていうのは実は本質ではなかったりする
っていう話はよくあるので。これ大事なので組織を
作らなきゃいけないんですよね。
結果把握できた組織課題は今言った4つですね。
人位不足と曖昧なPDMの期待値と
あちこちにあるネガティブな雰囲気と。最後は自分に対する
信頼残高の不足ですね。これは本当どうしようもないですよね。
続いて人位不足課題の分析から
入っていきたいと思います。課題の分解と
試作の検討が始まる話になるんですけど
人位不足が何かというと採用が足りないだけに正直見えるんですけど
実際はその人を育てて戦略化するところまでが足りてないんですよね。
とにかく入れればいいって話じゃないと。
分解すると募集団が足りないという話もあるし
育成期間がかなり長いとかオンボーディングでよく言われるやつです。
戦略化っていうのはアサインが下手だから力が発揮できないという話もあるので
これを全部何とかしようと思いました。
まあそうだよね。適材適所で能力がピタッとはまったら
その本人は勝手に戦略になってくれますからね。
もちろん丸投げしとか放置すればいいってわけではないですよね。
ここでもうちょっとステップの話を分解しますけど
採用人数っていうのはイコール募集団×書類突破率×
面接突破率×内定承諾率と
ほんとそうですよね。まず募集団を増やしましょうとか。
育成に関しても育成人数は採用人数×育成期間を
育成必要期間で割ってあげます。
最後戦力ってことですけど
戦力はイコール育成人数×有効アサイン率だという話ですね。
なるほど。
採用ですが先ほども話した通り社内で言われている
PDMの役割が全員違うっていうことがあるので
社長に聞いてみるとPDMはミニCEOだという話をしていますが
開発CMに聞くと開発ディレクターがいればいいので
という話をされて
トップと現場での思いとか期待値視点が違うよと
あとは実は僕が入ったタイミングぐらいで
トップダウンで社内のディレクターがPDMになるように
と言われたんですけど正直何ですかそれってこんなの起きたので
PDMとかいらんみたいな雰囲気が現場では出ていたと
とにかく開発ディレクターの方が欲しいということですね。
またミニCEO的な人を取ったら活躍できるのかというと
実際その人の仕事はなかったようなこともあったので
正直つらかった。
給食者についても今の開発者が何をやっているのか分からないので
ミニCEO的な役割をやりたくて入社してもそれが自分のキャリアにとって
正解なのか分からないということもありました。
難しいですね。トップの意思とか気持ちとかっていうのをちゃんと
説明席にもやっぱ必要なんだよなってツクツク思いますね。
立場役割の違う人の語るPDMが全部違う人ってことですね。
ミニCEO的な人を求めるマネジメントと
開発ディレクションをする人を増員してほしいという
開発チームのギャップっていうのがずっと大きくて
採用広告にもそのぴったりの人が採用できても現場では活躍できない
スキルセットっていうのがあると。
18:01
それは本当にぴったりな人だったのかどうかっていうのもまた疑問ではあります。
さらにこのユニファー社の開発者が何をやっているのかっていうのが
意外と認知不足だということですね。
どんなキャリアを歩めるのかっていうイメージもなかなかしづらいし
死亡先としてもなかなかこの会社が早期されないという
課題があったと。これ大きい話ですね。
このミニCEOが今のユニファー株式会社に
少し合わないということは現実にありました。
例えば保育施設の話だと、行政にアプローチしたり
教育関係者とこの先の保育についての話をしたり
でも物理でも考えなきゃいけない。
プロダクトが分かる人が一人だけいてもしょうがないところがあるので
みんなで手分けしてやるべきだというのが結論になりました。
8つのプロダクトを出さなきゃいけないのでまずそこを何とかしてほしい。
PDMとしての期待値もものすごくあったので
まずはそこをやったほうがいいという話になりました。
世間ではミニCEOだと言ってますけど…みたいな話ですね。
少なくとも現状にユニファーに合わなかったということですね。
少し細かいんですけど社内で話した内容が書いてあるので
この辺りをおまけとして残しておきます。ぜひ参考にしてみてください。
おまけの話ですけど仮説検証が十分になされていない
課題とかソリューションに対して迅速に動くものに対する
利用者の反応を見て改善を回す。いわゆる
小規模なプロダクトのところにフォーカスをした。
企画とエンジニアとデザイナー3人いれば最小整理するチームが
作られる。そうだよね。トラクションを取れる
プロダクトを最速で出すところに貢献できる最小単位。
課題に対し芯を突いたソリューションをいち早く提供することが
事業成功の軸であり企画書ベースで受注した後
いかに短期間で動くものを出せるか。
近いものがあまりなく事業を考える人が最もそれに対する
解像度が正直高い状況です。
規模もそこまで大きくないので人が最小限の方が
コミュニケーションコストも下がり結果有効時間が増える
っていう王道に帰っていった感じがすごいしますけど
でもちゃんと一つのプロダクトを小規模な
会社に近いですねここまで。で動けるように
最小単位で動かせたってことですね。これはまたいい話でしたね。
あとおまけですけどPDMがミニCO的な役割を兼ねない方が
いいプロダクトでもあると。
ソリューションの方向性がおおよそ見えており
営業アライアンスが肝になるプロダクトとかあるいは規模が
大きく推進するにも成功数がかかるプロダクトとかですね。
その協会の人と繋がり大手パートナーと組めることが
重要な状況だったという話ですね。
不動産系や医療系プロダクトの方がこれに近いと。
大体の場合プロダクトそのものより導入サポートや
実証実験にかかるパートナー探しなどの方に時間が取られる。
これも本当によくある話ですね。
開発チームとのコミュニケーションに時間を割くより
状況を優先した方が事業貢献はしやすいという話ですね。
事業視点がありプロダクトを全部任せられる人として
PDMを置くのが落としどころでしょう。
事業責任者と守備範囲は被ってしまいますが
PDMはユーザー視点でプロダクト中心の領域を担保していきます。
事業を見る側としてはアライアンス先の意見や
直近の受注を優先したくなるものなので
あえて頭を分けて最適を議論できるようにします。
とはいえ、ずっとPDM的な仕事だけでいいのかというと
そんなことはもちろんない。既存のディレクター陣と
21:02
話をしていても社内外注だけじゃないので
サービスを大きくしたいんだよねという話もあります。
そういう話を聞いていくと事業をグロースさせていくというPDMも
います。それをプロダクト軸で考えてもいいし
いわゆるミニCEOでなくてもいい。そう考えると確かに
権限が足りない。顧客情報の接点が足りない
みたいなのがありました。そこを頑張ることで既存の
ディレクターがPDMとして活躍できる道が描けるんじゃないの
というふうにこの時に思いましたよ。
リリースまでとリリース後で求められる役割の種がやっぱある。
それは本当はありますよね。またリリースからがむしろビジネスとしては
本格的スタートですからね。サービスをグロースしていく上で
納期を守ればOKという意味ではもちろんなくなる。
そこまではたぶん守りのある話でいえ
リリース後のグロースは完全に攻めの話ですよね。
実際既存のディレクターPDMメンバーも
伸ばしていきたいということは変わりはない。ただ急に事業リーダー型
を求められてしまうとそれはキャンでもウィルでもなくなるので
本人の強みもいかせない。開発を軸に事業グロースに
貢献できることは当然あり、そのためにはいくつかの
権限以上だったりとか顧客情報への接点拡大などが
必要になります。そのための階段をどう上っていくか
という建設的な議論が内部で進んでいるというのが
今最中です。既存メンバーにのっとって
PDM的なキャリアを選ぶことが
結果的に自分のやりたい方向性に進めるよという道も
作っていく必要があります。結果的に整理したのは
この辺りです。左はマネジメントで事業リーダーが
欲しいですね。PLがかけるPDMが欲しいと
言っているけど現場では開発ディレクションができる人が
欲しいですと言って実は全然違うという話ですね。
マネジメント認識では全職が企画や営業
コンサルの人を取ろうとしているけど現場はエンジニアと
ディレクターを欲しがっていたのでその基準違いますよとやっぱり
マネジメント認識と現場の認識の合わせということですけど
今4つの軸標が
張られていて横軸には期待業務と
相性の良い事業とベース職種ということですね。縦軸に
マネジメント認識と現場の実際の認識というところの
縦と横の軸でいろいろ張られています。
ちょっとこれ口頭すると長いので皆さんで後で見てみてください。
結局それをですねギャップが大きくありすぎて
誰が言うのって話ですね。問題提起を誰がするか
と言うと部長代理ということで結局山口さんが
言いに来ましたと。11月なので入社して4ヶ月
ぐらいで社長や人事の偉い人に給与に対する
レジュメのスペックが強すぎて無理ですみたいな話とかそもそも
考え直しませんかみたいな気持ちの資料を出したりしていましたと。
今考えるとよくそういうのを受け入れてくれたなと思うんですけど
嫌われようがなんだろうがこれを変えない限りは物が作れない
なんとかするぞという気持ちでやってきましたと。いや強いですね。
本当に嫌われ状と指摘と対案のアクションの
開始をスタートしたとこですね。僕も弱い
人間なので嫌われるのは嫌だなと思っていて
会社のエンジニアブログにはマネージャーって嫌われることが仕事なんで
という記事を書いて逆に社内からハンカーを買うこともありましたと。
でもそれぐらい排水の陣で
やらなければいけないと当時は思っていましたと。いやー本当
すごいですね。人位不足課題の対策と得られた
24:00
結果ですと。というわけで細かい話なんですけど
結果的に求人広告の内容を直しましたと。
もともとはPLが書ける人などって書いていて
求人を全部求めていたんですけどやめましたと。
そういう書き方は。おまけとしてそれも付けたんですけど
どういうふうな書き方変更したのかというのもちょっと後で見てみてくださいと。
結果何が得られたかというと採用
基準がぶれなくなりましたと。そもそも欲しいPDMが
全員違うところがなくなったのでぶれなくなりましたと。
それができるようになったのでHD面接のコンバージョンも上がったし
書類と全然違う人が来ることもだいぶなくなりました。
そうすると他社で活躍したPDMを取りましょうという感じになってきましたけど
今のユニファ株式会社と役割が違うので
というような人をちゃんと選考自体できるようになりました。
仮にその人が入社してきても何かが違うのでタイプマッチしない
ということが起こりづらくなったかなと思いますと。
しっかり古い、古いじゃないですね。
カルチャーフィットする人が取れるようになってきたところですね。
あとPDMが何をできる人なのかって決まるとどう育てていったらいいのか
っていうのもわかるので今後のアサイン戦略もわかります。
結果採用募集団もなんとかなるし採用後にどう育てたらいいか
っていうのもわかりますしアサインもわかって最高な状態が生まれましたよ
ってことですね。まあその結果今の話ができましたと。
この話は次回へ続くって書いてますね。なるほど。
わかりました。というところでこれの続きはまた
別の記事のリンク貼られてるのでそれは明日読もうと思いますので
今日の朝方はちょっと中途半端にここで一旦区切ろうと思います。
本日の参加者はリーズさんとネブさんとレノアさんですね。
ご参加いただきありがとうございました。
最近噛み噛みで聞き潤して大変申し訳なかったんですけど
明日もこんな感じでのんびりやっていこうと思います。
月曜日ですね。またゴールデンウィーク明けというところで
憂鬱な人もいればよしやるぞっていう気持ち切り替えられたら
いろんな方いらっしゃると思いますけど
お互い一緒にまた今週からですね。
5月本格スタート頑張っていけたらなと思います。
それでは終了したいと思います。お疲れ様でした。
25:54

コメント

スクロール