Training for D-Day

ブログの内容は個人の見解であり、所属する企業を代表するものではありません。

スクラムの記事まとめ

7月~9月にかけてちょこちょこスクラムやLeSSに対して自分なりの言いたいことを書いてきた。 少したまってきたので、リンク集作成。

note.mu

note.mu

note.mu

note.mu

note.mu

note.mu

note.mu

あとはプランニングと振り返りとスプリントレビューとデイリースクラムかな。 デイリースクラムとプランニングは前に記事書いたけどあんまり追加要素ないかも。

YOU SAID IT BUT DID THEY GET IT? HOW TO CHECK FOR UNDERSTANDING - あなたはただ言っただけ。みんなはそれを自分のモノにしてる? "理解"を確認する方法 -

YOU SAID IT BUT DID THEY GET IT? HOW TO CHECK FOR UNDERSTANDING
- あなたはただ言っただけ。みんなはそれを自分のモノにしてる? "理解"を確認する方法 -

シャロンさんのページちょっと意訳。

https://bowperson.com/2019/09/you-said-it-but-did-they-get-it-how-to-check-for-understanding-2/#more-8137

みんな本当に理解してるのかしら?

あなたは研修の講師。
受講生に、「理解した? 」ってきいたら、みんな頷くよね。
「何か質問は?」ってきいたら、みんな首を振るわよね。

でも後日、会社からクレームがくる。
「あの研修で、受講生が得たものは何もなかったぞ!」
「何も変わってないじゃないか!」
つまり、みんな理解できてないわけ。
”理解できた”ってことを確認する方法をいくつか紹介するよ。
これは受講生の理解を促すのにも役立つ。

理解を確認する方法

4つのBACKを覚えてね。4-backs。

REPEAT-BACK

リピートバックは、学習者同士に学んだことを教えあってもらう方法。要点は3~4つにしておく。
1対1でもいいし、1対多でもいい。何回も繰り返してもいい。
教えたときに間違いがあったら、その場でフィードバックをもらって、訂正してもらうように事前に言っておく。
間違ったままの理解はないようにしたほうがいい。
講師はREPEAT-BACKを、耳を澄まして聞いてみて、どのあたりが理解できてないポイントなのか探ること。まとめとして受講生に伝えるといい。

THINK-BACK

Think-back 別名、passive reflectionとも言う。
学習者に自身で考える時間を与えます。考える前に、こう問いかけます。「今学んだことを、あなたのこれからの仕事にどう役立てますか?」
そして考えを共有してもらい、その考えに対してフィードバックやディスカッションをします。

PLAY-BACK

今学んだことで即興演技(インプロ)をしてみましょう!
別名ロールプレイとも言う
即興演劇の部隊を講師であるあなたがすぐに作り、学習者に説明します。学習者はインプロを実践します。
インプロは1~2分程度の短い寸劇にしましょう。楽しく楽しく進めましょう。このインプロの内容から、学習者が自身の環境へ学んだことを適応できるかどうかを見てみます。
もし適応できなさそうだったら、職場に適応するのも難しいかも知れませんね。学習者の弱点がわかりますので、それを活かして研修をより理解の深まるものにしていきます。

REPORT-BACK

研修の時間が終わったからと言って、学習が終わるわけではありません。学習者は学んだことを職場なり実践の場で応用していかなければなりません。
実践の結果を報告する必要があります。これを実践とフィードバックの法則といいます。新しい学びは、繰り返し練習して、フィードバックをする習慣がないと身につかないです。
毎日の仕事の終わりに、学習者から講師に対して、何を試したが、何が良くなかったか、何が良かったか、途中であった困難などを連絡してもらいます。

終わりに

受講者が学習したことを耳に入れただでなく、”理解する”そしてそれを実践する、ことが必要です。
受講者と新しい情報を共有している間と後の両方で理解を確認することで、あなた、従業員、および会社の双方にとって有益な学習体験を作成できるでしょう。

感想

研修やワークショップでただただインプットを続けるのは退屈。
頭を随時使って身のある時間にするためには、こうゆう工夫が必要ですよね。
教育の現場でもそうだと思うし、人が集まるところではどこでも使えそう。
学習する組織とか、知識創造企業は、書いてあることはたしかにもっともなんだけど、こうゆう工夫がないと学習成果の最大化は難しいんだよなぁと思ったり。

