はんなりと、ゆるやかに

アジャイル、スクラムが好きが日々から学んだことをアウトプット

RSGT2024のセッションを見た感想「Outcomeにフォーカスするチームへのジャーニー」

RSGT2024 のYoutubeが公開されたので気になったセッションを見ていきます。
今回見たのは中村 洋さんの「Outcomeにフォーカスするチームへのジャーニー」です。

youtu.be

セッションに関連する記事


セッションを聞いて、重要だと思った要点

  • Output = 作った機能
  • Outcome = 利用者がどう変わったか
  • Output と Outcome はどちらも大切
  • Outputを最小にしてOutcomeを最大にしたい
  • 方法は色々ある(たとえば仮説検証型アジャイル)
  • Outcomeにフォーカスするときチームの状況によってアプローチが変わる
  • まずはOutcomeを計測してみる習慣をつくろう

考えたこと

ここ2~3年ぐらいでOutcomeの大切さをよく聞くようになりました。スクラムに取り組むとベロシティによってOutputが見える化され、その結果、Outputにフォーカスされていく。しかし、大切なのは価値を届けることなのでOutcoumeにフォーカスしましょうと言われているのだと思います。

アジャイルソフトウェアの12の原則にも「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。」があるように、早く作るのは顧客満足を最優先にするためとあります。早く作れること自体は良いことですが、作る目的である顧客満足にフォーカスし続けたいですね。

RSGT2024のセッションを見た感想「スクラムマスターはコーチ?メンター?ファシリテーター?8つの選択肢を探る」

RSGT2024 のYoutubeが公開されたので気になったセッションを見ていきます。
今回見たのはグレゴリーさんの「スクラムマスターはコーチ?メンター?ファシリテーター?8つの選択肢を探る」です。

youtu.be

セッションに関連する記事

セッションに関連する記事を見つけたのでまとめておきます。

セッションを聞いて、重要だと思った要点

  • 状況に応じてスクラムマスターが行う行動は変わる
    • 最終目的を示す
    • 敢えて何もしない
    • コーチ
    • ファシリテータ
    • 介入する
    • スクラムを支持する
    • メンター
    • 先生
  • シーンに応じてディスカッション

考えたこと

ワークショップのセッションです。
対話するために必要なスクラムの情報を紹介し、ワークショップに入りました。ワークショップはケーススタディでした。ケーススタディの内容はスライドをご確認ください。

私ならどうするを考えてみました。
シナリオ1
まずは、イベントをファシリテートして落ち着かせます。そして、ぶつかっている2人それぞれにの言い分を聞き、整理します。そのあと、どうすれば良かったのか、今後どうするのかを議論していきます。
介入とファシリテートですね。

シナリオ2
ふりかえりの場で、良い状態であることを伝えた上で、事実として完成できなかったインクリメントがあることをチームに共有します。
そこから、ふりかえりを始めますが、それ以降は基本チームに任せます。
ファシリテータとコーチぐらいでしょうか。

ケーススタディを使って対話するのはいい勉強会の方式だと感じました。取り入れてみようと思います。

関係の4毒素を考える

関係の4毒素とは?

ジョン・ゴッドマン博士が提唱する「関係性を悪化させる関係の4毒素」は「非難」「侮辱・見下し」「自己弁護・防御」「無視」の4つです。

この毒素がどちらからか出ると、相手も毒素を出し始め関係性悪化のループに入ります。

たとえば、散らかった靴下を見て「いつも散らかして、何度言ったらわかるの!!」(非難)と伝えると、相手は「いつもじゃないだろう!」(防御)だったり、「はいはい。」(無視)などが出やすくなり、さらにイライラが増長します。

この4毒素は人によって出やすい要素と出にくい要素があり、誰しも出てしまうものです。関係性や体調、状況、さまざまなことが起因して出てしまいます。

なので、出さない努力と出たときに修復する努力が必要なのだと思います。

出さない努力

毒素が出そうになったとき出所を把握することが重要だと思います。自分は「何にイライラしているのか?」を問いかけるのです。

出所がわかったら、それは目的達成のために必要かどうか考えて、必要であれば毒素を抜いて共有すると良いでしょう(ここまで考えていると、意識して毒素は抜けるでしょう。)

たとえば、「靴下が散らかってると洗濯し忘れるからカゴに入れておいて欲しいな」とか。

