今回お届けするのは、共同代表を務める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 編集部

<h2 id="h8d027c8ed3">はじめに</h2>こんにちは！株式会社 AzitのCTO の十亀です (<a href="https://x.com/Pocket7878" target="_blank" rel="noopener noreferrer">@Pocket7878)</a> 2025-02-13 ~ 2025-02-14に目黒の雅叙園で開催された、Developers Summit 2025に参加してきました！ 私自身はDevelopers Summitには今回が初参加だったので、会場の皆さんの熱気なども感じられてとてもワクワクしました。今回はそんなデブサミの参加レポートをいたします。

<h2 id="h4ac34ea3e7">イベント概要</h2>

Developers Summitは2003年から毎年開催されている、ITエンジニアのための大型イベントで、今年のテーマは「ひろがるエンジニアリング」でした。 今回は特に昨年大きな動きのあった生成AIをテーマにしたセッションが多く、生成AIによって我々エンジニアの仕事のあり方がどのように変わっていくのかを考えるセッションが多かったです！

ブースも盛り上がっていました！ 私たちAzitでは、DeliveryXという物流・SCM領域のDX事業をやっているため、近しいBtoBの企業の方や、弊社プロダクトに連携できそうな企業様などと楽しくお話させていただきました！

<h2 id="h7709cddada">ピックアップ</h2>聴講して気になった登壇をいくつか紹介します！

<h3 id="hd3a3e1819c">技術と情熱で創る未来</h3>Tably株式会社の及川 卓也さんによる講演でした。 コンピュータへの入力方法は、かつて2進数や16進数を直接トグルスイッチで入力していた時代から、アセンブリ言語、さらにはCのような相対的に高級な言語へと進化してきました。そして現在、生成AIに自然言語で指示を与え、コードを生成させるという新たなフェーズに突入しています。この技術の進化の中で、エンジニアとして今後どのような視点でソフトウェア開発に向き合うべきかが、講演のテーマでした。 私はこの講演を通じて、AIと人間の関係性の中で、人間の価値や責任とは何かを改めて考えながら話を聞いていました。 以前から、「プログラムは自然言語で書かれたものが、偶然コンピュータで実行可能な形になっているべきだ」という考え方があり、人間が読みやすく理解しやすい形式でコードを書くことが理想とされてきました。しかし、生成AIの登場によって、実際に自然言語で指示を与えることでコードを生成し、結果を得る機会が増えてきています。技術の大きな進歩を実感するとともに、年々加速するAIの進化に、私自身がどのように向き合うべきかを考える良い機会となりました。

<h3 id="h5299158714">業務理解の深化と実践～ドメインモデリングで基幹システムを捉える</h3>株式会社MonotaRO様でのドメインモデリングを活用したソフトウェアの内部品質の改善プロジェクトのご紹介のご講演でした。 弊社でも、物流業界という複雑なドメインに向き合うため、ドメイン駆動設計（DDD）の知見を活用することが度々あります。

配送にまつわる業務領域をどのように分割するか、それぞれの領域をどのように連携させていくかなどをマッピングしてまとめたり、実際にイベントストーミングを実施して、業務プロセスを改めて再確認したことなどもありました。 ビジネスの対象領域や戦略が複雑化し、開発年数が経過するにつれて、ブルックスの著書でも指摘されているように、競争力の源泉となる「本質的な複雑さ」に加えて、一般に「技術負債」（この呼称が正しいかはさておき）とも呼ばれる偶発的な複雑さがソフトウェア内で増加し、アジリティが低下していく場面が多々あります。こうした問題に向き合い、モデリングを通じて継続的に見直していくことの重要性を改めて実感した講演でした。

<h3 id="h994d369e86">変わるモデルと変わらぬ本質 - 実践知の深掘りと次世代開発アプローチの探求</h3>

