Nota-Sprintの歴史

https://gyazo.com/49d32eff7f6e9af522f82c7a0eb8c3cc

2016年10月末にNota, Inc.にSprintを導入した

原則2週間をひとつのSprintとして、Sprint.31まで来た

2018年最初のSprintがSprint.32というキリ番を迎える

導入前までは全員が自律的に自由にタスクを選んで動いていたが、以下2点の問題が大きくなってきた

人数が増えるにつれ、当時実務上のマネージャーであるCEOが全体を見渡すことが困難になった

当時の赤字を念頭に、タスクを着実に遂行する必要が出てきた

余談だけど、途中からVPoEと兼任でマネタイズの責任者をしていたので、2018年を迎えられて良かったと思ってる

つまり、以下2点の達成を目標にスクラム開発の導入を目指した

また、導入時の条件として以下がCEOから設定された

原則としてタスクに期日を設定しない

開始1ヶ月後の2016年11月からはVP of Engineeringに任命され、正式に開発チームのマネジメントを担当

導入当時のプロダクトラインは以下の通り

その他（メンテナンスの必要なプロダクトがいくつかある）

Sprint導入前

まずは全体のタスクが俯瞰できるようにすることを目標とした

資金との兼ね合いで、体制の構築に時間的コストをかけるのは厳しいと判断した

ちょっとずつルールを追加して本来のスクラム開発に近づければ良いと思っていた

Scrapboxに新しい開発フローの解説ページをつくり、Sprint.0として解説をした

各Sprintの歴史

「全社昼会」ぐらいのレベルからスタートして、徐々に仕組みを増やしていった

Sprint.1

日程

2016/10/26(水) 14:00 Start

2016/11/02(水) 14:00 Checkpoint

2016/11/08(火) 17:00 Close

エンジニア＋デザイナーをDevチームと捉え、計12名をSprint参加者としてスタート

マーケティング/広報/カスタマーサポート/バックオフィスといったBizサイドのメンバーは対象外としてスタート

Sprintミーティングの14時を開始時刻として設定

朝寝て夜仕事するエンジニアや、PM5時に夕食を家族でとるエンジニアも含めて、朝会でも夕会でもない、全員が参加できそうな時間としてこの時間になった

とりあえず「今なにをしているか」を書いてもらった

未完了タスクがあっても怒られないのでとりあえず書いてくださいとアナウンス

タスクの規模や状況が人によって違うので、とにかく安心して状況を共有できるという環境を作りたかった

進捗管理・タスク管理というキーワードが嫌いなメンバーもいるので、あくまで目的は状況の把握であることを伝えた

今なにをしているのか俯瞰できるようになった

誰が忙しいのか分かってサポートに入れるようになった

Sprint.2

日程

2016/11/09(水) 14:00 Start

2016/11/16(水) 14:00 Checkpoint

2016/11/22(火) 17:00 Close

BizSideの人もSprint MTGに参加したいとリクエストが来たので、参加してもらうことになった

ステークホルダーが直接参加することになるので、本来のスクラム開発からはより外れることとなる

エンジニアが出した機能修正をCSの人が横で聞くという状況になったので、「もしかしたら先日の〇〇がバグの原因かも？」とCSの人がシステムの状況をある程度把握できるようになった

エンジニアがたいした機能じゃないと思っていても、広報的には宣伝しやすい機能とかをすぐ知れるようになったのがよかった

デメリットも色々ある

個人での報告欄の後ろに「今回のSprintでの感想・反省点・気になったこと」という欄を作った

いわゆるKPTだが、KPTという名称は出さずに自由に書いてもらった

Sprint.3

日程

2016/11/24(木) 14:00 Start

2016/11/30(水) 14:00 Checkpoint

2016/12/06(火) 17:00 Close

ZenHubを導入した

Scrapbox+Sprintで全体を俯瞰できて便利だが、Github上に放置されているタスクがあったので、ZenHubも併用

1. 起票されたまま忘れられたIssue

2. レビューされずに放置されてしまっているPull Request

を救済するようにした

Sprint.4

Sprint.5

2016/12/21(水) 14:00 Start

