#githubkaigiに参加をしてきました。
Githubの中の人も招いて、Githubユーザー同士で交流をする勉強会、Githubkaigに参加をしてきました。！
主催の id:naoya さん、会場提供のサイバーエージェントさん、そしてGithub社の方々、スピーカーの方々、ためになって楽しい時間と情報を本当にありがとうございました！！
よく、「ブログに書くまでが勉強会」と言われるように参加してきたことを自分の言葉でまとめ、アウトプットをして初めて自分の勉強会は終わりを迎えます。つまり、この記事を以って俺のgithubkaigiは終わりです。正直、ちょっと勿体無い。もっと咀嚼したい気もする。でも、今のこの気持をアウトプットしたい思いの方が強いので、俺のgithubkaigiを終わらせます。
弊社における問題点
今回話題にするのは、 情報共有が上手くない 点。技術的な情報だけではなく、案件に関する情報、あるいは契約に関する情報などに関して属人性が高いように感じます。もちろん、情報共有の手段はアリます。それは、
- 朝礼、終礼での進捗報告
- ドキュメント
- 社内勉強会
と言った物。しかし、特に朝礼、終礼って目的を果たしてるのかな？と思うところがあります。
手段が目的と化した世界で
進捗報告はよくあるやつだと思います。自分が受け持っているタスクの状況、今日やること、やったことを手短にまとめて発表します。でも、考えてみてください。自分とは関係の無い案件に携わっている事柄を聞いて理解できますか？聞いたことのないお客さんの名前、システムの名前、毎日やりとりをしているとある程度いは覚えますが、それでもある程度、よくわかんないママに放置する。そんな毎日です。
少なくとも俺は。
情報共有の目的とは
いくつかあると思いますが、例えば「属人性を下げる」ことがあると思います。例えば、俺が作っているシステムに障害が発生した祭に偶然俺がインフルエンザとかで寝込んだら？そのあたりの属人性によるリスクの削減が目的のハズ。
朝礼や終礼での進捗報告やドキュメントでそれは満たせるのでしょうか？俺は、不十分だと思ってます。
- 朝礼、終礼
- 自分の携わっていないタスクに対しての知識の補強が足りない
- ドキュメント
- いわゆる外部設計や仕様については把握できるが、詳細な実装に結びつけるためにはコストがかかる
と言った理由から。
そして俺たちはPRを投げる
この本のでは序盤からPull Requestについて丁寧に説明されている。そして、今日の登壇者の中には著者の@HIROCASTERさんもいらした。
やってみようと思ったことが一つある。それは、プロジェクトを超えたPull Requestの実施だ。
Pull Requestを、プロジェクトに携わっていない人に投げる、これは弊社では全く新しい試みだと思う。考えられるメリット、デメリットをリストにすると
- メリット
- 実装レベルでの情報共有ができる
- 他の人が何をやっているのかが分かる
- 他のプロジェクトの進捗がわかる
- 技術的知識の共有
- デメリット
- セキュリティ上のリスク
- 人月計算における、工数の算出の複雑化
- 受託案件における契約の破綻
こう書くとデメリットでかい気がする。特に受託案件においては。でも、少なくとも今のチームの運営では問題があるし、ルールによってそれを改善できるのならするべき。「意識を改めます！」なんて言っても改まらないのは経験上わかっているので、ルールを決めてツールでサポートして、習慣化するべき。
追記
まあ、「明日やります！！」って言って簡単にできることじゃないハズ。ただ、検討するべき事項。
あした、なに着て生きていく？
少なくとも今日とは違う自分、環境。
