イベントレポート：成長中の2社が語る、複数プロダクトを跨ぐデータ活用を実現するためのアーキテクチャとは

カカクコムにてRailsエンジニアとして「食べログ」の開発に従事。その後、エバーセンスへ転職し、プロダクトオーナー、Webマーケティングなど様々な役割を担い、テックリードを務める。「更に大きい規模で社会を変えるようなことをしたい」という思いから2018年にリンクアンドモチベーションへエンジニア初期メンバーとして入社。開発チームの立ち上げを経験し現在はエンジニアリングマネージャー兼テックリードを担当。

▼当日のLT資料はこちら

リンクアンドモチベーションについて

リンクアンドモチベーション（以下「LM」）は、「モチベーションエンジニアリング」 という独自の基幹技術を用いて、従業員エンゲージメントを可視化し、その向上に向けた組織変革を支援している会社です。
「良い会社の定義を変える」というミッションを掲げ、上場企業に公開が義務づけられているP/LやB/Sなどの事業に関する指標だけで企業が評価されるのではなく、従業員との相思相愛度合い＝従業員エンゲージメントが高い企業も評価される社会の実現を目指しています。
最近では企業経営者や投資家の間で、従業員エンゲージメントをはじめとする「人的資本開示」に対する関心が高まっています。米国では2020年に人的資本の開示が義務化された他、日本でも人的資本開示に関するガイドラインが公開され、大手企業においては、人的資本開示を経営目標にする動きも出てきました。このような外部環境の変化から、従業員エンゲージメントについて最近特に注目が集まってきているように感じます。

エンゲージメントチェーン構想

そのようなトレンドを受けて、LMではエンゲージメントチェーン構想という戦略を打ち出しています。エンゲージメントチェーン構想とは、エンゲージメントに関わる組織や個人のデータを、LMが保持しているデータと統合することで新しい価値を提供する試みです。社内外のデータをやり取りしながら、大きな一つのデータベースを作りたいと考えています。そのため、プロダクトを跨いだデータ統合や、他サービスとの連携が重要になってきています。
それらを実現する上での課題は、人や組織に関するデータがサービスを跨いで統合されておらず、同一の人物や部署を「同じもの」として特定できない状態であることでした。そのため共通基盤を作って、認証や組織にguidをふることにしました。これが、なぜ共通基盤を作るのか？の背景です。

今回のサービス切り出しの特徴

現在LMでは認証や組織管理、契約管理をマイクロサービスとして分離し、自社プロダクト間でデータを統合中です。
一般的にマイクロサービスには、依存されていない処理を切り出す場合と、頻繁に利用されるデータや処理を共通的に使えるように切り出す場合の、大きく2種類があります。図の左側の処理を切り出すところは、認証やメール、PDFファイルの作成などが該当しますが、ここはAuth0やSendGrid、AWSLambdaなどサードパーティを活用して実施済みです。
今回は、ユーザーデータや組織データ、契約データなど、共通的なコアデータを切り出そうとしています。このコアデータを切り出すのは、実はLMとしては3回目のチャレンジです。ここからは進める中で具体的につまずいたことや、得られた知見を簡単に紹介したいと思います。

やっていく中で見えた課題

マイクロサービス特有なものとして、どこまでやるの？という課題があります。境界はどこなのか、という葛藤もあり課題はたくさんありました。ここでは3つに絞ってお伝えしたいと思います。
一つ目は、どこまでリアルタイムにデータ反映するかです。これについては、対象と時間それぞれに分けて考えました。実際データと処理によって要件は様々なので、LMではマトリックスを組んで、各処理をどのような反映速度でやるのか、実際にどういう方法で同期するかを整理しました。例えば、パスワード更新はリアルタイムで行い、APIがエラーで落ちている場合は同期的にエラーメッセージを返却します。特定プロダクトの契約更新では、処理が複雑で内部でさらに他システムへのリクエストが必要なところもあるため、非同期更新を選択しています。契約情報の参照は、契約基盤が落ちてしまうことも考慮しなければなりません。その場合でも少なくとも使えるようにキャッシュをかませながら参照しています。
その他、組織情報の更新など自動ではなくユーザーの任意のタイミングで更新できた方が良いものもあります。そういったものは同期的にキックしつつ非同期更新を行っています。このように、何をキックにどのくらいの反映速度でやりたいのかを起点に、処理方法を考えました。





