紙粘土スクラムに参加した

はじめに

　この記事はBBSakura Networksアドベントカレンダー21日目の記事です。遅刻です！すみません！
adventar.org

　社内のプロジェクトで野良スクラムマスターみたいなことをしているけどスクラムマスターの仕事がわからなくなってしまい、12/21（土）に札幌で開催された紙粘土スクラム 2019に参加してきたのでそこで学んだことを書きます。

きっかけ

　前回の記事（アジャイルな家庭を目指して - 猫が吠える）は子育てエンジニアアドベントカレンダーに参加して書いた記事だったのですが、その翌日に参加されていた id:izumii-19 さんが私の記事にリンクを貼ってくださいました。そこからizumii-19さんのブログを読みに行ったところ「アジャイル札幌」というコミュニティがあることを知り、週末に紙粘土スクラム（スクラムのやりかたに則って、紙粘土を使ってチームで動物園を作るワークショップ）が開催されることを知りました。ちょうどスクラムについてやスクラムマスターの仕事について悩んでいるタイミングだったので、参加してきました。

悩んでいたこと

　社内で11月から始動したプロジェクト（このプロジェクトの悩みについて詳しくは以前の記事に書いています）でスクラムを取り入れました。私はチーム開発というものをちゃんとやったことがなく、そもそもソフトウェアを書く経験も2年そこそこしかないのだけど、それも一人開発みたいなもので、今回初めてチームで開発に取り組んでいます。プロジェクト開始にあたりスクラムを取り入れようということになり、10月ごろに初めて『SCRUM BOOT CAMP THE BOOK』を読んでスクラムを勉強しはじめました。これはおもしろい！と思って、『アジャイルサムライ−達人開発者への道−』、『エッセンシャルスクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection)』、『アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き』などを読んでアジャイル／スクラムの考えかたが好きになり、プロジェクトでは野良スクラムマスターみたいなことをやり始めたところでした。
　プロジェクト開始当初、私は開発には入らずプロジェクトの推進のみをしていました。まず関係者に声をかけてキックオフを設定してビジョンとスケジュール・マイルストンの共有をし、各種スクラムイベントの設定とそれらの進行役をしていました。初めのうちはプロジェクトとしての形がなかったところからチームを作ってプロジェクトを推進している感があったのだけど、だんだんただの会議進行役になってきているように感じていて、同時にチームとしてもちゃんと目標やビジョンを共有してそれに向かって進めているのだろうか、という不安も出てきました。そこで一度仕切り直し会をやったり、私も開発に入ったりとしたのですが、こんな進めかたでいいのかな、スクラムマスターってもっとチームのためにできることがあるんじゃないかな、と思っていたところでした。

学んだこと

　今回は、最初にスクラムについての説明があり、それから2チームに分かれてワークショップを行いました。私のチームは4人構成で、プロダクトオーナー（PO）、スクラムマスター（SM）、開発メンバー2人という構成でした。チーム外にステークホルダー役が一人がいました。最初の自己紹介で会社で野良スクラムマスターのようなことをしているが進めかたに悩んでいると話したところ、主催の方にSM役やったほうがいいと思うと言ってもらい、私はSM役をやりました（POかSMどっちかやりたいなと思っていた）。ステークホルダーは主催の一人、POはアジャイル札幌コミュニティの中の人（？／コミュニティの構成をよくわかっていないのでハテナ付き）で紙粘土スクラム参加2回目の方、どちらも認定スクラムマスターを持っている方でした。開発チームのお二人は初参加でスクラム勉強中という方たち。このメンバーで、まず全体計画をやり、「スプリント計画・開発・ステークホルダーレビュー・レトロスペクティブ」というスプリントを4周回しました。
　具体的な内容について書いてしまうと今後参加する人へのネタバレになってしまって良くないようなので、以下、なるべく開発内容はぼかして書こうと思います。説明がわかりづらかったらすみません。

価値のあるものから作る、動くものを作る、レビューを受ける、次に活かすことの重要性

