スクラムではチームの成果にフォーカスする。
そのためには、個人で仕事をする形から、チームで仕事をする考え方にシフトしないとけない。
いわゆる Swarming という考え方で、チームが寄ってたかって一つの開発アイテムを進めることを意味している。
逆に、チームでバラバラと仕事を進めるわけではない。
イメージしにくい人は、アメフトの試合で、ボールがフィールド上にいくつあるのか（１つに決まっている）、チームはどのボールに向かっているのか（１つに決まっている）を想像してみるといいと思う。あっちもこっちもボールが転がってたら大変だ。面白そうだけど。
なぜチームで仕事をするのか
5つの機能がスプリントのスコープに入っているとする。
5人でこれらに取り組むとする。
効率を重視したこれまでのやり方で言えば、各自が分担してそれぞれの機能の開発を進める。
この場合、それぞれが進める中で、
- レビューが必要になるが、他の人は「自分の機能」が優先なので、見てもらうには時間がかかる
- 結果として、レビューが進むのは、全員がそれぞれ自分の開発が終わった後になり、リスクはスプリントの後半にギュッと圧縮される。
- スプリントの前半と後半でタスクの消化リスクに違いがあるなら、統計的に進捗を捉えるバーンダウンは機能しなくなる。後半の方が待ちや手戻りが多いのに前半（開発）と同じリスクで終わるとは思えない。
- 自分が担当していない機能については、知らない
- 結果として、担当した人間の能力に設計が依存する
- また、機能に対する知識も開発した人間に偏り、属人化が進む
とか言った弊害が多発するため、お勧めしない。本当に。
とか言ってもどうしたらいいんだか、って思う人は多いし、実際にやってしまっていても気づくことは難しい。
逆に、スクラムを個人戦にしてしまう方法（アンチパターン）があるのではないか
っていう観点で、今までいくつかのチームを見てきた中で、このパターンは個人戦が進んでチーム開発にならないな、というパターンが見えてきたのでまとめてみた。
これやっちゃってるな、っていうのがあれば、気づくきっかけになるかもしれないし、自省も兼ねてまとめてみた。書かれてないパターンもいくつかありそう。教えて欲しい。
パターン1. タスクボードのスイムレーンが個人単位
一番やっちゃいけないと思っているパターン。個人戦の象徴（個人の感想です）
自分が関わっていないタスクには興味がない、と言わんばかりに引かれたスイムレーンの境界線で、他人（チームメンバー）がやっていることに興味を持っていない。
サッカーで言えば誰がどこにいるのか興味がない。そんなチームがいるか。
パターン2. ストーリーごと個人にアサインする
選手一人一人がボール持ってるアメフトって見たことあります？
「困ったら言ってね。僕らはチームだからさ。」そんな言葉でその機能は基本的に自分の責任でないことを認識する。
イクメン自認してる割に言われないと仕事しなくて嫁にキレられる構図と似ている。
パターン3. デイリースクラムで、『私が昨日やったことは〜』と話してしまう。
「え、ダメなの？」とかいう声が聞こえてきそう。
いいんですよ、どんな形でやっていても目的が果たせていれば。
デイリースクラムの目的はチームのスプリントゴールに対する検査と適応なので。
３つの質問だけ答えてれば検査と適応ができるなんて魔法みたいなことが起こる訳がないのです。
以前のバージョンで、ようやく”スプリントゴールを達成するために” という枕詞がついた３つの質問ですが、個人的にはとてもイマイチ、というか、チームになっていない状況であの質問を続けてもスウォーミングは全く進まないと思っている。だって興味ないもん。
実は 1. のパターンを採用していると、スイムレーンの上から話していくことで必然的にこのパターンになってしまっていることもある。
逆に、このパターン（３つの個人の報告）をしているがために、話しやすいように個人別のスイムレーン1. になってしまっている場合もある。
パターン4. POやSMがイベントのファシリテーションで主体的に振る舞う/リーダーシップを発揮してしまう/タスクをアサインしてしまう
根が深い問題。リーダーシップは素晴らしいが、それでチームの自己組織化は進まない。
脳が全部命令してくれるなら心臓は自律的に動く必要ないの。
でもそれだと脳死した瞬間に全てが死んじゃうの。誰も何も考えなくなってるから。
自分たちが何をやるのかを自分たちで決めないといけない。
リーダーシップを発揮するなら、チームが自分たちでできるように促す方向に全力でリーダーシップを発揮しましょう。
これは、自分はできていると思っている人ほどできていない印象。（僕調べ。n=12）
こういう人は人の話を聞くのが苦手、というか、話をまとめて進めたがってしまうので、自分が聞いている時間を過大評価しがち。（私は傾聴してアドバイスしてチームを助けている、と認識している）
自分が話している時間は体感短いけど５倍くらいサバ読んでると思っていい。
１つ話したら５聞くくらいでちょうどいい、多分。知らんけど。
パターン5. ストーリーに WIP 制約をかけない。
WIP はカンバンの持ち物ではあるが、スクラムでもかなり有効に機能する。
まあSwarmingしてればWIPもくそもないでしょ、とは思うがなかなか１個流しは身に付かないので、所作としてWIPを制約するのは簡単な導入だったりする。
逆にこれをやっていないと、完成していない状態の機能がそこら中に放置される、またはそれぞれの人間がそれぞれのタスクを進めている。そして切り替えのムダに気づかず、残業時間に酔いしれる。
これらの裏を取ると、やらないといけないことは、
1. タスクボードを機能（ストーリー）単位にする
2. ストーリーを個人にアサインしない
3. デイリースクラムでは、『チームが昨日やったこと・今日やるべきこと・解決すべきこと』を話す
4. PO/SM はリーダーシップを発揮することをやめる
5. WIP 制約をかける
これらの取り組みによって、
タスクボードを機能単位にすることで、個人に意識を向けるフォースを減らす
同時に、WIP を減らし、ストーリーの個人アサインを止めることで、同じ機能開発を複数人で取り組むようにする
その上で、デイリースクラムでは、機能単位のタスクボードに向かって、チームが進めている機能について、関わっている人間がそれぞれ状況を共有する形を取る。
これらの取り組みにおいて、PO/SM がリーダーシップを発揮せず、チームが自律的に自分が何をやるべきかを考えられるように促すコミュニケーションを身につける。
ってな感じになる。ことが多い。
