YAPC::Asia Tokyo 2015×gihyo.jpコラボ企画 ― YAPC::Asia Tokyo 2015の作り方

第1回 コミュニケーション編

この記事を読むのに必要な時間:およそ 4 分

Slack

まずは「会話」部分を担うツールを考えました。いくら非同期でのコミュニケーションが前提でもやはり会話は必要です。そこでIRCに近い感覚のツールを導入したかったのですが,今回はSlackがちょうど登場してきたタイミングであったのでSlackの導入を決めました。

Slackは以下のような特徴があり,導入直後からぴたりとはまりました。

  • 比較的導入が簡単
  • 非エンジニアにとっても使用方法がわかりやすい
  • スマートフォンからの利用方法もわかりやすい
  • Integrationを使う事によって他サービスとの連携が容易

特に非エンジニアにとって使用方法がわかりやすいと言うのは重要なポイントでした。我々のチームには全くプログラミング・エンジニアリングとは関係ないメンバーもいるので,彼らが気持ちよく使えるツールが必要でした。

このように便利なツールなのですが,ありがちな運用として各プロジェクトごとに小さななチャンネル(Slackにおけるチャットルームのようなもの)を作って必要な人だけ各チャンネルに参加するという形になることが多々あります。これはメーリングリストと同じような運用方法ですが,これをするとどのチャンネルでどのような情報のやり取りが行われているのか把握しづらくなり,少人数チームの会話ツールとしての魅力が半減してしまいます。特にプライベートチャンネル(特定の人だけが入れる承認制のチャンネル)を使い始めると情報を得られる人と得られない人と差が出てき始めるのでそのような状態だけはどうしても避けたい気持ちがありました。前にも書いた通りSlackはあくまでオープンな「会話」のミディアムとして使いたかったのです。

そこであくまでチームメンバー同士の会話を重視した使い方をするために,Slackのチャンネルは以下のように限定しました。

  • #generalチャンネルで真面目なアナウンスメントや議論等を行う
  • #randomチャンネルでどんなくだらない話でも良いので常に雑談を行う

図2 Slack

図2 Slack

#generalチャンネルは重要事項やTODO的なものがポストされるので必ず確認してもらいます。ただし重要事項の伝達のみに限ってコミュニケーションを行うと逆にそれ以外の何も伝わらず,結果一緒にチームに参加しているお互いの事が何もわからず本番を迎えてしまいそうだったので,別チャンネルを用意することにしました。

#randomチャンネルはディスカッションにも使いますが,基本用途はチームビルディングのためです。雑談は直接イベント運営には関係ありませんが,他のスタッフがどういう人なのか,どういう事に興味があるのか,どういうことが得意なのかを知ってもらうために利用しています。これによりリモート・非同期で活動しているチームメンバー同士が働きやすいようになります。また#randomチャンネルは雑談をするためのチャンネルですので,特に用がなければ無視してもよいチャンネルとなっています。

基本全ての会話はこのSlackに2つのチャンネルを通して行われます。もちろん会話は流れてしまいますのでTODO管理等はSlackではできませんのが,Slackでの会話から始まり他のツールでそれ以外のコミュニケーションを行います。

GitHub

Slackは会話するには素晴らしいのですが,やはりログが流れてしまうと困る事は多々あります。そのような用途にはGitHubを使っています。GitHubでプライベートレポジトリを作成して,そこで「週報」「TODO」の管理をしています。

まず定期的にタスクの棚卸しをしないとマネージャー役の筆者が現在どのようなタスクが残っているのかわからなくなるので週報を毎週書いています。

週報は毎週月曜に自動的にひな形が作成され,レポジトリにコミットされます。レポジトリへのプッシュはSlackに通知されますので,これが到着したら週報書き開始の合図です。週報は正直筆者も大嫌いなのですが,この週報を強制的に書かされる事により自分が今持っているタスクの洗い出しを行う事ができるのと,ポイントポイントでの状態を後で見られるのが良いと考えています。週報には簡単な箇条書き程度で「やったこと」⁠やること」⁠問題点」があれば書きます。

図3 週報は自動的に生成されないとなかなか続ける気がしません

図3 週報は自動的に生成されないとなかなか続ける気がしません

GitHubにはこれの他,issueを使ってTODO管理を行います。これは皆様の想像通りで,エンジニアリングプロジェクトを進めるのと同じように担当者を決めて進捗確認をして,タスクが終了すれば該当issueはクローズします。

図4 Issue管理

図4 Issue管理

Google Drive

Slack・GitHubで進めた事項をまとめた物や,予算管理等のスプレッドシート的なツールが必要なもの,スタッフ以外にもシェアするドキュメントなどはGoogle Driveで管理・共有しています。

こちらの運用はシンプルで,ドライブ内にスタッフ全員に共有するフォルダを作り,その中に全てのドキュメントを保存するだけです。一旦共有フォルダを作ってしまえばあとはその中のドキュメントは全てスタッフに見えるので,あとは特に考える必要はありません。

Google Driveがさらに便利な点はスポンサー企業等に送る資料も「URLを知っている人に公開する」設定にしておけば「世界中の人に丸見えは嫌だけど別にそこまで秘密でもない情報」を配布する際の絶妙なアクセス管理を行う事ができることです。今回全ての配付資料はこの仕組みを使いました。

著者プロフィール

牧大輔(まきだいすけ)

オープンソース技術を使ったシステム開発をメインに,講師,執筆活動などを行う。2011年,Perlコミュニティに多大な貢献をもたらした人物に贈られるWhite Camel Awardを受賞。本業の傍ら2009年からのほぼ全てのYAPC::Asia Tokyoで主催をつとめ,その中で現運営母体のJapan Perl Associationも設立。LINE等を経て現在HDE, Inc.勤務。