Training from the BACK of the room まとめ#2

前回に引き続きTraining from the BACK of the Roomの紹介をしたいと思います。

Conceptの概要

Conceptでは学習の内容をトレーニングを受ける人(学習者)に伝える部分。トレーナーは以下のことに気をつける。

  1. 必要な情報 (Need-to-know Information) 本当に必要なことだけに絞る 例えば、時間が半分だったら何を削る？学んだことを持って帰って仕事が成功するために何が必要？10分に内容をまとめるとどうなる？
  2. 視覚化して整理する (Graphic Organizer) Graphic Organizerでググるといろいろ見つかるが、メモを取ってもらうためのあらかじめ、考えをまとめるための補助の絵や図が入っている紙を配る メモを取るということは記憶の定着に役立つ 学習者が自分でどのようにまとめるか決めてもいいが通常はメモを取り慣れてない　ここはメモを取るところですと伝えてもいい　パワポのスライドを渡すのはよくない
  3. 10分ルール (10-minute rule) 10分ぐらいの細かい単位に区切る 10分経つと覚えたことを忘れ始めるので、10分ごとにまとめを入れるといい
  4. インタラクティブなレクチャー (Interactive Lecture) 学習者にも喋ってもらう 質問に対して1人が答えるだけでなくたくさんの人に答えてもらう　たとえば、 "Three Before Me" 最低三つは答えをいう前に学習者に答えてもらう
  5. 1分のまとめ (One-minute Review) 定着を促すためのまとめ The Ten-Minute Trainerという同じ著者の本にいろいろなまとめ手法がある

コンセプトマップ

トレーニング中メモをとると学習内容の定着に良くさらに、絵や図があると良いとPatricia Wolfという人が書いたBrain Mattersに書いてある。 コンセプトマップとはトレーニングで話された内容について視覚的な概要を与えるメモツール　グラフィックオーガナイザーとも呼ばれる

マインドマップ型、フローチャート型、タイムライン型などいろいろある。

インタラクティブレクチャー

上にあるようにトレーニングはできるだけ細かく区切って、まとめを入れたほうが良い。 まとめのやり方には Rapid Response と呼ばれる以下のようなものがある。 1. 講義を一旦止める 2. 学習者に学習した内容の中でもっとも重要ないくつかの(e.g. 5つ)事実を考え共有してもらう 3. 学習者が事実を共有するまで待つ。間違っていない限り全ての事実を受け入れる 4. 学習者から出てこなかった重要な事実があれば追加する 5. 学習者の勘違いがあれば訂正する これは学んだ重要な事実を使うパターンの他にも色々ある 例えば、学習者に学んだ内容からテストの質問を作ってもらう、学習した内容を一文に要約してもらうなどなど

他にも、学習者に60秒で学んだ中でもっとも重要な10の事実をつ書く Beat the Clockというものもある。

ジグソー法

ジグソー法とは学習者同士がお互い教えあいながら学んでいく手法。知識構成型ジグソー法 | 東京大学 CoREFのサイトなど色々なところで紹介してある。 これも色々なパターンがあり、例えば Concept Clinicと呼ばれるのは以下のようなもの 1. それぞれのグループはチーム名を決めてそれをA4用紙かそれよりちょっと大きなサイズに書く 2. それぞれのグループに別の内容をアサインして、グループでは与えられた資料を使ってその内容について議論する　グループは白紙に事実を書き出す 3. それぞれのグループはまとめた内容を隣のグループに渡す 4. 渡されたものをグループで読んで追加の情報を書くというのを　自分のものが手元に来るまで繰り返す 5. それぞれのグループは数分使って自分のチームに紙に書いてある情報のまとめを書く 時間があるなら絵もつける それぞれのグループはそのまとめを壁に貼りみんな見れるようにする

コンセプトセンター

コンセプトセンターとは、テーブルや壁、トレーニングルームの特定の場所を、トレーニングのトピックに関するコンセプトやスキルを学んだり復習できるようにしたもの。学習者は休み時間などにそこを使って、学習したりレビューしたりする

