<h2 id="h8d027c8ed3">はじめに</h2>「午前中の打ち合わせで出たフィードバック、午後にはデモに反映できますか？」 従来の開発プロセスでは、この問いに「はい」と答えられる人は少ないでしょう。しかし、AI駆動開発ツール「Claude Code」を活用することで、コーディング経験がほぼない私でも、これを日常的に実現できるようになりました。 本記事では、株式会社Azitの新規プロダクト「ForecastX」のデモ開発において、PdMである私がClaude Codeを用いてどのようにAI駆動開発を実践したか、その具体的なプロセスと成果をお伝えします。

<h2 id="hee50120e89">筆者について</h2>株式会社AzitでPdM（プロダクトマネージャー）を務める佐々木寅彦です。物流・サプライチェーン領域のAIソリューション開発に携わっています。 重要な前提として、私にはコーディング経験がほぼありません。HTMLを少し触った程度で、本格的なプログラミングは未経験。そんな私が、React + TypeScriptで構築された本格的なデモアプリケーションを開発・運用することになりました。

<h2 id="h1836afb25c">プロジェクトの背景</h2><h3 id="heb12d85afa">ForecastXとは</h3>ForecastXは、Azitが開発中の需給予測プラットフォームです。従来の需要予測システムは導入費用が数千万円規模、開発期間も半年以上かかることが一般的でした。ForecastXは、低価格かつ最短1ヶ月での導入を目指しています。 <h3 id="h8c3e5e8516">なぜPdMがデモ開発を行うことになったのか</h3>新規プロダクトの立ち上げ期において、最も重要なのは「顧客が本当に求めているものは何か」を素早く検証することです。しかし、従来のプロセスでは：<ol><li>PdMが顧客ヒアリングで要件を整理</li><li>エンジニアに開発を依頼</li><li>数週間〜数ヶ月後にデモが完成</li><li>顧客に見せてフィードバックを得る</li><li>再度エンジニアに修正を依頼...</li></ol>このサイクルでは、1回のフィードバックループに数週間かかることも珍しくありません。 そこで私は、PdM自身がデモ開発を行うというアプローチを取ることにしました。顧客と直接対話している人間が、その場で得た知見をすぐにプロダクトに反映できれば、圧倒的なスピードで検証サイクルを回せるはずだと考えたのです。

<h2 id="ha777a68998">プロジェクト概要 - 何を作ったのか</h2>今回開発したのは、ForecastXを中心としたサプライチェーン管理の統合プラットフォームのデモです。 <ul><li>規模:<ul><li>6つのプロダクト: 需要予測、在庫計画、販売計画、補充計画、生産計画、発注計画</li><li>各プロダクト6つの機能: 計画、分析、アラート、ダッシュボード、カスタムレポート、データ管理/連携</li><li>合計36ページ: 6プロダクト × 6機能</li></ul></li><li>技術スタック:<ul><li>React + TypeScript（Claude Codeからの提案）</li><li>サンプルデータもすべてClaude Codeが生成</li></ul></li><li>開発期間: 約2週間（その後は必要に応じて日次単位で修正開発）</li></ul>

<h2 id="hf70eef0964">Claude Codeとの出会い</h2><h3 id="hc82c6a834c">最初の一歩</h3>Claude Codeを使い始めた当初、正直なところ半信半疑でした。「本当にコードが書けない人間でも使えるのか？」という疑問がありました。 しかし、実際に使ってみると、その印象は大きく変わりました。Claude Codeは単にコードを生成するだけでなく、私の意図を理解し、適切な実装方針を提案してくれるのです。 例えば、「需要予測のグラフを表示したい」と伝えると、単にコードを出力するのではなく：<ul><li>どのようなライブラリを使うべきか</li><li>データ構造はどうあるべきか</li><li>ユーザビリティの観点から何を考慮すべきか</li></ul>といった点まで含めて提案してくれました。 <h3 id="h57d0c452d0">初期構築から運用フェーズへ</h3>最初のデモ構築には約2週間かかりました。React + TypeScriptの環境構築から、基本的なUIコンポーネントの作成、データの可視化機能の実装まで、一通りの機能を揃えるのにそれなりの時間が必要でした。 しかし、本当の価値はここからでした。