コード補完から段階的に自律的にコードを把握して実装をすすめるAIエージェントへと、生成AIとエンジニアの関係性が変化していくなかでも変わらない、エンジニアリングの本質的を見つめ直すとても良い講演でした。 弊社でも開発にDevinを導入して日々タスクを依頼していますが、やはり「人間にとって分かりづらいコードは生成AIにとっても分かりづらい」という部分は日々実感しています。 Devinを導入した際にも最初に私が行ったのはサンプルコードの追加であったりREADME.mdへの情報の追記などでした。 新しい技術が登場した際に、いかにその技術を適切に活用していくかという観点では、エンジニアリングの本質は生成AI移行も変わることのない本質的な部分かとおもいますので、今年以降もさらに生成AIの技術自体の発展や活用も進むことを見越して、そのなかで開発チームのカルチャーもブラッシュアップしていく必要があると強く感じました。

<h3 id="hb08a300a91">生成AI時代のプロダクトの現在地点</h3>

Ai Workforceを運営されているLayer XのCTO 松本さんのご講演でした。 Ai Workforceの開発を進める中で、LLMを前提としたプロダクトの構成について、従来のように個別の業務をソフトウェア化していくアプローチではなく、LLMによって汎用的な業務を捉えるための枠組みをどのように要素分解するかをご紹介いただきました。 こちらのご講演でもAIオンボーディングという言葉が使われておりましたが、「ソフトウェア開発」に限らず、社内の様々な知識をいかにしてLLMにとってリーチしやすい形に整理し、磨き込んでいくかというのはやはりこれからのLLMの活用として重要になっていくと感じています。 また、「AI Agentに踊らされない」というセクションは、私自身も強く共感するところであり、 似た問題解決の領域に思われるツールであっても、「厳密で正確だが、柔軟性がない」ものから「柔軟で対応範囲が広いが、精度担保が難しい」ものというのが存在します。 そのなかで、手段が目的化してしまうことなく、適切に必要なツールや構成の選定というのはやはりエンジニアとして、それぞれの要素にどのような特性があるのかを把握したうえで使い分けることができるのが大切だと感じています。

<h2 id="ha214098e44">まとめ</h2>今回のデブサミでは、私は、生成AIの活用と開発生産性に関連するテーマを中心に、さまざまな講演に参加させていただきました。 ソフトウェアエンジニアとしての活動は、コードを書くこと、コードを読むこと、設計することなど、多くの要素に分解されます。しかし、それらを単なる日々の作業として捉えるのではなく、一つ上の抽象度の視点から見直すことで、生成AIを単なる効率化の手段ではなく、エンジニアリングそのものの対象として扱う必要があると改めて感じました。 特に、AIがコードを生成するという行為は、単に人間の代わりに作業をこなすという話ではなく、ソフトウェア開発の構造そのものを変えうるものです。たとえば、コードの可読性や保守性といったこれまで人間が重視してきた概念が、生成AIを前提とした開発のあり方においてはどのように変化していくのか。また、コードレビューや設計のプロセスはどう変わるのか。そうした問いに対して、技術的な視点だけでなく、エンジニアのキャリアのあり方や、業界全体としての育成の方向性といった側面からも考えさせられる機会となりました。 生成AIのケーパビリティは年々進化し、今年もまたその広がりとともに、ソフトウェア開発のあり方自体が変わっていくのだろうと感じています。その中で、エンジニアとしてどのように技術と向き合い、適切に活用していくのか。単にツールの使い手としてではなく、生成AIの可能性と限界を見極め、それを前提とした開発プロセスやチーム文化をどう構築していくか。そうした視点を持つことが、今後ますます重要になっていくのではないかと改めて考えさせられました。

Developers Summit 2025 イベント参加レポート

Sogame Masato

<a style="color:#000000" href="https://love-from.azit.co.jp/article/0t8w_v3zh" target="_blank" rel="noopener noreferrer">前編</a>に続き、CTO十亀のインタビューをお届けします。後編では、直近を振り返りながらこれからの組織などについてお話しました。

<h2 id="h5c4d85c8fd">PROFILE</h2>株式会社Azit CTO 十亀眞怜 <a style="color:#000000" href="https://x.com/pocket7878" target="_blank" rel="noopener noreferrer">@Pocket7878</a> 慶應義塾大学理工学部在学中に、吉兼・須藤と出会い、株式会社Azitを共同創業。2021年以降、CTOとしてサーバサイドの開発・技術戦略の立案ならびに実行、エンジニアの採用等を中心に担当。

