【イベントレポート】アジャイル開発「スクラム」って各社どうしてる?エンジニア知見共有会

今でこそアジャイル開発「スクラム」は様々なプロジェクトで採用され、概念も浸透していますが、具体的なやり方はプロジェクトの数だけ特徴があるかと思います。そこで今回は各社のアジャイル開発「スクラム」に携わるエンジニアが集まり、それぞれの知見を発表し、学びあう勉強会を開催しましたのでその様子をレポートいたします。

登壇者はこの方々!
藤澤 明慶さん/株式会社 BuySell Technologies
西澤 翔利さん/パーソルキャリア株式会社
Yuichiro ABEさん/株式会社タイミー

まずはBuySell Technologiesの藤澤さんより、チームの生産性を向上させるためのスクラム運用についてのセッションです。


チームの生産性を向上させるためのスクラム運用

バイセルは、リユース業界全体のデジタルトランスフォーメーションを目指して、リユースプラットフォーム【Cosmos】を開発しています。このプラットフォームには、「出品管理サービス」というプロダクトも含まれています。

今回の発表は、スクラム開発を始めたもののチームの改善が疑問な方や、開発生産性を上げたいけれども具体的に何をすればいいのか分からないと感じている方に向けて、スクラム運用の改善を通じて開発生産性を向上させた事例を紹介します。


最近、私が所属するチームの生産性が爆上がりしました!!

これは私が所属するチームの昨年の生産性に関する指標の推移です。
棒グラフと線グラフで、別々の指標を表していますが、大幅に改善されていることを示しています。

さらに…

このアワードは、生産性指標を可視化できるツール【Findy Team+】を利用している企業を対象に、生産性指標が特に高かった企業を表彰するものです。

では、どのように改善したかという具体的な事例の中でも、スクラム改善の事例を紹介します。

スクラム改善に至るまでの流れ


以前の出品管理チームでは、マイルストーンやロードマップの進捗状況について不安を感じながら作業をしていました。そこで、スクラムを導入することで、開発の進捗やスケジュールの見通しが立ちやすくなると伺い、チーム全体でスクラムを導入することを決定し、まずはスプリントの概念やスプリントイベントの実施に注力しました。

タスクをこなす上での考え方として…

・リソース効率からフロー効率へ
→工数をつかいきることより、スプリント内で予定したタスクの完了を重視
・開発スピードからベロシティの安定へ
→手が空いてもスプリント内で終わりそうにないことはやらない

この2点を意識するようにしました。
そして、ある程度スプリントをこなしてくると、いくつかの疑問が出てきました。

▲表面化した疑問

そこで、社内のアジャイルコーチにスクラムマスターを依頼して、これらの課題感を共有し、スクラム運用の改善を進めました。

具体的な取り組み

具体的に取り組んだことは

①生産性指標のKPI設定と可視化
②スプリントレトロスペクティブの運用改善

この二つです。

①生産性指標のKPI設定と可視化

チームの開発ワークフローに合わせて、プルリクエストを出してマージするとデプロイされるという方法を取っていたため、プルリクエスト数が多いほどデプロイ頻度と変更のリードタイムに影響があると考え、GitHubのプルリクエスト数をチームのKPIとして設定しました。

この仮説に基づき、スクラムを導入してからは、スプリント中には一定数のプルリクエストが出されるようになりました。そして、スプリント終了後には、開発した機能のレビューがステークホルダーによって行われ、必要な修正が洗い出されるようになりました。

また、生産性指標を可視化するためのツールとして【FindyTeam+】を導入。

すでに社内で導入の実績があり、プルリクエスト数がかなり見やすく可視化されていたので、採用を決めました。

②スプリントレトロスペクティブの運用改善

もともとチームでは、KPTというフレームワークを使ってレトロスペクティブを行っていました。
改善点を見つけるためには、KPTのような意見出しは必要ですが、それだけでは集中力を欠いてしまいます。そこでKPIにフォーカスしたレトロスペクティブを進めることで、チームの共通目標に向けた改善に集中できるようになり、その結果チーム全体での課題の共有や改善アイデアの共有がスムーズに行えるようになりました。

ではそれぞれのアジェンダでどのような話をしていったのか。
まずは【FindyTeam+】でKPIを確認しました。

プルリクエストの作成数の推移を前のスプリントと比べて「上がったのか、下がったのか」を確認しました。

