• 春日 重俊 氏
  Chatwork株式会社　執行役員 兼 開発本部長
• 小野 邦智（Tonny） 氏
  C Channel株式会社　執行役員CTO開発部長
• 太田 寛 氏
  日本マイクロソフト株式会社 Azure ビジネス本部 シニア Azure Product Marketing Manager
• 山田 雄 氏
  株式会社リクルートライフスタイル ネットビジネス本部 データエンジニアリングユニット

1：Chatwork／継続的な組織・システムのバージョンアップ

Chatwork株式会社　執行役員 兼 開発本部長　春日重俊さん

ユーザの拡大に伴い組織、システム、プロダクトを段階的に変革

春日：
Chatworkの春日と申します。私からは、当社がどのように継続的にデータドリブンを行ってシステムをバージョンアップしてきたのか、プロダクトの成長とともにお話していきます。本日伝えたいメッセージでもある「事業・組織・システムはどれも欠けてはならないパーツである」ということを前提として、みなさんの会社をバージョンアップしていくヒントを提供できればと思います。

まずはChatworkについて簡単にご紹介すると、日本発のビジネスチャットを提供している会社です。端的に言えば、非IT中小企業の方にも使っていただけるような製品を目指しています。導入企業数は2019年6月時点で約225,000社です。

Chatworkが誕生したのは2011年で、歴史的には8年ほどの古いプロダクトです。立ち上げから資金調達前までの2015年頃までは開発組織規模が10～20名程度。技術部、デザイン部、事業推進部をCTOがすべて一人で見るような体制でした。この時期は資金調達前で、そもそもプロダクトが伸るか反るかもわからなかったため、非常に簡単な組織構造だったのです。

システム面では、プロダクトのユーザー数が一定規模に達したので、非同期でのトランザクション管理しなければならなくなってきました。そこで、SQSのQueueやCloud Searchを入れるといった形で、少しずつAWSのコンポーネントを増やしていったのがこの時代の特徴です。

私がジョインしたのは2016年の1月なのですが、この頃が第2ステージです。大きくは今までCTOワントップだった組織構造を変更し、CTOの下に私が統括する開発本部を置きました。さらにその下のエンジニアも職能別にして、SRE部やアプリケーション開発部を立ち上げています。
システム面については分散システム（Kafka、Hbase)を導入し、スケールに耐えられるような形で新メッセージ基盤を作成していた時期でもあります。Webhook・OAuth・監査機能・リアクション等ののサブシステム機能が増えていき、どんどんマイクロサービス化しています。

プロダクト自体の進化の視点では、2016年にモバイルアプリをフルネイティブ化したというのが大きな変化ですね。また、2018年には社長交代など組織の環境変化もあり、それに合わせてUIのデザイン変更を行っています。特にWebのUIはすっきりとさせ、情報の視認性を高めるための進化を続けている状態です。

春日：
組織やプロダクト、システムをただ闇雲に進化させていくというのは辛いものがありますから、当社ではデータ分析を活用しています。概念としてはデータ収集層、データソース層、そして分析・可視化層に分けていて、データレイクには基本的にTreasure Dataを使用しています。分析・可視化層でRe:dashやjupyterを使っているのが現在のデータ分析環境ですね。

システム運用観点での例でいうとDatadogのメトリクスなんかはオフィス内に画面を設置して、リアルタイムでモニタリングできるようになっています。数値が急激に上がったら緑色の数値が黄色や赤色になることでチェックできる仕組みです。レスポンスが遅くなっていないか、どこが遅くなっているかなどはNew Relicのダッシュボードで監視しています。最近Chatworkに追加した「リアクション」機能というものがあるのですが、こういったアップデートがきちんと狙った通りに使われているかもモニタリング環境を整えて監視し、継続的に更新できるようにしていますね。

また、経営視点ではシステム原価などのコストも重要です。当社はAWSを使用していますが、サーバーコストが急激に上がっていないか、上がっていればアラートで変な動きをしていないか知らせてもらうようにしています。これはGoogle Data Studioです。

2：C Channel／成長速度を追求するフェーズにおける組織の判断

C Channel株式会社　執行役員CTO開発部長　小野 邦智（Tonny）さん

リファクタリングに至るまでには慎重なプロセスが必要

