Case Study
株式会社ベガコーポレーション

―今日はお忙しいところどうもありがとうございます。まず、ベガコーポレーション様の事業について教えてください。

石村俊幸さん：家具・インテリア等のインターネット通信販売事業であるLOWYAの運営と、越境ECプラットフォーム DOKODEMOの運営を事業展開しております。主力であるLOWYA事業は、自社オリジナル商品の企画・開発を行い、製造自体は外部に委託しているものの、商品の撮影やWEBページ製作については自社で行い、自社ECサイトおよび3大モール(楽天、Amazon、PayPayモール)にて販売しています。その裏では、自社倉庫に在庫を持ち、入荷や出荷などの物流管理や品質管理、販売後のカスタマーサポートまで自社で賄い、非常に長いバリューチェーンを持っているのが弊社の特徴です。 従業員数は2020年9月末現在で237名おり、エンジニアのチームは、自社EC開発チーム、バックオフィス系システム開発チーム、分析やデータ戦略を担うチーム、越境EC事業開発チーム、合わせて約60名のエンジニアで事業を技術的に支えております。

―家具のビジネスについて、ほぼすべての段階を自社で実施されているわけですね。

石村さん：はい、一気通貫という形でやっています。こういう形で事業を進めている会社は多くはないと思います。それが私たちの強みの１つだと思います。

―自社ECサイトのほかに3大モールにも出店し続ける理由は？

石村さん：当初は、販路を多くすることで認知度や販売力の低さを補い売上を高めていくためにモールに出店するところから事業を始めました。事業が成長するに伴い、ブランディングなど付加価値をつけやすい自社ECサイトを立ち上げ、ここにお客様を集約することを目指しています。昨年は売上高の半分以上を自社ECサイトを経由するようになりましたが、現在は両方の販路をしっかりと運用しお客様に購入して頂く段階だと捉えています。

UX改善のためECサイトのプラットフォームを自社開発に切り替え、運用も自社で担当

―PagerDutyを導入されたのは昨夏だったと思いますが、その経緯を教えてもらえますか？

―自社ECサイトのリプレースというとかなり大変な作業だったのではないのでしょうか？

石村さん：まず大前提として、バックオフィスはリプレース前から別システムとして整備しておりました。他社ECサイトからの情報は、自社ECサイトと同様にバックオフィスとデータ連携されるようになっています。つまりお客様の決済後にデータを受ける仕組みは備わっていますから、その入れ替えにはあまり手間がかからず、入れ替えたあとも、以前と変わらないオペレーションが作れました。

―そもそもなぜ自社ECサイトのリプレースを実施されたのでしょうか？

石村さん：大きな理由の1つは、自分たちで制御できる範囲を広げたかったのです。パッケージの場合は、カスタマイズはしてくれますが、何より時間がかかります。自分たちで作ったものなら2、3日で終わるものが、パッケージの場合は見積もりを取って、お願いしてから納品まで2週間くらい平気でかかってしまうのです。当社はスピード感を非常に大事にしていますから、コストをかけてでもスピードを取りに行ったというところがあります。

LOWYAサイトをご覧いただくと分かると思いますが、家具に特化した、非常に見た目も綺麗なサイトになっています。ところが既存のパッケージだとどうしてもかゆいところに手が届かないこともあります。自分たちが家具のプラットフォームを作っていくうえで、自分たちでやり切れる、ということも大事な点だったと思います。 もう一つ、これが技術者としてはここが一番大きいかもしれませんが、スマホのネイティブのアプリケーションが今までのパッケージでは作りにくかったのです。ネイティブアプリケーションを作るメリットは、優れた顧客体験を提供できることで、特にストレスのない操作性や快適さを提供できることが一番だと思っています。その実現にはECサイトからのデータ連携が重要なのですが、今までのパッケージでは難しかったのです。自分たちが思うようなデータを取り出して、最高のネイティブアプリケーションを作るには、もう自分たちでECサイトを内製するしか道がなかったのです。

―なるほど、良く分かりました。アジャイル開発という面でもパッケージは制約がありそうですね。リプレースされてからはアプリを頻繁にアップデートされているのでしょうか？

石村さん：ええ。今は1週間に1回くらいの定期的なリリースに切り替えてもらっています。その中に入れられる要素も以前よりもかなり増えましたし、リリース自体、以前は要望を頂いてから実現までに2週間かかっていたのが、今は2、3日で完了することが多くなりました。

New RelicとAmazon CloudWatchを組み合わせて運用

―PagerDutyとどんな監視ツールを組み合わせてお使いですか？

