情報共有の難しさ

Rebuild: 32: How We Work Remotely (Naoya Ito)のリモートワークの話、、、というよりも情報共有、感情共有、情報格差を作らない、疎外感を抱かないようにする、辺りの話がすげ〜共感したのでちょっとブログ書いてみる。
ちなみにワタクシは在宅勤務したことないし、一緒に仕事している人が在宅勤務だった経験も無いです。

他にも参考にしたブログとつぶやき

Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
情報共有の必要性について - Kentaro Kuribayashi's blog

いろんな会社と仕事するようになって思ったけど、ほとんどの組織が、情報共有、まともにできてない。CI はじめたとか、テストこう書いたとか、この OSS がいいって言ったって全然それが共有できてない

2014-02-11 15:35:53 via web

ほんと、ここうまくやるだけで色んな問題が解決するっていう組織、すごく多いと思う。まあ、それをうまくやるのが難しいから、できてないんだろうけど･･･

2014-02-11 15:38:10 via web

道具の問題じゃなく、ワークフローというか、何を皆が自然に発露するかみたいな空気の問題という感じもするから、道具作ってあげただけじゃ解決しないっていうのが難しいところなんだろな

2014-02-11 15:40:40 via web

KAIZEN 社は最近みんな Qiita Team にいろいろ書きまくってるけど、最初、書いてねって言っただけじゃ誰も書かなかったもんな。自分が日報とか作業ログとか書いてたら、他の人も書くようになった。最初の成功体験がないと、フォロワーも生まれないわけだ。

2014-02-11 15:44:27 via web

この点、入社した当時から息を吸うように日記書きまくってたはてな社は、その辺苦労がなかったから、とても良かった。「メールは使わないで、全部グループに書け」って初日に社長に言われたもんな。10年経って他の会社もそういうことはしてるだろうと思ったら、案外どこもやってなかった。イマココ

2014-02-11 15:47:25 via web

ウェブサービス作ってる会社なんだから、ウェブサービス駆使して仕事したいよね

2014-02-11 15:48:11 via web

人によっては、社内に対して技術文書がんばって書いたって全然読まれないしフィードバックも来ないからってんで、勉強会とかで気合いいれた資料作って発表したほうが楽しいって人も多いだろうな。それが回り回って Google/Twitter経由で社内に広まるという皮肉。

2014-02-11 16:04:04 via web

まあ、それは、インターネットのためには、そのほうがいいっていう話もありますか･･･

2014-02-11 16:05:16 via web

今日はとある会社のひとと情報共有どうしてる? って話をすこしして盛り上がったんだけど、僕がしたいのは情報共有というよりは感情の共有なんだなということが自分で話しててわかってきた。これよかった、これはまずいだろ、こういうことが凄くしたい、という温度をいかに伝搬させるか

2014-02-14 13:41:52 via web

情報共有というとミーティングだったり、TV会議だったり、メールだったり、メッセンジャーだったりがあるし、さらにドキュメンテーションというとファイルサーバーにOffice文書をおいとくとかWikiとかあります。

ちなみにクックパッドの情報共有に関する記事がWEB+DB 77にあって面白かったです。

WEB+DB PRESS Vol.77

立ち読みだったのでw今手元に無いんだけどwikiほどストック型ではなくメッセンジャーみたいにフロー型で流れやすいものではないツールとしてはてなグループみたいなものが必要だったので作ったみたいな話があったと思う。たぶん。

参考：

ちなみに、自分ははてな在籍中は Qiita Team がカバーするのとよく似たツールのはてなグループ を使ってこの辺の情報共有や連絡そのほかを行っていたけど、これはエンジニアの仕事ととても相性がよい。作業記録とか、アイデアとか、この処理はこう書いた的なことを何でもいいからどんどん書き込んでいくと周囲のエンジニアからスターがついたり、コメントがあったりでフィードバックが返ってきたり、後から検索できたり云々。まもなく発売の Web+DB PRESS Vol.77 にはクックパッドの開発現場での情報共有についての特集記事があるらしいが、クックパッドでも同じようなツールを内製して･･･というか、はてなから転職したエンジニアがはてなグループがないのを苦にしてオリジナルのそれを開発したと言っていたし、その辺の話も載っていると思う。

Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー

例えばオフィスが一つだけで在宅勤務もなく社員全員が日本人なら時差も言葉の問題も無いしで比較的情報共有はやりやすいでしょう。このコードは良いとかあのときの障害対応大変だったねとかこのOSSヨクネ見たいな話もその場でできるだろうし感情の共有もしやすいですよね。もしかしたらツールの選定でコンフリクトがあるかもしれないけど（例えば、オレはJIRAよりGitHubのissueを使いたい。なぜならその方がソースのdiffとのリンクを追いやすい。とか）、そんなに変なことにはならなそうですよね。たぶん。

でもそんな組織ばっかりじゃないですよね。

例えば課のメンバーが全員日本人だとしてもその大半が客先常駐で、しかも同じ場所ならいいけどみんなバラバラでなかには一人客先常駐のひともいる。みたいな状況でどういうふうに情報共有、感情共有すればいいのかっていうとまあ難しいですよね。しかも客先常駐なので社内ネットワークにつなぐのも難しいとかあったりするとなおさらです。

他にありえるケースとしては例えばメンバーに日本人とイギリス人が半々ぐらいいて会社は日本だけど社内共通語は英語ということになっている。でも日本人同士だとどうしても日本語の方がしゃべりやすいので日本人同士が日本語で技術的なdiscussionしている。で、その隣の席に座っているイギリス人は日本語が分からないから理解できない。でもそのdiscussionの内容は自分の仕事に関係している。日本人同士のdiscussionが終わって結論が出たのでその内容をイギリス人に英語で改めて説明して仕事を依頼する。みたいな状況ってあると思うんですよね（前振りが長いw）。例えばイギリス人が日本語を理解していたらdiscussionの内容を理解できるので途中でdiscussionに加わるかもしれない。でも現実はそうではないのでちょっとアレみたいなことってあると思うんですよね。たぶん。

これでさらに時差とかあったりリモートワークだったりするとなおさら情報共有って難しいですよね。でもだからといって小規模でオフィス一つで全員日本人で在宅勤務禁止が良いとは思わないですよ。ええ。なんか多様性なさ過ぎだし。

いろんな制約があるなかでもどうにかしてうまくやっていこうとするのが大事だと思いますしね。それに台風とか大雪の日に出勤したくないじゃないですかw

あとpodcastのなかで絵文字重要みたいな話もありましたね。まあ確かにテキストだけじゃそっけないとかありますよね。絵文字をさらに進めてスタンプ的なものがあるともっと良いかもしれません。