★★★Deep Diveシリーズ第2弾!!★★★ (シリーズなのか)

前回のプロダクトバックログ（https://slide.meguro.ryuzee.com/slides/107）に引き続き、今回はスプリントプランニングのすべてを完全解説!!

スクラムにおいて、スプリントの開始時にまず行うのがスプリントプランニングです。従来型のプロジェクトにおける失敗理由の多くが出だしで躓いたせいだと考えると、スプリントの最初のイベントであるスプリントプランニングも重要であることがわかります。

ここで計画づくりに失敗してしまうと、インクリメントを届けられず、スプリントレビューは針の上のむしろになり、スプリントゴールも達成できなくなってしまいます。

一方でスクラムガイドを見ると、扱うべき3つのトピックは明記されているものの、具体的なやり方や手順は書かれていません。結果的にスクラムの価値基準や原則にそぐわないことをしてしまっている例も散見します。

以下の項目のいくつかは、一般的に望ましくないとされています。どれが望ましくないものか考えてみてください。

• (a) 選択したプロダクトバックログアイテムのうち、必達のものを完成させることをスプリントゴールにする
• (b) 選択したプロダクトバックログアイテムの担当者を決めて、その人がそのアイテムの作業計画をたてる
• (c) できるかぎりReadyなプロダクトバックログを用意するのが望ましいが、必要ならスプリントプランニングで、選択予定のプロダクトバックログアイテムの中身を見直したり再見積もりする
• (d) ステークホルダーと約束した期日があるので、完成できる気がしないプロダクトバックログアイテムもとりあえずスプリントに入れる
• (e) スプリントプランニングの前に、先にタスクに分解しておく

もちろんスクラムガイドを解釈して、どのように進めるかは、スクラムチームごとに試行錯誤していけばよいのですが、とはいえ体系的に知識を押さえておけば（SCRUM BOOT CAMP THE BOOKも是非読んでみてください）、陥りがちな罠は避けられます。

本セッションでは、スプリントプランニングをうまく行うための基本から応用まで、Scrum Alliance認定スクラムトレーナー(CST-R)、認定チームコーチ(CTC)の吉羽が体系的に解説します。

なお、望ましくないものは、(c)以外のすべてです。

プロダクトバックログのすべてを完全解説!!

スクラムにおいて、プロダクトバックログは肝となる要素の1つです。プロダクトバックログがなければスプリントは始められないですし、単に要件を切り刻んで並べたようなプロダクトバックログでは変化にも対応できません。

スクラムガイドを見ると、プロダクトバックログの作り方、書き方、維持や管理の仕方については、多くは触れられておらず、多くの人は実践で試行錯誤しながらより良いプロダクトバックログを目指して改善を続けられているのではないかと思います（それはそれで素晴らしい）。

一方でプロダクトバックログを誤解しているのもよく見かけます。すべてをユーザーストーリー形式で書く必要もないですし、全部を同じ具体性にする意味もありません。すべてのプロダクトバックログアイテムをプロダクトオーナーが作らなければいけないわけでもないですし、すべてのプロダクトバックログアイテムを実装しなければいけないわけでもありません。Webアプリケーションでログイン機能がプロダクトバックログの上位に必ず来るわけでもありません。

本セッションでは、プロダクトバックログをうまく使えるようになるための基本から応用まで、Scrum Alliance認定スクラムトレーナー(CST-R)、認定チームコーチ(CTC)の吉羽が体系的に解説します。

昨年のスクラムフェス大阪で好評だった「旅するAgile本箱LT」再び！

旅するAgile本箱は、これからアジャイル開発に取り組もうとしている人たちや既に実践している人たちのために、関連書籍を段ボール2箱、会社やイベントへ貸出す活動です。 これまでに24ヶ所へ旅してきました。 本のセレクトは、アジャイル開発実践者の投票により成り立っており、含まれている本の中には、一般に「アジャイル」「スクラム」や「ソフトウェア開発」に分類されない本も混じっています。 それら含めて、この本箱にある本たちは実践者を何らかの形で助け本たちです。

今回の旅するAgile本箱LTも、実践者の皆さんを後押しした一冊、ないしは、心震えた一冊、ご自身で手がけられた一冊、かけた思いの丈を、語っていただきます！

★旅するAgile本箱LT2021：発表順(予定)

1. 前説:旅するAgile本箱って?
2. 細谷 泰夫さん『Ultimate Agile Stories - 10th Anniversary』
3. 根本 紀之さん 『ソフトウェアテスト技法練習帳』
4. 鳥井 雪さん 　「ダイバシティな絵本」のご紹介(順不同)
   『王さまと王さま』 『いろいろいろんなかぞくのほん』 『ふたりのママの家で』 『ジュリアンはマーメイド』 『タンタンタンゴはパパふたり』『ねえさんの青いヒジャブ』『300年まえから伝わる　とびきりおいしいデザート』
5. 吉羽 龍太郎さん「エンジニア的翻訳術」
6. 近藤 佑子さん 「大学生に『書くこと』の授業をしたときに引き合いに出した本」
7. 佐藤 竜也さん『達人プログラマー 第2版』
8. 島田 浩二さん『ユニコーン企業のひみつ』
9. 結び

●ハッカーライフラボスタッフ
・司会：コサカ ジュンキ
・配信：アジャイル札幌のみなさん

2020年12月に弊社CEO原田騎郎がScrum Alliance認定スクラムトレーナー（CST-R）となりました。

この資格の誕生した背景、できることできないこと、これによって何が変わるのかというお話をします。

• 「CST-R」という資格はなに？
• 普通のCSTと何が違うの？
• どんなことを教えてくれるの？
• どんなことを教えてくれないの？
• いつ受けられるの？

