ヘルスケア事業部の濱田です。チームで楽しく開発してますか？ コードベースの置き場として絶大な支持を集める GitHub。コードを管理するだけでなく、issue を使って様々な議論や報告を行い、その結果をスムーズに製品に反映させることができます。エンジニアだけでなく他の職種のメンバも巻き込んで GitHub で議論ができたら、開発はもっと活発になるでしょう。
一方、 GitHub にはちょっと敷居が高い、敬遠したくなるような雰囲気を感じる人も多いようです。 本記事では、様々な職種のメンバが GitHub を気持ちよく使い始めてもらうにはどうすればよいか、という観点から気をつけるべきことを紹介します。
GitHub は非エンジニアにとっては怖い場所？
エンジニアは GitHub が大好きです。自分たちの作ったコードがあり、ドキュメントがあり、仲間がおり、コードレビューを通じて自分の新たに作った価値が承認される場所です。金曜日の夜に今週のコミット数を眺めてニヤニヤしているエンジニアはきっと多いはずです。
一方、非エンジニアにとってはどうでしょうか。ヘルスケア事業部には多くの職種のメンバが在籍しています（ディレクタ、デザイナ、営業、渉外係、そしてレシピの栄養調整などを担当する管理栄養士等）。議論の場を GitHub へ移そうとした際に尋ねてみたところ、開発に GitHub (Enterprise) が使われていること自体は多くのメンバに知られていましたが、その印象はあまりポジティブなものではありませんでした。
- そもそもどういうツールなのかわからない
- エンジニアがいっぱいいる = 専門的
- 不用意なことをすると怒られそう
印象的だったのは、「GitHub って怖い」という言葉を使った人がいたことです。GitHub が怖い、という言葉の裏には、ツールのとっつきにくさに加えてそこにいるエンジニアが怖いという意味が含まれているんですよね。気持よく使ってもらえるように、いろいろな工夫をして歩み寄っていきましょう。
はじめに時間を取って不安をほぐす
GitHub を使い始めてもらうにあたって、まずはじめに一度説明の時間をとりましょう。 メンバの机のそばに行ってやってもいいですし、人数が複数人いるならミーティングルームで一気にやってしまってもいいでしょう。会話しながらなるべくカジュアルにやるのがポイントです。
まずは issue の使い方だけ覚えてもらう
慣れてしまうと忘れがちですが、GitHub のコンセプトって結構難しいです。 リポジトリがあって、issue が立てられて、pullrequest というコードへの変更の依頼があって、マージして……と、いろんな要素がありますよね。
すべてを説明するには情報量が多すぎるので、まずはコードを直接触らないメンバが一番良く使うであろう issue の機能に絞って説明を行います。このとき、一緒に操作をしながら issue を作る練習をすると良いです。以下のようなポイントを押さえてもらいましょう。
- issue は掲示板のスレッドや、Facebook の投稿みたいなもの
- 投稿にはメンバがコメントを付けていける
- 製品のバグ報告や質問など、トピックごとに issue を立ててほしい
- 議論がまとまったら、close ボタンを押して issue を一覧から消しておく
書き始めるのを容易に
作り方がわかっても、それだけでたくさんの issue が立ててもらえることはまずありません。どんなときに立てたらいいか、description になにを書けばいいか等、迷うことが多いのが原因のひとつです。気軽に issue を書けるよう、レールを敷いておきましょう。
トピックのパターンを分類し、テンプレート化
issue のトピックには以下のような典型的なパターンがあります。
- バグ報告
- 機能要望
- 議論／質問
- 実装依頼
パターンごとに必ず書いておいたほうが良いことはある程度決まっている事が多いため、それらを書き出してテンプレートに含めておきます。こうしておくことで抜け漏れも出にくくなり、不備を指摘される可能性も減るため、issue 作成に慣れていない場合でも気が楽です。
issue のタイトルやラベルの付け方等もただ真似すれば済むように、本番を模した issue にしておくのがお勧めです。バグ報告用のテンプレートであれば以下のようになります。
issue の雰囲気を和らげる
エンジニアは職業柄、正確性や客観性を重視した言葉遣いを好む傾向にあります。
認識の食い違い防止や簡潔さのため、GitHub 上でもできるだけそうすべきだと思いますが、時に難しくて近寄りがたい雰囲気が出てしまうのも事実。様々な職種の人が書き込むような issue では、以下のような点に少し気をつけるだけで、グッと発言しやすい場になるはずです。
なるべく早く反応を返す
「ありがとうございます、見ます！」の一言でも良いです。慣れないメンバは、「この聞き方で合ってるかな……？」「見てもらえてるかな？」等、issue 1つ立てるごとにドキドキしていたりします（はじめてネット掲示板に書き込んだ頃のことを思い出してください）。単純なことのようですが、はじめの一言が返ってくるだけで安心できます。
ポジティブなコメントを忘れない
コードレビュー等で記述の不備や疑問点を探すのに慣れているせいか、修正すべき点に言及するのに集中するあまり、良い点を褒めるのを忘れがちです。
わかりやすいディスクリプションを書いてもらえたり、早いレスポンスがもらえたりしたら、ありがとう、いいねという気持ちを積極的に伝えましょう。
絵文字を積極的に使う
文字だけのコミュニケーションではどうしても発言がきつい印象になってしまいがちです。ニュアンスの補足に絵文字を意識的に使っていきましょう。例として、以下に特によく使う絵文字を挙げておきます。
| name | ||
|---|---|---|
 | :thumbsup::clap: | よいね、などのニュアンスを加えたいときによく使われます。:thumbsup:だとちょっとカジュアルすぎるかな、というときは :clap:が使われている印象です。 |
 | :bow: | 見た目のとおり、申し訳ない気持ちを表現する時に使われます。お辞儀というよりは土下座に近い絵面なのですが、意外と他に代替のきくものがありません。 |
 | :pray: | なにか作業依頼をするとき、お願いします！という意味を込めて使われます。祈りというか、柏手ですね。 |
 | :ok_hand::ok_woman: | 「了解」の意味で文の後に置かれます。単体でもよく使われます。 |
