やまろぐはてな

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

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

コミットメッセージとコミットの粒度について思ったこと

medium.com

見た。以下思ったことです。


コミットメッセージが結構雑になる問題ってのは、自分が考える中としてコミットの粒度が割とデカい場合になるんじゃないかなと思ってる。

例えば数ページマークアップしたときに、ページごとにコミットを切るよりかは、全ページの作業をコミットさせておく方が分かりやすいし、どこまでの進捗なのかも一見しやすいかなと思う。もちろんページ内で機能が複雑化している場合はその限りではないと思うけど。

なのでコミットのメッセージを分かりやすく書く、ということと同時にコミットの粒度をどれほどのものにするか、という意識と進め方を持たないとこの辺はなりたたないのではないかなーと個人的に感じている。

基本業務の流れとして、バグや機能追加の課題が振られてそれらを対応完了するまでを1コミットとしているけど、LPなどページ単位で対応するときは、場合によっては、1ページ単位でコミットを切ることがある。

あと良くない癖なので直さなきゃなんだけど、その日に対応する修正もまとめて対応して「00/00対応分修正コミット」とかで切って細かく書かなかったりもする。修正範囲の意義を全体的なものとして捉えていると、修正する1機能というよりかはそれに付随するもとしてまとめて対応しないと、という意識になっちゃうのでその辺は進行管理とも付随する問題かなと感じる。

この辺の粒度対策としては、ブランチをいかに細かく切って作業するかにかかってるんじゃないかと思うので手を動かす前にまずブランチ切っとけ、終わったらマージしとけを工程の中に入れておかんと危ないなとは感じた。まあもし単位がデカくなってもやり直しが一応できるのがGitの良いところではあるけど、出来る限りそういう修正はしたくないよね、と。

課題の建て方としてもそうだけど個人としては、もう少し部品化・機能化するイメージで進めてみてもいいかなと感じた。この辺は実験として新規のプロジェクトとか、個人がメインで動いていたプロジェクトにもっかいアサインしたら試してみようかなと思ってる。誰かとやるんであればその時のルールには従います。

余談

昔、コミットの内容なんか見なくてもファイルの内容みればどうなったか分かるだろみたいな言説を聞いて、当時はまあそうだよなと思ったけど、結局属人性を加速させかねない危険な発言だったと徐々に分かってきて、1回限りではない・他人の手にも渡るリポジトリ内では、出来る限りは詳細的に書くように努めたいと思ってる。

こちらからは以上です。

PostCSSの雑感

f:id:cardboarder:20170806221911j:plain

業務で実験的に使ってみたんですが、

まだこの気持ちが強い。とりあえず1プロジェクト終えた後にちゃんとした感想やります。

ただこういうのがプラグインであるのは感動した。

github.com

以上雑日記でした。こちらからは以上です。プラグインの翻訳記事とかつくれば価値出ますかね?

記事を書くときに気をつけること

自分が所属している会社もこないだからQiita Organizationに参加して各自記事をアップしたりしています

qiita.com

こういうところに書くのも日々のモチベや多忙さに左右されるので継続は難しいなと感じるところですが、記事を共有するというのは慣れていないとどうも参入障壁がデカい気がします(いわゆるアウトプットが慣れてない場合)

そんな訳で少しでも参入障壁や苦手意識を取っ払うために自分の中で記事を共有するときに念頭においてることを以下書いてみます

重複する内容じゃないか

これは当たり前ですが既に世に出ているものでそれが十分だったらそれでいい訳です。いわゆる新規性がまったくない場合

もし間違ってたりアップデートしている内容があったら編集リクエストなり指摘を入れればよくて(直すかどうかはおいておき)、わざわざ自分が書くことはないと思います。それでも残したいならメモ帳にでも書いとけ

既存のものを組み合わてみる

もしかしたら大半のことは上記のことで弾かれてしまうと思いますが、別にそれは単一の内容だから被ってしまうのではと思います

いわゆる「点と点をつなげたもの」を調べてみるといいです

例えばバグをみつけて改修するときに、それに基づく情報やtipsがあったとして、そこに行き着くまでに試したことやダメだったことは一つの財産たるわけです

簡単に直せることはもちろん大事ですが、そこに行き着くまでのプロセスや何故こうしたらできたのか、ということを知ることが一番大切です。

そうした結果に行き着くまでのいくつもの点をつなげてみると、より洗練されたものになるのではないでしょうか

qiita.com

日本語情報があるか

ここら辺は有志がwikiなりしかるべき場所にまとめたりしてますが、無かったら書くに値するかなと感じます

