2015年6月27日の勉強会でのお話。 https://jaws-yamagata.doorkeeper.jp/events/26491

1. © chachaki 2015-
リモートワークで
チームを組む
ということ
ギルドワークス株式会社
佐々木 将之

2. © chachaki 2015-
自己紹介
昼の仕事：佐々木将之
ギルドワークス株式会社（2014.08∼）
エクスペリエンスアーキテクト
→開発の顔と企画の顔
夜の仕事：ちゃちゃき（@chachaki)
コミュニティ裏方（企画・運営）
仙台：DevLOVE仙台、UX仙台
東京：DevLOVE、hcdvalue

3. © chachaki 2015-

4. © chachaki 2015-
正しいものを、正しくつくる

5. © chachaki 2015-
アビリティ
・「正しいもの」探し
→一般的にはUXデザイン・人間中心設計
→定性調査、定性分析が好きでやってます
・「正しくつくる」
・プログラミング
→Ruby On Railsはなんだかんだで3年ほど。
・チーム開発をサポートする諸々
→アジャイル開発の道具立てなど

6. © chachaki 2015-
リモートワークで
チームを組む
ケーススタディ

7. © chachaki 2015-
ケーススタディ①

8. © chachaki 2015-
あるプロジェクトの開発陣形
東京
東京
仙台
開発
開発
全体管理
ギルドワークス
メンバー
凡例
ギルドメンバー
（パートナー）

9. © chachaki 2015-
Context
• 受託開発。お客様側では「顧客開発」を実施
• 週次で仕様変更がある。それに追随するマネージメ
ントとアジャイル開発が必要だった。
• デザインはほぼなし。開発(Ruby on Rails)のみ。

10. © chachaki 2015-
やったこと
• 日次での朝会(slack)
• 適宜、開発内容の共有(skype+pivotal tracker)
→進 確認や仕様伝達、直近やることの計画。
• 週次でのデモ確認(対面)
→動くデモでの確認。フィードバック。

11. © chachaki 2015-
ケーススタディ②

12. © chachaki 2015-
あるプロジェクトの開発陣形
大阪
京都
東京
東京
仙台
サーバーサイド
＆開発管理
サーバーサイド
デザインクライアントサイド
クライアントサイド
ギルドワークス
メンバー
凡例
ギルドメンバー
（パートナー）

13. © chachaki 2015-
Context
• 自社サービス。企画も開発も自社でやる。
とはいえ、ギルドメンバーのサポートも受ける。
• 典型的なAPIサーバー＆クライアントモデル。
• デザイン＆サーバー先行型。

14. © chachaki 2015-
やったこと
• 日次での昼会(skype)
→比較的短期間のプロジェクトであり、わずかな認識ズレが大
ダメージ。それを検知する。
• 週次での開発定例会(skype+pivotal tracker)
→週次での進 確認。翌週やることの計画。
• 週次でのデモ確認(skype+DeployGate)
→動くデモでの確認。フィードバック。
• （できるかぎり）常時skypeをつないでみる
→コミュニケーションを細かくとる。

15. © chachaki 2015-
ケーススタディ③

16. © chachaki 2015-
あるプロジェクトの開発陣形
島根
京都
東京
東京
仙台
サーバーサイド
＆開発管理
HTML/CSSコーダー
デザイン
＆デザイン管理
開発＆
開発管理サポート
開発メイン
ギルドワークス
メンバー
凡例
ギルドメンバー
（パートナー）
全体管理

17. © chachaki 2015-
Context
• 受託開発。「価値探索」と呼ばれる形で一緒に企画
を考え、開発も受けた。ギルドメンバーと協力。
• webサイト。サーバー開発＋デザイン。
• デザインと開発が並行。
• 現在進行中。

18. © chachaki 2015-
やったこと
• 日次での朝会(slack)
• 週次での開発定例会(skype)
→の進 確認。翌週やることの計画。
• 週次でのデモ確認(対面)
→動くデモでの顧客の確認。フィードバック。

19. © chachaki 2015-
リモートワークで
チームを組む？

20. © chachaki 2015-
何が課題なのか
• コミュニケーションツールは、既にたくさんある
• Skype
• pivotal tracker
• slack
• chat work
• backlog
• …and more.

21. © chachaki 2015-
何が課題なのか
• 「今コミュニケーションをとるべきか」に自覚的に
ならないといけない【メタコミュニケーション】
• 「こまりごとは？→特にありません」
• リモートワークでなければ、肩越しに気付ける
• チーム間の「信頼」貯金

22. © chachaki 2015-
どう解決するか
• スクラムのフレームワークは重宝する。
【定期的な確認】
http://www.itmedia.co.jp/im/articles/0410/05/news108.html

23. © chachaki 2015-
どう解決するか
• 【心的側面】心地よい仕事のためにどうするか
（スパイス程度の）LGTM画像やボケとツッコミ
• 【情報伝達】仕様の認識ブレをどう防ぐか
何を伝えるか。モデリング、仕様
• 【環境側面】プロセス・チームの形はどうなのか
スクラムのフレームワーク、インセプションデッキ

24. © chachaki 2015-
リモートワーク
• リモートという環境要因
• まずは「自分」「チーム」としてどうありたいか
考えるべき(why)
• 顧客にはリモートであるメリットはほぼない。→
顧客への説明責任が出てくる。
• 開発側には多大なメリットがある。デメリットも
ある。

25. © chachaki 2015-
まとめ

26. © chachaki 2015-
ざっくりまとめ
• リモートワークでは、メタコミュニケーション（今
コミュニケーションを取るべきか）が不足しがち。
→コミュニケーションの心的側面、情報伝達、環
境側面に配慮することが必要になります。
• ギルドワークスには、リモートでのチーム開発事例
が多数あります。
→お仕事のご依頼、または、チームを組みたい方、
お待ちしてます！（ http://guildworks.jp/ ）