fc2ブログ

makopi23のブログ

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

Regional Scrum Gathering Tokyo 2020 (Day3)

2020/1/8(水)~1/10(金) Regional Scrum Gathering Tokyo 2020に参加してきました。

公式サイト
https://2020.scrumgatheringtokyo.org/
https://confengine.com/regional-scrum-gathering-tokyo-2020/schedule/rich

Day3のブログになります。
Day1のブログはこちら
Day2のブログはこちら

Open Space Technology


参加者からテーマを募って、各テーマごとに参加者で議論するOSTです。


時間帯を3つに区切って、1つの時間帯に複数のオープンスペースでいろんなテーマの議論が行われました。

どうやってPBL決定するの?




上ロジと下ロジ


・POの上にいる上ロジがデカすぎ。上の意思決定がどこで決まっているかわからない。
・上へ報告する資料が面倒くさい
・POは、上ロジとのただの接点 → 本当のPOって誰?
・製造業だと、スコープ調整できない → 詰め込んでもやる
・POたたくさんのシステム単位にいてそれが癌では。
・本当のPOの顔が見えない。
・POはスクラム用語。製造業でもスクラムやりたがって、POと呼びたがる。
・バックログからガントチャートへ変換して報告する。ただし逆のフィードバックは受けない。ガントチャートからバックログは不可。
・先行開発は失敗が許されるが、量産では失敗が許されない。
・下ロジはスクラムがある程度いけそうだが、POの上にある上ロジをどうするか。
・POをやりたいと思ってる人をPOにして、情熱を持って上を突破する。上からPOを任命しないのが良いのでは。
・POの下に助さん角さんを置いた。持ち帰りが増えて行き詰ったので、POチームを作った。

NEXT→ACTION


https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/13336/nextaction

■アジャイルとの出会い
うまくいかない。変数が多すぎ。
うまくいかなくて、本よんだ

■自分をリビルド
「人生かけて俺らは何かひとつやり遂げる必要がある」 by 69 one ok rock

うまくいかなかったら
もういっかい作りなおしたらいい

人に関する問題が、上手くいかない原因だと思った
技術より、人に関して勉強しようと思った

読んだ本を自分のものにしようと思った
本を信じる
自分は容器です。好きなものを満たせる。いらないものを捨てる。
これをリビルド、と自分で呼んでいた

本を100冊くらい読んだ
これやったら、かなりやりやすくなった
迷ったら辛い方を選ぶ

■スクラムマスター
9か月くらい休んだ。リビルドした。
シリウスに入った

スクラムやろう、と上司がいってくれた
9か月リビルドして、いろいろ学習したので、スクラムマスターに立候補して
個人ごとにバーンダウンチャート作ったw
チームワークが一瞬で死んだ
バックログをExcelで管理して辛すぎ
スクラムマスターがタスクをアサイン
全部しくじった

クセがすごい 80%

歯ごたえエピソード
日本語と英語で怒鳴りあってるところをファシリテートと通訳
わりとみんな行くこと毎日かわる
朝5:30に起きて英語の勉強、通勤中はもちろん英語

オフィスに着いたら元気にあいさつ、とにかく明るくリード

自分が神になったつもりで、すべてを愛でつつめばなるんじゃないか
→ 結構効く

人生かけて俺らは何かひとるやり遂げる必要がある
これがあった

これだけやるとちょっとでは動じなくなる

■コミュニティ
がんばろう、だけで頑張り続けられるわけではない
スクラムマスターが開発チームとプロダクトオーナーと板挟みになる。
相談の場を会社で作るの、小さい会社では難しい。
勉強会に行ってみようかな

2009年12月 すくすくスクラムに参加してみた

自分のチームを「客観的にみられるようになった
他の人の話を聞いて、相対的に客観的に見れるようになった

利害関係が無いのに、共通の話題を相談できたり議論できる関係者は社外にしかない
安心して話せる。心の置き場のひとつ。
認定スクラムマスター(CSM)研修に参加したのもこの時期。

すくすくスクラム
スクラム道
Scrum Masters Night

会社の外に心を置いておける場所

2010年5月にヤフーにM&Aされた
買収されて半年で半分やめた
大企業に合わない人とかもいる。

辞めるのは簡単
残る方が難しい

迷ったら辛いほうを選ぶ
やめたら、シリウスでやってたうまくいってたDNAがなくなる
DNAを残したい