Tonny：
中国出身でTonnyという名前で活動しています。よろしくお願いします。私は今年の１月からC ChannelのCTOに就任したのですが、ベンチャー企業がどのように考えて成長し、リファクタリングを行っているかについてご紹介したいと思っています。

まず当社がサービスの成長コンセプトとして強く意識しているのは、「本当に必要な時のみリファクタリングをやる」ということです。毎回リファクタリングを行う前にチームに課題を投げ、お互いに詰めてから実施します。理由は「ど」ベンチャーだからです。エンジニアの数も限られていますし、ビジネスも成長に集中しているフェーズです。リファクタリングも含めお金でカバーできる部分はそうして、成長速度を追求しています。

一人ひとりのメンバーがサービスに対するチューニングの意識を高める

Tonny：
C Channelは現在サービスがいくつかあり、台湾や中国にもビジネス展開していますが、人材もお金も足りなくて、プロダクトマーケットフィットを模索中という部分も大いにあります。その中ではパフォーマンスをチューニングする必要性も出てくるので、我々はNew　Relicを利用したかったです。先程春日さんも紹介していたツールですが、非常におすすめです。ただコストが高いので、我々はより安いサービスElasticAPMで定着しています。

もうひとつおすすめなのはAWSのPerformance Insightなのですが、RDSのデータベースを保存するときにQueryもステップ・バイ・ステップで分析して可視化してくれるのがいいですね。有料サービスではあるのですが、節約できる時間を換算すると非常にコスパに優れていると思います。アプリも同じように分析していて、iOSはInstruments、AndroidはProfilerです。

ここでお話したいのは、こういったツールを利用してチューニングやリファクタリングを誰がやるのか、ということです。当然チームメンバーがやらなければならないのですが、時間とトレードオフしてみんなで進めていくことになります。その中で、一人ひとりが自主意識を持って「自分がやる」と積極的に動くことが大切ですね。

3：日本マイクロソフト／PaaSによるリファクタリング事例

日本マイクロソフト株式会社 Azure ビジネス本部 シニア Azure Product Marketing Manager 太田 寛さん

あらゆるツール・フレームワークに対応するMicrosoft Azure

太田：
まず当社のMicrosoft Azureについて簡単にご説明します。一部の方はMicrosoftに対してWindowsやOfficeの会社だというイメージを持っているかもしれませんが、今はもうクラウドの会社になっています。IaaSですね。マネージドやPaaSともいいますが、いわゆるサービスを作ればすぐに動くようにできるというもので、ここを担っているのがMicrosoft Azureです。Microsoftの製品はMicrosoft独自のものだと思っている方も多いのですが、全くそんなことはありません。Azureは一般的なツールやフレームワークはオープンソース系も含めてほぼ何でも動くという状況になっています。

IoT系サービスでMicrosoftのPaaSを用い、スケーラブルな構成を実現

太田：
私自身はお客様の実案件に参画し、Microsoftのテクノロジーを利用して開発を進めたりアーキテクチャの設計の助言などをしてきました。IoT系に5～6年程携わり、最近はビッグデータ系の領域も手掛けています。大小合わせると200以上の案件に関わっていますね。その視点で、リファクタリングについての事例をご紹介したいと思います。

2～3年前ほどの技術案件だったのですが、ちょうどスタートして1年目のIoT系のサービスがありました。センサーノードが設置されていたサーバーにつながるという構成だったのですが、サービスの人気が高まってユーザー数が増えるに従い、サービスの運用能力が限界に近づいていました。サービスに接続するセンサーデバイスが増えたからです。運用・管理コストが増大してお困りだったので、従来のVirtual Machineから当社のPaaS系のサービスを使っていただくことにしました。

本来ならサーバーに対してクラスタを組むことになるのですが、それでは作り直しになってしまいます。そこでIoT Hubというデータベースにつないだり送受信を行ったり管理をする機能を有したAzure IoT Hubというサービスを用いて、スケール可能な状態にしました。パラメータを変えれば、数台から数千万台まで捌くことができます。その他にもリアルタイムに流れてくるデータを処理できるサービスも採用しました。データストアも含め、すべてスケーラブルな構成に置き換えてもらったのです。

仮に最初からこのような構成にして開発していれば、数台レベルではそれなりのコストで、そこから数百台、数万台に増えていったとしても構成を変えず、リアルタイムでスケーラブルにイベント駆動が可能です。既存のプロダクトをAzure化したいときも、1から作りたいというときも、大体はこの構成を紹介します。これはIoTでなくとも、ビッグデータ系などにそのまま使えるアーキテクチャです。

