Scrum初心者が「Scrum Fest Sapporo 2020」に参加してみた話 ~Day1~

![scrumfestsapporo2020-1024x803.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/855853/78aed6e4-38a3-e2bb-facc-d2b4e9bedd99.png)
https://www.scrumfestsapporo.org/

<h1>【Scrum Fest Sapporo 2020】にDay1参加してきました！</h1>
本日は2日目です！
本日も昨日の記事同様、セッションを聞きながら記事を書いていきたいと思います！

**そもそも何故聞きながら記事を記載しているのか？**
セッションに参加しながら記事を記載することで、カンファレンス終了時に他の参加者との情報や感想を共有や、講演者への感想などをお伝えするために行っています！
またリアルタイムで記事を作成することで、その場の臨場感？熱気？ようなものが少しでも伝われば・・・的な気持ちもあります(笑)

<h1>Day1 【みんなで創る基調講演（仮）】</h1>
このセッションで最も印象があったのが、以下の問題です。

<h5>秘書問題</h5>
>問題の前提
>>- 秘書を1人雇いたいとする。
- 100人が応募してきている。
- 100という人数は既知である。
- 応募者には順位が付けられ、複数の応募者が同じ順位になることはない（1位から100位まで重複無く順位付けできる）。
- 無作為な順序で1人ずつ面接を行う。次に誰を面接するかは常に同じ確率である。
- 毎回の面接後、その応募者を採用するか否かを即座に決定する。
- その応募者を採用するか否かは、それまで面接した応募者の相対的順位にのみ基づいて決定する。
- 不採用にした応募者を後から採用することはできない。
- このような状況で、最良の応募者を選択することが問題の目的である。

>100人いたら、始めの36人は有無を言わせず不合格にする。37番目以降は36番目以前のもっともいい人と比較し、いい人が出てきた時点で採用する。
この37%という数字は感覚や経験則なもので実際活用している人はほとんどいない。

この問題のように感覚や経験則で物事を進めてしまっていいのでしょうか？

私たちは、問題に対する経験があると、「こうすればいい」と思う様になってしまいます。
それでは、自己能力を成長させることはできません。

自己能力の成長には根拠が必要なのです。

<h3>感想</h3>
日本人は感覚的に物事を進める習性があり、学術的根拠に基づいていません。その結果「正しい答え」という幻を見続けることで満足しがちだと思いました・・・（自覚あり）

実際自分も感覚的に行動している節が多々あるため、根拠に基づいた行動をすることで、最適解に少しでも近づけるようになりたいと思います！


<h1>Day1 【(自称)エバッキーの愛弟子！が札幌でエンタープライズシステム開発のスクラムマスターをしてみたお話</h1>
このセッションでは、waterfall型とScrum型が融合したチームでのお話を聞くことができました。

<h5>分業体制によるスクラムの不安定化</h5>
>テストチームは、分業していることでデメリットも多かったが、メリットもあった。
一部はウォータフォール、一部はスプリントで行っている。
単純に、すべてスクラムで対応しても問題は起こる。

<h5>スクラムマスターとして目指すべき方向性、Visionは？</h5>
>現状を早く論理的に分析して、あきらめずに変えていくことが大切だと思っている。
勇気、精神力、忍耐力、交渉力が大切。
また、可視化、ロジカルシンキングをもって、人に説明していくことが非常に重要と感じている。

<h3>感想</h3>
ウォータフォール型からスクラム型に移行することを検討しているチームにとって、とてもためになる話だったと思いした。
まだウォータフォール型が主流の企業だと、急にやり方を変えるより、この方法から始めた方がいいと思いました。

<h1>Day1 【これまでと違うやり方に取り組む時にうまくいくかもしれない方法とその落とし穴】</h1>
このセッションでは題名通り、うまくいくかもしれない方法とその落とし穴についてお話していました。

<h5>うまくいくかもしれない方法</h5>
>・とにかく実際の利用者にあって、観察し、話を聞き、違う視座を得る
・必要な人が必要な判断をできるように情報を行き渡らせる
・判断できない人は情報が足りていないのかもしれない

