FC2ブログ

makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

「エンジニアのためのコーチング体験型勉強会Vol.1」に参加しました

2019/7/25(木) 「エンジニアのためのコーチング体験型勉強会Vol.1」に参加してきました。

connpass
https://coaching.connpass.com/event/138647/

6/11に「エンジニアのためのコーチング入門」というイベントがあって、そんときブログ書きました↓ 
今回はそれを踏まえ、体験型イベントという位置づけなのでした。
以下、自分復習用のメモ。 




1on1もトレーニングが必要

チェックイン
  • 自己紹介
  • 今どんな気持ちですか?
  • いま、どんな状態ですか?

グランドルール
コーチングは自転車の乗り始めと同じ
慣れると普通にできるようになる
最初は上手くできない
安心して転べる場が必要

ワークセッションの説明
1on1に動きをもたらす
「動き」ってなんだっけ?
 状態・情勢・内容などが変わること
 相手の内容が変化する

問いで動きをもたらす
・ティーチングの真逆
・相手の内側から変化を起こす
 より深い洞察、気づき、学びを得る
・良い問いは持続性がある

ワークで鍛えるポイント
  • 資質: 好奇心
  • スキル: 拡大質問と認知

ワークの流れ
コーチ、クライアント、オブザーバーの3人1組
  • 6分:コーチングセッション
  • 1分:コーチから一言
  • 2分:オブザーバからフィードバック
  • 2分:クライアントからフィードバック
役割を交代する
オブザーバはその場の雰囲気を感じる

セッションの流れ
1.コーチは好奇心をもって拡大質問をする
 ・クライアントは質問されると自分に潜っていく
 ・コーチは探求している様子を傾聴する

2.クライアントは拡大質問に答える
 ・コーチは拡大質問の答えを傾聴する

3.コーチはクライアントを認知する

(拡大質問と認知はスキルです)

好奇心と拡大質問
・相手が持っているすべてのリソースに好奇心をよせる
・はい、いいえで答えられない、開かれた質問をする
・相手が持っている、秘めているものを知る質問をする
 ~さんがいま、本当に望んでいるものは、何ですか
・勇気をもって、無邪気に質問する 


認知
・相手の鏡になる
  ・言われて初めて気づくもの
  ・コーチは思ったことを返すだけでも気づきになることがある

・相手の本来ある姿、特性やありかたを伝える
  ~さんは粘り強いですよね
  ~さんはリスクを取る勇気をもってるんですね

・コーチが感じた/知った相手の深いところを伝える

当てにいかなくていい。これがコツ。

承認と認知
・承認には価値判断がある
  正当であると認める

・認知には価値判断がない
  認めるのみ
  (~という考えを持っているんですね)
  これがけっこう大事

フィードバック
・グランドルールを思い出す
 実験の場、守秘義務、あってる人はいない
・より良くなることを伝える

人はもともと創造力と才知に溢れ、欠けるところのない存在である
NCRW、って覚えてる

デモコーチング(3分)
以下、コーチとクライアント(参加者1名:ジャンボさん)のやりとりのメモ。

コーチ:
 どんなこと聞いてもいいですか?
 それとも、何かテーマあったほうがいいですか?
 では、ジャンボさんにとって仕事ってなんですか?

クライアントが回答:
 XXX

コーチ:
 ちょっと嬉しそうですね
 へー
 なるほど
 仕事は人生にかかせないものなんですね?
 では、人生とは何ですか?

クライアントが回答:
 YYYY

コーチ:
 嬉しそうな顔されますね?
 へー
 流れていくものですか?
 仕事が無いときはぼーっと空とか見てるんですね?
 それも楽しそうにしゃべりますね
 仕事で大事にしていることはありますか?

クライアントが回答:
 ZZZZ

コーチ:
 リスペクトするのとリスペクトしないのとどんな違いがありますか?

クライアントが回答:
 AAAA


ポイント
相手の言ってることよりも、相手の表情とかを傾聴する
そうすると、相手の新しいところに気づく

クライアント役の感想:
自分がしゃべってるときに笑ってる、とか言われたことないので新しい気づきがあった。

拡大質問ってけっこう勇気がいる
人生って何ですか?仕事って何ですか?とか

オブザーバーチェックシート
・好奇心
・拡大質問
・認知
・良かった点
・より良くなるとしたら、どんなことがあげられるか


ワークを実際にやってみて、チームから頂いたフィードバック
実際にワークショップを3人1組でやってみて、コーチ役の時にお2人からいただいたコメント↓

1.オブザーバー役の方から頂いたフィードバック
良い点:
  • 入り口は事実の説明が話やすいのかな
  • 具体例の話をだしていた
  • 事実をだしていた
  • 雰囲気づくりできた

