fwywd（フュード）でもバックエンドとして利用している Microsoft Azure に用意されている認証・認可機能などを兼ね備えた Azure Acitve Directory B2C (AADB2C) がめちゃくちゃ良いのです。その一方で、まだ情報が少ないからか使われていない印象を受けます。初期設定に関する情報が少ないだけでなく、実際に React や Next.js での実装にまで踏み込んでいる記事となるとほとんどありません。そこで、今回はそんな非常に使いやすい AADB2C をみなさまに使っていただけるように、ログインの認証機能をバッチリと使っていただけるところまで紹介していきます。この記事を読んでいただいた後に、なんで今まで自前で認証や認可を実装していたのだろうと後悔間違いなしです。

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

React & Next.js に Azure Active Directory B2C (AADB2C) で超手軽に認証機能を実装しよう


## はじめに

**これからの時代のアプリケーション開発に必須**である一方、意外と知られていない機能。それが **IDaaS (Identity as a Service)** です。

[**fwywd（フュード）**](/) でもバックエンドとして利用している **Microsoft Azure** に用意されている**認証・認可機能**などを兼ね備えた **IDaaS** である **Azure Acitve Directory B2C (AADB2C)** がめちゃくちゃ良いのです。

今回は絶対知っておいて損のない **IDaaS** に関して、**４つのメリット**を紹介します。

## IDaaS

### IDaaS とは？

まず **IDaaS** とはその名の通り、**ユーザー情報を管理するとこに特化したサービス**です。AADB2C 以外では **Auth0** が有名です。通常は自前のサーバー内でユーザー情報の管理からログイン時の情報の照合などを行うことが一般的でしたが、この機能だけを分離して、サービスとして提供しているのです。

