#RSGT2022 に参加しました

感想です。ポエムです。

RSGT2022は、私にとってユニークな体験でした。
参加するたびに違う体験を味わっていて不思議な場だなー。

RSGT2020はカンファレンスハイで頭のネジが飛んでいました。
RSGT2021はなんだかよくわからない間に気が付いたらはじまって、気が付いたらおわっていました
そして、今回のRSGT2022は、個人的には本当にいろいろあって、感情がぐちゃぐちゃになるくらいに感情が喜怒哀楽ジェットコースターでした。
RSGTやコミュニティが「私にとって大切な場なんだ」とあらためて気付かされてくれました。
セッションに全然参加していないのに満足度が高くてふしぎ。*1

当日スタッフ二回目

二回目の当日スタッフ*2をしました。
今年は去年よりは心の余裕があったのと、あとは参加者としての経験が活きたと思います。「だいたいこういう感じだよね」って思える感じ。

そして、私自身は、運営側やスタッフやホストという感覚はあまり強くはありませんでした。*3ただ単に「当日スタッフ」という参加の方法で参加者のひとりくらいに私は思っているのかも。
でも、今そう思っているだけで、来年には違うことを思っていそう。

またスタッフしたいと思う素敵な当日スタッフ参加体験でした。
全力でセッション参加全振りの楽しみ方もいいなーとも思うので、来年はわからない。

投影されました

@Aki_Moon_ のセッション中にスライドにアイコンが登場し、会場のスクリーンに投影され、さらにそれを目の前で見る実績を解除しました。
リアルタイムで見ていたら、いきなり映し出されたので思わず変な声を出しそうになりました。あぶない。
akiさんのRSGT初登壇に登場させてもらうというなんとも光栄な体験でした。ありがとう。

セッション内容に関しては、いつかやりたいと思っていたことを先にやられてしまったので、ちょっとくやしい。

牛尾さん

私のアジャイルやコミュニティとの出会いは、@sandayuu がきっかけでした。
だから、クロージングキーノートは、牛尾さんだー!なつかしいー!って感じで、声や話を聞けて、それがただただ感動でした。

そういうこともあって、個人的には今回のRSGTが何かの節目になりそうな予感がしています。

6回目

数えてみると、RSGTは6回目の参加でした。
ようやく気負わずに楽しめるようになったかもしれません。

最初はぼっちからのスタートでしたが、最近は知り合いも少しずつ増えました。
はじめましてもたくさんしました。
わざわざ探してまで声をかけてくれる方もいました。ありがとうございました。
探してくれたのに会えなかった方すみません。
Twitterで実況していて本当によかった。小さいけれど私にとってのぼたもちかもしれません。

あまり自分から声を挨拶や声かけに行けなかったのは反省。
オンラインと交流するぞーって思ってたけど、全然できなかった。
TwitterもDiscordもあまりできなかったから、まだまだ私のキャパシティが足りないのかもしれない。

小笠原さんのセッションやいくつかの場所で見聞きしたことを思い返していて、
初参加や慣れていない方向けに「RSGTの歩き方」を紹介するセッションを
Day1ランチタイムにできたりするとおもしろいかもしれないなんて妄想をしました。

感謝を

RSGTやコミュニティで出会ったみんな、ありがとう。
おかげで何とか日々を生きる勇気をもらっています。
特にコミュニティと繋がるきっかけを @viva_tweet_x には感謝しても仕切れません。*4本当にありがとう。

いつか「みんなのおかげで仕事でうまくいったぜー!ひゃっはー!」とRSGTで登壇することが夢です。
もらったものは多いので、少しずつでも返したり繋いでいったりもしたいです。

あと、これは自分でも意味不明な言葉だと思うんですけど「アジャイルうまくなりてえなあ」と思った。くやしい。

*1:録画があってもほとんど見ないタイプだから全然見ないまま来年を迎えるかも

*2:正式名称は「ボランティアスタッフ」だけど、今の私の言葉の捉え方だと「当日スタッフ」がしっくりくるので敢えて「当日スタッフ」と書きます

*3:これはいいことなのか?悪いことなのか?

*4:当人にとってはなんてこともないことだと思うけどこのこと

今すぐには通知したくはないけど、あとでSlackを読んでもらいたい

どこに書いてあるかわからなくて、いろいろ探すことになったからメモ。
通知しないDMがほしい。

その1:あとから編集して@をつける

メッセージを送信後、メッセージを編集してあとから@をつけると、相手に通知されない。
相手にバッヂ(赤いマーク)は表示されるため、相手がSlackを見た時に気付いて読んでもらうことができる。



これは「メッセージを編集してメンションを追加しても、メンションしたメンバーには通知されません」という制約を逆手に取ったテクニックのようだ。
「編集した時に通知を送らない」と言う機能ではないため、将来的に「編集しても通知を送れるようになったよ!」となる可能性はある。注意したい。

注意 : メッセージを編集してメンションを追加しても、メンションしたメンバーには通知されません。そのメンバーがまだチャンネルに参加していない場合、メンバーに追加するためのプロンプトは表示されません。

Slack でメンションを使用する | Slack