<h2 id="hb418d49441">ときには「現場」で課題解決も</h2>ー CREW時代から、結構現場に行ってバグフィックスをするシーンなどを見てきました。人と会うために外に出るんじゃなくて、課題解決のために外に出るんだな、と。ここには何か理由はありますか？ 現場で対応するのが一番解決法として良ければ、それがやっぱり早いですし、理想的かなとは思っています。そんなに外に出たいわけじゃないですけど（笑）それがベストだから、やろうかなっていうのはありますね。 当時の技術環境を考えると、生のエラーログみたいなものをリアルタイムでネット越しに見られるようなものはなかったので、現場に行って繋がないと何が起きてるか分からなかったというのもあります。特にライドシェアはそうで、Webサービスならサーバーのログとかがあると思うんですけど、アプリになると、やっぱり現場に行って端末で何が起きてるか、見ないといけないことも。CREWドライバーの方の横に行って、操作してもらい、ケーブルを刺して、吐き出してるアプリケーションレイヤーのログを見ないと判断できないこともあったりして。それが、Azitがまだ3〜4人ぐらいのときなので、自分でやっていましたね。 ー 事業をピボットして、物流・サプライチェーンの世界へやってきたわけですが、どのような技術的チャレンジが存在する領域なのでしょうか。 特にマーケットプレイスでは、物流システムのそれぞれのモデルや条件をどうやって上手く抽象化してまとめていくか、という所が、システム設計として一つ大きなチャレンジだと思います。 その中で、ライドシェアでもそうでしたがやっぱり物流も、リアルの世界で起きていることをデジタルで表現して拾っていくプロダクトになるので、現場で起きていることと、デジタルでどう表現してるかっていう所の繋ぎ目をシステムでうまく表現できているかっていうのが大事な所です。 物流やサプライチェーン領域って、既存の領域として複雑なオペレーションや、特例のオペレーションみたいなのがよくあるので、ある意味エンジニアが思い込みで勝手に仕様を狭めちゃったりとかしてはいけないんですよね。 そういうバランス感覚、例えばどこまでがシステムで許すべき部分なのか、ここは柔軟にあえて汎用的に使える形にしておくことで、現場で工夫してもらえる部分として残すか、みたいなところは、実際いろんな企業の話を聞いていく中で、プロダクトの仕組みと面白い部分だと考えています。 ー プロダクトとしてのチャレンジや技術的なチャレンジは、どういう領域になると考えていますか。 特定の要素技術に特化しているというよりは、情報のワークフローをAzitのプロダクトの中で統一する部分と、自由に組み合わせられる部分を組み合わせたシステム設計みたいなところが面白いんじゃないかなと思います。 このプロダクトは、業務フローを、決めてその通り使ってもらうわけではなく、もう一段上のレイヤーでの設計が必要になります。たとえば、ユーザーがどういうタイミングで何をするのかっていうのを決めることができるシステムを作るってなると、抽象度が上がるので、ここをどう破綻せずに作れるようなソフトウェアにするのかっていうのが、設計が難しいところの一つだと思います。その工程を作る仕組み作りの部分をも、うまくデジタル化するところがまた面白いかなと。 そういう部分って、今まではデータをどう表現するかを考えなければいけなかったと思うんですけど、今はAIがもっと柔軟にデータを差配したりとか判断できるようなコンポーネントとして間に入ってくる可能性はかなりあるなと思っているので。

