はじめに
こんにちは。モノタロウで開発を担当している渡邉です。半年前に初めて開発チームのチームリーダーになり、スクラムを使った開発を行ってきました。今回はこれらの取り組みを振り返ってみようとおもいます。
はじめてのリーダー業って不安ですよね。どう行動すればよいのか、何を変えるべきなのか、うまくチームの目標を達成できるかなどなど・・・。私自身、そのような不安をかかえてチームリーダーになりました。
しかし、開発プロセスとしてスクラムを取り入れたことにより、想像していたよりスムーズにチーム運営を進めることができました。これから初めてリーダー職につく方や、スクラムをこれから取り入れてみようかなと思っている方の参考になれば嬉しいです。
アサインは突然に・・・
ある日のグループ連絡会で、当時のリーダーから突然の連絡がありました。
これまでのリーダーは経験豊富で、技術面でも行動面でもチームを率先してまとめ、引っ張っていく"スーパーマン"のような存在でした。周りのメンバーに知識も技術力も及ばない自分が、前のリーダーと同様の役割を務められるのだろうか…と正直不安がありました。
とはいえ、目標は達成したい
モノタロウでは半期ごとにOKR（Objectives and Key Results）を定め、OKRをベースに作成した各グループの目標を達成すべくタスクに取り組みます。私が所属するチームでは、1・2週間程度で完了する小規模案件をスピーディーにリリースし、サイト改善のサイクルを繰り返し回すことで、既存ユーザのLTV向上およびユーザー新規登録率の増加を目指しています。組織体制が新しくなっても目標のレベル・求められるリリースの件数はこれまでと変わりません。新しい組織体制で目標を達成するにはどうしたらいいか考え、いくつかの取り組みを行いました。
チームの課題を確認した
チームの課題を書き出してみた
わたしたちのチームは扱う案件毎の規模が小さいため、1案件に1人の担当者を割り当て、設計からリリースまでを1人で担当する仕組みでした。しかしその進め方には下記のような課題がありました。
- お互いが何をしているか見えにくい
- 担当者によって知識レベル、技術レベルの差があり開発スピードが異なる
- レビュータイミングでの考慮漏れ発覚
- 案件数が多いためレビューの負荷が高い
メンバーの誰かがこまったとき・詰まったときにヘルプをしようとしても、お互いの案件内容を把握していないためヘルプすること自体に時間がかかってしまうことがある状態でした。
関係者（プロデューサー）に開発チームの課題を聞いてみた
モノタロウでは、プロダクトオーナーとしての役割を担う人を ”プロデューサー” と呼んでいます。プロデューサーは案件の企画、優先順位付け、リリース内容の承認、分析などを主に行い、開発チームと密に連携してプロジェクトを進めています。
私たちのチームのプロデューサーにも開発チームに対する課題をヒアリングしました。プロデューサーからは、以下のような意見が得られました。
- メンバー毎の進捗が違うため、優先順位に合わせたアサインが難しい。
- 案件の進捗が個人のスキルに依存するためリリース日の予測が立てづらい。
- リリース案件が確定するのが直前(1、2日前)になることが多く、分析の準備がしづらい。
まとめると、私たちのチームには以下のような課題がありました。
- お互いの仕事が見えにくい状況
- 案件の属人化
- 知識のサイロ化
- 膨大なレビュー量
- 不安定なリリーススケジュール
これらのチームの課題とプロデューサーの意見を考慮し、上長から新しいチームではスクラムを取り入れたらよいのではないかとの提案がありました。チームの自己組織化に有効であることが大きな理由です。他にも、今後大規模プロジェクトでスクラムを導入していきたいという機運が社内にあり、今のうちに小さめの案件で実績を積んでおくという意図もありました。
まずは本を読むなどして、スクラムとはなにか・基本的な進め方について理解しました。
スクラムとは
スクラムガイドでは、スクラムを以下のように定義しています。
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。
「アジャイルな開発を実践するための枠組み」であり、短い開発期間を反復してこまめに成果を生み出すという方法です。
スクラムには「透明性」「検査」「適応」という3つの大切な柱があります。
スクラムを成功させるには、開発プロセスに関連するあらゆる情報が透明であることが必要とされます。プロダクトのビジョン、要件、作業進捗、問題、リスクなど、成果物にまつわるあらゆる情報がチーム全体で共有された状態が理想です。そのため、スクラムでは定期的かつ継続的なレビュー(検査)を通して現状を正確に把握し、変化や問題、リスクを検知します。検査において得られた情報に基づいて、より良い方法を柔軟に取り入れ、最適な形に適応することを繰り返してプロジェクトを成功に導きます。
スクラムではこれら3つの原則を、5つの会議体を通じて実現します。
会議体
- スプリントプランニング
- スプリントレビュー
- ふりかえり
- プロダクトバックログリファインメント
- デイリースクラム(朝会・夕会)
ロール
- プロダクトオーナー
- 開発チーム
- スクラムマスター
プロダクトオーナーは開発するプロダクトにおける責任者です。そのプロダクトが実現するビジネス価値に対して責任を負い、プロダクトバックログのメンテナンス、優先順位の決定、リリース対象成果物の承認を行います。
開発チームは各スプリントにおいて、利用可能なインクリメント(成果物)の あらゆる側面を作成することを確約します。スプリントごとにゴールを定め、完成の定義を忠実に守り品質を保ちつつリリース物を作成していきます。
スクラムマスターはスクラムガイドで定義されたスクラムを確立させることの結果に責任を持ちます。スクラムチームと組織において、スクラムの理論とプラクティス を全員に理解してもらえるよう支援する役割です。
1つのスクラムチームは、1人のスクラムマスター、1人のプロダクトオーナー、複数人の開発者で構成されます。
スクラムでは、成果を生み出すための短い開発期間のことをスプリントと呼びます。上に挙げた5種類の会議はスプリント毎に実施され、スクラムチームのメンバーは各ロールの役割に沿って参加します。スプリントの期間中は、スプリント開始時に定めたスプリントゴールを達成するために、チームが一丸となってタスクに取り組みます。
スクラムの基本について学ぶと、お互いの情報共有を大切にする透明性や、こまめなレビューを通して柔軟にやり方を変える適応の姿勢は、複数の小規模案件を並行して進める私たちチームの開発体制に合っていると感じました。これらの情報を踏まえ、スクラムをチームに導入することに決めました。
課題を解決するためのスクラムの取り組み
導入は決めたものの、具体的な会議体の変更や開発スケジュールの調整では少し検討が必要でした。下記がこれまでの開発スケジュールです。
この頃、モノタロウでは、毎週火曜日にサイトの定例リリースを行っていました。
開発案件に着手するタイミングはあまり明確に定まっておらず、およそ金曜日までに実装しプロデューサー確認でＯＫがでたものを翌火曜日にリリースするという流れになっていました。しかし、プロデューサー確認で修正が必要になった場合や、テストが間に合わないような場合は、月曜日まで最終リリース案件が確定しないこともあるというような状況でした。
まず、スプリントの期間はリリース周期に合わせて1週間としました。
毎週火曜日のリリースの後、翌日の水曜日に新しいスプリントを開始したいと考え、水曜日にスプリントプランニングを実施することにしました。また、リリースの日はマージ作業や確認作業があるため会議を入れたくないという考えがあり、プランニングに加えてスプリントレビュー・ふりかえりも併せて水曜日に設定しました。
一般的なスクラムでは、要件確認や実装方針の決定、見積りをスプリントプランニングで実施しますが、水曜日に会議を詰め込んだためプランニングにそれだけのまとまった時間を使うのが難しくなりました。
そこで、プロダクトバックログリファインメントを毎週月曜日に実施し、優先順位の確認に加えて要件確認・見積りといったプランニングの内容の一部を行うことにしました。水曜日のプランニングは、月曜日に洗い出したタスクをどの程度スプリントに入れるかを決め、メンバーにアサインするだけの時間となります。
変更後のスケジュールは以下のようになりました。
また、各会議体毎に、目的と時間を調整したものがこちらです。
ここまでを検討した上で、上記の検討内容や開発フローの変更をプロデューサー・開発チームメンバーに共有しました。
一人でチーム全体の開発スケジュールの調整を調整することは初めてで、プロデューサーや関係するデザイナーも巻き込んだ大きなスケジュールの変更であったため、漠然とした不安がありました。検討した通りにうまく機能するだろうか、会議体の大幅な変化に戸惑うかもしれないメンバーをうまくサポートできるだろうか、そもそもスクラム自体がチームの体制にあっているだろうか、というものです。
それに加えて、これまでより会議の時間が増加する、案件着手からリリースまでのリードタイムが伸びるといった具体的な懸念もありました。
ただ、やってみないと分からないということもあり、ひとまずスクラムでの開発をスタートさせました。
ここからは、実際のスクラムの取り組みを各会議体の詳細と共に説明します。
プロダクトバックログリファインメント
プロダクトバックログリファインメント(以下：PBLリファインメント)は、案件の優先順位について、プロデューサー・開発チームが合意し、案件の要件について理解することを目的としています。 先にも触れましたが、私達のチームではPBLリファインメントで要件確認から見積りまでを行うことにしました。
- 全員で実装方針を考え、疑問があればなるべくこの場で解消する。
- 実装方針に基づいて工数の見積りを行う。
- 案件についての不安や懸念もこのタイミングで洗い出す。
アサイン前に全員で案件の実装方針を検討することで意見を出しやすくし、お互いの仕事の見えにくさ、属人化といった問題の解決を図りました。事前に実装内容を理解することは、その後レビュアーにアサインされた時の負担軽減に繋がります。
また、複数の視点からの意見が聞けることによる知識共有という側面もあります。経験の浅いメンバーも実装方針を合意した状態で案件に着手できるため、新しい案件に取り組む心理的ハードルが下がるというメリットがありました。
このような会議体の導入に際しては、なるべく質問のハードルを下げる必要があると考えました。そのために、些細で単純な内容でも確認のために質問を投げるよう率先して進めるようにしました。そのような簡単な質問からでも思わず議論が進むこともあり、また知らないメンバーには共有になるため実際にやってみてよかったです。
スプリントレビュー
スプリントレビューは、そのスプリントの成果発表の場です。実装した内容をデモ形式で共有し、プロデューサーや他のメンバーはレビュー・フィードバックを行います。
私達のチームでは、水曜日に実施するスプリントレビューで翌火曜日のリリース案件を確定するというルールを設けました。その時点でデモを披露でき、フィードバックによりリリースして問題ないという承認を得たものをリリース対象とします。これによりプロデューサーから上がっていた、不安定なリリーススケジュールの改善を図りました。 早い段階でリリース案件が確定することで、プロデューサーがリリース前に分析の準備をする時間が確保できるようになりました。合わせて、プロデューサーのレビューにより実装に微修正が必要になった場合も柔軟に対応することが可能になりました。
この変更によりリリースまでのリードタイムはこれまでより3日程度長くなりましたが、ぎりぎりでのリリース確定という状況はもともと心理的にも不安が強かったこともあり、メンバーにもプロデューサーにもスムーズに納得いただくことができました。
ふりかえり
ふりかえりは、そのスプリントでうまく行ったこと・うまく行かなかったことを洗い出し、次のスプリントをより良くするという目的で行います。
ふりかえりには、当時他のチームでも実施していた4Lsを取り入れてみることにしました。
4Lsとはふりかえりに用いるフレームワークのひとつで、そのスプリントの運用やタスクの中で「よかったこと(Liked)」「学んだこと(Learned)」「足りなかったこと(Lacked)」「望むこと(Longed for)」を書き出して共有するというものです。
チーム内のペアワークやヘルプ作業を通してそれぞれの案件に関する知識共有を促進しようと考えていたため、「学んだこと」の項目により学びや気付きが可視化できるのが魅力的でした。また、「足りなかったこと」やそれを踏まえて「望むこと」を書き出すことにより、単に問題を洗い出すだけではなく前向きなアクションにつなげられるというところが導入時に良さそうだと思ったポイントでした。
スクラム自体がチームにとって新しい取り組みだったこともあり、実際にこの方法で振り返りを実施すると毎週多くの意見があがりました。「足りなかったこと/望むこと」に書かれた内容は具体的なアクションに落とし込み、タスクとして次のスプリントにいれて時間を確保し、取り組むようにしました。
特に、スクラムを導入してからは、メンバー全員でこれまでより丁寧な共有や相談をするようになったことでふりかえりやプランニングの時間がオーバーしてしまう、PBLリファインメントの時間内に実装方針が洗い出し切れないことが大きな課題となっていました。
それらについても、メンバーと意見を出し合い、複数の取り組みを実施することで徐々に改善が進みました。
デイリースクラム(朝会/夕会)
デイリースクラムは、スプリントゴール達成のための障壁を見つける・解決策を見つけることを目的としています。
朝会/夕会をデイリースクラムとして実施するにあたって、以下の内容を取り入れました。
- メンバー毎に対応中のタスクを共有する
- 困っていることの共有・相談
- バーンダウンチャートの確認
もともとチームでは15-30分程度考えても分からないことは人に聞くことを推奨するようにしており、いつでもSlackやZoomで質問ができる環境ではありましたが、朝会・夕会でも困っていることを共有する時間をこまめに確保することで、より気軽に質問ができる状態を目指しました。
バーンダウンチャートの確認により、メンバー毎ではなくチーム全体の進捗が意識しやすくなりました。
バーンダウンチャートがうまく進んでいないときは、停滞しているタスクがないか、多くのタスクが一人に集中していないかをカンバンボードで確認します。あるタスクに見積りより長い時間がかかっているような場合は、周りのメンバーからのヘルプで解決できそうなことがないか、タスクを切り分けて分担できないかを話し合います。
あわせて、未着手のタスクが一人のメンバーに集中しているような場合は、他のメンバーでタスクごと引き受けることができないかを検討します。PBLリファインメントで実装方針を事前に把握しているため、スプリントの途中でもお互いのタスクの概要が掴めており、ヘルプの依頼が比較的しやすいという状況がありました。
そのようにして、チーム内でタスクのアサインを柔軟に変更すること、うまくいかないタスクをチーム全員で分担・協力してやっつけるという姿勢をつくっていったことで、徐々にタスクの遅れを個人の課題でなくチームの課題としてとらえることができるようになりました。
これらスクラムの取り組みによる開発を行った結果、当初の目標の案件リリースを90%達成し、プロデューサーからも開発チームへの不安がなくなったとのコメントをいただくことができました。
まとめ
スクラムを取り入れてよかったこと
改めてふりかえると、スクラムの取り組みが、最初に感じていたチームの課題解決にうまくフィットしていることがわかります。
チーム全体でゴールを目指すというスクラムの取り組みを通じて、チーム内のコミュニケーションや会議での発言率も増えていきました。
最初はスクラムの取り組みがチームにフィットするか不安を感じながらの導入でしたが、そんな心配は杞憂で、メンバーそれぞれが積極的に目的を理解して参加してくれました。毎週のふりかえりや朝会で出てくるたくさんの意見や課題を取り上げ、それらに対する対策を実践する・良くないと分かったやり方を変えることにより、チームで良い方向に変わっていけたようにおもいます。
スクラムという枠をチームに合った形で利用することで、メンバー全員が自然とチーム運営に参加することができました。
今後の課題
前期では比較的小規模案件を担当してきた私達のチームですが、今期は小規模案件に加えて、リリースまで半年程度の期間を要する中規模案件にも取り組んでいます。業務の幅が広がり、仕事の進め方も変化しており、これまでのスクラムのやり方ではうまく行かないところも多々出てきました。
これまで同様チームの状況に合ったやり方を考え柔軟に取り入れることで、中規模案件もうまく回せるような方法を模索していく必要があります。
リーダーの役割とは？
チームリーダーになる前は、技術面でも行動面でもチームを率先して引っ張っていくのがリーダーの役割だと思っていました。そのため、スクラムを最初に取り入れた際は、一人で開発スケジュールを考えたりスクラムの手法をチームに布教しようとしたりと、基本的に自分でスクラムの導入を進めようとしていました。また、その他のタスクも何でも自分で引き受けて解決しようとしてしまい、メンバーのサポートも自分のタスクもうまくこなせていませんでした。
しかし、スクラムの導入をはじめ様々な案件を進めるうちに、自分ひとりで考えて取り組むのではなく、メンバーに相談して話を聞くこと、メンバーを信じて任せることによって、少しずつ問題が解決していきました。それぞれのメンバーが出してくれる意見を取り入れることでどんどんチームが良くなっていくのをみて、先頭に立って物事を決め引っ張るだけがチームリーダーではないのかもしれないと思うようになりました。私自身まだたくさん課題がありますが、これからもチームメンバーの話を聞くことや意見が出しやすい環境を作ること、そしてチームが目標を達成するためにサポートできることを考え、取り組んでいきたいとおもいます。
私たちが取り組むサイト改善以外にも、モノタロウでは大小さまざまなプロジェクトが進行中です。一緒にプロジェクトを進めるメンバーを大募集しております。雰囲気をしりたい、話だけ聞いてみたいという方も大歓迎です！ご興味がありましたら、ぜひ カジュアルMTG登録フォーム よりご応募ください。
