Training for D-Day

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

スクラムと経済学・社会学・心理学

あるCSTの方と話をしていて、スクラムは組織論と心理学に基づくと言われました。 もっとスクラムマスター極めたいと思ったら組織論と心理学を学べと言われ、ちょっと調べていたのですが、そもそも組織論ってどのような学問なのか調べていたら、社会学と心理学だという。 組織行動のマネジメントに載ってた。

また違うCSTの方と話をしたら、おそらくJeffとKen(スクラム創始者)は、偶然スクラムのやり方を発見し後から理論を紐付けているのだろう、と。

でもそんな文献どこにもないから、自分で考えようと思った矢先、めっちゃいい本出た。

世界標準の経営理論

世界標準の経営理論

あやうく通信制の大学入り直すところだったよ。危ない危ない。

これで、スクラムと理論を結び付けられるかも。 スクラムすべて、つまりプロダクトオーナー、スクラムマスター、開発チームにも関連すると思ったら印をつけている。
ということで、概要レベルでの紐付けは以下。今後深堀りしていこう。2020年のテーマができた(笑 

f:id:kshimizu1226:20200121055506p:plain


○=直接的に関係がありそう
△=間接的に関係がありそう

こうみてみると、意外にも社会学の繋がりは弱い。LeSSで考えるとまた違うのかも。
リアルオプションは不確実性という文脈で、どちらかというとアジャイルに馴染む。

SCP理論

SCP理論をベースにした戦略フレームワーク

リソース・ベースト・ビュー(RBV)

SCP対RBV、および競争の型

情報の経済学(information economic)

情報の経済学(エージェンシー理論)(agency theory)

取引費用理論(TCE)

ゲーム理論(Game theory)

リアル・オプション理論

カーネギー学派の企業行動理論(BTF)

知の探索・知の深化の理論(exploration and exploitation)

組織の記憶の理論(SMM&TMS)

組織の知識創造理論(SECIモデル)

認知心理学ベースの進化理論(evolutionary theory)

ダイナミック・ケイパビリティ理論(dynamic capabilities)

リーダーシップの理論(leadership theories)

モチベーションの理論(motivation theories)

認知バイアスの理論(cognitive bias)

意思決定の理論(decision making)

感情の理論(emotion theories)

センスメイキング理論(sensemaking)

エンベデッドネス理論(embeddedness)

『弱いつながりの強さ』理論(weak ties)

ストラクチャル・ホール理論(structural holes)

ソーシャル・キャピタル理論(social capital)

社会学ベースの制度理論(institutional theory)

資源依存理論(resource dependence theory)

組織エコロジー理論(organizational ecology)

エコロジーベースの進化理論(evolutionary theory)

レッドクイーン理論(red queen theory)

2019年振り返り

2019年もお疲れさまでした。2019年の印象に残った本をご紹介します。だいたい2019年は、漫画を除くと100冊くらい読みました。進撃の巨人はクライマックス、ワンピースもあと数年で終わりそうですね。


「影響言語」で人を動かす

「影響言語」で人を動かす

Coachとしての資質の一つに必要かも知れない、Profiling。この本では、LABプロファイリングとして人を14種類の特性に分けて、どのように分類していくかが語られている。

組織行動学が学問的にどのように派生されてきたかも記載されている良書。心理学や組織論を体系的に学びたい方にはおすすめ。

すぐれた意思決定―判断と選択の心理学 (中公文庫)

すぐれた意思決定―判断と選択の心理学 (中公文庫)

意思決定の方法が様々記載されている。

ファシリテーション・グラフィックの元祖らしい。ミーティングのススメ方や結束力の高め方などが記載されていて、何回も読み返したくなる。

Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing (English Edition)

Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing (English Edition)

  • 作者:Gojko Adzic
  • 出版社/メーカー: Neuri Limited
  • 発売日: 2009/01/05
  • メディア: Kindle
ビジネス部門と開発部門のコキュニケーションのギャップを無くしたい、そのために・・・という本。 ATDDやBDD、Specification by Exampleの先にある本。Kindleだとすごい安いので、電子版がおすすめ。

一兆ドルコーチ内に参照されていた本。まぁ、そうなんですよ。本音で語ることの重要性。めっちゃ重要。でもできないのよ。日本人。

一兆ドルコーチ。最高。

偉大な組織の最小抵抗経路 リーダーのための組織デザイン法則

偉大な組織の最小抵抗経路 リーダーのための組織デザイン法則

個人的には何も学ぶことがなかった本。1回読んでお蔵入り。学習する組織のピーター・センゲの友達が書いてるって書いてあったから読んでみたけど、微妙。

大規模スクラム(LeSS)の誕生前2008年ごろ同じ著者、グレイグとBassに書かれた良書。でもScaling Leanのほうが響いたな。 Avoid ... Try... で記載されているのは、あくまでガイドだからかな。

新インナーゲーム (インナーシリーズ)

新インナーゲーム (インナーシリーズ)

個々人に対してどうやったら良いコーチングができるのかな、というところで読み進めた。良書。 なんというか、例えば、テニスプレーヤーをコーチするときに、『ボールをよく見ろ』ではだめで。 『ボールがネットを超すときに、ボールの縫い目はどの方向を向いていたか?』という問いが、本当の集中力を必要とさせる問いであると。 確かに。
それをビジネスの現場ではどうするのか、考えをくれた一冊。

グループ・コーチング入門 (日経文庫)

グループ・コーチング入門 (日経文庫)

グループコーチングという単語では、ではおそらくこの一冊しか日本で出てないのではないか。集団に対するコーチングのハウツーが記載されている。 システムコーチング(ORSC/CRR) とも違う流派ではなる。ここからインナーゲームにたどり着いた。

新版だったのだが、魅力が薄れた。初版のほうが好き。

システム・シンキング入門 (日経文庫)

システム・シンキング入門 (日経文庫)

システム思考の練習問題がたくさん載っている良書。ループ図の前提として、時間軸を考慮したグラフを考えろ、とか、ループ図のパターンを理解するにはこの本が一番良い。

DevOps関連の本ではこの一冊が一番良いのでは。定量的にどんな指標がいいのか指南されている。

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)

