Azit CTOの十亀（<a href="https://x.com/Pocket7878" target="_blank" rel="noopener noreferrer">@Pocket7878</a>）です。 DeliveryXでは、バックエンドのRuby on Railsでの開発をモジュラーモノリス構成で行っており、 本記事では、弊社のモジュラーモノリス構成へのRBSの導入にあたってどのような観点から判断を行ったか、 今後行いたい技術的な改善項目などをご紹介いたします。

弊社のDeliveryXでは、物流業界のDXという事業ドメインに向き合うソフトウェアの開発をおこなっており、 WoltやUber Directといった3PLとのAPI連携や、自社の配送網をすでに保有しているクライアント企業内の配送オペレーションの改善のための機能群など 一つのプロダクトのなかでも、ユースケースや利用タイミングが異なっていたり、同じ単語であっても業務フローが異なっている場面が存在するなど、 ソフトウェアとしてもロジックをいかに疎結合でわかりやすい形に保ち続けるかが開発効率の要の一つであり、顧客への迅速なアウトカムの提供のために重要です。 テストのカバレッジを高く保つことを意識したり、ドメイン駆動設計の概念などを取り入れてビジネス観点とソフトウェア内部の距離を近くするなどの活動も行っておりますが 本記事では、　RBSを利用して型チェックの観点から保守性を高めるための活動をご紹介いたします。

