「どういう人がスクラムマスターをやればいいんだろうか？」

この質問はチームがScrumに取り組もうとした時によく出てくることの1つです
Scrumにあるプロダクトオーナー、スクラムマスター、開発者の3つの役割のうち、特にスクラムマスターはわかりにくいようで、この冒頭の質問が出てくるようです

しかし、一方で、ScrumGuideには以下にあるようにスクラムが機能するにはとても重要な役割を果たします

では、どのような人がスクラムマスターに向いているのでしょうか？
またプロダクト、チームや組織の状況によってどういうような人がスクラムマスターをするとより良いのでしょうか？

このセッションでは、「どういう人がスクラムマスターをやればいいんだろうか？」という質問に、ギルドワークスの現場コーチとして70チーム以上(すべてにスクラムマスターがいたわけではありませんが)を支援してきた事例から自分なりの経験や考えをお話できればと思います

よりよいスクラムマスターと出会える、見つける、なっていくヒントになれば幸いです

システム開発において、テストは切っても切り離せない存在です。
しかし、「カバレッジを満たすために書いている」「テストコードは書いたが、本番でトラブルが多発している」となっていませんか？
実は、テストコードを書き始める前に既に勝負は決まっています。

本セッションでは、実際に例題を使って皆さんにも考えてもらいます。そして、作業ではないテストについて“体験”し“実感”してもらいます。

本セッションの体験を通じて、「開発エンジニア」「テストエンジニア」がともに考えて作り出す、一歩先行くテストの世界をご紹介します。

アジャイルやスクラムについて学び始め、実際に取り組むと、その原則や考え方がソフトウェア開発の領域に閉じないことを日々実感します。原則を日々の仕事・生活に活かすことは重要ですが、「アジャイル」という言葉は抽象度が高く、開発のイメージも強いため、一般化してエッセンスを伝えるのに苦労している方も多いのではないでしょうか。

スクラムマスターとして、開発に限らず組織の全員が、アジャイル/スクラムの原則を理解して、実践できるよう支援することは重要な活動です。サイボウズでは、数年前から新卒の全社員（＋希望者は誰でも）向けの基礎研修としてアジャイル/スクラムの話をインプットしています。

こちらのセッションでは、サイボウズ社内で実施している研修（講義）を社外向けに再編成したものをお届けします。アジャイルやスクラムの考え方をベースに、エンジニアに限らず、チームワークを高め、成果を届ける仕事の進め方の基礎となる考え方・プラクティスを紹介します。

チームを「アジャイルなチーム」にどう変容させるかという点に苦慮されている方は多いと思います。

「チームの動きがなかなかうまくいかない」「あの人が変えられない」「自分のやり方が間違っている」などと悩んでいる方もいるのではないでしょうか。

そんな時は、一呼吸おいて「チーム」や「他者」ではなく「自分の内面」に目を向けてみましょう。

本セッションでは、チームではなく個人、他者ではなく自分に着目して「自分が変わることで、チームが変わる」という可能性を探ります。

登壇者は、2000年から、XP、スクラムをはじめとする様々なソフトウェア開発、アジャイルの手法・思想・価値体系、パタン・ランゲージやネイチャーオブオーダーなどの周辺の思想も含めて探求してきました。そして現在着目しているのが「個人の変容」です。

Kent Beckは以前、来日した時に「Social change starts with you.」と言う言葉を残しています。本セッションでは「自分が変わる」ということはどういうことなのかをワークを通じて探求していきます。

まず最初に、IKIGAIマップによって自分の今を客観視してみます。IKIGAIマップは自分の今の人生の様子をざっくり俯瞰することができるツールです。

その後、「マルチポ・テンシャライト」という「器用貧乏」を肯定的に捉える考え方をご紹介した後に、自分の内面に目を向けるワークをおこないます。

最後に、「ザ・メンタルモデル」をヒントにして、自身の無意識の振る舞いがどのような現実を作っているのかを見つめます。

自分を内観することで、どのように認知が変わるでしょうか？「そこにあるものを、ある」と認めることで何が変わるでしょうか？

そして、結果として自分の周囲がどう変化するのでしょうか？

様々な手法や考え方を紹介しながら、他者ではなく自分を見つめ、チームが変わるのではなく、自分が変わることで世界が変わるという意味とはどういうことかを一緒に探求しましょう。

このセッションでは，大学のPBL（Project Based Learning）でリーダーのいない組織を形成し，その活動の中でどのようにチームが成長してきたかをお伝えします．

