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

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

サーバーサイドエンジニア (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 ー産業を創るー」

Love from Azit 編集部

株式会社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 ー産業を創るー』」を開催いたしましたので、その内容をレポートとしてご紹介したいと思います。

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

株式会社 Azit CTOの <a href="https://twitter.com/Pocket7878" target="_blank" rel="noopener noreferrer">@Pocket7878</a> です. 今回は、CREW Expressプロダクトの各領域で採用している技術スタックをご紹介します。 <h2 id="hebc0f8471a">APIサーバー</h2><ul><li>Rails 6.1.x</li><li>Ruby 3.1.x</li></ul>を利用しています。 サービスの開発当初は、WebフロントエンドもReactのコンポーネントをERBに乗せる形で提供していましたがフロントエンドの開発の生産性等を鑑みて、フロントエンドを切り話してAPIサーバーとしての機能提供に集中しています。 APIのスキーマはOpenAPIで定義しており、<a href="https://github.com/interagent/committee" target="_blank" rel="noopener noreferrer">commitee</a>で実装と定義の一致の検証をすると共に、Webフロントエンド側でAPIクライアントの自動生成に利用しています。 開発のプラクティスとしてTDDとDDDを採用しており、<a href="https://love-from.azit.co.jp/article/ddd" target="_blank" rel="noopener noreferrer">事業ドメインの整理の段階から戦略DDDに取りくんでいます</a> また、Rails上でドメイン構造を整理しつつ、静的型付けのある言語でより開発の信頼性や安定性を向上させるためにコアドメインを段階的にGoに移行することを計画しています。<h2 id="h3d909c6d1f">Webフロントエンド</h2>クライアントさんから利用していただく管理画面、弊社内のオペレータがカスタマーサポートの業務として利用する社内管理画面の開発では、ビジネスの変化に追従しつつ柔軟なUXを提供しやすいように<ul><li>Next.js</li><li>TypeScript</li></ul>を採用しています。 状態管理等にはRecoilとContextを利用しており、APIとの通信はOpenAPIからクライアントを自動生成し、SWRでラップしています。 CSSは、CSS ModuleとCSS in JSを併用していましたが、CSS in JSに寄せていく方針に決定して、新規コンポーネントはCSS in JSで書くと共に既存のコンポーネントの移行も進めています。<h2 id="h054fab72d6">モバイル</h2>配達パートナーから利用されるモバイルアプリケーションはAndroid, iOS両プラットフォームともにネイティブアプリで、Kotlin, Swift 100%でそれぞれ開発しています。 Android向けアプリはマルチモジュールのMVVMになっており、新規機能開発の際には既存の画面等もJetpack Composeでリライトを進めています。 iOS向けアプリはクリーンアーキテクチャ型のマルチバンドル構成で、UIのレイヤーではVIPERアーキテクチャを採用しており、新規機能開発の際には既存の画面をSwiftUIにリライトして開発しています。 VIPERアーキテクチャの採用判断はSwiftUIの登場する以前に判断したため、SwiftUIを前提に考えるとMVVMの方が適合しやすいため移行も検討しています。 Flutter等のクロスプラットフォームフレームワークの導入も開発初期に検討しましたが、サービス開発の時点でネイティブの専門性の高いメンバーが揃っていたこと、当時のフレームワークの知見の量や安定性とアプリケーションに求められる非機能要件などをふまえてネイティブで開発をする判断をしました。<h2 id="hb3c83ebaaa">最適化エンジン</h2>

CREW Expressでは、クライアントさんの配達リクエストをより少ない人数や稼動時間で効率よく配送するための各種最適化を提供する事で、クライアントさんのオペレーションや金銭的なコストを低下させる事を価値として提供しています。 そのような最適化を実施するエンジンはRustで記述しており、インフラはAWS Lambdaに乗せて最適化したい配送の問題定義をPOSTしてやると、最適化をした結果を返すようなプライベートAPIを公開しています。 APIのスキーマはOpenAPIで定義し、仕様の変更があると自動生成したクライアントコードがAPIサーバー側のリポジトリにPRとして発行されるようにしています。<h2 id="h1fc02ea273">インフラ</h2>インフラは全てAWS上に構築しており、スケールしやすい技術選定をすることで運用コストを下げるために、ECS Fargate, ElastiCache, Amazon Aurora, Amazon Lambda等を積極的に利用しています。<h3 id="hdc2da36b1a">位置情報管理</h3>AWS Automotive@Loft 第一回 モビリティサービスで登壇させていただいた時の資料:

配達パートナーの位置情報を記録する事でディスパッチの最適化に利用していますが、位置情報を稼動中の多くの配達パートナーの端末から受信して記録していくことが必要になります。 このシステムは、多くのトラフィックを受ける事になるためWriteに対してスケールする必要があり、またクライアントからの配達リクエストの量が増えた時にReadに対してもスケールが求められます。 そのような要件の位置情報の管理基盤を構築するにあたって、なるべく金銭的にも運用コスト的にも低コストで実現できる事を期待し、 Writeのスケールのために配達パートナーアプリからの書き込みの窓口にAmazon Kinesis Data Streamsを使用し、 位置情報の保存にはAmazon Location Serviceを利用しUberの<a href="https://h3geo.org/" target="_blank" rel="noopener noreferrer">H3</a>を利用してハッシュキーをつくってDynamoDBに索引をつくる事で高速な絞り込みを実現しています。<h3 id="hda9ca5f26d">構成管理</h3>構成管理にはTerraformを利用しています。 CI/CDにはGitHub Actionsを利用しており、PRを送るとfmtのチェックやvalidate、tflintの実行等の各チェックと共に、<a href="https://github.com/suzuki-shunsuke/tfcmt" target="_blank" rel="noopener noreferrer">tfcmt</a>でplanの結果がコメントされたり、マージされたら自動的にapplyされ結果がそのPRに投稿されるようにしており、GitHub上で構成の管理やレビューが完了するようにしています。<h2 id="h5e24d1c553">ログ分析・サーバー監視</h2>アプリケーションでエラーが発生してしまっている時の予兆にすばやく気がつき、その要因特定や解決をすばやく実施する事ができるよう、ログの集積・分析やAPMにはDataDogを利用しており、エラー発生時の要因分析、5xx系エラーの量の監視や外形監視等を実施しています。 また、アプリケーションレベルでのエラーの管理にはSentryを利用していて、新規のエラーが発生した場合にSlackに流れるようにして開発中やリリース後に即座に気がついて対応が可能なようにしています。<h2 id="ha214098e44">まとめ</h2>今回はCREW Expressプロダクトの各領域で採用している技術を紹介いたしました。 CREW Expressでは各領域毎に独立して最適な技術選定が可能となるように分離しながら日々改善を進めており、CREW Expressの技術的な改善を推進してくださる方を募集しています。 少しでも御興味をもってくださったら、是非お気軽に話を聞きにきてください!

CREW Expressプロダクトの各領域で採用している技術スタックをご紹介します。

CREW Expressを支える技術スタック

Sogame Masato

<h2 id="h5b7f0cf02b">当初はオフィスで口頭ベースで情報共有していた</h2>フルリモートになる前はコアタイムは設けていないにせよ、皆でオフィスに来て作業をして家に帰るというサイクルで日々の業務をしていました。 その頃は物理カンバンを用意して夕方デイリースタンドアップをチーム全体で実施して進捗やヘルプしてほしい事などを共有しながら進めていました。 また、PMとエンジニアの間の連携は、月曜日に前後半にわかれたスプリント計画の定例を開催し、 前半でPMからユーザーストーリーやバックログについて共有を受け、 後半でエンジニアがサブタスクに分解しながら見積を実施して、スプリントのスコープを決めてPMに共有して、物理カンバンに個別のタスクを付箋として貼っていく というサイクルで実施し、それ以外のプロジェクトの背景等は別途別のMTGや定例等で口頭で伝える形をとっていました。 この頃は、メンバーが日々オフィスで同期的に顔をあわせる頻度がたかく、またチームメンバーもあまり変動がないチームでした。<h2 id="he83ce89f4b">新規事業の立ちあげにチームのミッションが変化して発生した課題</h2>上述の口頭ベースで運用がされていたプロジェクトは、プロジェクトも開発されてから長く、チームも一定期間キープされつづけていたチームでした。 しかし、チームのプロジェクトが既存事業への改善や機能追加から新規事業のMVPファーストリリースを目ざす事に変化したために、不確実性やスコープ、仕様の変更等のリズムが従来チームが慣れていた頻度から大きく変化したために、様々な混乱が発生しました。 そのため、しっかりとプロジェクト自体への期待を周囲のステークホルダーと改めて揃え、プロジェクト全体を俯瞰で把握するための土台をつくらなければならないと感じ、インセプションデッキやユーザーストーリマッピングと共に要求仕様書として開発物のターゲットを体系的にまとめました。 その時の詳細は以下の記事にまとめてあります:

その際に、要求をどのようにして体系的にまとめるべきかを学び、要求仕様書をどう書くべきかについて以下の本をつかって勉強しました。 <a href="https://www.amazon.co.jp/%E6%94%B9%E8%A8%82%E7%AC%AC2%E7%89%88-%E5%85%A5%E9%96%80-%E5%AE%9F%E8%B7%B5-%E8%A6%81%E6%B1%82%E3%82%92%E4%BB%95%E6%A7%98%E5%8C%96%E3%81%99%E3%82%8B%E6%8A%80%E8%A1%93%E3%83%BB%E8%A1%A8%E7%8F%BE%E3%81%99%E3%82%8B%E6%8A%80%E8%A1%93-%E4%BB%95%E6%A7%98%E3%81%8C%E6%9B%B8%E3%81%91%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%81%8B/dp/4774142573/?_encoding=UTF8&amp;pd_rd_w=1volA&amp;content-id=amzn1.sym.79ec8dbb-a6ed-4b2c-b8a2-e2dc98848cba&amp;pf_rd_p=79ec8dbb-a6ed-4b2c-b8a2-e2dc98848cba&amp;pf_rd_r=1ZJ8EXNEVHP7WDDF1BZK&amp;pd_rd_wg=Cnrb1&amp;pd_rd_r=e131dc0e-a1a9-4051-bf15-1e60dd278279&amp;ref_=pd_gw_ci_mcx_mr_hp_atf_m" target="_blank" rel="noopener noreferrer"><img src="https://images.microcms-assets.io/assets/d4e25007543940f0849c6e5f6c46811d/d2c53fa005a44bc0ab322dc82ee67488/91rlese4pOL.jpg?w=211&amp;h=300" alt="[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?"></a>

そして、以下のような構造でユーザーストーリー単位でビジネスの背景と実現したい細かい挙動の仕様についてまとめはじめました。

# 要求カテゴリ1 ## 要求サブカテゴリ ### 要求: ○○が△△の時□□の時XXできるようにしたい - 理由: 要求が存在するビジネス的背景・届けたい価値 仕様 - [ ] ○○の時XXボタンを表示する - [ ] △△ページに、○○のxxx情報を表示する

<h2 id="hb462e80b8e">業務委託中心のフルリモートチームになって</h2>その後、さらに別の事業にチームのミッションが変化すると共に、チームメンバーも既存のメンバーから業務委託として時間帯や稼動時間がそれぞれ違うメンバー達を中心としたチームになりました。 また、社会情勢の影響もありオフィス勤務という形からフルリモートで働く形のチームへとも変化しました。 このように、既存の関係性や暗黙知が共有されていて同期的に働くメンバーというチームから、新たに会ったメンバーたちと非同期的に働くというチームへとチームの構造が大きな変化を迎えました。 そのため、チームの中での情報の共有のあり方も<ul><li>オンラインでの共有や読みあわせがしやすいよう文書を中心とし</li><li>各メンバーの稼動時間の違いの影響が低くなるようローコンテキストに</li><li>メンバーのいれかわりや新規追加等による在籍期間の差があっても、情報の差が発生しづらいように後から読み返しても記録性や理解がしやすいように</li></ul>という事を重視して、プロダクトチームだけでなく会社全体のナレッジを文章を中心として透明性高く管理するようになりました。<h3 id="h0dcf4373d8">プロジェクトの目的や背景の文書化・明確化</h3>要求仕様書のレベルでも、個別の機能のWhy, Whatだけではなくプロジェクト単位での事業上の意義やユーザーへの価値提供を伝えられるように明記するようにしました。 また、よりオーナーシップをもって開発を進められるようにするためには、決定した形だけでなく「なぜ他の形ではないのか」についても情報に簡単にアクセスできるようにする事が重要であると考え 要求分析の元となった議事録等についてもセクションとして追加し文書から参照しやすいように改善しました。 その後、現時点で開発中や分析中・検討中のものもふくめて、45個ほどプロジェクト要求仕様書を積みかさねてきて段階的に改善をしてきました。

<h2 id="h07b508bda2">実装方針の議論や認識擦りあわせ</h2><h3 id="h3aeba0e563">実装方法についての認識を揃える</h3>上述のように段階的に「要求」という観点から明確化してきた文書ですが、 実際にそれを実体化してユーザーに価値を届けるためには、それをソフトウェア上に実装する必要があります。 そして、ソフトウェア上に実装するという事自体もメンバー間での情報共有や認識の共有等も必要で複雑で難しい事です。 当初は要求仕様書の目的で共有していましたが、しだいに開発メンバーが要求仕様書の色々なところに開発中に検討している事や検討すべき事などについて「開発メモ」のような物を自主的に追加しはじめてくれていました。 そのように実装についても情報が共有されるようになった事で、開発メンバー間での開発に関する情報共有が成されるようになった一方で、 文書としてのパターンや構造がなくなってしまい、長期的な文書としての記録性については下ってしまったと感じました。 そのため、そのような情報を正式に構造として文書に組み込みたいと考え、実装設計というセクションを設けました。 また、このタイミングで要求仕様だけでなく実装設計等も含めて体系的に記載する文書であるという観点で名称をDesign Docに変更しました。 また、開発の実装方針等の「議論の過程」については議事録の一種であると考え、文書中に都度走り書きする形式ではなく、別の文書に書いておきリンクしておくようにしました。 そして、実装設計のセクションに議論を経てのAPIエンドポイントの設計やモデルに対する変化を記載するようになりました。 この記載が、JIRAのカンバンで管理するようになった開発のタスクの元となりチームでの作業の分担の土台となるようにしました。<h3 id="h1f65feefd4">課題: 実装と対応する要求仕様の関連を時間が立つと見失うよう事が発生した</h3>最初はPMが主に責任を持つ要求仕様のセクションと開発チームが責任を持つ実装設計は別のセクションにしていました

1 要求仕様 1-a ○○としてXXしたい 1-a-1 理由 1-a-2 仕様 2 実装設計 2-1 モデル 2-1-a [ActiveRecord, 新規] FooBar 2-2 API 2-2-a GET /foo/bar/baz

しかし、こうした事によってプロジェクト開始から時間がたつと「この実装設計はどの要求の実現のためにつかうやつなのか」という認識の齟齬が発生発生し、実装方針のミスや、レビュー時の負担が増えました。 責任を持って内容を管理するセクションを分けるという事と、実際に正しい実装を通してユーザーに価値が早く届くという事では、当然後者の事が大切です。 そのため、セクション設計を変更し

<ol><li>背景</li><li>モデリング<ol><li>システム関連図</li><li>ユースケース図</li><li>ドメインモデル図&amp;オブジェクト図</li><li>オブジェクト図</li><li>ドメインモデル図</li></ol></li><li>要求仕様書<ol><li>○○としてXXしたい</li><li>理由</li><li>仕様</li><li>実装設計</li></ol></li><li>4. 議事録・開発メモ</li></ol>

と、実装設計を各ユーザーストーリーのセクションの中に配置する事とし、実装社もレビュワーもどの要件がどのように実現されようとしているのか(いたのか)という把握がしやすいように改善しました。<h2 id="hd4d28df497">事業ドメインが複雑になって要求も複雑になった</h2>その後、様々なクライアントからのニーズを把握し重要な価値提供をするために機能を追加していくにつれて、プロダクトであつかう事業ドメインが段々と複雑になってきました

そのため、プロダクトに新たに追加しようとしている(もしくは既存の機能を変化させようとしている)部分がどのような立ち位置やユースケースを事業ドメイン上持つのかという事を要求分析の段階から意識する必要があると共に、チームメンバーとも意識を共有する必要があります。 そのため、sudoモデリングの図についてもDesign Docに乗せ、現在は以下のようなセクション構造になっています。<h2 id="h6650e53384">一つ一つのセクションや構造について追加する意義を考えながら段階的に改善する</h2>このように、Azitのプロダクトチームでプロジェクトの情報共有をするための文書は、直面した課題に対してアプローチするために段階的に育ててきました。 他社で同様にDesignDocと呼ばれている文書の中にはまだ、今現在の弊社のDesignDocには設置されていないセクションもあります。 もちろん、他社のテンプレートをそのまま持ってくるという方法もあるとおもいますが、チームの中でただ盲目的に「セクションに内容を書くという事になっているからとりあず書く」というような文書化する事自体が目的化してしまう事は避けたいと考えているため、文書の構造をすばやく改善していく事を重視し、一つ一つのセクションや構造について「なぜここにそのセクションがあるのか」をきちんと理解した状態で文書を育てていきたいと考えています。

フルリモートになる前はコアタイムは設けていないにせよ、皆でオフィスに来て作業をして家に帰るというサイクルで日々の業務をしていました。    その頃は物理カンバンを用意して夕方デイリースタンドアップをチーム全体で実施して進捗やヘルプしてほしい事などを共有しながら進めていました。

フルリモートチームで開発を円滑に進めるための要求仕様書の進化の変遷

株式会社 Azit CTOの <a href="https://twitter.com/Pocket7878" target="_blank" rel="noopener noreferrer">@Pocket7878</a> です. 今回は、CREW Expressのプロダクト開発チームで複雑な事業ドメインをあつかうプロダクトの開発をするためにチームで実施している取り組みを紹介いたします。<h2 id="h16abda21ee">プロダクトの事業ドメイン</h2>CREW Expressは、荷物の配送を実施してくださる配達パートナーと、配送の依頼をしてくださるクライアントという2つの種類のユーザーを扱うサービスです。 そして、配達パートナーさんは:<ul><li>ギグワーカーとして単発の案件を実施してくださる方々</li><li>私たちと連携してクライアントさん専属のシフトに入ってくださる方々</li><li>クライアントさんが直接管理しておられ我々のシステムを通して稼動している方々</li></ul>と、主に3種類のグループに大別されます。 また、クライアントさんも:<ul><li>個人として利用される方</li><li>企業アカウントと読んでいる企業単位のグループに所属し権限管理等をしながら利用される方</li></ul>と、2種類のクライアントの方々がいらっしゃいます。 また、配送については:<ul><li>クライアントさんが自社で管理されている方々と弊社からの専属の方々両方に送りたいといった場合や、逆に自社で管理されておられる方のみに送りたいといった、「誰に送りたいか」といったグループでのフィルタリング</li><li>「冷蔵可能」のような特定のスキルを持った方にだけ送りたいといった配達パートナーの方のスキルでのフィルタリング</li></ul>などの様々なフィルタリングであったり、 グループに応じての優先度や最適なルートなど、どの配達パートナーの方にどの案件をやってもらうべきかのディスパッチの部分であったり 配送の業務は、1箇所で複数の荷物をまとめて集荷し複数箇所に届ける場合や、配達の時間帯をしていただいてその時間に間に合うように逆算してマッチングを開始するであったり、自社配達員の払底に応じて一時的にリクエストをバッファリングしたりといった、リクエストの発行タイミングであったり..etc と、配送の業務をとりまく軸だけでも様々な範囲と種類の情報をプロダクトで扱います。 そして、まだまだ事業で価値を提供できる領域を広げていこうとしています。 <h2 id="h877723393c">プロダクトのドメイン領域をコンテキストマップで分析</h2>

上述のように、CREW Expressは非常に多岐にわたる領域をとりあつかっています。 そのため、プロダクトで取り扱う領域の全体がどのようになっているかを俯瞰で把握して意識しておく事は開発において重要です。 そのため、チームでプロダクトのドメインの領域をコンテキストマップをつくりながら分析を行いました。<h2 id="h9780270f43">プログラムにドメインの構造を反映するためにRails WayからDDDに段階的に移行</h2><h3 id="h872b7fafa3">開発当初から意識していた事</h3>スタートアップは常に速度との戦いです、そのためには日々素早く仮説検証を回す必要があります。特にサービス初期は事業の根幹の仮説を確かめるために慣れた技術で素早く開発をする必要があります。 そのため、弊社で事業開始時点で社内の技術スタックとして一番慣れていたRailsで開発を行ってきました。 一方で、当初から意識していたのはプロダクトの規模が広がるにつれて発生する課題を避けるために以下の2つは特に意識して開発をすすめていました<ul><li>TDDを実践し、ユニットテストやリクエストテストのカバレッジを高く保つ</li><li>RailsのActiveRecordのみにロジックを書きすぎず、PORO (Plain Old Ruby Object)でビジネスのロジックやドメイン上のロジックを記載する</li></ul><h2 id="h1afdd90196">プロダクトの拡大に応じて、よりDDD的な構造に移行</h2><h3 id="h634b0eae63">モデルをコンテキストに分割整理する</h3>そのように開発を進めていたプロダクトですが、徐々に対応領域を広げていくにともなってよりPOROにも構造が必要になってきました。そのため、上記のコンテキストマップで整理した構造にもとづいて、models以下に一律で格納されていたモデルを、○○_contextといったコンテキストマップに対応したネームスペースに整理をしはじめています。 <h3 id="h1a07eba474">UseCaseやQueryの層をつくり、ドメインモデルと分離する</h3>さらに、コンテキストで分離するのみでなくPOROで書かれているモデルを、ドメインのユースケースの表現のためのUseCase、表示用のデータを取りだすためにドメインの集約とは異なる切り口でデータを取得するQueryと分類し、use_casesフォルダとqueriesフォルダをつくり対応する分類へと整理をはじめています。 上記のようにすることで、ドメインモデルをあらわす処理とその他のロジックの部分との整理がすすみ、機能開発の時の新規追加や変更の箇所見通しが良くなり、テスタビリティもさらに向上したように感じます。 最初からUseCaseやQueryの層を作っておく必要はないとおもいますが、プロダクトをつくっていく中で、どの部分は意図的にRails Wayを外れるかというのを日々チームでのふりかえり会などを通して議論をしながら今の形になっています。 <h2 id="h164f7fb9b4">プロダクトを上での共通の技術的な知識を持つために読書会を開催</h2>上記のように開発をすすめているチームですが、今のメンバーの知見を揃えるためであったり、将来の新しいメンバーにより良く技術的なプラクティスや知見を伝えるために読書会も随時開催しています。 今のところ、参加メンバーが全員すでに読んだことがある本をおさらいで読みながらチームで議論しておきたい部分を持ち寄って議論をしています。上記のコンテキストマップもその中の取組みの一つとして実施したものになります。 今までに読んだ本、これから読む予定の本は以下のものになります <a href="https://www.amazon.co.jp/%E3%83%86%E3%82%B9%E3%83%88%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA-Kent-Beck/dp/4274217884" target="_blank" rel="noopener noreferrer"><img src="https://images.microcms-assets.io/assets/d4e25007543940f0849c6e5f6c46811d/e4423f99adc543beba6ea2bbd02b8df3/51qh3suMX0L.jpg?w=150&amp;h=213" alt="テスト駆動開発"></a> <a href="https://www.amazon.co.jp/%E5%AE%9F%E8%B7%B5%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88-%E3%83%B4%E3%82%A1%E3%83%BC%E3%83%B3%E3%83%BB%E3%83%B4%E3%82%A1%E3%83%BC%E3%83%8E%E3%83%B3-ebook/dp/B00UX9VJGW/ref=sr_1_1?crid=3MHOUKA7SJ89X&amp;keywords=%E5%AE%9F%E8%B7%B5%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88&amp;qid=1664169705&amp;s=books&amp;sprefix=%E5%AE%9F%E8%B7%B5%2Cstripbooks%2C189&amp;sr=1-1" target="_blank" rel="noopener noreferrer"><img src="https://images.microcms-assets.io/assets/d4e25007543940f0849c6e5f6c46811d/517258295248450a9e4c842cb464d2a3/619Gh1s721L._SX260_.jpg?w=150&amp;h=189" alt="実践ドメイン駆動設計"></a> <a href="https://www.amazon.co.jp/%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2%E3%83%BB%E3%83%90%E3%82%A4%E3%83%BB%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3-Dan-Bergh-Johnsson-ebook/dp/B09F697K2V/ref=sr_1_1?keywords=%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2%E3%83%90%E3%82%A4%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3&amp;qid=1664169619&amp;s=books&amp;sprefix=%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2%E3%83%90%E3%82%A4%2Cstripbooks%2C189&amp;sr=1-1" target="_blank" rel="noopener noreferrer"><img src="https://images.microcms-assets.io/assets/d4e25007543940f0849c6e5f6c46811d/8b49e59547994bcb9f1a456401683a17/512NUC5YzPL._SX260_.jpg?w=150&amp;h=193" alt="セキュア・バイ・デザイン: 安全なソフトウェア設計"></a> <a href="https://www.amazon.co.jp/%E3%83%A2%E3%83%8E%E3%83%AA%E3%82%B9%E3%81%8B%E3%82%89%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%B8-%E2%80%95%E3%83%A2%E3%83%8E%E3%83%AA%E3%82%B9%E3%82%92%E9%80%B2%E5%8C%96%E3%81%95%E3%81%9B%E3%82%8B%E5%AE%9F%E8%B7%B5%E7%A7%BB%E8%A1%8C%E3%82%AC%E3%82%A4%E3%83%89-Sam-Newman/dp/4873119316/ref=sr_1_1?keywords=%E3%83%A2%E3%83%8E%E3%83%AA%E3%82%B9%E3%81%8B%E3%82%89%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%B8&amp;qid=1664169653&amp;s=books&amp;sprefix=%E3%83%A2%E3%83%8E%E3%83%AA%E3%82%B9%E3%81%8B%E3%82%89%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%2Cstripbooks%2C186&amp;sr=1-1" target="_blank" rel="noopener noreferrer"><img src="https://images.microcms-assets.io/assets/d4e25007543940f0849c6e5f6c46811d/01fe2fddd7164aaaa01e4311f02bb1cb/51J5zsk3GTL._SX218_BO1%2C204%2C203%2C200_QL40_ML2_.jpg?w=150&amp;h=192" alt="モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド"></a> <h2 id="h02d9b52fc6">sudoモデリングを活用しながら要求分析を実施</h2>すでにある程度複雑なドメインに、さらに日々機能を追加していく時にきちんとドメインにたいする知識を育てていくためには、1つ1つの機能がドメインにたいしてどのような変化をもたらすのかを意識しながら積みあげていく必要があります。 そのために、弊社の要求分析ではDDDの第一人者である松岡さんが考案されていた分析手法であるsudoモデリング

を元に、要件をつくにあたって<ul><li>システム関連図 (s)</li><li>ユースケース図 (u)</li><li>ドメインモデル図 (d)</li><li>オブジェクト図 (o)</li></ul>を、ステークホルダー (クライアントであったり、サクセスやBizDev,セールス等の他チームであったり)と対話をしながら分析し、要件の解像度を高めながら分析を実施しています。 以前から要求仕様書とという形での要求の分析はチームに導入していました:<ul><li><a href="https://poketo7878-dev.hatenablog.com/entry/20201228/1609135015#%E8%A6%81%E6%B1%82%E4%BB%95%E6%A7%98%E6%9B%B8" target="_blank" rel="noopener noreferrer">2020年個人としてふりかえり - Let's write β</a></li><li><a href="https://poketo7878-dev.hatenablog.com/entry/20211018/1634568086" target="_blank" rel="noopener noreferrer">要求分析の時にやってる事・意識してる事棚おろし - Let's write β</a></li></ul>が、さらにここにsudoモデリングも付与する事でよりドメインの目線での解像度が高まったように感じています。 <h2 id="h3af0f58d04">よりドメインの知識を扱いやすくするため、Goへの移行を計画中</h2>上記のように、ドメインの知識やDDDの知識を深めながら日々開発しているプロダクトですが、よりドメインの知識を安定して表現しやすく、かつ生産性高く開発をするためにRailsからGoに移行する事を現在計画しています。 Railsの枠組みでは表現しづらい部分を表現しやすく、また静的型付けでドメインの条件などをチェックしやすい技術に移行したいという事は事業当初から考えており、その中で<ul><li>Rust</li><li>Kotlin</li><li>Go</li></ul>の候補にしぼって、移行先を検討していました。 その中で実際にDDD的な書き方をそれぞれの言語で実践してみて、どのように書きやすいのかを実際にチームの皆で比較してみながら、今後の事業の計画や様々な市場環境などを含めて総合的に判断してGoを選定しました。 (Rustは最適化エンジンのあたりでつかっているので、そのあたりはまた紹介します) <h2 id="ha214098e44">まとめ</h2>今回の記事では、CREW Expressのプロダクトをとりまく事業ドメインを紹介し、複雑な事業ドメインに対処するためにバックエンドの開発チームで実施してきた事と今後の展望にフォーカスして紹介いたしました。 このようにCREW ExpressのバックエンドチームはシンプルなCRUDに落しづらい複雑な事業ドメインと向きあうために日々プロダクトについて議論をしながら開発を進めています。

CREW Expressのプロダクト開発チームで複雑な事業ドメインをあつかうプロダクトの開発をするためにチームで実施している取り組みを紹介いたします。