Another works Developers Blog

<h1>はじめに</h1>
<p>Another works CTOの塩原です。<br>
最近はエンジニア採用に力を入れているので、今回は弊社で実践しているユニークな採用手法「複業転職」についてご紹介させていただきます。</p>
<h1>複業転職とは</h1>
<p>複業転職は、正社員として入社する前に、業務委託契約を経て実際の業務に携わり、その後に正式な転職を行う方法です。一般的な転職フローと比べると期間は長くなりますが、コーディングテストや面接のプロセスが簡略化される傾向にあります。</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/a2775c97-4322-4d95-b744-0041eb2e8b21/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882023-12-2515.45.40.png" alt="スクリーンショット2023-12-2515.45.40.png"></p>
<h1>複業転職のメリットとデメリット</h1>
<p>では複業転職がどういったメリット・もしくはデメリットがあるのか採用側の目線と求職者側の目線でそれぞれ整理をしていきます。</p>
<h2>採用側の視点</h2>
<p>複業転職は、特にエンジニアのような採用が難しい職種において、非常に適した手法です。<br>
または、人数を増やすだけでなく、カルチャーマッチを重視し、慎重に優秀な人材を選びたいという採用戦略に合致します。</p>
<p>ただし、即時の採用効果が期待できないため、急ぎで人員を確保する必要がある場合には不向きかもしれません。</p>
<table>
<thead>
<tr>
<th>メリット</th>
<th>デメリット</th>
</tr>
</thead>
<tbody>
<tr>
<td>転職潜在層へのアプローチが可能</td>
<td>転職までのリードタイムが長い</td>
</tr>
<tr>
<td>カルチャーマッチの判断が容易</td>
<td>外注費用が発生</td>
</tr>
<tr>
<td>オンボーディングコストの削減</td>
<td>マネジメント負担の増加</td>
</tr>
<tr>
<td>社内エンジニアとの連携がスムーズ</td>
<td>運用の複雑さ</td>
</tr>
</tbody>
</table>
<h2>求職者の視点</h2>
<p>求職者にとってのメリットとしては転職先の選択を失敗するリスクを減らすことができるという点があります。<br>
また面接を複数社受けたり、コーディングテストを受けたりなど従来の転職活動が苦手な方にとっても複業を通した付き合いの中でお互いを知ることができるため転職コストの低減となります。</p>
<p>一方で採用側と同様にすぐに転職したい場合は不向きです。<br>
また複業は一定の時間を取られることから複数の企業を同時並行で進めるのが難しいという特徴もあります。</p>
<table>
<thead>
<tr>
<th>メリット</th>
<th>デメリット</th>
</tr>
</thead>
<tbody>
<tr>
<td>入社後のギャップが少ない</td>
<td>選択肢の限定</td>
</tr>
<tr>
<td>転職活動のコスト低減</td>
<td>速やかな転職が困難</td>
</tr>
</tbody>
</table>
<h1>複業転職を活用した採用戦略</h1>
<p>通常の業務委託契約では転職につながることが少ないため、複業転職には独自のアプローチが必要です。<br>
複業転職では、業務の選定と定期的なコミュニケーションが成功の鍵となります。<br>
単純作業ではなく、複業者のスキルを活かす業務を選ぶことが重要です。</p>
<h2>割り当てる業務の種類</h2>
<p>業務は、定期的に正社員エンジニアとのコミュニケーションが発生するようなものを選びます。<br>
このような業務は、単純な作業ではなく、複業者のスキルと経験を活かすものであるべきです。<br>
業務内容を対話ベースで徐々に拡大していくと、複業者はよりやりがいを感じ、企業へのコミットメントも高まる傾向があります。</p>
<table>
<thead>
<tr>
<th>転職に繋がりやすい業務</th>
<th>転職に繋がりにくい業務</th>
<th>工夫が必要な業務</th>
</tr>
</thead>
<tbody>
<tr>
<td>アドバイザリー業務</td>
<td>単純なデータ入力</td>
<td>個人で完結するタスクの開発（技術負債の解消、UI修正など）</td>
</tr>
<tr>
<td>エンジニア研修の実施</td>
<td>デバッグ作業</td>
<td>自動テストの作成</td>
</tr>
<tr>
<td>チーム開発プロジェクトへの参加</td>
<td>-</td>
<td>CI（継続的インテグレーション）の改善</td>
</tr>
</tbody>
</table>
<p>特に工夫が必要な業務では、ペアプログラミングや同期コードレビュー、社内勉強会など、積極的なコミュニケーションを取る機会を設けることが、より効果的です。</p>
<h1>Another worksの事例</h1>
<h2>事例1: AIアドバイザーから正社員への転身</h2>
<blockquote>
<p><strong>💡ポイント:</strong> 受発注の関係を越え、相談内容を段階的に深めることで、双方が同じ目線に立てるようになります。</p>
</blockquote>
<p><strong>背景</strong></p>
<ul>
<li>AI技術を活用したプロダクトの改善が必要だが、社内には専門知識が不足している。</li>
<li>AIの影響力について不確実性があり、正社員として即時採用するのは困難。</li>
<li>そのため、社内でAIに関する知見を蓄積しつつ、プロトタイプ開発を行うために、AIアドバイザーとして複業人材を採用。</li>
</ul>
<p><strong>複業内容</strong></p>
<ul>
<li>週一回の壁打ちセッションと、Slackを介した定期的な相談。</li>
</ul>
<p><strong>転職への経過</strong></p>
<ul>
<li>最初はレコメンデーションシステムの導入から始め、使用可能なデータを基に、適切なライブラリや学習方法の相談に集中。</li>
<li>徐々にAIのプロダクトへの統合を進め、中長期的な戦略や概念的なアイデアへと話が広がる。</li>
<li>その過程で、AIエンジニアとして正社員への転職を望むアドバイザーが自ら名乗りを上げる。</li>
</ul>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/97ad74e7-cf03-4b56-b95a-45bd365d31f2/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882023-12-239.07.15.png" alt="スクリーンショット2023-12-239.07.15.png"></p>
<h2>事例2: カジュアル面談から複業を挟んで選考への以降を決める</h2>
<blockquote>
<p><strong>💡ポイント:</strong> 業務だけでなく、それ以外のコミュニケーションにも重点を置くことが重要。</p>
</blockquote>
<p><strong>背景</strong></p>
<ul>
<li>カジュアル面談で自社への興味を持った候補者がいたが、直ちに転職を予定していないため、一次面接には進めない。</li>
<li>複業を介して、カジュアル面談では伝えきれなかったチームの雰囲気や業務内容を理解してもらう。</li>
</ul>
<p><strong>複業内容</strong></p>
<ul>
<li>ロードマップには含まれていないが重要なリファクタリング、パフォーマンス改善、UI修正などのタスクをチケット化し、自由に選択してもらう。</li>
</ul>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/0f1a143c-293c-49c3-94a0-972cd8f439f4/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882023-12-2515.30.03.png" alt="スクリーンショット2023-12-2515.30.03.png"></p>
<p><strong>転職への経過</strong></p>
<ul>
<li>実際の業務体験を通じて、CTOとのランチやチームとの交流を深め、複業期間中に候補者の意向を高める。</li>
<li>Another worksのコードやプロダクトの良し悪しを包み隠さず示し、候補者が自社で果たせる役割の可能性を理解してもらう。</li>
</ul>
<h1>まとめ</h1>
<p>複業転職は、特にエンジニアやCXOクラスのような採用が難しい職種において、徐々にスタンダードな採用手法として認識されつつあります。この手法は、求職者にとっても非常に有効です。</p>
<p>現代の就労環境では、複数回の転職が一般的になりつつあります。<br>
しかし、従来の方法では、毎回複数の企業で面接を受け、新しい職場でいちからスタートするという重大な負担が伴います。<br>
複業転職は、このような負荷を軽減し、キャリアチェンジをよりスムーズで緩やかなものにします。<br>
実際の業務を経験することで、求職者は企業の文化や仕事内容を深く理解し、より確かな決断を下すことが可能になります。</p>
<p>この手法は、採用側と求職者双方にとって、新しい時代のニーズに適応した理想的な解決策となるでしょう。</p>
<h1>複業転職で採用したいなら「複業クラウド」で</h1>
<p>複業クラウドでは複業人材の採用はもちろんのこと、複業からの転職採用も行うことのプラットフォームです。</p>
<p><a href="https://cl.aw-anotherworks.com/">https://cl.aw-anotherworks.com/</a></p>


