大事な活動である「ふりかえり」。だが、難しい活動でもある。

スクラムの重要なイベントの一つである「スプリントレトロスペクティブ／ふりかえり」。
チームを自己組織化へと導く大事なステップでもあり、スクラムの中でも一番「チームによるチームのための活動」だと言えると考えています。

スクラムを始めたとき、多くの人が直面するのは、「ふりかえりがうまく機能しない」ということです。
ふりかえりが反省会のようなムードになってしまう。
チームのためのアクションが出ず、なかなかチームがまとまらない。
アクションは出たものの、なかなかカイゼンされているように思えない。
こういった悩みを持つ多くの現場を見てきました。

ふりかえりは、難しい活動の一つとして考えられがちです。
時間対費用効果が出ているのか、なかなか計測がしづらいですし、効果がすぐに現れない場合もあります。
他のイベントと違い、ふりかえりがうまくいかなかったときに、「この活動は価値がないものだ」と感じ取られてしまいがちなのです。
そのまま、ふりかえりが行われなくなってしまうのは、とても悲しいことです。

ふりかえりとファシリテーション

ですが、ふりかえりにはチームが成長するために大事な要素がたくさん詰まっています。
そのうちの一つが「ファシリテーション」という考え方です。

進行役としての「ファシリテーション」ではなく、促す者としてのファシリテーション。
スクラムマスター一人がファシリテーターなのではなく、チーム全員がファシリテーター。
チームが「ファシリテーション」を意識したとき、あなたたちのふりかえりはきっと良い方向へと変わります。

ファシリテーションというものをあなたがどうとらえるか。
そのとらえかたが変わると、きっと新しく見えてくるものがあるでしょう。

COVID-19とふりかえり

COVID-19の影響を受け、チームの姿は大きく変容しました。
ふりかえりも、著しい影響を受けたイベントの一つです。
ニューノーマルな世界が形成されていく中、ふりかえりはどのような姿を見せるのでしょうか。
これまでの先人の知恵や、私たちが培ってきた経験は使えないのでしょうか？

そこまで悲観することはありません。
このセッションでは、昨今のオンライン環境におけるふりかえりの新しい姿と、私たちが考えるべきこともお伝えできると思います。

このセッションについて

このセッションでは、あなたがふりかえりの中で行うファシリテーションを考えるときの気付きを提供します。

COVID-19で変わったチームの姿。そして、この環境下でふりかえりにおいて変わるもの、変わらないもの。
チームの形成、そしてチームの成長。チームのグラデーション。
ふりかえりのファシリテーションと、マインドセット。

「自分のチームでは今どんなことを意識しながらファシリテーションしているだろうか」
「自分のチームのふりかえりの現状はどんなものか」をイメージしながら、セッションに参加していただければ幸いです。

みなさんの現場ではすでにスクラムを導入済みでしょうか。

最初は仕事が終わらない、品質が低い、改善が進まないといった問題が沢山出ていたチームも、スクラムを始めると少しずつ安定して開発ができるようになってきます。ある程度のベロシティが出て、不具合の数もそれほど多くなく、割り込みタスクも大きい問題にはならなくなるでしょう。しかし、チームは魅力的で顧客の問題を解決する本当に強いプロダクトを作ることができているでしょうか。

本当に強いプロダクトを作るためには、プロダクトオーナーの支援が欠かせません。プロダクトオーナーが不確実性と向き合い、素早い仮説検証を繰り返して、価値の高いアイデアを見つけられるようになる必要があります。開発チームはプロダクトオーナーの活動に参加・協力し、スクラムマスターはその取り組みを様々な方法で支援することができます。

このセッションでは、自分がスクラムマスター/アジャイルコーチとして複数の現場で取り組んできたプロダクトオーナー支援の活動と、そこから学んだことについて紹介したいと思います。

基幹系システム開発は、ウォーターフォールで着実に品質を積み重ねて行うべきもの。

そういった固定観念が社内外充満している中、
SoEな領域だけでなくSoRにもスクラムが適用されたプロジェクトメンバー約200名のエンタープライズ・アジャイルSIプロジェクトに
札幌からスクラムマスターとして参画してみた顛末をセッションで共有いたします。

特段教訓めいた話に帰結するわけでもなく、発生したさまざまな出来事を通し、
札幌のエンジニア達がLeSSに近しい姿をトライ＆エラーしていく
天竺への道程（現在進行形）を等身大で聞いていただければと思います。

