カケハシ・LINE・BASEの開発者が振り返る「新規事業プロダクトの技術選定どうやった？

【BASE】新規事業の金融系サービス開発チーム「BASE BANK」の取り組み

BASE株式会社　柳川慶太氏

ノリと勢いが重要。役割分担することで開発スピードが高まる

トップバッターはBASEの柳川慶太氏。2018年にスタートした「BASE BANK」チームで開発に取り組んでいる金融事業の新規プロダクトの開発舞台裏について説明した。

初期のメンバーはプロダクトオーナー1名、エンジニア2名というリソースが限られた状態。納期は4カ月でドメインも複雑という、新規事業にありがちな厳しい条件と不確実性の高い状態でスタートした。

そこで、ノリと勢いで楽しみながら取り組むしかないと思った柳川氏は、当時の技術選定について、次のようなことを考えたという。

とにかく早く出す
素早く改善サイクルを回し続ける
自分たちでコントロールできる範囲を広くする
既存システムからは切り離す
最低限APIとして切り出したい
あえて既存と違う言語、アーキテクチャ、インフラでやる

さらに、次のようなアイデアも出てきた。

言語とか細かいアーキテクチャにはこだわらない
スピード重視で、要件ヒアリングと詳細設計を一刻も早く行う
役割分担（基盤周りは任せ、自分は要件定義とアプリケーション設計に集中）

柳川氏の施策は見事にハマり、想定通りのスピードで開発は進んだ。そして4カ月後の2018年12月にサービスリリースした。現在もサービス提供・開発が継続している「YELL BANK」である。

システムアーキテクチャはBASEの管理画面とは独立した構成とし、APIでサービスを呼び出す設計とした。自分たちで素早く決めて実行できる状態を作るためだ。

「新規事業においては、チーム内の役割分担も非常に大事」だということを実感したと、柳川氏は振り返っている。

柳川氏は、まとめのスライドを紹介するとともに、次のようなメッセージを投げかけ、セッションを締めた。

「新規事業は“人”依存がかなり高いです。そのため担当者は自信を持って取り組むこと、迷った場合はここでも気分が乗る方や、オーナーシップを持てる方を選択するといいと思います。精一杯考え抜き自信を持って出した結論であれば、まわりのメンバーも納得しますし、その後の広がりも大きいと感じています」（柳川氏）

フルスタックエンジニアがフルサイクルで開発をリードする

BASE株式会社　清水陽一郎氏

「YELL BANK」がリリースして4年、開発は現在も続いており、新しい機能をリリースする計画もあるという。加えて、本人確認機能（eKYC）やカード決済サービスなど、新たな金融系サービスの開発・リリースも実現しており、メンバーもエンジニアだけで8名体制となった。

だが一般的に、新規事業やプロダクトはグロースすることなく、チームの解体も含めて閉じてしまうケースも少なくない。BASE BANKチームは何が良かったのか。続いて登壇した清水陽一郎氏は、4つのポイントを挙げた。

アジャイル
フルスタック
フルサイクル
プロダクトに集中できる技術

「SREチームなど、他の部署に依頼を必要とする体制では、アジャイル開発の肝である仮説検証を高速にフィードバックすることが、遅くなりがちです。そこでチーム内で完結することがベストであり、メンバーがフルスタックエンジニアであることが必要となります」（清水氏）

もちろん、エンジニア一人ひとりに求められるスキルや担う領域が多くなることは、言うまでもない。プロダクトの企画・開発領域だけでなく、運用やユーザー対応といったローンチ後の業務までも含めた、一連の業務をチームメンバーが担うことが求められる。

そしてフルサイクルの取り組みでも開発フェーズと同じく、フィードバックループを高速で回していく。

技術負債が生じた場合の新たな技術選定については、次のように述べた。

「新たに選定する技術は、ユーザーの悩み事を解決することにつながるか。つまり、プロダクトに依存しているかどうかが重要。つまり、単に技術的な悩みを解決するための取り組みや採用であってはならないのです」（清水氏）

さらに技術を選定していくためには、どんな技術であってもプロダクトがより良くなるのであれば、柔軟に取り入れる姿勢であると、語っている。

そうして生まれたのが以下のアーキテクチャであり、清水氏はさらに各領域で使った言語やサービスの選定理由も説明した。

●Goの選定理由
プロダクトのビジネスロジックの設計・実装以外のLintや構成管理などで遭遇する問題が少なく、開発環境の構築やバージョンアップが容易。

●Pythonの選定理由
機械学習エンジニアがAPIサーバーをメンテでき、容易にライブラリを使えるから。

●Amazon ECS on Fargate
コンテナはGoと合わせるとChefなどが不要で、メンテが容易だから。

●Terraformの選定理由
インフラエンジニアでないとAWS上に作成されたリソースの存在を認知することが難しいため、AWS上のリソース確認や認知負荷の軽減にも役に立つ。

