エンジニアのツールだと思われていたGitHubを組織全体でどうやって使うようにしたのでしょうか？ 21日に都内で行われたイベント「Cookpad TechConf 2017」のセッション「組織全体でGitHubを使うようになるまで」で紹介されたその内容を、ダイジェストでまとめました。

組織全体でGitHubを使うようになるまで

　長俊祐（おさ しゅんすけ）と申します。Webアプリケーションを普段は書いています。

　クックパッドでは子会社で「クックパッド料理教室」というのをやっていて、私はそこでサービス開発をやっています。


　「クックパッド料理教室」は、簡単に言うと町中の料理教室をWebで予約できるというサービスです。

　料理でレシピは大事なのですが、レシピだけでは伝えられないこともいっぱいあって、例えば文章にするのが難しいコツであるとか、作っている過程で経験する味見とか。クックパッド料理教室はそういうインターネットでは伝えられない知識や体験を先生たちから習うことができる、そういったサービスです。

　今日お話するのは、エンジニアではない人たちも含めて組織全員でGitHubを使う、という選択をした経緯と、実際に導入するときにぶつかった壁と、その壁の向こうにあったもの、といったことです。

口頭のコミュニケーションでは記録も残らず作業への割り込みもある

　クックパッド料理教室は、メンバーとしてはエンジニア、デザイナー、ディレクター、そしてユーザーサポートの人とか、教室を増やすための営業の人、そして自分たちでも教室をやっているので、そこの運営の人や講師だったりと、エンジニア以外にもいろんなメンバーがいます。


　なので以前は口頭でのコミュニケーションが多かったんですね。例えばユーザーサポートの人から問題がエンジニアにあがってくるときも、「いまちょっといいですか？」と声をかけて、それを聞いてエンジニアがGitHubのIssueをたてる。そこから調査をして必要ならバグを修正して、「あれ、直りましたよ」と返答する、みたいなコミュニケーションをしていました。

　ただこうすると記録が残らないので「これってそもそもどういう問題だったんだっけ？」とか、会話するたびに作業が中断されてしまうとか、会話のために相手の作業に割り込むのが気が引けてコミュニケーションが減ってしまう、といった問題がありました。

　これを解決するために、「みんなでGitHubを使ってみよう」という選択をしました。


　なぜかというと、開発チームはそれまでにもGitHubを使って開発をしていたんですね。そのときの実感として、GitHubのIssuieが便利だと。だったら、これをみんなで使ってみたらいいんじゃないか、そういう素朴な感想で使い始めました。

問題をGitHubのIssueとして落とし込む方法が分からない

　ただ、やはり使おうとすると問題というか、立ちはだかる壁があるんですね。

　それは単純に新しいツールだから「使い方が分からない」とか、間違ったことを書くと怒られそうで「怖い」とか、心理的な障壁が壁としてありました。

　1つ目の、「使い方が分からない」に関しては、単純なんですが説明会をしました。