スピンオフサービス構築で培われた開発ノウハウをご紹介！

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Copyright© M&Aクラウド 7 ざっくりとサービスの紹介求人広告のように買い手がM&Aニーズを公開することで、売り手自ら買い手を探せるダイレクトマッチングにより人に依存しないスケーラビリティを実現買い手月額無料成功報酬・案件報酬はM&A成功報酬のみ・最低手数料なし・売り手ソーシングのチャネルが増える・M&Aニーズを発信するだけで売り手を集客・仲介業者を介さずにダイレクトにやり取り可能・潜在層にもリーチが可能手数料無料売り手・買い手のM&Aニーズを自ら調べることが可能・仲介業者を介さずにダイレクトにやり取り可能・買い手のM&A担当者に直接コンタクトをとれる・仲介業者を使わないので手数料が無料買い手のメリット売り手のメリット・仲介手数料が無料〇〇領域の会社を募集しますこの会社と一緒にやっていきたい！ 1.掲載する 2.オファー M&A・出資ニーズを掲載

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Copyright© M&Aクラウド出資企業資金調達企業 9 資金調達クラウドのサービスフロー完全無料で出資企業のマッチング（紹介）ができるプラットフォーム手数料完全無料 1.掲載する 3.資金調達依頼 M&A・出資ニーズを掲載 2.発信する〇〇領域の会社に出資したい！この会社から資金調達を受けたい【メリット】出資ニーズを発信するだけで、資金調達ユーザーから連絡が来る【メリット】出資企業の出資ニーズを見ることで、適切なマッチングが可能

Slide 10

Slide 10 text

Copyright© M&Aクラウドリリースまでの大まかな流れ ● 開発スケジュール ○ PdMとビジネスサイドのすり合わせは３ヶ月程度 ○ 開発は３ヶ月（7月〜10月末） ○ リリースは11月1日（必達で！） ● スコープ ○ 新規作成は新プラットフォームの３ページ ■ リリースに間に合うように調整可能 ○ 既存プラットフォームと共存できるように機能拡張 ■ 同じアカウントで資金調達とM&Aの両プラットフォームを利用したい

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Copyright© M&Aクラウド ● サイト構成 ○ 「サブドメイン」と「パス」どっちで新サービスを用意するのか ■ この選択で開発作業が大きく変化する ■ finance.macloud.jpOR macloud.jp/finance ● 同じアカウントでどちらのサービスも利用できる ○ M&A目的でも後から資金調達に切り替えられるように（その逆も） ● 新しいサービスドメインを確立させていく ○ 既存サービスドメインと中途半端に混ざらないように開発における課題

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Copyright© M&Aクラウド ● 後回しにできない仕様決定である ○ サブドメインなら ■ サブドメインによるログインセッション管理 ● 同じアカウントでPFを行き来するため ■ 既存フロントフレームワークへのページ追加だと対応が複雑に（Nuxt.js） ● できなくはないが、基本仕様から離れた実装になる ● 新しくフロントエンド環境を用意することも検討 ○ 新しいデプロイフローが必要になる弊社は「サブドメイン」にする決定をしたので、サブドメイン採用時の対応内容をまとめていきます！（課題・なぜ）サイト構成

Slide 17

Slide 17 text

Copyright© M&Aクラウド（課題・解決策）サイト構成サブドメインによるログインセッション管理方法（Laravel）値をしてしないとnullになるが、とすることでサブドメインのセッション共通化が行えるようになる 'domain' => env('SESSION_DOMAIN', null), config/session.php APP_NAME=macloud.jp #一緒に変更する必要あり SESSION_DOMAIN=.macloud.jp .env

Slide 18

Slide 18 text

Copyright© M&Aクラウド（課題・解決策）サイト構成この対応でハマったポイントすでにログイン中のユーザーは古いドメイン（サブドメインじゃない）のCookieを保持しているため、ログインセッションが狂ってしまう。（Cookie名の重複）そのためCookie名を変更する必要がある。その際にログイン中のユーザーは強制ログアウトされてしまうので注意！ 'cookie' => env('SESSION_COOKIE', str_slug(env('APP_NAME', 'laravel'), '_').'_session'), config/session.php APP_NAME=macloud.jp .env

Slide 19

Slide 19 text

Copyright© M&Aクラウド（課題・なぜ）サイト構成 ● 既存フロントフレームワークへのページ追加だと対応が複雑に（Nuxt.js） ● もしも、どちらのサービスにも同じパスが必要になった場合 ○ macloud.jp/offers ○ finance.macloud.jp/offers ● pages配下にoffersディレクトリは１つしか置けないため、実装できない... → /about →/ Nuxt.jsでは/pagesフォルダ構成によってルーティングが決まります。

