こんにちは！TECH Street編集部です！
2022年6月23日（木）に開催した、 「各社のサービスを支える技術スタック知見共有会」のイベントレポートをお届けします。今回は下記プロダクトについて技術を選定した理由やこの構成にしてよかったこと、そして今後の課題などをお話いただきました。
◆Fanicon
◆「求人ボックス」｜求人情報の一括検索サイト
登壇者は
城 弾さん／THECOO株式会社
佐藤 佳さん／株式会社カカクコム
早速、内容を紹介いたします！
まずはTHECOO株式会社 城さんの発表です。
IPOまで耐え切る技術選定について
今回はゼロからサービスを作るにあたって、どのような技術、特にどのようなSaaSを選んできたかについて紹介いたします。
今後新たなサービスを構築する人達の素早い判断や実装の一助になり、日本に色々なサービスが生まれて、経済も豊かになってほしい…という想いを込めています。
まずはTHECOOの会社概要と『Fanicon』についてご紹介いたします。
THECOOについて
会社名
THECOO株式会社
※開発部情報
設立
2014年1月
主な事業として会員制ファンコミュニティプラットフォーム『Fanicon』の運営とインフルエンサーマーケティングを行っています。
『Fanicon』について
『Fanicon』はアイコン(ファンのみなさんに愛される方々)とファンとの双方向コミュニケーションを実現する会員制のコミュニティアプリです。SNS全盛期における課題を解決する、新しいコミュニティプラットフォームを提供しています。
主な機能としてはこちらです。
・ライブ配信
・ECサイト運営
・チケットの販売
ファンクラブにコミュニティ機能が付いているというイメージです。
続いて『Fanicon』の技術選定についてご紹介します。
決済プラットフォーム
Stripe
https://stripe.com/jp
「Stripe」はインターネット向け決済処理プラットフォームです。
『Fanicon』のクレカ決済はこちらのサービスを使用しています。
Stripeの利点
①サブスク機能が元々ついているので、開発の必要がなく、スピーディーな対応が可能。
機能例
・トライアル期間
（例）最初の1週間だけ無料などの設定ができる
・多様なプラン設計
（例）特定のプランの人だけライブ視聴可などの設定ができる
②APIと管理画面のUIがとても美しい。
③手数料がとても安い。
AppleやGoogleには30％支払う必要がありますが、Stripeは4％。利益率を担保することができます。
サービス開発する時はまずStripeを利用すると良いかもしれません。
ライブ配信
Amazon Interactive Video Service (Amazon IVS)
https://aws.amazon.com/jp/ivs/
「Amazon IVS」マネージド型のライブストリーミングソリューションです。
Amazon IVSの利点
①導入が簡単
②低遅延
実際に作ってみたところ、QA込みでサーバーサイドエンジニア1人が5日、アプリエンジニア2人が3日程で導入完了。駆け込みでリリースまで進めることができました。
また、遅延がなく、安定しているので、予算に余裕があるならAmazon IVSをおすすめします。
ビデオ通話
Agora
https://jp.vcube.com/sdk
「Agora」は低遅延の“LINE電話“のような機能が手軽に作成できるサービスです。
コラボ配信機能なども目的にあわせて構築できるので、使い方によっては、幅広く活用することができます。
ただコラボ配信機能に関しては「簡単に…」とまではいかないので、シンプルにLINEのような通話機能を作りたい場合はおすすめのサービスです。
EC
OPENLOGI
https://service.openlogi.com/
「OPENLOG」は倉庫管理や配送業務などを全部一気に引き受けてくれるSaaSです。
OPENLOGIの利点
①物流や配送などは全部OPENLOGIに任せることが可能。
ECのフロント画面を用意するだけ。自社で倉庫を用意する必要もなく配送業者に荷物を預ける必要もありません。さらにAPIで全ての操作をするので、商品の配送依頼をシステマチックに実行することができます。出庫依頼や在庫の確認が、内側のサーバーでコントロール可能です。
②APIで様々な操作が可能。
出庫依頼や在庫確認など自社のサービスに合ったECを作ることができるのは大きいと思います。
ライブの監視
Amazon Rekognition
https://aws.amazon.com/jp/rekognition/
「Amazon Rekognition」は機械学習の専門知識なしに使えるAWSの画像認識サービスです。
コミュニティ内の健全さの担保するためのライブ監視を目的として「Amazon Rekognition」を利用しています。
・変なライブが流れてないか
・悪影響なライブが流れていないか
・犯罪に関するライブが流れてないか
上記のようなトラブルを防ぐために欠かせないサービスです。
Amazon Rekognitionの利点
①IVSと繋ぎこみが可能。
ライブ動画内に性的表現や、ドラッグ、暴力などの表現があると高精度で見極めてくれます。
②機械学習などの知識を必要としない。
ライブ動画は Rekognitionにてチェックしてもらうだけで危険性を見極めてもらうことが可能です。
とても使い勝手が良いのですが、割高なので、費用対効果を考えて検討することをおすすめします。
まとめ
自社開発のメリットは多数ありますが、SaaSサービスでマッチするものがないか探す価値はあります。
SaaSを利用して空いた時間で様々な立場の人とコミュニケーションを取り、ユーザーと向き合うことが大事だと考えています。
続いて株式会社カカクコム 佐藤さんの発表です。
「求人ボックス」の急成長を支える技術的取り組み
今回は「求人ボックス」についての技術スタックや取り組みを紹介いたします。
まずは会社概要と「求人ボックス」についてです。
カカクコムは1997年に創業。Web業界では長い歴史を持つ企業です。
購買支援サイトの「価格.com」やレストラン検索予約サイトの「食べログ」など、20以上のサービスを運営しています。
カカクコムについて
会社名
株式会社カカクコム
上場取引所
東京証券取引所プライム市場
従業員数
連結：1,301名（2022年6月末 現在）
※取締役、契約社員、派遣社員及びアルバイトを除く従業員ベース
求人ボックスについて
「求人ボックス」はカカクコムが2015年より展開する求人情報の一括検索サイトであり、下記のようなサービスを提供しています。
【ToC】仕事を探す人向け
全国の転職サイトや求人サイトから、1,000万件超の求人情報を集約してわかりやすく提供。キーワードや給与、勤務地、こだわり条件などから求人情報を検索できるサービスや、応募支援サービス（プロフィールや応募した求人情報を保存する機能など）を提供しています。
【ToB】人材を探している人や企業向け
求人情報の掲載（有料広告/無料広告）から採用まで行えるプラットフォームの提供をしています。
様々な機能を提供している「求人ボックス」ですが、サービス開始から約7年が経過し、大規模サイトへの急成長段階に入っています。
続いて「求人ボックス」の全体構成や、技術課題への取り組みを紹介いたします。
システム全体構成
基本構成
LAMP
※Linux/Apache/MySQL/PHPで作られています。
プログラミング言語（サーバサイド）
PHP
Webフレームワーク
Symfony
全文検索エンジン
Apache Solr
データストア
Redis
「求人ボックス」のシステムは、オンプレサーバー上で動いていて、現在Webサーバーが5台、採用ボード（※）専用のサーバーが2台、それぞれLB(Load Balancer)に繋がっています。
裏側では、Apache Solrが求人検索機能を提供し、料金システムがクリックの集計などを行っています。
バッチサーバやクローラー専用のサーバも動いています。
※「採用ボード」とは求人情報の掲載等が行える企業向けプラットフォームです
また、「求人ボックス」では独自のソフトウェアアーキテクチャを考案・導入しているため、導入の経緯も含めまとめていきたいと思います。
システム改善に向けた技術的取り組み
サービス開始からシステム全体構成の大部分は変わっておらず、LAMPやSymfony、Solrは、この頃から採用しています。
採用理由は、ずばり「コスパが高いから」。
当社は多くのWebサービスを運営してきた実績があり、他のサービスで使われている技術を採用するのが、最もコスパが高いと判断しています。
例えばLAMP構成は、他の新規事業が同様の構成のため、ナレッジや人的リソースなど協力しあえる体制が組めましたし、Solrは「食べログ」など大規模サービスでの活用ノウハウがあり、それを活かせることが決め手となり導入に至りました。
インフラに関しても、それほど大きいコストはかからず進められたのは、全社的なインフラ管理チームからの協力が得られる状態だったことが強いです。
長年Webサービス企業として事業を続けてきたカカクコムだからこそ、様々なノウハウが社内に蓄積されています。
ここまでサービス開始当初の話しをさせていただきましたが、ここからはサービス成長に伴い生じた問題をご紹介します。
「求人ボックス」は2015年頃にサービスを開始した後、私が入社する2020年頃には月間500万人が利用する大規模サービスに成長していました。
スピード成長の陰にはいくつか問題も発生していて、その中の一つがソフトウェアの作り方の問題です。この問題の解決策として、今回のお話のメインである、ソフトウェアアーキテクチャが導入されることになりました。
エンジニアであれば一度は経験するような問題が「求人ボックス」にも少しずつ増えてきてしまい、何が原因なのかを考えた結果「“開発の指針”がないまま、開発が進んでしまったこと」という解釈に至りました。
知識量や経験などが異なるエンジニアが集まる中、“開発の指針”がないまま進んでしまったため、様々な実装が入り混じり、結局は変更や改修が困難なコードが出来上がってしまったのではないかと考えています。
そこで「求人ボックス」の開発をエンジニアがストレスなく行える状態を目指して、“開発の指針“を模索することにしました。
その中で大きなキーになったのが、「求人ボックス」独自のソフトウェアアーキテクチャです。
「求人ボックス」独自のソフトウェアアーキテクチャ
このアーキテクチャは、いわゆるクリーンアーキテクチャなどの考え方をベースに考案されており、ソフトウェアをどのようなレイヤーに分けて考えるのか、各レイヤーではどのような構成をすれば良いかが示されています。
工夫ポイント①
「設計を意識しなくてもいい設計」
開発者が次々に参画しては移り変わっていく中で、高い理解度を必要とする設計や複雑な決まりごとの上に成り立つ設計はふさわしくないため、設計自体のことを意識しすぎなくても良いように設計されています。
工夫ポイント②
「コードをテスト可能な状態にする」
エンジニアが開発しやすい状態にするためには・・
↓
テストが可能なソフトウェアでなければならない
↓
そのためには変更がしやすいコード、設計になっている必要がある
↓
そのような設計を一発で達成するというのはなかなか難しいため、リファクタリングを重ねて、それを達成していく必要がある
↓
安心してリファクタリングを設置していくためには、最終的に動作を担保してくれないといけない
このようにどんどん掘り下げていき、「コードをテスト可能な状態にする」にたどり着きました。
現在のアーキテクチャの導入効果と課題
一番大きい効果としては「テストが可能なコードが増えたこと」ですが、一方で課題も残っています。
その課題とは「意外にテストが増えなかったこと」です。
「書けない状態」から「書ける状態」になったのは大きいですが、まだ「書きやすい」とか「書きたい」といったレベルには行き着いてないため、ソフトウェア設計以外にも、テストを作るスキルも改善が必要と思っています。
今後の展望
今後の展望としては、アプリケーションの疎結合化とインフラのスケーラビリティ強化を行う予定です。
①アプリケーションの疎結合化
「求人ボックス」にAPIを入れて、提供する機能を拡充させ、より疎結合されたアプリケーションを開発したいと考えています。
※現在は一部の機能のみAPIが実装されている状態で統一された設計になっていません。
＜理由＞
機能を疎結合することで、様々な形態でのサービス提供を実現するためです。
「求人ボックス」では最近、Android向けアプリをリリースしました。さらにiOS向けのアプリも進めていく予定ですが、まだAPIによる十分な機能提供ができていない部分があるため、APIを活用して、よりスピード感のあるサービスの拡大を目標としています。
②インフラのスケーラビリティ強化
現状「求人ボックス」のほとんどのサービスは、Dockerやクラウドサービスなどを使用していません。そのため、リソースを無駄にしてしまい、スケールしにくい状況です。
例えば、「求人ボックス」は1000万件の求人を掲載するために大量のクローラーを動かしていますが、これは現状、プロセスを並行で動かすことで実現しています。リソースを最大限効率的に使えているかと言われると不明です。そのため、今後は大規模なオーケストレーションを実現して、さらなるシステムの拡大や、安定化を図っていきます。
またAWSやGCPといったクラウド技術についても、現在は一部の機能しか使えていないので、今後はインフラとしての業務を視野に入れていきます。
まとめ
開発チームとして独自性を追及することよりも、確立した技術をきちんと使っていき、全員で地道な改善を続けて、ユーザーにより良いサービスを届けていく必要があると考えています。今後さらにサービスを拡大させて、サービスとエンジニアがともに業界をリードできるような存在になるよう挑戦を続けていきます。
城さん、佐藤さん、発表ありがとうございました！
Q＆Aコーナー
続いてQ＆Aコーナーであがった質問を紹介します。
（Q）THECOOさん、AWS推しとのことで、他のクラウドサービスとの比較もされましたでしょうか？
城 弾さん
元々Googleの社員が作った会社。基本的にはライブ以外はGCPで動いています。AWSの細部サービスを使ってみたら、凄く良かったのでそのまま使っています。IVSは知り合いがいて、使い方が分かったのでこれを選定した。スピードを選んだ結果です。
（Q）サービス選定の際のポイントをお聞きしたいです。（APIがきれい、が印象に残りました）
城 弾さん
APIがキレイかどうかは重要視しています。そしてエンジニアフレンドリーなサービスを優先しています。理由は、「エンジニアのモチベーションが上がるから」です。あとは、グローバルで使われているものをえらんでます。
（Q）困っている点とかもききたいです
城 弾さん
採用です。採用はミズモノなので、計画に載せにくいですね。
佐藤 佳さん
サービスが拡大していく中で扱うデータ量が膨大になってきています。このあたりのスケール対応です。
（Q）カカクコムさんもやはりサービス毎に部隊も技術スタックも違う感じですか？
佐藤 佳さん
各サービスごとに開発チームが組まれていて、それぞれが自分たちで使用する技術を選択しています。そのため、サービスごとで技術スタックは大きく違う場合もあります。
（Q）技術スタックを組んでいく時に障害になること。あと採用したものを大幅に変更（取り下げ）する時の主な理由について教えてください。
城 弾さん
①中国のOSSを使いたいが、読めない…。というのが障害になっています。
②もっと良いサービスが出てきて、そちらへ変更するコストが低いとき。新しいサービスが上回っているなら、乗り換えはアリだと思っています。
佐藤 佳さん
①開発チームだけでまわしているわけではないので、他チームとの調整などは手間がかかっています。
②必要なときに必要なものを取り入れています。そのため入れてから変更ということはあまりありません。利用がしにくくなってしまったタイミングで変更ということはあります。
（Q）テストの話が出たので色々聞きたいですが、多くの種類の技術を採用するとテストも多種多様になりますよね。どう管理してますか？
佐藤 佳さん
PHPのテストや画面のテストの場合は専用のテストツールを使っていたりします。どこにどのテストツールを使うかは、都度チーム内で検討して決めています。
（Q）今後の展望などを決めるのは各サービスの技術担当ですか？他のサービスとの横展開とか情報共有は有りますか？
佐藤 佳さん
サービスごとの展望は、そのサービスを作っているチームで決めています。そこに必要な技術を他サービスが使っているのであれば、その技術は横展開することもあります。
（Q）求人ボックスさんの開発エンジニアは何名体制でしょうか？
佐藤 佳さん
各開発チームの人数はお答えできませんが、全社員の4分の1がエンジニアになっています。
（Q）サービスは24時間提供だと思いますが、 営業時間外(土日、深夜帯)などの障害時の体制は どのような感じでしょうか。 （シフト制組んでる、外部委託しているなど）
佐藤 佳さん
担当者を置いて、障害を検知した際に担当できる人を内部でまわしています。問題が起これば、その人が対応します。人が足りなければ、都度チームに連絡をします。障害対応はエンジニアが担当しています。
（Q）クラウド上のOSのパッチやファームウェアのバージョンアップなど運用回りはどの程度自動化されていますか？ 最近、半年ごとぐらいにアップグレードが発生するので悩みの種になっております。
城 弾さん
僕も悩みの種です。ビジネスもまわしているので、できているのは100点ではなく半分くらいです。ヤバいところから処理しています。
佐藤 佳さん
「自動化」はあまりできていませんが、他サービスのチームとの横のつながりを活かし協力しあっています。順次必要に応じて対応しています。
いかがでしたでしょうか。皆さんがサービス開発時の技術スタック選定において少しでも役に立てればうれしいです。
次回のイベントレポートもお楽しみに♪