複業から転職へ！Another works エンジニア複業転職の極意

<p>こんにちは、Another worksのCTO、塩原です。</p>
<p>最近、Another worksではフロントエンドのテスト作成を始める動きがあり、私たちも徐々にテストを書き始めています。<br>
LT会も毎月開催する中で、せっかくなのでそこで話した内容の一部を記事にして公開することにしました。</p>
<h1>今回の目的</h1>
<p>まだテストがほとんど書かれていない状況ですので、まずは「テストを書く」こと自体を習慣化したいと考えています。その一環として、カバレッジレポートが作成できると、テストが増えていく過程を可視化するための一つの指標となり、レビュワーがどれだけテストを網羅して書けているかの確認にも活用できると思います。</p>
<p>ただし、全体のカバレッジレポートだけでは、まだテスト自体をほとんど書いていない現状では、PRを作成する際に新たに書かれたテストを可視化するのが難しいと感じています。そこで、提出するPRの差分がどれだけテストを含んでいるかを可視化するため、新たな取り組みを始めました。</p>
<h1>使用技術</h1>
<ul>
<li>jest &quot;^29.5.0&quot;</li>
<li>@testing-library/react &quot;^14.0.0&quot;</li>
</ul>
<h1>やらなければならないこと</h1>
<p>やらなければならないことは主に二つです。</p>
<ul>
<li>特定のファイルに対するカバレッジレポートを出力すること</li>
<li>生成したカバレッジレポートをPRのコメントとして投稿すること</li>
</ul>
<h1>特定のファイルに対するカバレッジレポートの出力</h1>
<p>まず、jestのカバレッジレポートで特定のファイルに対して出力する方法ですが、以下の公式ドキュメントに方法が記載されています。<br>
https://jestjs.io/ja/docs/cli#--collectcoveragefromglob</p>
<pre><code>$ jest &quot;--coverage&quot; &quot;--collectCoverageFrom=${file_path1}|${file_path2}&quot;
</code></pre>
<p>&quot;|&quot;で区切ることで、複数のファイルに対するカバレッジレポートを一度に出力することが可能です。</p>
<h1>GitHubのPR差分に対して実行する</h1>
<p>GitHubのPR差分を取得するためには、<code>git diff</code>を使用します。ファイルは先ほどのglobパターンに適応するために&quot;|&quot;で区切る必要があります。また、当社ではモノレポを採用しているため、&quot;fc_client_web&quot;というプロジェクトのディレクトリ名を削除しています。</p>
<pre><code>- name: coverage-report
        id: coverage-report
        run: |
          change_files=($(git diff --name-only origin/${GITHUB_BASE_REF}...origin/${GITHUB_HEAD_REF} | grep -E '^fc_client_web/src/.*\.ts(x)?$'))
          for i in &quot;${!change_files[@]}&quot;; do
            change_files[$i]=${change_files[$i]//fc_client_web\//}
          done
          IFS=&quot;|&quot;;files=&quot;${change_files[*]}&quot;;unset IFS;
          npm run unit -- --coverage --collectCoverageFrom=$files --coverageReporters=json-summary
</code></pre>
<h1>生成したカバレッジレポートをPRのコメントとして投稿すること</h1>
<p>カバレッジレポートの生成までは上記で行うことができました。<br>
最後にPRコメントに投稿する方法ですが、<br>
<code>--coverageReporters=json-summary</code> こちらのオプションを付与することで、json形式でレポートの結果を吐き出してくれるのでそのjsonをmarkdownに加工してPRコメントに投稿することができます</p>
<pre><code>- name: Post jest coverage comments
        uses: actions/github-script@v6
        env:
          GH_TOKEN: ${{ github.token }}
          COMMENT: ${{ steps.coverage-report.outputs.GITHUB_ENV }}
        with:
          script: |
            const fs = require('fs')
            const data = JSON.parse(fs.readFileSync('./fc_client_web/coverage/coverage-summary.json', 'utf8'))
            let mdTable = &quot;| File Path | Lines % | Functions % | Statements % | Branches % |\n| --- | --- | --- | --- | --- |\n&quot;;

            for (const path in data) {
                const coverage = data[path];
                mdTable += `| ${path.replace('/home/runner/work/FC_Cloud/FC_Cloud/fc_client_web/', '')} | ${coverage.lines?.pct || 0} | ${coverage.functions?.pct || 0} | ${coverage.statements?.pct || 0} | ${coverage.branches?.pct || 0} |\n`;
            }
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: mdTable
            })