また【Findy Team+】では、プルリクエストがマージされてからクローズされるまでといった区切りごとの所要時間をプルリクエストごとに見ることができるので、所要時間がかかったプルリクエストを中心にみんなで確認して、なぜ時間がかかったのか原因を追求するようにしました。

次にTryの確認です。

Tryは、チームが新しいアイデアや施策を試みて、その効果を検証することを指します。このような試行錯誤を繰り返して改善していくことが、スクラムの重要な要素の一つです。何度かスプリントを重ねて、同じTryが連続して効果がありそうであれば、それはワーキングアグリーメントに追加することにしました。ここにTryを追加して、恒久的にチームのルールとして取り込むような運用をしています。

最後に実験的なTryを考えました。

ここでは、生産性指標や時間がかかったプルリクエストの課題を解決する施策を考えます。しかし、この段階でのTryは根拠に基づくものではなく、「効果があるか分からないけれども、やってみよう」という実験的な試みです。

▲Try作成からKPI確認までのワークフロー

生産性向上のためのTry紹介

効果があったTry

● 1つのプルリクエストの変更行数を100行に制限
・レビューしやすくなってマージ速度UP
・Clでチェックしてルール遵守
変更行数を抑えることにもコストがかかりますが、レビューコストを抑えたほうが恩恵が大きいという印象でした。

● レビュー依頼の方法変更
・チャットベースのやり取りから通知ベースへ
・GitHub Schedule ReminderでSlackに通知
以前は、レビュー依頼はチャットベースで行っていましたが、プルリクエストの数が増えるにしたがって、どのプルリクエストがレビュー依頼されたのかを特定することが困難になってしまいました。そこで、通知ベースに変更することで、レビュー依頼があったプルリクエストを定期的に確認できるようになり、自分がレビューしたプルリクエストに対してアクションがある場合には、通知が届くためすぐに対応できるようになりました。

●スプリントプランニングでのタスクの細分化
・100行以内の変更をイメージしてストーリーを分解
・プルリクエストの分割の手間を削減

最終的にチームがどうなったのか

▲再掲:プルリクエスト作成数が爆増しリードタイムが圧縮


【Findy Team+】には、サイクルタイム分析という機能があります

▲サイクルタイム分析

指定期間の開発サイクルの時間を平均で確認できます。
1つのプルリクエストがマージされるまでの時間を区切りで確認できますが、全体で34時間以内であれば、Findy Team+内の区分けとしては最高ランクに分類されます。そこを我々は達成することができました。
以上の結果を受けて、良かったこととしては、最初はスクラムに悩んでいましたが、チームのみんながスクラムを通じて自分たちの生産性向上に実感を持てるようになりました。今では自信を持って、開発を進められるようになっています。

まとめ

スクラムの効果に悩んだらKPIを設定しよう
○ チームの改善の方向性が明確になる
○ KPIを可視化すると課題が見えてくる

振り返りの方法を工夫しよう
○ KPIにフォーカスするのがおすすめ
○ Tryを重ねて改善しましょう

上記を意識することでチームの生産性の向上が図れると思います!

Q&A(藤澤 明慶さん/株式会社 BuySell Technologies)

●「生産性」について、どんな議論をして、どんな背景や観点を持って現在の生産性指標にしたのか、教えてください。
藤澤:Four Keysは生産性向上に向けた施策のひとつであり、それを取り入れることでチームの生産性向上が期待されます。自分たちがFour Keysのどの部分に当てはまるのかを考え、それを踏まえて現在のKPIを決定しました。

●元々スクラム経験者メンバーでの取り組みでしたか?みなさん未経験でしたか?
藤澤:ちゃんとスクラムの経験がある人はいませんでした。みんなでガイドを読んでから始めました。スクラムマスターに関しては経験者です。

●KPI良いですね、設定前後でどう変わりましたか?
藤澤:設定したものを「改善する」という意識になったので良かったです。

●2プルリクエストはどういう観点で確定したのですか?他社を参考にしたとか、コンサルのアドバイスとか。
藤澤:他社を参考にしました。

●PR数をKPIとした時、PRのサイズ感を揃える必要があるのかなと思いましたが、何か工夫されたことはありますか??
藤澤:サイズ自体を決めました。

