🧑‍🤝‍🧑

AppBrew風 社内コミュニケーションの手引き

💡
行動指針を実現するための工夫として生まれたコミュニケーション方法をご紹介 入社時に読んでおくときっと便利!
(※外部公開中)

Slack

チャンネル

  • 公序良俗に反さない範囲であれば、すべての人にチャンネルを作り、自由に発言する権利があります
  • 適切な話題の切り出しのために作成を推奨

分報(#times_◯◯)

分報とは

  • Twitterのように使う個人のチャンネル
  • 今やっていること・困っていること・考えていることをつぶやく
  • ストレスなく自由に発言できる環境

分報のメリット

  • 週報・日報よりスピード感がある
  • 誰が知っているか分からない問題があったとき分報につぶやくと拾ってもらえたりする
  • 他メンバーの考えを知れる

分報の内容

  • プライベートなこと・感情面をつぶやいても良い
  • 分報だからといって毎分書き込む必要はない、つぶやくペースは人それぞれ
  • 全員が全員の分報を常に見ている必要もない(※重要)
  • 業務連絡は分報では行わない

メンション

  • 厚かましくメンションしよう、メンションしなかったせいで流れてしまうのは良くない
  • 誰をメンションすれば良いか分からないとき
      1. Slack内を検索し、関連しそうな人を探して聞いてみる
      1. わからなければ、それっぽいチャンネルで @here してみる
      1. それでも駄目ならメンターや分かりそうな誰かに相談する
  • 深夜・週末もメンションOK(ただしSlack通知オフにするのも自由)
  • 然るべきメンションがなければ、generalチャンネルであっても本人の分報であっても「見ていない」ことに責任は問われません

DM

  • 基本禁止
    • 業務に関する情報がDMに溜まっていくと、社員間で情報格差が生まれるため
    • SlackのDMに限らずLINE、メッセンジャー、SMSなどの二人きりで話せる媒体を含む
  • 事業に関わらない事務連絡やプライベートな話はOK(待ち合わせの連絡など)
  • 他メンバーからDMが来たが後述の例外に当てはまらない場合、「オープンチャンネルでお願いします」と言う責任が受取側にもある

リモート時のSlack活用

  • リモート推奨。
  • オフィスにいない分、Slackを開いたまま作業すること推奨
  • たまに今やっていることを分報に書くと、連携しやすい
  • やりとりが3回以上続いたらHuddlesで通話をして、結論をテキストにまとめる

使い方その他

  • 情報過多には、検索・フィルタ・通知をうまく活用し、各自で対応しましょう(メールのフィルタなどに対応する機能などが存在します)
  • チャンネルの入退出なども自由なので、忖度せず整理しましょう

Notion

  • 情報をまとめて貯めていくところ
  • 業務に関する知見をNotionにまとめて共有することは偉い(属人性、情報格差を防ぐため)
  • 業務委託やアルバイトもNotionには招待している
  • 基本は「全体に公開」、社外秘情報は「coremembers」に共有

MTG

  • あくまでディスカッションの場。単なる情報共有はNotionなどドキュメントで行う
  • アジェンダ必須。ゴールや何をディスカッションするべきかMTGのオーナーが事前に用意し共有する。されていない場合は冒頭で決める
  • 無駄に長くならないよう、30分や1時間といったよくあるmtg時間に縛られず必要最低限の時間で設定(基本は30分未満・1時間を超えたら強制閉会を推奨)
  • 他チームの人でも分かる形で議事録をNotionに残す
  • カジュアルMTGはhuddles、下記に当てはまる場合はzoomを推奨。
    • しっかり議論したい(=顔出しもして、情報量を増やしてスムーズに議論したい)
    • チーム内コミュニケーションをしっかり取りたい(=コミュニケーション自体もMTGの目的になっている場合)
    • 録画したい
    • 参加者が多い(=huddleだと不安定)

定例

  • 参加必須mtgは一人週2,3までが目安(固定化したmtgは惰性化しやすいため)
  • 他チームのmtg聴講は自由 & 推奨
  • 惰性で開催・参加する必要なし、必要に応じて調整
  • 特別な理由がない限り推奨時間内(11:00-19:00)内に設定
  • 基本的にネクストアクション・前回の定例のネクストアクションの確認をいれる

全体定例

  • 週に一度だけ全社員が物理的に集まり、皆に知って欲しいこと(OKR進捗、今やっていること、次やる予定のこと)を各チームから共有する
  • 1チーム2分
  • 発表者への質問は推奨
  • 全体定例ではトピックス共有と質問のみ・意思決定はなし
    • 全体定例は人が多い(> 35人)ので、意思決定には向かない。相談・決めなきゃいけないことは経営戦略会議か関係者を集めて決める

臨時

  • 随時自由開催

1on1

  • 任意の人同士で同意のもと開催可
  • 開催の際には開催する旨をオープンにする(Google Calendarに登録、分報などに開催した旨を残す)
  • 公開できる部分に関しては議事録を残すこと推奨

人事1on1

  • 新正社員に入社1~2ヶ月で適宜実施
  • 明確に相談したい緊急性・重要性の高い相談事項があった場合

データ活用

  • データ量とデータ活用力こそがAppBrewの競合優位性
  • 定性的な仮説はデータがなくても直感をもとに考えることができるが、データはときとして直感に反し、データを持つ者しか知り得なかった仮説を与えてくれる
  • とはいえすべての仮説がデータ起因でなくても良い。定性的にしか生まれない仮説もある
    • 定性的な仮説も、検証時にはデータを見るべし
  • 手で数値を打ち込む作業は非効率、なるべく避けたい
    • Redash、Spreadsheet、Google Analyticsなどを必要に応じて活用し、自動化すべし

Redash

  • LIPSのユーザー行動データを誰でも見ることができる
  • 主要Dashboard:
    • Main KPIs(Daily Active User数、Monthly Active User数、新規ユーザー数など)
    • DAUU & PV (LIPSアプリの画面ごとのUser数、PVなど)
    • App Product KPIs (LIPSアプリの継続率の副指標)
  • 今までに書かれたQuery一覧
    • 他のメンバーが特定のデータ(例: 記事一覧、今月の新規ユーザー一覧、etc.)を表示するために書いたQueryが検索できる
    • 見たい情報がDashboardに載っていなかったら、Queryを検索してみると良い