いま，日本の大学ではPBLという学習方法が広く実施されています．PBLとは，実際にプロジェクトチームを形成してプロダクトを作る経験を得ることによって，チーム開発やチームマネジメントの手法について学ぶことができる学習手法です．私が所属する大学でもPBLのカリキュラムがあり，スクラムを用いてプロダクトを作るという経験を得ました．しかし，私たちのチームはほかのチームとことなりリーダーを決めずに活動してきました．そして，その結果として，とても良いチームを形成できたと感じています．

リーダーもいなく，開発初心者が集まるプロジェクトで，どのようなことに苦労したか紹介・分析し，そのうえでチームをより良くするためにはどうすればいいかお話ししていきます．

開発のマネージャー職として採用されたはずなのに、
気がつけばなぜかユーザー部署でのオペレーター業務をやらされ、
エンドユーザーからの電話を取ることになった弱虫のeroccowaruico。

サポート対象はバグだらけで仕様も不明確で資料もない大規模展開システム。
エンタープライズ環境に理解のないシステム開発部署とエンドユーザーの板挟み。
そして僕に下される開発部署とのコミュニケーション禁止の判断。

嫌なことから逃げることしか出来ない弱虫はチームのメンバー、そしてエンドユーザー、何より自分を守るためにユーザー部署内で小さなプロダクトマネジメントとエンジリアリングマネジメントを行い、ユーザー部署からそのシステムを支えるプロダクトを作り上げ、数万人のユーザーに届ける事にしました。

理不尽にも思える状況の中、ユーザー部署内でひっそりとプロダクトマネジメントとエンジニアリングマネジメントの手法を適用し続ける。
その目的とその中で起こした変化をお話しします。

（本発表は守秘義務に反しない内容とするため、脚色や匿名化を行なった内容となります。実際の会社名、案件内容は一切お話できません）

2012年に翻訳発売された『リーン・スタートアップ』を皮切りに仮説検証という考えが身近になりました。観察して仮説を立てて確かめるプロセスを通して、より効果的な手をうち、問題の解決やプロダクトの売上の成長につなげていく考えです。

仮説検証は特別な行為ではなく、私たちは日常的に「いまこうなっているから、これをしたらこうなるだろう」と推論しています。これも仮説検証です。

しかし一方でこんな声も聞きます。

「仕事の中で仮説検証はやってみているけれど、本当にこれでいいのかいまいちピンとこない」

私は『リーンスタートアップ』の登場以前から仮説検証の虜になり、この10年のあいだに書いた付箋だけで7万枚を超えました。そこで分かったことは、ちょっとしたポイントで善し悪しが大きく変わってしまうということです。

このセッションでは仮説検証の質に悩んでいる方に向けて仮説検証のエッセンスを共有します。時間のかかる仮説検証のテクニックとは異なり、普段使いできるため日常で無理なく使えます。一言で、ここを押さえるだけですごくよくなるキモをお伝えします。

特に、次のような仮説や問題定義を目にする方には抜群に役立つと思います。
「時間がない」「スキルがない」「チームがうまく連携できていない」

みんなで協調してものづくりをするときに、ひとりひとりの心の中では、どのようなことが起こっているでしょうか？それぞれの人のなかで、言語的であったり、イメージ的であったり、並行的に動いているのです。それを上手くものづくりに活用するための情報を認知科学の視点からお伝えできたらと思います。

みなさんが、わかりやすく理解するためのアクティビティもご用意できたらと考えています。
人数に応じて、少し参加者同士で話していただくかもしれません。

開発チームの改善

開発者からTechLeadになると、チームもシステムの一部だと気づきます。

ソフトウェアシステムを改善するように、私達はチームというシステムを改善することでユーザへより良い価値提供ができるようになります。

Tech Leadになったばかりの頃は、まだチームの問題を認識できておらず、ソフトウェアシステムの改善を行うことでチーム改善をしていました。

この改善は容易で、わかりやすいですが、問題の核にアプローチできず、部分的な問題を解決するにすぎません。

そのため一度立ち止まり、チームで話し合い、チームの問題を明らかにし、取り組むことにしました。

スケジュールと実績の乖離

私達のチームでは、開発スケジュールに対して実績が大幅に超えることが多々ありました。

正確なスケジュールを引くことは不可能ですが、一方でこの状態は望ましくありません。

実績が超える原因の多くの理由は、想定外の修正や要件です。

この問題に対処するために、チームでスケジュール作成に取り組むことにしました。

星野リゾートでは、企業の発展とともに、開発の内製化の促進を進めており、海外展開など次の局面を迎えていた。
しかし、2020年に入ると、全世界に混乱をもたらされたコロナの影響を受け、宿泊業には大きな打撃をもたらした。
もちろん、星野リゾートも例外ではなく、今後にむけた開発は全て白紙になるだけでなく、事業の継続も危ぶまれる状況に陥った。

