LeSS' Yoaké ASIA 2024に参加しました。

前回のDay1に続き、LeSSの作成者であるCraig LarmanとBas Voddeが来日。彼らは何を語ったのか？語られたことから私が受けた学びや気づきを交えて、共有します。今回は、LeSS YoakeのDay5を報告します。
※Day2~Day4はトレーニングDayの期間として、認定スクラムマスター研修,認定プロダクトオーナー研修,認定LeSSプラクティショナー研修が開催されていました。こちらも盛り上がったようです。

Closing Keynote LeSS導入はどうやるの？ Bas Vodde

クロージングキーノートはBas Voddeです。Craigと共にLeSSを作り、実践してきたBasから、LeSS導入の方法を話していただけました。

LeSSの導入は教育、LeSS導入の準備、'フリップ'、基本的なLeSSの改善、LeSSの構造の維持という流れになる
教育の期間は長く、6年かかるケースもある。この期間はLeSSについての知識などのギャップを埋める期間。教育が終わるときは「そろそろLeSSを導入しようか」と言うとき
'フリップ'はLeSSの構造に変える期間。1週間くらいで終わる。その後6か月程度かけて、良くある課題に対応する
経営が変わると、LeSSの構造を壊されることがよくあるが、今のところ、適切な対応策はない。経営にはLeSSは知識が分散しているように見え、集約して管理しようとしてしまう

LeSSの構造がシンプルな故に一般的な組織構造との差を理解することに、かなりの時間が掛かるのであろう。しかし、6年という期間は驚き。また、シンプルが故に、経営陣の交代で壊されてしまうという話は、LeSS導入の困難さが伝わると共に、現在の一般的な組織構造との違いを意識させられる。
また、'フリップ'については邦訳されているLeSS本に記述のない概念です。初めて聞きました。flipという単語は「さっとひっくり返す、急に動かす、軽くはじく」や「軽薄な、軽々しい」「弾く、ぴしっと打つ」というようなニュアンスがあるようです。構造を一気に変更するという意味と合わせて、構造自体は変えること自体簡単だが、その前の仕込みが重要という思いも込められていそう。パンケーキをひっくり返すこともflipと言うらしいですが、生焼けだったりしたら綺麗にはひっくり返せませんからね。日本人ならお好み焼きの方がイメージ付きやすいですかね。

準備期間では、プロダクトの定義。プロダクトオーナー決め。現状のプロダクトオーナの扱い決め。新しい組織構造決め。今いる管理者の扱い決め。Doneの定義。ロケーション決め。ベンダー戦略。といった活動がある
プロダクトの定義は、広い定義を目指す。小さい定義では、チーム連携に加え、ミニプロダクト間の連携など問題が起こる。また、定義を決めることで、どの範囲でLeSSを適用するかが、わかってくる
プロダクトオーナーを決める話。お金をたどるとプロダクトオーナーを見つけることができる。また、プロダクトオーナーはひとりだけなので、今いるプロダクトオーナーの扱いを決めなければならない。ここでは雇用を維持することが重要。基本的にはチームに入って貰う。適当に進めると、後々問題になるのでちゃんと居場所をつくる
管理者についても同様。雇用を維持する。基本チームに入って貰う
組織構造がアーキテクチャ構造であれば撤廃しないといけない。リネームはダメ。Devopsチームもダメ。プラットフォームチームもダメ。チームトポロジーもよくない
Doneの定義を決めることで、学習の範囲も明確になる
ロケーションは同一拠点が良く、全員出社が基本
ベンダーにコンポーネントを任せていたら、内製化する
これらをLeSSの導入の最初に意思決定を行う

LeSSの準備作業から、LeSSは、徹底的なフィーチャーチーム※だということが伺われる。また、1チームのスクラムで実践すべきプラクティスを組織全体へ適用しようとしていることも感じ取れる。方針としては明瞭ではあるが、一般的な組織構造とは異なる。大変な作業となることが予想される。
※チーム単体で他のチームに依存せず、価値提供ができるチーム

LeSSの構造に移る'フリップ'では、強制ではなく、全員がなぜLeSSの構造に変更するのかを理解し同じビジョンを持つことが必要となる
バックログも、チーム構成も作り直す
最初のワーキングアグリーメント、最初のリファインメント、スプリント計画を行う

