業務委託の案件面談で、チームメンバーの稼働形態（専業／副業）を確認しなかった。結果、参画後にレビュー待ちでプルリクエストが滞留する状況になり、自分の稼働にも影響が出た。実体験から聞くべきだった質問を整理する。
業務委託で参画する前の面談で、チームメンバーがどんな稼働形態で構成されているかを聞かなかった。
契約形態や技術スタックは確認していたが、メンバー各人が専業か副業かについては気にも留めておらず、参画前に質問するという発想自体がなかった。結果、参画してから、チームがエンジニア全員副業で構成されており、プルリクエストを出してもレビューされるまでに時間を要するという状況になった。
聞くべきだったのは、チームメンバーがどのくらいの稼働時間・稼働形態（専業／副業）で関わっているか。
この記事では、実際にどんな質問をして、何を聞き漏らし、参画後にどんなギャップが生まれたかを振り返りながら、次に面談を受けるなら聞くようにしている質問をまとめる。
参画前の面談で、実際に何を聞いていたか
参画前の面談では、以下のことについて確認していた。
- 単価
- 稼働時間
- 契約形態
- 使用技術スタック
- メンバー構成・職種
単価や稼働時間、契約形態は業務委託である以上外せない項目として、ほぼ毎回聞いていた。技術スタックについても、これまでの経験を活かせるかどうかの見極めに直結するため、具体的な構成まで踏み込んで質問していた。メンバー構成・職種も、PdMやデザイナー、エンジニアが何人いるかは事前に聞いていて、体制図としては把握しているつもりだった。
このときは、この5つを押さえておけば判断材料として十分だと感じていた。メンバーの職種や人数は聞けていたので、「聞き漏らした」という自覚すらなかった。専業か副業かという切り口は、そもそも質問リストの中に存在していなかった。
参画してから分かったギャップ
参画後、PdMやデザイナーはプロパー（正社員）だったが、同じエンジニアであるメンバーの一人（以下、Zさんとする）は別の会社に正社員として勤めながら、このプロジェクトには副業として関わっていることが分かった。
副業であること自体は珍しいことではないし、それ自体が問題だとは思っていない。ただ、副業であれば稼働時間が専業より短くなるのは当然で、Zさんもフルタイムで会社員をしながらの参画だった。日中まったく連絡が取れないわけではなかったが、コードレビューは1週間に1度程度のペースで消化されることが多かった。
これは、Zさんの対応が悪かったという話ではない。本業を持ちながら副業としてレビューの時間を確保している以上、そのペースになるのは構造的に自然なことだ。ただ結果として、出したプルリクエストがレビュー待ちのまま数日から1週間ほど滞留し、次のissueに着手しづらい状態が発生した。実装が前段の設計判断に依存している場面では特に身動きが取れず、自分の稼働にも影響が出ることがあった。
正直に言うと、事前にメンバー構成や人数を聞けていたことで「把握できている」という感覚になり、そこで思考を止めてしまっていたのが実際のところだ。人数や職種は聞いていたのに、その人たちがどんな稼働形態で関わっているかまでは踏み込まなかった。情報を取りに行ったつもりで、実は取りに行けていなかった典型だったと思う。
稼働形態とは別に、もう一つ参画してから分かったことがある。別の案件では、参画先がそもそもGitHubを使っていなかった。もともと参画先の中にも「GitHubを使わなければ」という気持ちはあったようで、実際に自分がGitHubを使い始めても咎められることはなく、他のメンバーにも徐々に使い方を覚えてもらいながら、導入自体は幸い受け入れてもらえた。結果としてはうまくいったが、これも面談の時点でツールやレビューの運用について聞いていれば、参画してから手探りで進める必要はなかった話だ。
ただ、この時はとにかく仕事が欲しい時期で、開発体制がどうこうより何より仕事の獲得が優先だったのも事実だ。フリーランスあるあるかな？
今なら聞く質問
この経験以降、チーム構成を聞くときは、人数や職種に加えて、専業か副業かの割合まで聞くようにしている。特に自分と直接やり取りが発生するポジション、たとえばレビューをしてもらうエンジニアや確認を仰ぐデザイナーが専業か副業かは、稼働のリズムに直結するので優先して聞く。
聞き方としては、「メンバーの中に副業の方はいらっしゃいますか」とストレートに聞くこともあれば、稼働時間の話の延長で「皆さんはこの案件に専念されているんですか」と聞くこともある。答えにくそうな空気があれば無理に深追いはしないが、少なくとも一度は質問リストに入れるようにしている。
加えて、そもそもレビューする文化があるかどうかも念のため確認しておくといい。信じがたいかもしれないが、レビュー文化がない、それ以前にGitHubを使っていないという現場もいまだにある。私はWebアプリケーション開発だけでなくWebサイト制作も行っているが、サイト制作の現場にはGitHubを使っていないところがまだ珍しくない。だから今は、面談の段階で「GitHubなどのバージョン管理は使われていますか」と聞くようにしている。
聞かなくてもいいという考え方もある
一般的には、面談のたびにここまで踏み込んで聞くべきかというと、そうとも言い切れないという見方もできる。短期のスポット対応が中心の契約であれば、メンバーの稼働形態が自分の作業に与える影響は小さく、聞く実益は薄いという考え方もあるだろう。また、限られた面談時間で体制の内情まで踏み込むと、聞き方によっては相手を詮索しているような印象を与えかねない、という懸念も分からなくはない。
ただ、自分の稼働が滞ることは、そのまま売り上げ、ひいては生活に響くことと同義だ。だから自分は可能な限り聞くようにしていて、面談の場で聞けなかった場合は、その後のやりとりの中で追加で確認するようにしている。
まとめ
面談で全部を聞き出すことは現実的に無理でも、参画後に「聞いておけばよかった」と思ったことをリストに残しておくと、次の面談の精度が上がる。今回の場合、それは「メンバー構成」ではなく「メンバーの稼働形態」だった。
コメント