■2000人 VS ひとり
アジャイルやろう、自分ひとり
シリウスのアジャイルのDNAを残そう → 負けて当然
うまくいかなくて当然
やるんだったら自分の全人格をかえてやるしかない

「見たいと思う世界の変化にあなた自身がなりなさい」 by ガンジー

2000人に勝つにはどうすれば。
ウィルス気分で行こう
細胞に侵入していこう。癌細胞でもいいか。。。
結果がよければいい。

冷静になって考えた。
会社に土台がないので、目的を社内に置いたらモチベーションが持たない。
会社の制度とか、セキュリティとか、力関係とか、人間関係の基盤とか、わからないし、無い。
愛着もまだない。
どこに目的を置こうかな?
コミュニティのためにやろう。
事例をつくることによって、スクラムを始めるのが楽になるなら、コミュニティにとってもよい。
自分の努力が他の人の助けになるかも。

■標準化チーム
2010年10月にヤフーで仕事しはじめる
大きい会社なら標準化チームがあるだろうから、そこへいって、ぐつぐつに崩してやろうと思った。

乗るか反るか、ふたつにひとつ
決死の覚悟。アジャイルにやりにきました。WFやりません宣言。
ヤフーは、CTOがすでにアジャイルの手を打っていた。お墨付きがあった。

エンジンとハンドル
社内事情を知らないとやられる。
社内をよく知ってる人をハンドルとして、相談してやる。
自分がぐいぐい推進するエンジン役。エンジン役の漏れや調整をしてくれるハンドル役。
すごくよかった。ひとりじゃ絶対できなかった。

■最初の支援先
最初にやるのは、最初の実践をつくること。
3人のチーム。
不安の感情要素は俺がぜんぶうけるよ、と約束した。
不安を取り除く。

意外だった効果。
・しゃべらないと思ってた人がしゃべるようになった。
・信頼して任せるだけ。新卒デザイナーがすごいスキル。

このころ、初回のスクラムギャザリングが始動。

インセプションデッキとかリーンキャンバスとかなかった時代。
設立の企画を書いた。独自。

問題
スクラムの実践や知識の紹介の場が無い。
ブレイクしているとはいえない。

RSGTのスタッフはボランティア。
そのエネルギーを大切にしたい。

2011年のRSGTでヤフーの事例を出せた。
助けてもらう、というスタンスで、協力してもらえないか聞いた。
ルール大切だと思います、と断言して、(思ってないけど)、お願いしにいった。めっちゃ効いた。
積極的に、頼むわー、というとめっちゃ働いてくれる。

■支援先を増やす
勉強会を開催
・社内勉強会を定期的に開催
 チームを起動に乗せてあげる。
・アジャイルに興味をもってもらえる内容
・勉強会の最後に、もっとやりたいひとは個別にやりましょう。

やりたくなるようになってもらわないといけない。
説得するんじゃない。
そのために、個別営業をかけにいく。

個別営業する
問い合わせが来たら課題を聞きに行く。
期待なにしてるか共有
不安を聞く。理解する。不安を和らげる。
他に説明すべき人がいるか聞く。例えば、問い合わせ者の上司とか。これけっこう大事。根回し。所作。

逆に、上長からはじめる、という突っ走りは止めないといけない。
現場がようやわからん、となる。
チーム全員の合意をとるため、スクラムの説明をしにいく
みんなの不安を解消する
やな人?と聞くと誰も言わないので、言える環境を作る

■追い風爆速
2012年 ヤフー経営陣が交代
アジャイルを後押しする。
爆速化 → 危険な香りがするが、上手く乗る。結果がよければよし。

爆速化とは
PDCA
権限移譲 承認プロセスが8から2に。
縦割り組織から、合体したスモールユニットへ

