プロトタイピングのコツ（9/12頒布予定の実践プロトタイピングより一章抜粋）

先日、告知した本の第一章からの抜粋です。本についてのリンクは後ほど追加します。

なお、この記事や本に書いているプロトタイピングは筆者の経験に基づくものなので、もっとうまいやり方があるかもしれません。もしご存じの方は筆者に教えていただけると、筆者がとても喜びます。

実践プロトタイピング 〜Webフロントエンド＆バックエンドでプロトタイピング〜：東京ラビットハウス

先日も述べた通り、プロトタイピングとは、手早く、実際に動く物を作って触りながらフィードバックを得て改良していくという手法です。

この記事ではそれらプロトタイピングにまつわるコツやテクニックを紹介します。

原則

プロトタイピングに限りませんが、手早く開発するための原則を幾つか挙げておきます。

同時に複数のことをしない

同時に複数のことをしないようにしましょう。

・ 新機能を開発する
・ 新しいライブラリを試す
・ 新しい書き方を試す
・ 新しいツールを使う

こういったことを同時にすべきではありません。

プログラミングというジャンルにおいて人間の脳はマルチタスクに適していません。擬似マルチタスクになってしまい、まず効率が落ちます。また、問題が生じたときに切り分けしづらいということも効率を落とす要因です。

いかにして、同時にやることを一つに絞り込めるかが大切です。

設定

調査や設定は意外にエネルギーを消耗します。特にプロトタイプを作ることに集中したいモードに入ろうとしているときに、設定という全く別の方向性のものに脳のリソースを奪われるのは望ましくありません。

対処方法としては、前述の通り、設定とプロトタイピングという2つの事を同時しない、分けるということです。業務時間内のプロトタイピングで、必要ならば設定のための時間を見積もって確保しておき、プロトタイピングとは別工数にすると良いでしょう。

理想を言えば、余裕のあるときにあらかじめ、設定関連を片付けておくといいでしょう。これはプロトタイピングに使える武器を常日頃から準備しておくということです。

一番ありがちなミスは、設定なんてサクっと終わるだろうと思ってハマるケースです。とてもよくありがちです。

そのためオススメするテクニックとして、そういうときはタイマーを活用しましょう。たとえば10〜20分くらいでタイマーをかけて作業を開始します。タイムアウトしたら、そこで、いったん諦める、方針を見直す、最悪なやり方でも採用する、自分の足りない知識を棚卸しする、気分転換するなど、といった見切りをつけるのです。

これは別に設定に限ったものではありません。何かしらのハマりそうな作業にはとても有効です。

ライブラリの調査

これも設定と同じですが、ライブラリ特有の解決策もあります。たとえば、CodeSandbox というウェブサービスがあります。これはテキストエディタと JavaScript が動くサンドボックスと呼ばれるもので、エディタで書いたコードがブラウザ上で動作するというものです。

このサンドボックスには npm もインストールすることができるため、試したいライブラリと、それが依存するものだけをインストールした最小限の環境を用意して、試したいコードを書いて動かすことで、ライブラリの調査ができます。

もちろん、ローカルで実験するというのでも構いませんが、ディレクトリの作成、コマンドラインで様々な操作、ファイルの書き換えなどを行うことになり、多少面倒です。また、CodeSandbox なら結果を共有することができます。

調査で大切なポイントとして、なるべくミニマムに実験することが望ましいです。

そのため、よほどの理由が無い限りは、開発中プロダクトのコードベースと、ライブラリ調査用コードベースは分離しましょう。場合によっては社内の謎ライブラリやフレームワークに依存するケースもあるでしょうから、完全に分離はできないかもしれませんが、ライブラリの調査であれば、大抵はサンドボックスを活用できるはずです。

できない場合は、自分がそのシステムの把握をしきれてないサインだと思った方がいいでしょう。把握できてない事を認めつつ放置するのも、システムを分解して最小要素が何か追求するのも、それぞれ選択肢として考えてもいいでしょう。

ツールの整備をしておく

たとえば筆者は VSCode を愛用しています。2020年時点でウェブ開発としては最善のエディタ（IDE）だと考えていますが、もちろん WebStorm や vim, Emacs などを愛する人もいるでしょう。

他にも、Linter（eslint）や書式の自動フォーマッタ（prettier）といったツールも活用しています。

* エディタ（IDE）で TypeScript の型チェックが走っていること
* エディタ（IDE）で補完ができること
* エディタ（IDE）でリファクタリングができること
* エディタ（IDE）で自動で Linter / フォーマッタ が走ること

プロトタイピングのようにリズム感を持って開発をする場合、特にこういった足回りの整備は重要です。これについてもこれまでに説明してきたことと同様に、同時にやらないように注意しましょう。

