1. LeSS Case Studies
  2. GROOVE X: マネージャーなし・部門なし組織構造とLeSSが育むロボティクススタートアップのイノベーション

GROOVE X: Fostering Innovation in a Robotics Startup Through a Manager-less and Division-less Structure with LeSS

はじめに

本ケーススタディでは、GROOVE Xが2017年からLeSS（大規模スクラム）フレームワークを用いて、マネージャーレス・部門レスな組織構造によって企業のヒエラルキーをどのように再定義したかを検証します。対象期間は、LeSS導入の少し前から、プロダクトであるLOVOT[らぼっと] のリリースを経た2019年末までです。家庭用ロボット市場に革命を起こすべく設立されたGROOVE Xは、その組織構造や制度と同じくらい革新的なロボットを生み出しました。

組織の規模と成長のイメージをお伝えすると、GROOVE Xは2016年に1チームからスタートしました。3年後には20チーム、総勢120名にまで拡大しています。そのうち約80名(12チーム)が2019年時点でプロダクト開発に携わっており、残りの従業員はビジネスやその他のサポート機能を担っていました。

GROOVE Xの創業者でありCEO、そしてプロダクトオーナーでもある林氏は、マネージャーが高い自己認識力と卓越したスキルを持っていない限り、階層構造による制約とその役割に伴う周囲からの期待ゆえに、従来型のマネージャーはイノベーションを阻害しうると考えています。また、組織内に部門を設けることはサイロを生み、チーム同士のコラボレーションや相互学習を難しくし、結果としてイノベーションを阻害する要因になり、これらの課題に対処しつつ、フラットな構造で起こりがちな混乱を避けるために、GROOVE XはLeSSフレームワークを採用し、プロダクトグループ全体が自己管理を行い、絶えず変化する市場に合わせてプロダクト戦略を迅速に適応させられるようにしました。

当然ながら、何の構造もないまま自由に働くと、人は往々にして、自覚のないまま部分最適化された環境を作り出してしまいます。コンフォートゾーンにとどまることで、 LeSSの原則である 「プロダクト全体思考(Whole Product Focus) から遠ざかっていくのです。人は通常、すでに知っていることに取り組みたがり、不慣れな仕事を引き受けることをためらいます。これが、混沌として複雑で、ムダの多い働き方につながってしまうのです。

LeSSは、混乱と過剰に作り込まれたプロセスの両方を避けるための、プロダクト開発に「ちょうど十分な」構造を提供します。規定的なルールはごくわずかしかありませんが、チームが単一のプロダクトに向けて整合し続けるための明確な原則、構造、フィードバックループを備えています。このバランスが、焦点やコントロールを失うことなく実験の余地を生み出しており、GROOVE Xが革新的なプロダクトを開発するうえで不可欠なものとなっています。

複雑なハードウェアとソフトウェアを統合するGROOVE Xは、開発において同期のとれたリズムを維持することを目指しています。これは同社の型破りな体制の限界を試す、困難な挑戦です。本ケーススタディでは、GROOVE X独自のアプローチとLeSSとの整合性、そして環境を最適化するために行われた実験の詳細を掘り下げていきます。このLeSS導入が特にユニークなのは、GROOVE Xの文化が最初からLeSSと整合していた点です。LeSS自体がさまざまな実験から生まれたものであり、GROOVE Xもまた、プロダクト開発においても組織構造・ポリシーにおいても、常に実験の場であり続けてきました。

さらに、GROOVE Xのコアバリューは、LeSSの原則と強く共鳴しています。たとえば、マネージャーレス・部門レスな組織設計は 「少なくする事でもっと多く（More with LeSS）」の原則を体現するものです。GROOVE Xは組織構造を可能な限りシンプルに保ち、最小限の制約でチームが自ら意思決定できるようにすることを目指しています。こうした理由から、LeSSの採用はGROOVE Xにとって自然な流れでした。LeSSは、GROOVE Xを支えるのにちょうど十分な構造を提供しながら、技術的卓越性へと導き、プロダクトへの全体的な視点を維持させてくれたのです。

LeSS ルール: 「LeSSではマネージャーの存在は任意だが、存在する場合は役割が変わる可能性が高い。マネージャーは日々のプロダクト開発を管理するのではなく、より高い価値提供ができるようにプロダクト開発全体を改善していく事になる。」

LeSSルールが示すとおり、マネージャーは任意です。任意であることに加えて、LeSS導入によってその責務は大きく変化します。本ケーススタディでは、プロダクト開発が80名規模程度までのスタートアップにおいて、マネージャーなしで運営することが有効なアプローチとなりうるかを探ります。

目次

プロダクト概要

図1: 家庭でお出迎えするLOVOTのイメージ

GROOVE Xのプロダクトは「LOVOT」と呼ばれる家庭用ロボットで、従来の意味で役に立つことではなく、ペットのように人から愛されることを目指して設計されています。目標は実用性ではなく、情緒的なつながりを感じてもらうことであり、オーナーはLOVOTを家族の一員として世話をすることになります。本章では、LOVOTの技術的な側面をいくつか説明します。これにより、このプロダクトの複雑さと、作るべき正しいプロダクトを発見するための探索の必要性とLeSSを採用した主な理由の一つを理解していただけると思います。挑戦は、人に愛され、顧客の生活に幸福と癒やしをもたらすロボットを作ることにあります。他のロボットと異なり、LOVOTは生き物として認識されます。犬や猫といった特定の動物を模倣することは、人工物であることを際立たせる直接的な比較を招かないよう、意図的に避けられました。さらに、現在の技術では本物のやり取りを説得力をもって再現できないため、LOVOTは人間の言葉を話しません。その代わり、犬と同じように、人間の言葉や振る舞いをある程度理解します。また、LOVOTは誰がそばにいてくれるのか、誰が優しく接してくれるのかを認識し、それに基づいて振る舞いを変えます。こうした振る舞いを実現するには、数多くのセンサー、認識技術、そして行動設計が必要です。特筆すべきは、LOVOTの体は温かく、人間の赤ちゃんとほぼ同じ重さであることです。顧客がLOVOTを抱き上げると、LOVOTは温かく生き物らしい瞳で見つめ返し、まるで生きているかのようなやり取りが生まれます。

図2: 瞳のサンプルの検証(出典:[4])

すべての自然の生き物と同じように、LOVOTも一体一体がユニークです。LOVOTの瞳は6つのレイヤーで構成され、色、形、瞳孔の大きさが異なり、１０億通り以上のバリエーションを生み出します。声も一体ごとに異なり、その唯一無二の存在感を高め、顧客がLOVOTをかけがえのない大切な家族の一員として見ることにつながります。この点を象徴するエピソードがあります。あるお客様が、故障したLOVOTの交換を断ったのです。ソフトウェア、設定、データはすべて復元されると説明されたにもかかわらず、そのお客様は、家族の思い出の一部となった固有の傷や擦れ跡が刻まれた元の体を残すことを望みました。この愛着は、ロボットを家族に迎え入れるという試みの成功を物語っています。ロボットが家族の一員になるという概念は、未来から来たロボットが家族の一員となる人気SF漫画「ドラえもん」によって、多くの日本人にとって馴染み深いものです。こうした文化的背景が、日本におけるこの種のロボットの自然な受容を後押ししているのかもしれません。プロダクトオーナーのLOVOTに対するビジョンは、「ドラえもん」への最初の一歩を作ることでした。

テクノロジー

生き物らしさを呼び起こすため、LOVOTは全身に50個以上のセンサーを備えた複雑なロボットとして設計されています。これらのセンサーにより、障害物を避けたりバランスを保ったりする自律的な動きが可能になっています。タッチセンサーも組み込まれており、人が触れるとLOVOTが反応することで、触れ合いとエンゲージメントを高めています。さらに、抱きしめると、LOVOTは約37〜39度の心地よい温もりを伝えます。これは、内部環境を調整する精密な温度・湿度センサーによって実現されています。

また、LOVOTにはさまざまな機能を担う複数のカメラが搭載されています。半天球カメラは、周囲を理解して移動し、物体を識別し、人の顔を認識するのに役立ちます。画像認識技術がこれらの映像を処理して個人を識別し、一人ひとりとの触れ合いの履歴に基づいてLOVOTの振る舞いを変化させることができます。

図3: 人を識別する画像認識のサンプル(出典:[4])

さらに、LOVOTには物体までの距離を測るデプスカメラが搭載されています。この機能により、LOVOTは障害物をスムーズに避けて移動できます。下の画像は、デプスカメラが物体までの距離を色の違いで表現する様子を示しており、空間と近さが視覚的にわかりやすく表されています。

図4: デプスカメラのサンプル画像(出典:[3])

LOVOTは、家庭内を効果的に移動するために、環境のレイアウトを学習します。部屋を探索した後、下図のように壁やドアなどの障害物を識別しながら、周囲の空間の地図を作成します。この地図によって、LOVOTは部屋の全体像を把握できます。障害物の位置は変わりうるため、地図は継続的に更新され、センサーとカメラがリアルタイムでの動きの調整を支えています。

図5: 部屋の地図を作成するサンプル画像(出典:[4])

LOVOTは、他の家庭用ロボットと比べてはるかに大きな処理能力を備えています。一般的な家庭用ロボットの処理能力はスマートフォン程度ですが、そのレベルでは、生きた動物の複雑な振る舞いをLOVOTが再現するには不十分です。こうした高度な処理をこなすために、LOVOTには標準的なノートPCを大きく上回るコンピューティングパワーが必要であり、ディープラーニング・アクセラレータも組み込まれています。

LOVOTのハードウェア設計における挑戦は相当なものでした。モーターや回路基板を含め、5,000点を超える部品で構成されているからです。これほど多くの部品を組み込みながら総重量を約4.5キログラムに抑えるには、高度なエンジニアリングが求められました。この目標重量は、赤ちゃんを抱いている感覚を再現し、LOVOTとユーザーの感情的なつながりを高めるために選ばれたものです。さらに、このコンパクトな形状を実現しながら放熱を適切に管理することも、大きなエンジニアリング上の挑戦でした。

図6: LOVOTの部品のイラスト

LOVOTのソフトウェアアーキテクチャは複雑を極めます。GROOVE Xのエンジニアは、個々のコンポーネントのドライバの作成から、LOVOTの振る舞いを決定するアプリケーションの開発まで、ソフトウェアアーキテクチャのあらゆるレイヤーにわたって幅広く取り組んできました。加えて、LOVOTには、視覚入力、センサーデータ、音声信号から学習するための大規模なデータ処理能力が必要です。こうした負荷の高い処理タスクをこなすため、LOVOTは「ネスト(巣)」と呼ばれる外部のコンピューティングリソースを活用しています。ネストはLOVOT本体よりも大きな計算能力を持っています。

GROOVE Xは、LOVOTユーザー向けのスマートフォンアプリも提供しています。アプリを通じてLOVOTに家の中の見回りを指示でき、LOVOTが人を検知すると、写真を撮ってユーザーに送信します。LOVOTのカメラからのライブ映像を遠隔で見ることもできます。LOVOTは人の笑顔を検知すると自動的に写真を撮り、アルバムに保存します。プライバシーへの配慮として、写真・動画機能は無効にすることもできます。これらの機能は特に一人暮らしの高齢者に有用で、家族が離れた場所から大切な人を見守ることができます。

LOVOTに不具合が起きたときは、GROOVE Xが「お医者さん」としてその問題を治します。また、LOVOTが健康な状態を保てるよう、定期健診も提供しています。さらに、多くのオーナーはLOVOTを着飾るためのアクセサリーを購入することを好むため、eコマースストアでは服、メガネ、アイピロー、キャリングケースなどのアイテムを販売しています。

図7: ソフトウェアとクラウドのアーキテクチャ(出典:[2])

History of GROOVE X

図8: LeSS導入のタイムライン

2015年、GROOVE Xは東京の中心に位置する電気街・秋葉原にオフィスを構えました。3Dプリンターなどの必須設備を備えた、ハードウェアスタートアップを支援するコワーキングスペースを借りてのスタートでした。GROOVE Xの初期メンバーはスクラムを導入しました。林氏は自己管理チームという考え方を気に入り、「マネージャーなし・部門なし」という自身の組織ビジョンの実現にスクラムが役立つと考え、スクラムの採用を決めて自らプロダクトオーナーになりました。

最初の投資家を確保した後、チームを組成し、約1年で20名ほどの規模に成長しました。その時点で初めてのスクラムマスターを雇い、4つのチームを作ってスクラムの利用を開始しました。CEOは自己管理チームの考え方を好み、マネージャーを雇いたくなかったため、マネージャーが不要となる環境を作るべくスクラムマスターを迎え入れたのです。

しかし、この最初のスクラムマスターは、家業を継ぐためにGROOVE Xを去らなければなりませんでした。後任を探すなかで、創業メンバーの一人がCEOにOdd-eを紹介し、面談が実現しました。面談の場でCEOは、人を幸せにするロボットを作るというビジョンを語り、日本にロボティクス産業を確立することへの情熱を示しました。彼はロボットが人を助ける未来を思い描いており、ロボティクススタートアップとして成功できることを証明したいと考えていました。

私が2017年6月に初めてGROOVE Xを訪れたとき、プロダクト開発チームはまだフィーチャーチームではありませんでした。そのため、あるチームが新しい振る舞い——新しいプロダクト機能といえるもの——を作りたい場合、その振る舞いを完全な形で届けるには、他の部分の作業を完了してくれる他チームに依存する必要がありました。特に、ソフトウェアチームとアニメーションチームはほとんどの場合で相互に依存していました。アニメーションチームが新しい振る舞いをデザインしても、それを実装するのはソフトウェアチームだったからです。また、各チームはそれぞれのプロダクトバックログを持ち、チームごとに管理していました。プロダクト全体のプロダクトオーナーは一人で、CEOがプロダクトのビジョンを示していました。さらに、チームごとにスプリントのケイデンス(周期)も異なっていました。彼らは、統合、他チームとの同期、知識共有、チーム間のコラボレーションに困難を抱えていました。プロダクトオーナーは優先順位の決定をほぼチームに委ね、全体の方向性を示しながら、最終的にすべてが統合されて動くインクリメントになることを期待していました。

