会社のお金で、技術カンファレンスや研修に参加するもやもや。みんなどうしてるの?

最近、もやもやが多く書きました。
会社や個人や立場(役職)によって意見が違うと思うのですが、
ひとりで考えても答えがでないため、
コメントもらえると嬉しいです。
みなさん、どうしているのですか?


私が、所属していた、所属している、これから所属する組織をディスる意図はありません。
たんに、不安でもやもやという話です。
もやもやがおさまりません。だからこそ吐き出します。

追記:
いろんなひとがコメントをくれました。ありがとうございます!
ブコメへのリンクを載せておきます。
b.hatena.ne.jp

前提

私は、会社の費用でカンファレンスや研修に参加したことがほとんどありません。
(昔いた会社で過去一度だけある。当時は行きたかったわけでなく、えらい人に「xxさんに行ってもらうことなったから」と言われた経緯)
「認定スクラムマスター研修(CSM)」も自費で受けました。
ふりかえると2019年は、カンファレンスや研修に20~30万円くらい自費で参加しています。平日は有給休暇を使います。
ちゃんと計算はしてないので、金額はだいたいですが、我ながら頭おかしい。

2019年時点の私の年収は標準より低いくらいだと思います。ぎりぎりの生活です。
単に経済感覚ぶっ壊れているだけで、お財布事情に余裕はありません。お金はたまりません。むしろ減った。


「業務扱いで、会社の費用負担で参加してますー」ってひとうらやましい。覚悟がすごい。
私は、お金持ちではないので、自費負担ゼロで行けるなら行きたいよ!

(ひとつ感じたのは、私の中では趣味のひとつに近くなりつつある。
「旅行するのに自分でお金払う」感覚はあるのかもしれない)

自由でありたい。気負いたくない。ただ楽しみたい。

・無料カンファレンス
・有料カンファレンス
・海外カンファレンス
・研修・セミナー
・スポンサー
・登壇
など、費用感や日程でも違いそう

もやもやと不安

いくつかの会社を見てきましたが
「お金で出すよ!研修行ってきなよ!」と会社は言ってくれますよね。
でも、それには「責任」が伴うのでは?と不安でいっぱい。
そんなもやもやありませんか?私は「不安でしょうがないっ!」
プライベートで自費参加であれば、そんなことはありません。


寝坊して、遅刻できないんでしょ?
途中で帰れないんでしょ?
ちょっと休憩して、休もう寝ようってできないんでしょ?
写真とメモたくさんいるんでしょ?
もらったノベルティやグッズは会社のものなんでしょ?
ホントはだめなのに録音しろ・録画しろって言われるんでしょ?
牛尾さんがいってたみたいに、なんか超詳細なレポートかいて、興味がない人たちの前で発表するんでしょ?
(個人的には、昔いた会社で、家帰ったあとに睡眠時間を削って一週間くらい資料作った経験ある)
会社ブログに参加報告書かないといけないんでしょ?

行った後、独りで仕事にいかさないといけないんでしょ?
(チームで行って、そのあとみんなで、やってみよー!となる世界は素敵だと思うの)


会社からは費用負担に見合った成果や成長をしたかを評価とか査定とかされちゃうんでしょ?
申請書類とかレポートとか頑張って書かないといけないんでしょ?
できなければ、降格や減給やそれを理由に評価下がる(上がらない)んでしょ?
最悪「金返せ」になるんでしょ?
気軽に会社辞められなくなるんでしょ?


いい感じの写真を1~2枚くらい貼り付けて(写真取る派ではないので悩む)
感想を3行くらい書いて
よかった講演の資料のリンク1つ貼っておけば良くて、
あとは(半分くらいは)資料公開されるから、あとはそれ見ればわかるでしょ
くらいならできそう。
(プライベートの時間を使うか、仕事の時間を使うかの違いはありそう)


カンファレンスや研修に行った内容を共有するのが嫌なのではないんです。
ただ、たくさんの時間をかけるのはつらいし、忙しい時や疲れている時に「やらない」選択肢を持ちたい。気楽にやりたい。

興味ある人に、こういう話聞いて最高だったよ!◯◯っていうの聞いたから、ためしに一緒にやってみようよ!
楽しいから、今度一緒にいこうよー!

みたいなのは、普通にしたいし、仕事とかじゃないと思うの
でも、ノってくれる人、ほとんどいない説

下記は牛尾さんの引用

海外イベントに行った時の報告の違い
   一つの例を具体的に考えてみます。インターナショナルチームで、以前高額のDevOps Enterprise 2015というイベントに参加した時のことです。インターナショナルチームでも当然レポートとかはあるのですが、一般的に大変シンプルです。E-Mailで、Wordでいうと1-2ページ程度、大まかにポイントがまとまり、写真で雰囲気がわかればオッケー的な感じです。ですので、これを作るのはそんなに時間がかかりません。2-3時間ぐらいでしょうか?


 一方日本側として、海外のイベントに参加した時の報告は、プレゼンを作って、そのプレゼンをみんなで見れるように報告会があり、それが録画されます。これはとてもいいことなのですが、報告する人からすると、最低1日はがっつり準備が必要になってくるでしょう。見るほうも1日のイベントになります。


ちなみに、私が初めてインターナショナルチーム向けにレポートを書いたときに、がっつりとした日本式のものを書いて提出した事がありました。それは没になりました。というのも、彼らによると「読むのに時間がかかるからシンプルなのを」とのことでした。

simplearchitect.hatenablog.com

こういうイメージしかない(偏見)。

他の方の意見

もやもやしていたら、他の方から意見を教えてもらったり、勝手に見たりする機会を得ました。
※センシティブな内容だと感じるため、できるだけわざと改変してぼかして書きます。フィクションもあります。
※だめだったら教えて下さい。消します。

  • いろいろ面倒だから、50万くらい自費で払って、海外カンファレンス行ってる。
  • 仕事に活かすこと、と言われる
  • 部署や上司で違う。上司がカンファレンスや勉強会に行く人がいれば二つ返事。そうでなければ、断固拒否の場合も。
  • 会社がカンファレンス参加に費用負担するという、当たり前になりつつある世界を作りたい
  • 気にしすぎ。簡単なレポートだすか、フィードバック会を軽くやればいい
  • 会社から信頼されているかどうか
  • 海外カンファレンスに参加する費用捻出のために、家賃安い(3万円くらい)のところに住んでいる
  • 会社の予算取り
  • 研修やカンファレンスで成長効果がなかったら?
    • 数十万で効果がないことがわかるなら、安い
  • コミュニティが支援して費用を負担する。コミュニティでの活動を広げてほしいから。
  • 会社から、名刺交換してきてねと言われる
  • 参加したいことを普段から強いモチベーションで表明しておくとお金出してくれたり。参加後の報告会(数分)はあり。
  • 厳格な手続きは無くて、良い意味で緩い印象。結果として仕事で返したいと自然に思える。
  • 国内は費用もそんなにかからないから、うるさく言わない。海外は参加レポートを書いてもらう。(合同でも可)
  • 海外に行くことで、最新の情報がわかり、知り合いが増え、空気感もわかり、しかもモチベーションが上がるのなら、数十万の投資は安い。
  • 参加レポートの形式は自由。基本的に資料はアップロードされるため、資料に書いてない質問の内容、会場の反応、所感を書いてもらう。それを全エンジニアが集まるMTGで発表してもらう。分量は大体10分ぐらいで読める量。そういう場合もあるし、社内ドキュメント共有ツールに投稿するのがほとんど。
  • ある程度業務に関連「しそう」であれば「これ行きますー」でほぼオッケー。後はチーム内で調整してねぐらい。
  • 明らかにスキルとカンファレンスのレベルがあっていないと「まだ早いよー」となるらしいが、聞いたことはない。
  • どこにお金を使うかは難しいが、組織にとって良いことには躊躇せず使っていきたい
  • レポートは書いても書かなくても良い。実務で活きればそれで良い。
  • 海外のカンファレンスは対象外だが、国内ならどうぞどうぞ。会社の社内だけだと、気付きや観点に限界が出てくるため、出来る限り外の世界をたくさん見せてあげたい
  • そもそも福利厚生のうち

