フルリモートオンボーディングを仕組みで捗らせた話
TL;DR
スタートアップにおいては活発な採用活動と新規参画者の素早いランディングは事業推進の原動力になります。
私達スカイディスクは製造業界を中心として最適ワークス・DXソリューションという２本柱で事業を進めており、どちらの事業部も新規参画者が会社、事業環境、業務知識を素早くキャッチアップして物事を前進出来る体制になることを望ましいと考えています。
また、フルリモートで業務を進めるITベンチャーであるのでドキュメントコミュニケーションを中心とした仕組み化の必要性は出社前提の会社よりも高くなっています。
今回はスカイディスクにおける入社オンボーディングの仕組みを全社・事業部・チームのそれぞれのスコープで策定したことの記事になります。
WHO AM I
株式会社スカイディスクで最適ワークスのフロントエンドエンジニアの市川です。東京からフルリモートで働いています。GitHub idは icchie なので社内では「いっちーさん」などと呼ばれています。
私自身は文学部出身のエンジニアで、サービス名が「最適ワークス」になったワケでSaaS事業部長の畑村さんが触れていましたが「最適ワークス」というサービス名称を開発したりと、言語化とエンジニアリングの組み合わせで問題解決していくタイプのエンジニアです。
自己紹介ページで
入社時の1対Nの非対称性を解決する
私自身は2021年4月にスカイディスクに転職しました。その際、全社の人数は現在の約半分30名ほどで学校の1クラス程度の人数ですが、前述の通りフルリモートでなおかつコロナ禍ゆえにどのような人がいるのかの把握が難しい状況でした。
私の入社後にも新たに人が増えている状況で、もっとお互いを知りあえる必要性を感じた末に畑村さんに、自己紹介のページを作りみんながお互いのことを知ることが出来るようにしましょう、と提案したのでした。
当初は事業部単位からの開始予定でしたが、すぐに社長の内村さんから全社展開しようという方針が示されて、基本的に全社員が自己紹介を書く運用になりました。
この自己紹介ページは以下のような効果がありました。
社員同士がお互いを知る。意外な趣味やいままで知らなかった経歴を知ることが出来た。
新入社員が既存の社員の顔と名前を一致させるのが早くなったうえで、どのような人がいるのか何が得意かを知ることが出来る。
入社時のフローに自己紹介を書くことが組み込まれているので、部署が違っていたとしても新入社員について知ることが出来る。
会社に限らず、既存のコミュニティに飛び込む際には新たな環境への期待感と新しいことを吸収しなければならないという緊張感があります。
自己紹介ページは一緒に働く人達のことを知るということのハードルを下げて、会社に早く慣れてもらうことに一役買っています。
自己紹介で書いたことにコメントが付くことも多々あります。
業務知識・用語をみんなで話し合い、アップデートする
SaaS事業部が提供する最適ワークスは製造業向けの生産計画スケジューラです。一概に製造業といっても簡単に定型化は出来ず、製品であれば食品・自動車・化学製品など、生産方式であれば組立製造やプロセス製造とあったりと組み合わせによって策定している生産計画の方法論は異なり多彩になります。また、同じ用語であっても指し示す意味が異なるということもあり、その用語が指し示す意味の齟齬から事業部内でもコミュニケーションロスが発生する事例も起き始めました。
これに対して、用語が指し示す意味を明確にして事業部内の齟齬を減らすために「ワーディング委員会」という有志の会を立ち上げることにしました。ちなみに開始時当初の会の名称は「用語を確定する会」でした。
「ワーディング委員会」の当初の主たる目的は最適ワークス自体のプロダクト上での要素や生産計画を立案するために必要なデータや概念の言語化でした。これをマーケティング、カスタマーサクセス、AIエンジニア、Web開発と事業部内で横断的に議論することにより、ポジション毎によって同じプロダクトを通しても見ている視野が異なっていることを再確認し、それを踏まえて事業部全体で合意する用語を確定していくことが出来ました。
また、この会は単に用語を決めるという役割から広がり、ポジションを横断してプロダクトやそれを使うユーザーに関して議論することも多くなり、「もやもや」の言語化を促進する会ともなりました。それゆえに会の名称を「ワーディング委員会」に改称したのでした。
現在ではワーディング委員会が策定した用語集は新規参画者が最適ワークスを理解する石杖になっています。
開発フローを明確にして、戸惑いを減らす
前述しましたが、私は最適ワークスのフロントエンドエンジニアです。
最適ワークスのα版当初はフロントエンドエンジニアとしては私1人で進めていました。その後、山口さん（以下、つよしさん）が合流してフロントエンドエンジニアは2人体制となりました。つよしさんとは前職と合わせてその時点で2年以上一緒に働いていたので敢えて言語化せずとも必要とされる品質やテストの基準、レビューフローについて暗黙の了解があった状態でした。
その後プロダクトも順調に育ち、資金的にもフロントエンドエンジニアの増員が可能になってきました。そのタイミングで私達はフロントエンドの開発フローを明記したドキュメントを用意することにしました。
目的としては前述の求める品質やそれに目指す理由や考え方、手順の共有、後続のエンジニアの理解を促進するためになります。
このドキュメント自体の詳細についてはメンテナンスを重ねて結果として8割を執筆しているつよしさんが今後解説を書いてくれることを期待して割愛しますが、このドキュメントに私が込めた思いとそれのもたらした効果について説明します。
思いとしては開発に関しての文化の共有して一緒に働きたいということでした。ここで言う文化というのは、言い換えると共有する価値観や行動様式というようなものです。
新規にメンバーを受け入れる際、全く異なった文化の方が来ることは多々あります。例えば、とても開発が忙しい現場出身でテストを書く習慣がなかった、ペアプログラミングを徹底しているところだったのでコードレビューはなかった、などなど。
そのような違いはあえて明示的な文化を示さないと「やるのが当たり前だと思っていた」という齟齬を生む原因となります。齟齬を減らし、スムーズな開発オンボーディングをすることを目的にドキュメントを用意したのでした。
実際の効果としては以下が挙げられます。
開発フローをドキュメント化することで、新規参画者へのフロー/ルールの説明が容易、かつ明確になった
開発フローに従っていないことがある場合には、全てを説明しなくても「このドキュメントを参照してください」のように簡単に説明できるようになった
また、このドキュメント自体は不変の聖典のようなものではなく、不要になった項目は削除を行い、非効率だと感じるようなことがあれば改善を重ねています。
DXの会社として
人を思いやる仕組みを積極的に取り入れていく
ここまで全社・事業部・チームと3つのレイヤー単位でオンボーディングの仕組みを策定したことをお話してきました。
それぞれが効果を上げていること自体とても喜ばしいことですが、これを成し得たのもスカイディスクが改善する・楽になることを良しとし積極的に受け入れる会社であったこと、そしてメンバー全員が柔軟によい仕組みを受け入れる気概を持っていることが重要だと考えています。
顧客のDX推進を事業の要にしている会社だからこそ、社内の文化としてデジタル化やドキュメント化でスムーズになることを大事にしているのだと考えています。
これは私の意見ですが、会社というのは集団で知恵を積み重ねていくことが価値の源泉です。
スカイディスクはフルリモートでそれを実現して前進を続けている会社だと私は自負しています。
Join us!
スカイディスクは全職種採用強化しています。
経営層、管理部、セールス、マーケティング、カスタマーサクセス、AIエンジニア、Webエンジニア、各ポジションがそれぞれの領域で存分に能力を発揮しつつ、何がするとよくなるかという議論を真摯に重ねて価値を作り出しています。
この記事を読んでスカイディスクという会社やそこで働く私達に興味を持っていただけた方はぜひお問い合わせください。
この記事が気に入ったらサポートをしてみませんか？