中間ポジションをいただいての大切にしたこと
ポジションについて
現職では自社開発のフロントエンドとして6年ほど在籍しており、今回私は初めてポジションをいただきました。
そのポジションの期待役割は「特になし」ですw
具体的に言ってしまえばマネージャーorテックリードを目指すまでの中間的なポジションです。
整理すると下記です。
ポジションをいただいてからの取り組み
期待役割は「特になし」ですが私自身ポジションをいただいたからには何かしらチーム貢献はしていきたいと思っておりました。
その際に現状のチームに足りない部分。自分の目指したい姿を整理しテックリードを目指すための動きを行いました。
以下に具体的な取り組みをまとめます。
1.Slackを使いコミュニケーションを取りやすい印象作り
弊社ではSlackで分報をやっており、そこでは詰まっている問題やプライベートな小話的なつぶやきが活性化しています。
そのため問題に直面している人がいた場合にはフロントエンド、バックエンド問わず、Slackを声がけして一緒に問題の対処法を考えたり、対処法を教えたりしていました。
個人的にこれをやるにあたっては以下を大事にしました。
順に解説します。
- 声がけする問題はコンフォートゾーン、ラーニングゾーンに留める
- 義務化はしない
- 自惚れない
声がけする問題はコンフォートゾーン、ラーニングゾーンに留める
まずゾーンについての説明はここでは省きますが「コンフォートゾーンとは？意味を理解し、抜け出すことで、成長を加速させる方法を解説！」の記事がわかりやすいので読んでみてください。
他の人が抱えている問題なので結構ラーニングゾーンになる傾向はありますが個人的には通常業務ではコンフォートゾーンに収まることが多いので個人的には学びが多く楽しかったです。
逆に自分の力がわかっておらずパニックゾーンに突っ込んでしまうとかえってメンバーの邪魔になってしまいます。
逆にメンバーにとってのランニングゾーンになりうる課題に関しては安易に答えは言わずにデットを決め、少々時間をかけてでも考えていただくようにしました。それがメンバーの成長に繋がると思っているためです。
具体的にこんなイメージです。
この場合はむしろ説明時間などとってしまいAさんの邪魔になってしまいますよね。
A：「Nextの環境変数がうまく反映されないだよな。。。」
自分；「話聞きますー」
A：「ありがとー。ここまでは設定したんだけどどうやらクライアント時にだけうまく反映できないんだよね。。。」
自分：「そもそも環境変数って何ですかね？」
A：「・・・」
義務化はしない
中間的なポジションのため自分自身も通常タスクは普段通りあるため忙しい時は声がけしなかったです。（後からゾーンを見極めて返信したりすることはありました。）
これは自分が自主的に行なっている動きです。
「絶対に声がけしなければ」と義務化してしまうとチームに対してネガティブなイメージを持ってしまいます。具体的には以下です。
A：「Nextの環境変数がうまく反映されないだよな。。。」
自分；「話聞きますー」
自分；(自分の案件、今日中に終わるかな。。？)
A：「事象はこんな感じで〜」
〜一時間後問題解決〜
自分：(自分の案件が終わらない。。。Aさんの話が長いからだ。。。ちょっとは自分で考えてほしい。。。)
自惚れない
自分はまだまだ強いエンジニアではないですし、全知全能ではないです。
ラーニングゾーンであっても解決方法をすぐに提示できるわけではないです。
そのため以下が重要です。
👎 意固地になって直面している問題を自分で解決しようとする
👍 一緒に直面している問題の解決策を考え、解決策が浮かばない場合は方向性を示す
方向性とは具体的に下記イメージです。
A：「Nextの環境変数がうまく反映されないだよな。。。」
自分：「話聞きますー」
自分：(うーん、確かに分からないな。。。)
自分：「これから1時間は互いに調べてみましょう。それでも解決策がわからない場合には一時的に環境変数を使わずにクライアントべたがきで様子をみましょう」
このような取り組みを継続した結果、バックエンド、フロントエンド問わずフロントエンド関連の問題、相談は最初に自分に飛んでくることが多くなりました。
それだけでもやった価値はあったと思います。
2.メンバーを頼りスキル面で自信を持ってもらう
ここはチームビルディングに関する部分にもなります。
チームメンバーにもそれぞれの技術面で得意、不得意があります。
個人的には不得意は最低限補えればよくて得意が一つでもあったらそこをしっかりと伸ばし、チームに共有し還元してほしいと思っております。
ただ弊社のチームメンバーには以下ケースがあるのでは？と思っていました。
- 自分得意分野がわかっていない
- 自分の得意分野はフロントエンド領域ではないと感じている
- 技術強い人は全てにおいて強いので自分が下手に口をださない方が良いのではないか
フロントエンドの領域は年が経つごとにどんどんカバー領域が多くなってきていると実感しています。
なのでjsやts,lint,docker,CI/CD,テスト対応などコーディングがメインとなってきていると勘違いしてしまう方が多い気がしますが、デザインや動的動きの実現、アクセシビリティの考慮、サイト改善なども立派なフロンエンド領域な気がしています。
なのでデザイン関連やGTM、GA関連でわからないことがあったらそこを特技としているメンバーにしっかりと頼り自信を持っていただくことを心がけました。
3.メンバーの行動に対しての積極的なリアクション
上記につながるケースもありますが
チームメンバーからチーム内で知識共有していただく機会がありました。
その際もできる限り出席し、わからない部分は小さなことでも質問し、質問がない場合はポジティブ感想やリアクションは残すようにしました。
質問について
ただ質問に関しては良い質問と悪い質問があると思っており、良い質問をしなければ共有者の気分を害してしまうと思うので注意です。
悪い例
👎 マウント取るような試すよな質問
良い点
👍 自分が興味ある部分についての質問
👍 自分の知識不足をひけらかす基礎的質問
なんとなく想像つくかと思いますが、「自分の知識不足をひけらかす基礎的質問」は少し違和感があるかと思います。
少し説明させていただきます。
この質問の目的はチーム間で以下認識を持ってほしかったからです。
😄 こんな基礎的な質問しても良いんだ！
😃 技術面で先頭を動こうとしている「自分(tmo-taka)」でもこの分野はこのレベル感なのか！
まとめ
まだまだ自分の役割を果たしきれていないとは思いますが、微力ではありますがこれからもどんどんチームを良くしていければと思っております。
そのためにはチームメンバーの主体性も必要不可欠です。主体性に働きかけるために様々なアプローチを試していきたいと思います。
Discussion