世帯での情報共有のしかた
家庭を支える技術 Advent Calendarに寄せて
これは家庭を支える技術 Advent Calendar 2016の12月19日を担当する記事です。
2014年には新たな家庭を持った友人たちが書いているのを眺めていたところから2周遅れで不思議な気持ち。 他の方の記事を伺う限り、参加者層のバイアスがあれど、僕が使っている「家庭を支える技術」というものに該当しそうなツールもデバイスも特に真新しいことはなく、むしろこんなに当たり前な雰囲気でSlackやHueを使っている家庭があるのかと驚く。 どれもこれも全部書いてしまおうと当初は思っていたけれど、ひとつ、情報共有やコミュニケーションについて現状を書くことにした。
世帯内での情報共有とコミュニケーション
世帯を運用していく際に、導入すれば生活が便利になるであろうツールは山ほどあるのだけど、ツールのために生活を少し弄ることだけは可能な限り避けたいという気持ちが根底にある。世帯のそれぞれの人は僕にとってユーザであり、彼らが自然に使い続けられることに重きを置きたい。
アプリケーションのリストに世帯の運用由来で消すことが許されないアイコンが増えて続けてしまうのは嬉しくない。ルンバほどの存在でないツールには生活の何かを直接的に変えて欲しくない。
特に世帯内でのコミュニケーションや情報共有を取り扱う際には、うっかり色んなツールを重複した用途のために無理に選んでしまいがちになっていたのだが、やっと最近落ち着いた形を得られてきたので、その全体像と考察をこの記事では触れたいと思う。
情報のスピード感に合わせた3つのツール（サービス）
現在は、情報のスピード感に合わせて3つのツールに落ち着いてきた。
スピードが速い方から順に - LINE - Slack - esa という並びになる。
即時のレベルで反応が欲しく、その反応はしばらく後には必要ない性質を持てばLINEで行い、同期的な反応はほとんど求められず、発された情報が中長期的に記録されていることが望まれる性質を持てばesaに残す。これだけでは双方それぞれに不向きで間に落ちそうなものをSlackで受け止めるようにして、3つのツールを用いるようにしている。
何らかの組織やプロジェクトチームに於いてのコミュニケーションや情報共有についての文脈でいうストック情報とフロー情報という表現をされることがあるが、それに近い。表現の仕方だけの差異（情報が滞留する時間の長さを指しているのか、情報が通り過ぎるスピードを指しているのか）だけかもしれない。Information Architecture周りでの言及を探してみたが都合の良いものが見当たらず、用法として聞いた話を頭の中で勝手に解釈してしまっていた気がする。
それぞれのツールと具体的な利用シーンを以下紹介したい。前提として、現在はソフトウェアエンジニアの僕と、ウェブ系の（？）デザイナーである妻と二人だけがメンバーであることを念頭に置かれたい。
速い情報： LINE
紹介する必要もなさそうだけど、モバイルを中心としたメッセージツール。「今から帰る」であるとか、「今どこにいる」だとか、リアルタイムな伝達を意図する、スピードの早い情報が取り扱われる。
二人とも友人や親族とのやり取りのために元々利用し、使い慣れていて、アプリの挙動としても高速であるため、利用体験としても対面の会話と近しい感覚を持てる。やり取りの内容としても直接の会話に限りなく近く、違いは対面であるかどうか、写真など何らかのデータの送付が必要であるかどうかのみが異なる。
なお、電話による通話は遠隔地で過ごしている時でない限り、ほとんど夫婦間で行われることがなく、肉声である必要性についてはさほど求められない。
ツールとしてはFacebook Messenger等、他のものでも良かったのだが、メッセージのログをエクスポート出来る点が特にLINE以外を選ばなくなった（スタンプ等一部の情報は欠落する）理由かもしれない。
速くない情報：esa
情報、ドキュメントを書き残すツール。語弊を気にしなければ「いい感じのWiki」。
この系統のツールは、日本のサービスだとQiita Team、DocBase、Kibelaなど。海外で気になるもの、サービスだけでなく自分で動かすタイプのソフトウェアも加えると選択肢がかなり多かったのだが、個人的な好み、運営されている方々の素敵な姿勢、他ツールとの連携、導入を検討したタイミングが全てうまく重なったというのが選定理由で、安易に勧められる自信はない。
導入上は、僕はWebPayの仕事でしばらく使っていた（し、概ねの導入に携わった）のだけど、それに引っ張られる妻は大変だったかもしれない。
esaに実際に記録されている情報
実際に記録されている、速くない情報の例を並べるとこんな風になる。
- 実家の住所や親戚の名前等
- 身体の各サイズ（服、靴、指輪など
- 東京で借りているトランクルームへの入館方法とそこ保存されているもの
- 頂いた結婚祝い一覧と内祝いの発送状況、ハガキの文面
- 妻のポートフォリオサイトの構成や操作方法のドキュメント
- 旅行の計画（終わった後は写真へのリンクなどの振り返り情報）
こう眺めてみると、「ほぼ永続的に変わらない情報やドキュメントをメモしておくのを代替」としていたり、「一時的には繰り返し共同編集が行われて現況が随時わかるがその後はアーカイブになる情報」が記録されている。
一時期、お互いの状況がわかるように、仕事っぽく週報を残すなんてこともやっていたのだが、仕事が忙しくなると途端にプライベートが置き去りになったり、一緒に暮らすようになったらわざわざ書くタイミングが無くなったということもあり、現状廃れてしまった。
残す/残さない、反応欲しい/欲しくないの間に落ちそうな情報： Slack
チーム用のチャットツール。テーマや分野に応じたチャンネル（チャットルーム）を複数作ることが出来て、他のウェブサービスやツールとの連携によるメッセージの投稿などが簡単に実現出来る。
元々、二人ともそれぞれで仕事やその他のプロジェクトで複数のSlackのチームに属しているため、そこに一つ追加されたに過ぎないので、導入についての心理的な障壁は比較的低かった。 皮肉なことにモバイルアプリがあまり俊敏な操作に向かないため、LINEとの棲み分けが効いている面も伺える。
ここでカバーしていることを簡単な言葉にするのが難しい。決して「Slackを家庭内のコミュニケーションで主に使っている」という感じの発言には落ちない。「家庭用のSlackがあります」以上には一言で表現するのが難しい。見出しの通りに話したいけれど、コンテキストの補充がいくらか必要となる。
要は
- LINEより反応が遅くて問題ない、もしくは必要がないコミュニケーション
- esaに残すほどではない情報
にあたるものになるが、これには多くの情報や非同期で十分なコミュニケーションが該当する。
コミュニケーションの面では、話をしたいけれどこの1時間以内で急いで回答されたいわけでもない相談事であったり、思いついたアイデアを綴ったり、偶然見つけた面白いページのURLを伝える場になる。
情報の面でいうと、Google Calendarから分かる日々のスケジュール、各々のはてなブックマークの追加やSliceを通したECで買った物の配送状況といった、他のサービスの何かがタイムライン的に並ぶものが多くを占めている。
これらのコミュニケーション、情報がチャンネルという形で何らかの名前を付けて取り扱うことになる。
現状のチャンネルを名前がわかりやすそうなものをざっと並べると#life, #finance, #works, #wedding, #timeline, #sandboxといった具合である。
チャンネルをどの抽象度で立てるか、命名はどうか、統廃合するか、削除するかについてが肝で一貫性は諦めているが存在するべきかどうかについては常に考える必要がある。#weddingは両家の顔合わせを考えねばといった頃に立ち上がったが、結婚式を行って諸々の後対応が終わればアーカイブされるだろう。最近は#lifeでは何でも該当して広すぎるのではと気になるものの、細かく分けたら発言の出し分けが面倒そうで判断つかないという悩みがある。
簡単なサービス連携によるSlackへの通知
お陰様で今日、結構なサービスがSlackへの通知を簡単に実現させてくれる。 標準のSlackのインテグレーションを用いているものを挙げると
- Google Calendar
- 毎週の予定まとめ、当日の予定一覧を定時で通知している
- Arc
- 妻のポートフォリオサイトのGoogle Analyticsのまとめを定期的に通知している
- RSS
- それぞれのブログや共通して読んでいるもののRSSフィードから更新情報を得ている
- Wunderlist
- 買い物リストの更新通知を流している
冒頭でのツールを増やしたくない話と矛盾する部分もあるが、Wunderlistはなかなか便利で、買い物リストの共有に用いている。モバイルアプリがサクサク動くので、実際にスーパーでカゴにものを入れながらチェックを入れたり、思いついたタイミングで項目を追加するといった使い方をしている。
これに加えて、iftttとチャットボットであるHubotを通すことで
- Fitbit
- 睡眠状況、体重の計測値
- Slice
- ECで買ったものの配送状況
- はてなブックマーク
- それぞれの追加したブックマーク
- GitHub
- 共有しているリポジトリにまつわる通知、ポートフォリオサイト等が置いてあるGitHub Pagesの更新完了
といったものも、それぞれの関連しそうなチャンネルに流している。
esaとSlackの連携
esaに残すと判断された情報は当然esaに残しているのだが、esaに情報を残したという情報はSlackでのコミュニケーションをとても良くアシストする。
esaからのWebhookによる通知をHubotで受け取って通知するHubot Scriptsを作っていたのだが、作成/更新された記事タイトルのタグや階層からSlackのチャンネルを選択する機能を最近稼働させた。
例えば、esaでlife/トランクルームに預けているものというタイトルならSlackの#lifeに通知されるのだが、別でタグを明示的に指定した場合、life/結婚お祝いまとめ #wedding としたら#weddingに通知されることとなる。
元々はWebPayで働いていた際にQiita Teamで記事に付いたタグに応じてSlackのチャンネルに通知するようにしていたこと（その時はtomykairaが一瞬でつくってくれた）の再実装である。かつて単一のチャンネルに通知をしていた頃に、通知の流れる先が「何かの通知がされる場所」とか「分類出来ない何らかの掃き溜めっぽい場所」にあたるチャンネルが選ばれてしまうのがもどかしくて、記事のタグや投稿者から通知先をいい感じにするようにしたのが良かったという体験があったので導入を試みたのだが妻には割と好評のようだった。
メール通知の通知
どうしても流したい通知があっても、それらの情報元がSlackやiftttと縁がないことも少なからずあって、そういったところでもほとんどが対応しているメール通知をSlackに流すように環境を作ってある。例えば現状は銀行、カード会社からの逐次の利用通知、アパートへの配送物の到着通知を流すのに利用している。
MailgunのRoutes機能によるWebhookをHubotに投げて通知するようにしているのだが、結構これが汎用的に使える。特定のメールアドレスをMailgunで準備してあり、個々のメールボックスから特定条件で通知にあたるメールを転送するように設定することになるのだが、とりあえずSlackへの通知が欲しいと思ったものはその設定だけをしておき、後からメールの内容をパースして、Slackで見やすい情報構成にしたり、チャンネル選択をするような実装を加える。
ちょっと逸れるが、お金にまつわる通知は家計管理を担当している僕だけが見えている状態は良くないということで、随時通知を出すようにしたり、見えるべき情報をちゃんと見えるようにするよう特に努めている最中であり、メール通知の処理もそのために生れた。直近では、資産周りをそろそろクロールするなりして、定期的にわかるようにするつもりなのだがマネーフォワード、Mint等利用しているアグリゲーション系のサービスがもう少し外部からの情報取得に積極的になっていてくれればと思っているところ。
おわりに
Slackの点が妙に大きくなってしまったが、僕たちの情報共有やコミュニケーションについての現状をまとめた。
うまいこと納まっているような書き方になってしまったけれど、まだ経済的な共同体となってからは4ヶ月程度なのもあって、長期以前に中期的にもどういう形に収まっていくのかは引き続きの運用次第。ツールが転がっていれば人がうまく動くわけではなく、結局は情報の属性や場所をメンテしていくことに誰かが意識を回す必要があることに変わりはない。それはAIで解決されるのかもしれないし、人が情報を検索することをありきにすればいいだけなのかもしれない（アメリカの会社に入ってようやくGoogle DriveとSlackみたいな組み合わせに慣れてきた）。
もしこれが2008年のことだったら、はてなグループとIRC、携帯キャリアのメール、2012年にもしかしたら、Google DocsとHipChat、TwitterのDMを使っていただけの話で、ツールは時代に合わせて変わっていただけだろう。情報を共有するとして、何が知りたくて、何を残しておきたくて、何を伝えたいかを参加者が無理のない運用を考え続けられるよう気にしていたい。
