ソフトウエアを作るプロジェクトでは、複数人が集まって協同しているチームの中で実体験が得られる。チームには多様な人がいる。それぞれの勝ちパターンと、状況判断の能力を持ち寄り、問題へのアプローチを分担したり協力したりしながら、一つずつ解決していく。前回までに紹介したスキルマップは、チームが持っている勝ちパターンと、今後持つべき勝ちパターンを視覚化したもの、といえる。

　チームがうまく機能していくためには、メンバー相互の勝ちパターンの理解が重要になる。どういう時にどんな勝ちパターンを投入するのか。どう課題を捉えて、どう考えて何を試し、その結果をどう考えるのか。チームとして同じ場所にいて、同じ時間を共有していると、自然と他のメンバーから学べる。誰かが解決した結果だけを見るのではなく、その人の理解や思考、実験、失敗の過程すべてを観察できる。経験により裏付けられた知識を通じてスキルを身に付けたり、その人と効率的に協業したりするための理解を得られたりする。

　こうした行動を自然と可能にするチーム運営方法の一つが「スクラム」だ。楽天でもここ3年で多くの開発チームが採用するようになった。

　スクラムの基本部分を紹介しよう。まず、チームがこれから解決していく課題や、生み出していくべき機能を「プロダクトバックログ」というリストに記載する。プロダクトバックログには厳密な優先順位を付け、それを順に完成させる。完成したら関係者にデモし、その結果が期待されたものなのかどうか、変えるところはどこなのか、といったフィードバックを受ける。新たな情報を得たチームはやり方をもっと改善する方法について考え、できる範囲で試していく。そして、この一連の作業は2～4週間といった決まった期間（タイムボックス）で繰り返していく。

　こうしてメンバーは、課題の理解と解決を協同作業で進め、互いを理解し、より上手に解決できるようになっていく。ただし、メンバーが大きく入れ替わったり、解決の対象が大きく変化したりすると、チームに蓄積されてきた勝ちパターンをうまく利用できなくなる。そのためスクラムでは、長く同じチームを維持するよう勧めている。

再利用しやすい「パターンランゲージ」

　スクラムは、チームとして仕事を進めるための基本的なルールを書き出した勝ちパターンの集合体といえる。勝ちパターンを他の人にも再利用しやすいように書き出すために「パターンランゲージ」という手法がある。過去にうまくいった例を「パターン形式」で記載し、パターン同士のつながりを「一つのパターンランゲージ」として例示するものだ。

　それぞれのパターンには、「特定の状況において、どのような解決策が適用でき、その影響はどうなるか」という情報を記載している。例えば、パターンの一つである「スタンドアップミーティング」は、「情報にエアポケットがあったり、情報が伝わらない人がいるなら、毎日短いミーティングを行って開発状況を伝え合おう」という内容だ。こうしたパターンを集めたパターン集として、発表や出版が行われている。