機能横断的なチームを目指すためにどんなことをすると役に立ちますか？

機能横断的なチームを育てるには、メンバーが専門分野に閉じこもらず、幅広いスキルに触れることが欠かせません。そのために役立つもののうち、代表的なのがペアワークやモブワークです。誰かと一緒にコードを書いたり設計を考えたりすることで、知識やスキルが自然とチーム内に広がっていきます。

ただし、手段はそれだけではありません。

たとえばチームで勉強会に参加したり、特定のメンバーに研修に参加しもらい、それを持ち帰って、学びや気づきを全員に対して発表するといったことも有効です。また、あるコーチング先では、「自分の得意分野のタスクには着手しない」というルールを一時的に導入し、全員が普段はやらない種類のタスクをあえて経験したこともありました。こうした試みは、短期的には効率が落ちるように見えるかもしれませんが、長期的には大きなリスク低減や学習効果につながります。

もちろん、懸念として「ペアやモブをやるとスピードが落ちるのでは？」「勉強会や研修の分だけ開発の時間が減るのでは？」という声も出てきます。実際、短期間では作れるものが少なくなる可能性があります。しかし、プロダクト開発は長いマラソンです。目先の速さを優先して専門分野に過度に特化すると、将来大きなボトルネックや属人化のリスクを抱えることになりかねません。学習やスキル獲得への投資は、回り道のように感じるかもしれませんが、確実な最短ルートです。実際に「すべての作業をモブで進めたスプリントでも速さは変わらず、チームの仕事の仕方がうまくなった」という事例もあります（ただし、モブやペアをずっとするのは非常に疲れるので持続可能ではありません）。

工夫のひとつとして、スプリントゴールをやや小さめに設定するのも効果的です。作るものを減らしつつもゴールを達成することに集中すれば、学習と成果の両立がしやすくなります。

さらに、スクラムチームは自己管理であり、誰が何をいつどうやるかは自分たちで決めるものです。ステークホルダーに「ペアやモブをやっていいですか？」とか「スプリントゴールを小さくしていいですか？」と許可を求める必要はありません。インクリメントを通じて価値を届けることで信頼を築くしかないので、スクラムチームとして投資が必要だと考えるのであれば、スクラムチームの責任で判断してください（ただし、なぜその意思決定をしたのかを説明できるようにしておく責任はあります）。

最後にもうひとつ、プロダクトが実際に使われている現場をチームで見に行くこともおすすめします。利用者の状況を観察するだけでも、専門分野を超えてメンバーが学び合うきっかけが生まれます。

このような取り組みをしないチームは持続できずに消えるだけです。