<h2 id="h6c4f69cb4d">現場のニーズに共感し、取り組み続ける</h2>ー 一個人として、エンジニアとしての興味はどこに向かっていますか？ そうですね。一個人としては、量子コンピュータの分野は長期で見て何らかの面白みがある技術が繋がっていくと思ってるので、そこは引き続きウォッチしていきたいと思っています。 あとはやっぱり、今、汎用AIと直接対話するというところが世の中に全部出てきてますけど、そこをソフトウェアの中に隠したり、ユーザーにとっての直接インターフェースじゃなくて、補助する形でパワーアップする形でAIをどう使っていくかっていうのは、プロダクトのデザインとして重要になっていくと思うので、Azitのプロダクトでもそうですし、世の中的にどうなっていくのかっていうのは興味はありますね。 ー やはりAIは、今までDXされきってなかった物流やSCM業界にも大きなインパクトを与えるんですね。 そうだと思います。現場で起きてることって、もちろん改善できる部分もあると思うんですけど、そういうオペレーションって何かしらの理由で行われていると思うので。それをシステムにするときに、今までだと論理で表現しづらいからこぼれちゃってた部分が、ようやく直接取り扱いすることができるかもしれないような、技術が追いついたのかなと思っています。 現場で起きてることを、人間が聞けば理解して判断したり、柔軟に対応できる部分っていうところに、今までシステムがそれを表現する方法がなかったら追いつけてなかったというのがあって。そこにAIが入って、別の処理を打つことができるようになると、より現場の良い部分、現場の工夫によって成り立ってきたオペレーションを、そのままシステムに組み込めるかもしれないですよね。 ー そのために、Azitとしてはどういう組織になると考えていますか。 プロダクトマネージャーやエンジニアのチームは大きくなっていくと思いますし、設計の部分全体は人間が引き続き見ていくんじゃないかなと思っています。AIがほとんど全てを作ってしまうというよりは、差配してもらいたいロジックやコンポーネントは人間が丁寧に作っていき、AIエージェントにどのタイミングでどういう形に入ってもらうか、どっちのコンポーネントにどういう情報フローを移行するかとかを決めてもらうみたいなワークフローを組むところも、やっぱり人間がやるところになるかな。と考えています。 具体的なコーディングはAIが支援してくれる部分が多くなってくると思います。シンプルなコードだけ書き続けたい、みたいな志向は減ってくるのだろうな、と思っていて。どうやってAzitのプロダクトが使われるのか、どういう価値があるのかという所を考える時間が長い人が、増えていくんじゃないかなとは思います。 ー そんな中で、Azitは、どんな人が向いてると思いますか？ そうですね。会社の社風っていうのもありますけど、結構コミュニケーション好きな人が多いと思って。このコミュニケーションというのは、決して何か楽しい冗談を喋ってほしいとか、なにかのテレビ見ましたみたいな話をしてほしいという話ではなくて。 プロダクトを良いものにするために、きちんと取るべきコミュニケーションを取れることなんですよね、そのためにはやっぱりその人間関係が円滑に回ってないといけないので。当たり前ですが、いつも嫌な感じの人とは、なかなか話しづらいじゃないですか。それでビジネスに支障が出る可能性もあるので、仕事をする上で必要な情報をお互い気楽にやり取りして、より良いものにするためのチーム作りができる人や、価値が作れる人っていうのは、重要だと考えています。 DeliveryXは、仕組み作りのプロジェクトなんですよね。なので、やっぱりクライアントの現場ではいろんなことやってるので、それに共感することも大切だと思っています。 実際に現場に行ったときも、例えば薬剤師の方が袋に詰める傍らで、Azitに発注してくれたりとかしてるので、そういうのを間近で見ると、やっぱりその中でどれだけ効率的に皆様に使っていただけるかっていうのは考えないといけない。 自宅でキーボードとマウスで作業してるだけっていうのは、ちょっと違うのかもしれないと思ってしまうんですよね。技術に特化するみたいな話だと、その人がもっと集中して、まとまった時間を1人で取りたいともちろんあるかと思って。ただ、Azitが目指すことを実現するために、ユーザーが現場でどういうニーズを抱えてるのかみたいなことに対してきちんと傾聴して、取り組んでいける人とご一緒できるといいなと思っています。 インタビュアー：COO 山口 恭平、編集：坂井 華子