メッセージの編集で@をつけると「メッセージの編集中は通知が送られません」と表示される。
「編集中?ということは、編集が終わって送信したら、通知されてしまうのでは?」と怯えたが、そんなことはなかった。おそらく日本語訳がよくないのだと思う。
英語表示では"Notifications aren’t sent when messages are edited"
自信はないが、編集したメッセージは通知が送られないように読める。
「メッセージを編集しても通知は送られません」じゃないかな?
f:id:kobase16:20210714205417p:plain


しかし、DMはNG。そもそも@つけなくても通知されてしまう。

あと、通知をしてもしていなくても、Slackを見ている人は見ている。

その2: メッセージの送信日時を設定する

いわゆる予約投稿。

先日、Slackでメッセージの送信時に送信日時を設定できるようになった。
f:id:kobase16:20210714211628p:plain

slack.com

これはDMでも利用できる。

しかし、スレッドはNG。スレッド内では送信日時を設定できない。
スレッド内で送信日時を設定できるようになってほしい。

指導者ではないからこそ、私が心に留めておきたいこと

エンジニア育成勉強会で話すネタ案を考えたけど、まとまらなかったことを書きます。
engineer-education.connpass.com

私の大好きな漫画「さよなら私のクラマー」のことを書きます。
漫画のコマを紹介しつつ、「育成」っぽいテーマで、感想や刺激を受けたことを書きます。

極端な話、私のことはどうでもいいから、漫画を読んでくれたらうれしいです。

さよなら私のクラマー」は

高校の女子サッカーをテーマにした漫画です。
タイトルの「クラマー」は人の名前。
サッカーの指導者のデットマール・クラマーさんの名前に由来。
「日本サッカーの父」と称された方*1だそうです。
本作では、選手だけではなく、サッカーの指導者(監督やコーチ)にも焦点があたっています。

本作にあやかって、本記事でも「指導者」と称しますが、
先輩や上司が後輩や部下にOJTで教えるみたいなものだと仮定して、書きます。

だいじなことは最初に

さよなら私のクラマー(全14巻)を読んでね!!

環境のせいで死んでいく才能

alu.jp

「この人は才能あるのに」「すごい人だ」と思っても
環境のせいでうまく能力を発揮できなくて、活躍できていないという人達をみたことがある。
もし違う環境であったら、もっと成長して活躍できたんじゃないか?と。

その環境をつくっているのは誰か?
会社、本人、色々と構成要素はあるだろう。
もちろんすべてではないけれど、指導者の影響は大きいと私は思う。

OJTにおいての指導者とは誰か?
それはつまり、上司や先輩、メンター。

つまり、過去の私もその一人だ。
他人の人生に影響を与える立場にある。それはとても怖い。

それはとても怖い

私は、他人の人生をベットして育成ゲームをしているのだろうか?

alu.jp
人材を育てるのが指導者。腐らせるのも指導者。
そういう立場であることの自覚や覚悟が私にあるか?

プライドやおごりなど捨てろ

alu.jp

OJTで部下や後輩を教える立場にあるということは、
何らかの成果を上げている場合が多いんだと思う。

ある意味での成功者である人物がプライドやおごりを捨てて、
自分の培ったもの全てを出し惜しみせずに与える覚悟を持てるだろうか?

ダイヤか石コロか

alu.jp

指導者の責任は重大。

「いやー、そんなこと言われてもOJTで仕事の片手間で教えているだけで、私は教育が本業ではないんですよ」

うん、そう思う。私もそうです。
でも、そんなことはメンティには関係なくて、原石を輝かすことができるか。その影響が大きい立場にいることは変わりない。

100%全力を注がない。そういう判断をしてもいいと思うし、私はすると思う。その選択をするのは私、影響を受けるのは相手。
だからこそ、私は私の責任と向かい合っていきたい。

だって、OJTなんて上司ガチャじゃん?

必要なものは最前線にいる人間が選択すべき

alu.jp

自分のやり方か、相手にあったやり方か。
結果を出してる自分のやり方を捨てられるか?

必要なものを最前線にいるプレーヤーが選択・判断できるように、したい。

楽しんで出来てる?

alu.jp

楽しんで出来る環境を作れているだろうか?
楽しんで出来る状況を生み出せているだろうか?
楽しんで出来ているだろうか?

最高なパフォーマンスを出せているだろうか?

いろんな人がいて、そいつに合った目的、やり方、選択がある

alu.jp

こうしたほうがいい
ああすべきだ

それは、そいつに合った目的、やり方、選択か?

その未来をダメにするのは

組織や業界にとって「未来」を担うのは彼ら彼女らであり、彼ら彼女らが「未来」だ

その未来をダメにするのは

alu.jp

この先、私が指導者になるかはわからないし、
指導者になったときどういうスタンスで向かうかはわからない

専業の指導者ではないし、私は私の人生を優先すると思う

だからこそ、心に留めておきたい

まとめ

さよなら私のクラマーはサッカー漫画です!
さよなら私のクラマー(全14巻)を読んでね!!
前日譚のさよならフットボール(全2巻)も読んでね!!

それが指揮官の仕事だぜ

alu.jp
alu.jp

「DevOps Interview with Q&A」のメモ #DevOpsDaysTokyo 2021

DevOpsDays Tokyo 2021の一日目のKeynote「DevOps Interview with Q&A」のメモ