【コラム】 Linter やフォーマッタの重要性と非重要性

Linter や書式の自動フォーマッタの導入は必須です。もし入ってないプロジェクトがあれば、最初にこれらを導入できないか検討すべきですし、もし導入できないようであれば、転職を検討すべきサインかもしれません。

tslint の開発が終了したので、2020年の JavaScript/TypeScript 開発では eslint 一択です。もしかしたら2022年頃には Rome 一択という時代が来ているかもしれませんが……。

書式の自動フォーマットは2020年時点では prettier 一択です。

さて linter やフォーマッタを導入するときに話題になることが、その設定です。

設定は非重要なものです。

設定にこだわる時間は何も生み出しません。凝った設定をしても、リーダビリティ（読みやすさ）やメンテナビリティ（開発しやすさ）にはほぼ貢献しません。

linter やフォーマッタを導入することそのものが最重要であり、設定は好みとか気分だけで決めればいいでしょう。問題がなければデフォルトの推奨ルールを使えばいいでしょう。

方針としては、ゆるめな方向で設定すると良いでしょう。無駄に linter に沿って、リーダビリティを落とすよりはよほどいいです。

設定をすることよりも、導入することで得られるメリットの方が遙かに大きいことと、大抵の場合は設定の詳細を議論しても、自転車置き場の屋根議論と呼ばれるような「それは好みだね」といわれるタイプの議論にしかなりません。

好みであれば、チームリーダーなりテックリードなり、誰かがエイヤで決めちゃって良いのです。

たとえば一時間も二時間も「この設定はどうする？」みたいな議論を頑張ってもリーダビリティ・メンテナビリティへ貢献しません。

フロントエンドのプロトタイピング

プロトタイピングでは、画面モックや、動き、パーツから作るという手段があります。

これに必要な知識は最低限の HTML です。もちろんデザインを度外視しないのであれば CSS の知識も必要でしょう。コンポーネントに落とし込む時点で JavaScript/TypeScript + React などの知識も必要になります。

・ 画面全体を HTML + CSS で作る
・ 画面の一部を HTML + CSS + JS で作る

このとき、誰かがデザインした資料や、デザインツールのデザイン画面があれば、それを HTML + CSS に落とし込むことになりますが、そういったものがないケースもあります。

その場合、デザインツールに慣れていなければ、まずはペンと紙、あるいはタブレットなどを使い、手書きで雑に絵を描いてみましょう。

動き中心で作りはじめるなら

画面遷移や動き中心で作り始めることもできるでしょう。たとえば、最小限のボタンや input 要素などを配置して、JavaScript で動きを付けます。

このやり方は最速で動く物に到達できる反面、見た目がショボすぎるという問題があります。人間はある程度デザインに縛られる生き物なので、抽象化されすぎた UI よりは、多少でもイケてるUIを好みがちです。

プロトタイピングを見せたい相手が許容できるなら、デザインは最小限であることを伝えておいて、動きだけを見せることもできるでしょう。

ただ、どうしても完成品とのイメージの差は大きくなりがちなので、早めに、CSS の装飾などを付けるべきでしょう。

型定義から始める

やりとりするデータが分かっている場合は、そのデータを表現する型を書き始めてみましょう。

// 著者
type Author = {
  id: number
  name: string
}

// 記事
type Article = {
  author: Author
  tags: string[]
  subject: string
  content: string
}

この TypeScript の型定義は、記事と記事の著者のそれぞれの型です。重要なことは「記事という型」「著者という型」にそれぞれ名前がついてアクセスできることです。最初から完璧なものを作る必要はありません。

必要に応じて追加・削除・変更は、いくらでも可能ですし、それによって影響を受ける範囲は全部 TypeScript コンパイラが教えてくれます。

データの型があれば、コンポーネントの引数の型として渡すこともできます。コンポーネントに id name tags subject content を渡すのと、author article を渡すのであれば、後者の方が圧倒的にメンテナンスしやすいです。

TypeScript のパワーを最大限活用していくと、安全かつ高速な開発に近づきます。

【コラム】 型駆動開発

プロトタイピングにおいて型はとても便利です。

型定義さえしっかりしてあれば、多少テキトーに直感でコードを書いても大体なんとかなるからです。足りないものはエラーとして現れてきますから。

イマドキは VSCode が優秀ですし、型定義さえしっかりしてあれば、大抵なんとかしてくれます。

レイアウトに慣れておく

何かしらのウェブアプリや GUI を開発する場合、大抵ネックとなるのがレイアウトです。

ヘッダ・サイドバー・フッターみたいな構造、スクロールしない領域とスクロールする領域、そういったものをデザインすることがとても多い割には、ウェブ技術のレイアウトは、CSS でもとても面倒なものの一つです。そしてより悪いことに、画面の見た目のうちレイアウトはとても大切です。

