本記事は BASE アドベントカレンダー 2023 の5日目の記事です。
はじめに
こんにちは。
Shop to Shop チームでマネージャーをしている髙嶋です。
役割としてはエンジニアリングマネージャー（以下 EM）と言われるものを想像していただくとイメージしやすいかもしれません。
そんな私から、開発チーム内で取り組んだ10個の実験もとい取り組みについてご紹介させていただきます。
開発プロジェクトを遂行するチームの開発現場をスコープにした話になりますが、一つでも参考になるものがあれば幸いです。
ちなみにチーム構成としては PdM 1名、デザイナー1名、エンジニア5名、EM 1名（私）の総勢8名となります。
最後まで読むのが億劫になる可能性もあるので、この記事で伝えたいことだけ先に列挙しておきます。
- 出社（オフライン）とリモートワークの使い分けが難しいためにチームとしての活動はリモートワークに振り切ってみたが、それが自分たちの働き方を見つめ直すキッカケになった
- 雑談サイコー
- Slack は便利、ゆえに付き合い方や捉え方も様々で難しい
では早速参りましょう。
取り組み一覧と評価方法
まず、何に取り組んだのかその一覧をご紹介します。
詳細が伺い知れないものもあるかと思いますが、後述するのでここでは割愛させてください。
本記事では No.5 まで、明日の記事でそれ以降を取り上げさせていただきます。
| No. | 取り組んだ内容 |
|---|---|
| 1 | チームとしての出社日運用の廃止 |
| 2 | 雑談の活性化 |
| 3 | No Slack Day（日単位での原則 Slack 禁止） |
| 4 | No Slack Time（時間単位での原則 Slack 禁止） |
| 5 | オンライン会議ツールを Google Meet からハドルミーティングに変更 |
| 6 | タスク管理ツールを Notion から GitHub Projects に変更 |
| 7 | スクラムイベント時に使用するツールを FigJam から GitHub に変更 |
| 8 | スクラムイベント実施日を毎週水曜日から金曜日に変更 |
| 9 | デイリースクラムを4日間から2日間に削減 |
| 10 | GitHub Discussions の活用 |
そしてどう各取り組みを評価、つまり効果測定をしようかと考えたときに、定量的な形で表現できると一目瞭然なので望ましくはありました。
例えばベロシティや Pull Requests 関連の数値、あるいは稼働時間といったものを計測すること自体はそれほど難しくありません。
しかしそれらは様々な要因が絡み合って影響されうるものであるため各取り組みと結び付けて結論づけるのは難しく、なんとも言えない結果になるであろうことは容易に想像できました。
そのため今回はメンバーからの定性的な評価に重きを置くことにしました。
最終的には各取り組みに対する評価を以下の基準でつけ、なぜそう思うのかというコメントと併せて回答するアンケートを実施しました。
| 点数 | 意味 |
|---|---|
| 4 | 満足（続けたいし、現在の運用にも概ね満足している） |
| 3 | やや満足（続けたいが、一部運用は見直せないかと考えている） |
| 2 | やや不満（積極的にやめたいというわけではないが、少なくともあまり効果は感じていない） |
| 1 | 不満（期待していた効果がないのでやめたい） |
さて、前置きが長くなってしまいましたが、ここから各取り組みについてその詳細をご紹介させていただきます。
①チームとしての出社日運用の廃止
何をやったかの前に、まずは弊社としての前提、そしてチームとしての前提を先にお話しなければなりません。
弊社の働き方としてはハイブリッドであり、フルリモートではありません。
そのため会社としても出社を対面でのコミュニケーション機会として有効に活用していくことなどが推奨されています。
ただ、その出社頻度や活用方法については各チームに任されており、私たちのチームにおいては毎週のスクラムイベント実施日を出社日として定めました。
単にスクラムイベントを実施するというだけではなく、それ以外のオフラインイベントを同日に開催したり、あるいはチームメンバーとランチに行ったりするなど一定活用はできていたと思います。
結論、それをやめました。
誤解のないように補足しておくと、あくまでもチームとして定期的かつ同期的に出社することをしないだけで出社そのものを禁止するわけではありません。
各々の判断で出社したい日は自由に出社する形をとっていますし、あるいは互いに声がけしてスポットで出社して一緒に何らかの活動を行うといったケースもあります。
出社日運用を廃止した背景として、同一プロジェクトを遂行するチームメンバーであっても組織図上は別チーム所属の方がいる、また雇用形態等の事情により遠方で従事されている方もおり、出社することの足並みを完全には揃えられないといったことがありました。
そうなると結局はスクラムイベントもオンラインとオフライン混合の MTG であることに違いなく、その体験の違いもあって十分な効果を生み出せているとは言えない状況でした。
それならいっそのことリモートワークに振り切ってしまい、環境差異を極力なくそうという判断をしました。
メンバーからの声としては以下のようなものがありました。
- スクラムイベントの日の出社をやめたからといって、特段困るようなことはなかった
- 前提として、メンバーの関係性を一定築けていたからできたというのはあったかもしれない
- 一緒にランチに行くなどして親交を深めていた側面もあり、そういう機会は減ってしまったのでたまにはオフラインで会う機会も作りたい
結果：4点満点中3.4点で継続
これが以降の取り組みの布石となっていきます。
②雑談の活性化
チームとしての出社日運用を廃止したことで、業務外のコミュニケーション量が減ってしまい、そこから翻って業務にも悪影響を及ぼすのではないかという懸念がありました。
リモートワーク下において、雑談の大切さといったことも一般的に語られることが多いように感じます。
そこで仕事云々の前にまずはお互いをもっと理解することで心理的安全性を確保しようと、チームで雑談ができる random チャンネルを Slack 上に用意し、積極的にコミュニケーションをとってみることにトライしました。
元々チャンネル自体は存在していましたがそこまで活用されていなかったのと、「雑談しよう！」と突然言ってもできるものではないかなと思い、最初は私が中心となって話題を投稿することから始めてみました。
併せてカジュアルに発散したいもののアウトプット場所を Notion 上に用意し、それを当該チャンネルと連携することでさらなる活性化を図ることにしました。
結論、これが一番受けが良かったかもしれません。
正直やる前はどういう結果になるのか、どういった効果を生み出せるのかについて半信半疑でしたが、実際にやってみてその良さを感じ取ることができました。
当初は私が発信して始まることの多かった会話も、徐々にメンバーからトピックを提供する場面も多くなっていきました。
メンバーからの声としては以下のようなものがありました。
- チームメンバーとの距離が近くなり、仕事中のちょっとした息抜きにできてよかった
- 以前よりチームメンバーのパーソナリティを知ることができ、雰囲気もよくなったように感じる
- 仕事に関係のない話をする場ができて良かったし、非同期で強制されるものでないことも併せて良かった
結果：4点満点中3.9点で継続
次は業務上のコミュニケーションの話へと繋がっていきます。
③No Slack Day（日単位での原則 Slack 禁止）
ここもまずは取り組み自体について話す前に、BASE 組織全体での前提について話しておく必要があります。
現在、毎週木曜日の午後は No MTG Day となっており、原則会議は非推奨となっています。
私たちのチームとしてもその効果は一定感じつつも、作業の分断という意味では決して会議だけではなく、Slack もそうではないかという仮説をたてました。
会議をしない分、それが Slack 上に移って効果が半減してやいないかといった仮説です。
そこで木曜日の No MTG Day に合わせる形で、極力チーム内での Slack コミュニケーションを抑えることに取り組んでみました。
結論、この取り組みはやや評価が分かれる形になりました。
Slack が業務のど真ん中にあるツールであること、人によってツールとの付き合い方にも微妙な違いがあること、あるいは働き方のリズムも違うことなどから一律のルールを設けることの難しさがありました。
メンバーからの声としては以下のようなものがありました。
- 木曜日が MTG や Slack を気にせず集中できる時間になったのがよかった
- 開発作業を一人で集中して行いやすくなり、そうできるよう前日のうちにそのための準備をするような動き方ができた
- Slack でとっていたコミュニケーションが、今度は GitHub の Issue 上などに移っただけのような印象を受けることがあった（目的が Slack を使わないことになってしまった）
- その日のうちにカジュアルに話しておきたいことはどうしても発生するのでモヤモヤが残った
- そもそも Slack の通知が作業の妨げになっているとは思っておらず、非同期コミュニケーションであることでその受け手が自分のタイミングでレスできる点にメリットがあるので、作業効率とはあまり相関がないように感じた
結果：4点満点中2.6点で廃止
本施策はやめることにしましたが、Slack との付き合い方についてはもう少しだけ粘ります。
④No Slack Time（時間単位での原則 Slack 禁止）
日単位で禁止するのはちょっとつらみも大きいということであれば、時間単位ではどうかと考えました。
具体的には14時以降終日という形から始め、その後14〜17時に変更して検証しました。
結論、またまた評価が分かれることになりました。
結局本質的な課題感は変わらず存在し、一定メリットはあるものの、少なからずデメリットもあるといった状態です。
メンバーからの声としては以下のようなものがありました。
- No Slack Dayより No Slack Time の方が1日の中で作業計画が立てやすかった
- 14時まで話していいが故にそのまま続きの会話をしたくなることがあり、No Slack Day よりも切り替えが難しく感じた
- タイムゾーンが違うわけではないがリモートワークだと個々人の行動の柔軟性は増すので、オフラインで同じ場所にいるといった形じゃないとチームとしてはワークしないかもしれない
結果：4点満点中2.4点で廃止
いったんこれをもって Slack の制限という形での取り組みには区切りをつけることにしましたが、最適解を探っていく試み自体は続けていく予定です。
⑤オンライン会議ツールを Google Meet からハドルミーティングに変更
まずこちらも社内全体での傾向にはなりますが、オンライン会議ツールとしては Google Meet がメインで、私たちのチームも基本的にはそうでした。
しかしながら上述したように業務上コラボレーションする場としては Slack が最も多く、コンテキストに応じたチャンネルのハドルミーティングを使用することで会議参加をシームレスに実現できるとともに、参加者の分割や移動といったこともライトに行えるのではないかと考えました。
また、ハドルミーティングのスレッドなどに会話したことを議事録としてタイムリーに残せる（議事録を別ツールに探しに行くこともなくなる）ということも理由の一つです。
結論、この取り組みは概ね好評でした。
もちろんそれぞれのツールの良さはありつつも、会議に対する要求がハドルミーティングでも担保できると改めて理解できたことが大きかったのではと思います。
メンバーからの声としては以下のようなものがありました。
- Slack でのテキストコミュニケーションからシームレスに口頭での会話に移行できる
- 会話の中で出たメモやリンクなどをスレッド内に残すことができ、後から検索することも容易である
- 会議の性質によってはカジュアルにリアクションを取りたいシーンがあり、Google Meet の方がその表現はしやすかった
- ブラウザの特定タブの画面共有や、開始時にデフォルトでビデオ ON にするといったことがハドルミーティングではできず、ちょっとした不便を感じた
結果：4点満点中3.5点で継続
まとめ
取り組みのご紹介という意味ではまだ折り返し地点ではありますが、一つひとつは小さくともトライを積み重ねることで、何か新しい取り組みを始めることに対するチームとしてのハードルが下がったように感じます。
メンバー構成的にも一定期間同じような顔ぶれであった、またその業務ないし開発スタイルについてもある程度固まってきていたことで、効率性はありつつも一種の停滞感のようなものも同時に感じていました。
別にめちゃめちゃ悪いということがあるわけでもなく、かと言ってすごくいいというわけでもなく、なんとも評価しづらいといった感覚でしょうか。
繰り返しにはなりますが、今回の取り組みを通じてその状況をいくばくか打破でき、今後の活路を見出す機会になったと捉えています。
明日は本記事の続編をお届けします。お楽しみに！