山本五十六さんの「やってみせ 言って聞かせて させてみせ ほめてやらねば 人は動かじ」には続きがあった件

メモ:続きがあったの知らなかった。
@nrslib さんに教えて頂きました!

やってみせ
言って聞かせて
させてみせ
ほめてやらねば
人は動かじ


話し合い
耳を傾け
承認し
任せてやらねば
人は育たず


やっている
姿を感謝で見守って
信頼せねば
人は実らず


山本五十六

2019年のふりかえり『まだ何も成してない』

本記事は「ふりかえり Advent Calendar 2019」8日目の記事です。
adventar.org

前日:小田中育生さん
note.com
翌日:scrummasudarさん
scrummasudar.hatenablog.com


この二人に挟まれるとは!光栄です。

私の個人的な2019年のふりかえりです。
内容は、ただの個人的な記録となります。
日記のようなものですので、暇な方で興味ある方だけ読んでいただければ、と。
自分のためだけに、ノリと勢いで書きました。
(最後のほうネタ記事化してしまった)

当初の予定では、各種カンファレンスの学び直しをしたかったのですが、
書き始めたら違うこと書いていたため、
タイムボックスに入らないため、PIVOTしました。
(そもそも1ヶ月以上の前のことなんてまともに覚えてないよ!)

記事のリリース後に、変更するかもしれません。変更しないかもしれません。

2019年

【1月】

Regional Scrum Gathering® Tokyo 2019

  • Moubious Loop
  • No Estimate
  • 3日目は業務調整つかず、泣く泣く不参加

【2月】

Scrum Fest Osaka 2020

  • 基調講演ではない。基調"公演" 。つまり、LIVE!!
  • 勇気と元気!
  • アンパンマン

【3月】

Management 3.0ワークショップ

  • Management 3.0 との出会い
  • 特にこの3つが好き
    • 「システムをマネジメントする」人のための環境(システム)をマネジメント
    • 「Management 2.0」組織変革の課題はおそらくここにある
    • 権限委譲とエンパワーメント」これだけはやっちゃだめだけど、あとは自由にやっていいよ!

Management 3.0は、ムービングモチベーターズやデリゲーションポーカーのような手軽なプラクティスを紹介されがちな印象です。
私は、それを憂いています。
何故なら、Management 3.0は、たぶん、そこじゃなくて、考え方やマインドセットが至高なんだと思ってます。

【4月】

DevOps Days Tokyo 2019

  • ジーン・キムさんにサインもらい損ねる
  • Beyond Legacy Code . XPが大事
  • 2日間ともKeynoteのみ参加。午後はお仕事😖

【5月】

😄

【6月】

  • 自己肯定感本との出会い。「うわっ…私の自己肯定感、低すぎ…?」
  • 自己肯定感と詐欺師症候群について、もやもやしているので整理したい

booth.pm

DevLOVE X

  • スライドまとめが役にたったみたい
  • @kakakakakku さんから ブロハラブログ愛を受け取り、感想ブログをかいた

kobase16.hatenablog.com

  • 講演を聞いたことをきっかけに、@tsuyok さんに1on1コーチングをして頂いた
  • オーセンティック
  • ありのまま
  • 在り方
  • 詳細はここ

@DiscoveryCoachさんのファシリテーション基礎講座

  • 見る
  • フィードバック
  • 考える
  • 「作用する」ことをする
  • 詳細はここ

Interact 2019

  • Azureのセキュリティの話がよかった

www.slideshare.net

【7月】

Developers Summit 2019 Summer

  • 及川卓也さんの熱を受け取ったのは、この時が初めてだったかも?

Agile Leadership Summit 2019

AgileJapan2019

  • 豆蔵の中佐藤さんの「アジャイル推進のための"超"辛口アドバイス」でのひとこと
    • おそらく、今までで一番RTされた
    • みんな、気になる発言なんだなあ


【8月】

builderscon tokyo 2019

  • Red Teamの活動がすごい

【9月】

XP祭り2019

  • XP祭りは、アジャイルな人やQAな人が集まる特異点な気がしています。
  • はじめてのイベント運営に関わらせていただきました。ありがとうございます。
    • でも、全然打ち合わせいけなかったし、ROMってる幽霊実行委員でした。
    • そもそも、ほとんどの実行員の方から認知されてないと思う。自称スタッフなのでは?疑惑
    • 来年こそは、ちゃんと貢献したいです。応募する!

ストレングスファインダーをやってみた

  • 私のことをズバリ言い当ててくるので、客観視?できた。

【10月】

それぞれの現場の「正しいものを正しくつくる」

  • みんなでつくる

speakerdeck.com

Engineering Organization Festival 2019

  • 質とスピード

  • バズった?

kobase16.hatenablog.com
@t_wadaさんの講演メモで、いわゆる「バズる」に近いを体験をしました。
いつもは、月2桁程度のアクセス数です。でも、たった2日で約2万アクセス。
(アクセス数のスパイクが発生して、わけがわからないよ)

@t_wadaさんがすごすぎるのであって、私の力ではないのですが、ひとつの学びを得ることができました。

それは
「アウトプットすると、インプットになる」
「発信するところに情報が集まってくる」
の一端を感じたことです。

下記は、私の記事と@_wadaさんの元資料へのブクマコメントです。
[B! 品質] やはり俺の「質 v.s. スピード」はまちがっている。 #eof2019 - 名前考えるの苦手
[B! ソフトウェア開発] 質とスピード / Quality and Speed - Speaker Deck

Twitterやブクマで、たくさんの人が賛否ある意見や別の観点の意見をコメントしている。
普段生活していても、数人の意見を聞けるくらいですから、
「あー、そういう見方があるんだなー」と良い気付きがたくさんありました。

その中でも、とても印象的だったコメントをひとつだけ紹介します。

やはり俺の「質 v.s. スピード」はまちがっている。 #eof2019 - 名前考えるの苦手

ハマチの続編はよ

2019/11/01 14:42
b.hatena.ne.jp

記事タイトルなのかよ!(ツッコミ)
はまちの最終巻出たよー。まだ読めてない😭

やはり俺の青春ラブコメはまちがっている。 (14) (ガガガ文庫)

やはり俺の青春ラブコメはまちがっている。 (14) (ガガガ文庫)

  • 作者:渡 航
  • 出版社/メーカー: 小学館
  • 発売日: 2019/11/19
  • メディア: 文庫

【11月】

JaSSTソフトウェアテストシンポジウム-JaSST Review'19

  • QA系ははじめてだったかも。品質という文化なのか、お堅めの印象。
  • 違和感のつかまえかた

kobase16.hatenablog.com

Scrum Interaction 2019

  • 野中先生とサザーランド博士

kobase16.hatenablog.com

プロダクトマネージャーカンファレンス 2019

  • プロダクトマネージャーの視点が少しわかった
RSGT2020のボランティアスタッフ応募→落選

勇気を出して、このためだけにfacebookアカウントを作ったけど、落選。
前日の予定も空けられなくて、英語もできないからなー。仕方ない。
ボランティアスタッフが人気あるカンファレンスって、素敵じゃない?

【12月】

Scaled Agile with Jim Coplien

  • Jim Coplienさんのお話をはじめて聞いた
  • コミュニティ
  • Tokyo Agile Community (TACO) いいよ!

