やまろぐはてな

yamanokuの技術メモとか戯言。真面目に見たり見なかったりしてください

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

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

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

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

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

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

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

f:id:cardboarder:20170918011956g:plain

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

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

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

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

あとIssue立てる時にテンプレみたいなのも設定できるので、活用していくと良さげ。 Creating an issue template for your repository - User Documentation

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

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

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

gyazo.com

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

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

芝が濃くなる嬉しさ

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

gyazo.com

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


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

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