二つ目は影響範囲をどこまで広げるのか、です。これはスモールサクセスを積み上げるために広げすぎないことを意識しました。1回目のチャレンジでは、最初はAPIで共通サービスから良い感じにデータを引っ張ってきて、各アプリのDBをグラフQLなど使ってスリム化しようと試みたのですが、頓挫しました。
理由は、組織関連のモデル参照している箇所を全て修正する必要があったからです。APIなのでJOINも解かなければならないし、性能要件を満たすための工夫も必要でした。特にモチベーションクラウドはRailsで作っているので、ORマッパーに依存する作りになっています。その分コードとテーブル構造がとても密になっており、分離させるのはとても困難だったため、試行錯誤の末、無理だと判断しました。
今回のチャレンジでは、最終的に「データのキャッシュ先がたまたま今まで使っていたテーブルと同じ構造だった。そして同じデータストアだった」という考え方をしました。具体的には組織基盤から変更通知してデータを取得し、モチベーションクラウド側の組織情報を更新しています。そうすることで、実際にテーブル構造は変わっていないので、各アプリのテーブル・ロジック変更はほぼ不要になります。性能についてもほぼ気にすることなく分離をすることができました。





最後が、構成をどうするか、セキュリティをどこまでやるのかです。これは他社事例を積極的に仕入れました。社内でも論点がいくつかでてきたのですが、細かい課題に対する解決策については、外部から情報を得るのが大変でした。そのため、AWS社に相談しながら進めました。




また、運用面では開発効率の悪化を防ぐのが非常に難しかったです。ここについては今も課題を出しながら鋭意改善に取り組んでいます。

おまけ（だけど、LMが大事にしていること）

共通基盤のプロダクト開発を進めるにあたって、大事にしていることがあります。それはプラットフォームチームのスタンスです。LMが大事にしている組織作りにも通じるのですが、やってよかったことがいくつかあるので、こちらはパネルディスカッションでも詳しく紹介します。

株式会社LITALICO 執行役員 CTO
市橋 佑弥：
大手通信会社研究所にてIP電話サービスの開発に従事。その後、通信系ベンチャーで複数のクラウドサービスの新規開発や運用を行う傍ら、NOC、データセンター、カスタマーサポートを統括。教育系ベンチャーでのIT事業エンジニア統括を経て、2017年にLITALICOに入社し、2019年9月より執行役員に就任。その後2020年12月から執行役員CTOとして、新規プロダクト開発や既存プロダクトグロースのほか、社内ITやセキュリティも管掌。

▼当日のLT資料はこちら

LITALICOについて

LITALICOは、障害福祉分野を中心にtoC/toBそれぞれサービスを展開している会社です。社会生活に大きな困難があるために「障害者」と括られている人がいますが、私たちは社会の側に多様な生き方を実現する技術やサービスがあれば障害はなくしていけると考えています。社会の側にあるバリアをなくしていくことで、多様な人が活躍できる「障害のない社会をつくる」というのが、LITALICOの掲げるビジョンです。
また障害の有無に関係なく、社会での生きづらさや困りごとを抱えている方は多くいます。そのため経営戦略としては、障害福祉領域でのトータルソリューションサービスを中心に展開しつつ、介護や学校教育など障害福祉領域以外への事業展開も積極的に行っています。
特徴的なのは、WebサービスやSaaSなどIT事業だけをやっている会社ではなく、自社で全国約260箇所に事業所を展開して、直接支援サービスも提供している点です。直接支援サービスを通じて得られるノウハウを、WebサービスやSaaSプロダクトに価値転換し、より業界全体に普及させていく。そうすることで社外からも広く多様なデータが集まり、それをさらに活用して、サービスの品質向上や新規サービスの立ち上げにつなげ、実践を繰り返してまた普及させていく・・・、という連続したサイクルを経営の骨子としています。