　今回は時間の都合上見積というものをやらなくて、各タスクの作業量がわからないからスプリント計画を立てづらいなあと最初感じた。スプリントごとに「リリースできる状態のものを成果として出す」ために、見積をして、確実にできそう（かつ重要）なものから手をつけたほうがいいんじゃないかと思っていたから。でも見積がわからなかったから、まずはステークホルダーから必須で作ってくれと言われている動物をプロダクトバックログの先頭のほうに持ってきて、はじめのほうのスプリントで作ることにした。1スプリント目に、けっこう手のかかりそうな動物を作った。完成はしたけど、ステークホルダーのレビューを通らなかった。それで2スプリント目も丸々使って作り直した。その結果、1スプリント目の成果はゼロになってしまったけど、レビューと振り返りを活かして2スプリント目に開発したことで、今度はちゃんとレビューを通って、必須項目として求められていた動物をリリースすることができた。このときチーム内では”産業革命”が起きて開発チームの技術力も効率も上がり、3スプリント目以降スピードを上げて開発することができた。
　ここから学んだのは、

簡単にできそうなものから手を付けるのではなく価値の高いものから開発すること
デリバーできるプロダクトを完成させてレビューを受けること
レビュー結果を振り返り次のスプリントに活かすこと

の大切さ。スクラムの基本であり、知識としては読んだことあることだけど、こうやってワークショップで体験すると実感として理解できた。

細かく区切って振り返ることの重要性

　今回1スプリントは「スプリント計画・開発・ステークホルダーレビュー・レトロスペクティブ」の合計で20分。開発に使える時間は1スプリント6分しかなかった。作業時間としては6分×4スプリントで動物園を完成させたことになる。すべてのスプリントが終わったあとの全体振り返りで、「24分通して作業したとして同じものが作れたか？」と問われた。できなかったなあ！細かく区切って計画・開発・レビュー・振り返りを繰り返すからより良いものができるのだというアジャイル／スクラムの本質的な良さを実感できた。

会話・対話の重要性

　私のチームでは、プロダクトバックログの整理やスプリント計画はPO主導、開発（粘土で動物たちを作る）を開発チーム主導でやってもらってしまい、SMである私はなにをしたらいいんだ、と終始オロオロしてしまっていた。SMの仕事はチームの障害を排除することだって言うけど、具体的になにをしたらいいのかわからない。私がやっていたことは、スプリント計画中、POがやろうって言ったことについて開発チームに6分でやれますか、きつくないですかと聞いたり、開発中に必要な粘土の色を聞いて袋を開けたり、開発チームに困ってることないですかって聞いたり（だいたいは「ない」と答えが返ってきて、なにもできない）、タイムキーピングしたり、ぐらいだった。言ってしまえば雑用係。会社のプロジェクトでのうまくやれてない感・何したらいいかわからない感がそのまま出ている！
　最終スプリントが終わった後で隣のチームのSMに何をしていたか聞いたら、開発の時間中は手を動かす手伝いに入りつつPOにバックログの整理を頼んで、整理されたバックログを元にスプリント計画を主導していたそう。一度私のチームで開発時間中にPOがやっていたバックログ整備に入ろうとしたら「こっちはいいからSMは開発チーム見てて」って言われて、一瞬「ほんとにSMはバックログ整理に入らなくていいのかなあ」と疑問に思いながらも、あ、そうなのか、と開発チームが作業しているところに戻ってしまった。結果、POが決めた順番で開発チームが開発する、SMは特にやることなし、となってしまい、開発チームの意見をバックログに反映させることができなかった。
　バックログの整備をPO一人に任せるのが良いのかSMが入るのが良いのかはわからないけど、どちらにせよ、このチームとしてどういう役割分担でやっていくのかについての会話が足りていなかった。日々大事だと思っている「期待値の擦り合わせ」というやつができてなかったから、メンバーそれぞれがなんとなく違和感は覚えているのにそれを言語化し共通のビジョンを持つところに持っていけなかった。互いに（個人間でも、役割間でも）もっと会話をして、あなたに何を期待しているのか、私はあなたから何を期待されていると思っているのかを言語化して擦り合わせないと、「ただなんとなくそれぞれが思っている自分のロール」をこなすことしかできない。その結果、私はこれをやっていていいのかな、やらなくていいのかな、あれをやりたいけど私がやるべきじゃないかもしれないな、とモヤモヤしたまま開発を進めることになる。「こっちはいいから」って言われたときに、「私はSMもバックログの整理に入ったほうがいいと思う」と言って話をすればよかった。

