オンボーディングファイル作成のススメ

Last updated at 2022-04-23Posted at 2021-10-06

ISSUEに移動しました。

関連情報を発信していますのでご購読お願いします。

皆さんは、新しい会社で開発を始めた時開発環境の構築に時間がかかってうまくスタートをきれなかったり、
他の人がうまくスタートをきれなかった人をみたことはありませんか。

私は、あります。
私自身、掛け持ちで仕事をしていて新しく副業で入った企業先でgithubに招待してもらってその後何も作業せず地蔵状態になったことがあります。(これはちょっと極端ですが)

別の時には同時期に入ったエンジニアが途中で離脱してしまうケースもありました。
これらの原因は開発参加初期に受け入れ体制が整っていないことが原因です。

特にリモートで副業するエンジニアにとっては、
ちょっとでも壁があるとすぐに離脱してしまいます。

しっかりメンター的な立場の人がいれば問題ありませんが、
スタートアップにはそこまでリソースをさく余裕はありません。(スタートアップ以外も)

そこで、オンボーディングファイルを作り受け入れを半自動化することでこの問題を解決しましょう。というお話をします。

オンボーディングファイルとは新しく参加してきた人が1prを作ってmergeできるようにするためのもの

dockerコマンド打って、localhostを立ち上げるだけでなく、サービスの構成やビジネスドメイン、サービスウォークスルーの動画まで用意します。
このサービスはなぜ世の中に必要で、業界はどこで、登場人物は誰かまで把握できます。システムだけじゃなく、システムを利用する顧客の顔・声まで理解するとエンジニアのパフォーマンスは高くなります(多分)

以下はオンボーディングファイルのサンプルです。

■ トップ

■ サービス構成について

■ ウォークスルー

サンプルはこちら

なぜオンボーディングファイルを作ろうと思ったか？

自分で立ち上げたサービスの初期のコンセプトがissue単位で仕事ができることだったのですが、
受け入れ体制が整っていないとイニシャルコストが高いのでコスパが悪くなると言われその対策として用意したのがきっかけです。

実際に使ってもらった人の声

実際にISSUEを導入いただいてる企業様にはオンボーディングファイルを作成させていただいており、
ISSUE経由で参加しているエンジニアさんに使ってもらってます。

オンボーディングファイルを導入するメリット1: 受け入れコストが下がる

こちらはいうまでもないですが、
情報を集約することによって新しく入った人が自ら作業を行える状態になります。

オンボーディングファイルを導入するメリット2: オンボーディングファイルを渡して、質問数や環境構築の時間を他の人と比較し、能力を図ることができる

オンボーディングファイルには環境構築や開発に参加するための情報が揃っています。
それにも関わらず、ファイルに書いてあることを質問してしまうと読解力がなかったり、あまり自分でインプットをせず他者にきいてしまう人ととなります。それはコミュニケーションコストを高めることにつながり、チームのパフォーマンスを落とします。