途中からプロジェクトに参画した人へ最初に共有しておくと良さそうな3種類の情報
プロジェクトに参画するパターンとしては
1. プロジェクトの立ち上げ当初から参画する
2. 途中から参画する
の2つの場合がありますが、どちらのパターンで参画するかによって、プロジェクトに関する情報のキャッチアップのしやすさは異なるなぁと思います。
最初の1~2年は1のパターンで入る事が多かったのですが、最近は出向のような形で他のプロジェクトに入ることもあったり、別の会社で副業する機会があったりと2のパターンでプロジェクトに参画することが続いていて、立場が変わると
「こういう情報って最初に知っておけるととても楽なんだけどなぁ」
「こういう情報がまとまっているおかげでとても助かったなぁ」
と気づけたことがいくつかあったので、3種類に分けてまとめてみようと思います。
（1のパターンで気づいたことも書いています）
1. サービス自体に関すること
- サービスの概要・目的
- ユーザーロール
- リリーススケジュール
サービスの概要・目的
細かい仕様については追々共有してもらうとして、つくろうとしているサービスがどんなものなのか、そのサービスの解決したい目的は何なのかがわかると、とっかかりとしてとてもやりやすい様に思います。
背景やユーザー像が見えると開発をすすめるモチベーションにつながったりもしますし。
ユーザーロール
前提条件なのに自分にとっては当たり前になりすぎて説明することを忘れてしまい、話を進めていく中で「そんなユーザーがいるの？」と混乱を招いてしまった経験があります。
存在するユーザーロール、それぞれのユーザーの権限の範囲を先に説明しておくと、ソースコードだけでなく資料を探す作業が捗ったり、MTGで話がわからなくなったりすることもないのでとても大事だなぁと思います。
リリーススケジュール
これに関してはほぼ確実に共有される事が多いですが、個人的には「結局いつリリースするんだっけ？」と忘れてしまいそうになることがあるので、テキストや表でまとめておいてもらえると助かるなぁと思います。
2. 開発環境に関すること
言語・フレームワーク（バージョン含む）
自分が普段から開発しているものだとうっかり説明しそびれそうですが、忘れず軽く説明しておくと親切かなと思います。
設計の全体像
どこに何が書いてあるのかを調べる作業は結構たいへんだなぁ...と思うので、知っている人がざっくり説明してくれるととても助かります。（ディレクトリ構成だけでも）
なお、フレームワークもチームによってその利用方法はまちまち（一部しか使っていなかったり、それぞれの役割の使い分けが異なっていたり）だったり、馴染みがない人にはとっつきにくかったりもするので同様です。
とはいえ、説明する側も毎回話すのは結構たいへんなので、ドキュメント化したものを読んでもらって、わからないところとかを聞いてもらうのがいいかも。
ドキュメントやWikiのありか
上記のような情報は開発の助けになるので、一覧化されているページがあるととても見やすいです。
また、分類や階層に分けて管理されていると新参者にも情報が探しやすく、とても嬉しいです。
ツール
- タスク管理ツール
- 仕様書作成ツール
- デザイン確認ツール
などはプロジェクトやチームによって使っているものが異なっていることも多く、しかも似ているものがあったりしてややこしいので、それぞれの違いを教えてもらえると良かったりします。
仮想環境の有無
仮想環境があるのか、ある場合はどういうものが用意されているのか（Vagrant、Docker）など。
仮想環境のセットアップに四苦八苦してなかなかスムーズに進められない...ということもあるので、セットアップ方法や分かる範囲でのトラブルシューティングをまとめておいてもらえるととても助かります。
テスト環境/ビルドコマンド/デバッグ方法
これらも開発には必要な情報なので必ず。
こちらもドキュメントとしてまとめてもらえていると嬉しいです。
バージョン管理・運用ルール
- Gitのホスティングサービスは何をつかっているのか
- PRの運用ルールはあるのか
なども教えてもらえると嬉しいです。
gitコマンドが使えればだいたいどのホスティングサービスを使っていても問題ないようには思いますが、自分が使ったことのあるもの以外は名前すら知らなかったりするので。
また、PRのコメントの書き方やレビューの方針、マージャーなどについても教えてもらえると嬉しいです。
ちなみにPRの運用についてはルールがドキュメント化されていると出す側もわかりやすいし、マージャーになった際にもPRのフォーマットが定まっているとレビューしやすくていいなぁと個人的には思います。
3. 体制に関すること
- 連絡手段・稼働時間
- 開発手法・構成
連絡手段・稼働時間
チームによってSlackやchatworkなど使うツールもバラバラですが、使い方も微妙に違ったりします。なので、例えばSlackだとチャンネルごとの使い分けや、緊急時の連絡先については教えてもらいたいなぁと思います。
また、同じプロジェクトでもメンバーによっては違う時間に稼働していることもあるので、稼働時間も事前に把握できているとありがたいことが多いです。
（返信が来なくても「明日には返信してもらえるだろうな」といった予測を立てることができたりする）
開発手法・構成
ウォーターフォールとスクラムではメンバーの動き方も異なりますし、明確な開発手法をとっていなくても誰が何を握っているか、誰に何を聞けばいいのかといったことがわかるほうが圧倒的に仕事は進めやすいと思います。
入ってから感じ取っていく...という場合もありますが、可能であれば最初にどんなメンバーがいて、それぞれの役割でどんな体制かなどについて説明してもらえると嬉しいなと思います。
最後に
プロジェクトに途中から参画する経験を通して、今までは気づくことのできなかった「情報をちゃんと伝えてあげないと、途中から入ってきた人が苦労することもあるんだよ」ということに気づくことができたので、とても良い勉強になったなぁと思います。
今後はここにまとめた情報を伝え忘れないようにして、途中から入った人が早く開発作業に集中できるようにしていきたいと思います。
