概要
株式会社ドワンゴ NFC事業プロジェクト VP of Engineering の @chiyoppy です。
この記事は ドワンゴアドベントカレンダー 2023 の 2 日目の記事です。昨日は t_hazawa さんが「ゆるくやるRAMMapなどを使ってプロセスの使用量に表れないメモリ使用量を特定 (Windows、DriverLocked) (Bing Chat頼り)」として、ご自身の PC のメモリ使用状況の調査方法について投稿されました。
ファンコミュニティサービスのご紹介
ひとつのシステム基盤で複数のブランド展開を行っています。ひとつは「sheeta(シータ)」と呼ばれる、高度なデザイン管理機能やファンとのコミュニケーションが可能なファンクラブです。
もうひとつは、「ニコニコチャンネルプラス」です。
目的: 開発コスト効率（リソース効率性）の改善
リソース効率性を改善するメリット
ドワンゴ社内では開発コスト効率と呼んでいますが、ここでは世の中でつかわれているリソース効率性と呼びます。私はこの両者を同じ意味でつかっています。
リソース効率性を改善することには、多くのメリットがあります。
まず、あるチームの処理できる課題の量が増えるため、（業務の量が変わらなければ）コストを削減できます。実際には、このプロジェクトの成長速度は非常に速いため、業務量の増加を吸収するためにリソース効率性の増加分をつかうことになります。
また、実験的な新機能を導入するリスクを削減することになります。直接的に収益が増加することが明確ではなかったり、ユーザビリティを少し改善する（かもしれない）改善を低コストで実施できるならば、こういった課題に取り組む機会が増加する可能性が高まります。
もちろん、リソース効率性が高すぎる環境、言い換えると忙しすぎる環境は望ましくありません。とはいえ、これまで見てきたようにリソース効率性を高い状態にできる（高い状態を維持できる）ことによるメリットは非常に大きいです。
また、この記事のスコープからは外れますがここでいう開発には運用も含まれています。なぜならば、開発と運用を統合的に扱うこと（DevOps）もまた、効率の改善と品質の改善の両面で重要なことだからです。この点についは、いつか別の記事でご紹介したいと思います。
なぜフロー効率性よりもリソース効率性を重視するのか？
フロー効率性とリソース効率性
まず、フロー効率性とリソース効率性の違いについて簡単に説明しておきます。フロー効率性とは「何かを課題を解決するまでの時間（レイテンシ）」であり、リソース効率性は「一定期間に解決できた課題の数（スループット）」です。多くの組織では両者はトレードオフの関係にありますが、どちらも高い基準で実現している組織もあるとされています（「Lean と DevOps の科学」における「創造的な組織」）。
コスト削減による組織変更を避ける
一般的にはフロー効率性を重視する方が多いことと思いますが、私は（このプロジェクトでは）フロー効率性よりもリソース効率性を重視しています。
たしかに、カスタマーバリューの最大化という観点ではフロー効率性の方が重要のように思えます。これは市場投入までのリードタイムが縮まることによって、仮説検証のケイデンスが上がるためです。また、フロー効率性を重視したとしても、特に内製開発では（みかけの）リソース効率性は悪化しない傾向があるように思えます。理論的には、フロー効率性を改善することで、リソース効率性も改善します。
ただし、開発を外注する場合は事情が異なります。本当にこれだけの予算が必要なのか、カットできる部分はないのか、こういった問いに答え続けなければなりません。人員の追加・削減を簡単にできるというのは、良いシステムを作る上ではデメリットにもなりえます。
組織変更を頻繁に行うと、生産性の低下やメンバーが混乱するといった問題を引き起こします。
このため、こういった（開発チームの外からの）圧力からメンバーを守る必要があり、これを担保するのがリソース効率性です。たとえエンジニアリングが分からなかったとしても、常に忙しくしているチームの人を削減しようという人はほとんどいません。
フロー効率の説明困難性
一方で、もしもフロー効率が高かったとしても「工数のピタゴラスイッチを行えばコスト削減が可能」という論理への反論は難しいです。しかも、フロー効率性が高いことの説明は困難です。「半年前に要望した機能はいつ入るのか？」と質問してきた人に、あなたのチームのフロー効率性が高いことを説明することを考えてみてください。「さぼってるわけじゃないんだ。今は別のチームから要望された機能の開発で忙しいくて......」といったように、リソース効率性が高いことを説明してしまうのではないでしょうか。
「あのソファーで寝てるエンジニアを起こして仕事をさせろ」という言葉には、会社においては一面的な、だが強い正当性があります。この正当性に挑戦できるほどに明確なフロー効率性の説明は、私が知る限り存在しません。
リソース効率が高い状態ならばコスト管理を長期的な課題にできる
誤解がないように書いておくと、これは開発チームの規模を維持したいという縄張り意識的な論理とは異なります。
たとえメンバーを数名減らしたとしてもソフトウェア減価償却費へのインパクトは小さく、費用全体への影響は限定的です。逆に、メンバーを増やしたとしてもアウトプットがすぐに増えるわけではなく、売上に繋がるまでにはさらに長い時間が必要です。
このように、費用については、効果や影響が長期に及ぶために長期的な視点で考える必要があります。裏返すと、短期的には今の状態を維持することが合理的であり、そしてこの合理性の論理をサポートするのがリソース効率性です。逆にいえば、リソース効率性が低いならば、長期的な視点で議論しましょう、ということばは空虚なものになるでしょう。
（前提） 現在の開発体制
現在の開発体制は、去年のアドベントカレンダー記事「ニコニコで外注したサービス開発で、ドワンゴのエンジニアがスクラムを導入して、設計とコードの品質を改善した話」での図から重要な点は変更がないので、こちらの図を使って紹介します。
全体としては Scrum of Scrum を採用しており、各チームがその中に存在します。チームには、ドワンゴのメンバーと開発会社のメンバーが混在します。また、チーム単体で課題の特定から解決までの一連のプロセスを完了できるように、スキルセットが混在していること（いわゆるユニット制）であることも特徴です。
所属による重力
所属の違いによる見えない壁
さて、私たちの開発チームにはドワンゴのメンバーと開発会社のメンバーが混在しています。このような環境で発生するのが所属による重力です。
同じ組織に所属しているメンバーは、帰属意識が同じ組織に向いていますし、何よりそれまでに過ごした時間が長いでしょう。このため、所属が同じメンバーに対してはコミュニケーションのハードルが低く、所属が異なるメンバーに対してはコミュニケーションのハードルが高くなります。おそらく心理学などでの研究成果もあるのでしょうが、この重力が発生していたことは明白でした。
重力、ということばをつかっている理由は、単に何かを強制したり禁止したりすれば解決する問題ではないからです。直接的にコミュニケーション自体を制限するような方法は、強権的であるだけではなく適法かどうかも怪しいように思えます（「XXXさんとはなるべく仕事の会話をするな」といった業務命令は合法でしょうか？）。この問題は、仕組みで解決する必要があります。
所属による重力は、所属の違いによる見えない壁をつくります。この壁をどうやって低く（乗り越えやすく）したか？ が、今日の記事の主題です。
適切なコミュニケーションツールの選択は難しい
もうひとつの課題として、ミーティングへの依存があります。これは、報告事項や連絡、相談事項があったときにミーティングを設定したり、次の定例ミーティングで話す文化です。
このような状況では突発的なミーティングが多数発生しますし、定例のミーティングも削減することができません。
言うまでもなく、すべてのコミュニケーションにおいて Slack が適切なツールであるわけではありません。しかも、Slack とミーティングのどちらを選択するのかを合理的に判断することは、意外と難しいです。目的は何か、記録が必要か、相手に即答を期待するか、人数は何人か、などの多くのパラメータがあり、かつこれら全てを定量的に測定することは困難です。ミーティングはよくコスト（費用）が話題になりますが、Slack もメンションによる割り込みや、未読を処理するコストは決して低くはありません。
とはいえ、1日の半分以上がミーティングというのはさすがに多すぎると感じる人がほとんどだと思います。1日に10件以上のミーティングをこなして、自分の仕事もしつつアドベントカレンダーも書くというのは、ほとんど不可能です。
適切なツールを選択できるようにすることで、ミーティングの量を削減し、質を向上させるというのが、この記事のもうひとつのトピックです。
所属による重力から抜け出す
スクラムイベントでの限界
従来、この課題に対しては、デイリースクラムをはじめとするスクラムイベントで解決しようとしていました。スクラムチームとしての成熟が、自然とこの課題を解決すると考えていたためです。
しかしながら、各所属の内部で行われるコミュニケーションパスの強度はかなり強く、スクラムイベントだけでは解決できませんでした。むしろ、スクラムイベントの他に「内部の会議」があることで、ミーティングの量は極端に増加してしまいました。
誤解のないように補足すると、「内部の会議」は、開発会社の内部だけではなく、ドワンゴ内部にも多数存在していました。所属による重力は、開発会社だけの問題ではありません。先に確認したように、組織をまたぐことに対して心理的なハードルがあるというのは人間の特性なので、これは当然です。
「内部の会議」はコミュニケーションのコストを倍にする
とはいえ、この「内部の会議」をいかに減らすかが重要な課題となります。なぜならば、内部の会議で話した内容の多くは、（外部の）会議で話す必要があることがあるからです。仕様に関すること、設計に関すること、実装に関すること、これらはすべてスクラムチームとしての課題なので、何らかの「内部」で相談することがあれば、それは必然的にチーム内やチーム間で報告したり相談したりすべきことなのです。
こうした理由から、「内部の会議」があることで、コミュニケーションのコストは単純計算で倍になります。理論的には、相談内容がブラッシュアップされるなどして削減できる部分もあるとは思います（この効果を測定することはできません）。ただし体感としては、コミュニケーションのコストが倍になっているといっても過言ではないと思います。
もちろん所属組織の内部だけで議論される高い必然性があるトピックに関して、そのような議論の存在を排除しようとまでしているわけではありません。これは言い換えれば、コミュニケーションのコストが倍になることを避けて、適切な場を選択できるようにするための、いわば別の重力を発生させよう、という試みです。
スクラムチーム内のコミュニケーションには立ち入らない
さて、ここでスクラムの原則を踏まえておきたいと思います。スクラムでは、スクラムチーム内部のコミュニケーションを強くもつことが推奨されています。これは、アジャイルの目的を達成する、すなわち各メンバーの力を最大限引き出す上で、チームの（チーム内の）結束や信頼関係が特に重要だと考えられているからです。
この点からみて、チーム内のコミュニケーションの質や量をコントロールするのは悪いアイディアだと判断しました。もちろん、改善が必要なチームもありそうに思えます。ただし、それはどちらかというと、各チームがふりかえりを通じて解決するべき課題であって、チームの外からできるのは各チームが主体的に解決できるようにサポートをすることです。
チームをまたぐコミュニケーションの最適化が解決の鍵
したがって、問題はチームをまたぐコミュニケーションにあります。そもそも、「内部の会議」はチームをまたいで設定されていることがほとんどでした。言い換えれば、チーム間の連携が既存の仕組みでうまくいっていないために設定されていたのです。
なお、プロジェクトで発生した課題にこうしたアプローチがとられることも、所属による重力で説明できます。課題にアプローチするときに、所属をまたぐ壁が障壁となって、所属の「内部」だけで解決しようとしてしまうからです。
このような試みと裏腹に、実際には、所属の内部だけで解決することはできません。ドワンゴだけで議論しても実装するには開発会社の力が必要ですし、開発会社だけで議論しても実施の承認はドワンゴと相談する必要があります。課題を解決するためには、所属の重力にさからう必要があるのです。
コミュニケーションパスを改善するとりくみ
コミュニケーションそれ自体ではなく、コミュニケーションパスを改善する
コミュニケーションそれ自体の改善は、構造的に難しいです。コミュニケーションは、観測することによって変化してしまうからです（上司がいるミーティングと、同期だけのミーティングの雰囲気はかなり異なるのではないでしょうか）。観測している間は期待するように動いても、観測しなくなったらうまくいかない、では改善したとはいえません。
一方で、コミュニケーションパスを改善すること不可侵に可能です。コミュニケーションのスタイルは、コミュニケーションパスの影響を大きく受けます。この力をつかって、コミュニケーションを改善することができます。
所属による重力を乗り越える
所属による重力から抜け出すためには、チーム間のコミュニケーションを改善することが重要なことは既に指摘しました。これはすなわちチームの境界を明確化することでもあります。
改善後の全体像の図をご覧ください。
まず前提となるのは、チーム間コミュニケーションにおいては、コミュニケーションの主体はプロダクトオーナーである、ということです。プロダクトオーナーがチームを代表します。
これは、すべてのコミュニケーションをプロダクトオーナーを通じて行うということではないことに注意してください。コミュニケーション自体は、各チームのメンバー同士で行って良いのです。しかしながら、他チームへの報告は、プロダクトオーナーが内容を把握しておく必要があります。
図中のインターフェースの整備が、今回取り組んだことです。この2つのインターフェース、すなわちチーム間用 Slackチャンネルとお願いチケットが、チームの中と外を分離する境界となります。
チーム間用Slackチャンネルの作成
チーム間用のコミュニケーションパスは、従来、プロジェクトの全員が入るチャンネルで行っていました。これはSlackの流速が速くなるというだけでなく、心理的安全性が低い環境でのコミュニケーションを強制してしまいます。
Slackチャンネルの人数と心理的安全性の関係は、私個人としては（気にしないために）無関係のように思えるのですが、実態としては大きな影響があります。「この会話は別のチャンネルでやろう」という誘導をかけるときに、プロジェクト全体のチャンネルでやることの正当性を見いだしづらいようです。話題と無関係な人がいるところをあえて選択する必然性はないように思えるためです。
しかし、「コミュニケーションの主体がプロダクトオーナー」であって、相談先がそのプロダクトオーナーであることによって、チーム間用Slackチャンネルを選択する必然性が生まれるのです。より詳しくは、自分のチームのプロダクトオーナーと、コミュニケーションの相手の両方がいる場は、ふたつ（自分のチームのチーム間用チャンネルと、相手のチームのチーム間用チャンネル）しかないからです。一応、相手が所属する方を優先して使おうというガイドラインで補強していますが、これは趣旨からして守られなくても良い程度の強度のガイドラインです（実はどちらでも良い）。
心理的安全性の重力
また、Slackチャンネルに入っているメンバー数が少ない方が、そこでの発言に対する心理的障壁が低くなるという点に触れました。これを、ここでは心理的安全性の重力と呼びます。
チーム間用Slackチャンネルは、入っている人はなるべく内容を追いかけようとします（そこでの会話内容は、重要である可能性が高いためです）。なので、このチャンネルの流速が速いとしんどくなります（認知負荷が上がる、と表現しても良いかもしれません）。
そこで、この心理的安定性の重力を使うことで、「なるべくチーム内用Slackチャンネルを使おう」という力が働きます。こうすることで、チーム内用チャンネルで良いことは、なるべくチーム内用チャンネルを使うことになります。
お願いチケット（通称 おねチケ）
所属による重力を避けるもうひとつの方法として、他のチームに作業を依頼するときはお願いチケットを切ることを制度化しました。例として、Web チームから API のレイテンシ調査をインフラチームに依頼したときのチケットを添付します。
チームの境界をまたいで依頼するときにはチケットを切ることで、「内部の会議」で話された内容が作業依頼まで落ちてきたときにプロダクトオーナーが気づくことができます。これは、チーム間での相談はチーム間用Slackチャンネルをつかうように誘導するきっかけとなります。
また、「誰が」「誰に」「何を」「いつまでに」やってほしいのかを明確にすることができました。これには、コミュニケーションの効率を改善する効果があります。
じつは、お願いチケットはこういった効率の課題を解決するため、というお題目で導入しました。繰り返しになりますが、所属による重力は強力です。重力に反するようなアプローチには、拒否反応が発生する可能性が高いために、正面からの解決するのではなく、みんなが合意できる目標に近似してあげる必要があります。
お願いチケットの導入はすんなり実現することができました。今回のケースでいうと、「コミュニケーションの効率を改善する」という目的には、所属による重力を乗り越えることができるほどの正当性があったようです。
改善効果の測定
現在までの取り組み
お願いチケットが導入されたのが本年晩夏ごろ、Slackチャンネルが整備されたのは11月です。いくつかの「内部の会議」を他のミーティングに縮小・解体することで、整備されたチーム間インターフェースを利用するように誘導しました。
また、（あえて）残したドワンゴの「内部の会議」は、目的を組織へのエンゲージメントを高めること、と再定義し、アジェンダをこの目的に沿って整理しました。
意図を理解してくれるエヴァンジェリストを育てる
今回やってみて、こういったコミュニケーション設計の意図を理解してくれる人（エヴァンジェリスト）をつくることが重要だと感じました。ドワンゴにも、開発会社にも、こういった変更の意図を深く理解・共感してくれる人が何人かいます。こういった人を育てていくことで、よりはやくこういった設計変更を適用できると思います。
実際、「こういう話はこちらのチャンネルでやろう」「この依頼はチケットを切って下さい」といった発言が少しづつですが増えてきています。これは良い傾向です。こうした発言をしてくれる人が、将来また別の変更を加えるときにも助けになってくれるはずです。
効果が出るまでにはまだしばらくかかりそう
リソース効率性への影響はまだ見えていません。効果が出るまでにはもうしばらく時間がかかりそうです。
この記事で紹介した仕組みをつくるだけでは、所属による重力や、その結果としてできてしまう壁を取り払うことはできません。実際にうまくいくかどうかは、日々のコミュニケーション、すなわち実運用にかかっています。
メンバーに重力を振り切る力をつけてもらうことや、正しいコミュニケーションパスを使うように誘導すること、これらをトップダウンとボトムアップの両方から奨励していく（奨励しつづける）ことが必要です。
おわりに
いかがでしたか？
組織におけるコミュニケーションの傾向を分析して、「所属の壁」という概念を通じて理想とのギャップをみつもり、実際に変革するプロセスについてご紹介しました。
明日の枠はこの記事を書いている時点ではまだ埋まっていません。これを読んだドワンゴ社員は明日の分を書いてください。
Appendix
技術的負債との関係
解決が困難な技術的負債の代表例は、チームの境界をまたいで共有されるコードやドキュメント、データです。技術的負債が生まれる原因は、単なるエンジニアの技術力に問題があるからではありません。今回のアプローチが、技術的負債に対する分割統治というアプローチ（マイクロサービス化）の基礎となることを期待しています。
また、記事中には記載できませんでしたが、Slackチャンネルの整備とあわせてConfluenceスペースの整備（分割）も進めています。こちらはかなり時間がかかりそうではありますが、チームの境界が明確になることで、分割する方向に力がかかることを期待しています。
逆コンウェイ戦略との関係
逆コンウェイ戦略については、既に多くの識者が指摘しているほか、書籍チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 で非常に良く整理されているため、ここでは簡単に紹介します。
チームのプロダクトの間の結合度を低下させたい、というモチベーションが、今回のコミュニケーションパス変更の裏テーマとして存在します。今回の取り組みはチーム間のインタラクションを整理することに繋がると確信していますが、とはいえコミュニケーションパスを変更するだけではなく、技術的な解決策で補強する必要があります。
ダンバー数との関係
今回の試みは、ダンバー数を踏まえて考えると興味深い気づきがあります。シンパシー・グループ（12〜15名）の中に、他の所属のメンバーがどれだけ入れることができるのか？ という観点です。
もしこれができるのであれば、同じ所属のメンバーがこのグループから外れることを意味します。
客観的にみて、所属とダンバー数の間の関係性は独立しているように思えます。このため、プロジェクトの中のコミュニケーションが改善した副作用として、所属の中での心理的安全性をどう担保するべきか、という別の問題が発生するかもしれません。