<h2 id="hd77629fd89">「当日アップデート」という新常識</h2><h3 id="h3f6da54f00">最短数時間での修正サイクル</h3>初期構築後、私の開発スタイルは劇的に変化しました。顧客やステークホルダーからフィードバックをもらったら、最短数時間、遅くても1営業日以内で修正を完了できるようになったのです。 具体的なシーンを挙げると： 午前の打ち合わせ→午後には反映 顧客との午前中のミーティングで「この画面にアラート機能があると便利」という声をいただく。午後にはClaude Codeでアラート機能を実装することができる。 Slackでのフィードバック→当日対応 社内からSlackで「グラフの色をもう少し見やすくしてほしい」という依頼が来る。その日のうちにUIを調整し、「確認お願いします」と返信できる。 このスピード感は、周囲からも驚かれることが多いです。「え、もう対応できたの？」「こんな短時間でPDCAを回して高速でデモ改修できるんですね」といった反応をいただきます。 <h3 id="h4f2f1d7f93">エンプラ顧客への提案を変えた「個社別カスタマイズ」</h3>AI駆動開発の真価が発揮されたのは、エンタープライズ顧客への提案時でした。 物流・製造業の顧客は、それぞれ固有のニーズを持っています。ある企業は製品の保管期限管理を重視し、別の企業は特殊なアラート機能を求める。汎用的なデモでは、こうした個別のニーズに応えることができません。 従来であれば、個社ごとにデモをカスタマイズするには相応の開発工数が必要でした。しかし、Claude Codeを活用することで、私はFDE（Forward Deployed Engineer）的な動きを1人で実現できるようになりました。 FDE的な動きとは：<ol><li>顧客の現場に入り込み、ヒアリングを行う</li><li>要件を整理し、プロダクトへの落とし込みを検討する</li><li>短期間でデモをカスタマイズし、すぐに顧客に見せる</li></ol>特に3番目のステップが重要です。従来は「汎用的なデモをお見せして、導入時にカスタマイズします」という説明になりがちでしたが、私は各社向けにFDE業務を行った後の、最適化されたプロダクトをデモとして共有できるようになりました。 具体的なカスタマイズ例：<ul><li>実際の拠点名・商品名の反映: 顧客が実際に使用している拠点名（例：「東京倉庫」「大阪倉庫」）や商品名をデモに反映。汎用的な「拠点A」「商品1」ではなく、顧客にとってリアリティのある画面を見せられる</li><li>業務フローに合わせた機能追加: 保管期限の表示、特定条件でのアラート発火など、各社の業務フローに合わせた機能を追加</li><li>UIの調整: 顧客が重視する情報を目立つ位置に配置するなど、見せ方の最適化</li></ul>これにより、提案時に「これは御社向けにカスタマイズしたデモです」と言えるようになりました。汎用デモを見せて「実際の導入時にはカスタマイズします」と説明するのとは、顧客へのインパクトがまったく違います。