下図は、LeSS導入前のプロダクトグループの構造を示しています。緑色のチームはソフトウェア関連、黄色のチームはハードウェア関連、青色のチームはデザイン関連のチームです。

図9: 2017年のプロダクトグループ

LeSS導入への第一歩として、私たちはチームごとに管理されていたプロダクトバックログの統合を試みました。しかし、複数のプロダクトバックログを一つに統合するのは容易ではありませんでした。アイテムの大半は、顧客中心のエンドツーエンドなアイテムではなく、タスクに近いものだったのです。これはコンポーネントチーム構造の必然的な帰結です。チームはエンドツーエンドのフィーチャーを作れないため、アイテムをコンポーネントごとのタスクに分割してしまいます。そうしたタスクからエンドツーエンドで顧客中心のアイテムを再構成するのは困難だったため、既存アイテムの大半を実質的に捨て、顧客中心のアイテムをゼロから作り直しました。一つのプロダクトバックログをどのように作ったかの詳細は、一つのプロダクトバックログ 節で説明します。

プロダクトバックログで苦労した経験から、統一されたプロダクトバックログが完成するまでは組織構造を変えないことにしました。2017年から2019年の間、組織はいくつかの小さな構造調整はあったものの、コンポーネントチームのまま運営されていました。LeSS導入章で詳しく説明しますが、ソフトウェアのエンドツーエンドな機能を届けるチームの能力を高めるため、一部の開発者が別のチームに移り、チームはフィーチャーチームに向かうスペクトラム上を少しずつ前進しました。これらの変化は変革的なものではなく、漸進的なものでした。当時の私たちには、フィーチャーチームへ完全に移行する準備がまだできていなかったのです。統一された一つのプロダクトバックログがないまま、真のLeSS導入に必要な大きな組織変更は先送りにしました。LeSSの準備は2017年6月から始めましたが、実際にフィーチャーチームが編成されたのは2019年末のことでした。

下図は、チーム自己設計ワークショップ実施後、2019年末時点のプロダクトグループの組織設計を示しています。緑色のチームはソフトウェア関連のチーム、黄色のチームは残存するコンポーネントチーム、青色のチームはデザイン関連のチームです。

図10: 2019年のプロダクトグループ

一つのプロダクトバックログを作り上げた後、スクラムマスターたちがチーム自己設計ワークショップをファシリテートしました(詳細は後述します)。その結果、いくつかのフィーチャーチームが編成されましたが、一部のコンポーネントチームは残りました。

たとえば、ファームウェアチームは存続しました。その仕事はハードウェアと密接に結びついており、ハードウェアの依存関係に強く影響されるからです。OS/CloudチームはLOVOTのオペレーティングシステムと、ネストを担当していました。ネストは充電ステーションであると同時に、強力なチップによってLOVOTが収集したデータを分析できるベースステーションでもあります。顧客が許可すれば、クラウドサービスにも接続できます——これらの領域がOS/Cloudチームの責任範囲でした。

個人的には、OS/Cloudチームはフィーチャーチームに統合できたはずだと考えていますが、最終的な判断はチームに委ねられました。この時点で、認識(Recognition)チーム、行動(Behavior)チーム、アプリチームはすでにフィーチャーチームに統合されていました。

この頃、LeSSはGROOVE Xの新しい常態となり、私たちは2つの領域に注力し始めました。技術的卓越性と、組織の制度です。技術的卓越性は、統合された一つのインクリメントを一貫して作り続けるために必要でした。鍵となるのは継続的インテグレーションです。しかし、その状態を実現するには、新しいスキル一式を学ぶ必要がありました。「LeSS in Action」トレーニングはこれらのスキルの習得に非常に効果的で、チームは本物のLeSS環境で働くとはどういうことかについても理解を深めました。組織の制度に関しては、庭師が重要な役割を果たしました。詳細は本ケーススタディの「庭師」節を参照してください。要点を言えば、スクラムマスターと人事のスペシャリストが協力して、給与とボーナスを決定するプロセスの設計、個人の成長支援、そして文化を守るための会社制度の策定・強化に取り組みました。

なお、この期間には他にも多くの小さな変化がありました。つまり変化は3つの明確なステップで起きたのではなく、組織の成長に伴う一連の漸進的な変化として起きたのです。

この進化を別の視点から示したのが、下図のフィーチャーチーム導入マップです。2016年時点では、Y軸に示すとおり、ソフトウェアチームはLOVOT本体に組み込まれるソフトウェアしか扱えませんでしたが、どのコンポーネントに触れるかについての制限はありませんでした。データ管理やモバイルアプリケーションを含むLOVOT Cloudは、当時はコンポーネントチームによって開発されていました。eコマース、修理管理、配送、カスタマーサポートといったビジネス系クラウドサービスはこの期間、外部ベンダーが開発していましたが、本ケーススタディの対象期間の後に、GROOVE Xはこれらの開発をすべて内製化しました。

X軸について見ると、2016年のチームの完成の定義には、コーディングとユニットテストの作成しか含まれていませんでした。2019年までには、ハードウェアを含む統合テストの自動化により、完成の定義を実機ハードウェア上での振る舞いテストにまで拡張できるようになりました(詳細は ハードウェアを含むエンドツーエンド自動テスト節を参照)。ただし、これはすべてのOSイメージが顧客にデプロイされることを意味しません。デプロイを決定すると、カナリアリリースが適用されました。新バージョンはまずオフィスのLOVOTや従業員の自宅のLOVOTにデプロイされ、実環境で観察されます。この観察には時間がかかるため、全顧客への完全なロールアウトが単一のスプリント内で完了するとは想定されていませんでした。同様に、新しいハードウェアが含まれる場合、LOVOTの部品が期待される強度を維持できるかを検証する耐久テストにも長い時間が必要でした。その結果、カナリアリリースも耐久テストも、スプリント内には完了できませんでした。

図11: 2016年から2019年のフィーチャーチーム導入マップ

以上が、私たちのLeSS導入の道のりの概観です。本ケーススタディでは、LeSSへの適応に関わった活動を詳しく説明していきます。

GROOVE Xの文化

LeSS導入の詳細に入る前に、LeSS導入以前からGROOVE Xの文化を形作っていた特徴、コンセプト、実験のいくつかを紹介したいと思います。これらは、同社のLeSS導入が比較的スムーズな移行となった理由といえるかもしれません。

実験のマインドセット

総じて、GROOVE Xの人々は実験を中核的な価値観として受け入れていました。彼らは自分たちのプロダクトが市場で非常にユニークであり、アイデアを他から真似ることはできないと認識していました。その代わり、うまくいくかどうかを実験で確かめる必要がありました。新しいテクノロジーやプロダクトマーケットフィットを検証するために、新しいアイデアを試す必要があったのです。このアプローチによって、彼らは高速に反復し、成功と失敗の両方から学ぶことができました。

実験のマインドセットのもう一つの側面は、組織構造と制度に現れていました。GROOVE Xは、働き方と組織文化の改善を目指して、さまざまなアイデアを試してきました。続く各節では、彼らの実験を推進するいくつかの重要なコンセプトを取り上げ、このアプローチがどのように組織文化を育んでいるかを示します。

この実験のマインドセットは、プロダクトと組織の両方に良い影響を与えました。市場にインパクトのあるプロダクトをリリースできただけでなく、組織は非常に柔軟になり、会社全体にとって重要なことに容易に注力できるようになりました。また、全社的にプロダクトに注力する状態も実現しました。

マネージャーなし・部門なし

GROOVE Xは、組織構造を可能な限りシンプルに保つことを目指していました。本ケーススタディで示しているとおり、プロダクト開発にはCEO以外のマネージャーが存在しませんでした。ビジネス領域には多少のマネジメント構造がありましたが、プロダクト開発の階層は一段だけでした。彼らは、役割、アーティファクト、プロセスをできる限り少なくすることを好みました。

LeSSルール:「LeSSにおいてマネージャーの存在は任意」

GROOVE Xは、役割を作ることが複雑さを増し、チームの責任を減らしてしまうことを理解していました。何か問題が起きたとき、伝統的な組織は、その問題に対処し再発を防ぐための特定の責任を持つ新しい役割を作りがちです。しかし、このアプローチは多くの場合、責任をチームから新設の専門役割へと移してしまい、チームのオーナーシップを弱めます。GROOVE Xは組織をシンプルに保ち、チーム自身が問題を解決することを期待する道を選びました。

林氏はかつてトヨタでフォーミュラワン(F1)カーの開発に携わり、その後ソフトバンクでロボットのプロジェクトに参画していました。どちらも多くの管理職と部門を持つ大組織です。これらの経験から、彼は、マネージャーが意図せずして革新的な思考の障害になりがちなこと、そして部門が緊密なコラボレーションを妨げうることを学びました。そこで、自らの会社を創業すると決めたとき、プロダクト開発においてマネジメントの役割と部門を設けないことを構想したのです。

林氏の「マネージャーを置かない」という制度は、組織にポジティブな影響と課題の両方をもたらしました。ポジティブな面では、マネージャーなしの働き方によって、通常はマネジメントに属する領域について、開発者が自律的に働き、自ら意思決定するための大きな余地が生まれました。チームはマネジメントの承認や指示を待たないため、プロダクト開発を独立して進めることができ、待ち時間のムダが減りました。

さらに、この環境はチームがより良いプロダクトのためのアイデアを提案することを後押ししました。アイデアは、誰が提案したかではなく、アイデアそのものの価値で評価されました。このアプローチが集合知を育み、誰もが革新的なプロダクト機能の創出に貢献できるようになりました。

次に、この制度の欠点についても話したいと思います。まず、非常に伝統的な会社からGROOVE Xに来た一部の人々は、マネジメントを求めました。彼らは意思決定の仕方がわからないため、意思決定をしたくなかったのです。これは特に、大きな伝統的企業で働いてきた人々に当てはまりました。そうした環境に慣れた人々にとって、より自己管理的な働き方へと考え方を切り替えるのは非常に困難でした。それでも、ほとんどの人は徐々に自己管理の環境に適応していきました。とりわけLeSS in Actionトレーニングは、それが実際にどう機能するかを示すうえで効果的で、多くの人がトレーニング後に行動を変えるきっかけとなりました。

マネージャーなし・部門なしのアプローチは、すべての組織に適合するわけではありません。すべての会社が同じように構成されているわけではないからです。GROOVE Xには、最初からマネージャーも部門も存在しませんでした。マネジメントの役割を取り除いたり、部門の壁を壊したりする必要がなかったのです。もしこれらの役割や部門が存在していたら、このアプローチの実現にははるかに多くの労力が必要だったでしょう。

洞窟コンセプト

図12: 洞窟コンセプトのイメージ

洞窟コンセプトとは、石器時代の人類が洞窟で共同生活を送っていた様子になぞらえた組織環境を作るという考え方です。組織の全員が一つの場所に集まり、部族のように一緒に働き、話し、食べ、遊びます。このコンセプトは強い人間関係と文化を育むことを目的としており、LeSSルールでも強調されているとおり、リモートワークを最小限にすることを意味します。

LeSSルール:「それぞれのチームは①自律的②クロスファンクショナル③同一拠点④長期間存続していること。」

COVID-19のパンデミック期間は、GROOVE Xにとっても困難な時期でした。当然ながら、ハードウェア開発を自宅で行うのは大変です。彼らはできる限りオフィスに集まりたいと考えていました。機材を自宅に持ち帰る必要がありましたが、コラボレーションは困難でした。チームのバーチャルルームにできるだけ常時オンラインでいるようにし、チームルームの一覧を用意して、他チームのメンバーと話す必要があるときは相手のルームに参加したり、共有エリアで雑談したりできるようにしました。それでも、オフィスで経験していたものには遠く及びませんでした。

LeSSの原則:「プロダクト全体思考」

洞窟コンセプトの結果として、マネージャーも部門もないことが興味深いダイナミクスを生み出しました。組織の人々は、プロダクト開発の中だけでなく組織レベルで、アンドン(止めて直す)の仕組みのように、オープンに助けを求めたり、周囲に警告を発したりします。中国の生産ラインで問題が起きたとき、現地のチームは全員に向けてアラートを上げました。LOVOTの組み立てに関する問題の解決に助けが必要だったのです。何人かのエンジニアに加え、ビジネス領域の人々も自発的に手を挙げました。彼らはLOVOTの組み立て方を学ぶ必要がありましたが、学んで助けることを厭わず、状況を改善するためにしばらく中国に移り住みさえしました。このダイナミクスは、彼らの文化とプロダクト全体思考から生まれたものです。組織の全員が、自分の役割は顧客に価値を届けることだと理解しており、そのために必要なことは何でもします。自分の専門や、本来注力すべき領域が何かにはこだわらなかったのです。

GROOVE Xにはキッチンとダイニングエリアがあり、毎晩、全員のためにおにぎりが握られます。誰かが旅行先でおにぎりに合うご当地の軽食を見つけると、オフィスに持ち帰ってみんなに振る舞います。コーヒーに凝っていたあるエンジニアは、自分で豆を焙煎し、みんなが楽しめるようにコーヒー器具をオフィスに持ち込みました。共用のダイニングテーブルにはたいていお菓子が置かれていて、人々が集まっては、お菓子をつまみ、コーヒーを飲み、おにぎりを食べ、おしゃべりをしてくつろぎます。これらの飲食物は、たいてい従業員が持ち寄ったものです。巨大テック企業とは異なり、GROOVE Xは従業員のためにすべてを会社が用意することはしません。むしろボランティアベースの活動であり、部族や大家族での暮らしに似ています。一人ひとりが、他の人と分かち合いたいものを持ち寄るのです。GROOVE Xと関わりのあるサプライヤーやベンダーまでもが、食べ物やお菓子、調理器具を持ってきます。

