00:03
はい、5月10日、水曜日ですね。 時刻は朝9時10分になりました。
えー、今日もいい天気ですね。なかなか暑くなってくる気がしますけども。
はい、おはようございます。いめめめのkeethからくわはらです。
では、本日も朝活を始めていきたいなと思います。
本日は、昨日読んでいた記事の続きですね。
あの、続編です。プロダクトマネージャーカンファレンスというところで、
ユニファ株式会社の方が、ヤモンデさんかな、が語られていて、それの続きのお話になりますと。
昨日は、採用であったり、人の組織のところですね。
数を増やせばいいだけじゃないよ、という話ですし、
数を増やすことが解決策ではないよ、みたいな話の具体的なところをお話しいただいたんですけど、
まあ、それの後半の話をですね、今日はちょっと読んでいこうと思っています。
Aタイトルになりますけども、人の出入りがある前提でチームをどう設計するか、
信頼残高が足りない組織が持続可能性を高めた仕組みについての話ですね。
早速入っていきたいと思います。
改めまして、今回のスピーカーの筆者の方は、ユニファ株式会社のプロダクトデベロップメント本部、
プロダクトマネジメント部の部長代理の山口さんという方ですね。
登壇当時、そういう話でしたということですね。
ではでは、これもちろん続編になるので、前回の記事ですね。
人員不足は採用だけでなく、戦略化にも課題がある。
フルリモート化のプロダクトマネジメント組織立ち上げ戦記というところも一緒に読んでいただければと。
こちらも読んでいただいて、今回の記事を読んでいただくのがいいかなと思っております。
じゃあ入りましょう。
リズさんですね。ほぼ3回だけありがとうございます。
今からタラタラと読み始めていこうかなと思っています。
では後半ですけど、信頼残高が足りない問題の分析というところから入ります。
人はとりあえず採用ですね。人はなんとかなりました。
次は組織と信頼残高を積むというところで、まだまだ終わりがないですよ。
課題の分解と施策の検討実行、そして組織の信頼残高編というところに入りますが、
じゃあでもどうしようかなというところですけど、信頼残高が足りないという問題があって、
とはいえ課題も把握しなければいけないと思ったので、少しショートカットしようと思いました。
もともと組織にいて信頼残高がものすごく高くて、ファシリテーション能力も高いメンバーがいたんです。
その人にいろいろ聞いてみて、ワンオワンしてきてほしいという話をしました。
もちろんそのメンバーが密告者みたいな扱いをされると申し訳ないので、
ある程度匿名性は担保していた形でやっていきました。
いいですね。
でもそういう切り札となるというか、キーパーソンがいらっしゃるというのは本当にいい話ですね。
ネガティブな雰囲気でハードな新規開発はやっぱり持続可能とは言えないということで、
課題把握のために信頼残高をショートカットということですね。
組織は信頼されていない、マネージャーも信頼がない、正直に件を出そうと思わないというふうな負の連鎖が続いていると。
マネージャーが聞かなければならないという縛りももちろんないですし、
課題を解決できるのであれば誰が聞いてもぶっちゃけ良いと。
メンバー間では普通につらみの話をしているはずですと。
なので国ちゃんの立ち位置にならないように匿名性担保でさっきのメンバーに依頼したと。
結果こんな話が出ましたと。
みんな親なので優しくて場を乱したくないという気持ちがやはり強いと。
03:04
一つ一つ見るとそんなことが?みたいなところは思いますけど、
こういうのがめちゃくちゃ積み重なってくると日々辛いんですよねという話で、
ずっと我慢しているから辛くなっていくのでこういったものを大物小物問わず片っ端から倒していきましたと。
でどんなものが出てきたかという言いたいけど言い出せなかった例の話ですね。
とにかく場を乱したくない気持ちがあるが言えに放置されていた課題ですけど、
ざっくり4つぐらい出されてますね。
一つ目の課題は仕様に対してデザイナーは口を出していけないと思っていたし、
想定通りに実装されなくてもエンジニアに指摘してはいけないというふうに思っていたと。
まずデザイナー才能を言い出せなかった課題ですね。
デザイナーはその利用者のタッチポイント責任者なので当然指摘しても全然良いですよっていうのが本当の話です。
2つ目の課題はQAですね。
QAは社内から出る全ての成果物に責任を持つべきだというふうに思っていたと。
なるほどですね。
これもまたQAとかQAエンジニアにありがちなんですけど、全ての責任をQAが持たなきゃいけないというわけでは本当はないですよね。
コース不足なのにコーポレートサイトの高越までスコープにしていたが過剰なので廃止をしたと。
ついでに3つ目の課題はUI評価に対する期待値がずれていると。
これデカいですね。
情報設計のフェーズなのに見た目の話とか標準UIで良いのに独自UIにしようとする見た目の話があって、
UIレビューについてレビュー目的の説明を含め基準合わせというのを実施しましたと。
難しいですね。独自UIにしようとするっていうのはやっぱりやりがちですよね。
プロダクトが運営側としてやり、サービス運営側からするとそういうこだわりを持っているのは仕方ないですけど、
本来はそれ必要なのかどうかというところですよね。
はい、でラスト4つ目の課題ですけど、4つ目は開発マンアプリをPDMとしても確認したいが環境がなくて確認しづらいと。
なるほどね。レビュー関係なかったんですね。
はい、というので開発関係のアクセス手段を追加して確認ハードル以上下げました。
などなどですね。結構大きいものから小さいものまで多種多業に課題があったんですけど、それは各チームで一個一個倒していったという話ですね。
話していっているうちに参加者が増えてきましたね。
けんじさんとれのわさんと牛乳きらいさんですね。おはようございます。ご参加いただきありがとうございます。
いつもこんな感じでダラダラとやってきてます。
後ほどこの記事もツイートしますので、興味ある人は実際の本記事も見ていただければと思います。
では戻りまして、あとはですね。
週次で本部長と副本部長にこの辺りが課題なんですけど知っていますか?とか解決してねみたいなレビューを毎週やっていたと。
そうすることでワンオンワンで話してもどうせこの組織は何も変わらないんでしょう?というところからちょっとずつ良くなっているねとかちょっと話していいかもみたいなところまで信頼残高も積めるし雰囲気も良くなってきましたと。
いい話ですね。こういうのって本当草の根の活動なんで地道にやっていくしかないですよね。
今が変わることによりちょっと当てになるかもという信頼積めたというのがやっぱり大きくて、そのほんのちょっとの積め方なんでしょうねというところでした。
実際その代謝を様々な組織からの明確化により実際に変わる経験というのができてきたというのが大きいというところですね。
とはいえ信頼残高で言うと最後はプレイヤーとして仕事ができるかっていうのが大きくて、組織のことをやっている人ってだんだん机上の空論ばっかり言う感じになってしまうので、別にあの人は戦力じゃないしと話を聞いてもらえなくなってしまうんですよねと。
06:12
これもよくある話ですね。
当時の僕は子供は1歳ちょっとで育児もしなければいけないし仕事もしなければいけない。さらにマネジメントもするもんですかみたいな。
ハードワークな感じではありましたがやらなきゃしょうがないということでアンドロイドのコードを書いたりひたすらいろいろなことをやってなんとかしていましたと。
最初にプレイヤーとして入っているのでプレイヤーとして結果が出せなかったり意味がないとなると入社したての頃にしか間違えられないと思ったので最初の頃にガンガン間違えて地道にやっていましたと。
当たり前ながら信頼残高を積むにはやはり時間はかかるしプレイヤーとして最後が仕事を地道にやるというところはやっぱり変わらないということですね。
ハードワークとの控えにならざるを得ないが仕事をしていない限り残高がたまらないからどんどんアタックしていたということですね。
また組織のことばっかりやっている人ってやはり評価が厳しいと。現場が退治しているのであれば事業を進める上でこの人役に立つのかというのがそもそも第一ですねと。
現場の仕事ができないにどこかの本や記事のノウハウを入れてこようとしてくれる人ってのはやはり現場を混乱させるだけで邪魔でしかないと思われても仕方がない。
で間違ってもいいのでとにかくアウトプットを出し続けて、新人のうちに間違っていかないと間違える機会も失ってしまうしアウトプットがあることで具体的に指摘も受けられるという話ですね。
で一応おまけとしてツラミについてもう少し書いたので興味ある人は見てくださいということでざっくり読んでいきましょうか。
泥臭く言うと正直あの人大丈夫かいみたいな意見とか悲しみ駆動開発だみたいなところの話がザーッとされていると。
で次は答えの話ですね。地道な行動と時間がやっぱり回避してくれるところも少しは期待したということですね。
ここは結構大事な話で僕もベガベンチャーに行ったのでわかるんですけど大きい会社とかから来てこういうやり方が正義なのでやってくださいと言われても
そもそもお前のこと知らんし信頼しないし正直うるせえとなってしまうんですよね。
でお前の言うことはわかるけど気に食わないので聞きませんとなってしまうのでそこはやっぱり時間をかけてでもきちんとやらないと無理だというふうに思っています。
あとその言い分には共感はできないんだけどそう思うことがあるのよねと理解するのはすごく大事なんですよねと。
違いを認めずに一色にしようとするとすごくハレーションしてしまうというふうに思っています。
いやでもいいですね。正論じゃ人は動かないというところがやっぱり事実ですよね。
でまあ合ってるかもしれないけど信頼しないので聞きませんっていうのはまあ人なので仕方ないですよね。
かつ他の会社でやってきた実績とか成功事例があってもそれが今の会社とか今の現場に当てはめた時にそれが成功するとは限らないんですよね。
なのでまず一回まず現場のことを理解したり信頼を作るというのは本当に大事だなというところですね。
やっぱり人は人として言うことをするっていうところが大前提だなというふうに聞こえました。
で信頼残高を積む話をしていますがそれを削ってでもやらなきゃいけないこともあります。
本来は採用でやるべきなんですけど今のユニファー株式会社でできないことがいっぱいあったんですね。
であるべき開発プロセスがいいですね。
デザインシステムを極めたいと言われてもプロダクトを8個出さなきゃいけない状況なのでそれはごめん今は無理だわっていうような採用した人が入るときはその話をして謝りますと。
で中にいるメンバーへは悪いけど今はできないけどどう思うっていうかその後に転職するパターンもあるかもしれないけどっていう話をやっぱり誠実にやっていきました。
09:07
でこれで離れていったメンバーもちろんいますが最終的にお互いがそれでいいとなったら問題ないねっていう話をしていました。
まあそうだよね。
まあ要はいい顔だけができない話。
で今それはそうですね。
今じゃできないことってか。
ミニチュー用的なPDAを目指したってことがあるけどやっぱりそれはできないと。
でできない話を下じゃなくて上の人にもこの方はやってきたってことでしょうね。
現場がそれを受け入れられる体勢とか体力がなかったりそういう同情がなかったりするので下だけじゃなくて上にも言ってるようには聞こえますね。
これはすごく泥仕事ですけどいい話だなと思いました。
その事業位置早く伸ばすことが大事であって職種の制御を頑張っている場合でもない。
事業が伸び売上が立ち始めて様々な環境に投資ができるようになるのでまずそこからです。
だから今はそれがいいと思う人に出会いそれが嫌だと思う人には採用辞退されることがお互いにとっても良いことですと。
逆にですね採用辞退されるっていうのは本来はダメなんですけどやっぱりカルチャーフィットとかも目指すところが違う人を入れてもやっぱりお互いが不幸なんでね。
なので結果辞退されるっていうのはやっぱりいいことですよねって話でした。
人の出入りがある前提で地位の設計をどうするかっていうのが次の話です。
ユニファ株式会社は優しいので人が辞めてしまうことなどを大事として捉えてしまうんですけどベンチャーはだいたい2,3年で人が入れ替わります。
まぁそんなもんだよね。でもそうなった時に新人受入は個人がOJTをめっちゃ頑張るとか退職者の引き継ぎは中に人が忙しいかもしれないけど頑張ってみたいな。
だとみんな死んじゃうんですよねと。持続可能ではないしSDGs的な組織ではないとなってしまうのでそこも仕組み化して誰かがやってもだいたいはできる状態にしてみようというふうに思いました。
まぁそうなんだよね。新人受入や退職から引き継ぎコストを下げるというのが次の話ではそうですね。
前半の記事、昨日の記事では採用の話に結構フォーカスを置いたんですけど今回は育成と戦力感のところの話ですね。
もう一回言うと育成というのは育成人数イコール採用人数かける育成期間割る育成必要期間ですね。
戦力感というのは戦力イコール育成人数かける有効アサイン率だと。この2つですね。
人によらず誰でも同様の品質を出せる受入れシステムと意識しなくても引き継ぎやすい形の業務を成立させるにはというのが次の話です。
そこでみんなもやっていると思いますが誰でも再現できるオンボーディングを社内メンバーと一緒に作ることにしました。
これは2021年3月ぐらいに作りました。どうやって作ったかというとPDMのあり方から作ってしまうと偉いことになってしまうので取り急ぎ自分を含めた1年ぐらい前から入った人に入社して困ったことを全部ヒアリングしてみました。
ほうほうほう。あと既存メンバーにもなんで新人はこんなこともわからないんですかと思ってしまうようなことも多分いっぱいあると思うんですよね。
その部分をヒアリングしてきました。結果1ヶ月でこういうことをやると良いみたいなものを作って展開をしました。
リモート化なので誰が何の担当なのかわからなかったり普通だと思われていることが何なのかわからなかったりして期待値がそもそも合っていないんですよね。
だからアサインされていきなりすごい仕事を求められて無理ですとかあの人使えませんみたいなことになってしまいます。
12:03
そうするとみんな不幸になってしまうのでそこの交通整理みたいなことをやっていました。
まさにそうですね情報の交通整理がめちゃくちゃ大事なんですよね。特にオンボーディングのする方々にとってはですけど。
あと僕らが当たり前になっていることっていうのが結構僕らも認識できないことって結構多いんですよ。
会社の文化とかやり方とか歴史がありますのでそこに使った人っていうのはもう当たり前すぎて何がわからないのかがやっぱりわからないとなってしまうんですよね。
これは本当そうなのでちゃんとヒアリングをしてくれる人がいるっていうのは大事だなって思いましたね。
で続いて新しくメンバーに仲間になってくれるメンバーが成果を出しやすくするためにってところでオンボーディングプログラムの作り方ですけど
今さっき言ったことをもうちょっと整理したって感じですね。
まあ2020年3月以前あ以降に入社したメンバーに実際に何困ったかとか何先に教えてほしかったかっていうのをヒアリングして
ちょっと愚痴も聞いたんでしょうねここで一緒に。それもそれでいい話だと思います。
で既存メンバーにこういったことをまとめてインプットしてほしいっていうことを逆にヒアリングしたと。
ここが多分大変だったと思います。1個目の方はまあ実際に困ったこと、やっぱり人間って自分が受けたペインを話すとすごく簡単なんですけど
既存メンバーに今の自分たちの状況とかをもう一回再認識してもらうっていうのがこれが大変なんですよね。
日頃から自分たちのことをある意味疑った目線で何がどうなっているところを常に見ている人って実はほぼほぼいないと思うので
それをもう一回やってくれって言わなきゃいけないんでこれは結構きついんですよね。
状況を取りまとめた上で1ヶ月間のスケジュールを作って展開をしてあとは実施をして改善したと。
人と仕事の結びつき、担当者とか今よくべき普通が曖昧であり新入社員と既存メンバーで期待値が合わないこととか
他部署の役割がわからずその業務の理解が進まないことなど、そりゃ困るという顔ぶれがもう結構具体的に言語化されたんですね。
一応目次も示しておきますので、初日に説明することってバーっとこう初日のオンボーディングプログラムに説明があるのでこれも参考に見てみてくださいと。
詳しくは言わないですけど前提情報とかよく使うものとかスマートHRとか困った時にどうすればいいかとかこれからのオンボーディングについて
プロダクトの確認とか環境について最後お願い事を出していく。こんなことを初日に説明しているそうですね。
あとノウハウとして配属部署全員とワンワンは絶対にやった方がいいのでやってみてください。これは強制力があった方がいいです。
やらされているのでと言って上司が悪者になれば済む話なのでやってみるといいと思います。
やらされでもいいからワンワンは絶対にやってくださいと。これ結構大事かもしれないですね。
エイヤですけど取り組みをするっていうのはすごく大事かも。結局解決策とか本当に会社の課題っていうのを個人が持っているのは事実なのでそれを吸い上げるためにもワンワンってすごく大事ですよね。
一対一だとみんな発言する心理的なハードルが下がるのでそれもいい話じゃないかなと思いますね。
複数人だとみんな喋らないですかね。日本人は特にそうですけど。
明日からマネできるオススメ動画を打つところですけど、オンボーディングの目安期間は大体2ヶ月くらいがいいですと。
15:01
配属部署全員とのワンワンを行いましょう。使用理解は使用書よりも顧客向けデモ動画の方が圧倒的にいいですよと。
上位マネジメントとの期待値面談っていうのは配属後1週間経ってからしましょうと。
なんでもいいので自分の理解をアウトプットとして公開してもらいましょうと。
なんでも相談できるスラックチャンネルも準備しましょうと。
あと2ヶ月経過後にアンケートを取り気づきや改善点を一緒にもらってくださいとですね。
次は引き継ぎに関してのお話です。
次は引き継ぎに関してのお話です。
2020年後半、僕が入って少し経った時のチーム体制っていうのは
PDMが5,6人しかいないのにプロダクターがたくさんあるので1個作ったら解散してまた他のプロダクトに行くっていうことをしていましたと。
引き継ぎに関してのお話で
PDMが5,6人しかいないのにプロダクトがたくさんあったので1個作って解散して他のプロダクトに行くっていう
チームの醸成をする前に次の方にメンバーがどんどん移っていくみたいなことをやったんですね。
そうすると人が辞めちゃった時に知見がまるまるなくなってしまいますと。
1個のサービスに1人しかPDMがいないとか、PDMというか当時はディレクターでしたので
いなくなってしまうので大変な状態になっていてこんなのは続かないということになりましたと。
そうなんですね。結局チームの調整が会社としてはすごく大事な話になってくるので
プロダクト主導でのチームって
そのプロダクトが続いてそのチームがずっと続くんであればいいんですけど
作って解散作って解散って結局ノウハウがたまらないのでまたゼロペースでやらなきゃいけないんで
結果コスト高いんです。
あとその退職者から引き継ぎコストを下げるっていうそのチーム体制の話ですけど
ワンサービスワンテボラリーチームっていうところですね。
サービスを開発するときに人が集められるチームでサービス開発が悪いと解散すると。
PDM間で一緒に仕事をすることなくなり各自一人で頑張るしかないっていうので
そのキャッチアップハードルが大事だからここをちゃんと改善したいっていうのをしっかり言語化したことですね。
そうなった時に一人の体制だと一人の仕事もわからないし人を頼れず潰れてしまう課題もあります。
また入った時に今はこの案件をやるけど次に何をやるかわかんないという感じになっていて
毎回一期一会で超辛い状態でしたと。
誰かが退職しないとその人の仕事に触れる機会がない状況だったので
そもそも他の人とチームとして一緒に仕事をする機会を作りましょうとやってみましたと。
誰にも頼れず潰れてしまうことを物理的に避ける狙いもあってそういうことをやりましたとかですね。
まあ人依存になってしまう確率も上がってしまいまして
その人が倒れたら本当どうしようもなくなるっていうのは本当会社としては課題なので
やっぱり人の冗長化も考えておかなきゃいけないですよね。
チームがない頃っていうのは部署の仕事を学ぶとか
すなわち全てのプロダクト全てを一から学ぶ必要があったので
まずはチームの扱う範囲のプロダクトから覚えれば良いということになり
オンボーディングの階段も作りやすくなりましたと。
はいで
結果ですね変更したチーム体制でカスタマージャーニーが似たサービス
例えばこれは縁の先生が使うサービスですねとか
これはだいたい保護者ですよねということをまとめて
pdm と組ませてチームを作っていきましたと
こうなってくると一人で仕事をしているときは
ドキュメントをちゃんとやろうという気持ちになり
あまりならないと思いますが他のメンバーもいるので
ドキュメントを作る気持ちが出てきたり
人が入ってきてもチームの面
みんなが教えたりできるようになりましたと
今まで一人の pdm が全部やらなければいけなかったので
人によってブレてしまう部分もだいぶマシになった体制が作れました。
18:02
はいさっきのはワンサービスワンテポラリーチームだったんですけど
2から3ですねサービス1固定チームっていう風に体制を変えましたとこですね
でもちろんサービスで分けるのもいいんですけど
みんな人なので人のウィルやキャンを意識してやらないといけません
こういうことがやりたいとかこういう方向に行きたいということは
半年で全然変わるのでエスパーせずにちゃんと聞くことが大事ですと
あとはやりたいことが特にない人でもやりたくないことはあったりするんですよと
これは絶対やりたくないんですっていうこともちゃんと聞いておいて
変なアサインをしないことは大事ですと
結果的にみんなが能力を発揮できる状態ができます
つまり新人なのにリスクの高い新規事業を一人でやらせるのはやめましょう
っていうちゃんとケアも把握しましょうという話です
いいですね絶対やりたくないってことを聞くことはすごく大事ですね
やりたいことにピタッとハマるようなアサインができるとは限らないんですけど
やりたくないことを避けることは多分可能だと思うので
そこは本当大事だと思いましたね
これやるだけで多分会社への信頼度って結構高まると思いますよね
要はメンバーのウィルとキャンを把握しましょうってことです
単純に仕事だからっていうのでやらせるっていうのはやっぱり
ペインが溜まるってことですね
こういうアサインをするとやめますっていうことが書いてあるので
ぜひ参考にしてください
本当にやめてしまうと思うので絶対に避けてほしいと思います
メンバーのウィルキャンとアンケートのマッチドアイを見ますというところで
採用するときに伝えたアンケートもあったことのないアンケートにアサインしたりとか
サービス運用の経験を積みたいメンバーを顧客設定のない基盤にアサインするとか
システム知見の深いメンバーをあまりシステム知識のいらないプロジェクトにアサインするとか
こんな感じでとにかくメンバーのウィルキャンとアンケートのマッチドアイというのをしっかり話を聞いて
それを避けるようにしていったところですね
じゃあ最後です
組織改善とプレイヤーを一緒にやるのはやっぱり無理ですよってお話
僕は全部うまくいったみたいに喋ってますけど
前者的に謝るようなことも何度もやってます
担当していた保護者アプリのリリースが9月1日だったんですけど2週間遅れました
他のことを全部カバーしてるので自分が最後にそうなってしまって
保護者アプリのメンバーに大変申し訳ない部分もあったんですけども
そういうことを実際に起こしていたり
あと最初は業務プロセスを標準化しようと言っていましたが
それぞれのやり方があるので
パックを作らないといけないのに何やってるんですかとか
今はそれじゃないですよねっていうことがあったり
めちゃくちゃ失敗もたくさんしてますと
最初にHCDサイクルですね
Human Centered Design
人間中心設計の英語ですけどの話を出しましたが
あれもたくさん回していて
これはダメこれは良いという評価をすることによって
組織とユーザー理解をどんどん進めているかなという実感はやっぱりあります
ただまだ1年なのでこれからまだまだやることはあるとも思っています
例えば実際にリリースした後のグロースフェーズに必要な
PDMの組織はどうすればいいのか
そこを頑張らなきゃいけないというのはこれからもやっぱりありますと
要はいろんなことをやってきたけど
結果にリリース2週間遅れたし
トータルだと実はやっぱり負けているっていうのが
この山口さんの対価だそうです
今も組織とユーザーの理解を進めている途中だというところですね
タイムラインで言うと2020年の9月に入って
2021年の9月にアプリをリリースするところまで
1年近くかかっているんですよねと
最初の頃は空回りばっかりしているし
何やっているんですかということもたくさん言われました
なので信頼残高を積みながら組織を変えていくに
21:02
1年ぐらいかかるもんだなというふうに思っておくと
大体新しい会社に入った時にも変に焦らなくて済むと思いますと
組織改善としてHCDサイクルを回すというのは
こんな感じですというものもお分けで貼っておいたので見てみてくださいと
ユーザー観察ユーザーのASISと2Bで2Bを叶える試作実行
そして試作効果をユーザー評価をするということですね
このサイクルというところもおまけで貼ってあるので
皆さんの方で見てみてください
仕組みを作ることに取り組むと結構大きな成果を出せるということですね
明日から真似できるアクションをいろいろ書きましたが
持続可能な方法でものを一気に作っていくには
1人だけで頑張ってもしょうがない
みんなが特定の分野の天才ではなく
仕組みに乗っかって成果を出せることがすごく大事だと思っています
そういった仕組みを作ることも嫌がらずにやってみると
組織作り王子さんみたいに言われたりもしますけど
結構大きな成果を出せると思うのでお勧めです
皆さんの試行錯誤もぜひ教えてくださいという形で
今回私の発表を終わりたいと思います
というわけで最後まとめですね
明日からすぐ真似できるアクションのまとめ
1つは事業に必要な人の定義や採用基準の目線を合わせる
2つ目に時間がかかるので足元のことから信頼残高を積み上げる
3つ目は信頼残高を使って嫌われてもいいからと
批判と対案をセットでマネジメントにぶつけてみる
4つ目にメンバーのビルトキャンを折り返しアサインを再整理する
5つ目オンボーディングを整理し現場に対する新人育成コストを下げる
ラストですね
6つ目特定の人に依存しなくても教育と成果を出しやすいチーム構成に組み替える
はいというところで本記事は終了になりました
プロダクトマネジャーカンファレスですね
こんな話がいっぱい聞けるんであればすごく参加したくなりましたし
こういう話って技術ではない技術の話ですよね
前者の技術はハードスキルの技術で後者はソフトスキルだけだとこです
こういう実例と苦労話っていうのはやっぱ貴重ですので
ぜひぜひやっぱ僕らも聞いていきたいなって改めて感じましたし
これ発表とは別の発表後の単なるテキストでの書き起こしではあるんですけど
それでもすごく伝わるものがたくさんあったので
こういうのはやっぱ大事だなってつくづく感じましたし
組織と面と向かってぶつかっている人の話って学びだらけなんですよね
知見の方がと思いますので
技術を学ぶのもすごく大事ですけどハードスキル的なね
こういうところもしっかりやって
両輪ですよね
どっちかが大事でどっちかが今後回しっていうのは
別にそういう人を作ってもいいんですけど
どっちも考えていかなきゃやっぱり組織としてはうまくいかないと思いますので
改めて組織に向き合うっていうところの大切さを教えていただいたなっていうふうな感じがしました
とても良い記事だったと思いますし
重複になりますけど後ほどこの記事ツイートしますので
皆さんの方でまた読んでいただければと思います
ではでは長くなりましたけど今日の朝方ここで終了したいと思います
本日の参加者は改めましてリズさんとケンジさんと鹿内さん
そしてレノアさんと五蔵五夫さんと最後多分オンラインで見えてないけどスーさんかな
参加されてますけど
はいご参加いただきありがとうございました
明日もですねなんかダラダラ読んでいこうと思いますけど
ちょっとここのとこ二連チャンでそのソフトスキル的なとこだったので
明日ハードスキルのなんか技術記事読んでいこうかなと思っております
はいじゃあ水曜日中日ですね
今日も一日頑張っていけたらなと思います
それでは終了しますお疲れ様でした
