この記事はGoodpatch Advent Calendar の23日目の記事です。

こんにちは！エンジニアのkatoです！

新規事業開始時・クライアントへの提案時など、簡易的なデザインを作成し、デザインモックを元に会話するタイミングは多いと思います。今回は、提案の精度を上げるために「動くもの」を作り、エンジニアリングの力で提案のお手伝いをした事例を紹介します。

テクニカルプロトタイプとは
何を作ったの？
どうやって作ったの？
おわりに

テクニカルプロトタイプとは

グッドパッチでは、ノーコードツールやコード実装を用いて実際に動作するプロトタイプのことを「テクニカルプロトタイプ」と呼んでいます。デザインモックと比較して、以下のような場合に適しています。

ユーザー間のリアルタイムなコミュニケーションを扱う
端末にデータを貯め、長期間使用することで価値が発揮される
GPSや歩数機能など端末の機能を扱う
アニメーションや触り心地がコア価値に繋がる
技術的な課題がある

今回は 「4. アニメーションや触り心地がコア価値に繋がる」 に該当するため、提案資料としてスライド資料やデザインモックに加えて、テクニカルプロトタイプを用意しました。

プロトタイプについてはこちらの記事で詳しく解説しているため、あわせて御覧ください。

何を作ったの？

既存iOSアプリに追加するミニゲーム要素を、iPhone端末上で実際に動作するアプリとして開発しました。

ネイティブアプリとして動作しますが、普通のアプリとはちょっと違った物理演算やインタラクティブなアニメーション、BGM・効果音や振動など、ゲームに近い表現が多く求められました。

触っていただけないのが残念ですが、一部を動画で紹介します。ミニゲーム + 物理演算での遊びという構成なのですが、実際に提案に使ったものはお見せできないため、ここでは物理演算の遊び部分のみの紹介です。

触った絵文字がハプティックな振動や効果音と共に消える体験は、動画では伝わらない楽しさ・気持ちよさがあります。

（実際はもっとヌルヌル動作します。容量の都合でfpsを下げています。）

どうやって作ったの？

まずはデザイナーに作成中のデザインファイルを共有してもらいました。提案前の段階のためもちろん仕様など決まっていない箇所もあり、デザインも細かいところは抜け漏れのある状態です。提案までの短い期間の間に、デザインの価値を最大限に伝えられる「動くもの」を作り切る必要があります。

技術調査する

デザイナーから相談を受けた当日中に、コア価値であろう物理演算部分や、ミニゲームゲームで必要になるインタラクティブな表現の技術調査を行いました。ここが素早く作れるかどうかで、エンジニアから何を提案できるかが変わってきます。幸い SpriteKit を使えば、求められている内容がネイティブアプリ上でも簡単に実現できそうなことがわかり、表現の幅を提案できるほどには調査することができました。

見せたいコア価値を決める

提案の内容をヒアリングし、提案時に見せたいコア価値を決めました。今回の場合は、物理演算の触り心地とミニゲームのインタラクションがデザインモックでは再現できないコア価値です。コア価値ではない箇所や実装に時間がかかりそうな箇所、口頭説明で補足できそうな箇所は思い切ってオミットしました。

素早く段階的に作る

作るものを決めたら、実際に作るフェーズです。

デザインファイルに描かれていない箇所は脳内で動きを補足しながら、デザイナーと認識をすり合わせます。細部は相談しながら進めると時間がかかるため、ある程度エンジニア側の裁量で判断しながら実装し、事後共有で進めました。エンジニアがデザイン視点で判断することで、スピードを出し短いスケジュールで価値を提供することが可能になります。

実装では、最初から多くを作ろうとするとスケジュールに間に合わなかった時のリスクが高いため、なるべくスコープを狭め小さな完成を繰り返すように作ります。今回は、以下のように段階的に作成しました。

物理演算のみ：1日
物理演算 + ミニゲーム1つ：3日
物理演算 + ミニゲーム3つ：5日

結果的に5日間で、通して動作するものを作成できました。

変更に強く作る

プロトタイプでは「綺麗に実装する」が常に正しいとは限らず、あらゆる変数を考慮して、何を優先して実装するか判断する必要があります。特に今回はアニメーションのタイミングを調整する処理が多く含まれているため、全体的な調整のしやすさを優先し、コードの可読性を少し犠牲にする判断をしました。例えば、画面遷移は行わず画面内の要素の表示非表示を切り替えるように作ることで実装上の制約がなくなり、ギリギリまで細かいアニメーションを調整することができました。