オンボーディングと社内課題の解決ができる「一石二鳥」の制度
見出し画像

オンボーディングと社内課題の解決ができる「一石二鳥」の制度

※本記事は2019年7月に書かれたものです。


こんにちは、RELATIONSの池田です。note移行後、初ブログ。

現在はエンジニアとして、マネジメントツール「Wistant」の開発等に携わっています。技術系の話は「RELATIONS Developers Blog」で書いているので、よければ覗いてみてください。

今日は、技術の話を少し置いといて・・・

僕がRELATIONSに入社したのは、2019年の1月。そして4月にもう1名のエンジニアが新たにチームに加わったのですが、その時に実施された「オンボーディングプログラム」の話をさせていただければと思います。

簡単に説明すると、エンジニアとしては個人の成長と組織への帰属実感に繋がり、会社としては社内の課題を解決しながらエンゲージメントの向上を狙える、まさに「一石二鳥」の制度です。

プログラムの設計をしてくれたバックエンドエンジニアの奥宮さんと、
実際にオンボーディングを体験したジェロ(Jerome Dupuis)さん、そして僕の実体験に基づいて書いてますので、エンジニアの方々のご参考になれば嬉しいです。

オンボーディングを導入した理由

もともとRELATIONSには、全社としてのオンボーディングはあっても、エンジニアを対象としたオンボーディング制度はありませんでした。

そんな中、エンジニアの奥宮さんが2018年の「プロダクトマネージャー・カンファレンス」に参加した際、とある講演で「採用は、採って終わりではなく、その人が活躍するところまで!」という話を聞いたことが、エンジニアオンボーディングについて考える契機となったそうです。

この講演自体はPMの事例でしたが、RELATIONSのエンジニアにも通ずる部分がありました。例えば、エンジニアが所属するWistantチームは新規事業のひとつですが、全社としてはコンサルティング事業やメディア事業などの異なる事業部が複数存在しており、組織構造的にエンジニアの業務が全社に見えづらい状況でした。

業務上のコミュニケーション・パスがあまりない上、そもそもエンジニアってコミュ障が多い…。でも「技術で貢献し、みんなの役に立って認知され、自身も達成感を得て、羽ばたく」ことができれば、本人にも会社にもハッピーになるはず、と考えたそうです。

オンボーディング制度の目的

制度の目的としては、主に2点あります。

1.会社とチームに早く馴染んでもらう
2.成果を出してもらう

まずひとつめは、会社とチームに馴染んでもらうこと。そこで、全社のいろんな人とコミュニケーションが取れるように、「社内の課題を技術的に解決する」というテーマを設定しました。

実際、課題を通じてコミュニケーションをとっておけば、ゴチ制度を使って他事業部の人も食事に誘いやすくなったりしますし、より会社に馴染みやすくなるのではないかなと思います。

そしてふたつめは、成果を出してもらうこと。それも「目に見える成果」が大事で、この意味でも「社内課題の解決」が適していたそうです。というのも、身近な課題が解決すれば、全社の人から感謝され、自然と受け入れられる土壌ができ、所属意識や組織へのエンゲージメントにもつながります。

やはり、通常業務だけだと目に見える成果をすぐに創出することはなかなか難しいので、こういった確実な成果に繋がる取り組みは、エンジニアの達成感や承認欲求も満たせてくれるのではないかと思います。

オンボーディングプログラムの内容

実際のプログラムは、入社して最初の3ヶ月をかけて行われました。

僕が取り組んだ課題は、「360度フィードバックの改善」です。詳細はまた別のブログに書きますが、ヒアリングから要件定義、開発、ユーザテスト、リリースまで、社内メンバーの協力を得ながら行っていきました。

もうひとりのオンボーディング体験者、ジェロさんには「福利厚生システムの開発」を担当していただいてます。(今、完成間近です。)

技術的に難しい点や質問などがあれば、他のエンジニアメンバーに協力してもらいながら進めました。そして、納期ギリギリで完成したのがこちら。

画像1

フィードバックは「愛の込もった贈り物」ということで、「Gift(ギフト)」と名付けました。早速、今期1Qの360度フィードバックから全社で使っていますが、メンバーからもなかなか好評いただいてます。

オンボーディングの「効果」は?

では実際に、オンボーディングを通じて、どんな効果があったのか? やってみて何が良かったか? をジェロさんにインタビューしてみました。

ジェロ:課題解決のために、社内の色んな方々にヒアリングをしていくので、ほぼ全員の方とコミュニケーションがとれるから良かったです。

あと、この制度の魅力としては、課題解決の手段をすべて自分で決められるところでした。既存の技術に捉われることなく、自分が使いたい / 得意な技術を使って開発ができるので、何より楽しいです。また、入社して間もなく責任が持てるところも良かったです。

僕自身は、エンジニア未経験で入社したので、実業務で使う技術を学びながら開発することができ、チームの仕事に移るときにとても役立ちました。

成果にコミットしながらも自分の成長もすごく実感できて、会社に来るのがほぼ「遊び」の感覚でした(笑)業務ではこうした個人のアウトプットをゼロから作るのは難しいので、できるならまたオンボーディングしたいくらいです。

でも、まだまだ改善点はあります

まだ始まったばかりの取り組みなので、今後新しく入ってくるメンバーには、さらにブラッシュアップした形でオンボーディングを受けていただけたいと思っています。そこで、3人で改善点についても話し合ってみました。

ジェロ:自律的にプロジェクトを進める上で、専門でない部分の作業のサポートが少し足りないところですかね。もちろん助けを求めれば、皆さん潔く協力してくれるのですが、私はインフラ系が得意ではなかったのでその辺り少し苦戦しました。
奥宮:ヒアリングからリリースまで一人で完遂することのメリットがある一方で、確かに非専門領域に関しては難しいところですね…。全員がフルスタックなわけでもないし、実際のチーム開発ではフルスタックになる必要性もないですからね。
池田:似たようなところで、プロジェクトの成功も失敗も個人の努力次第なので、人によっては合わなかったり、完全に放置されてしまうケースが起こり得るかなと思いました。特に経験の浅い人で自分でキャッチアップできない人はそうなるかもしれないので、今後、そういった方向けのオンボーディングプログラムを作ってみても良さそう。
奥宮:確かに、未経験者でも無理なくオンボーディングに成功できる仕組みがあれば、採用面でも楽になりそうな気がするね。

最後に…「新しい制度」も生まれました

実は、オンボーディングプログラムで得た気づきから、新しい制度も生まれました。それが「サブ・プロダクト制度」です。

詳細は、また後日きっと奥宮さんが書いてくれると信じて(笑)、概要だけざっくりお伝えすると「開発工数の最大20%を、主業務以外のプロダクト開発に使える制度」です。

エンジニアって何かを作ることが好きだけど、「作りたい」となってから0→1でやり切るのは割とハードルが高いですよね。僕としても、この制度にはすごく賛成で、よりアウトプットを出す文化を作っていきたいと思っています。

今後入社してくるエンジニアの方々のためにも、より「ええエンジニア組織」と「ええエンジニア文化」を築いておきたいと思います。



この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
RELATIONS株式会社(https://www.relationsgroup.co.jp/)の公式アカウントです!会社や事業、メンバーについて、ありのままの姿をお伝えしていきます。