00:01
はい、おはようございます。たなけんです。 2024年3月19日火曜日の夜です。今日は
あるプロジェクトにおいて
メンバー間の引き継ぎというテーマでちょっと話してみたいと思ってます。
で、僕これまでのお仕事の経験の中で
あるプロジェクト、あるサービスにすごく知見のあるXさんという方がいたとして、その方が社内の別のプロジェクトに
移動しますと。 そういうシーンってね、これまで僕何度もあったんですよね。
で、そういう時にそのXさんがあるプロジェクトAから別のプロジェクトBに行く時にどういうふうに
引き継いでいくかというか、残るメンバーに任せていくかみたいなところって結構
大事だよなと思っていて
そのXさん、あるプロジェクトAにすごく知見があって、これまで頑張ってチームを引っ張ってきてくれたような
Xさんがいたとして、その人はつまりいろんなチームメンバーから頼りにされているわけですよね。
で、何か困ったことがあったらXさんに相談したいし、Xさんに意思決定を委ねたい、任せたいと思うし
Xさん自身もプロジェクトAについて知見もあるし思い入れもあるから、何か困ってたら
助けたいって思うのは自然なことですよね。 だけれども
そのXさんは新しいプロジェクトBとか、別の、新しくなくてもね、別のプロジェクトBをまた引っ張るために
移動することになるという、そういうシチュエーションだったとしましょう。
それはXさんにとってもそのプロジェクトBっていうものはすごくやりたいと思っているし
会社だったりチームだったり組織としても、このプロジェクトBをもっと盛り上げるためにXさんはすごく大事だと
Xさんに是非プロジェクトBに入ってほしいと思っていると。
プロジェクトAの方に残るメンバーも、これはXさんはプロジェクトBに行った方がいいとみんな思っていると
だからXさんがAからBに移動すること自体はすごくみんな
03:04
合意が取れているっていうとき、で、それでも何かそういう状態の時、じゃあ円満じゃんっていうふうに見えるんですけど
そういう状態の時でもやっぱり課題はあるなと思ってて
XさんはプロジェクトAからBに移るんだけど、どうしても
プロジェクトAの意思決定とか、今までずっと自分自身がしてきた
活動というかプロジェクトAのことは任せろってやってたXさんが
急にプロジェクトBに行くとどうしても元々いたプロジェクトAのことが気になったりはしちゃいますよね
ねえ
でもそれでもプロジェクトB、新しいプロジェクトBに集中するためには
XさんはプロジェクトAから離れていかなきゃいけないと
で、プロジェクトAに残っているメンバーもXさんに頼らないで
残っているメンバーで
責任を持って意思決定をしていく必要がある
っていうことですよね
で、それを
お互いXさんは
残っているプロジェクトAのメンバーに任せるっていうことが大事だし
任されたメンバーが、よし任せろもうXさんには頼らずにやりますって言えるってことがすごい大事
だよなーって思っていて
でもどうしても多分Xさんは
プロジェクトAのことは気になっちゃうと思うんですよね 特に最初の方
で
プロジェクトAを気にせずに働けるように
まあ例えばミーティングとかには参加しないとか
そのプロジェクトAの方のミーティングからはちゃんと足を洗うというか
完全に離れるとか
物理的にももしかしたらプロジェクトAの話が聞こえないような
区切り方をした方がいいのかもしれないですよね
で
まあそういうふうに物理的に区切っていたとしても
例えばプロジェクトAで
新たにこういうことをすることが決まりましたっていうのを
チーム横断的に共有したりするシーンはあると思うんですよね
そういう時にXさんはその意思決定なんでそういうふうに決まったんだろう
自分だったらそうやらないのになぁとか
06:01
感じることが 感じるシーンってあると思うんですよね
で
えっと
その
プロジェクトAの新しい意思決定 そのXさんを除いて
Xさん以外の人たちで決めた意思決定に対して
どれくらい
そのXさんは手放しできるか その意思決定を尊重できるかとか
尊重はしてるんだけどな どうしてもプロジェクトAのことを思って
もっとこうした方がいいんじゃないかとか
なんでそういうふうに決まったの?っていう背景が気になっちゃうとか
うん
背景がまだ
全く残ってなかったりとかするとね
余計気になると思うし
議事録とかにも何も書いてないで決定事項だけ伝えられるとかだと余計気になると思うし
で
決定事項のその仮定がどっか議事録とかに書いてあったとしても
うん
いやーこれ本当は違うんじゃない?とか
自分が持ってるXさんが持ってるこの知識
この前提があるとその結論は覆るんだよなとかがあるかもしれないんですよね
とかっていうのがあって
なんかそれってすごく
こう
心を鬼にしてXさんの視点で言うと心を鬼にして
プロジェクトAのことを見ないようにする
鬼にしてというかまあ信頼するってことになるのかな
プロジェクトAに残っているメンバーを
信じて
でなんか失敗を許容する
みたいなところがとても大事なんだよなぁと思うんですよね
うん
なので
なんかこういう話を
する
しながらまぁなんだろうな
根本的に大事だなって思うのは
失敗しても
大丈夫だよっていう
そういうチームの合意というか
失敗すること自体じゃなくて失敗をいかに生かす次に生かすかということを
捉えて
次に進めるっていうような
そういうチームの考え方っていうのが非常に重要になってくるんだろうなぁと思うんですよね
で失敗を許容できないチーム組織だと
こういう柔軟な移動とか
攻めた選択肢
09:00
攻めた選択肢?
うーんとチームの主軸となっていたXさんを別のプロジェクトに注力させる
してもらうとかっていう意思決定がしにくくどんどんなっていきますよね
なので
うーんとXさんの立場で言うと
失敗してもいいぞと
もう任せた
なんかあっても
そこで学んで次に生かしてくれるから
だから大丈夫で任せたっていうふうにできるっていうのが大事だし
プロジェクトAに残るメンバーの視点で言うと
いや任してくださいよ
ちょっとやってみますわと
もしなんかうまくいかないことがあったら
うまくいかないってなっちゃった後に
振り返りで相談させてくださいよ
Xさんぐらいの
なんかダメだったなってなったら
意思決定には関わらないでもらうけど
失敗した失敗なり成功したり
ある程度の区切りがついて
結果がわかった段階で
この結果になったんですよねっていうのを
Xさんにそのワンワンとかで相談する
共有するとかっていうのは
ありなんじゃないかなと
なので失敗から失敗から学べる
失敗に投資できるっていうチームが
チームとそういうマインドセット
というのがおそらくすごく大事なんだろうなと
そんなことをね思ったんですよ
僕自身も一番最初に入社した
新卒で入った会社で
直続の上司が
すごい当時入社した時
この人と一緒に働きたいな憧れだなみたいな人が一人いて
何でもできるタイプの方
開発もできるしチームもまとめられるし
いろんな人と仲良くやりながら
プロジェクト前に進めるみたいな感じの人で
いやこの人からいろいろ学びたいと思って
新卒入社の時もいろいろ
入社前にもご飯とか行かせてもらって
この人と一緒に働きたいなと思った人だったんですよね
でもう一人正社員の方いて
12:02
その方は技術特化っていう感じで
サービスにも長くて伝わっていて
知識がすごいあって
ただなんか人とコミュニケーションして
うまく何かまとめるとか
なんかそういうのはあんまり得意ではない方だったんですね
で3人目の正社員として僕が入って
他の方はアルバイトの方だったり
業務委託の方っていうのもあって
いろいろとチームをまとめるというよりかは
エンジンとなってプロジェクトをどんどん開発して
行動を変えていってくださる方々っていう感じだったんですよね
で僕が入社して半年経たないぐらいとかで
その僕が憧れていた何でもできるまんの先輩が
新しくサービス作るからって言っていなくなるというか
お隣のサービスみたいな感じで
つまりさっきの例で言うとXさんの立場の人ですよね
で自分は新しいサービス作ることになったから
あとよろしくみたいな感じでポーンと任されて
でもう一人の正社員の方は先ほども言ったように
プロフェッショナルな感じのチームをまとめるというよりかは
技術極めるという感じのタイプなんで
チーム誰がまとめるのって業務委託の方も
もうその当時たくさん結構いて
もう6、7人いたのかなその当時でも
で正社員が1人ぐらいの10人ぐらいの規模で
正社員は2人ぐらいの確かそんな感じの規模だったんですけど
その方々をどういうふうにまとめてどういうふうに
タスクを実装タスクをお願いしていくのかみたいなのを
誰が仕切るのってなったら
もう僕しかいないよねみたいな感じになって
僕はそんなことは全然できない状況だったけど
スキルセットとしては全然無理だわって思ったんですけど
もうXさんにあたるその上司の方が
あとは任せたなんか困ったら相談してみたいな
まあ無茶ぶりなんですけど
っていうのでなんか任されたから
もうやるしかないみたいな感じだったんですよね
っていうのを思い返すと
その新卒で入った会社が失敗を許容する文化があったかっていうと
それは全然わかんないんですけど
まあもうまるっと投げちゃう
投げちゃうXさんは投げちゃうし
残った僕は受け止めるしっていうので
それは結果的にやっていたなぁと
でうまくいかないこともあったけれども
15:01
本当にやばいもの
なんかサーバーが何日間も止まりますみたいな
何日か2日間とかなんかゲッションになるとやたら重いみたいな
そういう類のサービスだったんですけど
まあそれはもちろんプロダクトの設計だったり
アプリケーションコードの問題とかは多分にあったんですが
まあまあ事実としてゲッション毎朝数時間止まる
なんか3ヶ日っていうの
1日2日3日はまともに動きませんみたいな
のが毎月起きてるような時期もありまして
そういうなんかもうサービス影響が大きすぎるみたいな時は
その上司の方も元別のチームに移動しちゃった方も
助けに来てくれてそういうのはやってましたけど
それ以外の平常運転なところはもう
まるっきり口は出さずにもう後は任せたみたいな
スタンスだったなあと思うと
本当にヤバいやつは本当にヤバいんで
それはなんかもうチームがどう行こうというよりかは
もう関係なくみんな出張ってくるっていう
やれる人がやれることを全部やるみたいな
それぞれの人が得意なことを全部やるみたいな感じになると思うんですけど
そうそうっていうのがあったりしたなぁと思って
うん そうなんですよね
なので 何だろう
任せる 任せる 任せられる 任される
みたいなのと失敗もまあいいでしょうっていうふうにすると
なんか失敗したらその後相談できるぐらいの
そういう立てつけがいいんだろうなあというのが最近思っていることですね
うん はい
なんかそんな話をしてみました
うん はい
まあいろいろとね やりたいことが今の職場でも山ほどある中で
チームのね構成をこうドラスティックに変えていくっていうことはね
今後もたくさんある話なんで
そういう時にどう考えたらいいのかなというのをちょっと考えてみたくなったんで
お話ししてみましたというところですね
はい そんなところで今回はここまでとします
はい ではまた明日
バイバイ
