アプリ開発のご相談をいただくとき、多くの方が気にされるのは「これ、作れますか？」という点です。
でも、正直に言うと——たいていのものは作れます。プロなら当たり前です。
アプリの善し悪しを本当に決めるのは、その手前にある「どこに力を入れ、どこは引くか」という数十回の小さな判断だと、私たちは考えています。同じ予算・同じ機能でも、この判断の質でアプリの使い心地はまるで変わります。
今回は、私たちが自社開発しているボーカル練習アプリ 「Vocal Pitch Recorder（VPR）」 を題材に、その「判断」の現場を3つご紹介します。技術の自慢話ではなく、発注いただいたときに私たちが何を考えているかが伝われば嬉しいです。
VPRは、iOS向けに開発している、歌った声の音程（ピッチ）をリアルタイムでグラフ表示し、録音後にさらに高精度で分析できるアプリです。App Storeで配信しています。
📝 3行まとめ
① アプリ開発で本当に差がつくのは、「作れるか」よりも判断の質です。
② VPRでは、ピッチのガタつきを感覚ではなくデータで検証して改善しました。
③ 速さ、正確さ、リリース直前のリスクを分けて考え、やることとやらないことを選びました。
「作れるかどうか」より大事なこと
「作れるかどうか」は、もちろん大事です。ですが、受託開発で本当に怖いのは、作れるからといって全部作ってしまうことです。
たとえば、同じ「音程をグラフで見たい」という要望でも、歌っている最中に見るのか、録音後にじっくり確認するのかで、最適な作り方は変わります。リリース直前なのか、まだ検証段階なのかでも、取るべきリスクは変わります。
私たちが大切にしているのは、要望をそのまま機能名に変換することではありません。目的、使われる場面、予算、納期、リスクを見て、どの判断がいちばん良いかを選ぶことです。
判断① 「ピッチがガタガタ表示される問題」を、感覚でなくデータで直した
開発中、こんな不具合が出ました。
歌の音が消えていく最後の瞬間に、表示される音程が突然1オクターブ下に飛んで、グラフがギザギザになる。
非エンジニアの方向けに噛み砕くと、機械は「ド」の音を聞いたとき、ひとつ下の「ド」と勘違いしやすい性質があります。音には「倍音」という影分身のような成分があるためです。声が小さくなると、この勘違いが起きやすくなります。
ここでの分かれ道は、「とりあえず数字をいじって、見た目がマシになったらOKにする」か、「なぜ起きるのかを突き止めて直す」かです。
私たちは後者を選びました。具体的には、次のように進めました。
- 音を分析する“ひと区切り”の幅を約2倍に広げ、消え際でも音程を見失いにくくする
- 「1オクターブ飛び」のような不自然なジャンプを検知して、本来の音に引き戻す補正を入れる
- 1コマ1コマの判定結果をすべてCSVに書き出し、本当に直ったかをデータで確認する
最後の「データで裏取りする」が、いちばん大事なところです。「なんとなく直った気がする」で終わらせず、事実で確認してからOKを出す。これはお客様の案件でも必ず守っている姿勢です。
💡 発注者にとっての意味：「直りました」という報告の裏に、ちゃんと根拠があるか。私たちはそこをごまかしません。
判断② 「1つの完璧」より「2つの役割分担」を提案した
VPRには、音程を見せる仕組みが実は2つ入っています。
最初は「ひとつの高精度なエンジンで全部やる」のが理想に思えます。ですが、ここには相性の悪いトレードオフがあります。
- 歌っている最中の表示：多少粗くても、とにかく遅れずサクサク動いてほしい
- 録音し終わった後の分析：時間がかかってもいいから、とにかく正確であってほしい
この2つを1つのエンジンで両立させようとすると、どっちつかずになります。そこで私たちは、「リアルタイム用（軽くて速い）」と「録音後用（重いが正確）」の2系統に役割分担する設計を選びました。
これは技術というより、提案の話です。「音程を出してほしい」というご要望をそのまま受け取るのではなく、“いつ・何のために必要なのか”を分解して、目的ごとに最適な答えを当てる。結果として、軽快な操作感と分析の正確さを同時に実現できました。
💡 発注者にとっての意味：ご要望を鵜呑みにせず、「本当に欲しいもの」に翻訳して設計します。
判断③ リリース直前、あえて「今はやらない」と提案した
これがいちばん“らしい”話かもしれません。
リアルタイムの音程分析はそこそこ重い処理で、「将来、機種によってはカクつくかもしれない」という懸念がありました。技術的には、処理を裏方の担当、つまり別スレッドに移せば速くできます。やろうと思えばできました。
でも、それを検討していたのは、ちょうどApp Storeの審査に出す直前でした。
ここで私たちが出した結論は、「今はやらない」です。
理由はシンプルで、リリース直前の改造は、速くなる代わりに新しい不具合を生むリスクがあるからです。今わざわざ綱渡りをするより、まず実機でちゃんと測って、本当に問題が出てからでも遅くない。
「できることは全部やる」ではなく、「リスクとタイミングを天秤にかけて、やらない勇気を持つ」。これも立派な技術判断だと考えています。慎重に進めたいフェーズでは、むしろブレーキを提案するのがプロの仕事です。
💡 発注者にとっての意味：私たちは「とにかく盛る」開発はしません。納期・予算・リスクを見て、止めるべきところは正直に「止めましょう」とお伝えします。
共通しているのは「目的から逆算する」こと
3つの話に共通するのは、「言われた通りに作る」のではなく「目的から逆算して判断する」という一点です。
- 不具合は、感覚でなくデータで直す
- 要望は、そのままでなく目的に翻訳して設計する
- 改善は、できるからやるのでなくリスクとタイミングで取捨選択する
発注者にとっての本当の価値は、「コードが書ける人」ではなく、「判断を安心して任せられる相手」だと思っています。VPRは、その判断の積み重ねでできています。
開発のご相談はこちら
「こんなアプリは作れる？」「今の見積もりは妥当？」「この機能、本当に必要？」——企画段階のご相談だけでも歓迎です。
上でお見せしたように、私たちは「作る前の判断」からお手伝いします。
