広報担当の大木 @makiziii6です。
以前エンジニアの荒木との雑談の中で、一つの見解が一致して盛り上がったことがあります。それは、ビルディットに入社してコミュニケーションのオープンさにカルチャーショックをうけたけれど、そのことに好感をもったということ。
IT業界初心者のわたしはともかく、エンジニアの荒木も同じように感じていたことが意外でした。聞くと、他業界と同じように根回しや忖度が必要なIT企業も多いそう。
そして弊社でも、コミュニケーションがオープンに展開していくための仕組みを意識的に作っていること、そこに個々の意識が加わってそうなっている、ということがわかりました。
そこで、ビルディットがどんなふうにオープンで、エンジニアにとってどんなメリットがあり、どんな工夫や仕組みがあるか、をまとめました。
「オープンコミュニケーション」な場面。
職種と勤務形態問わず、全員参加の朝礼と終礼
人数が多い日でも10数人のわたしたちですが、エンジニア・デザイナー・広報、職種で分かれたりせずに朝礼は近くにいた人とランダムに2人1組になってその日の業務予定を報告し合います。終礼は、全員で輪になって1人ずつ今日やったことの報告。
新型コロナウイルス感染症(COVID-19)流行以前のオフィス出社のオフラインも、現在のフルリモートなオンラインでも、ベースは同じ運用です。
フルリモート下の現在ではこれまでより少し意識的にコミュニケーションすべく、朝礼は3~4人のブレイクアウトルームに分かれて詳しめの業務説明と数分の雑談を。元のセッションに戻り、部屋ごとに代表1人がメンバーの業務を説明する、というミニワークっぽいこともします。
全員でなるべく各プロジェクトの状況や取り組みを共有しよう、興味を持とうという意図もあります。
月に1度のパワーランチ
パワーランチとは月に1度、社内みんなで事業やプロジェクトにまつわることをざっくばらんに話そうというランチ会です。
プロジェクトの話は基本的に機密事項で外食ランチでは話しにくいので、コロナ以前の出社時は社内でちょっと豪華めなお弁当を社内で食べていました(会社負担でした🥳)。
今は各々自前で食事を用意しなければならないのですが、パワーランチの日はランチタイムを合わせて継続しています。
プロジェクトのコミュニケーションは全てGitHubに集約
代表の富田が書いたこちらのブログ でも言及していますが、プロジェクトの初期フェーズでもしっかり定例のミーティング設計を行い、そこでのアジェンダや議事録にコミュニケーション中でのトピックスも記録してGitHub Issueに随時保存していく方法をとることが多いです。
フェーズごとに変化していくメンバー構成でも、最小限のツールを見ることで認識共有ができて、新しいメンバーも不安感なくチームに入ることができます。
SlackではDMが推奨されない
各プロジェクトに関わることはもちろん、雑多な話はほぼSlackの該当チャンネル内で行います(チャンネルごとに参加メンバーの個別設定はあります)。
例えばプロジェクトの実務上の指導やフォローを口頭で話したあとに、Slackにも記載しておくという運用をして、知識やノウハウが属人化しないようにしています。
基本的にDMは使用していません。
私は以前勤めていた会社のいくつかで経験がありますが、何かの承認を得たり企画を進めたりするときは連絡する人の順序を考えて根回しする、といったことが会社によっては常識ですが、ビルディットの場合はオープンなチャンネルの中でオープンに・忖度なしで話します。
エンジニアにとってのメリットは。
小規模な組織での理想は、全員が知識や情報を共有して同じ温度で組織運営にコミットすること、そのためにはコミュニケーションはオープンな方が良いに決まっています。
しかしエンジニアにとってもそれが良いかどうかは別に考えるべきかもしれません。エンジニアにとって、コミュニケーションよりとにかく自分の技術だけに集中したい、という価値観もあるはずです。
冒頭で紹介したように荒木からは「オープンコミュニケーションであることに好感を持った。」と聞いていたので、良さをどう感じたのか改めて聞いてみました。
朝礼や終礼が多職種合同であることの利点
たぶん、みなさんが想像するよりも良い、です。
実は、当初、正直なところ億劫だなと思っていました。僕自身はそれほどコミュニケーションが得意じゃないのが理由です。
仕事で関わりがある人とは、十分やりとりしています。多職種合同で直接プロジェクトで関わらない人と喋るのって、仕事を進める上でどういう意味が発生するのだろう、と疑問に思いつつはじめは参加していました。
ただ、仕事にも効用があるのですよね。これ。特に、難しい業務では必要です。
仕事で、わからないことがあったときは、わかる人に聞こう！というのは定石だと思います。難しい業務ならなおさら。
その時、実際、日頃コミュニケーションを取っている人であれば、チャットなどですぐに質問することで解決への道筋を短縮できます。しかし、ただ、その人が直接関わっていない人の場合は、一瞬の躊躇があるので、コミュニケーションの障壁が1個生じます。
朝礼や終礼でコミュニケーションを取っているというのは、この障壁を1つ取り除ける効果があると思います。
多職種合同の朝礼や終礼により、いつか頼りになるメンバー全員と交流することで、いつ誰に話しかけてもいいんだなという心理的安全性が生まれるので、オープンコミュニケーションの土壌を形作る上で、利点を感じます。
パワーランチで他プロジェクトの話を聞くことの意味
個人的には、楽しくみんなでご飯食べようーというのが第一（笑）。
で、会社の事業全体の理解が深める、で、それ以外に利己的な目的をもって参加しています。
それは、困ったときに聞ける人を探す。です。
パワーランチは、月1回、食事しながら、肩肘張らない雰囲気で自分のプロジェクトについて気軽に共有するというのが目的の会です。
朝礼、終礼よりももう少しつっこんで、それぞれのプロジェクトについて、関連するリソース（人・技術）の情報を入手することができます。これにより、困ったときに、誰に聞けば良いのかという道標が自分の中で作る事ができます。
たとえば、この言語のことなら・・・デザインの事なら・・・広報のことなら・・・機械学習なら・・・Vueならとかです。
パワーランチを通して、自分の中での各分野専門家リストの更新が捗ります😏
GitHubでの業務管理で、特徴的なこと
GitHubを中心にしています。業務管理（課題管理や進捗）は全てGitHubです。
GitHubで表現しづらい場合、表形式でのまとめなど。その場合は、Google スプレッドシートでまとめて、そのリンクをGitHubに貼ります。ただ、少なくともGitHubから全ての情報にたどれるようにするということを第一にしています。
今メインで関わっているプロジェクトは、外部のエンジニアさんが多いチームです。なので、リモートでのコミュニケーションが中心です。
定例ミーティングでは必ず、Zoomの画面共有機能でGitHubのIssuesを開き、議論の内容をオープンに参加者全員に見えるように、随時打ち込みつつできるだけ画面に表示ながら行っています。
リモートで協力してくださっている方々の時間を同期的に拘束させていただいてますので、効果的なミーティングとなるよう心がけたいためです。
もちろん、随時といっても逐語録を作りたいというわけではなく、要点や、決まったことが画面に打ち込まれます。
リモートだと、非言語的な情報が伝えられませんので、議論している内容を言語化して画面に映しながらおこなうことで、限られた時間でプロジェクトチーム全体での合意を形成をスムーズにおこなえます。
まだまだ改善の余地がありますが、良いミーティング体験と感じてもらえることにより、次のミーティングへの積極的な参加のきっかけとなり、ミーティング中のディスカッション・コミュニケーションが活発になるのではと思っています。
”オープンな”コミュニケーションは、普通のコミュニケーションと何が違うか
非同期で頻繁に顔を合わせないプロジェクトメンバーでも、実務で直接やりとりがないメンバー同士でも、いつでもコミュニケーションが発生する環境になっていることじゃないかなと。
前述の通り、メインで関わっているプロジェクトは、週1でのミーティング以外は、非同期のコミュニケーションで進みますので。Slackが、重要なツールです。
Slackでわからないことや、疑問点や困ったことなどを書き込むと、レスポンスが素早く返ってきます。レスポンスの内容自体は、回答そのものもありますが、「見たよ！」「考え中！」というようなSlackの絵文字など様々です。
お互いに小さなレスポンスを素早く拾いあうというのが重要だと思っています。
それに普段仕事上では直接的なやりとりがあまりない人からもコメントやスタンプがくることも多いです。
僕はここにチームを感じます。自分一人だけで悩んでいるわけじゃないよね！というような気持ちです。
直接の回答がなくてもいいのです。見てくれている！という事実。リモートなのですが、その場で一緒に席を並べて仕事をしているような雰囲気。困ったことがあったらみんなで考えるという一体感です。
社内全員が、直接的な関わり合いがなくとも、お互いにコミュニケーションし、助け合う土壌がSlackのやりとりからも生まれているのではと思います。
--------- 😄💬 😄💬 😄💬 😄💬 😄💬 ---------
人数が増えていくなかで「オープンさ」を維持するヒケツ。
現在フルタイムメンバー10人程ですが、それでも1年半前の4~5人の頃とは、少しずつ空気が変わります。
一般的にも、10人を超えてくるとそれぞれの役割や立場の違いが出てきて認識共有に工夫と労力が必要になるといいます。
そうした変化があってもオープンかつ密なコミュニケーションは今のところ継続できていて、また急に全員フルリモート勤務になった今も、これまでの密度を保ちながら乗り越えようとしています。
それは、上で紹介した施策が個々の意識下のみに依存するものでなく、仕組みとして運用していることが功を奏していると感じます。
- 職種の壁を無くして、異職種同士がお互いの仕事に興味を持つようにするため仕組みとして、全員参加で業務共有をする朝礼・終礼を運用している。
- オフライン・オンライン問わず、誰でも気軽に話しかけて意見を聞いたり、レビューを頼んだりする意識的な障壁をなくす仕組みとして、毎日15時にレビュータイムを設定している。Slackで通知もするので、メンションなど気にせず送れる。
- 現在フルリモート になり、Slackでのレビュータイムだけでは物理的な雑談が減るので、月水金はZoomをつなげて雑談している。(その他、Discordを常時接続していることも。このあたりは試行錯誤中)
- ツールは、Slack、GitHub、Zoom、Discordを主に全員が使用。Slackでは関わってないプロジェクトのチャンネルにも目を配り、お互いに知見を共有しあい、1人で悩まない工夫をしている。
- 月に1度、ゆるはち.it(詳しくは以下のリンクご参照ください)という、「八王子で先端的なITの話をゆるく共有する場」をテーマとしたIT勉強会を開催し、エンジニアだけでなくメンバー全員で運営している。社内のコミュニケーション向上は主目的ではないが、エンジニアだけでなくデザイナーや広報も含めて1つのことに取り組むことは良い仕掛けになっている。
一つひとつは些細な仕掛けですが、それらが積み重なってメンバーの意識的な行動にも繋がるサイクルになっています。
ビルディットは、エンジニアとデザイナーが協働する体制があり、それがより良いプロダクトを作るベースになっていますが、仕事上で直接関わる前から、どんな人か・どんなスキルや知見があるのかを知れる環境があることが、「協働」するための強いパイプ作りになっているようです。
コミュニケーションが得意な人を求めたいわけではありませんが、小規模の会社で、事業や組織運営の当事者としてメンバーと関わりながら、より良いチーム作りに参加したいと思う仲間を増やしたいと思っています。
