Azitを卒業し、別の場所で挑戦を続ける“ex Azit”の仲間たちに、Azit代表の吉兼が話を聞くインタビュー企画「ex Azit」。第一弾は株式会社shizai代表の鈴木暢之さんをお迎えしています。 後編では現在経営されているshizaiでの組織作り、Azitカルチャーへの想い、そして、これからAzitにジョインする人へのメッセージを伺いました。 ▶前編はこちら <a href="https://love-from.azit.co.jp/article/99rrad0xu" target="_blank" rel="noopener noreferrer">【ex Azit】前編 | Azitを経て起業を選択。shizai代表鈴木さんが振り返るAzitの創業期</a>

<h2 id="h5c4d85c8fd">PROFILE</h2>株式会社shizai 代表取締役　鈴木 暢之（すずき のぶゆき）さん 新卒で株式会社電通に入社。国内/海外のエンタープライズクライアントの事業支援を担い、2016年末に退職。2017年よりライドシェアプラットフォーム「CREW」を運営する株式会社Azitに初期メンバーとしてジョイン。事業開発、オペレーション、CS、PR、コーポレート、採用/組織戦略等、プロダクト開発以外の領域全体を統括する経営メンバーとして活動後、2020年3月に退職。2020年10月に株式会社shizaiを創業。

<h2 id="h0d075aea15">“しんどさ”を楽しさと熱に変えるカルチャー</h2>ー shizaiとAzitで、組織づくりの観点で違いはありますか？ 「事業成長の過程で辞めてしまう人がいることは、一定仕方ないこと」と思えるようになったことですね。Azitは仲が良く、続ける人が多いカルチャーだったなと思っています。しかし、実際自分が経営していくとなると、どうしてもフェーズの変化の中で、個々人と組織があわなくなる局面も出てくるんですよね。 会社と本人の矢印を合わせたいとは思っていても、ライフステージの変化などで本人の方向が変わっていくこともある。そのときに、モチベーションが半減してしまっている人に残ってもらうより100%の力で取り組んでくれるメンバーで純度高く事業に向き合えている方が、結果的にチームとしてはワークする確率が高いと思っています。 もちろん採用した人には辞めてほしくないし、ずっと一緒にやっていきたいという気持ちはあります。ただ、以前よりは「その人自身の選択を尊重する」という考え方に明確にシフトしました。

ー 卒業した立場としてAzitに対して「こうなっていったら面白い」と思うことはありますか？ 良い意味で「変わらないでいてほしい」と思っています、特にカルチャーは。Azitって、いつどんなときも「ここからっす！」って言ってる会社だなと思っていて（笑）そういう空気感を持つ人たちが、最終的に勝つんじゃないかと思ってるし、僕自身もそうありたいと思っています。しんどいときに、なぜかテンション高く楽しんでる人がいる。そういう組織の強さを感じるし、見ているだけで元気をもらえるんですよね。 僕自身も、Azitにいたことで性格が変わった部分があると思っていて。もともとは、物事を頭で考えて「メリットはA、デメリットはB…」みたいに整理するタイプだったんです。でもAzitにいたことで、「わからないけど、とりあえずやってみるか！」みたいなマインドに変わっていった実感があります。 ー たしかに、僕は「考えすぎですよ」って人生で一番言った相手が、ノブ（鈴木さん）だった気がします（笑） 真顔で言えた年齢でしたからね（笑）組織については「変わらないでほしい」が本音です。事業に関しては、どちらかというと「堅く当たりそうなマーケットを狙う」会社ではなくて、「いろいろやっていたら、ひとつ大きく跳ねた」みたいな会社だと思っているので、今後もどかんと突き抜けてほしいですね。 ー 嬉しい言葉です。もちろん積み上げるべところは積み上げながらも、突破口を突き抜けていきたいですよね。 吉兼って、創業してから今まで、ずっと打席に立ち続けてきたと思うんですよ。10年もそれを続けている人って、かなり稀有だと思っていて。本当にすごいことだと思います。だからこそ、「ここからっす！」って本気で言える仲間じゃないと、その環境には向かないとも思うんですよね。

<h2 id="h82e9a3fb31">広がるキャリア。Azitの“その先”</h2>ー 今、Azitに入ることのメリットって何だと思いますか？ Azitは「人材の種類×年齢」みたいなマトリクスにおいて、かなりケイパビリティが高い会社だと思っています。たとえば「大企業出身×20代」とか「スタートアップ経験者×30代」とか、どういうバックグラウンドの人でも、適切なアサインをする感覚がAzitにはあるんですよね。 スタートアップに挑戦したいけど、「自分に合うか分からない」「入ってみたらミスマッチだった」みたいな話って、世の中にはよくあると思うんです。 でもAzitの場合は、そうならないようなアサインの妙がある。このくらいのボールを投げたらこの人はできるだろう、みたいな勘所に長けていて。だから、最初からミスマッチが起きることが無い気がします。そもそもミスマッチが起きそうな人は採用しないという判断も含めて、きちんとしていて。だからこそ、入社する人には最初から発射台が用意されていて、すごくいいなと思います。

ー ありがとうございます。そう感じてもらえていたなら嬉しいですね。 あと、Azitは、辞めた後の選択肢も広くなる会社だと思っていて。長く定着する人もいれば、起業する人もいる。もちろん辞めることを前提に働くわけではないけれど、「辞めたあとにも選択肢が広がる会社」だと思っています。 キャリアという意味でもすごく可能性が広いし、「人に優しい会社」という印象も強いですね。やっぱり、アサインが上手なんですよね。お互いがんばりましょう。

聞き手：吉兼周優　編集：坂井華子

<h2 id="hda492ffe51">採用情報</h2>Azitでは、各職種で採用を行っております。詳細は、以下のページをご覧ください。 <a href="https://herp.careers/v1/azitinc" target="_blank" rel="noopener noreferrer">https://herp.careers/v1/azitinc</a>

【ex Azit】後編｜変わらない熱量、広がる選択肢。Azitがくれた“人に向き合う力”

Love from Azit 編集部

Azitを卒業し、別の場所で挑戦を続ける“ex Azit”の仲間たちに、Azit代表の吉兼が話を聞くインタビュー企画「ex Azit」。第一弾は株式会社shizai代表の鈴木暢之さんをお迎えしています。 Azitの2人目の社員としてCREWの立ち上げ期を支え、その後起業して現在に至る鈴木さんに、当時のお話を伺いました。

<h2 id="hf0b532ce16">入社して最初の仕事は「自分の雇用契約書を作ること」</h2>ー 今日はよろしくお願いします。まずは自己紹介と、当時Azitでどのようなことをされていたかを教えてください。 株式会社shizai 代表の鈴木です。今日はよろしくお願いします。キャリアとしては、新卒で電通に入社し、2017年にAzitへジョインしました。社員として2人目の入社で、創業期から組織の成長過程まで携わり、2020年に退職。その後shizaiを創業し、代表を務めています。 Azitでは、最初はいわゆる何でも屋さん的なゼロイチポジションでしたね。ちなみに最初の仕事は「自分の雇用契約書を作る」ことでした（笑） ー 今考えると、当時は前職の業務とかけ離れたことをお願いしていましたね… そうそう。皆に得意な所をやってもらい、それ以外の部分を僕が拾っていくような感じでしたね。その後、組織が拡張してきたタイミングで、渉外領域をメインに担当しました。「会社の外のことは任せてね」というスタンスで、特にリーガルに軸足を置きながら動いていました。吉兼と一緒に組織作りにも取り組んでいましたね。 ー そうでしたね。その後、shizaiを創業したきっかけを教えてください。 もともと起業や経営には興味があったのですが、正直、当時は「これがやりたい！」という明確な事業はなかったんです。ちょうど退職のタイミングで本格的にコロナ禍に入り、その影響下だからこそ伸びそうな事業を20〜30個ほど考えました。その中でEC領域の伸びを感じていたことや、電通時代に印刷業・ものづくりに近い領域にいた肌感覚もあり、「まずはやってみよう」と創業に踏み切りました。