</code></pre>
<p>結果としてはこのようにPRコメントに差分のあるファイルだけがカバレッジレポートとして表示されます。</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/52e7bf7f-c3dc-4d7d-a7e1-899244ec1afd/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882023-06-2613.27.48.png" alt="スクリーンショット2023-06-2613.27.48.png"></p>
<h1>まとめ</h1>
<p>カバレッジレポートはあくまでも数値指標の一つでしかないですが、<br>
テストを書く際のモチベーションとしても機能すればと思いこの仕組みを取り入れてみました。<br>
テストについてはまたどこかで記事にできればと思います。</p>


Github PRの差分ファイルに対してだけカバレッジレポートを自動で出力してみる

<p>こんにちはAnother works CTOの塩原です。</p>
<p>複業クラウドのバックエンドではDDDとクリーンアーキテクチャを導入しています。</p>
<p>社内では、<a href="https://twitter.com/little_hand_s">松岡さん</a>の書籍やTwitterなどを参考にしながらDDDの開発に取り組んでいます。</p>
<p>DDDの記事は参考になるものが松岡さんの記事やその他の人が書いた記事など豊富にあるため、設計方法についてはそこまで困ることはありません。</p>
<p>DDDの記事を見ているとJavaやKotlin、Scalaだったり、一部フレームワーク独自構文を使ってDDDを実装しているものも多いため、今回はTypescriptで実装するための方法を記事にすることで、Node.jsを使っている方や、Typescriptを使っている方に参考になればと思い、書かせていただきました。</p>
<h1>この記事で書くこと・書かないこと</h1>
<h2>書くこと</h2>
<ul>
<li>ドメインイベントをTypescriptで実装する方法</li>
</ul>
<h2>書かないこと</h2>
<ul>
<li>ドメインイベントを始め、DDDに関する説明</li>
</ul>
<h1>シナリオ</h1>
<p>求人作成した際に、求人のデータなどを把握することができる求人レポートを生成することができる</p>
<h3>簡易ドメイン図</h3>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/d788e481-82e5-4a50-90d5-36177a978ec8%2F%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882022-12-1914.46.59.png" alt="スクリーンショット2022-12-1914.46.59.png"></p>
<h3>イベント周りの処理フロー図</h3>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/9f479852-ad4c-40cd-90b6-b57992fc4188%2F%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882022-12-1914.53.43.png" alt="スクリーンショット2022-12-1914.53.43.png"></p>
<h1>ドメインイベント</h1>
<p>まずはドメインイベントクラスを実装します</p>
<p>EventListenerでイベントごとに実行する処理を変える必要があるので、nameで判断できるようにします</p>
<pre><code class="language-tsx">export type DomainEventName = 'projectCreateEvent'