<h2 id="hda492ffe51">採用情報</h2>AzitでバックエンドのTech Leadポジションを募集しています。 詳細は、以下の募集ページをご覧ください。 <a style="color:#0b57d0" href="https://herp.careers/v1/azitinc/mFCv7shzKFSa" target="_blank" rel="noopener noreferrer">https://herp.careers/v1/azitinc/mFCv7shzKFSa</a> また、Azitではpodcastも配信しております！ぜひ聞いてください！

【後編】現場のニーズに共感し課題解決を続ける。CTO十亀の履歴書

今回は、CTO十亀のインタビューです。2回に分けてお届けし、前編ではこれまでの経歴から現在に至るまでを振り返っています。

<h2 id="h7422936a6c">きっかけは「難しい」という面白さ</h2> ー 幼い頃からパソコンを触っていたと聞いていますが、エンジニアになった経緯を伺えますか。 親の仕事の関係で、小さな頃から家にパソコンがあり触っていたんですよね。とはいえ、当時はまだインタラクティブアートみたいなもので遊んでいる程度でした。プログラムを書いてグラフィックを作ったり、カメラの映像をもとに動いたら画面のコンテンツも反応するグラフィックを作ったりして遊んでたのが最初の頃、小学校高学年くらいのときだったと思います。 遊び程度でも、コンピュータというものを使った物作りが好きでした。プログラムって入り組んでいるので、複雑なものを書いて思った通り動いた時の楽しさとか、逆に思ってもみないような動きをすることの面白さみたいなのもあって。コンピュータの画面の上とかコンピュータの中で動く何かを作るというのが、純粋に楽しいと感じていました。 ー その原体験があった上で、いつ頃から本格的にコーディングにのめり込んでいったのでしょうか？ 本格的にやり始めたのは中学1年生ぐらいのときですね。うちはiMacだったんですけど、Javaのプログラミング環境を使って、JavaでGUIのアプリケーションを作ったりしていました。後は、当時も今もありますけど、XcodeっていうMacでiOSアプリやMac用のアプリを作るツールで、開発して初めて何か作ったりとかをしていました。 ー 当時Macのアプリケーションを開発して、どういうフィードバックを世の中から得られたんですか？ たしかに、フィードバックはあんまりなかったというのが、正直なところです。中学1年生ぐらいのときに、Lispのコミュニティによく遊びにイベントに行っていて。そのときはLispってマイナー言語というかあんまり使用者が多くなかったので、その中でいろんな人と「僕はこういうの作ってみています」みたいに交流したりしていました。 当時周りには、プログラミングを知っていたり、HTMLを使ってる友達とかはいたんですけど、プログラミングしてる人ってあんまりいなかったんですよね。プログラミングができるということ自体に面白さを感じるようになっていました。 ー 聞いた話ですが、大学時代は「サービス開発しようとしたら十亀だ」みたいなのが大学で知られていたとか。それって、どういう感じだったんですか？ エスカレーター式の学校だったので、高校時代の同級生が大学内にも結構いたんですよね。僕、高校のときから学校にThinkPadを持っていって、廊下の端に座ってコード書いたりとかしてる時間もあったんで「そういう奴がいるぞ」という意味では、元々知名度があったと思います。そういう背景もあり、大学1年のときに1つ目のベンチャーに声をかけてもらいました。 ー そこが初めての学生起業になるわけですか？ そうですね。当時Railsで開発するのがちょうど日本で流行ってた時期で、僕は結構Railsを個人的にいろいろ触っていたこともあって、ニーズにもはまったので参加することにしました。 そこで、他のメンバーにコーディングを教える機会があって。それを知ってもらって、学内で「ベンチャーやってて、バリバリコード書いてサービス作ってる」って周りに伝えてもらったりして。誰かがうまく話を回してくれたっていうのがあり、起業したい人達の間で話題に上がりやすかったんじゃないかと思います。