ここまで、「LeSSの構造」という言葉が何回か出てきている。CraigのKeynoteでも構造という言葉が出てきている。スクラムを学習を始めて10年程度経つが、こんなにも構造について語られた経験はなかった。LeSSを成り立たせるために必要な構造があるということだ。またLeSSはScrumを組織に拡張したものなので、Scrumも構造が重要となるという理解は外れてはないだろう。最近たまたま、Michael JamesとLuke Walterがまとめた、スクラムリファレンスカードという資料をみた。スクラムマスターの役割説明で最初に書かれているのは「スクラムを導入できる環境を組織に作っていく。」というもの。スクラムマスターは、まずはチームから見て、最終的に組織と思っていたが、認識不足だったかもしれない。

LeSSの基本的な改善として、リファインメント、プランニング１、チーム間の衝突というよくある課題が挙げられた
リファインメントは、これまでプログラマーとして活動してきた人が、顧客の課題目線で考えることは難しいため、上手くいかないとのこと
プランニング１（スプリントで扱うバックログアイテムの選択）は、自分たちのチーム目線でしか視点を持っていないため難しいと指摘
チーム間の衝突は、自分のチームはテストコード書いているのにアイツのチームは書いてない！などということ。ただしこれは、コンポーネントチームであったら気づかない課題

フィーチャーチーム、コードの共同所有などLeSSのやり方により、組織の歪を洗い出すことができるようだ。スクラムも同じ効果はあるが、あくまでチームの範囲。LeSSだと組織レベルで効果を発揮する。

継続的なプロダクト開発の改善として「残っている役割をなくす」「完成の定義の拡張」「仕事の並列化」「チームが継続的改善にオーナーシップを持つ」「自動化と標準化の改善」「CICDの改善」「顧客中心の改善」「プロダクトの定義の拡張」が挙げられた
LeSSの構造が守らている限り、チームの人が変わっていくことを見てほしい

シンプルが故に、組織導入の課題は多そう。しかし、Basの言う、LeSSの構造によりチームの人が変わっていく様を私も見て見たくなった。

QAコーナー

Q：LeSSでのCICDを教えて
A：継続的に統合することが大事。プルリクを廃止しましょう。(Bas)

所感：プルリク当たり前な現場が多い中で即答。たしかに、待ちになってしまう。

Q：エンジニアは顧客になりえますか？
A：LeSSでは内部顧客は避ける考えを取る。(Bas)

所感：私は全く気付かなった質問。理由は話してもらえなかったので、AIに理由を聞いてみた。結構いい感じな答え。

真の顧客に目を向けることを阻害
価値の流れが分断される
目標の整合性が損なわれる
政治的な衝突を引き起こす
エンドユーザーの声が届きにくくなる

Q：LeSS is not Scrumというページがある。以前は、LeSSはスクラムだと言っていたかと
A：LeSSはスクラムであった。が正しいかもです。引き続きLeSSはスクラムですが、それは私たちの知っているScrumだという点です。今のScrumは好きじゃない (Bas)

所感：LeSSはScrumから一線を引いている様子ですね。

Q：経営に危機感を持たせるには？
A：メタやテスラの共通点はTopがSW開発者だという点。AI革命でSWが分かる、活用できるは必須。SWは外部に発注するものと考えている人も多いが、これは戦略的失敗。(Craig)　

所感：SWを外部発注しなくなる時代がそのうち来るのかもしれない

Q：プログラマーのマインドセットの変えるのは大変かと
A：仕事に対する姿勢を変えないといけないが、そのためには構造をかえること。コンポートネントだと難しい。誰のためというものを考えてもらう。プログラマーにとっては恐ろしい変化。(Bas)

所感：プログラマーもそうだが、LeSSを導入するという事は、LeSSに関わるすべての人にとって、恐ろしいというかチャレンジが必要になるんだなと思いました。

LeSS Yoake Day5の報告は以上です。（Day5ではabeamさんなど面白いスポンサーセッションもありました。）

今回のLeSS' Yoake全体を通じて、主に刺激となったのは2つ、multilearningの意味。目指すものくらいの感覚でしたが、認識を改めました。もうひとつは、組織構造を変えろというメッセージ。これも目指すものという感覚でしたが、まったく違っていたようです。刺激や学びが多く、今後の学習や活動の方向性に影響を与えるよいカンファレンスでした。

余談ですが、LeSS本を読み直しています。CraigとBasの思いや意図を知った後に読むと、まったく違って見えて面白い。

We Are Hiring!

BIPROGYでは積極的に採用活動を実施しています。システム開発から企画、スタッフなど募集中です。もちろんアジャイル関連案件もあります。詳細は採用ページをご確認ください。