悪い点:
  • 考えると話のバランスがイマイチ
  • 話させるシーンが多かった
  • 考えさせる質問の割合をふやしたほうがいい
  • 仮説をコーチ役の私自身がだしてしまっていた
  • もっとクライアントに考えてもらったほうがいい


2.クライアント役の方から頂いたフィードバック
良い点:
  • やりやすさはあった
  • 仮説を立てられて述べていた

悪い点:
  • 課題設定をしすぎ
  • 状況説明がたくさん必要な質問をしてしまった


ワークの振り返り

  • どんな気づきがあったか?
  • 明日から使えそうなものは何か?
  • どんなことが1on1に動きをもたらすでしょうか?

参加者からのコメント:
  • 認知で、他のコーチがやっていると、すごくいい表情になってた
  • 認知もっとやっていこう
  • 身振り手振り、言われて気づいた。 → ミラーリングと言って、これも認知の一種
  • 3人でやるのがよかった。客観的に見てくれる第三者がよかった。
  • クライアントとコーチって、やってるといっぱいいっぱいなので、第三者のオブザーバーが助かる。

チェックアウト
いま、どんな気持ちですか?
いま、どんな状態ですか?



感想


実際にコーチングを体験する場ってのは貴重ですね。
なんとなく知識はあっても、実際にやってみると、自分のコーチング力のマズさに気づく・・・
しかも、3人でやる、ってのが面白い。二人のやりとりをじっくり観察するオブザーバー役があるのデカい。

またこーゆうイベントがあれば、ぜひ参加したいと思うのでした。

「Agile Japan 2019」に参加しました

2019/7/18(木) 「Agile Japan 2019」に参加してきました。

公式サイト
https://www.agilejapan.org/index.html


会社でアジャイルなお仕事をやってるので、会社の経費で参加です。
以下、復習用の個人メモ。

[基調講演] マネージャー不在の洞窟型組織


セッション紹介: https://www.agilejapan.org/session.html#e-03
スライド: https://www.agilejapan.org/2019/session/keynote-03_GROOVE.pdf



【第1部】LOVOT概要および発表後の反響について


起業から発売あで、4年間売り上げゼロで、事業費100億。
LOVOTは360度の顔認識。
家に来ると地図を作る。
すべての声がオリジナルで、喉がある
服を着ないと動かない。着ている服を認識する。
赤ちゃんの見守りをする。
外出中の家の状況を送信する。動ける。

【第2部】LOVOT開発に、アジャイルが必須な理由


ピラミッド型はマネージャが必要。
GROOVEはフラット組織にしている。

LOVOT 開発は先が見通せないため、思考と学習を重視した。
初期が一番知識が無い。
見通せない領域はアジャイルが大事。
今は複雑で見通せない範囲が多い。
アジャイルでやるならフラットが相性がいい。

LOVOT開発は、生命の進化プロセスを4年の開発期間で再現
・早く試して、いかに早く学ぶか
・スコープがどんどん変わる
そのなかでどうやって組織を運営していくかの最適解がスクラム

①早く試して早く学ぶ
SpaceXの動画は、失敗をすることを誇っている。なぜなら、失敗させたほうが学びが大きいから。
ロケット打ち上げはNASAからSpaceXに移ってきた。
 ・NASAは税金を使うので失敗できない。それでどんどんコストが上がった
 ・SpaceXは失敗しても税金を使ってないので、失敗を許容しやすい

でも、「早く試して早く学ぶ」というのは、実際は大変。なぜなら、不安になるから。

アジャイルは【コロンブスの新大陸の発見」と同じだと思った。
コロンブスが戦ったのは、船員の不安。
なんとか船員を束ねながら新大陸を発見した。
不安のマネジメントが出来たのがコロンブスの勝因。

①早く試して、早く学ぶ → 不安との戦い → 見える化して不安解消
見せる化をして不安を解消するのが大事。
見通しの悪いところで遭難しない能力がアジャイル。
ぎりぎりを責めることが大事。
一歩間違えると失敗する。
ギリギリを攻めるにはどうすればいいのか。
それは、片足が落ちても踏みとどまれるかどうか。
失敗を盛大にするとリカバリにすごい時間がかかる。
アジャイルどころではなくなる。
どれだけ片足が落ちた時点で気づけるかが大事。
片足を落とし慣れるのがスクラム。
何かが起きたらすぐ方針転換する。

②スコープがよく変わる 〜オペレーションの完成度をあげる組織の弱み〜
スコープが変わると何がツライかというと、ピラミッド型は部門ごとに領域が分かれること。
仕様変更が少ない場合はこれが一番効率良い。