<h5>やってみたこと</h5>
>- 「やってみる」ことを続ける
	- 壁に張り出して見える化
	- ランチ勉強会
	- ユーザーを読んでのユーザーテスト
- 相手の世界の言葉で話す
	- 関心のある領域はそれぞれ違う
	- 「開発が楽しくなる」は伝わらないこともある
	- 売上、利益、ユーザ数など伝わる言葉で話す必要がある

<h5>起きたこと</h5>
>- 先にうまくやれそうなことがわかったので乗ってくる人が増えた
- 「わかってくれない」という衝突が減った
	- 違うものを見ていることが前提になった


<h5>うまくいくかもしれない方法</h5>
>- あれこれ説明するより、やってみせる、一緒にやってみる
	- 「こういう事が起きたのでどうしましょうかねー」
- 提案ではなく相談からする
	- 頼られるとみんな気持ちいい
- 積極的な反対者を作らない
	- 積極的な反対者の対応に労力がかかる
- 人にはそれぞれのタイミングがあるので気軽に待つ
	- 「かんふぁれンスに参加してきた」と伝えても伝わらないことも。

<h3>感想</h3>
これまでの経験をもとに、具体的なノウハウを共有してもらえてとても参考になりました。
思い込みを解消するためにするためにもまず一緒にやってみるのが大事っていうのはすごく共感と同時に、とてもありがたいと思いました。

<h1>Day1 【アジャイルに向かう組織に聴いてほしいアジャイルへの第一歩】</h1>
こちらのセッションでは、アジャイルが浸透してない組織にアジャイルを取り入れるときに何をすればよかったかのお話を聞くことができました。

<h5>こんな人向け</h5>
>- アジャイルを取り入れたい人
- アジャイルやりたいけど何やったらいいんだろうという人

<h5>初めてのスクラム</h5>
>- 社内部門の業務アプリを刷新しようとした
	- 勉強会を開いてスクラムとは何か学んだ
	- プロジェクトのルールや体制を決めた

<h5>起きたこと</h5>
><h5>#1</h5>
>>それぞれアジャイルってこうでしょ！という考え方がぶつかりあう

><h5>#2</h5>
>>依頼者は発注側であって、受注者が御用聞き状態

>まずはアジャイルを知ろう、それがスタートライン。WFとアジャイルを比較する人が多いけれど、そもそも軸が違う。
そして、アジャイルの誤解は最初に払拭しておくこと
そうすることで「想像していたものと違う」ことを理解してもらえる。
結果、長期計画が立てにくいということも理解してもらいやすくなる。

<h5>目的の認識を合わせる</h5>
>- 計画書など、明文化されていても、個々の受け取り方に微妙に差異があったりする。

>インセプションデッキは全部できたほうがいいけど、最低限「1. われわれはなぜここにいるのか」と「2.エレベータピッチ」はやっておいたほうがいい。
開発中に何度か実施して見失わないようにするのも良い
フランクにアイスブレイクっぽくやってみても面白い

<h5>チームのルールを決める</h5>
>スプリントの期間、ツールなど、狙いを持ったうえでルールを決めることが大切。
狙いを持っておくことで、ふりかえふりかえることができる。
一度決めたルールに固執しなくてもよい。スプリントが終わるのタイミングを待たなくても、スプリント中に変えたって良い。

<h5>まとめ</h5>
>得たいの知れないものを独自解釈しないようにする。
いきなり決めるよりはゆっくり頭を切り替えることが大切。まずは、よくわからない状態からチョットワカル状態にすること。

<h3>感想</h3>
独自解釈の観点で、自分が間違って認識してしまっていることは自分からはわからないと思いました。その間違いに気づくためには、ルールであったり意味を明確にすることが大切だと思いました。

<h1>Day1 【ゼロからつくったリモートスクラムチームはスクラムに挫折し解散しました】</h1>
このセッションでは初登壇ということで、発表者の方の実体験をお話しされていました。

