マイナビ Tech Night #3 でチーム開発をする上でやってきたことについて話しました
この記事は，マイナビ Advent Calendar 2019 4日目の記事となります. 前日は「GCEインスタンスの起動/停止をローカルマシンと同期する」でした．ちょうど個人開発をやりたいと思っていて，課題だと思ったことを解決するヒントを貰えた記事でした．
先月「マイナビ Tech Night #3」でトーク枠で登壇しました．今年の1月から入社し，イベント当日までマイナビニュースでやってきたことを発表する内容となりました．
今回は登壇した資料についての補足や発表時にあまり話せていなかった内容を書いていこうと思います．
登壇資料
プルリクエストの情報が GitHub 上に無い😨
マイナビニュースで開発をする時，マイナビ側のエンジニアは GitHub *1 ，開発ベンダー側のエンジニアは GitLab というように Git のホスティングサービスが分かれていました．
これにより開発ベンダー側のプルリクエスト（GitLab で言うマージリクエスト）の情報が見ることができず，実装の意図を追うのが大変でした．また開発ベンダー側がリリース前にどのような開発プロセスを経ているのかをマイナビ側で細かく把握できなかったのも課題でした．
やったこと
まずは Git のホスティングサービスをマイナビの GitHub に統合するところから始めました．今までは開発ベンダーへ開発依頼をする時は，Redmine で依頼をしていたため，Redmine から移行し，マイナビの GitHub で開発する上での issueやプルリクエストの使い方についてなど開発フローを再整備しました．
マイナビ側で開発フローの案を出し，開発ベンダー側へフィードバックを貰いながら進めていきました．
次に CI 環境の構築です．マイナビの GitHub を開発ベンダーのエンジニアも使うということはマイナビの CI を使うことになります．しかし他のチームと共用で CircleCI を利用していたため，タダでさえ契約コンテナ数が少ない状態から CI を利用するエンジニアが増えるということになり，CI の実行待ちが増えることが容易に想像できました．
CircleCI の場合，現在では「PERFORMANCE プラン」に変更すると従量課金制になり， CI の実行待ちを気にする必要が無くなりますが，当時はすぐに何とかしないといけない課題であったため，マイナビニュースでは AWS CodeBuild で CI 環境を構築することにしました．
その時の登壇についてまだ記事を書いていないため近々書こうと思います．
追記(2019/12/15)
こちらの記事で詳細を書きました．
え！誰が今どの環境でデプロイしてるの？😕
検証環境へのデプロイやリリース作業をした後，Slack で開発メンバーへ報告していました．
しかし，手動で報告していることや報告する途中で割り込みのタスクが入ったことで結果的に報告ができず，他のメンバーの作業が止まることが何回か目立ちました．
やったこと
Capistrano をデプロイツールとして採用していたこともあり，「capistrano-releases-notification」でデプロイ時に Slack で通知し，「capistrano-github-releases」で該当のプルリクエストに自動でリリース報告のコメントと Releases と Tags を自動生成するようにしました．Releases と Tags はリリースノートとして機能するので便利です．
それぞれの gem の使い方については，過去に記事を投稿したのでもし興味があれば見てもらえたらと思います．
リニューアル時の流れで使っている Git-flow
当時は develop ブランチを親ブランチとして開発をしていました．しかし切り戻しがあった時の作業の煩わしさや Git-Flow を続ける理由も現状の開発では特に無かったため GitHub フローにした方が効率が良さそうという思いが強くなっていきました．
やったこと
GitHub フローに変更しました．作業自体は develop ブランチと master ブランチに差分が無いことを確認した後に develop ブランチを削除するだけです．
後は開発フローが少し変更になるためそのメンテナンス作業すればOKでした．親ブランチを作りたい場合は，各自で適宜作成するようにしています．
どの改善でも共通で言えること
今振り返ると今回のイベントで発表したことは作業の難易度自体はそこまで難しくないものだと思いました．しかし，その中で苦労した点は改善に至るまでの議論です．
「○○にした方が良いんじゃね？」だけだと，改善を進めていくうちに生まれる懸念事項への解決が上手くできなかったり，開発メンバーが納得しないまま進めてします場合があります．
そのため改善を進めるには「そもそもの課題は何か」，「課題が解決されたらどんな状態になるのか」などを明確・整理することで懸念事項への解決や開発メンバーへの納得を得ながら進める必要があると感じました．
苦労した点と書きましたが，ここは時間を掛けて進めるべき内容だと思います．というかこの内容を発表の時にもっと話せば良かったと後悔してます😅．
まとめと所感
「マイナビ Tech Night #3」 で登壇しました．入社からイベント当日までの振り返りにもなったのでとても良かったです．完全ベンダーコントロールから内製開発への割合を増やすという段階なこともあり，GitHub の使い方や CI 環境の構築など今まで自分が Join したチームでは前提だったことをマイナビニュースでゼロから作り上げていくような経験をすることができました．
現在はスライドの後半にあるサーバーサイド，フロントエンド，インフラでやっていくことに取り組んでいるので，次回があればこれらの内容について発表できればと思っています．
今回のイベントや登壇資料がこれから内製・半内製開発をする上でどんなことが必要になるのかを検討している方達へ少しでも参考になればと思います（「内製開発へのシフト」がテーマのイベントがあったら登壇してみたい機運が高まりました）．
追記（2019/12/16）
「Geekroid」にてイベントレポートが公開されました．