kobase16.hatenablog.com

すえなみチャンス忘年会2019 本編

  • ノーチャンスだけどステッカーもらえた!

  • @nrslibさんの話を聞いていて、何故か泣きそうになった


【2019年まとめ】

2019年は、インプットし続けた年でした。
それだけで、私は何も成していません。

今年は、及川卓也さんのいくつか講演、ポッドキャスト、ソフトウェア・ファースト(まだ読み中)で、熱を受け取りました。
気付きのひとつは、私は「行動変容」ができていないことです。
「カンファレンスたのしー!すごーい!」とエンターテインメントを楽しみ、翌日には疲弊したお仕事の日々に戻る、そんな繰り返しです。

まだ何も成してない」(はねバド! 16巻より)

ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略

ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略

はねバド!(16) (アフタヌーンKC)

はねバド!(16) (アフタヌーンKC)

「あなたは、何をする人なんですか」「あなたの使命は、なんですか」

この「問い」に、私はまだ答えることができていません。

ただ、ひとつ、一年を通して、できるだけ続けたことは、
勉強会やカンファレンスのTwitter実況です。
単純に、自分にとって一番楽なメモの形がTwitterだからではありますが、
勉強会やカンファレンスの様子を少しでも他の方に届けられたらなーと思っています。
(ただ最近は「お前人の話を真面目に聞けよ」とも心の声が言っています)

もしかすると、私の使命は「恩返し」なのかもしれません。次の誰かにタスキを繋ぐこと。
そのためにも、私自身が変化して、走る必要がある。

印象に残った言葉・学び

  • まだ何も成してない
  • 力学
  • それは失敗じゃない、実績解除

aloerina01.github.io

  • 「学びだわぁ~」
  • 「早く寝なね」
  • 明るく元気に後ろ向き
  • 取り調べは「傾聴」だった

  • 山本五十六さんの「やってみせ 言って聞かせて させてみせ ほめてやらねば 人は動かじ」には続きがあった

山本五十六さんの「やってみせ 言って聞かせて させてみせ ほめてやらねば 人は動かじ」には続きがあった件 - 名前考えるの苦手

学びのつながり

XP、アジャイルスクラムリーンスタートアップサーバントリーダー、マトリクス組織、ネットワーク型、継続的デリバリー、DevOps、マイクロサービス、Management 3.0、360評価、不確実性、ビジネスアジリティ、モブプロ

これらの繋がりが少し見えた気がしています。
XP祭りで角谷さんの話しされていたアジャイルユニバースの一端なのかも。
一度、理解を整理したい。歴史や経緯や対比して考えて、流行ではなく本質を捉えたい
歴史学びたい。

それはそれとして、結局は、愚直に現場を見て、現場でがんばるだけだよね!!

2020年

じゃあ、どうするの?

来年は、行動変容の年にする

  • 自分の行動変容
    • まずは、とにかく自分が変わる
      • 我慢しない。できないなら、辞める覚悟
      • 心と体に染み付いたウォーターフォールマインドセットを捨てる。宗旨変え。アジャイルになりたい。
        • 選択と集中捨てるやめる増やさない
        • できるけど、やらない
      • なんらかのアウトプット(ブログなのか、登壇なのか、LTなのか)
      • はやく寝る。はやく帰る。休む。「がんばらない」をがんばる
      • 楽しむ。
      • RSGT2021のプロポーザル出す。そのために行動を!
      • 「あなたは、何をする人なんですか」「あなたの使命は、なんですか」の答えを探す。
      • 引きこもって同じ位置に留まらずに、ぼっちの旅に出る。
  • コミュニティへの恩返し
    • イベントの運営お手伝いとか、何らかの形で
    • XP祭りのスタッフ応募する!こんどこそ!
    • 私になにができるだろう🤔
  • 行く

そのために、インプットは、意識的に抑えたいです。
(最近は、気が付いたときには、参加をポチってる)
正直、インプット過多で、情報が瞬間的に流れて、忘れてしまっていまるだけな気がします。

全部やろうとして、結局どれもうまくいかない。
これって、ウォーターフォールマインドセットなんじゃなかと思います。

ちょうどこの記事を各数日前やちょうど書いている時に、Twitterで「寝ろ」「休め」など、ありがたい言葉を頂いています。
心と体を健全な状態で、質の良い学びを得て、変化したいです。

僕は友達が少ない

「(中略)お前自身は一体なにがしたいんだよ!?」
(中略)
 理科は俯き、
「……なにがしたいか……?」
 無感情な声でぽつりと呟いた。
「……そんなの、決まってるじゃないか……」
 消え入りそうな声でいったのち、理科は顔を上げた。
 ギラギラと強い意志の光を放つ鋭い眼差しで俺を見据え、


「僕は友達がほしいんだよ!!」


 これまでずっと表に出すことなく隠し続けていた、彼女自身の本当の願いを口にした。

僕は友達が少ない 8巻より)

知り合い、仲間を増やしたい。ぼっちつらい。
言い訳なのは承知の上で、
私は、コミュ障すぎて、コミュニケーションが苦手です。

懇親会は苦手です。知らない人と話せないし、知ってる人でも、かなり距離が近くないとまともに話せません。
距離が近くなると急に喋りだすので、下記のような感じです。

私と話してても、たぶん、相手もおもしろくないだろなーって思います。ごめんなさい。
懇親会ぼっちがつらいので、最近はすぐ帰ります。
でも、ほんとは懇親会や二次会で、みんなとわいわいしたい。

僕は友達が少ない 8 (MF文庫J)

僕は友達が少ない 8 (MF文庫J)

感謝

びばさん、渡部そばさん、はちさん、かおりっとさん、いなやまさん、gaoryuさん、ゆのんさん、すやまさん、KANEさん、まなみんさん、こまどさん、ひろもりさん、あろえりーなさん

会った時に声かけてくれるだけでも嬉しく思っています。いつもありがとう。話せなくて、ごめんなさい

ここまで書いて、結局は「自分が変わる」こと、「コミュニケーションを頑張らなきゃ」と感じました。つらい。
コミュケーションは「気まずさをみんなで倒す協力ゲーム」ですからね!(ぐぬぬ

なぜ、この人と話をすると楽になるのか

なぜ、この人と話をすると楽になるのか

mameco0417.hatenablog.com

スマイルスキル=スキスキル

この記事は「スマイルスキル=スキスキル」をBGMに書きました。
qiita.com

チャンスもハッピーも待ってたって来ないよ
つかまえなくちゃね(ですねー!)
そういうコトがわかってきたよ
明日はどこ行こう?(まかせなさーい)
真剣だってふざけてたって
負けたくないから(がんばっちゃう?)
ホンキ出すよ 恐る恐るだすよ
もっと楽しく、ね! オッケー? はいオッケー!

歌詞カードを見ながら、書き写してたら、涙が出てきました。畑亜貴さんすごい。

はいオッケー!

知り合いを6人辿れば、世界80億人と繋がれるのに、組織内のコミュニケーションに6人以上必要なのは、おかしくない? #TACO

Tokyo Agile Community (TACO)の「Scaled Agile with Jim Coplien」の講演メモ。

taco.connpass.com

英語がわからない私が、同時通訳してくれた内容を私の理解でメモしたものです。
断片的な上、正しくない表現や誤りが多いと感じます。いつも以上に自信がありません。
講演者と質問者と通訳者と私の言葉がとてもまざっています。
正しく理解したいため、違う点や補足などあれば、ぜひフィードバックお願いします。

Tokyo Agile Community (TACO) について

私は3回目の参加でした。
今回は、講演者の影響なのか、いつもと参加者層が違った(増えた)ように感じました。
Twitterで聞いたら、来たことある人は、少数だったらしいと、川口さんが教えてくれました)