そのような状況から、以下にして組織が同じ方向を目指し、短期間でリリースする体制を作り上げることで、危機的状況を脱し、飛躍できたのかをお話します。

NTTコムウェアはNTTグループの一員として、長年インフラを支えるキャリアグレード品質のシステムを提供してきました。
そんな我々が変化への適応を求められる今の時代において、アジャイル開発でプロダクトを開発する際に考えている『品質』について一部ご紹介します。

「つながってあたり前」「止まらないことがあたり前」というビジネス側やユーザーの期待と、アジリティ・価値を両立するために、
参考にしているモデルや取り組み方の考えなど、アジャイル開発の品質を考えている方々にとって参考になる知見を提供できればと思います。

本セッションでは、ゲーム制作会社で１メンバーとして新しい取り組みをしていくために重要なソフトスキルについて学びます。

まずは、第一歩として、個人からできるコミュニケーションの改善について学んでみましょう。

1. 修羅の国でのコミュニケーション入門 - 自分は悪くない、から脱却しよう
2. 過激な反応で関係を壊してしまう前に - Emotional Science
3. リモートワークは効果も問題も拡張する
4. 責任に目を向ける - 責任逃れの構図
5. チームの４つの毒
6. アジャイル戦略論 - 何かを始めるときの6つのステップ

人生初の開発現場は、6人のバックエンドチームがFAPI-CIBAという世界最先端の認証認可サーバー実装をしながら、モバイルアプリや銀行業務システムの開発まで担当する戦場でした———

毎日変わる要求と仕様。政治の絡む技術選定。立ち塞がる大量のRFC文書。

僕たちは、高速でアップデートするチームになる必要がありました。スプリント期間は、２週間から１日になり、モブプログラミングには、知識の新陳代謝が組み込まれました。肥大していく技術分野に追いつくために、勉強タスクを設けて学びを共有しました。

具体的な使いどころに関して、1日スプリントはプロダクトの方向性が定まっていない時に大変効果的でした。プロダクトオーナー側から細かいフィードバックが生まれ、プロダクト像がかたどられていくためです。モブプロは、新しい技術分野の実装時に、開発メンバー間の理解のキャッチボールを促した点で有用でした。

このセッションでは、そんな狂戦士の如く戦場を舞った、ぼくらの取り組みと考察を1日スプリント/モブプロ導入事例として共有します。

プロジェクトが始まったが、漠然とした課題解決方針のみで具体的な仕様はだれも言えない。。
誰も対象の技術分野の経験がない。。
これらの状況にある方にとって、日々の働き方のヒントになるような内容にしたいと思います。

リモートワークの課題をモブワークで解決する試み

金融系IT子会社にてプロジェクトマネジャーで奮闘中の谷口です。

出身は鳥取県で、山奥に生まれ、子供のころのお仕事は薪でお風呂を焚くことでした。裏山から薪を取ってきて小屋に保管し、夕方になると薪にマッチで火を点けお風呂を沸かしていました。暑い夏の日も、雪が積もる寒い冬の日も、毎日・毎日、お風呂を焚くことが日課でした。

そんな子供時代を過ごした私が、社会人となりエンジニアとしてシステム構築を担当し、大型のリニューアルを任されるPMとなった最近、ふと感じたことがあります。プロジェクトを成功させるカギは、「人」と「計画」。なかでも、多様な人で形成される「チーム」が担っているということです。そしてそのチーム形成は、子供のころのお風呂を焚くということとと、まさに考慮すべき点が一致していたのです。

・プロジェクトでは多種多様なメンバーが集まってきます。最初からやる気があるメンバーもいれば、モチベーションを下げていたり、口数少ないメンバーもいます。お風呂を焚く時だって同じです。全部が全部燃えやすい木はありません。中には湿っている木、なかなか火が付かない木、すぐに燃え尽きてしまう木、様々。

→　そんな多様なメンバーにたいして、どのように心に火を灯していければいいでしょうか。

・仕事だから強制すればよいという考えもあるかもしれません。ガスバーナーを使いますか？

→　それは、パワハラです。それ以上に、決して最後まで赤々とした炎で燃えることはないでしょう。

今回のセッションでは、私自身が子供のころに経験した「お風呂を焚くこと」をテーマにして、チーム形成の試行錯誤をお話しします。チーム形成に絶対的な正解はありません。ただ、私の試行錯誤を、お風呂焚きのストーリーを通じて、みなさんと一緒に考えていくことができればと思います。

世の中には「知識やツール」を知っているだけの人は数多くいます。でも、大切なことは「失敗しながらも実践していく」ことだと思います。

聴講者のみなさんと、心の炎を扱うお話ができればと思います。