『2時間スプリント』とフルリモートワークなシステム開発

デンキヤギという会社で『2時間スプリント』が定着してきたので、その話でも書きます。

2時間スプリント?

みなさん、すでにスクラムで開発してますよね!

ぶっちゃけ、スクラムがよくわかってなくても、とりあえずスプリントと称して開発のメリハリをつけるために、1週間なり2週間なりで区間を区切って開発をしていくのは、普通にやってるんじゃないかと思います。

2時間スプリントとは、その期間を2時間にするという話です。

スプリントを超短期サイクルにすること自体は、47機関の人たちがオリジナルだという認識です。このあたりに本家の情報がまとまっています。

kyon-mm.hatenablog.com

2018年に実際に47機関の人たちのチームに入って1時間スプリントで働くという機会があって、それ経て、デンキヤギでもパクって導入しています。本家ではのちのち15分スプリントになっていったらしいんですが、うちはうちの実態に合わせていったところ、2時間スプリントという形に落ち着いてきました。

後段でも言及しますが、1時間にするか、2時間にするか、はたまた15分にするかは、チームの状況や練度によって異なってきます。ただ、一般的な常識で考えるスプリント期間よりも超短期にすることが重要な要素の一つとなります。

超短期間スプリントを導入するメリット

成果報告のタイミングで「えっ、まだ完了してなかったの??」「えぇ…、その作業をやる必要は一切なかったんでは…」「何でもっと早く相談しなかったの??」ってなってる場面に出くわすことありませんか?こういうことに身に覚えのあるチームであれば、導入を検討する余地が十分にあります。

私は超短期間スプリントの本質を「時間経過をトリガーとして、他動的かつ適切な方法でチーム内で情報を同期し、高頻度に計画を見直す」ことだと認識しています。

いわゆる報連相とかいうやつを各自の判断でやらせると、強く属人性が発生します。結果、適切に動ける人と破滅する人間に分かれていきます。

残念ながらチーム内に破滅するタイプの人間が出てしまうと、チーム全体の生産性を低下させる要因になりがちですし、当人の人事評価も自己評価も下がってしまうし、全くいいことがありません。破滅しない側の人間であっても、忙しくなってくると報告が滞りがちになることは多々あり、結果的にチーム全体の生産性を低下させる要因となってきます。

この部分から属人性を排除すれば、作業ロスを減らすことができるはずです。みなさんが大好きなトヨタ生産方式で言うところの『ムダ取り』を、作業プロセスに対して適用しようという話です。

超短期間スプリントとリモートワーク

超短期間スプリントはリモートワーク専用ではありません。全員がオフィス勤務でも適用でき、非常によく作用します。実際、オリジナルの1時間スプリントを体験したときは、ほぼ全員がオフィス勤務でした。

そのうえで、超短期間スプリントは同じやり方のままで、オフィス勤務でもリモートワークでも、どちらにも対応できることができます。デンキヤギに関していえば、2時間スプリントの習熟度が上がってきたこともあり、フルリモートワークになる以前よりも今の方が生産性が上がってきていると認識しています。

そもそも「リモートワークになったから、生産性が落ちたよねー」という話は、リモートワークになったことで対話するきっかけが少なくなり、非常に属人的な『チーム内で情報共有する能力』に生産性が強く依存していたことが顕在化しただけのことです。 超短期間スプリントは、まさにこの部分の属人性をなくそうぜという話なので、ここが問題にならないのであれば、生産性に影響はありません。

とはいえ、リモートワークでは、ペアプロやらモブプロをやるには制約はあるし、大部屋の壁に付箋を貼りまくるような情報ラジエーターにも制約はあるし、といった空間的な制約で出来ないことや苦手なことがあるのは間違いありません。この点ではオフィス勤務の方が明らかに有利です。一方で、通勤による時間と体力を消耗していることが過少評価されている気もします。

2時間スプリントを行っている実感値としては、フルリモートだろうがオフィス勤務だろうが、生産性はほとんど同じだと思っています。もし差があっても、オフィス勤務が1-2%ぐらいは有利になるケースがあるかもね?ぐらいです。

繰り返しますが、超短期間スプリントは、オフィス勤務だろうが、リモートワークだろうが、全く同じやり方のままで仕事できます。今後、リモートワークが必須でなくなったとしても、やり方を変える必要がありません。

チーム構成と業務内容

