<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に来た理由

Love from 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で感じること

今回お届けするのは、サクセス部の部長 兼 パートナーアライアンス室 室長を務める足立のインタビューです。1号社員として創業初期のAzitに参画してからピボットを経て今に至るまでを深掘りしました。

<h2 id="h5c4d85c8fd">PROFILE</h2>足立れいき <a style="color:#000000" href="https://x.com/reikixs " target="_blank" rel="noopener noreferrer">@reikixs</a> 大学在学中のインターンで現CEOの吉兼と出会い、法人化前のAzitに参加。2015年 株式会社リクルートホールディングス（現：株式会社リクルート）に新卒入社。その後、再びAzitへ合流。

<h2 id="h4aa4a168af">とにかく前を向き続けるチーム</h2>— Azit1号社員でしたよね 当時はライドシェア事業を開始した時期で、それこそ1日1回使われるか使われないかくらいだったと記憶しています。役割としては、それまでの経験もありマーケティング職として入社しました。 — 入社当時のAzitはどのような状況でしたか？ 前進していくぞという空気感が強かったです。平均年齢25歳とかだったので、言ってみれば小難しく考え込めるほどの経験もなく、Aと決めたら「Aだ！」Bと決めたら（以下同文）の様な勢いで会社が前進していたと思います。 — マーケティング職とのことですが、当時の仕事内容について教えてください 最初は広告運用や、初回利用体験の改善みたいなところから始めました。そのうち、ドライバー側の集客とオンボーディングが課題となってきたので、オペレーションのフロー化を始め、CRM導入や運用体制の構築を行いました。ドライバーの皆様に対応いただく必要書類の提出の電子化などもやっていましたね。今思うとDXっぽいですね。 事業が伸びるにつれて、チームが大きくなってきたので、マネジメントに加え、ブランド方針策定から施策の実行までをやっていました。 ー 整理解雇もありましたが、Azitに残ろうという決断の理由はなんですか？ たしかに。整理解雇を経たからといって残留する義務が生じるわけではないので、辞めてもよかったですし、それを阻止するような雰囲気もありませんでした。 言われてみて考えると、私としては大学時代の知り合いのチームに再合流したと捉えていたので、「Azitに“転職”した」という感覚はあまりありませんでした。なので、辞めるとか他に移るっていう選択肢が浮かばなかっただけな気がします。 また、たまに質問されるのですがキャリア面でのリスクについては、スタートアップが訝しがられていた時代からずっと、リスクなしと判断しているのでそこの恐れは当時もなかったです。 ー その後ピボットをして苦労してきましたよね Azitはその時点でtoC事業の経験のみを持っていたチームでした。なので、今のDeliveryXをはじめとするtoB事業に求められる考え方や所作・振る舞いを分かっていませんでした。その学習にとても苦労したなと思っています。事業を成長させるためには自分たちが変わらないといけなかったこともあり、結果変われたという実感はあります。でも、やり直せるならもっと短縮できるんじゃないかと思う点は多いですね。 ー その中で、役割はどう変わったのでしょうか ライドシェア事業の頃はマーケティング職で入り、ブランディング全般も担うようになりました。オペレーションマネージャーもやっていましたが、いわゆるマーケティング部のマネージャーという役割だったと思います。 一方で、ピボット後はいわゆる広告宣伝みたいな機能は設けずにセールスによる企業獲得が主軸になりましたし、ブランディングについても優先度は落ちたので、オペレーションマネージャーの役割をメインに動きはじめました。 主なミッションとしては、クライアントの配送に関わる業務フローをDXしてやれることを増やす、売上を増やすということでしたので、過去の経験含め上手く自分のケーパビリティを活用できた気がします。 事業が成長するにつれて、DXができたあとに、「荷物誰が運んでくれるんだっけ」という局面で困るクライアントが増えてきたので、その課題を解決するためにフードデリバリー各社とシステム連携を行い、サービスを拡充していきました。その中で、各社とのアライアンスのミッションを持つことになり、提携の条件交渉と契約締結までなどアライアンス業務が増えてきました。この時点で、狭義のマーケティング職とは少し違う役職になったと思います。 ただ、今は、クライアント企業のサクセスの責任も併せて持っており、これは結局のところ「配送網拡大により売上を上げたい荷主」と、「荷物をたくさん運びたい配送ネットワーク」を結びつけることなので、本当の意味でのマーケティングであると感じています。

