スクラム開発未経験からスクラムマスターになってみた - 弁護士ドットコム株式会社 Creators’ blog

この記事は「弁護士ドットコム Advent Calendar 2023」の 14日目の記事です。
前日の記事は @astkhs さんの「イマジナリーキャットと暮らしたい」でした。
とても真剣に猫を追求する内容がとても面白く興味深かったです！
タイトルだけで面白いのずるいです（笑）

弁護士ドットコム株式会社で、電子契約サービスであるクラウドサインの開発に携わっているエンジニアの神達です。
入社して2年経ったのですが、業務にて入社前には未経験だったスクラム開発をすることになったので、その過程と大事だと思っている内容をまとめてみました。
内容としてはマインド面の要素が多く、具体的なテクニックのようなものは少ないです。
まだ経験値は浅いのですが、似た境遇の方に参考にしていただいたり、単純に読み物として楽しんでいただければ幸いです。

対象読者
要約
前提知識
- スクラム開発ってなに？
  - ん？？アジャイル開発ってなに？
- で、スクラムマスターってなに？
入社前の状態
入社
入社後初のスクラム開発
突然スクラムマスターになる
スクラム開発で大事だと思ったこと
実際のエピソード
終わりに

対象読者

こんな気持ちを抱いている方
- アジャイル開発やスクラム開発ってよく聞くけど、具体的にどういうこと？
- スクラム開発やってみたいけどよく分からなくて手が出せない
- スクラム開発やってみたけどこれでいいのか不安
ウォーターフォールでの開発にやりずらさを感じている方
自分の開発チームを良くしていきたいと思っている方

当てはまらなくても読んでください（笑）

要約

スクラムによって強い開発チームを作り上げていくことに大きな価値がある
現実に向き合い続けることが改善と成長につながる
スクラムのメンバーとして貢献するためにスクラムマスターの経験は大きく活きる

前提知識

スクラム開発ってなに？

スクラム開発はアジャイル開発のやり方（フレームワーク）の1つです。
開発チームが自己組織化し、柔軟にプロジェクトに取り組みます。
開発作業を複数の短い期間（通常は2週間から4週間）に区切り、それぞれの期間を「スプリント」と呼ばれる単位で進めます。
スプリントごとに、開発チームは特定の目標に向かって作業を進め、定期的に進捗と成果物の内容を確認し、振り返りや必要な調整を行います。
このような進め方により、スクラムは柔軟性と透明性を持ちながら、迅速に価値のあるソフトウェアを開発することができます。

ん？？アジャイル開発ってなに？

ソフトウェア開発の手法の一つで、従来のウォーターフォールモデルによる開発とよく対比されます。
概念や原則であって具体的な手順やルールではありません。
アジャイル開発では、要求や状況の変化に柔軟に対応しながら、短い期間で価値のあるソフトウェアを開発することを重視します。
そのために一度にまとめて作るのではなく、早い段階から動くものを作り、利用者や関係者のフィードバックを受けて改善を繰り返します。

で、スクラムマスターってなに？

スクラムマスターはスクラムフレームワークの適切な実践をサポートし、開発チームが最大限の成果を上げることを促進します。
スクラム開発ではスクラムイベントと呼ばれるスプリントを進めるための目的ごとの取り組みがあり、それらが正しく機能するようにスクラムマスターは働きかけます。
また、スクラムが円滑に進められるようにスクラムの原則やプラクティスを開発チームにコーチングしたり、開発の障害になる要素を取り除くためにチーム外への働きかけも含め率先して動きます。

入社前の状態

私は前職でITの受託開発を行っている会社で働いていました。
そこでは基本的にはウォーターフォールモデルでの開発になっていて、たびたび納期に追われて残業地獄になっていました。
残業して他がうまくいくならまだしも、実際は多くの問題が発生していました。

