MIXIデザイン本部内に設けられたエンジニアグループ (コミュニケーションエンジニアリングG) では、プロモーション関連サイトのデザイン実装を主な役割として担いながら、組織の活性化や情報共有の向上を目指し、コミュニケーション課題を技術視点で解決することにも取り組んでいます。
各種ツールでの情報を集約しながら、デザイン本部や各事業部との連携しやすさを高めています。
組織や事業が拡大するなかでコミュニケーションパスが複雑になってしまったり、リモート環境での情報共有がうまくいかないことで、「情報の非対称性が生まれる」「会話量が減少する」「意思決定スピードが落ちる」などの状況が生まれやすくなってしまいます。
このようなコミュニケーション課題に対して、組織内のエンジニアグループとしてどのように解決に取り組んでいるのかをまとめることで、組織の活性化や、情報共有の効率化に課題感を持つ方に少しでも役に立てると嬉しいです。
MIXIには250名を超えるデザイン職が在籍し、全社横断的な組織であるデザイン本部として、各事業部と連携しながら事業を推進しています。
関わる事業も多く、デザイン職がそれぞれの持ち場で業務に集中したり、リモートワークが広がっていくなかで、次のような声も上がってくるようになってきました。
事業部ごとに情報共有の仕方やタイミングが異なり、キャッチアップしづらい
事業部ごとに利用ツールや使い方が異なり、進捗やリソースの把握が難しい
対事業部と比較し、デザイン本部内でのコミュニケーションが少なくなっていた
例えば、事業部によって「Slackのスレッドを多用する / 推奨しない」「デザインツールはFigma / Adobe XD」「タスク管理はJira ／ スプレッドシート」などの方針の違いがあったり、Slack上で案件の依頼があったがチケット化されずに流れてしまうこともあったりと、細かなコミュニケーションのズレが各所で起こっている状態となっていました。
解決のアプローチとして、コミュニケーションの型を統一するという抜本的な方法も考えられますが、事業部ごとにワークフローやスタイルが確立されている部分もあるので、横断組織としてはそれらに柔軟に対応しながら、うまく連携して事業推進に集中できる状態を目指す方が適切だと考えました。
また、常に様々な場面・スタイルで生まれるコミュニケーションに対して、できる限りレバレッジの効く形で変化を生むため、エンジニアリング観点から解決に取り組むことにしました。
このような背景から、コミュニケーションエンジニアリングGとして課題解決に取り組むことになります。ここからは、いくつか例を挙げながら実際の取り組みをお伝えします。
1つ目の例として、「デザインやタスク管理に色々なツールを使っているが、通知に気が付きにくい」という課題を解決する仕組みをつくりました。
FigmaやZeplin、Jira、GitHubなどをSlackと連携し、コメントを通知することは誰でもできるのですが、メンションの形式が各ツールで異なると、Slack上でメンションとして機能しません。そのため、自分宛の通知も流れてしまって気が付けない状況が生まれていました。
対策として、各ツールでの通知内容から@メンションを取得し、Slackのメンション形式へ変換するbot「@mention-bot」を作成しました。 通知の本文に@メンションが含まれていれば、Slackのスレッド内で代わりにメンションを飛ばしてくれます。Slackでメンションがつけば、アクティビティからすぐに確認できるため、各ツールからの通知に気が付きにくいという状況が改善されました。
他にも、Slackのスレッド上でのやり取りが続き、他のメンバーが状況を追いづらかったり、意思決定された内容を知らなかったといった状況があったため、定期的にチャンネルに進捗が投稿される仕組みをつくりました。
Slackには、スレッドでの投稿をチャンネルにも展開する機能があるのですが、その機能を知らない場合もありますし、いつどのタイミングでその機能を使うかはその人の判断に任せられます。そのため、仕組みとして定期的に展開されることで、自然と情報共有がしやすくなっています。
Webサイト制作における、残タスクや進捗状況を分かりやすくする仕組みもつくりました。
Webサイトの仕様書は基本的にスプレッドシートで作る文化があるのですが、不具合報告やチケット管理を行うツールは統一されていませんでした。
Jiraを使用する場合もあるのですが、QAチームなど一部のメンバーは積極的にチケットを起票する一方、Jiraに慣れていないメンバーは起票せずにSlackで不具合報告や依頼を行うこともあり、全体での残タスクや進捗が把握にくいという運用面の課題がありました。
そこで、スプレッドシートでの仕様書と不具合報告場所を一体型にし、更新されたらSlackに通知するようにしました。
具体的には下図のように、スプレッドシートに更新を加えるとSlackの専用チャンネル (ex. #案件名_通知部屋) に通知されるようになっています。
さらに、回答待ち、確認待ち、完了などのステータスごとに色分けし、スプレッドシートやSlackでの表示に対応させることで、状況がひと目で分かるようにしています。
このような仕組みにすることで、以下のような効果が得られました。
「テキストが1文字違う」のような軽いタスクを、誰でも気軽に書き込める
チケットを切る程ではない細かな粒度のタスクも一元管理され、全体を把握しやすくなる
更新をSlackですぐに把握でき、会話もしやすいので、対応漏れも大幅に減少
Slackで過去の不具合事例も検索しやすい
スプレッドシートとSlack通知を組み合わせた仕組みはバランスが良く、制作メンバーに定着して継続的に活用されています。
このような業務上の課題解決に取り組んでいくなかで、組織内の交流やコミュニケーションの促進に対しての相談ももらうようになりました。
例えば、当時デザイン本部内のメンバーから「コミュニケーションや雑談の機会を増やしたい」という相談をもらい、雑談用の有料アプリの導入も考えられましたが、まずは必要性や実際に効果があるかを確かめるために、簡易アプリを自作してみました。
作成期間は1日、ChatGPT、Googleスプレッドシート(GAS)、Slack Appを駆使して、1日1回対象チャンネルのメンバーにランダムに質問を飛ばしてくれるというミニマムな仕様です。
実際に雑談が生まれるか、それによってコミュニケーションが増えたり相互理解が促されるかという検証の位置付けもあったため、1ヶ月ほど運用したうえで効果検証を実施しました。
結果として以下の効果が生まれており、継続的に運用をしながら頻度や、質問の内容などを改善していくことになっています。
アンケートを実施したところ、所属メンバーの半数以上が継続を希望
満足度が高く、有料アプリ契約はせず、自作アプリをそのまま利用することに
雑談アプリを入れる前後で、Slackでの会話が「2.5倍」に増加
現在は、デザイン本部の2グループ1チームで活用中
このような取り組みを続けてきた結果、コミュニケーションが取りやすくなった、業務を進めやすくなった、部内だけでなく広い範囲で導入してみたいという声も生まれるようになってきました。
現在は、現場で起こっている問題を適宜解消していくというスタイルで進めており、トライアンドエラーを繰り返しながら、各メンバーが心地よく、事業推進に集中できる環境を作っていきたいと思います。
また、顕在化している問題が解決されていってもその先でまた別の問題が生まれてくるでしょうし、メールからチャットツールに移行したり、タスク管理ツールもどんどん新しいものが出てきているように、最適なコミュニケーションのフォーマットは時代に合わせて変化していきます。
例えば今後は、AIの技術発展が進み、様々な場面でAIを活用していくことになると思いますが、そのなかでの上手い付き合い方や、いかに人の心を尊重したコミュニケーションを取れるようにできるかは新しいチャレンジになっていくと思います。
このように、コミュニケーション上の課題は完全に解消されることが無いと考え、状況に合わせて模索しながら仕組みに落とし、仕組みを通して促されていた行動が習慣となり、自然とより良いコミュニケーションが生まれていく土壌を作っていくことが重要だと考えています。
また、今回ご紹介したプロジェクトでは、組織内の人を対象としてコミュニケーションの課題解決に取り組んでいますが、転用していけば事業に活かせる部分も多くあると感じています。
今後も、事業と組織の両面から「豊かなコミュニケーションを広げ、世界を幸せな驚きで包む。」というMIXIのパーパスを実現できるよう取り組んでいきたいと思います。