<h2 id="hb6e258c86f">より面白く、困難な課題を解決するために。</h2>ー 当時からもう、将来的にも起業しようと考えていたのでしょうか？ 自分で事業をやりたい、会社をやりたいっていうモチベーションがあったわけではないんですよね。ただ、当時から一般的な大学生よりも実用的なプログラミングの知識を蓄えることができていて。だから、もっと面白い課題があって、もっと自分の能力を伸ばせる環境にいたいとは考えていました。 授業で出てくるものとかだと、物足りなさを感じることも多かったんですよね。そんな中で、ベンチャーでやっていると、もっと実践的な課題や、効率よく作ることを求められたりすることも多く、それを作って自分の能力が上がることに楽しさも感じていました。 なので、漠然とした作業をするようなところに就職するよりは、面白い課題が得られるような会社にいきたいと思っていました。それが起業なのか、もっと何か有名な企業に入るのかとかは、当時は決めていませんでしたが。 ー そんな中、卒業後の進路はどうやって決めていったんですか？ 大学時代からAzitをやっていましたが、当時はこのままAzitをやっていくか、Azitを手伝いつつ大学院に行くかどうかで迷っていて。なので、その時点で就職の選択肢はあまり考えてなかったんですよね。 当時、いろんな大学院も気になっていて、話を聞いてたんですよ。他大学の情報系や、数学系の研究室を実際に見学させてもらったりも。また、もう少しロジックとか、哲学みたいなことをやりたいとも思ったので、文学部の哲学科の研究室の先生にも1回面談に行かせてもらいました。そこの先生にも言われたんですけど、やっぱり僕は、ものすごく細かい世界で1人しか知らないことを、1人で知りたいというよりは、広い世界のいろんなことに挑戦したり知りたいというタイプなんですよね。 研究室の中で論文を読んで一生研究するよりは、実際のユーザーの声を聞きながら誰かに触ってもらえるような開発をした方がいいんじゃないか、と。先生からもアドバイスをもらいましたし、自分もそうだなと感じるようになりました。 勉強ももちろん好きなんですけど、1個のことをずっと一生ピンポイントで研究して、そのことについて世界で一番詳しくなるよりは、僕はもしかしたらいろんな問題を解いて、また新しい問題に向かっていくことをずっと繰り返してる人生の方が、楽しくなるんじゃないかということを改めて思ったんですよね。そうなるとやっぱり就職か、そのままAzitかっていうのを迷ってたら、目の前に今ちょうど様々な課題を持ったAzitがあったので、これを続けることに決めたという感じです。 後編につづく インタビュアー：COO 山口 恭平、編集：坂井 華子

<h2 id="hda492ffe51">採用情報</h2>AzitでバックエンドのTech Leadポジションを募集しています。 詳細は、以下の募集ページをご覧ください。 <a style="color:#0b57d0" href="https://herp.careers/v1/azitinc/mFCv7shzKFSa" target="_blank" rel="noopener noreferrer">https://herp.careers/v1/azitinc/mFCv7shzKFSa</a> また、Azitではpodcastも配信しております！ぜひ聞いてください！

【前編】技術的チャレンジをし続けるために取った「起業」の選択。CTO十亀の履歴書

今回は、取締役CRO須藤のインタビューをお届けします。2024年9月にCCOからCROへと肩書を変えた須藤が目指す、Azitのあり方について深堀りました。

<h2 id="h5c4d85c8fd">PROFILE</h2>株式会社Azit 取締役CRO 須藤信一朗 東京理科大学理学部在学中に代表の吉兼と出会い、Azitを共同創業。卒業後は中部電力に就職。「CREW」の立ち上げから、再度Azitに参画。現在は大手からスタートアップまで幅広く知見のあるChief Relation Officerとして、セールス周りを始めとした社外リレーション全般を統括している。