DevOpsDaysの創始者でありTHE DevOps HANDBOOKの著者でもあるPatrickAlexがインタビューする形式

メモ

DevOpsの名前の由来

  • DevOpsという名前は「DevOpsDays」のイベント名に由来。
  • 「DevOps」という名前は考えていなかった
  • カンファレンス後に「DevOps」という名前がついた。業界の言葉になると思ってなかった。

DevOpsの定義

  • 正式な定義はない。意図的にDevOpsの定義をしなかった
  • いろんな人に定義してもらいたいと思っていたから
  • 定義を紙(?)にすると誤解されてしまう
  • 定義を閉じ込めたくなかった
  • 常に新しいアイディアに対して扉を開き、進化するスペースを持つようにしたかった

Patrickの定義:サイロ間の摩擦を取り除くこと(reduce friction)

定義はしたくないと言った上で、10年以上活動してきた中で見えてきたPatrick個人の中にある定義を教えてくれた

  • どうやってサイロを取り除くか
  • どのようにサイロ間の橋渡しをするか
  • どのテクノロジーを使っているかではなく、ギャップを埋めることがDevOps
  • 例えば、DevとOpsの間でうまくいっていても人事の採用基準があっていないならギャップがある
  • パイプラインが完璧であっても、ビジネスの成功は約束されていない
  • 最近は、文化の部分を強調するようになった
    • でも、テクノロジーの話もする
    • 「テクノロジーによって摩擦を解決する」方向で話す
    • DevOpsDaysは、午前中はソーシャルトーク(コラボレーションやテクノロジーがギャップをどう埋めるのか)にしている
    • テクニカルな話はブレイクの後にする
  • 元々の意図が失われる時がある
    • 「DevOps=自動化」と結びつけられている時がある
      • 元々の意図はそこではなかった
    • アジャイルスクラムになってしまった
    • ITILがチケットになってしまった
    • 言葉として「DevOps is dead」という人もいる
    • NoOpsという人もいる
  • DevOpsのアイディアというのはサイロを結ぶもの

その他

  • パラドクス(矛盾)
    • 自動化の理由を忘れてしまった。
    • セキュアだと感じれば感じるほど、十分だと安心してセキュリティのバジェットを確保できない
    • カスタマーセントリック
      • お客様にフォーカスする
      • スタートアップSaaSはそうして始まった
      • やがて、たくさんお金を払ってくれるお客様にフォーカスしてしまう
      • それはカスタマーセントリックなのか?
  • Continuous Learning
    • 時間をかけて自分のバイアスを変更する
    • ラーニングパス(学びの道筋)を文脈の中で醸成していく
  • なぜやっているのか?他の人がやっているから?
    • CICDシステムがうまく機能しているとしましょう
      • 一日エンジニアがそこにいなかったら?
      • 一週間は?なんとかなるでしょう
      • 二週間は?不安になってきますよね
    • 人が何をすべきか。どうしてやっているか
      • 「どうしてやっているか」のWhyの部分を説明できれば、CICDシステムがなくてもできる
  • マイクロサービス
    • マイクロサービスが出てきたときに開発者の多くはワクワクした
    • オペレーションの人も限定的にデプロイすればいい
    • 開発者はFunctionだけに集中するようになって
    • 全体の複雑さはオペレーションが理解することになった
    • 複雑さをどこか別のところにシフトしているだけ

Q&A 1

DevOpsDaysの10周年のオーガナイザーミーティングに参加して感動した。
隣に座ったジュネーヴ(スイス)のオーガナイザーに
「どういう人がジュネーヴのDevOpsが来るんですか?」と聞いたら
「スイスだから、銀行、病院、ジュネーヴだから、時計が多いかな」

日本では、システムインテグレーターが多い。時計メーカーはみるけど、銀行はあまりみない、病院はみたことがない。
わからない人への説明役ではなく、エンジニアリングに集中させてあげたいと考えているけど、アドバイスがあればください

  • DevOpsDaysは、地域のローカルなコミュニティと繋がって宣伝している
  • 開発セントリック、ビジネスセントリックとイベントによって方向性が違う
  • オーガナイザーが最初にネットワークを作って、広げていく
  • スイスでは元々オーガナイザーが金融業界だったから、そこから広がっていった
    • オーガナイザーのツテがきいている
  • 経営陣にどのように説明するのがいいのか?
    • THE PHOENIX PROJECTTHE UNICORN PROJECTのような本がある
    • 大企業のサクセスストーリーですべてがいいわけではないが、DevOpsDaysよりもビジネス的な用語が使われている
    • こういった本が有効だと思う
  • なぜコラボレーションが有効なのか?
    • 信条(belief)のレベルで話していないか自問自答してください
    • 「自動化すればコラボレーションは必要ない」と考えている人もいる
  • Damon Edwardsはビジネスの方にDevOpsの話をしている
    • あるCEOの方は「おもしろいね。でも、商品の値段を数セントあげれば同じ改善ができるよ」と言った。ということもあるので過信はできない。
  • DevOpsというのは、常に話しあってより良い仕事をするためのもの
  • モブプロ
    • 7人が同じところで問題解決することで、効率的じゃないかという人もいる
    • これは信条の問題で、コラボレーションをすることによって、より効率的になると私は考えている
  • 昨今のソフトウェアは、機械的にAをやってBをやってCをやってとすればいいという世界ではない
    • 試行錯誤してみつけていく
    • その答えがコラボレーションだと思っている