でも、領域を分けると、領域間の隙間ができる。
忙しくなると領域が狭くなってきて、領域間に隙間ができる。
3-6か月かかって隙間がでてきて、埋めるのにまた同じくらいかかる。
最後に帳尻合わせでガタガタなものになる。
スコープが変わることを前提として作らざるを得なかったので、フラット型の組織を採用した。
フラッと型組織だと、隙間があると気づく。
各自の不安で領域間の空白地帯があぶり出される。
経営者には不透明感が出るかもしれないけど、それでも他社は追随出来なくなるので納得する。

組織のタイプ 〜「自律性」と、「船頭の数」によって、性質とパフォーマンスが変わる〜
フラット組織を導入して失敗するのは、仲良し組織で船頭が多数の場合。
船頭が多くなりすぎるのは取るべき選択肢ではない。
完全フラットだと、10人いると10の意見が出る。
船頭多くして船山に上る。
自律性はあるけど、物事が纏まらない。
派閥のないピラミッド組織ピラミッドは上手くいく。

スクラム・ホラクラシー型フラット組織
スクラムは横連携のコストが安い。
スコープ変化のコストが安い。
でも各自が説明責任を持たないといけない。
なぜなら横連携でコミュニケーションできないとメリットが活かされないから。
イノベーションにおいて大切な能力は、“Learning agility” (学びの素早さ)

職場の活気① 〜スクラム&フラット型組織の組み合わせは、活気がある〜
ピラミッド型組織は2:6:2の法則になる。
フラット型組織にすると下位の2割がほどんどいなくなる。
中間6割と上位2割の区別がなくなっていく。
それに対し、ピラミッド型組織の下位2割は生産性がマイナスで、それらが中間層の6割を食ってしまう。
するとピラミッド型の青の面積が減る。
フラット型組織は、青の総面積は大きい。

職場の活気② 〜「飽きる」をポジティブの捉える〜
イノベーションにおいて大切な能力 = “Learning agility”
学びが素早い=飽きっぽい
数年で飽きてもおかしくない。
飽きた人を縛り付けるとLearning agilityが下がるので輝きが失われる。
最大の敵は「飽き」

職場の活気② 〜「飽きる」をポジティブの捉える〜
7割は死亡保険の加入率は、アメリカは2割だけど日本は7割。
日本人は不安を減らす努力を怠らない。
でもリスクを取らないのでLearning agilityが上がらない。
積極的に「飽きる」ことを認め、覚悟を決めると、生産性はあげられる
飽きたら早めに手を挙げてもらう。
挑戦はLearning agilityの向上にもなる。

スクラムのメリット まとめ
船頭を一人に保ちながらチームの自律性を維持することが可能。
「服従の心理」という本がおすすめ。

服従の心理 (河出文庫)
スタンレー ミルグラム
河出書房新社
売り上げランキング: 37,694


フラット型でスクラム運営すると職場に活気が出る。
 ・スクラムできない、というヒエラルキーと戦うくらいならフラット組織にしてしまう

アジャイルコーチ、スクラムマスター、研修等にしっかりコストをかける
 ・研修にコストをかけて、ようやく動き始める。

実運用は、午後のセッションにて説明
Bazaar(バザール)をやってる。
フィーチャーチームへの移行には適切な時期がある。
なので、コンポーネントチームから始めている。

【残り時間】QA


Q.
会社だと人事評価とかある。どうされてるか?

A.
フィードバックと評価は分離しようとしている
フィードバックは振り返りをやっている。
年に1回、360度フィードバックをやっている。

スプリントごとのふりかえりは業務ふりかえりをやってる。
その人の成長以外に、自己認識と他己認識の乖離をどう理解するのかの課題がある。
自分はコミュニケーションできてると思ってるのに、他の人からは「できてない」と思われていることがある。
360度フィードバックは、最低7人からやっている。
自分と他者の乖離を見る。
トラブルとなるのは自己認識と他己認識が乖離している部分。

評価は、今はやっていない。
評価は一度やってしまうと、情報硬直性があるので難しい。
自分が手をあげて他の人が承認するプロセスを考えている。
チームで、どうやって給料を決めるかを考えてもらおうと思っている。



Q.
自律型組織に合わない人は、出ていってもらうことあるか?

A.
あまりない。
フィットする人ばかりではないが、合わないと自分から移っていく。
入社して1~2か月は、多くの人が戸惑う。
1~2か月経って、自分が合うか合わないかがわかる。
合わなければ離れていく。
でも離職率2~3%くらい。




Q.
出資者に対するリリースバーンダウンチャートの説明とか、スプリントレビューとか、どうやって出資者に説明しているか?