• アジャイルやスクラムも知らずに集められたメンバーの戸惑い。
• 複数拠点横断スタッフとのリモートワークによるチーミング。
• クライアントとのカルチャーギャップ。
• 自分自身含めたメンバーのマインドセットの成長。
• などなど・・・

「ゼロからつくる！リモートスクラムチーム」からタイトルを変更しました。

プロポーザルを出した時点では以下のようなことをお話しするつもりでした。

小さなベンチャー企業にて、新規自社プロダクトを作ることになりました。

会社として作りたいものはあり、期日もありますが、メンバーがアサインされるわけでもなく、だれかが号令をかけるわけでもありませんでした。

その状況から、

• いちエンジニアがチームを立ち上げてプロジェクトを始動させた話
• 他拠点・多国籍チームが立ち上がり、みんなでスクラムの勉強から始めてスプリントを回し始めた話
• リモートでもチームとしてワークするために試行錯誤している話

をお伝えしたいです。

それから半年ほど経った今、このチームはすでに解散しています。目指していたマイルストンは達成できませんでした。

でも、一部メンバーによってプロジェクトは推進されています。

チームを立ち上げ、スクラムマスターとしてスクラムを実践してみたこと、スクラムに挫折したこと、チームの解散、その後のメンバーの頑張り、私たちにできたこととできなかったことを、ひとつの経験としてお話しします。

アジャイル札幌で人気のコンテンツ「紙粘土スクラム」。
紙粘土と侮るなかれ、毎回リアルな現場のようなドラマがあります。
その中の失敗をアンチパターンとして紹介します。

紙粘土スクラムに特化したアンチパターンではなく、例えば下記のような実際の現場でもあるあるのアンチパターンになっています。

アンチパターン：チャラオーナー
対象：PO
プロダクトオーナーが開発者に対してイメージトークしかしない。例えば「もっとカッコよく」「いい感じで可愛く」「品質をあげよう」など。
改善ポイント：開発者とPOで具体的な例を挙げて認識合わせをする。事前に画像でイメージを共有する。

アンチパターン：妄想の暴走
対象：DEV
ステークホルダーが近くにいるのに、まったく聞かず仮定を積み上げて難しい仕様や不要なものまで作りすぎてしまう。POまで妄想に加わるとチームとして完全にアウト。
改善ポイント：仮説という認識を持って、ステークホルダーと対話する。

モブプログラミングは、いますごく話題になっています。モブはいいという話が多くされてはいますが、どういうことでいいのでしょうか。そして、モブプログラミングでは何が起こっているのでしょうか。モブで、チームメンバーはお互いにどんなやりとりをしているでしょうか。それがそれぞれにどのように働きかけているでしょうか、その結果、どんな効果が生まれているでしょうか。

サイボウズでは、日本の開発は全てモブでやっています。そこから戻ることはありません。何が彼らをひきつけているのでしょうか

私は、そのモブに接した時、衝撃を受けました。そしてその魅力に取り憑かれました。何が起こっているのか、もっと調べたくなりました。そこで、モブのやりとりを徹底的に取っていきました。そこからモブメトリクスというものができて来ました。そのメトリクスを改善していくうちに、虜にさせるモブのメカニズムが見えてきました。そこには、チームが不確実な問題に取り組む際のメンタリティーを高める効果ばかりでなく、高い品質をはじめから組み込んでいく仕組みを支える効果もありました。

このセッションでは、その膨大な情報から見えて来たモブの活動の何がすごいかをご紹介したいと思います。

遠隔のチームメンバーとのミーティングやスクラムイベント、どうしていますか？

チャット、TV会議、ホワイトボード共有ツールなどがありますが、うちのチームではどれも満足できませんでした。

バーチャルでメンバーとあって、付箋やボードを無限に広げて使える場、チームで占有できるプロジェクトルーム、欲しくないですか。

まだ、機材や制約もありますが「現実よりも便利に働ける場」を目指してバーチャルワークプレイスを作っています。

わたしたちのチームメンバー5名は、スクラムイベントを毎週そこで行っています。

少し未来の働き方を紹介させてください。

紹介動画: https://www.facebook.com/ricoh.jp/videos/808565413001238/

チーム、組織、会社、役割、契約、業種・・・
私たちの仕事にはいろんな状況があるので、つい、
「It depends（ケースバイケースだね）」
と言いたくなってしまうときがあります。

しかし、私たちがアジャイル開発やスクラムからヒントを得て成し遂げようとしているのは、そのいろんな状況の中で「It depends」ではない答えを出すことです。

こんにちは！

