
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) です！

Next.js における環境変数の基本的な設定方法をまとめまています。`env` ファイルの基本的な使い方の参考になれば幸いです！

## 環境変数の基本的な設定方法

バージョン 9.4 以上の Next.js から、環境変数のサポートが組み込まれています。

> This document is for Next.js versions 9.4 and up. If you’re using an older version of Next.js, upgrade or refer to Environment Variables in next.config.js.  
> 引用：[Basic Features: Environment Variables | Next.js](https://nextjs.org/docs/basic-features/environment-variables)

環境変数を設定する基本的な方法は以下の通りです。

- 基本的には `.env.local` に環境変数を定義（詳細は後述）
- 設定した環境変数を呼び出すときは `process.env.環境変数名` とする
- ブラウザで環境変数を使用したい場合は、先頭の文字を `NEXT_PUBLIC_` とする

## 環境ごとに環境変数は変更できる

Next.js では `env` ファイル名に応じて、**開発 / 本番環境で切り替えることができます**。具体的なルールは以下の通りです。

| ファイル名               | 環境         |
| ------------------------ | ------------ |
| `.env`                   | 常に読み込み |
| `.env.development`       | 開発環境     |
| `.env.production`        | 本番環境     |
| `.env.local`             | 常に読み込み |
| `.env.development.local` | 開発環境     |
| `.env.production.local`  | 本番環境     |

基本的にシークレットな値は `.env*.local` で定義を行い、`.gitignore` でリポジトリから除外します。

一方で、`.env` / `.env.development` / `.env.production` は、リポジトリに含めます。**URL や企業名などデフォルト値などを定義するときに使いましょう**。

> Note: .env, .env.development, and .env.production files should be included in your repository as they define defaults. .env\*. local should be added to .gitignore, as those files are intended to be ignored. .env.local is where secrets can be stored.  
> 引用：[Basic Features: Environment Variables | Next.js](https://nextjs.org/docs/basic-features/environment-variables)

## 環境変数の呼び出し方

環境変数を呼び出すときは、`process.env.環境変数名` となります。**ブラウザ（クライアント側）でも呼び出したい時は、環境変数名の先頭に `NEXT_PUBLIC_` を追記してください**。

実際に環境変数を設定し、サーバー側とクライアント側で呼び出して、確認してみましょう。

まず、環境変数は以下のように定義します。

```text
// .env
FOO=hogehoge
NEXT_PUBLIC_FOO=hogehoge
```

続いて `pages/index.tsx` に、サーバー側とクライアント側で定義した環境変数を呼び出します。コードは以下の通りです。

```tsx
// pages/index.tsx
import { GetStaticProps } from 'next';

// クライアント側で実行
export default function Index(): JSX.Element {
  return (
    <>
      {process.env.NEXT_PUBLIC_FOO}
      {process.env.FOO}
    </>
  );
}

// サーバー側で実行
export const getStaticProps: GetStaticProps = async () => {
  console.log(process.env.NEXT_PUBLIC_FOO, process.env.FOO);
  ...
};
```

下図のように、サーバー側では両者ともに環境変数を呼び出せましたが、クライアント側では `NEXT_PUBLIC_FOO` のみ呼び出せています。

![env_server](/img/pages/tech/next-env/env_server.png)
![env_client](/img/pages/tech/next-env/env_client.png)

このようにクライアント側で環境変数を扱うときは、変数名の先頭に `NEXT_PUBLIC_` が必要です。注意しましょう！

## 最後に

Next.js における環境変数 (env) の基本的な設定方法を紹介しました。シークレットな値だけでなく、デフォルト値も環境変数にまとめておくことで、汎用性が増します。

ぜひ参考にしてみてください！

---

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

### 参考文献

- [Basic Features: Environment Variables | Next.js](https://nextjs.org/docs/basic-features/environment-variables)
- [next.js/examples/environment-variables at canary · vercel/next.js](https://github.com/vercel/next.js/tree/canary/examples/environment-variables)
- [NextJS における環境変数まわりの挙動まとめ](https://blog.ojisan.io/next-env)


Next.js における環境変数 (env) の基本的な設定方法をまとめまています。env ファイルの基本的な使い方の参考になれば幸いです！

Next.js(TypeScript) に Google Analytics を導入し、PV を計測する方法

Azure Active Directory B2C でユーザー認証を超簡単に実装しよう

Next.js における環境変数 (env) の基本的な設定方法

2021年からReactベースのフレームワークであるNext.jsを本格的に学び始めました。昨年2020年はVue.jsベースのフレームワークであるNuxt.jsにどっぷりと使った１年であり、昨年リリースしたキカガク (kikagaku.ai) など、本運用に乗せるところまでプロダクト開発チームで学びながら進めていきました。その昨年に１年間もかけて知見を貯めたVue.js & Nuxt.jsを離れて、React & Next.jsへ移行した背景を紹介します。

react-scroll を導入し超簡単に画面内のスクロールを実装しよう

Next.js の Jest / React Testing Library でモック (mock) を含めた render で開発効率を高めよう

Vue.js & Nuxt.js から React & Next.js へ移行した理由


## はじめに

どーも、入田 / ぐるたか [@guru_taka](https://twitter.com/guru_taka) です！  
本記事では **React/Next.js (TypeScript) における Chakra UI の基本的な使い方**を紹介します。レスポンシブ対応や独自 CSS の記述方法など便利な Tips もまとめていますので、ぜひ参考にしてみてください！

> Chakra UI の導入方法については、以下の記事にまとめています。  
> 参考：[Next.js (JavaScript/TypeScript) に Chakra UI を導入する方法 | fwywd（フュード）](https://fwywd.com/tech/next-chakra-ui)

> 基本的に Next.js の PJ をベースとして、解説しています。もし、掲載しているコードが React で動作しない場合は、ディレクトリ構造やコードを適宜、確認してください。

### バージョン情報

- node：15.11.0
- react: 17.0.2
- react-dom: 17.0.1
- next: 11.1.2
- @chakra-ui/react: 1.6.7
- @emotion/react: 11
- @emotion/styled: 11
- framer-motion: 4

## 基本的な書き方

**Chakra UI は基本的にコンポーネントベースで記述します**。例は以下の通りです。

- グルーピングなど頻繁に使う `div` タグ → `Box` コンポーネント
- 見出しで使用する `h1` ~ `h6` タグ → `Heading` コンポーネント
- 文章を記述するための `p` タグ → `Text` コンポーネント
- `button` タグ → `Button` コンポーネント

コードで表現すると、以下のようになります。

```tsx
// pages/index.tsx
import { Heading, Box, Button, Text } from '@chakra-ui/react';

export default function Index(): JSX.Element {
  return (
    <Box>
      <Text>テキスト</Text>
      <Heading>見出し</Heading>
      <Button>ボタン</Button>
    </Box>
  );
}
```

![1.png](/img/pages/tech/chakra-ui-howto/1.png)

上記で紹介した Chakra UI のコンポーネントは極一部です。

Form で頻繁に使う UI コンポーネントも当然ありますし、実装が煩雑なオーバレイ系やフィードバック系 UI コンポーネント（モーダル、トースタ、スケルトンなど）も標準で搭載。さらに、便利なパンくずリストやアコーディオンなどもあり、**よく使う UI コンポーネントがほぼ網羅されています**。

下図のように[公式ドキュメント](https://chakra-ui.com/docs/getting-started)の左サイドバーに、搭載されている UI コンポーネントが羅列されています。ぜひ確認してみてください！

![2.png](/img/pages/tech/chakra-ui-howto/2.png)

基本的には、Chakra UI の機能が搭載されたコンポーネントで記述して、実装を進めましょう！

### スタイリングの方法

Chakra UI のコンポーネントに対し、**スタイリングする場合は props を使います**。例えば、フォントの太さや色、横幅などを変更したい時、コードは以下のようになります。

```tsx
// pages/index.tsx
import { Heading, Box, Button, Text } from '@chakra-ui/react';

export default function Index(): JSX.Element {
  return (
    <Box width="200px" background="gray">
      <Text color="blue" fontWeight="bold">
        テキスト
      </Text>
      <Heading>見出し</Heading>
      <Button>ボタン</Button>
    </Box>
  );
}
```

![3.png](/img/pages/tech/chakra-ui-howto/3.png)

Chakra UI コンポーネントの props に関しては、[Style Props](https://chakra-ui.com/docs/features/style-props)（下図参照）に掲載されています。種類が非常に多いため、必要に応じて確認すると、良いでしょう。

![4.png](/img/pages/tech/chakra-ui-howto/4.png)

Chakra UI は TypeScript に対応しているため、VS Code による補完が効きます。そのため、開発体験が良いです！

また、Tailwind CSS と同じように、`2xl` や `3xl` など、デフォルトの変数が用意されていますが、`10px` など適切な値を代入することも可能です。

▼ 補完の様子
![5.gif](/img/pages/tech/chakra-ui-howto/5.gif)

更に、一部の props に関しては、ショートハンド（型も対応）で表現できます。長めの props 名に関しては、略を使うと良いでしょう。以下、例になります。

- `width` → `w`
- `height` → `h`
- `background` → `bg`

その他、UI コンポーネント特有の props もあります。その場合は、各コンポーネントのドキュメントに詳細（下図参照）がありますので、適宜、確認してみてください。

![6.png](/img/pages/tech/chakra-ui-howto/6.png)

もし、**一部のコンポーネントで、特定の props が使えない場合は、使用した props が対応しているかどうか、公式ドキュメントで確認しましょう**。経験則になりますが、そのような場合は対応していないケースが多いです。

## レスポンシブ対応

レスポンシブ対応したい時は、以下のようにコードを記述します。

```tsx
// pages/index.tsx
import { Heading, Box, Button, Text } from '@chakra-ui/react';

export default function Index(): JSX.Element {
  return (
    // 追記：横幅をレスポンシブ対応
    <Box w={{ base: '150px', sm: '300px', md: '500px', lg: '700px', xl: '1000px' }} bg="gray">
      <Text color="blue" fontWeight="bold">
        テキスト
      </Text>
      <Heading>見出し</Heading>
      <Button>ボタン</Button>
    </Box>
  );
}
```

![responsive.gif](/img/pages/tech/chakra-ui-howto/responsive.gif)

各プロパティの意味は以下の通りです。

- `base`：From `0em` より大きい場合
- `sm`：From `30em`（デフォルト値）より大きい場合
- `md`：From `48em`（デフォルト値）より大きい場合
- `lg`：From `62em`（デフォルト値）より大きい場合
- `xl`：From `80em`（デフォルト値）より大きい場合

実はオブジェクト形式だけでなく、以下のように配列でも記述できます。

```tsx
// 配列
["150px", "300px", "500px", "700px","1000px"]

// オブジェクト
{ base: '150px', sm: '300px', md: '500px', lg: '700px', xl: '1000px' }
```

しかし、**配列で記述すると、閾値が直感的にわからないため、可読性の観点からオススメしません**。そのため、基本的にはオブジェクト形式でレスポンシブ対応を表現すると、良いでしょう。

## 疑似要素のスタイリング

疑似要素に関しては、以下のように `_` を先頭に付けて、表現します。以下、例になります。

- `_before` / `_after`
- `_hover`
- `_focus`

サンプルコードは以下の通りです。

```tsx
import { Heading, Box, Button, Text } from '@chakra-ui/react';

export default function Index(): JSX.Element {
  return (
    <Box>
      <Text color="blue" fontWeight="bold" _before={{ content: '"before の要素"', color: 'white' }}>
        テキスト
      </Text>
      <Heading>見出し</Heading>
      <Button>ボタン</Button>
    </Box>
  );
}
```

![before.png](/img/pages/tech/chakra-ui-howto/before.png)

詳細は公式ドキュメントを御覧ください。

参考：[Style Props pseudo - Chakra UI](https://chakra-ui.com/docs/features/style-props#pseudo)

## コンポーネントの html タグの変更

各コンポーネントの html タグを変更する場合は、 `as` という props を使用します。

例えば、`Heading` コンポーネントの html をタグを `h1` ~ `h6` に割り振る方法は以下の通りです。

```tsx
<Heading as="h1">h1</Heading>
<Heading as="h2">h2</Heading>
<Heading as="h3">h3</Heading>
<Heading as="h4">h4</Heading>
<Heading as="h5">h5</Heading>
<Heading as="h6">h6</Heading>
```

他にも自由に html タグを変更できます！

## 独自 CSS の記述方法

Chakra UI に搭載されていないスタイルを適用する場合は、`sx` という props を使用します。

例えば、テキストを縦文字で表現したい場合、独自の CSS を記述する必要があり、コードは以下のようになります。

```tsx
import { Heading, Box, Button, Text } from '@chakra-ui/react';

export default function Index(): JSX.Element {
  return (
    <Box
      sx={{
        // セレクタ
        '.vertical-mode': {
          // プロパティと値
          writingMode: 'vertical-rl',
        },
      }}
    >
      {/* sx で定義したクラス名 ".vertical-mode" を className に代入  */}
      <Heading className="vertical-mode" color="green" fontSize="7xl">
        縦文字
      </Heading>
    </Box>
  );
}
```

![vertical.png](/img/pages/tech/chakra-ui-howto/vertical.png)

`sx` の props を使用することで、独自 CSS も簡単に適用できます！

参考：[The `sx` Prop - Chakra UI](https://chakra-ui.com/docs/features/the-sx-prop)

## Chakra UI のようなコンポーネント定義

---

Chakra UI の機能を持たせたコンポーネントを定義したいケースも多々あります。

例えば、以下のようなグラデーションがかかった `Box` コンポーネントを再利用したいとします。

```tsx
import { Box, Text } from '@chakra-ui/react';

export default function Index(): JSX.Element {
  return (
    <Box>
      <Text>グラデーション１</Text>
      <Box bgGradient="linear(to-r, red,blue)" w="300px" h="200px" />
      <Text>グラデーション２</Text>

      <Box bgGradient="linear(to-r, red,blue)" w="500px" h="100px" />
      <Text>グラデーション３</Text>
      <Box bgGradient="linear(to-r, red,blue)" w="200px" h="100px" />
    </Box>
  );
}
```

![gradient-1.png](/img/pages/tech/chakra-ui-howto/gradient-1.png)

グラデーションのかかった `Box` コンポーネントをコンポーネント化すると、以下のようになります。

```tsx
// components/GradientBox.tsx
import { Box, BoxProps } from '@chakra-ui/react';
import { ReactNode } from 'react';

// BoxProps を継承
interface Props extends BoxProps {
  children?: ReactNode;
}

export default function GradientBox({ children, ...rest }: Props): JSX.Element {
  return (
    <Box bgGradient="linear(to-r, red,blue)" {...rest}>
      {children}
    </Box>
  );
}
```

そして、定義した `GradientBox` コンポーネントで共通化すると、以下のようになります。

```tsx
import { Box, Text } from '@chakra-ui/react';
import GradientBox from 'components/GradientBox';

export default function Index(): JSX.Element {
  return (
    <Box>
      <Text>グラデーション１</Text>
      <GradientBox w="300px" h="200px" />
      <Text>グラデーション２</Text>
      <GradientBox w="500px" h="100px" />
      <Text>グラデーション３</Text>
      <GradientBox w="200px" h="100px" />
    </Box>
  );
}
```

補足になりますが、`bgGradient` に別のグラデーション値を代入すると、以下のように背景色が上書きされます。

```tsx
import { Box, Text } from '@chakra-ui/react';
import GradientBox from 'components/GradientBox';

export default function Index(): JSX.Element {
  return (
    <Box>
      <Text>グラデーション１</Text>
      {/* 別のグラデーション */}
      <GradientBox bgGradient="linear(to-r, green,blue)" w="300px" h="200px" />
      <Text>グラデーション２</Text>
      <GradientBox w="500px" h="100px" />
      <Text>グラデーション３</Text>
      <GradientBox w="200px" h="100px" />
    </Box>
  );
}
```

![gradient-2.png](/img/pages/tech/chakra-ui-howto/gradient-2.png)

もし、`bgGradient` の値を固定し、props から除外したい場合は、継承する `BoxProps` から `bgGradient` を取り除きましょう。コードは以下のようになります。

```tsx
import { Box, BoxProps } from '@chakra-ui/react';
import { ReactNode } from 'react';

// Omit で bgGradient だけ除外
interface Props extends Omit<BoxProps, 'bgGradient'> {
  children?: ReactNode;
}

export default function GradientBox({ children, ...rest }: Props): JSX.Element {
  return (
    <Box bgGradient="linear(to-r, red,blue)" {...rest}>
      {children}
    </Box>
  );
}
```

他にも、`width`（ショートハンド `w`）と `height`（ショートハンド `h`）だけ、継承することも可能です。

```tsx
import { Box, BoxProps } from '@chakra-ui/react';
import { ReactNode } from 'react';

// Pick で 横幅と縦幅のみ継承
interface Props extends Pick<BoxProps, 'width' | 'height' | 'w' | 'h'> {
  children?: ReactNode;
}

export default function GradientBox({ children, ...rest }: Props): JSX.Element {
  return (
    <Box bgGradient="linear(to-r, red,blue)" {...rest}>
      {children}
    </Box>
  );
}
```

他にも TypeScript の Utility Types を使うことで、props の様々な制御が可能です。

参考：[【TypeScript】Utility Types をまとめて理解する - Qiita](https://qiita.com/k-penguin-sato/items/e2791d7a57e96f6144e5#requiredt)

以下の記事も参考になりますので、ぜひチェックしてみてください！

- [Chakra UI の再利用コンポーネント拡張の方法あれこれ](https://zenn.dev/terrierscript/articles/2021-05-11-chakra-ui-component-extends)
- [コンポーネントを拡張したものを共通化して使う｜ Chakra UI の歩き方 & Tips 集](https://zenn.dev/terrierscript/books/2021-05-chakra-ui/viewer/1-7-1-expand-box)

## 【補足】汎用性の高い便利なコンポーネント集

補足として、個人的に使いやすかった汎用性の高い Chakra UI 標準の UI コンポーネントを紹介します。

- [Box](https://chakra-ui.com/docs/layout/box)
  - 基本中の基本（`div`）
- [Container](https://chakra-ui.com/docs/layout/container)
  - メインコンテンツやサイドバーのラッパーに最適
- [Center](https://chakra-ui.com/docs/layout/center)
  - 縦と横の中央寄せ
  - 縦の中央寄せしたい時に便利
- [VStack / HStack / Stack](https://chakra-ui.com/docs/layout/stack)
  - 縦 / 横 / 縦 or 横の均等配置が簡単に実装可能
  - レスポンシブ対応で、縦横の並びが変わる時は、Stack を使うこと
  - `Spacer` コンポーネントも使うことで、`space-between` と同様の効果が得られる
- [SimpleGrid](https://chakra-ui.com/docs/layout/simple-grid)
  - シンプルなグリッド表示

その他にも便利な UI コンポーネントが Chakra UI には多数あるので、ぜひ確認してみてください！

参考：[Getting Started - Chakra UI](https://chakra-ui.com/docs/getting-started)

## 最後に

以上になります。React/Next.js で Chakra UI を使い始めた方の参考になれば幸いです。  
ここまでご覧いただき、ありがとうございました！

---

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

### 参考文献

- [Getting Started - Chakra UI](https://chakra-ui.com/docs/getting-started)
- [Chakra UI の再利用コンポーネント拡張の方法あれこれ](https://zenn.dev/terrierscript/articles/2021-05-11-chakra-ui-component-extends)
- [コンポーネントを拡張したものを共通化して使う｜ Chakra UI の歩き方 & Tips 集](https://zenn.dev/terrierscript/books/2021-05-chakra-ui/viewer/1-7-1-expand-box)


Next.js (JavaScript/TypeScript) に Chakra UI を導入する方法をまとめています。参考になれば幸いです！

IDaaS がこれからは必須！認証・認可は Azure Active Directory B2C (AADB2C) がおすすめ

Next.js (JavaScript/TypeScript) に Chakra UI を導入する方法

【React/Next.js】Chakra UI の基本的な使い方【TypeScript 対応】


## はじめに

React 向けにスムーズなスクロールを簡単に実装することができる [**react-scroll**](https://github.com/fisshy/react-scroll) の導入を紹介します。  
実装時間の目安は約 5 分と超お手軽です。

### 成果物

最終的にできあがる成果物はこちらです。  
ヘッダーにある `コンセプト`、`採用試験` や `ブログ` をクリックすると該当箇所までスムーズにスクロールできています。

![scroll5](/img/pages/tech/install-react-scroll/scroll5.gif)

### バージョン情報

- Node.js：15.11.0
- React：17.0.2
- Next.js：10.2.2
- react-scroll：1.8.2

### react-scroll を選んだ理由

『React scroll』で検索するとトップにヒットし、現在 GitHub のスター数が 3.4k となっているため、多くの人が利用しているメジャーなパッケージだと判断したためです。  
また、実際に導入した感想として、最低限必要な機能をしっかりと押さえつつ、導入が非常に簡単だと思いました。

ただ、GitHub のドキュメントだけをパッと見るとちょっとめんどくさそうに感じるため、こちらで `react-scroll` の導入を手軽に行いたい方向けにまとめることにしました。

## 導入手順

### react-scroll のインストール

`npm` もしくは `yarn` でインストールします。

```bash
# npm の方
npm install --save-dev react-scroll

# yarn の方
yarn add --dev react-scroll
```

簡単ですがこれで準備は完了です。  
今回は `devDependencies` にインストールするようにオプションの `--save-dev` もしくは `--dev` を付けていますが、この辺りは適宜環境に合わせてください（動かなかった場合にオプションなしでインストール）。

### react-scroll の初期設定

まずはスクロールを行いたい要素に `id` を付けます。

```html
<section id="concept">...</section>
```

そこに `コンセプト` というボタンを押してスクロールをしたい場合には以下のように設定します。

```tsx
// src/component/PageHeader.tsx

import { Link as Scroll } from 'react-scroll';

export default function PageHeader(): JSX.Element {
  return (
    <div>
      ...
      <nav>
        <Scroll to="concept">コンセプト</Scroll>
      </nav>
      ...
    </div>
  );
}
```

こちらが正しい実行結果です。

![scroll01](/img/pages/tech/install-react-scroll/scroll1.gif)

`Scroll` コンポーネントの `to` で指定した `id` までジャンプできれば正しく動作しています。

> ここで、`react-scroll` の `Link` コンポーネントを `Scroll` と名前を変えて読み込んでいる理由は、`next/link` の `Link` と混在するためです。  
> 基本的には `next/link` の `Link` コンポーネントを利用すると思いますので、ここは名前を変えておく方が無難でしょう。

### スムーズなスクロールへ

さらに今回の目的であるスムーズにスクロールするためには以下のように `smooth` を設定します。

```tsx
// src/component/PageHeader.tsx

import { Link as Scroll } from 'react-scroll';

export default function PageHeader(): JSX.Element {
  return (
    <div>
      ...
      <nav>
        <Scroll to="concept" smooth={true}>
          コンセプト
        </Scroll>
      </nav>
      ...
    </div>
  );
}
```

こちらが正しい実行結果です。

![scroll02](/img/pages/tech/install-react-scroll/scroll2.gif)

### スクロールにかける時間を調整

スクロールの時間がすこしゆっくりだと感じたかもしれません。  
ここは `duration` でミリ秒単位の調整が可能です。

```tsx
// src/component/PageHeader.tsx

import { Link as Scroll } from 'react-scroll';

export default function PageHeader(): JSX.Element {
  return (
    <div>
      ...
      <nav>
        <Scroll to="concept" smooth={true} duration={600}>
          コンセプト
        </Scroll>
      </nav>
      ...
    </div>
  );
}
```

こちらが正しい実行結果です。

![scroll03](/img/pages/tech/install-react-scroll/scroll3.gif)

### スクロール位置の調整

指定した `id` にギリギリのところよりも上に少し余白を持たせて止めたいという場合もあります。  
この場合には `offset` で調整可能です。  
上側に `50px` の余白を持たせたい場合は以下のようになります。

```tsx
// src/component/PageHeader.tsx

import { Link as Scroll } from 'react-scroll';

export default function PageHeader(): JSX.Element {
  return (
    <div>
      ...
      <nav>
        <Scroll to="concept" smooth={true} duration={600} offset={-50}>
          コンセプト
        </Scroll>
      </nav>
      ...
    </div>
  );
}
```

こちらが正しい実行結果です。

![scroll04](/img/pages/tech/install-react-scroll/scroll4.gif)

### ホバー時の装飾を調整

`コンセプト` というボタンの装飾がされていなかったため、最後にこの点を調整しておきましょう。  
通常の CSS で調整も可能ですし、Tailwind CSS での調整も可能です。  
fwywd のチームでは Tailwind CSS（JIT モード）を利用しているため、以下のように `className` で調整を行いました。

```tsx
// src/component/PageHeader.tsx

import { Link as Scroll } from 'react-scroll';

export default function PageHeader(): JSX.Element {
  return (
    <div>
      ...
      <nav>
        <Scroll
          to="concept"
          smooth={true}
          duration={600}
          offset={-50}
          className="font-medium text-[#008c8d] hover:opacity-50 hover:cursor-pointer"
        >
          コンセプト
        </Scroll>
      </nav>
      ...
    </div>
  );
}
```

![scroll05](/img/pages/tech/install-react-scroll/scroll5.gif)

これで今回の成果物に到達することができました。

## おわりに

### react-scroll の導入はたったの５分

`react-scroll` の機能は今回紹介した `smooth`, `duration`, `offset` 以外にもあります。  
こちらは [**react-scroll - GitHub**](https://github.com/fisshy/react-scroll) を参照してみてください。

もちろん自前でも実装することが可能なスクロール機能ですが、`react-scroll` を使うことでとても手軽に導入できるため、ぜひみなさんも使ってみてください。

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


React 向けにスムーズなスクロールを簡単に実装することができる react-scroll の導入を紹介します。実装時間の目安は約５分と超お手軽です。

Next.js に next-sitemap を導入して超手軽にサイトマップ sitemap.xml を生成しよう


## はじめに

どーも、入田 / ぐるたか [@guru_taka](https://twitter.com/guru_taka) です！  
本記事では **Next.js (TypeScript) を環境構築し、ESLint（読み方：イーエスリント）と Prettier（読み方：プリティア）を導入する方法**を紹介します。**Next.js のバージョン 11 に対応**しており、デフォルトで搭載されている ESLint の設定ファイルをベースとしています。  
ESLint と Prettier を駆使することで、**コードが綺麗**になるため、導入することを強くオススメしたいです。本記事では、VS Code 上で、ESLint で構文解析しながら、ファイル保存時に ESLint + Prettier によるコード整形する方法をハンズオン形式でまとめています。

▼ 成果物
![prettier-format.gif](/img/pages/tech/next-eslint-prettier/prettier-format.gif)
![next-eslint-import.gif](/img/pages/tech/next-eslint-prettier/next-eslint-import.gif)

ESLint と Prettier を含む Next.js (TypeScript) の環境構築の参考になれば幸いです！

### バージョン情報

- node：15.11.0
- eslint: 7.30.0
- eslint-config-next: 11.0.1
- prettier: 2.3.2
- eslint-config-prettier: 8.3.0
- next: 11.0.1
- typescript：4.3.5
- react: 17.0.2
- react-dom: 17.0.2

## ESLint とは？

[ESLint](https://eslint.org/) とは、**JavaScript のコードが正しいかどうか、検証するためのツール**です。コードの問題を発見したり、記述方法を統一できるようになり、**コードの品質を保つことができます**。

## Prettier とは？

**[Prettier](https://prettier.io/) とは、コードを綺麗に整えるフォーマッターです**。  
ESLint もコードの整形はできますが、**カバーしきれない部分を Prettier は補ってくれます**。そのため、基本的には ESLint と Prettier を併用することが多いです。

## ESLint と Preitter を Next.js (TypeScript) に導入する方法

1. Next.js (TypeScript) の新規プロジェクトを作成
2. Prettier のセットアップ
3. ファイル保存で自動フォーマットする VS Code の設定

### 1. Next.js (TypeScript) の新規プロジェクトを作成

まず、Next.js (TypeScript) の新規プロジェクトを以下コマンドで作成しましょう。

```bash
# npm の場合
npx create-next-app next-ts-eslint-prettier --typescript

# yarn の場合
yarn create next-app next-ts-eslint-prettier --typescript
```

ディレクトリ構造は以下の通りです。

```txt
├── .eslintrc
├── .gitignore
├── README.md
├── next-env.d.ts
├── next.config.js
├── node_modules
├── package.json
├── pages
├── public
├── styles
├── tsconfig.json
└── yarn.lock
```

**Next.js では、バージョン 11 から、ESLint がデフォルトで搭載**されています。ESLint に関連するインストール済みのパッケージは以下 2 つです。

- eslint：構文解析のエンジン
- eslint-config-next：Next.js 専用の ESLint のルール

```json
// package.json
{
  ...
  "devDependencies": {
    "eslint": "7.30.0",
    "eslint-config-next": "11.0.1",
  }
  ...
}
```

Next.js の新規プロジェクト作成時に生成された `.eslintrc` は ESLint の設定ファイルを意味しており、**デフォルトで `eslint-config-next` の設定が適用**されています（ルールの詳細は後述）

```json
// .eslintrc
{
  "extends": ["next", "next/core-web-vitals"]
}
```

現在 `lint` コマンドを実行することで、構文解析ができますが、**VS Code 上でリアルタイムに構文解析することもできます**。方法は至ってシンプルで、VS Code で ESLint の拡張機能をインストールするだけです！（下図参照）

![vscode_eslint](/img/pages/tech/next-eslint-prettier/vscode_eslint.png)

実際に、構文解析されるかどうか、確認してみましょう。ルートディレクトリに `sample/index.tsx` というファイルを作成してください。コードは以下の通りです。

```tsx
// sample/index.tsx
export default function index() {
  return (
    <div>
      <img src="/vercel.svg" alt="Vercel Logo" width={72} height={16} />
      <a href="/">test</a>
    </div>
  );
}
```

下図のように、ESLint によるエラーが表示されれば成功です！

![next-eslint-prettier-1](/img/pages/tech/next-eslint-prettier/next-eslint-prettier-1.png)

エラー文の解説は、以下のようになります。

> ① Do not use img. Use Image from 'next/image' instead.  
> ② Do not use the HTML a tag to navigate to /. Use Link from 'next/link' instead.

`img` タグは `next/image` の `Image`、`a` タグは `next/link` の `Link` を使用するようなエラーとなっています。  
このように **VS Code 上でリアルタイムに ESLint で構文解析できると、コードの保守性が高まります**。

しかし、ファイル数が多いとき、**全てのファイルを VS Code で確認するのは大変**です。そのため、対象ファイルを一括で ESLint による構文解析したい場合は、`lint` コマンドを使用します。

```bash
# npm の場合
npm run lint

# yarn の場合
yarn lint
```

上記のコマンドを実行してみると、VS Code 上ではエラーが出力されているにも関わらず、**以下のように問題ない趣の結果が表示されます**。

```bash
# 実行結果
$ next lint
info  - Using webpack 5. Reason: Enabled by default https://nextjs.org/docs/messages/webpack5
✔ No ESLint warnings or errors
✨  Done in 1.50s.
```

![next-eslint-prettier-2](/img/pages/tech/next-eslint-prettier/next-eslint-prettier-2.png)

実は、Next.js にデフォルトで搭載された ESLint では、**lint コマンドの対象ディレクトリが 以下 3 つに限定されています**。  
参考：[Basic Features: ESLint | Next.js](https://nextjs.org/docs/basic-features/eslint#linting-custom-directories)

- `pages`
- `lib`
- `components`

対処法は複数ありますが、**fwywd チームでは `src` ディレクトリに `pages` 含むソースコードを管理**。`lint` コマンドのオプションで `--dir src` とすることで、`src` ディレクトリ配下にある指定ファイルが ESLint の対象となるようにしています。  
実際に `src` ディレクトリを作成し、以下 3 つのディレクトリを管理しましょう。

- `pages`
- `sample`
- `styles`

```txt
src
├── pages
│   ├── _app.tsx
│   ├── api
│   └── index.tsx
├── sample
│   └── index.tsx
└── styles
    ├── Home.module.css
    └── globals.css
```

次に、`package.json` の `lint` コマンドに対し、`--dir src` を記述してください。

```json
// package.json
  "scripts": {
    ...
    "lint": "next lint --dir src"
    ...
  },
```

`lint` コマンドを実行し、VS Code 上のエラーと同様の結果が表示されれば成功です！

![next-eslint-prettier-3](/img/pages/tech/next-eslint-prettier/next-eslint-prettier-3.png)

本題とは反れますが、**`tsconfig.json` で `src` ディレクトリを `baseURL` として設定することもオススメ**です。
参考：[【Next.js】特定のディレクトリを基準にし、絶対パスでモジュールをインポートする方法 | fwywd（フュード）](https://fwywd.com/tech/next-base-url)

また、ESLint によるコード整形するコマンドは、以下のようになります。

```json
// package.json
  "scripts": {
    ...
    "lint": "next lint --dir src",
    // 追記
    // src --ext .js,jsx,.ts,.ts: src ディレクトリ内の js, jsx, ts, tsx ファイルを対象
    // --fix: コード整形
    "lint:fix": "eslint src --ext .js,jsx,.ts,.tsx --fix"
    ...
  },
```

実際に、ESLint でコード整形できるかどうか、動作確認します。`.eslintrc` のように、設定ファイルを記述してみましょう。

```json
// .eslintrc
{
  "extends": ["next", "next/core-web-vitals"],
  // 追記
  "rules": {
    // セミコロンない場合、エラー出力
    "semi": ["error", "always"]
  }
}
```

上記のように **ESLint で独自のルールを記述する場合は、`rules` に記述します**。詳細は [ESLint の公式ページ](https://eslint.org/docs/rules/)をご覧ください。  
すると、セミコロンがないファイル（例：`pages/index.tsx`）に対し、下図のようにエラーが出力されるようになります。

![next-eslint-prettier-5](/img/pages/tech/next-eslint-prettier/next-eslint-prettier-5.png)

以下のコマンドを実行した後、自動でセミコロンが追加されれば成功です！

```bash
# npm の場合
npm run lint:fix

# yarn の場合
yarn lint:fix
```

![eslint-fix.gif](/img/pages/tech/next-eslint-prettier/eslint-fix.gif)

このように **ESLint のルールに従って、一括でコード整形できます（便利！）**

今回 ESLint でルールを記述しましたが、以降 Prettier をメインにコード整形のルールを記述するため、先程のルールは削除して構いません。

```json
// .eslintrc
{
  "extends": ["next", "next/core-web-vitals"]
  // 削除
  // "rules": {
  //   // セミコロンない場合、エラー出力
  //   "semi": ["error", "always"]
  // }
}
```

### 2. Prettier のセットアップ

次は Prettier のセットアップを行います。まず、Prettier の拡張機能をインストールしましょう。

![next-eslint-prettier-4](/img/pages/tech/next-eslint-prettier/next-eslint-prettier-4.png)

Prettier におけるフォーマットの設定は VS Code 上でも設定できますが、**チーム開発する場合、コード整形のルールにバラツキがあると、大変です**。  
そのため、**コードベースで Prettier におけるコード整形のルールを記述**します。主な方法は、以下 2 つです。

- `.prettierrc` ファイルを作成し、ルールを記述
- `package.json` にルールを記述

fwywd チームでは、**省ファイルも意識して、`package.json` に記述**しており、以下のようなルールを設定しています。

```json
// package.json
  "prettier": {
    "trailingComma": "all",// 末尾のカンマあり
    "tabWidth": 2,// tab の長さは半角スペース 2 つ
    "semi": true,// セミコロンあり
    "singleQuote": true,// シングルクォーテーションに統一
    "jsxSingleQuote": true,//jsx もシングルクォーテーションに統一
    "printWidth": 100 // １ 行の最大文字数 100
  },
```

ルールの詳細は公式の [Options · Prettier](https://prettier.io/docs/en/options.html) をご確認ください。上記の設定を記述することで、**VS Code 上の Prettier のルールではなく、上記のルールが適用されます**。

続いて、以下 2 つのパッケージをインストールしましょう。

- prettier: 各ファイルをコマンドで、フォーマットできるようにするため
- eslint-config-prettier: ESLint と Prettier のコード整形がバッティングしないようするため

```bash
# npm の場合
npm install -D prettier eslint-config-prettier

# yarn の場合
yarn add -D prettier eslint-config-prettier
```

`.eslintrc` に対し、以下のように記述することで、**ESLint と Prettier のコード整形がバッティングしないようになります**。（公式推奨）

```json
// .eslintrc
{
  // 追記："prettier"
  "extends": ["next", "next/core-web-vitals", "prettier"]
}
```

最後に、Prettier でフォーマットするコマンドを `package.json` に記述しましょう。

```json
// package.json
  "scripts": {
    ...
    "lint": "next lint --dir src",
    "lint:fix": "eslint src --ext .js,jsx,.ts,.tsx --fix",
    // 追記
    // --write: フォーマット整形
    // --ignore-path .gitignore: .gitignore に含まれているファイルはコード整形の対象外
    // 対象ファイルの拡張子を指定
    "format": "prettier --write --ignore-path .gitignore './**/*.{js,jsx,ts,tsx,json,css}'"
    ...
  },
```

実際にルールに従って、フォーマットされるかどうか、確認してみましょう。`src/sample/index.tsx` ファイルを以下のコードに差し替えてください。

```json
// src/sample/index.tsx

export default function index() {
  return (
    <div className="sample">
      test
    </div>
  )
}
```

`format` コマンドを実行後、セミコロンが付き、ダブルクオーテーション -> シングルクォーテーションとなっていれば成功です！

```bash
# npm の場合
npm run format

# yarn の場合
yarn format
```

▼ 実行結果
![prettier-format.gif](/img/pages/tech/next-eslint-prettier/prettier-format.gif)

### 3. VS Code でファイル保存時に

ESLint と Prettier によるコード整形はできましたが、開発中に**毎回コマンドを実行するのは、手間がかかります**。そこで、**ファイル保存時にコードの自動整形ができるように、VS Code の設定を行います**。設定ファイル (`.vscode/settings.json`) は以下の通りです。

```json
// .vscode/settings.json
{
  // デフォルトのフォーマッタを prettier に設定
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  // ファイル保存時、prettier による自動フォーマット
  "editor.formatOnSave": true,
  // ファイル保存時、ESLint による自動フォーマット
  "editor.codeActionsOnSave": {
    "source.fixAll": true
  }
}
```

ファイル保存時、自動でコードが整形されていれば成功です！
![auto-save-format.gif](/img/pages/tech/next-eslint-prettier/auto-save-format.gif)

以上で、Next.js における ESLint と Prettier の基本的な設定は完了となります。

## eslint-config-next の設定ファイル

`eslint-config-next` の設定ファイルの主要な中身は以下の通りです。  
引用：[next.js/index.js at canary · vercel/next.js | GitHub](https://github.com/vercel/next.js/blob/canary/packages/eslint-config-next/index.js)

```jsx
/*
 * @rushstack/eslint-patch is used to include plugins as dev
 * dependencies instead of imposing them as peer dependencies
 *
 * https://www.npmjs.com/package/@rushstack/eslint-patch
 */
require('@rushstack/eslint-patch/modern-module-resolution');

module.exports = {
  extends: [
    'plugin:react/recommended',
    'plugin:react-hooks/recommended',
    'plugin:@next/next/recommended',
  ],
  plugins: ['import', 'react', 'jsx-a11y'],
  rules: {
    'import/no-anonymous-default-export': 'warn',
    'react/react-in-jsx-scope': 'off',
    'react/prop-types': 'off',
    'jsx-a11y/alt-text': [
      'warn',
      {
        elements: ['img'],
        img: ['Image'],
      },
    ],
  },
  ...
};
```

以下の主要な ESLint のプラグインが搭載されています。

- [eslint-plugin-react](https://github.com/yannickcr/eslint-plugin-react): React に特化した ESLint のプラグイン
- [eslint-plugin-react-hooks](https://github.com/facebook/react/tree/master/packages/eslint-plugin-react-hooks): React Hooks に特化した ESLint のプラグイン
- [eslint-plugin-jsx-a11y](https://github.com/jsx-eslint/eslint-plugin-jsx-a11y): React Hooks に特化した ESLint のプラグイン
- [eslint-plugin-import](https://github.com/benmosher/eslint-plugin-import): モジュールのインポートに関連する ESLint のプラグイン
- etc...

上記のプラグインに加え、**Next.js 独自の ESLint のプラグイン `eslint-plugin-next` が搭載**されています。ルールの詳細は[公式サイト](https://nextjs.org/docs/basic-features/eslint#eslint-plugin)をご覧ください。  
Next.js において、**デフォルトの ESLint の設定ファイルは非常に完成度が高い**です。基本的には `eslint-config-next` をベースに、ESLint のルールをカスタマイズすることをオススメします！

## モジュールをインポートする順番を、アルファベット順になるよう設定

fwywd では、`eslint-plugin-import` が推奨するルールも反映。また、**モジュールにおけるインポートの順番を、アルファベットの順番**にしています。  
参考：[eslint-plugin-import/order.md at master · benmosher/eslint-plugin-import](https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/order.md)

記述するルールは以下の通りです。

```json
// .eslintrc
{
  "extends": [
    "next",
    "next/core-web-vitals",
    "prettier",
    // 追記
    "plugin:import/recommended",
    "plugin:import/warnings"
  ],
  "rules": {
    // import の順番をルール化
    // 参考：https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/order.md
    "import/order": [
      "error",
      {
        "alphabetize": {
          "order": "asc"
        }
      }
    ]
  }
}
```

このように、モジュールをインポートする順番がファイル保存時に、アルファベット順になれば成功です。もし、うまくいかない場合は、VS Code を再起動して確かめてみてください！
![next-eslint-import.gif](/img/pages/tech/next-eslint-prettier/next-eslint-import.gif)

## 最後に

以上になります。Next.js ver11 となってから、**デフォルトで完成度の高い ESLint の設定が施されており、より環境構築がしやすくなった**と感じます。  
これから Next.js (TypeScript) を環境構築しようとしている方、ESLint や Prettier の設定で悩まれている方の参考になれば幸いです！  
スタイルファイルに対しても構文解析したい場合は、[Next.js に Stylelint を導入する方法](https://fwywd.com/tech/next-stylelint) という記事にまとめていますので、是非チェックしてみてください！
ここまでご覧いただき、ありがとうございました！

---

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


Next.js (TypeScript) の環境構築から、ESLint と Prettier を導入 -> コードを綺麗に保つ設定方法をハンズオン形式でまとめました！Next.js のバージョン 11 に対応しており、デフォルトで搭載されている ESLint の設定ファイルをベースとしています。Next.js (TypeScript) の環境構築をしようとしている方は必見です！

Next.js に Stylelint を導入する方法。VS Code の設定方法も紹介！

RSS フィードでエンコードエラーが発生した時の対処方法

Next.js (TypeScript) に ESLint と Prettier を導入し、コードを綺麗に保とう


## はじめに

みなさんは [**STUDIO**](https://studio.design/ja) というデザインツールをご存知でしょうか。  
**ノーコードツール**というと流行りに乗っている感じがありますが、Web サイトの実装をプログラムを書くことなく公開まで行うことができます。

そんな記事を書いている私はプログラミングに触れて早 15 年。  
ノーコードツールに頼ることなく Web サイトの実装ならサクッと行える私が、この度、[**STUDIO**](https://studio.design/ja) で Web サイトを実装してみました。  
ノーコードってプログラムを書けない人のためだと思われがちですが、実はエンジニアの方が恩恵が大きいのでは...? と思うぐらい慣れると快適でした。

そんなプログラミング大好き人間から見たノーコードで実装できる [**STUDIO**](https://studio.design/ja) を採用した背景やメリットを紹介します。  
また単に実装できるできないの話だけでなく、「ビジネスで使える使えない」といったビジネス視点での [**STUDIO**](https://studio.design/ja) のメリット・デメリットまでお伝えしていきます！

![STUDIO](https://storage.googleapis.com/production-os-assets/assets/24f6613f-c35d-4c53-8f16-eefc0c5c09ac)  
出典：[**STUDIO**](https://studio.design/ja)

## 要点

急ぎでメリット・デメリットを知りたいよ！という方向けにまずは結論から。  
理由をそれぞれ実際に使った視点で書いていくので、気になった方はゆっくり記事も読んでみてくださいね。

### エンジニア視点

- **メリット**
  - コードを書くより遥かに実装が早い
  - サーバーを持たなくても良い
  - 独自のフォームも対応
- **デメリット**
  - パフォーマンスが悪い
  - ロジックが書けない
  - 用意されたサービスとの連携以外使えない

### ビジネス視点

- **メリット**
  - PDCA のサイクルが圧倒的に早く回せる
- **デメリット**
  - Google 広告との連携が悪い
  - A/B テストなど最適化を行いにくい

## エンジニア視点でのメリット

### コードを書くより遥かに実装が早い

[**STUDIO**](https://studio.design/ja) を使う最も大きな理由がここだと思います。

別にコードも書けるんですよ。  
でも、成果物が同じならなるべく楽したいじゃないですか。

コードを書くことも好きですよ。  
でも、早く公開できると嬉しいじゃないですか。

コードを書くスピードに関しては決して遅い方ではない私ですが、それでも実際に実装から公開までのスピードを比較すると **10 倍くらいは早かった**のではないかと思います。  
CSS での装飾とかコードを書きながら表示を確認するよりも、マウスで動かしながら色とかもポチポチ変えての方が遥かに楽でした。

あと地味ですが、**レスポンシブ対応**が楽です。  
コード書いているとき、レスポンシブ対応って本当に面倒で億劫になりますよね...。

おすすめの用途としては、**Landing Page (LP)** や**コーポレートサイト**などのデザイン性が高くて、コンポーネントとして後でそんなに使いまわしをしないものです。  
コードを書いていると**どうやってコンポーネントを分けよう**（ウキウキッ）という無駄なエンジニア魂が出てしまい、いろいろ考えて遅くなってしまうのです。  
たぶん、エンジニアのみなさんであれば、**ヘドバン**しながらうなずいてもらえると思います（首は大切に）。

あとノーコードなのでちょっとした編集を**自分以外のコードが書けない人に任せられる**のも大きいです。  
ただし、マージンとかパディングとか HTML と CSS の基本的な用語を知らないとなんのこと？となるかも知れないです。  
使ってみて、ノーコードとは言いつつも**コード書ける人の方が絶対に有利だなぁ**と思いました。

実際にデザイン性が高いものって大丈夫なの？と気になった方。  
この [**fwywd の募集用 LP**](https://apply.fwywd.com) が [**STUDIO**](https://studio.design/ja) で実装したものなので見てみてください。  
デザイナーさんに Figma でデザインしていただき、それをベースに [**STUDIO**](https://studio.design/ja) で実装していきました。

▶ 実装例はこちら：[**fwywd の募集用 LP**](https://apply.fwywd.com)

[![fwywd の募集用 LP](/img/ogp.png)](https://apply.fwywd.com)

### サーバーを持たなくても良い

今どきは当たり前になっているかも知れませんが、こういったツールは **Wordpress** と比較されると思うので、ここが大きく違うところです。  
サーバー等のインフラ面はすべて [**STUDIO**](https://studio.design/ja) におまかせ。

**Web サイトをちょっと公開したいだけ**なのに、サーバーなんていうものが出てきて頭がこんがらがってしまう...。
こんな問題はありません。

でも、本当は**インフラの設定がバッチリできるエンジニアの人でもこれって結構嬉しい**のです。  
別にインフラの設定がしたくてエンジニアをしているわけでもないので、楽できるなら楽したいじゃないですか。  
あとサーバーって**攻撃されたときのダメージも大きい**ので、持たなくて良いなら持ちたくないじゃないですか。

最初は無料で始めることができますが、基本的には**独自ドメイン**を付けたいと思うので有料で利用することになります。  
月 980 円から始めることができ、これならサーバーを持つことと料金は変わらないので全然 OK です。

最も比較すべきはサーバー代ではなく、エンジニアが実装するためにかかる人件費の方ですよね。  
この時間が圧倒的に短くなるということは、**かなりのコスト削減**になります。  
喜んで課金させていただきます！

### 独自のフォームも対応

これわざわざ別で書くほどのことか？と思われるかも知れませんが、ビジネス的に**フォームって結構大事なポイント**なんです。  
最近だと Google Form などへのリンクを貼って遷移させることも多いと思うのですが、ページを遷移すると**コンバージョン率が下がる**ため、なるべくページの中にフォームを持っておきたい。  
これが [**STUDIO**](https://studio.design/ja) だと基本的なフォームも用意されているため簡単です。

あとは**フォームに登録された内容を他のツールと連携できるか？** といった業務効率化の面も気になりますよね。  
この点も大丈夫！

[**STUDIO**](https://studio.design/ja) のフォームに登録された内容は **Google Spread Sheet (GSS)** に自動で転記することができます。  
**GSS** に転記できれば、あとは [**Zapier**](https://zapier.com/) などのツールで変更を検知して、他のツールと連携したオペレーションの自動化が実現できます。最高！

一点だけ注意として、CRM ツールである [**Hubspot**](https://www.hubspot.jp/) のフォームを埋め込むこともできるのですが、こちらはあまりおすすめしません。  
フォームの表示が遅延してしまい、ユーザー体験として良いものではありませんでした。  
コンバージョン率を少しでも高めたいのであれば標準のフォームを利用した方が良いと思います。

## エンジニア視点でのデメリット

### パフォーマンスが悪い

[**STUDIO**](https://studio.design/ja) は残念ながら、**表示に関するパフォーマンスが決して良いとは言えません**。  
もちろん画像を最適化したりといった工夫によりパフォーマンスを多少上げることができますが、根本的には **Server Side Rendering (SSR)** で実装されていることです。  
**React/Next.js** ではページごとで **Static Generation (SG)** や **Incremental Static Regeneration (ISR)** が適用できるのですが、[**STUDIO**](https://studio.design/ja) は **Vue.js/Nuxt.js** を使っているため、この点が弱くなってしまいます。  
このあたりは過去にまとめた記事があるので、気になった方は読んでみてください。  
▶ 参考記事：[**Vue.js & Nuxt.js から React & Next.js へ移行した理由**](/tech/nuxt-to-next)

実際に私が実装したページを [**Page Speed Insights**](https://pagespeed.web.dev/) でパフォーマンスを計測すると以下の様になりました。

![01](/img/pages/tech/why-adopt-studio/01.png)

![02](/img/pages/tech/why-adopt-studio/02.png)

静的な Web サイトであれば、スマートフォン向けでも **90 点以上は欲しいところ...**。  
**読み込み速度が１秒遅いとコンバージョン率が 7% 下がる**と言われており、コンバージョン狙いの LP にはあまり向いているとは言えません。

私達も現在の LP の調整が終われば、やはりパフォーマンスアップが必要ですので、コードを書いて実装し直しを予定しています。  
欲を言えばキリがありませんが、**まずは素早く公開して検証することが最優先**であったため、[**STUDIO**](https://studio.design/ja) で実装したことは良い判断だったと思います。

### ロジックが書けない

これは当たり前の話ですが、JavaScript などでのロジックを書くことはできません。  
そのため、API で連携して...なんてことはできません。

ただし、[**STUDIO**](https://studio.design/ja) では **Contents Management System (CMS)** の機能も利用でき、ブログなどを作ることもできます。  
私は今回使っていないのですが、これは結構嬉しい人が多いと思います。

### 用意されたサービスとの連携以外使えない

ロジックが書けないことに類似しますが、用意されたサービスとの連携以外使えません。  
Google Analytics や Google Tag Manager などは用意されている安心感はあります。

この記事を執筆時点で用意されている連携は以下のとおりです。

- **マーケティング**
  - Google Analytics (GA4 対応済)
  - Google Tag Manager
  - Google Search Console
  - Google reCAPTCHA v3
  - Facebook Pixel
  - HubSpot Tracking
- **カスタマーサクセス**
  - Intercom
  - Channel

これを多いと見るか、少ないと見るかですが、個人的には**ビジネスで本格的に利用していくならかなり少ない**と感じます。  
独自 HTML や `<script>` タグを埋め込めればもう少し幅が広がるのですが、これができないため歯がゆい思いをするかも知れません。  
特に Google 広告のコンバージョン計測に必要な `gtag.js` 系の埋め込みができず、LP には致命的な気がします。

そういった視点では **LP の初期検証用**や、**コーポレートサイトのようなコンバージョンに対するシビアさが求められない用途**に向いているのではないでしょうか。

## ビジネス視点のメリット

### PDCA のサイクルが圧倒的に早く回せる

これはエンジニア視点ですでに紹介した**実装が楽であること**が理由です。  
ちょっと変更したいというときもコードを書いていると、エディターを開いて該当のコンポーネントを探して、GitHub へ Pull Request を送って、レビューしてもらって...と長い！！！  
初期ってこんなペースだと素早く PDCA 回せないので、このプロセスが減るのは**ビジネスにとって圧倒的なメリット**と言えます。

## ビジネス視点のデメリット

### Google 広告との連携が悪い

これ**めちゃくちゃ痛手**です。  
これが理由で周りも [**STUDIO**](https://studio.design/ja) を採用しないケースがあると聞きました。  
一応チャットで担当者に確認ができるので聞いてみました。

> Google Tag Manager の設定を済ませています。  
> 一方、Google 広告のコンバージョンを設定しようとすると、グローバルサイトタグが検出されないとの理由でコンバージョンを検出することができません。  
> script タグを自前で埋め込むことができれば問題ないのですが、STUDIO ではこれができないため、Google 広告の最適化が行えず困っております。  
> どのように対処すると良いか、ご教示いただけますと幸いです。

これに対して以下の回答がありました。

> お問い合わせありがとうございます。  
> Google タグマネージャーや Google 広告につきましては外部サービスになりますので、こちらから正確な情報をご案内をすることはできかねます。  
> STUDIO では基本的にサイト内に特定コードを埋め込むことは出来かねますので、Google タグマネージャーにて可能かどうか確認頂ければと存じます。

じゃあ、今後の対応を待とうかと思ったのですが、知り合いが**同様の質問を 3 年前にすでにしており、同様の回答だった**ようでした。  
ということは、**近いうちに対応されない可能性が高い...**。とほほ。

[**Wix**](https://ja.wix.com/) などはこの点が問題ないそうなので、ノーコードで広告周りもしっかりカスタマイズしたい人はこの辺りも視野に入れて良いと思います。  
私は LP の初期検証が終われば、React/Next.js でパフォーマンス・チューニングも込みで実装する予定です。

### A/B テストなど最適化を行いにくい

LP では **Landing Page Optimization (LPO)** というコンバージョン率を高めるための最適化を行っていきます。  
その代表格が **A/B テスト** であり、**[Google Opimize](https://marketingplatform.google.com/intl/ja/about/optimize/)** が無料で使えて、まずはみんな通る道だと思います。

手軽に実装できるので、素早く PDCA が回せるので、ガンガン A/B テストしていこう！と思いきや...

**Google Optimize との連携が用意されていない...**!!

ということで、Google Analytics を見ながら経験的に試行錯誤しかできません。  
もちろん、複数ページ作成して広告側で出し分けるなどはできますが、その広告のコンバージョンがうまく計測できない無限ループ。

## まとめ

[**STUDIO**](https://studio.design/ja) は超手軽に Web サイトを実装できるのでおすすめです。  
ただし、広告との連携の問題や A/B テストが経験的にしかできない点を考慮すると、[**STUDIO**](https://studio.design/ja) でコンバージョンの最適化までしていくことには期待しない方が良いと思います。

**コーポレートサイトなどコンバージョンが主目的ではない Web サイト**や、**まずは公開までのスピード最優先の LP** には向いていると思います。

普段コードを書いている人であれば 1 日あれば操作に慣れると思うので、まずは使ってみることがおすすめです！  
何事にも一長一短があるので選択肢は１つでも多く増やしておきましょう！


みなさんは STUDIO というデザインツールをご存知でしょうか。ノーコードツールというと流行りに乗っている感じがありますが、Web サイトの実装をプログラムを書くことなく公開まで行うことができます。そんな記事を書いている私はプログラミングに触れて早 15 年。ノーコードツールに頼ることなく Web サイトの実装ならサクッと行える私が、この度、STUDIO で Web サイトを実装してみました。ノーコードってプログラムを書けない人のためだと思われがちですが、実はエンジニアの方が恩恵が大きいのでは...? と思うぐらい慣れると快適でした。そんなプログラミング大好き人間から見たノーコードで実装できる STUDIO を採用した背景やメリットを紹介します。また単に実装できるできないの話だけでなく、「ビジネスで使える使えない」といったビジネス視点での STUDIO のメリット・デメリットまでお伝えしていきます！

【画像で解説】Thanks ページを使った Google 広告のコンバージョントラッキング'


## はじめに

現在募集を開始している起業家育成コースの『[**fwywd（フュード）in 淡路**](/awaji)』は**受講料が無料**です。今回はこの『**受講料無料**』に込めた思い、そして、これが最終的に私の考える真の教育像に近づいていく話も含めて丁寧に背景を紹介させてください。

この受講料無料は、**単なる客寄せパンダ**としてではなく、これは**新たな教育ビジネスへの挑戦**です。

**教育に本気の革命を**。

**成果が出せる人材を輩出する教育の構造**を紐解いていくと、この**受講料無料**に帰着しました。

## 本気で変わるために必要な関係性

### 受講料が研修ビジネスの当たり前

今回の企画『[**fwywd（フュード）in 淡路**](/awaji)』は**１年間、経営と技術を学べる環境を提供する上に私が淡路島に一緒に移住してビジネスの構築に向けて一緒に伴走します**。受講料無料でないとビジネスが成立しないか？と言われるとそんなことはありません。弊社では過去に**有償で 50,000 名の方に AI・DX を含めた先端技術に関する研修を提供**しており、しっかりと報酬をいただいて仕事をしてきました。そのため、今回の企画も**相場的には数百万円の金額**をいただいて始めることも当初の計画にありました。

しかし、創業から５年目が経ち、多くの方の成長を見守る傍ら、**今のやり方が本当に正しいのだろうかと自問自答**することもありました。その背景として、受講生が講義中はとても満足して講義を受けていただいており、実際に満足度も高い一方で、その後の活躍を聞いてみると、**なかなか次の一手が踏み出せていないと悩まれている方が多かった**のです。

**受講料を支払って教えてもらう**ということは現代の学校の構造に慣れた私達にとって最も親和性の高いものです。塾も大学も、社会人になってからの研修も当然このビジネスの構造であったはずです。もちろん、弊社のビジネスも基本的には受講料をいただいてスタートします。最初の挫折を防ぎ、**自力で学んでいけるところまでの自走力を付ける**といった**学びのきっかけを与える**場合には、この受講料を最初にいただくビジネスモデルの方が、教える側、教わる側の双方にとって良いと思っています。

### 受講生との関係性の歪み

一方で、**起業家育成**のような**成果にコミットするタイプの教育**では少し構造が違います。極端な話、**たとえ受講生であっても成果が出ない場合には諦めていただくこと**を許容する必要があります。

また最終的に成果を出していただくためには、**手取り足取り教えても意味がない**のです。経験上、1 から 10 まで丁寧に教えた人よりも、1 教えると 10 まで自分でなるべく考えながら試行錯誤していく人の方が圧倒的に伸びが違います。つまり、手取り足取り教えるという教育は**易しい (easy)** だけであり、受講生の本当の成果を願うといった観点での**優しさ (kind)** ではないのだとわかりました。

しかし、残念ながらこういった成果に対してコミットが必要な教育の場合においても、受講料を支払っていただいた以上、「**お客様は神様だ**」という構造になってしまいます。サービスを受ける側と提供する側といった**上下関係のある構造**になってしまうことで、本当に言いたいことを言えなくなってしまいます。教えてほしいと望まれた以上、**本当は自力で調べるべきところでも教えざるを得なくなってしまう歪み**が生じてしまいます。

これからの時代は**きっかけを与える教育**も大切な一方で、先端技術の社会実装が進んできた昨今では、**成果にコミットするタイプの教育**も需要が増してきています（筋トレみたいですね）。

### 社員の成長がヒント

この本当に成果が出せる人材を輩出するための教育に着目し始めたのは私が組織を構築して社内の教育を始めたころからでした。キカガクでは現在 35 名の社員とともにビジネスを展開しています。

基本的な募集の入り口は講師採用のみに絞っており、全員が講義を担当できるようになった後、コンテンツ開発、セールス、マーケティング、プロダクト開発など、様々な部署に分かれていきます。そのため、バックグラウンドは文理様々ですが、**全員がプログラミングや数学などを学ぶ**ことによって、論理的思考力を鍛えてもらっています。

さて、では講師として登壇していただくための２ヶ月間の社内研修はどのように設計しているかというと、ある３日間のコースを登壇できるように**ひたすらインプットとアウトプットを繰り返すだけ**です。先輩講師の講義を見て学び、徹底的に真似しながら教える練習を行い、定着してきたところに自分の色を出していく。表面的に教える内容だけでなく、先輩に模擬授業を見てもらったときに、さらに深い質問があるため、より深いところを学んでいく。そんな**自律的な学びを中心とした研修**です。

正直なところ、**そこまで手塩にかけて育てるという感じではありません**。もちろん、モチベーションを上げていけるようにフォローしたり、迷っていそうであればヒントを出したりします。それでも、手取り足取り教えるということはありません。残念ながら２ヶ月間の研修期間で合格点に到達できない方もいらっしゃるので、みんな必死に学びます。

### 教育の前提条件が正しいか

そして、キカガクは**全員が未経験採用**であるにも関わらず、いまや大手企業の研修をたくさんいただき、**研修のコンペティションではほとんど勝っている**そうです。自分たちで言うのもなんですが、もちろん、研修での満足度は非常に高く、リピートも多くいただけるようになりました。そんな**本気で成果を出せる人材**を輩出できるようになってきた今、重要なことに気づいたのです。

それは**教育の前提条件**です。なぜ、ここまで成果を出せる人材を育てることができるのか。

その答えに**真っ向から向き合う勇気がなかった**だけかも知れません。

弊社だけでなく、**企業の社内研修では学校の学びよりも遥かに成長した**という声があります。なぜ、学校ではこの情報を教えてくれなかったのか。

### 利害の一致

その教育の前提の正体は**利害の一致**です。この関係性を築くことができないと、構造上、人の成長に対して適切なアプローチを取ることができません。

もう少し噛み砕いて説明すると、弊社の場合、**研修期間に不合格になってしまうと人件費も含め多くの機会損失が生じます**。つまり、育成対象がうまく成長しないと**弊社も一緒に損をする**という関係です。一方で、うまく成長することができると一緒にビジネス拡大を進めていけるため、**弊社が得をする**わけです。この関係性こそが**利害の一致**です。

**多くの成果が出せる人材を輩出する教育の構造**を紐解いていくと、結局、この**利害の一致**に帰着しています。

## 起業家育成の枠組み

### 受講料無料の理由

ここまでお読みいただけたのであれば、お気づきの方も多いと思います。今回の起業家育成では**成果を出せる人材**を輩出することが重要であり、そのために必要な関係が**利害の一致**となることです。したがって、受講料をいただいてサービスの提供側と受ける側になってしまった時点で、**力がうまく伝わらなくなってしまいます**。

だからこそ、今回の企画では**受講料無料**としました。だからこそ、受講生には『**私はみなさんの仲間です**』と伝えています。受講生のお世話係でもないし、ご機嫌を取るための教育係でもありません。**一緒に伴走する仲間**であり、苦楽をともにする関係です。だからこそ、手取り足取り教えることなく、**成果が出るためのマネージメント**に近しい形の教育を提供します。

『**魚を与えるのではなく、魚の釣り方を教える**』

これを関係性から正しく構築するために**受講料無料**という**スタートライン**に立つことが最も重要だったのです。

### 入口や出口でのマネタイズの課題

成果を出すために**受講料無料**による『**利害が一致した仲間**』という関係が必要ですが、それでは**ビジネスが当然成立しません**。つまり、**戦略**が必要となります。

私は受講料をいただくビジネスモデルを**入口型**と呼んでいます。その一方で、転職支援などでマネタイズを行うモデルが**出口型**と言えます。一番わかり易いところでは、起業家としてなかなかうまくいかなかった際に、転職を薦めて人材紹介で報酬をいただくこともできます。もちろん、これも選択肢には入っていますが、ただこれをメインの収益源にしようとすると、起業家を育てるというよりも**転職支援のためのサービス**に構造的になってしまいます。起業家を目指して本気で挑戦する中で企業の新規事業担当としての選択を取ることは良いと思いますが、最初から市場価値を高める転職のために来られても本気度が低く、この企画の意図に沿いません。

また、起業家側からの希望があれば**投資家**として関わっていくことも本企画では想定しています。ただし、**社会課題の解決**を目指すためには短期利益の追求では歪みが生まれてしまうため、なるべく**自己資本で自由度が高く取り組めることが望ましい場合**も多いと思います。そのため、VC が実施するアクセラレータープログラムやインキュベート系のプログラムのように**投資を受けてからスタート**としてしまうと構造上の欠陥がゆくゆくは浮き彫りになってしまうのです。

私達は**最短 Exit 主義のユニコーン企業**だけではなく、**社会貢献と長期利益を目指すゼブラ企業**の挑戦も支援していくために、**投資家としては関わらない**という選択肢も用意したかったのです。

### 過程でのマネタイズという選択

そこで、[**fwywd（フュード）**](/)が注目するのは『**過程**』でのマネタイズです。最近では**プロセスエコノミー**という書籍も発売されるなど、私が長年注目してきた領域でした。たとえば、アイドルグループの NiziU がデビューまでの過程をビジネスにしていたような話が代表的です。つまり、**成長の過程**をビジネスに変換するのです。

今回の起業家育成の企画では、参加者に**情報発信**を行っていただきます。まさに、みなさんが今読んでいただいているこの記事のように、自身の考えやアイディアを発信していただきます。

![情報発信の連鎖](/img/pages/blog/challenge-of-a-new-education-business/01.png)

情報発信を行っていただくことは、もちろん、**起業を志す挑戦者にとって必要な道筋**だからです。

最近ではプロダクトを作ってから検証するといった失敗例をよく聞きますが、プロダクトを作るよりも、市場に対して最小のコストで仮説検証を行えるのが**情報発信**です。そこで反響がなければ、プロダクトを作ったとしても、当然ユーザーは集まりません。そもそも、情報発信などで獲得した**ファン**が存在しない場合は、**仮説検証すら空振り**してしまうのです。

起業家にとっての基礎体力は**言葉の力**であり、これを磨くためには**情報発信**が必要なのです。言葉の力が強い人には**ファン**、**顧客**、**仲間**、**投資家**と多くの人が集まるはずです。私もこの言葉の力を磨くことにより、いまの会社の礎を築くことができました。

### フックと回収の戦略

起業家志望の方が情報発信を行い、ファンや顧客を獲得していくところを [**fwywd（フュード）**](/)では**教育**と**プラットフォーム**の力で支援します。

**教育**は単純で読まれるための文章や構成の考え方などを伝え、あとは実践を通して経験から学んでいただくだけでわかりやすいと思います。

![プラットフォーム](/img/pages/blog/challenge-of-a-new-education-business/02.png)

**プラットフォーム**の力で支援とは、ある参加者 A さんが情報発信を行うと、その記事を読んで興味を持った方が別の参加者 B さんの情報にも遷移することがあります。また、良質な記事の発信が多くなることにより検索にもヒットしやすくなり、**個の力で取り組むよりも大きな結果が得られます**。参加者の力を合わせることで、この**規模の経済を効かせていくことが狙い**です。

また、読者が増えるということは**リード顧客**が増えることにも当然繋がります。起業における最初の困難である**集客**という問題にも、**個で取り組むよりも大きな成果に繋げることができます**。もちろん、このプラットフォームは発射台として利用していただければ OK で、大きくなって独自の顧客を確保できるようになってきたころには、健全なビジネスのために、独自の情報発信手段に乗り換えてもらうことを推奨しています。

このように、参加者同士での情報発信が規模の経済を生み、**一人で起業して挑戦するよりも遥かに大きな Win が参加者にあります**。その良質な情報を集めたプラットフォームを作ることができれば、弊社にとっては大きな**フック**となります。弊社ではいくつものサービスを展開しているため、**知名度が上がること**で**回収**できるマネタイズの手段があります。この**フック**と**回収**を戦略的に作ることでビジネスを伸ばすことができ、**回収**を既に持っている弊社にとっては**フックの構築ができることが Win** となります。

### ビジネスとして Win-Win の関係

参加者としては、**自身のファンや顧客の起点となる記事の PV 数が伸びるほど Win** です。弊社としては、**プラットフォーム上での PV 数が伸びるほど Win** です。つまり、それぞれの利害が一致しており、参加者の情報発信に対する PV 数が伸びなければ、我々も損をすることになるため、必死に情報が広がるように支援していくのです。

Win-Win とは良く意識高い系の言葉で言われることがありますが、**本当に成果を出すための支援をするためにはこのような Win-Win の関係を戦略的に築くことが重要**だと痛感しています。構造的に一方向のみが得をするようなサービスの作り方では**持続可能な成長を遂げることができない**のです。

この [**fwywd（フュード）**](/) の仕組みでは、継続するほど情報が蓄積して、より検索に対する力を増していくことで、知名度が低い場合でも情報が届きやすくなります。つまり、**過去の先輩の力が次の世代の起業家に繋がり、その成長を支援することもできるのです**。

これが**起業家を輩出するための真のエコシステム**であり、[**fwywd（フュード）**](/) は**全ての起業家の起点**になることを目指しています。

## おわりに

本企画は声高々に挑戦を宣言していますが、弊社キカガクの中でも**まだまだ実験的な立ち位置**です。そのため、いくつかの無料講座の提供には踏み込みはじめましたが、多くは受講料をいただいて実施しています。もちろん、社内のメンバーとは今回の企画を皮切りに、**受講生と良き仲間となるような構造に変革していけると良いよね**と話しております。現存の講座は受講料をいただく以上、もちろん精一杯の講義を務めます。

**変革にはトリガーが必要**であり、なんとしても今回の企画を成功に導き、**教育に新しい風を吹かせられるよう尽力する所存です**。このように**過程によるマネタイズでのビジネス化**が実現できると、**経済状況による教育の機会格差を減らすこと**ができます。

まだまだ私達ではそこまで踏み込める力があるとは言えませんが、より良い社会へ向けて一歩一歩進んで行きます。ぜひ、[**fwywd（フュード）**](/)含めまして、[**キカガク**](https://www.kikagaku.co.jp)をこれからも温かくご支援いただけますと幸いです。

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

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


現在募集を開始している起業家育成コースの『fwywd（フュード）in 淡路』は受講料が無料です。今回はこの『受講料無料』に込めた思い、そして、これが最終的に私の考える真の教育像に近づいていく話も含めて丁寧に背景を紹介させてください。この受講料無料は、単なる客寄せパンダとしてではなく、これは新たな教育ビジネスへの挑戦です。教育に本気の革命を。成果が出せる人材を輩出する教育の構造を紐解いていくと、この受講料無料に帰着しました。

起業家を英語で何という？ Debt や Equity など起業に頻出の用語も紹介

「好きなこと」か「得意なことか」のどちらをビジネスに選ぶべきか

受講料無料は新たな教育ビジネスへの挑戦である


## はじめに

これから起業も含めた新しいビジネスを考えるときに、ぶつかる大きな分岐点があります。  
それは、あなたが「**好きなこと**」か「**得意なこと**」のどちらをビジネスに選択するかです。  
もちろん、全てに通じる答えがあるわけではありませんが、経験上、多くの場合は**得意なこと**がビジネスへ繋がっていきます。

## 多くの人は好きなことから考え始める

### 起業とは自由な選択に思える

多くの人にとって**起業**とは**自由の象徴**のように思えているはずです。  
どのような選択を行うも自身の自由であり、だからこそ、**好きなことを仕事にしたい**と思うはずです。

すでに上場などで Exit してお金に余裕がある場合は、余生に対する仕事はこの考え方で進めても良いでしょう。  
ただし、この記事を読んでいただいている多くの人にとっては、これからの資産を形成するための初めての起業であるはずです。

### 好きなことをビジネス化するときの落とし穴

好きなことをビジネス化するときに、多くの人が『**好きだから安くて良い**』と甘い目線で始めてしまいます。  
これは転職するときのキャリアにも共通することで、**ゲームが好きだからゲーム業界で働きたい、だから給料は低くても良いと考える行動原理と同じ**です。

好きだからこそ、ビジネスというよりも自身の人生と一致させて始めたい。  
この思い自体は良いのですが、**この稼げない結末は、結局自分自身とそのユーザーを滅ぼすことに繋がりかねません**。

この**稼げないビジネスの結末**は以前の記事で綴っているので、ぜひこちらをご覧ください。

▶ 参考：[**儲からない社会課題ビジネスにおける最大の被害者は誰か**](/blog/victims-of-social-issues-problem)

## 得意なことにたどり着く

### 他の人よりも成果が出やすいから得意

当たり前のことですが、**得意**とは**他の人よりも成果が出やすい領域**です。  
私の尊敬する**瀧本哲史**さんの名言に『**適当にやってもそこそこ上手くいっていることは、徹底的にやって卓越した結果を出せる領域である。**』とあります。

ビジネスとは**他の人の課題を解決して対価を得る行為**と理解することができます。  
したがって、好きか嫌いかよりも、**他の人よりも成果が出やすい領域**であることが重要なのです。

### 好きなことにはお金を払う

キカガクの顧問としてお世話になっている元 P&G のトップデータサイエンティスト、現今村商事の今村さんがこんなことをおっしゃっていました。

> 誰かがやりたくないこととか、めんどくさいこと、簡単じゃないことを引き受けるから、お金が貰える。  
> 純粋に楽しかったら、お金払わないといけない。

引用：[今村さんの Twitter より](https://twitter.com/ShuImamuraCorp1/status/1447281408322400257)

私もこの言葉の通りだと思っています。  
好きなこと、楽しいことにはむしろ**お金を払う**ものです。

だからこそ、楽しいことを仕事にするよりも、人の課題を解決する**得意なこと**の方がビジネス化に繋がりやすいのだと思います。

## おわりに

今回は説得力を持たせるために尊敬する方の言葉を借りながらと反則気味でしたが、ビジネスを考えるときに「好きなこと」か「得意なこと」のどちらを選ぶと良いかの判断基準の一助になれば幸いです。

最後に私の考えを私の言葉で書いておくと、以下の手順でビジネスを考えてみると良いと思っています。

1. 「好きなこと」でビジネスを考える（特にマネタイズが持続可能な成長を踏まえて成立するか）
2. 「得意なこと」でビジネスを考える

私個人としては、まずは**好きなこと**でチャレンジしてみて欲しいという気持ちです。  
一方で、先述したように、持続可能な成長をおろそかにしたビジネス化はあなた自身でなく多くの人を不幸にするため、それは避けましょう。

まずは、**考えてみることが何もかもの始まり**ですので、ぜひ色々なアイディアを考えてみましょう！

今回の記事で、社会課題を解決するべく起業への思いが奮い立った方は、淡路島から始まる挑戦に最高な１年間を提供する『[**fwywd（フュード）in 淡路**](/awaji)』でお待ちしています！

最後までお読みいただきまして、誠にありがとうございました。

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


これから起業も含めた新しいビジネスを考えるときに、ぶつかる大きな分岐点があります。それは、あなたが「好きなこと」か「得意なこと」のどちらをビジネスに選択するかです。もちろん、全てに通じる答えがあるわけではありませんが、経験上、多くの場合は得意なことがビジネスへ繋がっていきます。

儲からない社会課題ビジネスにおける最大の被害者は誰か


## はじめに

現在、起業家育成コース『[**fwywd（フュード）in 淡路**](/awaji)』の立ち上げにあたり、これから起業を志す**起業家の卵**のアイディアを壁打ちする機会があります。  
**地方**、**医療**、**介護**、**教育格差**など社会課題の解決を目指し、戦う姿を日々見ることができます。

さて、話は変わりますが、私は好きになれないタイプの人がいます。  
１つ目は『**他人の批判はするのに、自分は行動しない人**』です。  
そして、もう１つは『**儲からないのに夢だけ語る人**』です。  
前者に関しては理解が容易かもしれませんが、私は後者の罪も大きいと感じています。

この『**儲からないのに夢だけ語る人**』が生まれやすい領域が**社会課題**です。  
教育格差をなくすために、無料で小中学生向けにプログラミング体験会などを開くといった話をよく聞きます。  
その行動自体は素晴らしいことだと感心していますが、ここで少し立ち止まって考えてみませんか。

『**儲からない社会課題ビジネスにおける最大の被害者は誰か**』

## ストーリー

今回は身の回りにある話をまとめ、**ストーリー仕立て**で紹介します。  
この話はあくまでフィクションです。

### 起：困っている人を助けたい

小学生にも**プログラミング教育**が必修となる社会を迎え、地方に住んでいた A 子さんは東京などの都市部との教育の格差を感じていました。  
自分の子供にはなるべく良い教育を受けさせたいと都会に移り住むことも考えましたが、これは自分たちの家庭だけでなく、**多くの地方が抱える問題**であると気づきます。  
この社会課題を解決すべく、憧れだった**起業**をしてみるのはどうだろうか。

自分たちを含めた困っている人を助けたいという**ピュアな思い**が A 子さんを突き動かしました。

### 承：人に教えることの楽しさ

知り合いに話をすると、空いているスペースを無料で貸していただけることに。  
地方が抱える課題を解決しようと志す A 子さんには**多くの味方**がいました。  
友達のお母さんにも話すと、運営をぜひ無料でも手伝いたいと申し出があり、**順調なスタート**。

最初はどんな風になるかわからないし、お試しなので、参加も無料で計画を開始。  
運営スペースや人件費もかからないので、黒字にはならないけれど、**赤字にもならない**ので OK。

TV や YouTube で誰もが**英語**と**プログラミング**を学んだ方が良いという時代。  
同じ小学校の生徒にクチコミで広がり、あっという間に定員が満席。

イベントも準備は大変でしたが、結果は**大成功**。  
自分の子供が喜んでくれたことは当然嬉しかったのですが、想像以上に**人に教えるということの楽しさ**を実感できました。

### 転：無料と有料の見えない壁

お試しでは**無料**で開催したものの、次は**ビジネスとして成立させる**べく動きます。  
今回、こんなに喜んでもらえたので、プログラミング塾としてもいけるだろう。  
小学生の塾は月謝が 20,000 円でも高い方なので、1 人 10,000 円としよう。  
20 人を受け入れるとなると、サポートが必要なので、知り合いのお母さんには時給 1,500 円でお願いしよう。
過去のイベントの成功がビジネスへと加速させていきました。

知り合いのお母さんは**負担がそこまで大きくならない**ならばと承諾をしてくれました。  
体験イベントへ参加してくれた家にプログラミング塾の話をすると、思いのほか、反応がよくありませんでした。  
**無料と有料には雲泥の差**があり、この点を楽観視していたのです。

結果的に、無料のイベントに来てくれた 3 人がプログラミング塾に入会してくれることになりました。

### 結：持続可能なビジネスを成立させる難しさ

想定以上に少なかった入塾者により、初月の売り上げは 30,000 円。  
知り合いのお母さんのパート代が 12,000 円で、場所代が 50,000 円。  
自分の給料を払うどころか、30,000 円以上の赤字です。

しかも、知り合いのお母さんも日によっては行けないこともあり、日程の調整が大変。  
苦労している上に赤字で、子供達も慣れてくると勉強を嫌がり、モチベーションを維持させるのも大変。

**こんなことなら、このビジネスを始めなければ良かった。**

そして、この３ヶ月後、結局うまく軌道に乗せることができずにビジネスを閉じることを決めます。  
入塾してくれていた子供達は中途半端にしか学ぶことができず、結局、**地方の教育格差は解消されないまま**。  
むしろ、プログラミングでできることが分からずじまいで、**プログラミングへの印象が悪くなってしまいました**。

## 儲からないビジネスの最大の被害者はユーザー

### 社会課題は戦略なしでは解決できない

このストーリーでは極端な展開としていますが、私の周りでは近しい話をよく聞きます。  
教育の格差という社会問題があるから『**志**』だけの**無計画**で始めてしまう。  
**戦略がないから、結局続かない。**  
そして、最終的にはそのツケは**ユーザー**へ回ってくるのです。

これが冒頭に述べた『**儲からないのに夢だけ語る人**』の正体です。  
使命感で燃えているのは結構。

ただでさえ難しい社会課題の解決には『**戦略**』が不可欠です。  
**ボランティア精神**とか**奉仕の心**とか、そんな甘えでは変えられないぐらい深い闇を抱えているのです。

### 社会課題をビジネスに変換

では、まず社会課題を解決するためには何をするべきか。  
それは、**社会課題をビジネスへ変換すること**です。

この問題設定の変換を正しく行うことができれば、『**課題を解決する = 儲かる**』の構造が出来上がります。  
儲ける構造ができあがれば、関わる社員の待遇を改善することができます。  
社員が学べる余裕も作ることができ、成長を促すことができます。  
待遇が良いと能力の高い人から応募もきます。

つまり、**『儲かる』とは好循環の始まり**なのです。

では、**どのように社会課題をビジネスへ変換すると良い**のでしょうか。

## 押さえるべきは２つだけ

### ユーザーの課題解決

私は起業した最初に Kaizen Platform の須藤さんの起業家向けの講演を聞く機会があり、これが今でも本当にラッキーだったなと思います。  
直接の面識はないので予想ですが、須藤さんはリーンキャンバスのような細かいフレームワークを埋めるのは面倒で、ぶっちゃけこの２つを押さえておくと良いよと教えていただきました。

その１つ目が**ユーザーの課題解決**です。  
『**誰の**』『**どんな問題を**』『**どうやって**』解決するか。

まず、ビジネスアイディアを考えるときには、この３つを文章でまとめるようにしています。  
これは社会課題を考えるときに多くの人が頭の中で思い描いているため、書き出すことは難しくないはずです。

つまり、多くの人はこの**ユーザーの課題解決**は考えられている一方で、何かが欠けてしまっているのです。

### ビジネスの課題解決

絶対に忘れてはいけないのが**ビジネスの課題解決**です。  
ユーザーの課題が解決できたとしても、ビジネスとして課題が解決できていなければ、冒頭で紹介したストーリーのように遅かれ早かれ縮小してフェードアウトしていきます。

ビジネスの課題解決では『**誰の**』『**どんな予算を**』『**何と比較させて**』ひっくり返すか？を考えます。  
お金を出す人は誰か。  
どんなお財布があるか。  
競合や他に使っていたお金をどうやって自分の方に引っ張ってくるか。

特に『**何と比較させて**』というところが肝です。  
起業をして新しくビジネスを開拓するときには、もともと使われていたお金なんてなくても、財源も新たに開拓してやる！と意気込むかもしれません。  
知名度と信用があれば実現可能かもしれませんが、実際には**新しい財源を確保することは非常に難易度が高い**のです。  
だからこそ、現在すでに通っている川の水（財源）をどうすれば自分の方に引っ張ってくることができるのか。  
これが答えられない限りは**ビジネスではない**というわけです。

この『**ユーザーの課題解決**』と『**ビジネスの課題解決**』の２つを答えられるように設計することで、『**社会課題 → ビジネス**』へと変換されるのです。  
ビジネスとして儲かる仕組みがあれば、**持続可能な成長**へと繋がり、より大きな課題解決が可能となります。

▶︎ 参考資料：[**ビジネスモデルの作り方**](https://www.slideshare.net/sudoken/ss-65668543)

## おわりに

絶対により良い方向に導いて欲しいからこそ、**社会課題の解決には戦略を**。  
志半ばで諦める人を見てきたからこそ、生優しい言葉は掛けません。  
**社会課題をビジネスへと変換し、儲ける仕組みで課題を大きく持続可能に解決していって欲しい。**

最後に、社会課題に注目している人に欠けている能力の１つである『**儲ける力**』。  
これを補うことができる本を紹介します。

▶︎ 参考書籍：[**金儲けのレシピ**](https://www.amazon.co.jp/dp/B08NPX48MQ/)

この書籍自体は社会課題の解決という観点はなく『**儲ける**』ということに終始しています。  
私はとにかく儲かればそれで良しとは思わないため、少し意に反するところもあります。  
しかし、それよりも意に反するのは『**儲からないのに夢だけ語る**』ことです。  
本当に社会課題を持続可能な形で解決したいのであれば『**儲ける**』ということも正しく勉強して、その力を良い方に使えるようになってください。

今回の記事で、社会課題を解決するべく起業への思いが奮い立った方は、ぜひ私と一緒に起業を志しましょう！  
淡路島から始まる挑戦に最高な１年間を提供する『[**fwywd（フュード）in 淡路**](/awaji)』でお待ちしています！

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

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


『儲からないのに夢だけ語る人』が生まれやすい領域が社会課題です。教育格差をなくすために、無料で小中学生向けにプログラミング体験会などを開くといった話をよく聞きます。その行動自体は素晴らしいことだと感心していますが、ここで少し立ち止まって考えてみませんか。『儲からない社会課題ビジネスにおける最大の被害者は誰か』