「事業の目標」を踏まえて技術的方針を決める。薬局業務DXスタートアップが急成長できた理由

株式会社カケハシは「日本の医療体験を、しなやかに。」というミッションのもと、薬局DXを起点に日本の医薬業界の課題解決に取り組むヘルスケアスタートアップです。国内に約6万店舗が存在する薬局ですが、まだまだアナログな業務がたくさん残っており、テクノロジーを用いて変革し得る余地があるとともに成長可能性が高いマーケットなのです。

今回はカケハシの黎明期から同社で働き薬局体験アシスタント「Musubi」のテックリードを務める松山哲也さんと、2023年10月に入社し新サービスの開発に取り組むソフトウェアエンジニアの荻野淳也さんにインタビューしました。

AWS Elastic BeanstalkからAWS Lambdaへの切り替え

――Webメディア「what we use」のインタビューでは、各企業が取り組んできた技術的意思決定のなかで印象に残るものや、そこから得た学びを話していただきます。

松山：まずは、「Musubi」のバックエンドで使用していたAWS Elastic BeanstalkをAWS Lambdaに乗り換えたエピソードについてお話しさせてください。もともと私たちはWebアプリケーションをデプロイするサーバーとして、AWS Elastic Beanstalkを使っており、創業から数年は特に問題なく使い続けていました。

ですが、数年ほどが経過した頃から、なぜかAWS Elastic BeanstalkのサーバーのCPU使用率が100％に達する障害が時折発生するようになりました。おそらく、AWS Elastic Beanstalkもしくは利用している何らかのミドルウェアの珍しいバグを踏んでしまったのではないかと思います。特定のサーバーを長時間稼働させ続けると、その事象が発生するようでした。

簡単にはバグの原因を解明できなかったため、しばらくはサーバーがあまり長く稼働しないように、ある程度の時間が経ったらローリングさせる運用をしていました。また、AWS Elastic Beanstalkは設定が複雑であるなど運用面でも課題があり、何か誤った設定を入れてしまった場合にサーバーの動作に不具合が生じるなどのトラブルも発生しました。

その状況を改善するための方針を考えていたところ、ちょうど世の中でサーバーレスアーキテクチャが流行していたんです。AWS Elastic BeanstalkをAWS Lambdaに置き換えてはどうかという意見が、社内で挙がりました。AWS Lambdaを用いることのデメリットとして、コールドスタートの場合に起動まで時間がかかることが挙げられます。しかし、「Musubi」は薬局の基幹業務で使われるサービスなので、BtoCのサービスのように遅延によって即座にユーザーの離脱が発生しないことと、導入件数の増加に比例してアクセス数も増えており、相対的にコールドスタートの発生確率が低くなることから、ユーザーへの影響は小さいだろうと考えました。そこで、AWS Lambdaに切り替える方針を3年前くらいに選択しました。

荻野：この事例のAWS Lambdaを使う方針もそうですが、他にもカケハシではメインのストレージとしてAmazon DynamoDBを使っているなど、AWSのマネージドサービスを使い倒しています。可能な限り運用にかかる工数を減らして、サービス開発に集中できる体制にしていることが大きな特徴ですね。

――この事例では、どのような方法でシステムの移設を行いましたか？

松山：1回ですべてのWeb APIをAWS Lambdaに入れ替えるのは難しそうだったので、機能単位で移設を行いました。Web APIの前段にはNginxがあるので、設定を入れてURLでのリクエストの振り分けを行い、「このURLならばAWS Elastic Beanstalk側、このURLならばAWS Lambda側」という感じに分岐させたんです。

こうしたインフラ移設系のプロジェクトは、一度にすべてを切り替えるのではなく、段階的に進めるほうが良いと思います。どれだけいろいろなことを考慮しても、必ず想定外のトラブルは発生しますから。たとえば私たちのプロジェクトでも、AWS Lambdaで使用していた特定のライブラリの処理が極端に重たくなったり、AWS Lambdaのレスポンス6MBの制限に引っかかったりという事象が起こりました。すでにユーザーに利用されているサービスの場合は、利用不可能な状態になってはならないので、特に注意深く移設を進めるべきだと思います。