チャンスが来たら全力に乗る。
やばいと思ったら速攻で降りる(笑

迷ったらワイルドな法を選べ
迷ったらツライほうを選ぶ

大きい会社はお墨付き大事。
時代が来た

■ネットワークを作る
チームとチームをつなぐ

ヒトデはクモよりなぜ強い
ネットワーク状の組織のほうが強い

普及チームのリソースは限られている
会社からコストとみられやすい、いつチームなくなるかわからない
でも、アジャイルの火をけすのは避けたい

勉強会などで自発的に広がっていくようにしたい。

エヴァンジェリスト認定制度
この人にきけばわかるよ、というのを見える化する活動
ゲリラ型ネットワークのノードを作る

副社長にノリで打診したらOKでた。
場が用意された

チャンスがきたら、準備ができてなくても、言え!
これすごい大切。

社外のコミュニティ作りと社内への還元
スクラム道やSCRUM MASTERS NIGHTの運営

普及の原則
・パートナー大事 ・・・ ひとりじゃ無理
・源流を狙う ・・・ 偉い人をさっさと捕まえる
・オープンマインド ・・・ ノーガイドで突き進んでください。ノーガード大事。構えている人には構えてしまう。
・話している相手の意見は必ず一理ある ・・・ 向こうから不安や疑問、そこには必ず一理ある、と思って理解しようとした。
・正しさよりわかりやすさ ・・・ 例え話するとか。
・お墨付き ・・・ Gとれるものなんでもとっとく
・頼り処になる ・・・ 全力でやるので頼ってね、と宣言
・お試し期間 ・・・ うまくいかなかったらやめる。いつそのチェックしますか、も話す。やめられる、という状態をつくってあげるの大事。

開発は不確実性がある。
不安になる。不安を解決するためにプロダクトマネジメントやる。
不安さえ和らげば、こっちに耳を傾けてくれるようになる。
自分の正しさにとらわれるのではなく相手の不安を取り除く。
だまされても、幸せならいいじゃんか。

世界をどう認知するかは、みんな違う。
脳が作り出す映像はみんな違う。

自分がやれることにプライド持ちたい
手段なんか選んでいられない

■新しいチャレンジ
いいチームになると、さよなら。特にアジャイルコーチは。

普及率の統計
普及を始めてから2年で統計とりはじめたら、21%こえてた。
キャズムは16%あたり。いきなり超えてた。
もう大丈夫だと思った。
キャズムを超えたら、普及をがんばらなくても勝手に伸びていく。

21%が50%くらいにいった。
70%くらいまで、一昨年できた。

2000 VS ひとり
ふりかえると、そうじゃなかった。
2000 WITH ふたり + コミュニティ
自分とパートナーと。対立じゃないので、WITH。コミュニティに支えられてた。

YOU ARE NOT ALONE

スクラムは、自分の仕事をよくしよう、もっとよく生きよう、と思う。
でも、来週出社するとすっと覚める。ちょっとだけ思い出してほしい
ここにいる人を思い出してほしい。
自分がちょと頑張って成果出して、他の人がすこしやりやすくなるかもしれない。
バタフライエフェクトとか。複雑系とか。
自分のちょっとした変化が、どこかで役に立つ。

WE ARE NOT ALONE.
仲間の輪を広げる。自分が外になにかやったぞ、じゃない。
オープン。

人生かけて俺らは何かひとつやり遂げる必要がある。

NEXT → ACTION
自分の活躍を期待している人が周りにいるかもしれない
自分がちょっと何かやることで誰かの役に立つになるかもしれない
そのために頑張る。
ときどき思い出すために、コミュニティに行ってください。

Regional Scrum Gathering Tokyo 2020 (Day2)

2020/1/8(水)~1/10(金) Regional Scrum Gathering Tokyo 2020に参加してきました。

公式サイト
https://2020.scrumgatheringtokyo.org/
https://confengine.com/regional-scrum-gathering-tokyo-2020/schedule/rich

Day2のブログになります。
Day1のブログはこちら。

Lost in Translation: The Manager’s Role in Agile


https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/13335/lost-in-translation-the-managers-role-in-agile

(スライドが公開されたらここに貼る)

Lost in Translation: The Manager’s Role in Agile
映画の名前
西洋のビジネスマンが混乱になる映画

アジャイルがわからない = LOST IN TRANSLATIONの状態

コミュニケーションをどう解決していくか
マネージャの役割とは?

自律的な自己組織化チームがいるのは幻想
理想郷
それっておかしくないですか

スクラムは階層を壊すもの
そこから新しいものを作り出すんだ

マネージャはどこにいる?役割は?
昔は、最優秀な人がマネージャだった

経営層からのサポートがないと45%が答えている
それは成功しません
マネージャなんて全員首にしてしまえ
アジャイルは人に価値をおく
マネージャも人ですよね
もっと共感できるアプローチしたい
マネージャを首にしないように

マネージャは「俺の役割って何なの?」と心理的な恐怖を覚えて考えることをやめる
これでは機能しない
なのでアジャイルの9割は失敗に終わる

自律的な組織は会社にとってどういう意味を持つのか
階層化がからネットワーク型の組織にするのは間違い
遠い未来の話としてはありえるが、アジャイル始める時は間違い
ここから取り組むと落とし穴になる
非常に特殊な状況をクリアした会社のみがたどり着けるだけ。

人が会社を導く、そういう組織にしましょう
ヒエラルキーをひっくりかえす

現場レベルの人ってリーダーシップを発揮する準備できてますか?
マネジメントは準備できていますか?権限をみんなで共有できますか?
この2つの準備、たぶんできてませんよね?

リーダーがアジャイルでどう成功していくか。アジャイルをどう成功させるか。

部分最適にすると、全体最適は下がる。
組織全体の下がる。これがリーン。

相互に関連するきちんとした責任を持ったチーム
完全独立でなく、相互に関係しあって、それが組織のために動く

いきなり自律でやれ、というのはよくない

チームの全員が自分の行動に責任を持つことで、はじめて、自己組織化のチームができる。
責任のある人から始めていきましょう。

ヒエラルキーは維持しましょう。捨てない。
そのほうが安心して仕事できる。

ティール企業
そういう会社でさえ、階層構造は維持している。
ヒエラルキー捨て去ることできるならやってもいいけど、してなくてもできる。

人を進化させて、初めて組織を変えることができる。

通常ビジネスは人の能力を多く無駄にしている。左
右は、人が進化していき、複雑さを曖昧さを受け入れられるようになる。
これがアジリティ、俊敏さを行うこと。
それには文化やマネジメントを変えていくことが重要。

とりこぼされる人があってはならない。

X理論は向上心が無い人。Y理論は向上心がある。
X理論からY理論を導くことがジャーニーの目的。
人を進化させることが目的。どうアプローチすればいいのか?

チームレベルから始めればいい?
下から始めれば組織が変わるのかというと、そんなことない。
マインドセットを変えた人が飛び飛びにいるよ、という状態にしかならない。
権限を持ってない人から始めると、組織に変更を加えるレベルにない

リーダーから始めていく。
リーダーが人間として成長してマインドセット変えられたら、組織を支援することができるようになれば、成功の可能性が上がる
リーダーシップから始めていくことが重要。
文化というのは局所的な階層
どの階層にも責任をもってる人がいる。その人から始めることが重要。

リーダーシップが、80%の「人が重要」だと回答者がいってる
新しいリーダーシップを求めている
従来型のリーダーシップのトレーニングでは不十分
成功するためには違ったアプローチが必要
21世紀のリーダーシップとは
2つ

マインドセットのトレーニングとコーチングが必要。
新しい在り方が新しい仕事をできるようにする
マインドセットを変えるということ

新しい視点が必要
それがなければどんな手法を用いてもうまくいかない

どんなマインドセットの変化が必要か?
アジャイルの定義は、アジャイルソフトウェア開発宣言
3つ重要のある


新しい良いやりかたを見つけだす学びの文化
学ぶ文化を醸成する
学ぶ予算と時間を与える

2.
変化へ対応する
不確実であることを受け入れる
不明瞭な中でリーダーシップをとる能力が必要

3.
プロセスやツールよりも個人との対話を

すべてアジャイルマニフェストの中に書かれている
もっともすぐれた新しいありかたを示している

アジャイルはプロセスよりも人である。
本質は人。
マインドセットをシフトする必要がある。
それがなければ成功は無い。

リーダーが成長して進化すればマグネットのようになる。
他の人も同じように振舞いだす。

マネージャ自身がY理論を体現していく必要がある。
自分を振り返って、自分中で変革を起こす
みんなはそれを真似をする
しなさい、というより、そのほうが効果ある
最も効果的なのは、自分が体現すること

権限をシェアしていく
リーダーが自ら、権限を周りに与えていく
権限をシェアする場合、みんなが進化するために行う
小出しで権限をシェアしていく

いっぺんに権限をシェアしてしまうと大変。
受け入れる側も、それは難しい。
すこしずつ小出しに実験しながら権限シェアを行っていく必要がある。
アジャイルな組織にするためにアジャイルを使う
反復的にインクリメンタルに、権限を共有する

最も成功に導く意思決定者は誰だろうか?

DESISION CARD
・自分が決定する
・アドバイスする
・後で教えてねカード
など5枚

大きな一歩を取ろうとすると上手くいかない
小さな一歩を積み重ねていく

これと近いのが、アドバイスプロセス
学習のカルチャーを実現するにはアドバイスが必要

アドバイスプロセス、を私の名前と一緒にググって

スクラムでマネージャが果たす役割とは
相互関連型のチームをどう実現していくか

人の成長にフォーカスして、チームをよりよくしていくために
コーチとしてSMの役割をとっていく。
チーフSM
会社にとって価値を与えられるならば、OK

意識改革を行ったうえではじめてできる
継続的に権限移譲
スタートは意識改革。それができてはじめて実現可能。

1人も落伍者を出さない
きちんとトレーニングを受けて、リスペクトを受けられるようにしないといけない

ビジネスアジリティを実現したい
ハイパフォーマンスを発揮する
それにはアジャイルやDevOpsが必要
その働き方は必要
実現するには、きちんと組織的な環境からサポートしないといけない
肥沃な土地に種をまかないといけない
アジャイルには肥沃な土壌が必要
健全なカルチャーが必要
なのでカルチャーが課題

まずは自分自身から、下位から始めよ。

ティール型の意識を持つ必要がある
自分をかえていく
リーダーの進化が大事

【完結編】総売り上げ:35,400円 ~ 受託エンジニアが自社サービスのPOをやって学んだこと


【完結編】総売り上げ:35,400円 _ 受託エンジニアが自社サービスのPOをやって学んだこと from Yukio Okajima

https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11784/35400-po-total-sales-35400-yen-what-the-contract-engineer-learned-from-the-experience-of-product-owner

思いつきでなく、現場でいけるという実感があった。お客さんのニーズとかもあった。

P.46 理想形
・ミトコンドリアの図。もともと別の生物だったのが、いつのまにか一緒になってる。

大企業の縦割り組織の中でProduct Discovery Teamを作ってサービスをリリース出来た話





https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/12093/product-discovery-team

リリースノートを開発に着手する前に書く
→ やてみると、いろいろ分かったのでオススメ

キャリアパス考察:開発者と動くQAテスターからチーム支援するスクラムマスターへ





https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/12616/qa

アジャイルな組織を創っていくには?地銀で取り組むアジャイルな組織創り





https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11844

ダメだったら止められるようにする
やらなきゃいけないという不安を取り除く
ふりかえる機会を用意する

問題が自分事になってからどうするか考える
将来必要になることは本気になってくれない
様々なワークは基本的に全員で実施
ことあるごとに、何のため?という質問を繰り返す

pbiを小さくしすぎた

楽しさの勘違い
真剣さ、規律の欠如
チームから緊張感が失われていた
ティーチングが必要なチームにコーチングしても効果ない

結果を出したい中堅と、新人の追加で、新人にプレッシャーかかる
プロダクト開発チームと教育チームに分ける。
教育チームは、基本的な教育が必要と判断された人が所属

10年たってやっとアジャイルがわかりかけてきた話





https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11791/10

基本はオフラインの会話なんだな、と強く気づいた

最高のScrumキメた後にスケールさせようとして混乱した話


最高のScrumキメた後にスケールさせようとして混乱した話 from Arata Fujimura

https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11822/scrum

開発前に決めて良かったことベスト3
1.明確なコンセプト
 ・エレベーターピッチ
2.3つのフェーズ
 ・ユーザーストーリーマッピングで3つのを区分け(背骨駆動開発)
  ①MVP ・・・ MVPで背骨を作り切り、以降は毎週肉付け
  ②MUST
  ③ADDITIONAL
 ・世に出せる状態を最初からずっと維持し続けた
3.デザイン先行FIX
 ・デザイン固めないで進める、はアンチパターン

まとめ
・組織目線でスケールを目指さない
 チーム目線で良いスモールチームを複数作るところから始める
・良いスモールチームは自律的に連携する

Regional Scrum Gathering Tokyo 2020 (Day1)

2020/1/8(水)~1/10(金) Regional Scrum Gathering Tokyo 2020に参加してきました。
20200110_010.jpg


公式サイト
https://2020.scrumgatheringtokyo.org/
https://confengine.com/regional-scrum-gathering-tokyo-2020/schedule/rich (タイムテーブル)

Togetter
https://togetter.com/li/1452991


アジャイル関連のお仕事やってるので、会社の経費で参加させていただけることに。
去年も参加したかったんですが、一瞬でチケット売り切れてしまったので・・・
今年は申し込み開始直後、すぐにサイトにアクセスして、なんとかチケット買えました。

以下、聴講メモ。

The Ten Bulls of the Scrum Patterns


https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/13334/the-ten-bulls-of-the-scrum-patterns



スクラムはガイドの中で見つけられるものではない
プロダクトバックログは要件のバックログではない。

十牛図 ・・・ 悟りにいたる10の段階を10枚の図と詩で表したもの

4.得牛(とくぎゅう) ・・・ 牛を捉まえたとしても、それを飼いならすのは難しく、時には姿をくらます
なぜ、がわからなければ、過去のやり方を踏襲してしまう。ウォーターフォールになってしまう。
→ なぜ、が重要である

デイリースクラム
デイリースクラムは型。毎日構築していくもの。1日1回集まってやる。
状況を毎日再評価する必要がある
スプリントゴールを達成するよう翌日の作業を再計画する。
報告や3つの質問に答える、ではない。
スクラムマスターはPMではない。
なぜ、がわかれば、アジャイルのコアである自己組織化し、次の24時間のために再計画することが大事
それを学んだ

スプリントレトロスペクティブ
Whyを使ってプロセスの変更を始める
ただスクラムガイドや本のとおりにやってるだけでは、同じもやもやが残っている
スクラムは1つではない
科学的な実験室のようなもので、失敗も許されている

失敗すべき
スプリントに持ち込むのはベロシティ。半分はベロシティに入り、半分は入らない
→ 50%失敗していなければおかしい
スクラムはしっかりコントロールされている中で失敗すること。

トヨタのカイゼン、失敗ないしに改善はありえない
みんなで反省する、集合的に反省する
失敗しなければカイゼンの動機がなくなる

継続的にプロダクトを変えていくことができる。
Windows Updateです。みなさん大好きですよね。
継続的な開発、これがアジャイルです。
アジャイルは解決策ではない。

多くの企業は目的が一貫していない。
アジャイルが問題。
トヨタのカイゼンから学ぶこと。
変化にオープンであること、それがアジャイル。

スクラムとは規律。
計画を策定し、変更を自分たちに許すこと。
計画はつきもの。変えると、お客さんいなくなる。

プロダクトバックログはデリバリの順番で並べる。優先順位ではない。
どういう順番でデリバリしていくか。
デリバリのありようを変える。
要件を変えるのではなく、ユーザーストーリーを変えるのではなく、インクリメントを変えていく。

6.騎牛帰家(きぎゅうきか) ・・・ 心の平安が得られれば、牛飼いと牛は一体となり、牛を御する必要もない

真実は常に変わっていく
スクラムは学ぶための仕組み
パターンはスクラムを学ぶための仕組み

スクラムで2つ構築する
・スクラムチーム
・正しいプロセス
 作れば正しいプロダクトが出来上がる トヨタ
 
マネージャを全員解雇しなさい
チームは自分自身で管理する
マネジメントは会社を管理する

止めることも大事。
止めたプロダクト、Googleだとこの5年で35くらいある。

上手くいっている日本の企業から学んだ。パターン。
アジャイルとは何かをすること。


スクラムは何かを構築していく
何かをする、ではなく、何かになる
一生懸命する、doする、はアジャイルではない

仏教は自然。自然をありのままに受け入れるのが無為
なにかを制御しようとするのではなく、調和するということ。

スクラムが作るのはプロダクトでない。プロセス。
プロダクトを作るためのプロセスをスクラムは構築する。組織を構築していく。

スクラムはメソッドではなくフレームワーク。
チームの本来の姿になる、ということ。
内省。自分の中を見つめなおしてください。

2つの集合体がある。
 1.どのように組織を構築していくのか
 2.バリューストリーム

56のパターン
バリューストリーム
学習のロードマップになる

自分の心に従ってください
パターンは手伝いをするだけ。サポートする。

パターンは相互に影響しあっている
Whyを知る必要がある。
自分のものにしていくことが必要
そこから、見つけていく必要がある
本に書いてあるから、ではない。
自分が信じているから、腹落ちているから、それが真実になる。

パターンは小さいもの
実験ができる。
うまくできなければ変えられる。
フィードバックを受け入れていく

アジャイルを使って、プロダクトだけでなくプロセスやチームを改善していく

無名の質
全体性、美しさ
アジャイルは常に変化していくということ。
場 ・・・ 集まると、その場から強力なエネルギーが生まれる
それが感じられなければ反省の余地がある
場が感じられないのか考えてみる必要がある
ワクワクして、情熱を感じる必要がある。

スクラムは組織を美しくしていくもの。
そうなっていなければ、改善が必要。
5つのS
日本の主婦からきている
家事 housekeeping
すべてのテストはパスしていますか?
日時のリズム、クリーンアップを習慣づけてください

Swarming
チームが全員、同じことに作業する

かんばん方式 
在庫があるのは恥ずべき事。かんばんがよいことであることを宣伝する人がいるが、そうじゃない。
この幻想をもとに作られた手法がたくさんある。
Swarmingはチームワーク

7.忘牛存人 ・・・ 家に戻ってくれば、牛を捉まえてきたことを忘れ、牛も忘れる

無為 何もしない
環境と調和する
自然についていく
毎日、変更に対応していくこと
それを無為と言う見方で行っていく
真の自分に戻っていく
個人を中心に据えないといけない。

スクラム=刺身


8.人牛倶忘 ・・・ 牛を捉まえようとした理由を忘れ、捉まえた牛を忘れ、捉まえたことも忘れる[1]。忘れるということもなくなる世界
無我。世界があるだけ。

9.返本還源 ・・・ 何もない清浄無垢の世界からは、ありのままの世界が目に入る
自然からリーダーシップを学ぶ
自然こそが我々をコントロールしている。
それと調和をすること。
お客さんをコントロールするのではない。
私とあなた、という概念はない。私たち。
自然から学ぶ。

10.入鄽垂手 ・・・ 悟りを開いたとしても、そこに止まっていては無益。再び世俗の世界に入り、人々に安らぎを与え、悟りへ導く必要がある

人を理解するには自分を理解しないといけない

アジャイルコーチ活用術





セッション内容:https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11780

アジャイルコーチは何をする人?
アジャイルコーチのゴールは、チームを自走できるようにすること。育てる。

ティーチングとコーチング
ティーチングが必要なことは多い。まずは教える必要があることが多い。
相手の状況に応じてやりかたを変える。

アジャイルコーチとスクラムマスターの違い
アジャイルコーチはスクラムマスターと違い、スクラムチームの責任を負うことはできない。

期待値を設定する
アジャイルコーチに何をどうやって依頼するか?
→ 期待値を設定する。これが今日の結論。期待値が無いまま外部の人を呼んでも意味が無い
大事なのは、優先順位付け。プロダクトバックログと同じ。同時に複数のことをやろうとしない。
コーチじゃなくて、技術のスペシャリスト呼んだほうがいいこともある。
期待値によって適切なソリューションを選択する

頻度や期間をどう設定するか
頻度や期間は期待値に密接に関係がある。
予算ありきにすると不十分な結果になる。予算がこれだけだから何回支援できるか、じゃない。

コーチングの期間が見短すぎると成果が出にくい。3か月は最低限必要。
タックマンモデルでも言ってるけど、3か月でも変わらないならコーチや現場に問題あり。

コーチが朝から晩まで週5日います、は役に立たない。ずっといる必要はない。
毎日いましょうか、とコーチに言われたら疑ってください。
感覚的には、週1~2。

よくある依頼のパターン
準備期間は手集めに支援。
3か月くらい経ったら週1くらい。
コーチはプロジェクトの初めから呼んでもらったほうが、途中で呼ぶより効果がある。
後から呼ばれても負け戦は変えられないことがある。

コーチに依頼すべきでないこと
スクラムチームがやるべき作業をコーチに依頼するのはダメ
今できないことをできるようにするのがコーチの目的。
アウトソースするのではない。
「達成」を依頼するのもダメ。コーチに権限と金を潤沢に渡さない限り、それは無理。

必然的にアジャイルコーチには継続的学習が必要
コーチは、みんながハマるところを事前に学習しておくことが非常に重要。
インプットがコーチングの質を上げる。
忙しすぎるコーチはまずい。
安い単価だと、稼働率を上げないといけない。
コーチの価格は、経験を含めての値付けになってる。
学習とかも価格に入っている。

アジャイルコーチとの相性
コーチも人間なので相性がある。
期待値を明らかにして、それにあったコーチを選ぶ。

よいアジャイルコーチを見つける方法
まずはコーチと会いましょう。

コーチの有効性の評価
定量的にコーチの効果を表すのは無理。
チームの状況がどう変わったかで見る。
定性的なものが軸になりやすい。

いつコーチの依頼を終了すべきか
自分達で走れるようになったらコーチから離れる。

みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか?





セッション内容:https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11778/outcome

OutcomeよりOutputのほうが評価しやすいので、重視しがち。
OutputできてないのにOutcomeを主張しても説得力がない。
PBIの価値を「ダイヤ」という単位で評価する。
https://guildworks.jp/works/item.html?id=53
ダイヤの運用で、詳細化する時はICEスコアのようなフレームワークを使う
ICEスコア = 影響力(Impact) × 信頼度(Conficence) × 容易性(Ease)
PBIの項目はインパクトトラッカーを参考にしている。

★スクラムガイドには以下に記述がある。
"プロダクトバックログには、詳細・並び順・見積り・価値の属性がある。"



見積りしないスクラム





セッション内容:https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/12120/noestimates-scrum

見積には隠れた5つのコストがある
・80/20の法則のコスト
・遅延コスト
・設計トレードオフ ・・・ 数値化によるコミット圧力
・見積作成時間 ・・・ 数値化による仕事量の最大化
・パーキンソンの法則のコスト ・・・ 数値化による正確であるという錯覚

→ ↑2つが優先順位付け(価値見積り)の問題で、下の3つが数値化することによる問題。

NoEstimate = 要求される機能を、サイズ/期間の数値に変換せず、意思決定に必要なコスト、情報、価値を取り出すこと

PBIやSBIの見積はしない。
・PBI(ユーザーストーリー)のサイズを1スプリント(1Week)以内にコントロールする。
・SBI(タスク)のサイズを1日以内にコントロールする。

スプリントの進捗はデイリースクラムでタスクの残数と残日数で確認する。

★このセッションにも、1つ前の中村さんのセッションにも、両者で「価値見積り」の話が出来てきた。
・中村さん: ダイヤ
・陶山さん: Cost of Delay (この機能のデリバリが遅れると、単位期間にどれだけ損失があるか?)



モブプログラミング x 行動分析学 x 教育


モブプログラミング x 行動分析学 x 教育 from Takuo Doi

セッション内容:https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11896/x-x-mob-programing-x-behavior-analysis-x-education

行動分析学
・行動を変える変数を実験によって探る方法論
・意志の弱さや能力のせいにしない

行動随伴性
・好子: その行動を強化する刺激
・嫌子: その行動を弱化する刺激

好子による介入の方が、嫌子による介入より良い

特殊部隊SETチームの日常 - 技術と実験を融合した実践アジャイル術 -





セッション内容:https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11774/set-

1.プロダクト開発チームと共に在る
・上手くいかない仮説: 施策が他人事になる
・検証のポイント: プロダクト開発チームと一緒に取り組む。プロダクト開発チームと一緒に苦しんで取り組む。

チームと3か月一緒に働き、一緒に取り組む。一緒に痛い目にあうことで本当に必要なものを発見・提供する。

2.Learning Session: チーム力の強化
新しい人をチームになじませて成果をだせるようにする
Onboarding ・・・ 組織の一員やサービスのユーザーとして新しく加入したメンバーに手ほどきを行い、慣れさせるプロセス

仮説: 業務時間内に勉強することこそ当たり前ではないのか
業務時間内にやる勉強会の手法 → Learning Lession
・仕事に必要な技能の習得
 ・チームの強化
 ・チームのプロセス改善

3.Design Sprint: 技術戦略の策定・実施
Design Sprintは、以下を一週間単位で実施する
 ・アイデア出し
 ・プロトタイピング
 ・ユーザー実験

効果あった。ダメなら即捨てられる。



テックリードは未来の話をしよう





セッション内容:https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11890/tech-lead-in-scrum

The Seven Levels of Authority
「The Seven Levels of Authority」のLevel1(指示する)からLevel7(任せる)に一気にいってしまって、上手くいかなかった。
1.指示する → 2.説得する → 3.相談する → 4.合意する → 5.助言する → 6.尋ねる → 7.任せる
Level1からLevel7までの間が大事

学び:チームの成長を支える
 1.変化に適応する
 2.献身を信頼する (コミットメントは献身のことであり、最終結果に対してではなく、行動や努力に対して適用される)
 3.心を否定しない (心を変えるのではなく、それを生み出す元となった部分を取り除く)

スクラムの価値基準にコミットメントが入っている

大切だなって思うこと
1.現在地を確認(現状を受け入れる) ・・・ 誰かのせいにしたくなったときは期待で動いている

2.目的地を確認(自分色のビジョン) ・・・ 強い信念を持って目指す場所を描こう

3.進む(選ばない選択) ・・・ 何かを選ぶときには何かを選ばないということも選んでいる

→ このループ = 失敗と学習



2日目へ(Comming Soon)

-->