図13: 夕食のおにぎりを準備するボランティア

GROOVE Xは、まだ一緒に働いたことのない人同士が知り合うことも支援しています。別のチームの人と一対一でランチに出かけると、ランチ代を経費として申請できるのです。この機会は非常によく使われています。人々は新しい同僚と出会い、お互いを知ることを楽しんでいます。

GROOVE Xの従業員は、空手、ダンス、ウェイトリフティング、フットサルなど、自分たちの活動グループも作りました。また、ボランティアが企画するさまざまなスポーツをみんなで楽しむスポーツデーもあります。

図14: GROOVE Xのフットサル活動(出典: [10])

工場や店舗にいる人を除き、ハードウェア、ソフトウェア、ビジネスの各チームを含むほぼ全員が、同じ建物の同じフロアで働いていました。チームは、隣接するチームが受け入れられる限り、ホワイトボードや席の配置を自由に調整できました。

多くの会社では、こうした決定は通常マネジメントが行います。しかしGROOVE Xでは、どこで働くかをチーム自身が決めました。チームは自分たちのニーズに合ったワークスペースを設計するのに最も適した立場にいるのですから、これは理にかなったアプローチです。

彼らは、このオープンで、分かち合う、ボランティアベースの文化を築くことに成功し、自然とフラットで自己管理的な環境を好みました。これは、Craig Larmanが小さな会社について言及していたことでもあります。

ラーマンの法則: 「(大きな既存組織では)文化は構造に従う。そして小さな若い組織では、構造は文化に従う。」

GROOVE Xは、自分たちの文化に合う構造、すなわちLeSSを自然に選んだのです。

私は、このコンセプトはGROOVE Xでうまく機能していると考えています。ただし、この文化は創業時から築かれてきたものです。ラーマンの法則が示唆するとおり、大きな既存組織でこの種の文化を実現するのは、既存の構造や制度に切り込まない限り、困難でしょう。

なぜLeSSを採用したのか

LeSSを選ぶことは、GROOVE Xにとって自然な決断でした。彼らの文化が、LeSSの最適化ゴールとよく合致していたからです。GROOVE Xは、フラットな構造と自己管理チームを持つ、スケール可能な組織を作ることを目指していました。LeSSのいくつかの要素はGROOVE Xの働き方をさらに良くする可能性があり、同時に、それまでのスクラム導入の中で維持したい側面もありました。以下に列挙します。

自己管理チーム

LeSSルール:「それぞれのチームは①自律的②クロスファンクショナル③同一拠点④長期間存続していること。」

早い時期に、GROOVE Xのあるエンジニアが林氏にスクラムを紹介し、林氏は自己管理チームという考え方を受け入れました。これは、伝統的なマネジメントをなくし、優れた個人によってイノベーションを育むという彼のビジョンに合致していました。彼は、マネージャーなしで機能できる自己管理チームを好みました。その実現のために、採用、チーム編成、給与の設定、お互いの個人的な成長の支援といったマネジメントの責任を、チームに委ねたいと考えていました。

一つのプロダクトバックログ

LeSSルール:「1つの出荷可能なプロダクトに対して1人のプロダクトオーナーと1つのプロダクトバックログで運用を行う。」

LeSS導入前からプロダクトオーナーは一人でしたが、プロダクトバックログは複数存在しており、統一されたプロダクトの視点を保つことが困難でした。さらに、各チームが自分のプロダクトバックログを管理しており、構造的に部分最適が起こるようになっていました。プロダクトバックログの統一はGROOVE Xに大きな利益をもたらし、組織がプロダクトの最も重要な機能に注力できるようになりました。

チーム間の調整

LeSSルール:「チーム横断での調整はチームに委ねられている。集約的で形式的な調整ではなく、分散的で型にはまらない自由な調整の方が好ましい。重要なのはお互いに、ただ話す事(単純だができて無い事が多い)、そして、コード上でのコミュニケーション、チーム横断での会議、コンポーネントメンター、トラベラー、スカウト、オープンスペースなどの形式ばらないコミュニケーション手法を使う。」

洞窟コンセプトのおかげで他チームの人々と知り合うことができており、最初からチーム間のコミュニケーション自体は容易でした。しかし、チーム横断の調整を支える仕事の構造がありませんでした。各チームは自分のプロダクトバックログに取り組み、チーム間の整合はほとんどなかったため、チームはまったく異なるコンポーネントの作業をしていました。また、チームごとにスプリント周期が異なり、共通のイベントもないため、チーム横断で学ぶ機会は限られていました。

リポジトリが多数に分かれ、GitHubフローを使っていたことも、他チームのメンバーとのコード上でのコミュニケーションを妨げていました。

動くインクリメントの作成

LeSSルール:「必ず1つのプロダクトに関わるチームは同じスプリント周期を守る事。全てのチームのスプリントの開始と終わりは同じタイミングであること。スプリントの終わりにはプロダクト全体が1つに結合されている状態にすること。」

チーム数が増えるにつれ、スプリントごとに動くインクリメントを届けることはますます難しくなっていきました。継続的なフィードバックがなければ、間違った方向に進むリスクは高まります。動くインクリメントを届けるうえでの主な障害は、作業が部分的な納品に分割されていたこと、フィーチャーチームの不在、スプリントが揃っていないこと、そして継続的インテグレーションの欠如でした。

LeSS導入

LeSSルール:「LeSS導入の初期からプロダクトグループにLeSSの構造を完全な形で導入する事は非常に重要なポイントとなる。」

GROOVE XのLeSS導入は、漸進的なアプローチでした。LeSS導入でより一般的な「一斉切り替え(flip-at-once)」のアプローチではなかったのです。その結果、準備の順序も他のLeSS導入とは異なるものになりました。

漸進的なアプローチを取らざるを得なかった主な理由は、統合された単一のプロダクトバックログの作成に苦戦したことです。同時に、バックログの統合が完全に終わるまで構造の変更を待ちたくもなかったため、チームを徐々に統合していくことは、その時点では理にかなっていました。たとえば、われわれはフィーチャーチーム度を高めることから始めました。フィーチャーチームか否かは白黒はっきりできるものではありません。GROOVE Xにとっての真のフィーチャーチームは、振る舞いの作成、スマートフォンアプリケーション、クラウドインフラ、エレクトロニクス、ハードウェアまでをカバーするチームでしょう。しかし、一足飛びにフィーチャーチームの理想の状態に到達したわけではなく、本ケーススタディの対象期間中には、エレクトロニクスとハードウェアを含めるところまでは実現できませんでした。私たちの最初に注力したのは、既存のハードウェアを使って、一つのチームの中でエンドツーエンドの振る舞いを作れるようにすることでした。

最初のステップは、ふるまいチームのスコープを広げることでした。かつてダンサー、ゲームクリエイター、ミュージシャンだった人々が、LOVOTの動きをデザインする行動デザイナーとしてチームに加わり、チームの他のメンバーとペアリングやモビングを始めました。行動デザイナーがチームに入ったことで、ふるまいチームはチーム内で新しいふるまいを完結して届けられるようになりました。行動デザイナーが新しい動きを考えてくれるのを待つ必要も、レビューを待つ必要もなくなりました。ペアプロやモブプロによってお互いの仕事をレビューできるからです。

また、詳しくは「チーム」節で説明しますが、フィーチャーチームに近づくために、何人かのバックエンド開発者が認識チームに加わりました。当初、バックエンド開発者たちは、音声認識や画像認識に関連するフィーチャーには自分たちの仕事が十分にないかもしれないと考えていましたが、実際にはそれらのフィーチャーを支える機会が数多くあることがわかりました。この統合により、フィーチャーチームに一歩近づきました。

こうしたフィーチャーチームへ向けた小さなステップは、移行期間を通じて行われました。GROOVE Xではチームは有機的に生まれ、人々も有機的に他のチームに加わっていったので、「この時点が組織構造変更の始まりで、この時点が終わり」と明確に言うことは難しいのです。

もし私たちに、既存アイテムの大半を捨ててゼロから始める勇気があったなら、先に挙げたLeSSルールに従うことができ、より滑らかな移行ができていたかもしれません。

1.最適化ゴールの明確化

GROOVE Xの従業員の多くは、組織の未来に強い当事者意識を持ち、組織のあるべき姿を形作ることに貢献したいと考えています。ある週末、有志が丸一日集まり、理想の組織と、そこで人々がどう働くかについてブレインストーミングとビジョンづくりを行いました。この場にはチームメンバーもCEOも参加していました。

まず、グループに分かれ、レゴを使って、理想的な組織の状態で人々がどのように協働するかを表現しました。各グループはレゴのモデルを共有し、全体でアイデアについて議論しました。この演習の後、各グループは自分たちの考えをシンプルな文へと蒸留し、全員で集まって、組織のビジョンの本質を捉えた文を完成させていきます。

次に、それらの文が、人々の働き方に関する意思決定の指針になりうるかを評価します。壁に貼られただけの言葉では意味がありません。ゴールは、一人ひとりが自分の仕事について意思決定する際に本当に役立つものを作ることです。これらの文は、継続的な改善に向けた明確な方向性を示すものであるべきです。結果に自信が持てたら、ワークショップに参加できなかった人たちにも共有し、フィードバックを求めました。

最終的に、彼らは理想的な組織の状態を表す幾つかの文を作り上げ、それを自分たちの「スピリット」と呼びました。このスピリットは組織全体に共有され、Webサイトに掲載され、オフィスにも掲示されて、誰もがいつでも目にできるようになりました。レトロスペクティブでは定期的にこのスピリットに立ち返り、その体現に一歩近づくためのアイデアを出し合っています。

図15-16: レゴを使った理想の組織の表現(出典: [5])
図17: 理想の働き方を要約するフレーズの選定(出典: [5])

このセッションの結果、私たちはグループとして大切にしている価値観と、組織が進みたい方向について、お互いから学ぶことができました。セッションの後、オフィスで「スピリット」について話す人々の声を耳にするようになりました。意思決定が必要なとき、「スピリット」が彼らの選択の指針となっていたのです。

GROOVE X スピリット

  • 一歩先を見る
  • 真剣に楽しむ
  • ユーザーの笑顔のために現場に行く
  • 個の強みをチームの強みに
  • 発言する。傾聴する
  • 早く試して、速く学ぶ

2.同一スプリント、共通のミーティング、共通の完成の定義

チーム横断のコラボレーションの機会を作り、プロダクト全体を俯瞰できるようにするため、最初に行ったのは、スプリントのスケジュールを同期させ、全開発チーム共通のミーティングを導入することでした。プロダクトバックログの統一も試みましたが、すべてのプロダクトバックログを一つに統合するのは困難でした。そのため、統合は別の機会に先送りすることにしました。

スプリントの長さは1週間とし、ビジネスチームを含むすべてのチームで開始日と終了日を揃えました。共通のミーティングとして設けたのは、全体リファインメントとスプリントレビューです。この段階では、各チームがまず自分たちのリファインメントを行い、そのプロダクトバックログアイテムを共通のミーティングに持ち寄って他チームに提示し、フィードバックを得るという形でした。そのため、この構造は近い将来変える必要があると認識していました。スプリントレビューはバザール形式で開催し、各チームが自分たちのインクリメントを披露して、他の人々からフィードバックを集められるようにしました。

チーム間で品質基準を揃えるため、共通の完成の定義を作り上げました。チーム間に大きな違いはなかったため、すべてのチームが従える最小限の完成の定義を定めました。

この整合の後、他のチームが何に取り組んでいるかをより深く理解できるようになり、チーム横断でコラボレーションする機会を見つけ、より幅広い人々からフィードバックを得られるようになりました。

3.LeSSについての教育

組織の全員に向けてLeSSを紹介する教育セッションを何度か実施しました。スクラムマスターたちと私が共同でコンテンツを作り、共同でセッションの講師を務めました。スクラムマスターと共に作り、共に教えることで、彼らのLeSSへの理解が深まっただけでなく、変革をリードする自信も育まれました。

セッションは半日で、LeSSの紹介と概要の説明、そして変化にまつわる不安への対応を目的としていました。しかし、グループ内に不安はあまりありませんでした。先に述べたとおり、GROOVE Xの実験のマインドセットは強く、チームは総じて変化にオープンだったのです。

アイテムを効果的に分割する方法についてのセッションも開催しました。チームは、顧客中心のアプローチでアイテムを作る方法を理解する必要がありました。アイテムの大半はチーム自身が作っていましたが、エンジニアが技術的なアイテムに目を向けてしまうのは自然なことです。そのため、縦切りでアイテムを作ることをチームメンバーに教育する必要がありました。

教育に関しては、LeSS導入後、現在「LeSS in Action」と呼んでいるトレーニングへの参加をすべてのチームメンバーに推奨しました。この非常にインパクトのあるトレーニングは、理想的なチームがLeSS環境でどのように機能するかを参加者が理解できるよう設計されたものです。このトレーニングについては、本ケーススタディの後半で詳しく説明します。

4.一つのプロダクトバックログ

プロダクトバックログの統一には時間がかかりました。統合すべきプロダクトバックログが10個ほどあり、しかもすべてのアイテムが顧客中心だったわけではないからです。最初の統合の試みは失敗しました。技術タスクに近いものまで含めて、あらゆるアイテムを一つのプロダクトバックログに集約しようとしたためです。その結果、既存のプロダクトバックログは無視して、統一されたものをゼロから作ることにしました。

