カンバン方式でチーム開発を改善しました
みなさんこんにちは！ワンキャリアでテックリードをしています、宇田川(X：@Ryoheiengineer)です！
今回は「カンバン方式」を僕たちのチームに取り入れたことで、チーム開発が改善した実例を記事にしました。
カンバン方式や、チーム開発に興味がある方はぜひ、ご一読ください！
チームが抱えていた課題
僕たちのチームは、以下のエンジニア5人で構成されていました。
テックリード1人
フロントエンジニア2人
バックエンドエンジニア2人
当時は5人が8個のタスクを同時に行っており、お互いがどんなタスクをやっているかわからない状況でした。
それゆえに、以下の問題が発生していました。
実装の周辺知識が浅いため、レビューの質が落ちる。
誰かが詰まっていても、自分のタスクで精一杯なのでサポートできない。
チームメンバーが疲弊しており、何か変えなければいけないと思ったときに出会ったのがカンバン方式です。
同僚に紹介してもらった『カンバン仕事術』という本を本を参考にしながら、チーム開発にカンバン方式を取り入れていきました。
カンバン方式とは
カンバン方式とは、アジャイル開発の手法の1つであり、その特徴は以下のとおりです。
見える化
WIP（仕掛り作業）の制限
各工程の改善
見える化
見える化とは、チームメンバーのすべての仕事を見える状態にすることです。
見える化をすることにより、チームメンバー全員が、誰が・何の仕事をしているか、どのステータスにいるかを知ることができます。
具体的には以下のような内容です。
誰が：チームメンバーの〇〇さん
何を：〇〇のチケット
どのステータス：リリース待ちの状態
これらの見える化では、通常ワークフローボードを用意して実施することが推奨されています。
見える化するときに大事なポイントは2つです。
仕事がチームに入るところから出て行くまでの各工程を明確にする。
顧客に価値を生み出すまでを工程とする。
僕たちのチームでもワークフローボードを使い、工程を以下のように分けています。
1. 開発待ち
2. 開発中
3. PdMレビュー
4. リリース待ち
5. 完了
以前より工程を細かく分けたことでチケットの正確な状態を把握することに繋がり、より適切で素早い判断が可能になりました。
WIP（仕掛り作業）の制限
WIP（仕掛り作業）の制限とは、作業中のタスクの数を制限することです。
作業中のタスク数を絞ってフロー効率を高めることにより、着手からユーザーに価値が届くまでの時間を短縮します。
僕たちのチームでは、WIP制限を入れて作業中のチケットを1ユーザーストーリーに絞り、そのチケットをさらにサブタスクにわけチームメンバー全員で対応しています。
特定のサブタスクで止まるとチケットが完了しないため、そのときには積極的にペアプロやモブプロをして、メンバー全員でサブタスクを完了しています。
各工程の改善
各工程の改善とは、どの工程に課題があるかを特定して改善することで流れをより速くすることです。
僕たちのチームでは、エンジニア組織における開発生産性を可視化・向上するプロダクト「Findy Team+」を使い、どこの工程に課題があるかを週1で分析し、その課題に対して改善のアクションを起こしています。
チームに起こった変化
カンバン方式を実践してから1年、以下のような様々な変化が起こりました。
チーム内でのコラボレーション活性化
チーム内でのナレッジシェア
実装〜ユーザー提供までの時間を短縮
チーム内でのコラボレーション活性化
WIPを制限しフロー効率を高めることを掲げたことで、チーム内でのコラボレーションが活性化しました。
具体的に言うと、タスクの進め方のコミュニケーションや、ペアプロ・モブプロの機会が増えました。
チーム内でのナレッジシェア
1つのタスクをチームで進めることによって、個人が得た知見を積極的にチーム内へシェアする文化が生まれました。
これは、Railsのデフォルトのi18nへの移行時の注意点に関するメッセージです。ワンキャリアでは、Ruby on Railsにてi18nを翻訳するために独自のサービスを使っていました。
これをデフォルトのRailsのi18nの翻訳に戻すため、i18nのkeyを変更する必要がありましたが、変更箇所が多かったためチームメンバーで作業を分割しました。その際変更時の注意点を一人が他メンバーに共有したことで、効率的に進めることができました。
チームとして1つのストーリーのチケットを進めることによって、このようなチームへのナレッジシェアが頻繁に行われています。
実装〜ユーザー提供までの時間を短縮
カンバン方式を始める前と比較すると、実装からユーザー提供までの時間が118.1h → 23.8hと大幅に短くなりました。
また他の要因として、PRの粒度が小さくなったことも挙げられます。
1ストーリーを複数のサブチケットに分けて進めているので、サブチケットの粒度が細かくなったことによって、それに紐づく1PRの粒度も小さくなり、実装の工数やレビューの負荷も小さくなりました。
おわりに
今回はカンバン方式を取り入れて、チーム開発を改善したお話をしました。
カンバン方式を実践することで、チームとして大きく成長できました。
ただ今回の改善は、実装からユーザーへの価値提供までに限定されていました。今後は、改善しきれていない企画から要件定義の工程について、改善アクションを起こしていこうと考えています！
ワンキャリアでは開発生産性を高めるために他にもいろいろな施策を実施しています。
開発生産性にご興味があるエンジニアの方を大募集してます！
ぜひぜひお気軽にお話しましょう〜！
▼ワンキャリアのエンジニア組織のことを知りたい方はまずこちら
▼カジュアル面談を希望の方はこちら
▼エンジニア求人票
この記事が気に入ったらサポートをしてみませんか？