●ワーキングアグリーメントはどういったタイミングで削除していますか?(全員がなれたら?)
藤澤:削除していません。新メンバーがきたときもこれを見てジョインしてほしいと思っています。

●スプリントを重ねるにつれてワーキングアグリーメントが増えつづけそうですが、間引き方などはあるのでしょうか?もしくは特に多さは問題視されていないのでしょうか
藤澤:間引きは現在していません。確かに多くなってきています…

●KPIに含まれない課題意識はレトロスペクティブでどのように取り扱っていますか?
藤澤:アジェンダを分かりやすいようにしていた。KPIに対してTryが出てこないときは、自分たちの課題感に対してTryを出すようにしています。

●slackでも埋もれてしまうことはなかったのでしょうか?
藤澤:スケジュールリマインダの機能で定期的に通知してくれる。間隔は30分毎にしています。

●生産性も大事ですが、開発の質を落とさないために気をつけていることを教えていただけますでしょうか?
藤澤:まずは「生産性を上げましょう」がKPIです。今はカンストした感あり。今後は、顧客の満足度やバグの数などをKPIにしていきたいと考えています。

●Four Keysの他の指標にも影響があったのか知りたいです。
藤澤:他の指標は現在測っておらず、これから他も測っていきたいと考えています。

 

続いてパーソルキャリアの西澤さんよりスクラム開発改善の道程を、失敗談も含めたリアルな経験に基づく知見を共有いただきました。


スクラム改善までの道のり

私は今回ご紹介するプロジェクトで初めてスクラム開発をしました。スクラム開発をするにあたり、関連書籍には目を通しましたが、自分の担当するプロジェクトにどのようにして落とし込めばいいのかについては、なかなか情報がありませんでした。今回はその時のお話を失敗談も交えながら共有します。

まず私が開発に関わったプロジェクト【HR forecaster】について簡単にご紹介します。
【HR forecaster】は転職サービス「doda」が蓄積した転職データ100万件以上をマーケットデータとしてご提供し、データをもとに転職マーケットにマッチした採用ターゲットを作成できる無料サービスです。

改善前の状態について

プロジェクトの歴史はこのような流れになっており、私がジョインしたのはα版リリースとβ版リリースの間だったので、まだプロジェクトとしては未熟な状態でした。

組織全体でスクラム開発を推進していたため、チームもスクラム開発を進めていました。しかしながら、サービスとしてはバタバタの状況が続いており、実際にはスクラム開発を遂行していなかったという状態でした。スプリントでタスクを区切るという単純な手法に留まっていたといえます。それでも、ビジネス側との調整に問題は生じず、重大な問題にはなりませんでした。
しかしある機能開発がきっかけで問題が起きることになりました。

事件発覚

当初は小規模なプロダクトバックログでしたが、要件が膨れ上がり、サイトの8割にも及ぶページに手を加える巨大なバックログとなって機能検討だけで、約8か月弱かかることが判明しました。構想の初期段階では、2〜3か月で実装可能と考えられていましたが、実際に着手してみると、すべての変更に1年以上かかるような状況でした。理由は“あるある”かもしれませんが、プロダクトバックログの明確な目標が時間経過とともにつれてぼやけていってしまったことが原因です。

当然、サービスオーナーは1年以上も時間がかかると思っていなかったので、想定していたビジネススケジュールとは大きく離れる形となってしまいました。
最終的な落としどころということで、機能開発はいくつかの段階に分けて実施することになりましたが以下のような課題があがってきました。

・すべてを1つのIssueで検討を進めていたので、ばらしても開発にかかる時間が膨大
→一連の機能の関連性が強く、最小リリース単位をどの程度までばらせるか検討にも時間が必要
・中でも優先したかった機能が後回しに


これがきっかけとなり、本格的にスクラム開発を改善することになりました。

改善に向けて

まずは「どうすれば回避できたか」の原因分析。目標が明確であれば各マイルストーンを設け、ユーザーの検証も段階的にできたはずだと思っています。同じことを繰り返さないために、仕組みとして機能しなければならない!
そこで目を付けたのが「見積もりをすること」です

そもそもプロダクトバックログを小さくすることは当然のことですが、実際の機能開発等の具体を想像しながらサービスオーナーだけでそれを考慮することは難しいと思います。
なので、最終的なアウトプットの責任を持つエンジニアが見積もりをし、開発にかかるコストとサービスオーナーの機能開発にかかるコスト感が一致するかどうかを認識合わせをすることで開発の計画が立てられると考えました。