A.
出資者はフラット型組織とスクラムに慣れていない
フラット型組織で失敗するベンチャーが多すぎるのは、拡大する時に課題がでて、ヒエラルキーに転換することが多いから。
なので出資者にはウォーターフォール的に説明している。
POの責務として、ROIを最適化するというのがある。ROIのIは、イノベータからのIN。
外向きにはウォーターフォール、内向きにはアジャイルで。

日本のイノベーションを加速するScrum


セッション: https://www.agilejapan.org/session.html#l-03
How Scrum boosts your innovation in Japan from Kenji Hiranabe


ランチセッションです。無料配布のサンドイッチおいしかった。
戦闘機「グリペン」の開発で使ってるスクラムのプロセスは、Scrum@Scaleですね。
今年のデブサミで原田さんのScrum@Scaleのセッション聞いて、ブログ書いてます。




展示会場では、いろんなブースが出てました。こちらは「旅するAgile本箱」。
アジャイル関連の書籍がたくさんあって、何冊か手に取って目を通させていただきました。
20190718_01.jpg


なぜ始まらない?アジャイル開発 アジャイルコーチと考える組織改革


セッション: https://www.agilejapan.org/session.html#e-05
スライド: https://www.agilejapan.org/2019/session/west1-2_freee.pdf



3セッション分の時間枠だったので、前半の2セッション分の時間枠のみ参加しました。
前半は、実際にコーチから支援を受けたチームの体験談が複数あったあと、質疑応答になりました。
以下、メモ。
---

コーチの見つけ方
 上司が知ってる方を連れてきて、やっとむさんがやってきた

コーチ呼んでよかったこと
 第三者視点でアドバイスくれる。社内事情に左右されない。
 コーチ来る前は、やってて自信が持てないのがツライ

アジャイルコーチを呼んで型を知り、型を守る。
まずは徹底する。
目的からずれ始めたらアジャイルコーチが指摘してくれた。
第三者的な視点で意見をくれるのがよい。

アジャイルの要素の概念が説明できるようになった。
ワークショップで考える会を開いてもらって、それで身についた。
コーチが不要になるようにコーチが動いてくれた。
圧倒的にホワイトボードや付箋を使うようになった。

コーチの見つけ方
コミュニティとか、知り合いからの紹介だった。

スクラムでずっといくわけじゃないので、そのあたりに中立な人が希望だった。
自分がいなくてもよいようにする、と表明してくれた。

コーチ呼ぶのに困ったところ
モノづくりしないのでどれだけコストかけていいか
 コーチングやティーチングできる人は単価が高い
 でも、コーチがSMやPOを育ててくれるのなら安いのでは。
 

まとめ
スクラムをはじめるのなら徹底する
徹底しないと良し悪しが分からない。
体験する場や考える場を設けてくれるの大事。

質疑応答(ディスカッション)


最初に、周りの人とこのセッションで質問したいことについて話し合う時間がとられました。
私のグループでは以下のような意見ができました。

・コーチが目指していること
・コーチがいなくなってもいいとは
・仮説検証のやりかた
・コーチとして入るときに、絶対外してはいけないこと

そのあと、各グループで出た質問内容をもとに、質疑応答ベースでセッションが進みました。
聴衆から出た質問はいかのようなものがありました。

・コーチ入る前に、どう始めたか?
・コーチのお値段
・やりはじめて最初もやもやしたのがどのタイミングで晴れてきたか
・freeで半年でよく半年で慣れたな
・1つのチームを社内に広げるときに何やれば広がるか
・コーチ導入する際にユーザ企業様と文化の相違あるときに衝突とかどうすりあわせるか
・コーチが週2日に入る時は、週のどんな日か。スクラムイベントがある日か?
・メンバーがコーチやスクラムに好意的じゃないときにどう進めていくか
・守破離の守で立ちいかなくて解散してしまった場合、どうやってマインドセットを育てていくのか
・コーチって、SMにやりかたを教えて、SMからチームに教えるのか
・アジャイルを上の縦に広げていくには?




Q.
コーチのお値段は?

A.
アトラクタさん25万円/日

今日のコーチのみなさんのお値段は↓
・15万円/日
・13万円/日
・15万円/日

まずは試してみませんか、で、最初だけ13万とか少し安くする。
コーチが合うかどうか大事なので、最初は安く設定とかして、長期的にいけそうなら価格を設定する。




Q.
コーチがくる日は?

A.
最初は週2で、今は週1
スクラムイベントがよく理解できていないときは、スクラムイベントを1日に全部入れるのはキツイので、それで2日にした
2日きてもらったほうがワークショップとかしてもらえるし。
意味が大丈夫とかなってきたら週1に