2016/12/29(木) 17:00 Closing day

メンバーが自由に選んでいたタスクに加え、会社タスクとしてやらなければならないタスクを追加

作業する人に個別に相談の上、Sprintページの当人の欄に🎯アイコンを付けて追記した

Sprint.6

｜

Sprint.10

Sprint.11

日程

2017/03/15(水) 14:00 Start day

2017/03/22(水) 14:00 Checkpoint day

2017/03/28(火) 17:00 Closing day

ZenHubをSprint MTG中に確認してほしいというリクエストがメンバーから来たので、全員でKanbanを確認するフローを追加した

New IssueとReview/QAを確認するようにしたので、以下のタスクが救済されるようになった

サポートが急ぎで実装してほしいと考えているIssue

☞ 誰が責任を持つかSprint MTG中に決めつつ、このSprint中に対応するか今後の課題とするか仕訳

誰もレビューしていないPull Request

☞ 誰がレビューするかSprint MTG中に決める

Sprint.12

｜

Sprint.16

Sprint.17

メンバーから以下の提案が来たので、日程変更に向けてスケジュールを組む

Sprintを「水曜始まり翌々週火曜終わり」から「月曜始まり翌々週金曜終わり」に

Sprint Feedback MTGを17時開催から14時開催に

Sprint.18

Sprint.19

Scrapboxで議論して煮詰まってきたり、急ぎでの対応が必要そうなものを提案する場として用意した

Sprint.20

日程

2017/07/19(水) 14:00 Start day

2017/07/26(水) 14:00 Checkpoint day

2017/08/04(金) 14:00 Closing day

Sprint始まりを月曜にするため、長めのSprintにした

経営会議やVPoEの休暇の都合で、ようやく調整できた

Sprint.21

｜

Sprint.30

Sprint.31

日程（年末進行）

2017/12/25(月) 14:00 Start day

2017/12/29(金) 14:00 Closing day

2017年中に黒字化も達成して穏やかな気持ちで新年を迎えられるのが嬉しい

今後の課題

本来のスクラム開発と違う「オレオレスクラム」になってるのが気になる

基本的にタスクの期日設定が無かったり、参加者が多すぎたり。

しかしそれでも会社は回っているので、しばらくはこのまま進めても良いかなとは思う

目的はメンバーが快適に働きながら会社の収益を増やすことであって、完璧なスクラム開発を実践することではないので

なんだかスクラム開発というよりは毎日全社会してるだけのような気がしている

人数が増えてきた時にどうするかで悩んでいる

現在Sprintページに名前が載っているのは16人（フルタイム以外のメンバーも含む）

だいたい毎回20分ぐらいでDaily MTGが終わる

20人30人と増えてきた時に

会議を分割する？

1人あたりの時間を削減する？

ステークホルダーとスクラムチームの分離が不十分なのが気になる

経営者/BizSide/バックオフィスがスクラムに入っているので、タスクがどんどん追加されてしまう

ほぼ全てのタスクに期日設定していない原因でもある

ステークホルダーとスクラムチームを分離してSprintの先頭でタスクを積むように変えたいという気持ちがある

その場合、期日のコミットをどう取り入れるか悩ましい

ミーティングに時間を使うべきか否か

文字メディアに強い人もいれば、口頭での議論が好きな人もいる中で、Daily MTGとして毎日参加者の時間をちょっとずつ割いているが、どれぐらい割いても良いものか

今まではなるべく会議時間は減らすべきだと思っていた

会議に参加した人数分の人件費を消費することになる

人数が増えれば増えるほど発言しない座ってるだけの人の時間が無駄になる

多人数で議論しても結論が出ない場合が多い

が、2017年末の中国出張でオフィスを案内してくれた中国人の人が「中国人は納得いくまで4時間でも5時間でも会議します」と言っていて、それでも会社は成長するのかとちょっと感銘を受けた

という経緯があるので、Sprint MTGの時間が伸び続けるのを許容するという作戦もあるんだなと思った

好き嫌いの議論に着地せず考えたいが、まだ自分の中での結論が無い

今後も問題が出てきそうになったら積極的にSprint自体を改善していきたい