Scrum Fest Niseko 2024に参加してきました

## はじめに

11/1-2に開催されたScrum Fest Niseko 2024に参加してきました。

https://www.scrumfestsapporo.org

主に以下の内容について思った事を書き連ねさせていただきました。

- 1日目
  - Keynote Session #1
  - OST #1
  - 夕食（＋懇親会？）
- 2日目
  - Keynote Session #2
  - OST #2

この会を通して以下のような事について考えるきっかけをいただきました。

- scrumの文脈におけるcommitmentとは？
- scrumでうまくいっている状態とは？
- 要件定義がどのように品質に影響を与えうるか？
- Legoを使った自身の価値観の再確認

## Keynote Session #1

開会の挨拶の後、永瀬美穂さんによる基調講演がありました。「SCRUM BOOT CAMP THE BOOK」の著者の1人でこの界隈では非常に著名な方です。

https://www.amazon.co.jp/SCRUM-BOOT-CAMP-BOOK%E3%80%90%E5%A2%97%E8%A3%9C%E6%94%B9%E8%A8%82%E7%89%88%E3%80%91-%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%83%81%E3%83%BC%E3%83%A0%E3%81%A7%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA/dp/4798163686

私の主観で簡単にまとめさせていただくと「commitmentとは？」というお話でしたが色々と考えさせられる内容でした。

「scrum commit」で検索すると「AIによる概要」として以下が表示されます。

> スクラムにおけるコミットメントとは、スクラムチームがゴールを達成し、お互いにサポートすることを確約することです。スクラムチームのメンバーは、スプリント計画プロセスや顧客とビジネスの全体的な成功にコミットしていることを示す必要があります。﻿
> 
> スクラムでは、チームで作業に優先順位をつけ、2週間のスプリント内での一定数のタスクの完了にコミットします。メンバーは、非現実的なスケジュールやタスクを受け入れるのではなく、各自の能力に応じて業務を拡張し、チームの期待に応えることでコミットメントを示します。﻿
>
> スクラムは、ソフトウェア開発チームが一丸となって迅速に開発を進めるための方法論をまとめたもので、アジャイル開発の1つの手法です。

commitmentは日本語で「確約」みたいに訳される事が多いようですが、agileの文脈では誤解につながりやすいようです。

commitという言葉の裏には「自己決定」や「内的な意思」が含まれており、本人がその行為を選択した意思的な行為という意味が含まれるようです。つまり、外的な約束ではなく内発的な決断を伴う状態とのことです。

国際紛争の研究でも戦争の原因の1つとしてcommitment problemというものが挙げらていたりします。

簡単にまとめると、どう考えても一方にとって戦争を仕掛ける方が利益的で、交渉による平和的解決が絶望的な状態を指しています。両者とも戦争を避ける事をcommitできない状態なのでcommitment problemと呼ばれています。

私の理解ではcommitという言葉の裏には「その選択が一番本人にとって合理的」という意味が隠れているように思います。複数ある選択肢の中でもそれが最も合理的だからこそcommitする状態が維持できる的な（ゲーム理論オタクなもので）。

これも含めると、commitとは「設定した目的達成のため主体的に全力で取り組む」みたいな事なのかなと思いました。各memberにとってそうする事が一番得だからこそ、全員が主体的に全力で取り組む状態が実現できるのかなと。

だからこそ各memberにteam firstで行動する事による小さな成功体験を積んでもらう事が大事なんだろうなと思ったりしました。

commitmentは外側から強制させられるものではないので「他人に何かをcommitさせる」という表現には必然的に矛盾が生じる事になります。

長瀬さんはcommitmentを強要する事を「ハリソニズム」と表現していましたが、「地面師」とやらをまだ観ていない私は笑う事にcommitできず空気を読んで空笑いが精一杯でした。。。

最後の「この2日間はコミットメントの練習をしてみましょう」という言葉のおかげで、いかなる状況でもできる範囲で自分にできる貢献をしようという意識が少しは芽生えたように思います（実際に行動に移せてかはともかく）。

以下が講演で使用されたslidesのspeakerdeckです。

https://speakerdeck.com/miholovesq/commitment-vs-harrisonism

## OST #1

基調講演の後にはOSTが行われました。最初にhostを募る時間があったのですが、私は特に提案せずでした。時間の枠は3つで、8卓に分かれて行われました。

![IMG_2500.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2885056/efaa18b5-30e2-83ac-7e61-23a62f75c5df.jpeg)

私が参加したのは「社内でスクラムの仲間を見つけたい」と「スクラムがうまくいっているってどんな状態ですか？」と「テストの取り組み方を考える」です。

1本目はばっさーさんがhostの「社内でスクラムの仲間を見つけたい」に参加しました。「社内で勉強会を開催すると良い」や「勉強会する場合はこうすると良さそう」といったたくさんの助言が飛び出しました。個人的には社内に外部で登壇してる人がいるとの話だったので、そこに突っ込んでいって懐に入り込むのが一番近道になりそうかなと思いました。私も社内でどうやってagileを広められるか考えていたりするので、参考になるご意見をたくさん伺う事ができました。

2本目はteppeiさんをhostの「スクラムがうまくいっているってどんな状態ですか？」に参加しました。私が当初考えている「うまくいっている状態」はそもそもteppeiさんからすると「当たり前の状態」である事に気づかされると同時に、teppeiさんの視座の高さ（＝私の低さ）にハッとさせられました。teppeiさんのteamでは全員が不満なくまわっている状態にはあるが、businessとして成果をあげられている状態ではないかもしれない、それができているscrum teamってどんな感じ？という問題意識があったようです。社内にいるだけではこの感覚を得る事は不可能に近いので、この話を聞けただけでもこの会に参加した価値があったなと感じました。

