
## はじめに

「あなたが誰であって、どんな経験をしてきて、**あなただから言えることは何でしょうか？**」

この質問に読者の皆さんは明確に応えることができるでしょうか。

もちろん、１週間前の私もそうでした。しかし、今はここができると自信を持って言うことができます。

今回は**この成長を遂げられた理由や方法**について紹介します。

### fwywd チームでのインターンシップに参加

私は fwywd １期生として起業家を目指し、仕事を辞めてこの４月から淡路へ移住しました。約２ヶ月、全力で日々を過ごしていましたが、まだ自分自身に能力が明確に足りないと感じていました。

そんな時に、fwywd のオーナーである吉崎さんから **fwywd チームのメンバーとして働くことができるインターンの募集**がありました。すでに起業家として活躍している人の直属として修行することができれば、自分自身に足りない能力を見つけることができるだろうと期待して応募しました。そして、まだインターンが始まって、１週間ですが私が**劇的に成長した**のは事実です。その裏側には何があったと思われるでしょうか。

これから「**どのようなすごいノウハウを教えてもらえるのだろう？**」と気になっている方の期待には応えられないと思います。
もちろん、私が今まで知らなかったノウハウや知っていても正しく活かせていなかった知識などたくさん得たものはありますが、今回私が得た一番大きなものは**ノウハウではありません**でした。

それにもかかわらず、なぜ劇的に成長できたのか実際に体験したことを踏まえて見ていきましょう。

### この記事で伝えたいこと

結論を言うと、「**自分のポジションをとれていない言葉や意見に価値はない**」と言うことです。

オーナーの吉崎さんから「**誰にでも言えることをあなただけの言葉で**」とこれまで何度も教えていただいていたのに、私は fwywd インターンに参加するまで本当の意味を理解できていませんでした。

### 対象読者

- 自分の言葉で伝えることが苦手
- そのビジネスを「なぜあなたがやるのか？」に応えられない
- 周りと同じ意見しか出すことができない

と悩んでいる方

## LP 制作の過程を通して学んだのはノウハウではない

### インターンシップで取り組んでいる内容

まず、インターンでやったことを簡潔にまとめると

1. fwywd 2 期募集の説明を受け、ユーザー目線で fwywd がなぜこれから必要かを雑記の量重視で自分の言葉でまとめる
2. 企画草案の作成
3. ワイヤーフレームワークでの文言レベルに整理
4. ワイヤーフレームワークの作成
5. デザイン発注

たった、この**５つだけ**です。

この項目だけ見ていると、「**Landing Page (LP) 制作はやったこともあるから、特に得られるものは無いんじゃないか？**」と思うかもしれませんが全くそんなことはありません。

fwywd のオーナーである**あの吉崎さんが何の意図もなくこのテーマに取り組ませるはずがない**のです。

一見するとただの LP 制作のタスク、ですがその裏に**劇的に成長するための設計**が隠れているのです。

実際にインターンへ参加した私なりの視点で、そのポイントを紐解いていこうと思います！

### ユーザー目線とは？

はじめに行ったのは 2 期募集の説明や fwywd が生み出していきたい人材の話、そしてその想いを聞いて 「なぜ fwywd が必要なのか？」を**ユーザー目線**で**自分の言葉**でまとめることです。