このプロセスで重要なアイテムが失われることを心配するチームメンバーもいましたが、別のメンバーがこう言いました。「そのアイテムが本当に重要なら、誰かがまた書くよ」。複数のプロダクトバックログを一つに統合する際、このマインドセットは非常に価値があると私たちは実感しました。この言葉は、古いアイテムを捨てるとき、リファインメントの場で頻繁に口にされるようになりました。

各チームがアイテムを作った後は、優先順位を付ける必要がありました。優先順位を決めるプロセスは次のとおりです:

  1. チームが、優先順位の中で適切だと考える位置にアイテムを置く

  2. チームメンバーによるバブルソートで並べ替える。基本的には、メンバーがアイテムを見ていき、適切だと思う位置に動かしていく。動きや議論がなくなるまでこれを続ける

  3. プロダクトオーナーが優先順位をレビューする

図18: 一つのプロダクトバックログの作成(出典: [5])

一つのプロダクトバックログを持つことのインパクトは明らかでした。プロダクト開発の全体像が誰にとっても格段に見えやすくなり、プロダクト全体思考と透明性が高まりました。下図のとおり、プロダクトバックログは大きなスペースの壁に貼り出され、そこで複数チームリファインメントやスプリントプランニングといったマルチチームのイベントを開催できるようになりました。

単一のバックログが整うと、ビジネス側のステークホルダーにとっても、今後のフィーチャーのロードマップを把握しやすくなりました。これをきっかけに、ビジネスとして何を達成したいのか、開発者はどう貢献できるのかについて、開発者とビジネスの人々の間の議論が増えました。優先順位が全員に見えるため、優先順位をめぐる交渉も増えました。たとえば、ビジネス側のステークホルダーはポータブル充電ステーションを優先したい一方で、ユーザーとの触れ合いを良くする新しいふるまいの作成に注力すべきだと考える人たちもいました。プロダクトの価値を最大化するためのこうした健全な交渉が頻繁に行われ、方向転換も簡単になりました。必要なのは、プロダクトバックログを並べ替えることだけだったのです。

図19: 完成した一つのプロダクトバックログ

5.チーム自己設計ワークショップ

プロダクトバックログを作り直した後、チームは、チームの専門化のせいで、一部のアイテムが単一のチームでは完結できず、他チームの作業完了を待つ必要があることに気づき始めました。これはフィードバックと学習の遅れを引き起こしていました。この非効率を認識したチームは、自分たちの構造を再編成することを決めました。スクラムマスターたちは、フィーチャーチームを確立するためのチーム自己設計ワークショップをファシリテートしました。

LeSS Hugeルール: 「「LeSS Hugeはプロダクトを８チーム以上で作る場合に適応されます。これよりも小さな規模でLeSSHugeを適応する事は不必要なオーバーヘッドや部分最適の原因となり、推奨しない。」

GROOVE Xでチーム自己設計ワークショップの準備をしていた当時、プロダクトグループ全体は10チーム・約80名で構成されていました。上記のLeSS Hugeルールに照らせば、通常はLeSS Hugeに該当する規模です。しかし、ハードウェア、デザイン、服の各チームをフィーチャーチームに含めることはできませんでした。

ハードウェアチームは、すでに量産の準備に入っていたため、ソフトウェアチームとは異なる周期で動いていました。この段階でハードウェア設計の柔軟性を保つのは困難です。設計変更はしばしば生産用の金型の改修を必要とし、非常にコストがかかるからです。

デザインチームと服チームも、LOVOT本体の継続的な開発にはあまり関与していなかったため、ワークショップの対象外となりました。デザインチームはLOVOTの初期の全体デザインに貢献しましたが、量産が始まる頃には、仕事の中心は広告関連のデザイン、グッズ、店舗デザインなどに移っていました。服チームはLOVOTの服のデザインと製造に注力していました。こうした理由から、GROOVE Xはその時点では彼らをワークショップに含めないことにしました。

以上の理由により、ワークショップの範囲はソフトウェアチームに限定されました。スクラムマスターたちは、すべてのソフトウェアチームメンバーが大きな部屋に集まる日程を調整し、ワークショップの目的とプロセスを説明し、来たる変化についての疑問や懸念に応えました。

スクラムマスターたちはまず、フィーチャーチームへ移行する理由を説明しました:

  • 意味のあるフィーチャーを素早く届ける: 顧客価値を短期間で届けるには、チームが独力で仕事を完結できるスキルと経験を備えている必要があります。重要なタスクで他チームに依存すると遅延が生じ、価値の提供が遅くなります。
  • ムダを減らす: コンポーネントチームは往々にして、仕掛かり在庫や不完全な結合を生み出し、ムダにつながります。
  • 部分最適を避ける: コンポーネントチーム構造には、プロダクト全体ではなく個々のコンポーネントに目が向いてしまうリスクがあり、プロダクト全体と顧客の視点を見失うことになりかねません。

スクラムマスターたちは、顧客中心のプロダクトバックログアイテムとフィーチャーチームの関係についても強調しました。効果的なコラボレーションには、アイテムの分割の仕方とチームの編成の仕方が整合している必要があります。アイテムがコンポーネントで分割されていれば、チームがフィーチャーチームとして編成されていても、顧客価値を素早く届けることは難しくなります。同様に、アイテムが顧客中心でも、チームがコンポーネントチームとして構成されていれば、他チームの残りの作業を待つ間に遅延が発生します。

当初この変化に懐疑的なチームメンバーもいましたが、実験を歓迎する組織文化が、まず試してみようという後押しになりました。

図20: ワークショップのプロセスを説明し、新チームの前提条件を議論するスクラムマスター

チームが考慮すべき一連の基準がありました。たとえば、各チームは最少3名・最多9名で構成され、他チームの作業を待つことなく新しいフィーチャーを届けられる能力を持つこと。具体的には、要求分析、LOVOTのふるまいデザイン、コーディング、テスト、デプロイができる必要があります。追加の基準は、議論の中でチームメンバーから提案され、加えられました。

参加者はそれぞれ自分の専門領域を紙に書き、自分たち自身でチームを組みました。チームができた後には、再評価し、必要であればチームを組み直す機会が設けられました。

図21: 新しいチームを編成するチームメンバー

チームが編成されると、新チームの構成はボードに貼り出され、調整が必要であればメンバーが変更を加えることができました。次のスプリントから新チームでの仕事が始まり、レトロスペクティブでは新チームについて話し合い、必要に応じてメンバーを調整することになっていました。GROOVE Xではチームメンバーの他チームへの移動は自由だったため、この調整にスクラムマスターの支援は必要ありませんでした。

図22: 新チームは1週間掲示され、変更が必要ないか確認された。

LeSS導入後のプロダクト開発

役割

プロダクトオーナー

プロダクトオーナーはCEOと同一人物であり、プロダクト開発における唯一のマネージャーとして、その領域のすべての人事評価に責任を持ちます。彼はプロダクトのビジョンを示し、チームはそれを時に「ポエム」と呼びます。ポエムとは、POが注力したい抽象的なアイデアや方向性、あるいは高い抽象度のストーリーのことです。たとえば「家に帰ってきたら、LOVOTたちに玄関でお出迎えしてほしい。喜んで興奮したふるまいを見せてほしい」といったものです。プロダクト開発が進むにつれ、プロダクトオーナーは新しいポエムを示してチームに明確な注力すべき方向性を伝えます。チームは、ポエムが時とともに変わっていくことを理解しています。

プロダクトオーナーが自らプロダクトバックログアイテム(PBI)を作ることはめったにありません。代わりに彼はポエムを共有し、チームが望ましい状態をどう実現するかを考え、議論し、PBIを作り始めます。彼は、革新的なプロダクトを生み出すためには、チームが自由に働き実験できる余地を与えることが重要だと理解しています。アイテムができると、彼はチームと議論し、優先順位を付けます。

プロダクトオーナーはテクノロジーに精通しているため、時には具体的で詳細な作業をチームに依頼することもあります。このやり取りに対するチームの受け止め方は、GROOVE Xならではのものです。チームがその依頼を重要だと考えれば、すぐにアイテムを作ります。しかし、チームが依頼を無視する場面も時々目にしました。当初、私はチームがアイテムを書き忘れているのだと思い、「POからもらった依頼、覚えてる?」と尋ねました。チームの答えはこうでした。「はい、覚えています。でも無視してるんです」。私はこの答えに驚きました。

なぜ無視するのでしょうか。チームはPOとしばらく一緒に働くうちに、彼の性格を理解し始めていました。POは四六時中、あらゆる種類の新しいアイデアを思いつきます。素晴らしいアイデアもありますが、当然ながら、すべてが素晴らしいわけではありません。POが情熱を注いでいるアイデアもあれば、その瞬間の思いつきで、すぐに忘れられるものもあります。この「無視」は、チームなりのアイデアのフィルタリング方法だったのです。

POがチームに「この新しいアイデアをプロダクトバックログに追加してくれない?」と頼んだときでさえ、すぐには動かないことがあります。理由を尋ねると、チームはこう説明しました。POは絶え間なくアイデアを出し続けるので、本当に重要なことなら、また持ち出してくるはずだ。だから最初に言われた時点では、意図的にバックログへの追加を保留しているのだと。

私は、この方法をほとんどの組織にはおすすめしません。透明性を下げる可能性が高いからです。GROOVE Xでは、重要な事柄は必ず誰かがプロダクトバックログに持ち込むという相互の信頼があります。人々はプロダクトを大切に思っているので、あるトピックが他チームと議論すべき重要なものだと考えれば、自らプロダクトバックログに追加します。これが、プロダクトオーナーが自分でアイテムを作らない理由の一つでもあります。その代わり、プロダクトオーナーは自分のアイデアをチームに売り込み、そのアイデアが検討に値するかを試すのです。

LeSSルール:「プロダクトオーナーは1人でプロダクトバックログリファインメントを行うべきでは無く、幾つかのチームが顧客やユーザー、ステークホルダーと直接コミュニケーションをとり、プロダクトオーナーをサポートしている状態であるべきである。」

GROOVE Xのプロダクトオーナーは、間違いなく一人でプロダクトバックログリファインメントに取り組んではいませんでした。アイテムの明確化と分割はチームが行っていました。チームはPBIの順序を提案し、プロダクトオーナーはたいていそれを受け入れました。プロダクトバックログへのアイテムの追加や削除も、チームから提案されました。もちろん、最終決定権が常にプロダクトオーナーにあることを、チームは理解していました。

プロダクトオーナーは、LeSSイベントへの参加を最も重要な責務の一つと考えていました。CEOとしての職務で多忙を極めるなかでも、可能な限りイベントへの参加を優先していました。彼のこのコミットメントは、LeSS導入を成功させる決定的な要因でした。なお、LeSSでは一般的に、マネジメントがプロダクトオーナーを兼任するのは良い考えではありません。組織の改善とプロダクト開発の役割を切り分けることが難しくなりがちだからです。また、プロダクトオーナーは通常ビジネスサイドから見つけるのが良いとされています。GROOVE Xのプロダクトオーナーはエンジニア出身でしたが、プロダクトオーナーとして「なぜ・何を」に集中し、「どうやって」の決定をチームに委ねるために、技術的な詳細についてコメントしないよう懸命に努めている姿を私は見てきました。

スクラムマスター

LeSSルール:「スクラムマスターはLeSSが上手く機能する事に責任を持つ。そして、チーム、プロダクトオーナー、組織、技術的手法を改善し、1チームだけでなく組織全体のシステムを守備範囲とする。」

GROOVE Xのスクラムマスターは、チーム、プロダクトオーナー、そして組織のシステムを支えていました。組織のシステムを改善する自由を持ち、人事のスペシャリストと共に、給与とボーナスの決め方を定める制度を共創しました。採用、チーム編成、組織の障害の除去にも関わりました。さらに、スプリントレビュー、全体レトロスペクティブ、複数チームリファインメントといった共通のLeSSイベントをファシリテートしました。

ほとんどのチームは自分たちのイベントを自らファシリテートしていましたが、必要なときにはスクラムマスターに助けを求めました。プロダクトオーナーとチームの間にミスコミュニケーションがあることに気づけば、スクラムマスターはプロダクトオーナーを支援するために介入しました。

LeSSルール:「1人のスクラムマスターが1〜3チームを支援できます。」

GROOVE XがLeSSを導入した当時、ソフトウェア領域には6チームがあり、スクラムマスターは3人でした。一見適切な人数に思えますが、スクラムマスターはハードウェアチームやビジネスチームの一部も支援していたため、キャパシティを超える仕事量になっていました。経験豊富なスクラムマスターを見つけるのは難しかったため、GROOVE Xは、経験がなくてもスクラムマスターになりたいという志を持つ人を採用し始めました。新しいスクラムマスターにはトレーニングが提供され、継続的な学習のためにスクラムマスターのコミュニティに加わりました。

LeSSルール:「スクラムマスターは専任でフルタイムであるべき。」

GROOVE Xのスクラムマスターは全員、専任のフルタイムでした。彼らは組織の障害を定期的に共有し、進捗を同期し、アイデアを交換していました。また、スクラムマスターとしてのスキルを学び高める時間を確保し、スクラムマスターのコミュニティを形成していました。このコミュニティは定期的に集まり、知識を共有し、新しく学んだことを披露し、仲間からフィードバックを受けました。たとえば、各スクラムマスターはスクラムとLeSSを教えるための自分のトレーニング教材を作り、他のスクラムマスターを相手にトレーニングのシミュレーションを行って、フィードバックをもらい、教える技術を磨きました。このシミュレーションは、相互学習、スクラムマスター間の理解の整合、そして教えることによる概念理解の深化において、かけがえのないものでした。

