チームが何かに夢中になると俯瞰して観ることが難しく、雑念に囚われ、本質に集中できなくなってしまいがちです。目の前のタスクに集中すればするほど近視眼的になってしまうのです。そういう経験はありませんか？

僕は以前プレイングマネージャーをしていたことがありますが、成功させたい！と想えば想うほどプレイヤーとしての意識が強くなり、全体像を見失い、ステークホルダーやチームメンバーへの配慮が足りなくなって、炎上させてしまうようなこともありました。

もう同じ過ちは繰り返したくない！専任スクラムマスターをすることになったのを機に「俯瞰して観る」ことを大切にしています。

スクラムはリーン思考に基づいており、スクラムガイド2020には「ムダを省き、本質に集中する」と書かいてあります。それって、マインドフルネスの「雑念を脇に置いておき、イマココに集中する」と同じでは？スクラムはチームでマインドフルネスをすることなのでは！と僕は解釈しこれまでスクラムマスターをしてきました。

日々の様々な活動の中でマインドフルネスを意識することで、雑念に囚われることなく、ムリ／ムダ／ムラをなくし、より良い活動ができるようになったと実感しています。その甲斐あってチームからも「俯瞰して観てくれて助かります」という声が何度かありました。この知見をみなさんと共有したいです。

※毎日瞑想しましょう！というお話ではありません

受託開発の会社で強いチームをつくりたくて、現場と一緒にコードを書くアジャイル専門組織をつくりました！が、JTCの荒波に揉まれる我々！

• 期待している形で案件が来ない！
• 支援って、ちゃんと評価されるのか？給料下がっちゃうんじゃないの？
• ３年単位で大きく変わる企業の勢力図によってトップダウンのアジャイル推進活動の雲行きが怪しく！

毎年お送りしている田舎スクラムチームの状況をお伝えします！

背景

スクラムマスター未経験の状態で前任者から引き継ぎを受けた駆け出しスクラムマスターのお話。
引き継ぎを受けた時点でチームにはある程度自律的に動けるメンバーが揃っていたため、引き継ぎ後も前任者のスタイルを概ねそのまま踏襲していた。
それから2年ほど経ち、メンバーとの1on1やスプリント毎のレトロスペクティブ（振り返り）を通して、チームには以下の課題があると感じるようになった。

• スキルセットの関係から、スプリント開始直後から優先度の低いバックログに着手するメンバーがいた
• 優先度の低いバックログのため、せっかく実装が完了してもテスト、リリースに着手できるまで数ヶ月かかることがざらにあり、メンバーのモチベーション低下に繋がっていた
• ペアプロやモブプロといったチーム内のスキル平準化につながる手法を何度か取り入れるもなかなか定着せず、結局１人１バックログを担当する文化が定着してしまっていた
• 「このままこのチームにいてもスキルアップが望めない」「数年後にスキルが身についている自信がない」というメンバーからの率直な意見が出ていた
• リモートワークに突入するとチーム内の会話やコミュニケーションの量が減り、上記の一人バックログの文化とあわさりチームという意識が減少してきてしまった

「これだけの課題がある以上、スクラムマスターとしてなにかアクションを起こさなければ！」
そんな考えを持ちつつも、彼は彼で人知れずこんな葛藤を抱えていた。

• チームやプロジェクトに対して駆け出しの自分なんかが変化を起こしてしまって良いのか、もはやどこかのアジャイルコーチに任せるべきことなのではないのか
• そもそも先述の課題を課題だと思っているのは自分だけなのではないか
• メンバーやPOは特に変化を望んではいないのではないか
• ベロシティを見る限りでは表面上は特に問題があるように見えず、自分がアクションを起こすことでかえってベロシティが大幅に下がってしまうのではないか（というかほぼ間違いなくそうなる）
• そうなる可能性が高い以上は説明責任を果たさなければならないが、POやステークホルダーからの理解を得られるのか
• むしろ「余計なことをするな」と言われてしまうのではないか
• 日々の業務だけでも時間が足りていないのに、果たしてチームの改革までやりきれるのか