まずは**もうこれ以上出てこない**というまで、いや、さらにそこからこれまで fwywd へ参加して感じてきた価値、なぜ必要なのかをひたすら書き出し「**発散**」します。（参考 : [収束と発散](https://fwywd.com/blog/entrepreneurial-ideas)）

レビューをもらい、量も申しぶんありませんでした。

この時点で私は、**ユーザー目線の意味**を正しく理解していないことに全く気づいていませんでした。

### 「0 点です」

そして発散した言葉を「**収束**」させ、より伝えたいことを明確にし企画草案へとまとめ受けたレビューは果たして...

「**悪くないですが良くもないですね、組織への貢献という面では全く価値を生み出していないでしょう。**」

まさに、あなたが 1 日かけて作ったものは「**0 点です**」と言われたような感覚でした。  
※ もちろん、吉崎さんからはその前後でしっかりとフォローの言葉や成果に対するレビューであり、個人に対する攻撃ではないことなど丁寧にフォローしていただいていました。

私がやったこととしては、ペルソナに対して考えを廻らせ、ゴールと現状のギャップを訴求軸に fwywd が生み出したい人材とその想い、そこに自分目線での意見も加えての作成。
ユーザーである自分の目線を加えているのだから、間違っていないのではと思っていました。

### 組織へ貢献するとは

確かに、初めの企画草案は**ユーザー目線**での意見や答えがあり、それは間違いではないです。

ですが組織が求めているのは、運営やオーナーが予想できる範囲外のユーザー目線や意見であり、

「**良い意味で組織と差分が大きい考え方や視点」**

これこそが、**無かったものを生み出し組織への貢献**となります。

まだスキルも経験も無い人間が提供できる価値として、この考え方や視点は自分の事業の営業をする際にも非常に有効なものです。

## 自分の言葉で伝えるには？

このように、私は一度大失敗をしてまた 0 から企画草案をつくり直すことにしました。

ただ、その大失敗のおかげで意識や視点が劇的に変わり「**自分のポジションだからこそ生み出せる文言や視点**」で物事を捉えることができるようになりました。

具体的に何をしたのかというと、

- 対象をもう一度自分の言葉で言い直してみるとどのような表現になるのか？
- 組織から見た捉え方との差分はどこにどの程度あるのか？
- これまでの人生も踏まえ渡邉智彦という人間からの目線でしか言えないことは何か？

この 3 点を発散で書き出した全ての言葉や考えに対して行いさらに深掘りです。

この工程を、繰り返すことで２回目のレビューでは最初と同じ fwywd のことを説明しているのに全く違った企画草案となり、「**あなただからこそ言える価値を生み出す**」ことが出来ました。

そして、自分の言葉で伝える力が劇的に向上し、組織へ貢献 0 だった状態から自分にしかない価値を生み出せる存在へと成長することが出来ました。

## 終わりに

今回は私がインターンに取り組んで学んだことをまとめましたが、結局、記事を読んだり知識を得ることも大切だけれど実際に参加して**当事者となって体験しなければ劇的に成長することはできない**とも強く感じました。

また、私なりの視点で見た**成長するための設計**は fwywd が日頃から大切にしている自力で取り組んでみて失敗しながら学んでいくことなのかと思いました。

それに加え、**方向性は示すけれども自分で考える余白をしっかりと残して発破をかけるという吉崎さんの絶妙なレビュー**があることかなと思います！

そして、**まもなく fwywd 第 2 期の募集が始まります**。

私が劇的な成長を遂げたように自分も成長したいと思う方はぜひ **fwywd 第 2 期への挑戦をお待ちしています！**

### 著者について

![watanabe](/img/authors/watanabe.jpg)

名前 : 渡邉智彦

前職 : ソムリエ＆フレンチ料理人

Twitter : [@nabeo654147](https://twitter.com/nabeo654147)


「あなたが誰であって、どんな経験をしてきて、あなただから言えることは何でしょうか？」この質問に読者の皆さんは明確に応えることができるでしょうか。もちろん、１週間前の私もそうでした。しかし、今はここができると自信を持って言うことができます。今回はこの成長を遂げられた理由や方法について紹介します。

ビジネスモデル探しに迷っている人が最初にすべきこと

あなただから言えることにこそ価値がある


## 【対象外あり】注意事項

本記事で紹介する方法は **自社開発向け** です。
受諾開発などの場合、基本的な考え方は共通していると思いますが具体的な仕様書の書き方は各々独自の方法があるかと思われます。先方の指示に従ってくださいね。

## 最も伝えたい、１０秒で読める結論

ソフトウェア設計をする際は **「そもそもなぜ作らなければいけないのか？」** から考え始めましょう。仕様書に残しておくのもお忘れなく！

## そもそもなぜ「設計」する必要があるの？

プロジェクトが成功するか否かは「なぜ・何を・いつ・どうやって作るのか」を開発に関わる人全員がどれだけ解釈の齟齬なく共有できるかにかかっているためです。この中には開発チームだけでなくユーザー等の「開発知識はないけどそのプロジェクトに関わっている人」も含まれます。開発に関わる人全員が理解・共有するためにドキュメントが作成され、これがいわゆる仕様書となります。それっぽく言うと「仕様書を作ってドメイン駆動開発しましょう」となるハズです。

運用・保守面の観点から見ても仕様書のある・なしで作ったモノの寿命は大きく変わります。設計から運用・保守まで全てのフェーズにおいて仕様書の存在は欠かせません。理想論ですけれどね！

## 具体的な流れ

大きく分けて 4 段階。

1. **要求獲得（一番大事。いちばんだいじ。）**
2. 要件定義
3. 外部設計
4. 内部設計

## 1. 要求獲得

大事なことなのでもう一度。 **一番大事なフェーズです**。カジュアルに言えば「ユーザーヒアリング」具体的にはユーザーの潜在的な欲しい物をこちらが引き出すことが目的です。

なぜ大事なのでしょう？ユーザー自身が本当に必要としているモノを全て言語化できているとは限らないからです。例えばあなたは今すごく疲れていて甘いものが食べたい気分だとします。コンビニで裏面のカロリー表記を見ないようにしながらチョコと生クリームたっぷりのスイーツを買ってたらふく食べてお腹いっぱい。するとどうなるでしょう。２０分後ぐらいに血糖値の乱高下が起きてもっと眠くなる ＆ 疲れて目も開けられなくなるに違いありません。あなたに真に必要であったものは適度な休息とリポビタン D だったのでした・・・（実話）。

上記の例で言うなら要求獲得はユーザーが今欲しがっている「チョコと生クリームたっぷりのスイーツ」は **本当に必要か？なぜほしいのか？他に手段はないのか？** をユーザーと共に探っていき最終的に「本当に必要なものは適度な休息とリポビタン D なんだ！！」と着地することが目標と言えます。その過程を仕様書に残しておくのが要求獲得。

必要な内容は主に以下となります。上から順に考えていくと ◎。

- 概要（まとめ）
- 背景（要求獲得したい経緯の説明）
- 目的（要求獲得で何を「決めたい」か）
- 対象ユーザー
- 解決したい課題
- 目標（何を作るのか）
- 動機（なぜ作るのか）

### 要求獲得を怠った場合の「最悪のシナリオ」

ユーザー「本当に欲しい物って実はコレだったわ。仕様から全部直しといて^^」

文字に起こすだけでゾッとするちゃぶ台返しが発生します。それがいつ発生するかはわかりません。運が良ければ設計中の段階で気付くかもしれないし最悪の場合は実装もテストも終わったリリース直前に起きるかも。そうなれば結果は想像するだに容易いですね。納期は間近で仕様書からやり直し、プロジェクトに関わった人数分の屍の山が・・・

こうならないための要求獲得。

### 誰でも再現可能！？要求獲得をマスターできる「魔法の言葉」

ソースは弊社会長吉崎（以下敬称略）から伺った同じく弊社開発事業部 PM 丸山発のエピソード（素敵でした！）。

ユーザーの期待を超えるアウトプットができれば要求獲得は 200 点満点と言えます。それをどう実現するか？その答えはユーザーの心の中にあり、私達の心の中にはありません。

ユーザーの心の中を聞き出す魔法の言葉が「そもそも」。「そもそもなぜそう思うの？」「そもそもどうしてこのプロダクトが欲しいの？」とユーザーへ深掘りの質問をすることで誰でも再現可能な要求獲得ができるようになります。前の例で言うなら「そもそもなんでチョコと生クリームたっぷりのスイーツが欲しいの？」→「疲れてるから・・・。」→「疲れているなら疲労回復効果の高いものの方がいいね！」という流れが自然とできます。これができるエンジニアはつよつよになれること間違いなし。私もなりたい。

## 2. 要件定義

なぜそのモノが欲しいのか、何がしたいのかは要求獲得でわかりました。次に「それ、どうやって作ろうか？」を決めていくのが要件定義です。そのモノには何が含まれていて何が含まれないのか？を細かく仕様書に落とし込んでいきます。要求獲得で設定した「解決したい課題」をどう解決するか構想し共有することが目標です。

必要な仕様書の中身はざっと以下のようになるでしょう。

- 対象ユーザーの種類別に作られたペルソナ
- ユースケース図
- （ユースケース記述）※自社開発・100 人未満の開発規模であれば省略可
- 機能要件（システムの機能に関する要件）
- 非機能要件（性能、拡張性、運用・保守性、セキュリティなど）
- 開発計画書（予算の設定・SWOT 分析・コミュニケーションのルール化・コード規則のルール化・チーム内での役割の明確化・マイルストーン、アクティビティ、時間設定・倫理規定・リスクマネジメント等を含む)

## 3. 外部設計

見た目の設計。この段階で状態管理や各コンポーネントの定義も行っておくと実装がぐっと楽になります。fwywd チームではワイヤーフレーム・デザインカンプ作成に Figma を使用しています。サイトマップは mermaid-js を使用するとリアルに 3 分で完成（※ 実際はプロダクトのボリュームによって前後）します。おすすめ。

- サイトマップ
- サイトマップ文章版
- ワイヤーフレーム
- デザインカンプ

## 4. 内部設計

ロジックの設計。UML で対応できる範囲で書くと労せず完成するのでコストパフォーマンス抜群です。

mermaid-js を使用すると Markdown で記述できて大変便利です。作成コストがぐっと小さくなります。

- DB 設計＝ ER 図
- Model ・ ViewModel ・ React Hooks で扱う State = クラス図
- API を叩いたときの流れを表現する ＝ シーケンス図
- Unit ・ Integration ・ E2E テストケース

各仕様書の中で最もボリュームが多くなりますが、ここでしっかりロジックを組み立てておくと実装がめちゃくちゃ楽になります。考えも整理でき保守・運用も楽になり一石三鳥です。

## 5. 用語集

チーム内で認識のすり合わせをしておくべき用語の解説リスト。Markdown でテーブル作ってぽんぽん書いていくと非常に楽です。

## これだけは抑えておくべき重要なポイント３か条【※自社開発の場合】

※ あくまで社内で仕様書のルールを決められる場合に限ります。
受諾開発など自社開発以外の環境では先方と定めたお作法に従ってください！

### 1. レビューの粒度を予め決めておく

各段階でレビューを挟むとよりよい仕様書が生まれます。レビューの粒度を予め決めておけばより効率的に作業できること間違いなし。実際に試してみたところ**各フェーズにおいて仕様書が 20・80・100％完成した時点でレビューを行う**といい感じでした。

### 2. 「全て」仕様書に残す

採用したものはもちろん、検討したけれど採用には至らなかったものも「全て」記録して残しておくとあとあと読み返したとき非常に参考になります。採用・不採用に至った経緯や理由も書いておくとより良き仕様書に。

### 3. 仕様書を GitHub に残す

仕様書は共有されてこそ意味があります。バージョン管理や各種便利機能が利用できることを考えると GitHub に残しておくのがコストパフォーマンス最高の選択肢と言えそうです。

各項目毎にディレクトリを切って README.md を作成しその中に Markdown 方式で書いていくと書く方も読む方も非常に快適。

## おすすめ参考図書

全体像・ポイントを掴んで共に設計上手なエンジニアになっていきましょう！
最後におすすめの参考図書を紹介して〆たいと思います。

「設計にチャレンジしてみたくなってきた！もう少し全体的な流れを詳しく知りたいな」というアナタに。

[【図解】はじめての上流工程(要件定義・システム設計・プロジェクトマネジメント)入門: よくわかる！システム開発入門](https://www.amazon.co.jp/%E3%80%90%E5%9B%B3%E8%A7%A3%E3%80%91%E3%81%AF%E3%81%98%E3%82%81%E3%81%A6%E3%81%AE%E4%B8%8A%E6%B5%81%E5%B7%A5%E7%A8%8B-%E8%A6%81%E4%BB%B6%E5%AE%9A%E7%BE%A9%E3%83%BB%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E8%A8%AD%E8%A8%88-%E5%85%A5%E9%96%80-%E3%82%88%E3%81%8F%E3%82%8F%E3%81%8B%E3%82%8B%EF%BC%81%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E9%96%8B%E7%99%BA%E5%85%A5%E9%96%80-%E3%81%B2%E3%81%90%E3%81%BE-ebook/dp/B08K3ZL8FK)

こちらは UML の書き方入門。仕様書を漏れなく網羅する必要のある受諾開発にも完全対応。初めての方でも読みながら作ることができる実践的な一冊です。

[ダイアグラム別 UML 徹底活用 第 2 版](https://www.amazon.co.jp/%E3%83%80%E3%82%A4%E3%82%A2%E3%82%B0%E3%83%A9%E3%83%A0%E5%88%A5UML%E5%BE%B9%E5%BA%95%E6%B4%BB%E7%94%A8-%E7%AC%AC2%E7%89%88-%E4%BA%95%E4%B8%8A%E6%A8%B9-ebook/dp/B00G9QIN62)


自己学習では意識しづらいソフトウェア開発の設計フェーズ。どんなモノを作る？を仕様書に落とし込むまでの流れをさっくりと解説します！

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

ソフトウェア設計のい・ろ・は


## はじめに

この記事に辿り着いたという事は、あなたはビジネスを創ることに興味がある方でしょうか？起業や副業を考えているのかもしれませんね。この記事で書いた内容は「**こういった考え方をするとビジネスアイデアを考えやすい**」という 1 つのご提案です。

必ずすべての人に当てはまるわけではありません。また私自身もまだビジネスを生み出す手前にいるので、今後考えが変わるかもしれません。しかしご紹介するメソッドは起業に向けて活動を開始した人 10 人程へ 1on1 を行い、評価を頂いた内容です。

## こんな人が書いています

私は 18 年間務めた会社を辞め、起業に向けて活動を開始しました。年齢は 42 歳。組織で働くことでは得られない裁量と可能性を求めてのチャレンジです。前職は大手製造業の社員で、営業 → マーケティング → 人事を経験してきました。「安定を手放して…」というイメージの典型例です。

## この記事は次の様な人に向けて書いています

- 起業や副業をしたいけれど具体的に何を事業もするか決められない人
- 新規事業を考える為のヒントが欲しい人
- 起業家の卵の試行錯誤に興味がある人

## １，なぜビジネスモデルが見つからないのか

執筆している 2022 年 5 月現在、日本は円安や資源価格の高騰による物価高への不安が高まっています。そんな背景もあり「お金を稼ぐ」ことへの考え方が変わり、従業員として定年まで働き続ける**今までの当たり前**が変わってきています。そこで副業をしたいとか、より可能性が大きい起業に興味を示す人が増えているのだと思います。

しかしいざ**どうやってお金を稼ごうか**と考えると、これが意外に難しいのです。

- スキルが足りない
- 資金が足りない
- すでに自分より強い競合がいる
- 自分に経営なんてできるのか？

こういった不安が壁になるからです。

## ２，ビジネスモデルを探す 2 つのパターン

ではどうしたらビジネスモデルを見つけることができるのか。この答えはいくつもあると思いますが、ここでは 2 つのパターンを紹介します。ポイントは具体化と抽象化です。下から上を見上げるか、上から下を見下ろすかという**視点のコントロール**を意識しましょう。

### 具体化する

対象：目標が大きすぎて「**何ができるのか分からない**」と考えてしまう人

私達 fwywd のメンバーはそれぞれが解決したい社会課題を持っているので、まさにこんなタイプが多いですね。この思考パターンの人は大きな目標に向かって目線は遠く上方に向いている為、考えが漠然としています。その為地に足が着いたビジネスモデルを思い付かないということがあります。目標の大きさに対し、自分の実力との乖離に打ち手が見つけられないのです。

#### **山頂までのルートと考える**

このタイプの人は目標を山頂に見立てて裾野から見上げるイメージで、「どのルートで上ろうか」と考えると良いでしょう。山の裾野は広がっているので複数のルートがあるはずです。またルートは一本道ではなく、分岐や合流もよくあることです。そのことが分かれば、目指すべき山頂に繋がっているとる思えたら「**まずこのルートを登ってみよう**」となります。

ビジネスに話を戻すと、「**まずは今できる事で始めてみれば良い**」と言い換えられます。大きく稼ぐビジネスモデルである必要はありません。むしろ小さくても直ぐに収益が出せるビジネスの方が、当座の生活費を稼げて良い場合があります。大きく・高く羽ばたくのは足元を固めてからでも良いのです。

### 抽象化する

対象：スキルや経験をもとに「**これなら自分にもできそう**」と考えやすい人

1on1 を行わせて頂いた方を例に説明します。現役のエンジニアで「自分は解析や統計分析ができるけど、それでどんなビジネスができるか分からない」と悩む人がいました。この思考パターンの人は**目線が今の状況という「足元」に向いている**為、選択肢が少なくなりがちです。また自分のスキルを社内などの狭い世界で比較評価してしまう為、**世間に対してどの程度通用するのか自信が持てない**ケースもあります。

#### **高い位置から見下ろしてみる**

このタイプの人は鳥になって空から地上を見下ろすイメージで考えると良いでしょう。**組織や業界という枠を超えて考える**のです。すると「計測されたデータがあればほとんどのことは分析できるぞ！」「分析スキルは世の中で広く求められているぞ！」と気が付きます。

後は自分のスキルがより強く求められる市場を考えれば、ビジネスモデルの輪郭が浮かび上がります。この時も具体化で説明したのと同じように、いきなり大きなビジネスを考える必要はありません。小さく始めて足固めをしてから、大きなビジネスに展開すれば良いのです。

ちなみにこの例の方は 1on1 を通して「**同じサービスでもポジショニングを変えることで価値が高まる**」という発見をして頂きました。

実はすでに姿勢判断の技術と測定機材までお持ちだったのに、近所の整体に無償設置しているだけでした。またそれほど良い評価もされていないとのことでした。そこでケーススタディとして「設置先を美容系のお店に変える」ことを考えてみました。

設置先の業種を変えただけで

- 美容系のお店は情報発信に熱心なので無料で拡散して貰える
- 顧客の「綺麗になりたい」熱量が高いので使用して貰える確率が高い
- 顧客単価が高いので適正な価格評価を受けられる
- これらの実績が出れば導入店の拡大が容易

という利点が考えられました。

## ３，大きなビジネスから始めることは大きなリスクを抱えるということ

そうはいってもできれば大きく稼ぎたいという気持ちはありますよね？ しかし現実的に**大きく稼ぐビジネスには大きな投資が必要**という問題が立ち塞がります。たとえばさきほどの分析スキルの例を考えてみます。

小さな案件を請け負うのであれば、一人で行えるか数名のサポートが必要になるくらいで対応可能でしょう。 しかしこれが自社プロダクト開発を行うとか大手から受注する為には、組織的な対応が必要です。 保守まで考えれば長期で人材確保しなければならないので、もはや個人のポケットマネーでは厳しい金額です。 そう言った事情もあり、最初のビジネスからホームランを狙うような大きなビジネスを考えても実行が難しいのです。

### 融資は借金

融資を獲得してビジネスを始めるという手段もありますが、これはリスクが大きい選択肢です。 なぜなら融資は必ず返済しなければいけないお金、つまり借金だからです。

しかも融資が受けられるのは事業が立ち上がる前に多額の出費を必要なケースが多いので、売り上げが伸びる前に多くの資金が手元からなくなります（ここでは資金調達に関する説明は割愛します）。 もし計画通りに収益が出ないと、仮に事業を畳んだとしてもあなた個人に借金が残ってしまうのでリスクが高いのです。

## ４，儲かるより喜ばれるか

以上の考えで最初に始めるべきビジネスでは、**生活を安定させることや活動資金が底をつく迄の期限を延ばすことが当座の目標**になります。その規模であれば、初期は口コミや少々の広告費用で獲得できるくらいの顧客数で十分です。そうなるといかに儲かるかではなく、**いかに喜んでもらえるかが重要**になります。顧客本人が気に入るだけでなく、**他人にも紹介したくなる**というのが狙うべき品質基準になります。

簡単に考えつかない時もありますが、「こんなサービスがあったら喜んでもらえるだろうな」と考えを巡らしましょう。そしてそのアイデアを口に出して、他も人から意見をもらいましょう。自分がどれだけ良いと思っても、評価されなければビジネスとしては成り立たないのです。

## 最後に

ここまで読んで頂きありがとうございました。ビジネスモデル探しで迷っているときに、この記事が少しでもモヤモヤから抜け出すヒントになれば幸いです。また「考え方は分かったけど自分一人では上手くできない」という方がおられれば、私がお手伝いをさせて頂きます。お気軽にご連絡ください！

## 書いた人

浅井健一郎

思考のカオスを解きほぐすカウンセリングと、実行アクションの洗い出しが得意です。モヤモヤと悩んでいる方にビジネスモデルを生み出すまでの伴走を行っていますので、お気軽にご連絡ください！

[Twitter : @kenchiro0406](https://twitter.com/kenchiro0406)


この記事に辿り着いたという事は、あなたはビジネスを創ることに興味がある方でしょうか？起業や副業を考えているのかもしれませんね。この記事で書いた内容は「こういった考え方をするとビジネスアイデアを考えやすい」という 1 つのご提案です。 必ずすべての人に当てはまるわけではありません。また私自身もまだビジネスを生み出す手前にいるので、今後考えが変わるかもしれません。しかしご紹介するメソッドは起業に向けて活動を開始した人 10 人程へ 1on1 を行い、評価を頂いた内容です。

あなただから言えることにこそ価値がある 〜インターン体験記〜

親でも職場でもなく自分が最大のドリームキラーだった話アドバイス


## はじめに

みなさんは自分の夢を阻害するドリームキラーに遭遇したことはありますか？例えば「プロ野球選手になりたい」、「有名なユーチューバーになりたい」と夢を語ると頭ごなしに否定してくる親や職場の人がそれにあたります。しかし私の場合は親でも職場でもなく自分が最大のドリームキラーでした。この記事は「ドリームキラーと化していた自身に気づき、考え方を改めることで夢や目標を見つけた経験をお話しします！

## 本心に気づかないふりをした 10 年

私は産業機械の設計を約 10 年勤めてきました。良い設計者を目指して設計のノウハウや部署間のスケジューリングなど多くを学んできました。そしておおよその業務がこなせるようになり、チームのマネジメント業が増え始めてきた頃です。そんな時期に **「この職業が果たして本当にやりたいことなのだろうか？」** ということを考えるようになったのです。それは会社の製品について熱く語る同僚を見ていると、自分が将来この会社でこんな機械をつくりたい！という夢や目標がないことを改めて実感したからです。実は薄々そんな自分の気持ちに気づいていましたが、学ぶべきことが多くあったので盲目的に突き進み、気づかないふりをしていたのだと思います。これからの人生において多くの時間を仕事に捧げて過ごすことを考えると、こんな自分がこの会社に勤め続けるのは自分と会社双方にとってもったいないことだと思うようになりました。そこでなぜ自分が将来の夢や目標を持てない職業に就いてしまったのか、これまでの軌跡を振り返ってみることにしました。

## 数字を比較して決めてきた人生

高校生までは将来の選択肢を広げることを目的として、センター試験（共通テスト）で良い点数をとるためにと全ての教科に注力してきました。大学への進路選択ではものづくりに興味があり理系に向いていると感じていたので機械系の学科で探しました。最終的にセンター試験で獲得した点数から合格が狙える大学を偏差値で比較して決めました。会社への就業選択では大学で就職実績のある会社の中から企業規模や収入、安定性などを比較して決めました。このようにこれまでの進路選択は数値化された情報を比較してより良いものを求めてきました。**夢や目標ではなく数字で判断する自分自身がドリームキラー**だと気づきました。

## 行動すれば変化する

本当に自分のやりたいことを探すために自分が興味を持ったものを思い返してみました。機械設計は物理学を主体とした職種ですが、実は物理よりも数学の方が得意だったことを思い出しました。数学は一つの問題を 1 日中考え続けても苦にならないぐらい没頭していました。その数学を主体として世の中のトレンドや将来性を加味した職業を考えたところ、機械学習に関する職業に興味を持ち勉強し始めました。そうすると **勉強を始めたことで変化が生まれました。** それは勉強し始めた機械学習の教材を提供している株式会社キカガク会長の吉崎さんとパソナグループさんが運営する **[fwywd in 淡路](https://fwywd.com/awaji)** というプロジェクトとの出会いです。このプロジェクトは淡路島で起業という同じ志を持った仲間と１年間一緒に取り組むというものです。率直に魅力的なプロジェクトだと思いましたが、参加するにはビジネスプランを掲げて **自分が何をしたいか** を考える必要がありました。このテーマを考える過程で、今自分が勉強している機械学習は手段であり、何がしたいのかという部分が欠落していることに気づかされました。
今度は自分のこれまでの経験から改善したいことを振り返りました。そこで頭をよぎったのが、友人に結婚祝いを贈った時のことです。絶対に喜んでもらえると自信があった贈り物でしたが、友人は既にそれよりも良い物を持っていたのです。もっと考えればよかったととても後悔しました。この苦い経験を思い出すことで私に夢ができました！それは **「贈り物のミスマッチをなくす」** ということです。相手の欲しいものがわかれば送り手は「喜んでくれるかな？」という不安な気持ちが解消されますし、貰い手は必要なものが手に入るので双方にとって有益なものになります。このアイデアを軸にこれからサービスを構築していきます。

## 最後に

私は明確な将来の夢や目標がなかったために数字で選択する人生を歩んできました。もし夢や目標を学生の間に見つけることができれば後悔や後戻りのない人生だったかもしれません。ただ、社会に出てから学ぶことはたくさんあり、そこでの人との出会いや結婚、子育てなどを通して価値観や考え方が変わったところもあります。大切なのは自分の気持ちに素直に向き合い、違和感があるのであれば解消するために行動することだと思います。そして**数字ではなくやりたいことで決めること**です。起業という選択が全ての人における正解ではありませんが、もし自分が起業するなら？というスケールで考えてみると本当の自分の夢や目標が見えてくるかもしれません。実現したいというアイデアが見つかった際は、fywyd への参加を検討されてみてはいかかでしょうか？fwywd の雰囲気など知りたいと言う方は下記 Twitter をフォローして頂ければと思います。
また、私が取り組んでいる「贈り物のミスマッチをなくす」サービスに興味を持って頂けた方も是非フォローしてもらえたらうれしいです！最後まで読んで頂きありがとうございました。

## 著者

廣岡　秀一 (Twitter:[@shuichi_gif](https://twitter.com/shuichi_gif)) <br>
相手がどんな物を欲しいか情報提供することで **「贈り物のミスマッチをなくす」** サービスを開発中。友人の結婚のお祝いを贈る際、相手が喜びそうな品を考え贈るも既に持っているものだったという苦い経験をする。一方で自身も複数の人から同じような贈り物を貰い、使いきれなかった経験から贈り手の不安や貰い手の悩みを解決したいと考える。


みなさんは自分の夢を阻害するドリームキラーに遭遇したことはありますか？例えば「プロ野球選手になりたい」、「有名なユーチューバーになりたい」と夢を語ると頭ごなしに否定してくる親や職場の人がそれにあたります。しかし私の場合は親でも職場でもなく自分が最大のドリームキラーでした。この記事は「ドリームキラーと化していた自身に気づき、考え方を改めることで夢や目標を見つけた経験をお話しします！

プログラミング学習で絶対にオススメしたい、たった１つのこと

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 における環境変数の基本的な設定方法をまとめまています。`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) の基本的な設定方法


## はじめに

どーも、入田 / ぐるたか [@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 を導入し、コードを綺麗に保とう


## はじめに

### 概要

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

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

### Git Flow とは？

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

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

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

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

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

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

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

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

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

## 手順の解説

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## おわりに

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

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

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

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


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

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

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

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


## はじめに

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 を生成しよう


## はじめに

[**fwywd（フュード）**](/) でもバックエンドとして利用している **Microsoft Azure** に用意されている**認証・認可機能**などを兼ね備えた **Azure Acitve Directory B2C (AADB2C)** がめちゃくちゃ良いのです。その一方で、まだ情報が少ないからか使われていない印象を受けます。初期設定に関する情報が少ないだけでなく、実際に React や Next.js での実装にまで踏み込んでいる記事となるとほとんどありません。

そこで、今回はそんな非常に使いやすい **AADB2C** をみなさまに使っていただけるように、ログインの認証機能をバッチリと使っていただけるところまで紹介していきます。この記事を読んでいただいた後に、なんで今まで自前で認証や認可を実装していたのだろうと後悔間違いなしです。

## 前提

今回は以下の前提の方にピッタリの記事となるように書いています。

- React & Next.js (TypeScript) を触ったことがある
- Azure のアカウントを持っている
- Azure Active Directory B2C のリソースを作成している（[参考記事](/tech/aadb2c-auth)）

参考になる記事を３つ紹介します。

### IDaaS の導入

Web アプリケーションフレームワークに標準で搭載されている**認証・認可**の機能を **IDaaS** として提供されている外部サービスを利用する理由を紹介しています。

▶ 関連記事：[IDaaS がこれからは必須！認証・認可は Azure Active Directory B2C (AADB2C) がおすすめ](/tech/why-adopt-idaas)

### AADB2C の導入

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

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

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

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

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

## AADB2C の設定手順

すでに前提として紹介したとおり、AADB2C のリソース作成に関して初めての方は、[Azure Active Directory B2C でユーザー認証を超簡単に実装しよう](/tech/aadb2c-auth) で手順を詳細に紹介しておりますので、まずはこちらから始めてください。

### 認証情報の設定

今回は React & Next.js で組んでいき、主に認証は**クライアントサイド**で行います。**サーバーサイド**での処理ではない点に注意が必要です。AADB2C を利用する際の最も大きな落とし穴が、どこで処理をするかわかっていないことです。

登録したアプリケーションからサイドバーにある**認証**を開き、プラットフォームとして**シングルページアプリケーション**を追加してください。注意として、**Web** もそれらしい名前がついているのですが、これは**サーバーサイド**での場合の認証であり、**クライアントサイド**での認証では動きません。ここの設定を忘れるとうまく動作しない理由が全くわからずに、永遠にさまようことになるので注意してください...。

![04](/img/pages/tech/nextjs-azure-ad-b2c/04.png)

![05](/img/pages/tech/nextjs-azure-ad-b2c/05.png)

![06](/img/pages/tech/nextjs-azure-ad-b2c/06.png)

![07](/img/pages/tech/nextjs-azure-ad-b2c/07.png)

![08](/img/pages/tech/nextjs-azure-ad-b2c/08.png)

### ユーザーフローの作成

ユーザーフローに関しては[前回の記事](/tech/aadb2c-auth)で紹介していました。

前回は新規登録とログインができるようになっていましたが、今回は違う知見もつけるために、**ログインのみのユーザーフロー**を作ってみましょう。アプリケーション側からは新規登録できず、**Azure のポータル画面からユーザーを登録するような管理方法**ですね。社員がブログを操作するときなど**限られた人間のみの登録を受け付ける場合には有効なユーザーフロー**です。

![09](/img/pages/tech/nextjs-azure-ad-b2c/09.png)

![10](/img/pages/tech/nextjs-azure-ad-b2c/10.png)

![11](/img/pages/tech/nextjs-azure-ad-b2c/11.png)

今回はログイン後にユーザーの情報として、メールアドレスも渡されるように、**要求を返す**にメールアドレスも追加します。

![12](/img/pages/tech/nextjs-azure-ad-b2c/12.png)

![13](/img/pages/tech/nextjs-azure-ad-b2c/13.png)

これで準備完了です。基本的に **GUI** だけで操作できるので本当に簡単ですよね。

### ユーザーの作成

ログインができるユーザーを Azure のポータル画面から設定しましょう。ブログの編集ができる社員を登録するようなイメージですね。こちらも当然、簡単です。

![14](/img/pages/tech/nextjs-azure-ad-b2c/14.png)

![15](/img/pages/tech/nextjs-azure-ad-b2c/15.png)

![16](/img/pages/tech/nextjs-azure-ad-b2c/16.png)

![17](/img/pages/tech/nextjs-azure-ad-b2c/17.png)

これでユーザーが追加されていれば OK です。

Azure 側での設定は以上です。簡単すぎます！

## Next.js のプロジェクト準備

次はログインを行うアプリケーション側を進めていきましょう。

### バージョン情報

- Node.js：16.13.1
- React：17.0.2
- Next.js：12.0.7
- @azure
  - msal-react：1.1.2
  - msal-browser：2.20.0

### プロジェクト新規作成

今回は多くの方に再現しやすいように Next.js のプロジェクトを新規で作成するところから紹介します。基本的に `yarn` を用いますが、`npm` でももちろんできますので、必要に応じて読み替えていただけると助かります。

```bash
# プロジェクト nextjs-aadb2c の作成（TypeScript）
yarn create next-app --typescript nextjs-aadb2c
```

これで Next.js のプロジェクトが用意できたため、ディレクトリを移り、サーバーを立ち上げて動作を確認しましょう。

```bash
cd nextjs-aadb2c
yarn dev
```

![01](/img/pages/tech/nextjs-azure-ad-b2c/01.png)

これで最初の準備が完了です。

### src ディレクトリの作成

Next.js では初期に `pages` がルートにありますが、この後の編集では `lib` なども作っていきたいので、`src` ディレクトリを作成します。`src` の中に `pages`, `styles` を格納し、`lib` ディレクトリもその中に作っておくと良いでしょう。

### ルートページのリセット

この後のログインの機能がわかりやすくなるように、ルートでアクセスする画面に必要な文字は削除しておきます。

```typescript
// src/pages/index.tsx
import type { NextPage } from 'next';

const Home: NextPage = () => {
  return <h1>React & Next.js と AADB2C の連携</h1>;
};

export default Home;
```

![02](/img/pages/tech/nextjs-azure-ad-b2c/02.png)

さて、ここから始めていきましょう。

### MSAL の導入

Azure を利用した IDaaS の良い点は、**クライアントサイド側の認証に必要なライブラリが用意されている**ことです。Next-Auth といった外部製のライブラリを使用することもできますが、これが非常に厄介な上に情報が少ないのです。

今回は Microsoft 製でセキュリティ対策もバッチリな **Microsoft Authentication Library (MSAL)** を利用して実装を進めます。MSAL は JavaScript 向けにもありますが、さらに **React に特化したバージョンもある**ため、**Next.js など React 製のアプリケーションでは開発者体験が最高です**。

[**msal-react**](https://www.npmjs.com/package/@azure/msal-react) の情報は現状で少なく、[こちら](https://www.npmjs.com/package/@azure/msal-react) のパッケージ配布用に書かれている簡単な導入と、[GitHub で公開されている導入記事](https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-react/docs/getting-started.md) を見ながら進めました。ただ、結構設定周りで苦労したので、今回の記事は他の方にとってかなり重宝するのでは無いかと思っています。

```bash
# msal-react のインストール
yarn add @azure/msal-react @azure/msal-browser
```

これでインストール完了です。ここまでは特に問題ないと思います。

### Config 　の設定

今回作成した AADB2C やユーザーフローの情報を記載します。基本的には以下の内容を編集していただければ OK です。

クライアント ID は Azure のポータル画面から確認できます。

![18](/img/pages/tech/nextjs-azure-ad-b2c/18.png)

![19](/img/pages/tech/nextjs-azure-ad-b2c/19.png)

`authority` で登場する `kikagakuapps` は私が AADB2C で登録した名前です。`b2c_1_signin` はユーザーフローで作成した名前でしたね。これらを合わせて設定してみましょう。詳細な情報に困ったときは、以下のようにユーザーフローで定義されているページを見に行くと、情報のヒントがあるはずです。

![20](/img/pages/tech/nextjs-azure-ad-b2c/20.png)

```typescript
// src/lib/auth/config.ts
import { Configuration } from '@azure/msal-browser';

export const msalConfig: Configuration = {
  auth: {
    clientId: '34d76626-.............',
    authority: 'https://kikagakuapps.b2clogin.com/kikagakuapps.onmicrosoft.com/b2c_1_signin',
    knownAuthorities: ['kikagakuapps.b2clogin.com'],
    redirectUri: '/',
    postLogoutRedirectUri: '/',
  },
  cache: {
    cacheLocation: 'localStorage',
  },
};

export const loginRequest = {
  scopes: ['openid', 'offline_access'],
};
```

ここで、注意点として `cacheLocation` を `localStorage` に設定しています。デフォルトでは `sessionStorage` です。違いはブラウザを閉じたときに記憶している (localStorage) か否 (sessionStorage) かだと考えるとわかりやすいと思います。セキュリティ的には、情報を短く持つ `sessionStorage` が推奨されています。この辺りは、ユーザー体験とバランスを取ると良いでしょう。

### Provider の設定

Recoil や Chakra UI でおなじみの **Provider** の設定です。先述した設定を反映するように、以下のように `MsalProvide` を追加しましょう。

```typescript
// src/pages/_app.tsx
import { PublicClientApplication } from '@azure/msal-browser';
import { MsalProvider } from '@azure/msal-react';
import { msalConfig } from '../lib/auth/config';
import '../styles/globals.css';
import type { AppProps } from 'next/app';

function MyApp({ Component, pageProps }: AppProps) {
  const pca = new PublicClientApplication(msalConfig);

  return (
    <MsalProvider instance={pca}>
      <Component {...pageProps} />
    </MsalProvider>
  );
}

export default MyApp;
```

これで準備完了です。

### ログインボタンの設定

それでは、AADB2C にログインさせるボタンを配置しましょう。話をシンプルにするために特にスタイリングは行っていません。

```typescript
// src/components/SigninBtn.tsx
import { useMsal } from '@azure/msal-react';
import { loginRequest } from '../lib/auth/config';

export default function SigninBtn(): JSX.Element {
  const { instance } = useMsal();
  return (
    <div>
      <button onClick={() => instance.loginRedirect(loginRequest)}>ログイン</button>
    </div>
  );
}
```

```typescript
// src/pages/index.tsx
import type { NextPage } from 'next';
import SigninBtn from '../components/SigninBtn';

const Home: NextPage = () => {
  return (
    <>
      <h1>React & Next.js と AADB2C の連携</h1>
      <SigninBtn />
    </>
  );
};

export default Home;
```

以下のように、ログイン用のボタンを押して、AADB2C でのログイン画面に遷移すれば成功です。msal-react があることで、神がかって実装を楽にしてくれました。

![21](/img/pages/tech/nextjs-azure-ad-b2c/21.png)

![22](/img/pages/tech/nextjs-azure-ad-b2c/22.png)

### ユーザーの状態を取得

ログインが完了しても見た目は特に変わりませんが、実はブラウザ上のローカルストレージにしっかりとプロフィール情報を含んだトークンのがしっかりと保存されています。Google Chrome の場合、開発者ツールで確認することができます。

![23](/img/pages/tech/nextjs-azure-ad-b2c/23.png)

このトークンから情報を読み込む方法も react-msal では当然サポートされています（当たり前ですが神！）。以下のように、`useCurrentUser` という Hook を作っておくと、色々なページから利用できて便利です。

```typescript
// src/hooks/useCurrentUser.ts
import { AccountInfo } from '@azure/msal-browser';
import { useMsal } from '@azure/msal-react';

interface Account extends AccountInfo {
  idTokenClaims: {
    aud: string;
    auth_time: number;
    family_name: string;
    given_name: string;
    emails: string[];
    iss: string;
    nbf: number;
    nonce: string;
    sub: string;
    tfp: string;
    ver: string;
  };
}

export interface User {
  sub: string;
  familyName: string;
  givenName: string;
  email: string;
}

const useCurrentUser = (): User | null | undefined => {
  const { accounts } = useMsal();
  if (accounts.length > 0) {
    const account = accounts[0] as Account;
    const user: User = {
      sub: account.idTokenClaims?.sub,
      familyName: account.idTokenClaims?.family_name,
      givenName: account.idTokenClaims?.given_name,
      email: account.idTokenClaims?.emails[0],
    };
    return user;
  }
  return null;
};

export default useCurrentUser;
```

この `useCurrentUser` を利用して、まずはターミナルで取得したユーザー情報を表示してみましょう。

```typescript
// src/pages/index.tsx
import type { NextPage } from 'next';
import SigninBtn from '../components/SigninBtn';
import useCurrentUser from '../hooks/useCurrentUser';

const Home: NextPage = () => {
  const user = useCurrentUser();
  console.log(user);
  return (
    <>
      <h1>React & Next.js と AADB2C の連携</h1>
      <SigninBtn />
    </>
  );
};

export default Home;
```

![24](/img/pages/tech/nextjs-azure-ad-b2c/24.png)

めっちゃ簡単にユーザー情報にアクセスできて感動的です！

### ログイン時にユーザー情報を表示

それでは取得したユーザー情報を文字として表示するように設定していきましょう。ここで、ログイン時にはユーザー情報が存在して表示しても良いですが、ログインしていない状況では表示しない**情報の出し分け**が必要となります。これを実装するのは意外と面倒なのです（情報が一時的に表示されるチラツキを抑えるなど）。

この点も msal-react はもちろん対応しています。ログイン時の情報は `AuthenticatedTemplate` のブロック内に、非ログイン時の情報は `UnauthenticatedTemplate` に記載するだけと超簡単です。

```typescript
// src/pages/index.tsx
import type { NextPage } from 'next';
import { AuthenticatedTemplate, UnauthenticatedTemplate } from '@azure/msal-react';
import SigninBtn from '../components/SigninBtn';
import useCurrentUser from '../hooks/useCurrentUser';

const Home: NextPage = () => {
  const user = useCurrentUser();
  return (
    <>
      <h1>React & Next.js と AADB2C の連携</h1>

      <UnauthenticatedTemplate>
        <SigninBtn />
      </UnauthenticatedTemplate>

      <AuthenticatedTemplate>
        <p>
          こんにちは、{user?.familyName} {user?.givenName} さん
        </p>
        <p>メールアドレス：{user?.email}</p>
      </AuthenticatedTemplate>
    </>
  );
};

export default Home;
```

![25](/img/pages/tech/nextjs-azure-ad-b2c/25.png)

これも超簡単です！最高！

### ログアウトボタン

最後はログアウトのボタンを作れば完成です。こちらもログインのボタンとほぼ同じです。

```typescript
// src/components/SignoutBtn.tsx
import { useMsal } from '@azure/msal-react';

export default function SigninBtn(): JSX.Element {
  const { instance } = useMsal();
  return (
    <div>
      <button onClick={() => instance.logout()}>ログアウト</button>
    </div>
  );
}
```

```typescript
// src/pages/index.tsx
import type { NextPage } from 'next';
import { AuthenticatedTemplate, UnauthenticatedTemplate } from '@azure/msal-react';
import SigninBtn from '../components/SigninBtn';
import SignoutBtn from '../components/SignoutBtn';
import useCurrentUser from '../hooks/useCurrentUser';

const Home: NextPage = () => {
  const user = useCurrentUser();
  return (
    <>
      <h1>React & Next.js と AADB2C の連携</h1>

      <UnauthenticatedTemplate>
        <SigninBtn />
      </UnauthenticatedTemplate>

      <AuthenticatedTemplate>
        <p>
          こんにちは、{user?.familyName} {user?.givenName} さん
        </p>
        <p>メールアドレス：{user?.email}</p>
        <SignoutBtn />
      </AuthenticatedTemplate>
    </>
  );
};

export default Home;
```

これでログアウトしてみると、以下のように `UnauthenticatedTemplate` のブロック内で書かれたログインボタンのみが表示されると成功です。

![26](/img/pages/tech/nextjs-azure-ad-b2c/26.png)

![27](/img/pages/tech/nextjs-azure-ad-b2c/27.png)

これで認証に必要な一連の機能をすべて紹介できました！

AADB2C と msal-react の組み合わせの開発者体験は最高です！！

## おわりに

認証という機能を作るためには、セキュリティなど非機能要件も含めた考慮が必要となりますが、AADB2C を利用することで、この点の問題を実装コスト 0 でクリアすることができています。また、クライアント側での実装も msal-react を利用することで、めちゃくちゃ簡単に実装を進められます。

今回の記事で IDaaS は難しいんじゃない？と疑問に思われえていた方も見方が変わっていれば嬉しいです。ぜひ、みなさん AADB2C を使った認証を利用することで、より本質的な独自性のある機能の開発に時間を割いていきましょう！

### 著者

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


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

IDaaS がこれからは必須！認証・認可は 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)


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