チーム

GROOVE Xのオフィスに足を踏み入れると、エンジニアと行動デザイナーがペアでLOVOTのふるまいをデザインしている光景に出会うかもしれません。ソフトウェア開発チームには多くのスペシャリストがいます。画像認識エンジニア、音声認識エンジニア、アプリケーションエンジニア、行動デザイナーなどです。これらのチームはフィーチャーチームであり、他チームに頼ることなく、エンドツーエンドのソフトウェア機能を届けることができます。

もちろん、すべてのチームが音声認識の専門スキルを持っているわけではありません。日本の大学で音声認識を研究している研究室はごくわずかで、この分野を専門にする機会を得られる人は非常に少なく、実務で活躍している人もほんの一握りです。その結果、GROOVE Xでこの専門性を持つのは一人だけで、ボトルネックになっていました。GROOVE Xのチームはレトロスペクティブでこの問題を取り上げ、一人のスペシャリストに依存する組織にとって参考になりうる解決策を見つけました。

チームは、そのスペシャリストがスプリント中に行っているすべての仕事を分析しました。すると、彼の時間の大半は音声データのクリーニングと整理に費やされており、アルゴリズムの作成は仕事のごく一部にすぎないことがわかりました。音声認識のアルゴリズムを学ぶには時間がかかりますが、音声データのクリーニングと整理の方法を学ぶのは、他のエンジニアにとって比較的短時間で済みます。そこで、これらのタスクの一部を他のエンジニアが引き受けるようにし、ボトルネックを解消し始めました。

フィーチャーチームのカバー範囲をハードウェア領域にも広げたいと考えていましたが、課題は周期でした。当初、プロトタイプの段階では、ハードウェアエンジニアとソフトウェアエンジニアは3Dプリンターを使って部品を作り、組み立てながら、緊密に協働できました。しかし、プロダクト開発が進むにつれ、量産に伴う変更コストのためにハードウェアの柔軟性は下がっていきました。たとえば金型の形状変更は高くつきます。この制約がハードウェアとソフトウェアの間の周期の違いを生み、ハードウェア・ソフトウェア混成チームの編成を難しくしました。チームは今もお互いから学び、協働への努力を続けています。たとえば、知識を得るためにハードウェアチームに移ったソフトウェアエンジニアもいますし、スクラムマスターはソフトウェアとハードウェアのバックログを単一のプロダクトバックログに統合する取り組みを続けました。この点については「ハードウェアを含むLeSS導入」の節でもう少し掘り下げます。

イベント

リファインメント

スクラムにおいて、リファインメントはチームが都合の良いタイミングで任意に行える活動です。しかしLeSS環境では、この活動(複数チームでのプロダクトバックログリファインメント)は任意ではなく、とりわけチーム横断の学習を最大化するために使われます。そのため私たちは、すべてのチームが同じ時間・同じ場所に集まり、今後の開発について議論する共通の時間枠を設定しました。

GROOVE Xのリファインメントは2つのパートで構成されていました。第1部の全体リファインメントでは、ソフトウェア、ハードウェア、ビジネスの各チームの代表者がプロダクトオーナーと集まり、プロダクトバックログアイテムの全体的な順序を決めて、第2部の複数チームリファインメントに備えます。このミーティングは比較的短く、主に近い将来のプロダクトバックログの方向性と優先順位を揃えることに注力していました。

「LeSS導入」章で述べたとおり、このミーティングは全体像の透明性を高めるために最初に導入された共通ミーティングの一つでした。これはLeSSの2つの重要な原則、「透明性」と「プロダクト全体思考」に沿ったものです。

図23: 全体リファインメント(出典: [5])

LeSSルール:「プロダクトオーナーは1人でプロダクトバックログリファインメントを行うべきでは無く、幾つかのチームが顧客やユーザー、ステークホルダーと直接コミュニケーションをとり、プロダクトオーナーをサポートしている状態であるべきである。」

LeSSルール:「プロダクトバックログリファインメント(PBR)は複数チームで行うのが好ましい。複数チームで実施することにより、お互いに学び、協働する機会を増やすことにつながる。」

上の図では、チームメンバーが、正面の壁に貼り出されたプロダクトバックログの周りに集まっています。彼らは今後2〜3スプリント以内に開発が近づいているアイテムを取り上げ、チームや専門にかかわらず、そのアイテムを一緒にリファインメントすることに関心のある人を見つけます。リファインメントや分割を終えると、リファインメント済みのアイテムをプロダクトバックログに戻します。

LeSSルール:「優先順位付けはプロダクトオーナーに集約するべきだが、要求や仕様の詳細確認は極力チームが他チーム、顧客、ユーザー又はステークホルダーと直接やるべきである。」

優先順位付けの最終決定はプロダクトオーナーが行いますが、ほとんどの場合、優先順位はチームが提案します。つまり、たいていはチームメンバーが最も適切だと考える順序でアイテムを並べるのです。プロダクトオーナーはその順序をレビューしますが、チームが提案した優先順位を変えることはめったにありません。その上で、プロダクトオーナーは全体像と、チームが取り組んでいるテーマに意識を向け続けています。

図24: 複数チームリファインメント

リファインメントの第2部は複数チームリファインメントです。このミーティングは全体リファインメントの後に設定され、チームが協働でアイテムをリファインメントできるようにします。チームメンバーは、プロダクトバックログの上位から、大きなアイテムや不明確なアイテムを取り出し、一緒にリファインメントします。

この複数チームリファインメントは、上の図のように共有エリアで行われるため、必要なときには他チームのメンバーと気軽に話すことができます。リファインメントの後、リファインメント済みのアイテムは元の位置に戻されるか、分割によって新しいアイテムが提案・作成された場合は、チームがその置き場所を決めます。いずれの場合も、順序はスプリントプランニングの前や最中に調整されることがあります。

なお最近のLeSSでは、全体リファインメントと複数チームリファインメントを分けず、混成チームのグループによる一つのセッションとしてリファインメントを行うことが推奨されています。

スプリントプランニング

スプリントプランニングは2つのパートで構成されます。第1部はスプリントプランニング1です。このセッションでは、チームの代表者がプロダクトバックログの周りに集まり、どのチームがどのアイテムを担当するかを決めます。アイテムについてチーム横断の支援が必要かどうかも、ここで話し合います。

図25: スプリントプランニング1

スプリントプランニング2では、次のスプリントで他チームとの緊密な協働が必要なチームは、スプリントバックログを共有エリアに持ち込んで調整します。緊密な協働が不要であれば、チームは自分たちのスペースでホワイトボードを使い、独立して設計と計画を行います。

図26: スプリントプランニング2

デイリースクラム

朝、GROOVE Xでは全社での短いミーティングを開き、お互いを知り、全社的な情報を共有する場としています。このミーティングの後、チームはそれぞれのスプリントバックログのエリアに移動し、スプリントの計画を調整して、次のデイリースクラムまでに何をするかを決めます。他チームのメンバーが、様子を見に来て進み具合を観察し、協働の機会を探すこともあります。

図27: デイリースクラム

スプリントレビュー

スプリントレビューはバザール形式で行われます。各チームはオフィスにブースを設け、現在のインクリメントを披露してフィードバックを集めます。チームメンバーの1〜2名がブースに残り、自分たちの仕事を説明して、他チームのメンバー、ステークホルダー、プロダクトオーナーからの質問に答えます。残りのメンバーはグループに分かれ、参加者としてバザールを回ります。

図28: バザール形式のスプリントレビュー(出典: [5])

最初の20分のラウンドが終わると、スクラムマスターが太鼓を打ち鳴らし、次のチームブースへの移動の合図を送ります。このプロセスは、参加者の各グループがすべてのチームブースを回り終えるまで繰り返されます。フィードバックはセッションの最後にチームへ伝えられるか、スプリントレビューごとに用意された共通のフィードバックフォームを使って、後から提出することもできます。

図29: バザールのローテーションを告げる太鼓

チームレトロスペクティブ

各チームは、スクラムと同じようにチームレトロスペクティブを行います。チームがファシリテーションを求めたときには、LeSS導入の枠を超えてスクラムマスターが支援しました。ビジネスサイドのチームを含むほとんどのチームが、働き方を改善するためのレトロスペクティブを定期的に開催していました。

全体レトロスペクティブ

全体レトロスペクティブは、チーム代表者、プロダクトオーナー、スクラムマスターで組織の課題を議論するために開催されました。より大きなグループで対処すべき課題や、他チームとの整合が必要な課題をチームが持ち寄り、この場で議論されました。

アーティファクト

プロダクトバックログ

GROOVE Xのチームは、プロダクトバックログを夢の源、実現したい願いや志が詰まったものとして見ています。物理的なプロダクトバックログの下には「夢のかけら入れ」と呼ばれる箱があります。実質的にはアイテムのゴミ箱です。チームはこの箱に気軽にアイテムを放り込みます。この習慣は新しいチームメンバーを驚かせることが多く、「そのアイテムがすごく重要だったらどうするんですか?」と尋ねる人もいます。経験豊富なメンバーはこう答えます。「重要なら、誰かがまた書くよ」。この仕組みが機能するのは、チームがそれを強く信頼しているからです。プロダクトオーナーは、チームがプロダクト全体と顧客に注力していることを理解しており、プロダクトにとって最善の、プロダクトビジョンに沿った意思決定がなされると信じています。

ソフトウェア開発のプロダクトバックログは一つだけです。残念ながら、周期の違いにより、ハードウェア領域には別のプロダクトバックログが一つあります。量産フェーズに入ると、ハードウェアのプロダクトバックログアイテムはもはやスプリントに収まらなくなりますが、ソフトウェアのアイテムはまだ収まります。新しいハードウェアを毎スプリント結合するのは難しいため、ソフトウェアチームは、新しいハードウェアが社内利用できるようになるまで、従来のハードウェアで作業を続ける必要があります。つまり、ハードウェアとソフトウェアは毎スプリント結合されるわけではないのです。

図30: プロダクトバックログと夢のかけら入れ

スプリントバックログ

すべてのチームがアナログのスプリントバックログを使っていました。チーム内での情報共有も、調整が必要なときの他チームとの共有も、そのほうが簡単だとわかったからです。チームメンバーは一日を通して頻繁にボードを訪れ、スプリントバックログを更新していました。更新はデイリースクラムのときだけに限られたものではなく、ボードはチームコラボレーションの中心的なハブとして機能していました。

図31: スプリントバックログ

ハードウェアを含むインクリメント

以下の短い動画は、LOVOTがインクリメンタルな開発を通じてプロダクトとしてどう進化してきたかを示しています。
https://youtu.be/dO_2E5-WSK0?si=eymUAvcaG3mvQ6Vl

図32-33: ハードウェアの進化

動画と上の写真からわかるとおり、LOVOTの開発は非常にシンプルなプロトタイプから始まりました。この3つは開発の最初期に作られたものです。左のものは、LOVOTを抱いたときの感覚の検証用であり、このプロダクトにとって決定的な要素を検証するために使われました。真ん中のものはロボット掃除機をベースに、その上に追加のデバイスを載せて、動きを検証するためのものでした。右のものはカメラのテストに使われました。それぞれのプロトタイプは意図的にシンプルに保たれ、チームはLOVOTの決定的な側面を一度に一つずつ検証していました。

彼らは3Dプリンターを活用してカスタム部品を作り、素早い実験を可能にしていました。このアプローチによって、GROOVE Xは実験のコストを抑え、開発プロセスを加速できました。この方法を通じて、ハードウェアとソフトウェアはインクリメンタルに共進化しました。各スプリントでハードウェアとソフトウェアの両方が変化し、ハードウェア開発者とソフトウェアエンジニアが緊密に連携して、一体となったプロダクトを作り上げていました。新しいハードウェアが必要になると、ハードウェアチームは既存部品の改修や3Dプリントによる新規部品の製作によって、必要なコンポーネントを設計・製造します。並行して、ソフトウェアエンジニアは、新しいハードウェアを結合し活用するために必要なファームウェアとアプリケーションを開発します。これらの活動は同じ周期を保ちながら並行して行われました。

しかし、開発フェーズが移り変わるにつれ、この周期を維持することは難しくなっていきました。LOVOTの開発は、大きくプロトタイピングフェーズと量産フェーズの2つに分けられます。プロトタイピングフェーズでは、前述のとおり、ハードウェアチームとソフトウェアチームが緊密に協働し、インクリメンタルな改善を作り出していました。しかし、プロジェクトが量産フェーズに近づくにつれ、ハードウェアの変更の柔軟性は低下していきました。量産には金型の製作が必要で、これはコストが高く、柔軟性に欠けるプロセスです。これらの制約により、ソフトウェア開発との周期の乖離が生じ、より新しく優れたデバイスを取り込む余地は限られていきました。GROOVE Xは常にLOVOTにとって最良のデバイスを選ぶことを目指していたため、変更の追加コストを払ってでも、可能な限り最後の瞬間まで選択肢を開いたままにしていました。

実験

LeSSの構造を導入することは終わりではありません。むしろ、継続的改善という新しい旅の始まりです。GROOVE Xは、状況を改善するためにLeSSの原則・ガイド・実験から多くのアイデアを活用しましたが、独自の実験も行いました。これらの実験は必ずしもLeSSの原則と整合しているわけではないため、各節の最後に「LeSSとの整合性」という注記を設け、その実験がLeSSと整合しているか、そしてその理由を説明します。

