引き継ぎプロジェクトでスクラムマスターが陥った危機　痛みを伴う失敗と知見で巻き返した"プロジェクトX"

スクラムをスクラムだと知る前からスクラムをやっていた

宗田知子氏：「スクラムネイティブなスクラムマスターの失敗とその巻き返しの物語」を始めていきます。

自己紹介です。私は、現在freee株式会社という会社で働いている人事労務系Webアプリエンジニアです。うさぎとダイビングを好んでいます。

スクラムとの関わりですが、スクラムをスクラムだと知る前からスクラムをやっていて、そこでいろいろと学びながらスクラムマスターやCSP（Certified Scrum Professional）を取りました。あとは「アジャイルひよこクラブ」というコミュニティをやっています。

ドメイン知識がない状態で開発がスタート

自己紹介が終わったので、次は概要です。本日は、リリースまでに予定の倍の時間がかかってしまった開発プロジェクトの裏側のお話をします。

プロジェクト名は「プロジェクトX」とします。Step1、Step2、Step3と段階を追ってリリースしたものなのですが、プロジェクトXには深いドメイン知識が必要で、ほかチームから私のチームに引き継いだ直後でした。

深いドメイン知識が必要なものというのがあとで出てくるので、ちょっと覚えていてもらえればと思います。

プロダクトの背景ですが、1つのプロダクトを3つのスクラムチームで開発していて、私のチームは「プロジェクトX」、ほかの1チームは「プロジェクトY」、さらにほかのチームは「プロジェクトZ」という依存関係がない状態で進めていました。チーム構成は4人チームで、そのプロジェクトをやりながら問い合わせ（不具合対応）などもやっている状況でした。

チームの状況としては、プロジェクトXをやる前に何個かのリリースをも終わって、ちょっと安定してきたかなという頃ですね。そのプロダクトは複数のドメインを併せもつWebアプリでした。3チームがドメインごとに分かれてはいなくて、横断的に開発していました。

そういう状況だったのですが、1個のドメインにフォーカスしたほうがいいだろうと、ドメインに分かれずにやっていたのを深いドメイン知識が必要になってくるところでドメインごとに分かれることになりました。その直後だったので、ドメイン知識はまだチームのノウハウとしてはぜんぜん貯まっていない状況でした。

深いドメインが必要なのに、ドメイン知識がない状態でスタートしたため、この『スクラムガイド』にある「複雑な環境下では、何が起きるかわからない」をそのまま進んだ状態でした。

次は、そういう状況下で予兆として何が起きたのかと、チームの変化はどういったものがあったのかを話していきたいと思います。

そもそも「プロジェクトX」はほかのチームから引き継いだプロジェクトだったのですが、その引き継ぎはすごく丁寧にやってもらったので、引き継ぎが悪かったという話ではありません。ただ、チームから2人エンジニアが出ていったり、ほかのチームから異動で1人来たりという、予想可能だったものと予想不可能だったものがあって、引き継ぎが重なりました。「複雑な環境下では、何が起きるかわからない」というところが少しずつ現れ始めてきました。

そんな中で、チームとしても焦りが出ていたのもあって、まだReadyな状態ではないものに着手していました。必要なドメイン知識を習得していないうえに、既存実装の作りを把握せずに進んでしまったため、ズレがちになりました。

結果、3つステップを踏んで進めていくうちの1つ目のステップは、3ヶ月で出せるだろうとコミュニケーションを取っていたのですが、6ヶ月かかってしまいました。

概算見積もりを更新しなかったことがチームの疲弊につながった

「経験主義の原則」というのが『スクラムガイド』で何度も出てくるのですが、さっき出した「複雑な環境下では、何が起きるかわからない」には続きがあります。みなさんご存知かもしれませんが、「すでに発生したことだけが、将来を見据えた意思決定に使用できる」とバシッと書かれています。

引き継ぎ前から概算見積もりがあったのですが、それを更新しなかったのはこの経験主義の原則に反すると思っています。具体的な行動を把握する前に「これぐらいでいけるだろう」とチームで判断して、そのまま走ってしまったところですね。経験に基づく必要があるのに、関係者に共有せず、また「このチームでやるとしたらまだわからないから」という話をせずに、そのままいってしまったというところですね。

その結果、起き始めた変化として、3ヶ月予定していたものが6ヶ月になり、チームでやっていた問い合わせ対応や不具合の対応に手が回らなくなってきて、2つのチームにヘルプをお願いしてもらいました。

今までできていたことができなくなってくると、だんだんチームとしても疲れだしてくるんですよね。スクラムチームや開発者だけではなくて、プロダクトオーナーとかステークホルダーとか、各種関係者に対してコミュニケーションが必要になってきて、疲れだしていました。

プロジェクト巻き返しのために行ったこと