半端ねぇ。シャロンさんすげぇ。

これまでの設計論とかコーディングとかをまとめたような感じでそんな新しい発見はなかった。。。まとめとしては良いかな。逆にこれまで設計やプログラミングであまり本を読んでこなかった人は最初に読むとまとまってていいのかも。

生々しくて大好き。古くからの現場ってこうゆう感じだよね。

基本は、権限を委譲するって話。

DVD付き カラダをリセット+体幹力UPのコアトレーニング

DVD付き カラダをリセット+体幹力UPのコアトレーニング

  • 作者:木場 克己
  • 出版社/メーカー: 成美堂出版
  • 発売日: 2012/05/18
  • メディア: 単行本(ソフトカバー)
半年間ぐらい週末はこれをやっているけど結構いい。とくにエキスパート体幹は結構利く。

ものすごい良かったけど、体系だってない。からまとめ書こうかと思ったけど、まとめられず。

その国に住む人は、XXX(例えば、主体性とか、危険回避性とか)の傾向が強いとか弱いとかそうゆうのが研究されていたみたい。まぁ、なんとなくわかる部分もあるけど、 一概にそのくくりに当てはめちゃうのは危険だとは思う。参考にはなる。

完全教祖マニュアル (ちくま新書)

完全教祖マニュアル (ちくま新書)

達人のサイエンス―真の自己成長のために

達人のサイエンス―真の自己成長のために

奇跡の経営 一週間毎日が週末発想のススメ

奇跡の経営 一週間毎日が週末発想のススメ

モダンサッカーの教科書 イタリア新世代コーチが教える未来のサッカー

モダンサッカーの教科書 イタリア新世代コーチが教える未来のサッカー

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

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

  • 作者:
  • 出版社/メーカー: 丸善出版
  • 発売日: 2019/01/30
  • メディア: 単行本(ソフトカバー)
LeSSを実践するなら読んでおかないといけないけど、実践しながら読むとまた色々と噛み締められる。バイブルですね。でも 個人的には、↓のほうがおすすめ。

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)

  • 作者:Craig Larman,Bas Vodde
  • 出版社/メーカー: Addison-Wesley Professional
  • 発売日: 2008/12/08
  • メディア: ペーパーバック
Be Agileって言葉が出てきた最初の本なのかな?とにかくAgile謳ってるなら必読。後のLeSSに繋がる。
Be agile rather than do agile.

アジャイルコーチのコーチパフォーマンス計測

単純なメモです。
Coaching Agile Teamのp281よりGoogle翻訳で抜粋しただけ。

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))

  • 作者:Lyssa Adkins
  • 出版社/メーカー: Addison-Wesley Professional
  • 発売日: 2010/05/18
  • メディア: ペーパーバック

以下の考え方から離れます 以下の考え方に向かいます
チームを駆動すると、結果を取得します 他人の作品を演出 チームは自然に、誰もが「ドライブ」できる環境。それらを考えることなく、素晴らしい結果を提供する環境を作り出すことを暗黙的にリードします
予測可能性を達成するために、チームの仕事を制御します 彼らは選択して、彼らが約束した結果を得るために、彼らが責任を持って仕事を成し遂げるためにチームを解放します
会社のルールに従います 都度、彼らが価値の提供を制限する会社のルールに出会ったら、それを変えていくことに挑戦します。
すぐに管理に問題をエスカレート 完全に関わる人たちの中に問題を通じて働くことは、それらを解決し、上に移動します
実績のある安全で有利なオプション チームのために安全性を作成すると、実験失敗し、学ぶために
計画によると製品を提供 その変化に応じた製品をお届けするためにチームを有効にし、ビジネス価値をまかせ、ますます正確な計画が唯一のメトリックその事項も配信
定番の戦略と手順に従って 創造性とでもおなじみの領土に改めてそれぞれの状況を確認し、ゲームを変える結果のためのチャンスを高めるために、チームの能力を育成
本を読んでアジャイルを実装します 「本を読んで」行くとき知ることが最善であると不完全な環境では、少なくともいくつかの改善を得るためにアジャイルの最も強力な表現を犠牲にするとき

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

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

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

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

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

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

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