長期スパンで変更を入れずに済むアーキテクチャとは？

太田：
今どきのアーキテクチャでよく聞くのが、データストアが細分化されていて、お互いをつなげられないという話です。これもリファクタリングをするのであればデータ基盤に手を入れることになります。HDFSのようなたくさんのノードから同時にアクセスできるもので基盤を構成して、マイクロサービスとそのフローなどを中間層に置いてつないでいく。あとはフロントエンドアプリをプラグインしていくようなアーキテクチャであれば、長期的にあまり見直しせずに済むと思います。この場合、蓄積したデータを共有してAIの活用などもできます。

4：リクルートライフスタイル／サービスを成長させるデータ基盤の作り方

株式会社リクルートライフスタイル ネットビジネス本部 データエンジニアリングユニット 山田 雄さん

データ基盤の運用に時間をかけないための3つの要素

山田：
私は主務がリクルートライフスタイルで、グループ会社のリクルートテクノロジーズなどの兼務をしています。職務としてはリクルートグループ全体のデータ基盤の開発・運用がメインです。

今回「サービスを成長させる」という点で、私が常々意識している80％という数字があります。これは、基盤系のエンジニアが運用に割いている割合です。もちろん人によっては全く違うこともあると思うのですが、多くの人の話を聞いていると、80％ほど割いている印象ですね。これは非常に高い数字なのですが、運用以外の開発などにも注力したいので、本来は10％くらいになってほしいものです。

では、データ基盤の運用に時間をかけないようにするにはどうしたらいいのか。

私はいくつかの要素があると考えています。まずはScalability。データはすぐにキャパシティを超えます。先程の太田さんのお話にもあるように、IoT分野などではデータ量が爆発的に増えることがあり、度合いも予測できない。その中でも基盤だけは落としてはいけないので、予測できないなりにScalabilityを持つ設計が必要になるはずです。

2つ目がマイクロサービス。データ基盤を作る上では、データソース・データ取得・データ加工・データ保存・データ分析・BI施策といった粒度で分けていくことをおすすめします。というのも、データやパブリッククラウドの技術進化はスピードが速く、どんどん良いサービスが登場します。そのときにすぐ対応できるようにしておきたいからです。データ保存の場所やデータ取得の技術を素早く変更できるようにしておけば、運用の手間は減っていきます。ただ基盤を作り込んでしまうと後から分割はできないため、やはり最初の設計が重要です。

意外と重要な基盤エンジニアのモチベーションコントロール

山田：
さらにエンジニア視点でお伝えしたいのですが、基盤の開発には時間がかかる上に、非エンジニアにとっては簡単そうでも、エンジニアからしてみるとそうではないことが数多くあります。ROIを出すのも難しい。その一方で、基盤は一度使えるようになると、それが当たり前の状態になる。つまり、良い基盤を作っても褒められることは無く、トラブルがあると責められる状況に陥りやすいのです。

それを踏まえると、データ活用を進めていく上では基盤エンジニアのモチベーションコントロールが非常に大切です。どうすればいいのかは私自身も悩んでいるのですが、きちんとエンジニアから成果を口にしてもらい、それを社内にも上手く広げたり、何らかの形で褒めたり、給与を上げたりといったことが重要になるはずです。

質疑応答

リファクタリングを「しない」選択肢の裏側にあるもの

春日：
では、ここからは会場からの質問を中心にパネルディスカッションを進められれば思います。

まずは「リファクタリングをあえて制限するという点について、エピソードがあれば聞かせてください」という質問がありました。恐らく、リファクタリングを「しない」という決断に対してはエンジニアサイドの疑問も生まれてしまうところなので、その点についてTonnyさんいかがでしょうか。

Tonny：
リファクタリングをしないという決断をするのは、やるならちゃんと測ってからやりましょうというスタンスを意識する前提であります。前編で述べたとおり社内の人数が足りていないという要素も非常に大きいです。エンジニアを大勢抱えて、一人ひとりが自分の専門分野を深堀りしながらプロダクトをチューニングしてくという体制を夢見てはいるのですが、実際には採用の問題があったり、サービスの成長を優先した結果、「とりあえずやらない」という決断をすることが多いです。

