この記事はGoodpatch Advent Calendar 2017の19日目の記事です。
私の開発チームでは現在、数十人規模で開発を進めているのですが、エンジニアが増員される中でどのようなインプットがあると、スムーズにプロジェクトに入ってもらえるかを色々と考えてました。今回は新たにエンジニアが加わる際に考慮しておくと良さそうな事を書きたいと思います。
ちなみに私はフロントエンドエンジニアなので、フロントエンド＆Webアプリケーション開発に多少寄った内容になってしまう事をご了承ください。
サービス理解
まずは何と言ってもサービス・プロダクトの説明が必要です。
例えば、以下のような情報をもとに、対話形式で説明していくと理解してもらいやすいかと思います。
- サービスのコンセプト、提供価値
- サービスの歴史
- ターゲットユーザー
- KGI・KPI
- 競合他社、競合サービス
- 開発ロードマップ
- 開発体制、組織図
仕様・規約の共有
ドキュメントをしっかり作成している開発現場は少ないかもしれませんが、もし以下の中で準備できるものがあれば、”開発まとめ”ページを作成して各情報へのリンクを貼っておくと分かりやすいと思います。
- システム構成図
- サイトマップ
- 対応環境（ブラウザ、機種、バージョン）
- アプリケーション実行環境
- 画面設計書
- API仕様書
- ER図
- テスト仕様書、テストコード
- コーディングガイドライン
- 利用フレームワーク、ライブラリ
仕様については大枠だけを伝えて、細かい部分は開発に入った後に徐々に共有していく形でも良いかもしれません。
開発準備
まずは開発で利用しているツールを共有して、ソフトウェアのインストールやアカウントの作成を行ってもらう必要があります。例えば、以下のようなものです。
- 開発ツール（Editor、Gitなど）
- デザインツール（Sketch, Photoshopなど）
- コミュニケーションツール（Slack, Chatworkなど）
- 課題管理（Backlogなど）
あとは、GitリポジトリのREADMEに環境構築手順を書いておいて、ローカルで動作確認できるようにしておけると良いかと思います。
コードレビュー
コードレビューは重要だと思いますが、Linterなどを入れていると細かい部分は気にしないで済むので楽になります。コードレビューはPullRequestを受け取って、レビューする形が一般的だと思います。
レビューのタイミングについて、最初の方は特にWIP形式の方がお互い楽かもしれません。WIP形式のPullRequestについては以下の記事が参考になります。
Work in ProgressパターンによるPull Requestを利用した開発フロー - Qiita
また、過去のコードレビュー指摘一覧のようなものがあると、同じようなミスが発生しにくくなるかもしれません。
その他オプション
もし戦力化するまでに時間がかかりそうであれば、以下のような施策を打つのもアリだと思います。
- 勉強会
- 開発チュートリアル
- ペアプログラミング
また、新しく参加したメンバーは最初は遠慮しがちなので、しばらくしたらKPTや1on1など振り返りの時間を持つとコミュニケーションが促進されると思います。
今回は私の思いつく範疇で書き出してみましたが、もっと良くできる部分があると思いますので、アドバイス頂けると幸いです。