学習する組織――システム思考で未来を創造する

学習する組織――システム思考で未来を創造する

知識創造企業

知識創造企業

ちなみに、シャロンさんの上記のテクニック集は以下の本にあるみたい。

The Ten-Minute Trainer: 150 Ways to Teach it Quick and Make it Stick! (English Edition)

The Ten-Minute Trainer: 150 Ways to Teach it Quick and Make it Stick! (English Edition)

2級小型船舶と特殊免許

20年前に4級小型船舶免許を取ったのだが、
2004年くらいに更新せず、失効してしまっていた。

家族旅行で沖縄や宮崎に行く機会が多いので、楽しさの幅が広がるかなーと考えて再交付を受けることにした。16900円。

4級取るときは8万くらいかかったかなー。当時学生だったので痛かったが、、、

そのおかげで千葉県御宿中央海岸でジェットスキーで海の監視ができたので良かったのだが、・・・

 

今は制度も変わり、特殊、2級と1級とう3区分になり、
特殊は水上オートバイ
2級は、5海里まで20トン未満の小型船舶
1級は、海域制限なし、20トン未満の小型船舶

ということになる。

4級からの移行だと、特殊と2級が取れるとのこと。

ということで、再交付講習を受けてきた。2時間半。
八王子でもやっているとは驚き。

免許更新講習のあと、再交付講習があるのだが、・・・
再交付講習受講者は


一人・・・

でした。


その後、理解度テストもあって、10問中10問正解で無事再交付を受けられることになりました。


講習で言ってたことは・・・とにかくライフジャケットを着用しなさい、とのこと。

 

ライフジャケットつけないで海に入るのは確かに怖い。

泳げるといっても服着てると全然重くなっちゃうし、

子供が海に投げ出されたら救うのは結構大変だよ。

 

というとりとめもない話でした。

 

More with LeSS: A Decade of Descaling with LeSS - Graig Larman

グレイグ・ラーマン
LeSSの考案者の一人であり、ソフトウェア開発の様々な著書がある方です。
特に、実践UMLは、タイトルに"UML"が載ってしまっているので、UML関連の本かと思いきや、全然そんなことないです。
デザインパターンアジャイルに関する本ですね。ボリュームがすごすぎる。



実践UML 第3版 オブジェクト指向分析設計と反復型開発入門

実践UML 第3版 オブジェクト指向分析設計と反復型開発入門

  • 作者: クレーグ・ラーマン,依田智夫,今野睦,依田光江
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2007/11/12
  • メディア: 単行本(ソフトカバー)
  • 購入: 8人 クリック: 179回
  • この商品を含むブログ (29件) を見る







マーチン・ファウラーのUMLモデリングのエッセンス同様、UMLは知識を共有するための手段であり、コミュニケーションを円滑にするツールに過ぎないと謳っています。
私もこれは完全に同意。
よくあるのが、設計フェーズだからUMLを書かなければならない、とか、クラス図とシーケンス図を書かならければならない、とかの意味不明な取り決め。
これは全く意味がない。
コードを書くことが設計ですから。

UML モデリングのエッセンス 第3版 (Object Oriented SELECTION)

UML モデリングのエッセンス 第3版 (Object Oriented SELECTION)





グレイグ・ラーマンは、言います。
一つの部屋にホワイトボード10枚用意して、スプリントプランニング時にUMLをホワイトボードで書いてチームで理解を深めよ。




グレイグ・ラーマンのLeSS研修を受けた方のコメントが面白かったです。


https://www.adventureswithagile.com/course/certified-less-practitioner-training/


「これまで受けた研修で最高。すべてが吹っ飛んだ」



Youtubeに何本かグレイグ・ラーマンのレクチャーが載ってました。

www.youtube.com

いくつか気になったところを抜粋。

Find the ten people and write the entire thing themselves.

Our Key Advice
large -- don't
multisite -- don't
offshore -- don't


Kent Beck said
Software development is a learning activity with code as a side effect.
And I think that's a really insightful way of describing what's going on programming, coding and both Bas and I work as professional programmers I'm not a primarily teacher and a paid programmer. So we come at this from the point of really understanding the nature of the work and indeed it is primarily a knowledge creation or a knowledge discovery activity.