LITALICOの技術戦略

テクノロジーの関わり方として、WebサービスやSaaSの開発・運用、共通基盤の整備や、自社で運営している福祉事業所の直接支援におけるDXの推進などがあります。DXにおいては、表面的な業務のデジタル化や業務負荷の削減に止まらず、属人化や暗黙知化しやすい支援業務のデータを蓄積・分析して、アルゴリズムを抽出しプロダクトに反映させていくという、さらに一歩踏み込んだDXにも取り組んでいます。
具体的な技術戦略の方向性としては、①多種多様なプロダクトを展開し、②サービス・プロダクト群を全体で繋いで包括的なソリューションを提供しながら、③それらデータを活用して業界を変革していく、の3つが柱になっています。
そもそも当事者の方を取り巻く社会環境には様々な場面があり、その至るところに課題が存在しています。互いに関連しあう課題もあるため、一つの課題を解決するプロダクトだけを作って大きく育てても本質的な課題解決には繋がりません。そのため多くのSaaSやWebサービスを作り、あらゆる課題に対して多様なソリューションを展開していく必要があります。そして、それらがバラバラに存在しても意味がないため、包括的なLITALICOのサービスとして提供し、そこから得られる膨大なデータを活用して業界を変革していきたいと考えています。

多種多様なプロダクト展開をする

LITALICOには現在社内外あわせて約15のプロダクトが存在しています。toCプロダクトだけでなく、自社で運営する事業所のシステムもフルスクラッチで開発し、それをベースに全国の事業所向けSaaSも開発しています。在籍するエンジニア・デザイナーはおよそ150人で、開発スタイルも多種多様です。ある程度共通の機能構造を持つプロダクト群については、共通部分を切り出して基盤化し、API等の形で利用しています。さらに各プロダクトの開発エンジニアがその共通部分を活用していくことで、効率的に長い期間グロースさせながら運用保守していくことを、一つの良い姿として描いています。
設計や実装上のオーバーヘッドもあるので、事業や組織の状況を踏まえて、共通化するメリットにどういうものがあるか、多角的な観点からタイミングを見極めながら進めています。




一方、将来的な可能性を見据えて設計上の仕込みをしていくことは意識しています。例えば、全国の福祉事業所向けに展開している業務支援システムのSaaSには「レセプト」という機能があるのですが、これを共通化していくプロジェクトが今動いています。レセプトとは主に医療事務で行われており、病院側が保険者に対して、医療費のうち保険者が負担する費用をデータで請求する業務のことで、障害福祉領域も同じような請求の仕組みになっています。
LITALICOにはレセプト機能が必要なプロダクトが既に二つあり、現在三つ目のプロダクトを開発中なのですが、このタイミングでレセプト機能を共通基盤として使えるよう開発を進めています。既にある二つも、一つは将来を見据えて、レセプト機能の部分だけを置き換えていくことが比較的しやすくなるようDDDやマイクロサービスで設計されています。もう一つは昔からあるプロダクトで、現在老朽化対策でリアーキテクティングを進めているため、その過程でいずれにしてもレセプト機能も大きく手を入れる必要があります。
障害福祉の分野では3年に一度大きな法改正があり、機能も法令と密接に関わってきます。そういう対応もプロダクト毎に分散した状態ではなく、対象を局所化することでリターンを得られると判断して、共通基盤化に踏み出しました。

サービス/プロダクト群全体をつないでいく