![IMG_2495.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2885056/4d64c072-38cc-4954-8706-fdf50c4fdb20.jpeg)

3本目はnemorineさんがhostを務められた「テストの取り組み方を考える」に参加しました。私が担当になった新projectで品質を上げるためできる事はあるのか興味があったのとQAに関して完全に無知だったので参加してみました。業界は微妙に違えども、皆さん同じような事で悩まれているんだなと感じました。過去に確認漏れがあったところなどを共有する事が大事であると同時に、QAの人達も含めて要件を理解した上で進めないとerrorを減らしていくのは難しいのかもしれないと思いました。

## 夕食（＋懇親会？）

夕食で最も印象に残っているのは旭川にてconferenceを開催されたNishiharaさんのマシンガントークです。Nishiharaさんはこちらのconferenceの実行委員長を務められたそうです。

https://note.com/tomio2480/n/n24b68c1db6e5?sub_rt=share_h

とにかくすごい熱量を持った人で圧倒されっぱなしでございました。

夕食に続いて懇親会も行われました。私の勘ではおそらくこういう時間に最も面白い濃い話がされるのではないかと思います。しかし私は今回ほぼ徹夜で乗り込んだためかなりヘロヘロだったので部屋で大人しくしていました。次回は前乗りするなどしてこういう場に参加できる状態にしないといけないなと思いました。

2日目は寝坊してSponsor Sessionには参加できませんでした。正直申し上げると、ギリギリ朝食に間に合う時間だったので朝食会場に向かい、朝食後会場に着いたらSponsor Sessionが終了したところでした。

## Keynote Session #2

2日目はSponsor Sessionの後、RDRAを開発された神崎善司さんによる基調講演が行われました。設計や要件定義にも興味があったので非常に楽しみにしていました。

まだまだRDRAの内容を咀嚼しきれていない歯痒さは残りましたが、間違いないく今後学んでいく価値のあるframeworkだと思いました。

今回のお話で特に印象に残ったのは「手戻りが多くなるのは要件定義に問題があるから」的なお言葉でした。

私の経験でも不具合が起きる結構な割合をこれが占めていると思いますし、逆に要件が明確で認識齟齬のない状態で開発に着手できた場合、errorが発生する確率はかなり低いと感じています。

ふわっとした要件の理解で開発に着手すると大抵そのふわっとしている部分から想定できなかったerrorが発生します。だからこそ上流で要件を明確にしておく事が非常に大切だなと改めて思いました。

RDRAは要件を明確にして業務側と開発側の認識を揃えるために非常に有効的なframeworkだと感じましたし、これを使いこなせるようになりたいと思いました。

AIを用いて要件定義の効率化を試みている部分も拝見できましたが、「AIは文脈を理解しているわけではない」的な言葉も印象に残りました。ちゃんと文脈を理解した上で効率化のためにAIを使用できれば非常に価値のある事だと思いますが、よく分からない状態でAIを使っても扱う側の力量次第では危険を伴うと感じました。

## OST 2日目

基調講演後、昼食を挟んでOSTが行われました。前日同様時間の枠は2つで、8卓に分かれて行われました。2日目も特に提案できなかった事は悔いが残りました。

![IMG_2510.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2885056/c8c45e6f-ed2c-01c2-04d1-e1f31909ec45.jpeg)

私が参加したのは「レゴブロックでワーキングアグリーメントを作ってみよう」と「多国籍チームで大変だったこと、気をつけることを共有する会」です。

1本目は「レゴブロックでワーキングアグリーメントを作ってみよう」に参加しました。OSTというよりワークショップという形式でした。

30分という枠でできる事は限られてはいましたが、Legoを使うという作業が童心に帰る感じがあって楽しかったです。それ以上にLegoを使って価値観を表現できるという事を体感できたのは良い経験になりました。

私が作ったのは↓の「多様性・相互尊重」なのですが、自分が今のteamで大切にしている価値観を再認識する事ができました。

![IMG_2505.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2885056/54b96984-04e9-7e27-3356-f42c10737770.jpeg)

2本目はこうざきさんがhostの「多国籍チームで大変だったこと・気をつけることを共有する会」に参加しました。海外の開発者が日本の習慣に合わせられない部分があると不当に評価される事があるというのが問題意識としてあったようです。私が経験してきた事と重なる部分があるのですが、会社や上司が定めた評価軸を変えるのは不可能に近いので、開発者に寄り添いつつも擦り合わせていく作業が大事なのかなと思いました。

## まとめ

心から参加して良かったと思いました。特に以下のような事について考えるきっかけになりました。

- scrumの文脈におけるcommitmentとは？
- scrumでうまくいっている状態とは？
- 要件定義がどのように品質に影響を与えうるか？
- Legoを使った自身の価値観の再確認

私は直前まで参加が確定しておらず、特に運営の上戸鎖さんには大変なお手数をおかけする形になってしまいましたが、ご好意で参加する事ができ感謝の気持ちでいっぱいです。ニセコに来たのは初めてでしたがとても素敵な街だと思いました。

運営の皆さん、参加者の皆さん、本当にありがとうございました。是非また参加したいです！