2014年にリモートで試したミーティング類のパターン

 今年の初めからアメリカに引っ越したので社内の人とのやり取りをどうするかという悩みに現実的に直面し、この1年で色々試したのでセーブポイントとしてまとめておくことにした。(ブログの記事を書かなさすぎてはてな記法忘れつつある...)

チームとミーティングの距離感

f:id:hxmasaki:20141229160507j:plain:w300:right

 8人くらいの会社。誰もがSPOFで、何かに詳しい人間はだいたい一人に絞られる*1。会社として重要な箇所に一人だと心許ないというより、誰も休めなくなってしまうので概ねわかるだろうという他者を含めるか、共有するなりで冗長化して、2人以上がひとつの何かに取り組んでいる形を組織中に点在させている。

 その2人の間や異なる担当間でそれぞれミーティングの時間を取っておきたいが、大仰に週例、月例、毎朝のスタンドアップみたいなミーティングをそっくり入れ込むにはちょっと負荷が大きいので何か工夫が必要だ。

 勤務地は強制していない。オフィスはあるけれど必要になった時に利用したら良いとしている。アメリカに居るとか、東京でも自宅から滅多に出てこないとか、週のほとんどはオフィスでたまに私用に合わせて自宅とか、仕事に全力投球する期間だけ泊まりっぱなしとか色々な勤務形式が伺える。

 ちなみに、「働く場所は自由です!」とは言ってなくて、「パフォーマンスを出すのに必要もしくは仕事をする上で合理的な動き方をしていれば何でもいいよ」という体裁である。(強いチームかどうかは別にして)オフィスを捨てていない。僕は帰国時に、メンバーとコミュニケーションを取ることが仕事に良い効果を持つので、だいたいオフィスに居る。周りはそれに合わせて普段よりオフィスに来るようにするというような変化もあって*2面白い。この自由度だけに溺れると簡単に居場所を失う。

 こうも自由だと、だいたいはコミュニケーションをとる時間やミーティングどうするのという話になるが、働く場所と一緒でうまく行くものを都度見つけ出しましょうというスタンスで試行錯誤しているので、以下はそのまとめとなる。

続けられているミーティングの形

A. 会話をすることが主体となる場合の1:1

f:id:hxmasaki:20141231072722p:plain:right:w300

 組織の代表であるkeikuboとプロダクト開発の代表である僕のサシ。週に1度、日本の早朝(アメリカ西海岸の昼過ぎ)に、朝食会と題して何か食べながら*3、1時間程話す時間を取っている。

 SlackのSnippetを作って議題スレとしていて、週ごとのミーティングを迎えるまでの間に思い当たった話したいことを、話題を思い出せるくらいのキーワードでコメントしておく。ミーティングの時にはそのSnippetを見ながら、話したいもの順(多い場合は倒しておきたい重そうなものから、少ない場合はコメントが早いものから)に、コメントした者が説明してそれについて会話をする。一服感出てきたら次の話題へ移る。「これは後でやります」とか「これは忘れそう」といった何か記録を残したり次のアクションが必要な場合はコメントに追記しておく。

 会が終わったら次回の日程を話し合って決めて、お互いのカレンダーを抑えつつ、その日程を冠するSnippetを新たに作成する。(Command + Return で一発!)

 小さい組織なのでプロダクトのことについての概ねの状況をkeikuboはわかっている。会社に影響を与えるだろうと二人が思うであろうものを除いて、全て権限として僕に委譲されている。逆に僕も「各チームのトップ4人」でのミーティングや、社長の社内外での行動、言動は僕のストーキングが及ぶかぎりで概ね把握している。

 なので、この会で話すのは上で解消されない、気になることや個人的な思い事が主役になってくる。この辺こそ意味が無さそうなため共有に達しにくい重要な情報であることが多く、お互いにやりとり出来ていると他の仕事の潤滑油のような役割を果たす。

 日常でそのような話題が思い当たった時に急を要さなければ、チャット等でその場で片付けず、議題スレに書いておく。即物的に話題について話したい欲を解消しようとしても、その時の互いの状況で扱われ方が都度異なりかねないので避けておく。正味かける時間としても互いにその話題だけに頭を使うようにするタイミングまでとっておけるのならそれが良い。

 これは最も気分良く続いている。うまくいっているからか日本に一時的に帰ったタイミングでkeikuboと会っても久しぶり感がなさすぎるくらいにコミュニケーションが取れていた。これについては、keikuboが社外の人に話したら全く共感してくれなかったということがあって「対面で会わないと族」が現れ得ることを学んだ。

 逆に僕の帰国中、「日本に居てオフィスで顔を合わせるからいつでも話せるし*4」と、この朝食会の開催をおざなりにしたら、出国するまでコミュニケーション不足だったという認識がお互い強まっていたので対面が可能な機会でもやり続けることになった。

 最近は、チーム内の上司と部下みたいな関係の2者間でも試しているが、週1で部下へフィードバックできる、上司へまとまって相談できる時間となっていてうまく機能しているように見える。

 ちなみにSlackのSnippetが業務中でも活躍している。コードスニペットを貼るという目的ではなく、「テキストが投稿されてそこにコメントが書ける」という点が便利で、例えばユーザからの問い合わせのメールを受信した際にSnippetで流し *5、そこで対応や方針について議論をすることでチャット上では流れていくメッセージ群がうまくストックされる。(現状カスタマーサポートでのそういったやり取りについてはFrontに移行した)