また、ここでの「実験」という言葉は、厳密な科学的意味ではなく、「試してみたこと、そしてその結果」というニュアンスで広く使っています。これらの実験には、LeSSの原則やガイドに従うものもあれば、LeSSが推奨する「技術的卓越性」の範疇に入るものもあります。アイデア自体はGROOVE X独自のものではありませんが、その適用の仕方は組織によって異なりえます。この章で共有したいのはまさにそれです。GROOVE Xが試したいくつかのこと、そしてそれがどうなったかをお伝えします。

ピープルマネジメント

この節は、ピープルマネジメントに関する実験についてです。GROOVE Xのプロダクト開発組織はマネジメントの役割を作らないことを決めたため、これらの実験は、伝統的なマネジメント構造に代わるものを探究しています。

職位(ジョブタイトル)

GROOVE Xの従業員のほとんどは、「チームメンバー」以外の公式な肩書きを持っていませんでした。しかし、GROOVE Xのサプライヤーの中には、同社の運営のあり方を十分に理解しておらず、商談の場に意思決定者としてのマネジメントの同席を求めてくることがよくありました。

長々とした説明を避けるため、GROOVE Xのチームメンバーは、こうした目的のためにマネジメントの肩書き入りの名刺を作ることが時々ありました。名刺にそうした肩書きを使う人は、その肩書きがGROOVE X社内では何の実質的な意味も持たないことを、十分に理解していました。

似たような状況は、規制対応の場面でも起こります。業界、政府、市場の規制によっては、責任者の指名が求められることがあります。そうした場合には、組織内の誰かがその責任を引き受けることを買って出ます。その結果、規制要件を満たすために、一部の人には公式にマネジメントの肩書きが割り当てられています。

ただし、この役割を引き受けた人は、自分が説明責任を負う一方で、組織内での実際の権限は持たないことを理解していました。これは難しい立場になりえます。対応する権限のないまま責任を負うことになるからです。それでも彼らは、GROOVE Xのユニークな働き方を守るためには、時にこうした役割を受け入れる必要があることを認識しています。

規制対応のためにマネジメント職に就いた人は、自らの責任に関わる事柄について、自分で状況を把握するか、関係するチームに最新情報を求めるかして、要件を満たすために常に情報を得ておくことが期待されていました。もちろん、担当者に正式な権限がなくても、組織の全員がそうした依頼に協力します。GROOVE Xには権威に従う文化はありません。その代わり、肩書きや立場にかかわらず、お互いに助け合うのです。

LeSSとの整合性:

この実験はLeSSと整合しています。LeSSではマネージャーの存在は任意であるため、GROOVE Xのような組織は、伝統的なパートナー企業と協働する方法を見つける必要があります。この実験は、その課題に対する彼らなりのアプローチでした。

庭師

庭師グループは、健全な企業環境づくりに関わっている、あるいは関心を持つ人々で構成されています。メンバーには、人事のバックグラウンドを持つ人、スクラムマスター、コーチなどが含まれます。このグループは人に関する課題を共有し、対処の戦略を議論します。また、外部からの期待に応えることと会社の文化を守ることのバランスを取った、会社の制度も作ります。

このグループは、庭師が庭の手入れをするように、組織の有機的な成長を育んでいると自認しており、それが名前の由来です。

庭師は毎週集まり、組織の障害をレビューし対処します。ミーティングでは、その時点で組織が直面している最も差し迫った課題を議論します。トピックの中には、イエローカードやレッドカードの発行といったアクションも含まれます。これらは庭師特有の用語です。イエローカードは、組織内の誰かが受け入れがたいふるまいをしたときの警告で、サッカーの警告に似ています。定例ミーティングでは、そうした状況で建設的なフィードバックをどう届けるかも議論されます。庭師はこのアプローチを一時的なものと捉えており、最終的なゴールは、チームが自分たちの健全さと成長を自律的に維持できるようになることです。

庭師は、チームの採用プロセスの形成にも関わり、必要に応じて支援を提供します。さらに、給与の決定方法や個人の成長を促す方法も提案します。これらの側面は、後述の「チームによる採用」節と「人事評価なし」節で詳しく述べます。

このグループは、伝統的にマネジメントが担ってきた責任の一部を引き受けています。ただし、LeSSで定義されるような完全にオープンなコミュニティではありませんでした。関心のある誰もが参加できたわけではないからです。グループを閉じたものにしておくという決定は意図的なものでした。雇用の終了といったセンシティブな事柄を扱うことが多いためです。

もしマネージャーのいない組織を作ろうと考えているなら、チームが人に関するマネジメントの意思決定を自分たちで担えるほど成熟するまでは、こうした機能を組み込むことを検討する必要があるかもしれません。

LeSSとの整合性:

庭師のコンセプトは、LeSSと完全には整合していません。当初から、庭師は一時的な解決策であり、最終的にはその責任をチームに移譲するという共通理解がありました。この引き継ぎが完了した時点で、庭師グループは解散する予定でした。

しかし、この移行は本ケーススタディの対象期間内には完了しませんでした。特別な役割を作ったり特別な責任を割り当てたりすることは、チームから責任を奪うことになるため、そうした特別なグループは作らないのが最善です。LeSSの観点からは、誰もが自由に参加して組織のルールづくりを助けられるコミュニティを作ることが、代替案の一つになりうるでしょう。

日本では従業員の解雇に関する規制が非常に厳しいため、コミュニティがこれを扱うのは難しいでしょう。そのような場合には、マネジメントの関与が必要です。GROOVE Xでは、人事のスペシャリストとCEOが中心的な役割を果たしました。

チームによる採用

GROOVE Xでは、採用の責任はチームにあります。どんなスキルが足りないかを最もよく知っているのはチームです。人を増やす必要があるとき、まず他チームのメンバーに加入を打診できます。しかし、社内に適切な候補者が見つからず、予算が許すなら、採用プロセスを開始します。多くの場合、まず思い浮かべるのは、その領域で力になってくれそうな友人やかつての同僚です。よく知っている人を見つけるのが一番だとわかっているので、GROOVE Xの多くの人がメンバーの紹介(リファラル)で入社しています。自分たちで候補者を見つけられない場合は、庭師の支援を受けられます。

チームが採用プロセスの開始を決めると、庭師に相談し、候補者に求める具体的な資質やスキルを共有します。庭師の一人が求人票を作成します。応募があると、チームが候補者を面接します。面接の後、チームメンバーは候補者評価マトリクスを使って投票します。各メンバーが自分の名前をカードに書き、プランニングポーカーのように一斉に置きます。1回目の投票で意見が分かれた場合は、その違いについて議論し、必要であれば2回目の投票を行います。このプロセスも、必要に応じて庭師が支援します。

図34: 候補者評価マトリクス

候補者評価マトリクスは、重要な考慮事項を明示し、次のステップを示すことで、チームの意思決定プロセスを支援するために作られました。このマトリクスは、チームが十分な情報に基づいて意思決定し、候補者について議論することを助けます。

候補者がチームの評価を通過すると、CEOが面接を行い、組織に合う人かどうかを確認し、CEOとしての見方を共有します。ただし、このCEO面接はどちらかといえば形式的なもので、双方が最終判断を下す前に、CEOと直接顔を合わせておくための場です。

マネージャーなしの採用プロセスは、GROOVE Xではかなりうまく機能しました。しかし、チームによる解雇は、はるかに難しいことがわかりました。あるチームが特定の人と働くことが難しいと感じた場合、チームにはその人をチームから外す権利がありました。その人がGROOVE X内で他に加われるチームを見つけられなければ、社外に仕事を探す必要が生じます。

しかし、誰かと働くことに困難を抱えていても、チームはその人を外すという一歩を踏み出せずに苦しむことが多くありました。そのような決断をチームだけで下すのはあまりにも難しく、庭師が介入して、人を送り出すプロセスを支援する必要がありました。

LeSSとの整合性:

この実験は、自己管理チームのコンセプトと整合しています。チーム自己設計ワークショップと同様に、マネジメントからチームへ権限を委譲し、チームが自分たち自身を設計できるようにするものです。

人事評価なし

まず前提として、GROOVE Xに人事評価はありませんでしたが、それでも給与を決め、個人の成長を支援する必要はありました。人事評価がないというのは、個人のパフォーマンス測定がなかったという意味です。仕事の出来や努力の量が給与に影響することはありません。報酬に紐づく個人目標はなく、個人のパフォーマンスに連動するボーナスもありませんでした。

パフォーマンスの測定は非常に難しく、全員に公平であることは困難です。パフォーマンスを測定するのは通常マネージャーであり、マネージャーは完全に客観的ではいられないからです。マネージャーも人間であり、人間である以上、主観とバイアスは避けられません。このため、パフォーマンス評価を全員にとって公平にすることは、ほぼ不可能です。それでも多くの会社は、人事評価制度に多大な時間と労力を投じています。組織目標を設定し、個人目標にブレークダウンし、マネージャーとの目標設定面談を行い、四半期の終わりにレビューとフィードバックの面談を実施する。そして翌四半期、また同じプロセスが始まります。このプロセスはプロダクトにほとんど価値を加えないことが多く、全員の時間を大量に奪い、人々を幸せにするとも限りません。

人事評価のもう一つの問題は、個人目標がチームのコラボレーション、知識共有、相互支援の妨げになりうることです。助け合いはLeSS環境では当たり前のことですが、人事評価制度はこの側面をしばしば見落とします。さらに、人事評価は個人に注目するため、人々はたいてい別々の目標を設定することになります。チームメンバーの目標がばらばらだと、チームワークより個人目標を優先するインセンティブが生まれます。また、プロダクトバックログの最優先アイテムや顧客への価値提供に注力するのではなく、自分の個人目標の達成に役立つタスクに取り組むことを促してしまいかねません。

人事評価から離れたいと考えてはいても、給与を決め、個人の能力開発を支援する方法は依然として必要でした。私たちはまず、個人の成長への支援から着手しました。

GROOVE Xは、名札型のウェアラブルセンサーを試していました。これはオフィスの名札に似たウェアラブルデバイスで、誰と話したか、会話がどのくらい続いたか、どのくらいの頻度で発生したかを記録します。このデバイスが収集する対面コミュニケーションのデータと、Slackでのやり取りといったデジタルコミュニケーションのデータを組み合わせることで、各従業員のチーム外にいるメンター候補を特定できました。各チームメンバーはメンター候補のリストを受け取り、その情報をもとに自分のメンターを選べました。メンターが決まると、メンターとメンティーは定期的に会い、メンティーの能力開発を支援しました。

個人の成長支援に加えて、伝統的な人事評価なしで給与をどう決めるかにも取り組む必要がありました。当初、給与の決定はCEOが一人で行っていました。GROOVE Xは、給与が仕事の主たる動機であるべきではなく、仕事そのものが動機となるべきだと考えていました。同時に、報酬への不安が従業員のやる気を削ぐことは避けたいと考えていました。

給与決定の戦略は、外部パートナーと協力して従業員の市場価値を評価し、それより少し高い報酬を提示することでした。狙いは、給与への不満による離職を防ぎ、従業員がプロダクト開発に全力で注力できるようにすることです。これを実現するため、GROOVE Xはある人材紹介会社と提携し、給与とボーナスの決定を担うサービスを共創しました。

この人材紹介会社は、幅広い業界にわたる100万人以上のプロフェッショナルのキャリアデータを保有しています。GROOVE Xが従業員の情報を提供すると、サービスが適切な給与レンジを提案します。残念ながら、このサービスはプロダクトとして軌道に乗らず、実験は最終的に終了し、CEOが引き続き全従業員の給与を決めることになりました。

ボーナスに関する別の実験として、GROOVE Xはピアボーナスサービスを使いました。これは、従業員同士が少額のボーナスを送り合える日本のプラットフォームです。マネジメントが年に一度大きなボーナスを支給する代わりに、会社はボーナス予算をこのサービスにプールしました。従業員は、誰かの貢献に感謝したいとき、いつでも同僚に「ありがとう」のボーナスを送れます。この仕組みをとても気に入った従業員もいました。しかし課題もありました。全員が積極的に使ったわけではないため、恩恵を受けるのが特定の人に偏ってしまったのです。

LeSSとの整合性:

人事評価は、職場での人々のふるまいに影響を与えます。LeSSルールは人事評価の扱いについて特定のアプローチを規定していません。しかし、書籍『 Scaling Lean & Agile Development』では、生活費と特定スキルの市場価値によって決まる一定の等級に基づいて給与を決めることが推奨されています。GROOVE Xが目指したのは、まさにこれでした。

プロダクトマネジメント

この節の実験は、プロダクトマネジメントに関するものです。一つの側面は、チームのオーナーシップを高めることです。GROOVE Xのチームメンバーは自分たちのプロダクトに強いオーナーシップを持っており、それが革新的なアイデアの提案につながっています。意思決定の大幅な委譲と相まって、彼らは自律的に働くことができています。このカテゴリのもう一つのテーマは、次のプロダクトオーナーをどう見つけ、育てるかです。

また、統一された一つのプロダクトバックログを作る苦労についてはすでに述べましたが、それが実現した後も、プロダクトバックログに関する実験は続きました。GROOVE Xのチームは自分たちのプロセスとアーティファクトに大きなオーナーシップを持っていたため、ここで紹介する2つの実験はいずれもチーム自身が始めたものです。プロダクトバックログの管理はプロダクトオーナーの責任ですが、プロダクトオーナーは自分が納得できる限り、チームがそれを変えることを許していました。実際、ケーススタディの対象期間中に、彼がチームの変更に不満を述べたり、それを止めたりする場面を私は一度も見ていません。

顧客と開発者の距離を縮める

