こんにちは！Nstock のじゃがです。
「Nstock の開発プロセスが知りたいです！」「スタートアップのスクラムってどんな感じですか？」
ありがたいことに、カジュアル面談などの場で、このようなご質問をいただくことが増えてきました。
そこで、本ブログではこの一年のスクラム開発を振り返ってみようと思います。
すでにスクラム開発をされている方や、これからスクラムの導入を考えているという方の参考になれば幸いです！
チーム
- PdM 1 名
- デザイナー 1 名
- エンジニア 3 名
前提知識
- 開発はじめて 1 年くらいのチーム
- PdM はスクラム経験者
- 他 4 人は未経験、あるいはスクラムっぽいのものの経験者
備考
- 本記事ではスクラム自体についての説明はしません
スクラムをはじめたきっかけ
開発チームの立ち上げ
プロダクト開発をはじめた時点で Nstock には 3 名のエンジニアがいました。一般的には 1 名か多くても 2 名だと思うので、スタートアップとしては珍しいと思います。それぞれ専門性が異なったので、はじめの一ヶ月はモブプロを実施し、互いの知識を共有していきました。
- wadayoshi (和田佳久) : バックエンドは得意だが、フロントエンドは初めて。Fintech での経験が長く、硬く開発するのが得意。
- ryan (佐野智章) : フルスタックにフロントエンド・バックエンド・インフラがかけるが、Java は初めて。スピード感を持って実装するのが得意。
- jaga (永山大輔) : フロントエンドとインフラは触れるが、Java もチーム開発も初めて。
全員がある程度フロントエンドもバックエンドも書けるようになったとき、プロダクトの開発スピードを上げるため、チケットを分担して作業するようになります。
仕様確認や、作業分担をするミーティングはそれぞれアドホックに設定していました。プルリクエストレビューは実施していたものの、PdM やデザイナー、ステークホルダーが成果物を検証する定期的な場はない、という状況です。
そんな開発をはじめてすぐ、課題がでてきました。
開発初期の課題
開発初期の課題は、適切な会議体がないことでメンバー間のコミュニケーションミスが多発していたという点に尽きます。例えば以下のようなコミュニケーションミスが発生していました。
ケース ① 手戻り発生しがち
お互いの担当範囲について理解が不足しているため、コンフリクトが発生しやすい状況でした。また、相互に影響を及ぼす機能について、互いが考えている仕様が微妙に異なり、手戻りも起きがちでした。ある程度は仕方がない面もありますが、この状況が続くことでストレスが溜まりつつありました。
ケース ② プルリクエストの寿命延びがち
完成の定義が曖昧なため、実装が正しい振る舞いをしているかチェックするのが困難でした。結果、実装者に意図を確認するためのやり取りが増え、プルリクエストの寿命が伸びがちになっていました。プルリクエストの寿命が伸びたことで、次のチケットに手を付けることが難しくなったり、後続の実装の手戻りが発生しやすくなったりしました。
ケース ③ PdM とエンジニア間で認識ずれがち
PdM が要件をチケットにまとめ、それをエンジニアに引き渡す形で進められていました。しかし入社したてのエンジニア達と、ドメイン知識に詳しい PdM との間では、前提知識の量も質も異なります。
エンジニアが実装した 3 ヶ月後に、実装内容が PdM の意図と異なっていたことが判明し、追加の作業が必要になることもありました。
スクラムやるぞ 💪
そんな折、親会社である SmartHR 社主催の社内勉強会、スクラムマスター養成講座が開催されます。
課題にひとつひとつ対応することもできますが、先人のプラクティスがつまったスクラムには以前から興味を持っていて、スクラムマスター養成講座の開催をきっかけとしてスクラムの導入を決めました。
講座には PdM とエンジニア 3 名が参加しました。アクティブラーニングを通じて、経験主義や透明性・検査・適応の三本柱など、スクラムの根幹にある考え方を学ぶことができました。後述しますが、この経験はスクラムをやる上で欠かせない土台になっています。
Nstock のスクラム開発
Nstock では一週間スプリントでスクラムを回しています。
祝日があるときは 2 週間スプリントにする、という試みも何度か試しましたが、プランニングとレビューのあいだが一週間以上空くと厳しい、という感覚を持っています。
開発チームの一週間
スクラムで大事にしているポイントを 3 つ紹介します。
ポイント ① スクラムイベントは一日に集約する
スクラムガイドによれば、スクラムにはスプリントプランニング(プランニング)、スプリントレビュー(レビュー)、スプリントレトロスペクティブ(レトロ)、デイリースクラムといったスクラムイベントがあります。Nstock ではデイリースクラムを除く全てのスクラムイベントを一日に集約しています。
主なモチベーションはコンテクストスイッチングを減らすことにあります。例えばレトロとプランニングの合間に採用面接や 1 on 1、外部ミーティングなどが入ってしまうと、レトロで話した内容をプランニングに活かしたり、開発のコンテクストを思い出すのが難しくなります。
また、Nstock には子育て中のメンバーも多く、朝と夕方は送り迎えなどで忙しい時間帯です。スクラムイベントが日をまたいでしまうと、朝や夕方に実施できません。結果として「スプリントとスプリントの間の手持ち無沙汰な時間」が長くなってしまいます。
これを避けるためにも、比較的確保しやすい日中の時間に全てのスクラムイベントを集約しています。
ちなみに…
- 比較的、祝日が少ない火曜日に集約することで、アドホックな予定調整の頻度を減らしています。
- Nstock では水曜日を開発集中デーとし、一切エンジニアがミーティングを入れない日(デイリースクラム除く)としています。これはプランニング翌日の、一番記憶がフレッシュな状態で、スプリントゴールの達成に集中する時間を確保するためです。
ポイント ② こころがける系トライは作らない
スクラム経験者にスクラムのコツはなんですか？と聞くと、多くの人が「レトロを一番大事にしていた」と答えます。
Nstock でもレトロを大事にしていて、１時間かけてじっくり振り返ります。「よかったこと」と「のびしろ」、２つの観点で自由にアイデアを出した後、スタンプで投票し、投票数の多いものから順に話していきます。(リーンコーヒーと呼ばれるプラクティス)
レトロスペクティブ用の FigJam
次のスプリントから試してみたいことをトライとして切り出します。このとき、「〜するよう意識する」「〜しないよう注意する」、といった、こころがける系トライを極力作らないようにしています。このようなトライはなかなか達成できないことが多く、また一時的に達成できてもキープしづらいです。
代わりにプランニングの手順に追記してプロセスに埋め込んだり、チケットを作ってバックログにいれたりします。例えば過去、「ドキュメントを書くチケットが後回しになっちゃってるよね」、という課題があがりました。対応として、「プランニングでチケットの並び替えをするときに、ドキュメンテーションのチケットを上にもってくる」、というステップを差し込みました。
プランニングのテンプレート(抜粋)
この方法の良いところは、次スプリントでトライを実施できるだけでなく、その取り組みをキープし続けけやすいところです。着実に開発プロセスを改善していくことで、チームとしての自己効力感が育まれている と感じます。
こうしたプロセスを回すに当たって、Notion が大きな役割を果たしてくれていますが、その話はまた別の機会に。
ポイント ③ デイリースクラムの進捗検査は丁寧に
スクラムの透明性・検査・適応という三本柱を、最も頻繁に実践する機会がデイリースクラムです。
Nstock ではレビュー前の木・金・月には進捗検査を念入りにしています。（火曜はスプリント間にデイリースクラムが実施され、水曜は開発集中デーのため、各自からの相談事項の共有にとどめています。）
具体的には以下の観点で進捗を検査します。
- 長期間残っている PR はないか
- 個別タスクのボトルネックや想定外はないか
- ゴールが達成できそうか
特にゴール達成の観点については、一番時間を使って話します。実装上のブロッカーがあれば解決するためのペアプロ・モブプロを設定したり、予想外にチケットの対応事項が増えてしまったらチケットを分割したり、仕様が詰めきれていなかった部分があれば議論したりします。
兎にも角にも、ゴールを達成するためにできることはないか？という観点で話し合うことで、チームとしてゴール達成への意識やコミットメントが育まれると感じます。
一年やってみて
当初の課題は解決 🙌
課題 ① 手戻りが発生しがち & 課題 ② PR レビューが滞りがち
Nstock のリファインメントでは、受け入れ条件や対応内容についてじっくり話しあいます。レビュー対象となるチケットの実装方針を互いに理解しているため、PR レビューがスムーズになりました。さらに、互いの担当分でコンフリクトしそうな箇所だけ先に PR レビューに出したりと、互いの作業を妨げない進め方が可能になりました。
課題 ③ PdM とエンジニア間で認識ずれがち
リファインメントで要求や実装についてすり合わせをすることで、認識のずれが起こりにくくなりました。またズレが起きたとしてもスプリントレビューで実際に触って動きを確認するため、すぐに修正できています。
当初、スクラムを導入すると、スクラムイベントで時間が拘束され、開発効率が落ちてしまうのではないか、という懸念もありました。結果的には逆で、アドホックなミーティングがスクラムイベントに集約されることで、むしろ以前よりも開発に集中できるようになったと感じています。
最初から上手く行ったわけではない 🏃
ここまで書いた内容は最新の Nstock のスクラムであって、そこに至るまでは試行錯誤の連続でした。
- スクラム導入当初はリファインメントをやっておらず、時間通りに終わらないプランニングが続く
- スクラムイベントを集約せずに本筋の開発に使える時間が減る
- こころがける系トライをつくって、あぁ今回もできなかった…とがっかりする
そんな中でも、「なにか上手く行ってない気がする」というモヤモヤをチームで共有して、改善策を次のスプリントで試す、という点は最初から実践できていました。スクラムマスター養成講座で経験主義について学んだこともありますし、そもそも Nstock の開発チームは「開発をどんどん良くしていこう」、というスタンスの人ばかりだったことも影響していそうです。
「1 ヶ月前の自分達よりも今日の自分たちのほうがうまく開発できているし、これからも良くなるはずだ」 と確信できるのは、開発チームとしてとても素晴らしいことだと思っています。
さいごに
スクラムはいいぞ
これからもスクラム開発の試行錯誤について発信していくので、よかったらまた見に来てください 👋
Nstock ではエンジニアを募集しています！
スクラムを大事にする開発チームで、スタートアップを皮切りに日本を変えていきませんか？
カジュアル面談 から気軽にお話しましょう 🤞
Discussion