これからのチャレンジの話になりますが、LITALICOのプロダクトは業態上これからもどんどん増えていきます。それら多数のプロダクトを直接繋いでいくのではなく、共通基盤を作りそこに各プロダクトが接続していくことで、最終的に全てのプロダクトが繋がっていく形を作りたいと考えています。
まだ構想中ですが、方向性としては、全てのプロダクトを連携させないとリリースできないということではなく、段階的にプロダクトを連携させ、順次価値提供していけるような作り方を検討しています。また、各プロダクトや機能の開発において、そのチームが過度に基盤の仕様を意識しなければいけない状況はなるべく避けたいです。

データ活用により業界を変革する

共通IDに関しては、LITALICOも個人データに全体でユニークなIDがない状態なので、まずはそれを作りたいです。事業の特性上、家族関係も表現できるようにしたいと考えています。そしてこれらをキーにシステム連携の基盤を作り、データ分析基盤を整理していくことが今後のミッションです。
最終的にはデータを活用して、一人ひとりの特性や志向にあわせた最適なサービスとのマッチングの実現や、そのサービスの提供価値も個別最適化していく、といったことを提案していきたいです。toC領域では個別最適化を追求しながらデータのポータビリティを確保し、toB領域では業界全体でノウハウを可視化し、共有していくことにも繋げたいと考えています。





また社会を大きく変えていくためには、同時にルールメイクも必要です。こういったデータ活用をエビデンスとした政策立案のサポートや、政策提言なども行っていきます。
その他、研究機関と連携しながら、LITALICOが実践してフィードバックを行うサイクルを回していくことや、集まったデータを活用して、先行事例の応用レベルを超えた、機械学習を活用したイノベーティブな研究開発なども進めていきたいと思います。

ここからはモデレーター山根さんのもと、当日参加者から頂いた質問も含めてパネルディスカッションを行いました！その内容の一部をお届けします。

Q. マイクロサービス・アーキテクチャの導入を意思決定した理由を教えてください

江上：データを繋げたい、というのが大きかったですね。内部でIDを統合する必要があったのですが、モチベーションクラウドシリーズ全体でデータが統合されていないと、なかなか外部連携も難しい状況でした。また顧客が複数のプロダクトを使う時に、同じ操作を何回もさせない、という顧客体験向上の側面もあります。あとは開発者体験の向上や開発の安定性の向上です。実際、昔からあるすごいコアな部分で負債が溜まっていたので、いっそのこと新しいものを作ってリプレイスしよう、共通化して綺麗にしようとなり導入しました。

市橋：法改正にどう立ち向かうかという観点から導入を決定しました。法令が関わる業務系SaaSの開発では、エンジニアも法令の深い知識が必要になってきます。ただ、それを全員に同じレベル感で求めるのは非常に大変な話なので、マイクロサービス開発で分離していくことで、チームによって必要な法令知識のレベル感を変えて対応しやすくなるようにしています。
法令ってシステムの都合を考えてはくれないんですよね（笑）。コアなデータ構造に影響がある改正もあったりする。しかも、法改正前のものでも対応が必要なものもあるので、分岐していくのではなく、アプリケーションを新旧それぞれの法令に基づいて作っていく形にしています。そうすることで改正前の法令についてのリグレッションテストも不要になるし、いつでも捨てられ、全体は複雑化していかない状態にできるなと。あとは個々の開発チームをあまり大きくしたくなくて、5〜6人くらいのチームに分けたかったという背景もあります。

江上：たしかに組織とシステムはアーキテクチャが似るって言いますよね。分離していけばチームも小さくなって、D/D/D（Deploys/ a Developer/ a Day)というか、デプロイ頻度もあげやすくなるのかなと。

Q. 法改正が3年ごとに実施される中で、アーキテクチャ設計や開発で意識していることはありますか？

市橋：新しい法令に変わっても、5年くらい遡って対応しなければいけないケースもあるので、結局3世代くらいは対応できないといけない点が難しいです。今はアプリケーションを分けて、ルーティングするといった考え方で開発しています。

