Next.js, GraphQL, Hasuraのキャッチアップも兼ねてプロトタイピングに関する書籍（実践プロトタイピング 〜Webフロントエンド＆バックエンドでプロトタイピング〜 - 東京ラビットハウス - BOOTH）を読み進めていくにあたり、忘備録を残しておこうと思います。
ただ書き写すのではなくて、自分の言葉や解釈で書いていこうと思うので一部間違っている部分などがあるかもしれないので、気になる方はコメントもしくは僕のTwitterとかでDMいただければと思います。
では、始めていきましょう！（謎テンション）
プロトタイピングとは
そもそもプロトタイピングとはどんな意味か。
wikipediaにはこう書かれています。
プロトタイピング（Prototyping）とは、実働するモデル（プロトタイプ）を早期に製作する手法およびその過程を意味する。その目的は、設計を様々な観点から検証する、機能やアイデアを形にすることでユーザーから早めにフィードバックを得るなど、様々である。プロトタイピングはシステム設計工程の一部として組み込まれることも多く、それによってプロジェクトのリスクと費用を低減させると考えられている。反復型開発では1つ以上のプロトタイプが作られ、欠陥や問題が徐々に解決されていく。プロトタイプの改善が十分なされ、機能/堅牢性/製造の容易さといった設計目標に達したとき、製品としての製造が可能となる。
ジョブズの名言を拝借するとこういうことです。
「人は形にして、見せてみないと、本当に欲しいものが何なのかわからない」
言葉だけのコミュニケーションだとどうしてもすれ違いや齟齬が発生します。
言葉の曖昧さやによる解釈の余地の幅をなるべく少なくするための有効な手法の一つとして、プロトタイピングは用いられます。
プロトタイピングを始める時の注意点
手早く作成し、手早く捨てる
プロトタイピングはあくまで開発手法の一つであり、それ自体がゴールではありません。手早く作成して容易に捨てられるようにしておくのが本来のプロトタイピングのあり方です。また、改良を前提とし容易に変更をできるようにしておく必要もあります。
状況にもよりますが、プロトタイピングに多大な工数を見積もるのは適切ではありません。とはいえプロトタイピングを進める上で本筋とはズレた設定や調査検証で時間を取られることも考えられるため、設定や調査は最初から別工数として見積もるのが良いです。
同時に複数のことをしない
新しいライブラリを試してみたり、書き方を試してみたくなってしまうのは人の性というものでしょう。。。しかし、プロトタイピングにおいては、いかにやることを絞り込むかが大事です。本来人間の脳はマルチタスクに最適化されておらず、特にエンジニアリングにおいては問題が発生した時の切り分けがしづらくなってしまうことで効率が落ちてしまうというデメリットもあります。
プロトタイピングを始める時のパターン（フロントエンド）
プロトタイピングに限らず、新しくコードを書き始める時の起点として、いくつかのパターンがあります。正解があるわけではなく、その人の得意なことや、慣れていることなど、状況に合わせて選択すれば良さそうです。以下に起点パターンの例を挙げます。
Figmaなどのデザインベースから作成
デザインスキルがある人はFigmaで画面遷移などの設計から始めるのもありです。アプリケーションによってはFigmaベースでほぼほぼプロトタイピングが完結する場合もあります。
画面モックから作成
マークアップ言語（HTML, CSS）に慣れている人はHTML, CSSで側だけ作ってしまうのもありです。ブラウザの検証ツールでDOM構造を確認、検証し、後でコンポーネント構造に落とし込んでいきます。
動きやパーツから作成
デザインは最低限にして、JavaScriptで画面の遷移やボタンなどの挙動のみに重点をおいて作成する方法です。
注意しておくべきなのが、完成品とのUIイメージの差が乖離してしまうのは否めないので、状況に応じて、CSSで装飾したり、ユースケースとして可能であればUIライブラリなどを用いるなどの、対応の必要があります。
型定義から作成
propsやデータ構造、関数などの型定義から行う方法です。
React Component構造でプロトタイプを作成する場合、DOM構造が頻繁に変わるため、スナップショットテストの恩恵が得られないケースが多いため、型定義をきちんと行うことでプロトタイピング中のコード変化に対応しやすいというメリットがあります。
すみません、短いのですが今回はここまでです。
次はバックエンドのプロトタイピングと改修を前提とした開発についてまとめてみたいと思います！
PS. エンジニアになってからまともにアウトプットするのが初めてで、普段使わないエネルギーを消費しました。。。