Slide 20

Slide 20 text

Copyright© M&Aクラウド（課題・なぜ）サイト構成 ● 既存フロントフレームワークへのページ追加だと対応が複雑に（Nuxt.js） ○ サブドメインの場合 ■ 基本のルーティング仕様から離れた実装が必要になる ■ ディレクトリを分けて、モジュールでルーティング機能を拡張する ● nuxt-router-module で実装できそうな見込み ○ パスの場合 ■ /AAA/mypage, /BBB/mypageとパスを分けるだけで対応できる

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Copyright© M&Aクラウド ● サイト構成 ○ 「サブドメイン」と「パス」どっちで新サービスを用意するのか ■ この選択で開発作業が大きく変化する ■ finance.macloud.jp OR macloud.jp/finance ● 同じアカウントでどちらのサービスも利用できる ○ M&A目的でも後から資金調達に切り替えられるように（その逆も） ● 新しいサービスドメインを確立させていく ○ 既存サービスドメインと中途半端に混ざらないように開発における課題

Slide 25

Slide 25 text

Copyright© M&Aクラウド（課題・なぜ）同じアカウントでどちらかのサービスを利用できる ● 売却ユーザーは「M&Aクラウド」、調達ユーザーは「資金調達クラウド」 ○ 売却⇆調達で目的が変わっても同じアカウントで実施したい ○ 調達して、事業を拡大し、最後にM&AでExitできるようにサポートしたい ○ ユーザーがどちらのPFを利用しているのか意識することなく、サービスを利用できるようにしたい ● 実現させるには ○ 新しいログインステータス ○ 文言の出し分け

Slide 26

Slide 26 text

Copyright© M&Aクラウド（課題・解決策）同じアカウントでどちらかのサービスを利用できる ● 新しいログインステータス ○ usersテーブルに資金調達ユーザーのフラグ（isFunding）を追加 ■ 資金調達クラウド経由で登録・変更するとフラグがONに ■ 既存の調達ユーザーにもフラグを付与する ○ 売り手サービスドメインのエンティティに値オブジェクト（isFunding）を追加することで、ログイン中の売り手が調達ユーザーかどうか識別できるように

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Copyright© M&Aクラウド（課題・なぜ）同じアカウントでどちらかのサービスを利用できる ● 文言の出し分け ○ ログインユーザーのステータスに合わせて表示を切り替える ■ サイトのヘッダー・フッター ■ 登録情報項目 ■ メッセージやメールの内容 ○ ページ ■ （back）middlewareで出し分けするための変数を設定 ■ （front）データをフェッチしてページ内で文言の出し分け ○ メール ■ Mailableを拡張してユーザー毎に出し分け

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Copyright© M&Aクラウド（課題・解決策）同じアカウントでどちらかのサービスを利用できる /** * @var array|string[] * @description ユーザーの資金調達フラグに応じて、資金調達クラウドとして振る舞いたいページを指定する指定はRouteName */ protected array $routeNameCheckedByUser = ['AAAApage','BBBBpage']; /** * @param Request $request */ public function handle($request, ¥Closure $next) { if ($this->isIncludeRouteNameCheckedByUser($request)) { $user = $this->authUserHelper->getUser(); if (!is_null($user)) { $this->viewFactory->share( 'serviceAttribute', new ServiceAttribute($user->isFunding()->rawValue()) ); return $next($request); } } } App/Http/Middleware/SetServiceAttribute.php 一部抜粋した実装イメージ

Slide 31

Slide 31 text

Copyright© M&Aクラウド（課題・解決策）同じアカウントでどちらかのサービスを利用できる class ServiceAttribute { public function __construct(private readonly bool $isFunding) { } public function isFunding(): bool { return $this->isFunding; } public function getName(): string { return $this->isFunding ? '資金調達クラウド' : 'M&Aクラウド'; } } App/DataTransferObjectServiceAttribute.php 一部抜粋した実装イメージ

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Copyright© M&Aクラウド（課題・解決策）同じアカウントでどちらかのサービスを利用できる ● メールの文言の出し分け（サービス毎に情報を出し分けする設計） SellerMailable BaseSellerMailable SellingTargetComplete CreationToSeller Mailable SellerImporta ntMailable SellerMagazin eMailable Laravel 売り手向けメールの抽象クラス売り手向けメールの送信元を定義した抽象クラス売り手ユーザーが案件登録した時に送信するメールのサブクラス

Slide 34

Slide 34 text

