チームで対応するタスクはすべて、GitHubのIssueで管理

弊社ジェネックスソリューションズは、2013年の7月にできた会社です。「ClipLine（クリップライン）」というコミュニケーション・マネジメントの見える化を可能にする動画プラットフォームを提供しています。ベンチャーとはいっても、社員の年齢層が30代と比較高めで、落ち着いた感じの企業ですね。

私たちは、社内で発生するタスクを、全社的に「GitHub（ギットハブ）」で管理しています。具体的には、GitHubの「Issues（イシュー）」という、掲示板のような機能を使っています。

▼依頼されているタスクの例

例えば、コンサルティングメンバーがバックオフィスのメンバーに書類の送付をお願いしたい場合、Issuesの中で宛先と期限を打って、管理部宛に送る。そうするとその依頼がひとつのチケットのようになって、進捗などをどんどん書き加えていけます。

▼依頼・進捗しているissue

チャットとメーリングリストがあふれる…タスクの管理が限界！

GitHubを使い始めたときは、まだ10名ちょっとの組織だったのですが、会社が3拠点に分かれていて。すべてのやり取りは、チャットツールの「Chatwork（チャットワーク）」かメーリングリストで行うという状況でした。

当然、チャットもメーリングリストも、ものすごいスレッド数になっていました。「名刺100枚お願いします」っていうひと言で投げられた業務を、受け取る側も出した側も大量のスレッドの中に埋もれてしまう、とことが多々起こっていまして。

さらに、ナレッジの共有もできていませんでした。新しく入社した人が、名刺を誰に発注すればいいのか複数の人に聞く、ということがいつも始まってしまって。「何々さんじゃない？」「前はこうやってた」といった風に、口頭で伝わっていって…。そこがやはり、大きな課題のひとつでした。

そういった中で、まずは全員が関わるバックオフィスの業務をどうにか効率化しようと、1年ちょっと前に、「GitHub（ギットハブ）」の導入を決めました。

組織にエンジニアがいなかった中で、なぜGitHubを選んだのか？

色々なタスク管理ツールがある中で、「どうしてエンジニア向けのGitHub？」って、聞かれることもあります。しかも、もっと言うと、私たちがGitHubを導入したときは、社内にエンジニアもいなかったので、なおさら社内からは「なぜGitHubなのか？」と。

ただ実は、それで逆に導入しやすかった部分もあって。タスク管理のツールは世の中に色々とありますが、各所の要件を聞き出すと、なかなか導入が難しくなる事が多いですよね。その点、当時弊社にはエンジニアがいなかったので、細かい要件を聞く事無しに、一番伸びているサービスを使うのがベストだと思ったんです。（社内向けには、「GitHubを使っていないとエンジニアは採用できない」と説得しました）

そういった意味では、GitHubはもうどこでも使われているし、拡張性も一番ありますし。ある意味、いったんわからないまま使い始めてしまうっていうのも、ひとつありなのかなと思います。

いまでは社内で、いわゆるビジネスサイドであるコンサルチームを含めて、全員が使っています。基本的には、「依頼になるもの」「タスクが発生するもの」に関しては、すべてGitHubで管理していますね。お陰様で、狙い通りエンジニアの採用も無事出来ました！

まずは成果を！導入初期は、とにかく使うハードルを低く

最初は、まず導入して成果を見せないといけないと考えました。そこで、最初は管理部への依頼の窓口だけをGitHubに変えました。この形ですと、実質的に影響範囲は全員になるということですね。

例えば、それまではトイレットペーパーが切れても、誰も補充しなかった。でも、それを見つけた人がGitHub上でIssue化する形で、管理部に依頼を出す。すると自動的に、トイレットペーパーが用意される。そういった細かい体験を積み重ねるために、まずは使う範囲を管理部への依頼に絞りました。

とにかくシンプルにわかりやすく、複雑にならないように、入口をものすごく柔らかくしたんですね。簡単な内容の依頼が、テキストを打って、ボタンを押すだけでできるイメージです。