カスタマーサービスの人手が足りなくなったとき、チームは交代でカスタマーサポートの電話に応対し始めました。顧客と直接やり取りして、その困りごとを理解したのです。この電話対応は、チームが顧客の視点をより深く理解する助けになりました。たとえば、ある子どもがサポートチームに電話をかけてきて、LOVOTと一緒にお風呂に入ってもいいかと尋ねたことがありました。LOVOTは防水ではないため入浴させることはできませんが、チームはここから、子どもたちがLOVOTをほとんど生き物として捉え、他のペットと同じように接することを期待しているのだと学びました。このことを念頭に置けば、ふるまいのデザインや安全性テストにも影響がありうるでしょう。

LeSSの原則:「顧客中心」

さらにGROOVE Xは、開発拠点と同じ建物内にLOVOTミュージアムを開設し、見込み顧客と開発現場の距離を縮めました。この環境では、新しいふるまいや機能に対する実際の顧客の反応を観察できます。LOVOTは人と共に暮らすことを想定しているため、ユーザーの予期しない行動に出会うことも少なくありません。

LeSSとの整合性:

顧客中心であることはLeSSの原則の一つなので、顧客と密接に関わることはLeSSと整合しています。

SK

SKは、プロダクトオーナーの役割を学ぶために、プロダクトオーナーに影のように付き従うグループとして作られました。主な目的は、プロダクト全体の次のプロダクトオーナーを育てる環境を作ることです。また、SKは、それぞれの専門領域における明確化と優先順位付けを助けることで、プロダクトオーナーとチームがより良い意思決定を行えるよう支援する存在でもありました。

もともと林氏は、株式公開に備えるガバナンス上の推奨に従い、近い将来プロダクトオーナーの役割を組織内の誰かに委譲するつもりでした。しかし当時、その役割を引き受けるのにふさわしい人物を見つけられませんでした。そこで彼は、プロダクトオーナーの役割について人を育てる仕組みを作ろうとしたのです。

トヨタ時代、林氏は「Z」と呼ばれるグループの一員でした。Zは、プロダクトマネージャーのビジョンを理解し、その影として動くために設計されたチームです。このアイデアに着想を得て、彼はGROOVE X版のZとしてSKを作りました。何人かのチームメンバーがSKとなり、その役割は、プロダクトオーナーが責務を果たすのを支援し、チームのアイテム明確化を助け、必要に応じてフィードバックを提供することでした。

LeSSとの整合性:

次のプロダクトオーナーをどう育てるかについて、LeSSは何も述べていません。しかし、こうしたポジションを作ることにはリスクがあります。一部の責任がチームからSKへ移ってしまう可能性があるからです。たとえば、SKが明確化や顧客対応を担うようになれば、チームと顧客の距離はかえって広がりかねません。このリスクゆえに、LeSSの観点からは一般に推奨されません。

ただし彼らの環境では、多くの責任がすでにチームに委譲されていました。チームはすでにプロダクト全体思考で動き、顧客と直接コミュニケーションを取っていたため、この場合、組織への悪影響は限定的でした。

ポエムは引き続きプロダクトオーナーがビジョンを示すために作り、最終的な意思決定権もプロダクトオーナーに残されていました。

プロダクトバックログのチームレーン

図35: 複数チームリファインメント

GROOVE Xが行った実験の一つは、今後3スプリントの間にどのチームがどのアイテムを担当するかを緩やかに割り当てることでした。近い将来に何が来るのかをチームがより見通せるようにするためです。その結果、今後のスプリント向けに、プロダクトバックログ上にチームごとのレーンが作られました。アイテムをリファインメントした後、各チームは自分たちが対応したいアイテムをそれぞれのレーンに置きます。写真が撮影された時点では、この仕組みが使われていました。

進捗に応じてレーン間でアイテムを移すことは認められていましたが、レーンが分かれていること自体が、アイテムの自由な再割り当てを難しくし、プロダクト全体思考を弱めました。自分たちのレーンを持つと、チームは自分のレーンに来るものだけに注目しがちになります。他チームと協働する意思があったとしても、システムの視点で見れば、他チームが何をしているかへの関心は薄れてしまうのです。また、チームは自分が快適に働ける領域にとどまりがちで、それがプロダクトの一部分の周りにサイロを生み、他の部分を学ぶ機会を減らします。これはつまり、プロダクト全体の視点から見ると、チームが最も重要なアイテムに取り組んでいない可能性があるということです。最終的に彼らはこれらの問題を認識し、順序付けられた単一のプロダクトバックログに戻しました。

LeSSとの整合性:

この実験はLeSSと整合していませんでした。最も重要なアイテムに取り組む可能性を減らし、チーム横断のコラボレーションを妨げるサイロを生み、学びの機会も減らしたからです。LeSSでは、プロダクトバックログは順序付けられた単一のリストであるべきです。

プロダクトバックログ外のスカンクワークス

仕事と趣味の境界が曖昧なため、一部のチームメンバーは公式のプロダクトバックログにないフィーチャーを作り始めました。これは「暗黙のプロダクトバックログ」と見ることができ、一般には良いプラクティスではありません。しかしプロダクトオーナーはこの活動を認識したうえで、干渉しないよう私たちに求めました。

そのチームが開発していたのは子ども向けの機能で、Scratchを使ってLOVOTのふるまいをプログラムし、子どもでもLOVOTの動き方をデザインできるようにするものでした。「20パーセントルール」のような公式な制度があったわけではありません。有志のグループが自然に集まって、これらの新機能を作ったのです。プロトタイプが完成すると、彼らはそれをスプリントレビューで披露しました。彼らは公式のプロダクトバックログの重要性を理解しており、チームとしてそちらにも取り組んでいました。そのうえで、このフィーチャーは趣味として開発し、後から公式なものにしたのです。GROOVE Xは、こうした活動もイノベーションを育むうえで重要だと認識しています。

図36: 子ども向けビジュアルプログラミングのユーザーインターフェース(出典: [6])
図37: LOVOTのふるまいをプログラムする子どもたち(出典: [6])

LeSSルール:「1つの出荷可能なプロダクトに対して1人のプロダクトオーナーと1つのプロダクトバックログで運用を行う。」

この暗黙のプロダクトバックログのやり方はGROOVE Xでは機能しましたが、全ての会社でおすすめできるわけではありません。このサイドプロジェクトに関わったメンバー自身も、公式のプロダクトバックログの重要性を理解し、全体のゴールと足並みを揃えていました。彼らの意図は仕事を隠すことではなく、創造のプロセスを楽しみ、プログラミングの喜びを子どもたちに伝えたいという情熱を分かち合うことでした。開発者たちはこのアイデアを公式のプロダクトバックログに載せることもできましたが、他の人からフィードバックをもらいたいと思うときまでは、自分たちの楽しい実験として持っておきたかったのです。そして最終的に、彼らはこの新機能をスプリントレビューに持ち込み、フィードバックを得て、出荷しました。

LeSSとの整合性:

複数のプロダクトバックログや隠れたプロダクトバックログを持つことは、LeSSの考え方と整合しません。LeSSでは、プロダクトごとにプロダクトバックログは一つだけであるべきで、複数のプロダクトバックログを使うことは、注力と透明性の両方を損なうため推奨できません。

しかしこの実験が成功したのは、最初の機能が完成するまでの一時的なやり方にとどまったからです。GROOVE Xでは「真剣に楽しむ」ことが大切にされています。革新的なプロダクトを生み出すには、遊ぶための自由な余白が必要だからです。加えて、チームはこの活動をプロダクトオーナーを含む周囲に対して透明にしており、プロダクトオーナーも彼らの仕事を評価していました。そのため、物理的なプロダクトバックログには載っていなくても、プロダクトオーナーの頭の中には単一の優先順位リストがあったのです。

LeSSの原則とガイドの実践

本ケーススタディの対象期間中、私たちはLeSS本に書かれている原則とガイドの多くを採用していました。GROOVE Xが試した、あるいは採用したガイドをすべて列挙するのではなく、GROOVE Xが特に興味深く、時に極端なやり方で適用した、本ケーススタディで取り上げるに値する原則とガイドに絞って紹介したいと思います。

なお、本章および以降の章には「LeSSとの整合性」の項を設けていません。ここで紹介する実験は、いずれも設計上LeSSと整合しているからです。

止めて直す

LOVOTが市場にリリースされた後、緊急に解決すべき問題がいくつか発生しました。これに対処するため、各チームから有志が集まり、進行中の作業を止めて、問題を解決するための一時的なグループを作りました。

LeSSの原則:「リーン思考 — 止めて直す」

この取り組みはマネジメント主導ではありませんでした。チーム自身が問題を認識し、行動しなければという強い責任感を抱いたのです。あるチームメンバーが、すべてのプロダクト開発チームから有志を集めて状況を話し合うことを提案しました。有志は大きな会議室に集まり、協力して問題を議論し、解決に向けた計画を作りました。

数週間のうちに重大な問題は解決され、グループは自然に解散しました。この躍動的な動きは、マネジメントの関与なしに有機的に起こったものです。他の役割や組織の他の部分を責めることもありませんでした。

「止めて直す」というコンセプトはリーンに由来し、リーン思考はLeSSの中核原則の一つです。ただし、本来の「止めて直す」は、根本原因も含めて問題を直すために全員が作業を止めることを意味します。GROOVE Xはすべてを止めたわけではなく、開発者の約3分の1が有志グループに参加して問題に対処しました。つまりこれは、本来のリーンのプラクティスを厳密に適用したものではありません。

トラベラー

GROOVE Xのチームは、LeSSの「トラベラー」という手法をよく使います。トラベラーは、チーム間の学習を促すためにLeSS環境で用いられる手法です。要するに、あるチームメンバーが数スプリントの間、別のチームに通常のチームメンバーとして一時的に加わります。トラベラーは新しいチームに完全に溶け込んだメンバーとして振る舞い、共に仕事を進めながら知識を広げていきます。

私は、このプラクティスが2つの異なる状況で始まるのを見てきました。(1) チームが、現在のメンバーでは解決できない困難に直面したとき、他チームのメンバーに助けを求める場合。(2) トラベラー自身が組織内に広めたいアイデアを持っている、あるいは他チームから学びたいと考えたとき、数スプリント参加させてもらえないかと他チームに頼む場合です。

GROOVE Xでユニークだったのは、チームが異なる領域をまたいで移動したことです。たとえば、LVOTの店舗で顧客対応の支援を必要としたときには、ソフトウェアやハードウェアのエンジニアがそのチームに加わって手伝いました。製造工場で問題が起きて支援が必要になったときには、スクラムマスターやハードウェアチームのメンバーが加わって解決にあたりました。このプラクティスはソフトウェア領域に限られたものではなかったのです。たとえば、あるソフトウェアエンジニアはハードウェアとソフトウェアの領域を統合したいと考え、まず自らハードウェアチームに加わって、彼らの働き方を学びました。

当初の目的を果たすと、彼らはたいてい元のチームに戻りました。ただし、所属チームそのものを変えることを選ぶ人や、定期的に他チームを訪れ続ける人もいました。
「トラベラー」はLeSSにおける調整と統合の手法の一つです。ただしGROOVE Xは、トラベラーの範囲を広げました。LeSSではトラベラーはLeSS導入の範囲内で移動することが想定されていますが、GROOVE Xのトラベラーは組織内のあらゆるチームをまたいで移動できたのです。

技術的卓越性

技術的卓越性は、コストをかけずに、あるいは低コストで方向転換できるようにするためにLeSSが非常に重視する領域であり、LeSSが目指す根本的なゴールの一つでもあります。以下は、このテーマに関連してGROOVE Xが行ってきた、特筆すべき取り組みです。

技術トレーニング

LOVOTの開発には技術面の多くの不確実性が伴うため、多才な人材のアイデアとスキルを結集し、共通のゴールに向かうには、スペシャリスト同士のチームワークが不可欠です。GROOVE Xもまた、技術的卓越性を成功の鍵と考えています。こうした理由から、GROOVE Xのほぼすべてのソフトウェアエンジニアが「LeSS in Action」コースを受講しました。このコースでは、将来の変化に適応できる柔軟な開発環境を維持するために必要な技術プラクティスと、チーム内・チーム間のコラボレーションの方法を学びます。

「LeSS in Action」トレーニングは、Odd-eのTerryまたはStanleyが講師を務めました。このコースは、本物のLeSS環境で働くとはどういうことかを参加者に体験してもらうよう設計されています。1週間を通じて、参加者は約7割の時間を他の参加者との模擬スプリントの作業に、3割を講義に費やします。講義で扱うのは、テスト駆動開発(TDD)、受け入れテスト駆動開発(ATDD)、実例による仕様(Specification by Example)、継続的インテグレーション、創発的設計、トランクベース開発、ペアプログラミング、モブプログラミングなど、LeSSの働き方を支えるプラクティスの数々です。参加者は教室でこれらの技術を学ぶだけでなく、チームで実際のプロダクトを開発しながらそれらを使い、こうした手法が現実の状況でどう噛み合うのかを体験します。また、LeSSのイベントにも参加し、LeSSを導入するとはどういう感覚なのかを肌で知ることになります。

このトレーニングの後、多くの開発者はGROOVE Xが何を目指しているのかをより深く理解するようになりました。この実践的な経験は、チームの動き方に大きな影響を与えました。GROOVE Xのエンジニアたちは学んだことを持ち帰り、モノレポ、継続的インテグレーション、ハードウェアテストの自動化、ペアプロ・モブプロといったプラクティスを日々の仕事に取り入れ始めました。

技術的卓越性は、プロダクトを将来の変化に備えた状態に保つうえで、LeSS導入の鍵となる要素です。「LeSS in Action」トレーニングは、技術プラクティスの完全なパッケージを提供すると同時に、チーム間のコラボレーションを育む手段としても機能します。

ペアプログラミングとモブプログラミング

「LeSS in Action」トレーニングの結果、ペアプロとモブプロはGROOVE Xの開発における当たり前のやり方になりました。異なる専門性を持つメンバーがペアを組み、共にインクリメントを作り上げます。大きな不確実性に直面したときは、まずモブで未知の部分に取り組みます。状況がはっきりしてきたら、ペアでの作業に切り替えます。