<h5>スクラムやってみて思ったこと</h5>
>- スクラム難しい
- でもじょうずにソフトウェア開発したい
  - 楽しく
  - みんなで
  - 儲かるものを

<h5>プロジェクト</h5>
>新しいコンポーネントをつくり、新しいソリューションを提供する。
ウェブ開発との違い：いろんな会社の機器と相互接続する必要があるため、国際標準の企画が厳密に決まってる

<h5>チーム結成前夜</h5>
>お客様になりそうな人たちと一緒に「こういうもの作りたい！」となっている状態。
必要なコンポーネント・マイルストーンも見えている状態で、早く開発するためにスクラムでやることに。
でも、開発は始まらない。開発者も集まらない。

>救いを求めてOSTへ。

>まずはマイルストン・スケジュールの合意とスケジュールの相談を行い、
メンバーは挙手制。60％以上時間をさける人を求めた。
前提知識を得るために課題を出す（SCRUM BOOT CAMP THE BOOK）

<h5>チーム結成</h5>
>集まった人たちはモバイルコアの開発、スクラム開発したことがない人たちばかり。

<h5>立ち上げ期</h5>
>1週間スプリントでフルリモートでスクラムを開始。
出勤時間がバラバラなので、デイリースクラムは非同期で実施。slackに何かひとこと＋やったこと、困っていることを書くことに。

<h5>自走期</h5>
>- SM/TL不在によりチームは自走しだす
	-自分たちでバックログを作る
- タスクを人ごとに割り振っていたが、だんだんとタスクの境界線がなくなってきた 
- ぬるっと進みだした


<h5>いつも通り進める期</h5>
>- slackへの報告は面倒なので廃止
- スラムでない 
- 自信を無くす


<h5>ふりかえって</h5>
>- メンバーはみんなゼロからはじめた
- 会社としても初めてスクラムやった 
- このチームでは「スクラムじゃない」状態から開発が進んだ
- スクラムのフレームワークにのっとるよりだいじなことがあった
- 経験と学習をくりかえして、じょうずにソフトウェアをつくれるエンジニア・会社になりたい

<h3>感想</h3>
初登壇のことや、内容からとても行動力のある方だと思いました。自分は行動力があまりない方なので、積極的に行動に移したいと思います。

<h1>Day1 【日本にJoy,Incを創る！どん底からスタートしたぼくらのジョイインクジャーニー7年間の軌跡　Scrum Fest Sapporo特別編】</h1>
このセッションでは「joy,inc」という書籍をもとにお話しされていました
その際に出てきた名言をピックアップします！

<h5>会話会スペースとノイズはチームワークの魔術を引き起こす機会を作るための重要な要素</h5>
>一見仕事とは関係のない話に思えても、そこから価値が生まれることがあります。

<h5>会話が関係を作り関係が価値を作る。</h5>
>コミュニケーションパスを繋ぐことで、技術などの共有が行われます。だからこそ、積極的にコミュニケーションを行います。

<h5>「すばやくたくさん間違えよう」という文化（許可を求めるな謝罪せよ）</h5>
>「こうすればいいんじゃないか？」と思ったことを、規模の小さい実験としてたくさんやりましょう。もし失敗したときは謝罪して、実験をやめればいいのです。

<h5>「メンローは完璧でない」</h5>
>メンローは完璧ではありません。ただ、人より多く失敗して経験があるのです。

<h5>大事なリソースは人であってスキルではない。人を維持するためには何でもやる。</h5>
>メンローではスキルより人を大切にします。スキルではなく人として必要とされるため、仕事において幸福度が上がります。


<h3>感想</h3>
「joy,inc」は自分も読みました！
「仕事を楽しむ」「当たり前のことを当たり前にするには？」など、
仕事をするうえで大切なことがとても書かれている書籍で、とても面白かったです。
だからこそこのセッションは共感できる内容が多く、とても分かりやすかったです！
　
　
　
　
　

「Scrum Fest Sapporo 2020」も明日が最終日・・・
引き続き記事をアップしますので、楽しみにお待ちください！！