<h2 id="h62bc43f01f">ステークホルダーの機微を見逃さない</h2>ー Azitのサクセス / パートナーアライアンスとして重要なことはなんですか？ 顧客の努力を無駄にしないことです。 私達は配送手配のアグリゲーターサービスを展開しています。この事業では、「複数の事業者の取引規格を統一し、売り手と買い手の流動性を上げる」ということが重要なのですが、ここで各事業者を統一規格に“押し込めて”しまうと、その統一規格自体がボトルネックになってしまいます。 例えば、配送ネットワークのうち一社が「荷渡し時のサイン機能」を一生懸命開発して利用可能にしたとしても、私達アグリゲーターがその機能を開放しないと、荷主もそのオプションを選べません。 逆も然りです。荷主が「配送効率化のため、荷物の到着期限を3日まで延長しました」といっても、アグリゲーターが当日配送しか規格をもっていない場合、荷主の企業努力が無駄になってしまいます。 たとえそれが私達からニッチに見えたとしても、たった1社のみの 機能 / 対応 だったとしても、それが必要かどうか判断するのは本来アグリゲーターではなく 配送ネットワーク / 荷主 のはずです。 それに、アグリゲーターがそのような振る舞いをしてしまうと、参加している各社の企業努力による 商品改善 / 要求緩和 を無意味なものにすることになります。結果として、業界全体の熱を冷ますことにつながると思っています。 日本ではまだまだデリバリーの利用が少なくポテンシャルもある分、業界全体でできることを増やし、市場を立ち上げていかなければいけません。 なので、荷主と配送ネットワークに互換性をもたせることは当然として、双方の制約を1mmでも取り払うことがDeliveryXの使命だと思っており、大切にしています。 ー その中で仕事を進める上で決めていることは 実現可能性の担保から逃げないことです。DXって、理論上技術的にはどんなことだって実現できるのですが、そういった一見夢膨らむ話をしているときに、クライアント出席者のうちの一人の表情が曇ってたりすることがあって、そういうのを見逃さないようにしています。 会議室全体は両社ともに夢が広がって大盛り上がりなのですが、きっとその人にだけ見えている、実現ハードルや懸念点があると思うんですね。その時に、きっとここを気にしているだろうなっていうのが感じられることがよくあります。 その場でぱっと解決策を伝えてもいいし、「こういう懸念がありますよね、そこは放置しません」と伝えるのでもいいんですが、そういうところから逃げずに全員が前向きな気持でプロジェクトを進められるよう、実現可能性が高い状態の担保を大切にしています。

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

キャリアを越境して必要なことを。Azit足立の現場視点

今回お届けするのは、バックエンドエンジニア 萩原のインタビューです。「その時代に合わせて適応していく」と語る彼が今考えるAIとの向き合い方について、COO山口が読者の視点に立って深堀りしました。

<h2 id="h5c4d85c8fd">PROFILE</h2>萩原登 バックエンドエンジニア 1984年愛知県生まれ。ECサイト開発、WEBメディア、フリーランス、法務系スタートアップでの経験を積む。現在はAzitのバックエンドエンジニアとして、ビジネス要件の技術的実装から運用までを担当。AI活用による開発プロセスの効率化に関心を持ち、時代の変化に「適応」することを重視。