こちらもいくつかパターンがあり例えば、Table Centerと呼ばれるのは以下のようなもの

  • コンセプトセンターになれる前は事前に準備した一つか二つの復習のためのゲームのようなシンプルなものがおすすめ。ゲームのオススメは Learner-Created Gamesのセクションにある
  • 壁に"Game Center - Try Your Luck!"のようなキャッチーなタイトルをつけて興味を誘う
  • 学習者に休憩時間中にそこを訪れてもらうように伝え、仲間と5分程度のミニゲームをやってもらう。
  • もし十分な復習ができるゲームがあったのならトレーニングの時間の5分から10分を全てのテーブルのグループが一回は遊べるような時間を作る
  • ゲームを複数のテーブルに配置して、トレーニングの中の時間でそれぞれのテーブルでゲームをしてもらって、違うテーブルに行ってまた違うゲームをするというようにするやり方もある
  • 慣れてきたら、復習だけじゃなくて、nice-to-know(知っておいたほうがいい情報)をコンセプトセンターとして提供するのもいい。ちょっとしたクイズや間違い探し、空白を埋めるワークシートなどを教材にする。
  • もしトレーニングの1-2時間、コンセプトセンターで使うと決めたら、それぞれのテーブルにそれぞれ違う教材を用意して、テーブルごとのグループに一つやったら次のテーブルに行って違うものをやるようにローテーションさせるというやり方もできる。
  • コンセプトセンターでの時間の後、"学んだ中でのもっとも重要なものはなに？"、"どんなアクティビティが一番有益か？そしてそれはなぜか"、"質問はあるか？"、"さらに勉強したい領域は何か？"、"そのほかに今のアクティビティを通して気づいたことやコメントはあるか？"と行った問いをする時間を儲ける

感想

ジグソー法やコンセプトセンターは結構時間が必要で自分がやっているような社内研修で実施するのは難易度たかそうだなと思うけど、実際アクティブブックダイアログ(ABD)で本を読んでみるという経験を社内でしてよかったという時間があるので、特にジグソー法はチャンスがあれば取り入れたいなと思います。

Training from the BACK of the room まとめ#1

前回からかなり間が空いてしまったんですが、せっかくのいい本だし、日本訳がないのでどんなことが書いてあるか少し紹介できたらと思っています。

本の構成

本の構成としては、トレーニングの構成の4Cの一つに一章使って説明して、その章の中自体も4Cで構成されています。

  • Connection - 学ぶ人がトレーニングトピックに関してすでに知っていることとこれから学ぶこと、学びたいこと、学ぶ人同士のつながりを作る
  • Concept - 学ぶ人が新しい知識を学ぶ その際には見たり聞いたり議論したり書いたり教えあったりなどしながら学ぶ
  • Concrete Practice - 学んだことを実践する
  • Conclusion - 学んだことをまとめたり、評価したり、アクションプランを作ったりする

Connection概要

今回はConnectionに関して紹介できたらと思います。

トレーニングの開始はConnectionから始めると良いと書いてあります、Connectionとは

  • 学習者同士を結びつける
  • 学習者と学習するトピックを結びつける
  • 学習者と学習者が何を学びたいかを結びつける
  • 学習者と学習の成果(learning outcomes)を結びつける

ということだそうです。人間は最初と最後のことをより覚えているという心理学の研究があったりするので、最初に単なる自己紹介で学習の内容と関係ないことやるのはもったいないいうのはそうかもなぁと思います。

Connectionのアクティビティ具体例

この章には、そもそもトレーニングの前にやってもらう宿題に関する章、トレーニングの最初に行う数分で終わるアクティビティの章、もうちょっと長いアクティビティの章に分かれていて、それぞれに説明と具体例があります。

  • Interview an Expert : トレーニングの前の宿題として、これは事前に学習内容に詳しい人にインタビューしてもらい、その内容をまとめるというもの。
  • Think it and Ink it :数分で行うアクティビティ。小さい紙に三つすでに学習内容に関して知っていることを書いてもらいそれを隣の人やグループで共有する。そしてさらに、もう一つ答えを知りたい質問、もしくは、トレーニングの後できるようになっていたいことを書くというものでした。
  • Where Do You Stand: ちょっと時間がかかるアクティビティ。学習内容に関連した課題とその一つの解決策を学習者に対して提示して、その解決策に賛成する人、反対する人、どちらとも言えない人に分かれてもらう。違うグループに存在する人でペアもしくは3人組を作ってなぜその決断をしたかを話し合う。時間があれば、全体でも話すというようなものです。

まとめと感想

いずれにせよ、すでに知っている内容や何を知りたいのか何ができるようになりたいのかというのを考えてもらうと共に、一緒に学習する人同士を知り合ってもらうというところに重点が置かれていてなるほどと思わせる内容でした。

