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

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