始める時はがっつり1か月フルでコーチに来てもらった。
スクラムの役割とかセレモニーとか、教えてもらう。
1週間、缶詰めになって議論する。POも入ってもらう。
だんだん歩けるようになってから、コーチに少しづつ離れてもらう。




Q.
コーチはどう入りたいか?

A.
月1はやめたほうがいい。
週1か2で、変化を見る。考える時間を作る。
チームにじっくり考えてもらう必要があるときは週3

スクラムイベントは出たいので、週1~2は必須。
スプリント0のときは週3か週4で入った。

最初は週3~4で半日を4回とか、間をあけないように。
コーチが抜けていくときは、イベントだけ参加とか。
そこでチームができるようになってきたら、開発中にチームがどうコミュニケーションしてるか、とかを見る。
それで、テスト書いてないね、ということが分かると、「一緒にテスト書こうか」と言う。
コーチが得意としていることは、スキルによる。
イベントある日に行くこともあれば、わざとイベントの日を外していくこともある。

スクラムイベントデーは、アジャイルコーチを確保できないことある。
他のプロジェクトにコーチを先通りされてしまう。
コーチの都合で丸1日フルで行けない日がでることがあるが、半日だけでも、行けない日よりはマシ。
午前は現場A、午後は現場Bとか。

コーチの掛け持ちは2~3件かな。

正しいものを正しくつくる ープロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について


セッション: https://www.agilejapan.org/session.html#p-01
分からないものを分かるようにする from toshihiro ichitani


「正しいものを正しく作る」というタイトルだと、「正しいとはなんや?」となるので・・・
今日のテーマは「分からないものを分かるようにする」

文脈
・新規事業やサービスづくり
・はじめてアジャイルに取り組む

どちらも、どうなるかわからない、というのが共通
分からない状況でも進めていかなければいけない
どうやればいいか?

不確実性の高い状況にどう立ち向かうか?
→ 基本戦略:わからないものをわかるようにする

「不確実」な中に、「確実」をつくる
わかるところを作る

わからないものをわからないまま進める
→わかったことが役立つかは運任せ

わからないことが後でわかってきても後の祭り
ビジネスは、間に合わないとダメ

わかるようにするための活動とは
検証活動を重ねて空白地帯(分からないこと)を知識で埋めていく

わからないものをわかるようにする戦略
1.わからないから選択肢を広く持つ
決めうちして間違えると時間的損失が大きい
時間あたりで得られる学びが少ない

2.最も「わかる」のは想像ではなく現実に直面したとき
→いかに現実に近い状況をコスパよくつくるか
コスパがよくないと繰り返しできない

3.分かる、に使う距離(時間、予算)を段階的に
活かす次が無いと意味がない
次を活かす設計=段階化

現実歪曲曲線
縦軸がリアリティ
横軸がリソース
傾きは一定でない

ランディングページは早いけど、リアリティない
デザイン入りプロトタイプは、飛躍的にリアリティが上がる 
フロントエンドのみ実装プロトタイプは、より表側の動きできて体験が味わえる。でもリソースはあがる
インターネットで公開できるMVPが最後にあり、リアリティとリソースは高い

横軸: 最初の学びを得られるまでの時間差
縦軸: 得られる学びの量との差

最初は左下だけでもかなりわかる。早く。それで学びを得られる
お金をかけてリアリティかけるよりいいんじゃないかな

MVPの力学
リソースももったいないけど、時間がもっともったいない
なのでリソースを減らしてリアリティを上げたい
できるだけ左上を目指す。 ①→②

ノンコーディングプロトタイプイングツールとかも使える。
競合他社のありものの製品を使うなら、安く済む
それでわかったフィードバックから仮説を立てて検証していくとか。そういう作戦もある
リソースは利用料を払うだけでいきなり検証できるものを使えばよい。

大企業の戦略
予算を投下して、たくさんの選択肢を試す
→ 段階的にダメな案を省いていく
→ 残った選択肢でプロトタイプを作っていく

現実で多いのは・・・
・決め打ち
・想像だけで決め打ち
・想像だけで決め打ちでいきなり超リアリティのあるものを作ってしまう
 → 学びはあるが、かける予算と時間と、期待があってない
 → 頓挫
・大企業的戦略もだいたい取られない

決め打ちは間違っている、とわかってるけど、なぜ起きる?

環境最適化問題
俯瞰的視点に立てば誤りに気づくことでも、詳細に寄りすぎると誤りに気が付かない

そこで、「自分たちを立ち止まらせる問い」を
ほんとにこれでいいんか?
正しいものを正しく作れているか

自分たちの思考と行動に別の方向性を与える
気づけないことを気づけるようにするにはどうすればいいか?

