この記事はGoodpatch Advent Calendar 2022の7日目の記事です。
オンラインホワイトボードStrapの開発を担当している、フロントエンドエンジニアのあげです！
みなさん、設計って得意ですか？なかなか設計通りに実装するのって難しいですよね。
Twitterでも、「コード書いてみないと設計書を作れない」という話題を見ました。自分はわりと苦手です…
- 「よし、完璧だ！」と設計したはずなのに、いざ実装すると計画通りに進まなかった
- 逆に詰めたわりに、呆気なく終わってしまった
- 反省して次に活かそう意気込んでも、やっぱり計画通りに進まなかった
こんな経験ある方、多いのでは？と思います。
この問題の解消のために、「テクニカルプロトタイプ」を試してみました！
テクニカルプロトタイプとは？
- チーム内で価値検証
- ユーザーテストなどで顧客検証
- 実現可能性
- パフォーマンス
- 具体の利用技術
- 開発スコープ、タスク切り出しのための情報収集
などの場面で特に効果を発揮する、「最終成果物の試作品を早い段階から作り、改善を繰り返す手法」のことです。
一般的なメリットや手法については、弊社のこちらのブログにまとめられています。 今回は個人の感想をメイン書きます📝
感じたこと
「ゴールが明確なら、設計も実装も工数削減できて、要件もスッキリして、結構ラク」
と感じました。この感想が、当記事の結論です、ありがとうございました！
…お時間ある方はもう少しだけお付き合いください🙏
考察
なぜ工数削減ができるのか？ゴールを明確にする必要があるのか？
認識のブレを減らすため、あらかじめ私が使う言葉の定義を明確にしておきます。
ゴール
テクニカルプロトタイプの完了条件。
「〇〇を達成したらテクニカルプロトタイプを終了する。」
設計
本来は目的を具現化するための準備・検討全てを示すが、今回は文字・図による説明に絞る。
「きちんと設計したのに、コードで実現できなかった。」
実装
リリース可能な製品をつくる行為。
「テクニカルプロトタイプを行なってから、実装に進みます。」
テクニカルプロトタイプは、設計と特性が逆
まず設計とは何のために行うのでしょうか？ 大別すると以下の２つだと考えます。
- 将来の見通しを立てて、あらかじめ対策を打ちたい
- 少ない工数で、実装の大幅な手戻りを避けたい
1 について、素早く実装できても、セキュリティ・スケーラビリティ等の面で負債になる可能性があります。その回避として設計が必要なケースがあります。ポイントは「未来志向」というところです。
2 について、前提が間違っていた場合、実装ほぼ全てがやり直しになる可能性があります。実装より少ない工数で調査することで、手戻りを減らせます。ポイントは「実装より少ない工数」です。
以上のことをまとめると、設計とは、未来の可能性を広げ、少ない工数で大きな失敗を避けるメリットがあります。デメリットは上記をほぼ逆にしたもので、検討する可能性を多岐に広げ、実装ほどの情報は得られないという点です。
これに対してテクニカルプロトタイプは、
検討すべき可能性を絞り、実装と同等のフィードバックが得られる特性があると考えます。
テクニカルプロトタイプのメリット
検討すべき可能性を絞れる
設計を進めていくと、様々な可能性が見えてきます。それ自体は悪いことではありませんが、時間が限られているので、全てを網羅することは不可能です。また厄介なのは、設計段階ではYES・NOで割り切れない問題が意外と多いということです。これらは時間さえかければ限りなく正解に近い答えを見つけられそうですが、仮に実装と同等の時間がかかるなら、実装した方がいいです。
よって結果的には、実装に対してかなり少ない時間で、多岐な可能性を検討しなければなりません。ここが設計の難しいポイントだと考えます。この難しさの解消には、テクニカルプロトタイプが効力を発揮します。
テクニカルプロトタイプは、実際に実装することによって、その難しさや曖昧な要件を明確にできます。「Aは簡単だと思ったんだけど、やってみたら影響範囲が広すぎて、全体的に修正がいる」「Bの対策は難しいのだけれど、そもそも問題が発生する可能性がすごく低かった」「Cのデザインもアリかと思ったけど、テクニカルプロトタイプ触ってみたら使いづらかった」などなど、作ったり使ったりしてみて初めてわかることもたくさんあります。なるべく早く失敗して可能性を潰すことで、設計をより洗練されたものに、実装の工数をより少なくできます。
コードからフィードバックをもらえる*1
コードを書くと、何かしらのフィードバックがあります。それはエラーであったり、実行速度であったり、行数であったり、様々な形で現れます。エンジニアはそれらを元に難しさや可能性など、良し悪しに気づいたりします。テクニカルプロトタイプにはこういったプロセスが存在しますが、設計にはここが抜けています。先ほど述べた設計の難しさは、この点から来るものもたくさんあります。実装ほど工数をかけず、テクニカルプロトタイプによってこのフィードバックだけ先取りしてしまうのは、大きなメリットだと思います。
テクニカルプロトタイプのデメリット
共通認識を関係者と持っておく必要がある
テクニカルプロトタイプは、実装より少ない工数で、実装と同じようなプロセスで動くものを作るので、基本的には何かしら欠陥や劣っているポイント・要件漏れがあるはずです。それらがあること自体は当たり前の事ですが、共有される人は何が削られているか知りません。また、削るものによっては、検証自体が無意味になってしまう可能性があります。そのため、取り掛かる前とテクニカルプロトタイプ共有時に、関わるメンバーと共通認識を持っておかねばなりません。例えば、「この機能にはどんな市場価値があって、何を解決するものなのか？」「どういった体験を生んで、いつ・どこから使うのか？」などの前提共有の上、何をテクニカルプロトタイプとしてやる・やらない、などです。
「砂山のパラドックス」にハマりやすい
下記は砂山のパラドックスについてのwikipediaからの引用ですが、どの媒体でも同じような説明がされていると思います。
砂山から砂粒を取り去っても依然として砂山のままだが、それから何度も取り続けて、最終的に一粒だけが残ったとき、その一粒だけを指して「これは砂山である」と言えるのか、という問題である。定義や境界値が明確でなく曖昧な概念をどう扱うかという問題であり、主に論理学の哲学・言語哲学において問題になる。 wikipedia
大雑把に説明し直すと、「曖昧なものは、ずっと曖昧なまま」という意味です。テクニカルプロトタイプとは、「曖昧で未完成なものを作ってフィードバックを得ること」がゴールです。つまり、この曖昧なゴールを明確にしておかないと、いつまでも終わりは来ず、ダラダラとテクニカルプロトタイプをやる危険性があるということです。指摘するのが自身なのか、レビュアーなのか、いずれにしろ、「この程度じゃテクニカルプロトタイプにすらなり得ない。見せるならせめてもっとクオリティを上げないと…」となりがちです。テクニカルプロトタイプに完成はありません。もっと言えば、実装にすら完成はありません。バグの１つや２つは大体潜んでます。こちらでゴールを決めないと、完成は不可です。
仮に1時間の追加工数で、20%テクニカルプロトタイプのクオリティを上げられたとしましょう。しかし、潰せる可能性の数は1つに変わりません。クオリティを上げても下げてもほぼ同じです。どうせならその1時間で、「共有 → 再テクニカルプロトタイプ」のサイクルを回す方が価値があります。そのテクニカルプロトタイプは何を目的とするのか、何がわかったらゴールなのか、厳格かつ明確にしなければなりません。
結論
以上のことから、ゴールを明確にして共有しないといけないのは大変だけど、それさえでクリアすれば設計も実装も工数削減できて、要件もスッキリして、結構ラクと言えます😋
テクニカルプロトタイプと聞くと少し難しく感じますが、要はスポーツにおける練習と同じです。映像や本を見て学習するだけでオリンピックにぶっつけ本番で出場する選手はいません。みんな練習をして、賢く小さく失敗して学習します。エンジニアもテクニカルプロトタイプを作って練習すればいいと思います。もちろん、テクニカルプロトタイプだけが全てではないので、状況によって様々な開発手法と組み合わせればいいと思います！ 今回は「設計」の意味を限定しましたが、本来はテクニカルプロトタイプや実装も含めて「設計」です。多角的に設計しましょう！
最後に少しだけ宣伝させてください🙏
私が関わっているStrapというサービスは、職種年齢問わず、誰でもビジュアルを共有できるオンラインホワイトボードツールです。もちろんエンジニアの私も、説明もチュートリアルも見ず、簡単に作図することができます。今回の記事で作成した図は全てStrapで作ってます！実際に動くテクニカルプロトタイプはコードを書く方がいいと思いますが、それ以前のダーティプロトタイプには、Strapはおすすめです😉
*1:「コードからフィードバック」という表現は、動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α - t-wadaのブログから引用しています。