いまでは完全にAWS Lambdaに移行して、運用がかなり楽になっています。ただ、実はこのインフラ移設のプロジェクトを実施している間に重要度の高い別のプロジェクトが発足し、そちらの対応を行う必要が生じました。そのため、このインフラ移設が完了するまでに2年ほどを要してしまったんです。

「ナショナルクライアントを獲得する」方針に舵を切った

――重要度の高い別のプロジェクトとは何だったのでしょうか？

松山：会社としてナショナルクライアント（全国的な知名度やブランドを持つ大企業の顧客）を獲得していく方針を打ち出したのが大きいです。「Musubi」というサービスは、初めは小規模な薬局を対象として顧客の獲得を進めていました。その次に、数店舗から10店舗ほどの規模の薬局を顧客としていきました。そうしたフェーズを経たうえで、ナショナルクライアントを対象としてサービスを導入していくことを選んだんです。

しかし、小規模・中規模な企業と比べて、ナショナルクライアントから求められる基準は高いものがあります。なかにはMusubiがその基準に達していない点もあり、不足している機能を開発組織のすべてのリソースを集中して開発しました。人が足りないため、エンジニアの採用やパートナー企業の開拓なども進めました。その状況が2年近く続き、かなりバタバタでした。

エンジニアの方であれば想像がつくと思いますが、急ピッチで機能開発を進めるとどうしても品質が犠牲になるんですよ。技術的負債が生じたり、バグが頻発したりといった課題も起きました。

――開発組織にはかなり負荷のかかる状況だと思いますが、なぜナショナルクライアント獲得のための新機能開発に踏み切ったのでしょうか？

松山：規模の大きな薬局の場合、使用している基幹システムを置き換えるのは5年おきなどの長期スパンになります。その企業が導入システムを検討するためのコンペも、チャンスを逃すとその後しばらくは実施されないんです。スタートアップがその大きなチャンスを自分たちのものにできず5年が経ってしまえば、資金が尽きて倒産するかもしれません。だからこそ、当時のカケハシとしてはかなり背伸びをしましたが、成長痛を受け入れて急ピッチで新機能開発を進めることにしました。

荻野：それが原因で、後々に技術的負債に苦しむことにもなるけれど、カケハシの事業が成長していくためには必要なことだったわけですね。

松山：そうです。大変な思いはしましたが、ナショナルクライアントへのシステム導入は成功して、事業が大きくなりました。もしこのプロジェクトが失敗していたら、私たちはここにはいないかもしれませんね。

――この事例のように、読者のなかには「大手企業を顧客として獲得していきたい」というフェーズのスタートアップで働く方々もいるはずです。そうした人に向けて、カケハシの事例を踏まえて伝えたいことはありますか？

松山：メンバー全員の“納得感”があることが一番重要だと思います。スタートアップはその性質上、基本的には事業が急成長するかダメになるかのどちらかしかありません。だからこそ、大手企業を顧客として獲得するために、無理をしてでも機能開発を進めなければならないケースもあると思います。会社で働くみんなが、その認識を持っていることが大切ですね。

そういう意味では「Musubi」の開発チームは恵まれていました。会社の掲げるビジョンや事業に共感して、「今は会社の重要なフェーズだから」と理解していただける方が多かったです。

新規サービスの技術を「Musubi」にもフィードバックしたい

――荻野さんは2023年10月からカケハシに参画されましたが、プロダクトや技術などで今後改善していきたいところはあるでしょうか？

荻野：私がいま所属しているチームは新規事業を担当しており、新しいプロダクトを開発しています。「Musubi」と比較すると、採用している技術はさまざまな点が実験的です。たとえば、「Musubi」はAWS Lambdaを中心としたサーバーレスなインフラ構成を用いてストレージはAmazon DynamoDBをよく用いていますが、私たちのチームではコンテナを採用しストレージはAmazon RDSを使っています。

積極的に技術的なチャレンジをして、私たちのチームでうまくいった手法は「Musubi」側にも取り入れるといったことが将来的に実現できるといいですね。基幹プロダクトである「Musubi」の開発チームは業務の負荷が高い状態なので、そちらのチームの役に立てるようになっていきたいです。