実はプロジェクト内では去年からパイロットチームが立ち上がっており、一足先に「なんちゃってスクラムチーム」からの脱却に成功し、成果を上げていた。
そんなこともあり、今ならプロジェクトの後押しを受けながら変革を推し進めることができるのではないか、と考えていた。

ある日、チームの抱える課題についてSoSMや上記のパイロットチームを含めた他のチームのスクラムマスターに相談する機会があった。
そのとき言われたほんの些細な一言が、一歩を踏み出すきっかけになった。

『とりあえずダメ元でもいいから、いったん率直にPOに話してみたらどうです？もしダメならダメで次の手を考えましょう』

その一言に背中を押され、早速POとチームのメンバーに話をしてみると自分の今までの葛藤は何だったのかと思うほど状況が前進した。
POやチームメンバーからの賛同が得られ、「なんちゃってスクラムチーム」から「真のスクラムチーム」への第一歩を踏み出すことができた。

これから「なんちゃってスクラムチーム」から脱却し、「真のスクラムチーム」への変革を目指す方に向けて、
駆け出しスクラムマスターが実際にチームのカイゼンのために実施した取り組みについて、少しでも参考になるお話ができればと思います。

こんな人に聞いてほしい

• なんちゃってスクラムから脱却し、真のスクラムチームへの変革を目指す全ての方
• スクラムガイド通りのスクラムが実践できているか自信が持てないスクラムマスターやスクラムチームメンバー（デベロッパー）
• 自チームのスクラムマスターが思ったような動きをせずに悩んでいるプロダクトオーナー
• 冒頭に挙げた、チームが抱える課題感に共感した人

アジャイルやScrumでチームを回していると本当にうまく回っているのか不安になるものです。

私どものチームも同様で、チームの状況を可視化するため色々検討してみましたがうまくいきませんでした。

FourKeysも計測していますが、どうすれば数値が上がっていくのかわからないまま。

最近知ったSPACE（達成感(satisfaction)、パフォーマンス(performance)、活動(activity)、コミュニケーション(communication)、効率性(efficiency)）という考え方を導入し、私達のチームでは多面的にチームの状況を可視化しようと試みているところです。

その意義と成果をほぼリアルタイムでご紹介できればと思います。

また、SPACE自体は具体的にどの指標を計測するかまでは指示していないため私達がどの項目を選択したのかもお伝えします。

プロポーザルの数だけストーリーがある

数年前からRegilnal Scrum Gathering TokyoやScrum Festでは、プロポーザル制によってセッション採択されるようになりました。どのイベントでもたくさんのプロポーザルが提案され、そこからたくさんの素晴らしいセッションが生まれています。

私も採択されてセッションが実現されることを目指していろんなイベントにプロポーザルを出してきました。そして、面白そうなプロポーザルに投票をしてきました。

そんなある日、

• 採択されるかされないかに関わらず、このプロポーザルおもしろそうだからもっと話を聞いてみたい！
• プロポーザルに書かれている内容だけだとわからないけど、実はおもしろいプロポーザルがたくさんあるのでは！？
• セッションにならないというだけで埋もれてしまうのはもったいない！

という想いにかられて、「プロポーザルを見ながらYYする会」というイベントをはじめました。

実験的にはじめてみたところ、参加してくださった皆さんのプロポーザルへの想いやストーリーを聴くことができて、胸がアツくなる瞬間が何度もありました。各イベントのセッションも面白いですが、それと同じくらいプロポーザルYY会もアツいです。

今回はそのプロポーザルYY会の素晴らしさをぜひみなさんにも味わってほしいと思いプロポーザルを出してみました。Scrum Fest Osaka 2023のイベント開催期間中に、ちょうどScrum Fest Sendai 2023とScrum Fest Mikawa 2023のプロポーザルを募集しています。出されているプロポーザルを見ながらYYしましょう。