B. タスクが主体になる場合の1:1

 相手はビジネス系(ここでは開発、サポート以外だいたい全部を指す)の代表者、僕は開発側の代表者。

 互いの仕事は一緒に取り組むものではないものの、依存し合っているものが多い。例えば、ビジネス側でデータが必要だけど開発側で実装が必要とか、開発側で規約が必要でビジネス側(この場合法務)に内容判断を仰ぎたいとか。

 どちらも会社で言うオペレーションにあたる部分の責任者であり、社内のオペレーションについてはこの二人が揃うとだいたい全部とされる。

 一番多い会話は「あれどうなってますか?」「これはそっち的にどうですかねえ」「頑張りましょう」

 やり方としては、Aの朝食会と同様にSlackのSnippetを使っていたが、数週間やるうちに、挙がるテーマが具体的なタスクに寄っていることに気づいてきたので、最近はTrelloを使い始めた。二人でやり取りするBoardを準備して、以下のようなListにタスクを並べて運用するようになってきた。

  • Done: 終わったもの
    • ミーティングの際にお互い振り返り等確認しながらアーカイブする
  • OnGoing: 今週やるもの
    • ミーティング時にToDoから持ってくる
  • ToDo: ミーティング以降にやることになるだろうと挙がったもの
    • 膨らみすぎる場合は何らかの分類をして別のリストにまとめる
  • Meeting 2014/12/XX 10:00-
    • 掲題の日程のミーティングで話そうと思っていること(SlackのSnippetのコメントに近しい)

f:id:hxmasaki:20141231073542p:plain

C. 各チームのトップ4人での会社全体の把握

f:id:hxmasaki:20141231074200p:plain:w300:right

 週末もしくは週初の夕方に、だいたいのチームの代表者4名が集まる。それぞれが会社全体を把握するためにやっていて、各人責任範囲の状況のスナップショット、共有事項をまとめた週報を持ち寄って話す。僕が知っているウェブ企業の中で最もありがちなミーティングのやり方を取っている。

 かつては司会が居て、各人順に週報について話し、それを録音して残すというサイクルを取っていたが、わざわざ話してもらうことで時間が無駄に使われる、話している途中で突っ込むと時間配分的に後ろにあるものがないがしろにされやすかった。

 そこで、全員が集まって最初に全ての週報を読み、参加者それぞれが気になったものを挙げて話をするようになった。特段ルールを定めているわけではないが、議論が絶えるまで話すかどうでもいい脱線を見せたらその話題はクローズする。

 全体を参加者それぞれが先に把握しているという前段があることで、話題として後ろに登場するものでも存在が認知されているため、序盤の話題が無為に膨らみすぎることが少なくなった。また発表者順、並べられた情報順ではなく、気になったもの順に議論されるようになるので、自分の責任範囲の都合上依存しあってるものや特に気になるものから優先的に解消され、大事なものがこぼれにくくなった。

D. 開発チームの2-4人でのプロダクト開発の進捗振り返り