顧客が欲しかったものとズレている
実はそれほど重要じゃないものにコストをかけてしまっている
- ひどい場合だとやらなくていいことをやっている
開発中に開発内容が見通せていなかったり、このままでいいのか漠然と不安を抱き続ける
全部作って繋げてみたら不具合や考慮漏れがたくさん出てくる

まとめると、価値のない取り組みと手戻りの多い進め方を見過ごしながら突き進み、最後爆死するというイメージです。

どうにかして抗えないかと、顧客とたくさん会話できるようにしたり、プロトタイプを作って認識をすり合わせながらの開発などを試してみました。
これからは一定の効果はあったものの、根本的に改善されるほどのものではありませんでした。

さらにどうにかしたいと調べていたところ、アジャイルという概念があることを知りました。
ちょうど社内に同じく関心を持っていたメンバーがいたので一緒に取り組んでみたのですが、そもそも軽く本を読んだだけでは実践できるほどのレベルには達しませんでした。

そこでアジャイルを実践できる環境で挑戦してみたいという思いが高まっていくのでした…。

入社

技術的に新たなものに挑戦したい、これまでとは異なるビジネスモデルや組織で取り組んでみたいという思いが高まり、弊社に転職しました。
入社して強く感じたのは開発のレベルが全体的にとても高いということです。
実装スキル、開発組織の体制、開発手法、良い意味でさまざまな面がいままでいた環境とは大きく違いました。
そしてスクラム開発が行われているというのもそのうちの1つでした。

入社後初のスクラム開発

入社してしばらくは比較的小規模の機能追加や改善のタスクを行っていました。
その後スクラム開発を身につけるべく、通常の開発チームとは別の一時的な開発チームを作っていただき、中規模程度の開発を行うことになりました。
そこではスクラムマスターとして別の開発チームにいる方に兼任で入っていただき、スクラムイベントを実際に進め、最終的にはスクラムマスターの方ができるだけ関与しなくても自分達で進んでいけるように取り組みました。
この経験でスクラム開発がどんなものかについてざっくり理解が出来ました。

突然スクラムマスターになる

最初のスクラム開発経験後、スクラムで機能開発を行っているチームに異動することになりました。
そこで、開発チームにしっかりと貢献して強い組織になっていきたい、そうできる能力を身に着けたいという思いが強くなります。
スクラムマスターとして動けるようなレベルになれば、自分の理想に近づけるのでは？と思い、それを目標に学習や取り組みを行うことにしました。
そのときの開発チームのスクラムマスターの方にスクラムで意識すべきことを相談したり、「SCRUM BOOT CAMP THE BOOK」や「エッセンシャルスクラム」などの書籍を読み、自身の動きやチームでの取り組みに適用できないか模索していました。

メンバーとしてそれらを続けることはできましたが、スクラムマスターをやっていた方から「どうせなら今からスクラムマスターをやってみたら？」と提案していただき、めちゃくちゃ不安を抱きながらもやってみることにしました。

実際のところ、もともとスクラムマスターをやっていた方は同じ開発チームにいて、他の開発メンバーの方々もスキルが高く意欲が高い人ばかりなので、自分がへなちょこでもなんとかなるだろうというのもありました。
ですが、今ではある程度は役に立つスクラムマスターになってこれたのかなと思っています。

スクラム開発で大事だと思ったこと

スクラムマスターとして動くようになってみて、これまでより解像度がはるかに高くなっていきました。
私がスクラム開発で重要だと感じたことをいくつかピックアップすると、以下のようなものがあります。

内的要素
- 「言ってもいいんだ」と思える雰囲気
- 正直に話しあっても問題ない信頼関係
- 自分たちの取り組みには価値があると思える裏付け
- 改善していっている・していけるという自信
外的要素
- 障害（ブロッカー）になるものへの反応の敏感さ
- 取り組みをノウハウとして残していく、共有する
- 成果に対する説明責任を果たせるようにアプローチする

実際のエピソード

上で挙げた内容を実際のエピソードで掘り下げてみます。

「言ってもいいんだ」と思える雰囲気、正直に話しあっても問題ない信頼関係