<h2 id="hf70a276f7d">開発プロセスの実際</h2><h3 id="ha7e770a1c4">日常的なワークフロー</h3>現在の私の開発ワークフローは以下のようになっています：<ol><li>要件の整理<ul><li>顧客フィードバック、社内からの要望を収集</li><li>優先度を判断し、対応する項目を決定</li></ul></li><li>Claude Codeへの指示<ul><li>実現したいことを自然言語で説明</li><li>必要に応じて画面のスクリーンショットや参考資料を共有</li></ul></li><li>コードの生成と適用<ul><li>Claude Codeが生成したコードを確認</li><li>意図通りの実装になっているかをプレビューで確認</li></ul></li><li>動作確認とフィードバック<ul><li>実際にデモを動かして確認</li><li>問題があればClaude Codeに修正を依頼</li></ul></li><li>デプロイ<ul><li>GitHubへのプッシュ</li><li>本番環境への反映</li></ul></li></ol>このサイクルを1日に何度も回すことで、高速なイテレーションを実現しています。 <h3 id="h1ff5ba6ccc">学んだこと：AI駆動開発のコツ</h3>約2ヶ月間の開発を通じて、いくつかのコツを学びました： 1. 具体的に伝える：「かっこいいダッシュボードを作って」ではなく、「売上推移を折れ線グラフで表示し、前年同期比を並べて表示したい」、などと具体的に伝える。 2. 段階的に進める：一度に大きな変更を求めるのではなく、小さな単位で確認しながら進める。 3. エラーを恐れない：エラーが出ても、そのメッセージをClaude Codeに伝えれば、原因と解決策を提示してくれる。 4. 既存コードの理解を深める：Claude Codeに「このファイルの構造を説明して」と聞くことで、自分が書いていないコードも理解できるようになる。 5. 定期的なコードの見直し： Claude Codeでは、ほぼコードを見ずに開発することも可能な一方で、不要なコードの削除漏れなどが起きても気づきずらいため、定期的に「コードの見直し（リファクタリング）」を指示することで、開発を続けやすい環境を維持することができる。

<h2 id="h41126f20c5">成果と効果</h2><h3 id="hda3cb31331">定量的な成果</h3><ul><li>初期デモ構築: 約2週間</li><li>機能追加・修正: 最短数時間〜1営業日</li><li>開発した画面数: 6プロダクト × 複数画面</li><li>エンジニア工数: ほぼゼロ（レビューのみ）</li></ul><h3 id="hef743a7640">定性的な効果</h3>1. 顧客との対話の質が向上：「次回の打ち合わせまでに反映します」ではなく「明日には反映します」と言えることで、顧客との信頼関係が深まった。 2. 仮説検証のスピードアップ：「この機能は本当に必要か？」という問いに対して、実際に作って見せることで素早く検証できるようになった。 3. PdMとしての視野の拡大：技術的な制約や実装の難易度を肌で感じることで、より現実的な要件定義ができるようになった。 4. エンジニアリソースの有効活用：デモレベルの開発はPdMが担当し、エンジニアは本番プロダクトの開発に集中できる体制を構築できた。

<h2 id="h9be0c3393d">おわりに</h2>「コーディング未経験のPdMがデモ開発を行う」というのは、少し前までは現実的ではありませんでした。しかし、Claude Codeのようなツールの登場により、技術とビジネスの境界は確実に薄くなっています。 特に重要なのは、「2週間で作れる」ことではなく、「当日アップデートできる」ことです。この圧倒的なスピード感があるからこそ、顧客との対話を通じて本当に価値のあるプロダクトを作り上げることができます。 もちろん、AI駆動開発は万能ではありません。複雑なビジネスロジックや、高度なパフォーマンス最適化が必要な場面では、専門のエンジニアの力が不可欠です。しかし、プロダクトの初期検証やデモ開発においては、PdMが自ら手を動かすことで得られる価値は計り知れません。 この記事が、同じようにAI駆動開発に興味を持っている方、あるいは「技術がわからないから...」と躊躇している非エンジニアの方の参考になれば幸いです。

<h2 id="hb953b41752">株式会社Azitについて</h2>Azitは「日本のインフラを新しい時代へと紡ぐ」をミッションに、物流・サプライチェーン領域に特化したAIソリューションを提供しています。需給予測プラットフォーム「ForecastX」、AI配車プラットフォーム「DeliveryX」などを通じて、サプライチェーン全体の最適化を目指しています。

BizDev｜ストラテジック・パートナー

コーディング未経験のPdMが、プロダクトデモの「当日アップデート」を実現した話

Torahiko Sasaki

こんにちは！ 今年の2月に入社したばかり、Azit新人エンジニアの斉藤です！ （といっても新卒じゃなくて転職なので、他社でのエンジニア経験は10年くらいあります✌️） AzitではDeliveryXのバックエンド開発とフロント開発の両方を担当してます。 普通の会社ならバックエンドならバックエンド、フロントならフロントだけと決められちゃいそうなところですが、ありがたいことに両方とも担当させて頂いてます。 自分は飽き性なので、色々と幅広い開発ができるのは嬉しい限りです。（感謝！）

