- Column
- スクラムで創るチームワークが夢を叶える
イノベーションを生み出すチームは職能横断が条件【第2回】
スクラムチームのステップは70年代の日本の製造業と同じ
次に、今日のデジタルサービスを開発するスクラムチームに上記のステップを当てはめてみよう。まずスクラムが機能する前提として、チームは職能横断でなければならない。ビジネスの担当者とプロダクトの設計・開発・テストに必要なエンジニアがチームに揃っている。
次に経営層は、チームにミッションは与えるが、プロダクトビジョンの設定や仕事のやり方はチームに任せている。職能横断な自律したスクラムチームがイノベーションを生み出すステップは、70年代の日本の製造業の新製品開発チームと全く同じになる。
第1のステップ=共同化
「スクラムチーム」は、3〜9人の職能横断の小さなチームであり、チームメンバー間の深い共感がまず、第一に求められる。
そのためチームは固定化され、数年間一緒に働き続けているチームも珍しくない。チームメンバーは、日々の仕事はもちろん、毎日、お昼ご飯を一緒に食べたり、仕事帰りに飲みに行ったり、時には皆でフットサルなど趣味の活動を共にしたりする。
そうした活動のなかでチームメンバーは、プロダクトについてはもちろん、仕事観や人生観を語り合う。チームによっては、チーム独自の憲章「ワーキング・アグリーメント」を作り、チームの結束を高める。
第2のステップ=表出化
深い共感を持つチームは、ビジョンステートメントやエレベーターピッチといったツールを使ってプロダクトビジョンを生み出す。プロダクトビジョンには、経営層のミッションだけでなく競合に対する差別化のポイントが反映される。
ビジョンステートメントやエレベーターピッチは、チームが暗記できるぐらいに簡潔な内容で定義され、チームが新たなサービスを生み出していく際の指針になる。多くのチームでは、プロダクトビジョンをチームが働く場所に掲げている。チームが迷いそうになった時、このビジョンがチームを導いてくれる。
第3のステップ=連結化
チームは、プロダクトビジョンに基づいてスプリントごとにプロダクトにおけるビジネス価値の高い機能から順に、要件定義・設計・開発・テストを実施する(図2)。
多くのチームでは「ユーザーストーリーマッピング」というツールを使って、ビジネス側の担当者とエンジニアが一丸になって、プロダクトが持つべき機能の要件を議論する。その際、開発チーム中では特定の役割を設けず、チーム全員が助け合って設計・開発・テストに当たる。ペアプログラミングやモブプログラミングを利用するチームが多い。
第4のステップ=内面化
チームは、機能の要件定義・設計・開発・テストを頻繁に繰り返す。その改訂において、チームの中にプロダクトを生み出すための様々なノウハウが蓄積されていく。
チームは、スプリントのたびに、ユーザーから直接、レビューを受ける。良い評価も悪い評価も、チームの新たな想いやノウハウにつながる。チームは自分たちの仕事のやり方も振り返る。振り返りにより、自分たちの仕事のやり方を改善しチームには加速度的にノウハウが蓄積される。
上記の1〜4のステップは、70年代の日本の製造業チーム同様、必ずしも順番通りに進むわけではなく、絶えず行ったり来たりを繰り返す。
熟達したスクラムチームは、その繰り返しのなかで、UberやAirbnbのようなイノベーションを生み出していく。そこには、それまで蓄積してきたチームの想いやノウハウが、美しいUI(User Interface)や分かりやすいUX(User Experience)、モダンなアーキテクチャー、シンプルなコード、高い品質として現れる。