はじめに
あじ太郎が今までに入った開発チームは、事業会社に所属していたときの自社システムでもお客様のシステムでも、たいていはメインで担当する機能やタスクの範囲などがある程度決まっていることが多かったです。
もしくは、エンジニアが少ないので全部担当！みたいな感じでした。
その中で、担当機能やタスクアサインを柔軟にしていた開発チームに入ったことがありました。
今回は、一般的な話と、その開発チームでのあじ太郎の気づきを語ってみたいと思います。
一般的に各開発者に対して担当する機能や作業内容を決める／決めないとどんなメリット、デメリットがあるか？
まずは一般的なメリット、デメリットを確認しておきます。
（ここではかなり簡単な話にしていますが、実務では担当範囲の境目はグラデーションがかかっているし、そもそもこんなに単純ではないと思いますが、あくまで一般的にはということで）
・専属で担当する機能や作業内容を決める場合
例えば「Aさんはユーザー管理機能、Bさんは決済機能」みたいに専属の担当を決めるやり方です。
作業内容についても仕様調整する人、プログラムする人みたいに分かれている開発チームもあるのではないでしょうか。
メリットは、担当する機能やタスクに詳しくなり専門性が高まりやすいこと。
担当範囲については作業が速い。
エンジニアの希望と担当範囲が一致した場合は愛着がわきやすいといった効果も。
不具合が出たときも該当箇所に詳しい担当者だと対応がスムーズ。
デメリットはなんといっても属人化しやすいこと。
たとえば担当者が不在のときトラブルが起きると、他の人がすぐに対応できない場合も。
・専属で担当する機能や作業内容など決めずに開発を進める場合
先ほどとメリット、デメリットが反対になりますね。
属人化しにくいので、特定の担当者でなくても他の人がフォローしやすい。
でも、責任範囲があいまいになりやすかったり、キャッチアップが必要だったり。
おおまかに上記のような特徴が挙げられると思います。
タスクアサインを柔軟にしていた開発チーム
ここから、あじ太郎の経験をお話します。
複数のサブシステムからなるサービスの開発チームに入ったときのこと、
当時、エンジニアが１５人前後いて、全員、全体的に見ていました。
そのタスクアサインは、自分が経験した中ではもっとも柔軟なものでした。
例えば、
ある機能追加では
要件定義はＡさん⇒設計はＢさん⇒プログラムはＣさん⇒テストはＤさん、
その機能をさらに改修する際に、単純に前と同じ人をアサインするとは限らず、
要件定義はＣさん⇒設計はＤさん⇒プログラムはＥさん⇒テストはＦさん、
みたいなアサインになることも。
また、テストで不具合が発見されたら、プログラムしたＣさんやＥさんが対応する場合もあれば、別のＡさんやＤさんが調査～修正することも普通ですし、突然Ｇさんが対応することも。
調査や保守タスクが発生すれば、みんなで分担してやってたな。
チームの中で、自分が最初に担当した保守作業はSQLを考えたり手順書を作ったりもしたけど、専属にならないこともあり２回目以降、他の人が対応していたと思います。
同じタスクは同じ人に継続して任せるチームも多いと思いますが、当時そんなことはなかったです。
調査やキャッチアップすることも多くなりやすいし、当時は、なんでここまで柔軟なアサインを徹底しているのかな？と不思議で、たしか周りの人にも質問もしたけど明確な答えはわからず。
気づき
その後、別の職場に異動となり、エンジニアそれぞれに対して専属で担当機能を決めている開発チームで奮闘しつつ、他のこともやりたいなと思った、そのときに気づいたことが！
担当機能や作業内容を決め打ちせず、アサインを柔軟にすることで、いろいろ挑戦しやすい環境になっていたなと。
もう一つ、各自の希望と異なることを一時的に担当することはあるけれど、そこにロックインされないというメリットもありそうです。
世の中には個人のスキルや視座によって仕事を広げる人がいて、それは素晴らしいことではありますが、
柔軟なアサインを徹底することによって、個人が仕事を広げやすい環境をチームの仕組みとして実現できていたのかもしれないと思いました。
あと、休暇も取りやすかったけど、これも各自の気持ちの問題ではなく属人化の少ないチームの仕組みによって担保されていたと思います。
リーダーがこういったことを意図していたかはわからないですし、当然、チームを取り巻く状況によって同じやり方でもうまくいかない場合もありそうですが、その時はうまくはまってました。
さいごに
当時よくわからなかったけど、きっと仕組みにうまくのせてくれてたのかなと、改めて感謝したあじ太郎なのでした。