<h2 id="h8d027c8ed3">はじめに</h2>で、今回は何の話かというと！ AzitのメインプロダクトであるDeliveryXに２段階認証の機能を追加したのです！ ＼すごーい！／ というわけで今回の記事では、なぜ２段階認証の機能を開発したのか？や、開発するの中で工夫したポイントなどについて書いていこうと思います〜

<h2 id="h0b179e5764">２段階認証とは？</h2>その前に、２段階認証とは？についても軽く説明しておきます。 （この記事を読んでる人は多分みんなリテラシー高いので知ってるとは思いますが、、念の為！） ２段階認証とは、「認証を２段階にすること」です！（そのまま過ぎますねｗ） そもそも認証とは、「あなたは誰？」ってやつです。 一番よくあるパターンが、メールアドレスとパスワードを入力するアレですね。 あれで１認証となります。 ので、認証が２段階ということは「メールアドレスとパスワードだけじゃまだ本物か怪しい！もう一つ認証をクリアしてもらうぜ！」ってことなんです。 例えば事前に登録した合言葉を入力させたり、免許証を提示したり、指紋を確認したりとかです。 そうすることで「よし！お前さんが本物だと信じよう！」ってなるわけですね。 最近は不正ログインも話題ですし、セキュリティの重要性はますます高まってますよね。 Azitとしても「今どき２段階認証がないサービスはセキュリティ的によろしくないぞ！ユーザー様にも不安を与えちゃうぞ！良くない！」ってことで、今回２段階認証を開発することになったわけであります。 もちろん実際にユーザー様から「２段階認証欲しい！」という声も頂いてました。

<h2 id="he58c0cb222">設計について考える</h2>２段階認証、なかなか大きい開発だと思うので新人エンジニアの自分には流石に担当回ってこないかな〜？と思いきや、なんと回ってきた！嬉しい！ いやーこれがスタートアップの良いところですわ。 最初から色々と大きい仕事がやりたいエンジニアの人！Azitおすすめですよ！（さりげなく宣伝） で、上述したように２段階認証の方式にもいくつか種類がありまして。 どういう方式にするかユーザー様の意見も聞きながら検討した結果、最終的にはメールを使う方式にしました。 メールに認証コードを送信して、それをログイン時に入力してもらう方式です。 メールであれば既存ユーザーも必ず登録している情報でしたし、かなり一般的な方法なのでユーザーにとっても使いやすく、開発のコスパも良いだろうと。 １点悩んだポイントとしては、メールに認証コードを送信するのではなく、マジックリンクを送信して、マジックリンクを踏むことで自動的にログインする方式もアリだなと考えてました。 マジックリンク方式だと、認証コードを入力する手間を省けるんですね。 ただ、マジックリンク方式も悪くはなかったのですが、認証コードの方が一般的に広く受け入れられている概念なのでユーザー様が混乱しにくいかな、というところで最終的に認証コード方式を採用しました。 DeliveryXはエンプラサービスですし、あまりITに詳しくない人でもスムーズに使えることを優先した感じです。 これがITに詳しい人向けのサービス（Slackとか）だったらマジックリンク方式でもよかったかもしれませんね。 今後もサービスのペルソナを常に意識して「何が適切な設計なのか？」を考えていこうと思います。

