いろんなチーム開発の形
あなたのチームはどの形でしょうか？
チーム開発にも流行りがありますが、自分たちの現状に合うスタイルを取り入れたいですね。僕は決してモビングが必ずしもどのチームに有効だとは思いません。メンバーの勤務スタイルや取り扱ってる分野、スピードによってはワンマンがベストかも知れません。チームメンバーとどの開発スタイルがいいのか話し合ってみても面白いですね!
チームの役割
BizチームとDevチーム
UXやユーザーストーリーを考えるBizチームと、開発をするDevチーム。Bizチームが「何を作るか」を決めてDevチームが「どう作るか」を決める。Devチームが開発に集中できるため、最近流行りのスクラムとか取り入れやすい。
- メリット:
- 責任の所在が明確。
- 開発サイドは開発に専念できる。
- スクラムなどの開発手法が活きる
- UXリサーチ分野のノウハウが強くなる
- 最近のUser企業と呼ばれる大手はだいたいこのスタイルを採用。
- デメリット:
- チームを分割するので、リソースを要求する
- 「何を作るか」と「どう作るか」のフローが分離しているので、フィードバックが遅い。
BizDevチーム
DevチームもBizサイドとともにUXやユーザーストーリーを考える。漠然とした「何を作るか」を決め、その後担当者が詳細レベルの「何を作るか」を詰めていく。Devサイドも稼働時間のうち3~4割はユーザーストーリーを詰めるために使ってる。
- メリット:
- 作っていきながら検証ができる。
- 「何を作るか」を素早く修正しながら開発できる。
- デメリット:
- 作ったあとの検証を誰がするのか、責任の所在が曖昧
- 開発サイドのフローが増えるので負担が増える。
- 開発サイドが開発に専念できない。
- スクラムとあまり相性がよくない？
- よい開発手法モデルがまだわかってない
Devチームの内訳
DevチームとOpsチーム
開発とインフラが分離したチームとなっている。社内にオンプレでサーバーを立てていたり、クラウドでもインフラ専門のエンジニアを雇っている。
DevOpsチーム
開発がインフラも担当する。クラウドが流行りだしてCI/CDパイプラインが比較的楽に構築できるようになったおかげで、インフラ知識の低い人でもインフラを構築できるようになった。
フロー効率とリソース効率の配分
モビング
- 3人以上でひとつのコードを実装する。
- コードは直コミット。
- レビューはない。
- フローをすべてまとめているのでフロー効率は高いが、リソース効率は低い。
- Theチーム開発。チームメンバーの創発の効果により各個人だけでは出せない品質の高い成果物を生み出すことができ、また技術ノウハウの共有ができる。
- コードを全員が所有している状態になるので誰もがあとから編集しやすい。
ペアプロ
- 2人でひとつのコードを実装する。
- コードは直コミット。
- レビューはない(ペアの能力が低ければ導入するときもある)。
- 得られる効果はモビングと同じいだが、より弱い。
- フロー効率はモビングと同じ。
- リソース効率はモビングより高い。しかしチーム全体の人数が3人以下であればほぼモビングと同義。
従来
- 1人で一つのコードを実装する。
- コードは別ブランチ。
- pull requestを作成して相互レビュー。
- リソース効率はよい。
- 相互レビュー時にレビュワーがレビューの時間を確保できなければ、フロー効率が落ちる。
- レビューによる大きな出戻りが発生する可能性がある。設計を事前に共有すればある程度可能性を減らすことはできる。
ワンマン
- ワンマン(リーダー的存在)がプロダクトコードの全体に責任をもつ。
- 他の開発者のコードはワンマンがレビューをする。
- ワンマンのコードは直コミットでレビューなし(ときどきやるときもある)。
- リソース効率はよい。ワンマンの担当するタスクのフロー効率もよい。他の開発者の担当するタスクのフロー効率はワンマンの忙しさに比例する。
- レビューによる大きな出戻りが発生する可能性がある。設計を事前に共有すればある程度可能性を減らすことはできる。
nマン
- n人がそれぞれの範囲で開発をし、それぞれの範囲の責任をもつ。
- n人がかぶらないように得意分野をもつスタイルもある。
- 全員直コミット。
- レビューなし(ときどきやるときもある)。
- フロー効率とリソース効率において最強だが、コードの品質は各個人の技量に依存する。
計画に対するスタイル
初期計画優先型
ウォーターフォール開発に取り入られている手法。一番最初にすべて計画し、あとは計画に沿って実行していく。
タイムボックス計画優先型
アジャイル開発に取り入れられている手法。一定の期間を決め、その期間ないの計画に沿って実行していく。タイムボックス期間中は計画を変更しない。
センスアンドレスポンド型(計画非優先型)
ロードマップは持たない。計画はたてるかもしれないが常に顧客の反応を観察し変更する。顧客の言動すべてに影響されるとブレブレなプロダクトが作られるなので判断軸となるビジョンが大切。
関係ないかもしれないが、どこかで読んだ本に「優れたインタビュアーは１つの質問しか用意しない」と書いてあった。１つの質問の反応をまた深ぼれば、そこからどんどん質問が湧いてきてその人の本質が見えてくるらしい。なんかそれに似ている気がする。
Discussion