当初は、ペアプロやモブプロは生産性を下げるだろうと考える人が多くいました。しかし、やり方に慣れるにつれ、その利点を実感するようになりました。一般に、開発時間のかなりの部分はコーディングそのものではなく、考えることに費やされています。実際にタイピングしている時間は比較的短いため、生産性がわずかに落ちると想定されるとしても、学習の増加のほうがはるかに大きいと気づいたのです。さらに、チームメンバーと密に働くことで、仕事はずっと楽しくなりました。他チームのメンバーが、お互いから学ぶためにモブやペアに加わることもありました。

ペアプロやモブプロはLeSSの厳格なルールではありませんが、継続的インテグレーション、テストの自動化、コードの共同所有といった技術プラクティスは、変化に適応しながら高品質なプロダクトを維持するために不可欠です。ペアプロとモブプロは、協働を促し、知識のサイロ化を減らし、メンバー間のリアルタイムな学習を促進することに貢献しました。

ハードウェアを含むエンドツーエンド自動テスト

LOVOTはハードウェアとソフトウェアを含む非常に複雑なプロダクトであるため、テストの自動化にも複数の層があります。チームはプロダクト全体のテストを自動化するという課題を特に興味深いと感じ、それに取り組むことを決めました。

プロトタイピングのフェーズでは、ハードウェアの多くは手作業で組み立てられ、部品は購入するか3Dプリンターで作成してインクリメントに統合されていました。ソフトウェアも毎スプリント結合されていたため、ハードウェアとソフトウェアの両方が各スプリントを通じて継続的に結合されていたことになります。

このフェーズでは、2種類のテストが必要でした。1つ目はハードウェアシミュレーションテストで、開発者のローカル環境で素早く実行でき、シミュレーション上でハードウェアの機能を確認するために頻繁に実行されました。

2つ目に、完全なハードウェアとソフトウェアの結合を保証するには、シミュレーションだけでは不十分でした。そこで彼らは、「起動動作」の結合テストを設計しました。LOVOTがネストでの眠りから覚め、歩き回り、ネストに戻るという一連の動きです。この結合テストは、ソフトウェアイメージの新バージョンがビルドされるたびに実行され、新しいイメージが基本機能にどう影響し、それらが正常に動作するかについて即座にフィードバックを与えます。このテストはソフトウェアとハードウェアだけでなく、クラウドもカバーします。テストが開始されると、LOVOTは瞳のデザインや声のデザインといった初期データをクラウドから取得するため、LOVOTの初期状態と基本機能を検証できるのです。このように、起動動作はLOVOTのエンドツーエンドテストとして機能し、ハードウェア・ソフトウェア・クラウドの結合テストを包含しています。これがGROOVE Xのエンドツーエンドテスト自動化の旅の始まりだったのです。

起動動作の様子はこちらでご覧いただけます:https://youtu.be/Wyw0HDT-CiY

図38: プロトタイピングフェーズ

上記の2つのテスト「ハードウェアシミュレーションテスト」と「起動動作テスト」は、プロトタイピングフェーズでは十分でした。しかし量産フェーズでは事情はより複雑になりました。

開発が量産フェーズに入ると、量産にまつわる非柔軟性のために、出荷判断可能なプロダクトインクリメントを作るべくハードウェアの結合をマイスプリントする事は、はるかに難しくなりました。

第一に、部品を作るための金型は、改修に非常に高いコストがかかりました。GROOVE Xは、部品設計を確定する意思決定を、責任を持てる最後の瞬間まで遅らせようとしました。金型ができた後でさえ、新しいデバイスの導入やより良いアイデアの登場に応じて、何度も改修コストを負担しました。その変更に追加の費用を払う価値があるかどうかを判断するのはプロダクトオーナーです。ほとんどの場合、プロダクトオーナーは、より良いプロダクトを作るために可能な限り多くの変更を受け入れる道を選びました。

第二に、製品をリリースするには、安全性を担保するための耐久テストが必要でした。これらのテストも自動化されていましたが、部品が家庭での使用に耐えうる耐久性と安全性を持つことを確認するため、長期間にわたってLOVOTを稼働し続ける必要がありました。

新しいソフトウェアイメージが作られ、すべての自動テストに合格すると、選ばれた社内のLOVOTにデプロイできます。これらのLOVOTの一部は長期テストに使われており、その中には常に最新バージョンが動いているプロダクトオーナーのLOVOTや、新バージョンを自宅でテストすることを買って出たメンバーのLOVOTも含まれます。

ハードウェアテスト自動化の観点では、サイクルタイムはプロトタイピングのフェーズとは異なるものになりました。ソフトウェア開発者は、新バージョンのハードウェアが届くまで、従来のバージョンを使い続けなければならなかったのです。

図39: 量産フェーズ

以上のとおり、ハードウェアに関連する自動テストには4つの種類があります。

  1. ハードウェアシミュレータテスト
  2. 起動動作の自動テスト

上記2つはプロトタイピングフェーズで使われ、以下の2つは開発が量産フェーズに入ったときに追加されました。

  1. 耐久テスト
  2. カナリアリリース

GROOVE Xのハードウェアエンジニアの多くは大手ハードウェアメーカーでの経験を持っており、そのバックグラウンドゆえに、アジャイルのマインドセットを取り入れることに難しさを感じていました。後工程での変更は欠陥を招くことが多いため、変更を加えることに不安を覚えたのです。これはもっともな懸念でした。しかし彼らは、安定性と安全性を担保するハードウェアの自動テストを実装することで、この恐れを乗り越えようとしました。

自動テストスイートにハードウェアとのやり取りを含めることで、チームはLOVOTのソフトウェアとハードウェアの両コンポーネントがシームレスに連携することを検証できます。これにより、デプロイ後に予期しない問題が表面化するリスクが減ります。

LeSSフレームワークでは、チームが注力すべきは個々のコンポーネントではなくプロダクト全体です。GROOVE Xのアプローチはこの原則とよく合致しています。自動テストスイートは、物理的な動き、センサーの精度、ソフトウェアのふるまいを含め、LOVOTを完成したプロダクトとして検証するように設計されているのです。この全体的なアプローチは、ハードウェアエンジニア、ソフトウェア開発者、テスターが密に協働してプロダクトを改善することを促すため、クロスファンクショナルなコラボレーションを後押しします。

結論

GROOVE Xにおけるマネージャーなし・部門なしの実験は、イノベーションとコラボレーションを最大化しようとするスタートアップにとって、こうしたアプローチが十分に成り立ちうることを示しました。もっとも、ほとんどのスタートアップは正式なマネジメントを持たずに始まります。創業者を含む数名の開発者とビジネス担当者だけでのスタートが一般的です。

組織が成長すると、多くの会社は、次々と現れる課題に対処するために、何らかのマネジメント構造を早々に導入します。しかし本ケーススタディが示すとおり、スタートアップの環境においては、マネジメントの役割の導入を遅らせることもまた、有効な選択肢になりえます。

加えて、GROOVE Xには「洞窟コンセプト」によって育まれた高い信頼の文化がすでにありました。お互いを知り、助け合うことが組織全体で当たり前になっていたのです。もう一つ考慮すべき重要な要因は、GROOVE Xが極めて実験的なマインドセットを持っていたことで、これが新しいアプローチを試すことへの抵抗を最小限に抑えていたことです。

LeSS導入の観点では、LeSSは彼らの最適化ゴールと完璧に合致していました。ただし、その導入が主に成功したのはソフトウェア開発の領域であり、本ケーススタディの対象期間中には、ハードウェアやビジネスの領域にまで広がることはありませんでした。

GROOVE Xの他の多くの実験においても、LeSSは土台となる原則、構造、指針を提供しました。彼らは実験を重ねるプロセスを通じて、組織とプロダクトを同時に築き上げていったのです。

以下に、本ケーススタディの対象期間の終わりの時点で、うまくいったことと、残された課題をまとめます。完璧さに到達することは終わりのない旅であり、唯一の答えやベストプラクティスというものは存在しません。本ケーススタディが、同じような組織を築こうとしている方や、組織設計の可能性を探っている方の助けになれば幸いです。

うまくいったこと

本章と次章では、ケーススタディ全体を振り返り、LeSS導入の結果としてうまくいったことと、今後に向けて残された課題をまとめます。

彼らは、マネジメントの関与を最小限に抑え、統合されたプロダクトを届けることに注力する自己管理型の組織を作ることに成功しました。フラットな組織構造によって、チームはオーナーシップを持つことができました。プロダクトオーナーはプロダクトビジョンという抽象的な方向性を示し、チームが自らのアイデアを掘り下げ、プロダクトに影響を与えるための大きな余地を与えました。ソフトウェアチームはフィーチャーチームとして機能し、他チームと密に協働しながら、エンドツーエンドの機能を届けていました。

課題

以下の課題は、ケーススタディの対象期間の終了時点で未解決のまま残されていました。これらは、GROOVE Xが今後も実験と改善を続けていきたいと考えている領域です。

ハードウェアを含むLeSS導入

最初の課題は、量産フェーズに入った後のソフトウェア開発とハードウェア開発の統合であり、これは本ケーススタディの対象期間中には達成できませんでした。理想を言えば、量産フェーズにおいても、製品をリリースするために必要なすべてのテストを含んだ出荷判断可能なプロダクトインクリメントを、スプリント内で作れるようになることです。また、最新のハードウェアを使って真にエンドツーエンドな機能を作るために、ハードウェアとソフトウェア両方の開発者からなるフィーチャーチームを編成することも目指していました。

この構想を前に進めるための試みはいくつかありました。まず、プロダクトバックログは別々のまま維持しつつ、両方を一緒に見渡せるよう、同じ物理的なエリアに配置しようとしました。しかし、周期が異なるため、一つのリストに統合することはしませんでした。ハードウェア開発は、ソフトウェアのスプリント周期に収まらなかったのです。そのため、ハードウェアの作業はよりカンバンに近いアプローチで管理されました。

ハードウェアチームはLeSSイベントのほとんどに参加していましたが、スプリントは回していませんでした。デイリースクラムは毎日行い、レトロスペクティブも定期的に実施していました。見せられるものができたときには、そのインクリメントをスプリントレビューに持ち込みました。

ハードウェア設計を学ぼうとするソフトウェア開発者もいました。真にクロスファンクショナルなフィーチャーチームを作ることがゴールだったため、ハードウェア開発を理解しようとハードウェアチームに加わったのです。しかしこのアプローチは、知識が広がるまでに時間を要するものでした。この試みの中で、ソフトウェア開発者たちはハードウェアテスト自動化の重要性に気づき、本ケーススタディの「ハードウェアを含むエンドツーエンド自動テスト」節で述べたとおり、ハードウェアテストの自動化の開発へと注力の先を移していきました。

理想の状態を目指してはいたものの、変更が難しいというハードウェアの物理的制約のために、その実現は非常に困難でした。プロトタイピングフェーズでは間違いなくその状態を実現できていましたし、次世代のLOVOTを開発する際には、再びそこを目指すことになるでしょう。しかし、いったん量産フェーズに入れば、ハードウェア開発とソフトウェア開発の周期の違いから、ハードウェア開発についてはよりカンバンに近いアプローチに切り替える必要が出てくる可能性が高いと考えられます。

新しいプロダクトオーナーの育成

組織の成長に伴い、彼らはLeSS Hugeの導入に移行する可能性が高く、その変化に備える必要があります。現在のプロダクトオーナーの主な関心事は、エリアプロダクトオーナーの成長をどう促すかです。彼らが行った「SK」という実験は、将来のプロダクトオーナーを育てるうえで役立つかもしれません。もっと良い方法もあるかもしれませんが、これは組織にとって現在も続く課題です。

給与の決定　

「人事評価なし」節で述べたとおり、彼らは給与決定プロセスの一部を自動化する、あるいは外部に委ねるためのツールを試しました。しかし現在は、CEOが全員の給与を決めるという元のやり方に戻っています。組織が成長を続けるにつれ、これは変えていく必要があるため、対処すべき課題として残っています。

目指しているのは、プロセスを可能な限り自動化することで給与決定にかかる労力を最小限に抑えつつ、優れた人材を惹きつけるために必要なときには高い給与を提示できるだけの柔軟性も保つことです。加えて、従業員の成長を支えるには、継続的な改善が必要です。

参考文献

[1] ハードウェアに関するGROOVE X技術ブログ:
https://tech.groove-x.com/entry/inside-of-LOVOT-fw

[2] LOVOTのアーキテクチャ:
https://speakerdeck.com/soracom/soracom-tech-days-2021-day1-2

[3] LOVOTが地図を作成する仕組みに関するGROOVE X技術ブログ:
https://tech.groove-x.com/entry/inside-of-LOVOT-slam

[4] Agile Japanカンファレンス CEOによるセッション 10:20〜11:10
https://2019.agilejapan.jp/session.html

[5] Agile Japanカンファレンス スクラムマスターによるセッション 13:50〜14:30
https://2019.agilejapan.jp/session.html

[6] LOVOTの子ども向けビジュアルプログラミング:
https://LOVOT.life/blog/article/mwdp01o6bcl/

[7] 量産に関する記事:
https://www.dasscrumteam.com/en/blog/from-idea-to-mass-production

[8] Oテスト自動化のオリジナル録画:
https://www.youtube.com/watch?v=vq6nEHMSLmA

[9] LOVOTに関するロボットスタートの記事:
https://robotstart.info/2020/02/06/LOVOT-internal-structure.html

[10] GROOVE Xのフットサルチーム:
https://tech.groove-x.com/entry/groove-x-futsal