TACOは、主催者の方の多くが日本語ネイティブではない日本(東京)のコミュニティです。
日本と海外をつなぐ、特異点な気がしています。まさに、ネットワークのハブ。
特に、英語できる日本人は、どんどん参加すると良いと思います。月1回開催みたいです。
(私が英語わからないので、勉強しなきゃ...)

川口さんがまとめてくれました。是非こちらを見てください!

kawaguti.hateblo.jp

Scaled Agile with Jim Coplien


www.slideshare.net

  • Jim Coplienさんは、今年2回目のTACO
  • コミュニティは未来
    • 私はコミュニティを育てたい
  • 1プロダクトで1チームの人はいますか?
  • 複数のDevチームの人はいますか?
    • 3チーム以上が多い
  • LeSS
  • SAFeはアジャイルじゃない
  • スケーリングはよくない
    • 日本チームと中国トームのように離れている以外では、スケールする意味がない
  • ただ、プロダクトが大きすぎて、誰も作り方がわからない
    • フィーチャーが多すぎる
    • 90%のフィーチャーは誰も作らない
  • Spotifyは1つのプロダクトに思えるが、80個の小さいプロダクトがたくさんある。
  • 1つのプロダクトは1つの開発チームでできる。
  • Skypeは人がたくさん増えたが、うまくいかなかった
    • はじめたときは5人だけ
  • スケーリングはそもそも悪い
  • ソフトウェアはアンフェア
    • 1人だけでソフトウェを作って、お金をたくさんもらうことができる
  • そもそもなぜスケーリングしたいか?
    • ビジネスがうまくいくと、もっとやりたくなる→スケール
  • スクラムチームは改善するだけで10倍、100倍になる
    • 新しい人を入れるより効率が良い
  • 7 + 1
  • 7人のチームに 新しく1人を追加すると?
    • 2チームに分ける
    • 40%はコミュニケーションコストになる
    • 20個くらいのチームでないと、同じ効率にならない
      • 勿体無い
  • お金がたくさんある会社は、スケーリングをやる
    • お金があるから。できるから。
    • キャピタリズムの証拠
      • お金がたくさんあるから、やる
  • 日本で「あなたの仕事はなんですか?」と聞くと
    • 「電話を受けて、他の人に共有すること」と答える人がいる。
    • 必要?
    • いろんな会社は意味がないことをしている
    • もしかしたら、そういう会社の人は参加者の中にいる
  • スケーリングはそもそも悪い
  • ある人は、「スケーリングしなきゃ」という。
    • 「改善」の考え方がない
    • SAFeを使って改善できないよね
  • 組織的なスケーリングについて話しましょう
    • 「たくさんある部門の人たちと話しますか?」
    • 自己組織化されておらず、他のチームと少しだけ話さないといけない
    • 他の人と話さないといけない状況は、スクラムチームの以外の他の人たちも実はスクラムチームにいる状況
  • Scrum@Scaleはスクラムではない
    • お金をもらいたいから、コンサルが広めてる?
      • 「スケールをやりたい場合は~」
  • サザーランドは、スケーリングパターンがないと言ってた
  • スクラムチームをコピペ→Scrum@Scale
    • フラクタル構造
    • Scrum of Scrum of Scrum of Scrum of Scrum of ...
    • Chief Chief Chief PO
    • ケン・シュエイバー
      • 完全に階層がある。ドイツの軍隊から持ってきた
  • 木構造。ツリー。
    • (データ構造の木構造の話)
    • 組織も同じような構造を持ってる
      • 人間はコミュニケーションできるツリーを作らないといけない
        • TACOはそのコミュニティのひとつ
  • Scrum@Scale
    • スケールフリー
    • 「どんな組織でもスケールできる」
    • 「どういうことですか?」聞くと
      • たくさんのチームでも 「一人あたりの生産性は下がらない」と言い張ってる
      • 組織が大きくなると生産性は上がるはず?
      • ジェフが解決しようとしたことはそもそも問題じゃなかった
  • 同じ話をしたら、数学者は怒っていた
  • そもそもスケールフリーってどういうこと?
  • Scrum of Scum of Scum ….
    • 5人いて下に5チームあるを想像する
    • 一番下に開発者
    • アジャイルだとindividual interaction
  • 完璧な状態だと他のチームとコミュニケーションしなくていい
    • 自己組織化ができてる
    • どう考えても話さないといけない場合
  • 平均的に2人で話したい場合、間に7人くらいのチームや人がいる
  • 100人と話さないといけない
    • 会ったことない人もいる

f:id:kobase16:20191205005106p:plain

  • 友達を辿っていくと6人で、地球の誰とでも繋がれる
    • スモール・ワールド仮説(6次の隔たり)
      • 世界の80億人が6ホップ
    • ヒエラルキー組織は6人以上
    • 統計的に証明されている
      • 地球は組織されてるわけじゃない
  • 組織を超えて、直接自分のネットワークで話すことができないと
    • 8人と話さないといけない
    • 世界の他の人と6人でいいのに?
  • アーキテクチャはイントラクションできない
  • どう直せばいいでしょうか?
    • 同じフィーチャーを、別のチームも触ってる
    • 新しいチームを作って、2チームを1チームにする。ハブと呼ばれている。
  • チームには何人いますか?
    • どう連携しますか?
      • 複数チームのエキスポートが集まって解決
    • Spotify
    • ギアツ
    • バーツ
  • スクラムだとどうチームで解決するか?
  • Scrum@ScaleのScrum of Scrums
    • 10年前はスクラムマスターではなく、一番困ってる人が集まってた
  • LeSS
    • Scrum@Scaleと比べて、スクラムに近い
    • 勝手に作って意味がないと思ったらやめられる
    • 作って終わって、作って終わって
    • 1回だけ作らないといけないと思ったら作る
  • 数学的にスケーリングを説明します
    • グラフ理論
    • ノードは5つの繋がりがある
    • ノードは1個だけのつながりがある
  • 組織についてのデータを集めて統計的に見ると、5を真ん中にして標準偏差になる
  • 5人以上は多すぎ
  • 多くの組織でも大体こんな感じ
      • Scrum@Scaleはこれ
  • ヒストグラム
    • 1人が何人と繋がっていますか、
  • スケールフリー
  • 例を見ると、普通の会社だけど、最後は多い
    • そういう人たちはホップが必要な人たち
  • チームをコミュニケーションするハブがない
  • アジャイルになるときに、会社は*何を捨ててきたか?*
    • コードオーナーをやめて、専門家をやめて、マネジメントをやめて*
    • コードのモジュールのオーナーはいますか?その人だけしかコミットできない。
    • マネージャーは自然なハブ
    • アジャイルするとハブはなくなる
  • How to build software
    • 人間はソフトウェアではない
    • 組織の中だとマネージャはうまくいかない
    • 文化人類学社会学、組織デザインの知見が巻き込まれないのが良くない
  • インタラクションが多い人たちは
    • こういう仕事をしたくて作ったのではなくて
    • 自己組織的に作った。コミュニティ。モチベーションのある人
  • 25人で6ホップ
  • ハブを作ったら6から3になる
    • コミュニケーション
      • ヒエラルキーの場合、間の人がいないと、他の人はコミュニケーションできない
        • 階層構造の問題
      • ハブだとできる
        • 人が休んだり、やめてもコミュニケーションに影響がない
    • マネージャーは、600人が自己組織的に動けることを信じられない
    • 人間は自己組織的にコミュニケーションができる
    • Scrum of scrum of …みたいな時間があれば非常に時間かかる
  • ツリー型(ヒエラルキー)の組織だと、末端ノードの人は上の人しか見てない
    • 上の人がバケーションに行くと、コミュニケーションパスをなくす
  • ハブはネットワーク型で冗長構成になってる。一部壊れてもネットワークは死なない。
  • ヒエラルキー型のコマンドコントロールから、ハブを中心としたパラダイムにいるのではないか?
  • ヒエラルキーの間にいる人(マネージャー)は、自分を通してほしい
    • 自分を通さずにコミュニケーションしようとすると、間に入ろうとする
    • これがひとつめの問題
  • Scrum@ScaleだとたくさんPOがいる
  • ふたつ目の問題
    • POが多重になってる。二段目のPOは何を持ってるの?→何も持ってない。
    • スケールしようとすると、
    • 途中のマネージャーいらないから「解雇しようぜ」って言う
  • ハブを使えれば、Scrum of Scrumsはいらない
    • 「A Scrum Book」にパターンが乗っている(宣伝)
      • Scrum of Scrumsと書かれてるけど、実際はハブ*1
  • Scrum@Scaleは、ある状況では良い
    • 個人的にはScrum@Scaleを使うのは、スクラムではない
  • Scrum@Scaleは
    • スクラムチームを『管理』したいならこういうやり方がありますよ」って言ってる
    • 自己組織化すれば、上にあるのがなぜ必要か、理解できない。
  • LeSS
  • Scrum@Scaleには、個人的には、いろんな問題があると考えているScrum Allianceと一緒に考える
  • LeSSを作った一人はScrum Allianceから抜けつつある
  • Scrum AllianceとLeSSは一緒にやっていたが、ジェフがScrum@Scaleが一番大事と言ったので、LeSS は離れつつある(?)

  • ウィーンのScrum Gathering で、今日と同じ話をした資料があります(近日公開予定だそうです)