江上：現状LMでは法改正の影響を受けることは多くないのですが、今まさに人的資本開示に関連した法改正や世の中のルールが変わりつつあり、外部環境の変化にあわせて機能の追加や、あるいはデータ保持の仕方を変えなければいけないフェーズです。例えば、従業員情報などはアプリケーションというすごく動きやすいもの、柔らかいものの上に置くのではなく、ちゃんと共通基盤において、硬めにしっかり設計するなどしています。

Q. 共通基盤を作ることで障害発生した際に複数プロダクトへ影響が及びそう。何か工夫していることはありますか？

市橋：そのリスクは確かにありますね。結局プロダクトを共通化することで得られるリターンと、そのリスクのどちらを取るかの話だと思っています。LITALICOとしては、一般的なシステム障害への対応や対策を取っていくより、法改正に対応するために、深い法令知識が必要な部分を局所化して、人員や体制をしっかり整えた方がリターンが大きいと判断して共通化に踏み切りました。
一般論としての工夫は、それこそ江上さんのところも色々工夫されてましたが、物によって同期しなくても良いところは非同期化していく、後から結果整合性であわせていく、といったところが共通基盤の工夫になっていくのではないかなと思います。

江上：反映速度の話で表もだしましたが、非同期にしたりキャッシュしたりといった工夫をしています。常時参照したいものや、それが参照できないとサービスが使えなくなってしまうものなども積極的にキャッシュしていますね。あとは専任チームを作ることでドメイン知識の深い人が触るので、あまり詳しくない人が触って思わぬ所に影響がでた、みたいなケースは少なくなると思っています。どちらかというと通信障害などは除いて、障害は減っていくのではないでしょうか。

市橋：障害の話からは逸れますが、江上さんのところは1回目と3回目で違うアーキテクチャにされていますよね。僕もいま、全プロダクトのデータを共通ID化していく基盤を検討中なのですが、まさに同じようなスタイルを考えていて。全部データを一元化して集めるのではなくそれぞれで持ってた方が良いのかなとか、その一方で整合性を担保していく必要はあるなと思っているのですが、LMさんではその辺どう工夫されているんですか？

江上：現在だと結果整合性というか、同期されているかを見るために外型監視みたいなものを入れています。簡単にredashを両方のDBに繋いで、整合しているかなど確認しています。結局それぞれで持っている方が使い勝手が良いんですよね。障害の話でいうと、同期的に取るところが多すぎると単体で動けないので、依存しすぎるという課題はあります。
市橋：そこをなるべく依存しない関係性にしたいなと思いながら、今まさにアーキテクチャを考えています。

江上：アプリケーションもそれぞれで開発するので、あんまり依存させすぎると開発も大変になりますよね。共通基盤側のコンテナも立ち上げつつ、自分のアプリケーションのコンテナも立ち上げなきゃいけなくて、みたいな。そういう意味でも、独立してアプリケーション開発できるようにするところは、今結構注力しています 。

市橋：ある2〜3プロダクトの共通機能を切り出すことと、全体のプロダクトの共通基盤は考え方が異なりますよね。僕らも、極力依存しない形で、設計上そこの仕様にあまり振り回されないようにしたいと思っています。

Q.マイクロサービス導入時の組織作りについて、気をつけていたことは何ですか？

市橋：組織作りは、開発の進め方やプロセスともいろいろ関係してきます。マイクロサービスといっても、LITALICOの場合はマイクロというよりミニサービスに近いサービスの規模感で、DDDも使っているので、関心事でアプリケーションが分かれています。これくらいの規模感のプロダクトだと、自分が開発しているマイクロサービスのことだけに集中して、他は何も知らなくても大丈夫、とはならないんですよね。お互いの開発しているものが、ある機能を実現していく上で複数のサービスにまたがっていくので、どういう形で適切に仕様や設計に落とし込んでいくかは気をつけました。

