Why ＝ 目的意識の共有が支えるアジャイルの急速スケールアップ：Agile Japan 2015 レポート (26)

店舗で利用するPOSレジアプリ「Airレジ」の開発を、なぜ、どのように大規模スクラムで実践してきたか共有いただきました。大規模スクラムというと、よくある勘違いとして1スクラムチームのメンバー数だけ10倍にしたようなスクラムチームを想像しますが、そうではないですよ、と笑いを誘うところから始まりました。

結論は

• スケールアップしても原理原則は変わらない
• 「Why」「検証と適応と透明性」が大事

ですが、これまでにはさまざまな試行錯誤があったようです。

なぜスクラム？当たり前を当たり前にやりたい

建前は「未経験の事業領域であり、試行錯誤が必要だから」ですが、現場にとってはぶっちゃけ「当たり前を当たり前にやりたい」というのが動機だったと言います。

スクラムを始める前は、たとえば「要件決まってないから作れない」「UIイケてないけど言われたから作る」などといった声が聞かれたそうですが、これはやりたい開発じゃない。率直な意見を言い合えるように、当たり前を当たり前にやりたいという思いがあったそうです。

試験導入フェーズは「かたちだけ」でもとてもうまくいった

まず、ウォーターフォール型だった当時の開発の中で、一部だけスクラムチームを組み、書籍『Scrum Boot Camp』を片手に、かたちから入りました。スクラムをちゃんと理解している人はおらず、たとえばリファインメントとか障害リストとか最初はありませんでした。それだけでも、タスク漏れがなくなった、可視化されて意見がでるようになった、などとてもいい手応えを得たといいます。

全面展開フェーズは「かたちだけ」＝ Why の欠如が問題に

試験導入がとてもうまくいったので、全面展開フェーズに移行しました。しかし、スクラムマスターは調整者？プロダクトオーナーはストーリーつくって終わり？、など「なんか違う」と感じる場面がいろいろ出てきました。

トップダウン式の導入で「やらされスクラム」になってしまい「かたちだけ」だったために、スクラムを誤解していたり、うまくいかないとスクラムプロセスのせいにされたりといった問題が噴出しました。決して成果がなかったわけではなく、たとえば、定期的なふりかえりで改善実施、最小スコープを探してリリースサイクルを向上するなどの効果もありました。しかし当時はまだ、本来できるはずの50％くらいしかできている感触がなかったそうです。

なんのためにスクラムをやっているのかという「Why」を全員が理解していることが決定的に重要だったといいます。このフェーズでは、以下のような問題への対策が実施されました。

• 事例1
  • 問題：スクラムだから◯◯しないとダメ＝スクラムをやることが目的化してしまう
  • 対策：Why を考えるワークショップ、相互に聞ける環境づくり

• 事例2
  • 問題：プロダクトオーナーのコミット力低下＝ストーリー書いて終わり→現場から離れる、計画ミーティングに参加するだけ、聞きたいときにいない
  • 対策：物理的な距離を近づける(席替え)

• 事例3
  • 問題：メンバーの自発性が育たない ＝ スクラムマスターが仕切っちゃう、ふりかえりがお通夜
  • 対策：スクラムマスターチェックリスト(「SMがタスクアサインやってませんか」などの質問リストに、SM自身とメンバーそれぞれが評価してフィードバックする)
    うまくいってないチームは自己vs他者の認識ギャップがある

なぜスケールするのか？

プロダクト／サービスの相互連携など規模拡大に伴い、組織も拡大し、スクラムも大規模対応を余儀なくされました。大規模化に伴い、POの意思を統一するPO Lead、プロダクト全体のアーキテクトを調整するArchitect チーム、プロダクトのリリースやその直前のQAを担当するReleaser などが役割として拡大していきました。
このあたりは、公開スライドを参考にいただければと思います。

(写真提供：筆者)