以上を踏まえて安定した開発スピードを維持しながら、中長期的な開発計画を策定しやすくし、より良い経営管理を可能とすることを目指しました。最終的に、基本的なスクラム開発プロセスを実装することで、これらすべてを確立できるという結論に落ち着きました。

スクラム開発運用の変更

・バックログリファインメント、スプリントプランニング2部を実施するようにし、見積を2段階に分けて実施する
・スプリントゴールを設ける
・スプリントレビュー、スプリントレトロスペクティブを実施する

この3点を軸に運用整理を行いました。

▲イベントスケジュール

他のイベントに関しては、特別なことはやっていません。各イベントを詳しく説明します。

ここでのリファインメント作業については、次のプランニングで取り扱うことになるかどうかはまだ不透明な状況です。従って、見積もりは行うことが望ましいですが、あまりにも時間をかけすぎることは好ましくありません。ここでサービスオーナーとの合意が得られたら、開発に取り掛かります。

実際に開発を進める段階ではスプリントプランニングの1部で、このスプリントでやることの概算見積もりを見ながら、やることを決めています。スプリントプランニングの2部では、タスクの洗い出しをエンジニア全員で行います。

やってみてどうだったのか

エンジニアがスプリントに意識を向けて開発を進めるようになったため、コンスタントに成果物が出せるようになりました。この状態を目指していたので、達成できたことはとても良かったです。

これまでの開発ではベストエフォートで作業を進めていたため、自分たちがどの程度プロダクトに対してコミットできているのかわかりませんでした。そのため、ひたすら機能開発を続けていくという状態が続いており、品質改善や個人の学習時間(勉強会参加等)の機会が失われてしまっていました。しかし、スプリント内の明確な目標が出来、その目標が達成できているという自信がついたことで品質改善やその他の活動に参加しやすくなったという副次的な効果もありました。

また、タスクの洗い出しを全員で行うことで、暗黙知の共有や属人化が少しずつ軽減されるようになり、チームメンバー全体のスキルの底上げにも繋がったと思います。


スプリントプランニングの時間が足りないという課題に対して、時間を短縮するのではなく、取り方を工夫することが必要だと考えています。
一番見積もりが難しいのは、技術調査が必要なバックログ。これらは時間があればあるだけ取り組めてしまうため、目的と時間を決めて進めていく、というのが現状のやり方になります。

まとめ

ビジネスサイドとの目線合わせをするためにも、見積もりは大切な材料です。作った機能をユーザーに使ってもらうためにも、リリース時期を正確に把握する必要があります。
ただし、見積もりをしたからといって、イシューのスコープが狭まるとは限りません。もし「ユーザーに必要な機能だから時間をかけてでもやろう」という判断がされた場合は、同じチームメンバーとして、「もう少し小さくできないか」といった意見を出し合う必要があります。ダメなものはダメとしっかりと判断することが、品質改善の一環となります。

Q&A(西澤 翔利さん/パーソルキャリア株式会社)

●初めてのスクラム!一番の不安は何でしたか?dodaではないのですね?w
西澤:自身の不安というよりは、スクラム経験者がチームメンバーにいなかったので答えを聞ける人がいない。そもそもあっているかわからないというのが不安でした。

●大事件、この時モチベどうでした?スクラム体勢でどんな乗り切る工夫をしました?
西澤:モチベーションはかなり下がってしまいました。自分たちの何ができていないのか、何をしなければならないのかをメンバーに説明して、プロジェクトに対する未熟さを認識することができました。この説明は、一つの工夫でした。今後も引き続き改善点を見つけていきたいと思います。

●「俺たちの考える最強の機能」これは危険ですよねwこれで失敗したこと何度もあります。パーソルさんは色々サービスありますが、他でもスクラムでやっているのですか?知見の共有体勢なんかも気になります。
西澤:この組織に入って長いわけではないのですが、私が所属する部署では勉強会やプロジェクト間での情報共有ミーティング等を定期的に開催し、ノウハウの共有をしたりしています。Findy Team+を使ってスクラム改善を図っているようなチームもあります。

●改善に向けたハンドリングは全部西澤さんが担当されたのでしょうか? 入社してまだ慣れてないタイミングですごいなと思いました。
西澤:私が担当していました。ただ自チームのリーダーやメンバーと課題の擦り合せをしながら今の形にしていきました。