<h2 id="h7ca7263d40">大切なのは課題解決するだけでなく、企業として信頼を得ること</h2> ー 「CRO」というポジションは、主にどういったことを管轄しているのでしょうか？ 社外リレーション全般を統括しています。セールスだけでなく、クライアントとの最初のコミュニケーションから、先方のキーマンとなるような方々と対話を重ねて、課題感やプロジェクトの進め方の大枠を決めていく所を担っていますね。 ー もともとは「CCO」（チーフカルチャーオフィサー）の肩書きでしたよね。 昨年9月のタイミングから今の肩書に変更しました。以前から社内カルチャーだけを見るというよりは、外に出ていく活動が多くなってきていて、より外寄りの役割のニュアンスを明確にするために、変更することにしました。 肩書については、CROだけでなく他のCxOも候補には出たのですが。「セールス」だけでもちょっと違うし「レベニュー」なんかも違うと思って。結局、リレーションが一番しっくりきたんですよね。能力特性上も含めて、言語化しにくい所ではあるのですが、AI時代のいわゆる論語と算盤でいうと、論語側というか…（笑） エンタープライズ企業に対して、価値を届けるというのはもちろん大切なのですが、それだけでなく会社として信頼してもらえるような基盤と関係性をしっかり作っていくという部分を大切にしています。そういう意味で、会社としてのリレーションを構築するというのが僕の役割ですね。 ー 肩書きが変わったことで、変化したことはありますか？ 役職で何かが決まるわけではもちろんないのですが、それでもCROという肩書きに変更してから、思っていた以上に深く課題感を伺えたり、プロジェクトを進める上での相談をいただくシーンが多くなりました。 関係値作りって、当然目に見えない部分が多いんですよね。例えば、オンラインで会議をしていても、先方の課題感をお伺いすることはできます。でも、それだけではなく、関係を深めるための様々な行動を取ることで、もっと深い課題を知ることができたり「実は一番の課題はそこじゃなくて、別の所が刺さっているな」とかが見えたりもするんですよね。そういったことを繰り返し、真の意味でリレーションを構築することが、次のサクセスに繋がっていくとも思っています。

<h2 id="hfd0ca63f3a">このサービスが顧客の生活をどう変えるかを、描き切る</h2> ー 事業開発とはどのように関わっているのでしょうか。 事業開発については、主に戦略の部分はほかの経営陣が役割としてやってくれています。僕は、その描いた事業の足元となる部分を0から1にどうやって持っていくかを担っています。 AzitはもともとCtoCビジネスを運営していた会社ということもあり「顧客にどういう価値を提供するのか」を大事にしている人が多いんですよね、僕自身もそうです。 現在の事業モデルになってからも、結局は「僕らの事業を通じて、顧客にどういう体験を提供できるか」を描き切ることが大切だと思っています。極端な例ですが、例えばクライアントが求めることだけをやって、使えるかどうか分からないようなシステムを作って売上を上げる、とかは絶対に僕らの仕事ではないと思っていて。DeliveryXを通じて真に必要な価値を提供すること、その最終的な価値まで描き切れるように落とし込んでいくというのが、大切だと思っています。 ー toBのビジネスおいても、結局は最後に使う顧客のことを考える、ということですね はい。それが社会での仲間作りにも繋がると思っていて。自分の知らない所で生まれたよく知らないサービスよりも、自分の生活に対してどういう影響を与えてるかが明確になっている方が、仲間になりたいと思ってもらえると思うんですよね。組織のモメンタムも上がっていきますし。社内だけじゃなく、社外の人たちからも応援してもらえる要素になると思うので、とにかく最後に使ってくださる方のことを考え、描き切ることを徹底しています。

<h2 id="h64950169de">令和らしい寝技とテクノロジー</h2> ー Azitとして、今後どのようなポイントに注力していきたいと考えていますか？ 2025年、プロダクトにAIという要素をより深く取り入れていくことは必須になっています。特に、AIエージェントや音声AIをうまく活用したプロダクト作りができると、時代にかけ合わせた僕らのユニークさが出てくると思うんです。そういう要素がどんどん生まれると、唯一無二性が強まっていくんじゃないかなと思います。 ー AIを活用している企業は数多く存在していますが、AIエージェントをうまく活用できている企業はまだあまり見ないですよね。 そうですね、AIを活用するtoBの企業は多くありますが、まだまだAIエージェントを活用しきれてる企業はないと思っていて。 例えば、輸送においてなら、意思決定まで代替させて、目標値を定めるところから効率化の手段まで託したり。オンラインマシンラーニングみたいな話もあって。データ収集はこれまでずっとマシンラーニングしてきたけど、モデリングも含めて最適化をどんどん回していけるようなものがうまく作れるんだったら、まだ世の中で生み出せていないようなものができる余地はあるのかなと思います。 ビジネスの場で昔から「寝技」なんて言うことがありますが、テクノロジーの強みがあるからこそ初めて寝技が生きるのが今の時代だと思っていて。寝技だけで何かが進むわけではなく、だからってテクノロジーだけで進むわけでもない。令和という時代だからこそできること、僕らの強みに合わせて攻めていく方法として、AIエージェントを僕らの事業に絡めることができれば、寝技がより生きると思っていますし、それがユニークさにもなると考えています。