<h2 id="h758b0362c7">Azitだから経験できた創業期の“いろは”</h2>ー 起業にあたって、Azitでの経験で活きたことはありますか？ スタートアップの初期に携われたことで、採用やコーポレートづくり、株主とのコミュニケーションなどを経験できたのは非常に大きかったですね。 よく「創業期はカオス」と言われますが、実際にはやるべきことは明確で、それらを順番に整理して進めていく、というシンプルな構造だと思っています。創業期“あるある”の課題を一度経験していたことは、起業時に大きなアドバンテージになりました。 また、大企業にいた頃は自分で人を採用し、組織によってレバレッジをかけるという経験がなかったので、Azitでそれを体感できたのも良かったです。 ー たしかに、20代で組織づくりを任されることってなかなか無いですよね。 そうですね。大企業では、どちらかというと20代は「プレイヤーとして成果を出す」ことを求められることが多いですから。当時のAzitは、様々な雇用形態の方を含めると100名ほどの組織規模になっていたので「人が増えると一人ではできないことが実現できる」というのを体感できたのは、今の組織計画にも大きく活かされています。 また「Azitで良かった」こともあって。まず、入社当時は全員週6くらい働いてたんですよね。今だとどうなんだろう…というのはもちろんありつつ、自分自身への厳しさの水準を作る土台にはなりました。「売上も利益も出てないから働くしかないじゃん」みたいなことを体現している人たちと一緒に働けたのは、すごく良かったと思っています。マインドとして、すごく良いものが培われたと思っているんですよね。 あと、Azitの最終面接には「人のことを聞く」文化があって、僕もshizaiでも続けています。過去の意思決定の変遷を聞きながら、その人の抽象化された軸を捉えていく。Azitは、“人と向き合うのが上手な会社”だな、と感じていました。

ー 当時のAzitで印象に残っている出来事はありますか？ 色々ありますが、特に印象的だったのは蒲田での合宿ですね。創業者3人と社員2人、計5人だけで2泊3日。「お互いの人生を知る」がテーマで、ほとんど寝ずに朝まで人生について話し込んでいました。当時はそれが「スタートアップらしさ」なのかと思っていましたが、今考えると「Azitらしさ」だったんですけどね（笑） あと、人が人を呼ぶ瞬間に立ち会えた、というのも印象的でした。熱量の高い時期を経て急激に仲間が増えたタイミングがあって。まさに、伸びるってこういうことか、と実感する瞬間でした。 僕はあまりVISIONにこだわるタイプではないのですが。でも、当時その言葉に共感してジョインしてくれる仲間が増えていく様子を見て、シンプルに凄いなと思ったんです。言葉の力を感じた瞬間でした。

<h2 id="hd2ad8167a5">真顔で「世界一の会社を作る」と言い続けていたい</h2>ー 今後の人生で成し遂げたいことはなんですか。 「真顔で“世界一の会社をつくる”と言い続けられる自分でいたい」ということでしょうか。人生は一回だけ。だからこそ、なるべく複雑な課題に挑戦したいんですよね。昔から簡単なことよりも難しいことに取り組むほうが、解く過程に面白さがあると思っていて。そのためには主語を大きくした方が良いんじゃないかなと思っています。「日本」ではなく「世界」とか「地球」「人類」みたいな。そういう大きなことを真顔で言っていきたいですし、今の事業もそうした目線で描けるようにしていきたい気持ちがありますね。常にそう思い続けられるよう、自分自身に期待したいところです。 ー そういった複雑な課題に面白さを感じるのってどういう点なんでしょうね。 僕にとって“唯一性”というのがキーワードです。「自分たちしかやっていない」「自分たちだからできる」とか結構大事で。自分自身がそういう人を格好いいと思って惹かれるし、僕が目立ちたがりだからかもしれませんが（笑） シンプルで簡単な問題だと、トライする人の母数も多いと思っていて。複雑な課題のほうが必然的にトライする人も少ないので、難しいのって良いなって思うんですよね。自分たちしかやっていないと感じられる課題には、価値を感じます。 ー たしかに、当時AzitもCREWを運営していて、日本で自分たちしかやっていないことを感じられましたよね。 本当に。自分たちだけというのが声高に言えたし、大きいことをしようとしてるぞという気持ちもすごく感じられましたね。

ー BtoBって、競合やバジェットという概念がある中で、唯一性というのが難しい部分もあると思うんですよね。だからこそ、会社=法人格の個性が大事ですよね。オリジナルであることの楽しさと、ゲーム的な楽しさが両輪で回っているような。 まさに。今の事業でお客様と向き合ってると、自分たちの唯一性に対する期待のハードルを少し下げても良いのかな、と思う瞬間はありますね。それは、失ったり無くしたりという意味ではなくて。 品質の高いものを提供することで、すごく喜んでいただける。そこには大きな価値があると思っています。だからこそ目先の「唯一性」にこだわるのではなく、目の前にある価値を積み上げていった先に唯一性というゴールがあるのかもしれない、と思ったりもしています。 それが競争優位性なのか、僕の言う“唯一性”というエモいものなのかはわかりませんが（笑）頭で考えすぎると「これって他に人でもできるんじゃない？」とか言えちゃいそうなシーンでも、意外と自分たちだからこその個性を感じられる所があったり。それはBtoBだからこそ感じられる所だし、自分自身を喜ばせるためにも良いかなと思っているんですよね。 ー BtoBに関しては、必ずしもユニークさにこだわらなくても良いのかも、という瞬間はありますよね。 そうですね、連続した先にユニークさがある気もしていますよね。例えばビズリーチさんも最初はビズリーチとしてスカウトを主軸に展開していたと思いますが、いまはビジョナルとして様々な事業を手掛けていたりするわけで。突き詰めた先や、成長の過程でそうなっていくことだってありますよね。 結局、目の前のお客様に愚直に価値を届けることが大事なんだと感じています。 聞き手：吉兼周優　編集：坂井華子 ▶後編へつづく 後編では、shizaiでの組織作りの話、Azitカルチャーへの想い、そしてこれからAzitにジョインする人へのメッセージを伺います。

【ex Azit】前編 | Azitを経て起業を選択。shizai代表鈴木さんが振り返るAzitの創業期

<h2 id="h8d027c8ed3">はじめに</h2>こんにちは、株式会社AzitでCTOを務めている十亀眞怜（そがめまさと）(<a href="https://x.com/Pocket7878" target="_blank" rel="noopener noreferrer">@Pocket7878</a>) です。 私たちは日々、さまざまな業務の効率化に取り組んでいますが、その中でも「住所データの処理」は、多くの企業が直面する共通の課題です。 本記事では、日本の複雑な住所体系において、住所を適切に分割・構造化する作業を、AIを活用して半自動化した取り組みについて紹介します。具体的な実装方法や、実運用で得られた知見を共有します。