export interface DomainEvent {
    name: DomainEventName
}

type ProjectInfo = {
  title: string
}

/**
 * 求人作成イベント
 */
export class ProjectCreateEvent implements DomainEvent {
    name: 'projectCreate' = 'projectCreate'
    projectInfo: ProjectInfo

    constructor(params: { projectInfo: ProjectInfo }) {
        this.projectInfo = params.projectInfo
    }
}
</code></pre>
<h1>ドメインイベントの生成</h1>
<p><code>DomainEventStorable</code> という抽象クラスで、エンティティーがイベントを保持するための機能を抽象化しています。</p>
<p><code>ProjectDomainModel</code>で継承し、create関数の中で <code>ProjectCreateEvent</code> を発火するようにしています。</p>
<pre><code class="language-tsx">export abstract class DomainEventStorable {
    private domainEvents: DomainEvent[] = []

    protected addDomainEvent(domainEvent: DomainEvent) {
        this.domainEvents.push(domainEvent)
    }

    getDomainEvents(): DomainEvent[] {
        return this.domainEvents
    }

    clearDomainEvents() {
        this.domainEvents = []
    }
}

export default class ProjectDomainModel extends DomainEventStorable {
  constructor() {
    super()
    //...
  }

  static create(title: string) {
    //...
    // 
    model.addDomainEvent(
        new ProjectCreateEvent({
            projectInfo: {
                title
            },
        })
    )
  }
}
</code></pre>
<h1>イベント発行処理</h1>
<p>Node.jsにはEventEmitterという標準クラスがあり、イベント処理など行えるので <code>DomainEventListener</code> というクラスを使ってイベント処理をラップしています。</p>
<p><code>DomainEventPublisherImpl</code> はイベントを発行する処理で <code>ProjectRepositoryImpl</code> の関数の引数に渡して、repository内でpublish処理を行うようにする</p>
<p>publishする処理はドメインイベント全体で共通となっているので、ドメインイベントごとに作成する必要はありません。</p>
<pre><code class="language-tsx">import EventEmitter from 'events'

