10人ほどで基幹システムの刷新を進めたとき、最初に悩んだのが役割分担でした。
同じエンジニアでも、設計を考えるのが得意な人、実装に入ると速い人、全体のつながりを見るのが得意な人では、任せ方が違います。人数だけを見て均等に割ればよいわけではありません。
そこで私は、肩書よりも普段の仕事ぶりを見ながら担当を決めていきました。ただ、それだけではうまくいかなかった経験もあります。誰が何を担当するかは決めたのに、「どこまで自分で決めてよいのか」が曖昧で、設計側と実装側の間に手戻りが出たからです。
それ以来、役割分担では得意分野を見るだけでなく、判断範囲、相談相手、完了条件、次工程へ渡す情報まで確認するようになりました。
10人の現場では得意分野を見て役割を決めた
基幹システムの刷新を10名ほどで進めていたとき、メンバーを見ていると得意なことがかなり違っていました。
設計を考えるときに抜けが少ない人もいれば、仕様が決まってからの実装がとても速い人もいます。細かなところによく気づく人もいれば、全体への影響を見るのが得意な人もいました。
そこで、単純に「10人いるから10等分」とはせず、その人が力を出しやすい仕事へ寄せていきました。
設計が得意な担当者には、仕様を整理し、実装側が迷わず進められる形にする仕事を任せます。実装が速い担当者には、決まった内容を確実に形にしていく部分を多く任せました。
私は一つの機能を細かく作り込むというより、機能同士のつながりや全体の進み具合、後から問題になりそうなところを見る役割でした。
最初から「この人は設計担当」「この人は実装担当」と肩書だけで決めたわけではありません。実際に一緒に仕事をしていると、「この人に設計を任せると話が早い」「この人は実装へ入ると一気に進む」と分かってくることがありますよね。
そうした普段の仕事ぶりも見ながら、少しずつ役割を合わせていきました。一人に何でも任せるより、それぞれの得意な部分を組み合わせた方が、結果として進めやすかったです。
担当だけ決めたら責任の境界で手戻りした
ただ、得意な人へ仕事を任せれば、それだけで役割分担がうまくいくわけではありませんでした。
一度、設計担当と実装担当を分けたものの、「設計側はどこまで決めるのか」「実装側はどこから自分で判断してよいのか」という境界を、はっきりさせないまま進めたことがあります。
担当そのものは決まっています。それでも実装中に仕様の解釈で迷ったとき、自分で判断して進めてよいのか、設計側へ戻した方がよいのかが曖昧でした。
結果として、実装側では「この解釈でよいだろう」と進め、設計側では別の前提を持っていた、というずれが起きました。後から認識の違いが分かり、一部を戻して修正することになります。
そのとき、「担当者を決めたから大丈夫」と考えていたのが甘かったんですね。
誰が担当するかと、その人がどこまで判断してよいかは別に決める必要があります。
設計担当なら、どこまで決めれば次へ渡してよいのか。実装担当なら、どの範囲は自分で判断し、どこから先は設計へ確認するのか。
ここが曖昧だと、せっかく得意分野に合わせても、途中で止まったり、後から戻ったりします。この失敗があってから、私は担当名だけを書いて役割分担が終わったとは考えなくなりました。
役割分担では担当以外の4点も確認する
今は、誰に何を任せるかを決めた後に、少なくとも次の4点を確認します。
- どこまで自分で判断してよいのか
- 判断に迷ったときは誰へ相談するのか
- どの状態になれば、その担当は完了なのか
- 次工程へ何を伝えて渡すのか
特に大事だと思っているのが、判断範囲です。
たとえば実装中に小さな仕様変更が必要になったとき、すべて設計担当へ確認していたら、そのたびに仕事が止まります。反対に、「担当だから自由に変えてよい」としてしまうと、別の機能へ影響する変更まで進めてしまうかもしれません。
だから、「ここまでは担当者判断」「ここから先は設計へ相談」といった境界を、先に合わせておきます。
相談相手も同じです。問題が起きてから「これは誰に聞けばいいんだ」と探し始めるより、迷ったときに最初に誰へ聞くかが分かっていた方が動きやすくなります。
また、私は「完了」の考え方も確認するようになりました。
設計担当が「設計書を書いたから完了」と思っていても、実装側が必要な情報を読み取れなければ、仕事としてはまだ渡せていません。次工程の人がそのまま仕事を始められる状態か、必要な情報や注意点まで渡っているかを見るようにしています。
役割分担を決めるとき、今の私は「担当者の名前」だけではなく、その横にこの4点まで書けるかを見ます。
異なる強みを組み合わせた方が進めやすかった
10人ほどのチームで仕事をしていると、「この人一人に任せれば早い」と思う場面もあります。実際、設計も実装もできる優秀な人はいます。
ただ、その人に仕事が集まりすぎると、判断も質問も全部そこへ集中します。周りの人は待つ時間が増え、その人が忙しくなるほどチーム全体も止まりやすくなります。
私が経験した現場では、設計が得意な人、実装が速い人、全体のつながりを見る人が、それぞれ違う強みを持っていました。
一人の人に多くを背負わせるより、「この人はここ」「ここからはこの人」と強みをつないだ方が進めやすかったです。
もちろん、最初から全員の得意分野が分かるわけではありません。任せてみたら、思っていたより別の仕事の方が向いていた、ということもあります。
だから私は、最初に決めた役割を固定しすぎず、実際の仕事ぶりを見ながら調整するようにしています。ただ、役割を変えるときも「何を担当するか」だけでは足りません。
その人がどこまで判断し、迷ったら誰に相談し、何をもって完了とするのか。そこまで合わせておかないと、担当だけを入れ替えても同じところでつまずきます。
10人の現場で一度手戻りを経験してから、私はそこまで確認して初めて「役割を決めた」と考えるようになりました。
まとめ
チーム開発の役割分担では、肩書や人数だけで均等に仕事を割るより、それぞれが何を得意としているかを見ながら担当を決める方が進めやすくなります。
ただ、得意な仕事を任せるだけでは足りません。
- 担当する仕事
- 自分で判断してよい範囲
- 迷ったときの相談相手
- 完了とする状態
- 次工程へ渡す情報
私自身、設計担当と実装担当を分けただけで安心し、責任の境界が曖昧なまま進めて手戻りしたことがあります。
それ以来、「誰に任せるか」と同じくらい、「どこまで任せるか」を見るようになりました。一人の優秀さに頼るより、違う得意分野をどうつなぐかまで考える方が、チームでは進めやすいと思っています。
コメント