Training for D-Day

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

コンポーネントチームとフィーチャーチーム

コンポーネントチームとフィーチャーチーム

フィーチャーチームの定義

そのチームがフィーチャーチームかどうかは以下で判断できる。
・そのチームだけで最終出荷製品が作れるかどうか。

リーン思考では、手渡し作業、待ち状態、仕掛り作業の制限、情報散財、未活用の人々、これらは致命的となる。
クロスファンクショナル、クロスコンポーネントフィーチャチームはそれらの無駄を減らすためのパワフルな解決策となる。

理想的なフィーチャーチーム

  • 長期間存続。
  • クロスファンクショナルでありクロスコンポーネントである。
  • 一緒に同じ場所で働く。
  • 要求分析、デザイン、プログラミング、テスト・・・顧客中心の機能をすべてのコンポーネントにまたがって実現する
  • 多能工で構成される
  • スクラムにおいては、7±2人で構成される。

フィーチャーチームのメリット

価値のスループットが増加する

顧客もしくは市場にプロダクトを届けることに焦点をあてる。

学びの増加

個人とチームの学びは、広い責任と様々なエリアのスペシャリストが集まり協働することによって増加する。

よりシンプルな計画をすることになる

組織的に計画がより簡単になる。例えば、コンポーネントチームが複数あった場合、それぞれのコンポーネントチームと調整が必要になるが、
フィーチャーチームの場合、このフィーチャーチームだけで調整は閉じている。

手渡し作業の無駄を減らせる

要求分析、デザイン、プログラミング、テスト・・・などのすべての作業において手渡し作業の無駄を減らせる。

待ち時間の無駄を減らせる

複数のコンポーネントチームでの協働の場合、そのコンポーネントができるまで自チームに待ちが発生する。その無駄を減らせる。

自己組織化、効率的にコストを改善できる

フィーチャーチームはプロジェクトマネージャまたはフィーチャーを市場または顧客の届けるためのマトリックスマネジメントを必要としない。
なぜなら、フィーチャーチームにすると、調整はささいなことになるかである。チームは顧客に届ける価値を自分達自身で調整し、彼らの仕事を仕上げる責任がある。
データはマネージャーの数と開発生産性に逆の相関があること、また、内部と外部の両方に焦点を当てたチームが成功する可能性が高いことをも示している。[AB07]
フィーチャーチームは出費を抑え、プロジェクトマネージャのようなオーバーヘッドを必要としない。

コードとデザインの品質がより良くなる

複数のフィーチャーチームで開発をすると、シェアすべきコンポーネントは、否が応でもクリーンなコードにせざるを得ないプレッシャーにさらされる。複数のフィーチャーチームで扱うのだから
コードフォーマットは標準化され、維持される。コンスタントにリファクタされ、たくさんのユニットテストで囲まれる。そうでなければ、仕事をすることが不可能になるからだ。
一方で、コンポーネントチームが長い間維持されると、彼らはそのコンポーネントに対する理解しか持たなくなり、似たようなスキルの人で固まり、よりコードをわかりやすくするという必要性に迫られない。

モチベーションをより維持できる

フィーチャーチームは、顧客と直接対話し、必要なものを作っているという実感を得られるとモチベーションが高まるという研究結果がでている[HO80, Hackman02]。
仕事満足度もあがる。これは、生産性と成功に重要なファクターとなる。

変更がより簡単になる

要求やデザイン、設計の変更により柔軟に対応できる。マルチコンポーネントチームとの相談や調整が不要になるし、コードがクリーンだから当然だ。

コンポーネントチームのデメリット

  • 順次開発サイクルとマインドセットを助長する
  • 同じコンポーネントを長期間開発し人々の学習を制限する
  • 最も価値のある仕事よりも、簡単にできる仕事をすることを助長してしまう
  • 人工的な仕事(仕事のための仕事)を助長してしまう
  • 手渡し作業の無駄と長い待ち時間による大きな遅延の原因となる
  • コードの重複を助長する
  • 増え続ける開発者を不必要に促進する(どんどん人を増やす原因となり、遅れが遅れを呼ぶ)
  • チーム間の計画と同期を複雑にする
  • ボトルネックを増加させる -あるコンポーネントチームが単一障害点となる-
  • より貧弱なコード・設計を育成することになる

よくある質問

例えば、デザイナーや要求仕様をまとめる人(Analyst)がフィーチャーチームでチームに加わっていたとして、その人の作業が終わるまでプログラマは作業ができないのではないか?

なぜプログラマはその人の作業が終わるまで待っているのですか?同じチームなのに。デザインが必要ならば、一緒にデザインをすればいい。要求分析が必要なら、一緒にやればいいのです。
忘れないでください。あなたたちはチームであり、共通の目的を持っている。そして短いイテレーションの中でその目的を達成し続ける必要があります。
プログラマがデザインの仕事を一緒にやることによって、より効率的な方法が見つかるかも知れません。逆のことも考えられます。
デザイナーやアナリストもプログラムを一緒に書きましょう。チームの一員なのです。これの繰り返しにより、メンバー全員のスキルが多能工になっていきます。よりよい世界が見れますよ。きっと。

