BackendチームとFrontendチームとアジャイル

話があんまりまとまってないけどとりあえず出す。

職能型組織とその弊害

ある程度大きい Web プロダクト開発の現場 (例: エンジニアが全部で20人) において、その内部が Backend チーム / Web Frontend チーム / iOS チーム / Android チームみたいにサブチームとして分かれていることは実際よくあることだと思う。

アジャイル開発の文脈だと、基本的にこういう分け方はあまりよろしくないとされる。この分け方だと、それぞれのチームに閉じてユーザーストーリーを満たす開発ができない。そうすると、本番環境に機能を出してユーザーに使ってもらうには、複数のチームにまたがってタスクの優先度を合わせたり、複数のチームの成果物をつなぎこんだりする必要がある。そうするとチームをまたいだ調整が必要になり、チームの自律性が下がる。

そうではなくて、例えばフィーチャーごとにチームを作り、各職能を持った人が全てそのチームに入っているのが理想的である。

それでも職能型組織になってしまう理由

...とここまでは多分教科書的な話だ(と僕は認識している)が、現実にはなかなかそううまくは行かず、冒頭に書いたようにBackendチームとFrontendチームのように分かれていることが多い。

理由の一つは、スキルをまたいだタスクのアサインが難しいことである。

例えば、8人のエンジニアで構成されたチームがあり、内訳は例えば iOS エンジニア2人, Android 2人, Web Frontend 2人, Backend 2人だとする。このとき、全てのユーザーストーリーが 1:1:1:1 の働きを要求されるなら問題ないが、実際にはユーザーストーリーごとにBackendが重かったり、Web Frontendだけに実装が必要だったりと様々である。そのようなときは、そのスプリントごとの優先度に応じて柔軟に、例えばiOS/AndroidエンジニアがBackendの機能実装も行ったりできるのが理想的だ。

このようにアジャイルなチームにおいては、職能を超えた動きが奨励される。しかしながら、昨今の情勢はどちらかと逆風で、プラットフォームごとの専門性を要求されるようになっていると思う。iOS アプリの開発を Backendエンジニアが手伝うのは、実際にはなかなかにハードルが高いことが多い。逆もしかりである。

また、フィーチャー型チーム構成にした際に、そのチームを長期間維持するのが難しい、というのもある。あるサービスを開発するためのチームを分割する際、それぞれのチームは目的・目標を持つべきであろう。その目的はある程度の期間変わらずに、かつ他のチームの目的とバッティングしないものであるとよい。提供しているサービス内のドメインがはっきりしていると、それぞれのドメインを成長させるチームを作ればよいので、わかりやすい。しかし、なかなかそううまく切れているとは限らなかったり、ドメインが切れていても全てのドメインへの開発が日常的に必要とは限らないのが実情だ。そうするとチームの分け方が安定せず、朝令暮改的に感じられてしまう。一方で Backend/Frontendという分け方なら、それぞれに対して開発が長期間続いていくので、安定的である。

そもそもサブチームが必要なのか

どういうチーム構成が理想なのか、みたいなことを考えていると、結局チームってなんなんだっけ、というところに行き着いてくる。

冒頭の例でいくと、エンジニア20人、それに加えてデザイナーやその他職種の人もいるから、チームが大きすぎるので、分割しよう、となる。しかし、チームが大きすぎて困ることってなんだろう?

スクラムのプラクティスに当てはめて考えてみる。タスク(ユーザーストーリー)は個人ではなくチームに対して割り当てられる。デイリースクラムで各々困っていることはないか共有し、チームとしてその困りごとに対処する。このとき、20人もいると、どのタスクを取るかお見合いが発生しそうだし、20人それぞれの悩みを全員で解決するのはやや非効率がすぎる気がする。

これくらいであれば、恒常的なサブチームを作る外の解決策もありそうな気がする。たとえば、以下のようなのはどうだろう。
・スプリントプランニングで、大玉ごとの大まかなアサインだけは決めてしまう。大玉ごとにデイリーミーティングを行う。
・開発上の相談は、定例ミーティングを待たずにリアルタイムで。また、職能ごとのメンバーでのミーティングを定期的に開催して、技術的な課題を上げてディスカッションする。

職能型組織にしたときの成果物の定義

タスクは、完了条件(受け入れ条件)が明確であることが重要で、それはユーザーの価値に紐づいていればいるほどよい。

職能型組織にしたときの大きな問題点は、タスクの完了条件が曖昧になりがちなことである。あるユーザーストーリーを「Backend実装」「Frontend実装」に分割する。すると、インターフェイスの設計と、つなぎこみ、の2つは、それぞれから漏れることになる。Backend実装・Frontend実装それぞれのタスクは完了しているように見えても、実際のユーザーの価値には繋がっていない状態になってしまう。

Schema-Driven Development は、うまくやれば、Backend実装・Frontend実装それぞれの完了条件を比較的明確・安定にし、「つなぎこみ」の労力をかなり下げることができる。

そのためには、この Schema-Driven Development に関する技術を整えることにかなり力を入れる必要がある。たとえば、Backend 視点では Schema と実装の乖離を防ぐことが非常に重要だし、Frontend 視点では Schema から Mock Server を立てて開発するが、その Mock Server を良い感じにすることにしっかり力を入れると良い。

GraphQL を使えば Schema-Driven Development に関するかなりの問題が自動解決される。iOS, Android には GraphQL を導入する初期コストがまあまあ高いという点には留意すべきであるが、いずれにしても職能型組織を成り立たせるためには、Schema-Driven Development に関する技術投資が必要なのである。

職能型組織にした時点で、タスクの完了条件がユーザー価値に結びつかないのはある程度諦めるしかないが、その条件を一段手前に持ってくるイメージになる。つまり、Backendでいえば、定めた Schema を満たす実装を完了する、というのが完了の定義になる。GraphQL の場合はさらに、クライアントが送ってくる query に対してきちんと動作できるテストが完了している、というのも含めると良いかもしれない。これを擬似的なユーザーストーリーとみなして、ストーリーポイントをつける対象もこれに限るとよさそう。