BacklogWorld/Mackerelのクライアントワークから学ぶ情報共有の成功と失敗
14:10-14:40
Mackerelというサーバー監視サービスは、SaaSということもあって原則クライアントワークはありません。ただ、いろいろな企業さんとコラボレーションすることはよくあって、そういう場合に他社と共同して動く、という場面があります。ここでは、過去のMackerel開発における他社とのコラボレーションを例に、情報共有の成功と失敗について学んでみようと思います。
※コラボレーション先の具体的な企業名などには言及せず、一般化してお話します。
Mackerelのコラボレーション開発
SaaSサービスなのでユーザー向け個別開発はやっていない
通知先連携や認証関連、クラウド事業者との連携などでコラボレーション開発がある
Cloud Providerインテグレーションとして各種APIを提供
具体例:Typetalkというツールと連携している
はてな-Typetalk間はTypetalkのみでコミュニケーション
社内ではGithubのIssueで設計の議論などしながら開発
企業間のコラボレーション開発について
どんな道具を使う?
コミュニケーションの属性について
実例を紹介しつつ考えてみましょう
基本的にはお互いリモートでの仕事になる
リモートワークの文脈
お互いをよく知らない
文章の行間や暗黙知に頼れない
遠隔地同士の情報のやり取り
気軽に声をかけあったりできない
自分達が普段使っているツールを相手も使えるとは限らない
タスク管理
進捗管理
仕様の相談
数え上げたらキリがない
情報の2つの属性
ストック型
蓄積され、いつでも参照が可能なもの
設計書、Wiki、ソースコード、タスクチケット
Backlog、Cacoo
はてな:Slackを使ってチャット
集まって会話、リモート先とテレビ会議
ペアプロ、ペアオペ、モブプロ
Github(ZenHub)、はてなグループ、Google Docs
フロー型
鮮度が高く、素早く交換される
蓄積されにくく、後から参照が難しい
チャット、電話、会議のやり取り
Typetalk
2つをバランスよく操るのがポイント
会議の内容を議事録に残す
会話した内容を設計書に反映する
フロー -> ストック
チャットツールのピン留め、などもストック化の一種
チャット
会話(電話・会議)
ホワイトボードの図
写真に残したりするけど、結局コンテキストが分からなくなったりする
中間的
振り返りのログ
フロー型に偏ったパターン
先方とのやり取りはチャットメイン
Trelloのカンバンで進捗を共有
設計ドキュメントは社内のGithubで管理
設計意図をチャットで話したが、流れてしまって経緯が不明となり水掛け論っぽくなってしまった
チャットツールは無料版だった
過去ログは一定期間で消滅、経緯も消失
経緯が残る仕組みをちゃんと考えよう
水掛け論を終わらせるには、どちらかが何かを諦めるしか無い
意外とアクティブなメンバーが限られる
チャットルームにはいるけど発言しない人とか
ストック型に偏ったパターン
先方の都合(インターネット禁止)でチャットツールが使えなかった
基本はメールベース
課題管理表を送り合う感じに
意外と開発は順調
経緯もコミュニケーションもメールに残ってるので水掛け論にはならない
スピード感が出ない
回答期限とか言われても結局書かない
短期決戦・単発開発はフローを多め
長期・大規模はストック
会社ごとに使えるツールに制限がある
ストックとフローを意識した選定が重要