目的達成のために不要なことであれば、私は伝えないを選択します。そして、不要なイライラだったなぁと思います。

修復する努力

努力しても出ちゃうときはあるし、誰かが出している場面に居合わせることもあるでしょう。毒素は別の人の毒素をパワーアップさせるので、積極的に修復しなければなりません。

ここでは、別の人同士が毒素を出したときの解毒について重要だと思っていることをまとめます。

大きくは以下の2つが重要だと思います。
・自分を介して話し合いが進むようにファシリテートする
・暗黙の前提を引き出す

毒素が出る時は意見や考え方の対立が多いと思います。そのとき、両方の意見を受け止めてどちらも大切に扱います。
「ちょっと整理しましょう」みたいな感じで、割って入ります。それぞれの意見を要約しつつ、その意見に至った前提をそれぞれに確認します。およそ、話しているポイントがズレていたり、議論に必要な情報量が違ったり、価値観の違いだったり、していると思います。

それぞれの考えを引き出すと、2つのことが起こります。
①言いたいことがきちんと受け止められて冷静になります。
②相手の前提を知ることで、相手の主張も理解できるようになり、毒素が減ると思います。

議論する土台が整ったら、話し合いを前に進めましょう。

チームに浸透させるには……

4毒素というものがあり、それは、誰でも出ることを伝えると良いと思ってます。そして、出たときに指摘しあうことをチームのルールにしておくと良いですね。認知さえできれば、出たとしてもチームで解決できると思います。

個人的には出さないことをルールにすると窮屈になるので、出たときに助け合えるルールが良いかなと思います。

RSGT2024のセッションを見た感想「チームが狙った成果を出せるようになるために 「目的大事キャンペーン」をしたお話」

RSGT2024 のYoutubeが公開されたので気になったセッションを見ていきます。
今回見たのは西口さんの「チームが狙った成果を出せるようになるために 「目的大事キャンペーン」をしたお話」です。

youtu.be

セッションを聞いて、重要だと思った要点

  • 人を惹きつけ行動を促すためには目的が大事
  • 参考文献:Whyからはじめよ
  • キャンペーンにすることで、組織的に働きかけたかった
  • 賛同者に広めてもらうと良い

考えたこと

目的が大事は共感です。わたしも「なぜ、それをするのか?」を理解してから進めようとしています。その時の工夫としては「なぜそれをするのか?」と質問しないことです。「なぜ?」は問い詰められる気分になるので要注意です。わたしは「○○が目的ですか?」っと当てずっぽうで聞きます。そうすると、相手は問い詰められる感じはなく、教えてあげる気持ちで回答してくれます。

賛同者に広めてもらうという考え方も良いなって思いました。以下のPodcastでも同じようなことが話されていました。「おーい磯野、野球しようぜ!」と中島くんが磯野を気軽に誘えるのは、磯野がいつも賛同してくれるからだという話です。2人目のフォロアーがいないと、中島くんのリーダーシップが出せないのでフォロアーが大事だということです。
www.cultibase.jp

RSGT2024のセッションを見た感想「仮説→実験→検証→学び... プロダクト開発を前に進めるためにMobius Outcome Deliveryを学び 実践していること」

RSGT2024 のYoutubeが公開されたので気になったセッションを見ていきます。
今回見たのは田中さんの「仮説→実験→検証→学び... プロダクト開発を前に進めるためにMobius Outcome Deliveryを学び 実践していること」です。

www.youtube.com

セッションを聞いて、重要だと思った要点

  • Mobius Navigator
    • Discover:問題を設定発見するフェーズ
    • Decide:問題解決する方法を判断する
    • Deliver:決定した方法を届け、学びを得る
  • Mobius Navigatorの考えに基づきアイデアの起案からユーザーに届くまでを見える化することで次の課題が解決できる
    • 施策の繋がりが見えるようになる
    • ボトルネックを見つけやすくなる
    • 他チームに知見を活かせる
  • Notionで見える化を実現
    • 「テーマ」と「実験」という2種類のページがある
    • テーマは「なぜ」「誰に向けて」「測定可能なアウトカム」など記載する
    • 実験は実験内容、結果、所感を記載する
    • 関連するテーマと実験、テーマとテーマ、実験と実験はリンクが貼られる

考えたこと

