初めまして、コネヒト所属のラブライバー田村(@Utmrer)です。 今日は「CTO以外もブログ書けよ」ってことで私が弊社の女性向けサービス（ママリ・ママリQ）を支える女神についてご紹介致します。
弊社のサービスを支える女神たち
現在、弊社のサービス開発は次の3人の女神たちによって支えられています。
- コミュニティマネジメントを効率化することり
- DeveloperとDirectorを繋ぐ花陽(はなよ)
- Pull Requestの質を高める海未(うみ)
今日は海未についてご紹介致します。
海未が生まれるまで抱えていた問題
弊社のサービスは去年まで私とCTOの2人のエンジニアによって開発されていましたが、春からはμ'sのように新しくエンジニア入ってきて以前の倍以上のエンジニアによって開発されています。
人数が増えたのはいいのですが、Pull Requestのレビューに関して以前よりも情報共有の不足が起こり易くなりました。
- このPull Requestってなんのためにやるんだっけ？
- この実装で十分なんだっけ？
- 重点的にレビューするべきなのはどこなんだろう？
このようなPull Requestのコンテキストをレビュアーが把握していないというケースがありました。
海未が生まれるまでの解決策
そこで最初に導入したのがクックパッドさんのこの記事に書いてある「目的」と「やったこと」を書くスタイルです。
これによって「なぜこのPull Requestが作られたのか」を把握できるようになりました。
ここで私は思います。
「いちいちメモ帳からコピペするのめんどくさいですね…」
めんどくさいなら自動化する
メモ帳からコピペしてくるのがめんどくさいのでPull Requestを作る時に勝手に入力してくれるChrome Extensionを作りました、それが海未です。
Pull Requetを作るページの#pull_request_bodyを探して次のような典型分を入力します。
## 目的 ## やったこと ## 追うべき数値 ## 関連するIssue ## チェック項目 - [ ] File Changedのセルフレビュー - [ ] Conflictを解消したか
定型文の各項目は下記のような内容です。
目的
ここには「なぜこのPull Requestが作られたか」を書きます。この項目は抽象的で要求仕様であることが多いです。
やったこと
ここには実際に行った実装の内容が入ります。ロジックの内容を書いたりして、レビュアーはこの項目に書かれている通りに実装されているかをレビューします。
追うべき数値
弊社ではリリースされた機能は必ず振り返ります。振り返りの仕方などは以前に弊社CTOの島田が公開した独身男性のためのデータドリブン講座にて紹介しています。
ここにどのような数値を追うべきか、その値がいくつだと「良い結果」と判断するか、などを書きます。
関連するIssue
Pull Requestがトピックブランチからさらに切られたトピックブランチだった場合、親ブランチが何なのかを把握しなければレビュー出来ない場合があります。
その場合にここにブランチが切られた流れを書くことでレビュアーは事前知識を得ることが出来ます。
チェック項目
これは一度セルフチェックすれば無くなるようなコミュニケーションを少なくするためです。
「ここスペルが違います」「改行の量が明らかに多いです」「こんなの破廉恥(はれんち)です！」など、こういった単純なミスは極力事前に減らしたいですね。
サンプル
このテンプレートにそって実際に作るとこんな感じになります。
海未を導入して
海未を導入することによってコピペするという作業が効率化された上に、Pull Requestのクオリティが上がりレビューコストが下がって作業効率が上がったと実感しています。
なぜ海未という名前なのかというと、「Pull Requestのdescriptionをちゃんと書こう」と注意するのって誰だろうと考えた時に海未ちゃんだったんです。
ほら、聞こえませんか？
「穂乃果(ほのか)、Pull Requestのdescriptionはちゃんと書かないといけませんよ。」
という海未ちゃんの声が…。
おわりに
私は自動化厨なので1日に何回もやる作業があればすぐツールを作ります。花陽やことりもそういったツールなので機会があればご紹介したいと思います。
また、弊社では効率化ツールを9人まで増やしてくれるラブライバーを募集しています。
興味がある方は是非ラブライブの話をしに来て下さい。
ラブアローシュート！