Q&A


Q:ウォーターフォールで、スケールフリーネットワークを作れる?
  • A:ウォーターフォールだとそもそも難しい
  • 他の部署に渡すと終わり
  • 例えば、テストの時には、分析した人は、別にものにアサインされてる
  • それだと、テストの結果を、分析にフィードバックすることは無理
  • ウォーターフォール:ロイスの論文
    • 論文には、戻るライン(フィードバック)は、絶対に必要だと書いてる
    • 実際には、部署がバラバラだと戻らない
    • 部署間で、レビューがあるだけで、渡したら終わり
    • 「戻す」が必要だと書いてあるけど、それがない
  • ラクルが起こらないと変わらないと思う。
  • ↑ここまでは、守破離の「守」の話



  • コーディングをいつしますか?
  • 開発をはじめないと、デザインをわかることができない
  • ソースコードの80%は、デザインしながら書く
  • (理想は)どっちの部署も話し合って
  • ルールを柔軟に変更しているのは、ウォーターフォールと呼ばれている何か
Q:「スケーリングは悪い。小さいプロダクトの集まり」という話だったが、最初から分けたほうがいいか?
  • A:お客さんは、小さいものにお金を払いたくない
    • たとえば、iPhoneの場合に1つずつのアプリにお金を払ってないですよね
  • できるだけUX大事
  • 小さい部分で分ける
  • 半分は UXわかってる人がいたほうがいい。UXは非常に大事
  • OOP(オブジェクト指向プログラミング)をやってる方はいますか?
  • OOPの源流の定義はなんですか?
    • アラン・ケイが作った
    • 作ろうとしのは、子供達が学べるようなプログラム
    • 子供から見たメンタルモデルをマシンの中に入れる
    • マシン自体が子供の頭の延長になる
    • すると、脳のウェットウェアとマシンのハードウェアが近いインターフェースになる。
    • OOPは目的は認知モデルと近づけることがアラン・ケイの考え。


  • UXを学んでください
    • UXのスケーリングは必要ですよね
Q:LeSSだとHubがありますか?
  • A:LeSSのハブは同じハブはない
    • 必要だったら集まって、終わったらなくなる
  • Scrum@Scaleは15年前の考え方
  • LeSSだと、問題を抱えている人を呼ぶ。
    • 判断で参加する
  • ハブはツールではない
    • Confluence(アトラシアンの製品)上にハブを作らない
    • *対話で解決*してください
  • ハブだと定期的でも、1回でもいい
  • ハブは3種類
    • スクラムだと2つ
    • お寺、神社の檀家さんみたいなつながり。ひとつのノードから何千人もいる
      • 人工的に設計しようと思ったらできる
    • ロールを作ることができる。マネージャーとかコードオーナーとか
  • ハブの種
    • 育てて、できるだけ人のためになる
    • その人はハブのオーナーになるかを判断したほうがいい。
  • 最初、会社に入ると、コミュニティやハブを知らない
  • スケールフリーネットワークだと、(理論上)人がたくさん入っても同じ長さになるけど
    • どう考えても、たくさん人が入るとダメになると思う
    • もしこれができたら、修士論文書けるレベル
  • ハブがあれば、行っていなくても、認識できる
    • それぞれのハブが詳しく何をしてるか知らなくても、どういうハブがあるかわかればいい。
Q:ハブの悪いところはないの?
  • A:ハブはパスをカットしても、問題ないと言っているけど、
  • ハブを完全に切ってしまうと、非常に問題がある
  • ハブが急に消えないようにしないといけない
  • 個人的に、弱さはこれしかないと思っている
  • ハブが解決したい問題がなくなったら、ハブは自然に消える
    • スプリントプランニングで2つのチームで問題あるよね。とわかったら、ハブができる。
Q:ハブと組織全体の情報共有はどうするか?
  • A:なぜそれが必要ですか?
  • ハブは本当に情報が必要な人が集まってる
  • 情報を中心とした集まり
  • そもそも全員が全員の詳細を知ってる必要がない

かんそー

  • *Small is beautiful!*
  • そもそもスケールは、よくないこと。
    • でも、大きくなって、お金があると、スケールしたくなってしまう。
  • 小さなプロダクトをたくさん作るほうがいい
  • ヒエラルキー組織構造をスケールするのではなく、ネットワーク型のハブ的なコミュニティ構築をする。」
    • ということの背景や捉え方を深めることができるお話でした。おもしろい!
    • ティールやらなんやら、「ヒエラルキー型ではなくネットワーク型」と最近流行っていますが、その理由を少し深く見れた感じ。
  • スモール・ワールド仮説の話は、
    • 知り合いを6人辿れば、世界80億人と繋がれるのに、組織内のコミュニケーションに6人以上必要なのは、おかしくない?
      • という「問い」なんだろーなーと感じました。
  • Scrum@Scaleとの比較

  • 上記のはちさんのツイートはまさにそうだと思いました。
    • 先日Scrum Interaction 2019で、ジェフ・サザーランド博士が「Scrum@Scaleでビジネスアジリティを実現する」という講演を話をされていたので、本日の話と比較すると見えるものが違うかも?おもしろそうです!
    • まだ、消化できていないのですが、ゆっくり時間ある時に比較して考えたい。
    • Scrum Interaction 2019の内容は、下記参照。

kobase16.hatenablog.com

  • 個人的に、生Jim Coplienさんを見たのは、はじめて。

エンパシー(共感)ってなんなんだろう? #ScrumInteraction2019

2019/11/8(金)に開催されたScrum Interaction 2019の講演メモ

野中郁次郎先生とジェフ・サザーランド博士の二人が講演だって!?
「行く以外の選択肢がない」

結果、普段聞けないようなお話を聞くことができました!ありがとうございます!
資料は(一部を除いて)後日公開予定だそうです。嬉しい。

f:id:kobase16:20191108235137j:plain

本日のバックログ

f:id:kobase16:20191108235153j:plain

