TypeScript人材・外注先を見極める方法：質問集と評価チェックリスト（Next.js対応）

なぜTypeScript×Next.jsの外注は「見極め」が難しいのか

TypeScriptやNext.jsでの開発を外注しようとすると、見積もりや提案書だけでは良し悪しが判断しづらい場面が多くあります。理由はシンプルで、成果物が「画面」だけでなく、保守性や拡張性、運用のしやすさといった後から効いてくる品質に強く依存するからです。見た目が同じでも、作りの丁寧さによって運用コストが何倍も変わります。

特にNext.jsは、Webサイト制作というより「Webアプリ運用」に近い性質があります。表示速度、検索エンジンへの最適化、ログイン・権限、管理画面、外部API連携などが絡むと、作り方の選択肢が一気に増えます。例えば同じ「一覧ページ」でも、SSR（サーバーで生成）にするのか、SSG（事前生成）にするのか、CSR（ブラウザで生成）にするのかで、速度・SEO・運用負荷が変わります。

またTypeScriptは「型（データの形）を厳密に扱う」ことで品質を上げられる一方、型を適当に逃がす実装もできてしまいます。外注先がTypeScriptを名乗っていても、実態はJavaScriptに少し型を付けただけ、というケースもあります。これは短期的には速く見えますが、仕様変更のたびにバグが増え、社内の情シスや運用担当が困ります。

さらに、Next.jsはバージョン更新が活発で、App Router、Server Components、API Routes、Edge Runtimeなど、選ぶべき設計がプロジェクトの性質によって変わります。だからこそ「この会社はNext.jsができます」ではなく、自社の目的に合わせた設計判断ができるかを質問で見極める必要があります。

この記事では、専門知識がない方でも使えるように、発注前の質問集と評価チェックリストをセットでまとめます。読み終える頃には「どこに頼むべきか」だけでなく、「何を合意しておくべきか」も明確になります。

発注前に整理すべき前提（要件が曖昧でもOK）

外注の失敗原因の多くは、技術力そのものよりも「前提の食い違い」です。発注側が完璧な要件定義を用意する必要はありませんが、最低限、判断軸だけは共有しておくとブレにくくなります。ここでのポイントは、細かい仕様より優先順位の合意です。

まず整理したいのは「目的」です。たとえばNext.jsでコーポレートサイトを作るのか、会員制の業務システムを作るのかで設計が変わります。前者ならSEO・更新運用・表示速度が重要、後者なら権限・監査ログ・障害時の復旧が重要です。目的が違うのに同じ評価基準で比較すると、良い会社を落としてしまいます。

次に「運用体制」を決めます。社内で更新するのか、外注が保守するのか。CMS（管理画面）が必要か、必要なら誰が使うのか。例えば更新担当が非エンジニアなら、ヘッドレスCMS（Contentful等）より、運用しやすい管理画面を優先した方がよいことがあります。逆にマーケ部が頻繁にLPを追加するなら、Next.jsとCMSの連携設計が肝になります。

また「セキュリティ・法務」も先に確認しましょう。個人情報を扱うか、ログインがあるか、決済があるか。これにより、脆弱性対応、権限設計、監査証跡の設計が必要になります。情シスがいる企業では、IP制限、SSO、端末管理、ログ保管などの要件が出ることもあります。ここを後出しすると、作り直しが発生しやすい領域です。

この前提を用意したうえで、以降の「質問集」を使うと、相手の回答の質が一気に比較しやすくなります。特にNext.jsは「何をどこで動かすか」が重要なので、前提があるだけで提案の具体度が変わります。

TypeScript人材・外注先を見極める質問集（そのまま使える）

ここでは、面談や提案依頼（RFP）の場でそのまま使える質問を並べます。意図は「正解を答えさせる」ことではなく、相手が理由を説明できるか、リスクを把握しているかを見ます。専門用語が出たら「それを採用すると何が良い/悪いですか？」と聞き返してください。

設計・アーキテクチャに関する質問（Next.jsの肝）

• 「この案件ではSSR/SSG/CSRのどれをどのページに使い分けますか？」
  良い回答の特徴：SEOや更新頻度、データの鮮度、ログイン有無で理由を説明できる。
• 「App Routerを使いますか？使う場合、Server Componentsの扱い方は？」
  良い回答の特徴：チームの習熟度、運用性、制約（ライブラリ相性）を踏まえて判断する。
• 「画像最適化やキャッシュ戦略はどう設計しますか？」
  良い回答の特徴：CDN、キャッシュ破棄、更新フローまで言及できる。