アジャイルってなんなんだろう
改善・探求・発見・学習・旅・変化。。。

核心に迫るための問い

価値の低いコーチン

コーチングをされていたり、していたりして思うことがある。

実際のところ、本当にこれ(今話していること)が重要な問題なんだろうか、と。

コーチングされる側にたっていて、コーチングの最初の導入で、コーチにこう言われることがある。

「今日お話したいことはなんですか?」

実は話したいことなんかない、あんまり頭が整理できていない、考える時間はほしいけど、コーチングの時間はだいたい時間が固定で30分~1時間と決められているので、早くしないと時間とお金がもったいないなぁ
なんて損得勘定が働いてしまい、割とどうでもいいことを話はじめたり。。。 私の場合は、「英語をもっと喋れるようになりたいんです」とか。

重要だし、必要なんだけど、それってコーチしてもらうところじゃないような。。


ということで、こんな気持ちを抱くことがあるわけです。

本当に話をしたいことを一緒に探っていくために


で、この状況を少し打開するための問いが、以下の本にありました。


リーダーが覚えるコーチングメソッド ――7つの質問でチームが劇的に進化する (フェニックスシリーズ)

リーダーが覚えるコーチングメソッド ――7つの質問でチームが劇的に進化する (フェニックスシリーズ)

  • 作者: マイケル・バンゲイ・スタニエ,Michael Bungay Stanier
  • 出版社/メーカー: パンローリング
  • 発売日: 2017/08/12
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る




コーチングをはじめるにあたって、「今日お話したいことはなんですか?」は、これはこれで良いと思う。

もう一つある。これは割と気軽にコーチングじゃない場合でも使えるかも。「何を考えているのですか?」

で、何かを答えられたら、それが核心かどうか聞き返します。

「他にはないのですか?」

「まだ、他にはありませんか?」


そして、話をしたいテーマを探ります。本当に話をしたいテーマを。


そのテーマが本当に重要なのか、再度問います。

「今、あなたにとってほんとうの問題は何ですか?」


この質問に相手が答えることによって、本当に話したかった問題の中の核心に迫りやすくなります。





つづいて、相手が求めていることを問います。

「何を求めていますか?」

「私に何かお手伝いできることはありますか?」

「これに はい と答えるなら、何に対して いいえ なのですか? 」






まとめ

コーチングに限らず、人生は、dance in the momentなのですが、本当に相手が話したい内容を導くのは結構重要な技術が必要だなぁと思いました。

その一つのツールとして、 「何を考えているのですか?」
「他にはないのですか?」
「まだ、他にはありませんか?」
「今、あなたにとってほんとうの問題は何ですか?」
は結構使えると思います。

良いプロダクトバックログリファインメントの兆候

ちょっと良い記事があったのでメモ。 ちなみにLeSSのリファインメントも同じようなこと言っている。

www.scrum.org

プロダクトバックログリファインメントのアイディア。 Main Ideas

Developers should communicate directly with the stakeholders. ・開発者はステークホルダーと直接コミュニケーションを取るべき

The whole Development Team participates in the refinement. ・開発チーム全体がリファインメントに参加する

The Development Team as a whole is responsible for business analysis. ・開発チーム全体でビジネス分析の責任を負う。

Product Owner is more focused on ordering while the Development Team on clarifying items. ・開発チームは、優先順位の高いアイテムの詳細化・明確化に取り組む一方、プロダクトオーナーは、優先順位付けに、より焦点をあてる。

Refinement can be conducted effectively in small groups using diverge and merge cycles ・発散と集中のサイクルを使用してリファインメントを効果的に行う

リファインメントって奥がすごい深くて、 単純に集まってバックログを明確化すれば言い訳ではないんですよね。その場自体をワークショップ的にして、 より学びが多い場にする必要があります。しかもステークホルダーも参加するとなったら、忙しい人が集まるから、ちょっとでも退屈させたら申し訳ない気持ちにもなる。 スクラムマスター疲れるわ、こりゃ。

【Mac】Finderの調子がおかしいときの対処方法

なんか、TerminalとかからVimでファイルを作っても、Finderで表示しても表示されない問題が発生した。

とりあえず、Option押しながらDockのFinderを長押しすると、「再度開く」メニューがでるので、それでFinderを再起動すると直った。