スプリントは2週間, リリーストレインは月1回の頻度で、スプリント中にはDemo DayやPO/SMのナレッジ共有会など、独自の儀式も実施するようになったようです。この頃はスクラムマスターも増え、内部でもナレッジが多く蓄積されるようになったと言います。

当然のように問題もありました。スケールアップすると、チームレベルの問題が抽象度が上がって再発するといった状況だったようです。具体的には以下の問題と対策が共有されました。

• 事例1：組織的課題が見えづらい
  • → チーム内の可視化はいろいろやるけど、全体の可視化を忘れる
  • 対策：全体の可視化と情報共有によるチェック

• 事例2：リーダーチームへの依存
  • → SM がチームの自律性を阻害したのと同様、リーダチームがうばってしまう
  • 対策：リーダチーム解散して、SM・PO共有から、自発的に解決するように
    原則チーム自身が問題解決するようにして、リーダチームはサポート型へ移行

• 事例3：アーキテクチャ問題・技術的負債
  • →モジュールの切り分けがちゃんとできてないとコンフリクトしまくる、マージコスト増大
  • 対策：内部アーキテクチャ見直し、挑戦中

今後とまとめ、Q&A

今後は、あらためて全体の可視化として、プロセス、スループットの可視化などに挑戦していきたいとのことです。可視化は、意見ではなく事実を顕在化させることが重要で、目的が認識できれば意思が共有できるとのことです。また、スケールアップにはマインドセットの変化が求められるので、それを支援していきたいと言います。

いろいろ失敗もありながらも、スケールアップしてよかったと断言して締めくくりました。アジャイル導入や組織への適応は「人のエンジニアリング」といった面もあり、非常にやりがいのあるものだったようです。

その他、質疑応答からも参考となる事例、考え方が聞かれました。

• チームは事業ドメインごとにわかれている
• Whyを理解するためのワークショップ＝原理原則の理解を深めるワークショップ
  • 教えるというよりは考えてもらうスタイル
  • スクラムマスターの育成は、最初は経験者が一緒に行いフィードバックする
• アジャイルの拡大にあたっては
  • ちゃんと上層に説明した
  • 文化的支援はあった
  • 人の育成になるというのが響いた
  • フルスタック ＝ 設計・開発までできるエンジニアが育つ
• エンジニアは相互評価のほうがいい
  • ベロシティは評価には使ってない
  • 定性的なほうがいい
• Portfolio Architectはざっくり大枠、戦略レベルで決める
  • 各アーキテクトは基盤レビュアー的存在
• メンバーを別チームなどに移動するときは 2人以上で動かす
  • 1人で動かさない
  • 文化は複数人の間で共有されているものなので

感想

大規模スクラムの実際の組織図や役割の定義など、スクラムの教科書にはないレベルの内容はもちろん参考になりましたが、それ以上に「Why が大事」というのは私自身も所属する組織において痛感していることなので、とても響きました。結果としての組織体制などは付随的なものでしかなく、目的意識の共有をはかること、はかり続けることがスケールアップするアジャイルの肝なのだろうと思いました。

拡大する組織にあわせて単に体制をしくだけではなく、その中でマインドセットの変化や意識の共有を支援するような、まさに「人のエンジニアリング」をどれだけうまくやれるかどうか、おそらくこれはスクラムやアジャイルに限らず、組織の大規模化に伴う「痛み」を乗り越えられるかどうか、その成否を分ける鍵なのだろうと思います。

もっと知りたい！Agile Japan

Agile Japanとは

• Agile Japanとは
  
• 公式サイト：Agile Japan
• Twitter：@agilejapan
• Facebookページ：Agile Japan

レポートコーナー

• Agile Japan 2015：http://www.manaslink.com/aj2015
• Agile Japan 2014：http://www.manaslink.com/aj2014
• Agile Japan 2013：http://www.manaslink.com/aj2013
• Agile Japan 2012：http://www.manaslink.com/aj2012
• Agile Japan 2011：http://www.manaslink.com/aj2011