Q&A 2

聞き逃した!

Q&A 3

本を読まない。勉強をしない。
そういう人たちにGracefulにどうDevOpsを広めるか?
1歩はできると思うけど、3歩くらい踏み出すためのポイントはありますか?

  • 関心がないけど、どう説得すればいいか?
    • 彼らがペインを感じていないか、あなたが相手のペインを感じられていない
    • 自分たちで問題があるということを気づくことが重要
    • そしたら、アドバイスをすることができる
    • 私から問題を説明することはできない。説明しても聞く耳を持たない。
    • まずは、じっくり話を聞いてください
      • 「あなたはどういう問題を抱えていますか?どうやってサポートできますか?」と聞いてください
      • DevOpsという言葉は使わない
    • 信頼関係を作る
    • どういった問題を抱えているのか理解する
    • アドバイスは、いい質問をすること
    • 「どういう問題があって、私からはどういう価値を提供できますか?」

Slide

事前の打ち合わせスライドらしい

参考

DevOpsの歴史に関して参考になりそうな資料

newrelic.com

www.ryuzee.com

気が付いたらはじまって、気が付いたらおわってた。 #RSGT2021

時間が経ってしまったけど、RSGT2021のことをつらつらと書く。

f:id:kobase16:20210110230151p:plain

感想

  • ボランティアスタッフ(当日スタッフ)として参加
    • 2019年末からボランティアスタッフになることを目標にしていて、ようやくなれた。
    • 時勢状況もあって不安はあったけど、ずっと抱えている気持ちを優先した。
    • あまりうまく貢献できた気はせず、反省は多い。次にまたできるなら、うまくやりたい。
    • 実行委員や他のスタッフの方の考え方や動きなどからたくさんの学びを得た。私にとってはとても良い体験ができたと思う。あと、ナチュラルに受け入れてくれて、初スタッフでも不安は少なかった。感謝しかない。
    • ギャザリングを別の視点でみることができた。
      • 改めてRSGTをみると「参加者が作り上げているんだなー」と感じた。顕著な例は廊下が誕生していたり。
    • 前日、1日目は余裕がなかった。2日目からは余裕が出てきた。余裕ですぎて力を抜きすぎたかも。
    • 来年もボランティアスタッフやってみたい。
      • できれば、ボランティアスタッフで業務参加してみたいけど、まだ難しいかも?
  • 会場内にいてリラックスしている自分を感じた。「あ、RSGTに慣れた」と思った。
    • 場にいることに対しての緊張がなかった。(どちらかというと気が抜けてた)
    • 人が少なかったからかもしれないけど、4回目にしてようやく慣れた。
  • ノートPCが故障していたので、持ってなかった
    • 今年はノートPCを持たずに参加した。ハイブリットを楽しむには、ノートPCは大切。
      • OSS用にはマイクとイヤホン、スピーカーもあるといいかも。
    • ノートPCがなかったからTwitter実況は諦めた。
    • iPadはあったから、Keynoteの内容だけは手で書き取ることにした。初めてかも。
      • 野中先生の講演は、書かずに全身で聞いたほうが良かったかも。
  • ぎゃざりんぐ
    • オンラインで出会ったりTwitterで知ってくれた方とはじめましてをして、オフ会みたいだなーと思った。
    • ふらふら歩いて、廊下に写り込んだり、公開収録に混ざってたりした。
    • RSGTをきっかけに本を読む会を始めた。
      • 約一ヶ月も続いてる。
      • ペアってすごい
      • うまくいえないけど、スクラムっぽさを感じる。貴重な体験してる。

昨年*1に比べて、全く違う体験をした。
今年は、日常とシームレス。気が付いたらはじまって、気が付いたらおわってた。
おわりの境目が正直よくわからない。まだおわってないのかもしれない。

今年も不思議な体験ができた。みなさん、ありがとうございます。
来年もたのしみ。

講演メモ

Day1 Keynote

Day2 Keynote

Day3 Closing Keynote

*1:ギャザリングハイにはなって頭が飛んでた

JSTQB ALTAメモ

ALTTAを受験したメモです。
書いた時点で合否は不明ですが、短期間の独学では限界ありました。
いろいろ教えてくれた皆さん、ありがとうございました。

当日メモ

  • 時間がなかった。
    • 3時間(180分)で60分、1問あたり3分かけられる計算。
    • 長文問題が多いので、ゆっくり読んでるとぎりぎりまでかかった。残り十分の時点で残り3問。その時点の解答をマークシートに書き写すのに5分、残りの5分で斜め読みしながら最後まで解答した。
    • 解いても解いても説いても終わらない。
  • すいみんぶそくで、眠かった。長文読んでいられない。
    • 前日寝付きが悪かったのと、それでも寝坊しないように早起きしたから、熟睡できたの3時間くらいだった。つらい
    • いつもなら直前まで暗記してるんだけど、ほとんど目をつぶってぼーっとしてた。
  • むずかしい!けどたのしい!
    • 問題は解きごたえがある!楽しい!
      • こういう試験問題はひさびさ
    • 最近の時勢を反映した題材が多く、「おっ」と思うものが多かった。
    • 長文まじでむずい。サンプル問題を基本、さらにその上の応用レベルみたいな問題がぽんぽんでる。このレベルの内容の問題集ないものか。
  • 自信はない。どーだろー?結構間違えてると思うからわからない。
    • 冷静に考えると、私はTTA(テクニカルテストアナリスト)という役割がどういうものかを詳しく知りたいだけなのに、何故TAの試験受けてるんだ。
  • FLと会場違うと思わなかった。ぎりぎりに行ってたら遅刻してたかも。