Training from the BACK of the roomの感想

前回、トレーナーのための本 Training from the BACK of the roomを読んでいるということを紹介したのですが、今回は少し内容に触れつつ感想を描きたいなと思います。

タイトルがすごくよく内容を表していると思います。 基本的な考え方として、トレーニングする時は、講師の話を聞かせるのではなく、トレイニーに学ばせる。講師が喋るのではなくできるだけ、トレイニーに喋らせるというというのがあるということです。

そしてその根拠として、そもそもbrain-friendlyな学習とは何かということが書いてあります。 cognitive neurosceinceの研究結果を参考にしているとのこと。講師が前で延々と説明するようなトレーニングはbrain-friendlyじゃないよということ。そもそも脳は新しいことを学ぶのが好き、そしてじっとしていたり、来る返しになることが嫌い。人間は感情は置いておいて情報だけ受け取って学ぶようにはなっていないので、感情を軽視してはいけない。人は基本的に自分を傷つけるようなことは避けるので、喜びを感じるようにすることも大事。人間の集中力は長く続かない。10分ぐらいにできるといいし体を動かすのも大事。図やグラフなどを用いて視覚を刺激したり、音楽を使って聴覚を刺激したりするのも有効。また、トレイニーに学び方を選ばせるのも重要。選択肢を与えて選ばせる。そして学んだ内容を振り返りをする。また部分的なトレーニング自体をトレイニーに仕切ってもらうのもいい。トレイニーに積極的に活動/協力してもらうのが大事。そのためには心理的安全な状態を作り、競争させるより協力させる方がいい。みんなが前(=講師)向いているスタイルより、円になってお互いを見ている方がいい

そしてトレーニングの構成は4Cというのをベースにすると良い 4Cは以下

  • Connection - 学ぶ人がトレーニングトピックに関してすでに知っていることとこれから学ぶこと、学びたいこと、学ぶ人同士のつながりを作る
  • Concept - 学ぶ人が新しい知識を学ぶ その際には見たり聞いたり議論したり書いたり教えあったりなどしながら学ぶ
  • Concrete Practice - 学んだことを実践する
  • Conclusion - 学んだことをまとめたり、評価したり、アクションプランを作ったりする

このやり方はaccelerated learningというのを元にしているという。accelerated learningtとは学ぶということは、精神肉体両方関係ある。学ぶという行為は情報の消費ではなく創造である。学ぶというのは線形に一回だけ起こるのではなくいろんなレベルで起こる。協力は学びを増やし、孤独は学びを減らす。消極的に聞くだけではなく、何かをしながらフィードバックを受けることで学ぶ。ポジティブな気持ちや頭の中で想像したりすることが学びを加速する。というような原則に基づくもの。トレーニングを作って行く時は、最終的にトレイニーにどうなって欲しいのか？何を学んで欲しいのかというところから始めるのが大事。そして、どうなって欲しいのかということが観測可能であることが大事。学んで欲しい。知って欲しいだと観測できない。必要なことだけ教えるということにも気をつける。何を教えるか、どんなアクティビティをするのかは4Cの順番じゃなくていい。色々あげてその後取捨選択して並び替える。そしてできるだけ、トレイニーにリードさせる

こういうことが最初の章に書いてあり、それ以降の章で4Cで具体的にどんなことをすればいいかが書いてあります。そのままトレーニングで使えそうなやり方もたくさん乗ってあって、学校の先生がこの本読んでたらいいのになと思いました。、

Training from the BACK of the Room

現在、会社にAgileやLeanの考え方を普及させるため、Lean & Agile TF(Task Force)として活動しています。 自分の活動の代表的なものとしてはこちらです。

社内向けトレーニングも活動の一環としてやっているのですが、トレーニングに関して体系的に勉強したことないので、Training from the Back of the Roomという本を紹介してもらったので読んでいます。

まとめを社内のwikiに書いていたのですがせっかくなので感想は公開しようかなと思ってひとまず記事を書いています。

社内hackathonでモブプログラミングをやった話

このブログ記事はモブプログラミング Advent Calendar 2018の6日目の記事です。 前日は@sato_ryuさんのモブプロ始めてからやらなくなったアレ、やらなくて良いって訳じゃないし、最近また始めたし。でした。 この記事では経験を共有することで、やってみようかなという人の後押しになればと思います。

概要

