## はじめに

Google Cloud 上でバッチ処理を行う際に、[Cloud Run jobs](https://cloud.google.com/run/docs/create-jobs)を使用したので紹介します。
本記事では、他サービスとの比較と[Cloud Run jobs](https://cloud.google.com/run/docs/create-jobs)の使い方について説明します。

## Google Cloud でバッチ処理できるサービス

Cloud Run jobs を使用するにあたって、他のサービスについても調べたのでそれぞれの特徴をまとめました。

### [Cloud Functions](https://cloud.google.com/functions)

様々なイベントをトリガーにできるので、特定のイベントが発生したときに動かしたいバッチ処理の場合は Cloud Functions を使うと良さそうです。
例えば [Cloud Storage](https://cloud.google.com/storage) に画像がアップロードされた際に、自動的にサムネイルを作成したり、画像にフィルターをかけたりする処理が簡単に作れます。
しかし、最大実行時間に制限(60 分)があるため長時間の処理には適さない場合があります。

### [Batch](https://cloud.google.com/batch)

大規模なバッチ処理ワークロードを効率的に実行するためのフルマネージドなサービスです。
高性能コンピューティング（HPC）、機械学習、データ処理など、さまざまな種類のバッチジョブをスケーラブルかつ柔軟に実行できます。
また、最大実行時間に制限が無いので長時間の処理に適しています。
しかし、Cloud Functions や Cloud Run jobs よりも設定が複雑になってしまうので採用しませんでした。

### [Cloud Run jobs](https://cloud.google.com/run/docs/create-jobs)

Cloud Run の一機能で、バッチ処理や非同期タスクの実行に特化したサービスです。
最大実行時間に制限がありますが、24 時間実行できるのでほとんどのバッチ処理は問題ないでしょう。

## Cloud Run jobs の基本要素

### Cloud Run jobs のリソース構造

Cloud Run jobs は以下のようなリソースで構成されています。<br>
 ![リソース構造](https://cont.sterfield.co.jp/uploads/resource_a778e2a692.jpg) 

### ジョブ (Job)

実行したいタスクの全体像を定義するルートリソースです。

ジョブでは以下の項目を設定できます。

- コンテナイメージ
- タスク数
- 並列実行数
- リソース(各タスクに割り当てる CPU やメモリなどのリソース量)
- 環境変数
- サービスアカウント

### タスク (Task)

ジョブによって定義されたタスクのインスタンスです。
タスクはジョブに設定された数だけ実行されます。コンテナインスタンスを 1:1 で用意し、コンテナインスタンスごとの進捗を管理します。タスクがエラーで終了した場合は、タスク単位で再実行もできます。

### 実行 (Execution)

タスクの実行履歴です。
ジョブの設定に応じてタスクを実行し、全てのタスクが完了するまでの状態を管理します。1 度作成した実行は、何度でも再実行が可能です。

## Cloud Run jobs の作成・実行方法

### サンプルアプリケーションの用意

以下のコードを適当なフォルダに作成します

環境変数に`SLEEP_MS`を設定すると、設定した時間だけスリープするようになり、時間のかかる処理を再現できます。
`FAIL_RATE`を設定すると、指定した確率でジョブがエラーになり、エラー時の挙動を確認できます。

main.js

```js
// Retrieve Job-defined env vars
const { CLOUD_RUN_TASK_INDEX = 0, CLOUD_RUN_TASK_ATTEMPT = 0 } = process.env;
// Retrieve User-defined env vars
const { SLEEP_MS, FAIL_RATE } = process.env;

// Define main script
const main = async () => {
  console.log(
    `Starting Task #${CLOUD_RUN_TASK_INDEX}, Attempt #${CLOUD_RUN_TASK_ATTEMPT}...`
  );
  // Simulate work
  if (SLEEP_MS) {
    await sleep(SLEEP_MS);
  }
  // Simulate errors
  if (FAIL_RATE) {
    try {
      randomFailure(FAIL_RATE);
    } catch (err) {
      err.message = `Task #${CLOUD_RUN_TASK_INDEX}, Attempt #${CLOUD_RUN_TASK_ATTEMPT} failed.\n\n${err.message}`;
      throw err;
    }
  }
  console.log(`Completed Task #${CLOUD_RUN_TASK_INDEX}.`);
};

// Wait for a specific amount of time
const sleep = (ms) => {
  return new Promise((resolve) => setTimeout(resolve, ms));
};

// Throw an error based on fail rate
const randomFailure = (rate) => {
  rate = parseFloat(rate);
  if (!rate || rate < 0 || rate > 1) {
    console.warn(
      `Invalid FAIL_RATE env var value: ${rate}. Must be a float between 0 and 1 inclusive.`
    );
    return;
  }

  const randomFailure = Math.random();
  if (randomFailure < rate) {
    throw new Error("Task failed.");
  }
};

// Start script
main().catch((err) => {
  console.error(err);
  process.exit(1); // Retry Job Task by exiting the process
});
```

package.json

```json
{
  "main": "main.js",
  "scripts": {
    "start": "node main.js"
  },
  "engines": {
    "node": ">=20.0.0"
  }
}
```

Dockerfile

```Dockerfile
FROM node:20
WORKDIR /app
COPY . .
RUN npm install
CMD [ "npm", "start" ]
```

### コンテナをプッシュ

次のコマンドで [Artifact Registry](https://cloud.google.com/artifact-registry) にコンテナをプッシュします。`${REGION}`と`${PROJECT_ID}`は各自で置き換えてください。

```
gcloud builds submit --tag ${REGION}-docker.pkg.dev/${PROJECT_ID}/gcr.io/job-sample
```

### ジョブを作成

今回は、以下の Cloud Run のコンソールから作成します。<br>
https://console.cloud.google.com/run/jobs

「ジョブの作成」をクリックします。<br>
 ![ジョブの作成ボタン](https://cont.sterfield.co.jp/uploads/job_create_1_691d934c36.png) 

「コンテナ イメージの URL」に先ほど作成したコンテナを選択します。
イメージ名が自動的に設定されます。
リージョンやタスク数はお好みで設定して下さい。<br>
 ![ジョブの詳細](https://cont.sterfield.co.jp/uploads/job_create_2_c2c65e6a14.png) 

### ジョブの実行

「実行」をクリックし、ジョブを開始します。<br>
 ![実行ボタン](https://cont.sterfield.co.jp/uploads/job_create_3_3049895faf.png)

しばらく経つと、全てのタスクが完了し、実行が完了します。実行の詳細を開くとタスクが完了していることが確認でき、各タスクのログ等が確認できます。<br>
 ![タスク](https://cont.sterfield.co.jp/uploads/job_create_4_6281075873.png) 

### 作成した Job を定期実行する方法

「トリガー」タブを選択し、「スケジューラ トリガーを追加」をクリックします。<br>
 ![トリガー追加ボタン](https://cont.sterfield.co.jp/uploads/scheduler_1_1e1f8511c4.png) 

頻度を unix-cron 形式で選択します。
今回は 5 分ごと(`*/5****`)に実行してみます。<br>
 ![トリガー詳細](https://cont.sterfield.co.jp/uploads/scheduler_2_f70181ea5b.png) 

指定した通り、5 分ごとにジョブが実行されました。<br>
 ![ジョブ一覧](https://cont.sterfield.co.jp/uploads/scheduler_3_69acf4aa19.png) 

## まとめ

今回は Cloud Run jobs について説明しましたが、各サービスのメリット・デメリットを比較し、要件に合った最適なサービスを選択することが重要です。
今後、他サービスにも触れる機会がありましたら紹介したいです。

## 参考

- https://speakerdeck.com/satohjohn/gcptenohatutichu-li-hatanwokao-etemiru
- https://zenn.dev/google_cloud_jp/articles/cloudrun-jobs-basic
- https://cloud.google.com/run/docs/quickstarts/jobs/build-create-nodejs

cloud-run.png

Cloud Run jobs を利用したバッチ処理

## はじめに

Prisma でデータベーススキーマを書く際に、[ZenStack](https://zenstack.dev/) というフレームワークが便利だったので紹介します。
ZenStack にはさまざまな機能がありますが、今回はデータベーススキーマの定義について重点的に説明します。

## ZenStack とは

ZenStack は、Node.js と TypeScript 向けのフルスタック開発フレームワークです。データベーススキーマを定義するだけで、フロントエンドとバックエンドの実装を自動的に生成できます。
ZenStack は、Prisma ORM をベースとして構築されているので、Prisma のすべての機能を利用できます。

## ZenStack を使用したデータベーススキーマの書き方

ZenStack では、[ZModel](https://zenstack.dev/docs/reference/zmodel-language) というデータモデリング言語でデータベーススキーマを作成します。
[Prisma Schema](https://www.prisma.io/docs/orm/prisma-schema) をベースとしているので、基本的な文法は Prisma Schema と同じように書くことができます。

また、VSCode 向けに[ZenStack の拡張機能](https://marketplace.visualstudio.com/items?itemName=ZenStack.ZenStack)が用意されています。
エラーチェックやコード補完をしてくれるので、ZModel でデータベーススキーマを書く際はインストールしておくと便利です。

## ZModel を Prisma Schema に変換する方法

ZModel で定義したデータベーススキーマを Prisma で使用するには、以下のコマンドで ZModel → Prisma Schema に変換する必要があります。

```
npx zenstack generate
```

変換元と変換先のファイルパスを指定したい場合は package.json に以下の設定を記述します。

```
  "zenstack": {
    "schema": "[変換元のZModelファイル(デフォルト：./schema.zmodel)]"
    "prisma": "[変換先のSchemaファイル(デフォルト：./prisma/schema.prisma)]",
  },
```

## ZModel の便利機能

Zmodel で利用できる便利な機能をいくつか紹介します。

### abstract

ベースとなる抽象化 model を作成し、各項目を継承できます。
登録日時などのように、各テーブルに共通なフィールドがある場合に使うと便利です。

```
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url = env("DATABASE_URL")
}

abstract model Base {
  id Int @id @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

model User extends Base {
  email String @unique
  name String
  posts Post[]
}

model Post extends Base {
  title     String
  content   String?
  published Boolean @default(false)
  author    User? @relation(fields:  [authorId], references: [id])
  authorId  Int?
}
```

上記 ZModel を変換すると、以下のような Prisma Schema が生成されます。

```
datasource db {
    provider = "postgresql"
    url = env("DATABASE_URL")
}

generator client {
    provider = "prisma-client-js"
}

model User {
    id Int @id() @default(autoincrement())
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt()
    email String @unique()
    name String
    posts Post[]
}

model Post {
    id Int @id() @default(autoincrement())
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt()
    title String
    content String?
    published Boolean @default(false)
    author User? @relation(fields: [authorId], references: [id])
    authorId Int?
}
```

### ファイル分割

1 ファイルで全てのスキーマを定義すると、スキーマが増えてくるにつれて管理が大変になると思います。
そこで、ZModel ファイルを分割してスキーマ定義する方法を紹介します。

今回の例では ZModel ファイルを以下のように分割してみます。

- base.zmodel: generator や datasource を記述するファイル
- user.zmodel: user のスキーマ
- post.zmodel: post のスキーマ

base.zmodel

```
// importに分割したZmodelファイルをすべて記載します
import "user"
import "post"

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url = env("DATABASE_URL")
}
```

user.zmodel

```
model User {
  id Int @id() @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt()
  email String @unique()
  name String
  posts Post[]
}
```

post.zmodel

```
model Post {
  id Int @id() @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt()
  title String
  content String?
  published Boolean @default(false)
  author User? @relation(fields: [authorId], references: [id])
  authorId Int?
}
```

変換元のファイルを「base.zmodel」に指定して変換すると、以下のような Prisma Schema が生成されます。

```
datasource db {
    provider = "postgresql"
    url = env("DATABASE_URL")
}

generator client {
    provider = "prisma-client-js"
}

model User {
    id Int @id() @default(autoincrement())
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt()
    email String @unique()
    name String
    posts Post[]
}

model Post {
    id Int @id() @default(autoincrement())
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt()
    title String
    content String?
    published Boolean @default(false)
    author User? @relation(fields: [authorId], references: [id])
    authorId Int?
}
```

### 属性

ZModel でのみ使用できる属性を一部紹介します。
詳しい内容は[公式リファレンス](https://zenstack.dev/docs/reference/zmodel-language#attribute)をご確認ください。

#### @password

データベースにハッシュ化した文字列を登録/更新します。
内部的には[bcryptjs](https://github.com/dcodeIO/bcrypt.js#readme)ライブラリを使用してハッシュ化しているようです。

以下のように引数が定義されていて、saltLength からハッシュのコストを設定したり、salt の設定も可能です。

```
@password(saltLength: Int?, salt: String?)
```

#### @omit

この属性を指定したフィールドはデータ呼び出し時に値が取得されなくなります。
上記の@password と組み合わせて使用すると便利です。

## まとめ

最近リリースされたばかりのフレームワークだからなのか、情報量が少なく調べるのに苦労しました。
今回は ZModel を重点的に紹介しましたが、他にも魅力的な機能がたくさんあるライブラリなので、次の機会に紹介したいと思います！

## 参考

- https://ZenStack.dev/
- https://www.ey-office.com/blog_archive/2023/09/20/i-learned-a-little-more-about-zenstack-zmodel-is-useful/
- https://www.Prisma.io/docs/orm/Prisma-schema/data-model/models
- https://zenn.dev/smish0000/articles/f1a6f463417b65


logo.png

ZenStack を使用してデータベーススキーマを作成する

## はじめに

2023 年 10 月に[Gmail のメール送信者ガイドライン](https://support.google.com/mail/answer/81126)がアップデートされました。<br>
2024 年 2 月から適用されるので、ギリギリになってしまいましたが、ガイドラインからどのような設定が必要なのかをまとめました。

## 対象となる送信者

個人用 Gmail アカウントに 1 日あたり 5,000 件以上のメールを送信している場合が対象になります。<br>
個人用 Gmail アカウントとは、末尾が @gmail.com または @googlemail.com のアカウントを指します。<br>
現在のガイドラインでは Google Workspace を利用しているアカウントは対象外ですが、今後のアップデートで Google Workspace を利用しているアカウントも対象になる可能性があるので、個人用 Gmail アカウントにメールを送信していなくても今のうちに設定しておくことをおすすめします。

### 5,000 件のカウント方法について

同じプライマリドメインから送信されたすべてのメールが対象になります。<br>
例えば、1 日あたり@example.com から 3,000 件、@sub.example.com から 2,500 件送信している場合、5,500 件とカウントされます。

## ガイドラインの適応スケジュール

[Google の FAQ](https://support.google.com/a/answer/14229414)によると、以下のスケジュールで順次対応するようです。

### 2024 年 2 月

要件を満たしていないメールのうち、一部のメールが一時的なエラーを受け取るようになります。

### 2024 年 4 月

要件を満たしていないメールの拒否を開始します。<br>
一部のメールから拒否をし始めて、徐々にその割合を増加します。

### 2024 年 6 月

全ての商用メール、プロモーションメールに、ワンクリックでの登録解除を実装する必要があります。

## 対応が必要な内容

今回のガイドラインで対応が必要な項目は下記の通りです。

- 送信ドメインで SPF と DKIM を設定する
- 送信元のドメイン、 IP アドレスに正引き、逆引き DNS レコードを設定する
- メールの送信に TLS 接続を使用する
- [Postmaster Tools](https://gmail.com/postmaster/)で報告される迷惑メール率を 0.1%未満に維持する
- [RFC 5322](https://datatracker.ietf.org/doc/html/rfc5322)に準拠する形式でメールを作成する
- DMARC を設定する
- メーリングリスト等、転送する場合は ARC ヘッダを追加する
- ヘッダ From ドメインは SPF、DKIM ドメインと一致させる
- ワンクリックでの配信停止に対応する

## DNS レコードについて

DNS（Domain Name System）とは、インターネット上でドメイン名と IP アドレスを紐づけるためのシステムです。<br>
今回のガイドラインでは、送信元ドメインの A レコードから送信元 IP アドレスを参照できるようにし（正引き）、逆に送信元 IP アドレスの PTR レコードから送信元ドメインを参照できるようにする（逆引き）必要があります。

### DNS レコードの例

「example.com」から IP アドレス「172.16.0.1」を参照（正引き）する設定は以下のように記述します。

```
example.com. IN A 172.16.0.1
```

IP アドレス「172.16.0.1」から「example.com」を参照（逆引き）する設定は以下のように記述します。

```
1.0.16.172.in-addr.arpa. IN PTR example.com
```

「1.0.16.172.in-addr.arpa.」の部分は、以下の手順で変換したものを記載します。

1. IP アドレスの各オクテットを逆順に並べる
   「172.16.0.1」の場合は「1.0.16.172」のようにします
2. IP アドレスが IPv4 形式の場合は、後ろに「.in-addr.arpa.」を記述する
   ※ IPv6 形式の場合は「.ip6.arpa.」を付与します

## SPF レコードについて

SPF（Sender Policy Framework）とは、電子メールの送信元ドメインが詐称されていないかを検査するための仕組みです。<br>
メールを受信する際に受信側は送信側の DNS ヘ SPF レコードを要求し、返答された SPF レコードが受信したメールの実際の送信元 IP アドレスと一致するかを確認します。<br>
2 つの IP アドレスが一致すれば認証が成功し、ドメインの管理者が意図した通りのメールサーバーから届けられた正しい送信元からのメールであることが証明できます。

### SPF レコードの例

「example.com」の IP アドレス「172.16.0.1」から送信されたメールアドレスのみを認証する場合は、以下のように記述します。

```
example.com. IN TXT "v=spf1 ip4:172.16.0.1 -all"
```

## DKIM レコードについて

DKIM（DomainKeys Identified Mail）とは、電子メールの送信元ドメインの認証技術の一種です。<br>
メール送信者が秘密鍵を使ってメールに署名し、受信者は送信元ドメインの公開鍵を使って、この署名の正当性を検証します。<br>
署名が正当であれば、そのメールは送信元ドメインの管理者が意図した通りのメールサーバーから届けられた正しい送信元からのメールであることが証明できます。

### DKIM レコードの例

DKIM レコードは下記のように記載します。<br>
セレクタ名は、任意の最大 63 文字の英数字を設定できます。<br>
ただし、セレクタ名はドメインに対して一意である必要があります。

```
[セレクタ名]._domainkey.example.com. IN TXT "v=DKIM1;k=rsa;p=[公開鍵]";
```

## DMARC レコードについて

DMARC（Domain-based Message Authentication, Reporting and Conformance）とは、電子メールの送信元ドメインの認証技術の一種であり、SPF や DKIM と併用することで、なりすましメール対策の強化が期待できます。<br>
DMARC の仕組みは、以下の 3 つに分けられます。

- 認証
  DMARC は、SPF と DKIM の認証結果を組み合わせて、メールの送信元ドメインの正当性を検証します
- ポリシー
  DMARC は、認証に失敗したメールをどのように処理するかを、ポリシーとして定義できます
- レポート
  DMARC は、認証結果を送信元ドメインに報告できます

ポリシーは、以下の 3 種類に分けられます。

- p=none
  認証に失敗したメールをすべて受信する
- p=quarantine
  認証に失敗したメールを、受信者から隔離する
- p=reject
  認証に失敗したメールを、受信者に拒否する

### DMARC レコードの例

「example.com」でポリシーを「none」、レポートの送り先を「dmarc-fb@example.com」に設定する場合、以下のように記述します。

今回のガイドラインでは、ポリシーは「none」でも問題ありません。

```
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-fb@example.com"
```

## ARC ヘッダについて

ARC（Authenticated Received Chain）とは、メールの認証状況を伝達し、なりすましメールや不正な改ざんを防ぐための技術です。<br>
SPF、DKIM、DMARC と連携して、メールの信頼性をさらに高める役割を果たします。<br>
メーリングリストやメールボックスプロバイダの自動転送機能などでメールを転送する場合、SPF や DKIM が失敗することがあるため、それを回避するために ARC ヘッダを追加する必要があります。

## TLS 接続について

TLS（Transport Layer Security）とは、インターネット上での通信を暗号化し、安全性を高めるための技術です。HTTPS や IMAP、POP3、SMTP などのプロトコルで使用され、通信内容の盗聴や改ざん、なりすましを防ぎます。

TLS 接続に対応しているメール配信システムを利用していれば問題ありません。

## ワンクリックでの配信停止について

今回のガイドラインでは、マーケティング目的のメールは 1 クリックでの配信停止の対応が必要です。<br>
具体的には、[RFC8058](https://datatracker.ietf.org/doc/html/rfc8058)に従い、以下をメールヘッダに含む必要があります。

配信停止リクエストを API 等で処理する場合は下記のように記述します。

```
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://example.com/unsubscribe>
```

配信停止リクエストを指定されたアドレスにメール形式で送信する場合は下記のように記述します。

```
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <mailto:unsubscribe@example.com>
```

[Google の FAQ](https://support.google.com/a/answer/14229414)によると、メール本文内の配信停止リンクを設置するだけでは要件を満たさないのでご注意ください。

## 各種設定の確認方法

設定が正しく適用されているか確認するためのツールを紹介します。

### [dmarcian](https://dmarcian.com/)

SPF、DKIM、DMARC レコードを診断してくれるツールです。

### [mail-tester](https://www.mail-tester.com/)

メールを実際に分析し、送信ドメイン認証のほか、様々な観点で送信メールのチェックを行い、10 点満点で評価をしてくれます。

## まとめ

ガイドラインの要件を満たしていない場合、メールがブロックされたり、迷惑メールに振り分けられたりする可能性が高くなるので、なるべく早く対応することをおすすめします。<br>
また、[ガイドライン](https://support.google.com/a/answer/81126)は今後も更新される可能性があるため、定期的にチェックしましょう。<br>
また、Google だけでなく、[米国 yahoo でも同様のアナウンス](https://blog.postmaster.yahooinc.com/post/730172167494483968/more-secure-less-spam)がされていますので、利用している方はこちらも対応が必要です。

## 参考

- https://blastmail.jp/blog/spam/gmail-guideline-202402
- https://sendgrid.kke.co.jp/blog/?p=17213
- https://sendgrid.kke.co.jp/blog/?p=5190
- https://sendgrid.kke.co.jp/blog/?p=1822
- https://www.value-domain.com/media/spf-record/
- https://www.cloudflare.com/ja-jp/learning/dns/dns-records/dns-dkim-record/
- https://hp-shizuoka.jp/column/2016/10/7515/
- https://baremail.jp/blog/2022/06/16/2552/
- https://docs.oracle.com/ja-jp/iaas/Content/Email/Tasks/configure-dkim-using-the-console.htm


20240202_1.jpg

Gmail 送信のガイドラインへの適応

## はじめに

本記事では、これから TDD の導入を考えている方や、TDD を導入している案件に携わる方に向けて、私が実際に TDD をやってみて感じたメリット・デメリットをまとめたいと思います。

## テストの重要性

テストは、ソフトウェアの品質向上や開発効率化に欠かせないものになってきています。テストを効果的に活用することで、ソフトウェアの品質や信頼性を向上させ、開発コストを削減することができます。

## TDD(テスト駆動開発)とは

テスト駆動開発（Test-Driven Development、TDD）は、ソフトウェア開発の手法の一つで、テストの作成から始めて、その後にコードを実装するというサイクルを繰り返すことで、品質の高いソフトウェアを開発する手法です。
手動テストするのではなく、[Jest](https://jestjs.io/ja/)や[JUnit](https://junit.org/junit5/)などのテストフレームワークを使用します。

一般的な開発では、下図のように設計とテスト作成は分けて行うと思います。

 ![image](/uploads/20230908_2_b6073f3e4b.png) 

TDD では、最初にテストを作成します。
テスト作成 ≒ 設計のようなイメージです。

 ![image](/uploads/20230908_3_11d5709f45.png) 

## TDD の基本サイクル

TDD は「レッド」「グリーン」「リファクタリング」と呼ばれる工程で進められます。各工程で何をするのか、説明していきます。

### レッド

要件から、実装する機能のテストを作成します。この段階では実装をしていないので、テストはすべて失敗します。
テストツールを使っているときにテストが失敗すると赤色でエラー表示されるため、この工程はレッドと呼ばれます。

### グリーン　

レッドで作成したテストをもとに、実装を行います。
ここで重要なのは、完璧なコードを書くことではなく、先に設定したテスト条件を全てクリアさせるだけの「最小限」のコードを書くということです。
テストツールを使っているときにテストが通ると緑色でエラー表示されるため、この工程はグリーンと呼ばれます。

### リファクタリング

すべてのテストが通るようになったら、リファクタリングを行ってコードの可読性を高めます。
この工程は後回しになりがちですが、プログラムの規模が大きくなると大変になってしまうので、こまめにリファクタリングすることをお勧めします。

## TDD のメリット

TDD を実施すると、以下のようなメリットがあります。

### 安心して実装ができる

テスト条件を全てクリアさせるように実装することで、実装漏れやバグの発生を抑制できます。
また、何を実装すれば良いのかはテストを見ればすぐにわかるので、工数の削減が期待できます。

### 品質向上

テストが既にあることで、開発者がコードを変更する際にも、影響を受ける他の部分に対して問題がないかを確認できます。また、テストが十分にカバレッジされている場合、バグやエラーを早期に発見できるため、ソフトウェアの信頼性が向上します。

### ドキュメントとしての役割

テストコードはソフトウェアの仕様や振る舞いを示すドキュメントとして機能します。ソフトウェアの動作がテストによって明確になり、コードの理解が容易になります。
テストコードはソフトウェアの変更に伴って、常に最新の状態に保つ必要があります。そのため、テストコードはソフトウェアのバージョン管理システムに登録し、管理することが一般的です。

### リファクタリングのサポート

リファクタリングを行う前に、テストケースを実行して、リファクタリング後にもテストが通ることを確認することで、ソフトウェアの外部的な振る舞いを保てていることになるため、安全にリファクタリングを行うことができます。
また、リファクタリングで起きがちなデグレ(デグレード)やバグの発生を防止できます。

## TDD のデメリット

TDD は、ソフトウェアの品質向上や開発効率化に効果的な手法ですが、導入にはいくつかの課題があります。

### テストを作るのに時間(工数)がかかる

TDD は、テストコードを先に作成する必要があるため、開発プロセス全体において時間がかかることがあります。
ただし、長期的にはバグの減少や品質向上が見込めることから、開発全体で考えると時間の節約と考えることもできます。

### 熟練度と学習コスト

TDD は、初めて取り組む開発者にとっては学習コストがかかる場合があります。
効果的なテストを作成するためには、適切なテストケースを選択し、適切なカバレッジを持つことが必要です。
しかし、開発の初期段階に完璧なテストコードを書くのは難しいので、今思い浮かぶ機能の中でテストを作成し、仕様変更などのタイミングでより細かいテストを増やしていく方針で進めていました。

### テストの保守

ソフトウェアの変更に伴い、テストコードも頻繁に更新する必要があるため、テストの保守に工数がかかることがあります。
TDD を導入する際にはその負担をチームに理解してもらう必要があります。

## 課題の解決策

TDD の課題を解決するためには、以下のような対策が考えられます。

### テストコードの自動生成ツールを活用する

テストコードの自動生成ツールとは、ソフトウェアの設計や仕様を元に、テストコードを自動的に生成してくれるツールです。
例えば、テストフレームワークに[Jest](https://jestjs.io/ja/)を使用しているのであれば、[jest-test-gen](https://github.com/egm0121/jest-test-gen)などがあります。
テストコードの自動生成ツールを活用することで、テストコードの作成にかかる時間を短縮することができます。

### テストケースの標準化を図る

テストケースの標準化とは、テストケースの作成や評価に使用するルールや手法を定義することです。
テストケースの標準化をすることで、開発者の経験やスキルに依存することなくテストコードを作成できるため、テストコードの作成や保守の効率化を図ることができます。

### チームでのテスト文化を醸成する

チームでのテスト文化を醸成することで、テストの重要性や必要性を理解してもらい、テストへの協力を得やすくなります。

## まとめ

私は気になるところがあるとすぐにリファクタリングしたくなっちゃう性格なので、TDD にはとても助けられています。
TDD は、一見面倒な手法に思われるかもしれませんが、バグの早期発見や仕様の理解、コードの品質向上など、多くのメリットがあります。
メリットとデメリットを理解した上で、適切に活用していきましょう！

## 参考リンク

- [テスト駆動開発（TDD）とは？基本サイクルと運用時の注意点を解説！【ソフトウェア開発・テスト用語 】| Qbook](https://www.qbook.jp/column/713.html)
- [テスト駆動開発（TDD）入門](https://products.sint.co.jp/ober/blog/tdd)
- [テスト駆動開発（TDD）とは？目的やメリット・デメリット、やり方を解説 ｜ソフトウェアテストの SHIFT](https://service.shiftinc.jp/column/4654/)

20230908_1.jpg

TDD(テスト駆動開発)について

【Git初心者向け】ソースツリーを利用したGit操作について

<p>最近のシステム開発ではGitを使うことが一般的になってきました。<br />
実際、スターフィールドでもほぼすべての案件でGitを活用しています。</p>
<p>しかし、Gitは覚えることが多く仕組みも複雑なため、これからGitを使い始める人にとっては高いハードルになっているでしょう。<br />
私も初めてGitを使った時は何がなんだかさっぱりわかりませんでした。</p>
<p>この記事では</p>
<ul>
<li>これからGitを使い始めるけど、用語とか仕組みが全然わからない！</li>
<li>名前はなんとなく聞いたことあるけど、どんなものなのかわからない！</li>
</ul>
<p>という人向けに、基本的な用語や仕組みを重点的に説明します。</p>
<h2>そもそもGitとはどういうものなのか？</h2>
<p>Gitは、ざっくり言うとファイルを「いつ・誰が・どこを・どのように」編集したかを管理するツールです。</p>
<p>ファイルの変更履歴を管理するツールは昔から多数存在しますが、Gitはそのツールの中でも分散型バージョン管理システムという分類にあたります。<br />
分散型バージョン管理システムの特徴は、各自のPCにファイルを持ち、自分の好きなタイミングで編集内容を同期(プッシュやプル)できることです。<br />
同期さえしなければ、どんなにファイルを編集したり削除しても別の作業者に影響しないというメリットがあります。<br />
そのため、Gitは複数人で開発をする際に多く利用されています。</p>
<p>また、集中型バージョン管理システムというものも存在し、CVS・Subversionなどがこれに該当します。<br />
これらは編集が完了したらすぐに作業者全員に共有されるので、誤った変更内容を登録すると作業者全員に影響を与えてしまいます。</p>
<h2>GitとGitHubの違い</h2>
<p>Gitを使う際に、GitHubもセットで登場してくることが多いので混同する方もいると思いますが、GitとGitHubは同じものではありません！<br />
上記で述べたように、Gitは分散型バージョン管理システムというツールです。<br />
一方でGitHubはGitの仕組みを利用した、開発支援をしてくれるwebサービスです。<br />
Gitは「システム」でGitHubは「サービス」のような関係にあたります。<br />
「メール」というシステムにおける「Gmail」というサービス、「動画」というシステムにおける「YouTube」というサービス、といったような関係と同じものです。</p>
<h2>Gitの仕組み</h2>
<p>Gitは以下のような構造でファイルの変更履歴を管理しています。</p>
<p><img loading="lazy" class="alignnone size-medium wp-image-11600" src="/uploads-archive/lc/2023/03/5135bc1d47ef31711ee94ad1dd2aea87-300x225.png" alt="" width="600" height="450" srcset="/uploads-archive/lc/2023/03/5135bc1d47ef31711ee94ad1dd2aea87-300x225.png 300w, /uploads-archive/lc/2023/03/5135bc1d47ef31711ee94ad1dd2aea87-768x576.png 768w, /uploads-archive/lc/2023/03/5135bc1d47ef31711ee94ad1dd2aea87-600x450.png 600w, /uploads-archive/lc/2023/03/5135bc1d47ef31711ee94ad1dd2aea87.png 960w" sizes="(max-width: 600px) 100vw, 600px" /></p>
<p>用語と仕組みを説明していきます。</p>
<h3>リポジトリ（repository）</h3>
<p>ファイルやディレクトリを保存している場所のことです。<br />
変更履歴もリポジトリに保存しています。<br />
リポジトリには以下の2種類があります。</p>
<h4>リモートリポジトリ（remote repository）</h4>
<p>主にサーバー上にあるリポジトリで、作業者全員の編集内容を共有するためのリポジトリです。<br />
各PCで行った編集内容を取りまとめしているリポジトリです。<br />
GitHubなどのサービスを利用することで、誰でも簡単にリモートリポジトリを作成できます。</p>
<h4>ローカルリポジトリ（local repository）</h4>
<p>自分のPC上にあるリポジトリです。<br />
作業者はこのリポジトリに対して編集します。</p>
<h3>クローン（clone）</h3>
<p>一言で言うと「ダウンロード」に近い機能です。<br />
リモートリポジトリから、自分のPCにローカルリポジトリを作成します。<br />
ほとんどの場合、Gitで最初に行う作業となります。</p>
<h3>プル（pull）</h3>
<p>リモートリポジトリにある最新の変更内容をローカルリポジトリに反映する機能です。<br />
クローンと少し似ている機能ですが、クローンはリモートリポジトリの内容をすべてダウンロードするのに対し、プルはローカルリポジトリに反映されていない最新の変更内容のみをダウンロードします。</p>
<h3>フェッチ（fetch）</h3>
<p>リモートリポジトリにある最新の変更履歴をローカルリポジトリに反映する機能です。<br />
プルと少し似ている機能ですが、プルは変更内容も反映するのに対し、フェッチは変更履歴のみを反映します。</p>
<h3>プッシュ（push）</h3>
<p>一言で言うと「アップロード」に近い機能です。<br />
ローカルリポジトリの変更内容をリモートリポジトリに反映します。<br />
プッシュを行うことで、自分の変更内容をリモートリポジトリに反映し、別の作業者がプルすることで自分の変更を別の作業者に反映できます。</p>
<h2>コミット（commit）</h2>
<p>ゲームで例えると「セーブ」のような機能です。<br />
コミットを実行することで、ファイルの変更履歴をローカルリポジトリに記録できます。<br />
また、コミットメッセージを記入すれば、このコミットでどのような変更をしたかなどを記録できます。</p>
<p><img loading="lazy" class="alignnone size-medium wp-image-11601" src="/uploads-archive/lc/2023/03/8fdcc7d29d3c66ae37c29c8503f30619-300x123.png" alt="" width="600" height="246" srcset="/uploads-archive/lc/2023/03/8fdcc7d29d3c66ae37c29c8503f30619-300x123.png 300w, /uploads-archive/lc/2023/03/8fdcc7d29d3c66ae37c29c8503f30619-768x315.png 768w, /uploads-archive/lc/2023/03/8fdcc7d29d3c66ae37c29c8503f30619-600x246.png 600w, /uploads-archive/lc/2023/03/8fdcc7d29d3c66ae37c29c8503f30619.png 957w" sizes="(max-width: 600px) 100vw, 600px" /></p>
<p>コミットを行わないと編集した内容がローカルリポジトリに適用されず残り続けてしまうので、編集が完了したら忘れずにコミットしましょう！</p>
<p>&nbsp;</p>
<p>さらに、コミットする前段階に「ワークツリー」と「インデックス」というものがあります。<br />
コミットするためには、以下のような段階を踏む必要があります。</p>
<p><img loading="lazy" class="alignnone size-medium wp-image-11602" src="/uploads-archive/lc/2023/03/2e1d56395b7836f2c7e7eefd0a2aadf5-300x111.png" alt="" width="600" height="222" srcset="/uploads-archive/lc/2023/03/2e1d56395b7836f2c7e7eefd0a2aadf5-300x111.png 300w, /uploads-archive/lc/2023/03/2e1d56395b7836f2c7e7eefd0a2aadf5-768x283.png 768w, /uploads-archive/lc/2023/03/2e1d56395b7836f2c7e7eefd0a2aadf5-600x221.png 600w, /uploads-archive/lc/2023/03/2e1d56395b7836f2c7e7eefd0a2aadf5.png 950w" sizes="(max-width: 600px) 100vw, 600px" /></p>
<h3>ワークツリー</h3>
<p>現在編集中の内容を仮置きしている場所です。<br />
ワークツリー内にある変更内容はコミットされないので、コミットしたい変更内容をインデックスに登録(add)する必要があります。</p>
<h3>インデックス</h3>
<p>コミットする変更内容を仮置きしている場所です。</p>
<p>&nbsp;</p>
<p>なぜこのような機能があるかというと</p>
<ul>
<li>この変更、まだ途中だから今はコミットしたくない</li>
<li>この変更は複数のコミットに分けたい</li>
</ul>
<p>という時に、変更した一部分だけコミットできるようにするためです。<br />
使い慣れるととても便利な機能なので、ワークツリーとインデックスを積極的に活用していきましょう！</p>
<h2>ブランチ（branch）</h2>
<p>感覚的な例えになってしまいますが、「パラレルワールド」のようなことを実現できます。<br />
以下のように、ファイルの変更内容を分岐させて記録できます。</p>
<p><img loading="lazy" class="alignnone size-medium wp-image-11603" src="/uploads-archive/lc/2023/03/a7532ee5b4e19612918b9757dcfbf02d-300x120.png" alt="" width="600" height="240" srcset="/uploads-archive/lc/2023/03/a7532ee5b4e19612918b9757dcfbf02d-300x120.png 300w, /uploads-archive/lc/2023/03/a7532ee5b4e19612918b9757dcfbf02d-1024x410.png 1024w, /uploads-archive/lc/2023/03/a7532ee5b4e19612918b9757dcfbf02d-768x308.png 768w, /uploads-archive/lc/2023/03/a7532ee5b4e19612918b9757dcfbf02d-600x240.png 600w, /uploads-archive/lc/2023/03/a7532ee5b4e19612918b9757dcfbf02d.png 1028w" sizes="(max-width: 600px) 100vw, 600px" /></p>
<p>なぜこのような機能があるかというと、複数人で開発する際にありがちな</p>
<ul>
<li>別の人が変更した内容のせいで自分の修正した箇所が動かなくなった・・・</li>
<li>同じファイルを複数人で編集したせいで、変更内容が消えた・・・</li>
</ul>
<p>という問題を防ぐためにあります。</p>
<p>&nbsp;</p>
<p>ブランチを作成することによって、別のブランチでコミットした内容に影響されず開発を進めることができ、作業の効率化を図ることができます。</p>
<p>また、自分のブランチでコミットした内容は別のブランチでは影響がないため、自分のコミットした内容に不具合があっても別の作業者に迷惑をかける心配もありません。</p>
<p>スターフィールドでは、機能の追加や不具合の修正などの作業単位でブランチを分けることが多いです。</p>
<p>複数人で開発する際は積極的にブランチを利用することをお勧めします！</p>
<h3>マージ（merge）</h3>
<p>2つのブランチでコミットした変更内容を統合させる機能です。<br />
以下のように、機能追加のため切り分けたブランチで作業が完了し、メインのブランチに変更内容を適用する際にこの機能を利用します。</p>
<p><img loading="lazy" class="alignnone size-medium wp-image-11604" src="/uploads-archive/lc/2023/03/c0731fa21e459a7fcbc6fb0c07356808-300x85.png" alt="" width="600" height="170" srcset="/uploads-archive/lc/2023/03/c0731fa21e459a7fcbc6fb0c07356808-300x85.png 300w, /uploads-archive/lc/2023/03/c0731fa21e459a7fcbc6fb0c07356808-1024x291.png 1024w, /uploads-archive/lc/2023/03/c0731fa21e459a7fcbc6fb0c07356808-768x218.png 768w, /uploads-archive/lc/2023/03/c0731fa21e459a7fcbc6fb0c07356808-600x171.png 600w, /uploads-archive/lc/2023/03/c0731fa21e459a7fcbc6fb0c07356808.png 1027w" sizes="(max-width: 600px) 100vw, 600px" /></p>
<h3>コンフリクト（conflict）</h3>
<p>同じファイルの同じ箇所を変更したブランチをマージする際に起きる現象です。</p>
<p>コンフリクトを解消しないと、マージできません。</p>
<p>コンフリクトが多発すると作業効率が落ちてしまうので、できるだけコンフリクトを起こさないようにしましょう！</p>
<p>できるだけ他の作業者が変更している、または変更しそうなファイルはいじらないようにすればコンフリクトは抑えられます。</p>
<h2>その他Gitの便利機能</h2>
<p>私がよく使っているGitの機能を紹介します。</p>
<h3>リバート（revert）</h3>
<p>特定のコミットで変更した内容を打ち消すコミットを作成します。</p>
<p>この機能を使うことによって、特定のコミットの変更を無かったことにできます。</p>
<h3>アメンド（amend）</h3>
<p>1つ前のコミット内容とコミットメッセージを修正する機能です。</p>
<p>コミットし忘れたファイルがあったり、コミットメッセージに誤字があった時に修正できます。</p>
<p>プッシュ済みのコミットや2つ以降前のコミットには使えないので注意が必要です。</p>
<h3>スタッシュ（stash）</h3>
<p>コミットしていない変更内容を「一時退避」する機能です。</p>
<p>今の作業を中断して別の作業をする時などに、今の変更内容はとっておきたいけど一旦無かったことにしたい時に便利です。</p>
<h2>まとめ</h2>
<p>この記事では、Gitを活用するために必要な用語と仕組みを紹介しました。</p>
<p>Gitはプログラム開発などを行うエンジニアにとっては必須のスキルになりつつあるので、ぜひ身につけておきましょう！</p>
<h2>参考にさせていただいたサイト</h2>
<p><a href="https://tcd-theme.com/2019/12/what-is-Git.html">https://tcd-theme.com/2019/12/what-is-Git.html</a></p>
<p><a href="https://www.i3design.jp/in-pocket/3111#GitHub%E3%81%A8%E3%81%AF%EF%BC%9F">https://www.i3design.jp/in-pocket/3111#GitHub%E3%81%A8%E3%81%AF%EF%BC%9F</a></p>
<p>&nbsp;</p>


Company

Our Solutions

Support

News

Blog

Blogブログ

カテゴリーから探す

年別から見る

記事一覧 - Author: airou

2024/08/02

2024/04/05

2024/02/02

2023/09/08

2023/06/09

2023/03/03