
fwywd チームでは新ブログを Tailwind UI の Syntax を使用して実装予定です。

[Syntax - Tailwind CSS Documentation Template](https://tailwindui.com/templates/syntax)

記事の表示と記事作成画面のプレビューを揃えたい & 後々の Syntax 導入をスムーズにしたい目的で Tailwind UI の Syntax ベースの Markdown Viewer を実装しました！

## markdoc のライブラリをインストール

```bash
yarn add @markdoc/markdoc @markdoc/next.js -D
```

## next.config.js を書き換える

括弧の位置を間違えやすいので注意が必要です。

```jsx
// next.config.js

const withMarkdoc = require('@markdoc/next.js');

/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
  images: {
    deviceSizes: [340, 640, 768, 1024, 1280, 1440, 1980],
    domains: [],
  },
  pageExtensions: ['js', 'jsx', 'ts', 'tsx', 'md'],
};

module.exports = withMarkdoc()(nextConfig);
```

## Prose.tsx

Markdoc で変換したデータを children で渡し画面表示するコンポーネントです。

Tailwind CSS の prose というクラスによって余白や文字間を調節しています。

下準備として、clsx, @tailwindcss/typography をインストールします。

```bash
yarn add clsx -D

yarn add @tailwindcss/typography -D
```

tailwind.config.js に plugins を追記します。

```jsx
plugins: [require('@tailwindcss/typography')],
```

Prose.tsx の内容は以下です。

```tsx
// Prose.tsx

import clsx from 'clsx';
import { ReactNode } from 'react';

interface ProseProps {
  children: ReactNode;
  className?: string;
}

export const Prose: React.FC<ProseProps> = ({ className, ...props }) => (
  <div
    className={clsx(
      className,
      'dark:text-gray-400 prose prose-gray max-w-none dark:prose-invert',
      // headings
      'prose-headings:font-display prose-headings:scroll-mt-28 prose-headings:font-normal lg:prose-headings:scroll-mt-[8.5rem]',
      // lead
      'prose-lead:text-gray-700 dark:prose-lead:text-gray-700',
      // links
      'prose-a:font-semibold dark:prose-a:text-primary-500',
      // link underline
      'prose-a:no-underline prose-a:shadow-[inset_0_-2px_0_0_var(--tw-prose-background,#fff),inset_0_calc(-1*(var(--tw-prose-underline-size,4px)+2px))_0_0_var(--tw-prose-underline,theme(colors.primary.200))] hover:prose-a:[--tw-prose-underline-size:6px] dark:[--tw-prose-background:theme(colors.gray.900)] dark:prose-a:shadow-[inset_0_calc(-1*var(--tw-prose-underline-size,2px))_0_0_var(--tw-prose-underline,theme(colors.primary.800))] dark:hover:prose-a:[--tw-prose-underline-size:6px]',
      // pre
      'prose-pre:rounded-xl prose-pre:bg-gray-900 prose-pre:shadow-lg dark:prose-pre:bg-gray-800/60 dark:prose-pre:shadow-none dark:prose-pre:ring-1 dark:prose-pre:ring-gray-700/10',
      // hr
      'dark:prose-hr:border-gray-800',
    )}
    {...props}
  />
);
```

Markdoc でデータを変換して Prose.tsx に渡すコンポーネントを作成します。

```tsx
// Markdown.tsx

export const Markdown = () => {
  const doc = `
  # heading 1
  
  ## heading 2

  1. ol
  1. ol

  - ul
  - ul
`;

  const ast = Markdoc.parse(doc);
  const content = Markdoc.transform(ast);
  const children = Markdoc.renderers.react(content, React);

  return (
    <Prose className={`${style.md} h-[600px] w-full overflow-auto border border-primary-800 p-2`}>
      {children}
    </Prose>
  );
};
```

余白や文字間は Tailwind CSS の prose でいい感じになっているのでテキストの大きさや色などの装飾を CSS モジュールで適用します。

マークダウン表示できます。

![1.png](/img/pages/tech/markdown-viewer-by-markdoc/1.png)

## Fence.tsx

マークダウンの表示はできましたがコードのハイライトはされない状態です。

Markdoc の Syntax highlighting を参考にして Tailwind UI の Syntax ベースでコードのハイライトを実装します。

[Common examples](https://markdoc.io/docs/examples#syntax-highlighting)

少し複雑でした。大まかな流れとしたら、

1. code をハイライトする `Fence.tsx` を作成する
2. code を取り出してハイライト適用するための config ファイル `node.ts` を作成する
3. Markdoc でデータ変換する関数に `node.ts` から config を渡す

といった流れです。

### code をハイライトする Fence.tsx の作成

コードをハイライトするための prism-react-renderer をインストールします。

```bash
yarn add prism-react-renderer -D
```

Tailwind UI からそのまま持ってきて型付けをしています。

`<Highlight>` に渡す code の children は String(children) としないと型のエラーが発生してしまうので注意です。

```tsx
// Fence.tsx

import { Fragment, ReactNode } from 'react';
import Highlight, { defaultProps, Language } from 'prism-react-renderer';
import vsDark from 'prism-react-renderer/themes/vsDark';

interface FenceProps {
  children: ReactNode;
  language: Language;
}

export const Fence: React.FC<FenceProps> = ({ children, language }) => (
  <Highlight
    {...defaultProps}
    code={children === undefined ? '' : String(children).trimEnd()}
    language={language}
    theme={vsDark}
  >
    {({ className, style, tokens, getTokenProps }) => (
      <pre className={className} style={style}>
        <code>
          {tokens.map((line, lineIndex) => (
            <Fragment key={lineIndex}>
              {line
                .filter((token) => !token.empty)
                .map((token, tokenIndex) => (
                  <span key={tokenIndex} {...getTokenProps({ token })} />
                ))}
              {'\n'}
            </Fragment>
          ))}
        </code>
      </pre>
    )}
  </Highlight>
);
```

### ハイライトを適用させるための node.ts を作成

```tsx
// markdoc/node.ts

const node = {
  fence: {
    render: 'Fence',
    attributes: {
      language: {
        type: String,
      },
    },
  },
};

export default node;
```

### Markdoc でデータ変換する関数に config を渡す

```tsx
// Markdown.tsx

const ast = Markdoc.parse(doc);
const content = Markdoc.transform(ast, { nodes: node });
const children = Markdoc.renderers.react(content, React, {
  components: { Fence },
});
```

code がハイライトされます。

![2.png](/img/pages/tech/markdown-viewer-by-markdoc/2.png)

## まとめ

TypeScript の型付けと code のハイライト表示に苦戦しましたがなんとかなりました。

なにより Tailwind CSS の prose が便利でした！

少しマニアックなところですが参考になる方がいれば嬉しいです！


fwywd チームでは新ブログを Tailwind UI の Syntax を使用して実装予定です。記事の表示と記事作成画面のプレビューを揃えたい & 後々の Syntax 導入をスムーズにしたい目的で Tailwind UI の Syntax ベースで Markdown Viewer を実装しました！

【Azure App Service | Node.js】GitHub Actions を利用して継続デプロイしてみよう【 トラブルガイド付】

Markdoc （Tailwind UI の Syntax ベース）による Markdown Viewer の実装


Q. 「オンボーディングで最もしんどかった部分はどこでしたか？」

\ Azure App Service 一択ウ〜！/

Azure サービス群の中でも屈指の面倒臭さを誇る（当社比）Azure App Service でのデプロイ方法ガイド、始まり始まり。

本記事は[公式ドキュメント](https://docs.microsoft.com/ja-jp/learn/modules/javascript-deploy-expressjs-app-service/)を参考に作成しています。

## 使用技術

- Node.js
- Express.js
- Visual Studio Code
- [GitLens](https://gitlens.amod.io/)（Visual Studio Code の拡張機能）
- Azure App Service
- GitHub
- GitHub Actions

## この記事を読んでわかること

Azure App Service に GitHub Actions を使用してアプリケーションを継続的にデプロイするための具体的な手順。

つまり「**main ブランチへ push するたび自動的に Azure App Service へデプロイする**」ことができるようになります。

## この記事では説明しないこと

- サブスクリプション、リソースグループ、リソースなど Azure 特有の用語の数々。詳しく知りたい方は[こちら](https://docs.microsoft.com/ja-jp/learn/modules/javascript-deploy-expressjs-app-service/use-resource-group)をまず読んでみてください。
- Node.js や GitHub など使用技術に関する基礎知識

## 大まかな手順の流れ

1. デプロイしたいものを用意する
2. リソースグループを作成する
3. Azure App Service リソースを作成する
4. GitHub Actions が使えるよう準備する
5. CI/CD 経由でデプロイ

## 1. デプロイしたいものを用意

Node.js 製であればなんでも OK。基本の流れは同じです。

今回は Express.js でささっと用意しちゃいます。

[Azure が公式に用意しているサンプル](https://github.com/Azure-Samples/msdocs-javascript-nodejs-server)をクローン。

![1.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/1.png)

![2.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/2.png)

![3.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/3.png)

今回は「2-Deploy-app-to-azure」の中身だけ使用します。他は消しちゃって OK。

![4.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/4.png)

![4.5.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/4.5.png)

## 2. Azure Portal からリソースグループを作成

アカウント作成・サブスクリプションの設定についての説明・手順は省きます。

まだの方は Azure 公式サイトより無料アカウントを作成し Azure Portal へアクセス・ログインしてサブスクリプションの用意まで行ってください。

手順を詳しく知りたい人は[こちら](https://docs.microsoft.com/ja-jp/learn/modules/create-an-azure-account/)。

Azure Portal からリソースグループを作成していきます。

![5.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/5.png)

![6.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/6.png)

![7.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/7.png)

![8.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/8.png)

無事作成されれば成功。

## 3. Azure App Service リソースの作成

2で作成したリソースグループの中に Azure App Service リソースを作っていきます。

まずはプランの作成から。

![8.1.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/8.1.png)

![9.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/9.png)

Azure Service プランを選択し「作成」をクリック。

![11.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/11.png)

今回はさくっと試したいだけなので価格レベルを **Free F1** へ変更。**ここを変更しておかないと月額課金が発生するため注意！**

「確認および作成」→「作成」でリソース作成が完了します。作成まで少し時間がかかることもあるのでコーヒーでも啜りながら待ちましょう。

![12.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/12.png)

完了したら App Service で Web アプリのリソースを作っていきます。

![9.1.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/9.1.png)

![9.2.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/9.2.png)

![9.3.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/9.3.png)

「確認および作成」→「作成」で完了。こちらも時間がかかるためコーヒーをひと啜りしながら待ちましょう。完了後リソースに移動するとこんな感じ。

![9.4.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/9.4.png)

## 4. GitHub Actions の準備をしよう

まずは GitHub にレポジトリを作成しましょう。詳細な手順は省きます。GitHub アカウントを持っていない方は [GitHub 公式サイト](https://github.co.jp/)でアカウントを作成・ログインしてください。

レポジトリの作成が完了したらこんな感じのページが広がっているはず。URL をコピーしておきます。

![14.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/14.png)

1で開いていた Visual Studio Code へ戻ります。リモート先を自身で作成したレポジトリへ変更しちゃいましょう。

![16.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/16.png)

※ REMOTES なんて見当たらないよ！という人は拡張機能「GitLens」を導入してください。

![17.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/17.png)

name: origin

url: コピーした URL を貼り付け

完了したらさっそくコミット＆ブランチの発行を試してみてください。最新のものに反映されていれば成功。

![18.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/18.png)

ここからが本番。 GitHub Actions 経由でデプロイする準備を進めていきます。

3で作成した App Service へ移動し、GitHub Actions と連携させていきます。

![19.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/19.png)

![20.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/20.png)

保存するとあら便利、 GitHub 側で勝手に設定ファイルを生成してくれます。

![22.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/22.png)

## 5. CI/CD 経由でデプロイ

さっそく GitHub Actions 経由でデプロイしてみましょう。

やたら長ったらしい名前の `.github/workflows/main_fwywdazuredeployintro.yml`ファイルを `deploy.yml` へ名称変更しプッシュしてみます。

![25.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/25.png)

deploy.yml のデフォルト設定では「main ブランチに push した際にデプロイが走る」ようになっています。デプロイが終わったらさっそく確認しにいきましょう。

![23.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/23.png)

おや・・・ Azure App Service くんのようすが・・・？

![24.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/24.png)

**出たよ。親の顔より見た光景。**

アプリケーション起動時に出るエラー。Azure App Service 触ったことがある人は絶対に見たことあるやつです。私はもはや  :( を見ると首の後ろがキュッ・・・となります。

## :( Application Error に遭遇した時の対処法

基本は以下のステップで地道にエラーを潰していく形になります。

1. ログを確認する
2. 原因っぽい箇所を探して試行錯誤する

### 1. ログを確認する

Azure Portal で 該当する Azure App Service を開き「問題の診断と解決」を覗いてみましょう。下部にある「ウェブアプリダウン」をクリック。

![33.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/33.png)

現在7つの問題を抱えている模様。詳しく見ていきます。

![26.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/26.png)

### 2. 原因っぽい箇所を探して試行錯誤する

7つの問題のうち直接アプリケーションエラーを引き起こしていそうなものを探しましょう。

![27.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/27.png)

下から4つは「有料プランにアップグレードしてほしいな❤️と言っているだけ」「警告で起動失敗に関するものではなさそう」っぽいことが読み取れます。上の3つがアプリケーションエラーに関わっていそうです。さらに分析するとサーバーエラーは起動に失敗しているがために出ているものと予想されます。ここから「**コンテナクラッシュ・コンテナの問題を解決すれば起動できそう！**」と算段がつけられますね。

一番怪しげな「コンテナクラッシュ」から見ていくと・・・

![28.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/28.png)

原因がひとつ判明。**アプリをスタートさせるためのコマンドが設定されていない**ようです。さっそく設定しにいきましょう。左バーの設定内にある構成をクリックし全般設定を覗いてみます。

![29.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/29.png)

確かにスタートアップコマンドが空っぽになってますね。ではここに `npm start` ないし `yarn start` をいれよう！と通常はなるわけですが、**入れても動かないため注意**。直接 node コマンドを叩きます。`package.json` の start スクリプトを確認してみましょう。

![30.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/30.png)

`"start": "cross-env-shell DEBUG=express:* node index.js"`となってますね。`cross-env-shell DEBUG=express:*`はそれぞれ環境変数・デバッグに関するコマンドなので省略。`node index.js`だけ抜き出して入力・保存します。

![31.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/31.png)

「再起動しますか？」と聞かれるため了承して保存完了です。

ここで一度アプリを覗いてみましょう。

![32.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/32.png)

以前としてアプリケーションエラーは出たまま。まだ対処していないエラーが残っているからですね。もう一つの問題だった「コンテナの問題」を見てみます。

![34.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/34.png)

どうやらコンテナがタイムアウトしたせいで起動できていないみたい・・・というのが見て取れます。説明が若干分かり難いのですが、「アプリケーションの設定で`WEBSITES_CONTAINER_START_TIME_LIMIT`の設定時間を伸ばしてみてね」ということらしいです。さっそく変更しにいきます。

![35.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/35.png)

保存するとアプリケーションが再起動されます。これで正常に起動できるはずッ・・・

![36.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/36.png)

**で、できた〜〜〜！！！（クソデカボイス）**
おつかれさまでした・・・！

## トラブルガイド

最後に Next.js で作ったアプリケーションと NestJS で作った API をそれぞれデプロイした時に遭遇したエラーと対処法をご紹介。
同じ症状に苦しんでいるあなたに届きますように・・・！

### デプロイに時間がかかりすぎる

アプリケーションの容量が小さくない場合、デプロイまでに凄まじい時間がかかります。私の場合 Next.js で作った簡単な Todo アプリをデプロイするのに**50分**かかりました。50分待った挙句デプロイに失敗した日には泡吹いて倒れそうになります・・・（実体験）。

対処法として `deploy.yml` ファイルの中身をいじってアプリを zip 化→ GitHub Actions にアップロード→ zip を Azure App Service へアップロードするよう変更することが挙げられます。私はこれでデプロイ時間を**7分**まで短縮できました。恐るべきビフォーアフター！

参考に Next.js をデプロイした時のコードの中身を載せておきます。

```yaml
name: Build and deploy Node.js app to Azure Web App - fwywdTodoAppApi

on:
  push:
    branches:
      - main

  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest

    env:
      DATABASE_URL: ${{ secrets.DATABASE_URL }}
      DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
      DB_USERNAME: ${{ secrets.DB_USERNAME }}

    steps:
      - uses: actions/checkout@v2

      - name: Set up Node.js version
        uses: actions/setup-node@v1
        with:
          node-version: '16.x'

      - name: yarn install, build, and test
        run: |
          yarn install
          yarn build
          yarn test-setup
          yarn test:unit 
          yarn test:integration

      - name: delete node_modules dir
        run: rm -rf node_modules

      - name: Zip all files for upload between jobs
        run: zip --symlinks -r next.zip ./*

      - name: Upload artifact for deployment job
        uses: actions/upload-artifact@v2
        with:
          name: node-app
          path: next.zip

  deploy:
    runs-on: ubuntu-latest
    needs: build
    environment:
      name: 'Production'
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}

    steps:
      - name: Download artifact from build job
        uses: actions/download-artifact@v2
        with:
          name: node-app

      - name: yarn install production
        run: yarn install --production

      - name: 'Deploy to Azure Web App'
        id: deploy-to-webapp
        uses: azure/webapps-deploy@v2
        with:
          app-name: 'fwywdtodoapp'
          slot-name: 'Production'
          publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE_630E8D07124C436791B1A377E09DC005}}
          package: next.zip

      - name: Delete zip file
        run: rm next.zip
```

### デプロイが途中で止まる

こちらもアプリケーションの容量がそこそこある時に発生。`node_modules` を `npm install` または `yarn install` する際ダウンロードに時間がかかりすぎてタイムアウトするパターンです。プロジェクトフォルダ直下に`.yarnrc` ファイルを作って以下を記述することにより回避可能。

```yaml
network-timeout 600000
```

### スタートアップコマンドに関するエラー

使用するフレームワークによってはデフォルトのスタートアップコマンドが効かないことがあります。私の場合は Azure App Service 内の構成→全般設定→スタートアップコマンドに以下を入力することで解決しました。参考にどうぞ。

Next.js の場合・・・`node_modules/next/dist/bin/next start`

NestJS の場合・・・`node dist/main`

### 何が原因でエラーが起きているのかわからないとき

「アプリケーションエラーが起きてる。問題の診断と解決を見たけどそれっぽいエラーが見つからない。なんでッ！？」

これもよく遭遇します。そんな時はログストリームをみるべし。

![38.png](/img/pages/tech/deployment-by-azure-app-service-for-nodejs/38.png)

アプリを再起動→ログストリーム（プレビュー）でリアルタイムにログ出力ができるためどこで失敗しているのかわかりやすくなります。

## 番外編： NestJS デプロイで詰まった時の解決策（体験談）

状況としては GitHub Actions で zip 形式でデプロイしただけの状態で Azure Portal で何も設定していない・・・という時間軸です。

経緯まで書くと大ボリュームになるので結論だけ置いときます。

1. `deploy.yml` の中身はこちら（デプロイ時間が短縮できます）。

```yaml
name: Build and deploy Node.js app to Azure Web App - fwywdAzureDeployNest

on:
  push:
    branches:
      - master
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Set up Node.js version
        uses: actions/setup-node@v1
        with:
          node-version: '16.x'

      - name: npm install, build, and test
        run: |
          npm install
          npm run build --if-present
          npm run test --if-present

      - name: Zip all files for upload between jobs
        run: zip --symlinks -r nest.zip ./*

      - name: Upload artifact for deployment job
        uses: actions/upload-artifact@v2
        with:
          name: node-app
          path: nest.zip

  deploy:
    runs-on: ubuntu-latest
    needs: build
    environment:
      name: 'Production'
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}

    steps:
      - name: Download artifact from build job
        uses: actions/download-artifact@v2
        with:
          name: node-app

      - name: 'Deploy to Azure Web App'
        id: deploy-to-webapp
        uses: azure/webapps-deploy@v2
        with:
          app-name: 'fwywdAzureDeployNest'
          slot-name: 'Production'
          publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE_2A62A5035C4241D78AC3A13D8D636DCA }}
          package: nest.zip

      - name: Delete zip file
        run: rm nest.zip
```

2. 「Azure App Service 内の構成→全般設定→スタートアップコマンド に `node dist/main` と入力する
3. 「Azure App Service 内の構成→ アプリケーションの設定→ 新しいアプリケーション設定」で「名前：WEBSITES_CONTAINER_START_TIME_LIMIT」「値：600」と設定
4. `package.json` の script 内にあるコマンド `“start:prod”` を以下に置き換える

```json
"start:prod": "yarn build && node dist/main",
```

5. main.ts のポート設定を変更する

```TypeScript
import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  const port = process.env.PORT || 3000;
  await app.listen(port);
}
bootstrap();
```

## この3つを抑えていれば Azure App Service も怖くない（多分）

- スタートアップコマンドが適切に設定されているか
- コンテナがタイムアウトしていないか
- その他、なんらかの理由でコンテナがクラッシュしていないか（ログストリームで確認可能）

特に上2つは Node.js でのデプロイだと再現性高く目にするエラー（当社比）なので真っ先に確認してみる価値アリ。
この記事で Azure App Service アレルギーに罹っている人が1人でも減りますように・・・！

Q. 「オンボーディングで最もしんどかった部分はどこでしたか？」答えは・・・\ Azure App Service 一択ウ〜！/ Azure サービス群の中でも屈指の面倒臭さを誇る（当社比）Azure App Service でのデプロイ方法ガイド、始まり始まり。

コードを書けるエンジニアが STUDIO をビジネス向けに使ってわかったメリットとデメリット


こんにちは！ fwywd 運営チームの高橋です！

私は前職、柔道整復師として働いていました。柔道整復師とはわかりやすく言うと「整骨院の先生」です。

大阪・東京あたりにお住まいの方は整骨院やマッサージ屋さんってたくさんあるなぁ。と感じたことがあるかもしれません。整骨院・鍼灸院・整体院・マッサージ院の件数は全国で 13 万件以上あり、その数コンビニの２倍以上です！顧客を激しく取り合っているような状況です。

もはや国家資格を持っていて施術ができるということは特別なことではなく、普通に働いている、経営しているだけでは将来不安な業界です。

そんな業界でプログラミングを習得し生き抜いてきた私が、**会社でもっと活躍したい**・**起業を成功させたい**という方に**プログラミング習得をオススメする理由**をご紹介します！

## 対象読者

- 働いている業界の将来に不安がある人
- 会社で成果を挙げて特別な存在になりたい人
- 起業して業務を効率よく進めたい人

## プログラミングを習得することで得られるメリット３選

### 売上を上げられる

ビジネスをする上で避けられない問題、それは**集客**です。どれだけいいサービスを提供していてもそれが必要な人に届けられなければ売上は上がりません。今の時代、 **Web での集客は必須**です。インターネットで調べて見つからないサービスは怪しいと言われるほどです。

プログラミングを習得することでホームページ・SNS や広告による集客ができ、売上を上げることができます。場合によってはプログラミングを習得していなくても Web での集客はできますが、習得しているとよりスムーズです。ホームページ制作や広告を外注するにしても知識があれば対等に議論ができるのでオススメです。

またサービス自体をプログラミングで作り売上を上げることも可能です。利用に料金が発生するアプリケーションや、ユーザーの利用は無料でスポンサーに広告掲載してもらうアプリケーションなどですね。

### コストを下げられる

集客ができるようになったら次にすること、それは**データの集計**です。データを集計・分析し現状を把握して次の展開を考えます。データの集計を例えば電卓などでしているとどうしても**人手や時間が必要**になります。

データの集計をプログラミングで効率化しその作業にかかる時間を短縮できれば、結果的に**人件費を下げることができます**。空いた人の手でより生産的な仕事をできれば**ビジネスが加速すること間違いなし**です！

### 論理的思考能力が身につく

プログラミングをしていると、「もし〇〇ならば △△」というような条件分岐をよく使います。この考え方は仕事をする上でもよくあることです。集計されたデータを元に仮説検証して「もし〇〇ならば △△」といったように仕事を進めることがよくあります。プログラミングを学習することで論理的思考能力が身につき、その時その時で**最適な手段をとりながら効率よく仕事を進める**ことができます。

## プログラミング学習、何から始めればいいの問題

プログラミングを学習したほうがいいんだね！で、何から始めればいいの？と思った方は、

[挫折よ、さらば。未経験からエンジニアになった私のプログラミング独学サイクル](https://fwywd.com/blog/2022072703)

を参考にしてみてください。目的が売上を上げることなのか？コストを下げることなのか？それによって学習内容が変わるので、ぜひ**ゴール地点を決めて学習**してみてください。

## この記事にたどり着いたあなたに fwywd はピッタリかもしれない

この記事を読んでいるということは、あなたは**会社でもっと活躍したい**・**起業して成果を挙げたい**と思っている方だと思います。

- **仕事を通して人生の価値を最大化したい**
- **望む世界を実現するために少しでも近道をしたい**
- **ビジネスを成功させて自由に生きるために挑戦したい**

そんな方に、 fwywd では**ビジネスの成功**に主軸を置き、技術（プログラミング力）・売る力（マーケティング力）・戦略（ファイナンス力）の習得をするためのコミュニティを運営しています。

あなたの希望を実現させるためのお手伝いができれば嬉しいです！

詳しくは以下からチェックしてみてください！

[挑戦しないことがリスクになる時代へ、学び方の革命を。fwywd（フュード）次期受講生募集中！](https://apply.fwywd.com/)


会社でもっと活躍したい・起業を成功させたいという方にプログラミング習得をオススメする理由をご紹介します！

ライター直伝！読みやすさに差をつける文章濃縮術

会社で活躍したい・起業を成功させたい人にプログラミング習得をオススメする理由



時間をかけて書いたのに・・・

「**君の文、なんか読み辛いね（ズバア）**」と言われた経験、ありませんか？

記事の書き方ガイド第3弾！いよいよ本命の「文章力」を高める秘訣を前職ライターの私古川が直伝しちゃいます！

【記事の書き方ガイドシリーズ】

第1弾：[もう悩まない！PV数がぐんぐん伸びるタイトルの付け方ガイド](https://fwywd.com/blog/2022051001)

第2弾：[適当につけてない？目を引く見出しで差をつけろ！記事の見出し整頓術3つのポイント](https://fwywd.com/blog/2022072702)

## 対象読者

記事や文章を書いた時に

- 「何が言いたいのがよくわからない」と言われて悲しくなったことがある
- 書いているうちに自分がこの文で何を言いたかったのかわからなくなってくる現象に悩まされている
- 自分の文章を「より読みやすく、分かりやすく」改善したいが方法がわからず困っている

人。

## 本文の役割

「より多くの人に読んでもらいたい」観点から記事内の重要な要素を3つ並べるとしたらどうなるか、皆さん考えたことはありますか？

[適当につけてない？目を引く見出しで差をつけろ！記事の見出し整頓術3つのポイント](https://fwywd.com/blog/2022072702)

で述べた通り私は「**タイトル>見出し>本文**」と思っています（詳しくは記事参照）。しかしながら当然「本文が担う役割」は非常に大きいです。タイトルと見出しが記事の初速をコントロールする担当であるとするなら、真に記事の価値を支えるのが本文と言ったところでしょうか。記事の内容はもちろんのこと、**文体が読み辛ければ読み手の離脱率は爆上がり**します。故に「読みやすく・分かりやすい・目が滑りにくい」文章を書けるようになることは記事を執筆していく上で非常に重要なわけです。

## 読み辛い文の特徴3選

この特徴にひとつでも当てはまる文がずらずらと並んでいると文章全体の品質がダダ下がりします。自分の文章の中でこれらを発見したら直ちに改善すべきです。

### 1. 文法が明らかにおかしい

私たちは人間なので書いているうちに誤字脱字が発生したり、ちょこっと助詞の使い方がおかしくなってしまったり・・・というハプニングは往々にして起こります。そういった「凡ミス」レベルの話でなくもっと大きい括りで「それはどう見ても変じゃない・・・？」と感じさせるような文法ミスがあった時、**書き手への信頼度は失墜**します。記事として致命傷となりかねないので最も気をつけたい部分です。

最近よく見かける間違いナンバーワン（個人調べ）を一例として挙げておきます。「〜ですが、〜ですが」など逆説の接続詞を連続で並べるケースです。

✖️「りんごはおいしいですが、みかんの方がもっと好きですが、酸っぱいです」

○「りんごはおいしいですが、みかんの方がもっと好きです。あの酸っぱさが好きなんです。」

NG 文で文の主旨が一気に迷子になったことに気づきましたか？「結局何が言いたいのか」非常に伝わり難くなります。やめましょう。

### 2. 読点「、」乱れ打ち

**0が理想、1個は OK、2個でギリギリ、3個以上でアウト**です。不要な読点は可読性を一気に引き下げます。たくさん読点を打ちたくなったときは1文の中に複数の主旨が混ざり込んでいないか確認してみましょう。1文1主旨が基本です。

0個：「このりんごおいしいですね。さすが青森県産です。また買いたいです。ごちそうさまでした。」

1個：「このりんごおいしいですね、さすが青森県産です。また買いたいです。ごちそうさまでした。」

2個（ギリギリ）：「このりんごおいしいですね、さすが青森県産、また買いたいです。ごちそうさまでした。」

3個（アウト）：「このりんごおいしいですね、さすが青森県産、また買いたいです、ごちそうさまでした。」

下に行けば行くほど一目瞭然の読み辛さになっていくことがわかるかと思います。0個 or 1個で常に留めておけるとベスト。

### 3. 1文の中に「言いたいこと」が複数混ざっている

1文が超長い人にありがち。大事なことなのでもう一度言います。**1文1主旨が基本**です。「2. 読点乱れ打ち」とも関連しています。読点を乱れ打ちしした長〜い1文は言いたいことが大量に混在する最強に読みづらい文となりやすいです。稀に1文を長く取っているにも関わらず主旨の一貫性をきれいに保って非常に読みやすい文章を書く人もいますが、これは相当なやり手ライターさんのみができる芸当です（弊社吉崎がこのタイプだな〜といつも尊敬しています）。初心者はやめときましょう。

### これだけは覚えて帰ってほしい10秒でわかる結論

- 文法正しく
- 1文1主旨
- 読点2個まで

## ライター直伝！読みやすい文章のヒケツ3選

「NG な部分はわかった。けれどもっと自分の文を読みやすく改善したいんだ！」というあなたに。

前職ライター  & 記事校正・今もこうして記事をつらつら書いている私が常に気を付けている秘蔵の言葉ダイエット法、教えちゃいます！

### 1. 基本は「徹底的に短く」

私、文章の理想系は「100%濃縮ジュース」だと思っています。1文をぎゅっと、ぎゅーーーーーっと濃縮して濃厚エキスにしたものを皆さんに飲んでいただくようなイメージ。

- なくても意味が伝わる単語
- 短く言い換えることができる単語

が存在しないか？常日頃から意識していくと徐々に身に付いてくるハズです。地道に取り組んでみてくださいね。

また手っ取り早く文を短くできる小技のひとつとして **「だ・である」調を採用する**のもオススメです。「です・ます」調に比べ自然と語数が少なくなるので労せずスッキリした文が書けます。採用 OK な環境であればぜひ試してみてください。ちなみに1記事の中で「だ・である」調と「です・ます」調をまぜまぜして使用するのは NG です。ご注意を。

### 2. リズム感を意識する

これはかなり感覚的なものも含まれているのですが、**「頭の中で歯切れ良く読める文章」を意識する**と文全体が垢抜けて見えるようになります。実際読んでいても「読みやすい・わかりやすい」と感じること間違いなし。私は以下の2点を特に気を付けています。

- 可能であれば「5・7・5」に
- 韻を踏んでいるかどうか

川柳やラップをイメージするとわかりやすいかもしれません。脳内でラッパーになって文章でラップバトルしてみましょう。「なんかリズムよく読めないな〜」と思ったら字を足し引きして整えてみてください。こちらも地道に行うことで頭ひとつ抜きん出た物書きになることができます。

### 3. 「それだけ読めば8割わかる」部分を強調する

記事を書いていると抜け落ちやすい悲しい事実。人はこちらが思っている以上に文章を読んでいないこともあるということ・・・。流し読みをされても記事の本質が伝わるよう、**「ここさえ読んでおけば意味は8割伝わる」部分を強調**しましょう。強調箇所が増えすぎると逆に可読性が下がってしまうため、見出しひとつにに1-2か所・多くても3か所ぐらいを目安にすると良いでしょう。

## 「いかがでしたでしょうか」禁止令

最後に個人的な意見100%で構成されている思いの丈を叫んで締めたいと思います。

**記事の終わりに「いかがでしたでしょうか」を付けるのを今すぐやめてくれ。**

一昔前に流行った暗黒の量産コピペまとめ記事が蔓延っていた時代を思い出すんですよ・・・（泣）文章術という観点から見ても、「いかがでしたでしょうか」が記事の本質を盛り上げる何かを担えているとは到底思えません。情報量0です。いち読者としては「いかがでしたでしょうか」より「あなたの今日の晩御飯は何か」が書いてあった方がよっぽど面白いな！と思います。今からお試しあれ！（圧）


時間をかけて書いたのに・・・「君の文、なんか読み辛いね（ズバア）」と言われた経験、ありませんか？記事の書き方ガイド第三弾！いよいよ本命の「文章力」を高める秘訣を前職ライターの私古川が直伝しちゃいます！

井の中の蛙が人の力を引き出す、群に対する教育の設計術 ~ 専門家が怖くて発言できない、こんな世の中に ~


## 大人になってから学ぶの辛くないですか？

子供のときより目的意思を持って学べる大人の学びは楽しいですよね。

でも、大人になってから学ぶことが億劫になったこともありました。  
その理由は**学びを共有する相手がいないこと**です。

もちろん今どきは SNS での繋がりで共有することもできますが、思わぬ落とし穴が...。  
気軽につぶやいたつもりが、専門家から**マサカリ**と呼ばれる技術的な指摘が飛んでくることがあります。

**ツヨツヨな人の意見だけが飛び交う上級社会と化した SNS**

子供のときほど無邪気に学べないこのご時世。  
専門家が怖くて発言できない、こんな世の中に。  
もっと大人が学びやすく、**人の力を引き出すことができる教育のあり方**があるのではないか。

今回は**教育系ベンチャー企業**であるキカガク代表の私（吉崎）が、この答えの１つとして考える「**群に対する教育**」を紹介します。  
なんと「**井の中の蛙**」がヒントなんです。

## 個に対する教育の加速

### オンライン動画でいつでもどこでも学べる時代へ

![01](/img/pages/blog/educational-design-for-groups/01.jpg)

私は 1991 年生まれ、現在 30 歳。  
私が中学生のときには塾に行くか、進研ゼミや Z 会の通信教育の教材を定期購入するかしないと学校以外の学びの環境はありませんでした。  
田舎でしたが親に送り迎えをしてもらい、クラスメイトの 9 割以上が塾に通っていた記憶があります。

それが７個下の弟の頃にはスタディサプリが登場し、スマホで動画を見ながら学ぶ時代に変わっていました。  
今では教育系 YouTuber の登場により、無料でも学べる環境が増えました。  
２次元だった教科書を時間軸も含めた３次元にするためには塾に通う必要がありましたが、それも動画教材の発展により家でも学べるようになりました。  
「**どこでも**」に変わった瞬間です。

そして、もう１つ変わったことが動画は「**いつでも**」視聴することができます。  
塾の授業では決まった時間に行かないと受けられなった**同期的**なスタイルから、**非同期**で授業が受けられるようになりました。

オンライン動画で学べる時代は「**いつでも、どこでも**」といった２つのパートで大きな変革をもたらします。

### 大人の教育も C2C でさらに加速

![02](/img/pages/blog/educational-design-for-groups/02.jpg)

学生に対する教育の話でしたが、もちろん社会人である**大人の学びにもオンライン動画は変革をもたらします**。  
しかも**大人の学びの方が相性が良いこと**もありました。

高校生までの教材は文部科学省が定める方針をベースにしているため、カスタマイズできる範囲が狭く、オリジナルの教材が作りやすいです。  
それに対して、大人の学びは社会で求められるありとあらゆるテーマが対象であり、企業とはいえ簡単にオリジナルの教材を作ることができませんでした。  
特に技術系などは日進月歩であり、コストを掛けて作ったコンテンツが翌年には使い物にならないこともあります。

ここに [**Udemy**](https://www.udemy.com/) を代表とした **Consumer to Consumer (C2C)** の教育サービスが登場します。  
個人でコンテンツを作るため、教材の質とのトレードオフはあるも、**多種多様なテーマの教材が提供可能**になりました。  
大人の学びに必要な需要を満たすことができ、私も多くの恩恵を受けました。

### 実はオンライン動画の終了率は低いという事実

![03](/img/pages/blog/educational-design-for-groups/03.jpg)

そんな「**いつでも、どこでも**」に加えて「**多種多様なテーマ**」という素晴らしい教育環境を提供しているオンライン教育にも**とんでもない落とし穴**があるのです。

それは**終了率が異常なくらい低いこと**。

以下の論文によると、ベンチマークとして大学の授業などを多く無料で提供している MOOCs (Massive Open Online Courses) の**平均終了率は 4~5%** なんです。  
海外の大学の最高峰の内容を最高峰の教授陣が手掛ける授業でも**ほとんどが視聴完了されない**のです。

▶ 参考文献：[組織を越えた Learning Analytics の可能性 − その批判的検討 − | 福井県立大学 山川修 氏 (2015)](https://www.jstage.jst.go.jp/article/konpyutariyoukyouiku/38/0/38_55/_pdf/-char/ja)

### 良い教育の構成要素は「教材」と「講師」の質だけ？

![04](/img/pages/blog/educational-design-for-groups/04.jpg)

**良い教育とは何か？** とよくある議題ですが、わかりやすい構成要素が「**教材**」と「**講師**」です。  
圧倒的にわかりやすい教材、そして圧倒的にわかりやすい解説をする講師。

恥ずかしながら、以前の私もこの２つを極めることが教育企業としての行く先だと思っていました。  
そういった意味では、これまでに累計 50,000 名を超えた方に受講していただいた AI の基礎を学べる [**[キカガク流] 人工知能・機械学習脱ブラックボックスコース**](https://www.kikagaku.ai/) は１つの完成形と言えるかも知れません。

ただし、このコースも**平均終了率は 約 10%** でした。  
先述した MOOCs の例よりは２倍程度の終了率となっていますが、それでも **90% の人は終了していません**。  
「**教材**」と「**講師**」が良い教育に対して寄与率の高い構成要素であれば、これを極めた結果としては **80~90%** の方が視聴完了するはずです。

つまり、**視聴完了してもらうためにはもっと他に寄与率の高い構成要素**があるのです。

> **補足 1**  
> 視聴完了だけを教育のゴールとして設計しているわけではなく、受講した人材の活躍を計測しています。多くのケースが視聴完了後から次のステップへ進むと想定されるため、活躍の前提として視聴完了を据えています。

> **補足 2**  
> ごく一部のオンライン配信でも学習が完了できる人には「教材」と「講師」の質が非常に重要と言えるため、弊社ではこれからもこの２点も追い求め続けます。これ以降は多くの人に目を向けるため、この視聴完了が高い人は議論の対象外とします。

### オンラインでもリアルタイムのライブオン研修がずっと人気な理由

![05](/img/pages/blog/educational-design-for-groups/05.jpg)

コロナ禍で教室に集まって学べる環境が提供できなくなりました。  
これにより、Zoom や Teams などのオンライン環境で講義を提供するように変わります。

オンラインであれば動画を撮影して、YouTube や Netflix のように**オンデマンド配信**で良いのでは？と仮説がありました。  
そこで、**リアルタイムで時間を拘束するライブオン研修**と、**いつでもどこでも受けられるオンデマンド配信の研修**の両方を提供してみます。  
もちろん値段はオンデマンド配信の方が安くライブオン研修の 1/2 ~ 1/3 程度です。

社会人向けの研修という前提ですが、どちらが人気だったかというと、圧倒的に**ライブオン研修**でした。  
**平均終了率は 95% 以上**と非常に高く、仕事の都合でどうしても抜けないといけない場合を除き、みなさんきっちりと終了されます。  
つまり、このライブオン研修にこそ、視聴完了してもらうために寄与率が高い構成要素が含まれているのです。

受講生へヒアリングを行い、なぜ視聴が完了できたのかを要素分解すると以下の３つがありました。

1. **時間の確保**（チームからの理解もある）
2. **仲間の存在**（モチベーションの維持）
3. **質疑応答**

3 番目の質疑応答に関しては、オンライン配信系のサービスでは Q&A を作って対応していることもあります。  
しかし、これがあっても終了率はそこまで高まっていないことを考えると寄与率はそこまで高くなさそうです。

つまり、**時間の確保**と**仲間**の２つが鍵であることが推測できます。  
しかも、同じ時間に学ぶという時間を確保すれば、必然的に同じタイミングで学ぶ仲間が生まれるので、これらは同時に満たすことができます。

ここから見えてきた教育に必要な構成要素として面白いのが、オンライン教育によって得られていた「**いつでも**」というパートを多くの人が本当は求めていなかったのです。

## 「個」から「群」に対する教育へ

### ずっと受けてきた学校の教育は群であった

![06](/img/pages/blog/educational-design-for-groups/06.jpg)

オンライン教育の加速は「**いつでもどこでも**」という視点以外に「**個人で学ぶ**」とも捉えることができます。

振り返ってみると、私達が学校や塾で受けてきた教育は常に集団、つまり「**群で学ぶ**」ように設計されていました。  
この学び方が平均終了率が高いという現代のオンライン教育の変遷から導かれたものではないと思いますが、原点回帰しています。  
ただし、昔と異なるのは「**どこでも**」という要素に関してはメリットが大きく、オンラインの恩恵は大きくあります。

大学も高いお金を払って一人暮らしをしなくても通えるようになりましたし、地方と都会の情報格差も減っています。  
また嬉しかった声としては、お子さんがいらっしゃる家庭でも自宅から受講できることで、学びに来てくれる方が多くなったことです。

これからの時代の教育は「**オンライン × 仲間**」といった**同期的な要素**も含んだものになると予想しています。

### 群に対する教育は経営目線の組織論がヒント

![07](/img/pages/blog/educational-design-for-groups/07.jpg)

「オンライン × 仲間」というと**オンラインサロン**がこの条件を満たしています。  
教育という文脈では語られることが少ないオンラインサロンですが、教育とマッチすると考えています。  
現在、私が主催している起業家コミュニティ [**fwywd（フュード）**](https://apply.fwywd.com) も**オンラインサロン**に近しいと言えます。

ただし、多くのオンラインサロンと異なる点もあります。  
私の知る限り多くのオンラインサロンは企画の発端であるリーダー格の人がいて、その人との繋がりを求める人が集まる**ぶら下がり型**です。  
**芸能人のファンクラブ**というとわかりやすいですね。

[**fwywd（フュード）**](https://apply.fwywd.com) では私との繋がりという面もありますが、それよりもコミュニティ間の会話を中心としています。  
これは私がこれまで作ってきた経営の経験に基づき**組織論**から設計しています。

### コミュニケーションには適切なサイズ設計が必要

![08](/img/pages/blog/educational-design-for-groups/08.jpg)

今の段階では以下のような構造を作っています。

1. チーム（5~8 人）→ 最も密に**同期**的にコミュニケーションを取る集団
2. バンド（30~40 人）→ **非同期**でコミュニケーションを取る集団（6 チーム程度のまとまり）
3. コミュニティ（全員）→ イベント等で出会う集団

人数が多くなってくると、バンドよりも大きな単位を随時作っていきます。  
この辺りはすでに**経営としての組織論**として適切なサイズ設計が議論されているため、先人の知恵をお借りするだけです。  
教育の問題は教育カテゴリーで議論したり調査しがちですが、結局は**組織が一番人を成長させており、経営の組織論で教育を見るべき**だと現在では私は考えています。

コミュニティとして全てをまとめないことには私の**失敗談**があります。

[**fwywd（フュード）**](https://apply.fwywd.com) の１期では合格した人から順次 Slack で作っていたコミュニティに参加してもらいました。  
最初は盛り上がったのですが、後から入ってくる人がコミュニティの適性の有無を問わず、ほとんど会話に参加できなかったのです。  
それも当然で、会話には**文脈** (**context**) の理解が不可欠であり、これがない状態だったと言えます。

どれだけ大きなコミュニティであったとしても、会話しているのはごく一部という経験がないでしょうか。  
これは後から参加した人の能力が低いのではありません。  
**会話に必要な構成要素を欠いている結果**なのです。

この失敗談から文脈を共有しやすいように、**目的を持った小さな単位のチームに分ける**こと。  
そして、**チームの始まりのタイミングを一斉にスタート（同期）すること**に決めました。

その結果、現在の [**fwywd（フュード）**](https://apply.fwywd.com) はコミュニケーションが以前よりも遥かに多くなりました。  
また、コミュニティオーナーの私一強のぶら下がり型からも徐々に解放されていき、望ましいコミュニティの形へ遷移しつつあります。

### 井の中の蛙が人の可能性を開花させる

![09](/img/pages/blog/educational-design-for-groups/09.jpg)

ここでようやく本題であった「**井の中の蛙**」です。

コミュニティ内のチームのサイズを小さく設計したデメリットは情報の正しさが確保しにくくなることです。  
答えを持たない素人同士の議論ではカオスになることがありますよね。

ここへの対策もあります。  
チームで解決できないことは１階層上のバンドに投げかけて解決していけるような流れがあります。  
また最終的には私が解決に手を貸すこともあります。

チーム内での議論がカオスになるデメリットもありますが、本当はメリットの方が大きいと思っています。  
**素人同士でも自信を持って議論することって大切じゃないですか**。  
**専門家に見張られていると、怖くて自分の意見って出せなくなりませんか？**

情報の成否は別としても自信を持って話ができることで主体性が高まり、情報を調べる感度が高まり、結果的に正しい情報にたどり着きやすくなると予想しています。  
これがまさに「**井の中の蛙**」です。  
最初から**海王類ばかりの大海原**に放たれると怖くて何もできなくないですか。  
それだったら、世間知らずかも知れないですが、まずは守られた井戸の中で成長できた方がよっぽど良いと思っています。  
成長したら次のもう少しだけ大きな井戸に入りかえることを繰り返せば良いじゃないですか。  
ルフィもそうやって七武海と戦えるレベルになっていき、今や四皇と戦うまでになりました。  
最初の島にいる敵から四皇のカイドウやビッグマムだったら、ワンピースはそうそうに終わっていたはずです。

**海王類ばかりの大海原**とワンピースの例えましたが、私達の学校教育もそうなっていました。  
私は超田舎の学校に入ったお陰で、成績優秀という位置づけをもらうことができ、だからこそ勉強が楽しかった記憶があります。  
まさに井の中の蛙で、高専に入ったら上には上がいて、京大に入ったらさらに上には上がいて...。  
それでも順番に上がっていけたから、なんとか今に繋がっています。

「**井の中の蛙**」って、実はどんなヒーローの物語にもあるのではないかと思います。

## 海王類ばかりの大海原よりも身の丈にあった井戸から

![10](/img/pages/blog/educational-design-for-groups/10.jpg)

Twitter で AI やソフトウェア・エンジニアリング、起業など専門分野について発言をするのは私でも恐怖でしかありません。  
こんな環境では**超一強**だけが育ち、それ以外の人は餌にすぎないとさえ感じます。

**ツヨツヨな人の意見だけが飛び交う上級社会と化した SNS**。  
まさに、海王類ばかりの大海原のようです。

いつの日か、こんな大海原でも暴れまわれる存在になるために、まずは**小さな井戸**から始めてみませんか。

詳しくは ↓↓ でお待ちしております。

▶ [**【次期受講生募集】起業家精神 × 学び方改革 = fwywd（フュード）| 挑戦しないことがリスクになる時代へ**](https://apply.fwywd.com/)

長文お読みいただき、誠にありがとうございました。

株式会社キカガク 代表取締役会長  
吉崎 亮介


子供のときより目的意思を持って学べる大人の学びは楽しいですよね。でも、大人になってから学ぶことが億劫になったこともありました。その理由は学びを共有する相手がいないことです。もちろん今どきは SNS での繋がりで共有することもできますが、思わぬ落とし穴が...。気軽につぶやいたつもりが、専門家からマサカリと呼ばれる技術的な指摘が飛んでくることがあります。ツヨツヨな人の意見だけが飛び交う上級社会と化した SNS。子供のときほど無邪気に学べないこのご時世。専門家が怖くて発言できない、こんな世の中に。もっと大人が学びやすく、人の力を引き出すことができる教育のあり方があるのではないか。今回は教育系ベンチャー企業であるキカガク代表の私（吉崎）が、この答えの１つとして考える「群に対する教育」を紹介します。なんと「井の中の蛙」がヒントなんです。

想像していたよりもはるか簡単に社長になった話


## はじめに

どーも、入田 / ぐるたか [@guru_taka](https://twitter.com/guru_taka) です！今回はコードの品質を保つ上で役立つ husky を紹介をします。

本記事では husky を導入し、コミットする前にステージングしたファイルに対して、Lint 系を実行し、コードの品質を保つようにします。またコミット前に、全体テストも実行。成果物は以下の通りです。

▼ コミット前に、Lint 系でエラーが出た場合
![husky_1](/img/pages/tech/husky-setup/husky_1.png)

▼ コミット前に、テストでエラーが出た場合
![husky_2](/img/pages/tech/husky-setup/husky_2.png)

### husky とは？

**husky とは Git hooks が簡単にできるパッケージ**です。Git hooks とは、コミットやプッシュなど、特定のアクションが発生したとき、特定のスクリプトを実行する仕組みになります。  
参考：[Git - Git Hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)

### husky v4 と v6 で大きな変化あり

**husky は v4 と v6 において、設定方法が大きく変わりました**。本記事では、最新版の husky v6 を扱います。

v6 の変更点やその理由については、huksy 開発者である Typicode 氏がブログで解説しています。  
参考：[Typicode's blog - Why husky has dropped conventional JS config](https://blog.typicode.com/husky-git-hooks-javascript-config/)

### lint-staged もインストール

[lint-staged](https://github.com/okonet/lint-staged) とは、ステージングしたファイルに対し、特定のコマンドが実行できるパッケージになります。

そのため **lint-staged は husky と相性がよく、一緒に使われることが多い**です。fwywd チームも lint-staged を採用しています。

参考：[okonet/lint-staged — Run linters on git staged files](https://github.com/okonet/lint-staged)

### バージョン情報

- husky：6.0.0
- lint-staged: 10.5.4

## 全体像

1. husky と lint-staged のインストール
2. lint-staged の設定
3. Git hooks の有効化
4. コミット前の hooks を作成

### 1. husky と lint-staged のインストール

まず、以下のコマンドを実行して、husky と lint-staged をインストールします。

```bash
# npm の場合
npm install -D husky lint-staged

# yarn の場合
yarn add -D husky lint-staged
```

### 2. lint-staged の設定

ステージングしたファイルに対し、実行したいコマンドを `package.json` に記述しましょう。

fwywd チームでは以下のように、ESLint と Stylelint による構文解析、また Prettier によるフォーマットを各拡張子に対し、実行しています。

```json
// package.json
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{css,less,sass,scss}": [
      "stylelint --fix"
    ]
  },
```

### 3. Git hooks の有効化

Git hooks を有効化するために、以下コマンドを実行してください。

```bash
# npm の場合
npx husky install

# yarn の場合
yarn husky install
```

すると、`.husky` ディレクトリが作成されます。

```bash
.husky
├── _
│   └── husky.sh
└── .gitignore
```

続いて `package.json` の `prepare` に `husky install` を記述しましょう。

```json
// package.json
  "scripts": {
    "prepare": "husky install"
  },
```

目的は **GitHub リポジトリから clone して各パッケージをインストールするタイミングで、Git hooks を有効化するため**です。

**■ yarn2 の場合**

**yarn2 の場合はライフサイクルに `prepare` が存在しないため、`postinstall` に記述します**。

```json
// package.json
  "private": true,
  "scripts": {
    "postinstall": "husky install"
  }
```

yarn1 と yarn2 の違いは以下のコマンドで確認しましょう。

```bash
yarn -v

# yarn1 の場合
1.X.X

# yarn2 の場合
2.X.X
```

もし、`yarn2` かつ、パッケージがプライベートではなく、公開されている場合（`"private": false`）は設定が変わります。

```bash
yarn add -D pinst
```

```json
// package.json
  "private": false,
  "scripts": {
    "postinstall": "husky install",
    "prepublishOnly": "pinst --disable",
    "postpublish": "pinst --enable"
  }
```

詳細は公式ドキュメントをご確認ください。
参考：[Husky - Git hooks](https://typicode.github.io/husky/#/?id=yarn-2)

### 4. コミット前の hooks を作成

```bash
# npm の場合
npx husky add .husky/pre-commit "npm lint-staged"

# yarn の場合
yarn husky add .husky/pre-commit "yarn lint-staged"
```

実行後、`.husky/pre-commit` ファイルが作成されます。

```bash
## .husky/pre-commit

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

# コミット前に実行するコマンド
# npm の場合
npm lint-stage

# yarn の場合
yarn lint-stage
```

`.husky/pre-commit` ファイルに、コミット前に実行したいコマンドを記述します。**今回はコミット前にテストも実行したいため、テストの実行コマンドも追記しましょう**。

```bash
## .husky/pre-commit
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

# npm の場合
npm lint-stage
# 追記
npm test

# yarn の場合
yarn lint-stage
# 追記
yarn test
```

## 最後に

以上になります。husky を導入することで、開発環境でコードの品質を最低限、担保できます。

また husky v6 よりも簡単な設定で Git hooks が使える [simple-git-hooks](https://github.com/toplenboren/simple-git-hooks) もありますので、気になる方はチェックしてみてください。

ここまでご覧いただき、ありがとうございました！

---

株式会社キカガク コンテンツマーケティング責任者  
入田 / ぐるたか  
twitter: [@guru_taka](https://twitter.com/guru_taka)

### 参考文献

- [Husky - Git hooks](https://typicode.github.io/husky/#/)

### RSS フィードで fwywd の技術記事を購読しよう

**fwywd（フュード）** のシェアボタンにある RSS フィードを利用すれば、**新しい記事が出るたびに自動的に通知を無料で受け取ることができます。**  
Slack への連携は**たったの５分**で行うことができ、以下の記事でその手順を具体的に紹介しています。

ぜひ、**fwywd（フュード）** が日々更新する技術記事をキャッチアップしていただけると嬉しいです。

手順：[**Slack の RSS フィード購読機能を使って情報収集を効率化しよう**](/blog/subscribe-rss-feed)

[![subscribe-rss-feed](/img/pages/blog/subscribe-rss-feed/ogp.png)](/blog/subscribe-rss-feed)


husky v6 のインストール方法と使い方をまとめています。lint-staged も導入することで、ステージングしたファイルに対し、Lint 系を実行できるようになります。開発環境でコードの品質を保つことができるので、オススメです！

Tailwind CSS のカラーパレットを拡張する方法

Google Search Console へのサイトマップの更新通知を GitHub Actions で定期実行しよう

husky v6 のインストール方法と使い方。lint-staged も導入して、品質を保とう


## はじめに

### 概要

**DevOps** を実現する手段として **GitHub** の機能として組み込まれている **GitHub Actions** がメジャーになってきました。  
少し前までは **Jenkins** や **Circle CI** がメジャーであり、今でもその人気は変わりませんが、ソースコード管理として日常使っている GitHub 内で**シームレスに使えることは大きなメリット**です。  
Jenkins や Circle CI には慣れているけれど、まだ GitHub Actions は触ったことがない、もしくはどれも触ったことがないけれど DevOps の方法を知りたいという方向けにわかりやすく解説しました。

### GitHub Actions とは？

![github-actions00](/img/pages/tech/introduction-to-github-actions/github-actions00.png)
出典：[https://github.co.jp/features/actions](https://github.co.jp/features/actions)

**GitHub Actions** は **GitHub** で用意されている **CI/CD（継続的インテグレーション / 継続的デリバリー）が実現できるサービス**です。  
簡単にいうと、**テストしたりビルドしたりといったサーバー側の処理**を **Push や Pull Request のタイミングで行うことができる**サービスです。

**GitHub Actions** の最もわかりやすい使用用途としては**ビルドからの公開**です。  
Next.js の場合 GitHub へ Push すると GitHub Actions が `next build` でビルドを行い、ビルド後のファイルを `main` リポジトリへアップロードし、**GitHub Pages** で公開するように設定できます。  
ここで、**GitHub Pages** も GitHub で用意されている静的ホスティングサービスです。

[**fwywd（フュード）**](/) ではデプロイ先として **Vercel** 利用しており、Vercel が DevOps に必要な CI/CD の箇所を全て担当しているため、GitHub Actions や GitHub Pages は必要ありません。  
その一方で、テストを導入する場合には GitHub Actions で自動的にテストが実装されるように設定したいため、Vercel と GitHub Actions の併用は必要となってきます。

Web 開発を行う全ての方に使い方を知っておいて欲しい **GitHub Actions** の使い方を紹介します。  
[**公式のドキュメント**](https://docs.github.com/ja/actions) では少し難しいという方を対象に、ひとつひとつ手順を追って紹介していきます。  
この記事は最初の導入編ですので、この記事で学んだ後は実際に使ったり、公式のドキュメントで知識を増やしていきましょう。

## ステップ別で紹介

今回はまず触ってみよう程度ですので、どのように GitHub Actions を触って機能の確認をしていけば良いか紹介していきます。

解説の準備として GitHub に `github_actions` のように任意の名前でリポジトリを新しく作っておきましょう。

### Step1. 機能の大枠を把握

作成したリポジトリのタブにある `Actions` を選択しましょう。

![github-actions01](/img/pages/tech/introduction-to-github-actions/github-actions01.png)

自動的に `blank.yaml` というファイルが以下のように作成されます。  
GitHub Actions は YAML 形式で表現するため、特に**他のプログラミング言語を覚える必要はありません**。  
`.github/workflows` の配下で Actions 用のファイルを管理することも覚えておきましょう。

![github-actions02](/img/pages/tech/introduction-to-github-actions/github-actions02.png)

ざっくりとここからお作法を見て、**それぞれの機能を推測してみましょう**。  
公式のドキュメントを見たり、こちらの解説記事を見て、そのまま進めるのも良いですが、「何が使えるかな？」「こういったことが実現できるかな？」と推測しながら学ぶと効果的です。

以下、私が初見で行なった機能の推測です。

- `name`：アクションを識別するための名前かな？
- `on`：アクションのトリガー
  - `push` や `pull_request` でトリガーのタイミングを指定可能
  - `branches` でブランチを指定可能
- `jobs`：具体的に設定するジョブかな？
  - `build`：指定するジョブの名前かな？具体的に `build` っていう処理ではなさそう
    - `runs-on`：`ubuntu-latest` が指定されているため Docker のイメージ名かな？
    - `steps`：具体的なタスクをステップで書いていくみたい
    - `uses`：ジョブで指定するリポジトリ？
    - `name`：コマンドに対するコメントかな？ `name` と `run` は一緒に書くのかな？
    - `run`：具体的なシェルで `|` を使えばパイプライン処理も可能みたい

このように推測しながら仕様を把握していくことで、どのように処理を実現していくのかがわかるようになってくるでしょう。  
ここで、**Docker** という用語が出てきていますが、知らない方はひとまずスルーで大丈夫です。

### Step2. Hello, world!

それでは、一度全て消してしまいましょう。  
完成形をカスタマイズすることも良いですが、やっぱり最初は慣れるまでガンガン手を動かして書いていきます。  
以下のように `Hello, world` 的な GitHub Actions を書きましょう。

参考：[新 GitHub Actions 入門](https://www.kaizenprogrammer.com/entry/2019/08/18/205010)

```yaml:github_actions/.github/workflows/hello.yml
name: Hello, world!
on: push

jobs:
  build:
    name: Greeting
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello, world!"
```

![github-actions03](/img/pages/tech/introduction-to-github-actions/github-actions03.png)

`on` に対して `push` をトリガーに指定しています。ブランチの指定はなくても OK で、全てのブランチで push された時に動作します。  
`main` ブランチだけに限定したい場合は最初の雛形にあったように

```yaml
on:
  push:
    braches: [master]
```

と書けば良いわけですね。

それでは、**作成した Action を実行**してみましょう。  
`README.md` を適当に編集して push してみてください。  
push の際には `.github/workflows/hello.yml` が追加されるので、先に `git pull origin main` が必要となります。

![github-actions04](/img/pages/tech/introduction-to-github-actions/github-actions04.png)
![github-actions05](/img/pages/tech/introduction-to-github-actions/github-actions05.png)
![github-actions06](/img/pages/tech/introduction-to-github-actions/github-actions06.png)

超簡単な処理でしたが、Action の作成および編集から実行までの流れを掴むことができました。

### Step3. リポジトリのファイルにアクセス

最後に、よく使う**リポジトリのファイルへのアクセス方法**も簡単に紹介しておきます。  
例えば、ビルドを行う場合には、リポジトリ内のファイルを取ってきて、ビルドコマンドを実行しますよね。  
ということは、**リポジトリのファイルへのアクセス**が当然生じるわけです。

ビルドの話になると複雑性が増すため、超簡素化して `sample.txt` を作ってみて、これにアクセスして `echo` で表示できるようにしてみましょう。

```bash
# sample.txt

これはサンプルです。
```

次に、workflow 用のファイルを編集しましょう。
まずは、作成した `sample.txt` にアクセスできるか確認してみましょう。

```yaml:hello.yaml
name: Access files
on:
  push:
    branches: [ master ]

jobs:
  build:
    name: Check the contents of the file
    runs-on: ubuntu-latest
    steps:
      - run: cat sample.txt
```

こんな簡単な処理を学ぶ必要なんてないよ...と思われた方。  
しかし、この結果はエラーとなってしまいます。

![github-actions07](/img/pages/tech/introduction-to-github-actions/github-actions07.png)
![github-actions08](/img/pages/tech/introduction-to-github-actions/github-actions08.png)

GitHub Actions では GitHub で管理されているソースコードとシームレスに繋がれるのですが、初期設定として利用できるわけではありません。
`uses: actions/checkout@v1` というステップが必要です。  
逆に考えると、これだけ覚えておけば、リポジトリ内のファイルへアクセスできます。

```yaml:hello.yaml
name: Access files
on:
  push:
    branches: [ master ]

jobs:
  build:
    name: Check the contents of the file
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - run: cat sample.txt
```

![github-actions09](/img/pages/tech/introduction-to-github-actions/github-actions09.png)
![github-actions10](/img/pages/tech/introduction-to-github-actions/github-actions10.png)

これでファイルにアクセスできるようになりました。

## おわりに

### GitHub Actions で DevOps を始めよう

超簡単でしたが、ビルドなどの操作のイメージがついたのではないでしょうか。  
また次のレベルとして、GitHub Actions でビルドした後に、GitHub Pages へデプロイといった DevOps の実現に挑戦してみてはいかがでしょうか。

ひとつのハードルとして、ビルド後のファイルのアップロードがあります。  
どうやって、`main` ブランチにビルド後の内容を送るかですね。

たとえば、`develop` ブランチで基本的に開発を行って、ビルド後に `main` ブランチに送る方法を以下のように実現しています。

```yaml
# .github/workflows/deploy.yaml

name: release
on:
  push:
    branches: [deploy]

jobs:
  build:
    runs-on: ubuntu-18.04

    steps:
      - name: Check the contents of the file
        uses: actions/checkout@v1
        with:
          ref: 'deploy'

      - name: Configration on Ubuntu 18.04
        uses: actions/setup-node@v1
        with:
          node-version: '10.x'

      - name: Deploy configration
        run: |
          mkdir ~/.ssh
          ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
          echo "${{ secrets.ACTIONS_DEPLOY_KEY }}" > ~/.ssh/id_rsa
          chmod 400 ~/.ssh/id_rsa

      - name: Build
        run: |
          yarn install
          yarn next build

      - name: Push to GitHub
        env:
          GITHUB_USER: 'user_name'
          GITHUB_EMAIL: 'user_email'
        run: |
          git config --local user.name "${GITHUB_USER}"
          git config --local user.email "${GITHUB_EMAIL}"
          git remote set-url origin git@github.com:${GITHUB_REPOSITORY}.git
          git add -f docs
          git add .
          git commit -m "Building website"
          git push -f origin HEAD:master
```

こちらを見ていただくとわかる通り、ビルドの処理の中で git で push しています。  
git を使うために SSH の設定が必要となっており、少し手間を感じるかもしれません。
これがベストプラクティスか不明ですが、色々試した結果、チームメンバーで一番わかりやすい方法のこちらで落ち着きました。  
他の実現方法もあると思うので、ひとつの参考程度に利用していただけますと幸いです。

今回も最後までお付き合いいただきまして、誠にありがとうございました。

株式会社キカガク 代表取締役会長  
吉崎 亮介  
twitter: [**@yoshizaki_91**](https://twitter.com/yoshizaki_91)


DevOps を実現する手段として GitHub の機能として組み込まれている GitHub Actions がメジャーになってきました。少し前までは Jenkins や Circle CI がメジャーであり、今でもその人気は変わりませんが、ソースコード管理として日常使っている GitHub 内でシームレスに使えることは大きなメリットです。Jenkins や Circle CI には慣れているけれど、まだ GitHub Actions は触ったことがない、もしくはどれも触ったことがないけれど DevOps の方法を知りたいという方向けにわかりやすく解説しました。

React / Next.js に algolia を導入して検索機能を追加しよう

Web 開発者のための GitHub Actions 入門


## はじめに

### 概要

[**fwywd（フュード）**](/) ではプロとして働く実力を養うことができる[**採用試験**](/news/recruitment) を**無料**で公開しています。  
リリースから３週間ほど経ち、早速１次試験をクリアして応募してくださる方が嬉しいことに出てきました。  
応募いただいた方には [**fwywd（フュード）**](/) チームから良い点や更に改善できる点のヒントをまとめたフィードバックを個別にお送りしています。  
今回はそのフィードバックを通して見えてきた **Web サイトをリリースする前に必ず確認したいチェックリスト**を紹介します。  
**React / Next.js / Tailwind CSS を使って Web サイトや Web アプリケーションを作っていきたい**という方に参考になると幸いです。

### fwywd の採用１次試験

まずはじめに **fwywd（フュード）** で公開している採用の１次試験の内容を簡単に紹介します。  
**React / Next.js / Tailwind CSS を使って、準備されたデザインで１ページの自己紹介サイト**を作っていただきます。

![introduction](/img/examples/introduction/01_introduction_pc.jpg)

フロントエンド実装に慣れている人には簡単ですが、日頃はバックエンドを中心に書いている人にとっては Tailwind CSS を含めた CSS の書き方の勉強が必要となります。  
また、HTML / CSS のフロントエンド実装に慣れている人には React / Next.js を学んでいただく必要があります。  
問題設定こそ簡単ですが、**どのような役割の人にとっても学びのハードルが少しある良い問題**となっています。

２次試験以降はフロントエンドも含めたバックエンド実装を課している中で、わざわざフロントエンドの実装も習得していただきたい理由があります。  
新規事業の Web アプリケーションを作り込む際は日々の機能追加に耐える能力が必要であり、フロントエンドからバックエンドまで、どのパートも対応できる幅広い力がある方が圧倒的に有利です。  
そのため、[**fwywd（フュード）**](/) のチームで働く初期のエンジニアには、フロントエンドからバックエンドまですべて対応できるようになって欲しいと考えています。

今回はこの一見簡単そうに見える１ページの Web サイトでも、プロとして意識して臨むとどのような点まで配慮しておくと良いのかを紹介します。

[![recruitment](/img/common/recruitment.jpg)](/news/recruitment-1st)

[**▶ fwywd（フュード）の採用１次試験の詳細はこちら**](/news/recruitment-1st)

## レベル１：表示系

ここは基本的なことであり、見た目で判断可能なことばかりです。  
Tailwind CSS でよく使うクラスの一例も併せて紹介します。

**fwywd（フュード）の１次試験ではレベル１がクリアできていれば合格**できるはずです。

### 内容の確認

- ユーザーが読みたいと思える内容になっているか推敲
  - １次試験の自己紹介サイトの場合はみなさんのプロフィール情報に編集しましょう
  - 自己アピールをうまく書いておければポートフォリオとして活躍します

### 表示崩れの確認

- Google Chrome の Developer Tools で PC 版やスマホ版の解像度で確認
- Google Chrome, Firefox, Safari, Edge と各ブラウザで確認

### 文字のフォントや間隔の調整

- 文字の大きさ：`text-sm` など
- 文字の太さ：`font-bold` など
- 文字の色：`text-white` など
- 文字の間隔： `tracking-wider` など
- 文章の間隔： `leading-5` など
- ホバー時： `hover:opacity-75` など

### CSS

- `_app.tsx` の `global.css` に Tailwind CSS 周りを設定
- Tailwind CSS を中心に書き、不要な CSS Modules を生み出していないか
  - 不要なグローバルの CSS はつくらない
  - `style.module.css` のようにモジュールとして読み込む
  - できれば `sass` をインストールして SCSS を使用
- `tailwind.config.js` の設定を使っているか
  - テキストや背景の色設定
  - 背景画像
- 余白：`py-2`, `mx-1` など
- レイアウト：`flex` と `grid` の使い分けなど
- グリッド間の線：`divide-x` など
- 縦横の位置：`flex` + `justify-center` や `items-center` など
- レスポンシブ対応
  - 画面に合わせた横幅の指定：`max-w-xs sm:max-w-sm lg: max-w-lg` など
  - 横方向のマージン：`mx-auto` など
  - 順番の変更：`order-2` など
- Tailwind CSS の JIT 対応：`w-[800px]`, `bg-[#59d3d4]` など

### 画像

- `width` と `height` を指定して縦横に変な歪みがないか
- `alt` を指定して画像非表示にも対応
- アイコン
  - Tailwind CSS では [heroicons](https://heroicons.com/) が推奨されている
  - [flaticon](https://www.flaticon.com/) などで他のアイコンを探すと良い
- 解説用は [Skitch](https://evernote.com/intl/jp/products/skitch) などで手順を見やすく加工できていると良い

## レベル２：SEO 系

それでは、及第点としての合格の先にあるチェックリストを確認していきましょう。  
クオリティの高い合格を目指す人はレベル２以降も挑戦してみましょう。

### meta タグ

- Next.js での設定：`Head`
- 基本的な設定：`_document.tsx`
- 可変な設定：`PageHead` などを作り、引数にデフォルトの値を必ず指定
- ファビコン `favicon.ico` を設定
- 画像やファビコンは `${domain}/ogp.png` や `${domain}/favicon.ico` などわかりやすいと親切かつディレクトリ構造が判別されにくい

### OGP 画像

- 画像サイズ：1200px x 630px
- 文字の 20% ルールはなくなったが、なるべく文字は小さい方が統計的に良い
- [freepick](https://jp.freepik.com/) などでベースとなる画像を探すと良い
- Facebook
  - Facebook OGP Debugger で確認
- Twitter
  - Twitter Card Validator で確認
  - Twitter は画像が相対パスでは取得されないため注意（絶対パスを使用）

### シェアボタン

- 各ページに対応するリンクが表示されるか確認
- シェア時の初期の文言やハッシュタグを設置しておく
- 日本語や記号は `encodeURIComponent` で文字をエンコード
  - 参考：[Twitter のシェアリンクに指定したテキストを JavaScript でエンコードする方法](/tech/sns-link-encode)
- SVG はコードの見た目が複雑になりがちなため、コンポーネント化推奨
- ボタンはなるべく自作せずに公式ページ参照：例. [はてぶ](https://b.hatena.ne.jp/guide/bbutton)参照
- 各デバイスごとにシェアしやすい位置にボタンを配置

### サイトマップ

- クローラーから効率的な検索のために設置
  - 参考：[Next.js に next-sitemap を導入して超手軽にサイトマップ sitemap.xml を生成しよう](/tech/next-sitemap)
- 購読されやすいように RSS フィードを設置
  - 参考：[Next.js に feed を導入して RSS と Atom のフィードを生成しよう](/tech/next-feed-rss-atom)
- Google Search Console に `sitemap.xml` と `feed.yaml`, `atom.yaml` を設定しておく

## レベル３：パフォーマンス系

デプロイ前は Google Chrome の Developer Tools にある Lighthouse で確認します。  
デプロイ後は Contents Delivery Network (CDN) へのキャッシュも考慮したパフォーマンス測定ができるため、PageSpeed Insights を使うと良いでしょう。  
この場合、キャッシュを考慮して計測は２回行いましょう。

### 画像

- `next/image` による最適化
  - 以下のような処理が自動化される
  - 解像度が無駄に大きすぎる画像は適切なサイズに加工
  - 画像の圧縮
  - WebP などの形式も検討
  - デバイスの解像度に合わせて出し分ける
  - 非同期で取得され初期画面の表示を邪魔しない
  - ビューポートに入ったタイミングでの遅延読み込み
- `next/image` での確認事項
  - レスポンシブ対応の場合に `config` に指定
  - 外部ドメインを使用する場合 `config` に指定
  - 画像が粗い場合は `quality` を指定
  - 背景画像に使用する場合は `objectFit` を指定
  - ロゴなど初期表示から欲しい場合は `loading` を `eager` に指定

### リンク

- `next/link` を内部リンクでは使用
  - プリフェッチが有効になり、ページ遷移が速い

### CSS

- `duration` でアニメーションの時間を調整する
- `@headlessui/react` で動作付きの実装にも挑戦する
- Tailwind CSS を使用する場合は本番環境で Purge CSS を有効にする
  - これを忘れると Page SpeedInsights で確認時に「使用していない CSS の削減」と提案がある
  - 参考：[Configure Tailwind to remove unused styles in production](https://tailwindcss.com/docs/guides/nextjs#configure-tailwind-to-remove-unused-styles-in-production)
- 不要なクラス名の増加を抑えるためになるべく Tailwind CSS を利用
- グローバルに CSS を読み込まず、CSS Modules を使う
- 読み込んで使用しているクラスを意識して必要な分だけ実装

### パッケージ

- `dependencies` と `devDependencies` を区別する
  - 開発 `dev` 時にのみ必要な場合は `yarn add --dev ***` と `--dev` オプションをつける
- 不要なパッケージの読み込みの除去
  - 手動で探すのは困難であるため VSCode などエディタの力を必ず借りる
- `chunk` が大きい場合は非同期での読み込みなど検討
  - 参考：[Next.js 製ブログページのパフォーマンスを向上させるために実施したこと](https://fwywd.com/tech/next-tech-performance)

### 動作

- `memo` や `callback` を使って、不要な親要素のレンダリングを防ぐ
  - 参考：[React.memo でトップページのレンダリングを最適化する](https://fwywd.com/tech/next-memo-animation)
- スムーズなスクロールなどユーザーとしての使いやすさを意識
  - 参考：[react-scroll を導入し超簡単に画面内のスクロールを実装しよう](/tech/install-react-scroll)
- 検索機能を付けて記事の探しやすさを向上
  - 参考：[React / Next.js に algolia を導入して検索機能を追加しよう](/tech/next-algolia)
- Google Analytics や Tags を導入
  - 参考：[Next.js(TypeScript) に Google Analytics を導入し、PV を計測する方法](/tech/next-ga-pv)

## レベル４：プロジェクト管理系

### Git

- 最新の Git にバージョンを上げる
  - `git switch` などを使う
- Visual Studiuo Code の Source Tree で GUI 管理
  - `git add .` といった操作を避ける
- `.gitignore` で不要なファイル形式のコミットを避ける
  - Next.js のプロジェクト作成時に標準で作成される
  - [gitignore.io](http://gitignore.io/) で Windows, macOS, Linux の OS 環境向けも追加しておきたい

### GitHub

- GitHub とは SSH で通信するように設定
  - なるべく HTTPS は使わない（毎度手間がかかるためパスワード認証を避ける）
- 開発を始める前に Project を作る
  - ToDo リストを書き出す
  - 着手するときに Issue に変換する
  - Pull Request で `fix` を使い、イシュー番号と紐付けることでマージして閉じる
- 小規模な場合はブランチモデルとして GitHub Flow を採用する
  - 参考：[GitHub でデフォルトのブランチを main から develop へ変更した後に main ブランチを削除から守る方法](/tech/github-switch-default-branch)
- 不要なブランチはマージ後に削除し、ローカルも定期的に削除
  - 参考：[git で main と develop 以外のブランチを一括削除するワンライナーのコマンド](/tech/git-delete-branches)
- `README.md` に必要な情報を記載
- `package.json` もプロジェクト名などを変更しておくと良い

### 静的検証ツール

- ESLint と Pretier、必要に応じて Stylelint を導入（**超推奨**）
  - Visual Studio Code の拡張機能もインストール
  - 保存と同時に ESLint が適用されるように設定
  - JavaScript はシングルクォーテーションに統一
  - セミコロンを最後につける
  - インデントは 2
- [husky](https://github.com/typicode/husky) で pre-commit 時の確認
  - ESLint のフォーマット確認を最低限入れておき、従っていないコードはコミットさせない
  - テスト駆動開発時にはテストの通過も pre-commit で必須とする

## レベル５：実装系

### 命名規則

- コンポーネントはファイル名含めてパスカルケース：`PageHeader.jsx`
- 変数や関数名はキャメルケース：`searchClient.js`

### 環境変数

- `.env` ファイルに格納して必要に応じて `.gitignore` の対象にする
  - 参考：[Next.js における環境変数 (env) の基本的な設定方法](/tech/next-env)

### ディレクトリ

- 相対パスから `src` を基準としたパスに変更
  - 参考：[【Next.js】特定のディレクトリを基準にし、絶対パスでモジュールをインポートする方法](/tech/next-base-url)

### TypeScript

- JavaScript に慣れてきたころに TypeScript へ移行を推奨
  - Visual Studio Code や ESLint との相性が良い
  - サーバーでの動作前にコード上の問題が発見できる
  - １次試験で合格した後に２次試験に入る前に１次試験の内容を TypeScript 化することを推奨
  - ２次試験ではバックエンドの内容などに加えて TypeScript も必須になるため、難易度の低いうちに習得しておくと良い

## おわりに

### たかが Web サイト、されど Web サイト

Web サイトは昔から存在し、HTML と CSS を書いて FTP (File Transfer Protocol) でサーバーにアップロードするといった時代もありました。  
今でも構造上の仕組みが変わっていないのですが、その手順が大幅に変わっており、当時よりも**学習コストはかなり増えています**。

その一方で、多彩な動作を表現できたり、読み込み速度といったパフォーマンスの良い Web サイトを作ることができるようになっています。  
**カスタマイズ性**と**学習コスト**のトレードオフは常に存在しています。

今回はたかが Web サイト１ページの構築でしたが、新しい技術の React / Next.js / Tailwind CSS を使うと、これだけ確認しておきたいことがありました。  
最初からすべて覚えておく必要はありませんので、レベル別に覚えていきましょう。

React や Next.js に関わる方の知見になっておりましたら幸いです。  
今回も長文をお読みいただきまして、誠にありがとうございました。

株式会社キカガク 代表取締役会長  
吉崎 亮介  
twitter: [**@yoshizaki_91**](https://twitter.com/yoshizaki_91)


fwywd（フュード）ではプロとして働く実力を養うことができる採用試験を無料で公開しています。リリースから３週間ほど経ち、早速１次試験をクリアして応募してくださる方が嬉しいことに出てきました。応募いただいた方には fwywd（フュード）チームから良い点や更に改善できる点のヒントをまとめたフィードバックを個別にお送りしています。今回はそのフィードバックを通して見えてきた Web サイトをリリースする前に必ず確認したいチェックリストを紹介します。React / Next.js / Tailwind CSS を使って Web サイトや Web アプリケーションを作っていきたいという方に参考になると幸いです。

絶対に間違えたくない。括弧（かっこ）と句読点にある、たった１つのルール

パブリッククラウドの選択肢として Microsoft Azure を採用する３つの理由

Web サイトをリリースする前に必ず確認したいチェックリスト ~ React / Next.js / Tailwind CSS 編 ~


## はじめに

### 概要

GitHub ではリポジトリを作成した時のデフォルトのブランチが `main` ですが、**Git Flow** などの**ブランチモデル**を適用すると、`main` は基本的に本番環境運用のためだけに存在させるべきです。  
デフォルトのブランチが `main` のままだと Pull Request を出すときの `base` となるブランチが常に `main` となってしまい、変更の手間が面倒であったり人為的なミスが生じてしまいます。  
そこで、今回はデフォルトのブランチを `main` から `develop` へ変更する方法を紹介します。

また、単にデフォルトのブランチを変更しただけでは、`hotfixes` の変更などを `main` から `develop` へ Pull Request でマージした時にブランチを誤って削除してしまう危険性があります。  
そこで、`main` ブランチを人為的なミスで削除から守る方法も併せて紹介します。

### Git Flow とは？

まず `develop` というブランチを採用するかといった議論があると思います。  
Git のブランチを運用する**ブランチモデル**としては **Git Flow** と **GitHub Flow** が有名です。  
fwywd のチームでもどのようなブランチモデルがベストであるか検討中ですが、現状では **Git Flow** を採用しています。

![gitflow](/img/pages/tech/github-switch-default-branch/gitflow.png)

出典：[A successful Git branching model](https://nvie.com/posts/a-successful-git-branching-model/)

ただし、少人数のチームで `develop` ブランチをわざわざ分ける必要があるかと聞かれると、確かにレビューの仕組みを整えておけば `develop` ブランチがなくても成立するように感じます。

Git Flow に対して、**GitHub Flow** ではこの `develop` ブランチが不要であると唱え、`main`（旧 `master`）ブランチに `feature/***` ブランチを作って Pull Request を送ってマージしていく方法です。  
以下の記事によると、2011 年の GitHub の開発チーム 35 人程度では問題なく Git Flow よりも効率良く運用できているという主張があります。

参考：[GitHub Flow](https://gist.github.com/Gab-km/3705015)

GitHub のチームが 35 人の頃なんて想像もつかないですが、この辺りの結論はもう少し吟味してから出したいと思います。
なお、**GitLab Flow** も存在し、Git Flow や GitHub Flow の足りない点を補っているようです。  
以下の記事が GitLab Flow をとてもわかりやすく解説されています。

参考：[GitLab Flow + GitHub Actions ではじめる、デプロイフローの改善・自動化 - エクサウィザーズ Engineer Blog](https://techblog.exawizards.com/entry/2021/01/21/111031)

今回は現状の fwywd チームで採用している **Git Flow** を前提として、`main` ブランチで本番環境の運用、`develop` ブランチで開発を進めるといった方針とします。

## 手順の解説

今回の手順は GitHub の GUI 操作だけで完結できるため、とても簡単です。  
事前準備として、`develop` ブランチを操作するリポジトリに作っておきましょう。

### デフォルトのブランチを main から develop へ

まず、ブランチの設定周りは `Settings > Branches` で確認することができます。

![github01](/img/pages/tech/github-switch-default-branch/github01.png)

以下の手順に示すように、ブランチを `develop` へ変更するだけです。

![github02](/img/pages/tech/github-switch-default-branch/github02.png)

![github03](/img/pages/tech/github-switch-default-branch/github03.png)

`develop` ブランチが `Default branch` に表示されていれば完了です。

![github04](/img/pages/tech/github-switch-default-branch/github04.png)

`Code` のページでも `develop` がデフォルトのブランチとして指定されているか確認しておきましょう。

![github05](/img/pages/tech/github-switch-default-branch/github05.png)

これで各種 Pull Request を送るときの `base` となるブランチが `develop` になります。

### main ブランチを削除から保護

Git Flow では **hotfixes** といって本番環境で即座に修正したい微細なミスを `main`（旧 `master`） ブランチに直接マージさせる方法を取ります。

![gitflow](/img/pages/tech/github-switch-default-branch/gitflow.png)

出典：[A successful Git branching model](https://nvie.com/posts/a-successful-git-branching-model/)

そのため、定期的に `main` から `develop` ブランチへ Pull Request を送ってマージさせることがあり、この Pull Request のマージが終わった後に、マージが終わった後の `main` ブランチを削除しますか？と聞かれ、`delete` と押してしまうと `main` ブランチがなくなってしまいます。
※ 厳密な Git Flow では hotfixes から develop ブランチにマージされるようになって、この問題は回避できるのですが、実際に運用してみると、`hotfixes > main > develop` とマージしていく方が自然だと感じています。

`main` ブランチを Vercel などのデプロイ先に指定している場合も多く、ソースコード自体が無事でも本番環境のデプロイが失敗してしまう原因となります。  
`main` ブランチを人為的に削除してしまうミスを防げるに越したことはありません。  
この `main` ブランチを削除から保護する方法はとても簡単です。

**Branch protection rules** を GitHub では設定することができます。

![github06](/img/pages/tech/github-switch-default-branch/github06.png)

![github07](/img/pages/tech/github-switch-default-branch/github07.png)

![github08](/img/pages/tech/github-switch-default-branch/github08.png)

たったこれだけで `main` ブランチが削除される問題から保護することができます。  
手順の途中にあったように、Pull Request 時のレビューを必須にしたり、直接の push を防いだりできますので、この辺りも必要に応じて設定しましょう。

## おわりに

### 人為的なミスは設定で防げる

情報漏洩などのセキュリティの事故は **大半が人為的なミス** だと言われています。  
GitHub など人為的なミスが起きやすいツールでは、プロジェクトの管理者が事前にそのようなミスを防げるように設定しているかが後々の大きな失敗から守ってくれるはずです。  
問題が起きなくても感謝はされにくいところですが、知らなかったでは済まされないため、この辺りの設定もしっかりと学んでいけると良いですね。

今回も fwywd の記事をお読みいただき、誠にありがとうございました。

株式会社キカガク 代表取締役会長  
吉崎 亮介  
twitter: [**@yoshizaki_91**](https://twitter.com/yoshizaki_91)


GitHub ではリポジトリを作成した時のデフォルトのブランチが main ですが、Git Flow などのブランチモデルを適用すると、main は基本的に本番環境運用のためだけに存在させるべきです。デフォルトのブランチが main のままだと Pull Request を出すときの base となるブランチが常に main となってしまい、変更の手間が面倒であったり人為的なミスが生じてしまいます。そこで、今回はデフォルトのブランチを main から develop へ変更する方法を紹介します。また、単にデフォルトのブランチを変更しただけでは、hotfix の変更などを main から develop へ Pull Request でマージした時にブランチを誤って削除してしまう危険性があります。そこで、main ブランチを人為的なミスで削除から守る方法も併せて紹介します。 

Twitter のシェアリンクに指定したテキストを JavaScript でエンコードする方法

git で main と develop 以外のブランチを一括削除するワンライナーのコマンド

GitHub でデフォルトのブランチを main から develop へ変更した後に main ブランチを削除から守る方法


## はじめに

Git を使ってチーム開発をしていると手元のブランチが増えすぎて削除が面倒という人いないでしょうか。  
そんな時に使えるワンライナーの便利なコマンドを紹介します。

## 結論

状況に合わせて以下のコマンドをお使いください。

### main ブランチ以外を削除したい

```bash
git branch | grep -v main | xargs git branch -D
```

### main と develop ブランチ以外を削除したい

`grep` では正規表現を利用できるため、以下のように複数文字列を OR で指定することもできます。

```bash
git branch | grep -v "main\|develop" | xargs git branch -D
```

参考：[grep で複数の単語を or 検索する方法](https://monaski.hatenablog.com/entry/2015/06/20/204612)

### main と feature ブランチ以外を削除したい

GitHub Flow で重宝するコマンドです。

```bash
git branch | grep -v "main\|feature" | xargs git branch -D
```

### コマンドの解説

これらは３つの処理をパイプライン `|` としています。

`git branch` でブランチの一覧を表示します。

```bash
❯ git branch
  develop
  hotfix/blog
* main
```

つぎに、`grep -v` で（正規表現で）指定した**文字列以外**を抽出します。

```bash
❯ git branch | grep -v main
  develop
  hotfix/blog
```

そして、これらを引数 `xargs` として `git branch -D` でブランチを削除するというわけです。

```bash
git branch | grep -v main | xargs git branch -D
```

## おわりに

`grep -v` は**正規表現**で書くことができ、厳密には `main` や `develop` という文字列を含まないブランチを削除するワンライナーのコマンドです。  
そのため、`develop-blog` といった `develop` を含む文字列は削除されません。
この辺りは正規表現を勉強してカスタマイズできると良いですね。

株式会社キカガク 代表取締役会長  
吉崎 亮介  
twitter: [**@yoshizaki_91**](https://twitter.com/yoshizaki_91)


Git を使ってチーム開発をしていると手元のブランチが増えすぎて削除が面倒という人いないでしょうか。そんな時に使えるワンライナーの便利なコマンドを紹介します。