例えば、うちのアプリをダウンロードして開いてみると、起動はさほど速くありません。本当は1秒以内に収めたいのですが、できていない。現在起動時に読み込んでいるAPIが複数個ある状態なので、これをどう束ねてスピードアップするのかさまざま検討はした上で、一旦今の速度のままでいくことにしています。

ただ、この間トラブルが発生して、起動時間が普段の倍以上かかるようになってしまいました。というのも、Apple審査で「ユーザー自身のコンテンツに関しては必ずミュート機能を実装しなければならない」というリクエストがあり、アプリがリジェクトされてしまったのです。ミュート機能は非常にパーソナライズされたデータで、ミュートするデータを探し出して取り除くという挙動はかなり重い。そうなると、さすがにこれは時間を割いてリファクタリングしなければならないだろうということになりました。

C Channel株式会社　執行役員CTO開発部長　小野 邦智（Tonny）さん

必要性に反して、リファクタリングしたくてもできないケースを体験する各社

春日：
リファクタリングはサービスを継続的に成長させていくには非常に重要なテーマですし、悩みの多いところです。太田さんは多くの企業を支援されていますが、各社ではリファクタリングにどう取り組んでいるのでしょうか？

太田：
基本的に日本のお客さんは「変えたくない」という心理が大きいのですが、困っていることがあればやはりリファクタリングが議題になりますね。ただ、本来的には作り直したほうが将来的に新しいサービスを入れ込むのが簡単になるし、運用コストも下がるとわかっていても、政治的な理由で進まないケースが非常に多い印象です。 また、極稀にではありますが、一部の技術屋さんなどがあるサービスを使いたいがためにリファクタリングするというような話もあります。これは危険ですね。よくよく要望を聞いてみると、リファクタリングすべきではないというパターンも存在します。

春日：
基本的にソフトウェアは作った瞬間から陳腐化していくので、やはりリファクタリングは一定割合必要です。ただ、前編のお話にもあったとおりやれば事業インパクトがあるわけではないので、限りなくその割合は減らしていきたいものなんですよね。

その点でChatworkがメンバーに方針として伝えているのは、開発とリファクタリングを目安として7：3にしていこうということです。気持ちとしては8：2、9：1くらいにしたいのですが、プラットフォームがどんどん拡大している状況の中では、一定のリファクタリングはあって良いとしています。

Chatwork株式会社　執行役員 兼 開発本部長　春日重俊さん

エンジニア組織をモノリスにするメリット・デメリット

春日：
では次の質問です。「Chatworkさんは組織を部署で区切りはじめたのはいつ頃でしょうか？6人の会社でどのタイミングで区切るか悩んでいます」ということなので、Chatworkについてあくまでケーススタディでお話します。

まず、10人前後の組織であれば部署を分ける必要はありません。ご存知の方も多いと思いますが、「ピザ2枚ルール」にあるように、大体一人のマネージャーが管理できる限界は8～10人程だからです。

実際、Chatworkは現在エンジニアが40～45名規模で、一度意図的に一つの部署にエンジニアを偏らせるというチャレンジをしてみたことがあります。その結果、1on1に追われすぎてマネージャーが立ち行かなくなった。1つの部署が大きくなりすぎると、モノリスで動きが遅くなってしまうんです。ですから、私の実体験でいえば8～10人規模の単位で部署を割っていくのが良いのではないでしょうか。Tonnyさんは20名ほどの組織ですがいかがですか？

Tonny：
うちは今、あえて束ねていこうとしています。というのも、C Channelのサービス本体と、mystaというサービスがあるのですが、以前はエンジニアが完全に分かれていました、私が両方見ているという状況でした。その中では、ノウハウの共有が遅いという問題が生じていたんです。一つのサークルの中であれば一言でみんなに伝わるようなことができず、結局それぞれの組織で同じ問題が起きてしまっていた。そこで最近あえてこの2つの開発チームを合体させて、1on1も同じタイミングでやるといった取り組みをしています。

小さなオフィスでも20～30人くらいなら収まるので風通しもいいですし、質問者の方の例で言えば6人ですから、分ける必要は全く無いと思います。

大胆な組織開発・運用の変革を実行するための会社風土

春日：
次の質問は太田さん宛てですね。「Microsoftさんは運用8割、開発2割から開発8割、運用2割に変革したと聞いたことがありますが、変革がどうなされたのかエピソードがあれば教えてください」ということです。