小原さん：監視ツールとしてはNew RelicとAmazon CloudWatchを組み合わせています。軽微なインシデントはSlackに、特にクリティカルなものはPagerDutyで通知を飛ばして、ちゃんと担当者の電話が鳴って気づけるように、という形にしています。システムリプレース以前は外部からしか監視が出来ませんでしたし、技術者が障害に気が付いたらパッケージの開発元に電話をするしかなかったのです。

石村さん：パッケージの開発元とはオンコールの契約も結んでいましたが、担当のエンジニアが常に空いているわけではありませんでしたし、精通したエンジニアが休みを取っていて、解決に時間がかかることもありました。細かくいうときりがありませんが、対応に関しては全体的にスピード感が欠けていると感じていました。

―ECサイトが停止した場合、その間の売上高がなくなるわけですが、それは定量的にわかりますよね。

石村さん：そうですね。実際に、先方が作業したことでサイトが止まった場合はいくらの損失になった、というお話もしたことがあります。全然楽しくない会話でしたが（笑）

自社のEC（プラットフォーム）に切り替えたからと言って、その直後から売り上げが上がるわけではありません。しかし、「ECの可能性を無限大に」という当社のビジョンを目指していくにあたり、「自社のECサイトを外注しているのはおかしくないか？」という話でもありました。リプレースしたことで、復旧までにかかる時間は明らかに減っていると思います。やはりエンジニア自身が動くのが早いですし、「あ、ここが悪いね」とすぐ気づいてくれるようになりましたから。

―外注をやめて自社で24時間365日のオンコールを実現するとなると、社内の体制づくりにもコストがかかったのではないですか？

石村さん：はい、そうですね、オンコールについては新たに手当を出しています。24時間365日対応を本当に実現しようと思ったら、3人体制で2回りの体制がいるのです。それを外注するコストを考えると、自社のエンジニアがいて対応できるのだから、手当を出して中でやったほうが安い、という判断でした。ここは非常に迷うところでもあります。売上の規模からいえば、正直、外注してもいいと思っていますが、それはもっと会社の規模が大きくなったときに検討しましょう、ということで進めています。

あらかじめ計画した対応フローを1、2週間で実装完了

―導入の際に困ったことはありませんでしたか？

小原さん：まずはスケジュール設定をして、エスカレーションをするだけでしたから、それほど苦労しませんでした。御社の日本語のヘルプサイトがとても役立って、本当に1、2週間で設定が済んでしまいました。事前にやりたいことが決まっていたからということが大きいです。 今のところは、ユーザーが設定した通りにエスカレーションする、という使い方をしています。 そもそも当社では、SLOやSeverity Level別の障害対応フローを細かく用意していまして、こういう障害のときにはこういうエスカレーションをする、ということを決めていますし、アラートのレベルによってツールを使いわけています。オンコール担当もプライマリーとセカンダリ―を決めてスケジュールを組んでいます。障害対応フローについては、定期的にレビューをしながら内容をブラッシュアップしています。先にも言いましたように、軽い障害はSlackにしか飛ばさないでおいて、サイトが停止したとか、DBがフェイルオーバーしたというようなクリティカルなものはPagerDutyに飛ばすようにしています。その先の通知の仕方はユーザーの好みに任せていますが、まずはアプリにプッシュ通知して、5分後には社用携帯を鳴らして、それでも出なかったら家電にかけて、というように、絶対にどこかで気づく形に設定してください、とお願いしています。

―現状では何か課題や不満は残っていますか？

小原さん：高度な機能について、例えばインシデントレスポンスについては、インシデント管理をちゃんとやるのなら、これからPagerDutyでやろうと思っているところです。 機能面では、できれば障害対応の記録をすべて時系列でログに残すことができれば良いと思います。今は何かインシデントがあればまずSlackに集合して対応をして、そこでやり取りをして、そのあとで別のドキュメントに記録を残して振り返り（ポストモーテム）をしています。Slackでやり取りをするよりも障害対応が楽になる、というメリットがないと、別のツールにはなかなか移れないですね。 それから、障害対応が始まると、みんなが復旧に集中してしまうので、定期的に「今どんな状況か」「あとどのくらいで回復できるか」を、PagerDutyが自動的にエスカレーションして知らせてくれると助かると思いますね。今はインシデントコマンダー的な人が報告役をしている状況です。Severity Levelごとに、こういう関係者に通知する、ということをしたいのですが、よい方法があれば教えてください。 それと、日本語化ですね。通知の電話が（自動音声の）早口の英語ではなく日本語でかかってくるなら、さらに嬉しいですね。

―なるほど。貴重なご意見をどうもありがとうございました。