勉強メモ

私にはシラバス読むの無理。諦めた。まったく頭に入ってこない。
過去問題集とかもないから、対策がむずかしい。
合否がわからない状態であるから、評価はしにくいが役に立ったことやそうでもないことをメモしておく

シラバス

問題を読んで解説見るくらいの使い方をした。
直前に思いついてできなかったけど、学習目標(TA-1.2.1みたいなやつ)に書かれている内容が問題に出て答えられそうか?という確認をすると良かったかも。

試験でTMとTAとTTAの違いを意識するのは大切。だけど、このシラバスだけ読んでも正直混ざる。

AL試験過去問題解説セミナーTA

AL試験過去問題解説セミナーTAの動画と資料。

質は一番だったと思う。量は3問分だけ。

試験に出ないJSTQB ALTA

一番勉強になったかも。
togetter.com
akiyamaさんの解説がとてもわかりやすい。

模擬問題

他に良さそうなのなかった。量と質を解きたかった。

ISTQB(英語)のサンプル問題

https://www.istqb.org/certification-path-root/advanced-level/advanced-level-test-analyst.htmlにあるサンプル問題
2012バージョンと2019バージョンがある。DeepLで日本語訳しながらなんとか読める。
試験問題がどんな感じがつかめる。基本レベルを浅く広くの印象。
ただ、本番は長いし、文章問題が圧倒的に多かった。あと応用レベルが多い。

非公式問題集

技術同人誌
英語のサンプル問題と同じくらいレベル感の日本語の問題集。
日本語だし、最初にやるならこれかなーって感じする。
紙の初版だったからか、けっこう誤植が気になった。
【PDF】JSTQB Advanced Level テストアナリスト問題集 - JSTQB Advanced Level 非公式問題集 - BOOTH

ASTERセミナー標準テキスト

ASTERセミナー標準テキストで概要とインデックスを抑えた。
内容はFL向けではあるが、シラバスを読むことを諦めた私にとって、全体像として何があるかを把握するためには、良かった。
TAには関係あるなーないなーと確認しながら読んだ。

ソフトウェアテスト技法練習帳

長めの文章問題を読んで解く練習になった。
内容は基本レベルかなあ。基本を丁寧には抑えられるけど、これ解いただけだと試験には歯が立たなかったと思う。なぜなら、他の技法がたくさんでる+応用レベルがたくさんでる。

技法とかなんとか

技法の意味がわからなすぎたけど、助かったもの

神の啓示を受けてakiyama924さんの記事はひらすら読んだ。

クラシフィケーションツリー

AL過去問セミナーで学んだ。

直交表

note.com

キーワード駆動

しーちきさんに教えてもらった!!

ペアワイズのオールペア

これだけは丸暗記

3因子4水準は16、4因子4水準は16以上
3因子2水準は4

状態遷移

note.com

期待結果と事後条件

www.kzsuzuki.com

エラー・欠陥・故障

note.com

まとめ系記事

最初のほうに読んでおくとまる

最初にあーこういうのなのねって掴んだり、こういう資料あるんだってのを知るのに良かった。
tunamagro58795.hateblo.jp

私にはシラバスを読めなかったので、さらっと読めて助かった。
mhlyc.hatenablog.com

「なんでラグビーのスクラムなの?」とずっと思ってた

アジャイルの文脈にでてくる「スクラム
名前の由来は、スポーツのラグビースクラム

私は、ずっと疑問に思ってた。
「なんでラグビーなの?」
「なんでラグビースクラムなの?」
野球じゃないのはなんとなくわかるけど、サッカーやバスケじゃなくて、なんでラグビー

……と思っていたアレコレを書くつもりが、私にまとめる力がなかった。
論理的に繋がってない部分やわかりにくい部分もあるが、時間もないので諦めた。
内容も自信はないので、是非フィードバックください。*1

スクラムの名前の由来

Scrum AllianceのDefinition of Scrumを見ると、スクラムの名前の由来について記述がある。

The term Scrum comes from a 1986 Harvard Business Review article in which authors Hirotaka Takeuchi and Ikujiro Nonaka made an analogy comparing high-performing, cross-functional teams to the scrum formation used by rugby teams.

雑訳

スクラムという言葉は、1986年のハーバード・ビジネス・レビューの論文に由来しています。この論文では、著者の竹内弘高と野中郁次郎が、ラグビーチームで使用されているスクラムのフォーメーションに、ハイパフォーマンスでクロスファンクショナルなチームを例えています。

