新卒スクラム研修での学びとスクラムガイドの解釈
はじめに
3週間、スクラム開発をテーマにしたPBL(Project Based Learning)研修でアサイン管理に用いる社内ツールを開発しました。1週間で1スプリントです。
本記事では、実際のスクラム開発での経験とそこから得た学びを整理します。また、最後に3週間の経験をスクラムガイドと照らし合わせて、自分なりの解釈を書きます。
また、スクラムマスターとしてI.Iさんに、ステークホルダー(顧客)としてS.Kさんに協力していただきました。さらにユーザーとして、T.Iさん、K.Nさんに意見をいただきました。
学び1：顧客を知ることが最優先
顧客が伝えてくれる要望を、そのままtodoリストとして受け取ってはいけません。顧客が普段どんな業務をしているか、使っているツールは何か、その中で抱えている痛みは何か、これを一緒に言語化する必要があります。顧客自身が課題を言語化できていない場合もあるため、開発チームが壁打ち相手となって理想の状態を一緒に考えることが求められます。
また、解決したい課題の優先順位を意識しないと、限られた時間の中で十分に情報を得られず、課題に対する解像度が低いまま次のスプリントがスタートします。
実際に業務を見せてもらう
スプリント1、2の実装中、顧客の業務を十分に把握できていなかったため、仕様の不明点やUIの実装イメージがわかないということが次々と発生しました。
この問題に対しては、
・実際にアサイン会議に参加する
・業務に使用している既存ツールのUIを見せてもらう
・後述する追加のヒアリング
などの手段で解決しました。
しかし、最初から「普段の業務を見せていただけませんか」と質問することができていれば、行わないで済んだ手戻りや認識合わせがあったと思います。
周囲を巻き込む
プランニングにおいて、UIの方向性がチーム内でまとまらず、その機能に関するストーリーポイントが大きくなり、スプリントゴールの達成が難しそうになったことがありました。そんなとき、スクラムマスターの提案でステークホルダーへの追加ヒアリングを実施し、UIの方向性を議論して確定させることができました。
スクラムイベントや顧客という立場にとらわれず、もっと頻繁にS.Kさんとコミュニケーションをとっていくことができれば、顧客を巻き込んで一つのチームとして無駄のない作業をできたと思います。
学び2：目的・背景を言語化してから動く
短いスプリント期間では、数時間の迷走がインクリメントに大きな影響を及ぼします。この問題に対し、目的と背景を言語化し、チーム内でお互いにチェックし合うことで、今やるべきことを意識することができます。
チーム内のコミュニケーション、スプリントレビュー、機能を実装するときなど、あらゆる場面で目的の言語化が機能します。
ヒアリング準備での失敗
初回のヒアリングにおいて、準備として各メンバーが聞きたい質問をリスト化しました。しかし、ヒアリングのゴールを正確に定義できておらず、ゴールと質問が結びついていませんでした。これにより、なぜこの質問をするのかを整理できておらず、似たような質問をしたり、具体的な機能に関する質問を頻繁にするなどの失敗を犯しました。
スプリントレビュー準備での成功
スプリントレビューでの質問を「抽象度の高い問い→具体的な問い」という木構造に整理しました。この順序で話すことで背景や文脈を共有してから詳細に踏み込めるようになり、ヒアリングの流れが自然になりました。
木構造で言語化するメソッドは、その後チーム内に定着し、レビューの時だけでなく、プランニングなどでも使われるようになりました。
学び3：妥協せず不確実性と向き合う
方針転換や想定していなかったトラブルは、頻繁に発生します。これに対して、自分たちの状況を客観視し、今までのやり方に固執せずに柔軟に対応するスキルが必要となります。しかし、作業中に自分自身やチームの振る舞いを客観視することは難しいです。特にこの点に関して、I.Iさんがスクラムマスターとしてチームを大きくサポートしてくれていたと思います。
プランニングで見積もりを大きく外す
スプリント1において、プランニング時に見逃した環境構築の受け入れ条件が発覚し、機能実装に使える時間が1週間のうち1.5日になりました。
チームがスプリントゴールの諦めと修正案を検討し始めたとき、スクラムマスターが「妥協するのではなく、やり方を変えることで今のゴールを達成できないか」と問いかけてくれました。不要なタスクを洗い出し、それまで行っていたモブプロを中断して並列作業に切り替えた結果、ゴールの大部分を達成し、レビューまでに動くインクリメントを作成できました。
これ以降、チームは進捗に合わせてモブプロと並列作業を使い分けるようになりました。
プランニングで時間超過する
スプリント1の反省から、スプリント2のプラインニングでは、受け入れ条件を細かく洗い出しました。しかし、粒度が細かすぎたため、プランニングの時間が予定を大幅に超過しました。ここで、スクラムマスターから「今スプリントで着手しない可能性のある優先度の低い部分まで詳細に考えている」と指摘を受けました。優先度が高いものは詳細に、低いものはざっくりという粒度の使い分けと、7割の完成度で区切りインクリメントを産む時間を確保するというアドバイスをいただきました。
これにより、スプリント3では、プラニングが5分の時間超過のみで終わり、開発を素早くスタートさせることができました。受け入れ条件の洗い出しを全てのユーザーストーリーに対して厳密に行わなかったことで、途中で抜け漏れも発生しましたが、大部分は順調に進み、スプリントゴールを達成することができました。
学び4：AIはコーディングだけではなくあらゆる作業を効率化できる
本研修では、コーディングだけではなく、思考の整理・レトロスペクティブ・タスク分割・コードレビュー・資料作成・顧客とのイメージの共有など、あらゆる作業でAIを使いました。一方で、その効果を発揮させるには、AIの使いどきを意識して運用するスキルも必要となります。
geminiメモとnotebookLM
レビューや作業時には、google meetを立ち上げ、geminiでメモをとっていました。このメモをNotebookLMに読み込ませることで、レトロスペクティブやプランニングなどで確認漏れがないか素早く確認できました。
cursorのcanvas機能
顧客とのヒアリングにおいて、cursorのcanvas機能を使ってUIのモックを作り、それをベースに議論しました。これを行うことで、顧客とのイメージ共有がスムーズに進み、体感1スプリントは期間を短縮できた気がします。
エージェントを使ったイシュー分割とコードレビュー
スプリント1のレトロスペクティブにおいて、コードレビューの負荷軽減が最大の課題として挙がりました。この原因として、プルリクの分割がうまくできていないこと、レビュー時のコード品質が悪いことが考えられました。そこで、ユーザーストーリーに対するイシュー分割とコードレビューのためのサブエージェントを作成しました。
しかし、イシュー分割エージェントはイシューを細かく分割しすぎる傾向があり、人間が指示して統合する必要がありました。さらに、コードレビューエージェントは、アーキテクチャに関して修正案をうまく提示してくれないことがわかりました。エージェントの継続的改善と、ただ任せるのではなくうまく運用するスキルの重要性を学びました。
学び5：学習とインクリメントのトレードオフ
スプリントを経ていくごとに、チームの振る舞いは大きく改善していきました。これを支えていたものは、モブプロやチームアグリーメントといった知識を共通するための仕組みです。
しかし、知識を共有するような「学習」だけを優先していると、短期間でたくさんのインクリメントを生み出すことは難しいです。学習とインクリメントのトレードオフを意識して、作業の仕方を柔軟に変える必要があります。
知識共有の仕組みと文化を作る
多くの実装はモブプロで進めました。プロダクト開発と研修を兼ねているため、知識のある人に頼り切りになることは避けたかったためです。チームアグリーメントに「知識を共有し、知らないことは必ず質問する」「Noから入らない」と明記したことで、メンバー間の知識共有と発言しやすい雰囲気が生まれました。日報・デイリースクラム・チェックインでの学びの共有もアウトプットの場として機能し、スプリントを経るごとにチーム全体の振る舞いが改善していきました。
作業の並列化
最後のスプリントゴールは、「実際にアサイン会議で使い始めることができる状態にする」となりました。しかし、事前に顧客と相談したMUSTの条件は、それまでのやり方で達成することは難しそうでした。そこで、最後のスプリントは、全員が個別にユーザーストーリーを担当する方法を取りました。知識の属人化やメンバーの進捗共有を密に行わなければいけないというデメリットもありますが、この方法を採用したことで、ゴールを達成し、顧客に「早速、業務で使いたい」と言っていただくことができました。
しかし、この方法が採用できたのは、前2週間でモブプロ・ペアプロを続けたことでチーム全体の知識共有とスキル向上が行われてきたからだと考えています。そのトレードオフを今後も意識していきたいです。
おわりに -スクラムガイドの解釈-
スクラムガイドによると、スクラムは「経験主義」と「リーン思考」に基づいています。経験主義は、予測するよりも実際の経験や観察に基づいて意思決定をする方針を、リーン思考は、繰り返し価値の定義やそれを生み出すプロセスを言語化することで、改善サイクルを回し無駄を無くしていく思考法らしいです。
実際にスクラムの形式で開発を行うと、多くの要素が揃って、初めてこの二つを実践できることに気がつきました。チームがお互いに信頼し学び合える関係性、顧客の協力、ドメイン知識、チームの状況を客観的に観察すること、問題に対して柔軟に適応する力、目的やその達成に必要なものを整理して考える力、ソフトウェア開発の技術力など、この他にも多くの要素が必要となります。
スクラムガイドは、これらを抽象化したものであると感じました。
研修に協力してくださった皆様、チームメンバーの皆さん、本当にありがとうございました。
これからも成長していけるように頑張っていきます！