• Srum Fest Sendai 2023 Proposal
• Scrum Fest Mikawa 2023（募集開始前）

プロポーザルを書いた方へ

プロポーザルを書いた想いを語りたい方、プロポーザルへのフィードバックが欲しい方はぜひ持ち込んでください！

書ききれていなくても、メモレベルでもOKです！まずは持ち込んでみることが大切です。

プロポーザルを書いてみたい方へ

プロポーザルを出すことに興味がある方、プロポーザルを書きたいけどネタがないと思ってる方、ぜひ参加してみてください！

出した人たちがどんな思いでプロポーザルを書いているのか、どうやって書けばいいのか雰囲気がわかると思います。

とにかくプロポーザルを見てYYしたい方

一緒にYYしましょう！

過去のプロポーザルYY会

• RSGT2023のプロポーザルを読んでYYする会
• スクフェス福岡2023のプロポーザルを読んでYYする会
• スクフェス大阪2023のプロポーザルを生みだしながらYYする会
• スクフェス大阪2023のプロポーザルを見ながらYYする会

ウォーターフォールモデルでの約7年間の開発プロジェクト経験を持ち、今は新潟でセールスやビジネスデザインの仕事をしており開発から遠ざかってしまった私ですがスクラムフェス新潟で皆さんのセッションや、会話を通じて刺さりに刺さる刺激をいただきました。
それは開発を行っていた当時や、開発を離れた今も共通的に大切だと感じて心がけていることであったり、うまく実践できていないこと、そんな様々な刺激を。
本セッションではその刺激を整理し、感じたことの一部をお伝えしていきたいと思います。

• 改めて感じた、「発信がコミュニケーションの起点であり、発信が変化を生み出す」

プロジェクトを進めるうえで共通的に大切だと再認識したのは「自分の考えたことや、感じたことを伝える、発信をする」ということ。自分の考えを伝えていけば、相手の考えや感情を引き出し知ることができる。私が体験した成功プロジェクトでは、プロジェクトにかかわるメンバ間でしっかり発信を行い意見を出し合っていたと思います。
それは、あるべき姿に関する意見だったり、現状に対する課題だったり、解決策だったり、感想だったり、いろいろな意見があると思いますが、すべて変化を生み出すきっかけになるものだったと思います。

• 発信が与える変化はよいものだけではない「想像力の大切さ」

与える変化もポジティブなものもあればネガティブなものもあります。
そのため、「何のために？」という意見を提示したいと感じた理由・目的、「誰のために？」という伝えたい相手や範囲を意識することが大切になります。受け手への配慮や、尊敬が必要で、自分が見えている範囲・自身の常識の範囲を超えて想像力を働かせ考えを伝えていくことが大切なのだと思います。
成功するプロジェクトではそれぞれの役割は当然大切なのですがメンバの皆さんが相手への思いやりや、役割を超えた目線をもって取り組んでいると思います。

• 発信の大切さを開発プロジェクトに活かす

上述したことを感じ、自身が改めて開発プロジェクトにかかわるようになったら大切にしたいと感じたことをお伝えします。
アジャイル、ウォーターフォールいずれのモデルで開発を行う場合においても、それぞれの良さを取り込むことでより良いプロジェクトになるのではないかといいうことです。
アジャイルは短期のスパンで実現したい要望、目的を最小限必要な単位から実装していくため、目的を実現していくためスピード感を持ちつつ、うまく要望を拾いながら進められる仕組みだと思います。
ウォーターフォールは柔軟性はないものの、一度決めた道筋を丁寧に進めていくということでは、堅実にプロジェクトを進めていくことができます。ヒントがそこにはあると思います。
例えばウォーターフォールモデルではドキュメントをたくさん作成します。これは工程ごとに担当者が変わるため後工程にその情報をしっかり伝えていくためのものです。要はコミュニケーションの手段としてドキュメントを作っていく必要があるのです。
アジャイルではコミュニケーションの手段を実際に動くプログラムやツールで代用して効率化を図りますが、特に重要な事項は今後も情報を風化させないためにもドキュメントを作る大切さを知り、作るべきドキュメントの取捨選択を行っていくとよいのではないでしょうか。このようにウォーターフォールモデルの場合によってはデメリットともとれる特徴を、捉え方を変えることでプロジェクトを安定させるための要素にしてはどうかと思います。

