Hitachi
お問い合わせお問い合わせ
「DXを加速するアジャイル ~変化を味方にしたチームづくり~」 第13回は、企業が独自に創造する「スケール」のフレームワーク、そして型にこだわり過ぎて中身が空っぽになってしまうゾンビスクラムについて。「仏作って魂入れず」にならないための傾向と対策を解説していただきます。

「第1回:DXがアジャイルを必要とする理由」はこちら>
「第2回:アジャイルとの出合いから現在まで」はこちら>
「第3回:スクラムの原点は、日本発のひとつの論文」はこちら>
「第4回:アジャイル開発の実際」はこちら>
「第5回:スクラムによる組織改革事例」はこちら>
「第6回:心理的安全性と幸福度」はこちら>
「第7回:1週間のスプリントを繰り返す「スクラム」」はこちら>
「第8回:「スクラム」の3つの役割」はこちら>
「第9回:「朝会」と「ふりかえり」を大切に」はこちら>
「第10回:「場づくり」の5つの原則」はこちら>
「第11回:オンラインで行う 「スクラム」」はこちら>
「第12回:「スクラム」をスケールする方法」はこちら>

スケールする組織づくりへの挑戦

前回は「スクラム」をスケールする代表的なフレームワークを紹介しましたが、企業が自分たちで独自のスケールのやり方を考えチャレンジしている例も出てきています。スウェーデンのスポティファイ・テクノロジーという企業が2008年にスタートした「Spotify」は、いまでは4億8,900万人のアクティブユーザー数を持つ世界最大級の音楽ストリーミングサービスです。

彼らは急激な成長を支え、しかも自分たちらしい働き方を実現するために、Spotifyモデルと呼ばれる組織構造を作り、チャレンジしてきました。そして、Spotify モデルと言われるひとつの型を作りました。さらに、今ではSpotifyモデルを捨て、新たなモデルを作っています。自分たちの文脈にあったフレームワークを作り出すなんて、素敵ですよね。これがアジャイルの最強の型だと思っています。つまり、自分たちで工夫する。

もう使われていないこのモデルは今でも世界中で参考にされていて、ネット上に多くの文献が存在します。要約して説明すると、基本は顧客に価値を届ける小さなスクラムチームが集まってるということです。そのために、製品のアーキテクチャを工夫して、それぞれのチームがある程度独立して動けるようにしている。さらにそのチームにいる人の役割、例えばテスターとかインフラとか、強みのある分野の人が横断して知識共有しているのです。

チームトポロジー

画像: Quick Reference Card チームトポロジー https://scrapbox.io/iki-iki/QRC_Team_Topologies-ja

Quick Reference Card チームトポロジー

https://scrapbox.io/iki-iki/QRC_Team_Topologies-ja

さらに最近では、「チームトポロジー」という新しいチーム設計のパターンとその言語が話題になっています。そこでは、1.自分たちでモノを作り上げる能力を持ったチームである「ストリームアラインドチーム」、2.それをサポートする基盤となる「プラットフォームチーム」、3.他のチームがソフトウェアの採用や変更などを行う際にそれをアシストする「イネイブリングチーム」、4.複雑すぎて通常のチームでは対処できないサブシステムに特化して取り組む「コンプリケイテッド・サブシステム」、という4つの役割を持ったチームで構成されます。

必要なときにはそれぞれが協力し合うわけですが、その「協力のしかた」を「コラボレーション」「X-as-a-Service」「ファシリテーション」の3つのインタラクションモードに分けているのが、このフレームワークの斬新さになっています。「公式な構造」である組織を、「非公式な構造」「価値創造構造」にすることが成功する組織の鍵であるとし、フレームワークでありながら型にはまらない組織をめざす。この考え方を応用して、企業それぞれが独自の型を作っていくのが健全なアジャイルの在り方だと思います。

ゾンビスクラムにならないために

「チームトポロジー」のような考え方が出てきた背景には、「スクラム」をスケールさせようとして型を導入してみたものの、その型に依存し過ぎてみんなが考えることをやめてしまうという現象があります。「ゾンビスクラム」という言葉があって、『ゾンビスクラムサバイバルガイド』という書籍も出ていたりするのですが、「スクラム」の態で1週間のスプリントを回してはいるものの、自分たちが何を作ろうとしているのかとか、何のために働くのかといったことを考えずに上からの命令でイベントを義務的に行う。実のないスプリントが繰り返されるという「ゾンビスクラム」は、型に依存し過ぎてチームの一体感や達成感など「スクラム」本来の目的が失われてしまう悪い例です。

アジャイルや「スクラム」の精神はトライして改善するというスプリントを繰り返しながら進んでいくことですから、Spotifyのように自分たちの組織は自分たちが働きやすいように自分たちで考える、それが本来のあり方だと思います。

例えばアメリカでは、CEOがエンジニア出身という会社が多いです。特にGAFAMに代表されるようなテック企業では、エンジニアが自分たちでモノやサービスを作ることから始まっていますから、組織づくりのフレームワークも自分たちで考えて進化させていくという方が自然なのです。だからベンチャーがメガベンチャーになり、エンタープライズになる時でも、彼らはアジャイルなエンタープライズに成長していきます。

ところが日本のメーカーのような大企業では、縦割りの組織が出来上がっていて、ガチガチのウォーターフォールの枠組みがすでにあるところに「スクラム」を取り入れようとするので、話はややこしくなります。しかし、いいものを作ろうというチームやエンジニア部隊はたくさんあるのです。だから、欧米発の型に無理に当てはめるのではなく、自分たちのビジネス、自分たちの強みや顧客に合ったフレームワークを自分たちで作り成長させていく。現場の工夫を柔軟に取り入れながら、ゾンビにならない組織づくりを追求し続けることが重要です。特に日本では、人の力を信じてビジネスを成長させる鍵がここにあるのではないでしょうか。

Hiranabe’s Point

「スクラム」のスケールに参考書はあってもマニュアルはない。
自分たちのビジネスと、自分たちの強みを活かした、現場発のやり方を作り出そう。

「第14回:アジャイル開発の実践例:株式会社 北國銀行 その1」はこちら>

画像1: DXを加速するアジャイル ~変化を味方にしたチームづくり~
【第13回】 ゾンビスクラムにならないために

平鍋 健児(ひらなべ けんじ)

株式会社 永和システムマネジメント 代表取締役社長、株式会社チェンジビジョン 代表取締役CTO、Scrum Inc.Japan 取締役。1989年東京大学工学部卒業後、UMLエディタastah*の開発などを経て、現在は、アジャイル開発の場、Agile Studio にて顧客と共創の環境づくりを実践する経営者。 初代アジャイルジャパン実行委員長、著書『アジャイル開発とスクラム 第2版』(野中郁次郎、及部敬雄と共著) 他に翻訳書多数。

画像2: DXを加速するアジャイル ~変化を味方にしたチームづくり~
【第13回】 ゾンビスクラムにならないために

『アジャイル開発とスクラム 第2版』

著:平鍋健児 野中郁次郎 及部敬雄
発行:翔泳社(2021年)

This article is a sponsored article by
''.