プロダクトに関わる人数が増え、組織が急拡大していくと、コミュニケーションロスが増えていき、チーム間でのやりとりにミスが発生することが多くなっていくでしょう。

note社でも社員数が50人から200人に増えたため、組織改編を重ねてコミュニケーションロスを減らす努力をしてきました。しかし、まだまだ問題は山積みです。

そこで、今回はヘンリー社のVPoEである張（シアン）さんを招いて、チームAPIの導入によるコミュニケーションデザインについてお聞きすることにしました。ヘンリー社は昨年7億円を調達し、今まさに組織が急拡大しています。

note社の組織改編の歴史と苦労や、ヘンリー社のチームAPIの導入など、対談を通してコミュニケーションロスとその解決について語っていきます。

note株式会社：
「だれもが創作をはじめ、続けられるようにする」をミッションに、メディアプラットフォーム・noteを運営。クリエイターのあらゆる創作活動を支援。

株式会社ヘンリー：
医療業界の業務改善を目指し、クラウド型電子カルテ・レセコンシステム「Henry」を展開。目標は民間企業として日本初のノーベル平和賞受賞。シリーズBで7.3億円の資金調達を行う。

組織の急拡大で発生するコミュニケーションロスとマトリックス組織の問題 - noteの課題と解決

シアン
noteはここ数年で組織が急拡大をしたと思うのですが、開発においてコミュニケーションロスは発生しませんでしたか？

福井
コミュニケーションによるペインはいくつかありました。ここ3年で社員数が50人から200人に増えたので、以前と同じ組織ではやはり回らないことも多くて。

福井
noteをリリースをした2014年頃は、エンジニアが5〜6人だったので何もせずとも情報共有ができている状態です。わからないところは近くにいる人に聞けばわかるような形ですね。

福井
コミュニケーションロスを感じ始めたのは、エンジニアの人数が20〜30人になった頃です。「この機能は誰の担当？」「誰に質問するべき？」と担当者がわからない問題が発生するようになりました。

福井
問題を解消するために2020年には、マトリックス組織を導入することにしました。

組織がフラットだったため、それぞれで自由に動いていたのですが、マトリックスを取り入れることで役割をハッキリとさせたのです。誰になにを聞けばいいのかある程度はわかるようになりました。

シアン
人数が増えて権限移譲が必要になるとマトリックス的な組織体制は必要になってきますよね。ただ、逆に担当領域が曖昧な部分がでてくると、意志決定しづらい部分が余計に発生してしまうかなと思っています。

福井
まさにおっしゃる通りです。マトリックス組織にして役割を決めたとしても、こぼれてしまうタスクはあります。AチームとBチームの間に落ちてしまう施策があるとか。どこのチームの目的にもジャストミートはしないけれど、プロダクトとしてやるべき施策をどのチームに任せるのかは難しい問題ですよね。

シアン
弊社も人数が増えてきてマトリックス的になりそうな部分があるので、難しい課題だなと感じています。

シアン
コミュニケーションロスの課題で一番大きかったのは、スピード感が遅くなってきていることでしょうか？

福井
そうですね。2020年ごろまではCEOとCXOが開発をハンドリングしていたのですが、組織が拡大したことで意思決定に時間がかかるようになってしまいました。そこで意思決定を高めるために、チームごとにPMを配置するようになりました。私もこの時期にエンジニアからEMにジョブチェンジしたのですが、やはり組織的な課題解決に向かうためなんですよね。

シアン
意志決定する場面が増えていくと、依存が集中してしまうのでキャパシティ的に難しいですよね。PMにはどのくらいの権限が移譲されているんでしょうか？

福井
チーム単位で機能開発についてはPMに任せています。大きな事業戦略は経営陣で決定し、組織構成を経営陣とマネージャーで構想し、戦略に対してやるべきことをPMと話し合っていくようなイメージですね。

シアン
現場に決定権を委譲したほうが成果も大きいと考えているので、ヘンリーでもなるべくチームメンバーが意思決定できるようにしていますね。