この運用ができると知見がたまるし、チーム内の情報が見える化し、とても良いと思いました。しかし、運用しきるのは難しそう。メンバーの理解やドキュメントを書く文化など取り入れるハードルは高い。私はこういうの好きだが、忙しくなるとさぼりがちになるので、続けるコツも併せて知りたい。
Discover、Decide、Deviverが明文化され、各つながりが分かる思想は良いと思ったので開発に活かす方法を考えたい。

ObisidianのMind Mapプラグインでマインドマップを書く

Obisidian の Mind Map プラグインを使ってmarkdown記法で書けるマインドマップを試してみました。

github.com

インストール方法

Obisidianのコミュニティープラグインから Mind Map を検索すると見つかります。

使い方

適当なノートを作って、コマンドパレットから「Mind Map」を選ぶとプレビュー用のタブが表示されます。

markdown記法ごとのマップ

見出し

# 見出し1-1
## 見出し2
### 見出し3-1
#### 見出し4
### 見出し3-2
##### 見出し5
###### 見出し6
# 見出し1-2


見出しのサイズが小さければ(# が多ければ)階層も深くなります。

リスト

* リスト1-1
  * リスト2
    * リスト3
      * リスト4
        * リスト5
          * リスト6
            * リスト7
* リスト1-2
1. リスト1-1
1. リスト2
1. リスト3  
    1. リスト3-1
1. リスト4


箇条書きリストも番号付きリストも対応されています。リストはネストすることで階層を表現できます。

チェックボックス

- [ ] タスク1
- [x] タスク2


チェックリストは箇条書きリストと同じ見た目になります。
チェックに応じて表示も変わります。

引用

> 引用1-1
>> 引用2
>>> 引用3
> 引用1-2
>>>> 引用4


引用の数が階層として表現されます。

文字の装飾

* ab *cd* ef
* ab **cd** ef
* ab ~~cd~~ ef


文字の装飾も分かりやすい

コードの入力

# 見出し1
* `コード`を書く
* `設計`をする

「`」で囲った部分がハイライト表示されます。

折り畳み

# <details><summary>abc</summary>def</details>



折り畳みのマークはでますが、展開は変でほとんど見えません。

リンク

# 見出し
* [ブログ](https://iucstscui.hatenablog.com/)


リンクも使えます。

画像の埋め込み

# 見出し
* ![Blog](https://3.bp.blogspot.com/-dknWIXCSs-w/WCqdlXLjszI/AAAAAAAA_j0/AygXNzLm3MclEb3x69Mr195tK84RUfKuACLcB/s800/blogger_man.png) 


画像へのリンクを記述すれば画像も表示されます。

| 左 | 中 | 右 |
|:-----------|------------:|:------------:|
| 左1 | 中1 | 右1 |
| 左2 | 中2 | 右2 |


表を書けばそれっぽく表現されます。

参考

VS Codeでも同じことを試しています。
iucstscui.hatenablog.com

RSGT2024のセッションを見た感想「そうさ、探索適応型のチーム・組織を目指そう!」

RSGT2024 のYoutubeが公開されたので気になったセッションを見ていきます。
今回見たのは市谷さんの「そうさ、探索適応型のチーム・組織を目指そう!」です。

www.youtube.com

セッションを聞いて、重要だと思った要点

  • 過去の勝ち筋を見つけて改善するため、微増微減が続くため、安定はするが成長が鈍化
  • どこかのタイミングで自分たちの可能性を広げる行動をした方が良い
  • 「ユーザー」、「プロダクト」、「チーム」を仮説立てて成長させよう
  • 既に安定して変われないなら、探索をテーマに対話から始めてみる
  • 実行する場合の案
    • 2割を探索活動にあてる
    • OKRやKPIに狙いを織り込む
    • 専任チームを作る
  • 進め方の概要は見立て用
    • 仮説を立てる
    • リサーチの準備と実施
    • 結果を分析
    • 次のリサーチやバックログに積む

考えたこと

開発や事業が安定するとそこに留まってしまう。それでは成長しない。だから、不確実性をあげる行動を取って、進めよう。進め方は「仮説を立てる」「リサーチする」「分析」「再リサーチ or 開発」の単位で考えよう。
というものでした。

「仮説」「実行」「検証」のサイクルを回ることは当たり前のようで難しい。まずは対話というのも理解できました。チーム内で必要だと同意しないと進められないですね。