こんにちは、及部です。

私は、2009年に楽天に新卒入社し、アプリケーションエンジニアとしてプロダクト開発の仕事に携わってきました。その中でもっとよいプロダクトをよいチームで作りたいと思い、スクラムやモブプログラミングを学んで、実践してきました。そして2019年には、チームFA宣言からのチーム転職をして現職であるデンソーでエンジニアとして働いています。

組織上の役割やプロダクトのドメインや会社が変わっても、「よいプロダクトをよいチームで作りたい」という想いは変わりませんでした。コードを書くだけではなく、チームにもプロダクトにも言い訳をしない自分を、そしてチームを目指して試行錯誤してきました。

伝えたいこと

教科書にあるスクラムとは違うかもしれないけれど、プロダクト開発のいろんな状況において言い訳をしないために、どのように考えてどのようにチームを実装してきたのかお伝えしたいと思います。

つい言い訳したくなってしまう人やスクラムをやっていても「これでいいんだっけ？」と悩んでいる人に、少しでも勇気と元気を与えて、行動のヒントを与えられるような時間にしたいです。

それでは、スクラムフェス札幌大会でお会いしましょう。アディオス！

会社の文化（カルチャー）変革の7年間の軌跡。

2013年ごろ、色々な問題が噴出し、会社としても個人（経営者）としてもどん底の状態でした。
そこから、色々な取り組みを行い、少しづつ会社の状態がよくなり素晴らしいメンバーにも恵まれ、会社の良い文化（カルチャー）が形成されるようになりました。

その過程のなかで2017年8月「Joy,Inc.」に出会いました。
「Joy,Inc」とは、Menlo InnovationsのCEOであるリチャード・シェリダンさんが執筆した本です。職場に喜びをもたらす知恵や経営手法だけでなく、顧客も巻き込んでより良い製品を作り、事業を継続させる手法などについて書かれた素晴らしい本です。
この本に共感しぼくらもこんな会社に成りたい！と決意。それまでの会社の文化を良くするための取り組みを更に推進していきました。

会社のカルチャーを変えることはとても困難です。それをどのような取り組みを行い実行してきたのか、そんなぼくらのジョイインクジャーニーの軌跡を共有したいと思います。そのジャーニーの中でやってきたこと、失敗したこと、いまも続けていることを含めて赤裸々にお話したいと思っています。このぼくたちの経験が、みなさんのジョイインクジャーニーに役立てていただけるのであれば大変嬉しく思います。

今回はScrum Fest Sapporo特別編として
1.コロナ禍によって全社リモートワークになり発生したメンバー間のコミュニケーションの減少という課題とそれを解決するために行っていること
2.Menlo Innovations の現在の状況
についてもお話したいと思います。

https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11835/joyinc3

去年、別のイベントで登壇したときの内容をアップデートしてお送りします！

社内へアジャイルを推進していく中で、いくつもの失敗や衝突がありました。
振り返ってみるとその原因は、アジャイルに対する期待値のギャップだったり、目的不明のプラクティス導入だったり、捨てきれないこれまでのやり方だったり。

でもそこに「それはダメ！」「そうじゃない！」と迫っても、「”よくわからないアジャイルというもの”は随分と面倒なんだな。」と終わってしまうかもしれない。まずはアジャイルがどんなものかを正しく知ってもらうのが良いんじゃないだろうか。

そんな中で見えてきた、私の感じた「アジャイルを始めるにはこのあたりから取り組んでいくと良さそう」を紹介します。

「問題がないことが問題だ」

朝会で問題が報告されないにもかかわらずピンチな状況が生まれてしまう、皆さんはこんな経験ありませんか？

チームでは日々の仕事の中で暗黙知から醸成された慣習が出来上がっています。
私達の場合は朝会の進捗共有で「作業が予定に間に合わなさそうなら報告する」「問題を報告すれば迷惑をかけてしまうかもしれない」「言ってもいいんだろうか」という雰囲気の（形骸化した）慣習が存在していました。
こういった慣習がチームの不安要因を表明することを邪魔して来たのかもしれません。

そんな慣習から旅立ってチームは自分たちの価値観に基づき新たな慣習を獲得することはできるのか。

このセッションでは組織の慣習から脱却した小さな成功体験から学んだことをお伝えします。

はじめに

本セッションはRSGT2020にてご好評いただきました「見積りしないスクラム」の続編となります。

