RSGT2024にボランティアスタッフで参加してきた

はじめに

2024年1月10日〜12日で開催されたRegional Scrum Gathering Tokyo 2024にボランティアスタッフとして参加してきたので、いま心に残っていることを記す。

ストラップの変遷


Fearless Changeに出てくる"トークン"として飾っているRSGTのストラップ。初年度はオンライン参加だったので名札なし。2年目のストラップに巻いてある紐はAkiさんのワークショップで使った紐。こうして並べてみると、毎年変化があっておもしろい。特に今年は名札のサイズが大きくなったり、ストラップを止める箇所が1箇所から2箇所に変わったりしていて、変化が大きい。並べるまで気づかなかった。

Zuziと話した

SCRUMMASTER THE BOOK、アジャイルリーダーシップの著者Zuziに、思い切って話しかけた。
最近私は読書会コミュニティ*1を運営するほどには人類学に興味があるが、これはZuziがRSGT2021のキーノートで人類学に言及したことがきっかけだった。
Zuziが人類学という学問を紹介してくれたおかげで、自分がそれまで歩んできた情報工学とは違う学問領域に興味を持てたので、その感謝を述べて、サイン本をもらった。*2. 自分の発音がひどすぎて、何回言っても「Anthropology」が伝わらなかったのは悔しかった。英語で話しかけるという最初のハードルは越えられたので、今後は発音も相手に伝わる程度にはちゃんとしたい。それにしてもZuziマジでいい人だったな。

フォトブースで写真を撮ってもらった

今年からプロのカメラマンに写真を撮ってもらえるフォトブースの企画が始まったので、自分も撮ってもらった。今までSNSのアイコンに使っていた写真が、いつの間にか8年も前のものになってしまっていたので、全部更新した。

XP会読会を一緒に運営しているkuroさんと一緒に写真を撮ってもらえば良かったな〜というのが、今年の一番の後悔。来年は撮ってもらおうと心に誓った。

来年の自分への申し送り

昨年は初スタッフかつXP祭りの書籍企画枠としてのスタッフ参加*3だったので、必死で観察するだけでカンファレンスが終わってしまった感があったが、今年は2年目で、XP祭りの書籍企画もなくピュアなスタッフだったので、DAY0よりDAY1、DAY1よりDAY2、DAY2よりDAY3という意識でスタッフ業に携われた。

そして来年は今年よりもっと貢献できる自分でありたいので、ここに来年の自分への申し送りを残しておく。またこれらのノウハウは今年スタッフやる予定のRESEARCH ConferenceやXP祭りでも活かせるものがところがあるので、積極的に活かす。もちろん、無理はしないことが大前提。

DAY0

  • 荷解きをする前に、初期状態を写真に撮っておく。3日後にはその状態に戻す必要があるのだから。初期状態を写真に撮っておくことで、荷解きする人以外でも梱包ができるので、タスクの属人化を避けられる。写真を印刷してダンボールに貼り付けておいておくのも良さそう。
  • 1階の配信のテストを全員でやると良さそう。オンラインorオフライン, 日本語通訳or英語通訳, 日本語字幕or英語字幕, Zoom字幕orUDトーク字幕といった組み合わせがある気がする
  • 個人のiPadとイヤホンを持っておくと、Zoomでの音声の聞こえ方や画角が簡単に確認できて良い。

DAY1-2

  • セッションの直前、登壇者に以下を確認しておくとよい。
    • 時間はフルフル使う見込みか、余る見込みか。余る場合、質疑応答を入れるか。
    • 残り時間の表示があった方がいいか。あった方がいい場合は、どこで表示するかを伝える。
  • 呼び込みをするときに「次はXXさんです、大きな拍手をお願いします。」というと、参加者の拍手からセッションが始まるので良い。これは登壇者だけではなくて、参加者からしてみても、セッションに気持ちを入れるスイッチになるような気がする。
  • 来年も初日にペンを配るのであれば、DAY3でペン使うので持ってきてもらうようアナウンスすると良い

DAY3

  • 最後のスタッフふりかえり、できる範囲でメモとって共有できると良き

おわりに

RSGT20204に携わった全ての皆様に感謝を!今年一年を頑張る気力をもらえました!来年の年明け、また皆さんと笑ってお話ができることを楽しみにしています。

*1:みんなで始める人類学読書会というコミュニティです。隔週水曜21:00からやっているので、気軽に遊びにきてください。

*2:この時名前を聞かれて苗字を答えてしまったため、サインの宛名が"To Yasugahira"になってしまった。こういう時はファーストネームを伝えた方が良さそうということを学んだ。

*3:その時のブログ記事はこちら:RSGT2023にボランティアスタッフで参加してきた

Women in Agile Japan Tokyo 2023に参加してきた

はじめに

2023年2月18日に開催されたWomen in Agile Japan Tokyo 2023に参加してきた。
この記事では、コミュニティへの参加のきっかけと、カンファレンスのふりかえりにつて述べる。

コミュニティに参加したきっかけ

Women in Agileというコミュニティは、コミュニティ発足当時からその存在は認識しており、男性が参加できることも知っていたが、コミュニティ名にWomenと冠しているところから、女性のコミュニティ参加へのハードルを下げることが目的の1つなんだろうと考えて、自分は参加していなかった。
今回のカンファレンスの開催にあたり、川口さんが「日本のIT業界におけるジェンダーギャップについて考える議論に加わってほしい」とXP祭りのスタッフに声をかけてくださった際も、自分はジェンダーギャップについて議論するだけの知識を持ち合わせていないので、参加する気持ちは起きなかった。
そんな中でRSGT2023にボランティアスタッフをした時、実行委員を始めとした様々な方々のうきうきなっとうメンバ*1への配慮を見て「あ、Women In Agileだからこそ、マジョリティの立場にある自分が参加する意味があるんだ」という気づきを得て、参加者募集に手を挙げた。