とはいえ、なかなか使えない、慣れない、という人もいましたね。そこで2ヶ月ほどは、チャットで依頼をされた側の管理部がGitHubでIssue化して、「今後はこちらで進捗管理します」という案内をしていました。

すると、その進捗がGitHubに上がるので、依頼した側もGitHubを自然と見るようになります。「いまどうなってる？」ということをいちいち聞かなくて済むので、非常にラクになりますよね。

それ以外ですと、勉強会を2回に分けて行い、さらに弊社が提供しているClipLineで動画マニュアル化して、GitHubの使い方を配置しました。

▼マニュアルの動画

リポジトリ、アサイニーの活用で、タスクをわかりやすく運用

現在では、管理部への依頼だけではなく、各部署でGitHubを活用しています。業務ごとに「リポジトリ」という箱のようなものを作って、目的別に分けて使っています。

例えば「このリポジトリはXXプロジェクト用」「インターン生への依頼用」といった形で決めて、関係者を招待して運用していますね。

▼リポジトリの使用例

GitHubでは、それぞれのIssueにアサイニー（依頼者）を設定できます。これは依頼者が決めることもありますし、例えば動画を制作するグラフィック部ですと、本当に多種多様の依頼が来るため、いったん部署で案件を受けて、その後グラフィック部の部長が誰が担当するかを決めて、GitHub上でアサインしています。

▼アサイニーの使用例（赤い矢印が指す部分がアサイニーのアイコン）

業務の抜け漏れがなくなり、会議時間の短縮にも成功！

GitHubを導入した成果として、まずは業務の抜け漏れがほとんどなくなりました。GitHub上に必ず何かしら履歴が残っているので、何がどこで止まったのかもわかりますし、あとで課題を振り返ることもできるようになりました。

さらに、定例会議の無駄な時間を削減することができるようになりました。例えば管理部ですと、週次でIssue（アジェンダ）を棚卸しし、ひとつひとつについて議論しています。そして、終わっているものはどんどんクローズしていくので、だらだらしないんですね。30分もかからず、確認を終わらせることができます。

また、現在は弊社にもエンジニアがいるのですが、彼らにとっても使いやすいツールなのはいいですよね。よく他の会社で、エンジニアとバックオフィスのコミュニケーションがうまくいかないという話も聞くので…。その点はGitHubがあってありがたいな、と思っています。

ちなみにGitHubは、モバイルでも見ることができます。ちょっと使いづらいですが、外に出ているメンバーが、移動中にスマホからIssueを書いたり、ということができるのは良いですね。

今後は、外部サービスも活用し、より細かい運用を

現在、全社的にGitHubを運用できるようにはなってきたので、これからもう少し細かく使い込んでいこうとしているところです。

例えば、各Issueに「ラベル」を付与する機能があるんですね。いまはそれをタスクの重要度の重み付けくらいにしか使えていないので、もう少し活用していきたいです。

▼ラベルの使用例

また、社内で動画を制作するグラフィック部では、GitHubの拡張性の高さを活かして、「ZenHub（ゼンハブ）」というツールと連携させています。

▼ZenHubの使用例

ZenHubのいいところは、タスクをひとつのボード上で、ステータスごとに管理できることです。このIssueは未着手、これは実行中、といった風に分けられるので、グラフィック部では毎朝10分ほど時間をとって、Zenhubをチェックすることで、各メンバーの業務を確認しています。

また、ZenHubの機能で「エピック」というものがあります。複数のIssueをまとめて、関連するものをグループ化できるというものです。

▼エピックの使用例

例えば「新規クライアントさんへのサービス導入」という業務であれば、その工程は18に分けて定型化できます。その工程のIssueをグループ化すると、わかりやすいですよね。このように、業務を1回テンプレ化するということを、いま実験的にやってみています。

今後の課題としては、社内のチャットツールとGitHubをより連携させるような仕組みに変えていくことと、もう少しルールを整備したいです。やはり最初のハードルを低くしたことで、例えば役割がかぶるレポジトリが複数立ち上がっているような状態も見受けられるので。そのあたりを改善し、今後もより一層、GitHubを活用していきたいと思います。 （了）