いてづきブログ

情シスでやってみたことの備忘録

フロントエンドとバックエンドをチーム分けするのは合理的なのか

11月からプロジェクトが変わって、引き続きReactNativeでアプリ開発する仕事をしてるわけですが、今回のプロジェクトもアプリ側(フロントエンド)チームとサーバーサイド(バックエンド)を分けるチーム構成で進めている。

 

一つ前のプロジェクトもそうやってチームを分けていたけど、イマイチしっくりこないというか無駄が多かったなと感じたので書き残しておく。
フロント/バックの分け方としてはこんな感じ。

  • フロント/バックでリポジトリは別
  • それぞれのチームのみレビュー(承認)権限がある
  • それぞれのチームのタスクのみを担当する

 

個人的にはフロントとバックが分かれていることで余計な作業が発生しているように感じている。少なくとも(アプリの大部分を占める)単純な機能についてはそう思う。

 

例えばバックエンドからユーザー情報を取得してその内容を画面に表示するようなユーザー詳細画面を作るとする。
フロント側は画面のレイアウトを、バックエンド側はユーザー情報を返すAPIをそれぞれ作ることになると思う。(既にフロント↔バック間の通信の仕組みは出来ているとする)

フロント側はAPIができていないのでまずはモックあるいはダミーデータで画面を作ることになる。
これらは最終的に消されることになるのでまずコレが無駄。

 

次にいざ結合してみると様々な問題が発生する。
例えば、

  • 表示に必要なデータが取得されていない
  • データの型が決まっていない(stringなのかnumberなのか)
  • データがないときはnullなのか空文字なのか

ひとつひとつはもちろん大したことじゃないしすぐ直せる。

…と思うだろうけどフロント/バックが分かれている時の修正の流れはこう。

  1. 修正してもらう
  2. バックエンドチーム内でレビュー(指摘したフロントエンドの人はレビュー権限なし
  3. マージ・デプロイ
  4. フロントとの結合再確認

フロントエンドの人にレビュー権限ないからバックエンドチーム内で更に別の人にレビューしてもらう時間を取る必要があるし、もしも修正方針のコミュニケーションがうまくいってなかったらもう一度このやり取りをする羽目になる。

 

そこはしっかりコミュニケーション取って決めておくところだろとかというのはごもっともだけど、経験則になってしまうけどそれでもやっぱり漏れや認識のズレは発生するしほとんどの人は「ちょっと言って直してもらえばいいことでしょ」と思っていると思う(実際は待ちの時間がかなり発生するわけだが)

 

 

とはいえ、たとえチーム分けをしない形にしたとしてもフロント/バックそれぞれのアーキテクチャとかについてはそれぞれの分野で得意な人・できる人がやる感じになっていくだろうし、ある時点ではスキル・知識的にフロント/バックどっちかのタスクをやることが多くなることもあると思うけどそれは別に構わないと思う。価値を届けられないよりはずっといい。

 

実際、今のプロジェクトはバックエンドが遅れ気味になった*1ためフロントチームの自分とかもバックエンドの機能実装をするようになっている。

1機能がフロント、バックエンドそれぞれの結合で完成するものならそれを分割するのはそれだけコストがかかることだなと感じた。

 

 

世の中ではこうやってチーム分け事例がたくさん紹介されているので、こういう問題をどう対処しているのかとても気になるところ。

 

 

*1:アーキテクチャ周りの調査が多かったとか、稼働の問題とかもあるけど