当日はこういった刺激を整理してその一部をプロジェクトマネジメントに大切なこととしてお伝えしていきたいと思います。

新規事業の「ノリと組織」

DevOpsDaysTokyo2023のkeynoteにて塩田さんの「ノリと組織」という講演を聞いて強く心に響くものがありました。
「Webサーバを開発して運用保守するだけがDevOpsじゃない、チームを組織をDevOpsしていくんだ！！」

私は、これまで前職も含めていくつかの新規事業に携わってきました。新規事業において最初勢いがあっても、３〜５年経過すると勢いがなくなっていく様子を何度も経験してきました。そんな中、私の所属する部署が分社化されました。私達は組織をDevOpsするために、これから勢いに乗ってノリを生み出し続けていかなければいけません。
ノリを組織にもたらすにはどうしたら良いのか？講演を聞いた直後言語化できないでいました。あれから少し時間が経ち、その小さなヒントが自分の経験の中にあることに気がつきました。

Fun Done Learnのうたの軌跡と奇跡

ただのソフトウェアエンジニアであった私が昨年11月、Scrum Fest Sapporo 2022でFun Done Learnのうたを発表した後、信じられない出来事が数多く起きました。

• ITプレナーズさん主催Fun Done Learnウェビナーの実施
• 業務の隙間に内製開発したふりかえりツールの利用者が社内で急増
• Fun Done Learnの生みの親やっとむさんがkeynoteで歌を歌ってくれる
• ふりかえりエバンジェリストの黄色い森さんがスクフェス新潟で踊ってくれる
• 各社のスクフェス動画鑑賞会でFun Done Learnのうたが再生される
• 自分の推し活ブログを書いてくれる方が出てくる

早く行きたければ一人で行け、遠くへ行きたければみんなで行け
（if you want to go fast, go alone; if you want to go far, go together）

弊社のVPoEが好んでよく使うアフリカの諺です。この半年で本当にたくさんの方と出会い、多くの人のおかげで予期せぬ経験をたくさんさせて頂き、元々居た場所からはちょっとだけ遠くへきたように思います。

しかしながら不思議とデジャブを感じていました。過去にも私は運の良いことに何度かこのような「ちょっと遠くに来る」瞬間を味わってきました。そして、一見再現性がなさそうなこの出来事を振り返ったときに共通しているあることに気がつきました。

二人目に踊る人とその共通点

それはどの遠くにきた瞬間にも必ず「二人目に踊る人」がいて、この人の一言がなければ実践できなかったということ。そしてその人達はフォロワーシップだけでなく、共通するサーバントリーダーシップを発揮していたことでした。

ちょっと遠くに来た出来事達をふりかえりながら、二人目に踊る人がどんな人だったか、どのようなサーバントリーダーシップを発揮していたか、共通点を探してみたいと思います。

このセッションを聞いてもチームや組織にノリをもたらす具体的な手法は分かりません。
ただ、ノリをもたらす時にどんな事が必要か？またスクラムを進める上でどのようなサーバントリーダーシップが必要か？それぞれ考えるきっかけになるかもしれません。

2022年の年末、私は入社以来初めてアジャイル開発のプロジェクトにジョインできることになりました。
しかし、ワクワクドキドキの中で迎えたチームビルディングをとある理由で欠席する羽目に…
しかも、開発メンバーの拠点はバラバラのため、うまくコミュニケーションをとりながら開発を進められるのか不安がありました。