f:id:hxmasaki:20141231081510p:plain:right:w300

 このチームでは完全にSlackにおけるチャットのみでのミーティング。プロダクト開発進行用のAsanaのプロジェクトでは、ラベルの分類(右図左側)を

  • Idea (Let's talk at meeting!):
    • ミーティングで話すためにとりあえず立てておく項目
  • Bug Fix:, Big things:, Side works:
    • 開発上で直近でやることになっている項目
  • Stockyard:
    • 気が向いたり、機が熟したらいずれやる項目

というようにしていて、ミーティングの開始時にはBot

  • 終了したもの
    • 今週finishedとなったタスク
  • 話すべきもの
    • 今週追加されたタスク
    • Idea (Let's talk at meeting!): のタスク
  • 状況を伺うべきもの
    • Bug Fix:, Big things:, Side works: のうち来週以前にDue Dateが振られているタスク
    • Bug Fix:, Big things:, Side works: のうち最終アクションから2週間以上経過しているタスク

をタスク名とパーマリンクのURLを連番付きのリストにしてSlackに吐き出す(図右側)ので、各リストごとに話を進めていく。このとき「終了したもの」、「状況を伺うべきもの」の2つは御礼を言っておきたい、補足しておきたいなど、触れておきたいものをつまみ上げて話す。必要に応じて他者が反応する。

 「話すべきもの」にあたるリストは、挙げた本人が事前に出している情報(Asanaへのタスク追加時にDescriptionに書いている)を元に次のアクション(やる、やらない、追加調査)を決める。補足として自分の考えを大きめに伝えたい場合は開始前にQiita Teamに書いて共有しておく。これはメンバーの一人がやってくれていてチャットでうだうだ話が長くなるのを防ぐのに効果があった。

 だいたい、これは30分から1時間くらいで終わる。以前は対面もしくはビデオチャットが前提だったが、チャットに移行を試した際に不利益が特に生じていないのでこのまま回っている。逆にチャットにやり取りが完全に残るので参加していない人が事後に全ての情報を再生出来るという面ではかなり良くなった。他の人がやっているミーティングもこのレベルで残ってたら楽なのにと思うくらい。

E. ミーティングをやらないチーム

http://instagram.com/p/oR1ynrLMJA/

 これは特例。取り立ててミーティングを必要としていないと判断したものの、ミーティング等でまとまる情報や状況把握の面は欲しいので、専用のSlackのチャンネルを立てておき、日次や作業単位で都度簡単な情報を残す。見る側、書く側それぞれで一度まとまった時間を使って話したほうが良いと感じたら手を挙げて話す。

 そもそもは僕の隣の部屋で暮らしているメンバーと僕の間で主に進行するプロジェクトだったので、日常生活で出くわした場合に話すことで特にミーティングでそれ以上得られるものもないとしていたが、僕が2ヶ月帰国しているうちに全く見えなくなる、全く把握されていないと感じる状態を解決するのに始めた。その時は週次でこのチャンネルの内容を振り返りながらSqwiggleでミーティングらしきものをしていたが、戻ってからはこのチャンネルだけが運用されるようになった。

 写真のようにお互いまとまって話しましょうかと思ったのが一致して、30分くらい近所に散歩に出て話して帰ってくることも何度かあった。おそらくミーティング無いという表現が間違っていて、まとまった時間での情報共有やコミュニケーションを代替する何かをやっていた。

続いているミーティングで共通すること

次の日程を必ず決める

 週例で曜日と時間が決まっている前提でも必ず確認する。祝日はじめその時点でスケジュール変更が必要とわかっているのなら、そこで一度巻き取る。3人を越えると特に日程の調整に言い出しっぺが走り回るのが大変になる。

 Aでは終了までに次のミーティング用のSnippetを立てる。これも立てるのを忘れていると、書きたいことを思い当たった時に、まず立てる作業(日付の確認の上でスニペット作成)に気を取られ鮮度を失いがち。

話す際に概ねの情報がまとまっている
  • 逐次ミーティング材料を吐く
  • 週報を全員が上げてからスタートする
  • 開始時にBotツール系から抽出する

など、大小あれど話す材料が整っている。いっぱい出し過ぎるのがコストになることもあれば、何もなければそれを漁るだけで時間を消費するので、それぞれの会において良い粒度を考えることが重要。大小の調整もそうだけど、自動化やまとめるのにかける時間の分散などして負荷も減らせる。

対面を強制しない

 明文化出来ていないけど、内容や状況に合わせて対面を要求することはあっても、通常の必須項目にしていない。

 今のところ毎回同じ空間に居るというのを体感として必要とするメンバーが居ないと踏んでいる。「対面で会わないと族」はいつか現れるし、それがおかしいことでもないので、逐次調整しないといけなさそう。

 極端なところで、僕が帰国した時と出国前にせっかくなので会ってミーティングしときましょう。それ以外は全部チャットで。という形式があってそのメンバーとは年5回会うかどうかという場合もある。それだけで済むと合理的に判断出来るので気にはしていない。

 逆に、そのくらい会わずに一緒のメンバーとしてやっていけるというのは当人の実力や気の回し方が実際に対面で居る場合と差を生まないくらい優れているという意味でもあると実感する。むしろ、会ってる頻度が高いメンバーよりも仕事の状態等全部わかるようになっているし、組織の中で最も信用できる人物である。

 ハグして会話が要らなくなるなら対面を強制すると思う。

話す必要があるねという同意から場が生まれている

 全てのミーティングが必要だと参加者全員が強く認知して成り立っている。「週例でやっとくべきでしょ」とか「あの立場の人とこの立場の人は話しておくべき」というのを安易に掲げると、

  • 何故やっているのかがわからないので発言が本質的なところから外れる(というか的にすべき本質がない)
  • 参加させられる側に立つ者のうやむやなモチベーションを原因に荒む
  • 会そのものが実は要らないのに、要る前提になっていて無意味な時間に心を痛める

で、だいたい腐った会が出来上がる。よくある方法論に乗っかるだけだと事故るので、ミーティングのような何かをしないとまずいと自覚出来るようなヒヤリハットに出くわす雰囲気をつくる(最近こういう事故とか嫌なことになったのやばいよねと話せる)ことで、会がそれぞれ発生させられている。

 「ミーティングの目的を掲げましょう」というと当たり前過ぎるけれど、だいたい何度かやると忘れていたり、字面では残っていても必要になった原体験を見失うもしくは、ミーティングそのものが必要なくなっている可能性があるので、無為なミーティングになりつつあるなら消すなり再構築するなりする。

やらなくなった、使わなくなったもの

PS3でのビデオチャット

http://instagram.com/p/i0kFIRLMOT/

 お互いPS3を立ち上げて、片方がビデオチャットを立ててもう片方を招待した上で入室する。どっちがホストになるかが定めにくく同期的な接続が大変。こちらから招待しておくので、誰かが出社したら入室させといてねという運用は続けられなかった。通信が不安定になった拍子に切れてしまい、それぞれが再度操作しないと復旧が出来ないのはかなり面倒。

 また、お互いテレビに表示しているというのが悪いのか、どうしても「他の空間同士が繋がっています☆」みたいな体裁を創りだしてしまって、個人的に好きではなかった。人数が多いか要人が居る方に場を握る空気が偏って、その中心から遠くで参加している側の疎外感みたいなのが出やすい。多い人数の方が少ない人数の方の声を聞き取れない時とかに置いてけぼりにされると遠隔地が尊重されていない気分に拍車がかかり辛くなる。テレビだと多い人数の方は視界から外されやすく、遠隔地の頷いたりなどフィードバックをキャッチされにくい。更に視界から外れていると音が脳内ではノイズのように処理されてしまいがち。

 Sqwiggleで解消出来ている感があるのは、

  • お互いがログインしていればワンタップで強制的に接続を確立出来る
  • (大人数側に設置したiPadで起動している場合)画面がテレビよりは近いから存在を認識しやすい
  • (大人数側で誰かもしくはそれぞれのMacで起動している場合)週報等ドキュメントと同じ画面に出るから、少なくとも誰か一人には確実に強く認知されやすい

 あたりが原因っぽい。

 よく見かける、みんながSqwiggleを立ち上げておいてお互いの顔がわかるようにみたいなのは早々に廃れた。マシンのリソースを割と食う、チャットで割と居るかどうかわかって別に顔が見えてもという意見に寄っていて、僕だけデスクに常駐させたiPadで起動している状態。少人数側が大人数側を気にしすぎる図(もしくは少人数側が気にされにくい図)はこういうところでも出てくる。けど、誰か僕と話したい時には繋いで話しかけてくれればいいよという態度は崩さないようにしている。

 iPadのSqwiggleのアプリはマシンリソースから切り離せるし、マシンの外で常にフロントに居てくれるのでなかなか便利。Ankerのタブレット用スタンドと一緒にだいたい持ち歩いてもいる。加えて、ハウリングやエコーが環境や状況によって散見されるので良さ気なイヤフォンマイクを使うようにしてから快適になった。特にMac Appでは起動してから時間が経つにつれエコーしやすくなってくる傾向にある。スペックが低いマシン程顕著。

 みんなにiPadを配るか、iPhoneもしくはAndroidに対応してくれるともう少しカジュアルに試せるかも。いい感じにSqwiggleの入退室のフックが取れればSlackにそれを流してアプリの起動を想起させられそうだが正攻法でないAPIを利用することになるので現状手が及んで居ない。

録音

 これは話している内容の質が低いか録音をするだけというのがナンセンスであることに依るものだろうけど、最終的なバックアップとしては良いかもしれないが、これを共有しておけばオッケーという場面に出くわさないまま1年くらい経っていて自然と撮らなくなった。会社のミーティングと開発のミーティングでそれぞれ撮っていて後で聞き返したが、「懐かしい」とか「この時はこう考えていたなそういえば」みたいな感慨や小さな発見はあるが、絶対撮っておいた方が良いという材料には巡り会えなかった。

 スマートフォンのアプリで撮って、後で共有するところに置いて...というのを自動化出来て量が溜まると変わるとか、組織サイズが増えてきたりすると共有の一次手段としては有効に変わってくるかもしれない。インターナルなポッドキャストとか。

"エンジニア"で動員するミーティング

 かつて全エンジニア5, 6名でやっていたが「エンジニアだから」という理由で、全員の時間を同期的に割くのは無駄と判断して辞めた。開発なりインフラなりで分割して代表者間でやり取りする形でカバーしている。

 技術的な共有とか、勉強会といったお話なら良いかもしれないが、それ以外でエンジニアをキーワードとして集めても意味が見つけられない。

 あと、keikuboが知っておきたいという意思で、参加していたがエンジニアリングに普段携わらずに話を持ち出す時の的外れ感や、日程の同期コストが一番高い割に出席に対するリターンがかなり少ないというのもあって、今も続いているAとCでカバーされる形になった。

議事録

 録音に関連するが、その場で作られる議事録は、書く者の参加しにくさと書かれた情報の大事さが釣り合わなくて消滅した。「話す際に概ねの情報がまとまっている」ようになっていれば、会を受けてそれを書き換えるだけで十分だった。

あとがき

 チーム間、メンバー間でのミーティングのやりかたを試行錯誤している。改めてまとめると特にリモートに限った話ではなかった。

 こういうのはどうも車輪の再発明をしている感があって外に書くのが何となく恥ずかしい。うまく行っているものを知って取り入れる時に辻褄を合わせるコストと自分たちで組み上げていくコストには(10人にも満たないこの人数だから)大差がなくて、結局自分たちに合わせてカスタマイズするくらいなら、最初から自分たちで組んでもいいんじゃないのと思うところが強い。おそらく、知らないところで損しているのを発見するために、先人がどうやって何を得たかをよく観察するのは必要。

 多分リモートという言葉も危なくて、現に「働く場所を強く制約しないだけで必要に応じて会うなり離れるなりしましょう」という僕達の考え方と「本にあるリモート」ではリモートワークへの入り口が違うので、「リモートやっています」と僕達が言ってはいけない。

材料

読んで考えるための情報を集めただけで、実装に残る形ではほとんど反映出来ていない。

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

  • 作者: ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン,黒沢 健二,松永 肇一,美谷 広海,祐佳 ヤング
  • 出版社/メーカー: 早川書房
  • 発売日: 2012/01/11
  • メディア: 単行本
  • 購入: 21人 クリック: 325回
  • この商品を含むブログ (35件) を見る
NASAのチームビルディング

NASAのチームビルディング

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

*1:逆に該当する主担当が無いならこのサイズの組織では存在する意味がない。

*2:気持ち良いというか僕のために来てくれている気分がして自惚れがち。

*3:アメリカ側は往々にして食後なのでリンゴをかじるか、コーヒーをすすっている

*4:僕は日本での生活習慣上、早朝から稼働するのがかなり辛い

*5:こういったSnippetの投稿にはSlack Anywhereを活用している。