00:00
はい、kameiです。 yykamei's Podcastやっていきます。今回のトピックは、新しい会社です。
転職をしまして、新しい会社に入りました。7月1日入社になります。 まだ
ご営業日しか経験してないので、正直何もわかりませんっていうのが感想です。 最初の方にオリエンテーションっていうのをやってもらって、
そこで会社の文化、カルチャーが色濃く見える オリエンテーションを受けました。
オリエンテーションってやっぱり 重要だなっていうのを感じますね。
で、その辺りで、こういう会社なんだなっていうのがわかるので、 よかったなと。よく設計されたオリエンテーションだなって思いましたね。
なんかまあ、毎月割とコンスタントにこの会社、人が最近入っているようで、 ちょっと具体的な数字は言わないでおきますが、
まあそれなりの数入っているそうですと。 来月もそれなりの数入るそうですということでした。
オリエンテーションを受けた後に、配属をされるわけなんですけれども、 配属された後は正直もう本当にわかんないですね。
前者的なオリエンテーションというのはうまく設計されているように見えるんですけど、 配属後のオンボーディングに関しては、もう各チームよろしくっていう感じなんですよね。
で、私が配属されたチームは全然アレですね。 まあ全然アレっていうのもアレですけど、そうですね。
そもそもチーム自体が今年の1月、2月だったかな。 まあとにかく最近できたっぽいような感じなんですよね。
で、そのままバタバタした感じで新しい人が入るってなって、 まあそりゃオンボーディングなんか準備する余裕ないよねっていうのもうなずける話かなとは思います。
まあそんな感じで、 私に求められているのはとにかくお前から動け、お前からムーブしろっていうことなんですよね。
なので聞かないといけないなということで聞くんですけど、 私ちょっと気をつけなきゃいけないなって思うのは普通に質問してるだけなんですけど、
なんかちょっと質問されている、詰められているように感じる可能性があるんじゃないかなと思ってて、
実際その新しい会社の人にそんなこと言われてはいないんですけど、 なんかもしかしたら詰められてるって思ってるかもしれないなって私がちょっと感じるところがあるので、
まあ本当にちょっと気をつけないなと思いますね。 マジで何もわからないから聞いているんですよね、今って。
本当にわかんないんですよ。 本当にわかんないし、これ誰に聞けばいいかわかんないから、まあとりあえずメンターの人に聞くっていう感じなんですけど、
03:03
まあ本当に気をつけないといけないなって思ってます。 チームごとのオンボーディングって
意外と大事だよねっていうのを入った立場としては気づきましたね。
会社のオリエンテーション、会社のオンボーディングっていうのは、この新しい会社では人事だから、総務だったかな、まあとにかくその
そういった部署があって、もう専門でやってるんですよね。 毎月のようにやってるからナレッジもたまるし、ノウハウもあるし、
まあもう本当に慣れて生きているので、全然うまくこなせるとは思うんですけど、チームのオンボーディングっていうのは、そんなことはなかなか機会が少ないし、
あとマンパワーもないし、そもそも他の業務が忙しいしで、なかなか手つかずだよなぁ。でも一番重要というか、入社したメンバーとして一番知りたいのって、
やっぱりチームのオンボーディングな気がするんですよね。 そのチームで扱っている業務、そのチームのドメイン知識
っていったものが一番知りたいと思うんですよ。それが知らないと、仕事にならないので。 なんですけど、そこを手厚くするのは非常に難しい。
これはちょっと新しい発見だなって思うので、誰かいいソリューションを考えてほしいですね。
チームのオンボーディングをどうするか。会社的なオンボーディングは正直、勝手にうまく設計されていくんですよ。さっき言った通りその人事とかロームとか
ソームとかわかんないですけど、そのあたりのチームが編成されて、その人たちが専門的にやるのでいいんですけど、
本当にチームのオンボーディングはマジで大変。で、これをやるにあたってよくある話が、
とりあえずドキュメントがあれば大丈夫じゃないかっていうのなんですけど、ドキュメントあっても無理です。
っていうのが、入社した立ち位置でわかりました。なぜ無理かというと、
とにかくドキュメントが多すぎたら、どれから読んでいいかわかんないし、
ドキュメント自体も本当に更新されているかどうかってちょっと怪しいので、あんまり信頼性が持てないんですよね。
このドキュメントを読めば完璧、これだけ読んどけば完璧みたいなのがあれば、まあいいんですけど、おそらくそういうのって少なくて、
まあドキュメントって、そうですね、ドキュメント読めばOKのスタンスはちょっと危険だなっていう気がします。
逆に言えば、このドキュメントを読めば確実にわかるぐらいの言い切りができるのであれば、それはそれで素晴らしいなって思いました。
06:01
ドキュメント、そうですね、ドキュメントは本当に書いて終わりじゃないですからね。
メンテして、更新されて、手垢がついていくのが、ドキュメントとしていいドキュメントだなっていうのが私は思っているので、
それを新しく入った人とか、あとはその開発以外のメンバーが見て、なんとなくわかるっていうレベルになると、まあいいなとは思いますね。
やっぱりどこの組織に行っても、このドキュメントに関する話題って尽きないなっていうのは感じますね。
で、本当にオンボーディング以外のことで本当にわからないですね。
とりあえず、いろいろな会議帯で自己紹介をしたりして、こうやって過ごしているわけですけど、
そうですね、ちょっと一つ気づいたことといえば、基本オンラインなんですけど、オンラインのリモートでの仕事なんですけど、
ミーティングというのは基本オンラインで行われますと。オンラインで行われるミーティングって、しゃべる人以外がミュートにするっていうのがよくある話じゃないですかと。
私個人としては別にミュートしなくてもいいかなとは思うんですけど、まあそれが礼儀とされている風潮もあるので、
まあみんな、みんなというか割と多くの人がミュートにすると。で、そりゃオッケーですと。
で、前の会社だとそれで本当にだんまりっていうのがよくあるなぁと思ったんですけど、
新しい会社に入ってみると、ミュートしつつも何かしらの発話者の言動に対してリアクションを結構するんですよね。
ビデオツールいくつかあると思うんですけど、多分どのビデオツールでも大体のリアクションをするみたいな機能があると思うんですよ。
手を挙げるっていうリアクションだけじゃなくて、そのいいねだとか、なんかハートだとか、泣いている感じのあの顔とか、
そういうのが絵文字みたいなのでリアクションするっていうのがあると思うんですけど、それを結構積極的に使っているのがいいなって思ったところですね。
そういったリアクションがあるだけでやっぱり多少安心しますよね、喋ってる人は。
なのでこれは結構簡単だから、このプラクティスいろんなところで使うといいんじゃないですかね。
結構簡単ですよね。使いましょうって言って終わりにはなるんですけど、
それで各メンバーが使ってくれるかどうかはまたそこのメンバー次第にはなると思うんですけど、
でも一回試してみる価値は全然あるなっていう気がしますね。
とにかくリアクションが薄いチームには、チームというか会議体ではオススメのプラクティスだなって思ったところです。
新しい会社入って気づいたところはそんなところですかね。
本当に今は何もわからんという感じで、これからどれくらい在籍することになるんですかね。
とりあえず今のところ辞める予定はないんですけど、頑張っていこうかなと思っています。
09:02
今回は新しい会社でした。
それではまた。