<h2 id="he8c51a2c75">世の中に適応していくために「まずは触ってみる」</h2> ー 最初にプログラミングに触れたのはいつのことでしょうか。 小学生の頃です。当時、家にPC-98という古い国産マシンがあったんです。あと、当時を経験した人なら分かると思うのですが「マイコンBASICマガジン」という雑誌がありまして…そこに書かれたプログラムを打ち込むと、何かしら動くものが作れるんです。そうやっておもちゃとして遊んでいたのが、プログラミングに触れたきっかけです。 ー 当時、普及率としては珍しかったのではないでしょうか？ 1990年代前半なので、パソコンは普通に売ってはいたけど、家にあるかっていうとちょっと人による所ではあったと思います。学校ではコンピュータールームやコンピューターの授業もありました。まだ始まったばかりくらいの時代ですが。インターネットよりは少し前の時代ですね。 その後、中学に入ってからもパソコン部はありましたが、当時は何かゲームを作ったりするよりも、ゲームで遊んでいることばかりでした。 なので、そこからいきなりエンジニアを目指したり「将来これをしよう」と決めていたということはなかったというのが正直な所です。当時から触れていたことで、自然と馴染んでいった感じです。 ー 社会人になり、ファーストキャリアからエンジニアなんですか？ そうですね。大学を中退したあと、25歳ぐらいまでは公認会計士試験の勉強をしたりしていました。結局それは諦めて、その後就職したのがファーストキャリアです。当時ネットゲームの知り合いが募集していた求人で、ECの会社に入り6年ほど過ごしました。 ー 公認会計士からエンジニアというのは、結構振れ幅の大きな決断だったと思います。 そうですね。何かしら仕事をしなきゃと思った時に、一番できそうだったっていうのがプログラミングだったんですよね。今と環境が違って、当時はプログラミングができれば仕事はあったというのが正直な所です。そんな始まりでしたが、だんだんプログラマーの立場が分かってきて、なんだかんだそのまま居座ってしまいました。 ー そこから割と様々な業界を経験されていますよね。 そうですね、ECから始まり、ライフスタイルのWEBメディアだったり、フリーランスを経験したり、法務系スタートアップにいたり、その後現職のAzitにきて。そんな感じなので「この業界をやりたい」っていう強いこだわりがないというのは、確かにあるとは思います。 もともと公認会計士を勉強していて、若干抽象的にビジネスを見るというか、仕組みを見たり、お金の流れを見たりっていうのが好きなので、様々な業界にいるというのはあるかもしれません。 ー なるほど。ご自身では自分のことをどういうエンジニアだと思ってますか？ エンジニアとしてというよりは仕事全般ですけど、「適応」を重視していますね。特に最近のAIも「これは触って適応していかなきゃいけない」と感じる気持ちは強くて。 何にしろ、自分で触ってみるのは結構大切だと思っています。ブロックチェーンにしろAIにしろそうなんですけど、意外と皆触ってなかったりするんですよね。そこで触って感覚を掴むだけでも、アドバンテージになり残るものが手に入ると思っているので、そういう意味で触っていこうと決めています。

<h2 id="hbca82ca24e">AIと共に進化する開発体制</h2> ー 現在の業務について教えてください。 &nbsp;バックエンドエンジニアとして、ビジネスの要件を技術的に実現することを主な業務としています。ビジネス側からの要望を受け、それを要件に落とし込み、実装から運用までを担当しています。 ー いま挑戦していることはなんですか？ &nbsp;AIをどうやって使っていくか、ということに尽きます。理由は明確で、私たちのようなスタートアップでは、小規模で大きなプロジェクトにチャレンジする。ということが多いからです。複数の企業で経験がしてきましたが、特に小さな企業ではチームビルディングは常に苦労してきました。採用活動を強化するのも1つのアプローチですが、AIをうまく活用することで、課題解決の一助になると感じています。 ー AIを使った開発体制の変化についてどう考えていますか？ 本質的にはそんなに変わらないと思ってますが、小さなプロダクトを作って、使って、作り捨てるみたいなことは簡単にできるようになると思います。&nbsp; 小さいチームで高速にプロダクトを作るというのは流行っていきますよね。本当にコストが10分の1、あるいは100分の1になる可能性がありますし。ただ、やはり大規模にサービス展開しようとなると、まだまだAIだけではできないのことも多いので、人の力が必要だと感じています。 ー Azitの場合だと、スモールなチームでのプロダクト開発が増えて当たり前になっていきそうですね。 そうですね。機能ベースで生まれて付け足していった時に、サービス全体として統合するとなったら、やはり人間が入らなくてはいけないシーンもあると思います。フィードバックを持って手元で開発するってなったら、やっぱりまだ人間が必要で。なので、教育とかそういうところを除けば、そういった分かれ方をするのかなと思っています。新規の案件ベースで作って、ある意味スモールに使い捨てになるようなサービスを作っていくチームと、統合してサービスとして作るチームに分かれるかもしれませんね。 ー Azitのプロダクトチームは主にリモート体制ですが、今後どうなっていくと思いますか？ 私自身今愛知に住んでいますが、AIを活用していけばいくほど、結局残るのは人間同士のコミュニケーションになるので、リモートで完結できない仕事の重要性が相対的に上がると思います。それこそ、もし全国各地にいるなら小さいリモートチームが日本全国あるっていうスタイルが増えるかもしれないですね。2、3人になれば、名古屋チーム、大阪チーム、九州チームみたいなのもあるかもしれないですし。 ー 萩原さん自身が本社のある東京に住む日も近いということでしょうか…？ 適応という形で必要なら出社、引っ越しもあるかなという感じですね。今の大学生は、一番AIネイティブ世代になると思っていて。その5年後ぐらいになると、もう体の芯までAIに浸かった大学生になるはずです。今でもAIはありますけど。でも大学4年間、今のAIやそれ以上のレベルのAIに触れてきた人たちが社会に出てきて、例えばベンチャーを起業するぐらいになると、また違う世界が見えるかなとは思ってます。ちょっとどうなるかはわからないですが。

