＼スニダンを開発しているSODA inc.の Advent Calendar 12日目の記事です!!!／
はじめに
開発プロセス[1]の改善として自チームで取り組んだことを失敗[2]した事と課題も含めて一部紹介していきます。
チーム構成
PdM: 1名
開発者: 6名
チーム設立から1年半ほど
設立当初はPdM:1名、開発者:3名
環境
言語: Go,TypeScript
フルリモート
コミュニケーションツール: Slack,Gather[3]
1. ペアプロ・モブプロをする
内容
レガシーコードからの脱却[4]を読んだ影響でペアプロ・モブプロ[5]を行うようにしました。
期待した主な効果としては下記になります。
- 技術やドメイン知識の平準化
- 複雑なタスクの壁打ちをして思考を整理する
- 新たに参加したメンバーのキャッチアップの速度向上
30分でナビゲータとドライバーを交代して進めています。
良かった点
当初期待していたような効果はありました。また副次的な効果として割り込みで声をかけられることが少なくなり作業に集中しやすくなったり、メンバー間のコミュニケーションが促進されたように思います。
失敗・課題
モブプロの人数が増えると発言の偏りや、なにもしていない時間が生まれてしまう人が居て無駄が多いのでは？という意見がありました。これに関しては本来モブプロで期待している動きが出来ていないと思うので、モブプロを効果的に行うスキルを向上させていかないといけない課題があります。
意識的にペアプロ・モブプロをしていこうとしないと時間が経つにつれて、実施頻度が減っていきました。これに関しては、手が空いた時に仕掛かり中のタスクがあれば合流するようにしたり、ドメイン・技術的に複雑なタスクがあればペアプロすると決めたり試行錯誤中です。
2. チームで勉強会をする
内容
よりよい開発[6]を行うためには、メンバーのスキルを向上させる必要があるという考えのもとチームで勉強会をすることにしました。
メンバーのスキル向上に有効なのは結局の所、個々人の頑張りが大きいかなと思いますがチームとして少しでもそこに寄与できることがないかという背景があったりします。
週に1度1時間メンバーの興味があるトピックを開発者全員で調べたり、話したりしています。
興味のあるトピックがない時はスキップしています。
実際の勉強会のトピック(一部抜粋)
良かった点
一般的に勉強会のメリットとして言われているようなことです。
失敗・課題
さまざまなロールのチームメンバーが増えてきたことにより、特定の領域に関するトピックだとチームメンバー全員が参加できる形で勉強会を行うのが難しいことがあります。
3. PRを小さく分ける
内容
PRを細かく分ける取り組みを行いました。
期待した主な効果としては下記になります。
- メンバーの取り組んでいるタスクが把握しやすい
- レビューの認知負荷が下がる
- 大きな手戻りを減らす
2022/06/07~06/10のPRあたりの平均変更行数(言語は主にGo)[7]
2023/12/05~12/08のPRあたりの平均変更行数
※非稼働日を含めないようにするために、火~金で計算しています。
良かった点
複数の関心事が組み合わさったPRをレビューするのに比べレビューの認知負荷が下がりました。
またPRを細かくする=タスクを細かくすることに繋がり、作業の分担がしやすくなりました。
数稼働日かけてレビューに出したPRが根本の箇所が原因で手戻りが発生することも少なくなりました。大きな手戻りが発生してしまうそもそもの要因に対しては、プランニングを同期的に行うなどで対応しています。
すべてを含んだPRでないと、全体を俯瞰したレビューや実装が出来ないのでは？という懸念がありましたが、こちらは例えば関数単位で実装したコードを上位のレイヤー(サービス/ユースケース層など)で使用して実装しそのPRで確認を行うので懸念していたような事が問題になることはなかったです。
失敗・課題
レビューの優先順位を上げないと、レビュー待ちのPRが溜まり大きなPRをレビューするのと変わらないので即時レビューとセットで運用する必要がありました。
また実施し始めは関心ごとの分離になれておらず大きなPRになりがちでした。
こちらはレビュー時にもっと関心ごとを分離できないかも確認することで徐々にPRを小さくすることが出来てきています。
もう変更行数の多いPRをレビューしていた頃には戻れなくなりました。
4. レビューの優先順位は高めに
内容
PRを小さく分けるを実施するのとほぼ同時にレビューの優先順位を高めにしました。
Cloudアーキテクチャセンターのトランクベース開発の改善方法[8]を参考にしたりもしました。
さらに具体的な内容は、bocchidaikiさんのチームで1年間コードレビューを最優先に実施したら開発生産性に良い影響を与えてくれたかもに詳しく記載されています。
簡易的に下記のように優先順位付けをしています。
良かった点
レビュー待ちで仕掛かり品が増えることが減りました。
また指摘があった場合も軌道修正が早くできるので大きな手戻りが発生することが少なくなりました。
レビューが頻繁にくることによりスイッチングコストが掛かる懸念がありましたが、PRを細かく分けることで比較的短い時間で区切りがつけやすいのもあり、作業効率が目に見えて落ちるようなことはありませんでした。
失敗・課題
この取り組みに関しては特に大きな失敗・課題はなかったように思います。
5. タスク分解を同期的に行う
内容
スプリントで実施することになったバックログアイテム毎に、開発者全員でタスク分解と実装方針を考える取り組みをしています。
期待した主な効果としては下記になります。
- 技術やドメイン知識の差による実装方針の違いや考慮漏れをなくす
- 実装方針を考える際の属人化の防止・ナレッジの共有
分解したタスクのイメージ
良かった点
複雑であったり未知のバックログアイテムに対して実装方針のずれが少なくなり、実装後に大きな手戻りが発生することが少なくなったと思います。また分解したタスクの実装方針を開発者全員が思考過程まで含めて理解していることで、分担してタスクに取り組みやすくなりました。
失敗・課題
1スプリント分のバックログアイテムのタスクを分解しきるのに、3~4時間ほどかかってしまいます。これに関してはすでに実装方法がチーム内で確立されているものや、比較的実装が容易なバックログアイテムに関しては担当者を決めタスクを分割,実装方針の検討を行い、その後開発者全員で結果をレビューするようにして時間を短くできないかなど試行錯誤中です。
メリットと裏返しになりますが、個人で答えを持っていなくてもチーム内に答えがあれば迷う箇所などすぐに答えが出てしまうので、個人で限界まで不明な箇所を調べ切って実装方針を考える場合と比べて実装方針を考える力が付いていくのかどうなのか難しい所だなと思っています。
6. ビジネス側の状況を理解する
内容
よりよいプロダクト開発[9]の為には、開発者が知らなくて良いことはないという考えのもとプロダクトのKPIやプロダクトが置かれている状況などをチームでより理解する取り組みを行いました。
具体的にはPdMやステークホルダーからKPIの推移の要因や説明、上位の階層の意思決定の会議の内容を共有して貰う場を設けました。
良かった点
施作の背景や目的をより開発者が理解することで、開発者側だけの視点ではなく全体最適を多少考えられるようになったかなと思います。がここらへんは何が出来るようになったかの判断は難しいですね。
失敗・課題
深く理解しようと思うと理解しないといけないことがたくさんあるので、個人の頑張りに頼らずチームの活動の中で効率的にキャッチアップするにはどうしたら良いか試行錯誤中です。
普段の業務と直接的な関わりが意識しにくいと理解するインセンティブが薄くなるので、いかにチームの目標やゴールとの繋がりを理解出来るようにするかが課題に感じています。
7. ファシリテーターをローテーションする
内容
チームではスクラムのようなもの[10]を導入しており、各種イベントのファシリテーターをローテーションするようにしました。
期待した主な効果としては下記になります。
- 各種イベントに対してオーナーシップを持ちやすくする
- 各種イベントで実施しないといけないことを覚えやすくする
良かった点
どこに情報があって、なにをしないといけないか少しずつ定着してきたように思います。
失敗・課題
当然ですが各種イベントの目的や必要性を理解できていないと、ファシリテーターをローテーションしたところでオーナーシップは生まれないので前提としてそれらを満たしている必要があります。[11]
8. 同期的な会議を爆破する
内容
週の会議時間が稼働時間の半分以上になり実装の時間が取れない問題が発生していたので、同期的な会議を爆破しました。必要なものがあれば復活していくだろうという推測の元、強引ではありますが自チームで完結している会議の予定を削除しました。完全に会議で実施していたことを止めるのではなく非同期+テキストベースで進められるものは移行していく取り組みでもあります。
画像は爆破する前の週と爆破した週を比較したもの
良かった点
同期的に集まらなくて良いものは一部非同期+テキストベースのコミュニケーション前提で進めることが出来るようになりました。その為頻繁に会議が存在することによるスイッチングコストは減ったように思います。
失敗・課題
当然ですが同期的な会議で思考していたり、コミュニケーションを取っていた時間は非同期にしても必要なので会議をなくした時間=実装に当てられる時間ではなかったです。
テキストベースだとコンテキストの共有に時間がかかったり、やりとりが何往復もする場合もあるので、その場合は同期的に集まるなど使い分けをしています。[12]
9. ストーリーポイントをつける
内容
相対的なポイントをつけることによりスプリントでどれくらいタスクが消化できそうかの見積もりに使うために導入しました。[13]
良かった点
スプリントの振り返りの際に、過去のスプリントの消化ストーリーポイント数と比較して、ベロシティが安定しているか議論する材料として使えました。
失敗・課題
予実のチェックのために使用し始めたことにより予実がズレて来た際に、詰まっている箇所や困っていることなどバックログアイテムを完成させる為の障害についてではなく、ポイントの妥当性や、測定の仕方の議論になってしまうことがありました。そのため現在は予実のチェックのためにストーリーポイントを使用することは止めました。[14][15]
最近はチームが慣れてきてタスクを同じくらいの粒度で細かく分けられるようになってきたので、ストーリーポイントは付けなくても良いのかもしれないと感じています。
10. 誰かがボケた時の対応について
内容
誰かがボケた時に誰も反応してくれないと悲しいので、チームで積極的にツッコむことになりました。
チームで決めたルールにも記載されています
良かった点
気持ちよくボケることが出来るようになったと思います。
また誰かがボケることで、雰囲気も和らぎその後の議論もしやすくなったように感じます。
適度にリラックスした環境ができ、創発的なアイデアが生まれやすくなったかもしれません。
失敗・課題
上手くツッコミが出来なくて無言の時間が生まれることがあります。
またボケすぎて仕事の話題から逸れすぎることもあるので、適切なファシリテーションが必要です。
-
失敗は成功の母と誰かが言ったとか言わないとか本当に言っていないとか ↩︎
-
曖昧な表現ですが、よりよい開発とはなにかについてはこの記事では省きます。 ↩︎
-
Findy Team+を利用したデータです。 ↩︎
-
曖昧な表現ですが、よりよいプロダクト開発とはなにかについてはこの記事では省きます。 ↩︎
-
スクラムガイドに記載されている要素を一部省略してしまっていたりするので、スクラムとは異なるが似ている箇所があるものという意味で
スクラムのようなものと記載しています。 ↩︎ -
GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ ↩︎
株式会社SODAの開発組織がお届けするZenn Publicationです。 是非Entrance Bookもご覧ください！ → recruit.soda-inc.jp/engineer
Discussion