ジェフ・サザーランド博士「Scrum@Scaleでビジネスアジリティを実現する」

  • 素敵なグラレコ


  • 企業全体
  • Eliminate the Agile BS
  • サッカーのルールを学ぶのではなく
  • デジタルディストラプチャー
    • 個人的な体験
      • 石油:太陽光
      • 太陽光モデル
      • 太陽光でエネルギー無料
      • マイクログリッド
      • モバイルアプリ
  • アジャイルプロジェクトの30%は失敗。失敗のうち、50%はデリバリーできていない
    • スクラムの全体のうち
      • 1/3はできてる
      • 1/3はうまくできてない
      • 1/3はしてない
  • 米国防の案件はアジャイルで行うという法律がある
  • 最後のスプリントでデリバリーできるか?
  • 1ヶ月以内にバックログを変更できるか
  • メタフレームワークであるScrum@Scaleのガイドを作成した
  • 人事が大事
    • パフォーマンス、評価
  • Scale-Freeアーキテクチャ
  • 意思決定
    • プロダクトオーナーの意思決定を10分以内にすべき。遅くても1時間以内。
  • Operationsチーム
    • Lean
  • Scrum of Scrumsの定義
  • アジャイルのカンファレンスで「ウォーターフォールのマネジメントをやっていますか?」と聞くと、会場のほとんどが手を挙げる
  • スクラムマネーボール

    • 使われる、不要、できの悪い、ムダ
    • プロセス効率 = Works Time / Calendar Time
  • みんなで合意をしようとするのが難しい。意思決定が遅い。
  • Appleは赤い本の通りにやっている
  • マネジメントは環境を用意する
  • Scrum@Scaleの最初のプロトタイプができた
  • FrAgile
  • 遅れると、マネージャーがミーティング増やしてさらに遅れる
    • 私はパイロットの経験がある
    • プロジェクトを着陸させる方法
    • 月曜に離陸して、金曜に旋回しながら着陸
  • 収入+30%<コスト
  • 6ヶ月後、収入>コスト+50%
  • このタイミングで野中教授の論文を読む
    • Scrum@Scaleのプロトタイプ→Scrumになった
  • Business Agility
  • 私が訪問した翌日には株価が上がる。投資家は見ている。そのあと変わっていないと、株価は下がる。
  • 人事
  • ファイナンスマーケティングは話好きなので、ベストなスクラムチーム
  • 「(講演の時間が)3分残っています。非常に大切なのは、はやくおわる。」
  • 近くにいる感覚
    • 電話ではなくテレビ会議を使う。顔を見るのが大事
    • Face to Face
  • (表彰式でのひとこと)「(アジャイルスクラムが)私の人生を変えました」と言われるのがうれしい

野中郁次郎先生「Humanizing Innovation -共感の経営-」

  • 素敵なグラレコ

  • Humanizing Innovation -共感の経営-
  • 最近のマネジメントの潮流
  • 新啓蒙会議。ディシプリンが必要→共感
    • 株主価値最大化を否定する
    • 株主でなく、顧客と向き合え
    • アジャイルマネジメントが大事
    • 経済・経営学の役割
    • 社員の復権。「社員はリソース。使い捨て」はそうではない
    • 共感をベースにして、短期長期に価値
  • (著書で)一番売れてるのは「失敗の本質」
    • 失敗の理由:過去の成功体験に過剰に適応した
    • 過剰分析(オーバー・アナリシス)
    • 過剰計画(オーバー・プランニング)
    • 過剰規制(オーバー・コンプライアンス)
  • 頭と体はわけられない
    • 相互補完の関係
  • イノベーションは、脳と身体と環境の相互作用からうまれてくる
  • GRIT(やり抜く力)はIQを超える
  • 暗黙知を原点にする
    • すべての知は暗黙知
    • 語れること以上のことを身体は知ってる
    • それだけだと主観で終わる
    • 人々の主観と主観を「共感」させる
  • 「知る」は個人のコミットメント
    • それがなければ、知は作れない。
  • 本田宗一郎
    • 上からでも下からでもなく目線を合わせる
    • 全身全霊で向き合いながら、知的な対話をする
  • SECIモデル
    • 共感からはじまる
    • そこからコンセプトにつなげる
    • はじめに共感ありき
    • 知というものは、個人・単独で生まれてくるものではない
    • 対話
    • コンセプトは共感から生まれてくる
    • 個人と個人の共感、から、グループの対話
    • 個人→集団→組織
  • PDCAは品質追求の効率化モデルで、創造モデルでない
  • 知識機動力
  • 社員の物心両面の幸福の追求
  • Me thinking. We thinking.
  • 1人称から3人称には、いけない。その間に2人称がある。
    • 2人称=共感、相互主観
    • 根本的に二人称が大事
    • 集合知のモデル、SECI
    • まず二人称
    • まずペアありき
  • 同感と共感
    • 同感(Sympathy)
      • 主観が残っている
    • 共感(Empathy)
      • 他人になりきる
    • Empathyドリブン
  • コンパ経営
    • 「やっぱ飲まないといけない」
    • プロフェッショナルに考え抜く
    • 畳でないといけない。肩を寄せ合う。椅子はダメ。
    • 鍋を囲む
    • 手酌はいけない。エゴイズムの塊
    • リーダーは飲んでいいが、酔っ払ってはいけない
      • (リーダーの役割)ここまでの話をまとめて、結論はこうだ
  • チームの原点はペア
    • 同質ではなく、対立のペア
      • ex.「一緒に居たくない」
    • 開発者とクォリティーコントロールがペア
  • ミドルアップダウン
    • リレー型、サイロ
    • 刺身型
    • スクラム(当時はそういう名前ではなかった)
  • メーカー(ハードウェア)の研究だった
  • ソフトウェアに展開したのはジェフ
    • 平鍋さんと川口さんが野中先生とジェフ・サザーランド博士をマッチングした
      • Innovation Sprint 2011!
  • ラグビー
    • One for all / All for one
    • フェアプレー、紳士
    • 徹底した共感に基づく対話
    • 自律分散
    • アートとサイエンスの統合
    • ラグビーって言ったのは偶然
  • 海兵隊フラクタル組織
    • チームオブチームス
    • 戦略とは人と人との対話
  • 物語戦略
    • ソープ・オペラ
    • 英雄譚がいい、ロマンス
      • 喜劇や悲劇ではいけない
    • それを実現する筋書き、プロット、スクリプト
    • 問題意識を提示すればそこに人が集まる
  • 京セラのフィロソフィー
  • スクラムを習得するには、実際にやってみるしかない
    • 卓越した境地は外から与えられるものではないけない。内側から生まれなくてはいけない
  • 二項対立から二行動態
  • 知的バーバリアン(知的野蛮人)
    • 知的体育会系
  • 野中酔い
  • 暗黙知-無意識
    • 極めて細かな事例の研究
    • さまざまな暗黙知が漂ってる
    • 絶えず対話を通じて共感とベースがないと、イノベーションは生まれない
    • 状況は絶えず変化している
    • 過去の事例が無意識に出てくる
      • 無意識の意識がひょっと出てくる
  • Here now ness(イマココ性)

ケーススタディ

  • 素敵なグラレコ

