スクラムガイドには「完成」という単語が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.

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