はじめに
60歳からFlutterで個人開発を始め、2026年8月にiPhone向けアプリ「MoveMaster AI Dance Analyzer」をリリースしました。
ダンスやスポーツなどの動きを、動画で比較・研究するためのアプリです。
私は長年ダンスを趣味にしてきたので、練習中に「こんな機能があったら便利なのに」と感じていたことを、少しずつ形にしてきました。
開発を始めた頃は、とにかく機能を増やすことに夢中でした。
「これもできたら便利だろう」
「この機能もあれば、もっと使いやすくなるはず」
思いつくたびに実装していきました。
ところが、実際にアプリを使ってくださった方と話してみると、自分が便利だと思っていた機能が、必ずしも求められているわけではないことに気づきました。
それどころか、機能を増やしたことが、かえって使いにくさにつながっていたのです。
今回は、ユーザーからの率直な意見をきっかけに、アプリのUIや機能構成を大きく見直した経験を書いてみます。
技術的な実装方法というより、個人開発で「何を作るか」「何を残すか」「何を削るか」をどう判断したか、という話です。
1. 最初は、とにかく機能を増やしていた
MoveMasterは、もともとダンスの練習を支援するアプリとして開発しました。
例えば、ダンスの練習では、先生のお手本動画と自分の動画を何度も見比べることがあります。
「ここの手の位置が違う」
「足を出すタイミングが少し遅い」
「身体の向きが違う」
そんな違いを見つけやすくしたいと思ったのが、開発のきっかけでした。
そこで、動画を2つ並べて比較する機能を中心に、さまざまな機能を追加していきました。
- 2つの動画を左右・上下に並べて比較
- スロー再生、コマ送り
- 2つの動画の再生位置を合わせる同期機能
- AIによる骨格表示
- 動きの軌跡を残すモーショントレース
- 動画への文字や矢印の書き込み
- グリッドや体幹ガイド
- チャプター管理
- ABリピート
- 動作の採点やレーダーチャート
Flutterで新しいことを実装できるようになると、次々と試してみたくなります。
特に個人開発では、自分で思いついた機能を、自分の判断ですぐに作り始められます。
それが楽しくて、気がつけば多機能なアプリになっていました。
開発者としては、機能が増えるほどアプリが進化しているように感じていました。
しかし、ここに大きな落とし穴がありました。
機能が増えることと、使いやすくなることは、必ずしも同じではなかったのです。
2. 実際のユーザーから厳しい意見をもらった
2026年9月、バレエを指導されている先生とZoomでお話しする機会がありました。
実際にMoveMasterを試していただき、率直な意見を聞かせてもらいました。
その中で特に印象に残ったのが、機能の多さについての指摘でした。
先生が必要とされていたのは、基本的に次の3つでした。
- お手本と自分の動画を比較できること
- 2つの動画のタイミングを簡単に合わせられること
- YouTubeのお手本動画を簡単に使えること
一方で、私が時間をかけて実装してきた骨格解析やグリッド、チャプター、採点などは、先生の使い方では優先度が高くありませんでした。
正直、少しショックでした。
苦労して実装した機能もありましたから。
でも、話を聞いているうちに、あることに気づきました。
先生が求めていたのは、多機能な動画解析ツールではありませんでした。
練習中に迷わず使える、シンプルな比較ツールだったのです。
考えてみれば、ダンスの練習中にスマホを操作する時間は、できるだけ短い方がいいはずです。
動画を選んで、再生位置を合わせて、すぐに比較できる。
本当に必要なのは、その一連の操作が簡単にできることでした。
ここから、MoveMasterのUIを大きく見直すことにしました。
3. UIを「機能中心」から「目的中心」に変えた
それまでの私は、新しい機能を作るたびに、その機能をどこに配置するかを考えていました。
しかし、ユーザーは必ずしも「骨格解析機能を使いたい」「チャプター機能を操作したい」と考えてアプリを開くわけではありません。
例えば、
「先生の動きと自分の動きを比べたい」
「この部分だけゆっくり確認したい」
「振り付けのタイミングが合っているか確認したい」
という目的があります。
そこで、UIを考える順番を変えました。
変更前
機能を作る → ボタンを配置する → ユーザーに使い方を覚えてもらう
変更後
ユーザーの目的を考える → 必要な操作を整理する → そのためのUIを作る
この考え方に変えてから、新しい機能を追加する際の判断基準も変わりました。
「技術的に実装できるか」だけではなく、
「ユーザーが迷わず目的を達成できるか」
を重視するようになりました。
4. 実際に変更したUI
① 再生操作を分かりやすくした
動画比較アプリでは、再生・停止・コマ送り・速度変更などの操作を頻繁に使います。
以前は、操作ボタンの意味が直感的に伝わりにくい部分がありました。
そこで、再生UIを整理しました。
例えば、
- 再生速度を「速度 1.00x」のように常時表示
- 5秒戻る・5秒進む操作とコマ送りを区別
- 2画面の同期操作を「連動」という表現に変更
- よく使う操作にアクセスしやすい配置へ見直し
- 再生中に操作UIを隠して動画を見やすくする
などです。
特に「連動」という名称は、技術的な仕組みを説明するよりも、ユーザーが何をできるのかを伝えることを意識しました。
開発者にとっては当たり前のアイコンや用語でも、初めて使う人には意味が伝わらないことがあります。
2画面比較では、お手本と自分の動画を左右に並べ、再生・コマ送り・速度変更など、よく使う操作を画面下部に整理しました。各ボタンには日本語の説明を付け、アイコンの意味を覚えなくても操作できるようにしています。
② 「ABリピート」を「ここだけ再生」に変更
これは最近変更したUIの中でも、特に象徴的な例です。
長い振り付け動画を見ていると、
「この8カウントだけ確認したい」
「この動きの部分だけ練習したい」
という場面があります。
そのために、動画の開始位置と終了位置を指定するABリピート機能を実装していました。
しかし、「ABリピート」という言葉は、動画編集に慣れている人には通じても、一般のユーザーには分かりにくいかもしれません。
そこで、機能そのものは残しながら、名称を**「ここだけ再生」**に変更しました。
さらに、指定した区間を再生するとき、最初から繰り返し続けるのではなく、リピートを初期状態でOFFにしました。
必要な人だけリピートをONにできます。
「ここだけ再生」を使いたい人と、何度も繰り返して練習したい人。
両方の使い方に対応しながら、初めて使う人にも分かりやすい操作を目指しました。
機能を削除しなくても、名称や初期設定を変えるだけで、使いやすさを改善できると感じた例です。
YouTube動画の研究画面では、専門用語をできるだけ避け、開始位置・終了位置・再生方法が分かるUIにしました。
③ YouTube動画をアプリ内で検索できるようにした
ユーザーからの要望で大きかったのが、YouTubeのお手本動画を使いたいということでした。
ダンスの練習では、YouTubeに公開されているお手本動画を参考にすることがよくあります。
最初に実装したのは、YouTubeアプリで動画を探し、「共有」からMoveMasterを起動する仕組みでした。
これでも、動画をダウンロードせずに比較できるようになりました。
しかし、操作手順は少なくありません。
そこで、さらに改良して、MoveMasterの中からYouTube動画を検索し、そのままお手本として表示できるようにしました。
現在は、
- アプリ内でYouTube動画を検索
- YouTubeアプリの「共有」から起動
- YouTube動画を1画面で研究
- YouTube動画と端末内の動画を2画面で比較
といった使い方ができます。
YouTube動画は公式のIFrame Player APIを利用して再生しており、動画ファイルをダウンロードして扱う方式ではありません。
この改善は、単に新機能を追加したというよりも、ユーザーが目的に到達するまでの手順を減らすための変更でした。
アプリ内のYouTube動画選択画面。 YouTubeアプリに切り替えることなく、動画を探して、そのまま練習に使えるようにしました。
④ 採点機能を削除した
初期のMoveMasterには、動きを点数で評価する機能やレーダーチャートもありました。
しかし、ダンスの良し悪しを単純な数値だけで表現することには限界があります。
骨格の位置が近くても、動きの質や表現が同じとは限りません。
そもそも、ユーザーが本当に知りたいのは「何点だったか」ではなく、「どこが違うのか」なのではないか。
そう考えるようになりました。
そこで、採点機能は削除しました。
現在は、AI骨格表示やモーショントレースを、ユーザー自身が動きを観察するための補助機能として位置づけています。
AIが正解を決めるのではなく、人間が違いを発見するために使う。
この方向性の方が、アプリの目的にも合っていると考えています。
5. FlutterでUIを作り直して感じたこと
Flutterを使っていて助かったのは、画面構成を比較的柔軟に変更できることでした。
一方で、UIの整理は、単にWidgetを並べ替えるだけでは終わりません。
MoveMasterの場合、動画再生には複数の状態が関係します。
例えば、
- 再生中か停止中か
- 再生速度
- 1画面か2画面か
- 2つの動画が連動しているか
- 基準点が設定されているか
- YouTube動画か端末内の動画か
などです。
UIを変更すると、こうした状態の組み合わせにも影響します。
実際に、YouTube動画と端末内動画を連動させた際、一時停止から再開すると再生位置がずれてしまう不具合も発生しました。
画面上では同じ「再生」ボタンでも、裏側では異なる動画プレーヤーの状態を扱っています。
特にYouTubeのIFrame Player APIと端末内の動画再生を組み合わせる場合、両者の再生開始タイミングが完全に一致するとは限りません。
UIをシンプルにすることと、内部処理をシンプルにすることは別問題でした。
むしろ、ユーザーに複雑さを見せないために、内部ではより丁寧な状態管理が必要になることがあります。
今回の改修では、機能の追加だけでなく、操作の意味と再生状態の整合性を意識するようになりました。
6. すべての要望をそのまま採用するわけではない
ここは個人開発で難しいところだと思います。
ユーザーから「この機能はいらない」と言われたからといって、必ずしも全員に不要とは限りません。
例えば、骨格表示は必要ないという方もいれば、自分の姿勢を確認するために使いたい方もいるでしょう。
ABリピートも同じです。
機能の存在が問題なのか、名称が分かりにくいのか、操作が複雑なのか。
その違いを考える必要があります。
今回、私は次のような方針で整理しました。
| 判断 | 対応 |
|---|---|
| アプリの中心となる機能 | 使いやすさを優先して改善 |
| 便利だが全員には必要ない機能 | 補助機能として残す |
| 名称が分かりにくい機能 | ユーザーの言葉に変更 |
| 目的に合わない機能 | 削除を検討 |
| 操作手順が多い機能 | 手順を減らす |
重要なのは、ユーザーの意見をそのまま仕様書にすることではなく、その意見の背景にある困りごとを理解することだと思います。
7. 個人開発だからこそできること
今回の経験で感じたのは、個人開発の強みです。
大きな開発チームでは、仕様変更に多くの調整が必要になることもあると思います。
しかし個人開発なら、ユーザーから意見をもらい、自分の判断で改善に着手できます。
MoveMasterでも、ユーザーの意見をもとに、比較的短いサイクルでUIを変更してきました。
もちろん、変更が早いぶん、不具合を作り込んでしまう危険もあります。
実際、修正ビルドを何度か提出することになりました。
それでも、ユーザーの声を直接聞きながら改善できることは、個人開発の大きな魅力だと感じています。
一方で、改善を急ぎすぎて、ユーザーが操作を覚える前にUIが変わってしまうことにも注意が必要です。
今後は、変更の必要性だけでなく、変更するタイミングも大切にしたいと思っています。
8. 今回学んだこと
今回のUI改修から、特に次の4つを学びました。
① 開発者が便利だと思う機能と、ユーザーが必要とする機能は違う
実装に苦労した機能ほど残したくなります。
しかし、開発時間の長さとユーザーにとっての価値は別です。
② 分かりやすい言葉は、機能を増やすのと同じくらい重要
「ABリピート」を「ここだけ再生」に変更したように、名称だけでも使いやすさは変わります。
③ UIをシンプルにするほど、内部の状態管理が重要になる
特に複数の動画プレーヤーを扱う場合、操作を簡単に見せるための内部処理は慎重に設計する必要があります。
④ ユーザーの要望ではなく、目的を理解する
「この機能はいらない」という意見の背景には、「もっと簡単に使いたい」という本当の要望が隠れていることがあります。
おわりに
60歳から始めた個人開発。
最初は、作りたい機能を実装することが楽しくて仕方ありませんでした。
今もその気持ちは変わりません。
ただ、実際のユーザーと話すことで、少し考え方が変わりました。
アプリを作る目的は、機能を増やすことではありません。
ユーザーがやりたいことを、できるだけ簡単に実現できるようにすること。
MoveMasterは、まだまだ改善の途中です。
今後はダンスだけでなく、スポーツ、武術、姿勢やフォームの研究など、さまざまな動きを観察できるアプリに育てていきたいと考えています。
これからも、実際に使ってくださる方の声を聞きながら、少しずつ改善していくつもりです。
同じように個人開発をされている方の参考になればうれしいです。
開発中のアプリ
MoveMaster AI Dance Analyzer
動画を比較しながら、動きの違いを観察・研究するためのアプリです。
現在、iOS版をApp Storeで公開しています。
最後まで読んでいただき、ありがとうございました。