人は制約を置かれたたとき、その制約の下で最適な解を見つけようとする
例えば、「重要なものを選べ」だと、全部重要ということで全部選ばれてしまう
「TOP3を選べ」とすると、並べて比較して決めるようになる

自分が気づけないところに行くには、
自分たちの意識にとらわれない問いで思考や行動に向き直る

不確実な高い状況ほど、わかっていることに答えてばかりいても発見が足りない
→ 回答不可能な問いをあえて置く
そのやりかたの1つが仮説検証型アジャイル開発

本当にできるの?
→ 経産省のシン・ミラサポプロジェクト
アジャイル開発だけで何をつくるべきかが見えるわけではない

・価値探索
・インセプションデッキ
・仮説キャンバス
・ユーザーインタビュー

やると見えてくる問題がある

LeSSでつなぐビジネスとIT


セッション: https://www.agilejapan.org/session.html#e-12


現在の組織の問題点1: 官僚型のマネジメント
・標準化で誰でもできる、わかりやすい
・ビジネスとITが分離され、開発現場が顧客視点を失う
・顧客に素早く価値を届けることよりも、組織内部の稼働に注目する

現在の組織の問題点2: サイロ化した組織
・機能別の部門
・部門の責務に閉じた目標

従来型の組織はチームになっていない
役割間で異なる目標、作業分担、やり方が共有されていない

組織をチームにしよう
・同じ目標を持つ
・フォローしあう関係
・やりかたを共有している

LeSSのコンセプト
組織をシンプルにし、アジャイルになるためにはどうすればいいか?

スクラムを大規模にするために、著者二人が実験をたくさんやってて、それが本になってる

大規模スクラムはスクラムである

スクラムの導入が爆発的に増えている理由
スクラムの成功は抽象的な原理原則と、具体的な手法の絶妙なバランスにある

LESSはスクラムと同様にバランスをとっている
抽象的な原理原則と具体的なプラクティス

LESS
フレームワークをルールで定義している。ルールは少ない。4-5枚くらい。
それだけだと動くの難しい。そのためにガイドが周りを覆っている
そのまわりに実験がある。みなさん実験してみましょう
フレームワークが薄くて、シンプルに初めて、実験してくださいね

原理・原則
LESSのコア
リーン思考とか顧客中心とか
少なくすることでもっと多く
フレームワークが軽い

フレームワーク
2つある
・LESS フレームワーク: 2~8チーム
・LESS HUGE フレームワーク: 9チーム以上


1人のPO、1つのプロダクトバックログ、1つのプロダクト
各チームは独自のプロダクトバックログを持っていない
完成の定義も1つ
すべてのチームが共通のスプリント
複数のチームが1つのスプリントで動いている

ラーマンの組織行動の原則
4つある
3の「カスタマイズ」と、4の「文化は構造に従う」について

クロールでしか泳いだことの内集落の話
1つの泳ぎ方しか知らない集落があった
クロールという名前も知らない

遠くの集落は違う泳ぎしている
平泳ぎというらしい
自分のはクロールと言うらしい
やってみようぜ

クロールしかしたことがない人が平泳ぎをすると
これまでより体力消耗するし、ぜんぜん進まない

これまでのやりかたを踏襲して、名前だけ変えて余計に重たくしているとか、あるある。

クロールをやったことない人が、やったことない平泳ぎを取り入れてもうまくいかない
ちゃんと学んでいかないといけない
自分たちが1点しか知らなくて、もう1個を知らないのに、その間の真ん中なんて取れるんですか?
カスタマイズする前に、振り切ってそれをやってみるのが大事。

文化は構造に従う
組織が変わらない限り、考え方は変わらない

顧客価値による組織化
・実際のチームを基本単位としてブロックを組んで組織をつくる
・自己管理、クロスファンクショナル、同一ロケーション、長期間存続
・チームの大半はフィーチャーチーム

フィーチャーチームとは
・エンドツーエンドで顧客中心のフィーチャーを実現する、安定した長期間存続するチーム
 (フィーチャーチームの対称的な概念が、コンポーネントチーム)
・クロスファンクショナル
・クロスコンポーネント ・・・ すべてのコンポーネントはすべてのチームが面倒をみる
・すべてのスプリントで完成したフィーチャーを提供

フィーチャーチームの利点
・明確なフィーチャーの所有権
・遅延を引き起こす依存関係がない
・顧客の言葉で話す開発組織

LeSSでのマネジメント
・ 「Hackmanの権限マトリックス」は、縦軸が「権限」で、横軸が「チームの名称」
・2番目が「自己管理チーム」
 アジャイルの文脈で求められているのは、最低限、自己管理チームであること
 