組織内で思ってることを正直に言えないことはあると思います。
参加して間もないときや、自分が経験やスキル面で他の人に劣っていると感じていたり、間違ったことを言ったら恥ずかしいと感じる場合などです。

これからの環境を改善する行動はいくつかあると思いますが、私が意識しているものを挙げてみます。

まずは自分から間違いを覚悟で気軽に切り出してみる
他の人の発言に対して否定から入らず、できればフォローを入れる
良い提案をしてもらったり気づきをもらった場合には感謝や称賛をしっかりと行う

これらは働く環境としてそのほうが望ましいというのもありますが、言うべきことを言えないことが課題を明確にしたり改善を提案する動きを大きく阻害します。そのためチームとして強くなる上では土台となるような重要な要素だと思います。

当初はこの点で少し不安もあったのですが、メンバーの人柄の良さもあり、今の開発チームでは良い雰囲気でやれていると感じています。
実際、開発チーム内でスクラム自体の振り返りをした際、これらの部分に対して肯定的な意見が多く出たので嬉しかったです。

自分たちの取り組みには価値があると思える裏付け、改善していっている・していけるという自信

前述の雰囲気や信頼関係にも関係あるのですが、スクラム開発の良さはチームとして成長して強くなっていけることだと思います。
なので体制はできるだけ維持したほうがいいですし、複数の機能開発にまたがって経験が生かされていくことが望ましいです。

強い開発チームになっていくために必要なのは、現実をしっかりとみて「課題」や「良い要素」を明確にして、その後の行動を改善していくという振り返りの行為だと思っています。
振り返りというは仕事においてはめちゃくちゃ当たり前で基本的なことなのですが、それがうまく出来ないのでこれまでたくさんの問題を経験してきたと感じています。
スプリントという短いタイムボックスに区切るというのは、成果物をこまめに評価してより価値あるものにしつつ、より早く提供するという側面が注目されがちです。
しかし、同じぐらい重要なのが、チームの活動に対する振り返りと改善を、短いタイムボックスによって円滑に進めていける、ということだと思います。

実際に振り返りによって改善したものを例として挙げます。
※長いので読み飛ばしても大丈夫です

スクラムイベントの司会と書記が固定だと、負担が偏ったり不在のときにうまく進まない
- 司会と書記はローテーションにした
- 司会が誰であっても円滑に進められるようにアジェンダにもなる議事録を整備した
- 書記の負担が軽くなるように、議事録が日次で自動生成されて事前記入できるようにした
スプリントゴールに設定した内容が達成できないことが頻発する
- レトロスペクティブの振り返りボードにスプリントゴール専用の枠を用意した
  - 未達であったことの原因や改善についてしっかりと考えるようになった
- タスク化やストーリーポイントの設定が出来ていないものを減らし、最初の見積もりで出来るだけ作業の全量が見えるようにした
- タスクを細分化して見積もりの精度を上げた
- タスクを完了とみなす条件は誰がやっても認識がブレないレベルで書くようにした
- スプリントごとにベロシティを記録して、過去のベロシティを基準にすればタスクが溢れないように認識を揃えた
  - 「なんとなくこれぐらい出来そう」を減らす
- ストーリーポイントの感覚を標準化するため、タスク内容とポイントの対応表を作った
  - 単純な相対値という考えだけだとブレたり悩んだりすることがあったため
スプリントゴールが達成しているのか曖昧に感じることがある
- チーム内のどの立場でも理解できる表現でゴールを記述するようにした
- 単純にタスクが完了しているか否かではなく、より掘り下げた表現をするようにした
  - すべて完了しない場合はどこまで完了したらいいのか細分化して明記する
  - 「QAタスクが全て完了してリリース可能になる」など、状態を表現する
