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

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

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

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

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

Sogame Masato

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

<p>その際に、要求をどのようにして体系的にまとめるべきかを学び、要求仕様書をどう書くべきかについて以下の本をつかって勉強しました。<br><br><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></p>

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

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

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

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

<p><span style="color:#222222">1 要求仕様</span><br><span style="color:#222222">1-a ○○としてXXしたい</span><br><span style="color:#222222">1-a-1 理由</span><br><span style="color:#222222">1-a-2 仕様</span><br><span style="color:#222222">2 実装設計</span><br><span style="color:#222222">2-1 モデル</span><br><span style="color:#222222">2-1-a [ActiveRecord, 新規] FooBar</span><br><span style="color:#222222">2-2 API</span><br><span style="color:#222222">2-2-a GET /foo/bar/baz</span></p>

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

<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><p><br></p>

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

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

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

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

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

<p>上述のように、CREW Expressは非常に多岐にわたる領域をとりあつかっています。<br>そのため、<strong>プロダクトで取り扱う領域の全体がどのようになっているかを俯瞰で把握して意識しておく事は開発において重要</strong>です。<br>そのため、チームでプロダクトのドメインの領域をコンテキストマップをつくりながら分析を行いました。</p><h2 id="h9780270f43">プログラムにドメインの構造を反映するためにRails WayからDDDに段階的に移行</h2><h3 id="h872b7fafa3">開発当初から意識していた事</h3><p>スタートアップは常に速度との戦いです、そのためには日々素早く仮説検証を回す必要があります。特にサービス初期は事業の根幹の仮説を確かめるために慣れた技術で素早く開発をする必要があります。<br>そのため、弊社で事業開始時点で社内の技術スタックとして一番慣れていたRailsで開発を行ってきました。<br>一方で、当初から意識していたのはプロダクトの規模が広がるにつれて発生する課題を避けるために以下の2つは特に意識して開発をすすめていました</p><ul><li>TDDを実践し、ユニットテストやリクエストテストのカバレッジを高く保つ</li><li>RailsのActiveRecordのみにロジックを書きすぎず、PORO (Plain Old Ruby Object)でビジネスのロジックやドメイン上のロジックを記載する</li></ul><h2 id="h1afdd90196">プロダクトの拡大に応じて、よりDDD的な構造に移行</h2><h3 id="h634b0eae63">モデルをコンテキストに分割整理する</h3><p>そのように開発を進めていたプロダクトですが、徐々に対応領域を広げていくにともなってよりPOROにも構造が必要になってきました。そのため、上記のコンテキストマップで整理した構造にもとづいて、models以下に一律で格納されていたモデルを、○○_contextといったコンテキストマップに対応したネームスペースに整理をしはじめています。<br></p><h3 id="h1a07eba474">UseCaseやQueryの層をつくり、ドメインモデルと分離する</h3><p>さらに、コンテキストで分離するのみでなくPOROで書かれているモデルを、<strong>ドメインのユースケースの表現のためのUseCase</strong>、表示用のデータを取りだすために<strong>ドメインの集約とは異なる切り口でデータを取得するQuery</strong>と分類し、use_casesフォルダとqueriesフォルダをつくり対応する分類へと整理をはじめています。<br>上記のようにすることで、ドメインモデルをあらわす処理とその他のロジックの部分との整理がすすみ、機能開発の時の新規追加や変更の箇所見通しが良くなり、テスタビリティもさらに向上したように感じます。<br>最初からUseCaseやQueryの層を作っておく必要はないとおもいますが、プロダクトをつくっていく中で、どの部分は意図的にRails Wayを外れるかというのを日々チームでのふりかえり会などを通して議論をしながら今の形になっています。<br></p><h2 id="h164f7fb9b4">プロダクトを上での共通の技術的な知識を持つために読書会を開催</h2><p>上記のように開発をすすめているチームですが、今のメンバーの知見を揃えるためであったり、将来の新しいメンバーにより良く技術的なプラクティスや知見を伝えるために読書会も随時開催しています。<br>今のところ、参加メンバーが全員すでに読んだことがある本をおさらいで読みながらチームで議論しておきたい部分を持ち寄って議論をしています。上記のコンテキストマップもその中の取組みの一つとして実施したものになります。<br>今までに読んだ本、これから読む予定の本は以下のものになります<br><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> <br><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><br></p><h2 id="h02d9b52fc6">sudoモデリングを活用しながら要求分析を実施</h2><p>すでにある程度複雑なドメインに、さらに日々機能を追加していく時にきちんとドメインにたいする知識を育てていくためには、<strong>1つ1つの機能がドメインにたいしてどのような変化をもたらすのかを意識しながら積みあげていく</strong>必要があります。<br>そのために、弊社の要求分析ではDDDの第一人者である松岡さんが考案されていた分析手法であるsudoモデリング</p>

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

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