コミュニケーションロスをチームAPIで解決 - ヘンリーの課題と解決

福井
ヘンリーさんも今まさにエンジニアの人数が増えている段階だと思います。同じようにコミュニケーションロスの課題はありますか？

シアン
ヘンリーもエンジニアが7人から20人に増えているため、やはり同じようにコミュニケーションロスを感じる部分はあります。

弊社ではプロジェクト管理ツール選びでかなり苦戦をしていて、Jira→GitHub→Wrike→notionと移り変わってきました。苦労はしましたが、ツールによってコミュニケーションの体験がまったく異なるのは大きな学びでした。だからこそ今はコミュニケーションデザインをしっかり行う重要さが身に沁みています。

福井
具体的にコミュニケーションロスを防ぐためにしていることってなにかありますか？

シアン
各チームの担当を明文化して、チームAPI(※)を定義するようにしています。チームAPIで区切られていれば、担当決めを明確にすることができるからです。

※ チームAPI：コードやドキュメント、業務内容などをすべてインターフェース（API）として定義し、他チームとやりとりを行う。チームトポロジーにて定義されている概念。

福井
チームAPIは業務のドメインごとに区切っているんですか？

シアン
そうです。弊社では電子カルテ、会計レセプト、プラットフォームグループの3つのチームに分かれています。前者2チームが各機能の価値デリバリーを行い、プラットフォームチームは全体のインフラ開発や生産性向上などを行っています。

担当領域が明確なのでインプットとアウトプットを定義しやすく、コミュニケーションの手段としてチームAPIは最適だと考えています。また、現在ではエンジニアチームだけではなく、カスタマーサポートやセールスでもチームAPIを定義しています。いずれは全社的にチームAPIで運用していく予定です。

福井
全社で共通言語があるのはいいですね。最初の設計が肝心だと思うのですが、区切りをつけるのが難しくありませんか？

シアン
やはりどのチームで持つべきなのか、境界線が曖昧な部分はいくつかありますね。

そもそもですが、まだまだ弊社はエンジニアの数が足りていません。チームAPIで効率的に区切ったとしても、リソースに限りがあるのが現状の悩みです。

福井
いやいや、現段階でコミュニケーションデザインを考えて組織づくりしていること自体が素晴らしいですね。

シアン
ありがとうございます。スタートアップだと人数が増えたり、組織が変化したりすることは頻繁にあります。それに伴ってコミュニケーションの量や組織の複雑度が増えていくのはよくあることです。だからこそコミュニケーションデザインを考慮しなければ、全体の生産性が下がってしまいます。プロダクトづくりは個人の作業ではなく、協力し合ってプロダクトのバリューを実現していくチームによる戦いだと考えています。

チームごとに業務を区切る難しさ

福井
ヘンリーさんのようにnoteでも機能ごとにチームAPIで区切れたらいいのですが、現状はミッションベースで切っているので難しいなと。

例えば少し前の組織では、「記事を書く機能を強化するチーム」や「シェアや認知を増やすチーム」でセグメントを切っていたのですが、どちらもエディタ機能などは改修する可能性がでてきます。チームAPIで区切ったとしても、どのチームにも関与することが悩ましいですね。

シアン
たしかに組織が大きくなっていくと、切り分けが難しい部分は発生していきますね。

福井
抽象的なプラットフォームチームを1つ作ってしまって、そこで曖昧な開発は吸収していく形がいいかもしれませんね。APIベースでコミュニケーションをして、変更がある場合はそのチームに依頼するようなイメージで。

シアン
いいですね。弊社でも同じような構想を考えていました。クライアントからの要望も多い複雑な機能は、共通プラットフォームとして区切るのがいいかなと。

シアン
noteさんはチームごとで開発をすすめるために工夫していることはありますか？

福井
我々の場合は、コードを分割してモジュラモノリス化するところから始めていますね。

