- タイでWebサイトやアプリを作る依頼先は、フリーランス、小規模な制作会社、ソフトウェアハウスの三種類です。それぞれ向いている案件の規模が違います。
- どの依頼先も同じ質問で測ります。実績、プロセス、契約、相性、危険信号の5項目です。
- 最初に確かめるのは三つです。実際にコードを書くのは誰か、コードとすべてのアカウントは誰のものか、実際の成果物をどのくらいの頻度で見られるか。
- 危険信号が一つでもあれば、合計点が高くても、その会社はいったん保留にします。
依頼先は三種類、どの会社にも公平な比べ方
Web制作会社を選ぶのは、社用車を任せる整備工場を選ぶのに似ています。修理した車が今も問題なく走っているかを見たい、誰が作業するのかを知りたい、見積もりは書面ではっきりもらいたい、そして車の名義は自社のままにしておきたい。ソフトウェアも同じです。ここでの名義にあたるのが、ソースコード、ドメイン、そしてシステムのすべてのアカウントです。
タイの市場には三種類の依頼先があります。フリーランスは一人か二人で働き、範囲がはっきりした小さな案件に向いています。小規模な制作会社はデザインやマーケティングに強いことが多く、既製のプラットフォームで会社のWebサイトやネットショップを素早く作ります。ソフトウェアハウスは専任のエンジニアチームを持ち、テストの手順と納品後の保守体制があり、社内データにつながるシステムや何年も使い続けるシステムに向いています。どの種類にも良い会社と避けるべき会社があります。そのため、この記事では会社のランキングは載せません。載せるのは、私たちを含めてどの会社にも使える質問だけです。
項目1：実績（自分で開ける成果物と、実際にコードを書く人）
良い実績とは、御社が自分で開いて使える成果物です。今も公開中のWebサイトのリンクや、ストアにあるアプリの名前を聞き、御社のスマートフォンで試してください。表示の速さとタイ語の画面を見ます。スライドのスクリーンショットからわかるのは、その案件がかつてあったということだけです。そのうえで過去の顧客2社の連絡先をもらい、予定どおりに終わったか、納品後の問題にどのくらい早く対応してもらえたか、また依頼したいかを聞きます。
見落とされがちなのは、実際にコードを書くのは誰かという質問です。提案に来る人は営業担当であることが多いものです。契約の前に一度、御社の案件を担当するエンジニアに会わせてもらいましょう。どの部分を社外に出すのか、中心メンバーが途中で辞めたら誰が引き継ぐのかを、率直に聞きます。自社のチームを持つ依頼先なら、その場で答えられます。
項目2：プロセス（プロトタイプ、デモ、テスト、コードレビュー）
良いプロセスには、外から見てわかる点が四つあります。一つ目はプロトタイプ（試作版）、本番のコードを書く前に操作できる画面です。完成したシステムを直すより、下書きを直すほうがはるかに安く済みます。二つ目はデモの頻度です。実際の成果物を毎週見られるのか、納品のときに初めて見るのか。デモとデモの間は、誤解が誰にも気づかれずに積み重なる期間です。
三つ目はテストです。誰がテストするのか、本番とは別の試験用システムであるステージング環境があり、公開前に御社のチームが試せるかを確かめます。顧客データを扱うシステムなら、バイブコーディング時代のサイバーセキュリティのチェック項目も見てください。四つ目はコードレビューです。「書き終わったコードは、本番に出す前に誰が確認しますか」と聞きます。良い答えはシニアエンジニアの名前です。
項目3：契約（範囲、価格、支払い段階、ソースコード、すべてのアカウント）
良い契約は、箇条書きのスコープから始まります。システムが何をするか、何が含まれないか、途中で追加を頼んだらどう計算するか。範囲を固定した定額は、要件がはっきりしているときに向いています。かかった時間で払う方式は、答えをまだ探している段階の仕事に向いています。どちらでもかまいませんが、どちらなのかを契約に明記してもらいます。支払いはカレンダーの日付よりも、受け入れ基準に沿って検収した成果物に結びつけます。
ゆっくり読むべき条項はソースコードの所有権です。代金を全額払ったら、ソースコード、データベース、システム文書、デザインが御社のものになり、別のチームに開発を引き継げることを、契約に書いておくべきです。依頼先が自社の権利を持つ部品を使う場合は、御社がどんな条件で使い続けられるかも明記してもらいます。
小さく見えて大事なのがアカウントです。ドメイン、ホスティング、クラウド、App StoreとGoogle Playの開発者アカウント、LINE公式アカウント、広告アカウント。どれも御社の名義で開設し、会社のカードで支払い、依頼先には作業用の権限を渡す形にします。依頼先名義のアカウントは、保守の担当を替えたい日に移すのが難しくなります。これがコードの外にあるベンダーロックインです。
この項目には、あと四つあります。保証期間、つまり不具合を何か月無償で直すか。保証が切れた後の保守計画と、SLAとして書かれた対応時間。タイの個人情報保護法（PDPA）に沿った条項、つまり依頼先が御社の顧客データにどこまで触れられ、案件の終了後いつ削除するか。そして税務書類です。付加価値税（VAT）の登録をしている依頼先はタックスインボイスを発行でき、e-Tax Invoiceで出す会社もあります。登録していないフリーランスが出せるのは領収書だけです。法人の登記状況は、タイ商務省事業開発局（DBD）で確認できます。
項目4：相性（チームの規模、言語、業界、断る力）
チームの規模は案件に見合っているべきです。御社の案件に何人がつき、それぞれが同時にいくつの案件を抱えているかを聞きます。言語については、使う人がタイ人スタッフなら、画面とマニュアルは読みやすいタイ語でなければなりません。経営者や親会社が海外にいるなら、システム文書と進捗報告には英語も必要です。チームの誰が両方の言語でやり取りでき、日々の窓口は誰になるのかを聞きます。
御社と同じ業種の経験がなければ、最初の打ち合わせで十分に踏み込んだ質問をしてくるかを見ます。最後は断る力です。良い依頼先は、頼まれた機能をまだ作るべきでないときや、既製のシステムのほうが作るより割に合うときに、そう伝えてくれます。最初の打ち合わせで何でも引き受ける会社は、後から追加費用を請求してくることがよくあります。
| 項目 | 聞くこと | 良い答え | 危険信号 |
|---|---|---|---|
| 実績 | 今も使われている成果物のリンクをもらえますか | リンクやアプリ名を送り、試させてくれる | スライドの画像しかない |
| 実績 | この案件のコードは誰が書きますか | 契約前にエンジニアと会わせ、どこを自社で作るかを明言する | 「チームでやります」と言うだけで名前が出ない |
| プロセス | 実際の成果物はどのくらいの頻度で見られますか。コードは誰がレビューしますか | 毎回日付の決まったデモがあり、シニアエンジニアがコードをレビューする | 納品のときに初めて見る |
| 契約 | 全額支払った後、ソースコードは誰のものですか | 御社のもので、契約に明記される | 「終わってから相談しましょう」 |
| 契約 | ドメインとストアのアカウントは誰の名義ですか | 御社の名義で、依頼先には作業権限 | 依頼先の名義 |
| 契約 | 支払いは何に結びついていますか | 各段階で検収した成果物 | 着手前に大きな金額を払う |
| 相性 | 当社の要件で、まだ作るべきでないものは何ですか | 理由とともに少なくとも一つ挙げる | すべて引き受ける |
架空のケース
ナコーンパトム県の紙製パッケージ工場（社名も詳細も架空です）が、取引先が自分で再注文し、タックスインボイスをダウンロードできるWebアプリを求めていました。2社の見積もりは近い金額でした。1社目は実績をスライドの画像で示し、打ち合わせには毎回営業担当が来て、ドメインとホスティングを「手間を省くため」自社名義で取ると提案しました。2社目は過去の顧客が使っているシステムのリンクを送って試させ、打ち合わせにエンジニアを連れてきて、コードを書く前に操作できるプロトタイプを提案しました。
工場長と経理責任者は、5項目の表でそれぞれ別に採点しました。1社目は相性の点数は良かったものの、危険信号が二つありました。依頼先名義のアカウントと、ソースコードについて「別途協議」とだけ書かれた契約です。1社目はこの二点を直さなかったため、工場は2社目を選びました。
5項目を30分で採点する方法
上の表を採点表として使い、依頼先1社ごとに1列を割り当てます。
5項目の採点表
- ステップ1：質問を先に送る。 すべての依頼先に同じ質問を送り、根拠つきで答えてもらいます。
- ステップ2：0〜2点で採点する。 0は答えられないか、はぐらかした答え。1は答えはあるが根拠がない答え。2はリンク、担当者の名前、契約書の案など根拠がある答えです。
- ステップ3：危険信号は点数と分ける。 次のリストに一つでも当てはまる会社は、直るまで保留にします。
- ステップ4：二人が別々に採点する。 そのうえで、点数が分かれた項目だけを話し合います。
- ステップ5：点数が近いときの決め方。 実際にコードを書く人と話して、早く認識をそろえられた会社を選びます。
AIを含む案件なら、モデル、データ、AIエージェントの権限についての質問はAI開発会社に依頼する前に何を準備するかにまとめています。
項目5：立ち止まるべき危険信号
- 御社の事業について何も聞かずに、すぐ見積もりを出す
- 検収に結びついた支払い段階がなく、着手前に大きな金額を求める
- 実際にコードを書く人に会わせない
- 契約にソースコードの記載がない、または依頼先のものと書いてある
- ドメイン、ホスティング、ストアのアカウントを自社名義で取ることにこだわる
- 書面の範囲がない
- 納品後の保守について「いつでも連絡ください」と答え、対応時間を示さない
開発チーム向け · コードを受け取るときの確認リスト
リポジトリは初日から顧客の組織アカウントに置き、コミット履歴をすべて残します。READMEには新しいマシンにセットアップして動かすまでの手順があり、コードを書いていない人でもそのとおりに進められます。.env.exampleファイルがあり、本物の秘密情報はコードとは別のシークレット管理に置きます。データベースのマイグレーションスクリプトはリポジトリにあります。CI/CDのパイプラインが自動テストを実行します。開発、ステージング、本番の環境は分かれています。バックアップは定期実行され、実際に復元の訓練をしています。外部サービスのアカウント一覧と所有者、ライブラリのライセンス一覧があります。復旧訓練については売上のピークにシステムが止まるをご覧ください。
このチェックリストに私たちはどう答えるか
見積もりの前に、DNA Makerはシステムを実際に使う人、つまり営業、経理、倉庫、店舗の担当者と話をさせていただきます。そのうえで、読めば姿が浮かぶ箇条書きで範囲を書き、最初のフェーズでまだ作るべきでないものも率直にお伝えします。上の表の質問はすべて私たちにも聞いていただけます。成果物のリンクと契約書の案でお答えします。
御社の案件を担当するのはDNA Makerの自社チームで、外注はしません。コードを書く前にプロトタイプを試していただき、毎週実データでデモをお見せし、本番に出す前にシニアエンジニアがコードをレビューします。範囲と金額は着手前に固定します。ソースコードとシステム文書は範囲どおりに納品します。私たちはタイの銀行、病院、大手企業グループとも、この進め方で仕事をしています。詳しくはプロダクション水準の開発標準とタイでのシステム開発・受託ソフトウェア開発をご覧いただくか、チャットページのDreamに聞いてください。
SOFTWARE ENGINEERING GLOSSARY
ソフトウェア開発用語集
| 用語 | 意味 | わかりやすい例 | 開発チームへの質問 |
|---|---|---|---|
| スコープ（Scope） | システムが何をして、何を含まないかの一覧 | 「再注文は対応、ポイント機能はフェーズ2」 | 途中で追加したら、金額はどう計算しますか |
| プロトタイプ（Prototype） | 本番のコードを書く前に操作できる画面 | システムを作る前に、取引先が注文画面を試す | プロトタイプはいつ試せますか |
| ソースコードの所有権（Source Code Ownership） | 納品後、コードと文書が誰のものかの取り決め | 全額支払った時点で御社のものと契約に書く | 依頼先の権利のまま残る部分はどこですか |
| ベンダーロックイン（Vendor Lock-in） | コードやアカウントが今の依頼先に縛られ、保守の担当を替えられない状態 | ドメインが依頼先名義のため移せない | 来年開発チームを替えたら、移せないものは何ですか |
| 引き渡し（Handover） | コード、文書、アカウント、知識を引き継ぐチームに渡すこと | 新しいチームが文書だけでシステムを構築できる | 文書どおりにセットアップできるか、誰が試しましたか |