ですが、失敗して終わりではありません。失敗してからが始まりなので、ここからどうしたかをお話しします。

長期見積もりの更新。長期と言っているのは、3ヶ月とか数ヶ月単位の見積もりの更新と共有を適宜行うというところです。あとは、どうしてもリリース時期をずらす必要がある問題が発覚することもあったのですが、そういう場合は関係者を適宜巻き込んでコミュニケーションを取るのをきちんとやりました。

でも、これも先人はバシッと『スクラムガイド』に書いています。「必要に応じてステークホルダーとのコラボレーションを促進する」のがスクラムマスターの役割の1つとして挙げています。

次の「Readyを整える」というのはやらないといけないところです。「まずは既存コードの把握」は、開発するエンジニアの責任としてやっていきました。それをやらないと、本当に何が起きるかがわからないというのを繰り返してしまうので、将来を見据えた意思決定に使用できる状態を作るべくやっていました。

「透明性と検査と適応」ですが、各タスクの完了見込みの期日を入れて、ズレ続ける場合は「これはアラートの出始めだな」と、対策を入れていました。開発者の役割・責任として、これも『スクラムガイド』に書かれています。「スプリントゴールに向けて毎日計画を適用させる。専門家としてお互い責任をもつ」というところです。

こうしたことをやり続けているうちに、きちんと未来が見据えられるようになって、問い合わせや不具合対応もまたチーム内ででき始めました。

『スクラムガイド』を改めて読み返すと突き刺さる部分がある

失敗してからが始まり、Step1は3ヶ月から6ヶ月と倍の時間がかかってしまったのですが、Step2は2ヶ月を予定していたところを2ヶ月で出せて、Step3は1ヶ月を予定していたところを1ヶ月で出せました。

短くなっているのは単にプラクティスを改善しただけではなくて、Step1で前提となる土台部分の実装などが終えられていたのも大きいとは思うのですが、大事なのはこの期日がだんだん短くなっていってるという部分ではなくて、自分たちで見積もりがきちんとできるようになっていったというところだと思っています。

この「痛みを伴う失敗から得た学び」ですが、まずは「期日に敏感になる」です。「無理と感じた場合はNOと代替案を」というのは、無理なものを無理だと言うだけだと、あまり建設的ではないので、スコープを縮めるのか、期日を伸ばすのかというトレードオフにはなると思うのですが、そういうところをきちんと、スクラムマスターとして関係者やステークホルダーとコラボレーションを促進することをやり続けていかないといけないなと強く感じました。

次が「知らないことを知る」です。知らないことが何なのかをきちんと知っていれば、アクションが取れるなと感じました。今回、チームが作らないといけないものは深いドメイン知識が必要なものだったのですが、現状その深いドメインをチームが習得しているのか・していないのかを知っているのと知らないのでは、取れるアクションが違うなと思いました。

習得していないにしても、「だったら、既存コードの把握はどれぐらいできているのか？」というところで、「まだ細部まで理解していないから、細部まで理解するためのタスクを切ろう」とか「きちんとそこまで話し込んでプランニングしよう」というようなアクションが取れるかなと思っています。

そういったところで、何度も出て来ているのですが、すでに発生したことから未来を見据えられる、意思決定ができるようになるかなと感じました。

次の「困難なことをやる勇気の獲得」ですが、これは深いドメイン知識や現状をチームが把握していないから、把握できるようにどうすればいいのかをきちんとするということです。開発者の責任としてスプリントゴールに向けて毎日計画を適用させたり、専門家として責任をもったりというところなのですが、引き継いだチームに言われたことを鵜呑みにして、そのまま関係者に共有して終わっている状態だと、この責任をもつという、開発者の役割を果たしきれていないと感じました。

そうではなくて、きちんと着実に1つずつドメイン知識を習得したり、既存コードを把握して、次に追加するにはどうすればいいんだというところを一歩一歩着実にやっていったりして、難易度の高いものにきちんと向き合って進めていけるようになったというのが今回の学びとしてあります。

今挙げたことは、全部『スクラムガイド』に書かれていることだなと感じました。チームがうまくいかない、うまくいってないなという状況がもしあったら、ぜひ『スクラムガイド』を読んでみてほしいなと思います。

私自身も、今まで「チームがあまりうまくいってないな」とか「チームに課題があるな」と感じた時に『スクラムガイド』を読むと、なにもない時に読む時以上に突き刺さる部分がポイントポイントで出て来るので、課題を感じている方がもし聞いている中にいたら、『スクラムガイド』を改めて読み返してみてほしいなと思います。

それぞれの人によって刺さるところは違うかもしれませんが、ヒントになるところがたくさん書かれているんじゃないかなと感じているので、ぜひやってみてほしいなと思います。

では、以上で終わりたいと思います。ありがとうございました。