見積りをせず、どうやってスクラムを実践するのか。RSGT2020では、我々の方法論とその背景にある理論を紹介させていただきました。
本セッションでは、それらHOWの部分に加え、時間の都合上ご紹介できなかった「見積りしない開発」にたどり着くまでの経緯や、
見積りをやめてから起こった問題やその対処についてもご紹介します。

また、現在我々のチームでは、書き入れ時である年度末に向けて、並列で走る納期駆動の小さなプロジェクトをこなしています。
以前は「見積りしない開発」は向いていないと考えていた「納期優先」な状況でも、見積りをすることなく納期を守っています。
この状況で考えたことや、納期駆動の状況でアップデートされた方法論についてもお伝えできればと思います。

Introduction

本セッションは「見積りは不要なのでやめよう」と一律に提案するものでは ありません。
アジャイル開発における見積りについては「アジャイルな見積りと計画づくり（AEP）」という素晴らしい書籍でその有用性や有効な実践方法が示されており、私自身もその有用性について同意しています。

しかしながら、見積りには負の側面があることもまた事実であるように思われます。
RSGT 2019 Key Note において、 Chris Lucian(@christophlucian) 氏は見積りのコストについて言及し、 #NoEstimates のコンセプトを紹介しました。

そもそも、なぜ見積りが必要なのでしょうか？

そして、本当に必要なものは見積りなのでしょうか。

この問を繰り返すうち、私達は「ほんとうに必要なものは見積りではなく、意思決定ではないか？」という仮説にたどり着きました。
それから、見積りの負の側面と向き合い、「見積り」をせず「意思決定」をする方法を模索し始めます。
以来、半年以上をかけて実験を繰り返し、時には失敗もし、今のプロセスをすこしづつ作り上げてきました。

この私達のプロセスでは、モブプログラミングが鍵となっています。

本セッションでは、私達がどのように見積りをせず開発をしているのか、その方法論を紹介するとともに、
見積りをやめたチームの事例を紹介し、ソフトウェア開発、特にスクラムにおいての見積りのあり方の議論の一助となることを目的とします。

見積りの負の側面と価値

見積りの負の側面について、私達の考えをまとめます。
私達が考える見積りの負の側面は、以下の「３M」に集約されます。

• 数値化による「コミット圧力」… 納期の「ムリ」
• 数値化による「仕事量の最大化」 … 仕事の「ムダ」
• 数値化による「正確であるという錯覚」 … 精度の「ムラ」

そしてこれらは、見積りを「数値化すること」により発生すると考えています。

もちろん、見積りは負の側面ばかりではありません。
見積りの価値について、見積りがなぜ必要なのか、という問いについて、AEPに完結に記されています。

見積りと計画づくりは、期日やスケジュールを決定するためだけのものではない。
計画づくりとは価値の探求なのだ。
– アジャイルな見積りと計画づくり

見積りだけでなく、価値の探求のための「計画づくり」をせよ、とあり、
見積もり自体ではなく、この「計画づくり」に必要な判断材料として見積もりが必要であると考えられます。

これらの考察から、私達は「#NoEstimates / 見積りしない」開発を

見積りの負の側面の根源である「数値化」を行わず、
見積りから取り出したい「価値」を抽出する手法

と定義づけています。

スクラムと見積り

私達はスクラムを実践しています。

見積りを行わなくても、スクラムは成立するのか。あるいはこれはスクラムと呼べるのか。
見積りをやめて以来、ずっと問い続けてきました。

スクラムガイドには「見積り」という言葉が９回登場します。
それぞれを分類すると、スクラムにおける見積りは以下の意思決定を行うための情報であると考えられます。

• リリース計画づくり … PBIの優先順位付け
• スプリント計画づくり … スプリントのキャパシティを測り、コミットメントを高める
• 進捗管理 … 残作業を確認し、計画を更新する

見積り自体を行うことなく、これらの意思決定をするための情報を抽出することでスクラムを行う。
これが私達のたどり着いた答えです。

我々は、以下の方法でこの意思決定を行っています。

• 優先順位付け / バックログリファインメント
  • PBIのサイジング … 直近のPBIを １スプリント以下のサイズ に調整
  • C3D(Cost of Delay Divided by Duration)
• キャパシティ / スプリントプランニング
  • PBIのスループット
  • スプリントゴール
• 進捗管理 / デイリースクラム
  • SBIのスループット
  • モンテカルロ法 … 過去データからの ‘予測’
• スプリント（開発作業）
  • モブプロ
    • WIP制限 … 安定性・予測可能性の向上

「見積しない」 開発と現実