●結論のところに書かれているプロダクトバックログの分割ってどういう意味なのでしょうか? プロダクトバックログ自体は1つというイメージだったのでちょっと気になりました。
西澤:複数のシナリオが入っているバックログのことを指します。
何を解決できていないのかを明文化できていないと、複数同じことが入ってしまい失敗してしまうことがありました。

●パーソルさん、安定した開発スピードを維持するためには、どうしても人数の上下の影響が強く出るかと考えておりますが、そのあたり何か工夫していることはありますでしょうか。
西澤:人数は増やしすぎない方が良いと思っています。人数を増やすと逆にスピードが落ちる場合もあるのでその点は気をつけています。
また特定のメンバーへの依存が強くならないように、全てのエンジニアで設計をしたり、スクラムイベント内で暗黙知の共有の機会を作ることで全てのエンジニアの能力の底上げに繋がるような工夫はしています。

●スプリントゴールは、どんな観点で、どんな粒度で設定していますか?
西澤:Tシャツ見積で見積もっている部分がハマるのかどうかで設定しています。タスク単位でみています。

●スクラム開発で一番の困り事をお聞きしたいです。
西澤:スプリントプランニングは、いつも時間が足りないものです。特に、技術調査などが含まれている見積もりが難しいタスクは、スプリント内で進めるのに課題があります。こういったタスクは、できるだけ早めにスプリントプランニングに組み込むことが必要です。
また、プロジェクトのヴェロシティが安定していない場合は、タスク量のコントロールも重要になってきます。そういう場合は、前回のスプリントの振り返りを行い、今後のスプリントでタスクを調整することが必要です。さらに、プロジェクトへのコミットが限られているメンバーがいる場合も、タスク量のコントロールは重要です。そういう場合は、メンバーの能力や状況に合わせて、タスクを割り振ることが必要です。

●今月からスクラムマスターを任されました!先輩方に、立ち上げ時これやっといた方がいいよとか、やっておけばよかった〜というのがあれば教えてください!
西澤:スクラム開発をすることで自チームの何を解決したいのか目標をハッキリさせた方が良いかなと思います。
スクラムイベントを回すことが正となって、目的と手段が逆転してしまうケースは避けたいです。
タイミーさんと回答が被りますが、そのためにもスクラム開発の理解はチーム全体で共通認識を作った方が良いと思います。私のチームではスクラムガイドの輪読会を実施してあーだ、こーだ言いながら認識合わせを実施する機会を設けました。各イベントが何のために必要なイベントなのか理解しておくことで守破離のようなものが身につくかなと思います。

●趣旨が違うかもで申し訳ないですが、開発手法より「結局人でしょ」「退職で崩れちゃったよ」みたいなことってありません?
西澤:私は個人への依存は大なり小なりあるかなと思います。ただ特定のメンバーへの依存を強いまま放置するとチームとしての生産性は上がらない、そのメンバー外れた時に崩壊するので特定のメンバーが持つノウハウや、暗黙知を共有する場をスクラムイベント内で設けて、チーム全体の平均が向上するようには努めています。

●デザイナーやエンジニア混合のチームでのスクラム事例がもしあれば聞いてみたいです。
西澤:混合と言って良いのか分かりませんが、私のチームでは
①POがPBI作成
②デザイナーが入ってPOとPBIをリファインメント
③デザイナーがブラッシュアップしたPBIをエンジニアがリファインメント
④開発着手可能なPBIになったら着手
という流れで進めています。スクラム開発ではデザイナーが登場人物として出てこないので当初戸惑いましたが、リファインメントを一緒に行っていくという立ち位置で関わっています。スクラムイベントに関しても出席してもらっていますが、やっていることはエンジニアと違う時間軸で動いていることが多いです。

