SQUEEZE のスクラムとモバイルワークの取り組み
株式会社SQUEEZE はプロダクト開発のプロセスとしてスクラムを採用しています。今回は半年にわたり試行錯誤と改善を続けてきたプロセスについて、スクラムマスターの立場から共有します。
何をつくっているのか
SQUEEZE は「価値の詰まった社会を創る」をミッションに掲げるスタートアップ企業です。価値あるものを共有したり、活用しきれていない価値を掘り起こして活用したりといった ”シェアリングエコノミーの発展” にフォーカスを当てた事業を展開しています。
SQUEEZE は創業時から、シェアリングエコノミーの領域である “民泊” を事業の1つの軸としています。現在、民泊に限らず旅館やホテルなど “宿泊施設のオペレーション” にまつわるさまざまな課題を解決するソリューションとして “suitebook” というプロダクトを開発・運営しています。
suitebook は Airbnb の API 連携公式パートナーとしてシステム連携をしていたり、楽天コミュニケーションズ様との取り組みで あんしんステイIoT というサービスを提供したりもしていますよ。
どのようなチームなのか
プロダクト開発部門は、CTO、プロダクトオーナー (PO)、エンジニア、開発パートナーで構成される 5–8名程度のチームです。その中で筆者は技術顧問として 2016年7月からビジネス推進の支援をしています。
開発チームの雰囲気がよく分かる取材記事を紹介します。
昨今は特定の言語や技術にこだわるということも少なくなってきていますが、2017年に Python のカンファレンス PyCon JP 2017 でダイアモンド・スポンサー（スポンサープランの中で最上位）を担うなど、Python を中心に OSS への貢献心を大事にしているチームです。
毎月開催している Python もくもく会 も毎回一定数の参加がある人気のイベントになっていますよ。
Tl;Dr 2018年11月時点のプラクティス
まず結論から、ということで、試行錯誤の末に現在取り入れているプラクティスのうち、重要なものを以下に記します。
- スプリント期間は6営業日 (約1週間)
- リリースはスプリント期間中複数回行う
- モバイルワーク環境とのコミュニケーション改善のために Zoom 常時接続
スプリント期間
まずスプリント期間について、2週間 (10営業日) では長い という考えに至り、より短く実証と改善のサイクルを回せる6営業日をスプリント期間と定めました。
6営業日というのはきりの良くない日数ですが、スプリント1週間 = 5日間の場合、実際の開発にあてられる時間は理想的にいって4日間程度です。スプリント期間中の1日分は、スプリントにおけるセレモニーや、全社ミーティング、採用面接、その他諸々にあてられることになるためです。
5日間は開発の時間にあてられるよう、6営業日と設定しました。
リリース
リリースについては、元々 “出来たものから出荷する” プロセスが根付いていたので踏襲し、1週間に 1–3回のリリースを行っています。
スプリントレビューを設けず、Pull Request 単位でプロダクトオーナーの確認をとおし、いくつかの Pull-Request をまとめた release branch をデプロイする、というプロセスです。
コミュニケーションとビデオチャット
SQUEEZE ではモバイルワークを積極的に取り入れています。スクラムでは顔を突き合わせたコミュニケーションを尊重するなど、身体の同期性を重んじる傾向にあります。モバイルワークとスクラムのコミュニケーションに対する思想は衝突する部分もあります。
筆者はスクラムの考え方に同意しますが、現代のワークスタイルを踏まえるとモバイルワークへの適応も必要です。SQUEEZE ではビデオチャットツールとして Zoom を採用し、スクラムのセレモニーでの利用のほか、チームメンバー同士が気軽に会話できる環境を整えています。
※ モバイルワークについて: SQUEEZE ではいわゆるリモートワークのことを意識的にモバイルワークと呼んでいます。リモートという言葉には、”本拠地に対してのリモート” という意味が含まれており、そこには主従関係が存在します。SQUEEZE の理想のワークスタイルは、どこにいても1つのチームとして活動できるということで、主-副 や 主-従 の関係ではないからです。
※ スクラムとビデオチャットについて: スクラムでは、リモート環境やビデオチャットを用いてはいけないと明示されているわけではありません。ただし、スクラムやアジャイル開発をするにあたり、情報を素早く適切に伝達するためには Face to Face が望ましいというプラクティスが共有されています。技術の進化によって高品質なビデオチャットは Face to Face と見なしてよいという考え方もあるかも知れませんね。
※ チームと身体性について: 人間の体が送受信する情報量というのは存外多いもので、私たちはわずかな差分から、他人の体調や気力の高低、悩みごとの有無といった情報を受け取ることができます。これらの情報量の一部は、ビデオチャットのようにデジタルデータに変換されることで欠落してしまいます。時間と場所を共有することの有効性を認めつつ、同時にこれは技術によって近い将来解決されると期待しています。
まとめを提示したところで、ここに至るまでの経緯を記載します。
スクラム導入の経緯
2018年3月、開発チームの生産性についての課題意識が経営チームやプロダクト責任者との議論で顕在化されるという一幕がありました。
ビジネス側の求めるスピード感に対してプロダクトが追いついてこない、四半期で決めたはずのマイルストーンが守られないなどの “スタートアップあるある” な課題といえばそれまでなのですが、何が起きているんだろう？ ということを明らかにする必要があったということから今回の話が始まります。
SQUEEZE では、以下にお話するスクラムの本格導入以前に、”スクラムのような何か” で開発サイクルを回していました。しかし、これもしばしばあることなのですが、朝会はやるけれどもレトロスペクティブはやらないといった、スクラムのプラクティスを部分的にのみ導入していたこと、スクラムマスターの存在が曖昧な状態だったことなど、スクラムのメリットを享受できる状況になっていないという問題が起きていました。特に課題に感じたのが、ベロシティに関する意識が低く、スプリントによってばらつきが大きすぎ、チームの実力が測れないという点でした。
スクラム（本格）導入の狙い
そのような中で、筆者がスクラムマスターとして開発プロセスをみなおすこととなったわけですが、その狙いは次の一点でした。
何が起きているのか明らかにすること。
重要なことは、納期どおりに仕事が進むようにしたり、生産性を向上することを目的にしていないことです。No Silver Bullet = 銀の弾丸はない という金言はスクラムにおいても当てはまります。
※ スクラムと生産性について: スクラムにおいて生産性の向上とは、”何がおきているのか明らかに” した次に、その明らかになったボトルネックを解消することで得られる副次的な効果、だと捉えるのが良いでしょう。もちろん現状把握と改善はある程度 “対” なので、生産性の向上が狙いに含まれていないわけではありません。CEO との会話の中で、スクラムマスターとしてベロシティの向上にコミットしますと宣言していたことも事実です。
まずベロシティの計測から — 2018年4月-6月
ということで 2018年4月からスクラムプロセスの改善にチームとして取り組みを開始しました。スクラムをフォーマルに取り入れることを重視したため、特筆するべき工夫はこの段階ではさほどありません。概ね以下のような合意事項 (Working Agreement) でした。
- スプリントは10営業日 (約2週間)
- リリース日を決めて、スプリント期間中に複数のリリースを行う
- セレモニーはスクラムのプラクティスに従う
- スプリントプランニングの時点で、担当をアサインしておく (変更はしてよい)
重視していたのは、とにかくベロシティを計測するということでしたので、2週間ではなく 10営業日 をスプリントの期間と定めました。これによるメリットは、祝日や実質的な非稼働日によって開発期間が少なくなることがないという点です。デメリットはスプリントと曜日を連動させられないことですが、特に問題は見られませんでした。
この期間の振り返りを KPT で整理してみます。
Keep
- ベロシティを適切に計測できるようになった。それにより個人の消化ポイントにばらつきがあるなど課題を顕在化できた
- スプリント毎に課題を解決しようという意識が高まった
Problem
- 四半期の始めにたてた計画と比較してずれが生じた
- ベロシティがプレッシャーになり常に追い立てられながら開発をしている空気があった
- スプリントプランニングにおいて、ストーリーポイントの見積もりに時間がかかり過ぎていた
- バックログリファインメントに関する運用が曖昧になっていた
これらを踏まえた Try として、1つは目標設定に関するものがありました。当初から目標設定と実績の乖離が問題になっていましたが、そもそも達成できない目標設定 = 実力以上の設定だったのではないか? ということがこの段階で浮き彫りになりました。ベロシティ計測が適切に行えていなかったのだから当然と言えます。
“次の目標設定は3ヶ月にわたり計測したベロシティに基づいたものにする” というのが重要な Try となりました。”追い立てられ” るように感じるという状況も、目標設定と実力との不和だと考えられました。
ストーリーポイントの見積もりにかける時間の肥大化も課題でした。これは、”リファインメント” に関する運用が曖昧になっていて、プランニングのときに一度に全て整理しようとしていることが原因と思われました。そこで、リファインメントについてもその他のセレモニー同様、実施するタイミングを定めて運用することを Try としました。
コミットメントについて考える — 2018年7月-9月
4–6月の三ヵ月の成果として最も大きかったのは “現状の可視化” だったと言えます。いっぽう、ビジネスサイドの要求に充分に応えられていないという感覚は解消されないままでした。これは、四半期計画と実力の乖離がもたらすものだと考えられました。そこで、三ヵ月の実績をもとに、7–9月の計画を行いました。
ここまでで何度か登場している “四半期計画” とは、スタートアップビジネスがマイルストーンを達成するために完了されている必要があるもの (例えば他社との事業提携 ) と、それに必要なプロダクト開発上のマイルストーン (例えば他社API との連携) とを協調させるために行う計画のことです。具体的には、ストーリーポイントが見積もられていないバックログに対して “概算で” 見積もりを行い、ポイントの累計と1スプリントで消化できるポイント数を照らし合わせ、機能がリリースされる時期の目安をたてます。
具体的に次のようなプロセスの改善を行いました。
- 四半期計画を実体に沿うよう調整
- リファインメントをスプリントの折り返し地点 (5–6日目) で行う
- 事前アサインをやめて、手が空いた開発者が自発的にスプリントバックログを取る
事前アサインをやめたのは、チームに自立性をもたらす目的でした。事前にスプリントバックログがアサインされていると、 “自分に割り当てられたものだけ消化すればよい” という意識が芽生えがちです。本当に達成するべきは “チームとして” 成果を最大化することなので、そのために必要なことを考えて実行してみようという意図がありました。
この期間の振り返りを同様に KPT で整理してみます。
Keep
- リファインメントをスケジュールしておくことで、バックログがクリアに保たれ、スプリントプランニングの負荷も減少した
- ベロシティの計測
Problem
- 四半期の始めに計画を立てた時点と状況が変わる。あらたな問題や事実の発覚により計画どおり行かない (バッファを含めてもなお)
- 消化ポイントや稼働の偏りが大きくなった
- 最低限必要なマイルストーンは達成できたが、余力がなく、技術的負債解消が後回しになる
この次期、開発チームはコミットメントを守らないといけないというプレッシャーに晒されていた苦しい状況だったと振り返っています。スクラムマスターとして、コミットメントとはなにか、という重要な点に対する咀嚼とステークホルダーへの働きかけが不充分だったと内省しています。
※ 開発チームとコミットメントについて: 開発チームは何に対してコミットメントをしているのか? という話はまたどこかで。
得手不得手に基づく最適化
SQUEEZE では、開発チームのスキル傾向にできるだけばらつきを生まないよう、フロントエンドやバックエンド、インフラなどの領域を区別せずに実装担当をアサインしていました。これはスクラムのプラクティスの1つでもある、チームの能力に大きなばらつきがないほうがよいということに合致する方針でもあったのですが…
暫定的な結論としては、短期的な成果を求めるのであれば得手不得手に基づいた最適化をしたほうがチーム全体のベロシティが “控えめにいって劇的に” 改善するということが言えます (これは現在体感中の事実です)。
理想をいえば皆がプロダクトのあらゆる機能に詳しいほうが良いですし、あらゆる機能を同じスピードで開発できたほうが良いと言えます。中長期的視点に立つと、暗黙知の拡大や属人化の抑止、サステナブルな組織を形成するためにも均一化への働きかけは必要なことでもあります。
いっぽう、フロントエンド1つとっても広大な知識を必要とされる昨今、平均的で分散の少ないチームで物事に取り組むより、高い専門性をもつ技術者の総力を結集して取り組んだほうが成果を上げられるという現実もあります。
これを踏まえた Try として、インフラや CI に関するタスクを担うチームを狭義の開発チームとは別に設置し、ベロシティの計測外とする取り組みを次の四半期に行うことにしました。また、フロントエンドのリファクタリング (AngularJS -> Angular への移行) を担うチームについても同様にベロシティの計測外としました。
自己組織化とモバイルワークの強化-2018年10月-12月
これは現在進行形のフェーズです。日々改善を続けていますが、現在の取り組みは冒頭 “Tl;Dt 2018年11月時点のプラクティス” にまとめたとおりです。
プロセスとしては、スプリント期間を 10営業日から6営業日に変更したことが最も大きな変化です。4スプリント実行してみた結果、6営業日スプリントに対して以下のメリットを感じています。
- 改善のプロセスを早く回せる
- プロダクトバックログの調整が柔軟にできる
セレモニー開催頻度が高まることによる影響 (スプリント期間と各セレモニーの開催時間はある程度比例するので倍になるわけではない) は、今回スプリントを6営業日としたように、あらかじめ計画に織り込んでおけば問題ないと感じています。
短いイテレーションになりリズムをとりにくなったという感想を持つ場合もあるようですので、絶対的な正解ではない点には注意が必要です。
また、スプリント期間を短くしてもリリースについては従来どおり “複数回行ってよい” という運用を続けています。
フルモバイルワークの開発メンバーが加わったことにより、モバイルワーク環境の改善が図られたことも変化の1つと言えます。
いま困っていること
終わりに、スクラムらしく (?)、目下の Impediment List= 障害 項目 を2つ共有します。
1つ目は、開発プロセスの最適化が進んだことで、実装後のレビュー〜 POの確認 〜 リリースのパイプラインがボトルネック化してきたことです。実装は終わっているのにレビューが完了しない、レビューは完了したのに PO の確認が完了しないといった連鎖で、バックログが完了しないというケースが表出するようになりました。
実装速度が比較的ボトルネックになってきたという SQUEEZE の歴史を鑑みるとこれは嬉しい悲鳴ではあるのですが。特に PO はスクラムプロセス上も 1人と定められており人数的にスケールしないポイントですので、責務が多くなってしまっているのではないかと見ています。
レビューについては、リリースまでのパイプラインの1つであることを意識して取り組もうという確認をレトロスペクティブで行ったところです。
2つ目はツールの話題なのですが、現在レトロスペクティブとして、付箋紙と模造紙という “物理カンバン” を用いた振り返りを実施しています。
この “物理カンバン” は身体性を重視した取り組みなのですが、モバイルワークとの相性がすこぶる良くありません。現在オンラインで利用できるボードツールの導入を検討している状況です。良いツールやナレッジがあれば是非教えてください。
WE ARE HIRING
株式会社SQUEEZE では、プロダクト開発を行うエンジニアを積極募集していますよ。今回とりあげたような開発プロセスの改善に一緒に取り組んでくれるメンバーを待ち望んでいます。
募集要項は下記をご覧ください。
