週1参戦要員tbpgr（てぃーびー）です。
クリエイターズネクストでは非同期・リモートの開発への工夫を少しずつ行っています。
今回はその過程をまとめます。

目次

1. 前提
2. 共通編
3. チャット編
4. Issue編
5. esa編

1. 前提

クリエイターズネクストで現在私が参画しているプロジェクトには以下の様な特徴があります。

・外部の開発者さんとの非同期連携が必要
・外部の開発者さんの中には遠隔地におり、対面のミーティングを実施することができない方もいる
・各メンバーは同じ時間帯に作業しているとは限らない
・社内のメンバーは毎日出勤しているわけではない
　・例えば
　　・メンバーAは月水金の定時
　　・メンバーBは水金の定時
　　・私は金曜日の定時
・重要な仕様の最終判断者である社長窪田は常時社内に居るわけではない
　・リモートでチャットやIssueを確認することは可能

つまり、チームメンバーが常に近くにいてちょっとしたコミュニケーションのずれを
対面で補正できる状態ではありません。
複雑な要件などに関するやりとりをする場合は必要に応じて、Skypeや電話によるコミュニケーションを選択することは
できますが、同期が必要なためこういった箇所の情報確認がクリティカル・パスになりがちです。

本当に必要な場面ではSkypeや電話によるコミュニケーションも必要ですが、
チャットやIssueなどの情報記載不足によるものであれば、
記載を工夫することによってボトルネックをある程度解消できます。

クリエイターズネクストにとって今回のプロジェクトのような
大きめのシステム開発は初めてのケースであり、
少しずつ工夫を取り入れているフェーズです。

目次へ

2. 共通編

必ずアイコン画像を設定する

GitHub, esa, Trello, ChatWork, Slackなど様々なツールを利用していますが、
参加メンバーには必ずアイコン画像を設定してもらうようにしています。

本当に僅かな時間の積み重ねでありますが、
ぱっと情報を見た際に、誰が情報を発信しているのか一瞬で識別できます。
また、個人を特徴化したアイコンが表示されていることで
デフォルトアイコンと比べて「人」の存在を感じることができます。

ほどよいゆるさを織り交ぜ,楽しい現場にする

文字のみのコミュニケーションは時に誤解や軋轢を生みます。
和やかなムードを生み出したり、誤解が起こりにくくするため、
EmojiやLGTM等を利用するようにしています。

LGTMの文化をインストール＋LGTM関連ツールを4つ紹介

目次へ

3. チャット編

外部の関係者とのやりとりはChatWork。
内部限定のやりとりはSlackで行っています。

チャットで扱うもの

・ 連絡・報告
・ GitHub でIssue管理される前の課題、問題

Issueにするか判断がつかないような段階の話題は先にチャットで話します。
Issue化したものについては、Issueのコメント欄でやりとりをします。
チャット側でIssueに関する話題を話してしまうと、
チャット内に様々なテーマの話題が混在し、Issueとチャットで課題に関する情報が
分散してしまうためIssueに情報をまとめるようにしています。

コンテキストを明示する

チャット内には上記のような内容が雑多に混ざります。
そのため、コンテキストの明示を意識する必要があります。

例えば「登録ページの件ですが・・・」という内容だと複数の登録ページが有った場合に
分かりにくくなってしまいます。
全員が全てのメンバーの全ての前提を把握しているのなら、
コンテキストを省略した方が効率的ですが
今回はそうではないので明示することを推奨しています。
また、こうしておくことで任意の課題を扱える人が任意の人しかいない、
という状況になりにくくなります。

検索を意識する

チャットの内容はあとで検索して調べることがあります。
検索の際のキーワードになりそうな情報が残るように意識しておくと、
未来の自分や他のメンバーがニンマリできます。
この辺りも、コンテキストを明示する理由の1つです。

コスト（時間）を意識

コンテキストを明示することで、誤解を防いだり検索しやすくなったりするメリットがありますが
あまりに記載に凝りすぎてもコストがあがります。
慣習として惰性でコンテキストを明示するのではなく、記載コストも加味したさじ加減が必要でしょう。
極論、短期的にも長期的にもコンテキストを省略して通じるメンバーで構成されているのであれば、
過度の明示は不要でしょう。

目次へ

4. Issue編

起票のコストを下げる

Issueについては下記のページでも触れていますが、
esaとGitHub Issueでちらばった情報を整理整頓

ラベルごとの投稿テンプレート付きでIssue登録画面を開くことができるリンクを用意しました。
これにより、Issue作成の負荷を軽減すると共にフォーマットを統一して
情報の可読性をあげています。

チケットメンター

Issue・チケットによる課題管理に不慣れなメンバーについては、
コメントなどで記載粒度や記載方法のアドバイスを行ったり、
私が一部の内容を編集し、その編集意図を伝えることでサポートを行っています。

吸収の早いメンバーが多く、最近は修正する機会も減ってきました。
皆さん、ご協力ありがとうございます。

目次へ

5. esa編

知識を長期保存する

Issueやチャット、その他の課題に取り組む過程で発生した

・ 業務的なノウハウ
・ 技術的なノウハウ
・ 手順
・ etc…

など、長期的な知識として共有すべきものについてはesaに残すようにしています。
また、外部と共有する必要がある情報についてはGitHubのWikiを活用しています。
（この辺りは現状のesaはユーザーによる情報アクセス制限の機能がないため、使い分けをしています。
今後、アクセス制限などが可能になればesaに一本化するでしょう。）

これにより、特定の知識・情報が特定の担当者しか知らない、という状況を防ぎます。
ただし、どの情報を残すべきか？という点についてはある程度の慣れが必要になるため
情報共有に不慣れなメンバーについては私が情報を残す理由も含めて説明した上で、
esa（Wiki）への登録を行うようにしています。
現状は社長窪田とベテラン開発者のTさんと私が主に登録していますが、
少しずつ若手のメンバーも自走しだすでしょう。

目次へ

まとめ

今後、さらなるリモート連携強化のためソニックガーデン社製のRemottyなど、
リモートワークを支援するツールの導入を予定しています。

To be continued…