• 「SEOが重要な場合、どこまで実装・検証しますか？」
  良い回答の特徴：メタ、構造化データ、サイトマップ、OGP、Core Web Vitalsなどを挙げ、測定方法も示す。

TypeScript品質に関する質問（見えない差が出る）

• 「TypeScriptのstrict（厳格設定）を基本ONにしますか？」
  良い回答の特徴：基本はON、例外を作る時のルール（段階導入・技術的負債の管理）がある。
• 「anyを使う場合のルールは？」
  良い回答の特徴：禁止に近い扱い、どうしても必要な場合は型ガードや境界で閉じ込める説明がある。
• 「APIレスポンスの型はどう作りますか？（例：OpenAPI、Zod等）」
  良い回答の特徴：フロントとバックで型のズレを防ぐ仕組みを提案できる。
• 「レビュー観点（型・責務分離・例外処理）をチェックリスト化していますか？」
  良い回答の特徴：属人化を避ける仕組みがある。

開発プロセス・運用品質に関する質問（情シス向け）

• 「テストは何をどこまで書きますか？E2Eはやりますか？」
  良い回答の特徴：重要導線（ログイン、決済、申請）などリスクに応じて最適化する。
• 「CI/CD（自動デプロイ）の提案はありますか？」
  良い回答の特徴：GitHub Actions等で検査→ビルド→デプロイ、ロールバックの方針がある。
• 「障害時の切り分け（ログ/監視/アラート）はどうしますか？」
  良い回答の特徴：監視対象（API、画面速度、エラー率）と担当分界が明確。
• 「ドキュメントは何を納品しますか？」
  良い回答の特徴：運用手順、環境構築、アーキテクチャ図、重要な設計判断の理由が含まれる。

体制・コミュニケーションに関する質問（失敗の8割を防ぐ）

• 「担当者の役割分担（PM/設計/実装/QA）は？」
  良い回答の特徴：PMが誰か曖昧にしない。設計レビューの責任者がいる。
• 「週次の進捗報告は何を見せますか？」
  良い回答の特徴：バーンダウンや課題表、次週のリスクをセットで提示する。
• 「仕様変更が出たときの見積りと合意手順は？」
  良い回答の特徴：変更管理の仕組みがある（口頭で進めない）。

これらの質問で重要なのは、相手が「やります」と言うかではなく、なぜその方法を選ぶのかを説明できるかです。Next.jsやTypeScriptは選択肢が多い分、説明の質がそのまま実力差として出ます。

提案・見積もりの評価チェックリスト（点数化できる）

複数社比較では、感覚で決めると揉めやすくなります。そこで「提案書・見積もりを受け取った後」に使えるチェックリストを用意します。各項目を「満たしている/一部/不足」で評価し、最後に総合判断するのがおすすめです。ここでの狙いは安さではなく、総コスト（作る＋運用）の最適化です。

注意したいのは「一式」見積もりです。もちろん簡易見積もり段階では一式でも構いませんが、発注前には、画面数・API数・権限・CMS連携・デザイン対応範囲など、主要な作業単位が分かれているべきです。分解されていないと、仕様変更時の追加費用がブラックボックスになりやすく、社内説明も難しくなります。

また、Next.js案件ではインフラ費用（ホスティング、CDN、DB、ログ、監視）も含めて提案されるかを確認しましょう。開発費が安くても、運用費が想定以上に膨らむことがあります。たとえばアクセスが増えたときにスケールする設計になっているか、キャッシュ戦略があるかで費用は変わります。

最後に「担当者の顔が見えるか」も重要です。提案書が立派でも、実装するのが別チームで引き継ぎが不十分だと、品質が落ちやすいです。可能なら、PMだけでなく実装リード（テックリード）とも短時間で良いので面談し、先ほどの質問集を当ててみてください。

ミニケースで分かる：良い外注先の提案はここが違う（Next.js）

専門知識がない状態でも「提案の良し悪し」を見抜くには、具体例に当てはめるのが早道です。ここでは、よくある3つのケースで、良い提案の特徴を紹介します。結論から言うと、良い外注先ほどリスクと代替案をセットで提示します。

ケース：SEO重視のサイトをNext.jsで作りたい

良い提案では、ページの種類ごとに生成方式を分けます。例えば、固定ページはSSG、更新頻度が高い記事はISR（一定間隔で更新）、検索結果ページはCSRやSSRなど、目的に応じて整理します。加えて、管理画面（CMS）からの更新フローと、キャッシュの反映タイミングまで説明があるはずです。

