スプリント開発と試行錯誤
Vicke
まずは教科書通りに組織に導入してみて、今1ヶ月ぐらい経って、いろいろ各チームで試行錯誤してるみたいな話があったと思うんですけど、
そこら辺の試行錯誤の部分がいろいろ聞けるといいかなと個人的には思っています。
よし、撮っていきますか。
Scott
はーい。
はい、じゃあそれじゃあ始めていきますか。
Vicke
やりましょう。
Scott
じゃあ、TimeTreeTechTalk始めていきたいと思います。
よろしくお願いします。
よろしくお願いします。
今回は、ここ数ヶ月ぐらい、社内でも頑張って取り組んでいるスクラム開発について話していきたいと思っています。
今日は結構大勢メンバーを呼んでまして、僕を含めて5人かな。
ちょっと大勢ですけれども、やっていきたいと思います。
じゃあちょっとそれぞれ自己紹介を軽く。
Stud
はい、スタッドです。
今はTimeTreeGiftというサービスでスクラムマスターをやっております。
その他はフロントエンドやiOSをやってます。
よろしくお願いします。
Vicke
はい、ビッケと申します。
プロダクトディビジョンでバックエンドエンジニアをやっております。
よろしくお願いします。
Andy
はい、アンディです。
アンドロイドエンジニアで、プロダクトディビジョンで一応スクラムマスターのようなことをやっています。
Scott
全然一応じゃないですよ。がっつり言ってます。
Sion
はい、シオンです。
プロダクトディビジョンでiOSエンジニアをやってます。
よろしくお願いします。
Scott
ということで、スクラム開発について話そうかなと思ってるんですけれども
そうですね、TimeTreeならではの取り組みみたいなところで
そうですね、ここ数ヶ月ぐらい、正直に言うとスクラムっぽい何かだったところから
ちょっとスクラムについてしっかり取り組んでいこうみたいな形で
ちょっと僕とかも本とか読んだり勉強して取り組んだところがあるんですけれども
実際にどういうことをやってたかみたいなことを聞いてもいいかな
じゃあ回しているアンディ、聞いてもいいですか?
Andy
はい、そうですね、具体的には
そうですね、スクラムイベントの名前をちょっと独自のものに変えてみたりして
ちょっと認識が合いやすくするようにしてみたりとかですね
なんかリファインメントとか言われても
ちょっとはっきり言って何言ってるのかよく分からないみたいな
どういうことをやるんだろうみたいな認識がやっぱり合いづらいところがあるので
解像度を上げる回なんていうふうな名前にしてみたりして
次何をやるのか、どんなことをやるのかの解像度を上げるみたいな
スクラムイベントの名前変更
Andy
回だよみたいな感じのことを名前つけて
やることを分かりやすくしたみたいな感じですかね
Scott
そうですね、いわゆるスクラムを進めるときにね
チーム全体で勉強してやろうっていうのもあると思うんですけど
そもそもチームの人数多くて
スクラムに関する認識が合わないみたいなところがありましたよね
Andy
そうですね、初期はいろんな用語がやっぱり出てきて
この用語はこういう意味だとか
そういった認識のずれとかが結構発生したり
これって何やる回なの?みたいな
よく分かってないみたいな
用語の意味が分かってないみたいなことが結構発生したんですね
最初の方は
Scott
そうですね
Andy
はい、なので認識の合わない言葉を使うのはやめようっていうふうに言って
いろんなものの名前を変えてもらいました
Scott
正直僕もスクラム勉強するまで
レトロスペクティブって何なのか全然分かってなかったですし
スクラムイベントの用語って勉強すれば分かるけど
勉強してないと何っていうのが全然分かんないみたいなのがありますよね
他に何か変えたような名前みたいなことでいうと
どういうふうに変えたのかとか
リッケとかあります?
Vicke
そうですね
あとはエピックとかプロダクトバックログとか
スプリントバックログとか
その辺ももっと分かりやすい名前にしようという形で
試作要件タスクっていう階層にして
タスクを分けたみたいなことはやっていますね
Scott
そうですよね
エピックとかユーザーストーリーとか
言葉が結構分散してましたもんね当時ね
どれがどれなんだみたいな
って感じで結構わけ分からなかったんですけど
スクラム開発の効率向上
Scott
横文字が結構多い印象が
あ そうですね 横文字ね
Vicke
なかなか覚えられないみたいなところが
Scott
分かりやすい名前にいっそ変えてしまおうみたいな
どうですかね 変えてみて
スクラム回す上で変わったことっていうか
影響ってどんなのがありました?
Vicke
そうですね でもなんかみんなの認識が
揃いやすくなったというか
イメージしやすくなったみたいなのは
あるんじゃないかなと思いますね
それまで名前を変えるまでは
これってどれなんだっけみたいな
感じでなってたような気がするんですけど
名前変えてからはそういうのとか
Stud
慣れもあると思うんですけど
Vicke
今のところいい感じに回ってるんじゃないかなという気がしてます
Scott
実際運用みたいなことの話していきたいなと思うんですけど
確か前エンジニアの採用イベントの時に
シオンが話してたと思うんですけど
設計を結構1日使ってガッツリやるみたいな話が
あったと思うんですけど
実際のところTime Treeって今大体のチームは
スプリント1週間で回してると思うんですけど
1週間のうち1日を丸々計画で使ってみて
シオンどうですか?
Sion
そうですね 丸々と言っても午後なので
でもその時間をかけるだけの価値はあるなって思っているのと
慣れてくるとある程度決まった時間でできるようになってきて
月曜日フルで使わずにちょっと空き時間ができて
その空き時間が実はスクラムタスク外のことをやるのに
結構良くて自由時間として使ったり
Scott
なるほどね 早めに切り上げて
Sion
そうですね 知ってますね
ただやっぱり時間はかかって
グッズ付けでやってるとだんだん後半
Scott
疲れてきてちょっと雑になったりみたいなことはあるんですけど
確かにずっとやってるとそういうのがありますね
休憩とか適切れてるんですか?
Sion
そうですね 最近だからちょっと頭回らなったから
Scott
30分休もうかみたいなことはします
さっき話の中で慣れてきたらだいぶ短くなったっていうのがあったと思うんですけど
慣れるっていうのは具体的にどういうことっていうのは説明できたりしますか?
そうですね そもそもやり方自体に慣れていくっていうのと
Sion
あとは何をどこまで決めたらいいのかみたいなのが感覚としてわかってきたっていう感じですかね
Scott
なるほど 今シオンはiOSでトレバーと一緒に設計してるんですよね
はい
その2人の間のどこまで話せばいいとか
そこら辺の加減がわかってきたみたいな感じがあったりするんですか?
そうですね
他に2人でガッツリ設計時間を取るみたいなことのメリットってありますか?
Sion
何も話さずに開発に着手しちゃうと
ちょっと設計を思ってたのと違ったわみたいなことがあって
後からレビューで指摘して結構作り変えるみたいなことがあると思うんですけど
そういうのがなくなって設計の方針はもうその場で決まるので
そこの手戻りみたいなのはないし
ある程度どう作るかも共有してるから
レビューする時もそこの認識が揃っているので
結構時間が短く済むっていうこともありますね
Scott
なるほど
Sion
あとは最近新メンバーも入って
Noiっていうもう1人メンバーが入って3人でやるようになってるんですけど
Noiはジョインして間もないので
まず前提としてどういう設計に今なってるのかみたいなところを共有しながらやるので
メンバーのオンボーディングとしてもすごい良いのかなっていう風に思ってます
Scott
確かにコードベースの知識が分かんないと
今特にリモートだから1人で新しくジョインしたメンバーでこれやってくださいってなると
すごい時間かかったりするけどそういうところがフォローできるっていう
なるほど
ある意味だからそういうことだったりレビューのコストみたいな話がありましたけど
そういうのを前払いしてる感じなんですかね
先に設計時の時に払っちゃうみたいな
Sion
はいはいはい
Scott
なるほどありがとうございます
ちなみにみんなに聞きたいんですけど
それこそ設計に丸一日かけましょうみたいなこと確か僕が提案した気がするんですけど
最初聞いた時どう思いました?
1週間のうち1日設計にかけるのかよと思われないかなってすごい心配だったんですけど
Andy
そうですね
すごくそれのおかげでミーティングが1日にまとまったみたいなところもあったので
そこでまとめてやっちゃうことで残りの日は
もうあとは設計したら作るだけみたいな感じになるので
そこの切り替えとか効率の良さとかはすごい感じましたね
Scott
最初は1週間のスプリントの中で1日丸々計画みたいに思って
Vicke
イベントに費やす時間多そうだなっていうのは最初に思ったんですけど
でも実際やってみると設計みんなでできるメリットの方が大きいなっていう感じがあって
それ個別でやっちゃうと自分で行き詰まった時とかに
また相談する時間とか取らなきゃいけなかったりするんですけど
みんなでまとめてやっちゃうことでその辺が最初にクリアになるので
あとは開発するだけみたいな状態に持っていけるので
それがすごい後々の作業が楽になった感じはすごいありますね
Scott
設計することと相談することが交じされて
作業と分離できるのがやっぱり良かったりするんですかね
今プロダクトディビジョンのチームの話を聞いてたんですけど
GIFTでスクラムを回している佐藤の話も聞いてみたいなと思うんですけど
GIFTはスクラム開発でリリースしたの4月でしたよね
Stud
そうですね
Scott
プロジェクト始まったのが
Stud
その半年前ぐらいかな9月ぐらいだった気がしますね
Scott
プロジェクト開始時からずっとスクラムやってたって感じですか
Stud
そうですね
自分が結構初期からプロジェクトのメンバーとしてアサインされていて
企画を最初詰めてたんですけど
いざ開発を始めようと開発メンバーが集まった時に
今回スクラムでやってみませんかっていう提案を自分化して
皆さんいいよみたいな感じで予感いただいて始めたって感じですね
その時は結構スクラムという名の皮を被った
なんかとりあえず朝会みんなでやるみたいなのをやってて
途中3ヶ月ぐらい経った頃に
ちょっとやっぱ改善したいなっていう声が出てきて
ちゃんとスプリントレビューとかリファインメントとかを始めたんですけど
まだちょっと改善の余地がありそうだということで
最近ですね新しいメンバーが入ったんですけど
今日ここの場にはいないんですけど
スクラムちょっとこういうふうに改善したらどうですかっていう意見をくれて
Scott
今絶賛改造中という感じです
Stud
どう改造していくかっていうのは完全にプロダクトディビジョンのやり方を
参考にさせていただいてまして
Scott
例えばエピックを試作って呼んだりとか
Stud
要件とかタスクって呼んだりとか
そういうような名前をもうちょっとやっぱ分かりやすくしたりとか
あとは設計をみんなでやるっていうのもすごい良いなと思ったので
Scott
その辺も取り入れていこうとしています
いいですねなんかもう良かったっていうやり方が横展開されてる感じで
Stud
色々吸収して
ここ1週間ぐらいずっとノーションいじってます
Scott
そうですねツール的な観点で言うとノーション使って管理してるチームが多いですかね
プロダクトディビジョンもすごいアンディがノーションめちゃくちゃ頑張って作ってくれて
今運用されてるはずですね
Andy
そうですねはい
Stud
あれでも読めちゃう
一部GitHubプロジェクト使ってるところもありますよね
Scott
そうですねちょうどスタッドもメンバーに入ってくれてると思うんですけど
プロダクトディビジョンの中のブラウザの開発チームは今ちょっとハイブリッドでやっていて
プロダクトバックログはノーションで管理してるんですけど
具体的なタスクとか見積もりはGitHubプロジェクトで管理してるという感じですね
その辺がそうですねちょっと今いろいろ実験中って感じで
GitHubプロジェクトを持ってるよくできてて
一周とひも付けやすいし結構便利だなみたいなところを持ってたりするんですけど
ノーションとかそれこそGitHubプロジェクト以外に
このツールいいんじゃねみたいな思ってるのって誰かあったりします
Stud
昔はZenHubっていうのを使ってましたね
使ってましたねZenHubね
スクラム開発のツール
Stud
タイムツリーでは結構昔からスクラム開発自体はやっていて
いろんなプロジェクトでそこでZenHubを使ってやったりしてましたね
あれは結構スクラムに特化したツールなんでよくできてるなと思いましたけど
まあお金がかかるっていうところで
Scott
あとプロダクトオーナーが見づらいみたいなところもありますよね
プロダクトオーナー自身がバックログアイテムを管理しづらいみたいなところがあって
Stud
そうですねあれもGitHubがベースなので
GitHubをエンジニアじゃない人が見づらいってところがあるから
Scott
そういうのはありそうですね
その辺結構一個のツールでやれたらいいんだろうけど
いいツールなかなかないなみたいなところでありますね
そういう意味で言うとNotionが今一番落としどころというか
いいところかなって思ったりしてますね
Sion
今のProData DivisionのNotionはすごい作り込まれてますよね
Scott
アンディ先生
Andy
そうですね最初の方はかなりNotionばっかりいじりまくって
2,3週間まではいかないかもしれないですけど
それぐらいずっとNotionいじってますみたいな
もうちょっとまた改善しますみたいな
1週間スプリントでこの課題があったんで
もうちょっとまたNotion直しますみたいな感じで
どんどんどんどん作り込んでいって
今だいぶ満足できるものになってきてるのかなみたいな感じです
Scott
テンプレートとか公開したいですね
確かにテンプレート
Andy
そうですね
Scott
いいんじゃない
Sion
スプリント
イベントごとのビューができていて
例えば朝会だったら朝会のページを開くと
その日のメンバーごとのタスクが並んでいて
あとその日に確認したい事項を入れるテーブルもあって
そこのビューにもアクセスできるみたいな
イベントごとにここ見ればいいみたいなページが
自動でできているっていうのがすごいなって思いました
あれ確かにすごい
Scott
あれ開いときゃいいみたいなのありますよね
Andy
そうですねそここだわりポイントです
やっぱり誰でも回せるみたいなところを考えると
もうこのページ開ければ何をやればいいか分かるみたいな感じで
それ用のビューを用意してるみたいな感じですね
Stud
それめちゃくちゃいいですね
Scott
おすすめです
テンプレ公開待ってますアンディ
Andy
社内だったら別にプロダクトディビジョンじゃなくても
そのまま流用できる形式にはなっているので
Scott
ぜひぜひそのまま使ってもらっても大丈夫です
Stud
そっかなんかデータベースを一個
Scott
共通のデータベースになってるので
Andy
どっちのグループなのかみたいな
Stud
グループを切り替えることで付けられるんですね
Scott
すごい考えられてる
じゃあちょっと話題を変えて
スクラム開発の課題
Scott
スクラム開発すごく取り組んできて
良かったという声も聞こえてきてるんですけど
一方でこの先の課題みたいなことを
ちょっと聞いてみたいなと思うんですけど
そうですね一人一人順番に聞いていきますか
BKそうですねスクラム開発における
今後こうしていきたいなみたいな課題っていうか
ここがまだ改善できるよねみたいな話ってありますか
Vicke
そうですね課題か
ベロシティの管理とかは
なんかまだちゃんとできてない感じがあっていて
Scott
なんとなく見積もりをやって
Vicke
今週ここまでやりますみたいな感じでやってるんですけど
ベロシティとかもしっかり管理すると
その先の見通しとかがもっと見えてくるのかなっていうのはあるんですけど
Scott
そこがまだちょっとできてない部分なのかなっていうのは思いました
確かにそうですね
結構スクラムっていうとベロシティとか
そういうところに結構注目が集まりがちですけど
今回プロセスの方にこだわって
その辺の可視化みたいなところちょっと後回しにしてるところがあったのかな
僕が少なくとも取り込んでるときは一旦後回しでいいやと思ったんでやってなかったんですけど
確かにそこはすごい重要な課題ですね
じゃあ続いてシオンはどうですか
Sion
そうですね
今プロダクトディビジョンは
一つの大きな施策を
みんなでエンジニア全員で取り組むっていう形になってるんですけれども
今後複数の施策を並行して進めるっていう
体制になることが予定されていて
そのときに
そのままやるとスクラムを二つに分けて
Scott
それぞれエンジニアが分かれてってなっちゃうと思うんですけど
Sion
そうすると
今だとIOSエンジニアはIOSエンジニアで集まって
計画とかいろいろ一緒にやってるんですが
それができない環境になっちゃうと今やってる体制の
メリットがなくなってしまうと思っていて
なので今後もこの
同じIOSエンジニア同士で
計画とかをやっていくっていう
体制を維持しつつ複数の施策を
回していくってことをやろうとしてるんですけど
それを具体的にやってみて
どうなるのかっていうところはまだ見えてないので
そこをうまく回していけるのかっていう
Scott
課題というか不安みたいなものがある感じですね
これは特にプロダクトオーナー側の
今結構大きいチームで1つのスクラムチームを回してるんで
それをチーム分割しましょうっていうことになっているので
それをいかに
今までのいいところを引き継いできるかみたいなところは
確かに課題というか不安というか
やってみないとわからないところではあると思うんですけど
そんな感じですね
ありがとうございます
Andy
アンディはどうですか
そうですね
先ほどビッケからあったように
ベロシティを見えるようにするみたいなところが
確かにできていないところだなとは思っていて
まずノーションで何かグラフのようなものを書くみたいなのが
まず実現が難しいんですよね
なので数値としては一応ベロシティみたいなものは
取っているんですけど
そこからはちょっと自分で計算する必要があったりして
もう自己申告ですね
いつ頃終わりそうみたいな話になっちゃうので
なんかパッと誰でも見て
どれぐらいに終わりそうなんだなみたいなのが
Scott
わかるようには確かになってないっていう感じですね
Andy
一応スケジュールとして
リリース予定日みたいな予測の日付を
記録してある場所はあるので
そこを見てもらうのはできるんですけど
リアルタイムに反映しているかっていうと
そうでもないって1週間に1回ぐらいの更新頻度だったりするので
そういったところはリアルタイムに見えるところには
なってないなっていうところですかね
あとはスクラムマスター的な観点で言うと
今のやり方を全社に広めるみたいな
役割もあったのかなと思うんですけど
あんまりそこまではできてなくて
まずは自分たちのチームでうまく回ってる
っていうところまでしかやってないかなというくらいですかね
Stud
なるほどですね
Scott
そこら辺のプロモーションはちょっと僕が頑張って
今ギフトにこうちょっと
プロダクトディビジョンでこんな感じでやってます
みたいな
共有してる感じだったりしますね
ありがとうございます
じゃあスタートどうですか
Stud
そうですね
今のことにも払いますけど
やっぱ社内の知見をいかに効率よく展開するか
みたいなのが課題かなって思いますね
結構プロダクトディビジョン
すごいいい感じにできてると思うので
なんかそこでそこの人たちを何人か
ギフトPJに呼んで
いろいろ講師役になってもらいたいなっていう
そういうのもあったらいいなって今思いました
あとは
そもそもスクラム開発の
お作法みたいなものって
我々本とかしか
学んでてないので
なんかちゃんとした講師呼んで
ちゃんと学ぶっていう機会があってもいいのかな
っていうのは思ってますね
Scott
確かにそうですね
スクラムマスターみたいな人との講師とかも
とてもそうですよね
なんか本で読んでとりあえずやってるって感じなので
一回聞きたいですよね
すごく良かったなと思ったのは
ちょっと大変だと思うんですけど
現場で計画立ててるメンバーが
こうやってるんですよみたいなことを
横展開できるような機会があると
すごい良いかもなって確かに思いました
計画1日かけてますって言われても
何をやってんねんみたいな話になりかねないので
それはすごく良いことかと思ったりしましたね
ありがとうございます
あと僕個人的にちょっと感じてるところで言うと
スクラムアンディとスタッドが回してくれてるんですけど
どちらも専任のスクラムマスターではなくて
専任のスクラムマスターを
来たいなみたいなところはあるのかなと思ってて
そういう人
スクラムマスターをやってましたみたいな人を採用して
チームに参加してもらうみたいなことも
ちょっと必要なのかなって思ったりしています
そうですね スクラムマスター募集中です
という感じで今回終わりますかね
ありがとう
Andy
はい お疲れ様でした
Stud
お疲れ様でした
