僕は今のチームでフロントエンド担当ということになっている。 一応肩書は「アプリケーションエンジニア」だしサーバー側のコードもガンガン書くけど、他のエンジニアとの立ち位置を考えると自然と担当範囲が決まってくる感じだ。
担当範囲の決め方
うちの会社ではWebサービス開発を行うエンジニアを「アプリケーションエンジニア」として一律に扱っているが、その実メンバー毎になんとなく担当範囲が存在する。 担当範囲は、個人的な嗜好、経緯、あとはチーム内での分担で決まる。
僕の場合は、フロントが好きということもあったし、チームに入ってすぐフロントのタスクをゴリゴリ進めた結果、すんなり現在のポジションに落ち着いた。 チーム内で一番JS書ける必要はなくて、チーム内での比較優位で決まることもある。
今のチームでもう2年以上も働いていて、その割に知らない仕様とか沢山でてくるけど、それらを全部把握しようとは考えてはいない。 わからない事があれば知ってる人に聞けばよい、と考えている。
メリットとデメリット
たとえば、タスクの内容によって反応すべきかどうかフィルタリングできる。 Slackでは沢山のチャンネルにjoinしてるけど、ひと目見て「これは○○さんの分野だな」と思ったらスルーするようにしてる。 GitHubのissueも同様。 全部見るという人もいるけど、僕は仕事に集中してる間Slackに気づけないタイプなので、気にせず流すようにしてる。
あと、担当範囲はどこかでアピールしておいて、他のメンバーにも共有しておく。 そうすると自然と「画面でバグでたら @amagitakayosi に報告しよう」とか「npmの話題だから @amagitakayosi に聞こう」となってくれて、とても助かる。
担当範囲を意識することで自分の可能性が狭まるかというと、そうでもないはず。 名刺に書けるような自分のスキルを追加するぞ、くらいの気持ちになれる。 社内で新プロジェクト始まる時に「このJSどう思う」みたいに聞いてもらえたりして嬉しい。
ただ、自分の好きじゃない分野の担当になったら、あんまり我慢せずとっとと切り上げたほうが効率良いと思う。
社内ブランディングとチーム間コミュニケーション
担当範囲がはっきりしたエンジニアが集まると、チーム間でのコミュニケーションがしやすいというメリットもある。 うちの会社では、インフラ系の人やスマホアプリエンジニアは担当範囲がはっきりしていて、ミーティングを開いたり、ある種の独立自治体制を築いている。 フロントエンドはまだまだだけど、フロントエンドランチ みたいな活動を続けていって、いずれいい感じになりたいなと妄想している。
