スクラムフェス札幌2022で受付をしました #scrumsapporo

スクラムフェス札幌2022で受付を担当をしました。
いわゆる当日スタッフです。

参加者のみなさんには、検温消毒や(入場証代わりの)ネックストラップの着用にご協力頂き、誠にありがとうございました。

どうしてやったか?

スクラムフェス新潟で一緒に実行員をした@izumii19から、
「受付周りをお願いしたい」 と言われたので「ぜひー」と言って、受付をすることになりました。
私は、スクラムフェス新潟で当日の受付を担当していたので、その経験を評価(?)してもらったのだと思います。


他にも、私の中に何かあるかなと改めて考えると、いくつか貢献したい理由が私の中にありました。

  • 札幌(という土地)に個人的に少し縁がある。
  • アジャイル札幌のみなさんの熱や想いをいろんな機会に感じていた。
  • 現地開催の今年こそはプロポーザルを提出するぞ!と意気込んで迷走しまくった結果、提出したのに自分でクローズしたのを後悔していた。

なにをしたか?

ツール類や受付方法は、スクラムフェス新潟と同じ方式だったので、
事前に準備が必要なことをだけ確認して、あとは当日にその場で合わせることにしました。

現地に行ってみると、
現地のスタッフが優秀すぎたので、めちゃくちゃ楽でした。
あとは、受付付近にいて、その場で何か起きたら何かするくらいでした。

スクラムフェス札幌は、現地開催は初めてで、スタッフの人数も多くはありませんでした。
コアスタッフであるアジャイル札幌のみなさんが他のことに集中できるように
認知負荷を下げられていたなら、うまくできたのかなと思います。

DIY Done

ネットワーキングパーティの場を借りて、やまもとさんと一緒に@matsukurouの誕生日のお祝いをDIYしました。自己満足です。

計画していたわけではなく、その場の思いつきでした。
お祝いしたかったのでしました。
喜んでくれていたらいいな。

でも、参加者の皆さんに対して、唐突感や内輪感が出てしまっていたと思います。
トークも下手くそでした。上手い人にお願いすればよかった。

宣伝:@matsukurouが実行委員のスクラムフェス福岡2023は2022年3月に開催予定です!

ぎゃざった

オンラインでは知ってるけど、オフラインで会うのは「はじめまして!」な方と何人もお会いすることができました。
特に@snoozer05@kappa4に感謝を言えました。ようやく言えた。
おとながこどもに学べることは多い。
他にもたくさん!

価値観が変わった

せっかくなので、北海道グルメの話。
🍣を食べました。おいしかったです。
私は、貝類や内臓系が苦手なのですが、ホタテや白子がおいしくておいしくて、感動しました。価値観が強制アップデートしました。
他にもいろいろおいしかったです。

ありがとうございました!!

書き尽くせないことがたくさんありましたが、一旦これだけ。

アジャイル札幌のみなさんのホスピタリティや会場の熱量や参加者の盛り上がりや想いを感じた数日間でした!
ありがとうございました!!

したっけー。


*1

*1:各地のパワーを少しずつもらって受付をしました

試験とか認定とか

試験や認定みたいなものを受験することはあるのだけれど、いつも忘れてしまうのでメモ。
「資格はただの飾りですよ」という言葉は、いつも心の中に留めている。

2022年12月時点

今後、頑張りたいもの

  • エンベデッドシステムスペシャリスト試験
  • ISTQB(JSTQB) ALTTA
  • Certified Agile Leadership (CAL2)

スクラムフェス新潟2022でした #scrumniigata


スクラムフェス新潟2022に参加しました。
www.scrumfestniigata.org
私は実行委員という立場の参加で関わりました。当日はだいたい受付の人でした。

私はほとんどセッションに参加しておらず、キーノートの内容もわからない状態です。それでも、謎の高揚感を感じる私がいました。フェスの熱気が伝搬したのかもしれません。
これがじゅんぺーさんが見たかった景色の一端なのかな。
私が実行委員長のじゅんぺーさんに(一方的に)出会ったのは、Agile Testing Nightだったと記憶しています。
Agile Testing Days2019の話をしていて、その時から何か惹かれるものがあったのかもしれませんしれません。いや、これは大袈裟かも。

とにかく、やりたいって言ってやってみせて、じゅんぺーさん、あんたすげーよ。
wingarc1st-spqi.connpass.com
イベントを運営する側の視点としては、私が主に関わった受付周り含め改善したい点はたくさん思い浮かびます。オンサイトってたいへん。ハイブリットむずかしい。
でも、そういうことを差し引いても、圧倒的にプラスだったんじゃないかと感じました。
会全体として本当にそうであったかは、参加者がどう感じたかだと思うので私にはわからないのですが、多くの参加者が楽しんでくれていればいいなと思います。
もうちょっと参加者の顔を見ておけばよかった。帰り際の参加者は笑顔だっただろうか?

きっかけはなんだったかよくわからないのですが、
アジャイルとテストのコミュティを繋げたいと、数年前から私は思っていました。
新潟でというのは全く想像していなかったけれど、そういうひとつの機会に携われたことを光栄に思います。

いわゆる開発とかインフラとかそういう人達とも次は広がっていければなーと思っています。


さいごに。
ベルギーから来てくれたダニエルをはじめ感謝をおくりたい人はたくさんいるのですが、私個人からだとするなら、新潟の二人と葛飾の一人に。

霜村さん、ありがとう。霜村さんが受け付けを手伝ってくれたおかげで、私は他に目を配る余裕ができました。
スズキさん、ありがとう。NIINOという素敵な場所でイベントを行うため必要なことをスズキさんが文字通り走りまわってやってくれていたと思います。
おおひらさん、ありがとう。オンライン盛り上げの功労者は間違いなくおおひらさんだと思います。


いろいろなことを次につなげたいなー。

#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