少なくとも検索かけて1、2ページに有効な手や翻訳記事がなかったら共有する価値は十分あるかなと思います

結構プロジェクトによっては、とあるバージョンのまま日本語記事が書かれていない場合もあったりします。

qiita.com

実際に試した内容か

正直tipsをこういうのがあるよ!と言って書いたりすることもありますが、ブラウザの互換性やバージョン、バグらへんを完全に無視したものもあったりしてそれはノイズとなんら違わないです

なので実際にやってみた雑感なり、ここを対応するときは注意みたいなことを追加で書いておくだけでだいぶ優しい記事になりえると思います

試した結果とかはjsfiddleとかcodepenとか実際のプロジェクトに置いて各自で試してもらうなど、形として残しておくとなお良いかと思います

qiita.com

試した・変えてみたことがどうなったか

色々な実験や改善策、アップデートが日々行われているとは思いますが、そうした試してみた結果、どういう現状になったかというのは一つのネタになり得ます

もちろん上手くいくことがすべてではなく、失敗して共有すらできないこともあるかと思いますが、できる限り咀嚼してみて同じ轍を踏まないようにしてあげる(たとえ届かなくても)のも、業界全体を良くすることだと思えば価値はあるかなと思います

yamanoku.hatenablog.com

yamanoku.hatenablog.com

個人でやってみたこと、社内で試したこと

ここら辺は場合によっては書ける書けないの領域もあるかとは思いますが、ネタとしては使えるものもあったりします

たとえば「社内でこうしたツールを使ってみたけどもっと使いやすくしてみた」「オレオレ設定だけど意外と人に使われてるよ」「みんなこうやってるけど自分はこんなパターンで試した」など、その人、その企業ごとで独自性をもったものになり得ると思います

yamanoku.hatenablog.com

この辺は宣伝にもなりそうなんでQiitaなり諸般の場所で書くのは程度問題にはなりますが、個人ブログや企業ブログに書いてみるというのもありかもしれません。それが結果として興味を持ってもらえる材料にもなるので

ゆるく書く意識

最後に一番重視していることとして、ゆるくやるということを忘れないようにしています

こんなに気をつけておいてゆるくって何でやねんってのはあると感じるかもですが、その辺と力みすぎてしまうのは別物だと思います

対人が見るものだから粗相のない文章を、と力むよりも、見た人がなるほどなとか、わかるわ〜と共感してくれるような語りかけ調で見てくれるのがいいよねと感じてます

あとは勢いにまかせて一気にやると良いです

 

そんなわけで自分が記事を書く時に意識していることたちでした。大したものを書いているわけではないですが、みんなでゆるく知見を広げていこうぜよ。

こちらからは以上です。

 

合わせて読みたい

yamanoku.hatenablog.com

書いた記事をアップデートすること

qiita.com

この記事を書いて早いもので1年経った。CSSプロパティの記述順に関してはひとつの解決の足掛けにはなれたのではないかと思っていたけれど1年たった今では記述順よりも煩わしいコンポーネント管理問題や他人とどうCSSを弄ればいいかなど悩みは尽きない。そんな記事を書いていたことも忘れかけていた中で最近ふと気にかかった言葉がある。

技術記事ってだいたい書いた当時の情報からアップデートされないよね

まあだいたいはその通りであるというか、記事に直近の追記以外でこのプラグインやら記述はもう使えませんよみたいなのって本当に丁寧な記事以外では全く見かけないしQiitaでもそんなにはないんじゃないのかーという感じではあるわけです。

これは俺がフロントエンド界隈にいる限りなのか、それとも単に手前の視野が狭いだけなのかというのは分かりませんが、少なくとも自分の界隈はそういったもんだと思っています。

別に記事なんて公式ドキュメントではないんだし、いちボンクラが書いたものをいちいち更新しなきゃいかんのかというのもダルい話ではある。でも、そんなボンクラが書いたような記事でも必要な人はそれを頼って見に来ることもある。どこの誰かは知らないけれども。そう思った時に自分は必要な人間側になった時にどう思うかというと多少なりともアップデートはしていてほしいなという気持ちにはなる。

そもそもがインターネットのものはアーカイブもできて、上書きできるものであるという前提を見失っていた気はします。

これは別にQiitaに寄稿した記事に限らずこのブログもそうだし、果てはGithubのドキュメントや社内のwikiやら議事録に至る何までどこの誰がどういう探索をしに来るかは知らんけども、今一度あの時書いたもの、作ったものを見直してみるのはどうかという感じにはなってきているそんな今日のこのごろです。