●基盤化の選定理由
共通ライブラリを使うことで、全社的なSaaS移行やARM導入にも対応。CI/CDの整備、デプロイも容易である。

今後の取り組みとしては、より定量的に仮説検証を繰り返していく。そのためには情報やデータを収集・分析し、プロダクトにフィードバックする「データ駆動開発」が必要となる。以下のアセットやツールを導入している最中だという。

PMM（Product Marketing Manager）
Looker
GA（Google Analytics）/ GTM（Google Tag Manager）

最後に二人は、これまで4年間の取り組みを振り返り、次のようなメッセージを投げかけ、BASEのセッションを終えた。

「チームがプロダクトに向き合う時間をいかに最大化できるかということ、裁量を持って決断できること、試行と反省の回数と速度を最大化し、小さく失敗できること。これらが重要だと考えています」（清水氏）

「自分たちで決めて、決め続ける。技術選定でオーナーシップを持てたことがいい経験となった。とにかく出して、チームで改善をまわし続ける。神になったつもりで、クリエイションし続けましょう」（柳川氏）

【カケハシ】Full TypeScriptで立ち上げた新規プロダクトの設計と反省

株式会社カケハシ　小室雅春氏

続いては、カケハシの小室雅春氏が登壇した。カケハシは、「日本の医療体験を、しなやかに」というミッションを掲げ、薬局と患者を結ぶクラウド型電子薬歴システム「Musubi（ムスビ）」など、主に薬局に向けたSaaSを提供するヘルステックスタートアップである。

小室氏が新規プロダクトに携わったのは、カケハシにジョインして間もなくのこと。リソースのメインは小室氏のみで、兼業メンバーが2～3名という状態。PoCは既に終了しており、3～4カ月をめどにMVP版をリリースし、その後のスケールを進めていきたいスケジュール感だった。

開発したプロダクトは、薬局が患者の服薬をサポートするJamstackな業務アプリで、以下のような課題があった。

個人情報が含まれる
薬局が患者をサポートした履歴など書き込みが必要
将来的に実装される機能が特定しきれていない

これらを踏まえて、小室氏は以下のように技術選定・設計方針をかためていった。

言語はすべてTypeScriptを使用することとした。その理由を次のように語っている。

「Webフロントエンドを有する開発をする以上、TypeScriptの利用が必須になりますが、昨今のエコシステムを考えると、TypeScriptで無理なくフルスタックに開発できます。構造的部分型の特徴を活用することで開発者に優しい型を書くことができ、情報の管理・可読性の向上が狙える点も魅力だと感じます」（小室氏）

中でも特に2019年にリリースされた、オープンソースのソフトウェア開発フレームワーク、AWS CDK （AWS Cloud Development Kit）の存在が大きかったと説明した。

レポジトリ管理については、ディレクトリごとにプロジェクト(package.json)を配置していくMonorepo（モノレポ）構成とした。

近年のエディタは、複数のpackage.json, tsconfig.jsonファイルに対応していることが多い。フロント・バックエンドが一体システムのため、プロジェクト間で一部のコードを共有でき、Full TypeScript環境の効果をメリットを出すことができたと、小室氏は語っている。

既存の手法やツールをアレンジしたひと手間を加える

アーキテクチャに関しては、クリーンアーキテクチャとドメイン駆動設計の手法を斬新的に取り入れた。

導入のモチベーションとして、クリーンアーキテクチャは、ロジックの置き場を整理し、コンポーネントを差し替えできるようにしておくことで、将来的なスケールに対応できる設計とした。

ドメイン駆動設計においては、多くの選択肢があるとしつつも、まずはドメインモデルの整理を意識し、ビジネス要件をコードに反映しやすくしている。またPdMと密に連絡を取りながら、設計の戦略面において概念や仕様を詰めていった。

具体的なアーキテクチャも示し、次のように説明した。

「明らかに役割の異なるコントローラー、ユースケース、リポジトリは切り分けておくのが良いと思いますが、データモデルをどこに何個つくるのか、皆さんも悩まれる点だと思います。個人的な結論としてはスライドのとおり、各レイヤーにひとつずつ配置しました」（小室氏）

Next.js、Angularなどを使った経験もあったが、フレームワークに依存したくない、使わない方が素早くプロダクトが立ち上がると思い、導入しなかった。

「フレームワークは、当初知識がなくても利用しやすいですが、将来的な学習コストが高いと考えています。また、ビルドに時間がかかることがありますが、課題があってもビルドシステムに手を加えるのが難しい点などが利用を控えた事の判断材料のひとつでした」（小室氏）

実際、React + esbuildを用いた開発環境を構築することで、ビルドプロセスが軽量になり、TryErrorサイクルが大きく向上した。