<h2 id="h3e28fc140b">Azitがあるからこそ存在する世界線を、世の中に感じてもらいたい</h2> ー Azitをどういう会社にしていきたいと考えていますか。 大前提として、売り上げを上げることと、社会的意義として世の中をより良くしていくことの両立は重要だと思っています。それを両方叶えるのは難易度が高いというのはもちろんなのですが。世の中に価値があるものばかりに囚われすぎるとボランティアのようになってしまうし、売り上げだけを考えたら別のことでも良くなってきてしまう気もするんですよね。 そして、それだけじゃなく、僕らがいてAzitがある世界線と、ない世界線で、世の中に対して変化を起こせないと、ハッピーじゃないんですよね。 世の中が僕らがいることによって変わった世界線というものを、顧客の方に感じてもらえることが、目指すところだと思うんです。その手前として、一緒に進めていく企業様の内側から変化が起こっても嬉しいですし。企業が変わることによって、顧客体験も変わりうる要素がたくさんありますから。僕らがご一緒させていただいているクライアント企業様が、僕らがあることによって変わっていき、そこから生まれる経済と社会的意義、そういう価値を両軸で作っていくことができればハッピーです。その車輪をよりどこまで大きくできるかという戦いになると思っています。 ー そのために、どんな組織になるべきだと思いますか？ 今のメンバーを見ていてもそうなのですが、言われたものを言われたままに作るチームではなくて（笑）そのスタンスはより強く持っていたいですね。 言われたものをそのまま作るのではなく「こうするとより世の中に価値がある」ということを言い返すこともあるし、そのための提案まできたり。 ー いい意味で御用聞きではないんですね。 言われたものをそのまま作るのがもちろん楽なのですが、そうではなく価値を考え、そう思った背景から説明責任を果たし、より良い方向を提案して真の価値を提供していく。このスタンスは、Azitらしいし、貫きたいなと思っています。 受託だけで終わらない、コミットして価値を提供していくスタンスが良いと思っているんですよね。細部までこだわり抜くというのは、普通のことであり難しいことですから。 コンサルティング会社のように戦略を描き、システム会社として作る部分もやる、配送網の提供会社としての役割も担う。僕たちはそういったことを三位一体で勝負しているので、例えば「配送費用をここまで下げたい」「ここまで効率化したい」という要望に対して、全部コミットして勝負できます。それが僕たちの強みだし、おもしろさでもあるかな、と思っています。 皆が自分ごととして進めていく姿勢がすごくいいなと思っていて。それがカルチャーとしてしっかり根付いていくと強い組織になるんじゃないかなと思っています。 インタビュアー：COO 山口 恭平、編集：坂井 華子

<h2 id="hda492ffe51">採用情報</h2>Azitではエンタープライズ・アカウントエグゼクティブのポジションを募集しています。 詳細は、以下の募集ページをご覧ください。 <a href="https://herp.careers/v1/azitinc/FUYzRLNKNkUv" target="_blank" rel="noopener noreferrer">https://herp.careers/v1/azitinc/FUYzRLNKNkUv</a> また、Azitではpodcastも配信しております！ぜひ聞いてください！

僕らがいるから変わる世界線を目指して。CRO須藤が目指すAzitの行く先とは

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の導入をすすめて、モジュラモノリスバックエンドの保守性を高める

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で目指すコト

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フロントエンドエンジニアを募集中です。ご興味をお持ちいただけましたら以下の採用サイトからご応募下さい

Pick Up!

Hashtags

Latest Articles