＼回答があります！／

• 

  Dai Fujihara

  プロジェクトマネジメント

  1年前
  アジャイルコーチとしてお客さまを支援していると、スケールが進むに連れてこの問題が出てきます。そういった経験から自分の感じたことをまとめてみます。
  
  ・ 分けると扱いやすいが、つなげるとき面倒になる。小さいものは扱いやすい分、結合するコストが生まれます。チームや仕事の粒度が悪いときに問題になりやすい部分です。組織やシステムにとって適切な粒度を探していく必要があります。
  ・チームサイズはそのチームで扱えるコミュニケーションの量に依存する。20人チームでもコミュニケーションが「うまく」とれるなら問題ないはずです。人数については2ピザチームとかが一般的ですが、10人以上のアジャイルチームを選択する現場もありますし、3人で頑張るチームもあります。扱えるコミュニケーション量にあわせたサイズが無難だと思います。
  ・分け方は現場によっていろいろありすぎる。理想を言うと、誰でも何でもできるフルスタックエンジニアがそろったチーム（フィーチャチーム）ですが、いきなりそこにいくのは難しいです。ただ、難易度別にいろんな方法が選べる時代なので、ちょっとずつ理想に近づいていく作戦が現実解だと思います。
  
  チームの分け方例
  （難易度低）
  ・職能で分ける（フロント、バックエンド、QA・・・）
  ・システムの機能で分ける（検索チーム、購入画面チーム・・・）
  ・職能横断型でゴールごとにわける（いわゆるアジャイルチーム、スクラムチーム）
  （難易度高）
  
  プラス、最近流行りのチームトポロジーを採用する。スケーリングアジャイルフレームワークを採用する・・・とかの選択肢も加わってきます。
  view数 17
  • 1
  • 1