![IDaaS](https://www.rworks.jp/wp-content/uploads/2021/10/Idaas-ttl.png)

出典：[IDaaS とは？ゼロトラストネットワークとの関連と Azure 上での実現方法について解説](https://www.rworks.jp/cloud/azure/azure-column/azure-entry/24482/)

### Azure が提供する IDaaS

基本的には、**Azure Active Directory (Azure AD)** が Microsoft Azure が提供する **IDaaS** です。**消費者 (consumer) 向け**に特化した機能が付け加えられた Azure の IDaaS が **Azure Active Directory B2C (Azure ADB2C or AADB2C)** というわけです。これからユーザーのログインなどの認証・認可機能を実装したいという方にはぴったりです。

**AADB2C** では、**Azure API Management** と組み合わせることで、認証済み（＋許可対象）のユーザーのみ情報にアクセスできるような**認可機能**も非常に手軽に実装できます。実装するというよりも、Azure API Management の画面上に利用する AADB2C の ID を設定するだけですので、時間にして 30 秒ほどで完了できてしまうのです。

これからのクラウドの時代は、サーバーを借りてその中でアプリケーションを構築するのでは環境をフル活用できていません。**IDaaS** や **PaaS** など各機能に特化したサービスを必要に応じて組み合わせることで、**コストを削減**しながら**スケール拡大**にも対応できるような構成を作っていくのです。

### 認証機能って簡単じゃね？

それでは、IDaaS を導入するメリットを見ていきましょう。Python での Django や Ruby での Ruby on Rails などの **Web アプリケーションフレームワーク**を利用して、これまで Web アプリケーションを開発して来られた方も多いと思います。その方々にとっては、**認証機能って Web アプリケーションフレームワークの中に入っているので、別で実装する必要なくない？** という感じだと思います。かつての私もそう考えていました。

## IDaaS を導入する４つのメリット

### メリット１：UI の実装が不要

この理由だけでも **IDaaS** を絶対に導入した方が良いと思います。通常 Web アプリケーションを実装していくときには、ログインやログアウトの画面が必要となります。当たり前のことですし、情報としてはそれなりに揃っているのですが、この認証周りの実装は**地味に面倒**なのです。

**AADB2C** や **Auth0** では、この認証画面の実装が一切不要です。ログインや新規登録ボタンを押した際に **AADB2C** の指定されたリンクに遷移させるだけです。ログイン後に、認証情報を持ってリダイレクトしてきてくれます。この辺りは本記事で実際に紹介しますね。最近では実装が当たり前になっている Google や Facebook アカウントでのログインも実装は意外と面倒なのですが、AADB2C では GUI だけで超簡単に設定できます。

### メリット２：セキュリティ対策になる

アプリケーションで攻撃が多いのが**ログイン画面**なのです。もちろん、この攻撃に耐えられるように Web アプリケーションフレームワーク側で**セキュリティ対策**が施されているため、知識がなくてもある程度攻撃から守ることができています。しかし、そのような一番攻撃が多い箇所を無知なまま進めていくと、いつか痛い目を見るかも知れません。

それに対して、**AADB2C** などの **IDaaS** では、ログイン画面などは全て **IDaaS** 側で管理されているため、強固な最新のセキュリティ対策が施され続けます。Web アプリケーションフレームワークで守るというよりも、**サービスとして守られる**ため、多くの開発者にとっては**絶対に取った方が良い選択**です。

私自身も、元々はソフトウェアテストの会社で働いていた経験があり、ある程度は攻撃のパターンに関する知識があります。それでも、最新の情報を追い続けることは困難ですし、同じ力を使うのであれば、UI/UX がさらに改善される方法論の調査に充てます。多くの開発者にとって、IDaaS を利用して認証・認可の内製化を手放すことは**本質的な開発に充てられる時間を長くする**ものです。

### メリット３：スケールに強くなる

ユーザー数の多いサービスの場合、**ログイン後の認証や認可を行う処理は極めて処理量が多く**なります。したがって、最初は動いていて良かったものが、いつしかどんどん遅くなっていくのです。

この対策として、**Reddis** などを利用して、ユーザーログイン後のセッション情報をキャッシュするなどで改善している例が多いはずです。ここまで実装できれば、もちろん良いのですが、新規事業など機能追加に追われるチームにとっては、この**スケールに向けたパフォーマンス改善に充てられる人材リソースは少ないはず**です。

それに対して、AADB2C などの IDaaS では、この点もほとんど気にする必要がありません。**スケールはパブリッククラウドが得意な領域**であるため、ユーザーが拡大しても、これまでと同じようなパフォーマンスを得られ続けます。

しかも、AADB2C は**月間アクティブユーザーが 50,000 人までは無料**で使えて太っ腹です。初期のコストを気にするベンチャー企業や個人開発にとっても良い選択と言えます。

▶ 参考：[Azure Active Directory 外部 ID の価格](https://azure.microsoft.com/ja-jp/pricing/details/active-directory/external-identities/)

### メリット４：複数アプリでも管理が楽

企業では、１つのアプリケーションだけでなく、**複数アプリケーション**を保有していることが多く、これらのアプリケーション間でユーザー情報を適切に管理できているかも重要です。運営している会社が同じにもかかわらず、各アプリケーションごとに新規登録が必要になったりといった不便な体験はないでしょうか。小規模な開発のみに関わっていると視野に入れていないことが多いのですが、大事な観点です。

情報を一元管理できていないとセキュリティのリスクが高まりますし、効率の良いマーケティング施策が打てないといったことも考えられます。これから大きくなっていくことを見据える会社ほど、**複数アプリケーションの情報を一元管理できる IDaaS** が求められているはずです。

## IDaaS が気になった方が次に読んでほしい記事

### AADB2C の導入

**AADB2C の導入**はすでに以下の記事で紹介していますので、興味を持っていただけた方はぜひこちらからご覧ください。**どのくらい手軽か**がすぐに分かっていただけるはずです！

▶ 関連記事：[Azure Active Directory B2C でユーザー認証を超簡単に実装しよう](/tech/aadb2c-auth)

### React & Next.js と AADB2C の連携

[**fwywd**](/) でも利用している **React & Next.js の認証機能として AADB2C を利用する具体的な流れ**を紹介していますので、ぜひご覧ください。

▶ 関連記事：[React & Next.js に Azure Active Directory B2C (AADB2C) で超手軽に認証機能を実装しよう](/tech/nextjs-azure-ad-b2c)

### Microsoft Azure を選択する理由

また、**Microsot Azure** をパブリッククラウドとして採用していますが、その理由も以前紹介していますので、気になった方はぜひこちらもご覧ください。

▶ 関連記事：[パブリッククラウドの選択肢として Microsoft Azure を採用する３つの理由](/blog/why-adopt-azure)

## おわりに

**IDaaS** も含め、これからは**複数サービスの組み合わせられる力**が重要になります。

その一方で、この議論をするときに話題に挙がるのが、サービスの差別化を図るための**内製化**も当然重要となります。

「**どのような機能は内製化すべきでないか？**」

その答えは、多くのサービスで共通する処理は内製化する必要がないと答えています。つまり、**コモディティ化**した機能です。**認証や認可**はその代表格と言えるのではないでしょうか。このようなコモディティ化した機能の開発に注力したところで、**サービスの差別化には繋がりません**。

この**コモディティ化しているか否か**を基準に、**XXaaS** や **API** といった外部サービスの利用か、内製化を判断していくと良いでしょう。

### 著者

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

### 【受講料無料】経営力と技術力を兼ね備えた起業家を目指そう

[![awaji](/img/home/entre.png)](/awaji)

キカガクの創業者であり、fwywd 責任者である吉崎が次に手掛けるのは『[**本気の起業家育成**](/awaji)』。  
経営力と技術力の両方を兼ね備えた人材を育成し、これからの日本の変革に挑戦します。

これからは**挑戦しないことがリスクになる時代**。  
起業家として成功すべく試行錯誤する日々は確実に市場価値を高めます。

そして、起業家育成の舞台は**淡路島**。  
パソナグループが**ベンチャーアイランド**として変革を起こしているこの地で、仲間と切磋琢磨できる１年間を提供します。  
宿泊などの生活面もパソナグループが全面バックアップで、挑戦するには最も良い環境です。

▶ 詳細をチェック：[**fwywd in 淡路 | 起業家育成プログラム**](/awaji)


これからの時代のアプリケーション開発に必須である一方、意外と知られていない機能。それが IDaaS (Identity as a Service) です。fwywd（フュード）でもバックエンドとして利用している Microsoft Azure に用意されている認証・認可機能などを兼ね備えた IDaaS である Azure Acitve Directory B2C (AADB2C) がめちゃくちゃ良いのです。今回は絶対知っておいて損のない IDaaS に関して、４つのメリットを紹介します。

React & Next.js に Azure Active Directory B2C (ADB2C) で超手軽に認証機能を実装しよう

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


## はじめに

**起業家**とは、みなさんどのようなイメージをお持ちでしょうか。起業を検討している方は、**どのような人が起業家に向いているのか？** を知りたい方が多いのではないでしょうか。

また、起業家と同じように使われる用語として**創業者**や**経営者**があります。起業家とはゆくゆくはこの**どちらかの道**をたどっていきます。著者である私自身も**５年前に会社を創業**したため、一起業家としての経験を含めて紹介します。

## 起業家とは

![01](/img/pages/blog/what-is-an-entrepreneur/01.jpg)

### どんなことをする人？

起業家とは**問題を解決する仕組みを作る人**です。そのため、**解決したい課題への当事者意識が必要**であることがもちろんのこと、**解決したい課題をビジネスへ変換する能力**も必要です。

たとえば、場所にとらわれずに学べる環境を提供するために E-learning 型のスクールを立ち上げるといったように、**『誰の』『どんな課題を』『どうやって』解決するか**といったビジネスアイディアを考え、実現可能な形にできるよう行動をし続けます。

### 起業家に向き不向きはあるの？

起業家には**課題意識**と**行動力**が必要となりますが、**起業家の向き不向きは基本的にはない**と思っています。その理由として、**行動力がない人は世の中に基本的には存在しない**ためです。行動力がないのではなく、『**いま**』行動するための**動機が弱い**だけなのです。そういった意味で『**いま起業すべきか？**』といった点は検討すべきです。

最近では、**週末起業**や**１円起業**といったようにハードルを下げた言い方もありますが、基本的には**挑戦にはリスクが伴います**。一時的に収入がなくなるといった**金銭的リスク**はわかりやすいですが、法を犯した場合などの**評判リスク**、起業しなかった場合のキャリアでの**機会損失**など挙げればキリがありません。だからこそ、色々なことを**天秤にかけた**上で判断をしないといけません。

## 起業家の分かれ道

![02](/img/pages/blog/what-is-an-entrepreneur/02.jpg)

### 創業者

創業初期は『**起業家 = 創業者**』です。起業家も創業者も**仕組みを作る人**です。社会に存在する課題を見つけ、それをビジネスモデルへ落とし込み、ビジネスの力で解決していく仕組みを作るのです。創業者は英語で **Founder** であり、プロフィールに **Founder** や **Co-founder**（共同創業者）と書いてある場合は、会社を立ち上げるときに一緒に始めた人ということです。

創業者は**熱しやすく冷めやすい**性格の人が多い印象で、仕組みを作り上げることができると、これからがビジネス的に美味しいときでも、次のことに挑戦したくなってしまう人がいます。**仕組みを作ることに美学を感じている**一方で、それが他の人の手によってうまく回り始める頃には興味を失っていることがあります。

実は私自身がそのタイプであり、**常に最前線で新しい仕組みを作り続けていないと耐えられない**のです。こういった性格の方は起業した後は**創業者**として経営よりも、新しい事業の創出に取り組み続ける方が向いています。

### 経営者

経営者は**仕組みを伸ばす人**です。**計画性が高く、緻密に行動を管理できる人が向いています**。起業家として事業を起こし、そのまま会社の組織を大きくするところまで一緒に成長していく人は**経営者**として成功しています。

一方で、創業者から経営を引き継ぎ、**２代目以降の社長として経営者**となるケースも私の周りでは増えてきました。新しい事業を作っていないと耐えられない創業者に**新規事業の創出**を任せ、経営は**後続の社長を中心とした経営陣を構築**して進めるのです。メリットは、**それぞれの強みを活かせる**ことです。創業者タイプの人は能力が高いように見えますが、経営など緻密に課題へと向き合うと相性が悪く、**全然力が発揮されないことがある**のです。デメリットは経営方針の意思決定が**創業者**のスピードには敵わないことだと一般的には言われています。

## おわりに

一言に**起業家**といってもキャリアとしては**創業者タイプ**と**経営者タイプ**があります。これらがわかるのは、意外と進めてみてからだったりするのです。

私が創業したキカガクでは、私が創業から４年社長を務めた後、５年目からは現在の社長に後任をお願いしました。私自身が、経営というよりも、常に新しい事業を創出し続ける**創業者**として行動し続けたいという願いを聞き入れていただいた上での判断でした。

事業を創出する力に不安があるが、緻密に戦略を練っていくことに自信がある方は、**次の経営者を探している創業者タイプの起業家**に出会えると面白い反応が起きるはずです。

### 著者

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

### 【受講料無料】経営力と技術力を兼ね備えた起業家を目指そう

[![awaji](/img/home/entre.png)](/awaji)

キカガクの創業者であり、fwywd 責任者である吉崎が次に手掛けるのは『[**本気の起業家育成**](/awaji)』。  
経営力と技術力の両方を兼ね備えた人材を育成し、これからの日本の変革に挑戦します。

これからは**挑戦しないことがリスクになる時代**。  
起業家として成功すべく試行錯誤する日々は確実に市場価値を高めます。

そして、起業家育成の舞台は**淡路島**。  
パソナグループが**ベンチャーアイランド**として変革を起こしているこの地で、仲間と切磋琢磨できる１年間を提供します。  
宿泊などの生活面もパソナグループが全面バックアップで、挑戦するには最も良い環境です。

▶ 詳細をチェック：[**fwywd（フュード）in 淡路 | 起業家育成プログラム**](/awaji)


起業家とは、みなさんどのようなイメージをお持ちでしょうか。起業を検討している方は、どのような人が起業家に向いているのか？を知りたい方が多いのではないでしょうか。また、起業家と同じように使われる用語として創業者や経営者があります。起業家とはゆくゆくはこのどちらかの道をたどっていきます。著者である私自身も５年前に会社を創業したため、一起業家としての経験を含めて紹介します。

起業家とは？創業者や経営者の違いも紹介！


## はじめに

『**どうやって起業のアイディアを考えたら良いですか？**』最近、この質問が一番多い気がします。

実は、考えようとするから出てこないのです。起業のアイディアとは、**行動できるほどの熱量**が必要であり、これは市場から生まれるものではなく、みなさん自身の**原体験**から生まれてくるものなのです。
今回はすでに起業のアイディアをまとめるための武器として確立されているフレームワークに加えて、私の我流の考え方も併せて、**おすすめのアイディアの出し方**として紹介します。

## 自己分析のフレームワーク

起業する際のビジネスのアイディアの考え方、その中でも起点となる**自己分析**のフレームワークはすでにいくつも提案されています。

今回は、[**起業を考えたら読みたい一冊『起業のすすめ さよなら、サラリーマン』**](/blog/recommended-books-for-entrepreneur) で紹介している書籍で紹介されている中から、始めやすいと思った**２つの自己分析**を紹介します。気になった方はこの書籍で全体を見通していただいても良し、それぞれで紹介する書籍で深掘りするのも良しです。

▶︎ 参考書籍：[**起業のすすめ さよなら、サラリーマン**](https://www.amazon.co.jp/dp/B09HK58VSK)

### デロイトトーマツベンチャーサポート理論

この理論では、**Why**, **How**, **What**, **Who** の４パターンに分けて、まず自分がどのタイプかを考えます。そして、自分の得意な方法からビジネスを考えていきます。

- **Why 型：ビジョンを考えるスキル**
  - ビジネスの重要性や熱量を人に伝えることが得意なタイプ
  - CEO に多いタイプ
- **How 型：ビジネスモデルを考えるスキル**
  - ビジョンをビジネスに変換して収益化を考えることが得意なタイプ
  - CFO や COO に多いタイプ
- **What 型：商品を開発するスキル**
  - 技術や製品を熱中して作ることが得意なタイプ
  - CTO に多いタイプ
- **Who 型：顧客を考えるスキル**
  - ユーザーは何を望んでいるか市場から考えることが得意なタイプ
  - CMO に多いタイプ

この自己分析では、**そもそも自分が CEO として起業すべきなのか？**、それとも共同創業する仲間を見つけるべきなのか？というところがわかるのが良いです。起業のアイディアが出ないという理由は、もしかすると、自分自身では課題意識が弱いため、他の人の強烈な課題意識を一緒にやり遂げたいと思う心の叫びなのかも知れません。

ベンチャー企業で課題解決に向き合うには **CEO 以外にも多くの役割が必要とされる**ため、**得意な領域で価値を発揮**できるように自己分析を進めましょう。

気になった方は、以下の書籍でさらに深掘りしてみましょう。

▶︎ 参考書籍：[**起業家とつくった起業の教科書**](https://www.amazon.co.jp/dp/B01N1U8NJ5/)

### ストレングスファインダー理論

これは書籍『[**さあ、才能(じぶん)に目覚めよう 新版 ストレングス・ファインダー 2.0**](https://www.amazon.co.jp/dp/4532321433)』にて紹介されている、主に『**強みの活かし方**』に焦点を当てた内容です。

これは方法自体が良いと言うよりも、**Web テスト**がついているため、質問に回答していく中であなた自身のことが自動的にわかっていくことが良いことです。フレームワークに落とし込んで考えてみると言うのは、簡単なようで**意外と自分のことを客観視できなかったりする**ので、こういった質問に回答していく形式の方が最初のステップとしては良いでしょう。

そして、得られた結果をもとに、**自身の強みを活かしていく行動アイディア**を深めていくと良いでしょう。

私の周りでも、起業のアイディアを考えるときだけでなく、**チームビルディングの一環として相手のことを理解するため**に使っている企業も多いです。

▶︎ 参考書籍：[**さあ、才能(じぶん)に目覚めよう 新版 ストレングス・ファインダー 2.0**](https://www.amazon.co.jp/dp/4532321433)

## 吉崎流の考え方

### 収束と発散を意識

それでは、ここからが**私の考えるビジネスアイディアの考え方**です。

まず、前提として、ビジネスアイディアを考えるときには**発散**と**収束**のパートを別々に用意することが重要です。多くの人はこれを同時に考えてしまうため、自分のアイディアに制限をかけてしまうのです。

**発散**のパートでは、これから紹介するように**原体験**をもとに、解決したい課題をどんどん書き出していきます。ここでの特徴として、**ビジネスとして成立するか？**といった観点は**一切不要**です。これを考えてしまうことで、アイディアの発想が狭まってしまうのです。

次に**収束**のパートでは、書き出したアイディアに対して、**ビジネスのフレームワーク**を当てはめます。クッキーを作るときに型にはめるのと同じ流れです。うまく型にはめられなかったところを**どんどん削ぎ落としていく**のです。

発散のパートでは**自己肯定感**を強く、収束のパートでは**計画性**を強く意識して、**一人二役**をそれぞれで演じるようにしましょう。

### 収束は慣れの問題

先に**収束**のパートから紹介すると、これは２つの課題を解決するように型を考えるだけで OK です。

１つ目の**ユーザーの課題解決**では、『**誰の**』『**どんな問題を**』『**どうやって**』解決するか。そして、２つ目のビジネスの課題解決では『**誰の**』『**どんな予算を**』『**何と比較させて**』ひっくり返すか？

これを答えることができれば、ビジネスとして成立する見込みがあるリストに入れていき、その中で検証していくアイディアを最終的に決めるだけです。

**事業計画書**をしっかりと書かなければいけないのでは？と思われるかも知れませんが、これは意外と違うのです。初期は見込みのある事業に見当をつけて、あとは**仮説検証のトラクション（実績）** の方が、綺麗な事業計画書よりも遥かに説得力があります。

ここで落とし穴なのが、ビジネスの課題解決にある『**どんな予算**』のところです。ここは**経験者の方が圧倒的に有利**なパートになります。ビジネスを開拓した経験が浅いもしくはない人は、**目の前のユーザーからお金を取る方法しか考えられません**。一方で、ビジネス経験が豊富だと**直接的なマネタイズ**でなく**間接的なマネタイズ**も見当することができます。視野が狭いと実現不可能に見えるものも、**視野が広いと実現可能なこともよくあります**。

**間接的なマネタイズ**を理解する上では、**フック**と**回収**の役割を分けることから知っていくと良いでしょう。以下の参考記事がお勧めです。**ビジネスを収束させるフェーズ**では、経験者が近くにいれば**壁打ち**を申し込んでフィードバックをもらうことが近道です。

▶︎ 参考記事：[**フックと回収エンジンでビジネスを拡大！── ドリームインキュベータが出版社から事業を譲受した理由**](https://c.kodansha.net/news/detail/38940/)

### 原体験を重要視する理由

ビジネスモデルに落とし込む**収束**は経験者が有利であると言うことは、結局**ビジネスは先輩が勝ち続けるものと結論づけられる**気がします。でも、意外とそうじゃないところが面白いところなのです。

実は**発散**のパートでは、ビジネスの経験よりも**原体験の強さ**が重要であり、これは経験で補うことができません。

先輩経営者でも１つ目のサービスは原体験から来る思いが強く、成功する一方で、それ以降の新規事業がうまくいっていないという話を聞いたことがないでしょうか。これは、１つ目の経験によってビジネスモデルへの落とし込みがうまくなった一方で、次の**ビジネスへ落とし込む原材料がない**ため、結局うまくいかないのです。

**原体験**は**行動の原動力**です。どれだけビジネス力が向上したとしても、**原動力なき成功**は難しいのです。

### フルコミットは最強の差別化要因

**人はひとつのことにしか注力できません**。だからこそ、差別化を図れるところは『**全力で課題解決に注力する**』ことです。

例えば、経験者である私から答えを与えられてその通りに実行する程度のビジネスであれば、**私自身が先に取り組んで成功している**でしょう。

世の中に**これだけ素晴らしい経営者がいても解決されていない問題がある**ことには理由があるのです。だからこそ、リスクを恐れず、フルコミットでその課題へ向き合うことこそ、**最強の差別化要因**になるのです。

### 原体験は過去の怒りがヒント

それでは、**原体験**からアイディアを**発散**させていきましょう。そうとはいえ、**原体験**の深掘りなんて、どこから手をつけて良いかわかりませんよね。

私は**怒り**をヒントに考え始めます。**解決したい**と強く思うということは、そこに**怒り**が隠れていることが多いのです。これまでの人生を振り返って、自分が抱えているコンプレックスなどに注目し、**怒りを強く感じたシーン**を振り返ってみましょう。

私自身は、公立の小中 → 高専 → 京大 → 社会人と人生を歩んできたときに、毎度環境が変わるごとに驚かされることばかりでした。次の段階で出会う人たちの当たり前と自分の当たり前が極端にレベルがずれており、いつも私は**劣等感**を抱えて生きてきました。そのときに、**なぜ教えてくれなかったのか**といつも怒りを抱えていました。専門的な学力だけでなく、一般教養、コミュニケーション力など、同じ時間を過ごしているはずが、同い年でなぜここまで**情報格差**が開いてしまうのか。

この**怒りが原点**になり、私のような田舎者（小学校は１学年１７人）でも臨めば機会が得られるようなサービスを作っていきたいと**教育**という領域を選択しました。また、社会人になってから、周りが全然学ばない様子を見て、この人たちと一緒に働いていかないといけないのかと**落胆の怒り**もあり、**社会人を本気で変えられるような教育**へと今は繋がっています。

このように、**みなさんの人生で怒りを感じたときを書き出してみましょう**。

### 生活に困らないときに何がしたい？

原体験とさらに向き合う方法がもうひとつあり、これは一般的に紹介されていることをあまり見たことがありません。一方で、起業家を志す人と面談をしているときに質問すると、**目の色が変わる**ことがあります。

それは『**もし生活には一切困らないお金がすでにあったら、何がしたい？**』という質問です。

アイディアを膨らませるときに、多くの人が『**最低限でも生活が成り立つ中で**』と心のブレーキをかけてしまっているのです。そのブレーキを外すのがこの質問の意図です。

最初から大きな野望を解決できるわけはありません。そうにも関わらず、ビジネスのアイディアを考える初心者は最初からラスボスと戦う気で考えてしまいます。そうなると、自分のレベルもそこまで高くないことがわかっているので、**ラスボスのレベルを下げる**のです。

### ラスボスは大きくて良いじゃん

よく起業家の失敗談に『**半歩先のサービスを作る**』という教訓が書かれています。倒すべき敵が早すぎた反省から、レベルをちょっと下げて現実的なプロダクトを作っていこうという話です。私自身、この考え方には賛成で、収益を上げるためには必然だと思います。一方で、それが**ラスボス**だと考えるのは違うと思います。けれども、多くの人がこの**半歩先のサービス**をラスボスとして会社のミッションを設計していき、時代に適した価値の高いうちに M&A や早期 IPO での Exit して売り抜くという流れにも見えます。この時代に適していることを証明するかのような**短期利益主義**、**PL 主義**が残念でなりません。

**ラスボスは大きくて良いのです**。ラスボスを倒せるように、自分自身や組織を成長させていけば良いのです。だからこそ大切なことが**マイルストーン**を適切に定め、今の自分達でも倒せる小さなボスから着手していくのです。

『**もし生活には一切困らないお金がすでにあったら、何がしたい？**』という質問では、多くの人が人生最後にやり遂げたい**ラスボス**が現れます。

みなさんにとって、人生を賭けて挑戦したいことはなんでしょうか。ぜひ長期的に取り組みたい、最後の展望まで見通してみてください。

## おわりに

少し前に後輩から起業したいと相談を受け、理由を聞いてみると「**５年以内に１０億円欲しい**」と回答がありました。なぜ１０億円欲しいのかと聞くと「**５年後に出産を計画している子供に良い教育を受けさせたいから**」。いま流行りの**早期退職して形成した資産で暮らすライフスタイルの FIRE を実現したい**のだと理解しました。

ちなみに、これから生まれてくる子供にとって、**働かずに悠々自適の生活を送る様子を見せる**のと、**社会への課題意識を持って日々取り組む父親の背中**と、どちらをあなたは見せたい？と聞くと、ハッと目が覚めたようでした。まさに**手段が目的になっていた**のです。

もちろん、**良い教育を受けさせられるように生活の資金に余裕がある形で、熱量高く取り組める領域を見つけていこう**と、そこからさらに深掘りしていきました。

この議論で大事だったことは**制約条件**と**目的関数**の切り分けです。**制約条件**とは、最低限クリアしていないといけないこと。**目的関数**とは最大化したいもののこと。つまり、この知り合いは、子供に良い教育が受けさせられる生活資金の獲得が制約条件（最低限の条件）であり、その上で、自身の熱量を最大限高く取り組めるビジネスを構築したかったのです。

**制約条件**と**目的関数**の２つを正しく切り分けて設定できることで、自身が最終的に取り組みたいテーマが見つかるかも知れません。

それでは、今回も長文をお読みいただきまして、誠にありがとうございました。[**fwywd**](/) では本記事以外でも[**起業のヒントになる記事**](/tech/tags/起業)を書いていますので、ご覧いただけますと幸いです。

### 著者

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

### 【受講料無料】経営力と技術力を兼ね備えた起業家を目指そう

[![awaji](/img/home/entre.png)](/awaji)

キカガクの創業者であり、fwywd 責任者である吉崎が次に手掛けるのは『[**本気の起業家育成**](/awaji)』。  
経営力と技術力の両方を兼ね備えた人材を育成し、これからの日本の変革に挑戦します。

これからは**挑戦しないことがリスクになる時代**。  
起業家として成功すべく試行錯誤する日々は確実に市場価値を高めます。

そして、起業家育成の舞台は**淡路島**。  
パソナグループが**ベンチャーアイランド**として変革を起こしているこの地で、仲間と切磋琢磨できる１年間を提供します。  
宿泊などの生活面もパソナグループが全面バックアップで、挑戦するには最も良い環境です。

▶ 詳細をチェック：[**fwywd（フュード）in 淡路 | 起業家育成プログラム**](/awaji)


『どうやって起業のアイディアを考えたら良いですか？』最近、この質問が一番多い気がします。実は、考えようとするから出てこないのです。起業のアイディアとは、行動できるほどの熱量が必要であり、これは市場から生まれるものではなく、みなさん自身の原体験から生まれてくるものなのです。今回はすでに起業のアイディアをまとめるための武器として確立されているフレームワークに加えて、私の我流の考え方も併せて、おすすめのアイディアの出し方として紹介します。

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


## 起業家を英語で？

起業家は英語で **Entreprenuer** と言います。日本語では**アントレプレナー**と発音されます。

本記事では**起業に関連する英語の用語**を紹介します。

**entrepreneurship**, **intrapreneur**, **finance**, **accounting**, **debt**, **equity**.

みなさんは、これらの意味を適切に答えられるでしょうか。

## 起業関連の用語

豆知識として、起業関連でたまに登場する英語も押さえておきましょう。この界隈ではカタカナの**横文字**も多いため、**即座に意味の理解**ができることが重要です。

### アントレプレナーシップ

英語では **Entrepreneurship** です。意味は**起業家精神**です。

Google の検索数ベースでの判断では、起業家の教育には**アントレプレナー教育**よりも、**アントレプレナーシップ教育**という方が多いです。**起業家精神**を養うという意味ですね。

私が手がけている**起業家育成コース**の [**fwywd in 淡路**](/) では、起業家精神を養うだけでなく、**行動によって起業家そのものになること**を目的としているため、**アントレプレナー教育**の方が近いイメージです。基本的に、この点をそこまで意識して使い分けているケースは見当たらないため、迷った時には多数派の**アントレプレナーシップ教育**を選択すると良いでしょう。

▶︎ 関連記事：[**経営と技術を学べる起業家育成コースの fwywd(フュード) in 淡路**](/awaji)

### イントレプレナー

この **Intrapreneur** は日本語で**社内起業家**です。日本語での発音は**イントレプレナー**が多いです。

主に、企業内で**新規事業を立ち上げる人材**のことを指します。特に**大手企業**でこの用語が毎日のように飛び交うようになっています。

企業内での新規事業創出自体はずっと取り組まれてきていましたが、最近での**起業ブーム**に後押しされるように、**社内起業**にも注目が集まり、アントレプレナーに対して、**イントレプレナー**という言葉で区別されるようになりました。

いま企業内での**新たな事業の柱の創出**が課題となっています。従来のようにビジネスが成立している事業の上で雇用される側の社員に新規事業を任せようにも、**経営**を含めた**ビジネス創出**の経験が全くないため失敗を繰り返しています。そこで、最近では、社内からも経営を含めた**新規事業創出**ができる人材を育成するといった流れに注目が集まっています。

**AlphaDrive** さんのように、イントレプレナー育成のための**研修プログラム**も少しずつ提供が始まりましたので、気になった方は検索してみてください。

▶︎ 参考ページ：[**AlphaDrive の新規事業開発支援**](https://adnp.alphadrive.co.jp/service/incubation)

## 起業家なら押さえておきたい用語

### ファイナンス

英語では **Finance** で、日本語では**財務**という意味です。

これは英語として使うと言うよりは、『**資本政策はどうするの？**』といった意味合いの時に『**ファイナンスはどうするの？**』と尋ねたりします。したがって、この**ファイナンス**は資金調達の方法から、その資金使途までの戦略などを指すことが多いでしょう。

起業を考え始めた段階で『**ファイナンスは？**』と聞かれてびっくりするかもしれないため、先に以下の書籍を読んでおくと見通しが立つでしょう。

▶︎ 参考書籍：[**起業のファイナンス ベンチャーにとって一番大切なこと**](https://www.amazon.co.jp/dp/B011HON7B6)

### アカウンティング

英語では **Accounting** で、日本語では**会計**や**経理**を指します。この**アカウンティング**は先述した**ファイナンス**と対比して用いられることが多い感じがします。

ベンチャー企業では**最高財務責任者 (CFO: Chief Financial Officer)** の有無で成長が大きく変わってくると言われていますし、私もそう感じます。多くの場合、CFO は後から参画していただくことになりますが、この人探しが非常に大変です。

大雑把な分類ですが、**未来のファイナンス (Finance)**、**過去のアカウンティング (Accounting)** と覚えておくと良いでしょう。もしかすると、**攻めのファイナンス**、**守りのアカウンティング** という覚え方でも良いかもしれません。これは良し悪しではなく、仕事の性質を指しています。

**ファイナンスの経験がある人**は、資金調達をしたり、その調達したお金の資金使途の戦略を考え、実行に落としていった経験を持っていることが多いでしょう。それに対して、**アカウンティングの経験がある人**は、企業内で使われたお金を財務諸表に整理していく経験を持っているでしょう。

企業内では**この両者が必要**となりますが、**初期の CFO はファイナンス経験のある人**であることが望ましいケースが多いでしょう。

### デット

英語では **Debt** ですが、主に **Debt Finance**（**デットファイナンス**）のことを指します。日本語で直訳すると**借金**という意味です。

**デットファイナンス** は金融機関から**融資**での借入のことを指し、**資金調達の手段の一つ**です。

主に、起業初期には**日本政策金融公庫**から**創業融資**を受ける人が多い印象です。多い場合には 1,000 万円程度、周りでは**数百万円**程度の融資を借りている人が多かった印象です。この創業融資は**無担保**な上に、**保証人なし**で借りられる場合があるため、起業初期には人気です。

民間の金融機関では**保証人**が必要な場合が多く、基本的には**代表者**がその連帯保証人になります。私も連帯保証人になって融資での借入を受けており、会社が倒産した場合においても、返しきれていない分のお金は個人で返していく必要があります。

創業融資で借りられる金額はあまり大きくなく、**健全に成長していても融資が必要になる場面**が多く、この連帯保証人になるタイミングが**腹を括るとき**かも知れません。

▶︎ 参考ページ：[**新創業融資制度 - 日本政策金融公庫**](https://www.jfc.go.jp/n/finance/search/04_shinsogyo_m.html)

### イクイティ

英語では **Equity** ですが、こちらも主に **Equity Finance**（**イクイティファイナンス**）のことを指します。日本語では**公平**のように調べると出てくるかも知れませんが、基本的にはそういった意味では使いません。

**イクイティファイナンス** とは、**株式**による**資金調達する手段の一つ**です。主に**デットファイナンス**と対比されます。

最近の**スタートアップ企業**での**主な資金調達手段**と言っても過言ではありません。**新しく株式を発行**し、それを**算定した企業価値**をもとに、**株式の買い手**を探します。株式の買い手が見つかるとそれが新しい**株主**になり、その**株式の新規発行分の資金**が企業に入ってきます。この資金を元手にさらに事業を加速させていくのです。

**デットファイナンス**との大きな違いとして、基本的には**失敗した場合にも資金の返済の必要がない**ことです。つまり、失敗しても融資のように**リスクを伴いません**。これがイクイティファイナンスの人気の理由です（補足：投資家界隈は狭いコミュニティであり、不誠実さはすぐに伝わるため、評判のリスクは当然あります）。

デメリットも当然あります。融資では決まったタイミングでお金を返せば経営への口出しは一切ありませんが、株主には**株主総会**で説明する責任が生じ、方針の合わない株主の場合でも、ある程度言うことを聞かざるを得ない**自由度の喪失**が天秤にかかります（補足：逆に相性の良い株主とは加速します）。

## おわりに

現在、募集を開始している起業家育成コースでよく使う横文字の用語をまとめてみました。私も最初に聞いた時は**デット？**、**イクイティ？？** となったので、みんなそんなところから始まるので大丈夫です。以下の記事で紹介している書籍ではさらに見通しが良くなるかも知れません。

▶︎ 関連記事：[**起業を考えたら読みたい一冊『起業のすすめ さよなら、サラリーマン』**](/blog/recommended-books-for-entrepreneur)

ぜひ今回の記事で紹介したリンクや書籍を見て、さらに理解を深めてみましょう。次は **IPO**, **M&A**, **PMI** など熟語についてもまとめていきたいと思います。

### 著者

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

### 【受講料無料】経営力と技術力を兼ね備えた起業家を目指そう

[![awaji](/img/home/entre.png)](/awaji)

キカガクの創業者であり、fwywd 責任者である吉崎が次に手掛けるのは『[**本気の起業家育成**](/awaji)』。  
経営力と技術力の両方を兼ね備えた人材を育成し、これからの日本の変革に挑戦します。

これからは**挑戦しないことがリスクになる時代**。  
起業家として成功すべく試行錯誤する日々は確実に市場価値を高めます。

そして、起業家育成の舞台は**淡路島**。  
パソナグループが**ベンチャーアイランド**として変革を起こしているこの地で、仲間と切磋琢磨できる１年間を提供します。  
宿泊などの生活面もパソナグループが全面バックアップで、挑戦するには最も良い環境です。

▶ 詳細をチェック：[**fwywd（フュード）in 淡路 | 起業家育成プログラム**](/awaji)


起業家は英語で Entreprenuer です。本記事では起業に関連する英語の用語を紹介します。entrepreneurship, intrapreneur, finance, accounting, debt, equity...みなさんは、これらの意味を適切に答えられるでしょうか。

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

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) です！  
本記事では **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)

### 【受講料無料】経営力と技術力を兼ね備えた起業家を目指そう

[![awaji](/img/home/entre.png)](/awaji)

キカガクの創業者であり、fwywd 責任者である吉崎が次に手掛けるのは『[**本気の起業家育成**](/awaji)』。  
経営力と技術力の両方を兼ね備えた人材を育成し、これからの日本の変革に挑戦します。

これからは**挑戦しないことがリスクになる時代**。  
起業家として成功すべく試行錯誤する日々は確実に市場価値を高めます。

そして、起業家育成の舞台は**淡路島**。  
パソナグループが**ベンチャーアイランド**として変革を起こしているこの地で、仲間と切磋琢磨できる１年間を提供します。  
宿泊などの生活面もパソナグループが全面バックアップで、挑戦するには最も良い環境です。

▶ 詳細をチェック：[**fwywd in 淡路 | 起業家育成プログラム**](/awaji)


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

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

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

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


## はじめに

どーも、入田 / ぐるたか [@guru_taka](https://twitter.com/guru_taka) です！  
本記事では **Next.js に Tailwind CSS を導入する方法**を紹介します。また、**VS Code で Tailwind CSS での開発がしやすくなる Tips もまとめています**ので、参考にしてみてください！

### バージョン情報

- node：15.11.0
- react: 17.0.2
- react-dom: 17.0.2
- next: 11.0.1
- autoprefixer: 10.2.6
- postcss: 8.3.5
- tailwindcss: 2.2.4

## Tailwind CSS とは？

[Tailwind CSS](https://tailwindcss.com/) とは、**ユーティリティファーストの CSS フレームワーク**になります。CSS フレームワークで有名な [Bootstrap](https://getbootstrap.jp/) のように、デザインが整ったコンポーネントがあるのではなく、**デザインを整えるときに便利かつシンプルな機能を寄せ集めたイメージ**です。

Tailwind CSS で用意されたクラスをベースに、デザインを整えます。例えば `padding` を `0` にしたい場合、Tailwind CSS では、`p-0` と class 属性に代入するだけで実現可能。**スタイルファイル内のコード量も抑えられます**。

また、**パフォーマンスの最適化**もされており、2021/07/19 時点で、**ホットな CSS フレームワーク**です。fwywd チームでは、基本的に Tailwind CSS を使用して、スタイリングを行っています。

## Tailwind CSS 導入の全体像

Next.js (JavaScript) と Next.js (TypeScript) で全体像が少しだけ変わります。

- Next.js (JavaScript)
  - ① Next.js (JavaScript) + Tailwind CSS の新規プロジェクトを作成
- Next.js (TypeScript)
  - ① Next.js (TypeScript) の新規プロジェクトを作成
  - ② Tailwind CSS の導入
  - ③ 設定ファイルの作成

## Next.js (JavaScript) に Tailwind CSS を導入する方法

### 1. Next.js (JavaScript) + Tailwind CSS の新規プロジェクトを作成

Next.js (JavaScript) で開発する場合は、**以下のコマンドを実行するだけで、Tailwind CSS 搭載の新規プロジェクトが作成**できます！  
コマンドは以下の通りです。

```bash
# npm の場合
npx create-next-app next-tailwind -e with-tailwindcss

# yarn の場合
yarn create next-app next-tailwind -e with-tailwindcss
```

ディレクトリ構造は以下のようになります。

```txt
├── .gitignore
├── README.md
├── node_modules
├── package.json
├── pages
├── postcss.config.js
├── public
├── tailwind.config.js
└── yarn.lock
```

`pages/index.js` のファイルを確認してみると、すでに Tailwind CSS を用いた装飾がされています！

```jsx
// pages/index.js
...
<h1 className="text-6xl font-bold">
  Welcome to{' '}
  <a className="text-blue-600" href="https://nextjs.org">
    Next.js!
  </a>
</h1>
...
```

以下コマンドを実行しましょう。

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

# yarn の場合
yarn dev
```

下図のように、**Tailwind CSS で装飾されたページが表示されれば成功**です！

![tailwindcss-next-1](/img/pages/tech/next-tailwind/tailwindcss-next-1.png)

**Tailwind CSS の関連パッケージや設定ファイルが気になる方や既存プロジェクトに Tailwind CSS を導入したい方**は、以降で紹介する Next.js (TypeScript) における Tailwind CSS の導入方法で解説します。ぜひご覧ください！

## Next.js (TypeScript) に Tailwind CSS を導入する方法

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

まず、以下コマンドで Next.js (TypeScript) の新規プロジェクトを作成しましょう。2021/07/19 時点で、Tailwind CSS + TypeScript 搭載の Next.js の公式サンプルがないため、Next.js (TypeScript) のプロジェクトを作成し、Tailwind CSS を導入します。

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

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

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

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

### 2. Tailwind CSS の導入

Tailwind CSS を導入するため、Next.js のプロジェクトに、以下 3 つのパッケージをインストールします。

- [tailwindcss](https://github.com/tailwindlabs/tailwindcss)
- [postcss](https://github.com/postcss/postcss)
- [autoprefixer](https://github.com/postcss/autoprefixer)

上記パッケージをインストールするコマンドは以下の通りです。

```bash
# npm の場合
npm install -D tailwindcss@latest postcss@latest autoprefixer@latest

# yarn の場合
yarn add -D tailwindcss@latest postcss@latest autoprefixer@latest
```

### 3. 設定ファイルの作成

続いて、Tailwind CSS に関連する設定ファイルを作成します。まず、以下のコマンドを実行して、初期化を行います。

```bash
# npm の場合
npx tailwindcss init -p

# yarn の場合
yarn tailwindcss init -p

# 実行結果
Created Tailwind CSS config file: tailwind.config.js
Created PostCSS config file: postcss.config.js
✨  Done in 0.86s.
```

すると、以下 2 つの設定ファイルが作成されます。

- `tailwind.config.js`
- `postcss.config.js`

```jsx
// tailwind.config.js
module.exports = {
  purge: [],
  darkMode: false, // or 'media' or 'class'
  theme: {
    extend: {},
  },
  variants: {
    extend: {},
  },
  plugins: [],
};
```

```jsx
// postcss.config.js
module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  },
};
```

Tailwind CSS では、`tailwind.config.js` 内にある `purge` オプションを設定することで、**ビルド生成時の未使用のスタイルを除外し、パフォーマンスの最適化を行えます**。今回は `pages` と `components` ディレクトリ内を `purge` の対象範囲とします。変更するコードは以下の通りです。

```jsx
// tailwind.config.js
module.exports = {
  // 追記
  purge: ['./pages/**/*.{js,ts,jsx,tsx}', './components/**/*.{js,ts,jsx,tsx}'],
  darkMode: false, // or 'media' or 'class'
  theme: {
    extend: {},
  },
  variants: {
    extend: {},
  },
  plugins: [],
};
```

続いて、 JIT (just-in-time) mode を適用するために、設定ファイルを変更します。**JIT mode とは、必要に応じてスタイルを反映するモード**（厳密には、コンパイラ）で、以下のようなメリットがあります！

- **ビルド時間が非常に速い**
- **開発時のブラウザパフォーマンスが良くなる**
- **カスタマイズが容易**になる

このように JIT mode には強力な機能が搭載されているため、**適用することを強くオススメ**します。設定方法は以下の通りです。

```jsx
// tailwind.config.js
module.exports = {
  // 追記
  mode: 'jit',
  purge: ['./pages/**/*.{js,ts,jsx,tsx}', './components/**/*.{js,ts,jsx,tsx}'],
  darkMode: false, // or 'media' or 'class'
  theme: {
    extend: {},
  },
  variants: {
    extend: {},
  },
  plugins: [],
};
```

最後に、Tailwind CSS のファイルを `pages/_app.tsx` で読み込むようにし、グローバルで適用させましょう。コードは以下の通りです。

```tsx
// pages/_app.tsx
// Tailwind CSS 以外のスタイルファイルはグローバルで適用したくないため削除
// import '../styles/globals.css'
// 追記
import 'tailwindcss/tailwind.css';
import type { AppProps } from 'next/app';

function MyApp({ Component, pageProps }: AppProps) {
  return <Component {...pageProps} />;
}
export default MyApp;
```

以上で設定は完了です。実際に、動作確認をしてみましょう！

![tailwindcss-next-jit](/img/pages/tech/next-tailwind/tailwindcss-next-jit.gif)

このように開発環境において、リアルタイムに Tailwind CSS のスタイルが反映されれば成功です！

## Tailwind CSS の補完が効く VS Code の拡張機能

VS Code を使用している場合、[Tailwind CSS IntelliSense](https://marketplace.visualstudio.com/items?itemName=bradlc.vscode-tailwindcss) という拡張機能をインストールすると、**Tailwind CSS の補完**が効くようになり、開発体験が良くなります。

![tailwindcss-vscode](/img/pages/tech/next-tailwind/tailwindcss-vscode.gif)

難しい設定は不要！  
[Tailwind CSS IntelliSense](https://marketplace.visualstudio.com/items?itemName=bradlc.vscode-tailwindcss) をインストールするだけです。非常に便利なので、是非インストールしてみてください！

![tailwindcss-next-2](/img/pages/tech/next-tailwind/tailwindcss-next-2.png)

## eslint-plugin-tailwindcss を導入すると、更に便利！

Next.js (JavaScript/TypeScript) で ESLint を使用している方は、[eslint-plugin-tailwindcss](https://github.com/francoismassart/eslint-plugin-tailwindcss) を導入すると、Tailwind CSS での開発が捗ります！  
Next.js に ESLint や Prettier を導入する方法については、以下の記事をご覧ください。  
参考：[Next.js (TypeScript) に ESLint と Prettier を導入し、コードを綺麗に保とう | fwywd（フュード）](https://fwywd.com/tech/next-eslint-prettier)

上記に書かれた ESLint と Prettier の設定をしていること前提で、[eslint-plugin-tailwindcss](https://github.com/francoismassart/eslint-plugin-tailwindcss) の導入方法を紹介します。

まず、以下のコマンドを実行し、eslint-plugin-tailwindcss をインストールしましょう。

```bash
# npm の場合
npm install -D eslint-plugin-tailwindcss

# yarn の場合
yarn add -D eslint-plugin-tailwindcss
```

続いて、ESLint の設定ファイル `.eslintrc` に、以下の変更を加えます。

```json
// .eslintrc
{
  "extends": [
    "next",
    "next/core-web-vitals",
    "prettier",
    "plugin:import/recommended",
    "plugin:import/typescript",
    "plugin:import/warnings",
    // 追記
    "plugin:tailwindcss/recommended"
  ],
  // 追記
  // tailwind.config.js などの config ファイル、ESLint の対象外にする
  "ignorePatterns": ["*.config.js"],
  "rules": {
    "import/order": [
      "error",
      {
        "alphabetize": {
          "order": "asc"
        }
      }
    ]
  }
}
```

以下のように、Tailwind CSS のクラスの変数が**アルファベット順で並ぶようになります**。ぜひ導入してみてください！

![tailwindcss-eslint](/img/pages/tech/next-tailwind/tailwindcss-eslint.gif)

## 最後に

以上になります。Next.js (JavaScript/TypeScript) に Tailwind CSS の導入をしたい方の参考になれば幸いです。  
ここまでご覧いただき、ありがとうございました！

---

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

### 参考文献

- [Install Tailwind CSS with Next.js - Tailwind CSS](https://tailwindcss.com/docs/guides/nextjs)

### 【受講料無料】経営力と技術力を兼ね備えた起業家を目指そう

[![awaji](/img/home/entre.png)](/awaji)

キカガクの創業者であり、fwywd 責任者である吉崎が次に手掛けるのは『[**本気の起業家育成**](/awaji)』。  
経営力と技術力の両方を兼ね備えた人材を育成し、これからの日本の変革に挑戦します。

これからは**挑戦しないことがリスクになる時代**。  
起業家として成功すべく試行錯誤する日々は確実に市場価値を高めます。

そして、起業家育成の舞台は**淡路島**。  
パソナグループが**ベンチャーアイランド**として変革を起こしているこの地で、仲間と切磋琢磨できる１年間を提供します。  
宿泊などの生活面もパソナグループが全面バックアップで、挑戦するには最も良い環境です。

▶ 詳細をチェック：[**fwywd in 淡路 | 起業家育成プログラム**](/awaji)


Next.js (JavaScript/TypeScript) に Tailwind CSS を導入する方法をまとめています。最後に Tailwind CSS での開発が捗る Tips も紹介。参考になれば幸いです！

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

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


## はじめに

どーも、入田 / ぐるたか [@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)

### 【受講料無料】経営力と技術力を兼ね備えた起業家を目指そう

[![awaji](/img/home/entre.png)](/awaji)

キカガクの創業者であり、fwywd 責任者である吉崎が次に手掛けるのは『[**本気の起業家育成**](/awaji)』。  
経営力と技術力の両方を兼ね備えた人材を育成し、これからの日本の変革に挑戦します。

これからは**挑戦しないことがリスクになる時代**。  
起業家として成功すべく試行錯誤する日々は確実に市場価値を高めます。

そして、起業家育成の舞台は**淡路島**。  
パソナグループが**ベンチャーアイランド**として変革を起こしているこの地で、仲間と切磋琢磨できる１年間を提供します。  
宿泊などの生活面もパソナグループが全面バックアップで、挑戦するには最も良い環境です。

▶ 詳細をチェック：[**fwywd in 淡路 | 起業家育成プログラム**](/awaji)


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

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

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

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


## はじめに

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)

### 【受講料無料】経営力と技術力を兼ね備えた起業家を目指そう

[![awaji](/img/home/entre.png)](/awaji)

キカガクの創業者であり、fwywd 責任者である吉崎が次に手掛けるのは『[**本気の起業家育成**](/awaji)』。  
経営力と技術力の両方を兼ね備えた人材を育成し、これからの日本の変革に挑戦します。

これからは**挑戦しないことがリスクになる時代**。  
起業家として成功すべく試行錯誤する日々は確実に市場価値を高めます。

そして、起業家育成の舞台は**淡路島**。  
パソナグループが**ベンチャーアイランド**として変革を起こしているこの地で、仲間と切磋琢磨できる１年間を提供します。  
宿泊などの生活面もパソナグループが全面バックアップで、挑戦するには最も良い環境です。

▶ 詳細をチェック：[**fwywd in 淡路 | 起業家育成プログラム**](/awaji)


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

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


## はじめに

どーも、入田 / ぐるたか [@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)

### 【受講料無料】経営力と技術力を兼ね備えた起業家を目指そう

[![awaji](/img/home/entre.png)](/awaji)

キカガクの創業者であり、fwywd 責任者である吉崎が次に手掛けるのは『[**本気の起業家育成**](/awaji)』。  
経営力と技術力の両方を兼ね備えた人材を育成し、これからの日本の変革に挑戦します。

これからは**挑戦しないことがリスクになる時代**。  
起業家として成功すべく試行錯誤する日々は確実に市場価値を高めます。

そして、起業家育成の舞台は**淡路島**。  
パソナグループが**ベンチャーアイランド**として変革を起こしているこの地で、仲間と切磋琢磨できる１年間を提供します。  
宿泊などの生活面もパソナグループが全面バックアップで、挑戦するには最も良い環境です。

▶ 詳細をチェック：[**fwywd in 淡路 | 起業家育成プログラム**](/awaji)


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)

### 【受講料無料】経営力と技術力を兼ね備えた起業家を目指そう

[![awaji](/img/home/entre.png)](/awaji)

キカガクの創業者であり、fwywd 責任者である吉崎が次に手掛けるのは『[**本気の起業家育成**](/awaji)』。  
経営力と技術力の両方を兼ね備えた人材を育成し、これからの日本の変革に挑戦します。

これからは**挑戦しないことがリスクになる時代**。  
起業家として成功すべく試行錯誤する日々は確実に市場価値を高めます。

そして、起業家育成の舞台は**淡路島**。  
パソナグループが**ベンチャーアイランド**として変革を起こしているこの地で、仲間と切磋琢磨できる１年間を提供します。  
宿泊などの生活面もパソナグループが全面バックアップで、挑戦するには最も良い環境です。

▶ 詳細をチェック：[**fwywd in 淡路 | 起業家育成プログラム**](/awaji)


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)

### 【受講料無料】経営力と技術力を兼ね備えた起業家を目指そう

[![awaji](/img/home/entre.png)](/awaji)

キカガクの創業者であり、fwywd 責任者である吉崎が次に手掛けるのは『[**本気の起業家育成**](/awaji)』。  
経営力と技術力の両方を兼ね備えた人材を育成し、これからの日本の変革に挑戦します。

これからは**挑戦しないことがリスクになる時代**。  
起業家として成功すべく試行錯誤する日々は確実に市場価値を高めます。

そして、起業家育成の舞台は**淡路島**。  
パソナグループが**ベンチャーアイランド**として変革を起こしているこの地で、仲間と切磋琢磨できる１年間を提供します。  
宿泊などの生活面もパソナグループが全面バックアップで、挑戦するには最も良い環境です。

▶ 詳細をチェック：[**fwywd in 淡路 | 起業家育成プログラム**](/awaji)


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)

### 【受講料無料】経営力と技術力を兼ね備えた起業家を目指そう

[![awaji](/img/home/entre.png)](/awaji)

キカガクの創業者であり、fwywd 責任者である吉崎が次に手掛けるのは『[**本気の起業家育成**](/awaji)』。  
経営力と技術力の両方を兼ね備えた人材を育成し、これからの日本の変革に挑戦します。

これからは**挑戦しないことがリスクになる時代**。  
起業家として成功すべく試行錯誤する日々は確実に市場価値を高めます。

そして、起業家育成の舞台は**淡路島**。  
パソナグループが**ベンチャーアイランド**として変革を起こしているこの地で、仲間と切磋琢磨できる１年間を提供します。  
宿泊などの生活面もパソナグループが全面バックアップで、挑戦するには最も良い環境です。

▶ 詳細をチェック：[**fwywd in 淡路 | 起業家育成プログラム**](/awaji)


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)

### 【受講料無料】経営力と技術力を兼ね備えた起業家を目指そう

[![awaji](/img/home/entre.png)](/awaji)

キカガクの創業者であり、fwywd 責任者である吉崎が次に手掛けるのは『[**本気の起業家育成**](/awaji)』。  
経営力と技術力の両方を兼ね備えた人材を育成し、これからの日本の変革に挑戦します。

これからは**挑戦しないことがリスクになる時代**。  
起業家として成功すべく試行錯誤する日々は確実に市場価値を高めます。

そして、起業家育成の舞台は**淡路島**。  
パソナグループが**ベンチャーアイランド**として変革を起こしているこの地で、仲間と切磋琢磨できる１年間を提供します。  
宿泊などの生活面もパソナグループが全面バックアップで、挑戦するには最も良い環境です。

▶ 詳細をチェック：[**fwywd in 淡路 | 起業家育成プログラム**](/awaji)


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