太田：
Microsoftはリファクタリングをするかしないかを非常に合理的に判断します。どれくらいの利益を見込めて、人件費などのコストはどのくらいかかって、企画はどうなっているのか、論理的にきっちりしていれば実行するということです。ですから、変革についても合理的なビジネス判断があればやるという風土が背景の一つにあります。

また、WindowsにしろAzureにしろOfficeにしろ、すべてVisual Studioで作っていますし、Visual StudioもVisual Studioで作っています。つまり、Microsoftはみなさんに提供しているサービスのユーザーでもあるのです。それを踏まえてリファクタリングすることもありますし、合理的に考えて利益が投資を上回るのであれば、1から作り直すということも平気でやります。そのあたりの思い切りの良さもあってできた変革なのかなと個人的には思っています。

日本マイクロソフト株式会社 Azure ビジネス本部 シニア Azure Product Marketing Manager 太田 寛さん

いかにして組織の技術的負債を溜め込まないエンジニアを採用するか

春日：
採用まわりについては「立ち上がり時期のエンジニア採用をどのように進めれば良いか苦労しています。各社の採用ノウハウでお話しいただけるものがあれば知りたいです」との質問が来ています。

当社の場合で言うと、私が入社してから1年間は巨大プロジェクトがありすぎて、それを回していくことに必死でした。針の穴を通すような採用をしなければならなかったので、基本的にはスカウトと信頼できるエージェント経由の二本柱でしたね。エージェントは玉石混交なので、当初は10社ほどにお願いしていたのを最終的に1社に絞り込んだことで成功したのだと思います。

スカウトについては、恐らく企業のフェーズによってどういう人材を採用したいのか、はっきりと定義した上でないと組織設計に失敗します。当社の場合注力したテーマが安定運用だったので、SRE部隊も作った上で、そこにジョインしてもらう人材をひたすら1年かけて口説きました。採用した最初の1人が現在のSREのトップです。

Tonny：
うちは個人の力に非常に頼っていますね。優秀なエンジニアで、なおかつ技術的負債についてよく理解している人がいれば、後々の負荷そのものが減っていくからです。例えば採用時は年俸が50万円か100万円かといった違いしかなくても、2～3年後に負債を減らしてくれているのか、それともプロダクトに爆弾を埋め込んでいるのか、そういう視点で人材を見抜けるかどうかがとても重要です。

春日：
山田さんの視点で見ると、大きな組織であるからこそキラーエンジニアを立てるのは大変だと思うのですが、どのように組織づくりをしているのでしょうか。

山田：
「合わない人は合わない」という視点を重視してきたような気がします。技術的に特化した優秀な人材がいても、カルチャー文化がフィットしなかった場合は仕事を楽しめなくなってしまうからです。その結果、なかなか採用するのが難しい状況にはなっているのですが、悪影響を与えてしまう人を入れるよりはマシだという考えはあるかもしれません。

先日はSmartHRさんで60億資金調達して30億は採用に充てるといった話もありましたし、そのくらい採用は大変なのだと思います。

株式会社リクルートライフスタイル ネットビジネス本部 データエンジニアリングユニット 山田 雄さん

サービスごとに安定運用の定義によってリファクタリングの方向性を定める

春日：
では最後に「サービスとなると安定運用が大事になると思いますが、どんなタイミング、どんな箇所のリファクタリングを行っていますか？」という質問です。これはサービスの特性によって異なると思っていて、そもそもそのサービスにとっての安定運用とは何かを決めるのが重要です。当社の場合はチャットですが、チャットが送られて反映するまで数秒かかるのは嫌ですよね。ですからサービスをリリースして10ms、20ms遅れると全体のパフォーマンスがすぐに詰まってしまうような仕組みになっているんです。そこはかなりシビアに運用しています。

山田さんが扱うビッグデータはユーザーがどう扱うのかという視点になるかと思いますが、安定運用の観点についてはいかがですか？

山田：
基盤を見ているエンジニアが今は少ないこともあって、SLOを設けずに負荷なく運用することで乗り切っています。1日落ちたら売上が下がるような部分についてはきっちり守るのですが、どれを守ってどれを守らないのかは、裏で動いている施策も含めて守るものを決定しています。

イベント終了後は、懇親会が行われました。

ご登壇者の皆様、有難うございました！！

企画/編集：FLEXY編集部