基調講演

基調講演はREALsの瀬谷ルミ子さん。アジャイルコミュニティでは瀬谷さんの執筆された書籍職業は武装解除が有名なので、「武装解除の瀬谷さん」だと思っていたが、基調講演の内容は武装解除のお話ではなく、争いを予防する活動のお話だった。
講演を聞いて様々なことを感じた。

  • 「自分たちがいつかいなくなることを伝え、できることはやってもらう。」というお話があり、それを実現するための手段の1つとして、コミュニティワーカーを育成しているという話があった。その後の話を聞くと、コミュニティワーカーがREALsの理念に共感して、自分の判断で動いている様子が伝わってきて、素晴らしい組織だと思った。
  • 「テロには予兆がある。成績優秀な女学生が学校を辞めることになり、気になったコミュニティワーカーが話を聞いてみると、その裏にはテロ組織の関与があった。」というお話があり、テロ組織の関与の仕方が巧妙で驚いた。何にでも予兆があり、それを検知することが重要であること、そしてそれを検知するためには、当事者に話を聞くなど、一次情報に当たらないといけないと感じた。
  • 「社会が不安定になった時に切り捨てられる立場の女性は社会の変化に敏感。だから和平交渉に女性が含まれている方が、和平合意の内容が弱い立場を考慮した有効な内容となり、和平合意の成功率が高まる。」というお話があって、それまでの「多様性はあった方がいい」という理解から、一歩理解が深まった。

また、今回の基調講演からの学びと、最近聞いたPodcastからの学びがすごくリンクした。基調講演を聞いた方は、こちらのPodcastを聴くことをお勧めします。

spinear.com

OST前にひたすら初めましてするタイム

JKさんが企画してくださって、初対面の方といろいろお話ができた。小さな輪になって話していたとき、のりっくさんがパックマンルールを実践していて、さすがだと思った。言葉は知っていながらも実践できていない自分に気づいたので、真似したい。

OST

以下の4つのテーマに参加した。

  • 多様性プロジェクト、ハードに進める?ソフトに進める?
  • Women in Agile Japanこれからどうする?
  • セクハラから守るとは?
  • 基調講演のふりかえり

どのテーマも活発に話し合いができて良かったが、特に「多様性プロジェクト、ハードに進める?ソフトに進める?」は、話し合いをする中で、DI(ダイバーシティインクルージョン)推進とアジャイル推進の類似点に気づけたことが良かった。

  • 大きく前進のためにはトップダウンが必須
  • 理念を訴えるだけでは推進は進まず、客観的な数字を見せる必要がある
  • 透明性が重要

参加者の方に、ダイバーシティインクルージョンの理解を深めるための2冊としてWORK DESIGN多様性の科学をお薦めいただいたので、この2冊は近いうちに読みたい。
下記は「多様性プロジェクト、ハードに進める?ソフトに進める?」で書き出した付箋。

おわりに

自社においてもダイバーシティインクルージョンの取り組みは実施されていて、当然それは自分の目にも入っているはずだが、無意識にそれをスルーしてしまっていた自分に気づいた。DI推進とアジャイル推進に共通する点があると感じることができたので、その取り組みから学びを得る眼差し、自分ごとと捉える態度を持ちたい。

*1:聴覚障害のある大学生チームによる臆さない発言環境の形成」というトークをしていた筑波技術大学のチームメンバ。

RSGT2023にボランティアスタッフで参加してきた

はじめに

2023年1月11日〜13日で開催されたRegional Scrum Gathering Tokyo 2023に参加してきました。
RSGTは一昨年オンライン、去年オフラインで参加して、今年もオフラインで参加予定でしたが、XP祭り枠でのスタッフ募集があったので思い切ってそちらに申し込みました。
結果として1月10日の準備を含めた4日間参加したので、スタッフとしての感想と参加者としてのふりかえりを述べます。

スタッフとしてのふりかえり

自分なりの貢献をしたつもりではありますが、今回はカンファレンスの運営を勉強させていただいたという気持ちが強いので、この経験をXP祭りをはじめとしたカンファレンス運営に還元したいという想いが一番にあります。
何が一番勉強になったかというと、全部です笑
一人一人が強いリーダーシップを持った成熟したチームによるカンファレンス運営を、4日間もチームの一員として経験できたのです。その全てが勉強になりました。
その中でも特に印象に残ったことは、トランシーバーを使ったコミュニケーションとリアルタイムでのふりかえりスレッドです。

トランシーバーを使ったコミュニケーション

RSGTの会場はソラシティカンファレンスセンターの1Fと2F、そしてオンラインの3箇所で、スタッフもそれぞれの場所に分かれているので、全体像は誰も掴めません。
それで活躍するのがトランシーバーです。このトランシーバーは、オンラインや配信業者の方も含めた全スタッフが装着していて、困ったら迅速にやりとりができます。体験して分かったのですが、トランシーバーのおかげで全スタッフが常に繋がっていると信じられるこの安心感はものすごく心強かったです。これがRSGTの透明性か!と感動しました。この安心感があったからこそ、初スタッフの私でも判断待ちで立ちすくむことなく、自分がやるべきと判断した作業を積極的に取りにいくことができました。

リアルタイムでのふりかえりスレッド

