多くの経営者は、公式サイトやシステムを作ると決めたとき、まず「見積もりを取ろう」と考えます。しかし3社に問い合わせてみると、見積もりは2万円から20万円まで幅があり、提案書はどれも立派に見えて、かえって誰を選べばいいのか分からなくなります。
問題は価格ではなく、このプロジェクトをどう進めるべきか、どこまでできれば完了なのかをまだ明確にできていないことにあります。Webサイト開発は規格品の購入ではありません。プロジェクトの境界が曖昧なら、後で必ずトラブルになります。
以下では実際の進行順に沿ってポイントを整理し、手元のプロジェクトが外部チームに任せるのに適しているか、またどう任せれば失敗を避けられるかを判断できるようにします。
まず展示型か業務型かを見分ける
企業サイトは大きく2種類に分かれます。1つは展示型です。会社紹介、製品一覧、連絡先などが中心で、情報が明確で表示が速く、スマートフォンで見やすいことが重要です。こうしたプロジェクトは期間が短く、デザインとコンテンツ構造が要点になります。
もう1つは業務型です。予約、注文、会員、データダッシュボードなどを伴います。本質的には軽量なシステムであり、企業サイトはあくまで入口にすぎません。
具体例を挙げます。設備保守を行う企業が公式サイトをリニューアルするとします。もともとは製品画像を載せるだけでしたが、リニューアル時に「オンライン修理受付」を追加したいと要望しました。顧客が設備番号、故障内容を入力し、写真をアップロードすると、バックエンドが該当エリアのエンジニアに自動で割り当てる仕組みです。
これはもはやリニューアルではなく、チケット管理システムの開発です。見積もりが10倍違うのは、こうした要件を事前に明確に伝えているかどうかの差であることが少なくありません。
進め方：プロジェクト開始前に機能を一覧化し、「必須 / 可能なら欲しい / 後回し」を1項目ずつ明記します。注意点：契約書に「機能は某サイトを参照」と書いてはいけません。それは書いていないのと同じです。
ミニアプリ開発とApp開発は、まずユーザーがどこにいるかを考える
多くの顧客は最初にAppを作りたいと言います。まず落ち着いて、こう問いかけてください。あなたのユーザーは1つの機能のためにAppをインストールしてくれるでしょうか。
予約、申し込み、注文照会のような軽い操作なら、ミニアプリ開発のほうが通常は有利です。ダウンロード不要で、WeChat内で直接開け、普及コストも低くなります。Appは利用頻度が高く、プッシュ通知が必要で、端末機能を多く使う場面に向いています。
よくあるミスマッチとして、ローカル生活サービスを行うチームが数か月かけてAppを作り、リリース後にほとんどのユーザーがインストールを望まないことに気づき、最後にミニアプリを追加するケースがあります。
進め方：まずミニアプリで需要を検証し、うまくいってからAppを検討します。注意点：2本の開発ラインを同時に走らせないことです。予算も工数も薄まります。
バックエンド管理システムは最も過小評価されやすい
フロントはきれいだがバックエンドは使いにくい。これは外注プロジェクトで最もよくある後遺症です。
バックエンド管理システムは顧客向けではないように見えますが、チームの日々の業務効率を左右します。コンテンツを一括インポートできるか、権限をロール単位で細分化できるか、操作ログがあるか、レポート出力が便利か。こうした細部はデモでは見えず、1か月使うとすべて露呈します。
進め方：検収時は画面を見るだけでなく、実際に使う人に新規作成から承認、出力までの一連の流れを操作してもらいます。注意点：契約書でソースコードとデータベース構造の納品を定め、動くプログラムだけを受け取る形にしないことです。
セキュリティテストとリバースエンジニアリングテストはどの工程に入れるべきか
多くの人はセキュリティをリリース後の問題と考えますが、実際にはWebサイト開発の段階から関与すべきです。
一般的な方法は、開発完了後に一度Webサイトセキュリティテストを実施し、権限外アクセス、インジェクション、ファイルアップロード、API認証といった基本項目を確認することです。決済やユーザー情報を扱うシステムでは、この工程は省略できません。
リバースエンジニアリングテストは、主に外部API連携、異常呼び出しの調査、データ暗号化の信頼性検証に用います。これは攻撃ではなく、許可された範囲内でシステムの実際の挙動を明らかにする作業です。
進め方：セキュリティテストをプロジェクトのマイルストーンに組み込み、リリース前の必須通過項目とします。注意点：テストは書面による許可と取り決めた範囲内で行い、境界を明確にすれば双方にとって安心です。
どのような場合にMIC Studioが適しているか
すべてのプロジェクトが外注に適しているわけではなく、すべてのプロジェクトが自社チーム育成に適しているわけでもありません。
比較的適しているケース：要件がすでに比較的明確だが、社内に安定した開発人材がいない。プロジェクトに明確なリリース時期があり、結果に責任を持てる小規模チームが必要。あるいは既存システムに対してセキュリティテストやAPI調査のような専門作業が必要。
あまり適さないケース：要件が頻繁に変わり、対象ユーザーすら決まっていない段階。この場合は開発に直接入るのではなく、まず調査とプロトタイプを行うべきです。
MIC Studioは企業Webサイト開発、ミニアプリ開発、App開発、スクリプト開発を行い、Webサイトセキュリティテストやリバースエンジニアリングテストも手がけています。規模は大きくありませんが、コミュニケーション経路が短く、問題を実際に担当する人に直接確認できるのが利点です。
すぐに実行できる3つの提案
第一に、要件を機能一覧として書き出し、優先度を明記してから見積もりを依頼します。一覧が具体的であるほど、見積もりは比較しやすくなります。
第二に、契約書に納品物を明記します。ソースコード、データベース、デプロイ資料、アカウント権限、そしてリリース後の保守サポート期間です。
第三に、検収時間を確保し、実際の利用者に一連の流れを通しで操作してもらいます。デモ環境で数回クリックしただけで署名しないことです。
プロジェクトの出来は、8割が開始前の数ページの書類を明確に書けたかどうかで決まります。