<h2 id="h5a4313384a">いざ、開発</h2>で、メールによる認証コード方式で開発することに決まったと。 ご存知の通り（？）DeliveryXはRuby on Railsで作られてるじゃないですか。 てことで何か良いgemはないかな〜と探したところ、以下の３つが候補になりました。<ol><li><a href="https://github.com/devise-two-factor/devise-two-factor" target="_blank" rel="noopener noreferrer">devise-two-factor</a></li><li><a href="https://github.com/wmlele/devise-otp" target="_blank" rel="noopener noreferrer">devise-otp</a></li><li><a href="https://github.com/mdp/rotp" target="_blank" rel="noopener noreferrer">rotp</a></li></ol> まず1について<ul><li>これはそもそも認証コードのためのライブラリではなく、Google AuthenticatorなどのOTPアプリのためのgem</li><li>一応６桁の認証コードも生成できるが、それは内部的に3のrotpを利用しているだけ</li><li>以下の記事にあるようにハマりポイントが多く、実質的にrotpを利用した場合とあまり変わらないことになりそう<ul><li><a href="https://zenn.dev/readyfor_blog/articles/4a63ca8dbac27c" target="_blank" rel="noopener noreferrer">devise-two-factor によるワンタイムパスワードを使った2要素認証とそのハマりどころ</a></li></ul></li><li>あとDeviseログインを前提としており、DeliveryXではクライアントのログインはDeviseではなくhas_secure_passwordを利用しており、その変更も必要になる</li></ul> 2について<ul><li>これも1と同様にGoogle AuthenticatorなどのOTPアプリのためのgem</li><li>機能は豊富だが、今回の要件とは少しズレてるし過剰機能か</li></ul> 結論：3のrotpを利用することにしました 理由：今回はメール認証コードがあれば十分であり、今後もOTPアプリの機能を導入する予定もないため。仮に今後OTPアプリの機能を導入する場合でも、結局1と2は3をラップしてるだけなので、今回の開発が０からやり直しになることにはならない。

<h2 id="hb7172d4790">できた！</h2>で、１週間ほどおりゃーと開発して、実際にできたのがこちら。 まずはログイン画面でOKボタンを押す

すると、通常はトップページに遷移するのですが、２段階認証を有効にしている場合はこんな風に認証コードを入力する画面になる

で、どれどれとメールボックスを見てみると、、ありました！ 認証コード！

メールに記載されていた認証コードを入力して確認ボタンを押す！

無事にログインできました〜！（パチパチ👏）

<h2 id="h9be0c3393d">おわりに</h2> いやーなかなか良い感じじゃないでしょうか。 これでセキュリティレベルが１つ上がったサービスになりましたね！（やったー！） 今後さらにセキュリティを向上させるためには、IPアドレス制限や、認証アプリを用いた２要素認証の導入などが考えられそうです。 ただしセキュリティばかり向上しても肝心の中身の機能が不十分だと意味がないので、その辺りの開発の優先順位は難しいところですね。 Azitエンジニアとして、今後も引き続きDeliveryXをどんどんアップデートさせていきますので、よろしくお願いします！ 現場からは以上です！

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

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

DeliveryXで２段階認証の機能を開発しました！

Saito Ryosuke

今回お届けするのは、共同代表を務めるCOO山口のインタビューです。なぜAzitを選び、今何を感じながら共同代表として会社を率いているのか。取締役CROの須藤が読者の視点に立ってインタビュアーとなって深堀りしました。

<h3 id="h5c4d85c8fd">PROFILE</h3>山口恭平 代表取締役COO 2012年株式会社ディー・エヌ・エーに新卒入社。株式会社DeNA Games Tokyo取締役、グローバルゲームエグゼクティブプロデューサーを経て、2019年4月Azitに入社。プロダクト本部長を務めた後、2020年6月取締役に就任。2024年9月より現職。