カンファレンス中のやりとりはトランシーバーで行うのでテキストでのやりとりが少なくなるのですが、その代わりに事前に用意されたふりかえりスレッドが活発に動いていました。「思い立った時が書きどき」ということで、後になると忘れそうな細かな内容も記録されていて、鮮度のいいふりかえりスレッドだったことが印象的です。
今思うと、やりとりを全てトランシーバーに集約したことが、テキストでふりかえりを残す余力が生んでくれていたのかもしれません。

参加者としてのふりかえり

たくさんの方とお話しできて幸せだった

昨年のRSGTでお会いした方や9月の「アジャイルコーチとスクラムマスターの集い」でお会いした方と久しぶりに再開して、言葉を交わせて嬉しかったです。
またオンラインでしかコミュニケーションを取ったことがなく、お顔がわからなかった方からもお声掛けいただき、お話しすることができました。今年はアイコンとリアルが一致した方が多かったですが、これは会期中にだいみょーさんがアイコンを印刷する方法*1をツイートされていて、それが参加者の中で広がったことも一因だと思います。

私はSNSのアイコンを自分の写真にしているため、やらなくて大丈夫かな?と思って印刷はしなかったのですが、懇親会でいろいろな方とお話しさせていただくと、アイコンが写真であっても、リアルとの印象の違いはあるとのことだったので、来年は絶対印刷してネームタグに入れようと思いました。来年はこの文化がもっと広がることを願います。
あと普段聴いているPodcastのパーソナリティーの方や、過去の登壇資料を参考にさせていただいていた方にご挨拶ができて、めちゃめちゃ高まりました。

久しぶりに手話で会話ができて嬉しかった

今回のRSGTには、聴覚に障害のある筑波技大の学生が参加していて、XP祭りのブースにも遊びに来てくれていたので、少しだけ手話でおしゃべりしました。手話を使うのがかなり久しぶりだったので、単語が全然思い出せず、指文字*2混じりだったり、単語を教えてもらったりになりつつになりましたが、手話でコミュニケーションが取れて嬉しかったです。
懇親会でも手話の話題が多かった印象で、ここから何かが起こりそうな予兆を感じました。ここから、誰もが企業でアジャイルを実践できる世界に向けて、一歩一歩歩み始められると良いと感じた。

クロージングキーノートで岩瀬さんの強い決意をお裾分けしてもらった

RSGTのセッションはどれも素晴らしいセッションでしたが、最終日のクロージングキーノートが特に心に残りました。

speakerdeck.com

特に、fukabori.fm 第17回の及川さんとのエピソードを契機に、上長にかけあって人事部に異動したというところに衝撃を覚えました。
fukabori.fmは大好きで毎回聴いていますが、あのエピソードは自分にとっても印象深い回だったことを覚えています。

fukabori.fm

楽しい雰囲気だった前半からは打って変わって、後半の及川さんの語り口には熱い想いがこもっており、それを受けて「自分はどうする?」と自分に問いかけざるを得ないような回でした。パーソナリティーとして直接その声を聴いていた岩瀬さんとしても、思うところはあっただろうとは予想していましたが、そこからすぐに行動を起こしていたところに、岩瀬さんの並々ならぬ決意を感じました。*3

クロージングキーノートの後、ちょっとだけ岩瀬さんとお話しさせていただき、ますます勇気が出てきたので、来年のRSGTに向けて、また明日からの仕事を頑張ろうと決意を新たにしました。

さいごに

学びと喜びしかない4日間でした。ただ、まだ見てないセッションがたくさんあるので、もうしばらく私のRSGT2023を続けて、その後RSGT2024に向けて、自分はどうActionしていくのかを考えたいと思います。
RSGTに携わった全ての皆様、尊敬してます!

*1:「だいみょーメソッド」と心の中で勝手に呼んでいます笑