3M:ブライアン・ハッカソン氏、デビッド・フレイジー
  • イノベーションを生み出せない
    • 40年の歴史がある会社
    • 世界のスピードについていっていない
  • 4年半の物語(2015-2019)
  • アメリカの医療系
  • HIS. ヘルスケアシステムの話
  • アメリカの医療系
  • IDC-10規制がはじまる半年前に、何も準備できていなかった
  • ヘルスケア事業は、収益性が高かった
    • (IDC-10規制がはじまる)10月1日がやってきた。達成はできたが、残業続いた。
  • Productivityが半年で +150%
  • ある役員「私はスクラムが好きです。本当に重要なプロダクト以外では」
  • ミネソタのマーチングバンドの動画
    • 8年経っても体が覚えている
    • Scrum@Scale
  • ver1. スクラムをする
    • 4つのバックログからはじめた
    • Tという形になっていない
  • ver2. Peple
    • バックログを1つにした
    • 重要にイニシアティブ
    • 科学者をチームに入れた
      • 「チームに入ってどう思う?」
      • 私の専門性を使える使える。毎日会社にくるのが楽しい。
  • ver3. Strategy
    • Epic(ness)を中心に
    • R&D、Data、Manufacturing、ビジネス
  • The Happiness of Innovation at 3M
    • Cloud、Scrum、Talent、Hack

f:id:kobase16:20191109003639j:plain

AgileWerk:ポール・タッケン氏
  • コーチとしての個人の体験
  • The Future is Electric
  • THE WHY GUY。私は理由を知りたがる男だった。
    • Curiosity(好奇心) killed Cat.
  • 変化のスピード、そしてそれに適応していくこと
  • Reptilian Non-Brainer
  • 爬虫類脳
  • SAFety Firstになってしまう
  • 「できない」というメンタリティをやめる
  • アジャイルスクラムの原則にのる
  • 「でも」というメンタリティ
  • Kickstarts the Agile Transformation
  • 90%の学生「スクラムをやりたい」
  • ハートビート
    • 1weekスプリントの心拍数
  • 教訓の一番目:HRと取締役会を関与させてはじめる
  • 教訓の二番目:トランスフォーメーションを並列しない
  • Less ego and Control
  • Agile en Bodeiment
  • 意見を言う、溜め込まない
    • 合気道のようにすべて流れていく
  • エネルギーのフロー
  • Meaning & Purpose
  • バッテリー
  • レジリエンス
  • マーケティングスクラム
  • クライアントとつながって、クライアントの話をする
  • 「楽しんでいるから」
  • 他社のScaleを真似しない
  • How will you charge it.
  • スクラムは、アルゴリズム。ブループリントでない。
コカ・コーラ:フランク・サーモン氏
  • 発表者
    • CGO
    • アルゼンチン
    • (日本語でひとこと)「貧乏暇なしです」
  • Agile growth Enterprise
  • 4つ
  • Agile@Scale
  • 南米の部門(アルゼンチン)の話。230人。会社全体の5%
  • ①TRANSUERVAL
  • ②COMPLAEX
    • Distruption
    • VUCA
  • ③CULTURE in Action
  • Less / More

f:id:kobase16:20191109003450j:plain

  • 1.PRESENT FORWARD
  • 2.FUTURE BACK
  • できるだけ専属、フルタイム
  • Scrum of Scrums
  • 24のアジャイルチーム
    • 3年かけた
  • Scrum@Scaleフレームワークにのった
  • BIG BET
    • 1.no suger
    • 2.非炭酸
    • 3.wabi
      • 5年で20%の利益
    • Business Outcome
  • エンゲージメント
    • モチベーション
      • 自律:自分で方向性をきめたい
      • 目的:意味がある、貢献したい
      • 熟達:(書き取れなかった)
  • LAST but LEAST
  • 「システムを変えれば、行動が変わる」
    • 文化を変えようとするのではなく、まずシステムから変える
    • CLAP
      • Culture,Lxxx,Axxx,Practise
        • (LとPが何だったか思い出せません...)
      • APから変えるとCLが変わるアプローチ

f:id:kobase16:20191109005011j:plain

MSDヘルスケア:フレイザー・ウッド氏
  • LESSONS FOR LEADERS. (すべてのリーダーが聞くべき重要な質問)
  • Empathy
  • 自己紹介
  • THE AGILE MINDSET
    • 「(写真のような)体験をされた方もいるのでは?」

f:id:kobase16:20191109000714j:plain

  • もっとも大事なのは、システムを変える
  • Continuously improve (継続的カイゼン)
  • WHAT you do and How do you
  • Business Agility
  • Transformationアプローチのカイゼン
    • カルチャー駆動:話すだけ、行動しない
    • ラクティス駆動:Zombie Scrum ゾンビスクラム
    • システム駆動:トップダウン
    • ひとつだけではなく、最初から3つを意識する。
  • もっとも大きな課題
    • 1.リーダーシップ
      • アジャイルいいねやろうよ」というけど、自分はアジャイルやらないリーダー
      • 透明性というけど、自分は話さないリーダー
    • 2.「アジャイルスクラムどうでもいいから、あなたの課題は?」
  • Agile Transformation 10のチェックリスト
    • 1.リーダーがアジャイルレーニングを受ける+現場をみる
      • (※すみません、メモ取りきれず違う気がしています)
    • 2.変化のストーリー
    • 3.アジャイルのチャンピョン
    • 4.トランスフォーメーションの範囲が定義されている
    • 5.初期のスケーリングモデル
    • 6.ベンチマークを測る
    • 7.セルフサービスのアジャイル。興味があるときに自分で勉強できる
    • 8.アジャイルコーチの採用
    • 9.トランスフォーメーションのバックログ
    • 10.パイオニアチームが価値を提供している
  • パートナーシップ
  • ペアリング

Scrum@Scaleのワークショップ

  • 講演者への質問をScrum@Scaleで、みんなで考えるワークでした

QA&クロージング

  • コミュニケーションは簡単には崩れる
  • まず、カルチャー、プラクティス、システムの3つを最初から考えること
  • Whyは常に明確にし続ける
  • (チームの固定化について)避けたいのは、チームが変わること
    • 何故変わるか?
  • 「わかるよ。でもさー!
    • でもさー!の言い方。うまく伝える。
  • アルゼンチンと比べて日本はヒエラルキーがとても強い
    • リーダーの「階層」「コマンドコントロール」「テリトリー」「エゴ」がつよい
  • アジャイルチャンピョンの意味は、日本語では難しいけど、「俺がやるぜ!」という人がチャンピオン
  • 取締役のコミットメント」重要
  • 平鍋さん「取締役を説得するときに、一緒に行きます。Scrum Inc. Japanに依頼してください」

感想

  • 「3分残っています」の下りで、私が「デリバリーを大切にしていない」ことに気付かされた。
    • 私はこれまで、発表時間ぎりぎりまで話すこと、詰め込むことが良いことだと無意識に思っていた。それはスコープを優先していて、デリバリーを優先していない考えだった。「時間より早く終わらせよう」と思ったことがない。
    • サザーランド博士は、冗談で話していたのかもしれないけど、私の内面を気付くきっかけになった。
  • Empathy
    • 野中先生のお話エモい。哲学的。
    • Empathy(共感)なにもわからない!
      • もっと学びたい、体感したい
      • 具体的に日々の私の行動にどう実装する?どう実践する?
  • 「過去の成功体験に過剰に適応する」
    • これは根が深そうだ
  • HR(人事)と取締役会を巻き込むのは、とても重要
  • 意思決定を遅らせない
  • システムを変える
    • (Management3.0だ!)
  • 「やろうよ」というけど、自分はやろうとしないリーダー
    • 自分ごとに置き換えて、自分自身がダメダメだと認識した。自分から変わらないと。
  • 評価と報酬、職位、キャリア
  • ひとつだけで駆動するとこうなる
  • 合気道」のメタファーを何人の方が使用されていた
  • 英語と日本語のスライド両方表示されていて、同時に切り替わってるの良かった。
  • 今日のワークショップ用のポストイットイーゼルパッドは3Mさんのものでした!使いやすい!
  • 自分の反省:一日分のノートに書いたものをテキスト化するのは死ねる。あと、メモってると、視覚を切り捨てるので、体感をうしなってしまう(気がする)。