また、現在はそれぞれのプロダクトのチームが自由に技術選定をしていますが、今後は採用技術を統一するような構想も考えています。その際に私たちのチームで用いている、既存プロダクトとは異なった技術を比較材料として使ってもらうことができるはずです。

――荻野さんがカケハシに対して感じている、企業としての魅力はありますか？

荻野：私は完全に、“人”に惹かれて入社したんですよ。入社前の段階から、一緒に働くことになるメンバーとの会食の場を設けてもらいましたが、すごく心地良くコミュニケーションができました。

松山さんが先ほど、「会社の掲げるビジョンや事業に共感している人が多い」という話をしていましたが、そういった特性を持つ人が集まっているからこそ、快適な雰囲気が生まれていると思うんですよね。入社してからも、それを毎日実感しています。

それから、採用面接の段階でVPoEである湯前慶大さんから「ぜひ、エンジニアとして手を動かすことに専念してほしい」という声をもらったこともうれしかったです。私は年齢が50歳近いんですが、一般的にはこのくらいの歳になると会社から「マネジメントをしてほしい」と要望されることが多いです。

ですが私は、もっとコードを書くことを追求したいという思いがありました。だからこそ、プロダクト開発の最前線でお客さんと向き合いながらエンジニアとして働けるカケハシの環境は、すごくありがたかったです。

エンジニアが最優先にすべきは“事業”

――今回のインタビューを踏まえて、プロダクト開発に携わるエンジニアが大切にすべきマインドをお話しください。

松山：私が思うのは、エンジニアが最優先にすべきは“事業”だということです。会社がどのような状況で、何を目指しているのかをエンジニアも理解する必要があります。お話しした事例のように、大手企業の顧客を獲得するための機能開発が求められるフェーズも、その逆に機能開発を止めてでもシステムの安定性を向上させるべきフェーズもあると思います。

技術はあくまで何かを実現するための手段だと私は思っているので、達成すべき目標が何なのかを自分なりに考えて、そのうえでメンバー同士で議論して認識を合わせていくことが大事ですね。

荻野：松山さんが言われたように、あくまで技術は手段であると捉えて、その道具を使っていかに会社のビジョンを実現していくか、自分たちの住む世界をより良い状態にできるかを考えて、行動していくべきだと思います。

一方で、エンジニアはやはり自分の思い入れのある技術に触れていないと、力がフルに発揮できないという側面もあるじゃないですか。だからこそ、個人的なこだわりは捨ててほしくないところでもあって。事業が目指している目標と自分の好きなこと・やりたいことをどうすり合わせるかを考えていくと、エンジニアはより良いキャリアを実現できると思います。

松山：それと近いことを、私はメンバーとの1on1でよく話しています。ベン図で「会社としてその人にやってほしいこと」と「自分自身がやりたいこと」を可視化した場合に、2つの円が重なった箇所の仕事をするのが、一番良いですね。

荻野：それに加えて、「自分自身がやりたいこと」の円を広げていく作業も大事ですよね。事業や技術についての勉強をすると、自分が面白いと思える領域はどんどん広がっていくので、会社が求める役割と自分のしたい仕事が重なる部分がより大きくなっていくはずです。

――最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？

松山：「論点を学べること」が重要だと思っています。要するに、何かの技術的な方針を決める際に「YESかNOか」は企業や人によって判断が分かれます。でも「何を判断軸として方針を考えなければならないか」という技術的な論点は、どんな企業や人でも似通っているはずなんです。先人たちが何を論点として挙げてきたのかを学ぶことで、より良い決断をできるようになると思います。

荻野：私は勉強会などに参加して、参加者同士で悩みを共有したり、すでに他の人が経験した事例を教えてもらったりすることがよくあります。やはり、情報交換をすることでお互いにとっての学びになりますし、それによって業界全体が前進していくと思うんですね。

エンジニア仲間と飲み会などでワイワイ話して、優秀な人たちからいろいろな事例やノウハウを聞けると、いつも元気をもらえます。エンジニアとしてたくさんの仲間を作ることや、その仲間たちと良い議論をすることは、キャリアを豊かにしてくれると思います。

取材・執筆：中薗昴

撮影：山辺恵美子

提供：株式会社Haul