<h3 id="h9b30d5f4c4">自分自身のチャレンジを通じて、日本を良くしたいから</h3> ー Azitの中では唯一、創業メンバー以外で取締役を務め、その後共同代表になりましたが、それによっての変化は感じましたか？ 正直なところ、ポジションが変わったからといって大きな変化は感じません。入社を決めたときから「自分が会社を引っ張っていくぞ」という気持ちで挑んでいて、取締役になったから何かが変わるということは、あまりなかったんです。共同代表になったときもそうです。もちろん、責任や働き方は異なったりしますが、根本の考え方に変化はないですね。 ー 会社に対する向き合い方は、ポジションによっては変わらない。という感じなんですかね。もともとゲーム業界にいて、そこからAzitへと来てくれた理由を教えてください。 幸運にも、やりたいことがいっぱいあるんです。たくさんあるならチャレンジングなことを選びたいと思っていて。 当時のAzitはライドシェア事業をやっていましたが、法規制の変更など、日本での大規模な展開を狙うには多くのハードルがあり、入社前に「こうすれば上手くいくだろう」という流れが自分の中でイメージできなかったんです。そこに、想像できないくらいのチャレンジができると感じたので、入社を決意しました。 ー そこから事業をピボットして、今に至るわけですが… 入社時点でこそライドシェアでしたが、究極的にはライドシェアだけが本当にやりたかったかというと、別にそうでもないんですよね。ただ「ものすごい難しい問題を解こうとしている、そのチャレンジを自分もしたい」と思ったのが、率直な想いです。 今は、物流・サプライチェーン周りでDeliveryXをはじめとした事業を展開していますが、今日本が抱える中でも、ものすごい大きな産業の中で、そこの仕組みを変えたり、新しいことにチャレンジするというのを、スタートアップの立場で取り組んでいると思っています。 それは、2024年問題（輸送能力が不足し、「モノが運べなくなる」可能性があると言われている問題）も含めた様々な問題があると言われている中で、今後、日本に住んでいる人の生活を変えるような責任とやりがいがある仕事だと思うんですよね。少し大きな話にはなりますが、基本的には「日本を良くするため」に働いて、会社を経営しています。 ー シンプルに、なぜ「日本を良くしたい」と思ったのですか？ 1つあるのは「日本に住む」という意思決定を自分自身でしたからですね。学生時代に中国に留学して、前職でも中国と日本のゲームパブリッシュ事業を立ち上げていました。転職を含め「中国で働く」という選択肢もあったんですが、結婚もして家族の事情もあり単身赴任ではなく、日本で家族と過ごそうと決めたことで少し意識が変わりました。そうなったら、日本でどういうことをするのか、日本をより成長させるにはどうすべきかとか、そういうことを考えたくて。 この日本という国で、自分のやるべきことを成し遂げないといけないと思っているんですよ。Azitに入って何かを成し遂げるとか、モビリティの領域で何かをやり遂げるということも、自分で決めたことじゃないですか。自分で決めたことを翻すのは、ダサイしやりたくなくて。

<h3 id="hcbb803d055">Azitは、やり切ることを諦めない集団</h3> ー Azitのチームに対しては、どう感じていますか？ 正直、この会社は良いときばかりではなく、挫折も経験しているんですよね。特に、コロナになったときの事業への打撃は大きくて。でも、誰も諦めなかったというのは、大きな体験だったと思います。実は周りからも「なんであのタイミングでやめなかったんですか」みたいなことを言われたりもしたのですが…。 素直に、僕には諦めるって選択肢はなかったんですよね。これは「皆が諦めなかった」っていうのが1つ、大きくあって。諦めない仲間たちが、目の前にいたんですよ。あの環境でも諦めない人たちでチームを作ってビジネスができるのは、すごく大きいチャンスだと感じてたんです。それはなんか、貴重なチームだなって。 実際にできるかどうかはさておき、このチームなら成し遂げられる何かがあるな、と強く思ったんです。 ー たしかに、当時強い一体感があったと思います。その体験を経て、今後どのような会社や組織の風土を作っていきたいと考えていますか？ 基本的には、やり切る人たちの集団でいたいですよね。やり切ることを諦めない集団でいたいし、ベクトルは世の中の「こと」に向かってほしいと思っています。 例えばですけど「いや、それできないと思ってたんですよ」みたいに、責任を人になすりつける人って、一緒に前向きに働きづらいじゃないですか。「なんでこれがいいのか説明を僕にしてください」みたいな。もちろん説明責任は果たすし、そこで疑問を問われればちゃんと答えますが、それをなんか「なんでこの戦略が妥当なのか、僕を納得させてください」みたいな人だと、違うのかなって… ー 逆に言うと「自分がやっている」という意識がある集団だといい、という感じでしょうか。 そうですね。自分の意思を持って「こうやりたい」「こういう責任を持ちたい」みたいなことを、責任と権限をセットにして機会を与えられるような会社でいたいと思っています。むしろ、そういう自分の意志を持ったコミュニケーションは、歓迎していくような組織でいたいですね。