会社では毎年hackathonをやっています。私も一昨年は、画風変換、昨年はブロックチェーンを題材にしたプロジェクトに参加しました。 アイデアは事前にアイデアソンやって、エレベーターピッチして、人集めてって感じで決めるんですが、今年は自分でアイデアを出してやりました。私のアイデアはLLVMプロジェクトのリンカlldの作者で有名なRui Ueyamaの作った簡単なプログラミング言語を作るライブコーディングをRustにポーティングしようと言うもの。そして時間があれば機能追加をしようと言うものでした。

hackathonのお題としてはちょっとチャレンジングじゃない感じですが、これは二つの意図があって

  • "hackathonの2日楽しくプログラミングをすること"だけを考えることができる
  • 分割が難しくモブプログラミングに適していそう

と言うことで社内で人集めしましたら、結構トントン拍子に人が集まり、最終的には5人でやりました。 アイデアもきてくれた人の1人が自作のマイコン(CPU, memory, display, bus, timer)シミュレーター(C++)と自作のアセンブラー(C++)を作ったことがあるとのことだったので、 最終形は

と言うことになりました。

メンバーは

内容が初心者向けと言うこともあって、私を含めRustを少し知っている人は2人、アセンブラーやマイコンに詳しい人は1人という感じでした。 みんな違うプロダクトチームに属していてほぼ初めて一緒に働くと言うメンバーでした。

hackathon前

アイデアをプレゼンした後は、五月雨で興味ある人が声をかけてくれたんですが、新しいメンバーが入る度にランチで自己紹介と雑談したり、hackathonでの実施内容を固めたりしていました。 チームビルディングを意識したわけではないですが、今思うとfearless changeのDo Food(何かを食べながら)のパターンになってよかったのではないかと思っています。

hackathon初日

モブプロと書いていますが、初日は、同じ部屋にいて、すぐに話し合えるものの、マイコン/アセンブラチーム2人、コンパイラチーム2人に別れてやりました。 二つのチームの境界線は明らかで、基本的にアセンブラ言語の言語仕様自体はほぼ変更しない方針でしたので以下のようにslackや口頭で何やるかを伝え時々認識齟齬がないか同期しながらやりました。 f:id:nakaly:20181206020521p:plain f:id:nakaly:20181206020610p:plain

hackathon2日目

マイコン/アセンブラチームは初日にほぼやることを終え、かつ初日欠席だったiOSエンジニアも加わってみんなでモブプログラミング。 f:id:nakaly:20181203035846p:plain iOSエンジニアと私がテスト通ったりすると「よっしゃー」って言ったりガッツポーズをしたりワイワイやっていました。

  • 関数導入時にスタックの一番上に戻りのアドレスが書いてあるってのを知らずに実装して無限ループになったり、
  • 2引数関数でグローバルな状態を導入した際にRustの言語仕様にちょっと苦労させられたり、

それなりに詰まったこともあったけど、フィボナッチ数列を取り扱えるところまでは行きました。 作成したもののレポジトリはこちら

モブプログラミングの感想

  • 楽しい
    • 自信を持って言えることはめっちゃ楽しかったです。ほとんど割り込みなくプログラミングに集中するのも久しぶりでしたし、うーんって悩むところもみんなで考えて、他の人のアイデアにおおそれ天才じゃない？みたいに感謝しながらも自分も何かしら貢献していた気がするのは本当に楽しかった。
  • メンバーの心理的安全性大事
    • 後悔しているのは、メンバーの1人が自分がコーディングしているのを後ろからみられたくないと言うことで、ドライバーをやらずナビゲーターのみをやっていました。よく、およべさんがモブプロはチームの問題を可視化すると言っていましたが、私たちのチームでは心理的安全性が十分ではなかったのだと思います。
  • フロー効率良い
    • そして、よく言及されるモブプログラミングと生産性ですが、マイコンとアセンブラーはほぼ完成していたものの、この内容を即席チームで二日それも10:00 - 16:00 お昼休憩ありの実質10時間ぐらいで仕上げたのはなかなか早いのではないかと思っています。
  • どういうときにモブプログラミングするか
    • 私たちは初日はチームを二つのコンポーネントごとに分割し、2日目に統合しました。初日の終わりにお互いのやったことを同期する時間を設けて2日目をスムーズに迎えました。同期のオーバーヘッドはそれほど多くなかったと思います。というのもコンパイラーを書いていたチームはマイコンの実装の詳細を知る必要なく、インターフェース(今回だとアセンブリ言語)さえ知って入ればよかったからかと思っています。これはハッカソンでなくても、プロダクトをコンポーネントごとに分けても、繋ぐインターフェースが明確で疎に結合する場合、分けた方がフロー効率がいい場合もあると思います。