●4つ質問があります
・スウォーミングで対応してますでしょうか?
・タスクはサインアップでしょうか?
・ふりかえりにPOも参加してますでしょうか?
・メンバーはそれぞれPJ掛け持ちありますでしょうか?
西澤:
・スウォーミングで対応してますでしょうか?
→現状特に指定はしていないです。ですが、設計は全員で行います。開発についてはタスク同士の依存関係もあるので一概には言えませんが、複数人で作業可能なものは可能な限りメンバーを割り当てます。
・タスクはサインアップでしょうか?
→サインアップ形式を基本としています。前述している通り設計はエンジニア全員でやっているので特別難易度が高い場合を除いて、アサインの意味合いが薄いです。(希望が出なければアサイン)
・ふりかえりにPOも参加してますでしょうか?
→参加していますが、オブザーバーとして参加している時の方が多いです。
・メンバーはそれぞれPJ掛け持ちありますでしょうか?
→あります。なるべく排除したいのですが、リソース等の都合もあり発生しています。
その場合は各スプリント内でどの程度プロジェクト内にコミット出来るか時間単位で割り出し、時間当たりのヴェロシティと掛け合わせてタスク量を調整することもあります。

●作業時間が見積もりした時間よりオーバーすることが多く、残業することが多いですが、どのように工夫すればよろしいでしょうか。
西澤:「実績がない作業で、感覚でつけることが多い」とあるので、恐らく見積もりのナレッジが少ないのかなと思いました。
開発が完了した後に見積もりの振り返りを実施してみてはいかがでしょうか?自分たちの付けた見積もりと作業時間を比較して、再度見積もりをし直すと自分達の実際のヴェロシティが明らかになると思います。
あとはタイミーさんの回答にもある通りですが、相対比較がよく言われる方法なので見積もりし直したタスクをプランニングやリファインメントの見積もりの際に利用すると良いと思いました。
また、見積もる際に必要な作業が見積もれていないケースも考えられると思います。開発タスクは当然そうですが、レビューの時間やQA等マージされるまでに必要な工程が見積もりに含まれていないケース等も私はあったので、それらの作業も見積もりとして含めると良いと思います。


最後にスクラム開発を最小で実施する知見共有をYuichiro ABEさんより共有いただきました。

スクラムを最小で実施するために、やったこと&やめたこと

 

スクラムを最小で実施するために、やったこと&やめたこと - Speaker Deck

みなさんにとって、スクラムは難しいですか?
やはり難しい部分があるからこそ、今回のようなイベントが開かれていると思いますが、ではなぜスクラムは難しいのでしょうか。難しいのは、本当にスクラムなのでしょうか?

私はそもそも開発方法がなんであれ、プロダクト開発が難しいと思っています。
ちなみにスクラムガイドを見てみるとスクラムは軽量級のフレームワークらしいです。さらに読み進めると意図的に不完全であり、理論を実現するための必要な部分のみが定義されていて様々なプロセス、技法、主要を使用して実践する人たちの集合知で構築されていると書かれています。
よって私は、スクラムを「最小の仕組みで、最大の価値を生み出す」というように捉えてみました。
今日は、この側面でお話をしたいと思います。
さて、私たちは最小の仕組みからスタートできているのでしょうか?

実際にはそんなことはなくて…

・長い年月をかけて作られた会社の規則
・既存の仕組みに慣れすぎた社員
・積みあがった様々な負債
…etc

こんな感じで、スタートの時点で抱えているものが多すぎると思います。
その結果、「スクラムはスタートアップ向き。我々には合っていない」となり、スクラムとお別れすることが多いのではないでしょうか。しかし、ちょっと待ってください!
スクラムガイドにもありますが、

引用元:スクラムガイド

「その存在を不要にする」ここに注目してほしいです。今やっていることが必要なのか見つめなおし、不要なことを捨てる勇気を持つことが大事ということです。

Timee(タイミー)について

ここで私が開発に関わる【Timee(タイミー)】についてご説明します。

前提として弊社は設立約5年のスタートアップなので、そもそもしがらみが少ない&捨てやすい環境です。

スクラムを最小に実施するためにやったこと

・スクラムガイドを読み、守破離の守を大事にする
・困ったときに最小限

まずはこの2点を実施しました。

スクラムガイドを読み、守破離の守を大事にする

チームメンバーでスクラムガイドを読み込み、抽象的な表現やわからない部分を質問や感想を言い合い理解する時間を設けました。

▲実施の様子。Miroを活用

miro上にスクラムガイドを1枚ずつ貼っていき、マーカーや付箋などを使って勉強をしました。
やり方としてはセクションを区切って読んでいき、そこまでの疑問や感想などを話していきました。
これによって、スクラムの基本的な型をチームで共有できたので、守破離を徹底しやすくなったと感じています。意識したのは“それはスクラムガイドで示されているか”というキーワード。

