複数プロダクトの立ち上げ失敗から学ぶ「スピード開発」を実現するための工夫
株式会社LayerX
バクラク事業 ソフトウェアエンジニア 松本 駿氏
最初に登壇したのは、LayerXで支出管理サービス「バクラク」シリーズの「バクラクビジネスカード」「バクラク電子帳簿保存」において、バックエンドからフロントエンドまで幅広く担当するテックリードの松本氏。
バクラク事業では、「圧倒的に使いやすいプロダクトを届け、ワクワクする働き方を。」とのビジョンを掲げ、手作業が多くなりがちな請求書処理、経費精算、稟議申請などの支出管理業務の効率・デジタル化を、一気通貫でサポートしている。
スピード開発と安定稼働を実現するために、松本氏は主に以下3つの点を意識しながらプロダクトの開発を進めた。
◆爆速開発×安定稼働を実現するために意識したこと
- ドメインロジックの実装など、本質的な部分に実装する時間を費やせること
- 爆速開発したものでもバグが起きにくい
- 開発に携わるメンバーが自然と効率くよく開発できること
「LayerXはバックエンドが得意なエンジニアが多かったため、私はフロントエンドを中心に開発に取り組みました。プロダクト限定ではなく、他のプロダクトにもレバレッジが効く改善を意識しました」（松本氏）
松本氏は先3つの意識に準じて、大きく3つの改革を行った。1つ目は、ドメインロジックの実装など、本質的な部分の実装する時間を増やすことだ。
具体的にはそれまで実装されていなかったコード生成の仕組み、OpenAPI generatorやtypescript-vue-apolloを導入。開発言語はバックエンドがGo、フロントエンドはVue.js、Nuxt.jsを用いた。
コード量を少なくするために、それまでOptions APIで書くことが多かったが、Compostion APIも導入。その結果、コードを把握しやすく、テストを書きやすい状態が構築できた。
Vueで意識せずに開発を進めると、templateの型が甘く、props漏れなどが起きやすい。間違っているのにビルドされてしまうようなこともある。
このようなトラブル、バグを防ぐ対策として、Vue.jsの開発において様々なサポートを担う拡張機能、Veturを採用。templateの型をチェックすることで、propsの漏れや型の違いを防ぐようにした。
さらには、データのキャッシュ目的で入れていたVuexを、必要がない箇所はswrvに置き換えた。その結果、少ないコード量で、データ取得における状態管理、再取得、キャッシュが容易になり、より型安全に簡単に実装できる方向にシフトしていった。
続いて、明細データを即時連携するなど、シリーズ累計3000社以上が導入している経理処理業務を効率化する次世代法人カード、バクラクビジネスカードにおける取り組みが紹介された。
バクラクビジネスカードは、サービス画面・与信・入金処理といった社内の管理業務を行う画面と、2つのフロントアプリケーションから構成されている。今回、この2つのフロントエンドを刷新することとなった。
技術スタックは上記スライドのような構成とした。これまでの開発はVue.jsが中心であった。Reactの採用を決めた理由を、以下のように語っている。
「エンジニアが慣れているという点では、Vueに優位性がありました。しかし、既存プロダクトで利用しているOSSのBootstrapVue.jsがVue3非対応だったため、TypeScriptの恩恵が受けられず、既存のリソースを再利用することが難しかったからです」（松本氏）
松本氏はReactに移行しても生産性が出せるように、様々な工夫や取り組みを行った。例えば、LayerXではデザイナーが実装まで行うケースも多いため、デザイナーと一緒にペアプロを実施。Vue.jsとの差分を説明しながら、小さい開発案件に取り組んでいった。
結果として生産性を落とすことなく、スケジュール通りに開発は進んだ。その他に採用した技術についても、それぞれ理由を説明していった。
特にMonorepoの導入においては、「開発メンバーが自然と効率よく開発できる体制の基盤づくり」に貢献できたと、その成果を振り返った。そして次のように述べ、セッションをまとめた。
「既存のアーキテクチャを絶対視するのではなく、積極的に改善していくこと。その結果得た成果を他のチーム、プロダクトに還元していくことで、組織全体のベースの底上げにつながっていくと考えています」（松本氏）
データ組織の横断プロダクトで、スピード開発と安定運用の両立に取り組む
株式会社リクルート データ推進室
データエンジニアリング部 鶴谷 誠文氏
続いて登壇したリクルートの鶴谷氏は、リクルートの企業と人（B to C）、企業と企業（B to B）、人と人（C to C）を結びつけることで対価を得るマッチングプラットフォームを提供するビジネスモデルを説明した。フリーペーパーからWebへとプラットフォームの場は変わりつつあるが、ビジネスの根幹は変わっていない。
鶴谷氏が所属するデータ推進室は、事業領域ごとに各種データ施策を推進する活動を行う縦の組織であるDSU（データソリューションユニット）が存在する。そこにデータサイエンスやデータエンジニアリングを扱う部署など、専門性強化を行う横の組織を交差させたマトリックス型となっているのが特徴だ。
データ推進室では、複数の事業領域で利用可能な共通機能をDPU（データプロダクトユニット）が横断的にプロダクト化することで、事業領域の開発の効率化や高速化、垂直立ち上げを実現している。
リクルートが実際に提供している横断プロダクトも紹介された。バッチ処理を効率的に開発・運用するためのバッチワークフロー機能を有した「Crois」である。開発効率化のため複数事業領域での利用が想定される機能を共通モジュールとして備えているのが特徴だ。
今回のセッションでは、このCroisを不動産情報サイト『SUUMO』のレコメンドシステムに導入した事例を紹介した。
『SUUMO』ではもともと内製開発したシステムを使用していたが、技術的負債を抱えていた。それを解消するために、当初は既存システムのエンハンス開発やAWSのサービスの利用も検討したが、最終的にCroisの導入を決める。その際に課題となったのが、最新の物件情報を日々安定的に更新し、お勧めの物件情報をユーザーに届ける安定運用面だ。
Croisはマルチテナント方式であることから、即日の利用や一括でのアップデートができるため、運用が効率的であるというメリットがあった。一方、他の領域でバースト的な負荷がかかる際に、別の領域が影響を受ける可能性もあったという。鶴谷氏は次のように語る。
「プロダクトの内部ログが利用者からは参照できない仕様のため、障害発生時の原因究明に時間を要するなど、安定運用における懸念をどう解消するかが課題でした」（鶴谷氏）
そこで打ち手として出されたのが、各領域の担当者がセルフで構築・運用するセルフホスティング方式の導入だ。セルフホスティング方式のポイントは大きく2つある。1つ目は、セルフ方式による自律的な構築・運用を実現した点だ。
インフラ環境構築手順を汎用化したプログラムを、Terraformを使って整備し、社内のWeb上に公開した。加えて、任意のバージョンに自動かつ無停止でアップデートできるデプロイツールも開発した。
2つ目はナレッジの習得だ。領域のCrois担当者が横断組織の開発業務も兼務することで、Croisのナレッジを共有でき、担当領域に持ち帰る体制とした。
鶴谷氏は次のように安定運用の成果を語っている。
「環境構築期間や運用工数という面では、以前と比べて多少増えました。しかし全体のメリット・デメリットで見れば、以前と比べ安定運用が実現できていると、手応えを感じています」（鶴谷氏）
高速かつ安定的にセルフホスティング方式を実現する工夫
株式会社リクルート データ推進室
データプロダクトマネジメント1部 宇野 稔章氏
続いて登壇した宇野氏は、セルフホスティング方式を進める上での工夫や実際のアーキテクチャ、マルチテナント方式との同時運用における苦労や学びについて紹介した。
セルフホスティング方式は、AWS上の様々なマネージドサービスを利用して構築される。そのため領域担当者側のAWS環境にも対応する必要があった。例えば、環境独自部分の特定パラメータ化だ。宇野氏は対応の苦労を次のように語る。
「もともと領域担当者側の別環境に構築することを想定していなかったため、サービスのドメイン名などが固定で書かれているコードがいくつもありました。そこで、環境ごとに異なる部分を特定し、変数化を行いました」（宇野氏）
領域担当者側の環境で必要のないリソースや機能の差分管理にも課題があった。対策としては、各環境に設定ファイルを用意。デプロイ時にファイルにあるフラグを利用し、マルチテナント環境とセルフホスティング環境で作成するリソースをアドホックに分岐した。しかし、この取り組みは後々失敗につながった。詳細は後ほど改めて触れる。
環境の分離・パラメータ化においては、インフラ構築で利用しているTerraformを例に紹介した。デプロイを行う際は、各リポジトリのCodeBuildが開始され、デプロイ用のS3バケットの設定ファイルを取得する。
デプロイの対象環境がマルチテナントなのかセルフホスティングなのかを識別し、後者の場合はマルチテナント環境のみで利用するリソースファイルの削除を行う。またファイルで分割できない部分に関しては、フラグを利用して作成を分岐。ホスティング環境の上書き設定を用いて反映させた。
従来のマルチテナント方式では最新バージョンのリリースを適用する仕組みしか備わっていなかった。しかしセルフホスティング環境では安定運用上の問題から、任意のタイミングで任意のバージョンのリリースを適用する必要があった。その難しさを、宇野氏は次のように語った。
「Croisは、APIサーバーやLambda関数など複数のコンポーネントから構築されているため、デプロイを行う際にはそれぞれの依存関係を考慮しながら行っていました。同業務を領域担当者が行うことは、事実上不可能でした」（宇野氏）
しかし宇野氏らのチームは、不可能を可能にする。複数コンポーネントの依存関係を自動で解決しながらデプロイを実行する独自ツールの開発に成功したからだ。
まずは、開発者がプルリクエストに依存関係を記述するようにした。リリースの際には、Release Creatorというスクリプトを実行。 このスクリプトはGitHub上の各リポジトリのmasterにマージされているが、リリースされていないプルリクエストを自動で収集。記載されている依存関係を元に、デプロイの順番を自動的に判断し、リリースファイルの形で記録する。
このリリースファイルを読み込み、マルチテナント環境の場合はWebHookを利用し、従来どおり即座にリリースする。一方セルフホスティング環境の場合は、手動でDeployer Projectを実行することで、任意のタイミングでリリースを行うという仕組みだ。
このデプロイツールの開発により、任意のタイミングで、任意のバージョンを連続してデプロイできるようになった。だが実際には、リリースによっては連続して適用できないものも存在していた。
だが、ここでもプロダクトチームが技術検討を行い、解決していた。今回も担当者に依存することなく、無停止でリリースを行う仕組みを構築。セマンティックバージョニングの導入だ。これにより、メジャーバージョンがアップするリリースにおいては、連続適用できないように配慮することで互換性問題にも対応した。
「CI/CDのCodeBuild移行とデプロイツールの開発により、安定したセルフホスティング方式を実現することができたと思っています。しかし、マルチテナント環境の開発と並走運用していく上では、様々な困難がありました」（宇野氏）
1つ目は、先述のセルフホスティングフラグを利用したアドホックな環境分離による影響だ。差分によりデプロイやリリースの失敗が発生し、その対応をプロダクトチームのメンバーが行う必要が生じた。結果として開発効率が低下した。
2つ目は、セマンティックバージョニング導入に関するトラブルだ。本来互換性がないはずのリリースが、依存関係記述時の見落としによりマイナーバージョンアップで連続してリリースされてしまい、アプリケーションが壊れる問題が発生した。
3つ目は、任意のタイミングでアップデートできる機能に関するものだ。プロダクトチームと領域側のコミュニケーション不足により、アップデートの期限があったものが期日までにデプロイされず、ジョブ実行が停止する問題が発生した。
「限られた時間内でプロダクトの安定運用を行うことは、非常に難しいことが分かりました。一方で経験をもとに、現在では開発側と領域担当者が密に情報の連携を行うなど、失敗時に高速で復旧できるフローの整備をすることなどから学びを重ね、チューニングを繰り返すことで、スピード開発と安定運用の両立を目指しています」（宇野氏）
おくすり連絡薬手帳アプリ開発におけるスピード開発と安定運用の取り組み
株式会社カケハシ
ソフトウェアエンジニア 種岡 篤志氏
カケハシは「日本の医療体験を、しなやかに」とのミッションを掲げ、薬局と患者を結ぶクラウド型電子薬歴サービス「Musubi（ムスビ）」を展開。患者向けのおくすり連絡帳「Pocket Musubi」など、服薬期間中の患者と薬局の関係作りをサポートするサービスを開発・提供している。
今回登壇した種岡氏は、「Pocket Musubi」の開発チームに所属。バックエンドをメインに、インフラ、フロントエンドなど幅広い領域の開発などに携わる。種岡氏はカケハシならびにプロダクトの特徴を、次のように語る。
「薬局の数はコンビニよりも多く、全国に約6万店もあります。BIツールや各種システムを導入することで、薬局のDXに貢献する。テクノロジーで薬局をあるべき形にしたいと考えています。その中で、Pocket MusubiはtoC向けで、LINE上で動作するのが特徴です。今回は、LINEだけでなく、iOSやAndroidでも動作するアプリをローンチしました。」（種岡氏）
開発期間は約半年。スピード開発においては、FlutterFlowならびにServerlessStackを利用し、安定運用に関してはチーム分割を行うことで、その実現を目指した。
種岡氏は以下のシステムの概要図と合わせて、FlutterFlowを採用した理由についてこう語っている。
「iOS/Android両方をリリースする必要がありましたが、当時は担当エンジニアがそれぞれ一人ずつしかおらず、圧倒的にリソースが足りない状況でした。そこで、ローコードツールを使おうと考えました」（種岡氏）
FlutterFlowはいわゆるローコードツールであり、コードを記述することなく、GUI上でパーツを組み上げていく感覚で、Flutterアプリを開発することができる。また、デザインだけでなくロジックの実装も可能。有料プランを利用すればGitHubと連携しソースコードを知ることもできる。
ただし、今回のケースでは主に各画面の作成とデザインで活用した。一方、ロジックにおいてはツール上だけでは実装が難しいため、設計観点でツールに依存することなどを考慮し、自前で行ったという。
また、自動生成するコンポーネントにおいては、FlutterFlow×××のように抽象化した独自コンポーネントが作成され、将来的に負債リスクになるとの懸念から、テストを書き、将来的にリプレース可能な準備をしておく対策をとった。
続いては、ServerlessStackについて。CDKと同じ使用感でありながら、アプリケーションコードの開発支援も行えるなどのメリットが紹介された。
例えば、ローカル環境でLambdaのロジック開発が簡単にできる、Live Lambda Developmentという機能だ。メンバーごとの開発環境、ローカルでの開発環境が簡単に構築できる。
「Lambda開発における障壁も、ServerlessStackを使うことで取り除かれたと感じています」（種岡氏）
種岡氏は、Live Lambda Developmentの利用例も紹介した。中央の領域がローカルであり、右がAWS領域だ。各エンジニアはローカル環境で開発に集中できるため、開発スピードを促進する。
データベースにおいてもDockerを使い、エンジニア専用の開発データベースが構築されていることがわかる。
続いては、安定運用についてだ。前提として、今回紹介したおくすり連絡帳アプリの開発においては、LINE上で展開していたサービスの開発に携わっていたエンジニアが全員参加し、総力戦で開発を行っている。
このような背景から、メンテナンス対象の増加など、運用面で様々な課題が生じることが考えられた。
「既存のサービスはAngularJSとPythonで開発されていたため、新たな技術スタックを理解する必要がありました。ドメイン知識も同様です。一方で全エンジニアに、すべての技術やドメインの理解を求めるのは難しいと考えました」（種岡氏）
結果として、チームを分割することを決める。一方で、トップダウンで一方的にチームを分割するのはよくないと考えた種岡氏は、チームビルディングのベストプラクティスを体系的に学ぼうと、関連書籍を参考に進めていくこととした。
種岡氏一人が書籍を読むのではなく、メンバー全員にベストのチーム分割のプラクティスについて考えてもらいたいと、輪読会も実施。実際、多くの意見が挙がり、意見交換なども行われた。取り組みの成果を、種岡氏は次のように振り返った。
「チーム分割に関するハードルが、確実に下がったと感じています。それぞれの担当領域の認知が深くなった結果、運用効率のアップにも寄与しました。さらには新しいメンバーが参画した際にもキャッチアップしやすくなるなどの恩恵も得ることができました」（種岡氏）
一方で、コンウェイの法則のごとく生じた課題もある全員が総力戦で開発したことでデータベースが密結合になり、データベーススキーマの管理が負荷が大きくなったのだ
打ち手としてはマイクロサービス化などを考えたが、このアプローチはあくまで現在の課題が生じたことによるアイデアであり、チーム分割を先に行うなどしていたら、判断が変わっていたであろうと種岡氏は振り返る。
種岡氏は、現時点でマイクロサービス化したサービスの運用経験者がいないこともあったなど、あくまで結果からの対策だと指摘。次のように述べ、セッションを締めた。
「マイクロサービス化も含め、スピード開発や安定運用に関する取り組みは、組織のフェーズや開発リソースなど外的要因によって変わるため、判断が難しいというのが正直なところです。一方で今回の経験も含め、得た知見を今後の判断軸に活かしていきたいと考えています」（種岡氏）
【Q＆A】参加者からの質問に登壇者が回答
セッション後は、イベントを聴講した参加者からの質問に、登壇者が回答した。
Q．得た知見を他のプロダクトに横展開する際の工夫など
松本：定期的に行うというよりは、スポットでエンジニアを集めて行っています。内容に関しては実際に起きたことを、愚直にそのまま伝えるようにしています。一方で、なぜそのツールを導入したかなどは、理由を合理的に説明しています。また、他のプロダクトでも使う場合は、すでに経験している私がインストールを担うこともしています。
Q．フロントエンドとバックエンド両方を兼ねる際の技術のキャッチアップについて
松本：いきなり両方任せるのは大変なので、あくまでもエンジニアが両方に興味があれば任せるようにしています。LayerXにはペアプロ文化があるため、新しいメンバーも含め、他の領域のキャッチアップをする際には積極的に活用し、ノウハウなどを共有しています。
Q．新規プロダクトで不明瞭な場合、ビジネスサイドとの連携で工夫している点は？
鶴谷：まずは使ってもらい、導入を検討してもらうことが大事だと考えています。CroisではPoCのフェーズを入れ、実機での検証を行いました。また、Croisのソースコードを公開したり、ヘルプページなどでCroisの使い方や仕様を共有することで、コミュニケーションの円滑化も意識しています。
Q．セルフホスティング方式の導入も含め、Croisによる具体的な効果など
鶴谷：以前はリリースを手動で行う必要がありました。しかしCroisはCI/CD環境が整っているので、自動でリリース出来ます。その結果、エンジニアの負担が減りました。開発者はもちろん運用者も含めて、みんながハッピーになっていると感じています。
Q．MVPであれば、iOS/Androidはどちらかだけでもよかったのではないか
種岡：他社がすでに同様のアプリを両OSで出していたため、両OSで出すことは必須でした。その中で機能をできるだけ絞っていきました。
Q．おくすり連絡帳「Pocket Musubi」開発期間の詳細は？
種岡：ローコードツールの探求は2週間くらい。構想ができてからは一気にアクセルを踏んで開発を進めました。全体としては半年ほどでしたが、ローコードツールとのくだりでいえば、フロントエンドはその約半分、3カ月ほどだったと思います。
Q．デザイン面におけるFlutterFlowの効果は？
種岡：以前はエンジニアとデザイナーがコンフリクトすることがありました。FlutterFlowを使えばエンジニア主導でデザインを進めることができるので、FlutterFlowの導入で解消につながると期待しています。
Q．テックリードとして日々大切にしていることは？
松本：1つはプロダクトのためになることを、自ら積極的に手を動かして行うことです。もう1つはメンバーがしっかりとついて来られるよう、技術に関する意思決定を明確にすることです。
宇野：まずは、リーダーである前に良きメンバーであるということです。レビューや日頃のコミュニケーションを通して、開発者として在りたい姿などを体現することで、メンバーからの信頼を得るようにしています。もう1つは、自分で何でも問題を解決するのではなく、チームメンバーを巻き込んで、結果としてチームとして解決に導く姿勢です。問題と向き合うことが重要だと考えています。
鶴谷：私はマネージャーなので、テックリードを全面的に信頼することを心がけています。 種岡：設計やシステム構成など、テクノロジーに関して合理的な説明と、それに準じた意思決定ならびに責任を持つことが重要だと日々考えています。
株式会社カケハシ
https://www.kakehashi.life/
株式会社カケハシの採用情報
https://recruit.kakehashi.life/
株式会社リクルート
https://www.recruit.co.jp/
株式会社リクルートの採用情報
https://recruit-saiyo.jp/
株式会社LayerX
https://layerx.co.jp/
株式会社LayerXの採用情報
https://jobs.layerx.co.jp/
関連するイベント