・ UI ライブラリのレイアウト機能を使う
・ Flexbox レイアウトを使う
・ Grid レイアウトを使う

UI ライブラリが使えるなら、それの持つレイアウト機能を使うといいでしょう。実際にはそれらは Flexbox などを使って実現されているのですが、ラッピングされて使い勝手はある程度は良いはずです。

Flexbox と Grid レイアウトはそれぞれ得手・不得手に違いがあります。Flexbox は一次元レイアウト、Grid レイアウトは二次元レイアウトに強いです。

Flexbox レイアウトはとても現実的な手段です。多少癖があり面倒くさいところもありますがさっくり使えるという利点と、IE とかでも polyfill で対応可能な点が良いところです。

Grid レイアウトは二次元レイアウトをするときにはとても使いやすいです。IE でも一応利用できますが、一部機能に問題があるようです。

ある意味 Grid レイアウトは、大は小を兼ねるところがありますが、Flexbox の使い勝手の良さもあります。

Flexbox と Grid レイアウトをそれぞれ使い分けできると良いでしょう。時間があるうちに、どちらも試しておくのが望ましいです。

どれを使うにせよ、よくあるパターンをまとめたチートシートや、サンプル集を手元に用意しておくべきです。そうでなければ、毎回ググるハメになり、開発効率を落とす原因になります。

バックエンドのプロトタイピング

バックエンドのプロトタイピングのうち、型定義の話は既にしてあるので省略します。

関数やクラスから作る

TDD（テスト駆動開発）をすると良いでしょう。テスト駆動開発は名前に「開発」とついていて、実装にもまたがっていますが、基本は設計のための技法です。

たとえば関数を作るとして、その関数のインターフェース（入出力）はどうあるべきか？を実際に、実コードとテストをそれぞれ書きながら決めるための技法だからです。

ちょうどプロトタイピングと同じです。実際に動くコードや、動くテストを書きながら、あるべきインターフェースについて決めるのです。

TDDでは100%を目指すこともできますが、完璧ではないがちゃんと動く物を手早く作るための、設計技法として使うのが望ましいでしょう。ここらへんは求めるもの、段階によって使い分けると開発力を大きく上げることができます。

データから作る

SQL文を書いてみる、データを入れる、実際に取得するSQLを投げてみるなどをやってから決めていくという考え方もあります。

今回使う、Hasura GraphQL Engine はちょうどそのようなやり方に適しています。PostgreSQL の SQL そのものを投げてもいいですし、GUI からテーブル追加、カラム変更その他を操作などすれば、RDB の定義を元に、GraphQL API の情報をほぼ勝手に設定してくれます。

RDBでテーブル定義やデータを入れれば、GraphQL のクエリを投げてデータを取得できるようになります。

容易に改修できるようにする

プロトタイピングは、手早く作ることと、フィードバックを受けて改修しなければいけないため、容易に改修できるようにしなければいけません。

型はとても重要

型さえがっちり書いておけば、改修は容易になります。ちょっとやそっとの改修程度では壊れないようになります。

JSDoc を書く

不完全でもいいので JSDoc を書きましょう。最低限、その関数・コンポーネントの意図、引数の制約などを書いておくべきです。

型情報のようなものはどうせ TypeScript で型アノテーションを付けてるはずなので不要ですが、型で表現できない情報は自然言語で記述するのが望ましいでしょう。

チームメンバーが同じコードを触るときに効率が段違いになるという面もありますが、一人でプロトタイプを作る場合でも JSDoc を書いておけば、あとで別の場所からそのコードを呼び出すようなときにエディタの機能で、ドキュメントが表示されて便利です。

ローカルのみで使われてるものに JSDoc を付ける優先度は低いですが、色々なところから参照されているものなんかは優先的に JSDoc を付けるべきです。

作り捨てられる気持ちを持つ

1・2日で作れるわ、くらいの気持ちで作り、維持しましょう。いつでも捨てられるという気持ちがある方が精神の安寧を保てますし、なによりフィードバックをくれる人にも「すぐ作り直せるんで、根本的な指摘でもOKですよ」とアピールしておかないと、プロトタイピングの意味がありません。

実際に1・2日で作れる範囲を超えている場合は、プロトタイピング自体を軽く済むように仕様を調整できるならした方がいいでしょう。

一度書いたコードを消したくない、消す・書き換えることに、心の抵抗を感じる場合は、何かしらコード供養の方法を考えてもいいかもしれません。どこかにメモしておくとかです。

書いたコードの数だけ上達すると、筆者は信じています。

常時、リファクタリングをする

