こんにちは！
株式会社SCOUTERの鍬(@kuwausk)です。
SCOUTERの開発組織について書きます。
この1年間で僕が所属するチームのエンジニアが2名→6名に増えているのですが、 その中で、「どうプロダクトの品質を守ってきたか、これから守っていくか」をまとめてみようと思います。
開発チームが10名前後の規模感の組織で、プロダクト品質に責任を持っている方が、メインターゲットです。
目次
目次は以下の通りです。よろしくお願いします！
これまでの属人的な守り方について
自分もエンジニアとして開発していたので、仕様設計から実装〜動作確認〜リリースまで、"センス"で品質を守っていました。 リリース直前の動作確認で細かい修正を行うこともありましたが、その度に自分自身の品質レベルが上げていきました。
自分自身が砦になることで、品質を維持して安定リリースすることは出来るようになったのですが、メンバーが4人・５人に増えてくると、
- 同じ品質レベルを共有する手段がない(属人的なので)
- チームメンバーの品質レベルが成長しない
- 自分がPO/PMとして本来やるべき仕事を一層求められる
という課題が顕在化しました。
「自分が離れると問題が発生しちゃうから！」というのは、一見求められている存在なようで宜しいのですが、裏返すとスケール出来ていない証明でもあります。
そして、チームをスケール出来ない、自分が成長できていない、というのはスタートアップ的には死です。。
スクラムをやってみた
チームをスケールさせるにあたり、SCOUTERではスクラムを取り入れました。
スクラムでは、「始めにゴールを決めて、ゴールまでの完成物(インクリメント)を分割して、スプリントでDoneを満たす完成物(インクリメント)をなるべく多く出そう！」ということをやっています。
僕たちは、完成物(インクリメント)を
- 前スプリントの完成物と、今回スプリントの完成物の差分
- すべてが正常に動くように十分にテストされたものである
- Doneの定義を満たすものである
- スプリントの終了時には、新しいインクリメントが「完成」している状態である
と定義しています。
「Doneの定義」は、リリースによって事業数値が伸びるかどうかを保証するものではありません。が、「サービス提供者として提供可能な品質である」ことを保証するものです。
種明かしになりますが、本記事のタイトルである「リリース品質、どうやって守っていますか？」に対するアンサーは、「Doneの定義で守っています」ということになります。
プロダクトバックログアイテム(PBI)やインクリメントの「完成」を決めるときには、全員がその「完成(Done)」の意味を理解しておかなければいけない。スクラムチームによってその意味は大きく異なるかもしれないが、作業の完了についてメンバーが共通の理解を持ち、透明性を確保しなければいけない。これは、スクラムチームの『「完成(Done)」の定義』と呼ばれ、プロダクトインクリメントの作業が完了したかどうかの評価に使われる。開発チームは、スプリントごとにプロダクトインクリメントを届ける。インクリメントは実際に利用可能なものであり、プロダクトオーナーがすぐにリリースすることもできる。インクリメントの「完成」の定義に関して、開発組織の慣例・標準・ガイドラインが存在する場合は、スクラムチームは最低でもそれを守らなければいけない。( スクラムガイド - Scrum Guidesより抜粋)
SCOUTERのリリース品質チェックリスト、公開します！
ここで、今実際にチームで運用している「Doneの定義」を公開してみようと思います。
「こんな当たり前な内容を書かないと守れないのか」とか「1週間で満たすには結構厳しい条件だな」など色々思われるかもしれませんが、これが今の僕たちの品質そのものです。
WF
- 必要なページが全て揃っている
- ページ内で必要な要素が揃っている
- ページごとに各要素の重要度を分類する
デザイン
- ユーザーストーリーを満たすフィーチャーがデザインされている
- 技術的な実現可能性の検討結果がesaに記録されている
- スタイルガイドの更新について検討結果がesaに記録されている
- 操作可能なオブジェクトの動的な挙動がある場合、それがesaに記述されている
- 操作可能なオブジェクトに対してhover,action,focusなどのデザインが網羅されている
- アニメーション・トランジションが発生するオブジェクトについて、挙動がesaで明確化されている
- 書き出しが必要な素材について、2倍の解像度でzeplinからダウンロード可能になっている
- 要素数が0件のパターンがデザインで網羅されている
- 要素数が多い場合のパターン(スクロール・ページネーション・展開など)がデザインで網羅されている
- 文字コンテンツの字数が多い場合の取扱がデザインで網羅されている
仕様/設計
- ユースケースを満たすエンドポイントが全て定義されている
- エンドポイントに対してAPISPECが作成されている
- デザインで扱っている項目を満たすDBスキーマが定義されている
- esaにDB仕様書が作成されている
- 現行仕様への影響が洗い出されている(現行仕様を変更する場合)
実装
- APISPECとAPIのレスポンスが同じ形になっている
- ユーザーストーリーで定義されたアクションを実行することができる
- デザイナーのUIチェックが通っている
- CI、レビューが通っている
- リリース手順が用意されている
ブラウザテスト（ステージング環境）
- ユーザーストーリーで定義されたアクションを実行できる（IEを除く）
- 現行仕様への影響箇所のテストのチェックリストを全て満たしている
振り返り
- ストーリーポイントについて、予定pt,完了ptが記録されている
- ストーリーポイントについて、3週間の平均(velocity)が記録されている
スプリントプランニング
- タスクが一覧化されている
- インクリメントごとにタスクが分割されている
- 分割したインクリメントを完成させる順番が決まっている
- タスクの見積が完了している（2点見積でも可）
- 見積結果を元にインクリメントの調整が終わっている
- 調整後のインクリメントが定義されている
- わかっているAPIの一覧が書き出されている
- 影響範囲がページ単位で明確化されている
※スプリントプランニングは、スプリントの始めに行うミーティングです
(参考) 1週間のスプリントにおける開発フロー
Doneの定義についてのチームのルール
補足になりますが、Doneの定義について、チームで以下のルールを設けています。
- Doneの定義は、スプリントの合間に更新しても良い
- Doneの定義は、開発チーム全員で満たすように頑張る。責任者を明確に定めない
- Doneの定義は、スプリント振り返りのmtgで発案し、合意すれば更新できる
- Doneの定義は、チームの習熟度によって追加され、定義が厳しくなるものである
スクラムを入れてみて思うこと
エンジニアやデザイナ出身で、職能のあるPO/PMは特に、"自分が出来る仕事" "簡単にバリューを出せる仕事" で手を動かしてしまいがちです。
けれども、PO/PMには、プロダクトを成功に導くという大事な役割があります。 僕自身は最近POとして、
- 開発ロードマップの更新(プロダクトバックログの可視化・並び替え)
- 完成物(インクリメント)の確認、開発チームへのフィードバック
- ユーザーインタビュー(企画した機能についてインサイトを探す)
- ユーザビリティ検証
- 数値分析(SQLを書く、振り返り、ログが足りないところのDB設計と実装)
- リリース準備(マーケチームやCSチームとの連動など)
- 大きな障害が発生した時のディレクション
などを行っていますが、"設計や実装をしている場合ではない"と、半年前の自分に教えてあげたいです。。
開発チームの人数が増えたりプロダクトがMVPリリースの時期を超えたりすると、PO/PMに求められる仕事は、実装や設計やリリース期限を守ることではなくなると思っています。開発チームと相互に助けあって、集合体としての力を最大化すれば、人間ひとりでは出来ないようなアウトプットを創造することができます。
プロダクトを成功させられるように、開発チームとPOがそれぞれの役割を最大限果たせるように、引き続き取り組んでいきたいと思います。
最後に
Doneの定義に「テストが通っていること」を追加してくれるリードエンジニア、募集しています！
デザイナーさんも大募集中です！ www.wantedly.com