このプロセスは教科書上の理論だけの話ではなく、現実のプロダクト開発で行われています。
通常のソフトウェア開発と異なり、「見積りしない」ことが現実のソフトウェア開発にどのような影響を与えるのかについて、私達の事例をご紹介します。

• 「見積りしない」の始め方
  • どのように上司を、ビジネスを巻き込むのか？
• 「見積りしない」計画づくり
  • どのように先の見通しを立てるのか？
• 「見積りしない」開発の課題
  • 見積りをやめてから、チームに降りかかる課題と対応
• 「見積りしない」で納期を守る
  • 納期が設定された小さなプロジェクトが複数件並行で走る状況で、見積りせず納期を守るには？

まとめ

Joshua Kerievsky はAgile2016 の基調講演「Modern Agile」において、アジャイルプラクティスは「補助輪」であると表現しました。
見積りは今、ソフトウェア開発の「補助輪」といえる段階に差し掛かっているのではないでしょうか。

私達のプロセスは完成されたものではなく、日々実験と失敗を繰り返して進化しているものです。

AEPから１０年、「見積りはソフトウェア開発において必須」という考え方もまた固定概念なのかもしれません。
我々の実践しているソフトウェア開発の形について紹介し、議論できればと思います。

北海道でそだち上京、23歳で組織初のスクラム導入。転職してなんちゃってアジャイルだと数年たってから気付いてスクラムの再導入。どちらも期待と不安がいりまじった時間をすごしましたが、とても楽しい時間になりました。私が当時どのようにスクラムを導入したり、変化させていったのか。そしていまならどうやるのかという考察をお話します。

　新卒向けインターンシップには企業と学生の「ミスマッチを埋める」という大きなミッションがあります。

日常の開発業務をスクラムで行い、総務ではカンバンを実践し、別の部門ではふりかえりが行われる私たちの様子をうまく伝えるには、インターンシップ自体をAgileに行い、Agileを体験してもらうことです。

　そんなインターンシップを行い、2年。

私たちがどんなインターンシップを行い、学生たちどのように未来の仲間を育てているのかをお話しさせていただきます。

数年前から札幌でスクラムを実プロジェクトにて実践してきました。

まわりではスクラムの事例が少なく、なかなか相談できる環境も多くはない状況でした。

その中での収穫は、自分たちで考え実践したことにより多くの失敗を経験することができたことです。

このセッションでは、これまでの経験から得た［失敗］そしてどのように［改善］していったかを紹介します。

スクラム視点での正解ではないかもしれないですが、これからスクラムに取り組む方や実践していてうまくいかない方の微力ながらヒントになればと思っています。

初めまして、北のグラフィックレコーダー、木村あゆみと申します。
北海道&札幌のトークイベントを中心に、話を絵と文字でリアルタイムに可視化する「グラフィックレコーディング（＝グラレコ）」を描いています。

北海道・札幌で講演を描くというスタイルでは、第一人者として活動しています。

エンジニアさんの間でも、
・チーム内外の相互理解を深めるため
・より良い場をファシリテートするため
などを目的として、ホワイトボードを活用したり、グラレコを活用したりする機会が増えていると感じています。

「絵が描けないと難しそう・・・」

と思われがちですが、ちょっとした道具や簡単なスキルを覚えるだけで、場をより良く可視化することができます！

現場で実践しているコサカさんの経験からも、
スクラムを通じて「現場をより良くしたい」と思っているみなさんにとって、グラレコのエッセンスは、即使える新しい武器になると考えています。

私たちと一緒に簡単なワークをしながら、グラレコを体験してみませんか？

楽しい時間を通じて仲間も増える、素敵な時間を過ごしましょう！

モブプログラミングは、ひとつの開発課題にチームメンバー全員での解決を試みることで、困難な課題の解決だけでなく、チーム内にノウハウ・スキルの浸透をもたらす魅力的な開発手法です。熟練者にとって開発を加速するだけではなく、新人教育や、新たなメンバーをチームに迎えいれるための教育手法としての効果の発揮も期待できます。

一方で、モブプログラミングは単にチームメンバーが集まって活動すれば成功につながるわけではありません。チームがモブプログラミングを軌道にのせるために試行錯誤する中で、効果を十分に発揮するための取り組み方、メンバーに求められる心得が見えてくると感じています。

このセッションでは、 1.新人チームとモブプログラミングを始めたとき、2. チームとして経験を積んでからのモブプログラミング、の2つの側面から、私達のチームがモブプログラミングの中で陥った苦悩と、その解決につながった要点を紹介します。