他のメンバーの感想

f:id:nakaly:20181206020634p:plain:w600

最後に

自分のチームではプロダクト開発にもモブプログラミングやモブレビュー取り入れていますが、もっとやっていこうと思いました。あと、これやったことでTuring Complete FMがもっとわかるようになっているといいなぁ。10日目は@matsuoshiさんの記事です。引き続きモブプログラミング Advent Calendar 2018をお楽しみください。

エンジニアのコミュニケーション能力

自分はおしゃべりの力や世間一般でいうコミュニケーション能力や雑談力は低いのだけど、プロダクト開発を早く進めて行くというコミュニケーションに関してはそこそこできると思っています。 そこで、自分が気をつけていることをちょっとまとめて見ようと思いました。

今回はチーム外とのエンジニアとのコミュニケーションに対して気をつけていることを考えてみました。

ほぼ全ての技術的な仕事は問題を解決するために、チームの外の人とコミュニケーションを取る必要があると思っています。 例えば、自分はプログラムが動く環境のOS全てスクラッチでプログラミングしていると行ったって、プログラミング言語を使っている時点でそのコンパイラーやインタープリターに依存しているわけだし、コンパイラーを作っている人だって、CPUやMemoryを作っている人とコミュニケーションすることはあるだろうし、CPU作っている人もその素材を作っている人とコミュニケーションすることはある気がします。

チーム内とは進捗や問題をほぼ毎日共有したりする単位。例えばスクラムで行ったら同じスプリントのタスクをやるようなイメージで、チーム外とはそのチームにいない人ということです。
 私はアプリやWEBサービスを作る仕事をしていますが、社内、社外を含めlibraryの作者、サーバーなのどのインフラを提供してくれるチーム、連携するWEB APIの開発者など様々な人と一緒に仕事をしています。 マイクロサービスなどが流行ったこともあって、社内でもそういうコミュニケーションが必要な場面は多いのじゃないかなと思います。

心構え

  • コミュニケーションの取り方次第で驚くほど柔軟対応してくれる
  • 相手側はついついブラックボックスと考えがちだけど、内部構造や相手の事情を推測したりすることやまた同じエンジニアであることを意識する
  • 自分と相手との関係は理解しておくといい
    • もちろん全てのやり取りする相手を尊重するべきだけれど、やり取りすることで相手の時間を奪うことになるので相手がどれぐらい時間と労力を使ってくれそうかを考えてコミュニケーションするといいと思う　例えば、OSSの使用者と作者、有料サービスサポート付きのユーザーと提供側では使ってくれる時間と労力が違う

チーム外と連携を取る場面

  • バグがありそうな時
    • 正確な再現手順を共有する
      • WEB APIであれば再現するcurlコマンド
      • 再現環境(OSやlibraryのversion)
      • アプリやUI操作を含むものは動画
    • エラーメッセージなどidやtimestampのあるログを共有する
      • libraryじゃなくてWEB APIやインフラなどであれば該当時間に障害があったかもしれない
    • 公開されているバグ管理表があれば似たようなケースがないか検索する
    • OSSや社内でもソースコードが公開されていれば原因を探してみる。可能であればPRを作る
  • 使い方がわからない時
    • 公式のドキュメントやFAQを読んだり、社外のものであればWEBで検索したり、社内のもの出れば社内のwiki的なこのを検索したりして解決できないか調べる
  • 共同で開発する時
    • 出来るだけ早く連携する
    • 自分たちが必要と思う部分だけではなく背景も伝える
    • リリース日に依存関係がある場合十分にバッファーを持ったスケジュールにする

コミュニケーション全般で気をつけること

  • 曖昧さをできるだけ排除する
    • やり取りの中で出てくるAPIなどは公式ドキュメントのリンクとともに伝える
  • やり取りはログが残り形にする
  • 使っている言葉が違うことがあるので相手の使っている言葉に合わせる

こちらに書いていることは、チーム外とのコミュニケーションに限らないことも多いと思いますが、チーム内であればもうちょっと雑でもいい気がしているので、個人的にチーム外の人とコミュニケーションするときに特に気をつけていることをあげてみました。