組織の強さを作る存在としてのマネージャ
2つの現場がある。
 1.価値を消費する現場・・・ユーザ側
 2.価値を創造する現場・・・チーム

「チーム」を組織図の一番上に置いて、マネージャは一番下にいる
・マネージャは、多くの権限をチームに移譲する
・マネージャは、チームとスクラムマスターが取り組んでいる障害排除と改善を手助けする

現地現物
1.問題解決力の向上 ・・・ マネージャの重要な役割は、問題解決の方法を教えること
2.より良い組織の意思決定 ・・・ マネージャはチームの仕事の状況を真に把握し、経営判断についてのフィードバックを得る

原著者からのメッセージ
階層型組織とマネジメント構造を同一を捉えている人が多いが、そうじゃない
階層型組織でも指示型のマネジメントスタイルでなければ自己管理チームを作ることは可能

大規模アジャイル方法論「SAFe」の実践 ~ペイメントサービスにおける組織デジタル化~


セッション: https://www.agilejapan.org/session.html#g-04
スライド: https://www.agilejapan.org/2019/session/east2-4_NTTdata.pdf



NTTデータのアジャイル
アジャイルプロフェッショナルセンタ
「Altemista」というブランドをやってる
方法論がProjectNow!
様々なメソドロジーを内包している

SAFe
・3つのレイヤ
  1.システム開発
  2.ビジネス
  3.組織運営
・2017年頃からSAFeがデファクト

SAFeをどう始めればいいか
公式手順はImplementation Roadmapが提示されている
ガイドラインで汎用的
具体的にはイメージしにくい

NTTデータの事例: 国内最大のキャッシュレス決済総合プラットフォーム CAFIS
129名のSAFe体制で対応中
Large Solutionを意識したチーム構成

導入の課題
SAFeを開始するまでの導入部分の話をする。

SAFeの立ち上げ方
立ち上げプロセスが従来のウォーターフォールと全然違う
SAFeの前半プロセスは新しいので先入観なく取り組める
後半プロセスは従来プロセスを踏襲してやってしまいやすい
つまづかないように、後半プロセスを意識的に変えた。場所とか人とか組織とかシステムとか。

SAFeの5つのコンピテンシー:成功のための行動特性
SAFeの5つのコンピテンシーに4つ(場所、人、システム、組織)をマッピングした

1.場所
課題
・人が集まらない (高スキル技術者ほど市場価値が高いので)
・レイアウトの問題で会話が少ない
・大規模なので狭い、
・利便性とのトレードオフのセキュリティ

→ ラボを立ち上げて対応

場所の対策1: ラボ
人が集まる場所を目指す
 1.働きやすい
 2.ワクワクする職場

アクセスのよい都心
デザイン性の高いオフィスで、新しいものに取り組んでる感
多様なデバイス

場所の対策2: 対話重視のオフィス設計
・フリーアドレス ・・・ 同じチームとしか話さない、ようにしない
・どこでも会議可 ・・・ ホワイトボードをいっぱい設置して、移動式
・音楽が流れる ・・・ コミュニケーションしやすいように スピーカー置いたり

場所の対策3: 開放感のある十分なスペース
関係者全員が一堂に会せる
4フロアを確保

場所の対策4: 自由度を上げてもセキュリティは確保
社内LANと分離した独立NW環境
端末構成管理システムを用意
内部統制監視システムを導入し、コミュニケーションツールやファイル操作を監査

2.人(チーム)
人(チーム)の対応が一番の成功理由だった。
Scrumの定着率が低いのは、育成期間を確保し、アジャイルコーチ、チームのスクラップ&ビルドで対応
人財評価

人の対策1:育成期間の確保
3~4スプリントはベロシティが上がらない
チーム立ち上げる際に、「見定め期間」を設ける

人の対策2:アジャイルコーチ
「見定め期間」にアジャイルコーチをつける
アジャイルコーチを入れるのが成功要因として大きかった
改善サイクルが不調の時とか、メンバ入れ替えがあったタイミングでもアジャイルコーチをつける

10チームのScrumチームを並行で立ち上げた
チームの立ち上げ期間をずらして、一人のアジャイルコーチが複数チームを見れるようにした

人の対策3: スクラップ&ビルド
見定め期間をすぎぎてもうまくいかないチームがある。
→ 性格的な適正とか、一度出来上がった人間関係とかが原因
→ チームの解散、メンバ再配置も必要だと考えた。心を鬼に。

10チームが軌道に乗るまで、シビアに評価した
それがそのあとステップアップできた成功要因となった。

人の対策4:人財評価
人財評価は対応中。
スキルセットと育成プランを継続して作っていくのを取り組んでる

