前回の記事で、案件面談ではメンバーの稼働形態を確認しておくべきだった、という話を書きました。
ただ、面談で聞けることには限りがあります。30分〜1時間の面談で、チームの実際の動き方まで把握するのは難しい。結局、残りは参画してから自分で確かめるしかありません。
この記事では、業務委託で既存チームに参画したとき、最初の2週間で何をしたかを書きます。私はその現場で4年ほど働き続けているので、「あのとき何が効いていて、何が足りなかったか」を今の目線で振り返ってみたいと思います。
前提：4年前、Laravelの案件への途中参画
私はフリーランスのフロントエンドエンジニアで、ここ4年は同じ業務委託先で働いています。今はNext.jsやTypeScriptを使ったWebアプリケーション開発と、WordPressのWebサイトの保守・運用が中心です。
ただ、参画当初に担当したのはLaravelで作られたWebアプリケーションでした。それまでWebサイト制作を長くやってきた私にとって、アプリケーション開発に本格的に関わるのはこれが初めてです。
プロダクトは新規立ち上げではなく、外部ベンダーが開発したものを引き継ぐ形でした。この記事で振り返るのは、そのLaravelの案件に入ってからの最初の2週間です。
また、4年いる間に、後から入ってくるメンバーを受け入れる側にもなりました。この記事には、その両方の立場から見えたことが混ざっています。
1. 環境構築でつまずいた箇所を、そのまま最初のPRにする
参画初日にやったのは開発環境の構築です。READMEには詳しく記載がありましたが、一部は最新の状況と異なっていて、何か所かで躓きました。当時はChatGPTが公開される直前で、AIに気軽に質問できる環境もありませんでした。
さらに「環境構築で躓いていると思われたくない」という謎のプライドもあって、誰にも聞かずにGoogle検索を頼りに何とか環境を作っていきました。今思えば、素直に聞いた方がずっと早かったはずです。
止まった箇所は、解決方法と一緒にメモしておき、READMEの修正として最初のプルリクエストにしました。
理由は2つあります。ひとつは、次に入ってくる人が同じ場所で止まらないため。もうひとつは、コードに触る前に「このチームのPRはどう出して、誰がどのくらいでレビューするのか」を確認できるためです。ドキュメントの修正なら、レビューで揉めることもほとんどありません。
その後に入ったメンバーはREADMEを頼りに環境構築をスムーズに行えていたので、面倒くさがらずにやっておいてよかったなと思いました。
2. 誰が、いつ稼働しているかを把握する
前回の記事の続きになりますが、ここは面談で確認しきれなかった部分を埋める作業です。
Slackの発言時間帯やGitHubのコミット時刻を見ていると、メンバーごとの稼働パターンが見えてきます。
副業で参画しているバックエンドエンジニアは、Slackには日中もオンラインでしたが、やはり本業の時間帯ということもあり、レスポンスにはラグがありました。
一方で、毎週の定例MTGは日中にコミュニケーションを取れる貴重な機会です。その場でレビューの依頼を口頭でもお願いしたり、すでにお願いしているものをリマインドしたりして、可能な限りスムーズに開発が進むよう心がけていました。
3. 小さいPRを、早めに出す
最初の機能開発は、なるべく小さいタスクから始めました。
例えば、タイポの修正や、引数・戻り値への型宣言の追加などです。
小さいPRを出すと、レビューで何を指摘されるかが分かります。命名、ディレクトリ構成、テストの有無、コミットの粒度。コードを読むだけでは分からない「このチームが気にするポイント」は、レビューコメントに一番よく表れます。
見立てを外したこと
正直に書くと、最初の2週間を全部うまくやれたわけではありません。
環境構築のときもそうでしたが、当時の私は「よく見られたい」という気持ちが強すぎました。Webサイト制作しか経験のない私を、アプリケーション開発の要員として契約してくれた現場です。何とか長く続けたいと躍起になっていました。
その焦りが一番悪い形で出たのが見積もりです。実力をアピールしたくて完了予定日を早めに見積もり、結果的に予定日を後ろ倒しにしてしまいました。プロダクト理解が浅い参画当初こそ、余裕を持って見積もるべきでした。
業務委託は成果で評価されるので、その焦り自体は自然なものだと思います。ただ、予定日を後ろ倒しにすると、そのタスクを前提にしていた他のメンバーの予定まで組み直させることになります。
受け入れる側になってから気づいたこともあります。このチームには専業のメンバーがおらず、複数の現場を掛け持ちしている人も多い。途中参画した人が止まる原因の一部は、受け入れる側の余裕のなさにあります。それは誰かが悪いというより、構造の問題です。
最初から成果を出しにいく判断もある
ここまで書いてきた進め方は、慎重な方だと思います。
一方で、初週から機能開発で成果を出しにいく方が合理的な現場もあります。人手が足りず、とにかく手を動かしてほしいと言われているチーム。契約期間が短く、2週間を把握に使う余裕がない案件。そういう場面では、READMEを直している場合ではないかもしれません。
私の場合は結果的に4年続く現場になりましたが、参画した時点ではそれは分かりませんでした。どちらが正解というより、参画先が何を求めているかで決まる話です。
まとめ
4年経って振り返ると、最初の2週間でやったことは、どれも「どこで止まるか」を先に把握する作業でした。
環境構築で止まる場所、レビュー待ちで止まる時間、質問が返ってこなくて止まる時間。コードを書く速さより、この「止まる時間」をどれだけ減らせるかの方が、参画初期の成果には効いてきます。
もしこれから業務委託で参画するなら、最初の2週間の目標を「成果を出す」ではなく「一人で止まらずに進める状態を作る」に置いてみてください。
コメント