概要
こんにちは、クラウド会計のフロントエンドエンジニアをしている@IZUMIRUです。
今回は、実装する前に「調査としてテクニカルプロトタイピングを取り入れると良いぞ！」という話をします。ざっくり要約すると以下です。
- テクニカルプロトタイピングとは、本実装に近いコードで早期に動作するプロトタイプを作成し、技術的リスクや仕様、UI/UX の検証を効率よく進める手法
- この手法によって、課題を素早く洗い出し、設計や実装の優先順位を見直し、無駄な手戻りを防ぐ
- さらに早期にステークホルダーと認識を統一し、より価値あるプロダクト開発を促進する
- 成功のポイントは、 時間の制約を設けて不確実性の大きい順に注力し、チーム内の連携を強化すること
ぜひこの記事をご覧いただき「テクニカルプロトタイピング（TP）やってみよう！」と思っていただけると嬉しいです。
テクニカルプロトタイピング（TP）とは
本記事でいうプロトタイプとは Figma などのデザインツールで作成したワイヤーフレームではなく、フロントエンドを中心にコードを書いて動くものを指します。これを「テクニカルプロトタイピング（Technical Prototyping）」 と名付け、以降は 「TP」 と呼称します。奇遇にもGoodPatchさんのブログでも同じ名称が使われていました。
私のチームが提唱するゴールは 「不確実性を減らして適切な価値を素早く提供すること」 であり、何かしらの理由で見積もりが大きかったり見積もれなかったりという状況に対して、効果を発揮します。
いくつか手法を簡単に表で比較してみます。
| ワイヤーフレーム（デザインツール） | テクニカルプロトタイピング | 本実装 | |
|---|---|---|---|
| 工数 | 低 | 中 | 高 |
| 技術的リスクの解消 | ×（コードは書かない） | ○（本実装に近いコード） | △（不確実性が高いと、調査と設計と実装が一緒くたになる） |
| UI/UX の検討 | △（アプリやブラウザと差異がある） | ○（実際の操作感や動作確認が可能） | △（不確実性が高いと、調査と設計と実装が一緒くたになる） |
| コードの使い回し | ×（コードは書かない） | △（一部流用可能だがマージしない） | ○（高品質でマージされる） |
| デザインフィードバック | △（主に UI 観点のフィードバックが得られる） | ○（具体的な動作を示せるため UX 観点でもフィードバックが得られる） | △（得られるが、根本的なフィードバックだと手戻りが生じる） |
TP は、本実装に近いコードを書くため、技術的リスクの解消や UI/UX の検証を迅速かつ効果的に進めることができました。モックデータやシンプルなロジックで動くプロトタイプを早期に作成することで、技術的な課題や設計の不確実性を明らかにしつつ、仕様や UI/UX の仮説を検証します。これにより、設計や実装の優先順位の見直しを行い、完成に向けた道筋がよりクリアになります。
また動作確認を行うことができるため、エンジニア以外のメンバーでも直感的に理解でき、ステークホルダーからの具体的なフィードバックを得る際にも有効です。チーム全体での認識の統一も図りやすくなるため、受入基準の合意形成が進み、認識齟齬による手戻りやバグの発生を防ぐことにも繋がります。
成功させるポイント
TP は有用な一方で、いくつか気をつけるべきこともあります。これに対応できるかが成功するか否かを分けるポイントになると思います。
不確実性の高い順に注力する
あくまで本実装ではなく不確実性を減らすために行う手法であることを常に意識し、不確実性の高い順番にリスク解消に注力すべきです。最終的にはリリースできるコード品質を担保することになりますが、プロトタイプ時点でどこに時間をかけるかは慎重な判断が必要です。例えば API 疎通部分に、ハードコーディングやモックを利用したり、ローカルで状態を持っておいたり、インラインでスタイルを当てたりすることはは TP の範囲内では許容してよいと思います。ただし、 API のレスポンスタイムが長い場合にローディング表示を出したいといった仕様がある場合、API 疎通部分は実際に実装する必要があります。そのため、どこまで実際の実装に近いコードを書くかは塩梅が難しいです。
事前に取り組む時間を決めておく
当然、精密さを追求すればするほど、実際に実装するのと変わらない時間を消費してしまうため、予め取り組む時間を決めておくことは重要です。私のチームでは、実装の規模にもよりますが、「半日〜3日以内で取り組む」としています。事前に決めた時間を超える場合は、一度チームで話し合うことが必要です。残っている不確実性を明確にして単純に時間を延ばすのも良いですが、時にはリソースの調整や仕様変更を検討する必要もあるでしょう。
チームとして取り組む
どうしても TP をするエンジニアに負担が集中するため、相応のスキルやリーダーシップが求められます。一番解像度が高いのは TP をするエンジニアなので、手始めに本実装のベース部分を実装するのが経験上スムーズだとは思います。ただこれは必要条件ではなく、同期的にレビューを行ったり、サブタスクを切りチームで見積もり直したりするなど、チームとして解像度を上げることに尽力することが役割分担に繋がります。
事例紹介
ここで 1つ事例を挙げてみます。
「一覧画面にある詳細ボタンを押下したユーザーは、待ち時間が発生してストレスを感じているため、詳細画面へのアクセス時間を短縮してほしい」というユーザーストーリーがあるとします。
アクセス時間を短縮するため、詳細画面を画面遷移ではなくモーダル表示に切り替えようとしました。また詳細画面の表示領域を確保するため、モーダルを画面いっぱいに広げようとも考えました。しかし、そうすると「別ページに遷移したかのように誤認させる」という懸念と「パンくずリストなどのナビゲーションがないとページ階層の現在地が把握できなくなるため、目的の情報にたどり着くための操作効率が低下する」という恐れもありました。技術観点でも詳細閲覧機能を独立した画面から一覧画面内へと移すにあたり、どのような設計や実装になるか不明瞭でした。
しかし、この課題に対して TP という手法を取り入れることで、詳細コンポーネントの内部構造のうち、状態の参照方法などの修正の必要がある部分が明確になりました。UI/UX 観点でも、モーダルの表示方法に関する迷いがありましたが、実際に一覧と詳細モーダルを シングルページアプリケーション（SPA） のように行き来する動きを見ることで仕様の改善ができました。具体的には、表示/非表示の際にスライドアニメーションを加えることで、モーダルであることが伝わるとチームで判断できました。また「一覧画面に詳細画面が覆い被さっている状態で、ブラウザの戻るボタンを押下すると、ユーザーは一覧画面に戻ることを期待するのではないか」という新たに考えるべき観点も得ることができました。
つまり TP したことで得られた価値は、技術検証だけではなく仕様や UI/UX とった大部分を短期間で明らかでき、それが適切に役割分担に繋がり、同時並行で素早く手戻りなく開発することができたことです。
上記の事例だけでなく、例えば以下のような課題でも、早期に実態の解明と他に取り得る選択肢を明らかにすることができます。
| 課題 | 詳細 | TP することで得られる価値 |
|---|---|---|
| Figma と Web アプリの乖離 | Figma 上ではサクサク動いてもブラウザ上では API レスポンスを待つため遅く感じてしまうが、UX として課題がないかを事前に明らかにしたい。 | ローディングアニメーションを表示するのか、根本的に API のレスポンスタイムを改善するのかを比較検討できる。また工数の兼ね合いで API 改善が難しい場合の算段や、実際の動きを見てレスポンスタイムの許容値を決めることができる。 |
| 新しい仕様と既存実装の乖離 | ブラウザバックしても beforeunload が発火しないケースがあるが、修正できるのかを明らかにしたい。 | 修正できる場合の工数と修正できない場合の取り得る仕様の選択肢を決めることができる。 |
| 仕様とコード品質 | フォームにおいて、特定のテキストボックスやボタンなどを変更もしくは押下した時にアラートを表示するという仕様は、どの程度複雑なコードになるのかを明らかにしたい。 | 著しくコード品質を下げるようであれば、中長期的な機能改善の予定を加味した上でも許容するか、仕様の変更を決めることができる。 |
| ブラウザ固有の課題 | iframe の表示がブラウザごとに異なるが、許容できるか、もしくは iframe を利用しないべきかを明らかにしたい。 | 推奨ブラウザと各ブラウザの利用率を確認した上で、UI/UX として差異を許容できるかを確認する。必要があれば、個別ブラウザ対応の有無をコード品質と iframe 以外の選択肢を検討した上で決める。 |
まとめ
不確実性を減らし、実際に動くプロダクトを見ながら議論ができるテクニカルプロトタイピングは、非常に素晴らしい手法だと思います。しかし、一番重要で忘れてはいけないことは、仮説検証ができる状態で早くユーザー価値を提供することであり、テクニカルプロトタイピングはそのためのより適切な仕様やデザイン、優先順位を決めるための手段にすぎないということを、チーム全体で認識を揃えた上で取り組みましょう。
つまり、目的を見失わずにデメリットも理解した上で、テクニカルプロトタイピングを銀の弾丸としてではなく、「急がば回れ」の手段として活用できると良いかと思います。テクニカルプロトタイピングをするかしないかの判断が難しい場合は、「3日かかっても仕様についての合意が得られなければ、不確実性が高いと判断し、テクニカルプロトタイピングする」といったルールを、予め決めておいても良いかもしれません。
ぜひこの「テクニカルプロトタイピング」が、みなさんのプロダクト開発に少しでも寄与できることを願っています。
\ Let's develop a product using TP! / by @IZUMIRU.