営業やマーケティングもフィーチャーチームに加わるべきでしょうか?

原則はリーン思考になります。リーン思考を考えると、Time to Market。つまり、いかに迅速に市場や顧客にプロダクトを提供できるか、提供後に学び続けられるかが重要になります。
営業やマーケティングのメンバーがチームに加わることで、それが達成できますか?答えがYesなら、そうすべきですし、Noであれば、そうすべきではないでしょう。
必ず加わらなければならないということではありません。結局は、Time to Marketがより迅速になるかどうかだけです。フィーチャーチームになることが目的ではありません。
コンテキストに依存するので、一概にYesとは言い切れない場合もあるでしょう。

意欲に満ちていない人々を集めてフィーチャーチームはできますか?

アジャイルの12原則に少し違反しているようですね(笑
意欲は非常に重要です。ただ、フィーチャーチームはより顧客に近いところで仕事をすることになります。
人間は社会性を持つ動物ですので、他者の役に立ちたいと思う動機は、どのような人であり、多少はあるようなのです。
フィーチャーチームは、その動機を刺激することはできると思います。
でも、刺激をしたからといって、本当に人と接したくない方もいらっしゃるでしょう。
無理強いはよくないですので、それでも、もしモチベーションが全然上がらない方、それが2ヶ月以上続いたら、フィーチャーチームから『優しい言葉』をかけて去っていってもらうようにしましょう。

結論

どちらを選ぶべきか目指すべきかは、もう明らかですよね。
大切なのは、目指すべきということ。
いきなりフィーチャーチームは難しいですが、組織・チームの壁を超えてフィーチャーチームを目指すと、とてもいいことがある。徐々に攻めていきましょう。

参考文献

Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum (Agile Software Development Series)

Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum (Agile Software Development Series)

怒涛の2019年10月

2019/9/26に第三子(長女)が生まれて、そこから10/1に新しい職場がスタートし、色々忙しかった。
10/9,10,11でいきなりCSPO研修受けたりして、その週末は台風19号が関東を襲い、その次は大雨災害と、怒涛の10月が終わろうとしています。
幸いにも私の住んでいる昭島市周辺は、多摩川沿いのグランドが川で流され、ほぼ利用不可能になった以外は大きな被害は聞いておりません。


さて、最近はもっぱらスクラムやLeSSに関して、再度自分がたどった道をレビューし直すということをやっています。
なぜかというと、新しい職場でもこれまでの経験が結構活かせそうだし、この経験自体に価値がありそうだからです。
がっつりスクラムマスター、しかも複数チームをべったり見てたっていう人ってあんまりいないんですね。日本には。

一度読んだ本を再度読み直したり、自分が昔作ったプレゼン資料を作ったり、、
ちなみに以下のものだったりましますね。

2016年のXP祭り

XP祭り2016:メーカー企業がガチスクラムに挑戦した結果 (清水 弘毅さん)


JASPICの講演。2017年。 http://www.jaspic.org/event/2017/SPIJapan/session1B/1B1_ID004.pdf



Agile Japan 2019。 www.agilejapan.org

https://www.agilejapan.org/2019/session/east1-1_GXSM.pdf

ScrumMasterやって、最初の2年くらいは1チーム、次は4チーム、次はもっとたくさんチームがあって色々と良い経験をさせてもらったなぁという感じです。
LeSSのスクラムマスター経験のほうが長いという。。(笑

で、大規模スクラムを読み返しているのですけど、
LeSSのルールっていうのが付録にあるんですね。読んでみると、ほぼ忠実に従っていたことが判明しました。
もちろん、この本が翻訳される前からLeSSをやっていたので、結果的に従っていたんだなぁと。
実際LeSSは楽しかったし、改善点はありまくりなんだけど、それがまた良いっていうね。確信犯的に不完全なんですよね。

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法


その中でのスクラムマスターの役割っていうのが非常に・・・人間味あふれており、これがまた面白いんですよね。人間力だわな。ほとんど体当たりですよね。

最近はまた『個』のチカラをどう高めていくかを考えていて
ディベートや心理学、システム思考、引き続きCo-Active Coachingの学びを継続しています。
同時にLeSSとScrumもさらに深めていこうと思います。



楽しーなー!!


Pair Shares

Pair Shareとは?

Pair Sharesは、別名 Dyad Dialogue(対話) もしくは Neighbor Nudgeと呼ばれます。 このアクティビティは、一番速く、簡単で、且つ、心理学的に、学習者にワークショップに参加して頂くための最も安全な方法です。

Pair Sharesは学習者にとって以下のことを手助けしてくれます。

  • 簡単に、素早く、低いリスクで、情報を復習します。
  • 今聞いたことを思い出せます。
  • 知っていたこと、今知ったことを繋げることができます。
  • 安全な学習コミュニティを形成できます。
  • 学習への積極的な関与と対話によって、より心地よい空間が作れます。

Pair Sharesを行うことによって、以下のことが期待できます。

  • 隣の人と話ができます。少し動きが生まれます。
  • 他の人の話を聞きます。(”聞く”ことはとても大切なことです)
  • トピックのディスカッションに、関わらせることができます。
  • お互いより気楽になれます。緊張を解します。
  • ワークショップや研修に注意を向けることができます。

Pair Sharesのいろいろなやり方

  • 隣に座っている人と
  • 後ろにいる人と
  • まだ話をしたことがない人と
  • 今、学んだことに対して、簡単な質問を作って、それを隣の人に質問し、回答を聞く。
  • すでに知っていたことと今学んだことについて、質問しあう
  • 奇数と偶数に分かれてもらって、奇数の人は今学んだ最も重要なことを15秒で偶数の人に伝える。偶数の人は15秒で奇数の人に、使える情報を伝える。
  • 隣人と一緒に、学びを要約する
  • 隣人と一緒に、質問を作って、メモしておく。あとで復習する。

所感

ペアシェアいいと思います。場が暖まるし、人に伝えることによって学びが増幅されるし。色々考える必要あるし。 これは随所に使えそう。

The Ten-Minute Trainer (Pfeiffer Essential Resources for Training and HR Professionals (Paperback))

The Ten-Minute Trainer (Pfeiffer Essential Resources for Training and HR Professionals (Paperback))

Got a Minute? -1分あったら?-

Got a Minute? -1分あったら?-

The Ten-Minute Trainer (Pfeiffer Essential Resources for Training and HR Professionals (Paperback))

The Ten-Minute Trainer (Pfeiffer Essential Resources for Training and HR Professionals (Paperback))

60秒で学習の最大化を図る

60秒のアクティビティで、学習者に、「繰り返す」、「復習する」、そして「思い出す」ことの手助けをします。

ワークショップや研修でも、10から20分に1回は、1分間、学習者が自身を内省する時間を与えること。
これにより、学習者の記憶はより強固なものになり、ワークショップや研修の経験がより密度の濃いものになり、現場へ持ち帰れる一助になります。

なぜ60秒なのか

Even though you have a large amount of material to cover in a short amount of time, you'll find it easy to sprinkle one-minute activities throughout your training. A sixty-second activitiy is doable when a sixty-minute activiy is not.A sixty-second activitiy is short enough to provide a quick review of a segment of information. And includeing one-minute activities keeps your taringing participants attentive, interested, involved, and learning.

60秒には意味があります。
60秒は復習するには十分短い時間です。少し短すぎるかもしれません。
(制約の中で学習の最大化を図るということかな)

60秒であれば、ワークショップや研修の随所にこの内省の時間を散りばめることができます。
逆にこの時間が長過ぎると、学習者からワークショップや研修に対する興味や注意、そして集中力が削がれてしまいます。

60秒で何ができるのか

1回の60秒のアクティビティはそれほど多くないように見えるかもしれません。結局、60秒はすぐに過ぎ去ります。
しかし、10分から20分に1回、毎回異なる60秒のアクティビティを差し込むことによって、学習者は以下のことを得られます。

  • 聞いたことを繰り返します。これにより長期記憶を助けます。
  • さまざまなクリエイティブな手法で、資料を確認します。
  • 彼らが今学んだことについて、考えてもらいます。
  • 心の声に耳を傾けます。
  • 学んだ事柄の中で、アクティブな参加者になれます。
  • すでに知っていたことと、今学んだことをリンクさせます。
  • 短期記憶を増大させます。
  • いくつかのことを長期記憶へ移動する手助ができます。
  • 笑いあい、質問をしあい、間違いを認め合う、安全な学習コミュニティを形成します。
  • 学習を楽しくします。


などなど
60秒の間で、ペアを作って共有しあうのも、60秒の使いみちとしてはGOODです。


60秒の使い道

色々あるんです。connections, time spponges, pair sharesなどなど12種類も紹介されています。。。それぞれに対して10個くらいバリエーションもあります。
時間を見て紹介していきます。



所感

10分~20分に1回、内省の時間を1分つくるか、結構難しいファシリテートテクニックだと思う。
毎回同じ60秒だと飽きちゃうし。
例えば8時間のワークショップだと、24回も内省の時間が取れるということか。合計24分。多いのか少ないのか。これまでの経験から言うと多いと思うが、そのほうが受ける側からすると腹落ちしながらすすめるな。

そして、少しづつ、振り返りながらすすめるという方法が、非常にアジャイルな感じがする。

スクラムの記事まとめ

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)