　また、隣のチームには同じ会社から参加している二人がいて、互いの特技を知っていたことでそれを動物園作りにうまく活かせたという振り返りがあった。初対面のメンバーでも、互いに会話をして特技ややりたいこと、なりたい姿などを最初に話せれば、それぞれの特性を活かした開発や役割分担ができていただろう。メンバー同士で会話しチームビルディングすることが大切だなと感じた。

発言しやすさの重要性

　バックログ整理やらなくていいよってPOから言われたときに疑問を持ちつつも納得してしまった理由を考えてみると以下の3つであるように思う。

PO役の人が認定スクラムマスマーであり紙粘土スクラムも2度目の参加で、スクラムについて私より知っている人だ、この人が言うならそれが正しいのだと認識してしまったこと
その場の雰囲気として認定スクラムマスターの4人（彼らは全員アジャイル札幌コミュニティの中核メンバーのようだった）は他の参加者に教える立場で、他の参加者は彼らから教えてもらう立場だという空気があったこと
分単位、秒単位で追い立てられるなかで、会話や期待値の擦り合わせが足りていないというところに頭が回らなかったこと

　これらは仕事でプロジェクトやるときにもそのまま陥ることだ。
　1つめについて、プロジェクトにはいろんな立場の人が参加するはずで、社内の役職、年齢やその会社にいる年数、それまでの経験や知識などで、言ってしまえばランク付けのようなことを無意識にして、この人は自分より上の人だから言っていることが正しいとか、自分より下の人だから自分の意見が正しいはずだとかってなってしまうことがあるのではないか。これは、自分の中での他者に対するランク付け。
　2つめについて、場の空気や雰囲気としてメンバー間で共有されているランク付けもあって、それによりなんとなく物が言いにくくなることがあると思う。社内やプロジェクト内での発言のしやすさ、どんな発言をしても許容され受け入れられる感については普段から気をつけているつもりだけど、今後より気をつけようと思った。そして、アジャイルな家庭を目指したいのに家庭内では完全に「教えてあげる親（私）」と「教えてもらう子どもたち」という構図になっている、というより私がしてしまっていることに気づいた。子どもたちの発言しやすさをもっと作っていきたい。
　3つめ、仕事なんてだいたいいつも納期やステークホルダーからの要求に追われるもので、その中で頭が回らなかったなんて言っていられないから、そのときに必要な行動を意識せず引き出せるくらい身に染み込ませておかなければと思った。

感想

知識として知っていたはずのことも、ワークショップとして実際に体験してみると実感として理解することができる。「腑に落ちる」経験を繰り返してようやく、実際の仕事で使おうと思ったときに使える引き出しになるのだと思う。
SMやることなんもわからん感は、より深まってしまった！ワークショップに参加することで、わかってないことがよりわかるようになったという進化の意味です。1月のRegional Scrum Gathering Tokyo 2020に誘っていただき行けることになったので、それまでに自分の中で知識と体験を整理してから参加し、使える引き出しを増やしていきたい。
イベントとしてネタバレを避けているけど、むしろどんどんネタバレして、それらの知識を持った上で参加する人が増えていったほうが参加者のレベルが上がっていっておもしろいんじゃないかなあと思った。車輪の再発明をさせなくてもいいんじゃないかと。産業革命は二次、三次と起きるかもしれない。

　懇親会まで参加させていただき、アジャイル札幌のメンバーのみなさんにくっついて夜中の4時までお酒飲みながらエンジニアリングの話をして（私は主に聞いて）、とっても楽しく、視野の広がる一日でした。ここからRSGT2020にも誘っていただいたし、4月にはスクラムフェス札幌というイベントも開催されるそうでこちらにも参加させてもらおうと思っているので（できればなにかしゃべりたい）、これからもより深くスクラム／アジャイルの勉強をしていきたいなと思いました。アジャイル札幌のみなさん、参加者のみなさん、ありがとうございました！