一方、危ない提案は「全部SSRで作ります」「全部静的でいけます」と単純化しすぎるものです。SSRは便利ですが、サーバー負荷やコストが上がることがあります。静的化は速度に強いですが、更新反映や検索機能が絡むと設計が複雑になります。何を優先し、何を捨てるかを言語化できているかが差になります。

ケース：会員制の業務システム（情シスが関与）

良い提案では、認証（ログイン）と権限（誰が何を見られるか）を分けて設計します。例えば「管理者/承認者/一般」のようなロール、操作ログ、パスワードポリシー、セッション管理、CSRFなどの対策が明記されます。Next.jsのAPI Routesや別バックエンドの採用、Edgeでの認証なども、要件に応じて選びます。

危ない提案は、ログイン周りを「ライブラリでできます」で終わらせるものです。ライブラリで実装できるのは事実ですが、運用要件（退職者の無効化、権限変更の反映、監査対応）に触れないと、後で情シス・総務が困ります。

ケース：既存システムと連携したい（APIがある/ない）

良い提案では、APIの有無や品質に応じて、段階導入の方針が出ます。APIが整っていない場合は、まずはCSV連携→次にAPI化、のようにリスクを下げる道を提案します。TypeScriptでは、API境界で型を厳密にし、予期しないデータで落ちないようにバリデーションを入れる提案があると安心です。

危ない提案は、連携を軽く見て「つなげば終わり」とするものです。実務では、データの定義が曖昧、例外データが混ざる、運用で手入力が発生する、などが起こります。データの責任分界（どこが正なのか）を確認してくれる外注先は信頼できます。

契約・進め方で失敗を防ぐ：スコープ、検収、保守の決め方

技術力が高い会社でも、契約と進め方が曖昧だとトラブルになります。特に初めて外注する場合は「完成の定義」がずれやすいので、検収条件とスコープを先に固めることが重要です。ここを押さえるだけで、納期遅延や追加請求のリスクが大きく下がります。

まずスコープ（やること・やらないこと）です。たとえば「ブラウザ対応範囲（Chrome/Edge/Safari）」「スマホ対応の範囲」「アクセシビリティ（最低限どこまで）」など、後から揉めやすい項目は文章化します。Next.jsでは、ホスティング（Vercel等）や環境構築、DNS切替、SSL証明書、リダイレクト設計もスコープに入りがちなので、どこまでが開発側の責任か明確にします。

次に検収です。「表示できる」だけではなく、受け入れ基準を決めます。例として、主要ページの表示速度指標、フォーム送信の正常系/異常系、管理画面の権限、バックアップ、障害時の復旧手順などです。全てを完璧にする必要はありませんが、事前に合意した基準で判定できる状態にしておきます。

さらに保守・運用です。Next.jsや関連ライブラリは更新が頻繁なので、リリース後に「脆弱性対応」や「依存関係アップデート」が必ず発生します。保守契約に、月次のアップデート枠、障害一次対応、問い合わせ対応時間、軽微改修の扱いを含めると安心です。情シスがいる企業なら、監視アカウントの権限や、ログの保管期間なども合わせて決めましょう。

最後に、丸投げしないコツとして「小さく始める」方法もあります。たとえば、まずは1〜2週間で技術検証（PoC）や画面のプロトタイプを作ってもらい、コミュニケーションの相性と品質基準を確認してから本開発に進む、というやり方です。TypeScriptやNext.jsの案件は、早期に設計の良し悪しが出るため、短期検証が非常に有効です。

まとめ

TypeScript人材や外注先を見極めるには、「できますか？」ではなく、なぜその設計にするのかを説明できるかを確認するのが最短ルートです。Next.jsは選択肢が多い分、提案の質に差が出やすく、発注側が少し質問を工夫するだけで失敗確率を大きく下げられます。

• 発注前に「目的・優先順位・運用体制・制約」を簡単に整理する
• 質問集で、設計判断・TypeScript品質・運用設計・体制を見抜く
• 見積もりは「一式」ではなく、前提と作業単位が見える形で比較する
• 検収条件と保守範囲を文章化し、リリース後の運用まで合意する

もし「自社の場合、Next.jsでどこまでやるべきか」「TypeScriptの品質をどう担保すべきか」を短時間で整理したい場合は、要件が固まっていなくても構いません。現状と目的を伺い、外注比較に使える観点（設計・体制・運用）を一緒に言語化できます。