なお、フロントエンドの技術選定については、サービスがBtoCかBtoBどちらなのかによって、非機能要件が大きく変わる。

また、技術選定に際してはJavaScriptに興味を持つ世界中のエンジニアのアンケート結果をまとめた、「The State of JS」などのトレンドも参考にしているという。

OpenAPIで採用したのはTSOAという若干マイナーなライブラリ。その理由としては、CodeFirstでOpenAPIスペックを作成できること、サーバーのボイラープレート部分を自動生成できるといったメリットがあるという。

さらに、OpenAPI‐generatorでAPIクライアントを自動作成することで、フロントエンドとバックエンドの整合性を簡単に担保することができ、開発工数の短縮につながるという。より詳しい情報はブログでも紹介されている。

テスト環境は一般的なE2Eテストのピラミッド構造ではなく、統合テストのボリュームを最も重視した、テスティングトロフィー手法を念頭に行っている。

「機能全体の副作用をテストできるため、安心感があります。障害が発生した場合も修正以降の動作が保証できるため、特に個人情報を扱う今回のシステムでは効果的です」（小室氏）

一方で、テストデータの生成が大変であること、ケースを網羅しきれない際に局所的に複雑なロジックはUnitテストに逃がすなどの考慮点があるとした。

なお、Jestの起動の遅さを解消すべく自作ツール「uvu-jest」を開発しているという。こちらもブログで紹介されているので、ぜひ参考にしていただきたい。

【LINE】新規に立ち上げたライブコマースサービス「LIVEBUY」の技術選定

LINE株式会社　岩谷明氏

続いては、2019年から開発が始まったLINEのライブコマースサービス「LIVEBUY」で、サーバーサイドを担当する岩谷明氏が登壇した。LIVEBUYとは、LINEのプラットフォーム上でライブ配信を観たり楽しんだりしながら、1タップで商品を買うことができるサービスである。

セラーとユーザーがリアルかつインタラクティブにコミュニケーションを取れるのが特徴で、例えば食材を売りたいセラーが生産にかけた想いや、こだわりの生産方法などをライブ配信で直接視聴者に伝えることで、商品の価値をさらに高め、より良い購買につなげる。

社内財産の活用と新規技術のバランスがポイント

LINEでは、インフラを構築しているサーバーはほぼオンプレミスであり、加えてVerdaと呼ばれるプライベートクラウドが整備されている。プログラミング言語はJavaを使うことが多く、Javaの仮想マシンへの知見、財産の蓄積があり、社内ライブラリも充実していて、オープンソース化しているものもある。

さらに、ミドルウェアなどインフラのメンテナンスの各領域を、専門に担当するチームが存在する。具体的には、MySQL、Redis、Kafka、Kubernetes、Elastichsearchといった言語や開発環境である。

「LINEではこのように、社内の標準的な技術スタックが決まっていて、アセットも充実しています。一方で技術選定においては、各開発チームが裁量を持って選定することができるため、エンジニアのやりがいになっています」（岩谷氏）

開発に際しては、岩谷氏は次のような方程式を立てて、技術選定を行った。

プロジェクトの特性は先述したとおり、ライブとECをかけ合わせたサービスのため、当然、開発する機能は多く、ドメインもライブ、コマースと複数領域にわたる。

だが、社内のアセットが豊富であることを踏まえ、アプリ・サーバー・フロントからなる少数精鋭のチーム体制とした。そして繰り返しになるが、決済、動画配信、モニタリング、APIなどの領域は、同分野の専門チームに任せることとした。

システム構成はマイクロサービスとし、社内のマネージドサービスを積極活用することとした。言語はKotlin、通信プロトコルはgRPC、APIの処理は非同期I/Oとし、次のようなアーキテクチャとなった。

岩谷氏は改めて、技術選定の理由や背景、実際に運用してみてからの長所・短所を紹介するとともに、次のように補足した。

Kubernetesは機能が豊富でバージョンアップが盛んなため、学習しないと使いこなすハードルは高い。プログラミング言語として採用したKotlinは、Javaに比べてコードが簡単で優秀な言語であり、Kotlin Coroutineを含め最大限利用している。

技術選定の理由とやってみた結果については、以下のように紹介された。

●システム構成でマイクロサービスを選んだ理由

マイクロサービスを選んだ理由は、配信や商品を扱うドメインが多岐に渡るため、巨大なモノリスになるのを防ぎたかったからだ。また、Kubernetesは社内にメンテナンスしてくれるチームがあり、スケーラビリティの担保が見込めることが大きかった。

●Kotlinを選んだ理由

マイクロサービス構成はIO（通信）が多く、Kotlin Coroutineでパフォーマンス向上を狙った。サポート体制もあり、Springでも対応できることや、Javaの知見を活かせることも理由の一つだ。