スクラム」という言葉は、日本人の竹内弘高氏と野中郁次郎氏が書いた論文『The New New Product Development Game』に由来する。
この論文に影響を得て、スクラムが誕生した。
つまり、影響を受けた論文にあやかって、「スクラム」という名前を名付けたようだ。

Core Scrum勝手に注釈付き参考文献 - スクラムガイド日本語版に更に詳しい記載がある。

論文以外にも、ジェフ・サザーランド氏のパイロット経験や組織パターン*2など様々なものに影響を受けてスクラムは生まれた様子。
組織パターンの拡張としてのスクラム*3が発表されたこともあった。

アジャイルとリーンの図*4

The New New Product Development Game

スクラムの言葉の由来となった論文「The New New Product Development Game

1986年1月に「ハーバード・ビジネス・レビュー」に掲載。
著者は竹内弘高氏と野中郁次郎氏。
タイトル「The New New Product Development Game」は、日本語に訳すと『新しい"新製品開発"ゲーム』。
日本とアメリカの企業*5の製造業の新製品開発を調査・分析し、共通的に見られた新しいアプローチについて論じている。

ラグビーアプローチと「Moving the Scrum Downfield」

従来型のシーケンシャルな方法を「リレーアプローチ」、新しい全体論的な方法を「ラグビーアプローチ」と称している。
ラグビーアプローチに共通した6つの特徴を「Moving the Scrum Downfield」と名付けている。
6つの特徴は、パズルのピースのようなもので、全体が組み合わさることで初めて、スピードと柔軟性をもたらすそうだ。

Moving the Scrum Downfield
1. Built-in instability
2. Self-organizing project teams
3. Overlapping development phases
4. “Multilearning”
5. Subtle control
6. Organizational transfer of learning

内容についてはスクラムの原典を読み解く(1):An Agile Way:オルタナティブ・ブログスクラムの元になった資料 - [ハーバードビジネスレビュー] New New Product Development Game - kawaguti’s diaryが詳しい。

*6

野中郁次郎氏と竹内弘高氏の著書は未読であるため、読んでみたい。

知識創造企業(新装版)

知識創造企業(新装版)

サシミ

f:id:kobase16:20210104204023p:plain*7
スクラム関連の話題で時々耳にする「サシミ(Sashimi)」もこの論文で登場する。
リレーとラグビーの間の各工程のはじめとおわりが重なったアプローチをサシミと呼んでいる。

ときどき見かけるこういう図。*8
f:id:kobase16:20210104204121j:plain

トヨタとの関係性

ちなみに、本筋からは逸れるが、調査対象の企業にはトヨタはない。

TPS(トヨタ生産方式):生産工程、つまり、工場で作る段階の方式。リーンの源流。
TPD(トヨタ流製品開発):生産工程より前の製品開発の企画や設計(?)

2020年版のスクラムガイドで、「リーン思考」との関係性が追加された*9が、それはこの論文ではなく別の影響によるもののはず。

スクラムの名前の由来?

論文の中で、スクラム(Scrum)という単語は「Moving the Scrum Downfield」の一箇所だけに登場する。一箇所しか無いため、ここから「スクラム」という名前を取ったのは間違いなさそうだ。

しかし、論文を読んでも
「なんでラグビーなの?」
「なんでラグビースクラムなの?」
という疑問は、解消できなかった。
「サッカーやバスケでいいんじゃないの?」と思ったままだった。

そこで、ラグビーを知ることにした。

なんでラグビー

私は、ラグビーとアメフト*10の違いもよくわかっていない。@sorano_tarouさんにはに教えてもらったり(感謝!)、Webで調べたりした。

そもそも、ラグビーなのは、ただの偶然かもしれない。

歴史

サッカー、ラグビー、アメフトの源流は同じ。
「現代サッカー(フットボール)になる前の原始フットボール」の試合中にボールを持って走り出した選手がいた。イギリス(イングランド)のラグビー校で行われていた試合であったことに由来して「ラグビー」(諸説あり)。*15
更に、ラグビーから分岐して、アメリカンフットボールが生まれた。*16

アメフトとラグビーの違い

ラグビーとアメフトは、似ているイメージがあったが、調べてみるとゲーム性(競技性)が異なるスポーツだと個人的には感じた。サッカーとラグビーのほうが似ていると思う。
(やったことないから不安だけど)

楕円形のボール、手で持つこと、ゴールの方法、タックルなどは共通点は多いが、違う部分も多い。

ラグビー アメフト
イギリス発祥 アメリカ発祥
15人 11人
ボールは白 ボールは茶色
試合時間:40分✕2 試合時間:15分✕4
トライ タッチダウン
前にパスができない 一度だけなら前にパスができる
ボールを持った選手にのみタックルOK 誰にタックルしてもOK
革製のヘッドギアのみ、付けなくてもOK ヘルメット、ショルダーパッドなど防具必須
サッカーやバスケのように攻守交替はない 野球のように攻守交替がある*17

ちなみに、ラグビーにはスクラムがあるが、アメフトにはない。*18

ラグビーの特徴

ラグビー独自の特徴という意味では、こういうところだろうか?

One for all, All for one

特に「One for all, All for one」を調べてみると、かなり興味深い。
元々はデュマの「三銃士」が起源*20として、ラグビーでも使われるようになったらしい。
「One for all, All for one」を日本語にすると「みんなはひとりのため、ひとりはみんなのために」
……だと思っていたのだが、どうやら違うらしい。

