-実際に作り運用するときに知っておきたい技術・知識- レアゾン・ホールディングス 2025年新卒エンジニア アプリケーション基礎研修

はじめに

こんにちは！2025年新卒エンジニアの三幡です。私は大学に在学しながら、1年間42Tokyoというエンジニア養成機関でプログラミングを学び、さらに1年半ほど、スクレイピング事業を展開する企業でサーバーサイドエンジニアとしてアルバイトをしてきました。今年2月中旬には内定者インターンを経て、レアゾン・ホールディングスに入社しています。

この記事では、2025年新卒研修のアプリケーション基礎講義（後半）で取り上げられた、「実際に作り運用するときに知っておきたい技術・知識」についてまとめます。認証・認可の基本から、アーキテクチャ設計、データベースやストレージの選定、アクセシビリティやオブザーバビリティ、ローカライズ対応、サービス立ち上げ時のMVP（Minimum Viable Product）開発、サービス運用時の障害対応、他職種との連携に至るまで、実務で役立つ幅広いポイントをご紹介します。

🛡️ 認証認可

Webサービスにおいて、ユーザーが安全にサービスを利用できるようにするために欠かせないのが認証と認可の仕組みです。この二つは混同されがちですが、その役割は大きく異なります。

認証と認可の違い

認証（Authentication）は「その人が誰か」を確認するプロセスです。たとえば、会員サイトへのログイン時にユーザー名とパスワードで本人確認を行うのが認証です。

一方、認可（Authorization）は「その人が何をできるか」を制御する仕組みです。たとえば、VIP会員だけがアクセスできるページに対して、ログイン済みユーザーがその権限を持っているかを判定するのが認可です。

Basic認証

Authorizationヘッダーに「Basic 」を設定する認証方式です。サーバーは受け取った値をデコードし、ユーザー名とパスワードが正しいかを確認します。シンプルで導入しやすい反面、ユーザー名とパスワードが平文で送信されるため、通信が暗号化されていない場合は盗聴や改ざんのリスクがあります。

Bearer認証

Authorizationヘッダーに「Bearer 」を設定する認証方式です。このtokenを利用することで認証を行います。多くの場合、このtokenにはJWT（JSON Web Token）が利用されます。

JWTの仕組みと検証

• JWTは「JSON Web Token」の略で、「ジョット」と発音します。
• トークンは <header>.<payload>.<signature> という3つの部分で構成されており、それぞれJSONをBASE64URLエンコードした文字列です。
  • header部: アルゴリズムやトークンのタイプなど、署名のためのメタ情報を持ちます。
  • payload部: ユーザーIDや有効期限など、認証・認可に必要な情報（Claimsという）を含みます。
  • signature部: header部とpayload部を秘密鍵で署名した値で、改ざん防止の役割を持ちます。
• トークン例：
  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
• JWS(Json Web Signature)の仕組みを用いて、JWTの改ざんを検知する
  • JWTの中身はBasic認証と同様に簡単に閲覧でき、また改ざんも可能です。そのため、パスワードなどのセキュアな情報を含めてはなりません。
  • 秘密鍵でJWTトークンに署名（signature部を生成）し、公開鍵で正しく復号できるかを確認することで、トークンが改竄されていないかを検証します。
  • このように、あくまで改ざんを検知するのが主な目的であり、JWTそのものには不正な通信を自動的にブロックするような機能はないことに注意が必要です。

アーキテクチャ

良いアプリケーションは、コードレベルからインフラレベルまで、一貫性のある設計思想に基づいて構築されています。これにより、変更に強い柔軟性のある成長性のあるシステムとなります。

📄 ファイルレベル

読みやすいコードを記述します。

• リーダブルコード: 読みやすさを重視することで、将来の機能追加やバグ修正が容易になり、保守性が向上します。
• 名付けへのこだわり:
  • ファイル名、関数名、変数名には、その役割や振る舞いが一目で分かるように工夫することで可読性が向上します。
  • 関数や変数は「何をするか」「どう振る舞うか」を意識して命名することで、コードの意図が明確になります。

📂 ディレクトリレベル

どこにどのようなコードが書かれているかを分類します。プロジェクトの規模が大きくなるにつれて、コードがどこに書かれているかを分類し、整理するルールが不可欠になります。

• 機能ごとやサービスのドメインごとに分類を行うのが一般的です。
• チーム内で分類ルールを共通認識として持つことが、コードの探しやすさや理解のしやすさに直結します。
• パターン例:
  • MVC（Model-View-Controller）
  • レイヤードアーキテクチャ
  • オニオンアーキテクチャ

🏭 インフラレベル

コード以外の観点で、サービスのデプロイやサーバー・データベースの構成を設計します。

• インフラ構成図の作成
• ネットワークや各コンポーネントの接続関係を整理する
• セキュリティや可用性（システムが停止することなく継続して利用可能な状態）も考慮する

🗄️ データベース選択

データを永続的に保存し、必要に応じて高速に検索・取得できる仕組みは、ほとんどのアプリケーションに必須です。

• データベース

  • データを永続的に保存する仕組みであり、データの整合性や検索性が高いのが特徴です。
  • RDBやNoSQLなどの種類があります。

• キャッシュ

  • 頻繁に使うデータを一時的にメモリなどに保存する仕組みです。
  • データの読み取りが特に高速に行えます。
  • 揮発性があり、永続的な保存には向きません。

👥 Accessibility

誰もが等しく情報にアクセスできるように配慮し、誰一人取り残さないデザインのことを指します。
アクセシビリティに配慮したサービスは、以下のような方々にも使いやすく設計されています。