想定外の問題を見つけるのではなく「想定を広げる」 #JaSSTReview

JaSST Review'19でmiwaさんの『違和感のつかまえかた』という講演をお聞きしたメモ。

最近、自分のやっていることは「違和感をみる」ことではないか?*1という仮説があり、参考にできないかと思いながらお聞きしました。

miwaさんはとてもやわらかくお話する方で印象的でした。
ふだん、なにげなくやっていることの言語化はむずかしいと思いますが、
それを聞けるとても貴重な機会でした。ありがとうございます。

資料

「風邪を引いたかも?」と思った時にどうする?

  • レビューはいつするのか?
    • うちのチームは、レビューしてない
    • 毎日そこらじゅうでディスカッションしている
    • これがレビューかもしれない
  • 最良の開発プラクティスを最大限適用する
  • レビューが良いものなら、常にレビューする
    • これだ!!
  • 自分達の製品のおかしさ
    • おかしさ=違和感=注意すべきシグナル
  • 自分たちの製品。自分が風邪をひく話。誰かが風邪をひく話でない。

違和感とはなんなのでしょうか?

  • 違和感とは「いつもの状態」と「今の状態」との差分
  • 違和感をかじるために必要なこと
    • 1.いつもの状態を知る
    • 2.理想や期待値を持つ
    • 3.今の状態(現実)を知る
  • いつもの状態 + 理想や期待値 × 今の状態(現実)

  • 自分の目で自分で考える
    • それが大事
  • 私がいつ何を見て違和感を感じているか?
    • 前兆の兆しみたいなもの、注目しているもの、やっていること
    • その時に何を考えているかを言語化した
  • 「それが実現されると何が嬉しい」のかよく話題になる
    • フレーズ「うまくいったらどうなるの?」
  • 朝会でみんなの脳を同期する
    • 脳がプライマリ
    • チケットやドキュメントはセカンダリ。着想を助ける。
    • 朝会のあとは脳が疲れる。疲れてないということは、考えてないので、異常な状態

「そんなに簡単には伝わらないだろうと思っている」「出し惜しみしない」

  • やりたいことがあって、作ったものを確認して、できないことを言いたい
    • どんな問題を見つけたいかを頭の中で描く
    • 起きたら嫌なことを考える
    • 具体的に何をしたらその問題が出せそうか、考える
    • 頭の中でテスト。出し惜しみせずに頭の中で壊した結果(予測)を話す。

  • 話題になってないことが何かを考えている
  • 同僚の様子、言動を観察
    • 会話の中でこういうフレーズが出てきたら、要注意というものがある「こういう仕様です」など
  • 製品をみる
    • 毎日製品を触っているので、昨日との違いが手触りでわかる
    • こう動く、こう動かないなどの理想が頭の中である。
    • 頭の中で考えたことが間違っていることがある。それは恥ずかしいことではない。間違っていることが知れて正しいことが知れる。
  • チケットをどう見てるか
    • 開発日記やテストの履歴が書いてある
    • 自分の知りたいことが書いてあるか。関連チケットも見る
    • チケットを見てどう開発したかを頭の中で構築する感じ。イメージができないものを確認する
  • 知りたいことを教えてもらうとき、なぜ知りたいかをセットで話すといいみたいです
    • 心配しようとしてること、試そうとしていることをプログラマに伝える
    • 知りたかったこと以上のことを教えてもらえることがある

  • 「(チケットに)たくさん書いてあって読めないよ」もシグナル
  • チケットの状況からもおかしさを感じる事もできる
    • 私たちのチームでよく見るのは「なんども仕切り直される」
    • 一人で複数のチケット、なかなか手につけないチケット
    • 思ったように製品が作れないという状態は「みんなの状態」
  • コミットログをみる(を過去にしていた、今はやってない)
    • 具体的なものが引っかからなかった
    • 今でも注目しているのは、連休前にコミットしたもの
  • 自分自身を知る
    • 自分の感情
    • 人間のせいにしない。(システムのせいにする)

違和感に対する感性を高める?

  • なぜ、違和感を感じることができたのか?
  • ここ数ヶ月、自分に問いかけてみた
  • 製品を知っているからこそ感じることが圧倒的に多かった

他者の違和感を取り入れる。

  • コスパ高い。
  • なんでそんな操作したんだろうか?
  • なんでそこに気づいてんだろうな?
  • 自分からも積極的に話す。
    • みんなに空気感染して、話してくれるようになる
  • 違和感を交換するのが目的ではなく、取り入れるのが目的
    • 自分のものにするまでは意識して取り入れる
    • なんとかさんになりきってテストする
    • 他人の違和感x自分の思考

  • 自分の感情
    • なんでそう感じてるかを考える
    • 自分の意識の持っていき方を矯正している
    • 自分やチームのみんなが考えそうもないこと
  • みんなで話している中で、見えないもの、書いてないものに注目する
    • 話題になっていないこと
    • 安心していること。安心仕切っていることは話題に出てこないことが多い。本当に安心できるか?
  • 間違っているかもしれないぞ
  • 「想定外の問題を見つけるのではなく想定を広げる
  • 疲れたときは休みましょう
  • 自分自身のバグもシグナルとして使う
    • テストに熱中する(=過集中、他を見逃す)
  • 差分が微量だとつかまえられないことがある
    • わざと差分を大きくして、つかまえやすいようにする

違和感をつかまえたのに、「そのままにしてしまったこと」ありませんか?

  • なんとなく言い出せない状況や心境
    • 言いづらい違和感ほど誰かに伝えるようにしている
  • 「気のせいかな?と思うことのほとんどは気のせいじゃない」
  • 言いづらいときにどうしているか
    • 「これは仕事だから仕方ない」と思う
    • 練習する言えるようになる、でも、言いづらさはなくならない
  • 違和感を自分ひとりだけのものにしておかない
  • 違和感を口に出す。
    • 「あれ?」と口に出すと周りが反応して、そのままにしにくくなる。
    • 練度が上がると首をひねるだけで周りがざわつく
  • 捕まえた瞬間に「あれなんだ?」を考える

わかったような気になっているとき、は違和感に対する感度が鈍くなっています

  • ちょっと話聞いたくらいでわかるはずない
  • 私のくせにこんなにわかるのはおかしい

パネルディスカッションでの一部

  • チームの仕組み
    • 「おかしいと持ったらすぐにいう」
    • 「わからなかったらすぐにいう」
  • みんなには他にしてもらいたいことがあるから、調べたり悩んだりがもったいない
  • 「安全だから喋る」とかじゃない
  • 仕組みや規則があるのでなく、みんなが良いと思っているから、そう振る舞っている
  • 「わからない」を言えると言えるようになる
    • 言わないと言えるようにならない

講演をお聞きして

  • 資料をみてゆっくり考えたいな、と思った。
  • 「想定外の問題を見つけるのではなく想定を広げる」と言う言葉は、とてもしっくりくる。
  • 私の「違和感」は、「理想の状態と今の状態の差分」を感じている気がする。
    • それを感じるために「理想」を描いたり知ったりすることが大切だと感じている。お話を聞いていて、やっぱりそうかな、と思った。
  • 私は、自信がないものは注力して考えているから、そこに隠れている「無意識に自信があるもの」に気付けてない課題がありがち。
    • 自分自身を疑ってモニタリングして、感情や感覚や行動がわかるようにありたい。自分を疑うことのしきい値
    • 『無意識を使う』
  • ふだんの自分の「なんとなく」感覚をつかめるようになりたい。言語化したい。まずは手帳に書いてみようかなあ。

*1:本当にそうかは違和感がある