2024年12月7日に投稿された記事です。
dotD Advent Calendar 2024 7日目です。
dotDではアジャイル開発を推奨しています。
プロジェクトの性質によって細かい手法は異なりますが、プロダクトオーナー、プロダクトマネージャー、デザイナー、エンジニアが密にコミュニケーションをとり、ユーザーに提供する価値を最大化することに努めています。
アジャイル開発は、コミュニケーションを重視した開発手法ですが、リモートワークでは、どうしてもコミュニケーションが疎になりがちです。
今回は、dotD社内で試したのコミュニケーション改善の取り組みを紹介します。
アジャイルマニフェスト
2001年に17人のソフトウェア開発者が、当時の「ドキュメント主導の重厚なソフトウェア開発」に取って代わるものとして、書いたアジャイルマニュフェストは以下のようなものです。
私たちは、ソフトウェア開発の実践あるいは実践を手助けする活動を通じて、より良い開発方法を見つけ出そうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
「アジャイルソフトウェア開発宣言」(https://agilemanifesto.org/iso/ja/manifesto.html)
このうち『プロセスよりも個人との対話を』について、続くアジャイル宣言の背後にある原則の中で
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
「アジャイル宣言の背後にある原則」より抜粋(https://agilemanifesto.org/iso/ja/principles.html)
と言及されています。書籍やウェブサイトによっては、これが
「アジャイルチームは原則として同じ部屋で作業する」
と説明されています。
リモートワークにないもの
新型コロナパンデミックから約5年が経過し、みなさんの自宅には、お気に入りの机と椅子、ディスプレイ(人によっては2台以上)やその他周辺機器が揃い、オフィスよりも作業しやすい環境が整っていると思います。
通勤時間が省かれた分、家族との時間や自分の趣味の時間も確保しやすくなりました。
行動制限が緩和されてからは、旅行先からミーティングに参加することすら可能です。
しかし、出社していた時には当たり前にあって、自宅の作業スペースには無いものもあります。
受動的なコミュニケーション
オフィスでは、自分は主体的に参加にしていないが、Aさんの後ろの席でBさんとCさんが喋っているのが聞こえてくる、という事象が発生することがあります。
アジャイルが「原則として同じ部屋で作業する」という言説は、この現象による情報伝達コストの低減を狙っていると推測しています。
例えば、Slack等のテキストベースコミュニケーションで
Bさんがある質問をCさんにメンションして聞く
↓
CさんからAさんが知っているだろうと返信される
↓
Aさんにメンションして回答を求める
ということがあったとします。
もしこれが、オフィスの同じスペースで働いていたら、
BさんがCさんに話しかける
↓
話し声が聞こえたAさんがすぐに会話に加わる
というふうに1ステップ省かれていたかもしれません。
少なくとも、すぐ後ろの席のAさんにすぐ質問ができて、解決までの時間が短縮されていたでしょう。
・・・そんなに差が出る?と思うかもしれませんが、E-mailがチャットツールに置き換わった際に省略された
「お疲れ様です。〇〇です。 〜〜 以上、よろしくお願いします。」
の定型分ように、チリも積もれば大きなコミュニケーションコストの差になるのではないでしょうか。
Slackのオープンチャンネルでやりとりしているから大丈夫??
でも、テキストコミュニケーションって、リアクションのタイミングや、そもそも自分が入ってないスレッドを隅々まで見てくれるかどうかは相手次第ですよね・・・?
雑談 = 信頼の構築
「雑談は、職場の雰囲気を和らげ、メンバー同士の距離を縮めます。」
と、chatGPTは言いました。
同意です。
しかし、これをただ「仲良くなる」と解釈してしまうと、
「雑談なんて不要じゃん?無駄話してないで仕事しろ。」となってしまいます。
多様なバックグラウンドを持つメンバーそれぞれが、お互いを信頼するためには、その人の経験や期待、どんなことに興味があるのかを知る必要があります。雑談は、これらの情報を交換し、信頼を醸成する役割の一端を担っています。
新規事業やなにか新しいことを始める仲間を探す時、だれに声を掛けますか?
ほとんど喋ったことない人に声をかけるという人は多分いないと思います。
オフィス回帰の潮流に抵抗を試みる
昨今のオフィス回帰の潮流は、こういったコニュニケーション面を重要視した結果だと認識しています。
しかし、ことdotDの場合、地方に住んでいるメンバーがいたり、そもそもオフィスに全員分の座席もなかったりと、いきなり出社を推奨するのも難しいです。
とはいえ、コミュニケーション面の改善は取り入れたい、
なによりも、せっかく整えた自宅のリモートワーク環境を手放したくはない。
ということで、リモートワークでもチームを機能させるために、試しているコニュニケーション施策を紹介します。
バーチャルオフィスの導入
バーチャルオフィスツール「Gather」を導入し、オンライン上に物理的なオフィススペースを再現しました。
私が参画しているdotHatchの開発チームは基本的にいつも同じ部屋にいます。
仮想空間上であっても、同じスペースを共有することで、受動的なコミュニケーションが生まれています。
Gather上のdotHatch専用部屋
「SlackのHuddleやGoogle Meetでいいじゃん」
という声もありますが、HuddleやMeetは招待制なので、呼ばれないと入っちゃいけない感じがする一方、Gatherは同じ空間にいるだけで、会話を聞くことができます。
テキストコニュニケーションの良さ、音声コミュニケーションの良さはそれぞれあるので、ツールの導入と同時にガイドラインを作成し、Slackを使った方がいい時、Gatherで話した方がいい時をそれぞれ整理しました。
デイリースタンドアップの雑談タイム
デイリースタンドアップは、本来10分程度で、昨日やったこと、今日やること、困っていることを共有する場です。
dotHatchの開発チームでは、あえて最初の10分くらいを雑談の時間にしています。
テーマはその日のファシリテート担当がネタを振りますが、ネタがなければ
「週末の予定」とか、「Amazonのセールで何か買った?」といった他愛のないことで良いです。
こうした雑談によって、「すみません、ちょっといいですか?」と、気軽に話しかけられる関係を日頃から構築することを目指しています。
輪読会
輪読会はさまざまな企業で既に実施されていると思います。
dotDでも過去に実施していましたが、初めてプロジェクト横断・職種横断で参考になりそうな書籍を選んで声をかけてみました。
結果的に、プロジェクトもポジションも違うメンバーが集まり、本の内容だけでなく、各プロジェクトの現状や課題を共有することにも繋がりました。
Gather上でのゲーム会
Gatherには、いくつかのゲーム機能が備わっており、たまに何人かで集まって30分くらいゲーム会を実施しています。
Gartic Phoneというゲームをやってみた
dotDは自社事業、共創事業とも、複数のプロジェクトが走っており、プロジェクトが違うとなかなか会話をする機会は多くないです。
ゲーム会のようなレクリエーションは、一見すると無駄に感じるかもしれませんが、こうしたイベントをきっかけに新しい人との信頼が構築されて、個別の対話が発生するようになれば、価値があると思います。
初めての完全オフライン.camp
dotDでは事業創造合宿「.camp」を毎年実施しています。
今年は初めて、完全オフラインで実施しました。
2日間掛けて、4つのチームが同じ物理的空間を共有してアイディエーションを実施したほか、合間の休憩時間で、他のチームの進捗を覗き見できる時間も意図的に設けました。
.campで行われているのは、「価値観の交換」なのだと思います。
Seederと呼ばれるアイデアの起案者が、自分の価値観や興味を開示し、そこへの共感を基にチームが編成される。
あるいは、多様な意見に触れることで参加者の価値観が変容していく。
その結果、新しい繋がりや別の新しい事業アイデアが生まれるきっかけになるということが実際に発生していると感じます。
こうした「価値観の交換」が発生するのであれば、オフィス回帰に抵抗すると言いつつも、たまにはオフラインで集まってみるのも良いなと思います。
まとめ:チーム自体をアジャイルに作り替える
アジャイル宣言の背後にある原則は、こう締め括られています。
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
「アジャイル宣言の背後にある原則」より抜粋(https://agilemanifesto.org/iso/ja/principles.html)
チームのパフォーマンスを最大化するにあたって、フルリモートかフル出社かの二元論で語るのは不毛だし意味がないです。
アジャイルマニフェストに従って、社会・組織・プロジェクト・メンバーそれぞれの状況に合わせて、チーム自体を自己組織的に改善し続けていくことが重要です。