●通信プロトコルにgRPCを選んだ理由

マイクロサービス間の通信やWebフロントエンドからサーバー間などを中心に利用していたことや、Protocol BufferによるAPIの定義をチーム間で共有できることが大きな理由となった。

リリース後は大きな障害もなく、開発速度も遅くないという。一方で、岩谷氏の判断が正解かどうかをジャッジできる段階ではないと前置きし、次のように語っている。

「技術選定に正解はなく、正解だと判断される時期もかなり先なので、悩み過ぎる必要はありません。LINEでは、社内財産の活用と新規技術のバランスがポイントとなります。実際、近年ではKotlinを使ったプロダクトが増えています」（岩谷氏）

【Q＆A】参加者から寄せられた質問を紹介

Q&Aタイムでは、参加者から多くの質問が寄せられた。その中からいくつか紹介する。

Q．技術選定に要する期間はどのくらいだったのか？

小室：1～2週間くらいです。開発がスタートしてからもアジャイル的に、使える技術は適宜、導入しています。

岩谷：同じく1～2週間で、開発がスタートしてからも技術導入は続けています。

柳川：概ね2週間ほどだったと思います。

Q．稟議はどうやって通したのか？

柳川：CTOやVPoEに見てもらうことをゴールとしています。

岩谷：ルールはありませんが、チームマネージャーや室長に意見を聞き、参考にしています。例えば、LIVEBUYではFlutterを採用しているのですが、これまで社内で事例がなかったため、事業部の企画メンバーやデザイナーにも事前に伝えていました。

小室：ドキュメントとしてまとめて、CTOやSREチームチームに相談しています。採用実績がないツールでも、否決されることはほとんどありません。

Q．「こうしておけばよかった」といった技術的反省点は？

小室：グロース後の一番の障害はデータモデル。当初の設計と合わなくなってくるからです。特に書き込みが走るシステムは移行や復元が難しく、早い段階から取り組む必要があると考えています。

岩谷：小さなところではたくさんあると思いますが、データ構造は一度本番環境を構築すると変えづらいので、最初の段階で作り込み過ぎたと反省する部分もあります。もうひとつ、Kotlin Coroutineなど新しい技術は情報が少ないため、導入が早すぎたとも感じる時もあります。

清水：別サーバーを設け、PHPとGoの間で通信しているのですが、スキーマ駆動開発ではなかったため、毎回手動で書いていることが手間だと感じています。

Q．メンバーの属性や役割など、フルサイクル開発の詳細について

清水：プロダクト開発には職種に関係なく携わるのが特徴です。メンバーはデザイナー2名、PMM寄りのPM、BizDev的な役割を担うメンバー、プロダクト寄りのメンバー、エンジニアの13名でアイデアを出し合い、検討しています。

小室：カケハシもフルサイクル開発に近く、デザイナー、営業寄りのPMMもチームに所属し、スクラム開発しています。PdMが薬剤師であったり、エンジニアがサービスに使われている様子を見に、薬局を訪れたりもしています。

岩谷：議論は職種の垣根を超えて、ざっくばらんに言い合える環境です。たとえば、仕様書に対してエンジニアが気軽に意見を言ったり、それぞれプロフェッショナルとしての意見を尊重しています。

Q．異なる部署のコミュニケーションで工夫していること

岩谷：一人ひとりが何にでも興味を持つこと、気になることは専門以外の領域でも、積極的に聞くこと。このようなマインドを多くのメンバーが持ち、何でも相談できる仕組みが整っていることが大切だと考えています。

LINEではフロントエンドの専門家がそろっており、Kubernetesのクラスタチームなどに、何度も聞いたり相談したりしています。逆に専門家チームにとっては、新規事業の事例は重要な事例なので、コミュニケーションはお互いにメリットがあると思っています。

小室：入社してまだ1年ですが、一人ひとりが他のチームや会社に貢献しようという意識が強いですね。バリューの設定や表彰制度といった文化的な土壌があるので、CTOやSREチームにも気軽に相談できています。

清水：我々もフロントエンドやSREといった他の部署から技術的なアドバイスをもらったり、こちらからも相談するようにしています。

Q．新規事業への適正（向き不向き）とは？

柳川：スキルや特性はないと思います。自分にできること、できないことが客観視できて、とにかく前に進める、他人に助けを求められることが大事ですね。

小室：コミュニケーションが大事です。コミュニケーション力があれば、状況をしっかりと説明でき、信頼感が得られ、権限委譲もしてもらえる。結果として、良きプロダクト開発につながると考えています。

岩谷：何でも楽しめることが重要だと思います。業務を進めていると、分からないこと、面倒くさいこと、ハマることなど、辛いことも多いからです。それでもユーザーの喜ぶ顔が見たいから頑張れる。そんなマインドが大事ではないでしょうか。