# 自社サービス統合リニューアルプロジェクト
## 概要
- 異なる設計で独立している各自社サービス(人材紹介系)をひとつのドメインに統合する
- 医療、介護、保育などエッセンシャルワーカーをメインとする有資格者をもった求職者が対象となる転職サイト
- 合計10ほどのサービスがあり、まずは規模の大きい医療と介護を統合したのちに他サービスをそこに組み込んでいく
- 統合に伴い、新規サービスを提供する
## 目的
### ビジネス目線
- 自社の規模・業界でのシェア率が大きくなってきた影響により、従来の手法では成長に限界が見えている状態であり、そこからの打開
- 電話主体の営業スタイルから法人と求職者が直接やりとりできるダイレクトリクルーティング機能の提供
- オーガニック流入の増加と、それに伴う広告費の削減と知名度の向上
### 開発目線
- 各サイトで微妙に異なる設計・環境の統一化
- 環境ごとではなく機能ごとに分割し、属人化の解消を図る
- レガシーシステムからモダンなフレームワークへの乗り換え
- UI面の全面リニューアル
## 開発規模・組織編成
- 外部ベンダーを取り入れ協力開発を行った
- POには自社から複数名を挙げ、POチームとしてビジネスサイドと要件をすり合わせる
- POチーム:3名
- 開発チーム
- 自社エンジニア:約10名
- 外部エンジニア:5名
- 自社デザイナー:5名
- 外部デザイナー:2名
## 開発手法・方針
- スクラムを組んでのアジャイル開発
- 外部ベンダーに協力してもらい、アジャイル研修を受けたのちに開発を開始
- 2週間を1Sprintとし、定期イベントとしてプランニング、リファインメント、レビュー、レトロスペクティブを行う
- フロント・バックなどで領域は分断せず、バックログの優先順に応じチーム全員で設計・実装・テストを行う
- 着手しなければならないが自分には不得手な内容だという場合は、適切なメンバーに相談し、ペアプロで進める
- 反対に、相談を受けた場合は率先してサポートし、チーム全体にナレッジの共有を行う
## 担当工程
- 上記の開発方針からAWSの設定や、DB設計・実装、API設計・実装、UIの設計・実装、レビュー、テストなどを経験
- メインはフロント領域となり、技術選定から行いAtomic Designを用いたUI面の設計実装、機能開発をリード
- AWS, バックエンドに関しては主にペアプロでサポートをしてもらいつつ、設計や実装を経験
## おもな課題とそれに対するアプローチ
### フロント資材のカオス化を解消
【課題点】
- 統合前である複数の既存サイトは、HTML, CSS(Sass)ファイルがページごとに存在している仕組みでスクラッチ開発されており、共通化という概念がほとんどない状態
- サーバーサイドも同様だが、当時の実装者はすでに在籍しておらず完全にブラックボックスとなっていた
【解決策】
- Next.jsの採用
- React的思想により、UIコンポーネントを再利用する設計を行なった
- Atomic Designの導入
- Reactに合わせデザインシステムを導入し、粒度ごとにコンポーネントを分類・定義し、統合後もサービスを跨り同一コンポーネントを利用できる設計にした
- MUIの導入
- MUIをカスタマイズして運用することにより、開発コストを下げた(フロントエンドは自身のみで、他エンジニアは全員バックエンドメインだった)
- MUIの機能を引き継ぎつつスタイルだけを再定義して運用する設計を行い構築した
- 採用したAtomic Designに基づく設計を行なった
- Themeでのスタイル運用
- MUIのThemeを拡張することにより、以下のようなスタイルがpropsにより自動的に付与される基盤を作成した
- ブレイクポイント
- 各種サイトカラー
- フォントに関するスタイル
- spacing(padding, marginなど余白の数値を配列で管理)など
- CSSファイルの廃止
- CSS in JSを採用し、コンポーネント内にスタイルの責務を閉じ込めることでデグレや競合を回避
- 上記フロント周りの設計の徹底した資料化
- Miroを用いて資料化し、バックエンドエンジニアも資料を見ながらUIを構築できるようナレッジの共有を行なった
【成果】
- チーム全体でフロント周りのナレッジが広がり、一人で手を動かせるメンバーがほとんどという状況になった
- 複数サービスを跨り、共通的なコンポーネントを利用できるようになった
- サービス全体を通してUIに一貫性が備わり、ブランディング面も強化された
- AtomicDesignを採用したことで汎用性が高まり、開発効率が向上しソースの肥大化も抑えることができた
### メッセージ機能の開発
【課題点】
- 新機能となるメッセージ機能の開発にあたり、実現方法や設計が誰もわからない状態であった
- できればリアルタイムがよいという要望もあり
- 法人が求職者に対して直接スカウトを送ることができるというビジネスモデルであり、求人情報や応募APIとの連携が必要
- 法人側管理画面は別会社が開発したシステムを利用
- 個人でのやり取りというところからセキュリティ的な課題もあり
【解決策】
- SaaSである「Twilio」の導入
- SDKによるデモ作成から要望を実現できるかの検証
- ユーザー情報の電話番号とメールアドレスをキーにsidを発行しトークルームに参加させる
- 営業側で利用していたSalesForceのIDと、マイページ発行時に生成されるアプリ側DBのidをもとに求人情報と求職者情報を法人側システムと連携
- フロント側でのデータ取得処理をカスタムhook化
【成果】
- リアルタイムに更新、未読、既読などの処理が行えるシステムをアプリケーション側に実装できた
- 法人側システムとアプリケーション側の、求人情報及びそれに対する応募システムを連携することができた
- チャット機能そのものはTwilioを利用することで、セキュリティを担保しつつ開発工数を削減することができた
## 導入技術まとめ
### フロントエンド
- Next.js
- Redux
- Atomic Design
- MUI
- StoryBook
- Jest
- PlayWright
など
### バックエンド
- Nest.js
- TypeORM
など
### SaaS
- Auth0
- Twilio
- Send Message
- SHIRAHA
- 以前買収した会社が開発していた、法人側へ提供する求職者へのスカウトシステム
- 自社サイトと連携させ、求人情報の掲載・更新・削除、スカウト及びメッセージの送受信を行う