福井
noteは2014年からRuby/Railsで開発を続けてきたためコードがモノリス化しています。そのため、改修をしたときにどこに影響を及ぼすかわからない状態になっていて。そもそもコードの依存関係がチームAPIのような仕組みも導入しづらいため、まずはモジュラモノリス化してチームごとに開発できる範囲を限定していこうと思っています。

シアン
依存関係の境界をまずはコードベースでつくるのは良いですね。ただ、キレイに区切ろうとすると余計に複雑になってしまうこともあるので難しい部分です。ちゃんと接続面を厚くして、プロマネが得意な方が窓口として収束させることでチームの分解点を良くするのがいいかなと。

福井
ですね。弊社もどう分割するか迷ったのですが、まずはファイナンスやセキュリティなど依存関係が少ない機能から小さく分割するようにしました。

シアン
問題自体を小さく分割して解決していくのは大事な考えですね。

目標設定やMVVの浸透

シアン
組織が拡大してチーム数が増えていくと、社員同士なのに顔が見えなくなってしまうのは大きな問題だと思っています。トラブルが発生しても、「自分たちには関係ない」という意識が生まれてしまうなと。組織として目標設定のすり合わせなども大事だと思いますが、noteさんはそういった課題感がありましたか？

福井
わかります。noteでも同じような問題に直面していたため、昨年からエンジニアの全チームでOKRを導入しました。チームによって目標や成果の粒度がまちまちだったので、共通言語化することにしたのです。

シアン
チーム間でOKRを共有して合意をとっていく形ですね。共通言語化したことで他チームの状況を理解して、納得感が得られるのはいいかもしれない。

福井
共通言語化ができればOKRである必要はないと思っていて、意思を共有できるフレームワークがあればいいなと。他チームと同じ目線で会話できるようになったので、やはり導入した効果は一定あったかと思います。

シアン
大事ですね。AチームとBチームでそれぞれ意志を伝えあったとしても、必ずしも伝わるとは限りませんからね。Aチームが意図を理解していない可能性もありますし、Bチームの言語化ができていないとも考えられます。コミュニケーションの窓口を共通化していくのは、コミュニケーションロスを減らす1つの答えですね。

シアン
共通言語の話しで言うと、私が大切だと思っているのが文化の浸透です。ミッションやバリューが浸透していないと、メンバーごとに行動指針が変わってきてしまうなと。

福井
弊社でも経営陣を含めて課題感を持って取り組んでいます。ミッションやバリューに紐付いた行動をしたチームメンバーの紹介をしたり、入社した社員にはCEOからバリューを直接共有する会を行ったりもしています。

シアン
なるほど。弊社でも同じようにワークショップの実施や、社員のエピソード共有などの機会を設けています。ミッションやバリューを実例で伝えることで、行動のベースとなるようになればいいなと。

福井
同感です。ただ、一方で弊社のバリューはあくまで全社員向けなので、エンジニア視点で抽象的で行動に紐付けるのが難しいことがあります。もう少しブレークダウンしてエンジニア向けのバリューを作っていく必要があるかなと。

シアン
わかります。我々もバリューを作る際にエンジニアの指針になるかどうかは意識しました。あとはバリューがSlackスタンプで汎用的に使われるようにする議論もかなり行いました。

福井
Slackのスタンプですか？

シアン
社員同士のやりとりで気軽に使いやすいスタンプにすることで、無意識にバリューを意識できるなと。メッセージのいろんな事例をイメージし、ワーディングの変更を何度も行いました。

福井
あー、なるほど。使われるシナリオから考えていくのはいいアプローチですね。

シアン
ヘンリーでは理想駆動と爆速アウトプットとドオープンの3つのバリューを作ったのですが、いずれもSlackスタンプとして非常に使われています。定例で話す際のバリューエピソード集めも、スタンプを検索すればいいのでピックアップしやすくなりました。

福井
自分たちで自然と使っていくことでバリューが浸透していくのか。弊社でエンジニア向けのバリューを考えるときの参考にします。

▼note社の技術記事をさらに読みたい方はこちら

▼株式会社ヘンリーの技術記事をさらに読みたい方はこちら