見出し画像

プロトタイピングのススメ

この記事は2020/09/22までオンライン開催中の技術書典9で頒布中の「実践プロトタイピング 〜Webフロントエンドとバックエンドにまたがってプロトタイピング〜」のPR記事です。

A5判 160ページという超力作です。お試し版はなんと71ページ分収録です。

お試し版
Booth 頒布ページ
技術書典9 頒布ページ

僕がなぜこのような力作を執筆したくなったか?それはプロトタイピングのやり方を意外に知らない人が多いことが理由でした。

プロトタイピングがとても有用であること、プロトタイピングはコツさえ掴めば強い武器になること、それらをお伝えしたかったのです。

プロトタイピングとは何か?

プロトタイピングとは、手早く、実際に動く物を作って触りながら、他の人からのフィードバックを得て、よりよい物を設計するという技法です。開発工程としては設計に該当しますが、やっていることは設計と実装をまたぐものです。

さて、一般的な設計からの開発という流れの場合、アイデアや機能を机上で考えても細部が異なる、様々な制約から思っていたものとは違うものを作らざるをえないこともしばしばです。

「○○が欲しい」と口にしている人がいたとしても、実装されたら「実は思ってたのと違った」というようになってしまうケースが多いことを皆さんも体験しているのではないでしょうか?

It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.
[BusinessWeek, May 25, 1998]

これは、スティーブジョブズの名言で、ものすごく意訳すると「人は形にして、見せてみないと、本当に欲しいものが何なのか分からない」というものです。さらに源流をたどると、ヘンリーフォードが言った「もし顧客に、彼らの望む物を聞いたら、彼らは『もっと速い馬が欲しい』と応えていただろう」という言葉もあります。

そこでプロトタイピングの出番です。

プロトタイピングは、開発の一工程として作られるケースもありますし、リーン開発のようにMVP(概念検証ができる最小限のプロダクト)を作り、市場に問うというケースもあります。

ひとは言葉だけでやりとりをするとすれ違いがちです。言葉の曖昧さによって解釈の余地がそれぞれのひとで異なるためです。より具体的になればなるほど、議論は適切になります。

たとえば、言葉だけのやりとりよりは図を交えたやりとりの方がより正確でしょう。さらにいうと、図があっても動きがあるわけではないので、動きも含めたものであればより良いでしょう。

実際に動くことで、議論の曖昧さを排除するためにプロトタイピングがあります。

開発効率を下げるもの: 空中戦

開発現場で、その効率を下げるものとして、僕は空中戦を挙げたいです。

ここで言う空中戦とは,お互いの意見を文字にすることなく,ただ口頭だけで会議を行うことを指す。参加者の頭の上をお互いの言葉が飛び交い議論(戦闘)している様子が,まるで戦闘機が空の上で戦っている様子に似ているところから作られた造語である。確かに見た目には華々しい空中戦ではあるがそれで大勢が決することはない。

これは日経XTECHの[コミュニケーション編]空中戦をやってはいけないからの引用です。

僕自身、先日このような記事を書きました。

このときの記事では、何かしらどのような方法でもいいから、どこかに書くべきだということで、主に MURAL というオンラインコラボレーションツールなどを使って、実際に形にすることで、議論を空中戦にしなくて済むようにするという提案をいたしました。

プロトタイピングは、これの進化系です。

何かアプリ、サイト、そのようなものを作るとき、手っ取り早く、見た目がそれっぽくて、動きがあるものを見せる方が絶対分かりやすいはずです。

実際にプロトタイピング版を触りながら「あーでもないこーでもない」という生産的議論をしたいものです。

デザインだけだと分からなかった「あー、実際に動くように落とし込むとこうなっちゃうのか!」という気づきを得られます。

僕が今回執筆した本では、手早くプロトタイピング版を作る為のコツを徹底的に書きました。

この本を読んで練習すれば、きっとあなたも、プロトタイピングを武器として、開発効率を下げる空中戦を阻止できるようになるはずです。

また、この本ではプロトタイピングだからこそリファクタリングが重要であることなども書いています。得てしてプロトタイプは、後々ずっと使われ続けてしまう運命なのです。

・ リファクタリング
・ TypeScript による型定義
・ ユニットテスト
・ JSDoc (ソースコード内ドキュメント)
・ DesignDoc(いわゆる設計書)

これらをしっかり残せば、手早く作りつつも、後もメンテナンスができるプロダクト開発をできます。

秋の夜長、あるいはシルバーウィークのお供に是非、本書を読んでみませんか?

また、弊サークルの書籍以外にも色々な面白い技術書に出会える技術書典9を是非冷やしていってください。

きっと、あなたにあったステキな技術書にであることでしょう。

この記事が気に入ったらサポートをしてみませんか?