デンキヤギ内で2時間スプリントで開発をしているるチームは、現状はこういう感じの体制です。

  • terurou(役員定額働きたい放題) - 1人
  • 時短正社員(6時間勤務) - 1人
  • 学生アルバイト - 4人
    • だいたい週2-3日、14時~19時の時間帯で2~5時間ぐらいの稼働
    • 学業や私用で突発休みもOKにしているため、勤務日や勤務時間はかなり不定
  • フリーランス - 1人
    • 週で8時間ぐらいで、特に時間帯を決めていない勤務体系
    • この人は今のところスプリントには参加していないが、学生アルバイトの担当作業の技術面や管理面を主体に支援してもらっている状況
  • ある程度同じような時間帯に働いてはいるが、始業/終業時間かかなりバラつきがあり、全員が揃う日はほとんどない

業務としては自社サービス(yagisan)の開発がメインですが、内製ツール開発やOSSにPRを投げたりする他、受託の技術コンサルティングサブスクリプション契約の開発なども並行しています。常時3-5プロジェクトが動いています。terurouは普段普通にコードを書いてますが、PMやPO的なロールもこなしていたりする一方で、代表取締役的な業務があったり、営業対応なんかもあります。

まあ、何も考えずにやっていたら、管理面が破滅するしそうだなという雰囲気です。実際には普通に回せてしまっています。

1日のタイムライン

  • (みなさん適当な時間に始業)
  • 11:00 スプリントレビュー&プランニング
  • (昼休憩、みんな時間はバラバラ)
  • (14時ぐらいからアルバイトがぼちぼち始業しはじめる)
  • 14:30 スプリントレビュー&プランニング
  • 16:30 スプリントレビュー&プランニング
  • 17:00 KPT(レトロスペクティブというよりも雑談)
  • (みなさん適当な時間に終業)

細かいことは後述していきます。

プロダクトバックログ

プロダクトバックログにはやっていく作業リストがたまっています。デンキヤギではAzure DevOpsをメインに使っていますが、開発対象によってGitHubも併用しています(以前はGitLabも使っていましたが、今は使ってません)。ここには超短時間スプリント固有の話はありません。

各担当者レベルのプランニング(随時)

各担当者は、作業の着手時や割り当てられたタイミング等で、割り当て作業をタスクレベルに細分化してもらっています。

タスクの最小粒度は5分で、30分より大きくしないことを推奨値にしています。最近は弊チームではみんな慣れてきているので、各自のプランニングにお任せ気味になっていますが、「かなり細かくタスクを分割する」ことは重要なポイントです。

タスクを切る粒度の例としては、

  • GitHubにprivateリポジトリを立てる(5分)
  • XXX処理をするクラスの命名を考える(15分)
  • XXX処理のバリデーションを実装する(20分)
  • ダミーレスポンスが返せるようにする(10分)
  • XXXの公式ドキュメントのGetting Startedのページを読む(20分)
  • XXXを公式ドキュメントに沿ってインストールして起動してみる(30分)

という感じです。XXXを実装するとか設計するとかで計画が終わらせがちなところを、もっと細かく切ります。ただ、どうにも細分化しづらいタスクというのも当然あるので、そういう場合は無理して細分化せず、とりあえず大きな粒度のまま残してもらいます。

細分化することで、どこに時間がかかりそうかといったことを、着手前に可視化します。

ウィークリープランニングやマイルストーン

2時間じゃないやんけ!みたいな話になりますが、月曜日11時のスプリントレビュー&プランニングで、1週間でだいたい何をやっていくか決めていくことはやっています。

超短期間スプリントは超短期計画でしかないので、全体の方向性は決めることができません。マイルストーンを置いたり、週次のおおまかな計画は、これはこれとして考えていきます。

ここも一般的な期間のスプリントでやるプランニングと大差はありません。

デイリープランニング

やっていません。毎日11時のスクラムイベントで「今日中でここまで終わらせたい」みたいな話をすることもありますが、デイリープランニングになっているかと言われると、なっていません。

前述の通り、全員が11時のタイミングでは揃っておらず、14:30でも始業していないことが普通にあるので、朝会なり昼会なりでデイリープランニングするということ自体が稼働実態にマッチしていません。

超短期間スプリントだと、朝会なり昼会に参加しなかったせいで、一日の計画がよくわからない!ということは発生しにくくなります。1日に何度もプランニングをしているので、どこかのタイミングで参加すれば、最新に追いつくことができます。

2時間スプリントレビュー&プランニング

前スプリントまでの作業成果の共有と、次スプリントのでやる作業の計画(の補正)をします。全員が参加した状態で、次のようなテンプレートに沿って各自に話してもらっています。

f:id:terurou:20200913190201p:plain

