CRMチームです。
2019年度にチームビルディングや技術的な施策に関して、CRMチームで実施したことでうまくいった・いかなかった点をまとめてみました。
はじめは社内で共有しようと思っていたんですが、「ブログ書けば社内外に共有できるよ」と囁かれたので公開します。
1. KPT Problemに解の質・Issue度を導入してTryの対象を絞り込み
課題
- Problemがたまる一方
- どれに取り組んだらいいかが分かりづらい
方法
まずはProblemを列挙する 4象限マトリクスで表現された解の質(y軸)・Issue度(x軸)の当てはまるところに移動させる。
解の質とIssue度が高いProblemに対してTryを考える 解の質が低くIssue度が高いものは解決できるようにProblemを分解したり議論する。
※Issue度・解の質については、「イシューからはじめよ」から拝借しました。http://www.eijipress.co.jp/book/book.php?epcode=2085
結果 ⭕️
以下のように分離できた。
- 解の質: 高／Issue度: 高→取り組む価値あり
- 解の質: 低／Issue度: 高→解を見出すために分解
- 解の質: 高／Issue度: 低→チーム全体には影響ないのでBacklogに課題登録して適宜
- 解の質: 低／Issue度: 低→取り組んでもコストパフォーマンス悪いので見送り
2. リリースフローのドキュメント化
課題
2019年9月頃からモブリリースを導入していたが、リリースフローについて明文化されていなかった。そのため新規メンバーへの説明もされず流れで参加してもらうようになっていた。新規メンバーからするとどのようなフローで進められているかよく分からない状況であった。
方法
リリースフローをQiita::Teamに明文化した。
結果 ⭕️
効果を評価するのは難しいが、明文化することで説明しやすくなったと思われる。また、新規メンバーにもチームがどう言ったことを実施しているのかwikiを見れば分かるようになった。
3. コードレビュー導入
課題
業務的観点
技術的観点
共通
- 新規メンバーのフォロー
- お互いのタスクや自チームで何が行われていることの把握
方法
GitHubの review assignment 機能を使用してラウンドロビンでレビュアーを自動選定する。指定された方はベストエフォートでレビューを行う。レビュー時に指摘や疑問に思ったことはPull requestのコメントに記入 またプルリクのテンプレート機能を使って、レビュアーにプルリクの説明を伝えるように工夫。新規メンバーにはレビューを通してチームが何をやっているのか簡単に把握してもらい、仕事やっている感を感じてもらう。
結果 ⭕️
業務的観点の評価は分からない(評価方法も考える必要あり) 技術的観点からいうとバグ・typoの指摘やコードの書き方などコメント上でやりとりがあったので、主観的ではあるが一定の効果はあったと思われる。
この4月からはレビュアーの負担を考慮して、チーム内の担当領域を大きく２つに分け、その中でアサインをすることになった。
ノウハウの共有とそれによる負荷のバランスの調整を今後も行っていきたい。
また今後の課題としてコードレビューがチーム開発にもたらした効果を評価する仕組みを作る必要がある。
4. バラバラだったブランチ戦略を統一化
課題
- リポジトリごとにdeploy方式が異なっていたため、CI/CD時を念頭においたブランチ戦略も異なっていた
- ex) handsnet-api: developブランチ→stg、masterブランチ→prod
方法
第1フェーズ: master & develop & feature ブランチ並行稼働
施策以前はリポジトリごとにブランチ戦略が異なっていたので、新規作成・変更可能なリポジトリは統一した。以下のような理由から本番はmaster、ステージングはdevelop、ローカル開発はfeatureブランチに紐付けた戦略をとった。
- 新規参入の開発者がスムーズに合流可能
- テスト/rebase/revert単位の矮小化
- コンフリクトの減少
- バグ修正なのか、機能追加なのかをブランチ名で判断可能
- ステージングと本番で稼働しているコードとブランチを紐付け
↓ブランチの関係を図に起こしたもの 
しばらくはこの方法を続けていたが、運用していく中でいくつか課題が見つかった。
- masterにマージするためだけにdevelopブランチを起点としたプルリクを作成
- ステージングでテストするためにdevelopブランチにマージしなくてはならない
- GitHubの機能でmasterブランチ(デフォルトブランチ)でないと使用できないものがあった
これらの課題があったので第2フェーズではブランチのシンプル化を目指した。
第2フェーズ: master & feature へシンプル化
ステージングで気軽にテストするためと主要ブランチをわかりやすく1つにするためにmaster & featureブランチのみにした。CI/CDを使用して気軽にステージングでテストできるように {Ymd}.stg.{sequence} タグを打てば自動でステージングにデプロイしてテスト可能にした。masterにマージされたタイミングで自動でステージングにデプロイするようにしたので最新のコードがステージングで稼働するようになった(タグでステージングにデプロイするリポジトリもある) 。本番へのデプロイは {Ymd}.{sequence} タグを打てばいいので任意のタイミングでデプロイ可能になり、複数のプルリクをマージ後にまとめてデプロイできるようになった。
↓新Git Branch & Tag Flow
結果 ⭕️
- 基本的にfeatureブランチ → masterブランチに集約された
- ブランチ名をつけやすくなった
- Backlogとの紐付けをAutolinkで実施するようにした、というのも一因
- tagのおかげで前回との差分がわかりやすくなった
- 変更をまとめてデプロイすることが可能になった
- featureブランチをステージングで気軽にテストできるようになった
5. モブリリース対象の制限
課題
CI/CDの導入前にモブリリースを導入していたが、CI/CDを導入後にもほぼ全てのリリース作業はモブリリースしていた。そうなると自動デプロイを見守るだけの時間が発生してメンバーの時間を奪ってしまう懸念があった。
方法
プルリクにモブリリース ラベルをつけることで、モブリリースの対象かそれともソロリリースするのかをフィルタリング可能にした。また、前提としてレビュー済み・事前にリリース連絡は必須とした。モブリリース とするのは原則としてgit操作などの手作業があるリリースや、本番への破壊的は変更がある場合にすると周知を行った。
結果 ⭕️
モブリリースが前よりは減ったので、それ以外の作業に時間を回すことができている。今後の課題はモブリリースにするかしないかの線引きをはっきりさせることだ。
6. GitHubプロジェクトの導入
課題
CRMは大量のリポジトリがあるが、開発中・レビュー待ち・リリース待ちなどを1箇所で管理しておらず把握するのが難しいかった。
方法
GitHubのProject Board機能を利用
結果 ⭕️
どのリポジトリのプルリクがどのような状態であるかを簡単に把握できるようになった。モブリリース時にリポジトリを横断して対象を把握できるようになった。
7. ドキュメントをGitHubに移行
課題
BacklogやQiita Teamでドキュメント管理していたが、継続的に更新する時に以下のような問題が発生した。
- 情報が分散する
- 議論が必要な場合に新たに別記事を作成しなければならない
- 過去のドキュメントとの紐付けが難しい
- ドキュメント更新者が作成者と同一になりやすい
- 共同編集モードになっていても他メンバーが更新しにくい
GitHubへの移行メリット
- 議論とドキュメント更新を紐付けられる
- 開発者であれば使い慣れている
- 情報を集約できる
- 社内に向けてCRMの情報をオープンにできる
方法
移行自体は更新頻度が高そうな記事を順次移行とする。
運用方法は本Issueで議論した上でプルリク(ドキュメント)を作成してマージを行う。
ドキュメントの更新でIssueが必要ないものは直接プルリクを作成する。
運用方法の流れ
- Issue作成
- 議論
- プルリク作成
- レビュー
- マージ (= チームに導入)
結果 ❌
運用サイクルがうまく回らなかったのと、移行中にドキュメントが分散してしまい断念した。
新しいドキュメントを新しい場所に書くにせよ、既存ドキュメントを参照せずには業務が回らない。すべて移行してしまい、既存ドキュメントを削除する、などの思い切った移行作業を行えば切り替えできたかもしれない。
まとめ
毎週の振り返りをKPTでやってきて、Tryしてきたものを列挙してみました。色々やったなぁ・・・。
2020年度も色々やります。
