Work In Prototypes
WIP / リフティング
このサイトを少し見ていただければ、ここで扱っている仕事の幅広さにお気づきかと思います。私は、どんな形であれアイデアを形にしていくことに大きなやりがいを感じていますが、その結果、試作だけが残って未完成のまま忘れられてしまうことも少なくありません。そこで、そうしたアイデアのいくつかを生かし続けるために、制作過程や作品を記録するYouTubeチャンネル、Work In Prototypes、を立ち上げました。
最初のプロジェクトは、息子と私のためのサッカーのリフティング記録用プロトタイプ「KeepyUps」です。制作の流れは次のとおりです。
目標の進捗管理
私の長男はサッカーが大好きです。
彼は地元チームに所属しており、大会でも好成績を収めています。練習の一環として、コーチが上達のための課題を出しました。「全員、少なくとも1分間はリフティングができるようにしよう。」そこで、彼に練習の機会を与えるため、できるだけ頻繁に公園や静かな通りへ通う長い日々が始まりました。私はその場に立って回数を数え、彼の足元を見つめながら、数字が増えたり減ったりするたびに、一つひとつの記録を見失わないようにしていました。
時間がたつにつれて回数は伸びていきましたが、彼が本当はどれだけ上達しているのか、私たちは次第に把握しづらくなっていました。妻が、毎回の練習後に息子がその日の最高記録を書き込める紙の記録表を提案しました。これは彼の自信と足さばきの向上を大きく後押しするきっかけになりました。自分のベストスコアを目で確認できるようになり、新しい練習のたびに、昨日の自分を超えるための勝負になったのです。
最近の家族旅行で英国を訪れた際には、その記録表も持っていき、祖父母の冷蔵庫に貼っておいて、練習を続けるよう思い出せるようにしました。記録表はその冷蔵庫に貼られたまま、うっかり者の父親に忘れられていましたが、上達し続けようという気持ちは彼の中に残っていました。それが、いつでもどこでも使えて、彼の歩みを見せられるデジタル版をポケットに入れて持ち歩けたら、という発想につながったのです。
競技規則
プロトタイプを迅速に立ち上げるため、いくつか明確な制約を設けました:
無料であること:
構築に必要なツール以外、予算はありませんでした。
持ち運べる必要がありました:
壊れやすい窓から離れた屋外で使う必要がありました。
新しいことに挑戦したかった:
過去の実験で学んだ vibe coding を使って、本格的なアプリを構築する初めての本格的な試みでした。
画面を見ずに使える必要がありました:
リフティングを数えるときは、視線は彼に向いていて、スマホではありません。これまでは指で回数を数えていたので、アプリにも同じくらい直感的である必要がありました。
いくつかの前提条件を定めたうえで、まずは実用的なものを作るために必要な画面の簡単なフローを整理しました。スマートフォンなら指先よりもはるかに多くの文脈情報を記録できるため、各セッションで取得したいデータの種類を洗い出しました。複数回の試行、表面の種類、場所、天気、時間など、扱える項目が揃いました。元の紙の記録表は、進捗の可視化とモチベーション向上に非常に役立っていたため、このデータを意味のある形で活用することが重要でした。
以前の実験では Cursor から Swift へつなぐワークフローに惹かれていましたが、今回はコストや、再インストールなしで iOS アプリを継続運用する手間といった制約に合いませんでした。そこで、何か新しいものを試すという意味も込めて、データは Firebase、ホスティングは Netlify を使って Web アプリとして構築することにしました。
機能を箇条書きにすると、ラフなスケッチになりました。Cursor にどう指示するかを考えたり、どんな実装なら成立するかを探ったりする助けには十分でしたが、最初の数回に生成された画面は粗いものでした。
私はまだ効果的なプロンプトの出し方を学んでいる途中で、Cursor とのやり取りで堂々巡りになることもよくありました。よりシンプルな解決策があるはずなのに、ひとつの方針を長く追いすぎてしまうのです。試行錯誤を重ね、Cursor が進めようとしていた見た目上の判断のいくつかをあえて無視した結果、屋外へ持ち出してテストできる動くプロトタイプにたどり着きました。
予想どおり、残念ながら、実際にはうまく動きませんでした。データが常に記録されるわけではなく、キックの記録を素早くタップするとズームジェスチャーが発生しました。デスクを離れた途端に問題は明らかになりました。それでも、改善の余地はあると感じていました。プロンプトの出し方を見直し、対象範囲を絞り、個別の問題を切り分け、変更したくない点を明確にしました。
それは助けになりましたが、私は一度立ち止まり、プロジェクトにもう一度心地よく向き合えるようになる必要もありました。私はUIと細部に焦点を移しました。ムードボードを作り、色を検討し、画面を常に確認せずにキープアップを記録する方法を慎重に考える時間を取りました。これは単なる使いやすさの問題ではありませんでした。使っていて気持ちよくなければ、何度も戻ってこないだろうと分かっていたからです。
新しいことを試すという意味でも、ビジュアルを完全にCursorに任せるだけでは不十分だと分かっていました。以前Figmaで行った作業をもとに小さなビジュアルライブラリを作り、その表現を最終的なアプリに引き継ぐつもりだったのです。これが正しい進め方だったかは、今も確信がありません。最近では、Figma's MCPをCursorに接続して、より1対1に近い変換を試す動きもあります。ただ、かなりの量の、頼んでいないビジュアル作業を取り消した結果、最終的には当初のイメージにかなり近いところへ落ち着きました。
さらに何度も反復を重ね、見た目の判断と機能面の改善を統合した結果、まだ完成にはほど遠いものの、ひとつの形にたどり着きました。
でも、動きます。
そして何より、これは自分と一緒に持ち歩けるものです。息子の進捗を記録するために使えるもの。息子に見せて、ここまでの成長を実感し、続ける励みにしてもらえるものです。
いまはこれで十分です。しかも、今では1分30秒までいきました！