「自分たちの取り組みはスクラムガイドに示されているか」それを意識することによって、その取り組みがスクラムによるものなのか、そうでないのかをチームで考えるように促しやすくなっていると思います。

「このイベントに自分はいらないよね」とイベントを実施しない人も実際にいますが、基本的にスクラムというのは、チームの透明性を保つために必要な要素が含まれているので、そのイベントや仕組みが何のためにあるのかを考えた上で、基本的にはその型通りにやった方がいいと思っています。

私がよくやる動きとしては下記2点です。
・守から外れそうになった時に、スクラムガイドを参照する動きをする
→例:「スクラムガイドにはこう書かれているよね」として動く
・スクラムガイドの解釈が不安になったら、認定スクラムマスターを受講したり、外部のスクラムマスターに相談する

困ったときに最小限

スクラムに限ったことではないかもしれませんが、チームが軌道に乗るまでは課題が山積みで、あれもこれも解決したい!となりやすいですよね。
課題を全部まとめて解決できる、魔法のようなソリューションがほしいと思いますが、基本的にそんなものは存在しないと私は考えています。
ただし、課題が解決できるような有効なアクションを探索すること自体を否定するわけではありません。

最初のうちは課題を分解してなるべく簡単に小さく試せる解決策を試してみることが重要
そしてレベルアップしていくのが良いと思います。
実際は、考えた解決策が上手くいく保証はなく、逆にうまくいかないこともあるでしょう。同じように、一般的に有効とされるプラクティスが役に立たないこともあるかもしれません。最終的には、チーム自身で実験を繰り返して、うまくいかなかったとしても、何が問題であるかを話し合い、実践することで解決策を見つけることが必要だと思います。様々なアクションを繰り返し、成長していくことで、より複雑な課題を解決できるチームになっていくと思います。

ちなみに自分のチームではスプリントは短く1週間単位で設定しています。
<利点>
・実験の試行回数を増やせる
・失敗してもきになりにくい

スクラムを最小にするためにやめたこと

・PdM(プロダクトマネージャー)がチームをマネジメントする
・プロダクトバックログアイテムのフォーマットに拘る
私たちのチームはこの2点をやめました。

PdM(プロダクトマネージャー)がチームをマネジメントする

「PdM(プロダクトマネージャー)がチームをマネジメントするのをやめた」きっかけは
PdMがチームメンバーと1on1を実施してメンタリングして、評価者になっており、その結果下記のような状況になっていたからです。

・PdMがプロンプトと向き合う時間が減る
・PdMが不在の時に意思決定できないメンタルになる
・チームの改善をチームが実施しない

<具体的な改善策>

要するに、PdMはプロダクトオーナーであり、プロダクトオーナーはプロダクトに向き合う人であるという意識を、PdMや開発者に理解してもらうように伝えました。

その結果チームは自分たちで意思決定ができるようになり、PdMは顧客価値創出のための、ユーザーインタビューなどに時間を使えるようになりました。

プロダクトバックログアイテムのフォーマットに拘る

続いて「プロダクトバックログアイテムのフォーマットに拘る」をやめた件についてですが、まずはフォーマットについてご説明します。

基本的に、プロダクトバックログはオンライン(Notionなど)で管理していると思います。私のチームもNotionを使っていますが、チームからの新しいアイデアや課題があったとき「PBIを起票するのは、なんか重いので自由にやりたい」という声がありました。
※PBI=プロダクトバックログアイテム

PBIがドキュメントのように扱われ、事前に色々な情報を書かされるテンプレートが存在すること「テンプレを埋めなきゃ」という空気感を重いと感じてしまいがちです。
そこで、起票時にテンプレートを埋めるのをやめました。

<具体的な改善策>

結果として活発にPBIを通じて議論が行われるようになり、何かあればPBIを通じて話がはじまるようになりました。

まとめ

最後にスクラムであろうとなかろうと、上手くいっていることは良いこと!
しかしこれからもずっと上手くいくとは限らない。スクラムは上手く使うことによって、間違いを発見する機会を作れるので、それを見逃さずにチームを改善していけば良いのではと思っています。

Q&A(Yuichiro ABEさん/株式会社タイミー)

●タイミーさんは、去年あたりからDevEnable室を作られたそうですが、それによってスクラム開発にもなにか変化はありましたか?
ABE:スクラム開発そのものに直接的な影響は多くないです。雑多なものをお願いできる仕組みもあるので、開発者の体験はよくなったと思います。