const emitter = new EventEmitter()
emitter.setMaxListeners(0)
export class DomainEventListener {
    static on&lt;T extends DomainEvent&gt;(
        eventName: T['name'],
        callback: (event: T) =&gt; void
    ) {
        emitter.on(eventName as string, callback)
    }

    static emit(eventName: DomainEvent['name'], event: DomainEvent) {
        emitter.emit(eventName as string, event)
    }
}

export interface DomainEventPublisher {
    publish(event: DomainEvent): Promise&lt;void&gt;
}

export class DomainEventPublisherImpl implements DomainEventPublisher {
    async publish(event: DomainEvent): Promise&lt;void&gt; {
        try {
            DomainEventListener.emit(event.name, event)
            new DomainEventEntity(DotEnvConsts.getFcLoggerEnv())
                .setData({
                    eventInfo: JSON.stringify(event),
                    eventName: event.name,
                    time: new DateLib().formatDate(
                        new Date(),
                        'YYYY-MM-DD HH:mm:ss'
                    ),
                })
                .save()
        } catch (e) {
            SentryLib.captureException(e)
            LoggerLib.error(`${event.name}: ${e};event: ${event}`)
        }
    }
}

export class ProjectRepositoryImpl implements ProjectRepository {
  async save(
        model: ProjectDomainModel,
        publisher: DomainEventPublisher
    ): Promise&lt;void&gt; {
    // 保存処理
    model.getDomainEvents().forEach((event) =&gt; publisher.publish(event))
  }
}
</code></pre>
<h1>イベントリスナー</h1>
<p>イベントリスナークラスはドメインごとに複数作成します。</p>
<p>今回イベントを受け取って振る舞いを定義するのはProjectReportになるので、 <code>ProjectReportListener</code>として作成して受け取ったイベントの振る舞いを定義しています。</p>
<pre><code class="language-tsx">export class ProjectReportEventListener {
  
  constructor(private repository: ProjectReportRepository) {
        DomainEventListener.on&lt;ProjectCreateDomainEvent&gt;(
            'projectCreate',
            (event: ProjectCreateDomainEvent) =&gt;
                this.callback(event)
        )
  }
  
  private callback(event: ProjectCreateDomainEvent) {
    // repositoryを使って、ProjectReportのsave処理を行う
  }
}

// index.ts
createConnection().then(() =&gt; {
    app.listen(DotEnvConsts.getAppPort(), () =&gt; {
        LoggerLib.debug(`Start on port ${DotEnvConsts.getAppPort()}.`)
        // Event Lisntenerを起動
        new ProjectReportEventListener()
    })
})
</code></pre>
<h1>まとめ</h1>
<p>今回はNode.jsとTypescriptを使って実装する方法を書きました。</p>
<p>TypescriptはkotlinやScaleなどと比較すると型システムとして足りない機能などありますが、ジェネリクスなどをうまく使うことでやりたいことを達成することができます。</p>


Node.jsとTypescriptでドメインイベントを実装する

