こんにちは。BASE株式会社 取締役EVP of Developmentの藤川（えふしん）です。
新型コロナの影響で、広告やインバウンドなど成長と期待されてきたWebサービスの分野によっては採用等を抑える動きがある中で、多くの商品ジャンルを取り扱えるECプラットフォームを担う当社の採用活動に関するスタンスは引き続きポジティブです。その中で、解決したい問題についてお話させていただければと思います。
技術課題１：コンポーネント化、アーキテクチャ刷新に対する学習コストへの適応
手前味噌ではありますが、「BASE」はサービスを止めずにアーキテクチャを進化させてきました。本来であれば、BASE バージョン2のようなものを別ラインで作って入れ替えるような作業を、CTO、テックリードの元で動的にサービスを入れ替える形で実現しています。
思い起こせば、元々の「BASE」は、よくもわるくも、ただのシンプルなCakePHP2を活用したWebアプリだったように思えます。ソースコードは多いながらも、一つ一つは低い学習コストのpost / getとデータベースへの入出力コードの繰り返し。これを駆使してサービスを作ってきました。
それ故に、オンボーディングのコストは比較的低かったものの、増えゆくソースコードの中で全体の冗長性、複雑性は上がっていくばかり。
開発工程が破綻しなかったのは「シンプル」を売りにするからこそのサービス性に恵まれたところは否めません。
しかし、サービスがシンプルであるということには、時に高度さを求められるところがあります。
ユーザーにとっては1クリックで実現できるところが、サーバサイド、すなわち裏側では実はそんなにシンプルではなかったというケースが存在し、それを増えゆくトラフィックの中で維持しつづけるのは意外と大変だったりします。
とりわけエンジニア視点では機能分割したくなる部分も、ユーザビリティのためにそうせずに頑張らなくてならない部分などが存在します。
言い方を変えると、他社であればスケーラビリティを優先した仕様変更を行っていたところを、対応コストをユーザー負担に押し付けるのではなく、どうにか1クリックのままで収まるようにユーザ体験を維持するためには、様々なシステムリソースと引き換えに頑張っていかねばならないシーンというのがあります。
このような部分は、実に細かいことですが差別化要素とも言えます。
そういう頑張りの結果、CakePHP2に依存するWebアプリケーションを作るという範囲のメンタリティだと、ソースコードの複雑性が高くなるところが出てきます。 そのような部分では、「BASE」を織りなすアーキテクチャとしてソフトウエア構造を整理し、メンテナンス性を高くしていかないと、技術的負債として将来の機能追加が破綻する可能性を秘めていたわけです。
このような話は、歴史を紡げるだけの価値を生み、常に発展を模索してきたWebサービスであれば、多かれ少なかれ存在しているはずです。我々も幸いなことに、このような改善を行う機会に恵まれました。
機能が整理されてサービスが高度化する代償としては、学習コストの増加です。
Amazon.comがRestfulなマイクロサービスの集合体になる前は、モノリシックなシステム構造の中で、データベースのマイグレーションに伴うトラブルが部署間で起きていて、その結果、トップダウンでデータベースを分割するマイクロサービス化を行ったと、Amazon CTOのWerner氏の講演を聞いたことがあります。
つまりそうすべき理由があったからというのが一番重要で、それをする理由も見えてない段階で高度化しすぎるのも開発コストや組織的なリスクをもたらします。
そうすべき理由とは、さらなるサービスの成長によってもたらされるものです。
このような構造下で、ビジネスとサービスを成長させるエンジニアリングの両方を満たしていくためには、技術系のリーダーシップを取っていく人員が不足しているように考えています。BASEは基盤整備とサービス性の向上との距離感が、比較的シームレスに存在しているのが特徴です。
これがゲーム基盤とゲームアプリケーションであったり、配信基盤とコンテンツなどと、キレイにレイヤー分けされていれば、もう少しメリハリの効いたチーム構成になるところが、まだ当社においては、そこまでは切り分けられていません。
冒頭に書いた1クリックによるユーザ体験を優先しているが故に、そんな簡単に組織をレイヤー化できないというのがあり、普通にサービスを拡張するにあたって必要な技術とサービス知識が、相応に多岐に渡っています。
少しややこしい言い回しをしてきましたが、Vue.jsやTypeScriptを書ければフロントエンドが書けるわけではないし、PHPやCakePHPが書ければサーバサイドが作れるわけでもなく、サービス知識と設計技術、基礎技術を兼ね備えていることが求められます。
こういった課題解決にピンと来る方に技術リーダーシップを発揮していただいて、チーム全体の技術力の底上げをしていける方を募集しています。
技術課題２：新型コロナで時間軸が圧縮されたことで見えてきたもの
5月15日に100万ショップを超えたことを発表させていただきましたが、ここしばらく新型コロナの影響で新規のショップ開設数が急増しております。また、香取慎吾さんを起用したテレビCMなどの影響もあり、引き続き増加しています。
4月後半、5月のゴールデンウイークでは、新型コロナに対する不安や、自粛に伴う巣ごもり消費によりサーバ負荷やトランザクション数が急増しました。
ショップオーナー様にはピークタイムの大規模販売を5分10分ずらしていただいたりなどご迷惑をおかけ致しましたが、社内では増えゆくPV、増えゆくトランザクションを安全に処理するために、CTOやSREを始めとしたメンバーが日夜、サービスを改善してきたという経緯があります。
その結果、単位時間あたりの処理トランザクション数や受け入れ可能なPVを一気に増やすことに成功し、受け入れ可能な流通総額の向上が成果として現れています。
某製菓会社様がコロナ禍で販売した応援セール商品について自社ECで処理しきれなかった販売が、急遽設立されたBASE支店では難なく処理できたというのも、この改善の成果です。
そもそも歴史ある企業様のネットショップが1日で作れるというのも「BASE」の特徴で、今後もこのような状況が増えていくことを望んでいます。
一方で、このまま時間軸が進んでいき、サービスが成長していくと、最後は、ものすごくプリミティブなところに問題が集約していって、将来に解決できない技術的な壁が存在するところも見えてきました。このような部分もさらなる改善でカバーしていく必要があります。
結局、Webアプリケーションというのは最後はTCP/IPでどう通信するか？という問題に落ちていくので、開発言語がGoだのPHPなどに留まらない視野での改善が不可欠です。mixiやFacebook、Twitterなどはその問題を解決してきたサービスなのだと思います。我々も、こういった問題もまた並列で解決していかねばならないイシューとして顕在化してきてワクワクしています。
今回の改善でしばらく時間稼ぎができましたし、5月は間違いなく異常事態だったと思いますので、新型コロナの第二波、第三波が来ても、物流や経済の流れというECの基本要素さえ壊れない限り、ウイズコロナでは問題なく「BASE」というビジネスを継続していく見通しは立ちました。
繰り返しになりますが、この短期的な時間軸の圧縮を経験し、3年後5年後に向けてのサービス成長への道筋もまた見えてきたというのがあり、これも取り組んでいきたい課題になります。
その際のお話は、弊社のオンラインイベントで、私とCTOの川口との対談でお話させていただくので、是非ご覧ください。
こちらから参加登録いただけます。
サービス開発を通じて、人の成長とサービスの成長を一緒に実現していきたいと思いますので、長くBASEのチームで働いてくれる方を募集しています。
