LeSSワークショップに参加してきた

# 前提
前回のLeSSイベントでは、どの程度組織がLeSSを導入できているのか？
を計測する8つのメトリクスについての講演でした。
今回は、そのメトリクスのうち以下の7つの因果ループ図を描き、
キーとなる根本原因を探索するというワークショップ。
<img width="600" alt="IMG_0306.jpg (1.4 MB)" src="https://img.esa.io/uploads/production/attachments/5827/2024/02/23/135213/cd0f8329-4d43-476e-b84f-e92a7f041a73.jpg">

https://less.works/jp/less/principles/systems-thinking　システム思考

# 成果物内容
各チームスクラムマスターやコンサルといった様々なロール別にテーブルを分かれて
因果ループ図を作成しました。
上記のメトリクスだけでは、因果関係を結ぶことはできないため、
各チームで「こんな変数を間に挟めば、繋がる」という変数を列挙し結んでいきました。

## チーム①
<img width="700" alt="IMG_3025.jpg (698.1 kB)" src="https://img.esa.io/uploads/production/attachments/5827/2024/02/23/135213/284d4329-ff58-4d77-9b2a-f392c1ffa062.jpg">
こちらのチームでは、起点は【一人当たりの一日のコミット数】。
1日のコミット数が増える→コンクリフトの数が増える
    →チーム内外の会話増加→共通認識が持ちやすくなる→助け合いの機会増加
    →ストーリーをたんとできる人数が増える→・・・(省略)
    →仮説検証の精度が向上してくるので→チームの学び増える & プロダクト価値も向上するので
    →全員が当事者意識持った、全員でPOやPMのロールという良いチーム
    →それによってPOの負担は減少している。

### 個人の見解
また図にはないが、個人的には
    良いチームであるので→自ずとチーム内外の会話の質が向上し
    →共通認識をより短時間で持ちやすくなり→より助け合いの機会が向上する
この状態の時には、実質障害時にもフィーチャーチーム構造を取っているようなものだと考えられるので、
バグの原因特定にかかる時間も短縮し、さらに継続的な学習によって重大なバグの量も減っていると考えられる。

この状態は組織として非常にエンゲージメントが高い状態と考えられる。

仮説検証の質が上がることによって、
最終的に組織全体でバグ対応の質も改善されて行き、
おまけに素早く価値を届けられるようになることで、エンゲージメントが上がるという
好循環が非常に理想的なチームだと感じる。

## チーム②
<img width="700" alt="IMG_7106.jpg (391.4 kB)" src="https://img.esa.io/uploads/production/attachments/5827/2024/02/23/135213/6bbc6c02-3e6a-41c1-b625-4ca50c1b1ed9.jpg">

個々のチームは確か、スクラムマスターロールの人々という観点での因果ループ作成であったので、
スクラムマスターの仕事が与えるインパクトに関心が生きやすいモデルでした。
こうやって見ていると、スクラムマスター自身が提供する場づくりって改めて重要ですね。
あとここでの成果物の発表では、
最初からコンポーネントチーム体制で分業が進むと、同じ質量だけのタスクをこなしても、
給料が異なるという、なんともモチベの下がる現象を引き起こすトリガーの説明も受けた。
それでもなぜ頑なに、コンポーネントチーム体制でやるかというと、
マネジメント層が【管理しやすい構図】だから　だと聞いて非常に納得しかなかった。

### 個人の見解
自分の所属する組織では、当たり前のように管理職層が最初からビジネスサイドと開発者サイドの分業でチームのコンテキスト境界をはっており、
しかも自分以外の多くの者が、発注者POが背景の説明を言語化できていないがゆえなのか、
そのビジネスの背景に関心を持とうとしない　という構図が続いている。
結果的にチーム全体の設計スキルなども上がりにくいという場の性質を生み出しているなと
実体験と照らし合わせながら納得していた。

## チーム③
<img width="700" alt="IMG_2040.jpg (1.3 MB)" src="https://img.esa.io/uploads/production/attachments/5827/2024/02/23/135213/902a2184-4ffa-4df5-9908-18f2bade4cd9.jpg">
起点は【モブプロ回数】という変数。
コードのレビュー数という変数を意図的に減らす(モブプロする)ことで
    →属人的コードを減らす→するとコード品質が向上する

たしかに、プルリクしてからコードレビューするよりも、
そもそもそのプロセスをまとめてモブプロにした方が、無駄な手間を減らせることは立証済み。

### 個人の見解
技術的負債が減ると、価値の提供がしやすくなるところに矢印が引ける。
それによって利益向上し→一人一人の給与が向上し →退職者は減少傾向
という関係線も引けるなと。
あとは、意図された技術的負債がないと、実践的なリファクタリング経験が積めないので、
それはそれで開発者のスキルが養われないから、
継続的に意図された技術的負債を肌で感じ取れるようにできるよう、
組織全体で文化づくり、文化のメンテもしておくことによって、
安定的な思想と、刺激的な新たな挑戦といった変化しやすい思想がバランスよく混在できる。
それによってたとえ給与が上がらずとも、毎日の仕事が刺激的であるがゆえに、
退職者は減るという構図もあると感じました。

## チーム④
<img width="700" alt="IMG_0312.jpg (1.5 MB)" src="https://img.esa.io/uploads/production/attachments/5827/2024/02/23/135213/121c4719-1015-4887-9c63-ba9caf4f9e70.jpg">
こちらは自分の所のチームであり、起点は【各スプリントにおける進行中の先祖の数】。

最初は、「フィーチャー度合い」と「コンポーネントチーム度合い」という２つの変数があったが、
そもそもフィーチャー度が低ければ、それは分業されたコンポーネントチームと言えるので、
途中で１つの「フィーチャー度合い」という変数にまとめた。

後から気づいたことですが、以下の課題点が明らかになりました。
・時間の観点での変数がない
・エンゲージメントなどの人の気持ち系の変数がない

また、フィーチャー度合いというものが抽象的すぎるので、
もう一段階細かく分割した上でだったら、より強固な因果関係が完成したであろう。

ワークが終わってから「コミュニケーションの量より質だよね」という議論にもなり、
「でも最初から高い質なんて難しいからまずは量を意図的に増やすことからじゃない？」
みたいな振り返りを行いました。

### 個人的振り返り
ちょっと変数を削り過ぎてしまっていて、確かに全体かんを俯瞰はできるはできますが、
もう２段階くらいの詳細な変数を出したうえでじゃないと、
変数同士のつながりが弱いままだなと他のチームの成果物を見ていて感じました。
このあたりの論理の飛躍の予防の練習として最近読んでいる
【ロジカルプレゼンテーション】で経験を積んでいきたいと感じます。

# まとめ
最後の振り返り会では、
あまりに細かい変数を列挙してしまうと全体観を失ってしまうけども、
かといって俯瞰し過ぎた変数だけでは、因果関係のつながりが弱く感じてしまう。
このバランスが結構難しいというお話をした記憶です。

あとは、開発生産性のFour Keysのお話や、
技術的負債の原因って文化的負債だよねって話も参加者の方と議論しました。
どこかで組織内の生産性の因果ループ図のワークショップもやりたいな。