<h3 id="h31e3ce6245">現状を再構築する独自の難しさと向き合いながら、挑戦を続ける</h3>ー 今後、物流領域でどんなチャレンジをしていきたいと思っていますか。 難しいという前提ですが、この領域は新しい仕組みを入れるしかないかなと思っています。そう言うと、ポジショントーク過ぎるのですが…今後、人手も不足して、荷物も小口化し続けると、総じて今の日本の生活環境が悪化する方向で対応するっていう方針を取らざるを得ないんじゃないかと考えていて。 荷物が「正しく」「早く」届くというのは、世界を見たときにも、もの凄い価値だと思っています。それを、人のオペレーションで構築してきたわけですが、今後はそれをテクノロジーを用いてどう再実現し、最適化していくかというのが、大きなチャレンジになると思っています。日本の生活の豊かさを損なわない、更に引き上げ生活をより豊かにしていくことが、僕たちのチャレンジですね。 僕たちのやっていることって、ゼロイチを作るわけじゃないんですよ。すでにあるもの、大きな日本全体を動かしてるものを、今の動いてる状態のままで未来の生活に向けて再構築していくという難しさがあります。 ー 物流領域に大きなインパクトを与える動き、そして動かしながら変えていくという難しさに対して今、何が求められていると思いますか。 やっぱり、もっと仲間を集めなきゃいけないな、というのは感じていて。仲間というのは、社員という意味はもちろんですが、それだけではなく、提携企業などもです。まさに、同じ志を持って実行できる仲間ですね。日本全体を変えようとするには、それくらい仲間集めは大切なことだと思っています。 ー 最後に、読者に向けて伝えたいことはありますか？ Azitは、日本を変えていくとか、新しいことを生み出すっていうことに対して、まっすぐにチャレンジしてる会社だと思っています。そういう面に共感してくださったり、面白みを感じてくださる方に、ジョインしてもらえると嬉しいな、と思っています。まだまだ僕たちのチャレンジは、道半ば。1合目くらいだと思っていて。日本の課題を解決していくために、一緒にチャレンジしてくださる仲間がいるといいな、と思っています。 キャリアアップとか、自己実現とかももちろんいいのですが。その先にある未来を見て、一緒に働いている間は、同じ方向を向いて一緒に頑張りたいなと思ってます。そんなチームを作り、物流業界を変えていきましょう。 インタビュアー：CRO 須藤信一朗、編集：坂井華子

<h3 id="hda492ffe51">採用情報</h3>Azitでは全方面でポジションを募集しています。 詳細は、以下の募集ページをご覧ください。 <a style="color:#1155cc" href="https://herp.careers/v1/azitinc" target="_blank" rel="noopener noreferrer">https://herp.careers/v1/azitinc</a> また、3月18日（火）にリアルイベントを開催します！ 本イベントは、Azitが運営するpodcast「AND エンタープライズ」の特別イベントです。10x代表の矢本様とLoglass代表の布川様にお越しいただき「スタートアップが生み出すエンタープライズ×AI活用の未来」をテーマにパネルディスカッションを実施します。 下記からお申し込みください。 <a href="https://azitazit.connpass.com/event/346829/" target="_blank" rel="noopener noreferrer">https://azitazit.connpass.com/event/346829/</a> ご来場、お待ちしております！

日本を良くするための挑戦。COO山口が語る、物流・サプライチェーンの未来

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年)チームのコミュニケーション面で改善したことを紹介します。

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

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

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

鈴木

<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には設置されていないセクションもあります。 もちろん、他社のテンプレートをそのまま持ってくるという方法もあるとおもいますが、チームの中でただ盲目的に「セクションに内容を書くという事になっているからとりあず書く」というような文書化する事自体が目的化してしまう事は避けたいと考えているため、文書の構造をすばやく改善していく事を重視し、一つ一つのセクションや構造について「なぜここにそのセクションがあるのか」をきちんと理解した状態で文書を育てていきたいと考えています。

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

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

Sogame Masato

株式会社 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のプロダクト開発チームで複雑な事業ドメインをあつかうプロダクトの開発をするためにチームで実施している取り組みを紹介いたします。