backlog上で案件・進捗管理をしていた自分がGithubに触れてみた感想

転職してから業務管理ツールをサイボウズ（勤怠が主だったけど）→backlog に変わってずっと進捗管理をそこで行ってきた。２年くらいになるけど、Redmine とかには触れないでも、方向性とかやり方を模索しながらうまいこと立ち回ってきたように感じる。

そんな中こないだより弊社でも backlog では案件自体の管理、Github 上で修正・ソース管理を分割していこうという流れが出来てきて実質２案件くらいの開発案件では行っている。自分も１つ案件に入ってきたので Github 上で仕事している。そんな中で思ったこととか感想とかを書き綴ってみるなど。

案件の可視化に関しては圧倒的に backlog 優位

見やすさとか検索のしやすさであれば圧倒的に backlog かなと思った。そりゃ案件管理ツールと Git 連携サービスとを比較するのであれば酷なのではあるが、ガントチャートを見たり案件内でどのような課題が作られているか・進行しているか、などのディレクター、マネージャー、エンジニア、デザイナーなどの全員が案件の動きを見る面ではかなり強いなものなのだと感じる。

Github 上でもマイルストーンや Issue を作ってあげたり Wiki で詳細を書いてあげたり、backlog 同様に１つのプロジェクト内で案件管理することは不可能なことではないしうまくやれる方法は模索できるとは思うが、それ相応の準備（勉強）とかがいると思うので、Github を使って案件管理をしよう！　というよく分かってない浅はかな思考をもつエンジニア・ディレクターが居たら首を締めてあげるのが人情というものです。

あと自分は Git の履歴を見る上でネットワークで図示されたのを見るので backlog のは割と分かりやすくてよいのだけれど、Github はそこに行き着くまでが若干分かりづらいかなとも思った。見れるには見れるんだけど。

逆行して考える力の必要性

新しい案件が走る場合、まず要件定義なり客の要望などをしっかりと固めてあげて、そこからどのようなものを作るかを明らかにするものだけど、それを完成するに辺り何が必要なのか、何をもってして完了と言えるのか、という部分を明確にしなければならない、というのが Github でプロジェクトを進行していてわかった・感じたことだった。

Github では Issue（課題）を立ててどのような機能を作っていくか・作ったときに出たバグを潰すかというのがあるが、Github の仕様上、立てた Issue はClose こそできるが完全に削除できない（消すにはプロジェクト自体を削除するとかになる）のでバカスカバカスカ立てても結局精査する時間もあるので、Issue を立てるのは慎重にやる必要があると思う。

つまり課題を立てる上で、何をもってそれをプロジェクトやバグ修正の完結に向わせるか、それを完結させるために用いるものがあるとしたら何かということを考えてものを作るのが進行管理者でも作業者でも求められることなのではないかなと感じた（全員が全員できるようになれという話ではない）。

あと Issue 立てる時にテンプレみたいなのも設定できるので、活用していくと良さげ。

Manually creating a single issue template for your repository - GitHub Help

CI ツールと連携できる強さ

backlog には無い機能として、CI ツールとの連携が Github にはある。Travis CI とか Circle CI とかで自動テストとかデブロイをやってくれるのが凄まじい。これは正直自分のプライベートプロジェクトでは試してなかったので勉強になった。

連携自体は割と簡単で各サービスにサインアップしてプロジェクトを連結させるだけ。あとは設定ファイル（.yml とか）を弄って push して自動で走らすなどしておけば、コミットログの横にチェックマークが出てちゃんと出来てますよーという確認ができる。

コード品質管理をどうするかということでテストなどを走らせるというのがあり、今までだとこうした連携がなかったので、厳密なものは自社のガイドライン遵守でコード内容が守られているかとかを目測確認したり、そこまででなかったら結構省略することもあったので、PullRequest よろしくレビュー文化みたいなのをやっていく上でも、こうした指標は便利かなと感じた。

作業の進行上、どうしても WIP 的なものであってそれらもチェック走るなどのめんどくささもあるが、一応スキップする機能はあるみたいなので（Circle Ci だと[ci skip]ってコミットメッセージに打てば走らない）内容に合わせて送るようにすれば問題なさそう。

芝が濃くなる嬉しさ

backlog と関係ない完全に私的な内容だけど、芝（＝ Contributions）が濃くなるのは単純に嬉しい。個人開発をやれている人なら毎日濃くはなるだろうけど、実際問題なかなか芝を濃くしていくのは難しいと思う。通常業務であれば backlog のプロジェクト上で結構頻繁に push 作業をしているので（跨いでるプロジェクトが多いのもあるけど）、自分の芝はもっと濃かったのではないかと思っちゃう。

もちろん Contribution activity とかをしっかり見れば何をしていたかは分かるのだけれど一見のインパクトというものは凄いなとも感じるところ。あとはモチベ維持につながるとかかな。

ようやく本業でも Github を利用し始めて、個人で使う分では色々と見えなかった部分が見えてきて楽しくなってきたところではある。自分のプライベートリポジトリもいい感じにできそうだなというのも分かってきたので業務と合わせてうまく活用していきたいなーなど。

そんな感じで、こちらからは以上です。