Copyright© M&Aクラウド（課題・解決策）同じアカウントでどちらかのサービスを利用できる abstract class BaseSellerMailable extends BaseMailable { public function __construct( public ServiceAttribute $serviceAttribute, ) { } public function serviceNamePrefixSubject(string $title): static { return $this->subject("【 {$this->serviceAttribute->getName()}】 {$title}"); } public function serviceNamePostfixSubject(string $title): static { return $this->subject("{$title}【 {$this->serviceAttribute->getName()}】 "); } } BaseSellerMailable.php 一部抜粋した実装イメージ出力イメージ【M&Aクラウド】（メールタイトル）【資金調達クラウド】（メールタイトル）

Slide 35

Slide 35 text

Copyright© M&Aクラウド（課題・解決策）同じアカウントでどちらかのサービスを利用できる abstract class SellerMailable extends BaseSellerMailable { public function __construct( public ServiceAttribute $serviceAttribute, ) { parent::__construct($serviceAttribute); if ($this->serviceAttribute->isFunding()) { $this->from( config('mail.finance.address'), config('mail.finance.name'), ); } else { $this->from( config('mail.from.address'), config('mail.from.name'), ); } } } SellerMailable.php サービスに合わせてメールのドメインを変更する一部抜粋した実装イメージ

Slide 36

Slide 36 text

Copyright© M&Aクラウド（課題・解決策）同じアカウントでどちらかのサービスを利用できる class SellingTargetCompleteCreationToSeller extends SellerMailable { public function __construct( public AbstractSellingTarget $sellingTarget, public Seller $seller ) { parent::__construct(new ServiceAttribute($seller->getIsFunding()->rawValue())); } public function build(): SellerMailable { $title = $this->serviceAttribute->isFunding() ? '調達情報の入力が完了しました。' : '売却情報の入力が完了しました。'; return $this ->serviceNamePrefixSubject($title) ->to($this->seller->getEmail()->rawValue()) ->markdown('emails.selling_target.complete_creation.to_seller'); } } SellingTargetCompleteCreationToSeller.php 一部抜粋した実装イメージメールタイトル、宛先、メールテンプレートを用いて生成する

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Copyright© M&Aクラウド（課題・解決策）同じアカウントでどちらかのサービスを利用できるこの対応でハマったポイント(未来形) ● 技術的負債になっていく ○ 案件を複数化する機能ニーズが高まってきたタイミングで、負債解消としてリファクタリングが必要になる ■ パーミッションのような扱いにしてもよかった ● パーミッション毎にページを用意する ■ ログイン基盤の作成売り手情報にisFunding を持たせている

Slide 39

Slide 39 text

Copyright© M&Aクラウド ● サイト構成 ○ 「サブドメイン」と「パス」どっちで新サービスを用意するのか ■ この選択で開発作業が大きく変化する ■ finance.macloud.jp OR macloud.jp/finance ● 同じアカウントでどちらのサービスも利用できる ○ M&A目的でも後から資金調達に切り替えられるように（その逆も） ● 新しいサービスドメインを確立させていく ○ 既存サービスドメインと中途半端に混ざらないように開発における課題

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Copyright© M&Aクラウド（課題・なぜ）新しいサービスドメインを確立させていく ● 共通部分は継承しつつ、新しい情報は新規サービスドメインで表現 ○ サービスを分けることでサービスドメインの重要な情報が変わる ○ 既存のサービスドメインで対応するとファットクラスになってしまう ■ ２つのサービスで利用するデータを全部持っているクラスが誕生する ○ 一方のサービスで機能改修時に思わぬ事故が発生したりもする ■ 不具合を発生させないような設計にしたい

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Copyright© M&Aクラウド ● 技術的に負債について ○ 財務的に利息と元本が投資の利回りよりも低ければ、負債はポジティブ ○ ソフトウェアでも同じことが当てはまるはず開発における課題と解決策最初に市場へ出るために内部品質を犠牲にしたとしても、より良い内部品質で後から市場に出た場合よりも、この決定によって得た金額が高ければ、利益を生み出します。しかし、ある程度不確かなことがあるため、そのような利益を予め見積もるのは難しいので、ここにはリスクがあると言えます。引用：InfoQ（技術的負債を管理する）

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Copyright© M&Aクラウドまとめ ● 「サブドメイン」か？「パス」か？ ○ 両方に対してのメリット・デメリットを用意する ● 同じアカウントでPFを行き来できるようにする ○ 「サブドメイン」か「パス」かで難易度が変わってくる ○ 「サブドメイン」は対応できるのか、できるとしてどれくらいかかるのか調査 ○ 既存Viewの出し分けは、多少の辛さを覚悟しておく（メール大変だった。。。） ● 新しいサービスドメインを確立させていくには ○ クラス設計においては、適宜分けていく ● 技術的負債と投資のバランス、負債の返済タイミング

Slide 50

Slide 50 text

Slide 51

Slide 51 text