<p>Another works CTOの塩原です。<br>
フロントエンドの設計は複業クラウドでもいろんなことを試しました。<br>
今回は、現在の複業クラウドのフロントエンド設計を紹介できればと思います。</p>
<h1>技術スタック</h1>
<ul>
<li>Next.js</li>
<li>React</li>
<li>Typescript</li>
</ul>
<h1>フロントエンド設計の考え方</h1>
<h2>1. 無理な共通化・抽象化を行わない</h2>
<p>これは過去の経験からですが、一時期フロントエンドの設計に対して、DDDの考え方や、クリーンアーキテクチャの考え方を取り入れようとしたことがありました。<br>
バックエンドではDDDやクリーンアーキテクチャを導入しているのでフロントエンドでもその考え方を取り入れてみようという考えでした。<br>
複業クラウドのコアな概念をドメインモデルとして定義したのですが、フロントエンドの場合<br>
表示する画面によってデータ構造が影響を受けてしまい、<br>
例えば複業クラウドでも「求人」という概念が一覧画面で見た時と、詳細ページで見た時、閲覧履歴や検索結果から見る時で表示される情報が変わるので共通化や抽象化に苦戦しました。<br>
画面も頻繁に書き変わることが多かったので開発コストと見合わなくなりました。<br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/00c6d221-daed-45ff-bf0f-d90f87d3b232%2F%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882022-11-2114.05.26.png" alt="スクリーンショット2022-11-2114.05.26.png"></p>
<h2>2. 変更における影響範囲が広くならないことを意識する</h2>
<p>また上記に関連することですが、共通化などをしすぎると画面変更に伴い共通化したもの自体にかなり大きな変更が入り、結果として特定の箇所の画面変更にも関わらず他の画面にも影響が出てしまうといったことも発生しました。</p>
<p>特に複業クラウドでは大幅に画面仕様が変わることも多く、そういったフェーズでは特に抽象化したものがそもそも0から書き直さなければならないといったことが発生しました。</p>
<h2>3. 仕組み化に頼りすぎずコミュニケーションを重要視する</h2>
<p>エンジニアには自動化や仕組み化といったことが得意かつ好きな人が多く、ついつい全てを仕組み化してしまいたくなりますが、プロダクトチームで人数がまだ10人に満たない中、常に変化も大きいため、仕組み化や自動化は取り入れながらもコミュニケーションを取ることも重要視するようにしています。</p>
<h1>推奨利用しているライブラリ</h1>
<ul>
<li>styled-component
<ul>
<li>reactでcssを書くためのライブラリ</li>
<li>jsx, tsxファイル内で書くことができる
<ul>
<li>css in js</li>
</ul>
</li>
<li>値に応じて動的にCSSを変更するようなコードを書ける</li>
<li><a href="https://styled-components.com/">https://styled-components.com/</a></li>
</ul>
</li>
<li>SWR
<ul>
<li>stale-while-revalidateをうまくやってくれる
<ul>
<li>キャッシュから値を返したあと、裏側で再フェッチし最新データに置き換える</li>
</ul>
</li>
<li>利用する側がフェッチ処理などを意識することなく、データのように利用することができる</li>
<li><a href="https://swr.vercel.app/">https://swr.vercel.app/</a></li>
</ul>
</li>
<li>react-hook-form
<ul>
<li>フォーム管理ライブラリ</li>
<li>バリデーションの機能も持っている
<ul>
<li>Yupを使わずに書くことができる</li>
</ul>
</li>
<li>以前はformikを使っていたが、内部でrefをうまく活用することで再レンダリングする箇所を最小限に抑えていたりなどパフォーマンス面に優れている</li>
<li><a href="https://react-hook-form.com/">https://react-hook-form.com/</a></li>
</ul>
</li>
</ul>
<h1>ディレクトリー構成</h1>
<h2>ディレクトリーの説明</h2>
<pre><code class="language-markdown">-- src
 |-- adapter
   |-- fcCoreApi
   |-- localstorage
 |-- assets
 |-- exception
 |-- hooks
 |-- features
   |-- projectSearch
   |-- mypage
 |-- lib
   |-- date
 |-- pages
 |-- styles
 |-- ui
   |-- homeland
   |-- origin
</code></pre>
<h2>adapter</h2>
<p>データ通信が発生する部分などの技術的な部分を扱うレイヤーを入れています</p>
<p>API通信についてという項目で詳細に説明しますが、useSWRを使うのはこの層になります</p>
<h2>features</h2>
<p>機能単位で分解しているモジュールです</p>
<p>こちらもfeatureディレクトリーについてという項目で詳細に説明します</p>
<h2>lib</h2>
<p>日付の共通処理や数字の変換処理など普遍的なクラスをこの中に入れています</p>
<p>utilではなくlibとした理由は、複業クラウド以外のプロジェクトで利用されても問題ないものが入るという意味を表すためにlibという名前を使いました</p>
<p>カスタムhook系の処理はhooksディレクトリーに入れるのでこの中には入りません</p>
<h2>hooks</h2>
<p>カスタムhooksの中でfeaturesを跨いで使うような共通処理を置くモジュールです</p>
<p>ファイル名は必ずuseXXXとなります</p>
<h1>Featureディレクトリーについて</h1>
<p>弊社ではfeatureというディレクトリーを使って単数もしくは複数のページをまとめています。</p>
<p>まとめた中に共通となるコンポーネントや、カスタムhooks、型定義や定数などを格納しています。</p>
<pre><code class="language-markdown">|-- features
 |-- projectSearch
   |-- ui
     |-- pages
     |-- origin
   |-- consts
     |-- projectConsts // 求人の型を入れておく
   |-- hooks
