これは Supership株式会社 Advent Calendar 2018の1日目の記事です。
こんにちは、トップバッターを務める Kujou です。
Supership データビジネス事業部にて働いております。
現在関わっている新規のプロダクト開発現場では「自社＋開発協力会社」の体制で
開発を行っているのですが、そこにスクラム開発を導入したことを記事にしたいと思います。
記事で書くこと
- 2拠点での開発チームにスクラムが導入されたこと
- 現場で起こっていたことにどう対応したか
記事内では書かないこと
- 基本的なスクラム手法/用語の詳細な解説
- スクラムマスターの役割とは
- レトロスペクティブとは
- リファインメントとは etc
導入
冒頭に書いたように新規プロダクト開発の現場に自分がアサインされ以下の状況になりました。
- MVP完成までの時間が限られている
- 新規プロダクト開発をする中で「自社の開発メンバー＋開発協力会社メンバー」のチームが発足
- 自社開発メンバー
- プロダクトオーナー
- バックエンドエンジニア
- フロントエンドエンジニア
- 協力会社メンバー
- スクラムマスター
- バックエンドエンジニア
- フロントエンドエンジニア
- デザイナー
- 自社開発メンバー
限られた時間の中で最大限の生産性を出すためにも
協力会社含めてのスクラム開発がスタートしました。
自分の役割はスクラムマスター補佐 兼 プロダクトオーナー補佐 のような中間的立場になっています。
現場で起こっていた / 起こりそうだったことにどう対応したか
1. 開発時の共有問題
開発メンバーが2拠点になるということでコミュニケーション、及び開発内容に関しての共有などが疎かに
なるのが大きな問題点として考えられました。
まずスクラム内の重要なイベント（振り返りとプランニング）に関しては
協力会社の人も同じ場所に集まるようにしました。
この部分だけは同じ場所に居ないと実施していくのは難しいと感じています。
加えてコミュニケーションに関してはslack、デイリースクラムでの電話会議による共有を利用し、
対面時と同じような状況をなるべく作ることが重要です。
コミュニケーションに関しては現在はかなり解決できていると思うのですが、
それとは別に実際のコードを書く中では処理がコンフリクトしてしまったり、
近しい機能を作ってしまうなどということが懸念されており、これはチームとして明示的に防ぐ必要がありました。
実際の現場ではその状況に陥ることは無かったものの、近い状況になりそうだったので、
チーム内での解決策としてはある機能を作るときの先行的なPBIを先に準備し、
機能的な優先度と共に開発的な優先度も実際の現場では管理するようになっていきました。
例えばある情報の登録、編集、削除というような機能があるとしたら、
そのバリデーションなどを処理する「モデル作成」が先行PBIとして準備されている、というイメージです。
カンバン上では、
- タスクA（タスクB、Cに対する先行PBI）
- タスクB
- タスクc
- タスクD（タスクE、Gに対する先行PBI)
- タスクE
- タスクG
このような形です。PBI自体はさらに細かいタスクに分解されていますが、
先行PBIが終わった後に後々それに紐づく機能開発をしていくことにより、
現状では同じような処理を作るような事態にはほぼならなくなっています。
開発メンバーも常に先行PBIがどれかという話は整理しながら進めていたので、
これには意味があったと思っています。
2週間1スプリントを繰り返すうちに、機能的な優先度と共に開発的な優先度もかなり意識して
動けるようになっていたので生産性の向上は実感できたかなと。
2. コミュニケーションラインの整理
2拠点になるということでチーム内が混乱しないような整理はとても重要です。
実際の現場では開発する中で後述するような様々な仕様に関する懸念や変更点が起こりえます。
スクラムマスターの役割を持つ人は協力会社になるので、自社 / 協力会社とで状況を整理し、
プロダクトオーナー、スクラムマスターに加えて自分のような中間的な立ち位置も含め、
ある程度コミュニケーションラインを整理した状態が出来上がっていきました。
実際の開発現場では
- 協力会社のデザイナーとスクラムマスター
- 協力会社のスクラムマスターとエンジニア
- 協力会社スクラムマスターと自分
- 自分と自社プロダクトオーナー
- 自分と自社エンジニア
上記のような形で整理されています。
全員が集まるMTGでは情報の鮮度、粒度は同じなのでそこまで気にする必要はないですが、
お互いの開発現場で発生した開発内での細かい仕様の確認、変更などの共有などは、
各個人がバラバラに投げないように整理しルール化されて行っています。
自分の立ち位置がスタート時はやや中途半端な感もあったのですが、
徐々に上記のような状態になっていきコミュニケーションラインの整理として機能したので、
悪くなかったかなと。
3. 最新の仕様問題
正直この部分に関しては現場でも完全に解決出来ている状態ではないです。
あるPBIを作成し機能に関する仕様を策定した後でも、実際の現場では仕様変更が頻繁に起こります。
- 仕様からデザインを起こしてみたらUI/UX的に違和感があった
- UI / UX的にもっと便利になるアイディアが出た
- 開発していく中で作り的に面倒なところを変更する必要が出た
- 他のページの変更に依存して、開発中の機能に影響が出た
- そもそも機能開発していく中で必要ではなくなった、現状では開発しないことを選択した
などなどなど、挙げていったら数限りないです。
またPBIを整理するチケットなどにも仕様が書いてあり、仕様を整理するためにwikiがあり、
画面仕様を起こすワイヤーがあり、ワイヤーをデザインしたファイルがあり・・・と。
仕様変更 ＋ 仕様整理
という複雑な状況を如何に整理するのかというのが大きな課題です。
先に述べたように我々のチームとしても完全に上記の課題を解決できている状態ではないのですが、
基本的な方針としては、
- 何か仕様変更をしたらスクラムマスター/プロダクトオーナーは以下を直ちに更新する
- 仕様を記載しているPBI
- それに準ずるwiki
- 仕様変更の画面ワイヤー
- 仕様に関する話が出たMTG議事内で、上記情報が更新されたかどうかをチェック出来るようにする
- 開発メンバーが常に見る場所を統一する
こんな形で整理しています。
またそもそも「仕様変更が起こりうる場面をなるべく減らす」というのも重要だと感じています。
現在のチームではいわゆるリファインメント（優先度整理、仕様確認）の時間をデイリーで取り、
先々のスプリントで開発する部分の認識合わせをかなり細かい粒度で行っています。
こちらもスクラム内では定期的なイベントとしてスプリント内に組み込むことが多いかと思いますが、
「仕様変更の機会をなるべく減らす」という目的があり、デイリーでやる意味もあったのではないかと。
総論
スクラム開発に関してはなるべく同じ場所、同じ環境でチーム編成してやるべきだとは思いますが、
以下のようなことをチームメンバーが意識すれば2拠点でも問題なく行えるかなと実感できています。
- 開発におけるコンフリクトを防ぐルール
- コミュニケーションラインの整理
- 仕様変更の機会を減らす努力
- 仕様を最新の情報に揃えることの重要性の理解
- 仕様に関して同じ場所を見ることの徹底
- 振り返りとプランニングだけは同じ場所にメンバーを揃える
Supershipではスクラムで開発してみたい人、プロダクト開発に関わる人を超募集しております！
是非ともよろしくお願いします。