外注に約100万円かけたゴミアプリが、
Codexで生まれ変わった件④|ベトナムの会社に依頼編

こんにちは!吉田です。
前回は、AIの分析機能を依頼したものの、気軽に使うには費用がかかりすぎた話でした。今回は、並行して進めていたアプリ本体の作り直しと、確認・修正のやり取りを振り返ります。

29件の提案。誰に任せればいい?

ココナラで作ってもらったアプリを、そのまま改修し続けるのは難しい。そこで、必要な機能や条件を整理し、ランサーズで作り直しをお願いできる方を募集しました。

予算はココナラと同じく20万円程度で、募集をかけてみました。QRコードの発行・管理だけでなく、チラシ画像の登録やAIとの連携も盛り込み、要件の整理から設計、開発、テスト、リリースまで相談したいと記載しました。
ソースコードや設計資料の納品も、今回は最初から条件に入れています。

実際の募集画面|予算10万〜20万円・提案29件
※クリックで拡大。

集まった提案は29件で、予算に近い金額を提示してくれた方もいて、選択肢はありそうに見えました。

実際の提案一覧|名前・アイコンなどは非表示
※クリックで拡大。

※金額は提案時の提示額で、最終的な契約額・支払額とは異なります。評価は撮影時点の表示です。

ただ、安ければ、そのままお願いできるわけでもありません。評価や実績を見て不安を感じる相手もいて、価格と信頼性の両方をどう判断するか、かなり迷いました。提案の文章だけで技術力まで見極めるのも難しいところです。

その中で候補になったのが、ここではA社と呼ぶ、ベトナムの開発会社です。当時、ベトナムでの開発は費用を抑えながら質も期待できると聞いていたうえ、A社には開発実績もありました。

提案には、画面設計や定期的な確認、ソースコードの納品についても説明がありました。アプリ本体だけでなく、動かすためのサーバー構築もA社にお願いしています。
単に安いからではなく、こうした環境づくりも含めて相談できそうだと感じ、依頼を決めました。

先に費用の話をすると、アプリ本体に加えてAPI連携と追加対応をお願いし、A社にかかった開発費は、合わせてこのくらいになりました。

アプリの作り直しに、約44万円。

アプリ本体(フェーズ1):286,005円
API連携(フェーズ2):109,218円
API連携に伴う追加対応:約48,000円

追加対応は、既存APIのデータをアプリ側で扱うための調整や画面修正など、24時間分の作業です。最初は20万円程度で募集していましたが、連携や追加対応まで含めると、費用はそこから大きく増えることになりました。

※アプリ本体は当時の支払額の合意と仮払いの記録、API連携は入金済み領収書、追加対応は送金記録に基づく概算です。追加分はベトナムドンで送金しており、為替差と送金手数料があります。別途依頼したAI API自体の開発費・API利用料は含みません。

今度はMiroで、さらに細かいワイヤーフレームを

ここで、作ろうとしていたアプリについて少し説明します。チラシに載せるQRコードを配布先ごとに分け、どこに配ったチラシが、どれだけ読み取られたのかを確認できる。
紙の販促を、配って終わりにせず、反響を見て改善につなげるためのアプリです。

さらに、会社やキャンペーンの情報をもとに、AIで配布前のエリア提案や配布後の振り返りを行う構想でした。当時は、こちらから利用企業を招待して使ってもらう想定だったため、運営する私たちと、利用する企業では必要な画面が違いました。

前回の経験もあり、今回はこうした役割の違いも含めて、画面と機能のつながりを伝えようと考えました。そこで使ったのが、オンラインのホワイトボードツール「Miro」です。

会社やチラシをどこで登録し、どの画面からQRコードを発行するのか。AIの分析結果をどこに表示するのか。管理者側とユーザー側の画面を並べ、矢印でつなぎながら整理していきました。

当時のワイヤーフレーム|Miroで整理した画面と機能のつながり
※クリックで開きます。+ / − で拡大・縮小、全体表示に戻せます。

もちろん、これだけですべての仕様が伝わるわけではありません。ただ、少なくとも「どこに、何のための機能があるのか」は共有できると思っていました。

ところが、実際に形になったものを触ると、画面上の見た目と、私が想定していた使い方との間に違いが出てきます。

例えば、ワイヤーの「MY QRコード」欄には、発行済みのQRコードが一覧に並ぶイメージを伝えるため、仮に3つの項目を置いていました。

ところが相手からは、「1つのチラシ内には3種類のQRコードが存在するため、どのQRコードを生成すべきか不明確」と確認がありました。そこで、最初から3つ表示するのではなく、発行するたびに一覧へ追加される想定だと説明し直しています。

ワイヤーの表示例

作成のたびに増える一覧の例です。
※クリックで拡大。

相手からの返信

※クリックで拡大。

早速起きた、認識のズレ

この違いは、AI分析の画面でも起きました。私が考えていたのは、チラシを作る前に配布エリアを検討できる、独立した分析機能です。ところが確認した画面では、「新規チラシ作成」の中に分析機能が入っていました。

2026年4月、Chatworkで意図を確認すると、開発側はワイヤーを見て、AI分析を「1つのチラシ内におけるサブ機能」と捉えていたことが分かります。チラシを作ってから使うのか、作る前に使うのか。
同じ機能でも、使う順番が違えばサービスの流れそのものが変わってしまう。