それでも、実際には開発は楽しく進んでいきました。そこにはいくつかのファクターがあります。

まず、MTG中のカメラオンやカジュアルなチャット文化は、コミュニケーションを促進する大きな要因でした。また、経験豊富な先輩エンジニアの言葉がきっかけで、困ったら即相談という習慣が身につくようになりました。さらに、明るいスクラムマスターのおかげで、心理的安全性の高い状態でスクラムイベントを実施することができました。

最初は不安を感じつつチームにジョインした身でしたが、徐々にスクラムチームで開発を進めることに楽しさを覚え、自分でもやれることを模索するようになりました。ほかのメンバーと雑談できる話題を探してみたり、自分のタスクを意識的にオープンにしてみたりと、能動的なコミュニケーションを心がけるようになりました。

このようにこのセッションでは、初めてスクラムチームにジョインした私が、リモートでもスムーズに開発を進めるために重要であると感じたファクターをいくつかご紹介します。

皆さんうまくプロダクトゴールの達成、PBIの完了、効果的なふりかえりをできていますでしょうか？

みなさんは、ベンチャーキャピタル(VC)と聞いてどんなイメージを持ちますか？

おそらく、名前は聞いたことがあっても実態がピンとくる方は少ないのではないでしょうか。
そんなVCがスクラムを支援しているなんて、全く想像がつかないですよね。

私が働いているVCは、投資先の事業を現場レベルで支援する専門チームを持っています。
国内VC界隈ではそれだけでも珍しいのですが、弊社ではそのオプションの中にスクラム支援が入っています。

初期メンバーが単独で開発を行うようなシード期はわかりませんが、シリーズA前後で人数が増えチーム開発をするタイミングでスクラムがよく採用されます。

構造上、プログレッシブに変化する開発現場なので、以下のような事象が起こりやすくなっています。

• 自分がやった方が早い、名ばかりマネージャ問題
• 感じて動けない人は「向いていない」、言語化しない(ハイコンテキスト)文化
• チーム取りまとめを任されるが求められるのは実働のプレイングマネージャ
• 見積もりがコミットメントに、マイクロウォーターフォールで開発が疲弊
• 創業期の技術的負債解消のためのリプレイスをもう数年続けている、開発の内部が見えない
• 気がつけばビジネスと開発が分断……

スタートアップの立場からすると、T2D3の成長曲線を狙う中で常に事業や会社の環境は目まぐるしく変わります。

そんな時に有効なのはアジャイルコーチなどのサポーティブな役割ですが、スタートアップは一般に資金が限られているため、アジャイルコーチを雇えないことが多いです(もっとも、ニーズとして顕在化していないことも少なくないのですが)。

上記は開発の例ですが、スタートアップが成長する中で現場が直面する様々な事象に対して、カイゼンを外部から支援するために我々のチームは存在しているのです。

本セッションでは、そんなベンチャーキャピタルでのスクラム支援業務を紹介すると共に、複数スタートアップに携わって気づいたスクラムのDos and Don'tsをご紹介できればと思います。

※本プロポーザルはScrum Developers Night! in Tokyoの参加者の皆様によって壁打ちいただきました。ありがとうございました！

前職はとある音楽企業の社内ベンチャーである, ゲームを自社開発運営する事業会社に在籍しておりました
2021.09 に現職である大手 IT ベンダーに転職し, 一年半以上が経過しました

転職をすると必ず制度や文化の違いで戸惑いが起こるものですが, 一年半も経てば大抵のことは慣れるものです
しかし, いつまで経っても大変だと感じる仕事があります

体力を使う仕事, 頭を使う仕事, いろいろありますが, ぼくが大企業で働く上で一番大変だと感じている仕事は "調整業務" です

