Webアプリチームの大橋です。
昨年4月に入社した新卒メンバーも先月からは2年目の先輩となりました。
サポーターの一人であった私も感慨深く、この一年を振り返ってみたいと思います。
昨年の新卒メンバーたちは2週間の社内研修期間を経て、4月15日から各プロジェクトに配属されました。
他社に比べたらかなり早いほうだと思いますし、完全リモートワークで直接のコミュニケーションができなかった状況で、かなり不安だったと思います。
彼らをオープンワークの一員として受け入れ、適応をサポートすることが私たちの役割の一つでしたが、特別なマニュアルもなく進め方は各プロジェクトに委ねられていたため、正直なところ私も少し不安でした。
今回は私が所属するプロジェクトチームに配属された加瀬さんのオンボーディングの振り返りを行います。
オンボーディングとは
企業が新たに採用した人材を職場に配置し、組織の一員として定着させ、戦力化させるまでの一連の受け入れプロセスです。
私は主に以下のことを意識していました。
- チームに馴染んでもらい、仕事に慣れてもらう
- 仕事に必要な知識を手に入れて、戦力化する
- 仕事のやりがいや楽しさを見つけてもらう
チームに馴染んでもらう、仕事に慣れてもらう
新機能開発とオンボーディングの両立
加瀬さんが配属された頃の既存メンバーは大きめの新機能開発の真っ最中でした。
その為、開発フローを順調に進めながらオンボーディングも実施するということが初めは難題でした。
そこで、プロジェクトのエンジニアを新機能開発チーム(スクラム開発)と保守・改善系タスクチームに担当をわけ、始めは保守・改善系タスクチームに入っていただき、少し仕事に慣れてもらいました。
スクラム開発チームへの参加
その後5月末からはスクラム開発チームの一員として参加していただきました。
チームとしての一体感が出るようになりましたし、他のメンバーの目も届きやすくなりました。
スプリント期間(1~2週間)を意識してタスクを進めることにも慣れてもらいました。
また、スクラム開発では様々なスプリントイベントがあるのですが、例えばスプリントレビューでは自身が主に担当した開発物のデモを行ってもらいました。
オープンワークではエンジニアでも人前で話すことに慣れることも必要で、最近では私よりも説明が上手だと思いました。
意図的なコミュニケーション機会を設ける
毎日朝会をプロジェクト全員で行っていたのですが、朝会のファシリテーターとして、曜日ごとにエンジニアで交代し、加瀬さんにも担当していただきました。
また、それ以外にも夕会として6月初旬までの毎日夕方の30分ほど、質問や相談ごとを気軽にできる時間を設けました。(交代で正社員エンジニア1名+加瀬さん)
仕事に必要な知識を手に入れて戦力化する
効率の良いソースレビューの模索
原則、社員2名以上の承認が必要というルールにしていましたが、初めのころはレビュー指摘が多くなったり、レビュー依頼するまでに時間がかかってしまうことがありました。
そこで、以下のことを実践しました。
- 完成していなくても途中段階でのレビュー依頼や相談をしてもらう
- 毎朝45分のモブレビューを導入し、そこで相談を行う(持ち時間1人10~15分)
- 始めて実装する機能は初めだけ画面共有しながらペアプロする
また、スピードを重視するならレビューコメントで結論を「教える」「示す」のが手っ取り早いですが、 自身でも考える姿勢を身に着けてほしかったので、途中からはできるだけ最初から答えを出したり、断定しないようにコメントを気を付けました。
相談、質問することへのハードルを取り除く
開発中につまづいたり悩んだりしたとき、すぐに誰かに聞いたほうがいいでしょうか?それとも自分で調べたり考えたほうがいいでしょうか?
加瀬さん自身は自分で考えたいという気持ちもあり、そこで時間を費やしてしまうことがありました。
私もあまり急かさずに考える時間を与えたいという思いがある一方、スプリント期間内でタスクを終わらせなければというプレッシャーの間で悩むことがありました。
そんなとき、メンバーが紹介してくれた良い質問をして自己成長に繋げるためのあれこれ がとても参考になりました。
この記事にあるように、質問の仕方次第で自身やチームを成長させることができると思います。
良い質問の仕方ができるようになることはとても大事で、その質問によって他のメンバーも新たな気づきを得ることもできます。
また、オープンワークではSlackを活用しているのですが、加瀬さんには自分専用のつぶやきチャンネルを作ってもらいました。
自分で解決中のつまずきなどはそのチャンネルでつぶやいてもらい、メンバーが時々見に行くようにしました。
経験値を増やす
チーム内でのタスク分担において、初期のころはなるべく簡単なコーディングなどを加瀬さんにアサインするようにしていましたが、途中からは「やったことないこと」や「できるようになってほしいこと」を敢えてアサインするようにしました。
また、初めは主にコーディングをアサインすることが多かったのですが、昨年末からは詳細設計やテスト設計、画面設計も依頼するようにしました。
私はどちらかというと慎重派で、プロジェクト全体の遅れや加瀬さん自身への負担を気にしがちでしたが、他のメンバーは思い切って任せてみようと考えるタイプだったことや、その頃にはメンバー同士が柔軟にフォローできるチームが出来上がっていた為、安心して任せられるようになりました。
やはり思い切って任せてみたほうが成長の幅が大きいと感じることができました。
仕事のやりがいや楽しさを見つけてもらう
社会人は平日のほとんどを仕事の時間に費やして、やることに追われたり、思うようにできなかったり、良い評価をされなかったり、と学生の頃とは異なるストレスも多いと思います。
そんな中でも私が仕事を長く続けられているのは、仕事にやりがいや楽しさがあるからです。
例えば、1つの施策を問題なくリリースできたとき、実際にそれを使っている人たちがいて、会社の資産や利益に繋がったと感じたとき、自分がスキルアップしたと感じたとき、頑張りを見てくれている人がいて良い評価をもらえたとき、同僚との交流など。
新入社員のメンバーにも、それぞれのやりがいや楽しさを見つけてほしいと思っています。
ですから昨年末、オープンワークの新入社員も含めた開発プロジェクトがグループ全体で表彰されたときはとても嬉しかったです。
こうした気持ちを忘れずにこれからも頑張ってほしいと思います。
最後に
私自身もこの一年、オンボーディングを通していろんなことを学ばせてもらいました。
マニュアルがないからこそ個々のスキルや性格にあったオーダーメイドのオンボーディングを模索できたと思います。
オープンワークでは、指示された仕事だけでなく、チームや会社にとって必要な仕事を自ら考えて生み出すことができるエンジニアを求めています。
私が今後目指してほしいのはそういうエンジニアで、オープンワークにはそれを実践できる環境があります。
「未経験だけどできるだろうか?」と不安な学生さん、どうか遠慮せずに、私たちに新しい学びを与えるという意気込みで飛び込んで来てください。
オープンワークと一緒に成長していきましょう。
新卒エンジニアの視点から techblog.openwork.co.jp オンボーディングについての他の記事 techblog.openwork.co.jp vorkers.jp