改善された製品を見てもらう
自分発の疑問や提案、報告を元にした変更が製品に反映されるのは嬉しいものです。
直接開発に携わっている実感を持ってもらうために、リリースしたらスクリーンショットを貼ったり URL を伝えたりして、あなたのアクションが改善につながったよ、とアピールしましょう。
文化を共有する - LGTM 画像で楽しく祝福
ある程度 GitHub に慣れてきたメンバには、ソーシャルコーディングならではの文化を少しだけ紹介するのがお勧めです。共有できる文化があると、コミュニケーションの潤滑油となってスムーズに開発が進みます。
例えば、「OK だと思います！」という意味を込めて LGTM (Looks Good To Me) と書き込む習慣がありますが、ヘルスケア事業部ではメンバのスナップ写真などを加工して LGTM 画像を作成し、ここぞというところで issue に貼り付けて楽しく祝福をしています。最近ではエンジニア以外からも「それ LGTM 画像にしよう」のような声も聞こえるようになりました。
一度遠ざかっても、また戻ってこられるように
こうして慣れてくれたメンバでも、ちょっと別の仕事に離れるなどして GitHub から遠ざかると、再び使いはじめる際に高いハードルを感じるそうです。
議論の最中など、良いタイミングがあればすかさずメンションを飛ばしてあげて、「どう思いますか」などと話を振ると自然な流れで戻って来られてよいでしょう。
まとめ
いかがでしょうか。メンバの多様性が高いほど、製品を改善する視点の数も多くなります。なんとなく GitHub 怖いな、で議論に参加しない人が多かったとしたら、それはものすごくもったいないことです。
ヘルスケア事業部では、多くのメンバに GitHub 上での開発に直接加わってもらったことでたくさんの製品改善のアイデアを得ることができました。他にも様々な工夫をして、GitHub を「怖くない、楽しく開発できる場所」にしていきたいと思います。