3.システム
アプリとインフラの維持コストが高いのが課題
→ オープンAPI化とかマイクロサービス化とかクラウドとか、対策をとった新環境を用意した

システムの対策1:オープンAPI化
これまでは新しいチャネル追加なるとIFを追加してたので工数が大きかった
新環境はオープンAPIに統合

対策2:マイクロサービス化
これまではサイロ化してて、他IFとの重複があった
新環境でマイクロサービス化して保守性とアジリティ向上を実現

対策3:パブリッククラウド活用
用途に合ったパブリッククラウドを用意

4.組織
課題は2点
 ・各レイヤーの情報の見える化
 ・WF準拠の社内ルール、意思決定が遅い

対策
 ・DevOpsの活用
 ・社内ルールを改定、新ビジネスマネジメントプロセス

組織の対策1: DevOpsの活用
進捗管理はJira
情報共有はconflueence
コミュニケーションはMattermost
ビジネス、組織運営との関連付けは付箋アナログ

組織対策2: 特区化
プロジェクトでなくプロダクトライフサイクルで管理

ここまでで下地作りできた
→ 2019年7月からSAFe本格始動

まとめ
100名超規模の大規模アジャイルをSAFeでやってる
SAFeの立ち上げには従来のやりかたを意識的に変える必要がある
人が一番大事。人の集め方、意識の変え方、働き方、チームビルディング、すべて人間中心

質疑応答
Q1.
SAFeをやるのに3アジャイルコーチに入ってもらったとあったが、コーチに何をやってもらったか?

A1.
スクラムマスター自身どうふるまえばいいのか定着してない。
スクラムマスターのそばで、イベントに観察者のように張り付いて見てもらい、改善の指示をする
最初の1スプリントはべったり入ってもらう
2~3スプリントは最初の計画会議か最後のレトロスペクティブだけ参加するようにする
---

Q2.
スクラムチームの見定め期間後の、「ダメだね」となる判断基準はあるか?

A2.
明文化したものはない
プロダクトオーナー的なトップの人が判断する形をとってる
アウトプットとかチームの雰囲気とかを勘案して全体最適化をしている
---

Q3.
大規模アジャイルの方法論はいくつかあるが、なぜSAFeを選んだか

A3.
LeSSとかScrum@Scaleとかでも大規模なものは作れる
でも、縦に組織として伸ばしてくのはSAFeしかなかった
組織を変えたいというのを目指していくのでSAFeを採用した


Fun! Done! Learn! 〜 チームの楽しさと学びを成果に結びつく新しい振り返りを体験しましょう!


セッション: https://www.agilejapan.org/session.html#e-14
スライド: https://docs.google.com/presentation/d/1PzKrGMIahCkeAqddv8g14oxQEzpI5HPd5zrTv0DLspw/edit#slide=id.p
20190718_07.jpg
(クリックするとスライドに飛びます)

1.説明
Fun! Done! Learn!がどうやって生まれたか?
沖縄のイベントで。
スクラムやりたくないチームにどうアジャイルコーチが関わるか?
どんな工夫すればチーム自らチームの状態を知って行動がおこせるのか?

成果重視でかんばってるけどこのままもつのか
うちのチームは成長してるのか
もっとたのしくやりたい

チームが自己診断できたらおもしろいかもね
→ fun/done/learnを生み出した

とにかく楽しい絵をかいてやってた
funの要素がないとやってられない

2.やる
10人~15人でチームを作って、今日のアジャイルジャパンに参加して思ったことに対してやってみる。

実際にやってみた。
20190718_02.jpg
20190718_03.jpg

やってみた感想:
スプリントレトロスペクティブはいつもKPTを使ってるけど、マンネリ化したら、Fun! Done! Learn!を一度試してみるのもありかもしれない。
KPTだと↓の要素が確かにあるなぁ、と思いました。
 ・課題の改善という意識がすりこまれているのか、”よくなかったこと”にフォーカスして話しがちな傾向があるのは確かに。
 ・振り返りをする時間をしても「できなかったこと」にばかり目が向いてネガティブな印象になりがち


ネットワーキング 併設:平鍋師匠のアジャイルあるある相談会


セッション: https://www.agilejapan.org/session.html#nw-1

参加者のみなさんと軽食をまじえての歓談タイムです。
軽食も十分な量があって、翌日は人間ドックなのに食べ過ぎてしまった・・・
20190718_04.jpg
20190718_05.jpg
20190718_06.jpg

感想


上質なセッションがとても多くて有意義でした。
こーゆうオープンな場で生の現場の事例などを知れるのは大変ありがたい。
自分の現場にも試せそうなヒントや気づきがありました。
有料だけど、また会社のお金で来年も参加したいと思うのでした。

-->