はじめに
こんにちは、エンジニアリングマネージャーの八巻(@hachimaki37)です。
今回の記事では、Slackワークフロー(以下、ワークフローと呼ぶ)を活用して開発チームにおけるオンボーディングプロセスを効率化した取り組みを紹介します。前回の記事「開発者体験サーベイで始める可視化とカイゼン(続編)」では、開発者体験の可視化について触れました。本記事では、その続編として、可視化を通じて明らかになったチームの課題を解決するための具体的な改善策に焦点を当てます。
前半では、オンボーディングプロセスに感じていた課題感と具体的な取り組み内容を紹介し、後半ではその経緯やチーム全体で得られた成果について振り返ります。
注記:
前回までの記事の内容についてはあまり触れておりません。そのため、以下をお読みいただけると内容の解像度が高くなるかと思います。
目次
前提
当社では、新卒・中途を問わず、入社初日から研修を提供しています。この研修では、フォースタートアップスで働く上で基本的な知識を身につける内容が中心です。一方、業務に直結するオンボーディングは、各配属先で行われます。本記事では、私が所属するグループ(以下、チームと呼ぶ)におけるチームのオンボーディングに焦点を当てています。
オンボーディングにおける課題
オンボーディングのプロセスには、既存メンバーと新人メンバー双方に課題が存在すると考えています。
既存メンバーの視点
例えば、
- 教育とサポートの負担:新人メンバーのサポートに時間を割くことで、自身の業務が圧迫される。
- 情報伝達のズレ: 社内プロセスや技術的仕様の伝達が非効率。
- 進捗の不透明さ:新人メンバーの困りごとや詰まりどころがわかりづらい。
新人メンバーの視点
例えば、
- 環境やツールへの習熟:新しい開発環境やツールの理解に時間がかかる。
- コードベースの理解:複雑なコードやアーキテクチャへの適応に時間がかかる。
- サポート不足:フィードバック機会の少なさによる不安や不透明さ。
- 心理的安全性:既存メンバーへの聞きづらさ、焦りや不安。
共通の課題
例えば、
- チーム文化への適応:新人メンバーがチーム文化に馴染むプロセスのサポート不足。
- コミュニケーションの質と頻度:効率的な情報共有と疑問解消の促進。
解決策と期待できる効果
これら課題を解決するために、ワークフローを導入してオンボーディングプロセスを自動化しました。すべての課題を完全に解決できるわけではありませんが、この仕組みにより、以下のような効果が期待できます。
汎用性を高め、属人化を解消
- チームの資産となる仕組みを構築
- レバレッジを効かせた効率的なオンボーディングを実現
適切なタイミングでの情報提供
- 新人メンバーの早期戦力化を促進
- オンボーディングプロセスのリードタイムを効率化
- プロダクトや業務フローの理解を、新人メンバーのペースで進められる環境を提供
- ファーストリリースの早期実現
既存メンバーの負担軽減
- 教育やサポート業務の効率化
具体的な取り組み
ワークフローを使ったオンボーディングの仕組みは至ってシンプルです。下記はイメージ図です。新人メンバーと既存メンバーとの間にワークフローが入り、橋渡しの役目を担っています。
簡単に紹介いたします。
期待すること
ワークフローが完了する時点で、チームでは下記のことを期待しています。
- 開発環境構築が完了していること
- チームの開発プロセスを理解していること
- 各種ルールのインプットを終えていること
上記が達成できていれば、チームでの開発を円滑に進めるための基本的なスキルを習得していると考えられるからです。
概要
ワークフローを活用し、主要なプロセスを自動化しました。これまで、オンボーディングの各工程が完了するごとに既存メンバーがサポートを行い、次の作業を指示していました。そのため、新人メンバーが学ぶべき情報やドキュメントを適切なタイミングでワークフローが提供できるようにしました。
仕組み
- 誰かが特定のチャンネルに参加した時にワークフローを開始する
- ボタン操作を活用して、次のステップへ進行する
- よって、各ステップは新人メンバーおよび既存メンバーのボタン操作により自動通知され、進行していく
構成
ワークフローは全13ステップで構成しており、オンボーディングの目的や期待値、開発環境の構築サポートなど、インプットが必要なドキュメントに加え、3つの演習が含まれています。ステップの一部を紹介します。
- チャンネルの新メンバーの自己紹介
- オンボーディングの目的や期待値について
- おおよそのタイムラインについて
- アカウントの作成依頼
- 開発環境の構築サポートについて
- プロダクト情報について
- チームの文化について
- コーディングルールについて
- 演習
- ブランチ戦略:GitHub Flow
- Commitルール:Emoji Prefix
- デプロイ手順:検証環境へのデプロイ方法
実施例
ワークフローの流れ
誰かがチャンネルに参加した時に開始する
- 新人メンバーがチームの開発チャンネルに追加されることで、ワークフローが開始。
新人メンバーのアクション
- 指示されたタスクを完了すると次のステップが進行。
既存メンバーのアクション
- レビューや指示されたタスクを完了し、ボタンをクリックすると次のステップが進行。
基本この繰り返し
- 新人メンバーのアクションに対して、必要に応じて既存メンバーがアクションすることで、段階的にオンボーディングが進行する。
詳細に説明いたします。
1. 誰かがチャンネルに参加した時に開始する
チームの開発チャンネルに追加された時に「チャンネルに参加したユーザー」にメッセージが送信されます。そこからオンボーディングのワークフローが始まります。
実際にチームの開発チャンネルに追加された時に、参加したユーザーにメッセージが送信されます。
2. 新人メンバーのアクション
次のステップでは、ステップのフォームを使い「情報をフォームで収集する」から「チャンネルに参加した新メンバーの自己紹介」を行っていただき、既存メンバーに対して周知するようにしています。
3. 既存メンバーのアクション
上記キャプチャーのように既存メンバーに対してボタンクリックを促し、「確認しました!ありがとうございます🎊」ボタンをクリックしてもらうことで、次のステップが進行します。
4. ワークフロー完了後
新人メンバーが全てのステップを完了すると、ワークフローから既存メンバーに対してその旨がお知らせされます。
このように、新人メンバーと既存メンバー間のコミュニケーションフローにワークフローを組み込むことで、適切なタイミングで情報を提供し、スムーズなオンボーディングを実現しています。
経緯
後半は、開発者体験サーベイで始める可視化とカイゼン(続編)で可視化された課題について少し振り返ります。
開発者体験におけるチームで浮き彫りになった課題は、「フロー状態」と「認知負荷」の2つでした。特に、チーム全体の最適化を図るには「認知負荷」の改善が鍵であると判断しました。
これらの中でも特に 「プロジェクトのソースコードを理解するためのドキュメントは十分である」 を最優先で改善することを決めました。その理由は、新人メンバーが複数名チームに参画する予定があったため、チーム全体の開発生産性を高めるためには、新人メンバーの早期立ち上がりが不可欠と判断したためです。
ドキュメントを充実させることは重要なのですが、ドキュメントだけがあっても上記の目的の達成には課題が残ります。 そこで、ドキュメントの充実に加えて、既存メンバー、新人メンバーにとって、より良い開発者体験を構築できるようオンボーディングプロセスの効率化に取り組むことを決めました。
導入後のフィードバック
実際に5名の新人メンバーに今回紹介したワークフローを使ってオンボーディングを進めていただきました。その結果、以下のようなフィードバックが寄せられました。一部を紹介いたします。
新人メンバーの声
- ワークフローがあることで、次にやることが明確になった。
- 演習を通じて開発の進め方を学ぶことができてよかった。
- ドキュメントに不十分な部分があり、既存メンバーに質問する場面もあった。
- ワークフローの前段でシステム全体の概要が説明されていると、より理解しやすくなりそう。
既存メンバーの声
- オンボーディングの負担が軽減された。
- 自分の業務に集中できる時間が増えた。
- 新人メンバーのサポートが体系化され、効率的に進められるようになった。
貴重なご意見をいただき、よかった点や改善点をしっかりと把握することができました。これを踏まえ、さらなる改善を進め、チームが継続的に成長できる仕組みを構築していきたいと思います。
その第一歩として、実際に活用いただいた方々と改善ミーティングを行い、ワークフローの構成や内容の見直し、補完作業、ドキュメントの充実化に取り組んでおります。
具体的な変化
昨年10月頃から、ワークフローを活用したオンボーディングを導入しています。従来は、入社後に最初のプルリクエストを作成するまでに約2週間かかっていましたが、Findy Team+のデータを見ると、現在では約1週間ほどに短縮されています。
チームで日々改善を重ねているため、ワークフロー導入だけがこの変化の要因とは言い切れませんが、少なからず効果はあったと考えています。
あとがき
本記事では、ワークフローを活用したオンボーディングの効率化に関する取り組みを紹介しました。この仕組みを導入することで、チーム全体の生産性向上や開発者体験、新人メンバーの早期戦力化に向けた確かな一歩を踏み出せたと感じています。
次回の記事では、開発者体験のこれまでの改善活動を振り返り、開発者体験サーベイの結果を第1回と第2回とで比較します。その数値の変化を分析し、そこから得られた学びや気づきを共有したいと思います。