2019新卒・配属から1年経ったので振り返り

日常
2020年8月3日
北邑圭佑

こんにちは！POSチームの北邑です！

去年4月に新卒入社、7月にチームに配属されて今年の7月で1年経過しました。
ここ5ヶ月は新型コロナウイルスの影響で在宅勤務に勤務体系が変わってきたりと、イレギュラーな1年ではあるんですが、振り返ってみたいと思います。

Pocket

突撃!隣のリモートワーク

リモートワーク
2020年7月2日
asahina

Pocket

こんにちは、ハンズラボのfasahinaです。

弊社では今年3月より暫定的にリモートワーク勤務を継続しているのですが、緊急事態宣言解除後も恒常的にリモートワークを実施することが決まりました。

さて、以前エンジニアブログ界隈では社員みんなのキーボードを紹介する記事が流行っておりました。
弊社ももちろん便乗しております。

突撃!隣のキーボード
https://www.hands-lab.com/tech/entry/3272.html

そんな折、他社さんのブログの記事でこんなものを見つけました。
freee株式会社さんの記事

これは・・・乗るしかないこのビックウェーブに
というわけでこちらをパク便乗する形で弊社もやってみようという運びになりました。

Pocket

CRMチームが2019年度に行った施策について

Pocket

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操作などの手作業があるリリースや、本番への破壊的は変更がある場合にすると周知を行った。