コスメアプリ「LIPS」を開発・運営している株式会社AppBrewで作った「社内コミュニケーションの手引き」を公開します。形式はまだ発展途上ですが、AppBrewの雰囲気を知っていただく・社内コミュニケーションについて考えるきっかけとなれば嬉しいです。

課題: 小さい組織に存在する、多数の暗黙の了解

多くの成長中の企業と同様、弊社では毎月数名新メンバーが入社しているのですが、あるタイミングから新メンバーと昔からいるメンバーでSlackでの発言量が違ったり、新メンバーがSlackの使い方で戸惑う様子が観察されました。

新メンバーに話を聞くと、入社時の説明に含まれていない暗黙の了解とされている独自のコミュニケーションの風習が複数存在し、それらの把握が難しいようでした。数名の組織だったときからいる人は風習が生まれる過程を見ていたので、無意識的に共有されていたのです。

数名規模だった頃。コタツで会議をしていました

最近の写真。全員写っていないですが、現在社員で35名程です

例えばSlackのメンション一つ取っても、組織によって@hereや@channel を使う頻度、メンションを飛ばして良いタイミングが異なるようで。実際弊社でも、一部のメンバー間では「いつでもメンションを飛ばしても良い、ただしメンション通知をオフにするのも自由」との認識が共有されていましたが、ドキュメントにまとまっている訳ではない、という状況でした。

個々の風習自体が良くないかというと、そうではないと思います。特に弊社の場合コミュニケーション効率化のために生まれたものが多かったので、むしろ意識として共有しておきたいと思いました。

参考資料として手引きを作ってみた

そこで入社時の説明資料として、またいつでも参照できるドキュメントとして「社内コミュニケーションの手引き」を作ってみました。

本文は細かいのでここではいくつか良いなと思っている風習をピックアップします。

Slackのチャンネルに関して

- パブリックチャンネルは誰でも作って良い、適切な話題の切り出しのために作成を推奨
- あるチャンネルが不要であると判断した場合、誰でもアーカイブして良い

細かいw でも「作っていいのかな？」「アーカイブしていいのかな？」みたいな迷い、地味にありそうです。

Slackの分報に関して

### 分報の内容
- プライベートなこと・感情面をつぶやいても良い
- 「分報」だからといって毎分書き込む必要はない、つぶやくペースは人それぞれ
- 全員が全員の分報を常に見ている必要もない

### メリット
- 週報、日報よりスピード感がある
- 誰が知っているか分からない問題があったとき分報につぶやくと拾ってもらえたりする
- 他メンバーの考えを知れる
- どこに何をつぶやけば良いか分からない新メンバーのオンボにも向いている

### 分報のデメリット
- チャンネルが細かく分かれるため情報が蛸壺化しやすく、オープン文化を阻害

### デメリットを解消するためのルール
- 業務に関するディスカッションや連絡は分報ではなく当該チャンネルに移動する
- 意図せず分報で業務に関連する会話が始まってしまうのは仕方がないが、ディスカッションに発展するタイミングで気付いた人が当該チャンネルに会話を移す

弊社は分報が盛んなのですが、そのメリットもデメリットも過去に議論したので言語化しておきました。実際、業務連絡は分報から該当チャンネルに移す、などは割と徹底されています。

Qiita Teamに関して
- 業務に関する知見をQiitaにまとめて共有することは偉い
   - 属人性、情報格差を防ぐ

上記に表される「情報格差を作って個人だけ強くなるのではなく、積極的に共有して皆で強くなろう」という空気感を個人的には日々実感しています。それも明言化することで継続させていければ嬉しいです。

本文はこちら

手引き内で参照されているSlack周りのルール・活用法はこちら（こちらの内容はほとんど私以外のメンバーが考えた）

手引きのメリット

みんながここに載っていることを実施すれば、組織全体のコミュニケーションコストを抑えられるのではないかと思います。

特にターゲットとしているのは前職でオンラインコミュニケーションが少なかった人や一人ひとりの発言力が大きい組織に不慣れな人です。迷いそうな点を事前に明言化することで、考えることが減り、楽に発言できるようになったりしないかなと目論んでいます。

手引きのデメリット

風習を言語化すると、ドキュメントの形骸化を防ぐための運用コストが生まれます。これは仕方がないので、実際運用してみて費用対効果が悪ければしれっと手引きごと消すかもしれません。

また、言語化することによって本質的でない場面で恣意的に引用されたり、警察活動のようなことに無駄にコストを割く人が現れるかもしれません。これを防ぐために、「強制力のあるルール」ではなく誰でも編集可能な「参考ドキュメント」程度の立ち位置であることを強調したいです。（Slackに関しては一部ルールと断言してますが命名規則等はルール化しないと機能しないので仕方がないとします）

最後に

ここまで書いておいてアレですが、そもそもドキュメントをじっくり読む行為がエンジニア以外の職種では当たり前ではなく、ハードルが高そうな気がしています。

ぶっちゃけまだ社内でも浸透していないので、今後も浸透しなければ他の方法で課題を解決していきます。

内容自体は弊社の様子を表していると思うので、何かの参考になれば嬉しいです。