※クリックで拡大。

あらためて独立した導線を想定していたと説明し、Miroの画面をもとに入力項目や表示の仕方を整理し直すことに。その後、開発側からも、独立した導線として見直す方針の返信がありました。

※クリックで拡大。

同じワイヤーでも、使う順番や機能の位置づけまで同じように伝わるとは限りません。解釈の違いが分かるたびに、画面と仕様の確認に戻ることになりました。

終わらない、バグの確認と修正

特に気になったのが、QRコードを作成するまでの流れでした。

このアプリでは、どの会社の、どのチラシに対するQRコードなのかが分かることが重要です。そのため、ワイヤーフレームにも「このボタンを押したら、こちらをグレー表示にする」といった操作後の状態まで、細かく書き込んでいました。

それでも意図を汲み取ってもらえず、確認した時点では、どの画面からでもQRコードを作れてしまう状態に。ボタンを置いて発行できるようにするだけでは、想定していた使い方にはつながりませんでした。

そこで、改めて画面のスクショに赤枠や説明を書き込み、「この状態では作成できないように」「ここで対象のチラシと紐づけたい」と、操作の流れを一つずつ伝え直していきました。

※クリックで拡大。

こうした確認は、QRコードだけではありません。画像が保存されない、仮の表示が残っている、必要な情報にアクセスできないなど、触って初めて分かる点もありました。

※クリックで拡大。

さらに厄介だったのが、管理者側では直っていても、利用者側では同じように使えないケースです。このアプリは、管理者側と利用者側で一部の画面や表示内容を共有する設計で、管理者側に表示される分析の回答は、利用者側の該当画面でも確認できる想定でした。

それなのに、管理者側では動いていても、利用者側ではスクロールすらできないなど、基本的な不具合が残っていることがありました。同じ機能を使う画面なのだから、一方を直したら、もう一方も直して動作を確認する必要があるはずです。ところが、そのつながりまで踏まえずに渡されるため、こちらが両方を触り、改めて指摘しなければなりませんでした。

※クリックで拡大。

※クリックで拡大。

住所候補やスクロールを修正したとの返信はありましたが、関連する画面にも修正が反映されているか、こちらで確かめる必要がありました。

ココナラのときもそうでしたが、こちらに確認を求める段階で、触ればすぐに分かる不具合が残っていました。正直、スクロールのような基本的な動作まで、毎回こちらから指摘しなければならない状況には、かなり疲れていました。

「報告前に、デバッグや動作テストは十分に行っているのだろうか?」と感じ、こちらへ渡す前に、開発側でも動作を確かめてほしいとお願いしました。

※クリックで拡大。

UIを良くするはずが、その手前で足止め

最初の打ち合わせを担当してくれたのは、日本語が堪能な会社の社長さんでした。UIやAIの回答の見せ方も相談すると、こういう見せ方にした方がいいのでは、と具体的な案を出してくれたので、安心感がありました。

そのやり取りを踏まえて依頼しましたが、実際に開発の窓口となったのは、社長さんとは別の、社内のディレクターさんです。APIとつながった画面を見ながら、見出しやレイアウトを整え、もっと見やすいUIにしていく。そんな前向きな相談に進みたかったんです。

ところが、実際にはスクロールなどの基本動作の確認に追われました。特に、APIを実行しても結果が画面に表示されない不具合は、年始から伝えていたのに、なかなか直らない状態が続いていました。

回答をどう見せるか相談したいのに、そもそも回答が表示されない。当初やりたかった改善の話まで進めず、同じ不具合の確認と修正に時間を使い続けることに疲れてしまいました。

UIを良くする相談に進みたいのに、
その手前のバグ対応から、先に進めない。

「組織なら安心」と思っていた

ココナラでの経験を振り返ると、事前のすり合わせだけでなく、一人に任せる体制にも不安を感じていました。次は、複数人で確認しながら進められる会社に依頼したいと考えていたんです。

ただ、日本でプロダクトチームを組んで開発する会社に頼むと、予算は数百万円規模になる。一方、20数万円ほどで提案してくれた方は、個人のフリーランスが中心でした。そこで、予算との兼ね合いも考え、ある程度の人数がいて、組織として開発しているベトナムの会社を選びました。

A社は数十人規模の会社でしたが、実際の確認や修正の進め方は、ここまで書いたとおりです。人数が多ければ、それだけで安心して任せられるわけではなかったんです。

もちろん、ベトナムの開発会社すべてがそうだとは思いません。ただ、日本語で会話できることと、日本の商習慣や、お客様が実際にどう使うかまで理解してもらうことは別でした。

決められた機能を実装するだけでなく、こちらの業務に踏み込んで、一緒に使い方を考えてもらう必要があるアプリほど、仕様書やワイヤーだけでは伝えきれない。その認識をそろえるために、結局こちらが何度も説明し、確認する時間が必要になりました。

こうした経験を経て、少しずつ「自分で確かめながら、自分で直せたら」という気持ちが強くなっていきました。

次回は、完成したアプリを前に立ち止まっていた私が、友人への相談をきっかけにCodexを使い始めるまでの話を書いていきます!

シリーズの続きを読む

記事一覧へ戻る →