スクラム開発チーム立ち上げの失敗談を話しました #GWD_Nulab

概要

Nulab様が主催する Geeks Who Drink in Tokyo - Agile Team という勉強会に参加しました。 なるべく具体的なケーススタディ（特に失敗談）を共有したかったので「スクラム開発チームの立ち上げでアンチパターンを踏みまくった話」という発表をしました。

イベントの様子

イベント風景や発表内容は、以下のブログでレポートされています。

モブプログラミング？アジャイル？自分たちに最適な開発手法を本気で考えてみた「Geeks Who Drink Agile Team Edition」をレポート！ | ヌーラボ

会場の合いの手スキルがやたら高くて面白かったです。

発表資料

当日のスライドは以下になります。

PEXELSにラグビーの画像がなく、アメフトでごまかしたことについては、深く反省しております。

内容

かいつまんで説明します。 詳しくはスライドを見てもらえると嬉しいです。

この話の位置付け

• とあるスクラムチームの立ち上げでアンチパターンを踏みまくった話を共有します！
• 反省を活かして、それ以降のチーム立ち上げ時には、比較的スムーズに話を進められるようになりました！
• 「失敗談」と「こうすべきだった」を共有することで、同じように困っている方のヒントになれたらと思います！

アジェンダ

• チーム立ち上げの背景：モバイルアプリ開発チームを立ち上げました！
• アンチパターン
  1. 改善とビジョン：目指すゴールの共通認識（＝Good/Badの基準）がないと改善のやりようがありません！
  2. 課題とフォーカス：解決したい課題を明確にせずに「アジャイルっぽいやり方」をやろうとしても本末転倒です！
  3. 出荷とロール：下手に役割分担するのではなく、全員が優先順位の通りに行動することで、ボトルネックが可視化されます！
  4. 作業とストリーム：1つのチームで1つのプロダクトの1つのゴールに向かって作業しないと、綻びが生じてしまいます！
• スクラム開発：「What」と「How」を見直す → 継続的な「課題発見」と「課題解決」による進化を支えるフレームワークだと解釈しています！

スライドの一部抜粋

補足

誤解が生じないように補足すると「これがスクラムだ」と断言したり押し付ける意図はありません。 正直なところアジャイルやスクラムという言葉を使う必要さえないと思っています。

あくまで位置づけとしては

• ビジネス価値の最大化が目的である
• その過程でチームビルディングが必要となる
• 開発プロセスのフレームワークとしてスクラムを採用する
• 運営の過程で何かしらの問題は起きる（コンテキストによって違いはある → とはいえ類型もある）
• なのでアンチパターンや失敗談を起点にして知識を整理した

という感じです。

ケーススタディとして含めなかった話

なぜスクラムを採用するのか

中長期のプロジェクト型開発（ウォーターフォール）は必要悪だと思っています。

• 事前に定めたQCDS目標を達成するために、学習頻度を犠牲にしがちだからです。
• 半年間のプロジェクトなら、半年もフィードバックを得られない（仮に得ても活かせない）ことになります。

可能な限りイテレーションを回せるプロセス設計が望ましいです。 そうなると、何らかのアジャイルプラクティスを（結果的にであれ意図的にであれ）適用することになるでしょう。

特にスクラムは型が明確で「最初にこれをやりましょう」の会話がしやすいです。 それゆえに意図の解釈や議論があちこちで起きてしまいがちなので、ビジョンの補完やフォーカスの徹底、ロールやストリームの考え方を装着することが必要になります。

また、スクラムはデファクトスタンダードゆえの恩恵をもたらしてくれます。 困った時に参照できるリファレンスや知見が世の中に溢れているのです。 新規参画メンバーに話を通しやすい、別の場所に移っても学びを活かせる、といった利点もあります。

チーム立ち上げ時に使う資料

ホワイトボード

下の図を描きながら、スクラムとは「What」「How」の「問題発見」「問題解決」を繰り返すフレームワークだと伝えます。

参考図書

最初に読んでもらう → 必要に応じて輪読会をします。

• SCRUM BOOT CAMP THE BOOK：まずは見よう見まねで始めるための1冊。
• リーン開発の本質：背景にあるトヨタの考え方（ソフトウェア向けにカスタマイズされているが）を抑えるための1冊。

URL

いちおうチームに共有しておく → 結局自分で見ることが多いですが。

• Scrum Guide：邪道ですが「スクラムガイドには書いてないので、自分たちでやりやすい方法でやってみたらどうかな！」と言うために参照することがしばしばあります。
• Ryuzee.com：困ったときによく見ます。

アジャイル博士になることがチームの目的ではないので、提供する情報量は最小限に絞ります。 なるべく余計なことを考えずに、目の前の問題に集中してもらうことが大事だと繰り返します。

感想

自発的に継続進化できるチームの構築は、基本であり奥義でもあると改めて思いました。 顧客価値にコミットできる良いチームを作っていきたいです。

スクラム　仕事が４倍速くなる“世界標準”のチーム戦術