キャッチアップの重要性
こんにちは、ぐちポジfmです。ぐちポジfm 第9回です。このポッドキャストは、
ぐちぐちをポジティブに日常の話、エンジニア やプロダクト開発全般の話をする
ポッドキャストです。この放送を聞いて のご意見ご感想等は、ハッシュタグ
ぐちポジfmでポストしていただける と嬉しいです。はい、鈴木です。
秋です。
おにぎりです。よろしくお願いします。
よろしくお願いします。
シンプル。
はい、じゃあ今日のテーマは、新しい チームとかに配属、配属っていうのか、
参加するときにどうキャッチアップ していくかについて話しましょう
の回です。これはどういうきっかけ でこの話するのみたいなところは
話さなくてもいい感じ。スーンと 行く、スーンと。
スーンと行ってもいいんですけど、 これ長年結構気になってるテーマで、
何ですかね、鈴木さんとこれで4年 ぐらい仲良くさせてもらってると思
うんですけど、いろんなプロジェクト 新しく入ったときに、スムーズに
立ち上がってるふうなことをいつも 言われるじゃないですか。
俺がね、俺がね、はいはい。
そのあたりなんか、私も言って新しい 現場に入ったときに、そんなにスムーズ
じゃなかったことはあんまりないん ですけど、実際そのあたりは言語化
言語化したいなと思ってお話しして みたいなと思うのと、あとこの辺は
おにぎりさんもすごい得意そうな 印象があるので、ぜひ話を聞いて
みたいなと思っています。
プロジェクト管理とスケジュール
確かに聞きたい。
おにぎりさんはどうしてチャットするんですか。
いきなり触れちゃう。まず鈴木さんの 話したいな、私は。
そうなの。
チラッチラ。
そうね、だからさっきちょっとチラッと 話してたけど、多分いろんな
なんか話で参加すると思うんだよね。
なんか新たにここの新しく立ち上げる からやってほしいってあったり
だとか、単純に転職しましたみたいな感じで
入っていくこともあるし、部署の 配属が変わりましたみたいな話も
あれば、SIRとかSESみたいなところ であれば、途中参加でプロジェクト
に入っていくみたいなパターンも あると思うので、機体役割が何なのか
によってキャッチアップの方向性 とかどういう立場で入るのかっていう
ので、ちょっと変わってくるかな っていう気はするなという話を
聞いていようかなと思ってました って感じですね。
なるほどですね。なんかその引消し とかではないのと、メンバーじゃなくて
PMの引き継ぎとかで入るパターン ってあるじゃないですか。既存プロジェクト
が途中まで走ってるんだけど、もともと 担当してた人が他のプロジェクト
のほうに欲しいから代わりに入って ほしいとか、あとは今だとフューチャーチーム
みたいな考え方があるとして、スピード 速めたいからそこのリーダーとして
新しくもう1チーム分入ってほしい とかの若干コアメンバーであるが、
それなりに最初から責任を期待 されてる場合って何からやって
けばいいんですかね。
そうだな。僕だったらまずは、でも さっき引消しでとかそんな話も
あったけど、やっぱりスケジュール 見るかもしれない、俺の場合は。
まあそうか。
スケジュール見るかな。これ結構 アプローチの仕方みんな違うな
と思うんだけど、XQ Twitterとかを見てる とまずはソース見ますみたいな
人がやっぱり僕のフォローしている 人とかだと多かったりするんだけど、
でも結局PMのだから、直近PMしか やってないっていうのもあって、
だからやっぱりちょっとプロジェクト 管理目線のところを把握しにいく
ことが多いかもしれないな、スケジュール。 あとはそのプロジェクトなのか
プロダクトなのか、自分が知ってる のか知らないのかみたいな話は
あるのでちょっとここわかんない けど、スケジュールだったりとか
体制だったりだとか、そこら辺の そのいわゆるプロジェクトマネージメント
目線の何々管理みたいなところが どうなってるかっていうのをちょっと
見に行くかもしれない。
なんかでも今の会社に入ったのが 3年、もうちょうど3年経つんですけど、
3年前で、私が入ったときもそれは プロジェクトがすでに若干動いてて、
最初にプロジェクト検証を作った 記憶ありますね。
なるほどね。
ねぇじゃんって思って、今の鈴木 さんの話ってスケジュールって
言いましたけど、要は概要理解だから プロジェクト検証から見るよって
ことですよね。
そうだね。プロジェクト検証、プロジェクト計画。
もしかしたらインセプションデッキ みたいなのがあるかもしれないけど、
そういうのから確認していくかな。
で、なければ作んなきゃいけないね っていうアプローチをするかもしれない。
ソースコードと環境構築
そうですよね。確かに。
なんかそれ、初手なんか作らなきゃ いけないねになりそうな気がするんですけど、
意外とあれなんですかね、
昨今のプロジェクトとかはできてる もんなんですかね。
できてないもんじゃないですか。
そういうもんなんですね。
わかんないけど、その場合によるような、
まあ、境外化してるよねみたいな話 とかはあるかもしれないよね。
ちょっと長くなってきてさ、最初の本 作ったんだけど、今はちょっと
なあなあになってますみたいな。
確かに。
あったりするかもしれないので。
いや、でも、入ります、プロジェクト検証 ないですってなったら、
その後自分がPMムーブする未来しか 見えないじゃないですか。
PMムーブ。まあね、そうだね。
整備して整備して。
ソースコードにいつ至れるのかな っていうのは気になりますね。
でも、あきさんはソースコードに 至りたいと思ってるってこと?
至りたいって思っていて、
昔の、昔多分開発メンバーだった頃って、
どうやってキャッチアップしたか 覚えてないですけど、
ドキュメントに概要がなくて、
全職で入社したプロダクトは 概要が載ってなかったから、
ソースコードから確かに見てたな っていう記憶はありますね。
でも、それで言うと、その時代の話で言うと、
多分まず動かせるようにするっていうのを 先にするかもしれない。
してたような気がする。
でも確かに。
環境構築最初にやって、
画面がつく状態になってから、
触ってみてデバッグして、
ある程度ユースケース確認して みたいなことは確かにやってましたね。
それを結構最初にするな。
まずそのプロダクトがどういうものなのか みたいなのを見たりしてたかな。
仮に新しくやるみたいなところの時って、
企画する人たちとか、
そういう人たちの頭の中には類似の サービスとかがあったりするから、
それなんですか?みたいなところも 僕聞いてたりするな。
確かに。今だとでもあれですよね。
自分たちも手数が広がってるというのもあるので、
実際に動くプロダクトのソースが もうあるんだったら環境構築すればいいし、
まだ作られてない機能があるんだったら プロトタイピングツールというか、
HelmaとかXDとかでMockがすぐに作れる気がするので、
ある程度イメージは湧きやすいのかもしれないですね。
確かに。あと俺直近そういえば、
こういうのを作るんだみたいなやつで、
ささっとリアクトで自分でちょっと作ってみたね、そういえば。
さすがですね。なんかさすがですねっていうのもありますし、
鈴木さんほどのスキルがなくても、今ってV0あるじゃないですか。
はいはいはい。
そのNext.jsの環境でバーセルで立ち上げられるやつがあるので、
同じようなことはフルスクラッチじゃなくてもできそうですね。
その時は多分、クロードさんに教えてもらいながらババッと作って、
なるほど、こういう動きするやつね、これみたいな。
ちょっと自分で見てみたりしたね、そういえば。
ちょっと話を戻すと、プロジェクト検証から多分入るじゃないですか。
今自分たちが通常の既存PMの入れ替えで入った時に。
プロジェクト検証がちゃんと作られてなかった場合って、
そっち側から多分整備に入るから、整備してきますよね。
で、ソースコードの理解と多分そのアーキテクチャの理解のタイミングが
どんどん後ろ倒しになっちゃう気がするんですよ。
はいはいはい、そうだね。
そこのバランスをどうしていくかは個人的には気になる感じですね。
あー、なるほどな。
俺が大変申し訳ないことにソースコードに至ろうとすら思わないから。
あのですね、これ、ここ3年ぐらいの経験で言うと、
まさに自分もそういう感じだったんですけど、
なんかそれって役割分担を最初からテックリードを入れちゃおうっていう発想だから、
あ、そうだね。
あんまり良くないなっていうのを、
いざ入れられなかった時じゃあどうすんだよって話だから、
バランスはちょっと考えておきたいなっていうのを思ってる感じですね。
なるほどな、なるほどな。
プレイマネやんなきゃいけなくなるケースの時に、
既存のプロジェクトマネジメント状況がボロボロだったとして、
そっちの整備してる間に何て言うんですか、
設計とかがどんどんクソな感じで積み上がっちゃって手遅れになるケースもあるじゃないですか。
あるよね、あるよね。
そう考えると早めにそっち側もキャッチアップしとかないと結局まずいのかなとかは、
思うんですけど。
確かに、確かに。
そうね、それで言うと、
あんまりまずゴール設定みたいなところは認識合わせします。
プロジェクトのね。
で、やっぱり次スケジュールで、
そのスケジュール見た後に、
WBSなのかプロダクトバックログなのかは、
諸説あるかもしれないけど、
そこの整備はちゃんとやるっていうのが初手かな。
でもそのタイミングであれか、
コードもある程度キャッチアップするというか、
キャッチアップのプロセス
作る機能のキャッチアップがそこで入ってくるから、
そうだね。
バックグラウンド的にやるってことですね。
タスクの善良が見えてれば何作るかが分かって、
何を作ってるかも分かるはずで、
ボロボロのパターンって多分そこら辺が整備されてないことが多いので、
まずそこ整備しに行って、
そしたらここってクリティカルパスなのか、
今の体制でっていうところで考えたときに、
自分がどこに入らなきゃいけないのかっていうのが見えてくるから、
そこをまずバックグラウンド的に環境構築もしつつ、
動かせる環境はしつつ、
引き出しが増えちゃったのが、逆により難しさを増してる気はしますね。
手出せる範囲が増えたから、
自分はどこに手を入れていくのが一番いいのかなっていうのを見ていくかな。
引き出しが増えちゃったのが、逆により難しさを増してる気はしますね。
手出せる範囲が増えたから、
まずどこに手をつけようっていうところが、
やっぱりより上からアプローチしようってなるし。
そうですね。
例えばスケジュールを引いてタスクの洗い出しをした後に、
人が足りなくなったら、
じゃあ人員調達が先だよねとか。
そうだね。
逆にスコープマネジメントするのが先だから、
ステークホルダー調整を先にやろうとか。
多分そっち側に何か舵を切る気がしていて。
そうだね、そうだね。
だけど多分言われたものを作るときに、
必要なものを作る方向でスコープマネジメントをした方がいいよね、
みたいな観点にもなってきて。
うん、そうだね、そうだね。
でもどれもどれもコアのスキルが必要だから、
はいはい。
同時並行でできないじゃないですか。
いや、そうなんだよね。
これが、
スケジュールを作るときにスケジュールを作るときに
スケジュールを作るときにスケジュールを作るときに
いや、そうなんだよね。
これが、だから、
そうですよね。
人が入れない場合とかっていうのを考えると、
やっぱりそこからのアプローチになっちゃうよね。
そうですね。
スコープを調整するための理屈みたいな、理屈?
うんうん、ロジックを考えるからってことですよね。
そうそうそうそう。
こうなってるからこんだけ足んないですとか、
ここが足りてないからこういうスキルセットの人が欲しいです、
でもいないんだったらこうなりますみたいなところ?
組み立てにやっぱり行くから、
そうね。
そこにあるか。
そうですね。
いや、なんか大変そうだなって思いました。
キャッチアップね。
効率的な進行方法
キャッチアップは大変だよね。
うん。
なんか自分、どの選択肢をとっても、
結局落ち着くところは多分同じだと思うんですよね。
ゴールは一緒で、どういうふうに進んでいくかってなったときに、
なんかでもその方向だとあれですね、
得意なやつで自分の中で再現性がある手法を多分使うから、
プロジェクトマネジメントの手法で、
多分直しに行くんだろうなっていう気はした感じですね。
確かに。
そうね。
うーん。
うーんとかっつってね。
でもそうだと思うよ、やっぱり。
まずはそっちに行くかな。
さっきの話、ここ収録前の話だけど、
知らないサービスだったらとりあえずサービスの理解するし。
うんうんうん。
でもこれはやっぱりあれだね、
本当にこう仕事の時間にするんじゃないかなもん。
あーうまく。
結局は夜とか土日とかを使い、
関連サービスというかコアなところっていうところを調べに行って、
で、あとそのあれじゃないですか、
新しいチームだったら、
新しいチームとか新しい組織みたいな話すると、
ウォーターホールでやってるのかもしれないし、
アジャイルかもしれないし、
アジャイルの中でもそのスクラムなのか、
もうちょっとスクラムオブスクラム的に動いてるのかとか、
なんか別のアジャイルのフレームワーク使ってるのかとかっていう話もあるだろうから、
ちょっとそこら辺の復習もするだろうし、
そこはあるよね、
今スクラムのっていうかアジャイルのフレームワークも、
今というかずっといっぱいあるから、
何を採用してるのみたいな話も、
ちょっと確認必要かなっていう気はするな。
そっか、でも前提条件で話したところだと、
基本のプロジェクトに入るわけだから、
そこでのやり方がすでにあるんですもんね。
そうそうそう、あるはずだから、
今ちょっとスケジュールとかゴールに向けての話したけど、
そもそも体制どんなんだっけとか、
仮にスクラムだとしたら、
プロダクトオーナーみたいになってる人は、
プロダクトオーナーの動きがちゃんとできてるのかとか、
スクラムマスター的な人はいるのかとか、
ペアプロ、モブプロみたいなことしてんのかとか、
そういったところも結構キャッチアップ必要になるよね。
確かに。1回でもだから難しいですね。
よく新しく入社したら、
様子をまず見た方がいいみたいなのあるじゃないですか。
いきなりごちゃごちゃ変えるとかじゃなくて、
今のチームのやり方を把握した上で、
改善してった方が良いのではみたいなのを、
よく聞くと思うんですけど、
なんかあれって、リリース後のプロダクトだったら、
確かにそれでいいかもなって思うんですよ。
うちの会社も事業会社なので、
基本的にはリリースされた後はアジャイル系で開発していて、
そこにEMとかスクラムマスターで後から入るんだったら、
その1ヶ月ぐらい見る状態で入って、
1ヶ月してからこの1ヶ月でのフィードバックを
みんなにしていくとかは結構いいと思うんですけど、
鈴木さんが所属してる会社みたいな、
今日は開発プロジェクトが期間が決まってて、
たくさん来る場合のときで1ヶ月も情報確認してたら、
プロジェクトそのまま終わっちゃう可能性あるじゃないですか。
そうだね、そうだね。
いうのもパターンとしてあるなっていうのは思いましたね。
いや、そうだね。
そうだね、だから、
決が決まってたらどう動くかっていう話。
でも決が決まってたらどう動くかっていう話が、
やっぱりWBSとかプロダクトバックログみたいなところになるかなっていう感じで。
スケジュール確認した上で取るアプローチをだから変えるってことですよね。
そうだね、そうだね。
人を調達しないで。
俺なんかは結構その、
なんとかお願いみたいな感じで入ることがやっぱり多いので、
フィットするための意識
そういうアプローチになることが普段多いかな。
急に話を切り替えるんですけど、
おにぎりさんのキャッチアップエピソードを教えてください。
キャッチアップエピソードか。
2人の話聞きながらちょっと自分どんな感じだったかなってさっきメモしたんですけど、
考え方をまず言うと、
2段階自分の場合は振り返るとあるなと思ってて、
まずは会社なり、チームなのかわかんないですけど、
にフィットするためにやるっていうフェーズと、
より成果を出すために意識してることとか、
2段階あるなと今振り返って思っていて、
ざっくり言うと、
まずフィットするために自分で意識してることは、
当たり前のことになっちゃうんだけど、
そもそも自分と周りとか会社、
違いを知る、ギャップを知るみたいな背景だったりとか、
仕事の仕方とか、
私は最近だと社長とミニ三脚でデザインやることがほとんど多いんですけど、
例えば社長とか意思決定者の思想とか価値観、考え方の癖、
何をいいと思うのかみたいな価値基準をまず知るとか、
周りの人たちをまず知るとか、
逆に自分のことを知ってもらうみたいなのをすごい大事にしてて、
相互理解みたいな、簡単に言うとそれになっちゃうんですけど、
それによって結構自分は早い段階で、
自分自身の殻を破るじゃないけど、
自分に対する心理的安全性をまず高めて、
その後の成果を出すフェーズに行けるために、
そこで結構意識してやってるなっていうのが、
最初のフィットするために意識してることで、
成果をより出すためにっていうところのフェーズで言うと、
それは別に両方最初からやっていくイメージなんですけど、
どっちかに移行していくっていうよりかは、
どっちもやっていくイメージなんですけど、
成果を出すためにっていうと、
結構さっき周りのことを知るみたいな文脈とつながるんだけど、
チームの考え方の癖とか、今までやってきたこと、
何をやってなぜダメだったのかとか、
そこの背景とかも知った上で、
そこに最低限のリスペクトを持って提案するみたいなところで、
なんでこの話になったんだっけ。
そこをまず観察して、
自分の場合は結構そこで、
それを知った上で自分には何ができるかなとか、
どこで成果が出せそうかなみたいなのを観察して分析して、
自分が発揮できるのはここかなみたいなのを結構考えるんですよ。
その上で最速で、
まずここが結構インパクトありそうだから、
先にやるのか後々やっていくのかとかもあるけど、
そこの成果を出せるところを探して、
とにかく早く丁寧に所属を出していく。
所属を出していくっていうのはアウトプットもだし、
コミュニケーションもすごい気をつけてて、
なるべく早く成果を出せるようにやってるなって感じです。
ただし焦らないように気をつけるっていうのを毎回気をつけてる。
キャッチアップのプロセス
そんな感じかな、ざっくり言うと。
結構あった。
ありがとうございます。
はい。
成果の部分はでも面白いというか、
一般的によく言われますよね、
入ったときにいかに早くアウトプット、
多分必要なアウトプットをいかに早くして、
チームに溶け込んでいくかみたいな観点はあると思うんですけど、
期間で言うとどれぐらいを目安にアウトプットされるとかはあったりします?
そうですね、でも内容によってまちまちなので難しいけど、
普通に今の職場とかは一発目から結構新機能のデザインで、
1ヶ月ぐらいでそれやったんですけど、
それもそうだし、ただその前段で何だろうな。
だから物によりますかね。
今のおにぎりさんのエピソードの話だと、
1ヶ月目にその新機のデザインを頼まれてるって、
前段で何かあって、頼もうってなるから頼まれてる気がするんですけど、
確かに。
そっちの方が気になるかもです。
そうですね、なるほど。
でも、最初のちょっと軽めのタスクを、
本当に軽いやつ頼まれてそれをやってみたら、
そこのたぶん仕事の仕方とかもあると思うけど、
そこでちっちゃい信頼を獲得していくみたいな感じだと思うんですけど、
そこで、でも割と私の最初の今回の会社は結構特殊で、
それをやりかけてて、いけそうだからもうちょっと大きいやつやってよみたいな感じだったんで、
どうだったかな、難しいですね。
なんか最初の期待値とかもあったかもしれないなぁ。
今までの現場とかだとどうしてたんですか?
でもそうですね、それでいうと、
それ以外だとやっぱり最初、まずはオンボーディングタスクじゃないですけど、
まずなんかキャッチアップ目的みたいなタスクがやっぱりアサインされて、
軽めのものをやりつつ、そこでキャッチアップしていってみたいなのが多かったと思うんで、
そこでいかにほうれん草もそうだし、アウトプットもそうだし、
そこで丁寧に、でも早く所属を出していくみたいなところで、
まず信頼貯金を貯めていくとか、
あとはそうですね、みんながあんまり忙しくてやれてなかったこととか、
そういうまず役に立つみたいなところで意識してやってるかもしれない。
ありがとうございます。
なんか1年ぐらいチームに新しくチョインした人で、
すごいキャッチアップが早かったって感じた人が2人いるんですけど、
キャッチアップのときって、向こうとか新しく入ってくれる人も慣れが必要だから、
結構バッファー取ってオンボーディングのスケジュールって組んでると思うんですよね。
信頼構築の重要性
基本的に。
それをめちゃめちゃ早くやってくれる人とかが、
なんか結構印象が良いというか、その後の立ち上がりもすごい良かった印象がありますね。
確かに。それめっちゃ分かります。
1日で終わったから、バグチケとかあればやりますとかの人は、
多分そのまま機能開発とかに入ってくるイメージあるけど、
3日時間もらったから、なんか3日かかっちゃったよ、
でももっと勉強したいからプラス2日くださいみたいな人は、
その後もそれなりに遅いイメージはありますね。
でも私も最初それでしたね。今回の会社は。
2週間以上かかるかなーみたいな感じで相談されたのを、
2日ぐらいでやって、おーいいじゃんっていう感じで、
どんどん任せてもらったみたいな感じでしたね。めっちゃ共感するかも。
最初は150%ぐらい頑張ったほうがいいんだろうなって思いますね。
すごい思います。成果を出せそうなら、最初ちょっと無理してでも、
早く成果を少しでも出して、早く信頼してもらうみたいなところは確かに意識してますね。
いかに早く信頼してもらえるかみたいなところはすごい大事にしてるかな、そういう意味で。
そうですよね。期待値を捉えるためにもコミュニケーションはしつつ、
ちゃんと成果を出していきましょうってことですね。
そうですね。コミュニケーション量を増やすこともすごい大事ですよね。
にぎりさんのエピソードでさっき気になったのが、
みんなが着手できないことを代わりにやってあげるっていうのがあったと思うんですけど、
ちょっと難しいところだなと思っていて、
みんながそれをできてないというものの、なんでできてないんだっけっていうのがあると思っていて、
他に優先度の高いタスクがたくさんあるから、
早くそっちの方に手伝ってみに入ってほしいのかもしれないじゃないですか。
そうなったら多分それをやるっていう行為をしたときに、
ものによっては印象があんまり良くないかもしれないなっていうのは思いましたね。
確かに確かに。そこの見極めだったり。
そうですね。
確かに。あるかもですね。
にぎりさんはものすごく上手に得られてそうですけど、
ここはずらのままやっちゃうと、たぶん自己る人は出てきそうだなっていう。
確かに確かに。そうですね。確かに。
ここは見ますね、すごい。
勝手にやっちゃいましたみたいな感じじゃなくてっていう。
はいはいはいはい。ありがとうございます。
そろそろ良い時間ですので、鈴木さん、締めをお願いします。
まとめはしません。
みんなのね、聞いている人たちのみ分かりますということで、
そんな感想やこれを聞いてどう思ったか、
こういうふうにまとめられるんじゃないかっていうのを
ハッシュタグぐちっぽじFMでXにポストしていただけると、
我々とっても励みになりますので、
ぜひぜひよろしくお願いいたしますというところで終わりにしたいと思います。
はい、今日は、今日も、今日も、本日も、今回も聞いていただきありがとうございました。
よろしくお願いいたします引き続き。
バイバイ。
ありがとうございます。バイバイ。