あとはワンチームでモノリスに開発しているわけではないので、進めていく上でのプロセス上の工夫とか、どういうレベルの情報をお互い共有していくのか、といった共通の課題を、ワーキンググループみたいな形で各チームのテックリードが集まり、解決していくための仕掛けを作るといった工夫をいろいろ重ねています。

江上：僕たちもめちゃくちゃ同じことをしています（笑）。プロダクトが分かれてきて、横断で解決すべき課題もでてきたので、各テックリードを集めて課題共有するなどしています。あとは、僕らはいま共通サービスを作っているので、主体はプラットフォームチームだというスタンスが大事だなと感じています。
結局プラットフォームチームがみんなを繋ぐ役をしているので、プラットフォームチームから積極的にいかないと、ともすると共通化しているだけでは、って思われやすいのかなと。他チームのエンジニアを顧客とするチームは「新しいことがそんなにできてない」と自分たちも受け身になる傾向はあると思います。なのでミッションビジョンを強く作って、それを定期的に確認することを大切にしています。マイルストーンもアプリケーション側が切るのではなく、こちらから積極的に、ここまでにこれを用意するからそっちで繋ぎ込んでほしい、みたいにプラットフォームチームが主導で切ります。

僕らもマイクロというよりミニくらいの規模感でやっているので、関連するところは結構深く知らないといけません。その時にアプリケーション側からプラットフォームを知ってもらうのではなくて、プラットフォーム側からアプリケーション側に入っていく。実際契約のところも、インターフェイスを作った上で、さらにあちらでどういう風に使われるかまでをプラットフォームチーム側で作り、それを渡した上でブラッシュアップしてもらう、といった具合で進めました。攻めるプラットフォームであることを大事にしています。

Q.採用において、ビジョンやカルチャーマッチはどのくらい重要視していますか？

市橋：重視はしていますが、カルチャーは僕ら自身が固めきれていないところもあるので、そこは今まさに注力しているところです。先ほどのマイクロサービスの組織と話を絡めると、他職種のチームも含めて互いにコラボレーションしていかないと話が進まないことが多いんですよね。敵対関係とか縦割りではなく、相手を理解しリスペクトする、そういう動きができることが重要になってくるので、採用でもそういう考え方を共有できるかは、重要視しています。
狭い意味での技術力は後から身に着けることができると思うので、その方のベースとなる価値観やカルチャー、物の考え方が、僕らの目指す組織に近いかどうかの方が、採用での重要度としては高いと思います。

江上：僕らも同じような考え方です。加えて、ミッションビジョンは大事にしていますが、選考段階でそこへの共感は強く求めているわけではないです。ある程度いいなと思ってくれるくらいの共感度はあった方が良いと思いますが、そこにめちゃめちゃ傾倒していますというテンションである必要はないと思っています。それよりも人として良い人というか、ちゃんとリスペクトをもって接することができるか、陰口を言わないかなど、コラボレーションしながら働く上で気持ちよく過ごせる人かどうかを見ています。

Q.大規模開発に関わる魅力を教えてください！

江上：東証プライム企業で、ITを主戦力としてやっている立場からお伝えできたらと思いますが、ある程度の規模の開発に関われるのが魅力ではないでしょうか。規模が一定あると気をつけなければならないことが増えますし、その上でマイクロサービスに挑戦するとなると、通信や性能にも気をつけなければいけないので、技術力は上がると思います。

またスタートアップと比較すると予算も結構あるので、自由度も高いです。LMの場合はプロダクト開発に投資してもらえていることもあり、現場の裁量でばんばん新しいツールなども導入しています。最近だとメンバーの提案でQiitaチームを導入しました。まとめると、複雑度が高くてかつ幅広くできる点が、大規模開発に関わる魅力だと思います。