プロトタイプを作る工程では常にリファクタリングをしましょう。リファクタリングは、最初から完璧なものを作れないという人間心理に基づいたものですし、リファクタリングを怠ると、プロトタイプのコードは、いとも簡単に、誰も触りたくないようなコードになってしまいます。

プロトタイピングとリファクタリングは切っても切り離せないものです。

デザインドキュメントを書く

いわゆる設計書です。これも完全なものを書く必要はありません。簡単に Markdown で書いてリポジトリに `design.md` あたりの名前で入れておくといいでしょう。Excelを頑張る必要はありませんし、エビデンスも必要ありません。

・ 背景（なぜ作るのか？）
・ ゴール
・ 選択理由（なぜそれを選んだ？なぜそれを選ばない？）
・ 用語集
・ 大まなか構造
・ 大まかな設計思想

などをざっくり書いておくというものです。図はあると役立つかもしれませんが、必須ではありませんし、フォーマットに凝る必要もありませんし、殴り書きのようなものでも十分です。

どこかの段階でユニットテストを書く

プロトタイピングは作り捨てる気持ちで手早く作るものですが、プロトタイプとして作ったものが最終的に生き残るということも往々にしてあります。

そこで大切になってくるのが、リファクタリングとユニットテストで、前者に関しては既に説明済みなので、ここではユニットテストの大切さを解説します。

TDD でやっていない場合、プロトタイプの序盤でユニットテストを書くのは無意味になりがちですが、プロトタイプもある程度固まってきたら、ユニットテストを書いていくべきでしょう。

まだフロントエンドでは、ユニットテストが普及しているとは言いがたいですが、たとえばバリデーションスキーマ、一部のカスタムフック関数、ユーティリティ関数などといったもののユニットテストは書きやすいはずです。ある程度仕様が定まりつつあるコンポーネントのスナップショットテストや画像回帰テストなんかも有用でしょう。

誰でもアクセスできるようにデプロイしておく

プロトタイピングは、作ったものを実際に触ってもらわないと意味がありません。

ついつい「リポジトリに入れてあるからビルドして動かして試してみて！」といいたくなる気持ちはありますが、エンジニアですら、それを面倒くさがる人はいます。

そのためプロトタイピング中は開発・試験用の環境にデプロイするのが望ましいでしょう。コミットしたら自動でCI/CDが走ってデプロイまでしてくれれば理想形です。

次善策としては、ngrok などの、ローカルサーバーをグローバルに公開できるサービスを使うことです。ただし、なぜか重いというような謎のトラブルがあったり、ローカルサーバーを起動しっぱなしにするのは問題があることも多いでしょう。

経験の積み方

これもプロトタピングに固有の話ではなく、プログラミング全般に通じるものですが、プロトタイピングにおいても重要なので、ここに書いておきます。

最初から最後までの工程をやり遂げる

プロジェクトの作成から、実運用なりまでを一度やり遂げておくといいでしょう。序盤から終盤までに何をすればいいのかを把握できますし、序盤までもっていくために、最初のうちにしておいた方がいいことを肌感覚として掴めるようになります。

時間的余裕のあるうちに、技術を練習しておく

たとえばプロトタイピングが一週間でできあがったとしても、実際にはそれは、その一週間だけで出来あがったわけではありません。常日頃から、技術について習熟しているからこそできるのです。

この本でも取り上げている、React, Next, Hasura, GraphQL, SQL などのように、プロトタイピングに使えるフレームワーク、ライブラリ、仕組み、概念など、常日頃から習熟しておきましょう。

フロントエンドのコードも注意深く書かなければ、容易に動作が遅くなりがちです。どういうときに遅くなるのか？どうすれば速度が改善されるのか？という経験値を詰んでおけば、最初からアンチパターンを避けてコーディングできるようになるはずです。

暇のあるときにプロトタイピングやリファクタリング、TDD などの練習をしておくのもいいでしょう。

ふりかえりを活用する

ふりかえりといっても、KPT だの PDCA だのをやる必要性は全くありません。ふりかえりの達人になることが目的ではありませんし「同時に複数のことをやらない」の原則を思い出しましょう。

その日やったことを自然言語でメモに書き出す、図にする、得た資料リンク集（公式サイトや参考にしたブログなど）を作る、感想を書く、そんな程度で十分です。もちろん、これら全部をやる必要すらありません。

「今日はうまくいった。やったー！」だけでも十分です。

もしフレームワークを使うなら Fun Done Learn を採用するといいでしょう。

・ Fun は、今日楽しかったこと
・ Done は、今日やりとげたこと
・ Learn は、今日学びだったこと

この3つを意識して、メモを残すだけでも効果はばつぐんです。

もし、自分を省みたくなったら心の赴くままにやればいいのです。