</code></pre>
<p>そうすることで、hooksやconstsなどの利用範囲が限定されているので</p>
<p>実際に表示で使う型に合わせて定義することができます。</p>
<p>featureディレクトリーというと、一ページ内での機能単位でディレクトリーを切る場合もありますが、機能単位に微妙に分解しづらいものなども存在するのとページ単位の場合、Next.jsでは <code>pages/</code> ディレクトリーをいじらなければ移行自体はやりやすいのでページ単位を採用しました。</p>
<h2>ESLint</h2>
<p>feature同士が依存するとせっかくディレクトリーを分けた意味がなくなるので、</p>
<p>その依存を防ぐためにeslintを使ってimportの依存関係を制御しています。<br>
https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-restricted-paths.md</p>
<pre><code class="language-json">module.exports = {
  extends: [
    'next',
    'next/core-web-vitals',
    'plugin:import/recommended',
    'plugin:import/typescript',
    'prettier',
  ],
  settings: {
    'import/resolver': {
      typescript: {},
    },
  },
  rules: {
    'import/no-restricted-paths': [
      'error',
      {
        zones: [
          {
            from: './src/features/!(accountDelete)/**/*', // 対象の依存パス
            target: './src/features/accountDelete', // 禁止するパス（正規表現可）
            message: 'features同士で依存することはできません', // エラーメッセージ
          },
        ],
      },
    ],
  },
};
</code></pre>
<h1>コンポーネント設計</h1>
<h2>landscape/homeland/origin</h2>
<p>複業クラウドでは三種類のコンポーネントを使いわけています。</p>
<p>以前はAtomicデザインを適用していたのですが、実際の運用を行う上で分けやすい分け方がいいと思いコンポーネントの種類を見直しました。</p>
<h3>landscape</h3>
<p>ボタンや、formなどの基本的なコンポーネント</p>
<p>複業クラウドでは企業側とタレント側などでフロントエンドリポジトリーが分かれているので</p>
<p>npmライブラリで実装して複数箇所で使えるようにしています。<br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/ae80688d-fdbb-4bb0-8d73-cbd958c1c370%2FUntitled.png" alt="Untitled.png"><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/57b24c2a-3634-4037-8d9a-4bee936e00fe%2FUntitled(1).png" alt="Untitled(1).png"></p>
<h3>homeland</h3>
<p>このコンポーネントは上記のコンポーネントほど頻出ではないものの、</p>
<p>求人カードやタレントプロフィール画面などプロダクトのコアになりそうなデザインコンポーネントを定義しています。</p>
<p>そうすることで、変更が入った時にも一箇所を修正すれば変更が反映され、デザインする際にも一貫性が保たれます。</p>
<p>こちらはリポジトリーに直接定義するので、企業側・タレント側それぞれで定義されています。</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/76583943-7fa1-4df2-9d00-a8f8774a4ddf%2FUntitled(2).png" alt="Untitled(2).png"></p>
<table>
<thead>
<tr>
<th></th>
<th>landscape</th>
<th>homeland</th>
<th>origin</th>
</tr>
</thead>
<tbody>
<tr>
<td>デザイナーとのコミュニケーション</td>
<td>必要</td>
<td>必要</td>
<td>不要</td>
</tr>
<tr>
<td>ビジネスロジックを持てるかどうか</td>
<td>NG</td>
<td>OK</td>
<td>OK</td>
</tr>
<tr>
<td>実装方法</td>
<td>npmライブラリ</td>
<td>src/ui/homeland配下に実装</td>
<td>src/ui/originもしくは各features配下に定義</td>
</tr>
</tbody>
</table>
<h1>API通信について</h1>
<h2>SWRを使ったAPI通信</h2>
<p>弊社ではAPI通信にswrを利用しています。</p>
<p>swrにはいくつか利点がありますが、特に気に入っているポイントとして</p>
<ul>
<li>キャッシュを簡単に行なってくれる</li>
<li>useEffectとuseStateの乱立を防げる</li>
<li>楽観的更新・定期ポーリング・エラー時の再試行などを簡単に実装できる</li>
</ul>
<p>という点が挙げられます。</p>
<p>特にuseEffectとuseStateの乱立を防げるという点では下記のコードで比較をしてみます</p>
<p><strong>useSwrを使わない場合</strong></p>
<pre><code class="language-tsx">import useSWR from 'swr'