市橋：LITALICOも似ていますね。ある程度の規模感で、やれることの選択肢や自由度が一定ありつつも、すごく巨大ではないので個人の裁量が小さくなっていくことがない。僕らはチームの人数が10人に満たないくらいにサービスを切っていて、各プロダクトのアーキテクチャや技術選定はそれぞれのチームの裁量にある程度任せています。その上でプロダクトの規模が一定あるので、いろんなプロダクトを連携したときの設計がどうだとか、この場面はどうするとか、そういう複雑な課題を議論する機会もあるのは面白いと思います。
LITALICOの場合は作っている物の種類も、Webメディアから業務系SaaS、支援員の暗黙知をアルゴリズム化してプロダクト化するといった研究開発など多岐に渡ります。なので、いろんなキャリアのチャンスがあるし、キャリアの方向性も多様です。コーディングや実装だけでなく、モデリングの能力をごりっと身に付ける機会は多いかもしれないですね。

Q.モノリス開発とマイクロサービス開発を比較した際に、エンジニアに求められるスキルに違いはあるのでしょうか？

江上：立ち回りでいうと、プラットフォームチームのスタンスの部分でお伝えした、自分の方から関わりにいくことでしょうか。技術的に求められるスキルは、テーブル設計やデータ設計だけではなく、アーキテクチャの部分まで考えられるか、関心を持てるかが必要になってくると思います。

市橋：モノリス開発で曖昧になっていたところも、構造をはっきりさせて理解しないといけないところは大きな違いかもしれません。アーキテクチャの話もそうですが、構造を理解・整理できるとか、言語化するとか、抽象化するといった力がより求められてくると思います。

江上：ドメイン境界というか、境界ってどこ？みたいな、そういうことをすごく考えますよね。
市橋：そうですね。それをより強く意識する機会が増えるんだと思います。

Q.プラットフォームチームと、アプリチームとのコミュニケーション活性化のために意識していることはありますか？

江上：アプリチームで週に一回や隔週でMTGを実施し、全体の進捗や何を目指しているのかを、プラットフォームチームも一緒になって確認できる場を設けています。プラットフォームとして独立するのではなく、アプリケーションの一つとしてプラットフォームもワンチームなんだよ、というのを強く意識できるようにしています。あとは単純に双方のチームが入るSlackチャンネルを早期に立てたり、ランチ会を実施したり、自己紹介の場を早めに設けるといったことはしっかり取り組んでいますね。一緒の場にいるというコミュニケーションのラインができれば、自然に活性化していくのではと思っています。市橋さんは社内のコミュニケーションはどうされていますか？

市橋：結局お互いを知っていることが促進につながると思っていて。僕らは今パートナーさんも含めると150人くらいの組織体なのですが、いかにネットワークを作るか、知り合いになるきっかけを作るかは意識しています。エンジニア全員を集めた部会も定期的に実施していて、グループワークもするのですが、そこで普段接しない人とグルーピングするなどは工夫していますね。お互い知る機会をまずつくることが、活性化の土台だと思います。それが今リモートワークの中で難しい側面もあるので、より意識的にやらないといけないと感じているところです。

江上：LMだとGather（ギャザー）という、バーチャルオフィスのようなツールも活用していますね。雑談が簡単にでき、リアルオフィスと同じような感覚でコミュニケーションが取れるのでめちゃめちゃ良いです。

Q.最後に一言お願いします！

市橋：LMさんとは近しい課題や、やり方をしているところもあって、逆に僕が勉強させていただくことも多く、有意義な時間でした。本日参加いただいた皆さんにも、そういうことが聞けて少しでも助けになっていれば嬉しいなと思います。本日はありがとうございました。

江上：僕もLITALICOさんとLM、近しいところにいるんだなというのをすごく感じました。だからこそ、同じような課題を抱え、同じように解決しているというのがわかって、すごく安心に繋がったと思っています。やっぱり同じような課題だと同じような解決に導かれるんだなというところが、参加者の皆さんにも感じていただけたのではないでしょうか。だからこそ、技術だけではなく組織作りも、組織としての強さに繋がっていくのだと思います。なので、そこらへんも含めてご興味ある方は、LMをよろしくお願いします！（笑）