スクラムガイドには「完成」という単語が36回、「完成の定義」が12回登場します（弊社調べ）。ほかの代表的な単語を調べてみると、スプリントバックログは16回、スプリントレトロスペクティブは12回です。
つまり、スクラムにおいて「完成」は非常に重要な意味を持つことは明らかです。

しかし、「完成」に対する認識がスクラムチームのなかで違ったり、組織での品質の基準をまったく考慮せずに開発を進めていった結果、リリース直前に品質上の大きな問題が起こったといった話もよく聞きます。

ネット上の記事を調べても、「完成」が重要な意味を持つ割に「完成」とは何なのか、どのように「完成」を定義し、どうやって「それを守っていくのか」というノウハウはあまり出回っていません（と認識しています。プロダクトバックログの話なんかは山のように見かけるんですが）。

そこで、本セッションでは、「完成の定義」をできる限り深堀りし、今後みなさまが「完成」を守っていく上でのヒントを共有します。

DevOpsという言葉の世界はますます拡がり、様々な○○Opsが生まれました。DevOpsDays Tokyoに集まったプロポーザルを見ても、たくさんのDevOpsがあることがわかります。定義を1つに統一する必要はないですが、自分の中のDevOpsを更新し続けることは大切だと思います。

そこで今回の朝まで生DevOpsは「結局DevOpsとはなんだったのか」をテーマに、定義の話を超えてDevOpsから我々は何を学ぶべきなのかについて考えていきたいと思います。

パネラーは随時追加していく予定です。
また、このパネルディスカッションは飛び込み参加可能なオープンパネルディスカッションです。

世の中でアジャイル開発が一般的になるにつれて、アジャイル開発を支援する「アジャイルコーチ」という職種や肩書を見かけることが多くなってきました。
アジャイルコーチとは組織がアジャイルなやり方で成果を出せるようにするために、組織的な観点、技術的な観点、プロダクトの観点などさまざまな観点から支援する役目です。
アジャイル開発に慣れていないチームには、アジャイルコーチは必要な存在だと言ってよいでしょう。

一方で、アジャイルコーチといえば、「めんどくさい」「マサカリ投げる」「上がった感」「単価が高い」「実際の効果がよくわからない」といったイメージがあります。
これらはコンサルティングを始めとした支援系の仕事に対する共通のイメージでもありますが、銀の弾丸思考の表れでもあります（アジャイルコーチがあなたの問題をすべて指摘し、魔法のように解決してくれるわけではなく、あくまで主体はスクラムチームです）。

本セッションでは、アジャイルコーチとは何なのか、実際にアジャイルコーチをどう活用すれば良いのかを、日本で唯一のScrum Alliance Certified Team Coach(CTC)で実際にアジャイルコーチングを有償サービスとして提供している現役アジャイルコーチが解説します。

デマルコの名著『ピープルウェア』では、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」と言っています。

アジャイルやスクラム界隈でも、心理的安全性をどう醸成するのかといった話題やレトロスペクティブでいかにアイデアを引き出していくか、といったテーマに関心が集まっているようです。

しかし、これは本当に今あなたのチームがフォーカスすべき問題なのでしょうか？

スクラムで成果を出すためには、以下の3つの要素が必要です。

• 適切な課題を設定する力（プロダクトビジョン、ミッション、ゴール）
• 課題を解決するソリューションを構築する力（言い換えれば技術力）
• これらを上手く進める力（プロセスやチームの関係性など）

心理的安全性だけでは成果は出ません。ダメなビジョンをいくら良いチームで実現しても何の価値もありません。良いビジョンでも技術力がなければ時間がかかってマーケットに出せないこともあるでしょう。

このセッションでは、あなたのスクラムチームが改善すべき問題にはどのようなものがあるのか、それらの問題の中から取り組むべきものをどのように選ぶべきか、説明します。

多くの組織では、うまく進めるためのショートカットやツールを求める傾向にありますが、足元が固まっていない状態でさまざまなプラクティスやツールを導入しても無意味で、混乱したまま成果も出せずに終わってしまうこともあります。また、そのような状態で大規模な開発を進めるのは自殺行為です。

本セッションでは、アジャイル開発をうまく進めるために最低限考えなければいけないポイントをスクラムの文脈で紹介いたします。これらのポイントは多くのアジャイルコーチングの場において強く伝えていることです。

DevOpsには技術的な側面だけでなく、開発や運用をはじめとするさまざまな部門を繋げる組織文化を構築するという重要な側面があります。 つまり単にDevOpsツールなるものを導入したりアジャイルなプロセスを導入すれば良いというわけではありません。

本セッションでは、主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を説明します。

Scrumではプロダクトバックログを用意し、そこからスプリントが始まることが前提になっています。しかし新たなプロダクトやプロジェクトを開始する際には最初からプロダクトバックログが用意されているわけではなく、ほかにも準備をしなければいけない項目が多数あります。本セッションでは最初にスプリントを開始する前までにやるべきことを過去のコンサルティング事例を踏まえて解説します。

Scrum assumes that there's a product backlog and then sprints can be started from there. However, when starting a new product or project, the product backlog is not prepared yet from the beginning, and there are many other items that must be prepared. In this session, I will explain what should do before starting sprint #1 based on my past consulting experience.

As an agile coach, I've been finding and watching lots of failure or mistake or misunderstanding related to Scrum. This session will introduce common pitfalls that many team encounter and will provide the way how to avoid those pitfalls.

アジャイルコーチとしてスクラムに関する多くの失敗や間違い、誤解を見てきました。本セッションではよくある落とし穴や問題、間違いと、それをどう避けるかについて解説します。