本書『[プロダクトマネジメント](https://amzn.to/3oxqmtc)』では、プロダクト開発における**ビルドトラップ**について定義し、この罠を避けるための方法についてストーリーで書かれています。ビルドトラップとは、本書では次のように定義されています。

> 実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状況

つまり、簡単にいうと『**顧客にフォーカスせず、機能を追加することで前に進んでいると思い込んでしまっている状況**』ですね。このような状況に陥らず、顧客に価値を届けることでプロダクトを成功に導く方法について、ストーリー形式で書かれているのが本書となります。

本書の内容は、著者がビルドトラップにハマってしまったときにリーンスタートアップに出会い、実践してきたことがもとに書かれています。

## 対象となる読者
本書『[プロダクトマネジメント](https://amzn.to/3oxqmtc)』は、複数のチームで動いている組織の中でプロダクトマネージャをされている方、経営メンバーにとってとても役立つ本だと思います。あるいはそこをめざしている方にとっても勉強になると思います。

プロダクトマネジメントに直接関わらない方、たとえばエンジニアの方でも、チームをよりよくする上で参考になります。一方で、個人開発者の方や数人規模のスタートアップでプロダクトをつくっている方にとっては、すこし現実とかけ離れているかもしれません。

## なぜこの本を読むべきか
組織が大きくなるとビルドトラップ、つまり顧客のことを忘れてつくることに集中してしまいがちです。顧客にフォーカスしないと、いくらつくってもプロダクトはよくなりません。

本書『[プロダクトマネジメント](https://amzn.to/3oxqmtc)』は、顧客にフォーカスしてプロダクトをよくした結果、会社自体を成長させることを目的としています。そこにいたるまでにどんな課題が起こるのか、どう解決するのか。マーケットリーという架空のプロダクトを例に話が進みます。

この本を一度目をとおした上で、実務で似たような課題に当たったときに見直すと、解決の糸口が見つかるかもしれません。

## 本書の内容
本書『[プロダクトマネジメント](https://amzn.to/3oxqmtc)』は、次のような構成で話が進みます。

1. ビルドトラップとはなにか、陥りやすいのはどういうケースか
2. プロダクトマネージャとはなにか、どういう役割か
3. プロダクトにおける戦略とはなにか
4. プロダクトマネジメントのプロセスとはどういうものか
5. プロダクト主導組織とはどういうものか

このような構成で、プロダクトを成功するためにプロダクトマネジメントの観点でどういうことをすべきかが書かれています。

本書は実践書ではないので、本にしたがって行動することでなにかを改善できる、というものではありません。本書にあるストーリーと自分が直面する課題を照らして解決策を見つける、そういう使い方ができる本だと思います。

本書の中で私が印象に残ったものとして、『プロダクトの死のサイクル』というものがあります。これは

> 顧客に足りないものを聞く→足りない機能をつくる→誰もプロダクトを使わない

というアンチパターンのことで、大きい組織ほど起こりがちな問題です。私も過去に何度も経験しました。

本書を読みながら過去をふりかえり、あのときああすればよかったな、次からこうしよう、というような気づきを得ることができました。

## まとめ
多くの組織が、価値ではなくつくるという行為そのものに意味を持たせてしまっています。本当にやるべきことはなんなのか、プロダクト開発における課題と解決策がストーリーベースでわかります。

本書『[プロダクトマネジメント](https://amzn.to/3oxqmtc)』は複数のチームで開発に携わる方、あるいはそこをめざす方にとって有益な本だと思います。

顧客に価値を届けるプロダクトをつくるための本。とくに大きな組織で開発に携わる方に役立つ本です。

プロダクトマネジメント ――ビルドトラップを避け顧客に価値を届ける

私はプロダクトマネジメントやWebサービス開発に関する本はとにかく読むようにしています（おすすめの本などありましたらぜひ教えてください！）。今回は本書「[ゼロから始めるプロダクトマネジメント](https://amzn.to/3biKTvH)」を読んでみました。ひとことでいうとプロダクトマネジメントの基本をわかりやすいストーリー、読みやすい文体で読める、プロダクトマネジメントの『超』入門書です。

本書の参考文献にもある[アントレプレナーの教科書](https://amzn.to/3gLplsL)や[リーン・スタートアップ](https://amzn.to/3lBdfpT)はとてもいい本ですが初学者にはわかりづらいところがあり、また実践向けに体系化されたものでもありません。[RUNNING LEAN](https://amzn.to/3lFRllx)はこれを解決した実践書ですが、本書はさらに読みやすく、プロダクトマネジメント全体を俯瞰することができます。

本書を読んだあとで、上記書籍を読むとより理解しやすいと思います。

<br />

本書の対象は、これからプロダクトマネジメントをはじめる方、プロダクトマネジメントとはなにをする人かがわからない方になると思います。こういった方が本書を読むことで、プロダクトマネージャがどういうことをする人か、プロダクトをつくるプロセス全体などを俯瞰できます。

<br />

主人公が中学生ということもありますが、ストーリーがわかりやすく、文章がとても読みやすいです。ページ数も多すぎないので、はやい方であれば1時間で読み終えられます。私が中学生、高校生のときに読んでも十分理解できる内容だな、と思います。内容が薄いかというとまったくそういうことはなく、ストーリーをとおしてプロダクトマネジメントの本質を十分理解できます。

もし将来私のこどもが開発に興味をもったら、ぜひ本書を薦めたいと思いました。開発だけでなく、たとえばカフェや旅館など「なにかをはじめる」ときにはプロダクトマネジメント全般の知識が大いに役立ちます。なにかをはじめるときに読んでもらいたい、読む障壁の低い本です。

<br />

本書の内容はアプリ開発という題材です。アプリが解決を目指す課題とその解決策を、仮説立案やユーザインタビューをとおして検証していきます。検証できる必要最低限の機能をつくり、KPIを計測し、LTV>CACをめざします。つまりアプリ開発の基本パターンであるCustomer-Problem Fit→Problem-Solution Fitを経てProduct-Market Fitをめざす流れをストーリーとして読めます。また、体系的な知見も整理されています。

<br />

感想としては、わかりやすくも実践的な内容が書かれているところに読みごたえがありました。たとえばHookモデルというフレームワークがあります。外的要因でアプリを起動し、なんらかの行動をし報酬を得て、次の内的要因による起動につながる行動をする。次は外的要因がなくともアプリを起動する、という循環モデルで、こういった概念をストーリーベースでわかりやすく理解することができます。

ほかにもバリュー・プロポジションやAIDA、AARRRといったフレームワークについて学ぶことができます。

<br />

本書はプロダクトマネジメントをはじめるときに読むと、全体を俯瞰できてとてもよいと思います。読むに際し、特別な知識は必要ありません。ぜひ、開発に関わるすべての方に読んでほしい本だと思いました。

このような良書をご執筆いただき、著者の方に感謝いたします。

わかりやすいストーリーとやさしい文体で学べる、プロダクトマネジメント学習の最初の一冊におすすめの本です。

ゼロから始めるプロダクトマネジメント

それでは、さっそく技術ブログ収益化入門の内容に入りましょう。まずは技術ブログを作る上で知っておくべきこと、決めておくべきことを3つのステップで見ていきます。

はじめに、よくいわれる『技術ブログは儲からないのか？』という問題について、技術ブログと収益の関係から見ていきます。次に収益を作る広告のしくみについて簡単に学び、最後に技術ブログを運営する目的を決めます。

まずはお金との関係について見ていきましょう。

この章ではよくいわれる『技術ブログは儲からないのか？』という問題について、技術ブログと収益の関係から見ていきます。次に収益を作る広告のしくみについて簡単に学び、最後に技術ブログを運営する目的を決めます。

技術ブログを作る準備をしよう

前の章で、技術ブログの収益化について知っておくべきことを学びました。次は技術ブログを作っていきましょう。すでに技術ブログを持っている方も、流し読んでいただければと思います。

はじめに技術ブログをどう作るかを決めます。次にサーバを契約し、ドメインを取得していきます。このときあわせて技術ブログの構築も行います。

それでは、まず技術ブログの作り方から決めていきましょう。

この章では収益化を行うための技術ブログを作っていきます。まずどうやって作るかを決め、サーバとドメインを契約します。あわせて技術ブログの構築も行います。

技術ブログを作ろう

前の章で技術ブログを作りました。次は、いよいよ技術ブログを収益化していきましょう。

技術ブログを収益化するには、まずASPと呼ばれるサービスに登録します。登録したら、技術ブログに掲載したい広告を選びます。選んだ広告についての記事を書いて、技術ブログ内から記事にリンクを貼ります。

この流れで、収益化のベースができます。まずはASPへの登録からやっていきましょう。

この章でいよいよ技術ブログを収益化していきます。まずASPに登録し、ASPの中から掲載したい広告を選びます。次に選んだ広告で記事広告を書き、技術ブログ内から導線を貼っていきます。

技術ブログを収益化しよう

前の章までで、技術ブログを収益化するベースができました。これで、少しずつ収益が生まれることになります。

ただ、**収益のベースをもっと高めることができます**。その方法のひとつが、記事の書き方を工夫することです。この章では、技術記事や記事広告の書き方、SEOに対する考え方について、知っておいた方がいいことを学んでいきます。

これが最後の章になります。それでははじめましょう。

この章では技術ブログの収益のベースを高めるための、技術記事の書き方について学んでいきます。技術記事や記事広告を学ぶことで、より多くの方に読んでもらえるようになります。

技術記事を書こう

以上で技術ブログ収益化入門はおわりです。ここまでお読みいただき、本当にありがとうございました！

何度も書いてしまいますが、技術ブログにおいて大切なのは**収益ではなくアウトプット**です。継続してアウトプットをしていくことで、少しずつ収益を生むことができます。

この技術ブログ収益化入門が、あなたの技術ブログ運営の参考になればうれしく思います。また、よかったら[Twitterアカウント](https://twitter.com/zenizh)をフォローしてくださいね。技術ブログの収益化についての情報も発信しているので、なにかのお役に立てると思います。

技術ブログ収益化入門のまとめです。大切なことは収益ではなくアウトプットであることを意識して継続することで、収益を生むことができます。

おわりに

技術ブログ収益化入門は、エンジニアの方の技術ブログを収益化するための入門です。月に数十万円を稼ぐようないわゆるブロガーになるのではなく、**エンジニアとしてのアウトプットを目的とした上で**月に数千〜数万円の収益をめざしていきます。

## 技術ブログの収益化とは
ここでいう収益化とは、技術ブログ上に掲載した広告をとおして、広告主から報酬を受け取ることをいいます。

広告と聞くと情報商材のようなものをイメージしがちですが、決してうさんくさいものばかりではありません。たとえば、あなたのエンジニアとしての体験をコンテンツ化することで、**読者の方にとって価値のある形で広告を提供する**ことができます。たとえば技術書のレビューや転職・副業の体験談などですね。

技術ブログ収益化入門では、エンジニアとしてのセルフブランディングを損ねることなく、本来の目的である技術情報のアウトプットから外れない方法で、収益化をめざしていきます。

:::note
### 技術ブログ収益化入門の対象となる読者の方

技術ブログ収益化入門は、技術ブログをはじめようとしている方、すでに運用している方を想定して書いています。とくにプログラミングを学習中の方や、エンジニアとしての実務経験が1〜3年目の方を想定しています。
:::

## 技術ブログ収益化入門の構成
技術ブログ収益化入門は、次の構成で進めていきます。まず技術ブログで収益化をめざすにあたっての心構えをし、技術ブログを作ります。その後記事広告を書き、最後に記事の基本的な書き方について学びます。

| 番号 | タイトル | 内容 |
| - | - | - |
| **1.** | [**技術ブログを作る準備をしよう**][1] | 技術ブログを収益化する心構えをします |
| 1.1 | [技術ブログは儲からない？][1.1] | 技術ブログとお金の話を学びます |
| 1.2 | [広告について学ぼう][1.2] | 技術ブログにおける広告のしくみを学びます |
| 1.3 | [目的を決めよう][1.3] | 技術ブログを運用する目的を明確にします |
| **2.** | [**技術ブログを作ろう**][2] | 技術ブログを作ります |
| 2.1 | [作り方を決めよう][2.1] | 技術ブログをどう作るかを決めます |
| 2.2 | [ドメインを取得しよう][2.2] | ドメインを取得します |
| 2.3 | [サーバを契約しよう][2.3] | サーバを契約します |
| **3.** | [**技術ブログを収益化しよう**][3] | 技術ブログの収益化を行います |
| 3.1 | [ASPに登録しよう][3.1] | 広告を貼るのに必要なASPに登録します |
| 3.2 | [広告を選ぼう][3.2] | 記事広告に用いる広告を選びます |
| 3.3 | [記事広告を書こう][3.3] | 自身の体験をもとにしたコンテンツを作ります |
| 3.4 | [内部リンクを設置しよう][3.4] | 記事広告への導線を貼ります |
| **4.** | [**技術記事を書こう**][4] | 記事をたくさんの人に見られる方法を学びます |
| 4.1 | [書き方を学ぼう][4.1] | 技術記事の書き方を学びます |
| 4.2 | [SEOを学ぼう][4.2] | 検索エンジン対策について学びます |
| **5.** | [**おわりに**][5] | 技術ブログを運用する上で大切なことを学びます |

技術ブログ収益化入門の使い方としては、まずひととおり読んでみて、実際に技術ブログを収益化するときに必要なページを見るような使い方を想定しています。

:::info
### 技術ブログ収益化入門の進め方

もちろん、技術ブログ収益化入門のとおりに行わなくても問題ありません。技術ブログ収益化入門はあくまでやり方のひとつを示しているだけです。あなたが進めたいやり方があれば、その方法でやっていただければと思っています。
:::

## なぜ技術ブログ収益化入門を書いたのか
私は個人の技術ブログとして本サイト『[Product Development IO](http://product-development.io/)』を運営しています。アウトプットを第一の目的としていますが、収益化にも取り組んでいます。

技術ブログの収益化について調べる中で：

* 技術ブログは儲からない
* エンジニアは広告をクリックしない
* アウトプットに集中すべき

といった記事をたくさんみました。実際、技術ブログ一本で食べていくのは難しいと思います。ただ、ちゃんと収益化すれば、技術ブログで技術書を買うくらいの収益は十分得られると思っています。

私は個人の方が書かれている技術ブログを見るのがすきです。ただ、更新が止まってしまうことがよくあります。できるだけ更新を続けてほしいと思っていて、**収益化が継続のちょっとしたモチベーションになれれば**と思い、技術ブログ収益化入門を書きました。

[1]: /guides/monetize-tech-blog/prepare
[1.1]: /guides/monetize-tech-blog/prepare/whether-tech-blog-profitable-or-not
[1.2]: /guides/monetize-tech-blog/prepare/learn-advertising
[1.3]: /guides/monetize-tech-blog/prepare/decide-objective
[2]: /guides/monetize-tech-blog/create
[2.1]: /guides/monetize-tech-blog/create/decide-how-to-make
[2.2]: /guides/monetize-tech-blog/create/contract-server
[2.3]: /guides/monetize-tech-blog/create/get-domain
[3]: /guides/monetize-tech-blog/monetize
[3.1]: /guides/monetize-tech-blog/monetize/register-asp
[3.2]: /guides/monetize-tech-blog/monetize/choose-ad
[3.3]: /guides/monetize-tech-blog/monetize/write-advertorial
[3.4]: /guides/monetize-tech-blog/monetize/create-links
[4]: /guides/monetize-tech-blog/write
[4.1]: /guides/monetize-tech-blog/write/learn-how-to-write
[4.2]: /guides/monetize-tech-blog/write/learn-seo
[5]: /guides/monetize-tech-blog/conclusion

エンジニアの方の技術ブログを収益化するためにはどうすればいいかを、4つのステップで進めていきます。月に数十万円を稼ぐようないわゆるブロガーになるのではなく、エンジニアとしてのアウトプットを目的とした上で月に数千〜数万円の収益をめざしていきます。

お金のイメージ

技術ブログで月数千〜数万円の収益をめざそう

技術ブログ収益化入門

このガイドは、まだアイデアがない状態からスタートし、プロダクトが市場に受け入れられることをゴールとしています。このために、次の4つの問いに対する答えを、ひとつずつ検証しながら決めていきます。

1. **誰の課題を解決するのか**
2. **どんな課題を解決するのか**
3. **どう解決するのか**
4. **どう提供するのか**

なぜこの手順で進めるのでしょうか。

たとえば、ありがちな例として「こういうプロダクトをつくりたい」という話があります。このアイデアの切り口は、3の『どう解決するのか』から入ってしまっています。つまり、このプロダクトはどんな課題を解決するのか、そもそもその課題を抱えている顧客が本当に存在しているのかがわかりません。

失敗しないプロダクトをつくるためには、顧客や課題、解決策をひとつひとつ検証しながら前に進む必要があるのです。

## この章でやること
この章ではFounder/Customer Fitをめざします。解決したい課題はなにか、顧客は誰か。これらをリーンキャンバスで整理します。また、プロダクトが果たすべき使命であるミッションを定めます。

Gumroadの創業者Sahil Lavingia氏は[次のように述べています](https://twitter.com/shl/status/1250159924002222081)：

> 誰もがProduct/Market Fitについて話していますが、より重要なのはFounder/Customer Fitです

誰の課題を解決したいかは、プロダクトのすべてのはじまりです。ここがゆらぐと、以降のステップすべてが脆いものになってしまいます。

それでは、さっそくはじめましょう！

プロダクトづくりの第一歩、『あなたが誰の課題を解決したいかが定まっている状態』をめざします。解決したい課題はなにか、顧客は誰か。これらをリーンキャンバスで整理します。また、プロダクトが果たすべき使命であるミッションを定めます。

Founder/Customer Fitをめざそう

前の章では、リーンキャンバスの中で『誰の課題を解決するか』、つまりあなたの顧客を決めました。次は、その顧客がもっとも解決したい課題を見つけていきましょう。

同じく前の章で『解決したい課題』も決めました。ただ、この課題はあなたが解決したい課題であって、**顧客が本当に抱えている課題かどうかはわかりません**。この状態のままプロダクトをつくっても、顧客に使ってもらえる可能性は低いです。

株式会社ユニコーンファームCEOの田所雅之氏は、『[起業の科学](https://amzn.to/3iC0eeJ)』の中で次のように示しています：

> PMFを達成したスタートアップの8割はプロジェクトの初期段階で「課題の発見と検証」に集中しています。一方で失敗したスタートアップの74%が、同じ段階で「プロダクト（製品）の検証」に時間を割いています。

一旦決めた『解決したい課題』をベースに、ユーザと対話を繰り返し、顧客にとってより深いニーズを見つけていく必要があります。

## この章でやること

田所氏は『[起業の科学](https://amzn.to/3iC0eeJ)』の中で、『課題の質を上げるため』としてペルソナと共感マップ、カスタマージャーニーマップで顧客について分析する手法を示しました。

この章では、顧客がもっとも解決したい課題を、次に示す4つのステップで見つけていきます。

1. ペルソナや共感マップ、カスタマージャーニーマップで顧客について整理する
2. 顧客の課題や顧客自身についての仮説を整理する
3. ユーザインタビューで仮説を検証する
4. 1と2を更新する

4で更新する仮説がなくなったら、Customer/Problem Fitは完了です。ここまでくれば、顧客と、その顧客がもっとも解決したい課題が見つかります。つまり、**プロダクトが失敗する可能性を大きく減らすことができます**。

それでは、まずペルソナから立てていきましょう。

この章では『顧客がもっとも解決したい課題が見つかっている状態』をめざします。これはペルソナや共感マップ、カスタマージャーニーマップで顧客について整理し、仮説を整理したあとユーザインタビューを行うことで実現します。

Customer/Problem Fitをめざそう

前の章で、顧客とその顧客が抱えている課題を見つけました。次は、この課題を解決するための“もっともよい”方法を見つけていきます。

もっともよい、とはつまり、**課題を解決する方法はいくらでもある**ということです。リーンキャンバスで解決策を考えましたが、もっといい方法があるはずです。

いくつもある解決策の中で、もっともよい方法をユーザと対話しながら見つけていきましょう。

## この章でやること
この章では、次の6つのステップをとおして解決策を見つけていきます。

1. PEST分析で解決策のリスクやニーズを把握する
2. フックモデルで課題を解決するシンプルな方法を定義する
3. プロトタイプで解決策の画面を表現する
4. 解決策についての仮説を整理する
5. ユーザインタビューで仮説を検証する
6. インタビューの結果をもとに1〜4を更新する

6で更新することがなくなったらProblem/Solution Fitは完了です。ここまでくれば、顧客とその顧客が抱えている課題、解決策が見つかります。これをもとにMVPの構築に入っていきます。

それでは、まずPEST分析からはじめましょう。

この章では『課題に対するもっともよい解決策が見つかっている状態』をめざします。PEST分析でリスクやニーズを把握した後、フックモデルで解決策を整理します。プロトタイプで画面を表現したあと、ユーザインタビューで検証します。

Problem/Solution Fitをめざそう

前の章で課題の解決策を見つけました。ここまでで顧客と課題、解決策を見つけました。つまり、プロダクトをつくる準備が整いました。

いよいよプロダクトをつくっていくのですが、**プロダクトも解決策と同じくいろんな形があります**。たくさんあるプロダクトの形から、もっともよいものを見つける必要があります。これを実現するのがMVPです。

## この章でやること
この章では、次のステップをとおしてもっともよいプロダクトの形を見つけていきます。

1. 名前を決める
2. ユーザストーリーマップで機能を整理する
3. MVPを構築する
4. MVPの仮説を整理する
5. インタビューで仮説を検証する
6. 2と3を更新する

6で更新することがなくなったらSolution/Product Fitが完了です。ここまでくれば、顧客と課題、解決策、さらにプロダクトの形も見つかります。あとは実際にプロダクトを構築するだけですね。

それでは、まずプロダクトに名前をつけていきましょう。

この章では『解決策を実現するもっともよいプロダクトの形が見つかっている状態』をめざします。まずプロダクトに名前をつけ、ユーザストーリーマップで機能を整理します。その後MVPの構築、検証を行っていきます。

Solution/Product Fitをめざそう

前の章で、もっともよいプロダクトの形が見つかりました。この章ではいよいよ実際のプロダクトをつくっていきます。

この章の目的はProduct/Market Fit、つまり**プロダクトが市場に受け入れられること**をめざします。顧客に継続的に利用され、収益面でも十分な持続可能性があり、かつほかの解決策では代替できないようなプロダクトをつくりましょう。

## この章でやること
次の7つのステップで市場に受け入れられるプロダクトをつくっていきます。

1. グロースサイクルでプロダクトの成長モデルを定義する
2. 利用規約をつくってプロダクトを守る
3. プロダクトを構築する
4. ユーザインタビューをする
5. 顧客ライフサイクルをもとにユーザの利用状況を計測する
6. ユニットエコノミクスで収益面の持続可能性を評価する
7. PMFテストでユーザの満足度を調査する

Product/Market Fitの達成は、5で計測するユーザの継続率、6のユニットエコノミクス、7のPMFテストの数字をもとに総合的に判断します。これらの数字は、いずれも**プロダクトを継続的に改善する**ことで向上できます。

それでは、まずグロースサイクルから定義していきましょう。

この章の目的はProduct/Market Fit、つまり『プロダクトが市場に受け入れられること』をめざします。顧客に継続的に利用され、収益面でも十分な持続可能性があり、かつほかの解決策では代替できないようなプロダクトをつくりましょう。

Product/Market Fitをめざそう

このガイドは、Webサービスやアプリといったプロダクトをつくるためにやるべき基本的なことをまとめたガイドブックです。まだアイデアがない状態から、プロダクトが市場に受け入れられるまでを5つのフェーズでつくっていきます。

このガイドには、具体的なやり方は書いていません。わからないところはセクション内ある関連記事や関連書籍、あるいはGoogleで検索しながら進めることを想定しています。各セクションには架空のプロダクトをもとにしたストーリーを書いていますので、これを参考に進めることもできます。

:::info
### 内容についてのお問い合わせ

ガイドについて、ご意見やご指摘などありましたら[@zenizh](https://twitter.com/zenizh)までご連絡いただけますと幸いです。
:::

## プロダクトマネジメント入門とは
プロダクトマネジメントの目的のひとつは**プロダクトの価値を最大化すること**です。そのためにやるべきことはプロダクトやチームによってもさまざまで、とても体系化できるものではないと思っています。

このプロダクトマネジメント入門は、たくさんのプロダクトに共通する**基本的なプロセスだけをまとめたガイドブック**になります。

:::note
### プロダクトマネジメント入門の使い方

このガイドブックは、あくまで“道しるべのひとつ”にすぎません。進み方が分かっている、あるいは進みたい道がある方は、その方法でつくるのがベストだと思っています。

プロダクトをつくるときになにからはじめていいか分からない方にとって、このガイドブックが道しるべになればうれしいです。
:::

## プロダクトマネジメント入門における5つのフェーズ
東京大学Found Xディレクターの馬田隆明氏は『[あなたのスタートアップのアイデアの育てかた](https://www.slideshare.net/takaumada/how-to-get-your-own-startup-idea-46349038)』の中で、スタートアップにおける4つのフェーズを示しました。

また、株式会社アルファドライブCEOの麻生要一氏は『[新規事業の実践論](https://amzn.to/3c2Z1fd)』の中で、創業者が解決する課題に対する原体験化、つまりFounder/Customer Fitの重要性について示しました。

プロダクトは顧客からはじまり、課題、解決策、MVPと検証しながら進めることで、市場に受け入れられるプロダクトにつながっていきます。このガイドでは、次の5つの『Fit』をめざすことで、プロダクトをつくっていきます。

| ステップ | 名前 | 意味 |
| :-: | - | - |
| 1 | [**Founder/Customer Fit**](https://product-development.io/guides/management-basics/founder-customer-fit) | あなたが誰の課題を解決したいかが定まっている状態 |
| 2 | [**Customer/Problem Fit**](https://product-development.io/guides/management-basics/customer-problem-fit) | 顧客がもっとも解決したい課題が見つかっている状態 |
| 3 | [**Problem/Solution Fit**](https://product-development.io/guides/management-basics/problem-solution-fit) | 課題に対するもっともよい解決策が見つかっている状態 |
| 4 | [**Solution/Product Fit**](https://product-development.io/guides/management-basics/solution-product-fit) | 解決策を実現するもっともよいプロダクトの形が見つかっている状態 |
| 5 | [**Product/Market Fit**](https://product-development.io/guides/management-basics/product-market-fit) | プロダクトが市場に受け入れられている状態 |

### プロダクトマネジメント入門における26つのステップ

スティーブ・ブランク氏は『[アントレプレナーの教科書](https://amzn.to/3qn5Wne)』の中で、リーンスタートアップの根幹となる考え方である顧客開発モデルについて提唱しました。またMVPの概念を定義しました。エリック・リース氏は、『[リーン・スタートアップ](https://amzn.to/3sozEdn)』で顧客開発モデルと従来のアジャイル開発を組み合わせて抽象化し、リーンスタートアップという手法を確立しました。

アッシュ・マウリャ氏は『[RUNNING LEAN](https://amzn.to/3oKXNJ1)』でリーンスタートアップの実践的なプロセスを体系化しました。リーンキャンバスでアイデアを整理し、これをもとに課題、解決策、MVPと段階的に検証していく方法をまとめました。

株式会社ユニコーンファームCEOの田所雅之氏は『[起業の科学](https://amzn.to/38M2WuW)』でアイデアの検証からProduct/Market Fit、その後のスケールにいたるまでのロードマップを提示し、各フェーズでの具体的な手法を示しました。

ニール・イヤール氏は『[Hooked ハマるしかけ](https://amzn.to/3olAzby)』で、ユーザの習慣がプロダクトにもたらす価値と、習慣化の手法を体系化しました。note CXOの深津貴之氏は『[noteにおけるコア体験と相互作用メモ](https://note.com/fladdict/n/n25abad09f96b)』の中でグロースサイクル=プロダクトが継続的に成長するための循環図について提唱しました。

このプロダクトマネジメント入門の目次は、上記文献に学ぶところが多くありました。また、ガイドの中においても引用させていただきました。この場を借りてお礼申し上げます。

:::note
### 本コンテンツの公開にあたり

本コンテンツは、『起業の科学』著者様事務局の承諾をいただいた上で公開しております。
:::

## なぜプロダクトマネジメント入門を書いたのか
私は過去にスタートアップを創業し、オンラインプログラミング教育サービスの事業開発に携わりました。このプロダクトは失敗におわってしまいました。

その後、Webエンジニア&プロダクトマネージャとして、上場企業やスタートアップ、受託開発会社、また個人開発などをとおして20以上のプロダクトをつくってきました。あわせて、たくさんの書籍や資料をとおして学びました。この結果、教育サービスがなぜ失敗してしまったのかが、すこしずつ見えてきました。

このプロダクトマネジメント入門は、[参考文献](#参考文献)や私の経験をもとに書いています。私自身このガイドをもとにふだんの開発に取り組んでおり、また今後も必要に応じてアップデートしていく予定です。

## プロダクトマネジメント入門の対象となる読者
**プロダクトづくりに関わるすべての方**：経営者やプロダクトマネージャ、エンジニア、デザイナーの方などを読者として想定しています。

## 参考文献
このガイドは、次の書籍や資料からたくさんのことを学ばせていただきました。ガイド内で引用しているところについてはその都度出典として明記しますが、ガイド全体にわたり学びを得たものについて、次に示します。

* [起業の科学](https://amzn.to/38M2WuW): プロダクト開発の各プロセスにおける具体的な方法論、ユーザの課題検証についてたくさんのことを学びました
* [あなたのスタートアップのアイデアの育てかた](https://www.slideshare.net/takaumada/how-to-get-your-own-startup-idea-46349038): プロダクト開発の基本的なプロセスについて学びました。このガイドの目次をつくる上で大きな影響を受けました
* [新規事業の実践論](https://amzn.to/3c2Z1fd): 課題や顧客に焦点を当てた開発手法、またFounder/Customer Fitの重要性について学びました
* [RUNNING LEAN](https://amzn.to/3oKXNJ1): リーンキャンバスの書き方、これをもとにしたユーザインタビューによる仮説検証の方法について学びました
* [リーン顧客開発](https://amzn.to/3nJOfg5): ユーザインタビューの相手の集めかたや実施など、顧客開発の具体的な方法論について学びました
* [アントレプレナーの教科書](https://amzn.to/3qn5Wne): このガイド全体にわたる概念である顧客開発モデルの重要性について学びました
* [リーン・スタートアップ](https://amzn.to/3sozEdn): プロダクト開発の基本的な手法であるリーン・スタートアップについて学びました

このガイドは、Webサービスやアプリといったプロダクトをつくるための体系化されたガイドブックです。まだアイデアがない状態から、ユーザインタビューをとおして仮説を検証し、プロダクトが市場に受け入れられるまでを5つのステップでつくっていきます。

プロダクトマネジメントのイメージ

実践をとおしてプロダクトマネジメントの基礎を学ぼう

プロダクトマネジメント入門

:::wonder
エンジニアが情報発信をすべきなのはなんとなく感じてるんだけど、本当に必要なの？ あと情報発信をするとしたら、なにをすればいいのかな。
:::

といった疑問について、記事でお答えしていきます。

この記事を読むことで、**エンジニアの方が情報発信をすべき理由**と、**なにをすればいいのか**がわかります。情報発信に悩んでいたら、ぜひ読んでみてくださいね。

私はTwitterやGitHub、また本ブログをとおして情報発信をしてきました。転職の面談で評価の対象となったり、情報発信をとおして仕事の依頼を受けたこともあります。

また、過去に情報発信をやめてしまった期間もあります。こういった経験をもとに、この記事を書いています。

:::note
### この記事で想定している読者の方

この記事は、プログラミングを学んでいる方、またエンジニアとしての実務経験が1〜3年目の方を主な読者として想定しながら書いています。
:::

## エンジニアにとっての情報発信とは
エンジニアがする情報発信とは、主に**技術情報の共有を目的として発信すること**ですね。たとえば：

* **バグとその解決方法**
* **ライブラリの紹介**
* **新しい技術に対する考察**

といった技術情報を文章として公開したりします。あるいは、作ったライブラリを公開することも情報発信のひとつですね。

## エンジニアが情報発信をすべき理由
エンジニアの方が情報発信をするメリットとして、大きく次の4つがあります：

1. **セルフブランディングになる**
2. **他の誰かの役に立つ**
3. **自分のためになる**
4. **文章力が向上する**

ひとつずつ見ていきます。

### 1. セルフブランディングになる

情報発信をしていると、内容によっては**転職や社内での面談のときに評価**されたりします。また、あなたのスキルがわかるようになるので、あなたのスキルを頼りに仕事の依頼が来たりします。

あなたの人となりもわかりますので、他のエンジニアの方とコミュニケーションが取りやすくなったりもしますね。

### 2. 他の誰かの役に立つ

Twitterや技術ブログで情報発信をすると、**その情報を見た方が抱えている課題を解決できる**かもしれません。あるいは、公開したライブラリをちょうどほしいと思っている方がいるかもしれませんよ。

### 3. 自分のためになる

Twitterや技術ブログは他の方が見ることになります。他の方がわかるように文章を書くので、**思考の整理**になり、**知識として定着**しやすくなります。あと、将来の自分が参考にすることもできますね。

### 4. 文章力が向上する

**文章力はエンジニアにとって大切なスキル**のひとつですね。ドキュメントを書いたり、チャットでコミュニケーションをとるときにも必要になりますが、このスキルを大きく高めることができます。

こういった理由があるので、エンジニアの方は情報発信をどんどんやっていくべきですね。

:::anger
でも、そんなことする時間なんてないよ。
:::

たしかに、『情報発信をすること』が目的になってしまったら、時間を作るのは難しいかもしれません。でも、たとえば『自分のために書く』といった理由なら、続けられませんか？

なにかしら情報発信をするモチベーションを作れるといいですね。これについては後述します。

## エンジニアにとっての情報発信の手段
:::smile
情報発信をすべきというのはなんとなくわかったよ。情報発信をはじめようと思うんだけど、なにをすればいいの？
:::

情報発信にもいろんな手段がありますが、私は次の3つがいいと思っています：

| 番号 | 手段 | 内容 |
| :-: | - | - |
| 1 | [Twitter][Twitter] | ニュースのシェア、エンジニアとの交流、更新情報のシェア |
| 2 | [GitHub][GitHub] | ライブラリなどのソースコードを公開 |
| 3 | 技術ブログ | バグの解決方法、体系的な知見などを公開 |

技術情報の発信という意味では、この3つでほとんどをカバーできると思います。他にもポッドキャストやYouTubeなどが考えられますが、**ちょっとハードルが高い**ので書いていません。

[技術ブログをはじめるメリット][技術ブログをはじめるメリット]については別の記事で書いていますので、そちらもあわせてご覧くださいね。

:link{slug=how-to-write-technical-blog}

### 技術ブログはWordPressがおすすめ

技術ブログを書く場所については[Qiita][Qiita]や[Zenn][Zenn]だとプラットフォーム的に書きたいことが書けない・書きづらいことあります。[はてなブログ][はてなブログ]などのブログサービスは広告が表示されたり遅いなどのデメリットがあります。

こうした理由から、私は[技術ブログをはじめるならWordPressがいい][技術ブログをはじめるならWordPressがいい]と思っています。これも別の記事で書いているので、ご覧ください。

:link{slug=tech-blog-with-wordpress}

## 例：私の情報発信
参考までに、私がやっている主な情報発信のアカウントやURLを紹介しますね。Twitterについては、プロフィールや投稿を見ていただいて、有益そうならフォローしてもらえるとうれしいです。

| 媒体 | URL |
| - | - |
| Twitter | https://twitter.com/zenizh |
| GitHub | https://github.com/zenizh |
| 技術ブログ | https://product-development.io |

## エンジニアが情報発信をするモチベーション
情報発信が長続きする秘訣は、人によっていろいろあると思います。私の場合ですが、私はとにかく**自分のため**に情報発信をしています。

私はこのサイトで技術情報を書いていますが、動機としては『**将来の自分が参考にするため**』です。私は物覚えがわるいので、『このサイトを見ながら仕事をすればなんとかなる』という状況を作るために記事を書いています。

たとえばこのこの記事自体も、将来の自分が情報発信で目的を見失ったときに読み返すことで、モチベーションを取り戻せたらいいな、という動機で書いています。

あと、副次的に**他の誰かの役に立てる**のもうれしいですね。Twitterでお礼のメッセージをいただいたりしますが、これを見たときに「がんばろう」と思えたりします。

あなたなりの情報発信のモチベーションを作れるといいですね。

## まとめ
エンジニアが情報発信をすべき理由と、情報発信の種類についてまとめました。まだ情報発信をしていない方は、ぜひはじめてみてくださいね。

[Twitter]: https://twitter.com
[GitHub]: https://github.com
[Qiita]: https://qiita.com
[Zenn]: https://zenn.dev
[はてなブログ]: https://hatenablog.com/
[技術ブログをはじめるメリット]: https://product-development.io/posts/how-to-write-technical-blog
[技術ブログをはじめるならWordPressがいい]: https://product-development.io/posts/tech-blog-with-wordpress

この記事を読むことで、エンジニアの方が情報発信をすべき理由と、なにをすればいいのかがわかります。情報発信に悩んでいたら、ぜひ読んでみてくださいね。

情報発信のイメージ

エンジニアが情報発信をすべき理由と、3つの手段

:::wonder
権限管理をすることになったけど、どうすればいいの？ なにからはじめればいいのかわからない。
:::

という悩みについて、記事でお答えしていきます。

この記事を読むことで、権限管理とはなにか、その際に押さえておくべきRBACとABACについて、また権限管理を設計するやり方の一例がわかるようになります。

私はエンジニアとして、主に立ち上げのフェーズで20以上のサービスを開発してきました。権限管理は、どのサービスにも必ず入ってくるプロセスでした。ここでの経験や、調べたことをもとにこの記事を書いています。

:::note
### 想定している読者の方

この記事が想定している読者の方としては、エンジニアとしてシステムを設計または実装する立場にある、実務経験が1〜3年目の方を想定して記事を書いています。
:::

## 権限管理とは
この記事でいう権限管理とは、ユーザー認証を行った相手に対して、『**誰がどの機能に対してなにをしていいのか、あるいはしてはいけないのかを管理すること**』をいいます。

たとえばTwitterにおける権限管理について考えてみると、次のようになります：

* すべてのユーザーは投稿できる
* すべてのユーザーは自分の投稿を削除できる
* ツイートはすべてのユーザーが閲覧できる
* 非公開ツイートはフォロワーのみが閲覧できる
* ブロックされたユーザーはツイートを閲覧できない

こういった、**サービス内の行動に対する権限を設計する**のが権限管理ですね。この権限管理について、この記事で書いていきます。

:::note
### この記事の権限管理の前提

権限管理は、**システムの種類によって大きく変わってきます**。このため、この記事の内容はすべてのシステムに適用できるやり方というわけではありません。参考資料のひとつとしてお読みいただければと思っています。
:::

## どう権限管理を設計するか
:::trouble
権限管理がなにかはわかったよ。じゃあ具体的にどう設計すればいいの？
:::

Googleで『権限管理 設計』で検索してもらってもわかることですが、権限管理にはいろんなやり方があって、**ベストプラクティスはない**と思っています。この前提で、私はシートで管理するやり方をとっています。

たとえば次のような感じですね。これは架空のドキュメント共有サービスを例に作ってみています：

![権限管理の例](//images.ctfassets.net/pppgbgujcovf/319j6VkMVXG6mdQJhx65Tk/95133f1312b3bf4296e41c3f848d6410/__________________.png)

### 権限管理のシートに書く内容

このシートには、次のようなことを書いていきます：

| 項目 | 内容 | 例 |
| - | - | - |
| **機能** | どの機能に対する権限か | 投稿閲覧 |
| **役割** | どの役割に対する権限か | 一般ユーザー / 管理者 |
| **属性** | どんな属性をもったユーザーに対する権限か | 同じグループに属していること |
| **対象となるデータ** | 処理するデータはどれか | グループのメンバーの投稿 |
| **処理の可否** | 処理をできるのかどうか | できる / できない |
| **説明** | その権限の概要 | 同じグループのユーザーの投稿を閲覧できる |

開発が進むにつれて、機能が追加・削除されて、権限もどんどん変わっていくことになります。その度に、このシートを更新していきます。

すべての権限管理が一枚のシートに集約されている状態がベストですね。

## 権限管理におけるRBACとABACという考え方
上の表で、権限管理には『役割』と『属性』があると書きました。これについて、権限管理を設計する上で**RBAC**と**ABAC**という考え方が大切なので、それぞれについて書いていきます。

### RBAC: Role-Based Access Control

RBACは『**ユーザーの役割によって権限のチェックを行う**』やり方です。役割とは、たとえば一般ユーザーや管理者などがありますね。

権限を変更するだけで処理の可否を変更できるという利点がありますが、権限がふえると管理や実装が大変になってきます。

『管理者』のような役割以外にも、WritableやReadableのような複数のパーミッションを持たせるようなやり方もあります。

### ABAC: Attribute-Based Access Control

ABACは『**ユーザーの属性によって権限のチェックを行う**』やり方です。たとえばツイートの投稿者かどうか、あるいは同じグループに所属しているかどうか、ですね。

ABACは柔軟な権限管理ができる一方で実装が大変だったり、ものによってはデータベースへのアクセスがふえてパフォーマンスが悪くなったりします。

:::wonder
RBACとABAC、どっちのやり方がいいの？
:::

RBACとABACは、システムの種類によって使い分けるとよいですね。ひとつのシステム内で両方を使うことももちろんあります。

## 権限管理を設計するフロー
権限管理の設計はシートでやるといい、と書きました。その手順としては、次の3つでやるとスムーズに設計できます。

1. 機能を洗い出す
2. 機能に対する権限を洗い出す
3. 重複した権限の優先度を考える

まずシステムの機能を洗い出して、それぞれの機能に対する権限をシートにまとめていきます。このとき、重複した権限が出てきます。たとえば：

* 管理者はすべての投稿を表示できる
* ブロックされたユーザーは、相手の投稿を表示できない

という二つの権限があったときに、『ブロックされている管理者』は投稿を閲覧できるのかどうかを考える必要が出てきます。

こういった重複について、ひとつひとつどうするかを決めていきます。

## 権限はどこでチェックするか
:::smile
権限を設計するやり方はなんとなくわかった。あとは実装していくだけだね。
:::

次はコード面での設計についてです。権限は、データベースなどの**データとのやりとりが発生するところ**でチェックするといいですね。

たとえばフロントエンドにJavaScriptを用いていて、データとのやりとりにAPIサーバーがある、という構成について考えてみます。

フロントエンド側で権限管理をする/しないについては選択の余地がありますが、**API側での権限管理は必須**ですね。なぜなら不正なリクエストなどで、意図しないやりとりが行われる可能性があるからです。

もちろんトークンの照合などでリクエスト自体の正当性は検証しつつも、API側で権限をチェックする必要があるといえます。

## 権限はどこで実装するか
次は、チェックではなく権限自体をどこで実装するかについて考えてみます。

権限管理とは：

> 誰がどの機能に対してなにをしていいのか、あるいはしてはいけないのかを管理すること

であると書きました。つまり**権限はビジネスロジックである**といえます。権限はそれ単体でひとつの責務をもつので、権限管理をする責務として切り出して実装していくとよさそうです。

:::note
### 例：Rubyの場合

Rubyには[Pundit](https://github.com/varvet/pundit)というGemがあります。これはモデル層に属する純粋なRubyオブジェクトで、リソースに対する権限を実装するときに有用なライブラリです。
:::

## 権限管理を設計するときの指針
権限管理を設計するときは、次の二つのことを実践していきます：

1. **役割をできるだけ減らす**
2. **テストコードを書く**

それぞれについて簡単に書きます。

### 役割をできるだけ減らす

権限管理の役割がふえると、その分だけ**権限管理シートやソースコードが複雑**になってしまいます。

ビジネスを表現するために必要であれば役割をふやすことも仕方がないですが、「とりあえず問題を解決するために役割をふやそう」という発想は避けるべきだといえますね。

### テストコードを書く

前述のとおり、権限管理はビジネスロジックに属します。権限の実装にミスがあると、**意図しないデータの流出などにつながるおそれ**があります。

権限に対するユニットテストはもちろん、データとのやりとりが発生するコントローラ層へのユニットテスト、またE2Eテストなどを書くことで、信頼性の担保につながります。

## まとめ
この記事では権限管理を設計するときの考え方、やり方について書いてきました。

権限管理はシステムの種類によって変わってきます。この記事の内容を参考にしつつ、システムに適したやり方を見つけられればと思います。

この記事を読むことで、権限管理とはなにか、その際に押さえておくべきRBACとABACについて、また権限管理を設計するやり方の一例がわかるようになります。

権限管理のイメージ

システムの権限管理を設計するときの考え方

:::wonder
目標に向けてがんばりたいんだけど、タスクがたくさんあってうまくいかないな。
:::

といった悩みについて、私の経験をもとに記事でお答えしていきます。

この記事を読むことで、**タスクよりも習慣を管理することが大切**であることがわかります。習慣とはなにか、なぜタスクより習慣が大切か、習慣を管理するやり方について書いていきます。

私自身も、ブログを書くことを習慣としています。また、毎日6:00に起きたり、ラジオ体操をするといった習慣があります。いくつか習慣に関する本も読んだ上で、考えを整理する意味でこの記事を書いています。

:::note
### この記事で対象としている読者の方

この記事は、目標に向けてがんばりたいけどうまくいっていない方に向けて書いています。本サイトはエンジニア向けのサイトですが、この記事は特定の職種などによらず、広く参考になると思います。
:::

## タスク管理とはなにか
まず、この記事でいうタスク管理とはなにかについて整理しておきますね。タスク管理とは、『**やることを洗い出して、優先度順に並べること**』をいいます。

たとえば仕事なら『◯◯さんに△△の件で連絡する』だったり、プライベートなら『牛乳を買う』だったりします。このように、やることを洗い出して、優先度順に並べることをタスク管理とします。

## 習慣とはなにか
一方で習慣とはなんでしょうか。習慣は、『**目標を達成するために重要な、繰り返すと決めたこと**』をいいます。

たとえば仕事なら『朝会の前に前日の作業をふりかえる』、プライベートなら『毎朝6時に起きる』などですね。このように、仕事や生活などで目標のために繰り返すと決めたことを習慣としています。

## タスクよりも習慣を管理すべき理由
:::trouble
タスクと習慣についてはわかったけど、なんで習慣の方が大切なの？
:::

タスクよりも習慣の方が大切な理由は、習慣が『**重要度をもとに決めるものだから**』です。

タスクはよく緊急度によって並べられます。たとえば

> この日までにこれをやっておかなきゃいけない

みたいなイメージですね。こういったタスクがたくさんあると、タスクに追われる形になってしまい、目標に向かうために重要なことができなくなってしまいます。

### 『重要かつ緊急でないこと』に集中する

習慣に関する有名な本『[7つの習慣][7つの習慣]』では、次のような『重要度』と『緊急度』からなる**時間管理マトリクス**を示しています。その上で『**重要かつ緊急でないこと**』に集中すべき、としています：

![時間管理マトリクス](//images.ctfassets.net/pppgbgujcovf/KHBU5q9mTen60pC6CymoY/c25268ed6adf54234a60aa56efb6dd22/___________________________.png)

この中で、『重要かつ緊急でないこと』に時間を使うことが大切だ、としています。図でいうと、『Ⅱ 生産性とバランス』ですね。**ここに集中することで、目標に近づくことができます**。

タスク管理をしていると、どうしても『緊急度』だけに目を向けがちです。今やらないといけないことに集中してしまって、大切な『重要なこと』ができません。

あなたが目標に近づけていないと感じる理由は、もしかしたらここにあるかもしれませんね。『重要かつ緊急でないこと』が大切だと認識して、これをやれるよう習慣を管理することがスタートです。

### やるべきことがたくさんあるとき

:::anger
そんなこといったって、やらなきゃいけないことはたくさんあるよ。
:::

やらないといけないことがたくさんあるときは、上のマトリクスと照らしてみて、そのタスクがどの領域に当たるか考えてみてください。重要でないなら**やらない判断をする**、あるいは**やらなくていいように立場を変えてみる**といった解決策が、きっとあると思います。

## 習慣を管理する手順
では、習慣は具体的にどう管理すればいいのでしょうか。これは、次の3つのステップで決めるといいです：

1. **目標を決める**
2. **目標を達成するために必要なことを洗い出す**
3. **習慣を決める**

ひとつずつ見ていきますね。

### 1. 目標を決める

習慣は、なにかしらの**目標を達成するため**にあります。たとえばエンジニアの方であれば『技術力を高める』、あるいは行きたい会社に転職する、など具体的な目標ですね。まずはこれを決めましょう。

### 2. 目標を達成するために必要なことを洗い出す

1で決めた目標を達成するために**必要なことを洗い出します**。たとえば『毎朝6時に起きる』とか、『毎日30分コードを書く』などですね。

### 3. 習慣を決める

最後に習慣を決めましょう。これは、2で洗い出したことを**生活のスケジュールに組み込んでいきます**。たとえば『毎朝6時半からコードを書く』とか『22時には布団に入る』などです。

あとは、これを毎日やっていくだけです。繰り返しになりますが、習慣は『重要かつ緊急でないこと』です。**これを積み重ねる**ことで、目標達成に近づけます。

ちなみに、習慣を管理するのに専用のアプリを使うのもアリだと思います。私は使っていませんが、[Habitify][Habitify]は評判がよさそうなので、いろいろ見てみるとよさそうですね。

## 例：私の習慣
参考までに、私の習慣を書いてみます。私は個人開発とブログで生活できるような目標を設定しています。そのために、次のような習慣を作っています：

| 時間 | 習慣 |
| :-: | - |
| 5:55 | 起きる |
| 6:00 | 作業開始 |
| | 1日の作業内容をツイート |
| 8:00 | 記事公開 |
| | 記事を公開したことをツイート |
| | ラジオ体操 |
| | カフェまで歩く |
| 9:00 | 作業再開 |
| 12:00 | 技術系のニュースをシェア |
| 20:00 | 記事公開ツイートのスレッドに追加 |
| 22:30 | ストレッチ |
| | 温かいものを飲む |
| 23:00 | 寝る |

習慣は試行錯誤中なので、随時更新予定です。他にもやっていることはありますが、目標達成のために重要でないことなど書いていないものもあります。

余談ですが、私はタスク管理というものをしていません。していないというと語弊がありますが、タスクは常に1〜3つくらいしかありません。タスクが少ないので、ノートアプリにメモする程度にしています。

このようにして、**タスクよりも習慣にフォーカスする**ように気をつけています。

## 参考：やり抜く人の9つの習慣
『[7つの習慣][7つの習慣]』の他にも、私が習慣について実践する上で影響を受けている本に『[やり抜く人の9つの習慣][やり抜く人の9つの習慣]』という本があります。

この中で、目標を達成するための習慣として、次の9つについて詳しく書いています：

1. 目標を決めている
2. いつになったらやるかを決めている
3. 『目標に近づくためにすべきこと』に焦点を置いている
4. 成功できると信じている
5. 最初から完璧をめざさない
6. どんなことでも努力で身につけられると信じている
7. 意志力は鍛えられることを知っている
8. 誘惑を近づけないようにしている
9. 『やらないこと』ではなく『やること』に焦点を置いている

この記事の内容に興味をもっている方であれば、『[やり抜く人の9つの習慣][やり抜く人の9つの習慣]』はとても参考になると思います。ぜひ読んでみてくださいね。

## まとめ
あなたが目標に近づけていないと感じるとき、もしかしたらタスクに追われているかもしれません。タスクではなく、習慣に着目して管理することで、目標に近づけると思います。一緒にがんばっていきましょう！

[7つの習慣]: //af.moshimo.com/af/c/click?a_id=2464392&amp;p_id=170&amp;pc_id=185&amp;pl_id=4062&amp;url=https%3A%2F%2Fwww.amazon.co.jp%2Fdp%2FB00KFB5DJC
[やり抜く人の9つの習慣]: //af.moshimo.com/af/c/click?a_id=2464392&amp;p_id=170&amp;pc_id=185&amp;pl_id=4062&amp;url=https%3A%2F%2Fwww.amazon.co.jp%2Fdp%2FB0732RRCWX
[Habitify]: https://www.habitify.me

<div class="tracking-tags">
  <img src="//i.moshimo.com/af/i/impression?a_id=2464392&amp;p_id=170&amp;pc_id=185&amp;pl_id=4062" alt="" width="1" height="1" style="border: 0px;" />
</div>

この記事を読むことで、タスクよりも習慣が大切であることがわかります。また、習慣とはなにか、なぜタスクより習慣が大切か、習慣を管理するやり方についてわかるようになります。

タスク管理のイメージ

タスクではなく習慣を管理することが大切

:::wonder
ユーザー認証を実装することになったんだけど、どう設計すればいいの？ 認証にはいろんなやり方があると思うんだけど、なにから考えればいいのか分からない。
:::

といった悩みに、記事でお答えしていきます。

この記事では、Webアプリケーションやネイティブアプリでのユーザー認証の仕組みや方法を説明した上で、どの方法がいいのかをケースごとに見ていきます。

私はBtoB、BtoCのWebアプリケーションやモバイルアプリをいくつか作ってきました。その度に、ソフトウェアの種類に応じたユーザー認証について考え、設計・実装してきました。その経験をもとにこの記事を書いています。

:::note
### この記事の対象となる読者の方

この記事はプログラミングを学習中の方、エンジニアとしての実務経験が1〜3年目の方を対象として書いています。わかりやすさを優先して、用語の使い方が厳密でないところがあります。その際は注釈として補足しています。
:::

## ユーザー認証とは
:::trouble
そもそもユーザー認証とはなに？
:::

この記事でいうユーザー認証とは、Webアプリケーションやネイティブアプリにおいて**リクエストした相手がユーザーであることを確認すること**をいいます。たとえば現実世界でいう運転免許証での本人確認ですね。

ユーザーにだけなんらかの機能を提供したいときに、ユーザー認証を行います。

## ユーザー認証のフロー
ユーザー認証は、基本的に次のようなフローで行われます：

1. クライアントからサーバーに認証情報を送る
2. サーバー上で認証情報を検証する
3. 認証情報が正しければ、クライアントにアクセストークンを送る（+必要に応じてセッションに記録する）

たとえばフォームにメールアドレスとパスワードを入力・送信し、入力内容が正しければサーバーからアクセストークンが渡される、というイメージですね。

## ユーザー認証を設計する上で決めるべきこと
:::anger
それで、結局ユーザー認証を設計するときなにをすればいいの？
:::

このユーザー認証ですが、設計する上で次の4つについて決める必要があります：

| 順番 | 項目 | 選択肢 |
| :-: | - | - |
| 1 | **認証方法をどうするか** | パスワード認証、OpenID Connect |
| 2 | **アクセストークンをどう管理するか** | JWT |
| 3 | **アクセストークンをどう引き回すか** | Authorizationヘッダー、Cookieヘッダー |
| 4 | **アクセストークンをどう保持するか** | OS標準のストア、メモリ、Cookie、localStorage |

今はまだそれぞれがなにかを理解する必要はありません。これからひとつずつ見ていきましょう。

## 1. ユーザー認証の方法
まず、ユーザー認証の方法には、大きく次の二つがあります：

| 番号 | 認証方法 | 概要 |
| :-: | - | - |
| 1 | **パスワード認証** | IDとパスワードをサーバーに送る |
| 2 | **OpenID Connect** | 外部のプロバイダ上で認証し、アクセストークンをサーバーに送る |

OpenID Connectは、OAuth認証と聞くとなじみがあると思います。たとえばGoogleやTwitterなどのアカウントによる認証ですね。ただ、『OAuth認証』という言葉には語弊があります。これは後述しますね。

この二つの認証方法についてひとつずつ見ていきます。

## 認証方法(1): パスワード認証
パスワード認証にも、大きく二つの認証方法があります：

1. Basic認証やDigest認証など
2. 独自の認証機構

独自の認証機構とは、たとえばフォームからIDとパスワードをサーバーに送って、ユーザー基盤をもとに認証を行う一般的なやり方ですね。広く使われている**フルスタックのWebフレームワークならだいたい認証機構をもっている**と思います。

この認証方法はパスワードを平文で送ることになります。仮にSSLで通信を暗号化していたとしても、ログに書かれて流出につながったりします。

## 認証方法(2): OpenID Connect
次にOpenID Connectについて説明します。これはGoogleやTwitterなどのアカウントで認証する方法ですね。

まず、前提知識として、OAuthという『**アクセストークンを発行する仕組み**』があります。アクセストークンは、アプリケーションをAPI経由で操作するときなんかに使われますね。たとえばTwitterクライアントを自作するときにアクセストークンを使ったりします。

このOAuthは前述のとおりアクセストークンを発行する仕組みであって、**認証については定められていません**。認証に必要な、ユーザー情報などの取得については決まっていないんですね。

このOAuthを拡張し、ユーザー情報の取得についてなどを標準化したのがOpenID Connectというわけです。これについては『[OpenID Connectユースケース、OAuth 2.0の違い・共通点まとめ](https://www.buildinsider.net/enterprise/openid/connect)』の説明がわかりやすいです：

> OpenID Connectは、『OAuth 2.0を使ってID連携をする際に、OAuth 2.0では標準化されていない機能で、かつID連携には共通して必要となる機能を標準化した』OAuth 2.0の拡張仕様の一つである。

### OpenID Connectによる認証のフロー

このOpenID Connectは広く使われている認証方法なので、フローを押さえておきます。まず、IDトークンという『**ユーザー情報が含まれたアクセストークン**』があり、これを次のフローでやりとりします。プロバイダというのはGoogleなどの認証を行うサービスを想定しています：

| 順番 | リクエスト元 | 相手 | 内容 |
| :-: | - | - | - |
| **1** | **クライアント** | **プロバイダ** | **IDトークンを要求する** |
| 2 | プロバイダ | ユーザー | IDトークンの発行可否を聞く。あわせて認証を行う |
| 3 | ユーザー | プロバイダ | 発行可否と、発行する場合に認証情報を送る |
| **4** | **プロバイダ** | **クライアント** | **IDトークンを発行する** |

この1と4のやりとりを標準化したのがOpenID Connectです。OAuthが『アクセストークンを発行する仕組み』なのに対して、OpenID Connectはこれを拡張して『IDトークンを発行する仕組み』と考えるとわかりやすいかもしれません。

詳しいことはさておき、『Googleなどのアカウント認証を使う』=『OpenID Connectを使う』という認識がもてればいいのかな、と思います。

:::note
### Googleの認証方法はOpenID Connectではない

OpenID Connectについて書きましたが、実際のところGoogleやTwitterの認証はOpenID Connectではありません。GoogleはOpenID Connectの仕様に準拠しつつ、OAuth 2.0を採用しています。TwitterはOAuth 1.0aという仕様で、OpenID Connectには準拠していません。

いずれにしてもOAuthをベースにした認証を行なっていますが、ここではわかりやすさのためにOpenID Connectという用語に統一して説明しています。
:::

## 2. JWTでトークンを管理する
OpenID ConnectはIDトークンをやり取りする、と書きました。これはJWTというトークンの形式になっています。JWTはユーザー認証において大切な概念なので、簡単に説明しておきますね。

### JWTとは

JWTは『**二者間で情報のやりとりを目的とした、JSONベースの形式について規定した標準仕様**』です。『ジョット』と読みます。たとえばJWTは次のような値になります：

```
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
```

わかりづらいですが、三つの文字列がピリオドで連結されています。わかりやすく書くと：

```
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
```

となります。それぞれBase64でエンコードされた文字列となっています。上から順番に、次のような名前と役割があります：

| 順番 | 名前 | 役割 |
| :-: | - | - |
| 1 | **ヘッダー** | 署名の検証に必要な情報 |
| 2 | **ペイロード** | やり取りに必要な情報。ユーザー情報など |
| 3 | **署名** | 検証する内容 |

署名には秘密鍵を使うため、これを用いて検証を行うことができます。署名はヘッダーやペイロードをもとに行うので、内容の改ざんができない、という仕組みです。

クライアントからトークンを受け取ると、サーバー側でトークンが正しいかどうかをその場で検証できます。JWTを用いることで、**パスワードなどの認証情報をデータベースに保存する必要がない**、というメリットがあります。

:::note
### 正しくはJWS

上の説明ではJWTという用語を出しました。これは広く使われているのでこうしましたが、正しくはJWSという仕様です。JWSはJSON Web Signatureで、署名つきのJWTの場合にとりわけてこう呼びます。
:::

### JWTは使うな？

:::anger
いろいろ調べてみると「JWTは使うな」っていう人が多いんだけど、大丈夫なの？
:::

JWTは危険だという議論があります。確かにJWTの署名を検証する方法によっては脆弱性を作り出してしまうという問題があります。たとえば**ヘッダーの情報を改ざんするやり方**です。これについては『[JSON Web Token（JWT）の紹介とYahoo! JAPANにおけるJWTの活用](https://techblog.yahoo.co.jp/advent-calendar-2017/jwt/)』に詳しいです。

ただ、これは実装によって対応できる問題であり、ほとんどのライブラリ側で対応されています。JWTは使うメリットが大きいので、脆弱性への対応がされていることを確認した上で、積極的に使うべきだと思っています。

## 3. アクセストークンをどう引き回すか
上で、ユーザー認証の方法としてパスワードとOpenID Connectについて書きました。この認証結果として、アクセストークンが返されることになります。以降は、このアクセストークンを用いて認証することになります。

では、このアクセストークンはどう引き回せばいいでしょうか。つまり、どうやってクライアントからサーバーにリクエストを送ればいいのでしょうか。これには次の二つがありますが、結論からいうと『**特定の条件を除いてAuthorizationヘッダーで行えばよい**』と思っています。

### 方法1: Authorizationヘッダー

このやり方は、認証を行うために定義されているAuthorizationヘッダーにアクセストークンを入れるやり方です。たとえば次のような形式になります：

```
Authorization: Bearer <アクセストークン>
```

このAuthorizationヘッダーは、Basic認証やDigest認証で使われていました。その後[RFC6750](https://tools.ietf.org/html/rfc6750)でBearerというスキームが策定されました。これは**単一の文字列を認証情報として送信するのに適しています**。

特徴をまとめると：

* ステートレス。サーバー側にセッションストアがいらない
* ネイティブプラットフォームで扱いやすい
* Cookieが使用できない環境でも問題ない

Authorizationヘッダーを用いるやり方は、OpenID Connect、パスワードのどちらの認証方法にも適しています。

### 方法2: Cookieヘッダー

このやり方は、CookieヘッダーにセッションIDを入れつつ、サーバー上でも保存しておくやり方です。ユーザー認証を一度行ったら、以降は**Cookieヘッダーに含まれるセッションIDとサーバー側のセッションIDを照合**してユーザーを識別します。

次のような形でサーバー側からクライアントにCookieのセットをリクエストして：

```
Set-Cookie: SID=<セッションID>
```

次のような形でクライアントからサーバーにリクエストを行います：

```
Cookie: SID=<セッションID>
```

特徴をまとめると：

* ステートフル。データベースなど外部のストレージからセッションを取得する必要がある
* サーバーにリクエストするたびに自動でCookieが送信される
* CSRF脆弱性への対策をする必要がある
* 異なるドメインに対して制約がつく（=CORS）

APIは一般的にステートレスで行うため、Cookieヘッダーによる引き回しは実用的ではないといえます。このやり方はパスワード認証かつ、ネイティブアプリやSPAでない従来のWebアプリケーションに適していると思います。

## 4. アクセストークンをどう保持するか
長くなりましたが、最後のテーマです。前述のとおり、パスワードやOpenID Connectでユーザー認証を行うと、アクセストークンが発行されます。これをヘッダーに乗せて認証します。つまり、**クライアント側でアクセストークンを保持**しておかなければなりません。

アクセストークンはどう保存すればいいのでしょうか。大きく次の4つがありますが、結論からいうと可能な限り『**OS標準のストレージ**』か『**メモリ**』に保持します：

| 番号 | 場所 | 概要 |
| :-: | - | - |
| 4.1 | **OS標準のストレージ** | iOSのKeyChain、AndroidのKeyStore |
| 4.2 | **メモリ** | JavaScriptの変数など |
| 4.3 | **Cookie** | WebブラウザのCookie |
| 4.4 | **localStorage** | Web Storage APIのlocalStorage |

ひとつずつ見ていきます。

### 4.1 OS標準のストレージ

iOSのKeyChainやAndroidのKeyStoreなど、OSが標準で提供しているストレージを利用するやり方です。[Auth0によるアクセストークンの保持についての記事](https://auth0.com/docs/tokens/token-storage#regular-web-apps)でも、次のメモリとあわせて推奨されているやり方です。

### 4.2 メモリ

JavaScriptの変数などに格納し、CookieやlocalStorageには保存しないやり方です。スコープに気をつける必要はありますが、永続化しないため安全といえます。

ただ、ページから離脱するとアクセストークンが消えてしまうので、**ソフトウェアが要件を満たせる場合のみ採用できるやり方**になります。

### 4.3 Cookie

これはWebブラウザのCookieを使うやり方ですね。Cookieを使うやり方にはいくつか問題があります。たとえばXSS脆弱性やCSRF脆弱性などです。

CookieにSecure属性やHttpOnly属性をつければ安全性はいくらか高まります。ただ、Authorizationヘッダーを用いる場合JavaScriptを用いることになるのでHttpOnly属性をつけられません。つまりXSS脆弱性が残ってしまいます。

### 4.4 localStorage

[Web Storage API](https://developer.mozilla.org/ja/docs/Web/API/Web_Storage_API)のlocalStorageを使うやり方です。これもCookieと同じくJavaScriptから操作可能なので、XSS脆弱性が残ります。また、localStorageには『[HTML5のLocal Storageを使ってはいけない](https://techracho.bpsinc.jp/hachi8833/2019_10_09/80851)』で書かれているようないくつかの問題点もあります。

以上、いずれの場合もクライアントとサーバーのやり取りに**HTTPSで通信する**のは必須ですね。HTTPだと通信が見えてしまうので、アクセストークンが盗まれる可能性があります。

また、CookieやlocalStorageを使う場合は**有効期限を短くしてリスクを下げる**などの対策が必要だと思います。

## ユーザー認証の設計例
:::trouble
ユーザー認証についてだいたい分かったけど、長くて頭が混乱してきた。一度整理してほしいな。
:::

記事のはじめにも書きましたが、ユーザー認証を設計する上で決めるべきこととして、次の4つがあります：

| 順番 | 項目 | 選択肢 |
| :-: | - | - |
| 1 | **認証方法をどうするか** | パスワード認証、OpenID Connect |
| 2 | **アクセストークンをどう管理するか** | JWT |
| 3 | **アクセストークンをどう引き回すか** | Authorizationヘッダー、Cookieヘッダー|
| 4 | **アクセストークンをどう保持するか** | OS標準のストア、メモリ、Cookie、localStorage |

この4つについて、どう選択すればいいのでしょうか。これはソフトウェアの種類や事業のステージなどによって異なりますが、いくつかの例をとおして見てみます。

### ケースに応じたユーザー認証の設計例

たとえばフルスタックなWebフレームワークを用いて、APIを使わないWebアプリケーションを構築するケース。この場合は**パスワードで認証**し、**Cookieヘッダー**でリクエストします。**JWTは使わず**、アクセストークンはクライアントの**Cookieに保持**します。

SPAでサーバーはAPIとしてのみ利用する場合は、**OpenID Connectで認証**し、**Authorizationヘッダー**でやり取りします。アクセストークンは**メモリ上**に保持します。

ネイティブアプリかつユーザー基盤を自前で構築する場合は、**パスワード認証**をしつつ**JWT**でやり取りします。リクエストは**Authorizationヘッダー**を用い、KeyChainやKeyStoreといった**OS標準のストレージ**を利用します。

## まとめ
長くなってしまいましたが、ユーザー認証を設計するための基本的な知識はだいたい書けたかと思います。

OpenID ConnectやJWTなど、実際に開発する上でもっと深く掘り下げなければならない知識はあると思いますが、この記事がユーザー認証を実装するときの参考になればうれしいです。

この記事では、Webアプリケーションやネイティブアプリでのユーザー認証の仕組みや方法を説明した上で、どの方法がいいのかをケースごとに見ていきます。

ユーザー認証のイメージ

ユーザー認証とは。Web、APIでの認証の仕組みと認証方法

:::trouble
システムに障害が起きちゃった！ どうすればいいの？
:::

:::smile
障害が起きたときのために、どう障害対応をすればいいか学んでおきたいな。
:::

といった悩みに記事でお答えしていきます。

この記事を読むことで、**障害が起きたときの業務フロー**を学ぶことができます。実際に障害が起きたときに見ながら対応することで、復旧につながっていきます。また、障害が起こらないための準備についてもまとめています。

私は上場企業やスタートアップなどでBtoBやBtoCのシステムを開発・運用してきました。ここで経験した障害対応得た知見をもとに、記事としてまとめています。

:::note
### この記事の前提

この記事では、Webサービスやモバイルアプリの障害対応を想定して書いています。他の領域における障害対応でも参考になるかもしれませんが、当てはまらないこともあることをご承知おきください。

また、想定している読者の方としては、エンジニアとしての実務経験が1〜3年目の方としています。
:::

## 障害対応とは
:::wonder
そもそも障害対応ってなに？
:::

障害対応とは、『**システムに障害が起きたときに、正常な状態に戻すための対応のこと**』をいいます。ここでいう障害とは、なんらかの問題が起きたときに『今すぐ対応すべき』と判断したものを障害としています。

## 障害対応の業務フロー
障害対応の業務フローは、次の7つのプロセスからなります：

| 順番 | 項目 |
| :-: | - |
| 1 | **関係者への周知** |
| 2 | **体制構築** |
| 3 | **ユーザへのフォロー** |
| 4 | **復旧** |
| 5 | **復旧の共有** |
| 6 | **再発防止** |
| 7 | **関係者への共有** |

上のプロセスのうち、復旧までにかかる時間をできるだけ短くすることが大切だといえます。障害の大きさによらず、3の『ユーザへのフォロー』までは**努力次第で確実に早くできる**ので、そのための準備をしておくといいですね。

私もそうでしたが、運用の経験がない方にとっては障害対応=4の『復旧』だと思いがちだと思います。ただ、復旧は障害対応の一部に過ぎません。上の7つのプロセスをしっかりと押さえておきましょう。

:::info
### システムの復旧は障害対応の一部に過ぎない

障害対応において、システムの復旧はもちろん重要な要素です。ただ、その前に関係者への周知や障害対応の体制構築、ユーザへのフォローなど、確実に行っておきたいプロセスがあります。まずはプロセス全体を把握しておきましょう。
:::

## 1. 関係者への周知
それでは障害対応についてひとつずつ見ていきます。まずは関係者への周知についてですね。このプロセスでは、**システムに関わるメンバーに障害について周知**します。とくに、2の『体制構築』に関わるメンバーには確実に共有できるようにします。

周知の方法については、社内で使っているチャットツールなど、全体に通知できる方法を用います。書く内容としては、次のような項目がいいでしょう：

* 障害の内容
* いつ発生したか
* 原因はなにか
* 影響範囲
* 障害対応にあたるメンバーおよびリーダー
* 対応内容
* 完了目処

周知の段階で、わからないことは一旦未定でいいと思います。障害対応に進捗があったとき、必要に応じて随時周知を行います。

## 2. 体制構築
障害対応を行うための体制を構築します。たとえば次のようなメンバーで構成します：

* ユーザとのフロントに立つセールスやカスタマーサクセスなどのメンバー
* 技術的な復旧対応にあたるエンジニア
* その他、影響範囲を確認したり、状況を関係者に報告する、ドメイン知識が豊富なプロダクトマネージャなど

障害対応における体制構築において大切なことは、**ひとりで解決しようとしないこと**です。複数人で行えば、後述する復旧対応を複数の視点から行えます。一方で復旧を間違えると二次、三次の障害が発生し、被害が拡大してしまいます。

なにより、障害対応はやることがたくさんあります。個人開発などひとりでしか行えないケースを除いて、複数人であたるようにします。たとえば『[インシデント指揮官トレーニングの手引き](https://yakst.com/ja/posts/5588)』では『インシデント指揮官』をはじめとする4つの役割で障害対応にあたるとしています。

## 3. ユーザへのフォロー
障害対応にあたる体制を構築したら、まずは**ユーザにフォローを入れます**。フォローを入れる方法としては、障害の種類や影響範囲、プロダクトの種類に応じて次の中から使い分けます：

* システム上にメッセージを掲載する
* メールで通知する
* 電話などで個別に連絡する

## 4. 復旧
復旧は、システムを問題なく使用できるようにすることを目的とします。復旧は次のようなプロセスになります：

1. 復旧のゴールを決める
2. 情報を収集する
3. 調査する
4. ソースコード等の変更を行う
5. 変更を適用する

障害対応における復旧の最終的なゴールは、障害が起こる前の状態に戻すことです。ただ、復旧には時間を要する場合もあります。このときは、**暫定的なゴールとしてひとまず問題なく使える状態**にします。

次に情報を収集します。発生した障害を体験したユーザにコンタクトが取れる場合は、情報をヒアリングします。このときユーザのアカウント情報を得ることで、後述する調査のときにログ等と照らし合わせることができます。

### 障害を調査する

情報収集と合わせて調査を行います。障害対応の起点となるのはエラー監視ツールによる通知の場合が多いと思いますが、まずはエラー監視ツールを見て、問題を切り分けます。

切り分けた対象を元にリソース監視ツールやプロセス監視ツールを確認し、障害の要素を見つけます。また、関連するログも見ます。アプリケーションやサーバ、それぞれのアクセスログやエラーログなどを見ていきます。

このとき、**障害が発生した時間やユーザのアカウント情報と照らし合わせて確認する**ことで、原因を突き止めやすくなると思います。

調査して原因がわかったら、ソースコード等を変更し適用します。このとき、データの変更などで本番環境に負荷がかかる場合があります。必要に応じてメンテナンスモードへの移行やバックアップ、リストア手順の確認などを行います。

## 5. 復旧の共有
システムの障害が復旧したら、あるいは復旧のメドが立ったが時間を要する場合にも、ユーザに共有します。これも3の『ユーザへのフォロー』と同じ考え方で行います。

## 6. 再発防止
システムが障害から復旧できたら障害対応は終わり、ではありません。**なぜ障害が起こったのか、再発しないためになにをするか**を決めていきます。たとえばインスタンスのサイズを上げたり、レビューのプロセスを改善する具体的な方法を決めたりします。

障害対応のプロセス自体に問題があったときも、再発防止策として改善したいですね。

## 7. 関係者への共有
**再発防止の内容を元に、今回の障害について関係者に共有**します。同じ障害が起きない安心感を与えたり、似た障害が起きたときに再度報告してもらうことにつながります。

また、障害対応のプロセスに問題があったときに、第三者の目から見て客観的に問題を指摘してもらい、次につなげることができます。

:::convinced
障害対応って、調査と解決以外にもやることがたくさんあるんだね。実際に障害が起きたら、焦らずまわりに協力してもらいつつ、ひとつずつやっていこうl
:::

## システムに障害を起こさないために
この記事では障害対応の業務フローについて書いてきましたが、そもそも障害を起こさない方がいいですよね。そのために重要なのが：

* コードレビューを行う
* 自動テストを導入する
* 運用監視ツールを導入する

などです。変更しようとするソースコードに問題があったとき、ソースコードレビューや自動テストの実行で検出することができます。また、運用監視ツールでは急激なアクセスの増加などで問題が起こりそうなときに、前もって検出することができます。

この3つについては次の記事でも説明しています。あわせてご覧くださいね：

:link{slug=how-to-do-source-code-review}

:link{slug=how-to-create-test-cases}

:link{slug=what-is-server-operation-monitoring}

## まとめ
障害が起きたときの業務フローについて書きました。システムに障害が起きたら、ひとりで焦って対応せずに、関係者への共有からひとつずつやっていきましょう。また、運用監視ツールの導入など、障害が起きないための準備もしておきたいですね。

この記事を読むことで、障害が起きたときの業務フローを学ぶことができます。実際に障害が起きたときに見ながら対応することで、復旧につながっていきます。また、障害が起こらないための準備についてもまとめています。

障害対応のイメージ

障害対応の業務フロー。システム開発における障害対応の手順、体制

:::wonder
管理画面を開発することになったけど、どう作ればいいの？ デザインの記事は見つかるんだけど。どう設計すればいい？ 必要な機能ってなに？
:::

という悩みについてお答えしてきます。

この記事では、**管理画面を設計する上でなにを考えればいいか**、指針をまとめていきます。また、プロダクトのフェーズにおける管理画面の考え方についても整理します。

この記事を読むことで、管理画面の作り方がよくわからない状態から、どう作りはじめればいいかがわかるようになると思います。

私は上場企業やスタートアップなどで20以上のプロダクトを作ってきました。そのすべてに管理画面をもっていました。たくさんの管理画面を設計・開発した経験をもとに、この記事を書いています。

## 管理画面とは
:::trouble
そもそも管理画面ってなんなの？ なにをする画面なんだろう。
:::

管理画面は、『**プロダクトの運用を目的としてデータを管理するための画面**』のことをいいます。基本的には運用者のみがアクセスや操作を許されていますね。

管理画面を作る上で、まず『利用者』と『目的』のふたつを押さえておくことが大切です。

### 管理画面の利用者

管理画面の利用者には、大きく分けると：

* 運用者
* ユーザ

のふたつの役割がいます。ユーザとは、たとえばブログサービスにおける投稿画面のようなイメージですね。この記事では、前者の『運用者』が使う管理画面について書いていきます。

### 管理画面の目的

また、管理画面の目的には、大きく分けると：

* オペレーションのため
* データ分析のため

のふたつがあります。この記事ではどちらもふまえますが、どちらかというと前者のオペレーションを目的とした管理画面について書いていきます。

:::info
### まとめ：管理画面とは

管理画面は『プロダクトの運用を目的としてデータを管理するための画面』です。管理画面を設計する前に、まず利用者と目的を明確にしておきましょう。
:::

## 管理画面の設計指針
:::smile
管理画面についてはなんとなくわかったよ。じゃあ次にどう設計すればいいのかについて教えてね。
:::

では、管理画面をどう作ればいいのか、なにを考えて作ればいいのかについて書いていきますね。これはプロダクトの種類について変わってくるので、ここでは共通する普遍的なことについてまとめます。

まず表にまとめて、それからひとつずつ見ていきます。

| 番号 | 設計項目 |
| :-: | - |
| 1 | **認証をどうするか決める** |
| 2 | **認可する対象を決める** |
| 3 | **テストを書く** |
| 4 | **監査用のログを記録する** |
| 5 | **自動でバックアップを取る** |
| 6 | **機能を決める** |
| 7 | **体験を決める** |
| 8 | **デザインを決める** |
| 9 | **外部サービスの利用を検討する** |

### 1. 認証をどうするか決める

まず認証をどうするか決めます。GoogleやSlackなどのアカウント連携がよさそうですね。どのアカウントを使うかは、**組織が利用しているプラットフォームに応じて**決めればいいです。

あとは、IPアドレスによる制限をかけるなど、他の手段とあわせて認証するとセキュリティが強化されます。

実装がラクだからといって、プロダクト本体のユーザ基盤を利用してしまうと、セキュリティの担保が難しくなったり、管理画面がプロダクト本体と密結合になってしまうので、基本的には避けた方がいいと思っています。

### 2. 認可する対象を決める

次に**認証した運用者の役割によって許可する操作を分けていきます**。たとえばアルバイトや業務委託の方など、アクセスしていいデータが変わってくることがあるので、これを分けます。

やり方としては、まず管理画面上の操作の一覧をスプレッドシートなどに書き出し、許可する役割をセットで書いておくことで、実装しやすくなります。テストも書きやすくなりますね。

### 3. テストを書く

管理画面は大切なデータを扱う画面です。不具合があってデータに不整合が起こってしまうと大変なので、当然ですがテストを書きましょう。テストを自動で実行し、不具合を検出できる環境も作っておきます。

### 4. 監査用のログを記録する

誰がいつどんな操作をしたのかを記録します。組織によっては必要になるので、**事前に確認しておきましょう**。

### 5. 自動でバックアップを取る

システムのバグや操作ミスなどでデータが意図しない形になってしまったときに、もとに戻すためにバックアップが必要になってきます。管理画面がなくても必要ですが、念のために項目として書いておきます。

### 6. 機能を決める

管理画面にどんな機能を作るかを決めていきます。管理画面といっても、通常のプロダクト開発と同じやり方で作ります。つまり、基本的には『それがないと成り立たない機能のみ』を作ります。

作るだけではなく、使わなくなった機能はどんどん消していきましょう。これについては『[プロダクトに機能を追加するかどうかを判断する方法](https://product-development.io/posts/how-to-determine-whether-to-add-feature-to-product)』で詳しく説明しています。

:link{slug=how-to-determine-whether-to-add-feature-to-product}

### 7. 体験を決める

体験とは操作をしたときのメッセージ表示やアラートの出し方などですね。運用者もユーザと同じで、**マニュアルに書いたところで操作ミスなどは必ず起こります**。このミスができるだけ起きないよう、メッセージの出し方やアラートを出す基準を決めましょう。

### 8. デザインを決める

どんなデザインにするかを決めます。管理画面のデザインにはコストをかけられないかもしれませんが、見た目がよくないと運用のモチベーションに影響してきます。これって結構大切だったりします。

CSSフレームワークなどを使って、最低限の見た目は整えるようにしたいですね。

### 9. 外部サービスの利用を検討する

機能を作ることは負債であるという認識をもつことが大切です。たとえば分析は[Redash](https://redash.io/)を用いるなど、できるだけ外部サービスを利用するようにしましょう。

## プロダクトのフェーズに応じた管理画面
上で管理画面の設計指針についてまとめました。ただ、**管理画面の作り方はプロダクトのフェーズによっても変わってきます**。とくに、Product/Market Fitの前後で変わります。

### PMFをめざしているとき

PMFをめざしている段階では、日々変化するプロダクトに対応できるよう、オペレーションをまわしていく必要があります。このための**開発スピードがなにより大切**になってきます。

開発スピードを優先するために、管理画面を作るためのフレームワークなどを用いることを検討します。

### PMF達成後

PMFを達成したということは、ある程度オペレーションが固まったことを意味します。この段階では長期的な運用を見据えて、**自前で管理画面を作る**ことを検討します。

PMFをめざす過程では機能の追加・削除が繰り返されると思います。汚くなった機能やソースコードを一度整理するのもこのタイミングがよさそうですね。

## 管理画面に対する基本的な考え方
管理画面は、基本的にはプロダクトと同じです。**ユーザ=運用者が抱える課題を解決するため**に、管理画面を作ります。

このため、誰が運用者なのか、運用者はなにを解決したいのか、どう解決するのかを、ひとつひとつ検証しながら作っていくべきです。つまりリーンスタートアップの考えに基づいて作っていきます。もちろん、一度作って終わりではなく、継続的に開発していく必要がありますね。

:::convinced
管理画面はプロダクトのフェーズに応じて作り方を変えることが大切なんだね。プロダクトと同じように作る、というのも分かったよ。
:::

## まとめ
管理画面は主にオペレーションのために運用者が使う画面です。運用者をユーザととらえ、リーンスタートアップの考え方に基づいて作っていくことで、よりよい管理画面になっていきます。

管理画面を作るときはプロダクトのフェーズに応じた作り方をすることで、小さいコストで作っていけます。

この記事では、管理画面を設計する上でなにを考えればいいか、指針をまとめていきます。また、プロダクトのフェーズにおける管理画面の考え方についても整理します。

管理画面のイメージ

管理画面を開発するときの設計指針。ゼロからわかる作り方

Web APIのための規格。
APIリクエストのためのクエリ言語と、APIの仕様を記述するためのスキーマ言語からなる。
必要なリソースのみをクエリに記述するため、結果が予測可能となる。
またひとつのリクエストで多くのリソースを取得できるため、ネットワーク接続が遅い環境下に対応しやすい。

GraphQL

Webページの情報を提供するための標準化されたデータ形式。
Googleがページをクロールする際、より正確に情報を収集できるようになる。
また検索結果に画像などのコンテンツを表示できるようになる。

構造化データ

アプリケーションの実行モデルのひとつで、サーバの運用が不要なモデルのこと。
イベント駆動により、実行に必要なサーバが立ち上がる。
従量課金制によるコスト削減や、サーバのアップデート・スケーリングといった管理が不要になるなどのメリットがある。
これにより開発者がプロダクトの価値向上にリソースを使うことができるようになる。

Serverless

「上位のモジュールは下位のモジュールに依存してはならない」という原則。
下位のモジュールに依存すると、モジュールが変更されたときに影響を受けてしまう。
各モジュールの間に抽象クラスを導入し、各モジュールはこの抽象クラスに依存することで、モジュールを疎結合に保てる。

依存性逆転の原則

「クライアントにとって不要なインタフェースに依存することを強制してはならない」という原則。
依存するインタフェースがふえると、インタフェースの変更による影響を受けやすくなる。
責務に応じてインタフェースを分けるよう設計する。

インタフェース分離の原則

「サブクラスはスーパークラスに置き換え可能であるべき」という原則。
置き換えられないということは、つまりサブクラスへの知識をもつということ。
これは密結合の原因となってしまう。
スーパークラスの知識のみをもち、サブクラスは置き換え可能であるように設計することで、クラスを疎結合に保てる。