あなたにもこんな経験はございませんか？
この話を決めるためには山田さんと田中さんと佐藤さん（すべて架空の人物です）を招集する必要がある
全員の Outlook を並べて始める工数パズル
今日は月曜日, 全員のアンドが取れるのは来週の木曜日の 14:00-14:30 の 30 分だけ orz...

その度ぼくはこう思います
前職だったら, 「デイリーの後, 二次会でちょっと話しませんか」で済んでたのになあ

工数パズルに苦しむぼくを妄想へと駆り立てたのは A-CSM トレーニングで伺った Tesla の話でした
「 Tesla では常時モブワークを行っている, イーロンも含めてほとんどの社員がだ」

すごく理想的な組織だな, 弊社もこんな組織になれないかな
例えるなら "ひとりの人格のようなチームで構成された組織" だ

しかしながら残念なことに, どうしたらこれが実現できるのか, いまのぼくにはさっぱりわかりません
そもそもこの考えが良い考えなのかもわかっていません

なぜならこれは, ぼくの目に映る世界の情報のみをもとにした世間知らずな妄想だからです

そこでぼくは考えました
ずっとこの組織にいる先輩, 外からこの組織に来た先輩, この組織から去った先輩を呼んで意見をいただこうと

本セッションでは, 前半でぼくの妄想話を発表させていただき, 後半ではスペシャルゲストをお呼びして公開ディスカッションを行います

こんにちは、佐々木と申します。
私含め4人のエンジニアチームで、マネージャーを担当していました。
しかし、みな散り散りになりました。

このセッションでは、マネージャーであった私の振り返りをお伝えします。
なぜメンバーは去っていってしまったのか、私に足りなかったのは何なのか......。
特にフォーカスするのは、「メンバーは幸せにお仕事できたか？」「自己組織化できたか？」「マネージャーの私はもっとこうすべきだったのではないか？」です。
詳しくは、Outline/Structure of the Talkの節に記載しました。

セッションの多くは、最終的には成功したというお話かと思います。
一方で本セッションではほとんどが失敗談です。
覚悟を決めて赤裸々にお伝えしますので、みなさまの学びも多いことと思います。
より良いチームを作るためのネタやスクラムマスターが自分自身の働きを振り返るネタを、どうぞお持ち帰りくださいませ！

1年前に転職という形でスクラムチームから今のチームへ異動しました。

新たなチームは、プロダクトへの情熱を持っているメンバーは多い一方でエンジニアが個人商店状態になっていました。そのため、Joinしてしばらくは雑談会でコミュニケーション量を増やすなど、チームになることを目指して草の根活動をしていました。

そこから月日が経って iOS エンジニアチームのリーダーになり、自分が直接手を動かすことよりチームとしての成果を意識するようになりました。コーディングルールの再検討や今ある技術的負債について議論し、個人が感じていたことチームとして認識できるような取り組みをやってきました。取り組みの中には、チームの理解を得られず挫折する・取り組みを継続させることができず霧散するなど失敗もたくさんありました。

そうした取り組みをしているうちに、今度はモバイルエンジニアチーム(iOS / Android)として技術的負債への戦略的な取り組みをリードすることになりました。技術的負債と向き合う中でも「どうしたらみんなが楽しく開発できるだろう？」「持続的に改善を重ねられるチームにしたい」などエンジニアチームのために考える時間はどんどん増えています。

そんな自分の取り組みをふりかえってみると、ただのエンジニアからリーダーへ、リーダーからエンジニアチームをリードする立場になり、少しずつ良いチームを考えるときの視点が変わってきていることに気づきました。それだけではなく、自分の行動もリーダーになった当初は自分がやるんだと抱え込みがちだったのが、Whyは自分が考えてそれ以外はみんなで考えようなど周囲をうまく巻き込むことがいつの間にかできるようになっていました。

このセッションでは、新米リーダーが取り組みに失敗したときの思考やそこから変化するために挑戦してきたことをお話しします。