• 視覚に障害がある方
  • alt属性を必ずつける
    • 音声読み上げ機能が画像の内容を補助します。
      • 例：<img src="car.png" alt="自動車">
  • コントラスト比や読み上げツールが使いやすい構造にする（aria属性など）
• 身体に障害がある方
  • Tabキー操作時に自然なフォーカス移動を設計するなど
• 高齢者
  • 理解しやすいUI設計や文字サイズの変更機能を提供する
• Web開発
  • 意味的なHTMLタグ（例：<header>, <nav>, <main>, <footer>, <section>, <article>など）を適切に使うことが重要です。
    • これにより、スクリーンリーダーや検索エンジンがコンテンツ構造を正しく理解できます。
    • Lighthouse などのツールでアクセシビリティ評価が可能です。
• ネイティブアプリの場合
  • Apple製品のVoiceOver（音声読み上げ機能）や、Android製品のTalkBack（Google製の音声読み上げ・ユーザー補助機能）などのスクリーンリーダーに対応する

👀 Observability

サービスの稼働状況や異常をリアルタイムで監視するための仕組みです。DatadogやCloud Traceなどの監視ツール、Slackへの自動通知などを活用し、システムの状態や障害発生時の情報を取得するための環境を構築しています。エンジニアは、サービスが常に正常に動作しているかを意識し、問題発生時には迅速に対応できる体制を整えることが重要です。

🌏 LocalizationとInternationalization

Global化のために

• Internationalization（i18n）

  • 多言語対応や地域ごとの差異に柔軟に対応できるよう、あらかじめ仕組みを整えておくことを指します。
  • 一例として弊社では、Slack上で日本語と英語の翻訳を自動で行う「ReazonTranslator」というアプリが開発されるなど、日々グローバル化を支える基盤の整備が進められています。

• Localization(L10n)

  • 具体的な地域や文化に合わせて、翻訳や表示形式の変更、文化的要素の調整などを行うことを指します。
  • 一例として弊社では、アプリ「ブルーロック Project: World Champion」のグローバル版(英語)が2024年4月にリリースされ、今後は繁体字・簡体字・フランス語へのローカライズも順次進められる予定です。

🚗 MVP（Minimum Viable Product）開発

MVP開発とは、「提供したい価値」に集中してサービスを構築・開発することを指します。ユーザーが抱える課題を解決するために、最小限の機能でプロダクトを開発し、その価値を検証していくアプローチです。

以下の図では、ユーザーが「移動したい」というニーズに対して、最初から車を目指すのではなく、まずはスケートボードや自転車のような、より簡易な手段を提供することでニーズを満たしています。

画像引用元：https://www.ankr.design/designtips/making-sense-of-mvp

研修では「ユーザーからの問い合わせに基づいて、AIがおすすめの花束を提案するWebサービス」を題材に、MVPのあり方を考える課題が出されました。

回答例として、「AIを使わず、花屋などの専門家が花束を提案する」という案が挙げられました。サービスの初期段階では、そもそもユーザーがどのような提案を求めているのか、ニーズが存在するのかといった検証が重要です。そして多くの場合、ユーザーが本当に関心を持っているのは「どんな花束が届くか」であって、その提案プロセスにAIが関与しているかどうかは、本質的な価値とは言えません。

エンジニアとしては、ついAIのような先進的・技術的に魅力のある手法に注目してしまいがちです。しかし、プロダクトの価値を検証する段階では、それが過剰な開発（オーバースペック）になってしまうことも多いため、まずは「シンプルに価値を届ける」ことを重視する必要があります。

サービスを運用する

🚨 障害対応

サービスを運用する以上、常にユーザーの利益を考える必要があります。障害が発生している間は、ユーザーにとって本来得られるはずの価値や利便性を奪ってしまっている状態です。そのため、障害にはできる限り早く対応し、影響を最小限に抑えることが求められます。

🤝 エンジニア以外の職種との協働

サービスは、エンジニアだけで完結するものではありません。デザイナー、カスタマーサポート（CS）、営業、運営など、さまざまな職種の方々の力があってこそ、ユーザーに価値を届けることができます。

だからこそ、他職種への感謝を忘れず、「チーム全体でサービスをつくっている」という意識を常に持つことが大切です。その上で、自分がエンジニアとしてどう貢献できるのか、どのように価値や利益を生み出せるのかを考え続ける必要があります。

研修の最後に行われたハッカソンでは、デザイナーを加えたチームで開発を行いました。その中で、デザイナーの手が加わることでプロダクトの魅力が一気に引き立ち、プロダクトとして垢抜けた印象になり、完成度が格段に高まることを実感しました。

まとめ

今回は、2025年新卒研修のアプリケーション基礎の中で、「実際に作り運用するうえで知っておきたい技術・知識」についてご紹介しました。技術的な内容にとどまらず、サービス開発・運用の現場で本当に求められる、より広い視野や実践的な知識に触れることができました。この研修を通じて、単にコードを書くだけではなく、ユーザーに本当に価値を届けるためにはどうすべきかというプロダクト思考を重視するレアゾン・ホールディングスという会社の姿勢が感じられました。

---

▼採用情報

レアゾン・ホールディングスは、「世界一の企業へ」というビジョンを掲げ、「新しい"当たり前"を作り続ける」というミッションを推進しています。

現在、エンジニア採用を積極的に行っておりますので、ご興味をお持ちいただけましたら、ぜひ下記リンクからご応募ください。