元日本代表監督の平尾誠二氏よると
「みんなはひとりのために、みんなはひとつの目的(勝利)のために」*21*22
という意味(日本語訳)のようだ。

また、五郎丸ポーズで有名な[五郎丸選手のブログには、こうある。

「自分の勝利はみんなの勝利。みんなの幸せが自分の幸せ。」
こんなふうに思えるようになったら、素敵な大人になっていけると思いませんか?
それぞれの個性を活かし、みんなでひとつの目標に向かって頑張るこのスポーツ、自分を大きく成長させてくれるラグビーに、これを機に少しでも興味を持ってもらえたら嬉しいです。


「みんなでひとつの目的(勝利)のために」や「みんなでひとつの目標に向かって頑張る」は、(アジャイルの)Scrumや「The New New Product Development Game」が目指すイメージに近いと、個人的には思った。

ラグビースクラム

ラグビースクラムは、ボールを前に落とす(ノックオン)、前にパスする(スローフォワード)などの反則行為で中断した場合の試合再開のセットプレー。
スクラムに参加するのは、フォワードと言われるポジションの8人の選手。両チームのフォワードがボールの取り合いを行う。*23
スクラムは、肩ではなくて、腰で組む(らしい)。

ちなみに、2019年のワールドカップの日本代表のスクラムは新しい戦術を取り入れていたらしい。

語源

skirmish(小競り合い)

スクリメージ(scrimmage、小競り合い)

スクラメージ (scrummage)を短縮して

スクラム

語源で見ると、とても物騒。

仮説「ボールを前にパスできない」から

サッカーにもアメフトにもない*24ラグビーの特徴として、
「ボールを前にパスをできない」がある。

  • ラグビーはボールが価値。
  • ボール(を持った選手が)を常に先頭とする。
  • 先頭を追い抜いてはいけないため、前にパスするのはNG。(「スロウフォワード」という反則になる)

ということらしい。*25

その目線で、「The New New Product Development Game」を読むと、ある一文に目がとまった。

a holistic or “rugby” approach—where a team tries to go the distance as a unit, passing the ball back and forth—

雑訳

チームが一体となってボールを前後にパスしながら距離を移動する「ラグビー」のような全体論的なアプローチ

言葉で言い表すのは難しいのだが、
前にパスができないから「ボールを持った先頭の選手が横や後ろの選手にパスしながら」「チームとしては、ゴールに向かって前に動き続ける」動きをする。
その動きが非線形的でジグザグな「チームが一体となってボールを前後にパスしながら距離を移動する」動きになるのでは?という仮説を思い至った。
イメージはScrum Approachの図に近いかも。

これはアメフトにはない動きのはず。
サッカーではできるが、あくまで数ある戦術のひとつになるはず。*26
基本的な戦術で、ボールとチームがこの起動を描くのは、ラグボーだけなんじゃないか?*27

あくまでラグビー素人による仮説に過ぎないが、
「なんでラグビーなの?」の答えとして「ボールを前にパスできない」という仮説を考えてみた。

しかし、「ラグビースクラム」の理由は、まだ謎のまま。
何故「Moving the Scrum Downfield」なのか?
例えば「Moving the Rugby Downfield」でも良いように思えるのだが、「Scrum」にしたは意味はあるんだろうか?

なんでスクラム

野中先生と共感

少し、話は変わる。
2019年に開催されたScrum Interaction 2019で野中先生の「Humanizing Innovation -共感の経営-」という講演があった。

講演の内容の一部を書く。*28

  • 同感と共感は異なるもの
    • 同感(Sympathy)は、主観が残っている
    • 共感(Empathy)は、他人になりきる
  • SECIモデル
    • SECIモデルは、共感(共同化)からはじまる
    • はじめに共感ありき、そこからコンセプトにつなげる
    • 知というものは、個人・単独で生まれてくるものではない
    • 対話、共感から生まれてくる
    • 個人と個人の共感、から、グループの対話。個人→集団→組織。
    • 絶えず対話を通じて共感のベースがないと、イノベーションは生まれない

人と人のつながり、共感*29*30、そこから生まれる創造性を大切にしているのだと、個人的に感じた。

野中先生がジェフ・サザーランドに「合宿しなさい!」と言ったエピソード*31も印象的。

共感経営 「物語り戦略」で輝く現場

共感経営 「物語り戦略」で輝く現場

Overlapping People

そして、Regional Scrum Gathering Tokyo 2020のJames Coplien氏の講演で、興味深い話があった。
講演自体は「A Scrum Book」についての内容。*32

動画のこの辺り。
www.youtube.com
すごく意訳すると
「工程が重なり合うのは、サシミ。では、人が重なり合うのは?」と言っている。
その答えは「スクラム*33

流石に冗談やこじつけだとは思うのだが、
「人と人との重なり合い」は、人の繋がりや共感を大切にする野中先生の講演内容とも共通点を感じ、違和感はなかった。しっくりくる。
人と人の関係を大事にしているからこそ「スクラム」だったらおもしろい話である。


……結局「なんでラグビースクラムなの?」の答えは、わからなかった。
現実的には、ラグビーの代名詞としての「スクラム」や比喩表現の「一致団結=スクラム」説の可能性が高そうか?

まとめ

偶然か必然か

「なんでラグビーなの?」
「なんでラグビースクラムなの?」
この疑問が解けたかというと、そうではない。

しかし、私のなかでずっと思っていた疑問が、一旦落ち着き、あまり気にならなくなった。

私の個人の感想としては、サッカーやバスケのほうがわかりやすいと思うことは変わらない。ハイキュー!!*34が流行ってるし、バレーボールもいい。
でも……ラグビーも十分にハマる。そう思えるようになった。

偶然か必然か。*35
それはわからないが「ラグビースクラム」であることは違いない。

この話のオチ

前述のScrum Interaction 2019Scrum Interaction 2019での野中先生の講演メモを見返していると、衝撃の発言を発見した(?)
ラグビーって言ったのは偶然」

偶然かよ!!*36

明日から開催のRSGT2021の平鍋さんのセッション*37には注目したい。
そして、クロージングキーノートは野中先生!

ラグビースクラムになった理由も聞けるかも?

*1:スクラムラグビーもサッカーもアメフトもやったことがない素人が、自分の疑問を解消するために調べた小学生の夏休みの自由研究レベルです。あくまで現時点での私の理解です。歴史詳しくないし、本人に聞いたわけでもないし、自信はありません。

*2:おそらく書籍の「組織パターン」の前身 https://www.amazon.co.jp/dp/B00G9QJ1ZO

*3:http://jeffsutherland.org/scrum/scrum_plop.pdf 日本語版:https://web.archive.org/web/20160304123321/https://www.metabolics.co.jp/XP/Scrum/Scrum.html

*4:https://kawaguti.hateblo.jp/entry/20130217/1361047033

*5:富士ゼロックスCanon、ホンダ、NECEpson、Brother、3M、ゼロックスなど

*6:2021年に第二版が出版予定

*7:@pineapplecandyさんに頂いたお刺身の写真

*8:https://www.slideshare.net/hiranabe/nonaka-scrum-the-new-new-product-development-game-seci-model-the-us-marin-and-fractal-organization/13

*9:https://scrumguide-ja.kdmsnr.com/#%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%81%AE%E7%90%86%E8%AB%96

*10:アメフトを知るために「アイシールド21」を読んだ

*11:https://ja.wikipedia.org/wiki/%E9%87%8E%E4%B8%AD%E9%83%81%E6%AC%A1%E9%83%8E

*12:https://dictionary.goo.ne.jp/word/%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0/

*13:フットボールのほうが表現正しそうだけど、わかりやすさ優先でサッカーとする

*14:ラグビーユニオンとラグビーリーグの2種類あるらしい。ここで説明するラグビーは「ラグビーユニオン」のはず?

*15:https://ja.wikipedia.org/wiki/%E3%83%A9%E3%82%B0%E3%83%93%E3%83%BC

*16:https://ja.wikipedia.org/wiki/%E3%83%95%E3%83%83%E3%83%88%E3%83%9C%E3%83%BC%E3%83%AB#%E3%83%95%E3%83%83%E3%83%88%E3%83%9C%E3%83%BC%E3%83%AB%E3%81%AE%E5%88%86%E5%8C%96

*17:例外はある

*18:アメフトには、スクラムから派生したスクリメージがあるが異なる性質のものだと思う

*19:襟付きのシャツなのは、試合後のパーティーに参加するためだったらしい

*20:諸説あるようだ https://www.rugby-worldcup-j.com/2019rugby-worldcup-source

*21:https://tokyo-futsaler.blog/archives/20190630-rugby-proverb.html

*22:https://note.com/ss_morioka/n/n8d4e9222f517

*23:詳しくは https://ja.wikipedia.org/wiki/%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0_(%E3%83%A9%E3%82%B0%E3%83%93%E3%83%BC)#%E3%83%A9%E3%82%B0%E3%83%93%E3%83%BC%E3%83%A6%E3%83%8B%E3%82%AA%E3%83%B3

*24:と言い切るには、アメフトに関しては微妙かも

*25:要出典

*26:トライアングルや5レーンは近いかも

*27:キックはあるんだけど

*28:講演メモからの起こし https://kobase16.hatenablog.com/entry/2019/11/09/011305

*29:日本語の「共感」は複数の意味を持ってるからややこしい。ここでは、シンパシー(Sympathy)、同感、同調、同情とは異なるものと私は捉えた

*30:野中先生の言葉ではないが、私の好きな共感の説明「相手の世界に敬意を払いながら、純粋な気持ちで興味を持って相手の心に目を向ける」こと

*31:https://www.slideshare.net/hiranabe/nonaka-scrum-the-new-new-product-development-game-seci-model-the-us-marin-and-fractal-organization/57

*32:Webで見るなら http://scrumbook.org/

*33:うろ覚えだが、3人で肩を組んでスクラムを表現していた

*34: https://speakerdeck.com/kawaguti/haikyuu-and-scrummasterway

*35:「この世には偶然なんてないわ あるのは 必然だけ」なんて

*36:私の聞き違いかもしれない

*37:https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14725/nonakas-scrum-revisited