*2:単語ではなく、50音それぞれを手で表す方法。単語があるなら単語で表したほうがいいので、指文字だらけでの手話はちょっと申し訳ない気持ちになります。。。(参考:指文字(50音字一覧・数詞一覧) | NTTデータグループ - NTT DATA GROUP

*3:岩瀬さんが人事部にいることは普段のツイートからなんとなく想像できていましたが、できる人が管理部門に行くことは大企業だとよくあることなので、異動はあくまで会社の判断だったのだろうと思っていました。

「アジャイルコーチとスクラムマスターの集い」に参加してきた

はじめに

9/12-14で「アジャイルコーチとスクラムマスターの集い」に参加してきました。 www.attractor.co.jp

私は初めて参加しました。私以外にも初参加の方は何名かいましたが、全体としては2回目、3回目の参加の方が多い印象でした。
開催場所はライムリゾート箱根という箱根のめちゃめちゃ快適な合宿用施設です。 バスタ新宿からバスで1本で行けるというのも楽で良かったです。

参加の目的・背景

3日間OSTなどを活用して研鑽するというプログラムを見て「これ絶対参加しないとわからないやつだ。」と思い、申し込みました。
申し込んだ時はこの営みのことをよく分かっていなくて*1、過去の回に参加された方は参加しないものだと思い込んでいたので、申し込んだ後、過去回の写真に写っていたコーチの方々も参加されると知り、ミーハー気分で高まりました。(漫画「ミワさんなりすます」のミワさんはこんな気分なんだろうなぁと妄想しました。)
その一方で「憧れは理解から最も遠い感情だよ」と心の中で藍染惣右介が囁くので、今回コーチの方々とお話しすることで、コーチの方々がアジャイルとどう向き合ってきたのかを理解したいと考えていました。

参加した感想

参加者の皆様とOSTで色々な話を聞いたり、自分の出したテーマについて話し合ったり、散歩しながらお話ししたり、温泉入りながらお話ししたり、美味しいビールを飲みながらお話ししたりできて、最高に楽しかったです。何年経ってもこの3日間を忘れないと思います。
特に良かったのは、自分がアジャイルに携わり始める前のお話を聞けたことと、OSTでテーマを2つ出して、それについて話し合ったことなので、これらについて述べます。

アジャイル黎明期のこと

私はDXを推進するという文脈の中で2018年からアジャイル開発に携わり始めたので、それ以前のアジャイルの黎明期のことが分からなかったのですが、そのあたりを色々なコーチの方々にお伺いして、理解を深められたことが良かったです。
特に「アジャイル開発宣言」が出たときにどう感じたか?を、何名かの方にお伺いして、「共感した」や「ふわっとしたことを言っていると思ったというのが第一印象」といった、その時の感想を教えてもらえたことが良かったです。(「アジャイル開発宣言」は今だと原典として扱われていて、それがなかった時代や出た瞬間を想像できないので。)
その他にもコミュニティや研修、書籍についても色々お伺いできて、コーチの方々がどういった姿勢で仕事に臨んでいたり、コミュニティに貢献されているのかをお伺いできました。
ただまだまだ聞き足りないので、コミュニティ活動などを通して色々な方にお話をお伺いし、ゆっくり理解していきたいです。

OSTテーマ1【観察できているのか?】

テーマを出した背景

以前参加した観察力がテーマのワークショップで、人々の行き交うバス停の様子を収めた動画を見て、観察したことを書き下すというワークを実施しました。
私はSMとしてチームを観察しているつもりだったので、このワークでも成果を出せると思っていたのですが、蓋を開けてみると、[ 1 ]記述量は一番たくさん書けていた人の1/5程度、[ 2 ]多くの方が気づいていた「人々の様子を見るに、バス停の文字盤が見づらい可能性が高い」というポイントにも気づけていないという散々な結果でした。
SMはチームを観察して得た情報をインプットに次のアクションを判断するので、観察できていないポイントがあったということは、少ない情報量で次のアクションを決めていたことになり、これにより質の低い判断をしていた可能性があると感じ、怖くなりました。
そこでこのセッションでは、他のコーチの方々は何をもって観察できていると考えているのか、また観察力を鍛えるために意識していることをお伺いしたいと思いました。

書き留めた付箋たち

受け取ったアドバイスと今感じていること

まず学生時代人類学を専攻していたという石井食品の石井さんに「観察は人類学でも大きなテーマになるものだが、人は先入観で見るもの、見ないものを取捨選択しているので、そもそも全てを見るすることはできない」と大前提となるコメントをいただき、その上で「チームで見たものを持ち寄って、対話する方法もある。」とアドバイスをいただきました。
このアドバイスをいただいた時、「観察はSMの重要な役割だから、自分が高いレベルでやり遂げる必要がある」という考えに自分が囚われていたことに気づき、自分が山王戦のゴリの状態に陥っていたんだと気づきました。

おそらく現段階でオレは河田に負ける でも 湘北は負けんぞ

というやつです。自分ひとりで達成できないことがあるなら、周りの力を借りて、チームとして判断の質を上げていけばいいだけ、と気づけました。

また「観察できている/できていない、より重要なことは、観察などを通して得たインサイトを頭の中でどう構造化するか。観察もインサイトを構造化するためのインプットの1つに過ぎない」というアドバイスをいただきました。
「観察もインプットの1つに過ぎない」という点については、最近はトライアンギュレーション*2を意識して様々な人の話を聞いたり、成果物を見たりして判断をするよう心がけているところだったので、これを継続します。「インサイトの構造化」は今まで意識していなかったので、これから意識します。

OSTテーマ2【SMはチームに「プロセスより対話」をどう伝えればいい?】

テーマを出した背景

私はSMはアジャイルスクラムの価値観を理解した上で、それを示す行動を率先して行い、その背中をチームに見せることが重要だと考えて、そのようにふるまっているつもりでした。特に「プロセスやツールよりも個人と対話を」は強く意識して、DEVが最初の一歩を踏み出せないところのサポートやPOの困りごとの相談・対応には注力してきたつもりでした。
しかし自分がSMの任を外れてチームの外に出た後にチームを観察すると、「スクラムだと◯◯だから」とスクラムが都合のいい言い訳に使用されるシーンや、「これはPOの役割」「これはSMにやってほしい」「これはDEVよろしく」などセクショナリズムの兆候を示すシーンが頻繁にあることに気づきました。
私はスクラムもプロセスでしかないので、価値あるプロダクトを開発するため、チームのお互いの状況に関心を寄せた上で、自分たちに最適なプロセスを対話を通して探索してほしいと思っていましたが、そういった想いはチームに全く伝わっていなかったのです。
この経験を通して、背中を見せることでアジャイルスクラムの価値観までチームに伝えられると考えるのはSMに都合の良い幻想で、背中を見せる以外の方法で、アジャイルスクラムの価値観をチームに伝える必要があると思ったので、参加者の皆さんがこの辺りをどう意識されているかを伺いました。

書き留めた付箋たち&様子

受け取ったアドバイスと今感じていること

「現場の細かい話をすると拠り所がなくなってしまい「これはPO」みたいな結論になりがちなので、『なんでプロセスより対話が大事なんだと思う?』と問いかけたり、『逆に対話よりプロセスを大事にするとどうなるでしょう?』と問いかけて嫌なことを書き出すと良い」というアドバイスをいただきました。私は現場の細かい話からスタートをして、結果としてチームが腹落ちする結果に辿り着けないこともあったように思うので、これはぜひ実践したいと思いました。
また「背中を見せるだけだと、チームからはSMが選択しなかった行動が見えず、その判断基準が分からないので、判断基準をチームに示す必要がある。その上で、意図が伝わっているか直接メンバに確認するような営みは必要」というコメントもいただきました。このコメントをくださった方は、この3日間折を見て「何を学びましたか?」など様々な問いかけをしてくださって、「伝わっているか確認する」というコメントを背中で示してくださっていたと、今ふりかえって感じます。
スクラムはゴールではなくゲート。スクラムの先に自分たちの目指すべきスタイルがあるとチームに伝える必要がある」というコメントもいただきました。スクラムがゴールではないということは理解していたつもりですが、果たしてそれをチームに伝えて、スクラムの先にある自分たちにあったスタイルをメンバみんなで目指せていたかというと、そうではなかったので、今後はスクラムのその先を目指します。スクラムの先にゴールがあるという意識をメンバみんなで持てれば、会話は「スクラムだと◯◯だから」で止まらず、「スクラムだと◯◯だよね。これは何でだろう?自分たちはどうすべきだろう?」というところまで踏み込めると思うので。
さらに「背中を見せる行為自体は尊いことで、それをしなくなると理論だけ、口先だけの存在になってしまうので、背中を見せる行為は続けた方が良い」という励ましのコメントもいただきました。この時自分は、背中を見せる行為はプラクティスレベルを伝えるためには有効でも、価値を伝える上では有効に機能しないような気持ちになっていました。このコメントをいただいたことで、背中を見せる行為の問題ではなく、自分がまだ上手に背中を見せる行為ができていないことが問題で、そこを改善していけば良いのだと気づけて、めちゃめちゃ勇気づけられました。
この3日間ずっといい体験をさせてもらいましたが、自分の心が一番震えた瞬間を選ぶとしたらこの時だと思います。

最後にちょっと余談で、帰り道で高江洲さんとお話しさせていただいた時、2年前に参加したアジャイルマインド・インストレーション体験セミナーの話になりました。(参加レポート:アジャイルマインド・インストレーション体験セミナー参加レポート - 其未来
このセミナーの中で、高江洲さんが考案された「スクラム・ペルソナ・ロールプレイ」というワークショップを実施していたのですが、今思うと、このワークショップの内容は今の自分の困りごとにドンピシャで刺さる内容でした。
すごくいいワークショップだったと記憶しているのに、必要なタイミングで頭の引き出しから引き出せなかった理由は一つで、教わったところで止めてしまって、自分でワークショップを開かなかったからです。参加レポートの最後にこう書いているのに。。。

ぜひ組織に持って帰ってほしいということだったので、折を見て自社でもロールプレイをやってみたいと思う。

自分でやらないと身につかないと強く感じたので、このワークショップを今年中にやるとともに、OSTでいただいたアドバイスは明日からどんどん実践しようと心に決めました。

おわりに

学びの一部を書いただけですが、それでも長くなりました。それくらい濃密な3日間でした。
主催のアトラクタの方々をはじめ、集いに参加された全ての方々に感謝します。本当にありがとうございました。
最後に集合写真を貼るとそれっぽいと思うのですが、私なんと呑気に部屋の片付けをしていて、集合写真に写り損ねるという失態をおかしたので、集合写真は載せません。
集合写真に写るという忘れ物を取りに行くためにも、次回も参加したいです。

更新履歴

9/17 10:00 石井さんのお名前と「スクラムはゴールではなくゲート。」の段落を追記

*1:その後このイベントはコーチングリトリートとも呼ばれ、リトリートは「日常生活から離れてリフレッシュする時間をもち、心身ともにリセットする」という意味と知り、やっとイベントの趣旨が理解できました。

*2:複数の視点(データ、調査者、方法、理論など)を組み合わせることで、物事の理解の妥当性をより高めること

Vue.jsでブックマークツール「Quick Bookmark」を作った

はじめに

この記事はVue Advent Calendar 202120日目の記事です。
ちょこちょこ作っていたツールの開発をアドベントカレンダー駆動で加速させ、とりあえず紹介するところまで持ってきました。
この記事では前半でツール自体の紹介、後半でツールの技術面の紹介をします。

f:id:sonomirai:20211220081329p:plain
Quick Bookmark

Quick Bookmarkについて

エレベータピッチ

Quick Bookmarkの価値を、アジャイル界隈でよく使われるエレベータピッチのフォーマットでまとめました。

資料のリンクを見失って、メールやチャットを掘り返すのを何とかしたいユーザ向けの、  
Quick Bookmarkというプロダクトは、ブックマーク用のツールです。  
これはブックマークを端末内に保存し、保存したリンクを絞り込み検索できます。  
はてなブックマークやPocketといったブックマーク用のサービスとは違って、  
ブックマークを端末内に保存するので、社内ファイルサーバのパスを保存しても問題ありません。  
Proxy環境下でも利用できます。  
ブラウザのブックマーク機能と違って、絞り込み検索ができるので、ブックマークが増えた時も探しやすいです。

触ってみる

こちらからQuick Bookmarkを触ることができるので、まずは軽く触ってみてください。
ブックマークを登録できます。Quick Bookmarkは登録したブックマークを端末のlocalStorageに保存するので、ブラウザを閉じた後もブックマークは消えずに残ります。端末に保存するので、インターネット上の誰かにあなたが登録したブックマークの内容を見られてしまうこともありません。

デモ

デモ用のGIF動画を作成したのですが、はてなブログに貼れなかったので、こちらの下の方に貼り付けています。もしよければご覧ください。

Quick Bookmarkの技術面について

利用技術

Quick Bookmarkで利用している技術は以下の通りで、導入順に並べています。

利用技術 利用シーン
Vue.js 全体
vue-good-table 「ブックマーク絞り込み検索」の表で使っています。多機能の上に、自分で定義した関数を実行することもできてとにかく便利です。削除やソートはまんまvue-good-tbleの機能です。
wanakana ひらがなとカタカナが異なっていても検索ヒットさせるために利用しています。
Puppeteer 動作確認テスト用に追加して、GitHub Actionsでテストが回るよう設定しましたが、vue-router導入時に既存のテストコードが壊れてからは、直せていません。
vue-router 機能ごとにページを分割するために導入しました。
vuetify 見栄えを良くするために導入しました。

Vue.jsの良いところ

ツールを作っていて感じたVue.jsの良いところを述べます。Angular.jsやReact.jsなどの他のJSフレームワークと比べる意図はありません。
冒頭述べたように、私は普段コードを書かないのですが、そんな自分でも、欲しいものを作れてしまうのがVue.jsのすごいところだと思うので、その辺りを中心に述べます。

日本語情報が多い

2016年にAngular.jsの1系で、Quick Bookmarkとほぼ同じlocalportalというツールを作っていたのですが、その当時は分厚い本が1冊出版されているだけで、初学者が勉強するのはしんどい状況だったので、Udemyか何かで英語のレッスン動画を見ながら、Angular.jsの機能を覚えていた記憶があります。(もちろん今はAngular.jsの日本語情報もたくさんあるのでしょうが、当時は大変だった印象があります。)
Vue.jsは日本語の公式情報もあるし、基礎から学ぶ Vue.jsVue.js入門をはじめとした書籍も充実しているので、同じ機能を様々な解説・サンプルコードを見ながら学習することができ、理解がしやすかったです。

利用者が多く、コミュニティも活発

私は2018〜2019年頃に、秋葉原のWeeybleというコワーキングスペースでVue.jsの書籍の輪読会に参加して勉強することで、Vue.jsを覚えていきました。(当時の資料
この勉強会でVue.jsを勉強していなかったら、このツールは作れていなかったと思うので、この場を提供してくれた方や、Vue.jsを現場で利用してVue.js人口を増やしている方に感謝します。

プログレッシブフレームワークゆえVue.jsの技術習得と機能追加がいい感じに回る

以下は、v0.1.0時点のQuick Bookmarkの画面です。1つの画面に全機能が詰め込んであって、見た目も質素ですが、今と基本的な機能は変わりません。

f:id:sonomirai:20211219232038p:plain
v0.1.0時点のQuick Bookmark
調べたところ、Quick Bookmarkの開発を始めたのは2021年6月27日で、v0.1.0をリリースしたのは2021年7月18日だったので、作り始めて1ヶ月足らずで、最低限自分が必要な機能は実装できていました。
私のような普段コードを書いていない人間が欲しいものを1ヶ月でリリースできるというのはすごいことだと思っていて、これを実現してくれたのがVue.jsのプログレッシブフレームワークという考え方だと思っています。
もともとvue-routerやVuexで何ができるかはざっくり把握していたこともあり、自分が最低限必要とする機能を実装するのにこれらは不要と判断できたので、vue-routerやVuexの勉強はすっ飛ばして、実装に集中できました。
その後ツールを改良しようとした時に、以下の通り段階的にVue.js関連の技術を習得して、機能を追加していくことができました。

  • 1画面1機能に分割したい → vue-routerの導入
  • 見た目をもう少し綺麗にしたい → Vuetifyの導入

次はブックマーク登録をした時に「ブックマークが登録されました」とフラッシュメッセージを出したいと思っていて、その時Vuexが必要らしいので、次はVuexを勉強しようと思っています。
このように段階的に勉強をして、すぐにそれを活かした実践で活かせるので学習意欲が湧くいてくるという点も私にとってはVue.jsの良いところです。

おわりに

この記事ではQuick Bookmarkの紹介、使用しているVue.jsの技術スタックの紹介、私が思うVue.jsの良いところの紹介をしてきました。
Quick Bookmarkをご利用いただき、フィードバックをお寄せいただけると嬉しいです。よろしくお願いします。

チームのアジリティはスキルマップのどこに表れる?

はじめに

安ヶ平です。普段はSIerスクラムマスターとして働いています。
メンバのスキルを星取表の形で可視化するスキルマップ。チーム発足時のメンバのスキルの可視化、離任によるリスクの可視化、学習モチベーションの向上などを目的に作成、運用しているチームは多いのではないでしょうか?
スキルマップの運用について考えていた際、実はスキルマップにチームのアジリティ*1が表れていて、それを認識した上でスキルマップを運用することで、チームのアジリティを向上させることができるのでは?という仮説が浮かんだので、この記事で説明します。
スキルマップ自体の説明は、ryuzeeさんのブログエントリスキルマップ作成のすすめをご覧いただくのが良いと思います。

私なりのスキルマップの作り方

私はスクラムチーム発足時に、インセプションデッキ作成などと共にチームでスキルマップを作成するので、基本的にはPOっぽいスキルやSMっぽいスキルもスキルマップに入れて、POと一緒にスキルマップを作ります。そうすると私のチームのスキルマップは、図のように、DEVっぽいスキル、SMっぽいスキル、POっぽいスキルにゾーンが分かれたスキルマップになります。

f:id:sonomirai:20210802001303p:plain
チーム発足時のスキルマップ例

スキルマップの運用で難しいところ

私はスキルマップを作成した後、ふりかえりの場などを活用して定期的にチームで話し合って、スキルマップを更新しているのですが、このとき難しいと思うことがあります。
それはSMっぽいスキル、POっぽいスキルの更新です。DEVっぽいスキルの部分は、項目自体が細分化されたり(例えばAWSという項目は早い段階で細分化される気がする)、スキル度合いもぐんぐん向上していくはずなので、チームの会話は弾みながら更新できるのですが、SMっぽいスキルやPOっぽいスキルの部分は、ついつい更新をおざなりにしてしまっていました。
理由としては、DEVは複数名いるのに対して、POやSMは基本一人なので、話し合いの中での優先順位を下げてしまっていたというのと、私がスキルマップの主な目的を「DEVのスキル可視化」と捉えていたというのが正直なところです。

チームのアジリティ

唐突に話が変わるのですが、私はチームのアジリティは、メンバがお互いのロールについてどれだけ共通認識を持っているかによって決まると思っています。
DEVがPOに提案しても、POが開発のことをわかっていなかったら、説明に時間がかかります。
POがSMと会話しようにも、SMにPOを支援する度量がないと、バックログ作成が進みません。
SMがDEVにアジャイルマインドを伝えようとしても、DEVが興味なかったら開発は進みません。
チーム発足時に上記の状態だったとすると、それはチームのアジリティが低い状態だと思います。
その後チームで会話を重ねてお互いのロールについて理解することで、チームのアジリティは向上すると思います。

チームのアジリティはスキルマップのどこに表れる?

さてここまでの内容で、「チームのアジリティはスキルマップのどこに表れる?」に対する私の考えがわかったでしょうか。
私は下図の通り「メンバが自分以外のロールのスキルをどれだけ有しているか」にチームのアジリティが表れると思います。

f:id:sonomirai:20210802004600p:plain
他のロールのスキルを有したスキルマップ例

他のロールのスキルについて、高いスキル度合いを有する必要はないと思います。
ただDEVであれば、POがバックログの説明を聞いて、その裏にある業界知識や業務をイメージできる程度のスキルがあるといいし、POであれば、DEVがテストの自動化を訴えてきたときにその優先順位を判断できる程度のスキルがあるといいと思います。

目指したいスキルマップの運用

スキルマップを使って、メンバが他のロールのスキルをどれだけ有しているかを可視化することで、それぞれのロールに対して理解が足りないところは勉強会で補うことができ、結果としてチームのアジリティが向上すると考えているので、今後はこの点をチームメンバに伝えた上で、スクラムチーム一丸となって、改めてスキルマップを運用していきたいと思います。

さいごに

この記事では、スキルマップを見たときに「メンバが他のロールのスキルをどの程度有しているか」を評価することで、チームのアジリティを可視化・向上させることができるのでは?という仮説を説明しました。実践して学びを得たら、また記事にしたいと思います。

*1:この記事において「チームのアジリティ」とは、メンバが何かを提案してから、チームとして合意して具体的なアクションに繋げるまでの期間を指しています。この定義は私の勝手なイメージなで出典はないので、一般的なイメージと異なっていたらすみません。。。なおチームのアジリティという考え方は、広木さんの「2つのDX」とDX Criteriaのお話を聞いていて思いついた考え方です。

エラスティックリーダーシップを読んで考えたこと

この記事はScrumFestSapporo2020 Advent Calendar 202020日目の記事です。

はじめに

安ヶ平です。普段はSIerスクラムマスターとして働いています。
今年は各地のScrumFestにオンラインで参加していて、11月はScrumFestSapporo2020に参加しました。招待講演がすごく良かったので、そこで言及されていたエラスティックリーダーシップアドベントカレンダー駆動で読んで、考えたことをブログにしたためてみました。
記事の前半では、エラスティックリーダーシップという考え方について、私なりの理解を述べます。次に、書籍を読んでスクラムマスター視点で大事だと考えたことを2つ述べます。最後に、この本の内容とSCRUMMASTER THE BOOKの内容はいい感じの補完関係にある気がしたので、その点について述べます。

エラスティックリーダーシップという考え方

エラスティックリーダーシップというのは、「チームにはサバイバルフェーズ、学習フェーズ、自己組織化フェーズという3つのフェーズがあり、リーダーはチームのフェーズに合わせたリーダーシップスタイルを取る必要があるという考え方」と私は理解しています。書籍を読むことで、この考え方の他にも様々な気づきを得ることができましたが、タイトルになっているこの考え方を知れたこと、これが自分にとってのこの本の一番の価値でした。
各フェーズとそれに合わせたリーダーシップスタイルは以下の通りだと理解しています。

サバイバルフェーズ

サバイバルフェーズというのは、メンバが目の前の仕事をこなすことに精一杯で、チームとしての学習時間が取れていない状態を指します。
このフェーズにおいて推奨されるリーダーシップスタイルは、指揮統制型のリーダーです。
アジャイルの文脈で出てくる支援型のリーダーシップは、このフェーズにおいては推奨されません。燃えさかる炎上案件においてチームが必要とするのは、出口を探索するよう背中をそっと後押しするような支援型のリーダーシップではなく、最短距離で一刻も早く、出口まで引っ張っていってくれるようなリーダーシップだからです。
このフェーズだと透明性を上げて検査と適応で改善だ!なんて言ってられません。なぜでしょう?それはこの言葉に尽きると思います。

ゆとりのないところに改善はない。

引用:カンバン仕事術

サバイバルフェーズにいるチームに対してリーダーができるアクションは、とにかくチームをそのフェーズから引っ張り出して、チームが学習時間を設けられるよう、ゆとりある状態にすることです。これが実現できると、チームは次の学習フェーズへ向かいます。

学習フェーズ

学習フェーズは、アジャイルの知識がある人にとってはイメージしやすいと思います。自己組織化したチームを目指して、チームがチャレンジするフェーズです。このフェーズのチームに対して推奨されるリーダーシップスタイルは支援型のリーダーシップです。チームは学習フェーズを経て、自己組織化フェーズへと向かいます。

自己組織化フェーズ

いわゆる自己組織化したチームで、このフェーズにおける推奨のリーダーシップスタイルは、自己組織化した状態が維持されるようファシリテートするリーダーシップです。

スクラムマスター視点で大事だと考えた2つのこと

チームのフェーズをよく観察する

正直にいうと、この本を読み始めた時点では、チームの3つのフェーズのことを以下の通り単純化して捉えていて、サバイバルフェーズはアジャイル開発している自分には関係のないことのように感じていました。

  • サバイバルフェーズ:従来型の開発チーム
  • 学習フェーズ:一般的なアジャイル開発チーム
  • 自己組織化フェーズ:理想的なアジャイル開発チーム

でも書籍を読み進めるうちに、チームのフェーズというのはちょっとした要因で変わってしまうものだということが理解できてきました。例えば学習フェーズにいたチームが、ちょっとバックログ消化がうまくいかない時期が続いたことでサバイバルフェーズに戻ってしまったり、自己組織化フェーズにいたチームが、メンバの入れ替わりで学習フェーズに戻ってしまったり。なのでスクラムマスターとしては、常にチームがどのフェーズにいるのかを観察して、その状況に合わせたリーダーシップスタイルを発揮することが大事なのだと思いました。

守るだけではなく、創る

スクラムガイドには、スクラムマスターの仕事として以下の印象的な仕事が掲載されています。

開発チームの進捗を妨げるものを排除する。

引用:スクラムガイド2017

最近以下の通りになりました。

スクラムチームの進捗を妨げる障害物を排除するように働きかける。

引用:スクラムガイド2020

私はこのあたりの記述から、スクラムマスターはチームを守る存在というイメージを持っていました。スクラムマスターが守るものの1つに「予想外の事態に対処するためのゆとり時間(≒バッファ)」があると考えていて、それを守ることは実践してきたつもりです。ただ、そこからさらに一歩踏み込んで「チームが学習・改善するためのゆとり時間を創る」という意識が薄かったことに、この本を読んで気づきました。
これまで私は「学習はプライベートでやるもの」と考えていたのですが、チームとしてハイパフォーマンスを出すためには、今のチームでうまく働くための学習や実験が不可欠で、それはプライベートでは実践できないことなのだから、スクラムマスターが学習・実験のための時間を創るよう、チームや組織に働きかける必要があると考えるようになりました。

SCRUMMASTER THE BOOKとの補完関係

書籍エラスティックリーダーシップの一番の価値が「エラスティックリーダーシップという考え方」であるのと同様、SCRUMMASTER THE BOOKの一番の価値は「#ScrumMasterWayという考え方」だと思っています。私は#ScrumMasterWayを以下の図のようなイメージで捉えています。*1

f:id:sonomirai:20201219125949p:plain
#ScrumMasterWayのイメージ図

私はSCRUMMASTER THE BOOKを読むまで、#ScrumMasterWayのLevel3がスクラムマスターのスコープという意識がありませんでした。ですが#ScrumMasterWayを読んでからは、チームの先にいる組織・会社を意識するようになってきたと思います。こういった気づきを与えてくれたという点で、この本に出会えて良かったです。ただ一方で、自分がこの本に期待していたのは「自己組織化したチームを作るためにスクラムマスターは何をすべきかのヒント」だったので、その点については肩すかしを食らったような印象を受けました。
そんな時に出会ったのが書籍エラスティックリーダーシップだったので、自分がSCRUMMASTER THE BOOKに期待していたことはこっちに書いてあったんだ!と思いました。*2
チームを自己組織化に導くエラスティックリーダーシップと、そこでの経験を組織や会社、社会に広めていくという#ScrumMasterWayを学んだことで、私はスクラムマスターとして常に意識すべきことを以下のイメージで捉えるようになりました。*3
私はこのイメージを、T型人材になぞらえてT型スクラムマスターと心の中で呼んでいます。

f:id:sonomirai:20201219145341p:plain
スクラムマスターとして意識することのイメージ図(T型スクラムマスター)

T型スクラムマスターを意識して仕事をするようになったのはまだ最近のことなので、実践していくうちにイメージは変わってゆくかもしれませんが、今のところT型スクラムマスターを意識した動き方は自分にしっくりきていて、チームや組織の状態を以前よりもうまく観察できるようになった気がします。

おわりに

この記事では、エラスティックリーダーシップという考え方、書籍を読んでスクラムマスター視点で大事だと考えた2つのこと、SCRUMMASTER THE BOOKとの関係、そしてそこから導いたT型スクラムマスターという考え方について述べました。T型スクラムマスターという考え方はこれからも実践するとともに、他の方とも対話していきたいと考えています。

*1:#ScrumMasterWayについて詳しくはこちらをご覧ください。

*2:改めてSCRUMMASTER THE BOOKを読み返すと、5章の「部族としての組織」はエラスティックリーダーシップに通じるものがあると感じますが、この章だけだと具体的なアクションには結びつけられない印象です。

*3:フェーズとモードの使い分けについて補足します。書籍ではチームの状態をフェーズ、それに対するリーダーシップスタイルをモードと定義しています。従って、サバイバルモードとは「サバイバルフェーズのチームに対して、指揮統制型のリーダーシップを発揮すること」と考えると良いと思います。