<h2 id="h35a3140377">モジュラーモノリスの分割方針とdry-structの活用</h2>DeliveryXでは、ルートディレクトリに <code>packages</code> というディレクトリを切り、 その下に <code>marketplace</code> (3PLネットワークとの接続） であったり、<code>delivery</code> （配達員アサイン後の配送進捗管理）などといった独立したディレクトリを作成し、 各ディレクトリの間はできるかぎり疎結合にできるように努めて構成をしています。 そのなかでの方針の一つとして、パッケージからは <code>usecase</code> という外部公開の用の限定されたインタフェースを腐敗防止層として定義し、 またUseCaseへの引数としては <code>types</code> というネームスペース以下に定義したイミュータブルなオブジェクトおよびIntegerやStringなどに限るようにしています。 そのようなイミュータブルなオブジェクトは例えば、以下のように<a href="https://dry-rb.org/gems/dry-struct/1.6/" target="_blank" rel="noopener noreferrer">dry-struct</a>と<a href="https://dry-rb.org/gems/dry-types/1.7/" target="_blank" rel="noopener noreferrer">dry-types</a>を利用して定義しています: <pre><code>module Marketplace
&nbsp; module Types
&nbsp; &nbsp; class FooBarConfiguration &lt; StructBase
&nbsp; &nbsp; &nbsp; attribute :foo_bar_id, Types::Integer
&nbsp; &nbsp; &nbsp; attribute :maximum_amount, Types::Integer
&nbsp; &nbsp; &nbsp; attribute :maximum_delivery_minutes_limit, Types::Integer
&nbsp; &nbsp; &nbsp; attribute :foo_prioritize_criteria, Types::Symbol.enum(:price_priority, :time_priority)
&nbsp; &nbsp; &nbsp; attribute :bars, Types::Array.of(Bar)
&nbsp; &nbsp; end
&nbsp; end
end</code></pre>(実際には、StrictやParamsやCoercibleなども適宜使い分けます） このように定義しておくことで、このパラメータとして受け取ったあとの処理は、このオブジェクトから取り出したフィールドはIntegerやStringなどであることは実行時に保証されているとして実装をすることができます。 また、ユースケースの返値についても同様にイミュータブルで明確なオブジェクトにしておくことで、ユースケースの返値を受け取る側の処理に対しても安定したインタフェースとして依存することができるようになります。

<h2 id="hc76d192b89">RBS導入の狙いと課題</h2>上記のように進めているdry-structやdry-typesでは主に実行時の型の保証と、インタフェースの明確化によるコードのドキュメントとしての効果を狙って行っています。 そこに加えてRBSを導入することで、静的にチェックできる領域を増やすことでテストのカバレッジの維持と同様にシステム全体の安全性を向上させるとともに、追加の機能開発の際に静的な型検査による影響範囲の検知なども狙いたいと思い、RBS CollectionやSteep、RubyMineでのRBSサポートがより成長してきたことなどを踏まえて正式に積極的に導入をすすようと判断をしました。 また、AzitではGithub CopilotやChatGPT Team、ChatGPT Proの試験導入や、Devinの試験導入などAIによる開発生産性の向上にも会社全体で取り組んでいます。 そのような観点からもAIにとって扱いやすい形として、主要なデータ型やinterfaceを明確な形で与えておきたい・設計したいという意図もあります。

<h2 id="h544f04ea88">dry-structとRBSの併用</h2>当然のことながら、すでに各パッケージのインタフェースとして定義しているdry-structはそのまま活用でき、引き続き実行時の保証という面では非常に役に立っています。 RBSによる静的型検査では、以下のようにuntypedを経由することで、実際には間違った型の値を外部から渡されてしまう可能性が存在するため、 引き続きdry-struct等による実行時の型検査は必要となります。 たとえば、以下のようなコードが書かれてしまっているとします。 <pre><code>class Foo
 def greeting_message
 return "Hello, World!"
 end
end


class Bar
 def add_two(number)
 return number + 2
 end
end


if __FILE__ == $0
 foo = Foo.new
 puts foo.greeting_message


 bar = Bar.new
 puts bar.add_two(foo.greeting_message)
end</code></pre> このとき、Bar側の型シグネチャとして <pre><code>class Bar
 def add_two: (Integer number) -&gt; Integer
end</code></pre> と、Integerを期待していることを明確にしていたとします。 このとき、Fooの型シグネチャが <pre><code>class Foo
 def greeting_message: () -&gt; String
end</code></pre> と定義されていれば、 steepによる検査時に <pre><code>app/sample.rb:18:19: [error] Cannot pass a value of type `::String` as an argument of type `::Integer`
│&nbsp; &nbsp;::String &lt;: ::Integer
│&nbsp; &nbsp; &nbsp;::Object &lt;: ::Integer
│&nbsp; &nbsp; &nbsp; &nbsp;::BasicObject &lt;: ::Integer
│
│ Diagnostic ID: Ruby::ArgumentTypeMismatch
│
└&nbsp; &nbsp;puts bar.add_two(foo.greeting_message)
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;~~~~~~~~~~~~~~~~~~~~</code></pre> と、正しくミスが指摘されますが、 <code>greeting_message</code> の返値が <code>untyped</code> と宣言されてしまっている場合は 実行時までこのミスに気がつくことはできません、プログラムが段々と大きくなっていくにつれてどのコードがどこで呼び出されているかを 記憶しておいて人間がミスに気がつくというのは段々と難しくなります、またテストのカバレッジを十分に高く保っていたとしても テストケースに万一の漏れが発生してしまう可能性はありますので、異なるタイプの検査で検知できるのであればそれに超したことはありません。 また今回の場合は、すぐにパラメータがbarメソッド内で利用されているので実行時にも値を渡しているところのすぐ近くでエラーが発生しますが、 もし、barメソッドがもらった引数をまた別の関数に渡して、その関数が..と呼び出しの連鎖が長くなってくると、 実行時のエラーを検知した際に、どこからそのような値が侵入してきてしまったかを把握することは困難になってしまいます。 このような場合にもdry-structで適切にインタフェースを宣言してあれば、想定外の値を渡してしまっていることはユースケースを呼び出すための パラメータを作成した段階で実行エラーとして検出されるようになり、パッケージ内部ではその心配をする必要性が減ります。 このように実行時の動的な型検査によって入り口の段階で型を一定保証することによって、パッケージ内部の型シグネチャではユースケースから連鎖的に呼び出される処理の間で渡される型について静的に型検査を行っておけば内部の呼び出し関係の型にある程度自信を持てるようになります。 このように実際の運用では、実行時の動的な型検査と、静的な型検査の役割の違いはきちんと意識して使い分ける必要があります。

<h2 id="ha3f037a130">RBS-Inlineへの段階的移行とそのメリット</h2>上記のようなメリットもあり、RBSの導入を進めていますが、さらにRBSでの普段の開発をスムーズにするために rbs-inlineについても導入をすすめています。 もともと、チームでRBSを導入をすすめるなかで<ul><li>コードレビューの際に、RBSとRubyコードの一致を確認することが難しい</li><li>手作業による型シグネチャの記述の場合に、RBS側にだけ残ってしまっている場合に検査で発見できない</li></ul>など型シグネチャとRubyコードの両方を同時に編集するなかでのミスも発生していました。 前者についてはRubyMineでの型シグネチャへのジャンプ機能なども進歩してきたためスムーズに行えるようになりました 後者については、リファクタリングの過程でのミスなどによって削除したはずのメソッドを引き続き呼び出してしまっている 処理が存在するものの、型シグネチャの方からの記述の削除漏れも同時に発生してしまうことによって型検査でも検出されなかったりする場面もありました。最終的にはCIでのテストによって発見されるものの、もっと開発者がコードでの機能開発に集中しながら型での恩恵も受けやすくしたいと思っていました。 そんななかで、rbs-inlineを導入することでRubyコード側のコメントと完全に同期した形でRBSが生成することが可能になり 開発者も開発中にわかりやすく、またコードレビューでも無意味に浮いたコメントであれば気がつきやすいのでより導入がしやすくなりました。

<h2 id="h0b42f6d9af">dry-structにも型をつけておく</h2>上記でも触れましたがdry-structで定義してあるオブジェクトにも静的型検査用の型シグネチャをrbs-inlineのコメントとしてつけておく必要があります。 以下では、いくつかのパターンに触れて、紹介しておきます。 まずは、メインであるattribute関連の型付けです<pre><code># frozen_string_literal: true
# rbs_inline: enabled
module Optimization
 module Types
 class FooConfiguration &lt; StructBase
 # @rbs! attr_reader optimization_duration_in_seconds: Integer
 attribute :optimization_duration_in_seconds, Types::Coercible::Integer
 # @rbs! attr_reader vehicle_speed_km_per_hour: Float
 attribute :vehicle_speed_km_per_hour, Types::Coercible::Float
 # @rbs! attr_reader clustering_equal_coordinates_service_jobs: bool
 attribute :clustering_equal_coordinates_service_jobs, Types::Bool
 # @rbs! attr_reader ttl: Time | nil
 attribute? :ttl, Types::Params::Time
 end
 end
end</code></pre> たとえば、このようにdry-structが独自で提供している <code>attribute</code> は当然のことながらrbs-inlineでは認識されないので、 <code>@rbs!</code> という埋め込み構文をコメントとしてつけておくことで、このオブジェクトからInteger型などでアットリビュートを取り出すことができることを表現しています。 また、すこしトリッキーな例としては、 <pre><code># frozen_string_literal: true
# rbs_inline: enabled
module Optimization
 module Types
 # @rbs!
 # type batchAssignmentServiceJobsStatus = "IN_PROGRESS" | "COMPLETED"


 # @rbs skip
 BatchAssignmentServiceJobsStatus = Types::String.enum('IN_PROGRESS', 'COMPLETED')
 end
end</code></pre> このように、dry-struct側では、独自の型を表現として大文字から始まる形で宣言ができるのにたいして、同等の型宣言はRBSでは小文字からしか開始できないことなどの制限もあるため 適宜、もとの記述を　<code>@rbs skip</code> でスキップしてもらい、先程と同様　<code>@rbs!</code> による埋め込みで同様のリテラル型による等価な型シグネチャを出力するなどの工夫も必要になります。

<h2 id="h5c913b2688">rbs_railsを併用した運用方針</h2>また、本記事では紹介しませんでしたが、<code>rbs_rails</code> も併せて導入済みのためRailsの自動生成してくれるアソシエーション系のメソッドなども 適切に型がつくため、より一層開発中にIDEでメソッドの自動補完が適切に行われたり、カラムが空の場合を考慮してメソッドの命名や設計意図をどのように設定するかなど 静的な型検査によってより意識的に設計を考える良い機会になっています。 rbs-inline, rbs_railsを併用して、以下のような配置でRBSファイルを管理しています。

<table border="1">
 <thead>
 <tr>
 <th>対象</th>
 <th>対応方針</th>
 <th>配置先</th>
 </tr>
 </thead>
 <tbody>
 <tr>
 <td>ActiveRecordのメソッド</td>
 <td>rbs_rails に一本化</td>
 <td>sig/rbs_rails/ 以下</td>
 </tr>
 <tr>
 <td>ActiveRecordのカラムへのアクセサ</td>
 <td>rbs_rails に一本化</td>
 <td>sig/rbs_rails/ 以下</td>
 </tr>
 <tr>
 <td>rbs_inline をつけたファイルの sig</td>
 <td>rbs_inline に一本化し、適宜 @rbs! を使う</td>
 <td>各パッケージの sig 以下、 および app/sig 以下</td>
 </tr>
 <tr>
 <td>その他</td>
 <td>可能であれば rbs_inline に段階的に移行していく</td>
 <td>各パッケージの sig 以下、 および app/sig 以下</td>
 </tr>
 </tbody>
</table>

<h2 id="h28b62bc2c0">今後の課題</h2>本記事では、現在DeliveryXの開発で進めているRBSの導入を紹介いたしました。 テストによる試験などと同様に、静的な型チェックを進めることによってよりプロダクトの開発を自信をもって進めることが可能になり、 また、型という目線からプログラムやメソッドの設計を考える機会にもなり、よい設計の指針にもなっています。 今後は <code>steep stats</code> を定期的に報告する仕組みなどを作成し、プロジェクト全体へのRBSの導入率などをチェックできるようにしたいと思っております。

Azitではサーバーサイドエンジニアを募集中です。ご興味をお持ちいただけましたら以下の採用サイトからご応募下さい！

サーバーサイドエンジニア (Tech Lead)

RBSの導入をすすめて、モジュラモノリスバックエンドの保守性を高める

Sogame Masato

2024年最後にお届けするのは、Azitの代表取締役CEOを務める吉兼のインタビューです。Azitでは2024年に主力となる事業名をCREW Expressから「DeliveryX」に変更し、提供するサービスの幅を広げ、さらなる成長を目指しています。 起業してから11年。何を目指して創業し、今何を考え、どこへ向かおうとしているのか、代表取締役COOの山口が読者の視点に立ってインタビュアーとなり、深堀りしました。

<h2 id="h5c4d85c8fd">PROFILE</h2>株式会社Azit 代表取締役CEO　吉兼周優 1993年埼玉県生まれ。慶應義塾大学理工学部管理工学科卒。在学中である2013年11月に株式会社Azitを創業。2015年に、プロダクト・マネージャー兼デザイナーとして、配車アプリケーション「CREW」を公開。2020年、コロナ禍で事業を物流・SCM領域のDXを支援するDeliveryXへと転換。現在は京都在住。

<h2 id="ha326b150ef">AからZまで。全てにITを使って何かを作りたい</h2>ー Azitを起業したのは、在学中ですよね。当時は初めから「起業」を意識していましたか？ 最初から「起業をするぞ！」みたいな強い意志があったわけではないんですよね。Co-Founderの須藤や十亀と出会ったのが2012年の頭ぐらい。最初は、サークルのような形でAzitとして活動していたんですよ。いろんなサービスを、皆でワイワイ作ってみたりしていて。 その中で、写真管理アプリや電子書籍を作れるWebサービスなんかも作って、シリコンバレーに行って見てもらったりもしました。 ー なぜ「Azit」という名にしたのでしょうか。 とにかく僕たちはITが好きだったので「AからZまでITを使って何かを作りたい」という想いをそのまま表現したのが「Azit」です。そして、日本語でいう秘密基地のニュアンスの「アジト」という意味も含んでて。「僕らのアジトとして、このチームを成長させたいな」という思いでスタートしたのが、Azitなんです。 ー なるほど。起業はどのくらいのタイミングで決めたんですか？ 当時はまだ卒業後に事業を継続するか就職するかも決められていなくて。法人にはせず、ファッションECやったり、家庭教師のマッチングサービスをやったりもしていたんです。 2014年末くらいに、すでにお会いしていたアンリさんとお話をして、出資していただくことになり、本格的にスタートアップとしてチャレンジしていくことになりました。それが卒業の3ヶ月前ぐらいですね。そのタイミングで、Azitを法人として続けていく覚悟を決めました。 ー アンリさんにご相談したときは、まだ事業が定まっていなかったということですよね。 そうなんです。当時はまだCREW*に絞っていたわけではなく、電動キックボードなどモビリティ関連も考えていましたし、SNSを活用したDtoCなんかも。合わせて100個くらいは、アンリさんに相談していたと思います。アンリさんから「これは吉兼に向いてない」みたいにアドバイスをいただいたりもしていました。その中の事業候補の1つが、ライドシェアだったんですよね。最初は「日本って何でライドシェアないんだろうね」って、シンプルな疑問から始まりました。 *Azitが運営していた一般のドライバーと乗客をマッチングするライドシェアサービス。2020年にサービス休止 ー 当時海外はライドシェア全盛期、まさに気になる領域だったわけですね。&nbsp; そうなんです。日本でもやるべきだろう、という観点と、自分たちの周りの人たちが顧客になりうるかみたいなことを考えながら絞っていって。それが2015年の春くらいですかね。 その頃もまだCREWだけに絞っていたわけではなく、3つか4つくらいのサービスを一緒に回しながら、検討していました。なので、実際CREWは「これをやりたい！」みたいな始まりではなく、面白そうなものを絞って残り続けたようなイメージなんです。

<h2 id="h0c27660298">CREWからDeliveryXへ</h2>ー コロナ禍を経て、現在のDeliveryXのサービスへと変化しましたね。 CREWの継続が難しいと判断したとき、その後やることをゼロベースで考えすぎても無限に浮かんでしまうので、CREWを運営していたAzitだからこそできることに挑戦したいと思いながら、メンバーと議論を重ねていきました。 移動という切り口は変えず、人じゃなくて物を運ぶとしたら、今まで培ってきたプロダクト開発のナレッジも、大企業や官庁などと一緒に動いてきたケイパビリティも活かしていけるのでは、と考えました。 ー 簡単に表すと、今のDeliveryXはどういう事業をやってますか？&nbsp; DeliveryXの名の通り、配送のDXを行っている会社です。ただ、今後はデリバリーに限らないXにしたいなとは思っているんですよね。現状のプロダクトを言い表すと「デリバリー」ではあるのですが、これが今後ウェアハウスXになってもいいし、ストアXになってもいいし…とはいえ、あまりXにこだわりがあるわけではないですが（笑） サプライチェーン全体でDXは広がっていくので、配送デリバリーというところを起点とはしつつ、周辺領域までプロダクトの価値を広げていくっていうのが大事だと思っています。 ー ラストワンマイルの配送から始まったDeliveryXですが、現在はより「輸送」そのものにも関わるように広がってきていますよね。 初期は当日配送やクイックコマースのような領域を構想しましたが、物流産業や日本社会へどういうインパクトをもたらすのかを考えたときに、クイックコマースだけの改善やラストワンマイル単体の解決では、根本的な課題を解決していないと感じる点が多かったんです。 色んな企業の方々とお話ししながら見えてきたのは、例えば配送だけではなく倉庫の課題や、現場ドライバーさんだけでなくオペレーターさんも人手不足、みたいな周辺領域のサプライチェーン全体の課題が複雑に絡み合っているということでした。 ー サプライチェーン全体にテクノロジーを活用していきたい、と。 そうなんです。もちろんサプライチェーン全体に広げるという側面もあれば、ただシステムで生産性を上げるだけでなく、AIの活用も積極的に取り組んでいくべきだと思っています。人手不足とAIって、すごく相性がいいじゃないですか。これまで人がやってきた仕事の中で、AIが意思決定を代替したり、業務のリプレイスができるようになったり。それによって、より働いている人たちをエンパワーメントできるような仕組みを作るのも、僕たちの役割だと考えています。

<h2 id="h8f1e5a8ec5">Azitで働いた時間そのものが価値になるように</h2>ー 少しテーマは変わりますが、どんな組織にしていきたいというイメージはありますか？ 珍しいかもしれませんが、僕たちは「これを成し遂げたい」「この課題を解決したい」みたいなミッションの元に集まった集団ではなく、冒頭にお話したようなイメージで、Azitとして働いているのが好きだから続けている、という感覚なんですよね。 なので、個人的なモチベーションとしては、皆がつまらなくなったり、一緒に働くメンバーが嫌になってしまったり、Azitで働きたくなくなってしまう状態には絶対にしたくないと思っています。 もちろん社会にインパクトを与えることも、会社として資本主義の中で戦って勝つことも大前提大切です。そのゲーム自体も楽しみたいと思ってますが、そもそも「Azit」の名の通り、そこにいることが楽しくてわくわくするとか、好きな人と一緒に何かができるみたいな居心地の良い場でありたいなと思ってて。 本気で仕事を楽しくやってるからこそ居心地のいい場というのを、作り続けたいと思っています。もちろん稼ぐことも事業を伸ばすことも大切ですが、そのためだけに人生の時間を無駄にはしてほしくなくて。事業を伸ばし社会に対して貢献することを通じて、このメンバーと一緒に働いてた時間そのものがいい時間だなって思ってもらえたらいいなと思っています。皆が後から振り返ったときに、そう思える場であることが、創業者として自分の幸福だと思っています。 ー セカンドプレイスだけどサードプレイスのような感じですね。 そう、そういう感じです（笑）事業を伸ばすのはもちろんですが、社員が幸せに働いてくれることも、僕のミッションに入っていると思っています。でも、もちろん長く働いてもらえると嬉しいですが「絶対ずっといてほしい」と考えているかというと別にそうでもなくて。人生の一部の接続の場所であっても、その瞬間をともに楽しく過ごせるならいいなと思っています。 ー 普段京都に住んでいてリモートワークという手段を取っていますが、会社の雰囲気の作り方やコミュニケーションで大切にしたいポイントは？ 出社かリモートかどちらが良いかというのは、これからも時代に合わせて変わっていくと思っていますが、現時点ではまだ世界的にも正解がないですよね。会社ごとに試行錯誤をしているフェーズだと思います。 僕自身は京都に住み、最近は毎週東京にいるような生活になっています。エンタープライズのクライアントの方々が東京にいらっしゃるからというのもありますし、メンバーと顔を合わせるのもやっぱりいいな、と思っていて。プロジェクトベースの生産性だけを追い求める会社にするのは、そもそもAzitらしくないなと思っています。信頼関係が作れている人と働くというのを、やっぱり大事にしたいなとは思っていて。 例えば、すでに信頼関係が作れている状態なら頻繁に対面で会う必要はないかもしれません。でも、初めて一緒に働く人がいきなりずっとリモートというのは、やや難しいところがあるなと感じていて。新しく入ってくださった方ともどんどん顔を合わせられるようにしたいなと思ってますし、気軽に話しかけられるような距離感でいたいとも思っています。 Azitの場合は、東京に住んでいても週5で出社しているわけではなくて。リモートの人もいる中で全社でうまく一体感を持って働いていくにはどうすべきか、情報の連携が途絶えないようにするにはどうすべきか、というところの仕組み作りや、仕組み以上にカルチャーを育てていかなくてはいけないと考えています。リモートの働きやすさも、出社の良さも見出していきたいですね。

<h2 id="h01667fd9d7">目の前主義じゃないからこそ選んだ未来</h2>ー 自分自身を起業家としてどう見ていますか？ もちろんプロダクトは好きですし、西海岸も大好きなのでシリコンバレーっぽい企業にしたいなっていう憧れもあるはあるのですが（笑）でも、自分なりに少し珍しいかと思うのは、もちろん資本主義のゲームも好きだし得意だとは思っていますが、それをあまりモチベーションに感じていない点ですかね。 面白いやつらと人生の時間を豊かに過ごしていきたいがための手段。それがスタートアップで起業することだった、という感じなので、別に起業家というキャリアにはあんまりこだわりもないですし。 ー 結果志向よりはプロセス志向がなんですね。 そうですね。とはいえ、若い起業家の持つエネルギッシュな感じは失いたくないなとも感じていて。やっぱり自分の好奇心や探究心、人との関係性を大事にしながらやっていきたいなという思いはずっとありますね。 あと、あんまり目の前主義じゃないみたい所もあります。起業したときも、手前の1〜2年で成功しようみたいな期待ではなく「10年後にこっちを選んで正解だったな、と思えるか」みたいな軸でも見ていて。大きな意思決定は、割と長い目で見るタイプだと思います。

<h2 id="h9f1ec7b4f7">テクノロジーで社会を変える。Azitが目指したいこと</h2>ー 改めて、Azitは何を目指す会社だと思いますか。 テクノロジーで社会を変えるというのは、もちろん目指していきたいことです。海外の分かりやすい例だと、Palantirのような会社を目指していきたくて。Palantirのモデルって、これまでのスタートアップとも違えば、SIerとも違うんですよ。テクノロジーで社会を変えるという意味で、プラットフォーム作りをしているわけではなく、大企業を変えるソリューションを持っていてその力をいかしていく、そういった意味で、最も成長している会社だと思っています。 日本でこれをやっていくときに、どこから立ち上げてどんなケイパビリティを身につければ良いのかでいうと、まだまだ試行錯誤の段階ではありますが。SaaSだと解決しきれないような領域を、AIを使って横断的に解決していければいいなと考えています。 エンタープライズと一緒にテクノロジーを活用できる会社は、面白いですよね。プラットフォームだけでもSaaSだけでもないハイブリッドな企業を目指していけたらと思っています。 ー その先にある未来の生活を変えていくようなイメージでしょうか。 生活もその一つだと思いますし、配送に限らずテクノロジーで変えたい部分は多分にありますよね。日本は世界に比べデジタル化や活用が、ルールの改革も含めて遅れがちなので、10年経ったらだいぶ取り残されてると思いますし、それこそ30年経ったらもう取り返しがつかなくなってるかもしれません。 大企業でもテッキーな意思決定をできるように、その意思決定のサポートをする存在になれることも大切だと思っていて。相手は、ときにエンタープライズかもしれませんし、政府かもしれない。大きな組織の意思決定者から信頼してもらえるような、テクノロジーを活用する会社になることが求められていると感じています。 特に、物流やサプライチェーンという領域は街の小さなお店とかではなくて、大企業が国民の生活のインフラとして担っている部分がほとんどで、彼らを変えていかないと社会全体が良くならないのが自明な領域でもあって。そこにスタートアップがテクノロジーの面から支援していくというのは今後の日本のあるべき姿なのではないかな、と思います。 ー 最後に、これを読んでくださっている方々に伝えたいことはありますか。 AzitではVALUEとして「Love &amp; Respect」というのを掲げています。心の底から愛とリスペクトがある人と働きたいと思って作られたチームでもあるので、これから一緒に働いてくださる方にも、大切にしてもらえたらいいなと思っていますし、その社風を感じてもらえるような会社でありたいな、と思っています。 また、AIの活用というのも全社的に推進していきたいと考えています。全員がAIを使いこなして、どんどん少数精鋭でも社会に大きなインパクトを作れる会社にしていきたいですね。これは別にエンジニアだけの話ではなく、Bizサイドもコーポレートも、全部門で活用できると思っていますし、全員のバックグラウンドに関係なくリテラシーを求めていきたいなと思っています。 もちろん、人と一緒に何かをすることはすごく貴重な経験だし、大事だと思っていながらも、その裏側でAIを活用しまくれるようになっていきたいし、そういうチーム作りをしていきたいですね。 インタビュアー：COO 山口 恭平、編集：坂井 華子

<h2 id="hda492ffe51">採用情報</h2>AzitではCEO直下で働く、Cheif of Staffのポジションを募集しています。 CEOと共に経営課題解決の伴奏を行うポジションで、企業成長のため生成AIを活用したオペレーション・組織づくりにフォーカスしたミッションとして持ちます。 詳細は、以下の募集ページをご覧ください。 <a href="https://herp.careers/v1/azitinc/Xxe4VkvM-6vO" target="_blank" rel="noopener noreferrer">https://herp.careers/v1/azitinc/Xxe4VkvM-6vO</a> また、Azitではpodcastも配信しております！ぜひ聞いて下さい！

「ここが僕らのアジト」CEO吉兼がAzitで目指すコト

Love from Azit 編集部

Azit CTOの十亀（<a href="https://x.com/Pocket7878" target="_blank" rel="noopener noreferrer">@Pocket7878</a>）です。 DeliveryXでは、2023年中盤からWebフロントエンドへの新しいアーキテクチャの導入を進めており、 本記事では、新しいアーキテクチャの導入にあたってどのような観点から判断を行ったか、 DeliveryXのWebフロントエンドで今後行いたいと思っている技術的な改善項目などをご紹介いたします。

<h2 id="he3a56227a9">2024年現在のDeliveryXのWebフロントエンド技術スタック</h2> 2024年11月現在、DeliveryXのWebフロントエンドの技術スタックは以下のようになっています。<ul><li>Next.js 14</li><li>React 18</li><li>TypeScript</li></ul>そして、プロジェクトの構成はモノレポ構成になっており<ul><li>クライアント企業が利用する管理画面</li><li>弊社オペレーターが利用する管理画面</li><li>共通化されたUIコンポーネント</li><li>UIコンポーネントではない共通化されたロジック</li></ul>という構造になっています。 また、クライアント向け管理画面は画面数27画面、社内管理画面は26画面となっており、それぞれの画面にいくつか機能が存在しますので機能数としてみるともう少し多くなっております。

<h2 id="h18d06fe205">2023年中盤ごろのアーキテクチャと課題</h2> 2023年中盤、DeliveryXではNext.js 13を使用し、Page Routerを採用していました。この時期、次期バージョンであるNext.js 14やApp Routerへの移行を検討していました。 当時のプロジェクト構成では、以下の特徴がありました： 	•	各ページを*.page.tsxファイルとして定義。 	•	ページ内で使用するコンポーネントを同じディレクトリに配置する形式。 <h3 id="h472bd8c72c">当時の課題</h3> この構成で初期段階の開発は順調に進んでいましたが、ページ数や機能数が増えるにつれ、以下の課題が明らかになりました。 コード管理の煩雑化 ページ内機能が複雑化するにつれて、データ取得用のReact hooks、UIコンポーネント、API通信（POSTやDELETEなど）が混在し、管理が難しくなりました。 プロジェクト構造の視認性の低下 ページとその関連コンポーネント、ロジックが一箇所にまとめられているため、どのページが存在しているか一目で把握しにくい状況に。 新規メンバーへの負担 プロジェクト内に明確な規律や設計パターンが存在せず、新しいメンバーが加入した際に開発に慣れるまで時間がかかる状態でした。 これらの課題は、アプリケーション規模の拡大に伴う問題を浮き彫りにし、設計や構成の見直しを検討するきっかけとなりました。

<h2 id="h0fc17a5a23">新しいアーキテクチャの導入検討</h2> そのため、これらの課題の解決のためにプロジェクトのアーキテクチャの見直しを検討しはじめました。 いくつかのアーキテクチャ設計のパターンを見ていく中で、たとえば以下のような事を検討しました。 <h3 id="h0a1de854d8">Atomic Design</h3> UIデザインの観点から整理するという方向で Atomic Designの思想にもとづいて整理することも検討を進め 実験用のブランチを作り試験的に既存の機能をリファクタしてみたりしました。 またAtomic Designを先に導入をすすめた企業の知見なども取り入れたいと思い、記事を探す中では以下の食べログさんの記事が非常に参考になりました。

食べログさんの記事では、<blockquote>「Atoms」と「Molecules」を分けることで得られたメリットが特にありませんでした。</blockquote>と触れられており、<ul><li>Atomsは他のコンポーネントに依存していない最小粒度のコンポーネント</li><li>MoleculesはAtomsや同じ階層のMoleculesなどを組み合わせたコンポーネント</li></ul>としてAtomic Designでは定義されていますが、 我々のチームの開発のなかでも<ul><li>ボタン</li><li>入力フィールド</li><li>入力フィールドとボタンが一列にならんだインラインフォーム</li></ul>などAtomsとMoleculesにそれぞれ分類できそうな単位のコンポーネントは存在しますが、 一方でそれらを区別して管理することで特に開発上まだメリットを感じられる状況では無いように思えました。 事業フェーズやチーム編成を考えると、場当たり的に開発を進めるのは当然避けるべきだと考えています。 一方で、設計思想に準拠しているかを検討することに過度な時間を割いてしまうリスクも、同様に避けるべきだと判断しました。

<h3 id="h66d711161f">bulletproof-react</h3>そのなかで、以下の記事と出会い、bulletproof-reactというアーキテクチャの存在を知りました。

bulletproof-reactではfeaturesというディレクト以下に機能のグループごとにディレクトリを作り<ul><li>hooks</li><li>api</li><li>components</li><li>types</li></ul>という構成で分類し、index.tsを通して外部に必要な部分だけを公開するという方針をとっています。 このような機能 (feature) ごとにディレクトリを分割して管理する方式はfeature moduleパターンとしてモバイルアプリなどでも採用事例が多く

実際にfeature moduleパターンを利用したプロジェクトの開発体験が良いことは弊社モバイルアプリに機能追加をした際に触れてみた場面でも感じていました。 ある機能がReact hooksであるか、componentsであるかなどは開発者の間で意見が分かれることは考えづらいと思い、 また、新しいアーキテクチャの導入目的であるプロジェクトへの規律という意味では十分であると判断しました。 そこで、実際に既存機能のいくつかを実験ブランチのなかで再整理し、迷いなく移行できることを確認したうえで導入を決定しました。 featuresディレクトリからはindex.tsを通して必要最小限の部分だけを外部公開しているため、内部のコンポーネントやロジックを再整理する際にも影響範囲が明確になるため、中長期でもメリットがあると感じています。

<h2 id="h59012fef17">featureアーキテクチャとAppRouter移行</h2>Next.js 13を長く使用してきたため、Next.js 14への早期移行を目指し、併せてApp Routerへの移行も進めることを検討していました。 しかし、まずは既存のコードベースの見通しが良くないと、新しい技術の導入は難しいため まずは新機能開発時にはfeatureアーキテクチャで開発することとし、開発の合間で既存機能についても移行をすすめて全ページの移行を完了しました。 そこで、今度はPageRouterからAppRouterへの段階的な移行プロジェクトを開始することとしました。 AppRouterを利用するにあたっては、ページをRSCに対応する必要がありますし、速度の観点などからも当然メリットがあるため導入したいと思っていました。 一方で、DeliveryXでは物流のデータを扱っているため、ページは必要な情報鮮度の観点から以下のように区別できます: <ul><li>クライアントの操作を伴わずに情報が更新され、鮮度の高い情報が随時反映される必要があるページ（業務の進捗確認ページや、車両の動態管理画面等）</li><li>一般的なCRUD型の管理機能であり、クライアント側の能動的な操作によって情報が変更されるページ</li><li>クライアントの操作を伴わずに情報が更新されるが、鮮度の高さは求められていないページ</li></ul> 後者の2つについてはブラウザのリロードをされたタイミングで最新の情報が反映されればよく、データのフェッチはレンダリングごとで問題ありません。 （※ログインを伴ってユーザーごとの情報を表示する部分が多く、完全に静的に配信できるページは今現在はほとんど存在しません） 一方で前者についてはタブレットや作業場所でブラウザを開いたままにしていても勝手に画面内容が更新されてほしく、 そのようなページについてはすでに<a href="https://swr.vercel.app/ja" target="_blank" rel="noopener noreferrer">SWR</a>を利用して実装されていたため、このようなページについてはほとんど丸々クライアントコンポーネントのままのほうが適切であると判断しました。 また、<a href="https://github.com/react-hook-form/react-hook-form" target="_blank" rel="noopener noreferrer">react-hook-form</a>を利用してデータの入稿や更新系のフォームや実現していたため、Server Actionsには対応しておらず 将来的にServer Actionへの移行は別プロジェクトとして行いたいものの、今回の移行プロジェクトにおいてはこのような通信についても引き続きクライアントサイドから実施する方針としました。

このようにApp Router移行にともなって引き続きクライアントから利用される部分と、RSCでサーバーサイドから利用されるようになる部分が生まれるため features内のAPI通信については、従来のapiディレクトリに一括してまとめるのは難しいと判断しました。 そこで、<ul><li>server_api</li><li>client_api</li></ul>という2つのディレクトリに分離し、それぞれに適切なAPIコールは配置することとしました。 また、featureディレクトリから外部に公開するのはserver_apiディレクトリのみに制限することでApp Router側のページからはRSCからの呼び出しを想定しているAPIのみとなるようにしました。

<h2 id="h7891b8d0ac">今後の課題とやりたいこと</h2> <h3 id="h7ad20108e9">ContainerとPresentationパターン化を検討しコンポーネントを整理する</h3> RSC化をすすめるなかで、今回はserver apiとclient apiを分離する形で分離をしていました。 現在はデータのフェッチはapiを直接呼び出すか、hooksで取得する形を利用していますが、<a href="https://zenn.dev/akfm/books/nextjs-basic-principle/viewer/part_2_container_1st_design" target="_blank" rel="noopener noreferrer">RSCにともなってそのような構成を見直す動き</a>もあります。 もしそのような設計のメリットが大きい場合は、featureディレクトリからserver_apiの公開を不要にできる可能性があり、その点も含めてリファクタリングを検討していきたいと思っています。 <h3 id="hb22db67169"> styled-componentsからRSCに適したCSSへ移行する</h3> RSC化を進めていく中でいくつかのコンポーネントでは、単に情報を表示しているのみなので本来はサーバー側でレンダリング可能であるものの styled-componentsしてスタイリングを行っているためクライアントコンポーネントのままになってしまっているパーツも存在します。 こちらについては、Tailwind CSSへの移行を進めており、そちらについても今後記事化したいと思っております。 <h3 id="h9603ac7f08">Sever Actionへの段階的な移行</h3> DeliveryXでは通信量を削減したりプログレッシブエンハンスメントを進めることで、 中長期的にプロダクトとして倉庫内など電波状況があまり良くない可能性がある環境など様々な方たちに導入していただきやすくなります。 そのような観点からRSCやServer Actionなどの仕組みを導入していくメリットがあると考えております。

AzitではWebフロントエンドエンジニアを募集中です。ご興味をお持ちいただけましたら以下の採用サイトからご応募下さい

Webフロントエンドエンジニア (Tech Lead)

DeliveryXのWebフロントエンドでのFeatureアーキテクチャ導入の背景と実践

<h2 id="hd76adefb87">安全なリファクタリングを実現するための高いテストカバレッジの重要性</h2>CREW Expressはビジネス領域が複雑なためDDDで開発をしています。配達パートナーです。 コードベースの肝となっているDomainsとUseCasesのテストカバレッジはほぼ100%です。

※All Filesが低いのはLibrariesには生成したファイルが多くありますがそれらはテストコード書いていないためAll Filesのテストカバレッジが低いためです。 CREW ExpressではRailsを利用しているため、静的型検査等による恩恵を受けることが難しく、リファクタリングには大きなリスクが伴います。 しかし、ユニットテストのテストカバレッジが高いことにより、そのような言語のサポートがない場合でも、安全にリファクタリングを行うことができるため、開発効率の向上とプロダクト品質の維持に貢献しています。 テストカバレッジの高さが、どのようにリファクタリングに貢献したかについて説明をします。

<h2 id="h33bebc3fd0">DDD導入をすすめ、Formクラスをユースケースやドメインサービスへと変更</h2> まず、最初にリファクタリングをしたのはDDDの導入をすすめるためにおこなったFormクラスのリファクタリングです。 Formクラスは、ドメインを表す適切なクラス名にできていないという問題があったため、ユースケースクラスやドメインサービスクラスに変更することで、プロダクトの内部品質を向上させることができました。 大きなコード変更でしたが、高いテストカバレッジのおかげで、バグがおきることなく順調にリファクタリングができました。 詳しくは以下の記事を参照してください。

<h2 id="h89e0d144c1">コンテキストマップのリファクタリングも漸進的におこなうことができてきた</h2>コンテキストマップについてもドメイン領域の理解やビジネスの変化・進化にあわせて漸進的にリファクタリングをしてきました。 具体的には次のような流れでコンテキストマップを改良しました。 最初にコンテキストマップを作成したときは、配達と配達パートナーのマッチングは同じコンテキストにありました。 しかし、コンテキストをシンプルにするため、配達とマッチングのコンテキストを分けることにしました。 さらにビジネスモデリングの変化によって、マッチングをマーケットプレイスと配送管理システム（TMS）の2つのコンテキストへ分けることになりました。 このようなビジネスモデリングの変化にともなうコードの変更は、逐次できていないと大きな負債になってしまったり、コンテキストマップが間違った情報を伝えてしまうことになります。 ビジネスモデリングにともなうコンテキストの変更では、大規模なクラスの移動や呼び出し関係の変更などが必要になります。 CREW Expressでは高いテストカバレッジのおかげで、このような大きめなリファクタリングでも、想定外の影響範囲があった場合はテストが失敗するため、すぐに気がつくことができます。

また、小さいリファクタリングも頻繁におこなうことができるため日々コードの内部品質を向上させることができます。 このように、日々コードの内部品質を高い状態に保たれていることで、開発者は新しい機能の追加に集中できます。 また、内部品質の高いコードは、将来的に発生するバグを減らし、保守性を向上させることもできます。 このようにテストカバレッジが高いことは、プロダクトの品質を維持し、開発者が新しい機能を追加することに集中するためには必要不可欠な要素です。

<h2 id="h643e2f2dfb">リファクタリングがユーザーエクスペリエンスに与える影響</h2>前述の通り、テストカバレッジが高い状態を保つことで、開発チームは安全にリファクタリングを進めることができます。 リファクタリングによって、コードの可読性が向上し、保守性や拡張性が高まります。 しかし、リファクタリングを行う際には、意図せずプロダクトの機能が変化してしまうことがあります。そのような問題を防ぐためにも、高いテストカバレッジが必要になります。 さらに、テストカバレッジが高いことは、ユーザーにとってもメリットがあります。 テストカバレッジが低い場合、ユーザーがプロダクトを利用する際の不安定な動作につながる可能性があります。 例えば、ユーザーが想定していない動作が起こる、あるいはエラーが表示されるなどです。 そのような場合、ユーザーは不快な体験をしてしまうことになります。 高いテストカバレッジを保つことで、プロダクトの品質を維持し、ユーザーに安定した体験を提供できます。

<h2 id="h9243659064">今後はE2Eも充実していきたいです</h2>高いテストカバレッジがあるため、テストにおいては十分に見えそうですが、サービスの都合上E2Eテストはあまりできておりません。 CREW Expressは、配達パートナーが使用する配達アプリを含む複数のアプリケーションが統合されたサービスです。 これらのアプリケーションは、実際の運用環境においては複雑な操作や実際の移動をすることがあります。 そのため、E2Eテストを行うためには、実際の運用環境に近いテスト環境を構築する必要があります。 しかし、これは非常に困難であるため、私たちはまだE2Eテストに注力できていません。 E2Eテストを行うことで、ユニットテストでは確認できないサービス全体の仕様の不備やバグの検知ができます。 そのため、私たちは今後、ユニットテストだけでなくE2Eテストにも取り組み、システムの品質を高めていくことを目指しています。

<h2 id="h3bcda3e6b0">最後に</h2>最後に、テストカバレッジが高いということは、開発チーム自身がプロダクトに自信を持っているということでもあります。 テストカバレッジが高く、コードの品質が高いということは、開発チームがプロダクトに対して真剣に向き合っているということでもあります。 今後、CREW Expressはより様々な企業に導入してもらうことになっていきますが、高いテストカバレッジがあることで大きめの設計の変更やリファクタリングをするときにも自信をもっておこなうことができると確信しています。 Azitは高品質なプロダクトを目指し、テストカバレッジだけでなく設計や開発プラクティスにも力を注いでいます。開発チーム内での議論や読書会などの勉強会を積極的に行い、知識や技術の共有を促進しています。 現在、CREW Expressの開発に共に取り組んでいただけるほうを募集しています。興味をお持ちの方はカジュアル面談などでの情報共有でもいいのでぜひご応募ください。

CREW Expressの開発チームは、プロダクト品質の維持と開発効率の向上を目指して、高いテストカバレッジを維持しています。今回は高いテストカバレッジがあることのメリットについて説明します。

サーバーサイドエンジニア (IC)

安全にプロダクト品質を改善できる！ほぼ100%のテストカバレッジがある世界

鈴木

<h2 style="text-align:justify" id="h4ac34ea3e7">イベント概要</h2>第３回となるBeyond SaaS。本イベントは従来のSaaSとは違い、ソフトウェア以上の価値を提供するBtoBスタートアップ企業の代表に登壇いただき、今後の市場の発展、新たな時代の潮流を読み解く対談を実施。 今回は小売チェーン向けのECプラットフォームを運営する株式会社10Xの代表取締役CEOの矢本さんをゲストに迎え、“エンタープライズDX事業”の極意について紹介。

矢本真丈

吉兼周優

<h2 id="h08a41db196">今回はアーリーステージ期にエンタープライズ企業と提携する上で大切な事業開発、プロダクト開発、組織開発など細かな課題解決方法について語られました。</h2>主にPM、BizDevなどに携わる20名弱の方々が参加したオンラインイベント。初めてエンタープライズ企業と提携する場合、実績のないところからどのようなコミットメントを達成させていくのか、信頼構築の取り組み方や円滑に稼働できる組織形態の秘訣など詳しく話していただきました。およそ1時間弱にわたる登壇の中から要点のみを一部ピックアップしてお伝えいたします。

<h2 style="text-align:justify" id="h24451c175f">事業開発について</h2>

エンタープライズ企業との提携を始めたきっかけはなんですか？

現在はStailer（ステイラー）という小売チェーン向けのECプラットフォームを展開するBtoB事業をやっていますが、その前はタベリーという献立アプリのBtoC事業をしていました。BtoC事業の立ち上げ当初は、ユーザーが集まっていれば金融市場からも評価される風潮があり、実質的にマネタイズが不十分でもやってこられたという内情がありました。ですが、果たして会社としてそれで良いのかと考える時期に差し掛かりました。本当にマネタイズはできているか、事業としてスケラビリティはあるのか、もっと本質的なことを言えば大切な顧客にとっての重要な問題が解決できるサービスになっているのかなどですね。その他にも事業の稼ぎ方も顧客の体験を毀損することのないより良い事業を作りたいという思いはずっとありました。そこで、小売業界の中でも一番難しいと言われている食品のネットスーパー領域の課題解決につながる事業に着目したのです。こうしたあらゆる観点で事業の発展性を考えた時にエンタープライズ企業と組むことが一番良いと思い、現在のStailerというサービスが生まれました。

エンタープライズ企業と組むにあたって大事にしていることはなんですか？

エンタープライズ企業側が何を実現させたくて、そこに自分たちがどのようなアプローチができるかという視点を大事にしています。10XはStailerの前にＢtoC事業をしていたので、エンドユーザーの声をはじめとしたデータを直接もらうことができていました。そのため、小売の先にいるお客様が何に困っているかというニーズを詳細に拾いあげてプロダクト開発に繋げています。

エンタープライズ企業はやはりSMBと違って契約まわりが厳しかったり、期待値調整が難しかったりすると思うのですが、大変だったことはありますか？SMBかな？と思いましたが、ご確認ください。

過去2年ほどは本当に大変でしたね（笑）2020〜2021年、2022年の頭くらいまでは、その帳尻合わせをプロダクト開発においても行なっているという状況でした。まず、私たちスタートアップは当然ながら交渉力が低い状況です。エンタープライズ企業の方々の課題解決をどこまで請け負うのか等の期待値調整も非常に曖昧でした。なので、実際にシステムが稼働してから当初思ってもみなかった要望を受けたり、期待値の調整を行なったりといった経験もありました。

具体的に言うと、Stailerは2021年からお客様アプリに加え、店舗オペレーションのためのアプリケーション開発、在庫データを推論するシステム開発、ポイント・決済システム設計なども一括で行なっていたので、当初想定した納期に対して非常に厳しい状況に…。何とかリリースはできたものの、結果的に当初は品質の低い部分もあるサービスになってしまったため、お客様からのクレームをいただくという事態も発生しました。

この課題について今現在の矢本さんならどのように対応しますか？

これは完全に期待値調整、というか事業開発に問題があったんですよね。まず、最初の時点で「プロダクト開発は不確実性があります」とエンタープライズ企業の方々に前提をお伝えすべきだったかなと。アジャイルの考え方や不確実性が大きい中でどのようにQCDを確保するかという方法論を顧客であるエンタープライズ企業の方と話をする必要がありました。どうしてもスタートアップ企業は立場上、契約を取るために許容範囲以上のコミットメントをしてしまいやすいと思います。焦らず、背伸びしすぎずに。…と言いたいところですけど一周目はどうしても失敗してしまうのではないかな（笑）僕が今もう一度最初から立ち上げるとなっても背伸びしますね。リスクを取るタイミングでチャレンジしないと、事業が作れないと思うので。

そうですよね、そうしないと事業が成立しないですよね。

そもそも契約が取れなければ会社としても成立しないわけです。QCDに関する問題は事業が始まってさえいれば解決できる問題ではあるので。究極的な言い方をするなら事業をやらないか、事業をやった後で起こる困難を全て引き受けるかという選択肢になるのですが、それなら僕は後者をとりますね。

エンタープライズ企業のなかでも相性の良い企業、成功した事例などあればお願いします。

今回の対談テーマのキーワードにも「DX」とありますが、個人的にD（デジタル）は特に重要視しておらず、トランスフォーメーションに重きをおいています。この30年間日本の経済が衰退しているのも、産業変革が一部の企業でしか行なわれていないというのも要因ではないかなと思っています。では、変革とは何か。それは根本的な構造を変えることです。やはり既存の事業やオペレーションに一切の痛みなく遂行することは難しいと捉えています。教育コストをかける、未知の分野に先行投資をするといったリスクに加え、事業のポートフォリオに変革を起こせるかどうか、といった点を最初の打ち合わせではお話しさせてもらっています。今の時代ネットスーパーを参入することは難しいことではありません。ですが、単に時流だから取り入れる…のではなく、ネットスーパーという事業を今後10年、20年先も会社のコアにしていくという意思があるかどうかというのは、私たちがお付き合いする上でも大切にしています。

社内の体制についてはどうでしょうか？

そうですね、事業が成長する限り常に何かしらの体制不足は否めません。パートナーが増えるたびに要望も大きくなり、増えていくので社内のケイパビリティを増やすには人員を増やさなくてはならないです。かといって求人募集を始めても採用・育成期間も含めて最低半年はかかる。このように会社規模が大きくなるほど、実質の社内体制が追いつかずギャップが生まれる。CEOはそのギャップをどう解消していくか、そして自身の取捨選択に応じて得られなかった成果を受け止める覚悟というのも時には必要なのではないでしょうか。

<h2 style="text-align:justify" id="hd192f3b8d1">プロダクト開発について</h2>

事業立ち上げ当初のプロダクトの完成度はどの程度のものでしたか？

実は私たちはStailerを初めて一社目と二社目で売っているプロダクトが変わっています。一社目で提供したプロダクトはエンドユーザー向けが使いやすいネットスーパーアプリでした。しかし、いざ取引を始めて見えてきたのは、エンドユーザーが快適に使えるアプリ開発をしただけでは顧客の本当の課題解決につながりにくいという点。たとえば、ネットスーパーをやったことのない人に向けた取り組みやネットスーパー分野の事業を2倍に増やしたいという顧客の要望があった場合、エンドユーザー向けのアプリ開発だけで解決できる範囲はせいぜい1〜2%くらいです。このことが一社めですでに見えていたので、二社め以降は、店舗のオペレーションや商品データなどにも入り込みより本質的な課題解決に対応するプロダクト開発に臨みました。なので、一社めの時点で完成度の高いプロダクトを作るというよりは、業界に認知してもらうための旗揚げとなるプロダクト開発になりましたね。

その顧客課題の本質が見えていたら、一社目から今のようなプロダクトを作っていましたか？

いや〜、わからないですけれど再現性はあまりないかなと。立ち上げ当初のチームメンバーは10人でしたが、今のプロダクトを10人で動かすとなると開発に3年と4ヶ月は要しますね（笑）事業として成立するギリギリのプロダクト、かつ顧客が欲しいと思ってくれるタイミングと提供できるタイミング、そして効果がしっかり現れて一定の品質が保たれるという、さまざまな掛け合わせが実現できる範囲からのスタートが望ましいですよね。いずれにしても何か新しい事業をやろうと思うなら知ってもらわなければ始まりません。大事なのは、参入したい産業にどんなアプローチができて、その後どのような発展性を遂げられるのかという未来図を描くことでしょうか。

確かに我々Azitも当初配送サービスを自前で行なっていましたね。その後に出てくる課題解決に向けて体制を変えていかないとと思い現状に至りますが、それでも自前で配送サービスを行なっていたという経験がエンタープライズの方々にとって大きな価値を生み出したところがありますね。

そう考えると、ほとんどの成長しているSaaS企業って事業としての登り方に共通する部分はありますよね。アプローチをかけたい業種の実際の課題はどこにあるのかを、その事業に携わりながら理解を深めていくことが大切なのかもしれません。

Slerとして個社に向けたプロダクト開発に注力をする一方、自社の資産となるプロダクトの開発もしなくてはならない。そのなかでどのように開発優先度をつけていますか？

Sler企業にとって個社の成功は自社の成功でもあります。そのため、一社ずつ細かいニーズを拾った方が良い場合もあるでしょう。その一方でプロダクト開発段階でもROIを考えなくてはなりません。10Xではドメインエキスパートが取引をしている各社のニーズを広い、対応できる抽象水準を定めます。さらにアナリストが自社のGMVの成長予測やインプットメトリクス・アウトプットメトリクスなどを試算し、自社内での共通認識をすり合わせています。可能な限り、どのラインでどのようなプロダクトを作れば良いのかという仕様書を作成し、社内で共通認識が持てるように設計を組んでいますね。これがなかなか難しいところです。

<h2 style="text-align:justify" id="hd4eaa0610a">組織体制について</h2>

エンタープライズ企業と提携を行う上で、組織拡大の面ではどのような壁を感じましたか？

事業のフェーズが進むと必要になる組織や体制も拡大しなくてはいけないものの、現実問題すぐには解消することは難しいです。そこで生じるギャップが、社員の疲労や不平不満という深刻な問題を引き起こしてしまう。多くのスタートアップ企業の組織拡大における最初の壁ではないでしょうか。ただ、これはもう壁というか起きるべくして起きた問題だなと捉えています。

具体的にはどういうフェーズで問題が生じましたか？

提携企業が一社から一気に複数社に増えたタイミングです。五、六社くらいの企業のサービス、プロダクト開発、リリースなどを一貫しなくてはいけない。当初の10Xでは案件を担当している人のオーナーシップで仕事を分担していく自由度の高い形式をとっていたため、結果的に一人の人に大きな裁量負担がかかっていたんです。なので、プロジェクトの数が大きくなっていくと同時に社内の組織体制も多様性のあるものに切り替えていく作業は必要でした。

組織図の形はどのようなものを採用しましたか？事業フェーズによって変化があれば変えたタイミングも教えてください。

組織の形は事業のコアが決まると自然と決まっていくものだと考えています。10XはSlerとしてプラットフォームを作っているので、プロダクトを作るだけが仕事ではありません。かつあらゆるパートナー、スタッフ、エンドユーザーの問題を解決しなくてはならないので、その優先順位をもとに考えると社内の組織図は必然的にマトリクス型しかないなと。

マトリクス組織って難易度が高いと言われていますが、その組織づくりの基盤となった参考モデルはありますか？

トヨタですね。トヨタは昔からマトリクス組織を採用していて、以前からその在り方に共感をしていました。そのほかにもマトリクス型を採用している身近な経営者の方や社長秘書を勤めていた方などにヒアリングをして、体制づくりに参考しました。加えて、社内に生産性をあげる優秀な人員が揃っていたことがマトリクス型採用の決め手となりました。

<h2 style="text-align:justify" id="h1afe451c43">さいごに</h2>スタートアップ期から段階を踏んで登っていく上での課題なども赤裸々に語っていただきました。今後エンタープライズ企業とパートナー提携をしたいという起業家、経営者のみなさんの参考になる話も多かったのではないでしょうか。 今後も魅力的な登壇者をお迎えしていく予定のBeyond SaaSをお楽しみに！

2022年12月13日に「 BtoBスタートアップのネクストトレンド「第3回 Beyond SaaS ー産業を創るー」」を開催いたしましたので、その内容をレポートとしてご紹介したいと思います。

【イベントレポート】 BtoBスタートアップのネクストトレンド「第3回 Beyond SaaS ー産業を創るー」

株式会社AzitでRailsを使用したバックエンド開発をしている鈴木です。

今回は、Azitでのチーム開発に少しでも興味を持ってもらえるように去年(2022年)チームのコミュニケーション面で改善したことを紹介します。

# 改善した項目

- DesignDocのアップデート
- 定期的に話し合うために週次でのディスカッション・振り返りをするようにした
- チームで共通の認識をもつために社内読書会をおこなうようにした

## DesignDocのアップデート

私達のブログの記事でDesignDocを導入したことを書きましたが、DesignDocを運営をしていく中で以下の問題にあたりました。

- Draw.ioにログインをしている状態じゃないとNotion上で図が見られない
- SUDOモデルだと実装に入るために必要な情報が不足している

## **Notion上でDraw.ioを見れないときがあるのをMermaidを使用して改善した**

以前のDesignDocではDraw.ioに図を書いたものを貼り付けていたのですが、Draw.ioにログインをしている状態じゃないとNotion上で図が見られなかったり、Notion上では変更することができないという問題がありました。

それを改善するために、[Mermaid](https://mermaid.js.org/#/)というNotion上からでも編集できるテキストで図形を描画するツールを使用しました。

Mermaidを使用すると下のような図を作成することができます。


下のようなNotionでコードを入力するところでMermaidを使用して以下のような記述をすると上のような図を書くことができます。

これにより、最初の設計時に間違った内容だったとしてもドキュメント内(Notion)で簡単に編集をすることができ設計図を修正していくことができるようになりました。

## チームで実装をするために必要な設計をして共通認識をもったまま実装を開始できるようにした

DesignDocは以下のことを書くようにしています。

- 要件定義書のへのリンク
    - PdMとBizで話し合ったことの開発チームへの共有を簡単にしています
- コンテキストマップのアップデート
    - ドメインの変更について話し合ってドメインを適切にアップデートをしていくことができるようにしています
- ドメインモデリング
    - 今後の設計に必要な概念や用語を洗い出します
- ユースケース
    - ドメインモデリングをした概念や用語をもとにユースケースを定義します
    - ここからは、[ICONIX(ユースケース駆動)](https://ja.wikipedia.org/wiki/ICONIX)を参考にしています
- ユースケース記述
    - ユースケースを実装するために必要な項目を記述します
- ロバストネス図
    - プロジェクトを網羅的に理解できるようにするために作成します
- ドメインオブジェクト図
    - 集約などについて考えるために作成します
- ER図
    - ドメインオブジェクト図で考えた内容をRDBで作成できるようにします
    - ドキュメントの抽象度を高くしたいためテーブル名のみを記述します
        - カラムも記述するとソースコード内のマイグレーションファイルに記述している内容と乖離が発生しやすくなってしまいます
- UseCaseクラスの模擬コード
    - 実装のイメージを共有するため擬似コードを書く

このように、細かく設計を作成していくことですぐに実装に入ることができるようになります。

設計するときは必ずモブプロをすることで設計に関する議論をリアルタイムでするのと認識の共有をしていくことができます。

また、1回ではすぐに実装をするドキュメントを作成することはできないので、後工程で修正する必要があったら前工程の図を更新するようにしています。

# 定期的に話し合うために週次でのディスカッション・KPTをするようにした

私達のチームはフルリモート・コアタイム無しのフレックスです。また、Gatherなどのようなコミュニケーションツールも使用していないです。

そのため、なにもしなかったらただモクモクとタスクをこなして、チームで適切なコミュニケーションをしながら仕事をすることやチームを通しての成長をするという機会があまりとれないです。

その問題を解決するために、週次で各メンバーが今考えていることを話すためのディスカッションと簡単なKPTをするようにしました。

## ディスカッション

ディスカッションでは、チームに関することとリファクタリングに関することを相談できるようにしています。

### チームに関すること

チームに関することはこれができると良くなるのではないかという提案や相談したいこと、認識を揃えたいことなどチームに関することならなんでも良いです。

話し合うこと自体が目的な部分もあるのでここに書いたことは必ずしもおこなわなくてもいいです。

一度話したことに実際に着手するときは、チームではすでに話し合っているので実施しやすいです。

実際に話し合ったこと

- DDD Learningの次の社内勉強会で扱う本について
- RBSさわっています
- Rspecの記法を統一するために,RubocopのRspecを導入したい

### リファクタリングについて

リファクタリングは、現在は定例MTGに参加しているメンバーが全員バックエンドなのでRailsのリポジトリのコードでリファクタリングしたいことについて話しています。

今実装していたコードに関してはPRでレビューをすることができますが、以前実装した部分やモジュールレベルでのレビューはPRではできないです。

そのため、特定のタイミング(週次MTG)で話し合っています。

ここで話したことでおこなうことは、話し合ったことを忘れないようにするためにJIRAでチケットにしています。

実際に話し合ったこと

- UseCaseのクラス名について
- テストコードの粒度について
- RspecやOpenAPIで `.json` 等のURL末尾によるAcceptの指定をやめる

## KPT

フルリモートなため基本的に一人で仕事をすることになりますので、チームがどういうことをおもって仕事をしているかがわからないです。

わからなかったとしても直近の仕事をする上では問題はないですが、チームメンバーがどういうことをおもっているかが

わかるとお互いのことを知ることができチームビルディングの一つとして機能すると思いますので長期的には有効だと思います。

お互いのことを知るための手軽な方法はKPTだと思いますので、KPTをしたときにチームとして改善したほうがいいということを話すこともできると思います。

# 読書会の実施

チームの共通認識を作っていったほうが、コードレビューやコードの共同所有が効率的におこなえるという考えから勉強会の実施をすることにしました。

最初は、テスト駆動開発入門や実践ドメイン駆動設計などを扱っていましたが、チームとしてDDDに本格的に取り組むにあたりLearning Domain-Driven Design(以下Learning DDD)を読んでいくことにしました。

**Learning DDDの読書会について**

この本は最近発売したばかりなので、イベントソーシングドメインモデルやイベントストーミングなどの最新のトピックについても扱っています。

また、本の説明がわかりやすかったり、章末にある問題をチームで話し合いながら答えを探していくことにより1人で読むよりも理解度がたかくなります。

この本を読書会で扱ったことにより、チーム全体でDDDの共通認識をもつことができるようになっているのでこの本を読書会で扱ってよかったです。


# 求人

この記事に書いたように去年だけでも多くの改善をしていますが、今年はエンタープライズ規模のお客様などを含んだより多くのお客様にCREW Expressを使用してもらえるように、様々なお客様のニーズに答えられるようにしていく必要があります。

一緒に機能を開発したり、開発効率の改善を一緒にしてくれる方を大募集しています。

株式会社AzitでRailsを使用したバックエンド開発をしている鈴木です。今回は、Azitでのチーム開発に少しでも興味を持ってもらえるように去年(2022年)チームのコミュニケーション面で改善したことを紹介します。

2022年に開発チームのコミュニケーションを改善するためにおこなったこと

<h2 id="h4ac34ea3e7">イベント概要</h2>ニューノーマルな生活やビジネスに対応するため、新たなサービスや商品も続々と誕生した2021年。今回は、次代をけん引する新ビジネスの中でも"BtoBスタートアップ"に焦点を当て、SaaSの新たな潮流や市場の可能性について4社で対談を実施。 第2回となった本イベントでは、第1回でも多くの参加者から注目を集めた「各社の参入理由」や「どのようなことに現在チャレンジしているか」という内容を中心に語られた。

鈴木隆宏

遠藤崇史

本間拓也

<h2 id="h8e2be66aa2">Vertical SaaSに挑戦する各社だからこそ語ることのできる内容をベースにパネルディスカッションを行いました。</h2>総勢40名以上の方が参加したオンラインイベント。 スピーカーとなった3社の事業説明や各社が考える「BtoB SaaS」への想い、今後の展望など熱いディスカッションが行われました。 約1時間のイベントの中から要点のみ一部ピックアップしてお伝えいたします。

なぜAzitはドメインに「移動」を選択し、今もなおここまで深掘ることができているのか？

事業開発を2012年よりスタートし、2013年に会社を設立。 当時、ソフトウェア開発を起点に事業を行っていた中で、スタートアップが好きでスタートアップど真ん中のテーマを展開していきたいと思っていました。 世界各地ではモビリティ領域でスタートアップが生まれるなかで、どんなイノベーションがあるかを考えた時、「スマホで位置情報が取れることで、人の行動や運転手の行動がテクノロジーで最適化できる余地があること」をモビリティ領域に対して仮説として最初に考え、この仮説の深掘りを今もなお続けています。 これまで「人は移動したくない/交通費を払いたくない」という最低限の移動で済ませたい風潮があり、そこからデリバリー領域に興味がありました。 コロナが世界中で大流行し、人が移動しなくなったときに、社内のメンバーたちと会話をするなかで「クルーエクスプレス」へのチャレンジを決めました。 2012年12月にクルーエクスプレスを公開、その後1年間は「移動」ドメインからはブレることはないものの、次に何を展開していくか・チャレンジするかを検討し続けました。 そして「To C／To Bどちらが相手なのか」「地方や都心部なのか」など、誰に向けてどのように提供をしていくかについて選定を行いました。 ここから気づいたことは「バイク便」「フードデリバリー」「当日配送」など、どの領域・どのターゲットに対しても、テクノロジーで解決できる課題はかなり近いということでした。 そうであれば、規模が大きいところから挑戦しセールス効率のよいものから始め、SMBは中期的にやろうという順番になりました。

複雑性の高い領域にROUTE09がチャレンジした理由は何か？

伝統的な大企業勤務を経て、自分でスタートアップを立ち上げ、ゼロからプロダクト作りを経験したことから、大企業のシステムやプロダクト開発の現場を新しいアプローチで変えていきたいと思うようになりました。 大きな課題に対して解決する手段を具体的にイメージできていたことに加えて、オープンイノベーションやスタートアップ・協業など、大手企業を取り巻く時代の流れを考えた時、今このタイミングで始めるべきだと感じたことも創業の後押しとなりました。

2012年から現在まで「教育」をトライし続けているのはなぜか？EdTech（エドテック）領域分野における山の登り方は？

これまでの経緯としては、「Quipper」「スタディサプリ」でまずBtoCのサービスを提供していました。「Quipper」は”動画で学習する”シンプルなアプリとなっており、マーケティングで広めていくことをインドネシアやフィリピンで行い、「スタディサプリ」は日本で展開を行いました。 サービス提供する中で、BtoCでは子供たちがなかなか自発的に学習しないため、管理する人やサポートする人が必要であることがわかりました。 そこで学校へのアプローチを開始しました。 「スタディサプリ」は現在日本の学校数千校で導入され、「Quipper」でも5000校へ訪問営業を実施する中で、先生がいると子供も使うことを実感し、BtoBの走りをしていました。 その中で、「Quipper」の動画学習だけでは学校の学習全容を掴めていなかったり、先生達は教務以外の業務も多いため、ここをデジタル化しないと先生たちが楽にならないと感じました。 そこで現在は、先生達が関わるあらゆる領域をすべてデジタル化できるよう、教務だけでなく校務を含め分析し、システムを構築している段階となります。 塾・学校・高等教育機関、それぞれすべて洗い出しを実施したところ、教務の所はシステム的な違いがなくても問題ないが、校務部分は異なることが見えてきました。 そこから教務においては1つのシステムを他の機関で転換して展開していくことは可能である、という仮説が今見えてきています。 また、インドやフィリピンなどグローバルでもこのシステムは変わらないと考えています。特にインドでは1学年2000万人近くの生徒が存在し、さらに小学生は１億5千万人。そして進学率も上がってきているようなマーケットであるため、日本で磨いたシステムやオペレーションを海外にも展開し、効率よく子供たちにデジタル化したシステムを届けていきたいです。

生徒向けサービスを出しているVertical SaaSな会社が多いなかで、「オールインワン」で戦うことができているのは、多くのエンジニアがいるからこそ行うことができているのでしょうか？また初めから挑戦していたのですか？

先生や経営者たちの課題として、ログインだけで授業の半分が持っていかれてしまったり、データ自体がバラバラになってしまっていたりと、様々なシステムを使い過ぎていることでオペレーションが煩雑になっていることがありました。 この課題解決としてのオールインワンサービスを提供することがありました。 ベトナム展開した際に、日本よりもリーズナブルで優秀なエンジニアを採用・マネージメントすることは前職から経験しており、競争優位になると感じていたため、すべて作れるように動いていました。

みなさんはコンサル的に課題を解決し、課題の共通点をプロダクトへと落とし込む際、「どこまでをプロダクトに落とし込むか」についてはどのように考えますか？またどこまでコンサル的に落とし込むのでしょうか？（イベント参加者）

我々はかなりコンサル的なことを実施しています。 「自分が教育機関を経営したらうまくいく」と言えるくらいまで、事業戦略やオペレーションを理解していこうと社員に話しています。 その中でまず、中長期の経営課題から経営者と握っていくことをやっており、事業を成長させるために、システムやコスト削減や売上アップ施策について解像度高く提供しています。 さらに、プロダクトでどのように提供価値を作り満足度をあげていくかなど、ROI含め数値化し提示した上で、既存プロダクトとのフィット感前提で、事業インパクトの大きいものを優先度高く展開しています。 また、1社に対してだけのバリューにならず他のお客様に対しても普遍的に提供できる価値であるかについては、コンサルチームやプロダクトチームが密に会話してジャッジを行ってきました。

Azitではソフト開発でDDDを入れているため、ドメイン言語をどう作るかが重要になります。 例えば”配送”といっても「何が、どこまでが配送なのか」の定義がありません。 開発をしていく上で、この言葉の定義が必要となります。 逆算的になりますが、エンジニアリングの定義ができるものはプロダクトを作りますし、そこが曖昧なうちはソフトウェア開発やオペレーションに落とし込まず、コストをかけない判断を行うこともあります。 例えばベーシックなSaaSプロダクトで解決できない場合、海外SaaSで解決できるのであれば、海外のものでドライバーマネジメントしています。 無駄なものは全く作りたくないため最低限の開発になるように意識しており、「ドメイン言語を明確にする」というところをBizDevやソフトウェア開発チームに対して重要なポイントとしています。

すべてのプロダクトのUXや業務フローはすべて洗い出し、把握し、どこを自社プロダクトで賄い、SaaSを導入してカバーするのか、開発しないべきかを判断するために、細かい部分までUXや業務フローを明確にしています。

Vertical SaaSの苦悩（ 顧客理解の解像度 / プロダクト理解度 / 組織・採用 / 他）をどう乗り越えているのでしょうか？

開発チームへのドメイン知識に関してはきちんと細かく伝えています。 まず我々の場合、大きいマーケットの中で開発者がベトナム人やフィリピン人なのでローコンテクストです。 教育制度は国によって異なり、日本の塾のような文化が発展していない国となります。 そのため、ドキュメンテーションしたり、図に落とし込んだ上で、ビジネスモデルから説明し、オペレーションや経営課題・塾の成長についてなどを彼らにも細かく伝えています。 今後インドに展開する場合、インドの教育機関のオペレーションや経営課題を理解することが必要となり、そこから始まると考えています。 様々な課題がある中でプロダクトとして優先順位をどのようにつけるか、についての意思決定はかなり難易度高く、今後出てくるであろう課題にもなると思います。 今後、課題に対応できる組織やワークフロー、ドキュメンテーションなどを早めに準備する必要があり、先回りしていきたいと考えています。

顧客の理解度は特にエンタープライズだと複雑かつ理解が難しいところもあります。 そしてDDDのドメインについてもメンバーごとでのリテラシーの違いもあると理解していますが、個人的にはそれが好きなメンバーで集まるしかない、と考えています。 難しいし複雑だからこそ考えるのが好きなメンバーや、カルチャーレベルでコミットできるメンバーであることを肝としています。 そんな意識を持つ人は母集団として小さくなるものの、そこにディープな関心を持っている人たちが集まることで快適に働けるのではないか？と考えています。 もちろん組織を拡大するフェーズになると、モチベーションや働くことへの求めるものや取り組み方が異なることは理解しています。 そんな中でも、今の会社のフェーズについては、メンバーを集中させる・選択するフェーズとなります。

プロダクトマネージャーの職種が多いお話がありましたが、一定ドメインやECへの知識や経験が必要と思いつつ、世の中的に経験者が少ないイメージですが、どのような人を採用しているのでしょうか？また、未経験の場合のトレーニングプロダクトはありますか？（本間）

今はPdMや類似経験者を主としています。 うちの場合は、プロダクトを立ち上げてお客さんと一緒に事業をグロースしていく上で、事業立ち上げのための「プロダクト定義」や「UX定義」をする上での熱量がある人や、ものづくりが好きな人の方がマッチしていると考えています。 ドメイン知識がなくても、上記がマッチしているとお客さんに評価されたりもしますね。

教育機関関係なくBizDevで活躍している印象ですが、教育領域での課題の解像度をあげるのにどれくらいの期間がかかり、どれくらいの期間で戦力となるかと考えていますか？

教務と校務、それぞれサポートするかでかかる期間は異なります。 わかりやすい教務と比べて、請求管理や時間割管理などの校務については業界知識が必要となります。 そして高等教育についてはもう少し難易度が高く、高いからこそ誰もチャレンジしていない市場でもあります。そのため将来的にも攻めていきたいと考えています。

吉兼さん、物流領域はどうですか？

「物流領域といいつつ、自社では物流というワードを使っておらず、会社でやっていることは違っていると思っています。 自分達の課題解決は半径10km、リアルタイム性のあるもののため、ヤマト運輸や佐川急便のような「物流」とは異なり、どこかの業界経験が生きるというわけではなく、物流業界を積極的に採用しているわけではありません。 どちらかというと、ピュアに課題解決の視点をエンジニアリングやデザイン視点で考えられる人が本質的であると思っています。

それでは最後に、「Vertical SaaSの未来」についていかがでしょうか？

ストーンマイル配送の分野を行っていますが、既存のものと違うところが面白いと感じています。 例えば、「宅配」は今当たり前にありますが、「ラストワンマイル配送」には定義されていない状態です。 freeeやマネーフォワードは会計のルールが存在していますが、ラストマン配送については管理や配送体制・規格について、グローバル含めまだ未発展で定義づけが完了していません。 その中で新しいテクノロジーを使って顧客に対して課題解決をしている動きが先行していると考えています。 直近、配送分野でプロダクトが出来上がってきており、この新しい産業ができてきている中でルールメイキングできるところが日本社会の感じがあり、面白いところであると思います。 同時に顧客の課題解決や事業開発は面白いが、それで終わる会社にはしたくないとも考えています。 世の中がどうなるかわからない中で、課題解決に繋げていくところがスタートアップの一起業家としても個人の人生としても取り組みたいです。 例えば地震が起きた際、被災地に対して配送網を届けられるような活動を自分達の会社ができるのか、CO2削減などグローバルな課題や世の中が求めていることに対して、どのようにアプローチしていくのか、という部分はSaaS関係ない部分で取り組んでいきたいと思っています。 「かっこいいスタートアップ」を作っていきたいです。

これまでグローバルな事例も踏まえてみると、バーティカルSaaSで伸びているのはホールプロダクトかつ圧倒的なコストメリットを提供している会社だと認識しています。 日本でも同様だと思いつつ、この先を見据えるとコストメリットだけでなく、お客様の新しい売上の機会創出に貢献するような会社が大きくなっていくと思っています。 マーケティングや営業のソリューションだけに頼るのではなく、お客様のオペレーションに根付いて売上を伸ばしにいく会社はまだ多くないので、だからこそ可能性がありおもしろいポイントです。

マナビーが今やっていることは、教育の未来を実現しているとはまだ思えていません。 動画での教育がやっと世の中に少しずつ広まっている状態。 思っていることの1つ目に、将来的には新しい教育の形や単純なコストカットではなく新しい事業形態のデジタル化サポートがあります。 ただし、いきなり新しい形で参入しても浸透するまで時間がかかるため、既存のSaaSプロダクトでできるだけ多くの教育機関をサポートし始めたあとに、新しい教育のありかたやコンテンツを提供していきたいです。 それが新しい教育を提供する上での最速の道ではないかと考えているので、今持っているプロダクトを広げていきたいと考えています。 2つ目は オンラインでの学習は日本ではなくインドなどで先進的な事例が生まれてくると考えており、インドの教育はデジタルファーストになっていくと思っています。 インド政府の方針として、大学進学率の底上げがありインフラが必要となってくるため、デジタルファーストの新しい教育の形が求められていきます。 そんなデジタルファーストの国に対して、フィジカルのオペレーションが進んでいる日本とオンラインとを組み合わせて、楽しみながら展開していきたいと考えています。

今回レポートで取り上げることができなかった話もディスカッションされ、モデレーター・スピーカーの熱量の高いイベント開催となりました。 イベントにご参加いただいたみなさまありがとうございました。 また、今回日程が合わずに参加できなかった方も、今後様々なイベントを予定しておりますので、ぜひ今後も注目いただけますと幸いです。 また次回のイベントもお楽しみに！

2022年8月16日に「 BtoBスタートアップのネクストトレンド「第2回 Beyond SaaS ー産業を創るー」」を開催いたしましたので、その内容をレポートとしてご紹介したいと思います。

【イベントレポート】 BtoBスタートアップのネクストトレンド「第2回 Beyond SaaS ー産業を創るー」

<h2 id="h4ac34ea3e7">イベント概要</h2>ニューノーマルな生活やビジネスに対応するため、新たなサービスや商品も続々と誕生した2021年。今回は、次代をけん引する新ビジネスの中でも"BtoBスタートアップ"に焦点を当て、SaaSの新たな潮流や市場の可能性について4社で対談を実施しました。

福島広造

幸松大喜

狭間健志

<h2 id="h15a53a7927">今回はスタートアップ（SaaS）市場や各社の”SaaS+α”を軸にパネルディスカッションが行われました。</h2>総勢40名以上の方が参加したオンラインイベント。 スピーカーとなった3社の事業説明や各社が考える「BtoB SaaS」への想い、今後の展望など熱いディスカッションが行われました。 約1時間のイベントの中から要点のみ一部ピックアップしてお伝えいたします。

3社は共通して「初期事業がSaaSではなかった」。そんな各社がBtoB SaaSに参入したきっかけとは？

<h3 id="h9205b71082">「受発注事業から見えてきた新たな可能性に大きなニーズを感じた。」</h3>

創業当初からSaaSを出していく構想は元々ありました。 「ものがほしい」「金属部品が欲しい」というお客様に対して、オンラインで発注を受け、届けるというところをキャディが担ってきました。 しかし製造業にとって、「ものを作り」そして「ものを納める」ことは非常に本質的であり難しい体験で課題もあります。 SaaSでいいプロダクトを出す上ではドメイン特有の課題への理解の深さが大事。また、ユーザー目線で細部にこだわりをもってプロダクトを進化させることが大事です。 これまで自分たちが経験した課題に対してプロダクトを磨き、社内で実際にプロダクトを使用することで進化させることできる、という構想があるなかで受発注の事業をおこなってきました。 キャディも４年半この事業をおこなってきた中で辿り着いたのが、ニッチな領域ですが強いニーズのあった「図面データの管理・活用」でした。

このタイミングで「図面データの管理・活用」をプロダクト化してこうとなったきっかけや確信は何かあったのでしょうか？

1つ目は「エンタープライズ企業のお客様とのお取り組みの中で、継続的な接点を持ち続けることできること」。 受発注をおこなっている中で、様々な企業様との接点を持つことができました。特にエンタープライズ企業のお客様との取り組みを行い始めたのはここ1~2年。 会社として「図面データの活用」においては、エンタープライズ企業のお客様からニーズを獲得していきたいと考えていたので、この取り組みを進めることにしました。 2つ目は「社外に提供していく、という前提で社内ツールの開発を行ったこと」でした。 ファーストユーザーの自分たちが産業に入っていく中で課題が見え、プロダクトに落とし込んでいきました。

狭間さんはいかがでしょうか？

<h3 id="hd2242b8b85">お客様の課題解決が参入のきっかけに繋がった。</h3>

ハコベルは、マッチングのプラットフォームを起点としてはじまったので、当初はSaaSへの参入は考えていませんでした。 最初のお客様であるネスレ様の運送会社の1つとして、ハコベルを採用いただいておりました。

ハコベル導入前、他の運送会社とのやりとりはエクセルをメールで管理するというアナログシステムとなっており、情報連携の不備による配達ミスなどにより再配達のコストが発生していました。 「全てシステムで完結させたい」というネスレ様からの要望がきっかけとなり、ハコベルの仕組みだけを切り出したシステムを大手食品企業様やメーカー様へと広く展開していき、SaaS事業に参入することとなりました。

なるほど。それでは最後に吉兼さん。

<h3 id="hd380980c0e">toC事業で培ったノウハウを元に、toBへと参入。</h3>

我々は元々CtoC事業「CREW」がスタートでした。

20億円弱の資金調達を行った年に「コロナ」の影響を受け、トラクションは大幅に減少。しかし、資金調達を行っていたこともあり当時ある資本の中で事業を生み出し、成長させることが必要でした。 モビリティマーケットに参入した理由の1つに「位置情報をリアルタイムでとれる」ことへの技術的な革新が起こると考えていました。 同時にデリバリーマッケットもウォッチする中で、後発でUber Eatsと正面から戦うことは難しいものの、ここに自分達が培ってきた配車のアルゴリズムが生かせるのではないか？と考え進めてきました。 ただしSaaSを立ち上げることは、プロダクト開発にかかる時間も長く当時それだけにフォーカスするには厳しいものがありました。 そこで「SaaSで売っていく」のではなく、まずはコンサルやBPO（ビジネス・プロセス・アウトソーシング）として自分達ができることを元に業界の知見を貯めていくことにしました。 生産性改善やコスト削減をしていくということに対し、テクノロジーを使って課題解決をすることはできそうだったので、そこに対して自分たちが作ったものを売り込んでいきました。とはいえアナログに配車もするし配車管理も行っていました（笑） まずは事業として作り上げ、ノウハウをため、SaaSとして展開することでただの受託事業ではなくテクノロジーによってレバレッジを効かせることができる。 これがtoCからtoBへと参入した流れになります。

3社は共通して「SaaS+α」を事業の付加価値としている。 この+αへの想いや理由、そして生み出されている結果とは何か？

<h3 id="h87bdb3ef42">SaaS+BPOによって、ARPUと向き合い展開を広げていく。</h3>

吉兼

2019年SaaSの未来について考えたとき、今までと同じやり方だとどこかで限界を迎えてしまう可能性があると感じていました。 バーティカルSaaSの良いところはお客様一社一社のARPU（アープ）と向き合うことができることです。 さらにこのARPUはPLの中におけるインパクトがかなり大きい。半年~1年で10倍・100倍に繋げることもできます。 私たちはSaaS＋BPOでエンタープライズに対して、このARPUの成長に繋げていく戦い方を行ってきました。 例えば、ChargeSPOT（<a style="color:#1155cc" href="https://chargespot.jp/" target="_blank" rel="noopener noreferrer">https://chargespot.jp/</a>）です。 スタート当初、1県からスタートしましたが、すぐに実績を作ったことで、いまでは全国展開に繋げることができました。 そして今後においては、さらなるエンタープライズのPoCを狙いたいと考えております。 飲食店やコンビニなど、1店舗での成功体験が実証できればその後は全国展開の話がスムーズになります。 そのためこれまでのSaaSとは違った進め方となるため、ソフト開発を行う技術職だけではなくビジネスサイドの人がスタートアップでバリューを出す・活躍できるチャンスがあると考えております。

<h3 id="h490fcac01f">SaaS+オペレーションのサポートによって、お客様との関係値を築き、離れられない状態を作る。</h3>

狭間

私たちはSaaS+オペレーションのサポート、広い意味でのBPOであると考えています。 お客様や物流にとっての価値は「コストダウン」にあります。 ハコベルコネクトを使ってコストダウンに繋げないと、お客様に対しての価値にはならなく、事業としてのバリューにもなりません。 しかし現場にプロダクトを導入しただけでは使用されることはなかったので、お客様をサポートをすることでプロダクトの導入・活用へと進めてきました。 その結果コストダウンはもちろん、一緒に作り上げてきたという「組織間の関係値」を築き上げることができ、お客様の継続利用に繋がりました。 またそれだけでなく、3つの便益を得ることができました。 1つ目はシステムの最適化を行う中でお客様のオペレーションに詳しく理解したことで、食料や飲料メーカーでのシェア獲得に繋げることができたこと。 2つ目はプロダクト導入へのプロセスに時間をかけることで、「一緒に作り上げてきた」状態となり、お客様が離反しづらくなること。 そして3つ目はお客様の様々な課題解決をサポートしてきたことで、新たな課題が出てきたときに第一想起を得ることができたこと。

<h3 id="h2e9cb9b8d9">SaaS+バリューチェーンを”あえて”作ることで、参入障壁をより高くした。</h3>

幸松

私たちのSaaS+受発注領域については、事業ビジョンの背景もありました。 私たちはミッションとして「モノづくり産業のポテンシャルを解放する」を掲げています。 このために「製造業の根本的な課題を解決する」＝見積もり作成を楽にすることに留まらない、大きな価値を出していきたいと考えてきました。 そもそも製造業はコストを下げることが重要な産業ですが、「コストを下げる」といっても工数だけでなく原価を下げるやり方もあります。そして原価を下げることは経営インパクトも大きい。 見積もりが簡単に取れても、見積もりにある原材料が手に入らないと意味がないというお客様の声を受け、「正しい価格提示だけでなく、そのものが手に入る事業を作ろう」と思ったのが受発注事業の戦略転換のきっかけとなりました。 この結果、「調達・生産機能として、物を届けること」と「ソフト提供」という2つのビジネスが両軸で成長でき、相乗効果を生み出す構想ができました。 またあえてバリューチェーンを作ることで、品質保証するノウハウや海外での工場運営のノウハウを掛け算させ、システム開発だけだと難しい「参入障壁の高さ」を作りあげているといえます。

SaaS+αによって様々な価値を見出してきた各社。今後の展望とは？

<h3 id="hc9295beda6">TMSの拡張とPoCの全国展開</h3>

サービスとしては「TMS(配送管理)の拡張」です。 自社の配送ネットワーク上では使いやすいプロダクトになっているが、他社の配送ネットワークではまだ最適化ができていない状態です。 アグリゲーターとしての連携先を増やすことで、顧客の利便性を高めていきたいと考えております。 またビジネス全体としては、大手企業と始めているPoCを全国規模にしていきたいです。 これから1年は飲食・小売・医療の3領域をメインとし、2~3年はその他の産業に対してのインパクトを与えていきたいと考えています。 大手ECによる「当日配送への体制構築」や「倉庫をどこに設けるか」など様々な課題があります。 配送管理や配送員を集める、などコアな部分や入り込んだ課題を解決するようなソフトウェア開発をしていきたいです。 そして何にかを作ろうとしたらAzitに頼めば作ってくれる・そして質もコスパも良い、というイメージに繋がるようなブランディングも必要です。

<h3 id="hb898847c40">原価最適化への参入と利便性あるサービス展開</h3>

今後の展望は2つあります。 1つ目は原価最適化への参入です。すでに物流コストの「マッチング」「業務生産性」には入り込めているので、これからは「原価の最適化」を行いたいと考えています。 私たちの強みでもあるテクノロジーを活用した発注のアロケーション最適化に入り込んでいきます。 2つ目は配送・物流サービスの相互乗り入れをしっかり行うことで、お客様に利便性あるサービスを届けていくことです。 各社から様々なサービスが世の中にリリースされており、お客様目線に立つとサービスが多数あることで複雑化し、ベストな選択が何かわかりにくい状況になりつつあります。 そこで自社サービスだけでなく他社とも連携することで、お客様が最適なサービスの組み合わせを選択し、活用できる状態を作りたいと考えています。

<h3 id="ha4272ccbc6">アプリケーションの拡大とグローバル進出</h3>

今の事業の周辺機能へとアプリケーションの拡大を行いたいと考えています。 私たちが取り扱っている部品は、部品によって製造スケジュールが異なったり、原材料も異なります。 例えば、キャディを導入することで部品の製造効率や、図面設計時の予算などがわかるようなプロダクトなど、様々なプロダクトを出していきたいです。 また製造業はグローバルでも同様で、いいものを安く購入できるとお客様は喜んでくださるので日本にとどまらずアジア・米国進出も視野に入れています。 まだ会社としても成長中のため、やりたいことは様々です。

2022年6月28日に「 BtoBスタートアップのネクストトレンド『Beyond SaaS ー産業を創るー』」を開催いたしましたので、その内容をレポートとしてご紹介したいと思います。

Pick Up!

Hashtags

Latest Articles