株式会社ハンズシェアで技術系マネージャーしているきょんすけです。Twitterでは @kyonsuke19101 で活動しています。マネージャーとしては1年ぐらいで、会社・チームのみんなに助けてもらいながら、日々チームをカイゼン（トライ＆エラーともいう）しつつプロダクトを磨いております。

今回は弊社の開発チームでの取り組みの中で結構うまくいったのでは！？と思えるスクラム開発においてインターバルの期間を取るというものについて記事にしました✌('ω')✌

弊社チームでのスクラム開発

スクラム開発に関しての説明に関しては検索すると、こちらや公式的ガイドのスクラムガイドなど素晴らしい資料がざくざく出てきますので、そちらにお任せしてここでは弊社でどのようなスクラム開発を行っているかについて記載…しようと思ったところ、既に詳細について記載してある記事がありましたのでこちらをご参照下さい。

ざくっと弊社のスクラム開発を説明しますと

• スプリント期間は2週間
• チームで行うスクラムイベントは以下になります
• • プランニング
  • レビュー
  • レトロスペクティブ
  • デイリースクラム
• バックログリファインメントはPOと私が担当しています

スクラム開発で起きた問題や課題

スクラム開発を運用してみて、スクラムはチームでの開発を円滑に進めるために有用なフレームワークだと感じています。特にタスクマネージメントが分散されることで、マネージャーがタスク管理と細かな指示をしなくても、開発チームとしてプロジェクトを推進していけるようになり、自己組織化されたチームに近づくのが素晴らしいです。
ただ、運用していくにつれ、いくつか問題も見えてきました。

ビジネス要件と技術要件の優先度が付けづらい

POがビジネスサイドの人なので、バックログ上で技術的タスクの優先度を付けづらい。逆に私は技術サイドなので、また同様の問題になる。

スプリント内としてフォーカスする部分がぶれる

特にビジネスと技術を混ぜ込むとおきやすい。会員数増加とCSコスト削減のための実装とCIツールの改善と…といった形で闇鍋のような状態になり、どこ目指して開発しているんだっけとなってしまう。またフォーカスしてないためレビューの指摘も局所的な物となり、全体としてスプリントゴールに向かえたのか、掲げた目標に近づいているのか、という話が行われづらい。

振り返りで出たTryをやる時間がない

弊社のスクラム開発におけるレトロスペクティブではKPTを用いた振り返りをしており、そこで出た続けたいこと（Keep）や問題（Problem）に対する改善策（Try）を実行することで、改善のサイクルを回していますが、スプリント期間中はスプリントバックログにフォーカスするため、時間を割くTryの場合は後回しになりがちという問題がありました。

エンジニアが個々に立てた目標に向かう時間がない

クォーター毎に目標を立てていますが、技術的な目標を立ててもプロダクトロードマップに縛られ、そこに向き合う時間が確保しづらい。プロダクトロードマップに巻き込む場合は優先度によって落ちたりする可能性や、また皆でやるタスクになるので個々の目標からは少し外れがち。

これら問題に直面して、今クォーターから始めた取り組みがスプリントにインターバルを設けるというものです。

インターバル期間を設けてみる

取り組みの概要としては以下のような形になります。

• スプリント期間を7日間とし、インターバル期間を3日間とする。合わせて2週1サイクルとなる
• インターバル期間では以下のことを行う
• • スクラムイベントのレビューとレトロスペクティブ
  • ビジネス要件を除くプロダクト改善（リファクタリングやテストの改善など）やチーム改善
  • 各自目標に絡む業務
• スプリント期間ではビジネス要件のプロダクト開発にフォーカスする
• • （ただし技術面でも検証等のプロダクトロードマップに関わる事項は行う）

期間を区切って、それぞれビジネス面の改善とそれ以外の改善に切り分けた形になります。優先度が付けづらいなら最初から分けてしまえば良い！という発想です。

結果

結果として切り分けたことにより、このような良いことが起きました。

メンバーの目標に対するコミットの増加

• e2eテストの充実化
• テックブログの定期更新
• 広報採用活動の強化

1on1 と絡めて定期的に状況を確認しつつ目標に対する行動をブラッシュアップし、インターバル期間を活用してコミットしていくというサイクルが回っています。

自発的なチーム改善行動の増加

メンバーからの立案で理想の開発チームを語る会開催。こちらもインターバル期間に行いました。またモブプロの開催や自発的なペアプロも行われるように。スキルシェアの意味でも開発の連携力的にも良い方向に進んでいると思います。

スプリントゴールの明確化により、ゴールにフォーカスした議論の増加

目的を達成するために最も重要な部分はどこか、逆にそぎ落としてもいい部分はどこかという議論が起こるようになり、目的達成のための開発というのがより推進されるようになりました。

インターバルの期間を設けたことで、メインのプロダクトに直接大きく関わらないけども、将来的な開発チームのアウトプットを増やしていく活動を気兼ねなくやることが出来るようになり、チーム内に主体的に改善していこうという正のフィードバックサイクルが生まれているなと感じています。

次に向けて

インターバル期間の取り組みは良い手応えを感じていますが、いくつか検討すべき事項もありますので、更にブラッシュアップしつつ次クォーターでも運用していけたらと考えています。

良い手応えはあるが、具体的な数値とかで変化を示せていない

故に良さが普遍的に説明しづらい。また恐らく日数が削れるため一時的なビジネス要件へのアウトプットは下がると思われる。将来を見据えた話が出来ないときつそう

日数に関しては検討の余地あり

レビュー、レトロスペクティブをスプリントに入れて、インターバル2日でも良さそう。スプリントでのアウトプットとのバランスを取っていきたい

目標絡み以外の技術的負債をまだ余り返せてない

技術的負債は場当たり的な物だけでなく、きちっと方針決めてプロジェクトとして進めないと辛い物もあるので、余り手がつかなかった。また目標とそれ以外のバランスという問題も

外部のエンジニアリングマネージャーや技術組織作りに関わっている方とも技術組織作りに関して色々お話をしたいので、よければ @kyonsuke19101 宛までDM下さい！　ランチやお茶しつつお話しできれば嬉しいです(｀・ω・´)

最後に弊社ではプロダクトを作るだけでなく、チーム・開発改善もセットでやっちゃいたいエンジニアを募集しています。いわゆる”僕が考えた最強の開発組織”を一緒に作りましょう！！！