LeSS' Yoaké ASIA 2024参加記録-Day5
LeSS Yoakeという国内初のLeSSカンファレンスに参加してきました。個人の復習を主目的としての記録します。Day1に続いてDay5。（Day2-Day4はトレーニングセッション。）
Sponsor 企業変革の現実から考える「組織レベルのアジャイル」への道のり ABeam Consulting
あんまりメモを取れなかった、、、記憶のある部分だけ。
大規模案件（数千人月）への適応
純粋なLeSSの適用は困難と考え、まずはProjectベースでまずは成功を体験してもらう。20年のキャリアを踏まえてこの方法が答えである。
要員のアサインに渋られたとき、「大事なプロジェクトなのに何故アサインできないのか？」など議論した。
優先順位を経営含め合意した。やらないことも決めてもらった。
当たり前品質をパターン化した。
Q：複数チームでQAができた。自ら品質を組み込むのが難しい。そのあたり教えて。
A：がんばりますで終わらせない。チームにやらせる。仕組みを入れる。無理なら人を入れる。確実に回るようにすることが大事。
Q：大規模だと振り返りは？
A：イテレーションの単位で振り返りを行った。ただ、日々の作業を忘れてしまうので、日々やったことや課題を記録してもらうようにしている。
Q：説明するときのデータはどこから？
A：Craig Larmanの書籍を根拠にした。あとは自社の成功事例を示した。
Closing Keynote LeSS導入はどうやるの？ Bas Vodde
教育Ph、フリップ、LeSSの構造の維持。といった流れ。
LeSSの導入前後で認識が変わったりする。
先に研修を受けた人のイライラをよく聞く。
※理解や認識の差によるものと考える
教育はギャップのある状態から、ギャップを埋めていくこと。Basのクラスで紹介したが、6年間実施した。
学習の期間は非常に長い。
教育が終わるときは「そろそろLeSSを導入しようか」と言うとき。
教育が終わると、LeSS導入の準備期間となる。ここが一番難しい。
準備が終わると、フリップ。これは一週間くらい。
※フリップはLeSSの構造に変える期間。
LeSSの構造になって最初の６か月はよくある問題に対応する。そのあと本格的な問題に対応する。
LeSSを導入して、定着していたとしても、経営が変わると、LeSSの構造を壊されることがよくある。今のところ適切な対応策がない。LeSSコミュニティの課題でもある。
新しい経営「知識が分散している！どこかに管理すべきだ！！」
Bas「8年もかけたのに。。。」
準備期間でやること。
プロダクトの定義は？
これが最初のStep
広い定義を目指す。これは一般的な理解とは逆になる。
客に価値を提供するのに、小さいプロダクトだと、大量の問題を引き起こす。
プロダクトの方向性を変えるとき。ミニプロダクトそれぞれの優先順位を変える必要がある。
チーム連携に加え、ミニプロダクト間の連携が必要となる。
プロダクトは技術の寄せ集めと思われているがこれは誤り。パーツの集合でもない。
LeSSでは顧客が捉える定義を使う。顧客が考える定義と同じかそれ以上に大きい範囲を扱う。
ミニプロダクトだと、顧客との会話が難しい。
250人くらいで1プロダクト。
これを決めることでどの範囲でLeSSを適用するかわかってくる。
プロダクトオーナーは誰？
1プロダクトで1人のプロダクトオーナー
今のプロダクトオーナーのほとんどは、プロダクトオーナーではなくなる。
プロダクトマネージャーでも管理者でもない。
プロダクトオーナーはVisionを定め、バックログの優先順位を決める。予算を握る。
※Basではなく、通訳として来日していた元CSTのエマーソンとの雑談で。Visionとは見て、何をすべきかが分かる具体性。朝起きて「Vision達成ために仕事するかー」となるようなものでなければらない。とのことでした。そういうVisionてあんまないよね。
お金をたどるとプロダクトオーナーを見つけることができる。
今のプロダクトオーナーをどうするかを決める
役割の維持よりも、雇用の維持が重要。
チームに入ってもらう。
元プロダクトオーナーがチームに入ると、無理と思ったり、降格されたと感じることがあるが、ちゃんと居場所を決めてあげることが大事。あとあと問題となる。最初にきちんと決める。
ふたりのプロダクトオーナーはだめ。
新しい組織構造はどうなっている？
LeSSは組織設計である。
機能チームを削除する。
QAチーム、UIチームは削除
チームの人はクロスファンクショナルなチームとなる。
管理者はどうするか決める
チームの中に入ってもらう。もしくは、クロスファンクショナルな管理者となってもらう。
LeSSではチームメンバーだけでなく、管理者もクロスファンクショナルである必要がある。
組織構造がアーキテクチャ構造であればそれを撤廃する。
避けること
コンポーネントチームをリネームすること。
チイトポ使うこと。
Devopsチームもダメ。プラットフォームチームもダメ。
プロダクト全体で一つのDoneの定義を話す。
プロダクト定義の時に、どこまでが学習の範囲とするかを決めないといけない。
初期ではUXを外に置いたりする。こういうことがDoneの定義から導かれる。
UXを外に置くべきということではないよ。
ロケーションとベンダー戦略の明確化
同一拠点がベスト
様々な研究によって、リモートは個人ワークではうまくいくがチーム作業ではネガティブインパクトを起こすことが分かってきている。LeSSではこれを重要視している。
週5オフィスがよい。ハイブリッドにするなら、出社日を固定にして、全てのチーム全員出社させる。個人の判断で、やらせない。勤務場所がバラバラだとリモートと同じになる。出社日に共同作業が必要なリファインメント、レトロ、プランニングなどを行う。
拠点が複数ある場合は、閉めましょう。ひとつにしましょう。
ベンダーにひとつでもコンポーネントを任せていたらコンポーネントチームになる。
内製化してください。
顧客価値を最大にしたいのであれば、スコープの調整ができるようにしなければならない。大きなコストを支払うことになります。沢山支払うコスト最適であればまぁいいけど。
LeSS導入の最初に意思決定する。
フリップ LeSSの構造に移ること。
まず、全員がLeSSの構造への変更をなぜするのかを理解する。
チームにLeSSの構造を強制すると上手くいかない。同じビジョンを持つことが必要。
バックログを最初に作るが、最初から作り直した方がよい。
チーム構成を変える。チーム構成はチーム自身に考えてもらう。
チームがスクラムマスターを選ぶのではなく、スクラムマスターがチームを選択する。難しいチームを経験豊富なスクラムマスターが見れるようにするため。
そのあとは、最初のワーキングアグリーメント、最初のリファインメント、スプリント計画を行う。
直ぐには機能しません。基本的なLeSSの改善を行う。
リファインメントはうまくいかない
プログラマー（だった人）が顧客の課題を考えることになれてない。
プランニング１が難しい
最初は、リファインメントが上手くいってないので、優先順位にならんでない。
自分たちのチームが～の目線しか当初はもてない。これをどのチームがどのタスクを選択するのが最善かを考えるようにする。
オフィスの最適化が進んでない。
チーム間の衝突
テストコード書くチームと書かないチームにイライラ。
しかしこれは、コンポーネントチームでは気付くことはない問題。
継続的なプロダクト開発の改善
残る課題、継続的に対応を続ける必要がある課題はこんなのがある。
残っている役割をなくす
完成の定義の拡張
仕事の並列化 ※UXチームがまだあったりする。
チームが継続的改善にオーナーシップを持つ ※コーチの言いなりではなく、言い返すくらいじゃないとね。
自動化と標準化の改善
CICDの改善
顧客中心の改善
プロダクトの定義の拡張
LeSSの構造が守らている限り、チームの人が変わっていくことを見てほしい。
顧客の課題を考えてもらおう。
QAコーナー
Q：LeSSでのCICDを教えて
A：ビルドだけではない。継続的に統合することが大事。プルリクを廃止しましょう。プルリクは結合が遅れるだけのもの。 Bas
Q：プロダクトのスコープを広くというのは難しい
A：LeSSHugeのエリアをつかったらどうか？顧客中心でエリアを分けていく。そうすると、現実的には触るコードがエリアごとにわかれるようになる。 Bas
Q：エンジニアは顧客になりえますか？
A：LeSSでは内部顧客は避ける考えを取る。 Bas
Q：LeSS is not Scrumというページがあるが？以前はLeSSはスクラムだと言っていたかと、、、
A：LeSSはスクラムであった。が正しいかもです。引き続きLeSSはスクラムですが、それは私たちの知っているScrumであるという点です。今のScrumは好きじゃない Bas
基礎の話ですが、LeSSの基本がScrumだとして、Scrumが変わってしまうと困りますね。 Craig
最初にBasと考えたのはLeSSはLeSSと思ったが、スクラムと結合するのがマーケティングにとって価値があるものとしたため採用した。今後はPDSAサイクルに変えても良いかもとも思った。 Craig
Q：何もできない人はどうするの？しばらく受け入れる？
A：そう。システム思考の11の法則などがおすすめです。Bas※たぶんこれかな？
両方大事だけど両方はできない。時差がある、忍耐が大事。 Craig
学習機会は、インパクトがあります。 Bas
トランスペアレントという論文があります。Bas※これ見つからない…メモ間違か？
現実的なアプローチとしてペア作業。ペア切り替えのタイミングの研究がある。1時半が効果的。ペアの学びがチーム全体にいきわたる。 Bas
あと、最も不適切な人が実装するというアプローチもある。効率性が圧倒的に下がると思われたが、2週間後には高い生産性を示していた。 Bas
効率性は想定と大きく異なる。物を作るのではなく、知識を創造すると捉えると良い。不適切なバックログを選べと言っているわけではない。 Bas
Q：経営に危機感を持たせるには？
A：メタやテスラの共通点はTopがSW開発者である点。AI革命でSWが分かる、活用できるは必須。SWは外部に発注するものと考えている人も多いが、これは戦略的失敗。これができないと、その国は観光業が主体となり衰退する。国レベルの問題。開発者はSW工学が必須であり、高給である前提に立たないといかん Craig
Q：トップマネジメントが変わるとLeSSが前の構造に戻るというのは？長い時間かけたのだから構造は維持されそうだが？
A：前の構造に戻るとは言ってないし、8年かけて構造を変えたわけでもない。シニアマネージャーは新しいことをしたいので、構造を変えたくなる。トップを内部から選ぶとこうなりにくい。デミングが言う「継続的に目的を継続する」という考え Bas
※このあとCraigもコメントしていたがうまくメモ取れてなかった…
Q：LeSS版のスクラムガイドにリーン思考がなくなったのは？
A：スクラムの歴史を知っているが、スクラムはリーン思考ではない。 Bas
Basの言う通り。 Craig
Q：PGからProduct Developerになるというが、そのマインドセットの変えるのは大変では？
A：私の意見。仕事に対する姿勢を考えて。PGの姿勢は要求をもらって要求通りに作るという姿勢。Product Developerの姿勢は、顧客の課題を解決するという姿勢。例えばGrooveXのラボットは誰も要求していない。誰も課題と思っていなかったものを課題として解決した。顧客も自分の課題をしらない。要求を発見すること。そのためには構造をかえること。コンポートネントだと難しい。Bas
気にするというのが大事だよ Craig
なので、誰のためというものを考えてもらう。PGにとっては恐ろしい変化。やるべきことを誰も教えてくれない。 Bas