function Profile() {
  const [data, setData] = useState(undefined)
  useEffect(() =&gt; {
     const callback = async () =&gt; {
       const result = await fetcher()
       setData(result)
     }

     callback()
  }, [setData])

  if (!data) return &lt;div&gt;loading...&lt;/div&gt;
  return &lt;div&gt;hello {data.name}!&lt;/div&gt;
}
</code></pre>
<p><strong>useSwrを使う場合</strong></p>
<pre><code class="language-tsx">import useSWR from 'swr'

function Profile() {
  const { data } = useSWR('/api/user', fetcher)

  if (!data) return &lt;div&gt;loading...&lt;/div&gt;
  return &lt;div&gt;hello {data.name}!&lt;/div&gt;
}
</code></pre>
<p>とこのようにSWRを使わない場合、useEffectとuseStateを駆使しなければいけません。</p>
<p>APIが一つなのでまだシンプルですが複数必要になるとかなり複雑になってきます。</p>
<h2>SWRを使った設計</h2>
<p>上記のサンプルコードはSWRの公式ドキュメントを参考にしたものなので、</p>
<p>コンポーネント内に直接 <code>useSWR</code> を記載していますが、</p>
<p>このような書き方にはいくつか問題があると考えています。</p>
<ul>
<li>異なるデータのキャッシュの値が被ってしまう可能性がある
<ul>
<li>APIのパスにすれば被っても問題ない
<ul>
<li>postやgetのrequest情報もパスに含める想定なら
<ul>
<li>ただ理想としてはキャッシュ値は中央集権的に管理しておきたい</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>第二引数のデータ構造をAPIのまま使うのではなく、加工したいときにコンポーネントに加工処理が漏れる</li>
<li>APIのレスポンスやリクエスト内容などはコンポーネントの関心ごとからは切り離したい
<ul>
<li>これはプロダクトの思想によっては異なる</li>
</ul>
</li>
</ul>
<p>そのため複業クラウドでは以下のような三層構造で設計をしています</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/8093264e-df13-4d23-a307-088e4c204ef6%2F%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882022-12-0516.04.04(1).png" alt="スクリーンショット2022-12-0516.04.04(1).png"></p>
<p>Adapter層では、APIと直接通信し、APIのエンドポイントごとに通信するための関数を用意し、その中でSWRを実行しています。</p>
<p>feature内のhooksで、adapter層の関数を使って、見た目に必要な情報などを加工する処理などを記載します。</p>
<p>楽観的更新やポーリングなどもこのcustom hooksで実装するようにしています。</p>
<p>componentはAdapterを直接参照せずに、feature内のhooksから参照するようにすることで、componentがそこまでAPIの情報を意識することなく利用することができます。</p>
<p><code>adapter/useGetProfile.ts</code></p>
<pre><code class="language-tsx">export function useGetProfile(request: {id: string}) {
  const { data, error } = useSWR(['/api/user', request], fetcher)
  return data, error
}
</code></pre>
<p><code>feature/hooks/useProfile.ts</code></p>
<pre><code class="language-tsx">export function useProfile(params: {id: string}) {
  const {data, error} = useGetProfile(params)
  return {
    data: {
      ...data,
      fullname: data.lastName + data.firstName
    },
    loading: !error &amp;&amp; !data
  }
}
</code></pre>
<p><code>feature/ui/origin/profileBox.tsx</code></p>
<pre><code class="language-tsx">function ProfileBox() {
  const { data, loading } = useProfile()
  
  if (loading) return &lt;div&gt;loading...&lt;/div&gt;
  return &lt;div&gt;hello {data.fullname}!&lt;/div&gt;
}
</code></pre>
<h1>まとめ</h1>
<p>フロントエンドに限らず設計は日々最適解を見つけながら進化させていくべきだと考えています。<br>
なので今回の設計で満足せずに、会社の規模・チームの規模、技術の進歩に合わせて常に改善を続けていきたいと考えています。</p>


Articles by ソル / 塩原基弘

複業から転職へ！Another works エンジニア複業転職の極意

Github PRの差分ファイルに対してだけカバレッジレポートを自動で出力してみる

Node.jsとTypescriptでドメインイベントを実装する

複業クラウドのフロントエンド設計を紹介します！