●「そもそもスクラムが難しいんじゃなくプロダクト開発が難しい」これはいきなり格言だ。あべさんのオリジナル格言ですか?
ABE:資料作りながら思ったことです。先週受けた研修でも似たようなことを講師の方が仰っていました。

●抱えているものが多過ぎる、これ分かるなぁ。これにどう気付けるか、なにが不要なものなのか、この対応できる、できないって経験ですかね?
ABE:書かれてないことは基本的にはオリジナル。外からもってきているものだと思います。不要かどうかは捨ててみてください。捨てると何かしら課題が出てきて、そこで気づけると思います。

●らずさん、タイミーに入社する前からスクラムマスターなのですか?トークがおもしろいですが、これはスクラムマスターに必須なスキルな気がするw
ABE:タイミーに入社して任命されました。

●フルリモートでの体制、miro活用についてお話いただいたので参考になります。他にも使われているツール等あればお聞きしたいです。チャット等。
ABE:slack、Meet、Miroが社内では全体的に使われています。

●外部のスクラムマスターに相談するとありましたが、どのように人脈を広げているのでしょうか。
ABE:スクラムマスター研修を受けると繋がりができます。スクラムマスターはスクラムについて語りたい人多いので、「相談したいんですけど!」とコンタクトを取ってみてください。

●スクラムガイドの理解を徹底させる、良いですね。この理解を進めるうえで工夫されていること等があればお聞きしたいです。
ABE:いっぱい引用すると良いと思います。先行する人がいちばん詳しくなっていきます。具体的なことは書いていないので、具体的なことを伝えてあげると理解が深まると思います。

●タイミーさん、なんとなく社内コミュニケーションのハードルが低い感じでうらやましい。
ABE:ありがとうございます♪

●スクラム開発で一番の困り事をお聞きしたいです。
ABE:課題を分解できない複雑な問題にどうやって取り組むべきか。いまだに答えがありません。基本的には分割して取り組んでいますが、それによって失われてしまっている価値が存在している可能性は捨てきれないので、今後なんとかしていきたいって思っています。

●今月からスクラムマスターを任されました!先輩方に、立ち上げ時これやっといた方がいいよとか、やっておけばよかった〜というのがあれば教えてください!
ABE:発表の中でも言いましたが、全員でスクラムを理解するっていうのをやるのが良いと思います。あとは、スクラムマスターであるなら、逆に何もやらないっていうのが大事な時もあるかなって思います。あとは、odd-eさんの認定スクラムマスター研修を受けるのは、おすすめしておきます笑

●テンプレをやめるとどういう粒度のPBIが起票されるようになったのか気になります。
ABE: 様々な粒度のPBIが起票されます。でも、重要なのは起票時の粒度ではなく、リファインメントで対話を進めることです。その内容は今のプロダクトゴールに関係するのか?取り組まないことで、どんな問題があるのか?そういった会話をするきっかけにすぎないと考えているので、粒度が問題になったことはないです。

●4つ質問があります
・スウォーミングで対応してますでしょうか?
・タスクはサインアップでしょうか?
・ふりかえりにPOも参加してますでしょうか?
・メンバーはそれぞれPJ掛け持ちありますでしょうか?

ABE:
・スウォーミングで対応してますでしょうか?
→現状特には指定してないです。各々がやれることをやっています。
・タスクはサインアップでしょうか?
→Yes
・ふりかえりにPOも参加してますでしょうか?
→POはスクラムチームのメンバーなので参加してもらっています
・メンバーはそれぞれPJ掛け持ちありますでしょうか?
→デザイナーやアナリストは組織的に人が少ないので、兼任や別の仕事をしています。
POやSMも2チーム見たりしています。

●作業時間が見積もりした時間よりオーバーすることが多く、残業することが多いですが、どのように工夫すればよろしいでしょうか。実績がない作業で、感覚でつけることが多いのが原因ではありますが。

ABE: 一般的に良く言われているのは、作業時間での見積もりをやめて、作業量で見積もる。見積もりは過去にやったアイテムとの相対で見積もりする。っていうのが、よく言われていますが、質問者さんの状況次第なので、なんとも言い難いところではあります。

次回のイベントレポートもお楽しみに♪