<h2 id="hc9565f2c21">日本の住所処理が抱える課題</h2><h3 id="h6b3ee203e3">住所体系の複雑さ</h3>日本の住所は世界的に見ても特殊で複雑な構造を持っています。都道府県、市区町村、町名、丁目、番地、号、建物名など、多層的な要素で構成されており、さらに以下のような課題があります：<ul><li>表記の揺れ（漢字/カタカナ、全角/半角、ハイフンの有無など）</li><li>建物名の多様性（正式名称と通称の混在）</li><li>企業ごとに異なる住所フォーマットの要求</li></ul>実際、<a href="https://www.digital.go.jp/policies/base_registry_address" target="_blank" rel="noopener noreferrer">デジタル庁のベース・レジストリ</a>でも、日本の住所の標準化は重要な課題として取り組まれています。<h3 id="h822009bb2f">Azitにおける具体的な要件</h3>私たちAzitでは、住所データを以下の3つのフィールドに分割する必要がありました：<ol><li>address_line_1: 丁目までの住所（例：東京都港区六本木6丁目）</li><li>address_line_2: 番地以降（例：10-1）</li><li>address_line_3: 建物名・部屋番号（例：六本木ヒルズ森タワー53階）</li></ol>この分割は、システムの都合だけでなく、配送業務やマーケティング分析など、様々な場面で必要となります。 従来の配送依頼の処理では、一件毎にユーザーが入力していたため、上記の3つのフィールドに分割する作業はユーザーが実施してくれていました。 しかし、今回はユーザーの社内独自フォーマットのファイルを弊社側のオペレーションで上記の弊社側の形式に沿ったフィールドに分割したファイルに変換して一括入稿する必要がありました。 そのため、数十〜百件ほどの配送依頼を一回で取り扱う必要が発生し、この変換業務をいかに効率的にするかが重要となりました。<h3 id="h245aa8c8e7">既存ソリューションの限界</h3>当初、Google Maps APIなどの既存サービスの活用を検討しましたが、Google Mapは前述のような複雑な日本の住所には十分には対応できておらず、たとえば番地以下をGoogle Mapではそもそも認識できていなかったりするなど、住所文字列を分割するという観点では利用が困難でした。一方で、Google Maps APIには住所が誤っていてもランドマーク名などが含まれていれば、おおよそ正しい位置を認識できるといった特性があります。 このように住所情報の処理という観点では<ul><li>集合知的なアプローチによって「曖昧ではあるが、柔軟に住所を処理できる」ツール</li><li>厳密なルールやマスターデータによって「厳密な住所を厳密に処理できる」ツール</li></ul>の間のグラデーションで様々なAPIや手段やツールが存在します。 今回のケースでは、厳密に住所を分割したあと弊社のシステムに沿った形式に結合し直すというアプローチも考えられますが 元々の住所が厳密なのかという観点や厳密に住所を分割するためのシステムを構築するコストにたいして今回の対象となる運用においてどの程度の厳密さが求められるのかのバランスを考えた際に、より前者に近い曖昧でも良いので柔軟に住所を処理できる方式を探ることとしました。 事実、本機能の対象となった顧客から送付されるデータの中には丁目や番地などが省略されているが、ランドマークとなるような有名なビル名がふくまれているデータなどが入っており、厳密な住所である前提での正規化などは困難であろうと判断しました。<h3 id="h8249b11277">発想の転換：完璧な自動化から半自動化へ</h3>上記について話し合いを進める中で、チームメンバーから「完全な自動化を実現しなくても、AIで候補を出してもらって、人間がチェックすれば良いのでは？」という提案がありました。 これは音声認識のコーパス作成で同様の手法（TTSで読み上げ→人間がレビュー）でサンプルデータを作った事例からの着想でした。 そこで完璧な自動化を目指すのではなく、「AIが候補を生成し、人間が最終確認する」という現実的なアプローチを検討することにしました。<h3 id="hcf83e1357e"> </h3>

<h2 id="h2ca338e16c">Anthropic Claude APIの活用</h2>様々なAIモデルを検証した結果、Anthropic Claude 4 Sonnetが最も良い結果を出しました。 少し工夫をした点としては、Prefill機能を使った確実なJSON出力の実現です。<h3 id="hcc690ded8a">実装の詳細</h3>プロンプトエンジニアリング 以下が実際に使用したプロンプトです：<pre><code>user_prompt = """あなたは日本国内の住所の文字列を処理するプログラムです。
住所リストの各住所を適切に処理してください。

出力は以下のJSON形式に従ってください:

[
 {
 "original_address": "元々の住所の文字列そのまま",
 "address_line_1": "住所の「丁目まで」の文字列",
 "address_line_2": "住所の「番地以降」の文字列",
 "address_line_3": "住所の「建物名・部屋番号」の文字列"
 },
 ...
]

住所リスト:
{ADDRESS_LIST}"""

# 重要：Prefillで配列の開始を指定
assistant_prefill = "["

</code></pre>