テンプレートを使うという発想も47機関のパクリです。このテンプレートは紙に印刷して、スプリントレビューの際に視界に入るようにしておくことを推奨しています。

このテンプレートで会話する作業は、前述の各担当者レベルのプランニングで細分化したタスクレベルになります。ここで、各自が立てた計画に『違和感』を感じた場合や、何か課題が発生している場合は、チーム全体で対応策を検討したり、計画の補正をかけていきます。

  • 当人は知識がなかったので半日ぐらいかかるつもりだったが、実はチーム内にかじったことがある人がいて、その人からの情報を足掛かりにすれば30分ぐらいで終わりそう
  • 逆に30分ぐらいで終わるつもりだったが、傍から見たらどう考えても見積もりが甘すぎる
  • やってみたら実はめちゃくちゃ実装が難しいので助けてほしい
  • 要求仕様がよくわからないので悩んでいた など

また、テンプレートに「成果デモの実施」とありますが、これも非常に重要です。「全部完成する前に、上の人に方向性が合ってるか見てもらうね」と指導された経験がある人は多いと思いますが、これを2時間毎にワークフローとして強制的に実施します。全部作りきってしまってから、実は方向性が違ったとか、過剰品質だったとか、品質不足だったとかという不幸は、本当によくあります。

適切な手法で超短時間にスプリントレビューを実施することで、ムダの発生を早期に検出して対処していくことで、生産性が高くなっていきます。リモートワークではコミュニケーションが取れないから生産性が落ちるという話を、属人性にゆだねることなく、仕組みで未然に防いでいきます。

超短期間スプリントの期間の決め方

スプリント期間をどれぐらい短くするかという点は、47機関とデンキヤギで考え方の違いが出ている大きな箇所です。デンキヤギというか、PMとしての私の考え方では、

  • 最悪半日ぐらい工数をドブに捨てるようなことになっても、他に得るものがあったなら、まあ仕方ないかなー
  • とはいえ、1日まるっと無駄にされたら、若干イラっとするよね
  • 2時間ぐらいなら全然仏の顔できますよ。人間、眠気に襲われたりして30分ぐらい意識が朦朧としたりすることもあるよね
  • 1時間間隔でチェックポイントを仕込むのは、せわしくなくなりすぎて、逆にストレスが溜まる…

という仕事感覚なので、2時間に落ち着いてきた次第です。

KPT(レトロスペクティブというよりも雑談)

スクラムではレトロスペクティブ(ふりかえり)が重要ですが、それに該当するもので、KPT形式で行っています。

デンキヤギの場合、レトロスペクティブという面もありますが、社員間で雑談する機会を設けるという面を優先しているので、別に実業務とは関係のないことを話してもらってもOKにしています。ちなみに参加者は社員のみに絞っています。

  • アルバイトは稼働時間が短く、スプリントレビューも含めると、稼働時間の結構な割合が打ち合わせ時間になってしまう
  • チームをまたいで人が参加するので、当然他のプロジェクトの話が出てくることがあり、社員間ならともかく、アルバイトの人に不必要なNDA的リスクを負わせたくない

という判断でやっています。このあたりの匙加減は、これで正解とは思ってないので、今後変わる可能性はあります。

細かなテクニック

仕事に集中していたりして、スクラムイベント(スプリントレビュー&プランニング、KPT)の時間になったことに気が付かないみたいなことは結構あるので、少し前に時報を鳴らすようにしています。フルリモートワークになる前はチャイムを鳴らしていましたが、フルリモートワーク以後はチャットに通知を流すようになりました。

超短期間スプリントをやらなくても、時報を鳴らすこと自体はかなり良いです。自分で時間を確認しに行かなくても、時間の経過がプッシュされてくるのは、仕事のリズムを作っていくためのフックポイントとして使いやすいです。

超短期間スプリントが適用できないチーム

チームメンバーの働いている時間帯が全く違っていて、全く重なっていないという場合には適用ができません。こればかりはどうにもなりません。

さいごに

長々と書いてきましたが、興味があるチームは id:kyon_mmアジャイルコーチを依頼するといいじゃないでしょうか。正直、うちが高精度に2時間スプリントを導入できたのは、オリジナルを実際に体験できたことが大きいんじゃないかと思っています。

とはいえ、とりあえず時報を導入して、時報が鳴ったら強制的にチーム全体で話すようにするというところからでも良いかもしれません。そして、前述の報告テンプレートを適当に改変して使えると、なお良いという感じがします。

報連相とかいう属人性の塊みたいな文化を抹殺しましょう。