機能追加する際、ベースにする既存機能をよく理解していなかったために開発スコープから漏れる部分がある
- 開発に着手する前に時間を取り、関連する機能、類似する機能、そもそも今回開発するものに対しての深掘りを行うことにした
  - Sprint-1（スプリントマイナス1）と名付けた
  - ボードを作って全員で意見を出して付箋を貼っていく
  - 開発メンバー全員で調査して共有することで、最初に気づきを得たり認識を揃える
    - 意外と開発前でも見つけられる課題は多い
  - 明確に事前の調査をしたり既存機能に触れてみる時間をつくることで、なんとなくの理解で進むことを減らす
- BugBashという多人数で自由に機能を触ってバグを見つけるイベントを行うことにした
  - 参加者は開発メンバーだけでなくてよい（色々な人が参加するほうがむしろ望ましい）
  - テスト仕様書などに縛られず、自由にいろんな考えで機能を触れてみる
  - いつもと違う気持ちで見て考えると気づく要素は結構多い

これらは1つ1つの改善成果も大事なのですが、改善を積み重ねることによるチーム全体での自信の形成や、今後の改善へのモチベーションの向上がとても重要だと思っています。
スプリントごとに行うことで高速で振り返りと改善を実現出来ます。

取り組みをノウハウとして残していく、共有する

弊社ではクラウドサインの開発を行う複数のチームが存在しています。
主に新規機能追加を行うチームだけでも3つあり、その他も含めると7つあります。
それぞれが自己組織化しており、独自の進め方やノウハウを持っていたりします。
とはいえ1つのプロダクトを作っている開発組織として、良いノウハウや失敗の振り返りは共有していく価値があります。

これはスクラムについての話からは少し脱線する気がするのですが、より良い開発を進めていく上で重要なことだと思っています。
自分たちの開発チームが失敗を振り返って始めた取り組みが、他の開発チームでも採用されることが度々あり、その逆もありました。

最近では他の開発チームのスクラムマスターの提案で「スクラムマスター座談会」というものが開かれ、知見の共有やスクラム開発に関する相談が行われるようになり、ますます学びが増えています。

成果に対する説明責任を果たせるようにアプローチする

ウォーターフォールモデルの良いところ（？）は、顧客が納期や開発内容を約束してもらえるということだと思います。
仕事である以上、スケジュールの見通しとそれに合わせた関連業務の調整は必要であり、発注したシステムがいつまでにどこまでできるかは重要なことです。
しかし、多くの場合は約束された納期や内容では納品されません。
なぜならシステム開発は不確実性が高く、最終的にどういったものが完成したらいいのかを最初から具体的に把握できる人は存在しないからです。
だからこそアジャイル、スクラムを採用して開発を行います。

いつまでに完成するかを問われるのは受託開発だけではありません。
弊社のようなSaaS企業においてもいつまでに何ができるかは強い関心を持たれており、プロダクトの企画・検討、セールス、カスタマーサポートやヘルプデスクの仕事にも関わることです。

以前、自身が関わった機能開発で当初のリリース時に問題が見つかり、再リリースや事後対応に数ヶ月要することがありました。
サービスの利用者にいつまでになにを提供するかを約束しているわけではありませんが、利用者はいつまでも欲しい機能が提供されないサービスを使ってくれるわけではありません。
もちろん不確実性の中で開発しているので一定どうしようもない部分は存在しますが、改善すべき点として反省する経験になりました。

最初にいつまでにどこまで出来るかがわからない前提で開発するスクラムですが、それはなにも説明せず責任を持たないことではないです。
信頼性のあるリリース見込みを提示するため、ストーリーポイントに基づいたベロシティを計測して、残タスクの消化がどれくらいで出来るかを予測します。
本来想定した価値提供が損なわれないようにするため、スプリント単位で細かく成果物を評価します。

それらを高いレベルで実施し、より信頼性のある予測や価値の高いリリースを目指す必要があると思っています。
スクラムを行うチームが円滑に開発を進めることに対して直接重要な要素ではないかもしれませんが、組織やプロダクトとして目指すべきものとして意識していくべきだと感じています。