Prefill機能の重要性 Prefillを使わない場合、以下のような問題が発生します：<pre><code>// 望まない出力例1：Markdownのコードブロック
```json
[
 {
 "original_address": "..."
 }
]

// 望まない出力例2：余分な説明文
以下が処理結果です：
[
{
"original_address": "..."
}
]</code></pre>Prefillで <code>[</code> を先に出力させることで、これらの問題を回避し、純粋なJSONのみを取得できます。

実装コード例<pre><code>import anthropic
import json

def build_user_prompt(address_list: list[str]) -&gt; str:
 address_list_str = "\\n".join(f'"{index}. {address}"' for index, address in enumerate(address_list, start=1))
 return f"""
あなたは日本国内の住所の文字列を処理するプログラムです。
住所リストの各住所を適切に処理してください。

出力は以下のJSON形式に従ってください:

[
 {{
 "original_address": "元々の住所の文字列そのまま",
 "address_line_1": "住所の「丁目まで」の文字列",
 "address_line_2": "住所の「番地以降」の文字列",
 "address_line_3": "住所の「建物名・部屋番号」の文字列"
 }},
 ...
]

住所リスト:
{address_list_str}
""".strip()

def split_addresses(address_list: list[str]) -&gt; list[dict]:
 """
 Splits a list of Japanese addresses into structured components.
 
 Args:
 address_list (list[str]): List of addresses to be processed.
 
 Returns:
 list[dict]: List of dictionaries containing structured address components.
 """
 # Build the user prompt
 user_prompt = build_user_prompt(address_list)

 # Initialize the Anthropic client
 client = anthropic.Anthropic(
 api_key=os.environ.get("ANTHROPIC_API_KEY"),
 )

 # Replace placeholders like {{ADDRESS_LIST}} with real values,
 # because the SDK does not support variables.
 message = client.messages.create(
 model="claude-sonnet-4-20250514",
 max_tokens=8192,
 temperature=1,
 messages=[
 {
 "role": "user",
 "content": [
 {
 "type": "text",
 "text": user_prompt,
 }
 ]
 },
 {
 "role": "assistant",
 "content": [
 {
 "type": "text",
 "text": "["
 }
 ]
 }
 ]
 )
 # 結果の先頭に[を結合して、JSONとして処理する
 result_json_str = f"[{message.content[0].text.strip()}"
 result_json = json.loads(result_json_str)
 return result_json

# 使用例
parser = AddressParser(api_key="your-api-key")
addresses = [
 "東京都港区六本木6-10-1 六本木ヒルズ森タワー53階",
 "兵庫県神戸市中央区三宮町1-9-1 センタープラザ東館4階",
 "静岡県浜松市中区砂山町320-2 浜松メイワン8階"
]

results = parser.parse_addresses(addresses)

</code></pre>

<h2 id="hf4217128d1">実際の処理例と結果</h2><h3 id="h1d29343e7a">入力データ(サンプル)</h3><pre><code>1. 東京都港区六本木6-10-1 六本木ヒルズ森タワー53階
2. 兵庫県神戸市中央区三宮町1-9-1 センタープラザ東館4階
3. 静岡県浜松市中区砂山町320-2 浜松メイワン8階
4. 茨城県つくば市吾妻1-9-2 つくばセンタービル3階301号室
5. 長野県松本市中央1-23-1 松本市役所3階

</code></pre><h3 id="hba5a52a911">出力結果</h3><pre><code>[
 {
 "original_address": "東京都港区六本木6-10-1 六本木ヒルズ森タワー53階",
 "address_line_1": "東京都港区六本木",
 "address_line_2": "6-10-1",
 "address_line_3": "六本木ヒルズ森タワー53階"
 },
 {
 "original_address": "茨城県つくば市吾妻1-9-2 つくばセンタービル3階301号室",
 "address_line_1": "茨城県つくば市吾妻",
 "address_line_2": "1-9-2",
 "address_line_3": "つくばセンタービル3階301号室"
 }
 // ... 以下省略
]

</code></pre>

<h3 id="h3e3d3efde9">モデル比較</h3>ベースとなるプロンプトや生成結果の確認はAnthropicのWorkbenchの画面でプロンプトの内容やサンプルと期待する出力を様々なパターンを設定しながら確認しました。 精度がある程度高く、また一方で無用に高度なLLMモデルを選択するのもコスト面や処理実行時間面でももったいないので、いくつかのモデルを比較しました。 Claude 3.5 Sonnetと4 Sonnetを比較した結果：<ul><li>Claude 3.5 Sonnet: 単純に数字が始まったら分割するなど、判断が甘い</li><li>Claude 4 Sonnet: より正確な判断で、日本の住所構造を理解した分割が可能</li></ul>といった所もサンプルのデータからわかり、今回はClaude 4 Sonnetをモデルとして選択することとしました。

<h2 id="hbcad4da9f5">運用での成果と知見</h2>このようにデータを自動的にAIによって自動分割することで、従来は人間が一件ずつチェックして切り貼りが必要だったステップが、人間は目視でレビューをしていくだけで確認が可能になり、大幅に作業時間が短縮されました。 元々の生の住所もレビュー用のデータとして残すことで、ハルシネーションによってまったく異なる住所が出力されてしまっているようなケース(実際には発生していませんが)にも気がつけるようになっています。

<h2 id="h7dabb5418b">今後の展望</h2><h3 id="h661e3f122b">機能拡張の可能性</h3><ul><li>ランドマーク対応: 「東京タワー」「丸の内ビルディング」など、有名建築物の自動補完</li><li>表記揺れの統一: カタカナ/漢字、全角/半角の自動正規化</li><li>エラー検出: 明らかに間違った住所の自動検出とアラート</li></ul><h3 id="h462e03ef05">他業務への横展開</h3>この「AI＋人間レビュー」のアプローチは、住所処理以外にも応用可能です：<ul><li>商品カテゴリの分類</li><li>顧客データのクレンジング</li><li>ドキュメントのメタデータ付与</li></ul><h2 id="ha214098e44">まとめ</h2>日本の複雑な住所体系に対して、生成AIを活用した半自動化アプローチを実装しました。重要なのは、AIを「完璧な自動化ツール」としてではなく、「人間の作業を効率化するアシスタント」として位置づけたことです。 Prefill機能のような技術的なテクニックを活用することで、より確実で実用的なシステムを構築できました。この事例が、同様の課題に直面している方々の参考になれば幸いです。

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

生成AIを活用した住所分割の半自動化

Sogame Masato

今回のインタビューに登場するのはエンジニアの斉藤。「カオスを楽しみたい」と語る彼の真意に迫りました。

<h2 id="h5c4d85c8fd">PROFILE</h2>斉藤 涼介 広島大学卒業後、新卒で野村総合研究所にエンジニア職で入社。4年勤務後、Uターンで地元福岡に戻り、フリーランスやリモートワークでスタートアップ企業を経験。2025年4月よりAzitに入社。現在は、DeliveryXの開発に従事。

<h2 id="h3df065e5c5">成長を止めないために歩み続けたキャリア</h2>ー まずは、これまでのキャリアを教えてください。 生まれは北九州で、大学は広島大学の工学部です。卒業が近づいた時、就職するか大学院に行くかを迷ったのですが、野村総合研究所（以下、野村総研）のエンジニア職として採用されたため、上京して東京に行くことに決めました。 新卒1年目で結婚して、子どもが生まれました。その後も野村総研で勤務を続け、計4年間ほど働きました。 ー なぜそのタイミングで退職を決めたのでしょうか？ 優秀な人に囲まれた魅力的な職場ではあったのですが、SIerという業界的な特性もあって自分でコードを書く機会が少なくて。実際の開発は国内外のパートナー企業に託し、自分たちはスケジュールやプロジェクトの管理などが中心なんですよね。大きなシステムなのでやりがいはありましたが、実際の開発をしていない自分に対して、本当にエンジニアと名乗って良いのか？とモヤモヤする気持ちを抱えていました。 また、親や友達など頼れる人が近くにいない中での子育てにも限界を感じ、地元の北九州へのUターンを決めました。 ー なるほど。地元ではどういう働き方をしていたのですか？ 北九州って実は結構広くて、自分の地元は北九州の中心地である小倉まで1時間以上かかるような田舎の場所なんです。なので近くにIT企業がなくて。クラウドワークスを利用して、業務委託として自宅からフルリモート開発を行っていました。1年ほど経った時、業務委託を受けていた大阪の会社から正社員として打診をいただいたので、入社することに決めました。入社後もフルリモート勤務のままで開発させて頂けたのでありがたかったですね。 この会社では、社長が要件と仕様を固め、自分が開発・リリースするという二人三脚の小規模体制でした。最初は、ようやくエンジニアらしい開発ができていると充実感を感じて働いていました。ただ、開発フェーズはテストもコードレビューもない完全な1人開発だったので、少しずつチーム開発への憧れが強くなり、2年ほど働いた後に転職することにしました。 ー チーム開発への想いが強かったんですね。 そうですね。次に入ったのは、在庫管理のサービスを提供するスタートアップで、念願のチーム開発ができる環境でした。JiraやSlack、GitHubなどチーム開発ツールを活用しながらチーム開発できたのはすごく楽しかったです。また、実際にお客様の在庫管理の現場に足を運び、自分が開発したプロダクトを使っている所を直接見る機会があったことも、すごくやりがいに繋がりました。 ただ、最初は分からないことだらけの中の開発で、毎日成長を感じることができていたのですが、数年も経つと少しずつ自分の成長が鈍化していくのを感じてきて。ずっと同じプロダクトを開発していると、例えば要件を聞いた段階で「あのファイルをこう修正すれば実現できるな」ということが良い意味でも悪い意味でも大体分かってしまうんですよね。そうすると開発作業が単調作業に感じられてしまい、飽きてしまって。そこから新しい環境に挑戦したいという思いが強くなり、4年ほど働いた後に転職を決めました。 ー 「エンジニアとしての成長」が大きなポイントなんですね。 そうですね。元々エンジニアと言う職種に興味を持ったのも、常に新しい技術を学び続けたいという思いがあったので。あと、もともと性格的に飽きやすいので、開発が単調作業になった瞬間に興味が持てなくなっちゃうんですよね。経験した事のない新しいエラーやバグに揉まれてひいひい言いながら開発するのが好きなんです（笑）。

<h2 id="hf257fc914d">Azitで見つけた“楽しいカオス”</h2>ー Azitへの転職を決めた理由はなんでしたか？ 各企業が自分に対する推定年収を提示してくれる転職サービスを使っていたのですが、そこで提示された年収がAzitが一番高かったからです（笑）。と言うのは半分冗談として、Azitのスタートアップらしい雰囲気が面白そうだなと感じたからです。サービスとしてはまだ未完成だけど、野望はあるしこれから社会を変えていくぞという強い情熱を感じましたし、複数の投資家から出資を受けているという点も魅力を感じました。 ー 実際に入社してみてどう感じていますか？ 想像以上にカオスでびっくりしました（笑）。開発資料も最低限しかないしプログラムコードも整理されておらず古いコードが放置されてたり。ただ、意思決定にスピード感があるし、サービスの未来に対する期待感がある。過去に大きいピボットを経験しているだけあって、組織の柔軟性も感じます。 数ヶ月先の自分がどんな開発をやっているか予測がつかない。それは、リスクもありますが、飽き性で単調作業が苦手な自分にぴったりの職場だと感じてます。あとはセールスが強くて。0から仕事を取ってくる強い熱意があるので、自分もそれに応えて良いプロダクトを開発するぞ、という気持ちにさせてくれます。 ー 現在の業務内容を改めて教えてください。 今は、DeliveryXの開発を主に担当しています。最近では2段階認証やパスワード変更の機能を実装しました。Bizサイドから「こういうことやりたいんだけど、どう思う？」という上段から入って、要件を詰めて、設計して、実装して、リリースまでもっていくという開発の流れを一気通貫で経験できて楽しいですね。 DeliveryXのクライアントは自分も普段からお世話になっているような有名企業も多いので、それもやりがいに繋がっています。

<h2 id="hb1a53d410a">目標はつくらない。だから思ってもなかったところにいける。</h2>ー 今、入社して3ヶ月ほどですよね。特に充実した出来事はありますか？ 日々充実していますが、やはり先ほどお話した2段階認証のプロジェクトは印象的ですね。詳しくは<a style="color:#1155cc" href="https://love-from.azit.co.jp/article/delivery-x-two-step-auth" target="_blank" rel="noopener noreferrer">こちらの記事</a>に書いたのですが、要件定義からリリースまで１ヶ月以上かかりました。普通は新人にはなかなか回ってこない大型案件だったと思います。いわゆる上流工程から自分自身で旗を持って進めていくのはプレッシャーを感じつつも充実していました。 ー 課題解決の「課題」だけ与えられているような状態ですね。 まさに。それが1番楽しいですよね。もちろんそれが嫌だと言う人もいると思いますし、もっと要件を固めてから持ってきてほしいというエンジニアもいると思うんです。なので、あくまでも相性だと思うのですが、少なくとも自分にとっては楽しい働き方です。 ー どんな人がAzitに向いていると感じますか？ やっぱり、カオスを楽しめる人だといいのではないでしょうか。要件が曖昧なこともあるし、毎日状況も変わります。決められた通りに仕事したい人には辛いかもしれませんが、「課題を渡されて、自分で考えて形にしていく」ことが好きな人にとっては、最高の環境だと思います。 ー 先ほど「エンジニアとしての成長」の話がありましたが、今後Azitでどんな成長をしていきたいですか？ 長期の目標を明確に立ててそれに向かうというよりは、目の前の課題を1つずつクリアしていく、その連続の中で自然に成長していくのが自分には向いていると感じています。 野村総研の時、半年ごとに目標シートの記入と提出がありましたが、個人的にそれがあまりしっくり来てなくて。ゴールをイメージしすぎると、仕事がただのすごろくゲームみたいになってしまう気がするんですよね。ある程度のランダム性がある方が面白いと感じます。あまり遠い未来を細かく見すぎないようにしているというか、眼の前のことをしっかり楽しんで着々と実行していくことで、結果的に思ってもみなかったような遠い場所にいけるのかなと。 ー 最後に、これからのAzitに期待することはありますか？ もちろん物流・SCMのプラットフォーマーとして進化し続けることを期待していますが、一方で全く想像もしていない方向へ進化するのもそれはそれでAzitらしくて面白いなと思いますね。この変化の早い時代に適合し続けて欲しいなと思いますし、自分もそれを支えるべく開発し続けていこうと思っています。 インタビュアー：COO 山口 恭平、編集：坂井 華子

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

“成長”を止めない。カオスを楽しむエンジニアがAzitに来た理由

今回のインタビューに登場するのはEM・AIスペシャリストの岩瀬。新卒で考古学者になった彼がなぜ今Azitにいて、何を思っているのか話を聞いてきました。

<h2 id="h5c4d85c8fd">PROFILE</h2><h4 id="h2f96ba51e5">岩瀬 雄史</h4>大学で考古学を専攻し、卒業後は考古学者として遺跡調査の現場へ。約10年その道を歩んだ後、IT業界へ転身。SIerを経て、2024年10月にAzitに入社。現在はコンサルティング事業部のEMおよびAIスペシャリストとして在籍。

<h2 id="h01955f73c0">考古学者からエンジニアへ、異色のキャリアの真相とは</h2>─ 考古学からITへ、珍しいキャリアですよね。 はい。大学では考古学を専攻し、卒業後にそのまま遺跡調査の仕事をしていました。10年ほど続けた頃、30歳を目前にして「このまま続けていくのか？」と悩み始めたんです。色々と考えた結果、学生時代に考古学とどちらにするか悩んでやめたプログラミングを仕事にしてみようと決めてIT業界に入りました。 ─ 当時、エンジニア以外の業界は検討しなかったんですか？ もちろん、そのまま遺跡調査を続けていくことも考えたりしていました。もし別の会社に行くにしても、例えば博物館で働いたりなど、シミュレーションはしてみました。けど、難しいんですよね。考古学は好きなんですけども、仕事として割り切るのがなんだか辛いな、と思って。そこで、別の業界を考えました。 ─ IT業界は未経験だったということですよね？ そうですね。学生時代から将来考古学で食べていけなくなった時の潰しになればと触れてはいましたが、いわゆる業務経験はなくて。最初に入った会社は小規模で、何でも屋のような雰囲気でした。SES的な業務が主でしたが、所属していた部署はSI寄りのこともやらせてもらいました。 ─ その後、SIerに移ったんですね？ はい。小さな案件で経験を積むうちに、もっと大きなシステムに関わりたいという思いが芽生えてきました。そこで、金融系の大規模プロジェクトを扱うSIerへ転職しました。そこでは、7年ほど働きました。

<h2 id="h78df7a0a3d">想像できる未来は、選ばない</h2>─ Azitに来たきっかけを教えてもらえますか？ 実は当時、次もSIerで探していたんです。でも、「次に何をやるか」が想像できてしまって、あまりワクワクしなかったんですよね。想像がつく同じような毎日が続くだけだったら転職する意味がないのでは、と考えて一度リセットすることにしました。 そこで初めて自社プロダクトを持っている会社やスタートアップに目を向け始めました。その中でAzitと出会い「先が読めない感じ」に惹かれ、入社を決めました。 ─ 先が読めない、が魅力だったんですね（笑） はい。当時の自分は正直、少し考え方も凝り固まってしまっていたと思うんです。新しいことも受け入れられなくなってきている気がして、もう一度柔軟な発想ができるようになりたいと思うようになっていました。 スタートアップって、尖ってる部分もあれば、あまり整っていない部分もあって。そのいびつさが面白そうだなと。SIerだと、プロジェクトやお客様によってバラけると良くないので均一化していく文化がありますが、Azitは、型がないからこそ、自分の考え方ややり方を試せる。ここなら自分自身の幅も広げられると思いました。

<h2 id="hf1b1138cae">アンラーニングの苦しさと楽しさ</h2>─ 前職と比べて異なる業務に対して、チャレンジングだと感じることはありますか。 はい。とにかくプロジェクトの進め方も、仕事の進め方もこれまでとまったく違います。例えば、過去の職場では「それは良くない」と言われて避けていたようなやり方が、まかり通るというと語弊があるのですが、良い意味で型にはまってないからこそ成立する所があって。「こうしなきゃいけない」「プロジェクトはこう進めなきゃいけない」みたいな締め付けがないから、自由にできる楽しさはありますよね。 ─ 大変なことも多いのではないでしょうか。 プロダクト開発をしていても、数ヶ月でやることがコロコロ変わったりしますからね（笑）そんな短期間で変わるということは、今までにはなかったことです。 でも、必要に応じて変わっていけばいいと思っていて。むしろ変えることが推奨されている文化でもありますが、プロジェクトを進めていると「このまま進むと上手くいかないな」と見えている状況もあったりするので、考え方もやり方も違いますが、そうやってどんどん変化を起こしていくことに面白みは感じています。 ─ アンラーニングするのが1番大変だったポイントはありますか？ 大変だったのは、正直にお話すると否定から入ってしまう自分の思考パターンでした。前職では「まず仕様通りに作る」「変更には厳密な理由が必要」といった常識がありました。でも今は、まずやってみて、違ったら変える、という柔軟さが求められる。だから、考え方をアップデートし続ける必要があります。 どうしても「なんでやり通さないの？」みたいな思考が生まれてしまうんですよね（笑）やり通すということの意味と基準が違うということも、大きな学びだと思います。

<h2 id="h6d87a39262">「自分で手を動かせる楽しさ」をもう一度</h2>─ Azitが今後どうなっていったらいいと思いますか？ すごくシンプルですが「普通の会社」にはなってほしくないな、と思っています。この規模、この業界で、こういうメンバーがいるからこそ成り立っている面白さがあると思うんです。ありふれた会社になったら、面白くないなと思ってしまいます。 ─ そのために、必要なことはなんだと思いますか？ 先ほどの話にも近いのですが、新しいことに挑戦する姿勢を持ち続けることだと思います。一度満足してしまって同じやり方をずっと続けていくと、多分そのまま進歩せず枯れていくと思うので。やり方も、考え方もその時その時の状況に合わせて柔軟に変化することが大切かな、と感じています。 そして、年齢や役職に関係なく、意見が言える場を持つことも大切だと考えています。前職で、もともとそういった場があったのが、なくなってしまった途端、組織の風通しが悪くなった経験があるので、特に強く感じますね。 ─ 今、どんな40代を過ごしたいですか？ 20代と30代で培ったものを活かしつつ、新しいことに挑戦していけたら、それが理想だと思います。今、久しぶりにプレイヤーとして自分の手を動かして考えながら仕事をしていますが、それがすごく楽しいんですよね。 今AIを使ってデモを作ったりしてるのも、以前なら恐らく私は誰かに指示を出してスケジュールを管理して、とかそういう仕事になっていたと思うんです。自分で作るというのはなかったと思うんですよね。 ─ 最後に、どんな人と一緒に働きたいですか？ 私は反面教師のようですが…否定から入らず、相手の気持ちや考えをまず受け止められる人がいいのでは、と思います。小さな違和感やアイディアを拾って、育てていける人。Azitはそういう人が活きる場所だと思いますし、そういう人が増えたら、もっと面白くなると思っています。 インタビュアー：COO 山口 恭平、編集：坂井 華子

<h2 id="hda492ffe51">採用情報</h2>AzitではAIスペシャリストのポジションを募集しています。詳細は、以下の募集ページをご覧ください。 <a style="color:#1155cc" href="https://herp.careers/v1/azitinc/Xxe4VkvM-6vO" target="_blank" rel="noopener noreferrer">https://herp.careers/v1/azitinc/Xxe4VkvM-6vO</a> また、Azitではpodcastも配信しております！ぜひ聞いてください！

考古学の世界からITへ。「面白い」を追求する岩瀬が今Azitで考えること

今回お届けするのは、コーポレートチームの長田のインタビューです。様々な企業でコーポレート部門を経験した彼女が今Azitで何を思うのか、聞いてきました。

<h2 id="h5c4d85c8fd">PROFILE</h2>コーポレート 長田 陽子 複数の会社でバックオフィスを経験した後、2018年12月よりAzitに参画。経理、労務、総務などバックオフィス全般を担う。

<h2 id="hcb1e4023dd">「この人たち絶対楽しそう！」その気持ち一つで、入社を決意</h2> ー 今日はよろしくお願いします。 お願いします。慣れないので緊張しますね…皆さんのようにうまく話せる自信はありませんが、よろしくお願いします。 ー 最初に、Azitに入社する前のことを教えてください。 結構いろんな会社にいたんですよ。20歳のときに介護職としてグループホームで働き始めました。その後は、探偵事務所や人材派遣、マーケティングの会社などに勤めてきましたが、どの会社でも経理や労務総務など、バックオフィスを担当してきました。 ー Azitに入社するきっかけは何だったんですか？ 転職活動をしていたときに、求人サイトでたまたまAzitを見つけました。求人ページに掲載されていた写真が、社長（吉兼）と須藤さん（CRO）が笑っている一枚で、その写真がなんだか凄く印象的だったんです。それで気になってどんな会社か調べて、どんどん興味が湧いてきました。

ー 写真がきっかけなんですね。 そうなんです、本当に素敵な写真だったんですよ。2人が車のトランクか何かに寄りかかっていて、その笑顔がなんだか凄く自然で。胡散臭さがないというと少し語弊がありそうですが（笑）、とにかく「この人たち、絶対楽しそう！」と思って。それで応募を決めました。感覚としては一目ぼれですよね。 ー 入社してみて、その笑顔に嘘はありませんでしたか？（笑） 先日、全員で合宿をして集合写真を撮ったんですが、そのときの皆の笑顔が、当時の写真と同じような表情だったんです。入社の決め手になった2人の笑顔が、今は皆にも伝染していて。仲間が増えているんだな、と強く実感しました。そのとき「あ、この会社に入って間違いなかったんだな」って、改めて思ったんです。 以前社長がインタビューの中で『楽しさ』や『居心地の良さ』、『好きな人と一緒に何かができる』ことについて触れていたと思うのですが、それは私も同じ考えで、人生の中で会社で過ごす時間は短くないと思うので、楽しい・居心地が良いことに越したことはなくて、さらにそこで働く人たちを尊敬できたり、一緒に働けて嬉しいと思えたら最高で、社長と答えが一緒だ！って感じて、それがまた凄く嬉しかったです。

<h2 id="h2b30383f87">嬉しかった気遣いを、次の人へと繋げていく</h2> ー バックオフィスのチーム編成を教えて下さい。 現在は私含め2名です。私は経理・総務・労務を担当して、もう1名の方が財務・経営企画を担当しています。 ー バックオフィス全般を担う中で、大切にしていることはありますか。 Azitはトップダウンではなく、皆で組織を作り上げていく組織だと思っています。だからこそ、バックオフィスも体制や福利厚生、就業規則などを、皆の声を取り入れて作っていくことを大切にしています。 管理部が一方的にルールを決めるのではなく、皆の希望を聞きながらちょうどいいバランスを探していくことを大切にしたいですね。Azitは基本的にフルリモート・フルフレックスタイム制（職種による）の働き方が可能なので、ライフスタイルに合わせて働きやすい架橋に放っていると思いますが、さらにもう少し良くしていけたらいいな、と思っています。 少し話がそれますが、妊娠を上長に報告してから、上長が毎朝『長田さん体調どう？悪くなったら言ってね、俺やるからね』と声をかけてくれてました。その気遣いが嬉しかったのと、その言葉に助けられたのをよく覚えています。そういった気遣いを忘れないこと、相談されやすい人間になるというのは個人的に意識しています。 ー 今後、バックオフィスとして取り組んでみたいことや挑戦したいことはありますか？ そうですね、福利厚生を充実させたいとか業務の中でここ改善したい、みたいなピンポイントでは様々あるのですが。それよりは、Azitが今後こういう会社になったら良いなぁと思うことの方が大きいです。 私の密かな理想で、そうなるにはまだまだですが…もしかしたら他の人とは感覚が違うかもしれないですが、例えば震災などの有事の際に早い段階で被災地に対して何かしらのアクションを起こせるような会社になれたらいいなぁと考えていたりします。製造業ではないので食料そのものを届けることはできないけども、その配送ルートや配送方法を提案するといったことは可能なんじゃないかなと。とは言え震災時はネットワークが遮断される可能性もあるので何とも言えないですが、それでも何かしらのアクションを起こせる、とくに非常時や緊急時に組織力の強さを備えている会社になってほしいなと感じています。

<h2 id="ha49ff5122e">ピボットしても変わらない「Azitらしさ」</h2> ー 長田さんから見て、Azitはどういう会社でしょうか。 私が入社した当時はライドシェアサービスのCREWを運営していて、当時日本国内ではAzitだけが提供していました。事業内容を聞いて「クリエイティブで、新しいサービスや価値を作っていく集団なんだな」と、感じていたのを今もよく覚えています。そして今でも、その当時培った知恵を活かしながら、新たな挑戦をしている所が、やっぱりAzitらしいなと思っています。 今年で入社して7年になりますが、今も変わらず感じることは、みんなが「好きでやっているんだな」ということです。コロナ渦を経て事業内容は変わりましたが、事業に対する熱量は相変わらず高いし「これも提供できそう！」とAzitが提供できる価値を見つけたときの喜びようは見ていて微笑ましくなります。 Azitの事業を通じて社会に貢献したいという前向きな姿勢を持った人が多くて、そういう人たちからパワーをもらっています。 ー 今後人が増えるとしたら、どんな人が向いていると思いますか？ 給料や能力などの条件面だけを考える人ではなくて、Azitのやっていることが社会にとって意義があると感じてくれる方が良いなと感じています。『Aiztってここが良いよね』みたいなことを話せる方だと、一緒に働く上で心地よいかなと思います。 また、その人自身がバリュー含めAzitで働くことに違和感を感じないとか、馴染めそうとか、なんとなく相性が良いなとか、プラスの何かを感じれる方かな。私自身でいうと面接官と相性が良いとその会社とは合ってるなと感じたりします。 あとは、お互いの状況や考えを理解しようとしてくれる方でしょうか。人それぞれライフワークがあって、リモートワークの中相手の状況が見えにくい部分もありますが、お互いに助け合って思いやれる方たちが来てくれると、心温かい会社になると思っています。 インタビュアー：COO 山口 恭平、編集：坂井 華子

<h2 id="hda492ffe51">採用情報</h2>Azitでは各職種で採用を行っております。詳細は、以下のページをご覧ください。 <a style="color:#000000" href="https://recruiting.azit.co.jp/" target="_blank" rel="noopener noreferrer">https://recruiting.azit.co.jp/</a> また、Azitではpodcastも配信しております！ぜひ聞いてください！

「この人たち、絶対楽しそう！」一目惚れした会社で7年目の今、長田が感じることとは

こんにちは！ 今年の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

今回お届けするのは、1人目BizDevの西高のインタビューです。外資系コンサル企業からAzitに参画した背景を深掘りしました。

<h2 id="h5c4d85c8fd">PROFILE</h2>西高 寿紀 アメリカの大学を卒業後、デロイトトーマツコンサルティングに新卒入社。ITユニットにて経営管理支援に関する案件を経験した後、M&amp;Aコンサルタントとしてディールの交渉やBDD、組織再編の支援などを担当。2023年11月Azitに転職。現在は、BizDevとして営業企画、提案活動、プロダクト企画、プロジェクトデリバリーなどに従事。

<h2 id="ha7a17b0756">起業のために選んできたキャリア</h2>ー 大学はアメリカに行かれたんですよね。 はい。最初の2年はニューヨークの短期大学に通い、その後サンフランシスコの4年制大学の3年生に編入して2年。計4年をアメリカで過ごしました。 ー 就職のとき、そのままアメリカに残るという選択肢はなかったのでしょうか？ 高校生の頃から「東京で働きたい」と思いがずっとありました。本当は大学も東京に行きたかったのですが、偏差値が足りずアメリカを経由したんです（笑）。「アメリカに行きたい」とか「西海岸で働きたい」という願望があったわけではなく、東京に行くための手段としてアメリカを選びました。 ー 珍しいですよね（笑）。新卒の会社を選んだ理由は？ 高校生の頃からビジネスに興味があり、就職活動のタイミングで「ビシネスを俯瞰できる仕事ってなんだろう」と考えた時に、コンサルタントだと思ったんです。あと、大学ではファイナンスを専攻していたこともあり、金融にも関心がありました。ですが、机上の数値計算に留まらず、現場で人と接しながら仕事をしたいという気持ちが強かったので、投資銀行ではなく、コンサルタントを選びました。中でも、M&amp;Aユニットの規模が大きく幅広い案件に携われそうなコンサルがデロイトだったので、就職先として決めました。 ー なるほど。そこから転職を考え始めたきっかけは？ 最初に配属されたのはITユニットでしたが、入社前からM&amp;Aユニットに入りたいと思っていたのでパートナー陣にアピールを続け、3年目でやっとM&amp;Aユニットに入ることができました。4年目のタイミングで、半年以上かけて交渉から契約成立まで伴走する案件に従事したことで、M&amp;Aディールの一連のプロセスを経験することができました。一定程度M&amp;Aコンサルタントとして案件の経験ができたタイミングで、このままマネージャーに上がるか、他のキャリアを模索するか思案し始めたというイメージですね。 実は、高校生の頃からいつかは起業して経営者になりたいという思いがありました。このままM&amp;Aコンサルとしてキャリアを積めば、40歳頃にはパートナーになって、大企業の役員に転身する…という道も描けましたが、もっと早く経営に近い経験を積んでおきたい、という気持ちが強くなり、転職を決めました。 ー そのとき、なぜAzitを選んだのでしょうか？toBの領域でかつ、物流サプライチェーンというのはある意味マニアックでもあると思うのですが。 コンサルティング企業で様々な業界に触れていたからこそ、良くも悪くも業界は特にこだわっていなかったというのが本音です。toBだともともとのキャリアを活かしながら働けそう、という思いはあったのですが。その中で、転職の条件として「営業が経験できる、エンジニア組織であること、資金調達の経験ができる、10人程度の小さい組織」という4つの条件を意識していました。条件に合致する会社は複数ありましたが、決断の材料として一番大きいのは結局「人」です。人が良ければ、どんなドメインでもあんまり関係ないかな、と思っていました。 ー なぜそう感じていたのでしょうか？ コンサルティング業界は3~6ヶ月のPJごとにメンバーが招集されて、案件終了後は一緒に業務をすることが無くなったりするので、一緒に働く人の相性はあまり考えることが無かったのですが、事業会社の場合同じ人と働き続ける必要があるので、自分がこの人と一緒に仕事してしっかりパフォームできるかという観点は特に重視していました。

<h2 id="ha7ebb45452">事業会社だからこそプロダクトが届けられることが面白い</h2>ー 実際にこの業界に来て、率直にどう感じていますか？ Azitを選んで、ドメインに潜ってみて感じるのは「やっぱり物流・サプライチェーンは大変」というのが正直なところです。コストに直結する領域なので、クライアントから求められる要求が多い領域だと思うんです。だからこそ社会課題（2024年問題等）にまでなるのですが。 純粋に価値提供するだけだときっと足りていなくて。プラスαのチャレンジをし続けていかなくてはいけないドメインなんだと思っています。 ーなるほど。営業活動というのも転職して初めて経験していることだと思いますが、実際にやってみてどうですか？ 少し変な言い方になってしまいますが「ただ正論を言うだけじゃだめ」というのを強く感じますね。というのも、結局は人間力が大事だと…当たり前かもしれませんが。 例えばコンサルに依頼をいただけるときって、何かしら抱えている課題があって、コンサルに発注したいなって思えるほどに課題が膨れ上がっている状態なんですよね。ゴールが一定決まっているので、ある程度やることが決まってることが多いです。 ですが、今の仕事はもっと潜在的な課題を引き出す所が必要なんですよね。潜在的な課題を引き出すみたいなところとか、いかに自分たちのプロダクトがお客様にとっていいものだと思ってもらうという、啓蒙活動みたいなところから入るっていうのは、今までやってこなかったのでギャップに感じましたし、難しい所だなとは思いました。だからこそ、それを伝えるには人間力は欠かせないなと思っています。 ー 実際体験してみて感じたことはありますか？ やっぱり、ちゃんと形になる所は面白いですよね。具体のプロダクトを提供できるのって、素直に面白いな、と。それはコンサル時代から感じていたことで、戦略コンサルで描いたものが叶うのって、実際に5年、10年かかるようなこともありますし。それに比べてM&amp;Aコンサルは、必ず実行を伴う戦略案件なんですよ。絶対形になる。買うか売るかまで行くので。そこまで見届けれるっていうのが楽しかったという所もあり、やっぱり事業会社ってプロダクト持ってるので、ちゃんと提供できるというのは面白さを感じていますね。

<h2 id="h26a89195cd">インプットや気付きを組織に届けられるようなチームを目指して</h2>ー 環境が大きく変わったと思いますが、そのあたりはどう感じていますか？ 同じロールの人がいないことが、逆に面白いと感じています。10人以下のチームに入るというのはそういうことなんですよね（現在は10名を超えています）。コンサルの時は、同じ能力・同じ役割を持ったメンバーでチームを組んでそれぞれが分担して進めるというスタイルでした。でも、事業会社来て思うのは、みんなロールもスキルもバラバラで、だからこそそれぞれの強みを活かしてチームアップしてデリバリーするというのは、自分の中では新鮮な感覚でした。 替えが効かない責任感という感じですかね。事業会社には、自分がいなければ成しえないロールや役割があって、それで結局最後お客様の価値につながるっていうところは、やりがいがあっていいなとは思いますね。 ー 働き方も大きく変わりますよね。 本当にそうですね。丸の内のオフィスビルから、恵比寿の住宅街のマンションがオフィスになったり。スーツじゃなくてパーカーになりましたし（笑）前職はオフィスに行けば顔の知らない1,000人以上がフリーアドレスで働いたり、クライアント企業に常駐したりと疎外感と言うかアウェー感を感じていたんですね。人数が少ない中で皆で肩寄せ合って頑張る所は、僕にとってはかなりいいギャップです。そういう方が好きだな、と思えるんですよね。 ー 今は1人BizDevですが、これからチームとして拡大していく上で、どんなチャレンジがあると思いますか？ そうですね。Azitの特徴として「このソリューションで勝負するぞ！」と一つに絞り込むよりも、ある程度目指す方向を定めながら、そこに向かって広く“芽”を探して育てていく、という感覚があるんですよね。 だからこそ、チームとしてはインプットや気付きを組織に届けられるようなファンクションにしていきたいと思っています。ニーズを拾ってくることもそうですし、リサーチを通じて新しい発見をもたらすことも。そんな役割を担えるチームにしていけたらいいですね。 ー 今後、どういう人と一緒に働きたいと思いますか？ AzitのVALUEにもありますが「LOVE &amp; RESPECT」が体現できる人がいいなと思います。仕事仲間を思いやって、皆が働きやすい空気を自ら作れる人だと、すごくポジティブだなと思っています。 ー 最後に、西高さんがチャレンジしていることを教えてください。 僕個人が思っていることは入社当時から変わっていないのですが、自分の給料の十倍の売り上げを会社にもたらすっていうのは、目標としては一応考えてはいます！ インタビュアー：COO 山口 恭平、編集：坂井 華子

<h2 id="hda492ffe51">採用情報</h2>AzitではBizDevのポジションを募集しています。詳細は、以下の募集ページをご覧ください。 <a href="https://herp.careers/v1/azitinc/Nl-SKbkB0UjK" target="_blank" rel="noopener noreferrer">https://herp.careers/v1/azitinc/Nl-SKbkB0UjK</a> また、Azitではpodcastも配信しております！ぜひ聞いてください！

「プロダクトを届けられるのって、シンプルに面白い」コンサル出身の西高が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ではサーバーサイドエンジニアを募集中です。ご興味をお持ちいただけましたら以下の採用サイトからご応募下さい！

Pick Up!

Hashtags

Latest Articles