<h2 id="h3fffc9597c">自然と取り入れるマインドセット</h2> ー どんな方にAzitに入社していただきたいと考えていますか。 直近で私個人の希望で言うと、一緒にAIを使った開発フローの掘り下げをやりたい、と言ってくれる方が一番嬉しいのですが。 全体的な視点で言うと、まだAzitやDeliveryXは運用フェイズではなく試行錯誤してサービス改善を推し進める段階です。それを受け入れて一緒に成長・完成させたいと思ってくれる方がいいなと思っています。もしかしたら、半年後には別のことをやっているかもしれないんです。そういった部分も含め、柔軟に受け入れてくれるタイプの方だといいですね。そういう開発フローを作ること自体が財産というか、価値に感じて楽しんでいただける方だと嬉しいです。 ー 少し広い話ですが、AIの台頭をエンジニアとしてどう見ていますか？ 「AIでエンジニアいらなくなる」なんて言われますけど、そんなことはしばらくなさそうです。今はパソコンがあれば何でもできるじゃないですか。でも、実際に手を動かし価値を届けることのできるエンジニアはまだまだ多くはありません。例えば今後10年ほどで、本当にエンジニアがいらなくなる時が来るかもしれません。その時は社会の仕組みも変わっていると思うので、その時に合わせて適応していきたいと思っています。 ー そのときこそ「感性」など人間的なものが大事になってきますよね。 そうですね。仕事の密度はAIによってどうしても上がっちゃうので、難易度が上がっていくと思うんです。ちょっと言い方に迷いますが、何も考えずに作業をして、資料を作ったりする時間ってあるじゃないですか。そういうのがAIで全部なくなっていくので、その分仕事の密度は上がっていくと思います。それはいいことばかりではないかなって思うこともなくはないんですよね。 人間、本当に集中して創造的な時間を1日8時間週5日で過ごせるかと言ったら、ほとんどの人が無理なんじゃないかと思っているので。 ー わかります。AIを使い始めて、自分で情報を頭で考えて整理して出力するよりも、レビューする数が異様に増えてレビュー疲れが発生している気がします… そうですね。同時並行ができすぎるので、同時にやり過ぎちゃって、実はパフォーマンスが悪いとかもあり得るので、タスク管理はもうAIに全部任せちゃうっていうのが、割と今後行く道かなと思ってます。 AIのアウトプットを読み込んで決断する仕事しか残らないって、それで1日8時間働けますかって言われたら、めちゃくちゃタフですね。 ー 最後に、これからの人生の目標はありますか？ しばらくはAIの発展を見守りながら、エンジニアとしてその進化を追いかけていきたいと思っています。実際に、今動いている技術や、これから来るものを見据えながら、どこまでAIが進化するのかを追いかけることに個人的な興味があります。せっかくエンジニアをしているので、その進化を実感しながら仕事をしていきたいですね。 インタビュアー：COO 山口 恭平、編集：坂井 華子

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

「その時代に合わせて適応していく」エンジニア萩原の、AIとの向き合い方

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