スマートシティ・MaaS開発の外注｜都市OS連携と運用移管の設計

複数のベンダーから提案書が届いたものの、システム構成も金額も見事にバラバラで、比較する軸そのものが作れない。ある社は都市OSの導入から提案し、別の社はアプリ開発だけを見積もってきた。金額は数百万円から数億円まで開きがあり、どれが自分たちの事業に合っているのか判断できない。スマートシティ・MaaS 開発の外注を任された担当者の多くが、まずこの場面で立ち止まります。

さらに社内からは「他都市では実証実験で終わったと聞いているが、うちはどうなのか」という問いが飛んできます。交付金の期間が終わった後に何が残るのかを説明できなければ稟議は通りません。しかし技術構成の妥当性を自分で評価できない以上、ベンダーの説明を信じるしかない状態に追い込まれます。

この状況は担当者の能力不足が原因ではありません。スマートシティ・MaaS は、発注主体が複数にまたがり、扱うデータの多くが自社の外から来て、しかも標準仕様が複数併存するという構造を持っています。一般的な業務システムの発注経験だけでは、判断軸を組み立てにくい領域なのです。

一方で、技術に詳しくなくても提案の妥当性を評価する方法はあります。委託範囲・契約形態・成果物・出口条件という四つを発注側が先に決めておけば、提案書はその枠に照らして比較できるようになります。技術的な優劣を直接判断するのではなく、「発注側が決めた枠を満たしているか」で評価する形に切り替えるということです。

本記事では、スマートシティ・MaaS 開発の外注について、実証止まりになる構造の整理から始め、委託範囲の切り分け方、都市OS・データ連携基盤の選定で確認すべき観点、フェーズ別の契約形態、ベンダーロックインを避ける仕様の書き方、実証から本番運用へ移すための出口条件、費用構造の読み方、そして発注側に判断力を確保する体制の作り方までを、発注者の視点で解説します。

スマートシティ・MaaS開発の外注が「実証止まり」になる構造

「実証実験で終わってしまった」という話は、往々にして事業採算性の問題として語られます。利用者が集まらなかった、収益モデルが成立しなかった、という説明です。しかし発注実務の側から見ると、実証止まりには別の原因が積み重なっています。

内閣府がまとめたスマートシティ施策のロードマップ（2024年3月）でも、全国でスマートシティの取り組みが始まっている一方で、多くが分野個別・都市個別の実証段階にとどまり、分野間・地域間に広がった持続的な運営・実装まで進んでいる地域は少ないという課題が示されています。

発注設計の観点から整理すると、実証止まりには次の三つの欠落が連鎖しています。

第一に、補助金・交付金の期間がそのまま開発期間になっていて、運用移管が計画に入っていないことです。交付決定から年度末までの限られた期間で「動くもの」を作ることが目的化し、期間終了後に誰が運用費を負担し、誰が保守を担うのかが決まらないまま実証が終わります。

第二に、標準仕様の選定をベンダー提案に委ねていることです。どのデータモデルを採用するか、どの API 仕様で外部に開くかという判断は、後から他システムと連携できるかどうかを決定づけます。この判断を発注側が持たずにベンダーの提案どおりに決めると、次の年度に別のサービスを追加したいときに、そのベンダーにしか作れない状態が生まれます。

第三に、発注側に技術判断者がいないことです。前の二つは、社内に技術的な妥当性を評価できる人がいれば、提案を受け取った段階で気づけます。逆にいえば、判断者不在がほかの二つの欠落を見逃させる根本原因になっています。

自治体・交通事業者のシステム開発外注が一般の業務システムと違う3点

自治体や交通事業者のシステム開発を外注する場合、社内の基幹システム更改とは異なる三つの前提があります。ここを言語化しておくと、なぜ通常の発注手順が通用しないのかが説明しやすくなります。

発注主体が複数にまたがる。MaaS アプリひとつをとっても、交通事業者・自治体・商業施設・決済事業者など、意思決定に関わる組織が並びます。仕様変更の判断を誰が下すのかが決まっていないと、開発途中で調整が止まります。

データの多くが自社の外から来る。運行データ、施設の混雑情報、気象情報、決済情報など、収集元が社外に分散しています。データ提供元との調整が開発と並行して必要になり、その調整の担い手が発注側なのか受注側なのかを最初に決めておかないと、どちらも動かない期間が生まれます。

運用主体が開発主体と別になりやすい。実証段階はベンダーが運用まで面倒を見て、本番移行後は自治体や事業者が引き取るという構図が典型です。開発時点で運用を担う組織が決まっていなければ、引き継ぎ可能な形で作られる保証がありません。

IoT センサーや現場デバイスからのデータ収集を伴う点では、製造業のスマートファクトリーが先行して同じ課題に取り組んできました。工程単位でスコープを絞って段階的に広げる考え方は都市側にも応用できるため、スマートファクトリーのIoT・AI活用も参考になります。

発注側に技術判断者がいないまま進むと何が起きるか

技術判断者が不在の状態は、単に「詳しい人がいない」以上の影響を及ぼします。

進捗と品質の報告がベンダーの自己申告のみになり、遅れや設計上の問題が表面化するのが遅くなります。見積もりの妥当性も比較できないため、金額の差が技術構成の差なのか、見積もり範囲の差なのかを区別できません。そして成果物の受け入れ検査では、動作しているかどうかしか確認できず、保守しやすい形で作られているかは検証されないまま検収されます。

この状態を「丸投げ」と呼ぶこともできますが、担当者としては丸投げしたくてしているわけではありません。判断材料を持たないまま判断を求められているだけです。したがって打ち手は「もっと勉強する」ことではなく、判断できる範囲を発注側の枠として先に固定し、そこから外れる部分だけを専門家に見てもらうという設計になります。以降ではその枠の作り方を順に見ていきます。

MaaSシステム開発を外注する前に決める3つの範囲

MaaS システム開発の外注で最初に決めるべきなのは「どのベンダーに頼むか」ではなく「何を外に出し、何を自社で持つか」です。ここが曖昧なままだと、提案書は各社が得意な範囲だけを切り出して出してくるため、そもそも比較が成立しません。

スマートシティ・MaaS のシステムは、おおまかに次の四つのレイヤに分解できます。

RFP を書き始める前に、この表の右列を自分たちの事業に合わせて埋めてみることをおすすめします。埋まらない行があれば、それが提案を受けても判断できない領域です。

範囲1: サービス企画とKPIは発注側が持つ

サービス企画と KPI は、外部に委ねてはいけない範囲です。理由は単純で、事業の成否を測る物差しを他者が決めると、本番移行の判断も撤退の判断も自分たちで下せなくなるためです。

ここで決めておくべきなのは、対象となる利用者像、提供するサービスの範囲、実証期間中に測る指標、そして本番移行を判断する水準の四つです。「アプリのダウンロード数」のような測りやすいだけの指標ではなく、「対象エリアの定期外利用者のうち、月1回以上の利用が継続する人数」のように、事業の継続性と結びつく指標にしておくと、後の出口判断が機能します。

企画の言語化を支援してもらうこと自体は外部に頼んで構いません。ただし最終的な指標の設定と、その指標に責任を持つ立場は発注側に残します。

範囲2: データ連携基盤は共同設計、アプリは外部委託しやすい

データ連携基盤は「設計は共同、構築は委託」が現実的です。どのデータをどの形式で扱い、どこまで外部に開くかという設計判断は、後述する相互運用性やロックイン回避に直結するため、発注側が意思を持つ必要があります。一方で、その設計に沿って実際に基盤を構築・設定する作業は専門性が高く、外部に委ねたほうが早く安く仕上がります。

アプリ・フロントは四つのレイヤの中で最も委託しやすい領域です。画面と機能が定義できれば成果物の範囲を明確にでき、品質も利用者視点で確認できます。ただしアプリだけを先に発注すると、後から基盤側の仕様に引きずられて作り直しが発生しやすいため、基盤の API 設計と並行して進める前提で発注します。

IoT センサーやモバイル端末を含むスコープの切り分け方については、建設現場を題材にした建設現場アプリとIoT連携の外注設計で具体的な分解例を扱っています。デバイスからのデータ収集を含む発注の考え方はスマートシティにも共通します。

範囲3: 運用・保守の担い手を発注前に決める

実証止まりを避けるうえで最も効くのが、この範囲です。運用・保守の担い手を発注前に決めるとは、次の三点を書面にしておくことを意味します。

• 実証期間中の運用を誰が担うか（多くの場合は受注ベンダー）
• 本番移行後の運用を誰が担うか（自社・自治体・別ベンダー・同一ベンダーの継続契約）
• 移行時に引き渡すもの（運用手順書、監視設定、アカウント、データ）

本番移行後の担い手が「未定」のまま発注すると、実証システムは引き継ぎを想定しない作りになります。逆に、たとえ「同一ベンダーに継続委託する」という結論であっても、それを最初に決めておけば運用費を含めた総額で比較検討ができます。決めるべきなのは担い手の名前ではなく、担い手を決める意思決定を発注前に済ませておくことです。

都市OS・データ連携基盤の選定をベンダーに丸投げしない

都市OS（データ連携基盤）は、都市の中で発生するさまざまなデータを集め、共通の形式に整え、必要とするサービスに API として提供するレイヤです。交通・防災・健康・エネルギーといった分野ごとに個別のシステムを作るのではなく、データを一箇所に集約して複数サービスから使えるようにするための仕組みだと考えると理解しやすくなります。

内閣府が整備するスマートシティリファレンスアーキテクチャでは、データ連携基盤に求められる性質として「相互運用性（つながる）」「データ流通（ながれる）」「拡張容易性（つづけられる）」が挙げられています（内閣府 スマートシティ）。この三つはそのまま発注仕様に落とせる観点です。つながるかどうか、流せるかどうか、続けられるかどうかを提案書に照らして確認する、という使い方ができます。

FIWARE / NGSI など相互運用の標準を発注仕様に書く

FIWARE は、スマートシティ向けのデータ連携基盤を構成するソフトウェアモジュール群です。その中核となるのが NGSI（Next Generation Service Interface）というオープン API 仕様で、データモデルを標準化することで異なるシステム同士が同じ形式でデータをやり取りできるようにします。国内でも内閣府のリファレンスアーキテクチャに準拠した基盤で、FIWARE の Orion（コンテキスト情報を管理するモジュール）を中核に据える構成が広く採用されています。

発注仕様への書き方としては、特定製品名を必須指定するのではなく、「データの入出力インターフェースは NGSI など公開された標準仕様に準拠すること」「採用する標準仕様とそのバージョンを提案書に明記すること」という形が扱いやすくなります。製品名で縛ると選択肢が狭まり、逆に何も書かないとベンダー独自の形式で作られてしまうためです。

地理空間データの扱いについては、内閣府からスマートシティリファレンスアーキテクチャ 別冊「地理空間データ連携基盤」が公開されています。位置情報を中心に扱う事業では、こうした公的資料の記述を発注仕様の下敷きにすると、独自解釈のリスクを減らせます。

GTFS・GTFS-RT など交通データ標準を要件に含める

交通分野には、より具体的で成熟した標準があります。GTFS（General Transit Feed Specification）は、時刻表・停留所・運賃といった運行情報を経路検索サービスに提供するための国際的なデータ仕様です。国土交通省はこれを国内の実情に合わせてローカライズした「標準的なバス情報フォーマット」を策定しており、静的データの GTFS-JP と、遅延・車両位置・到着予測などの動的データを扱う GTFS リアルタイム（GTFS-RT）の2種類で構成されています（国土交通省 公共交通運行情報標準データ（GTFS-JP）に関する資料・検討会）。

MaaS を扱うのであれば、この二つを発注要件に含めるかどうかは必ず検討すべき論点です。GTFS-JP に準拠した形でデータを整備しておけば、自前のアプリだけでなく主要な経路検索サービスにも情報を載せられます。逆に独自形式のまま作ると、利用者はそのアプリを開かない限り運行情報にたどり着けません。整備の進め方については国土交通省が「標準的なバス情報フォーマット」データ整備の手引きを公開しており、発注前の予備知識として目を通す価値があります。

要件文としては「運行情報は GTFS-JP 形式で出力可能であること」「リアルタイム情報を扱う場合は GTFS-RT に準拠すること」「出力データの生成手順を運用手順書に含めること」といった書き方になります。

都市OS採用の提案を受けたときに確認する質問

技術構成そのものを評価できなくても、次の質問への回答を求めることで提案の性格は判別できます。回答が具体的かどうか、書面に残せるかどうかが判断材料になります。

• このデータ連携基盤は、どの標準仕様のどのバージョンに準拠していますか。準拠していない独自拡張部分はどこですか
• 蓄積されたデータを一括で取り出す方法はありますか。その形式と、取り出しにかかる作業・費用はどの程度ですか
• 他社が新しいサービスを追加する場合、どの API を使いますか。その API の仕様書は納品物に含まれますか
• 契約終了後もこの基盤を使い続ける場合、ライセンス費用と保守はどうなりますか
• 同種の基盤を他自治体・他事業者に導入した実績はありますか。そこでは別ベンダーによる追加開発が行われましたか

最後の質問は特に有効です。同じ基盤に別のベンダーが後から手を入れた実績があるかどうかは、開かれた作りになっているかを示す実績ベースの証拠になります。

データ基盤そのものを外部委託する際の分担設計や成果物定義については、データ基盤構築の外部委託でフェーズ別の考え方を整理していますので、あわせて参照してください。

委託範囲別の契約形態｜請負と準委任の使い分け

契約形態の選択は、多くの担当者が「一括請負にすると仕様変更に対応できない、かといって準委任にすると社内に管理できる人がいない」というジレンマに突き当たる領域です。この二択で悩むのではなく、フェーズごとに使い分けるのが現実的な解になります。

請負契約は成果物の完成に対して対価を支払う契約で、仕様が確定していることが前提になります。準委任契約は業務の遂行そのものに対価を支払う契約で、仕様が固まりきらない探索的な作業に向いています。IPA（情報処理推進機構）が公開する情報システム・モデル取引・契約書では、両者の適用場面や契約条項の考え方が整理されており、アジャイル開発版では仕様変更を前提とする開発を準委任契約で進めるモデルが示されています。

フェーズ別の契約形態の使い分け

このフェーズ分割発注には明確なメリットとリスクがあります。メリットは、各フェーズの終了時点で継続・中止・ベンダー変更を判断できることです。リスクは、フェーズのつなぎ目で責任の所在が曖昧になることです。企画フェーズの成果物を別ベンダーが実装して不具合が出たとき、要件定義の不備なのか実装の不備なのかを切り分ける必要が生じます。

このリスクを下げるには、各フェーズの成果物の完成基準を先に定義しておくことが有効です。「要件定義書には API 一覧と非機能要件を含む」「実証の完了報告には検証項目ごとの結果と、本番実装時に想定される課題を含む」といった水準を契約時に書いておけば、つなぎ目での議論が事実ベースになります。

なお、準委任契約で外部人材が常駐する形態を取る場合は、指揮命令関係の整理が必要です。発注側が受注側の作業者に直接指示を出すと偽装請負とみなされる可能性があるため、業務の進め方については受注側の責任者を通じて調整する形にします。

発注側に最低限置く2つの役割

準委任契約を選ぶと管理コストが発生します。誰がその管理を担うかまでを設計に含めないと、契約形態だけ整えて実態は丸投げ、という状態になりかねません。

発注側に最低限置くべき役割は二つです。

意思決定者は、仕様の最終決定と優先順位づけの責任を持ちます。複数組織が関わるスマートシティ・MaaS では、この役割が誰なのかを事業開始時に明文化しておくことが特に重要です。関係者の合意形成に時間がかかる場合でも、「最終的にこの人が決める」という取り決めがあるだけで開発の停滞は減ります。技術知識よりも、事業目的と関係者調整の理解が求められる役割です。

技術評価者は、提案書・設計書・成果物の技術的な妥当性を確認します。アーキテクチャが標準に準拠しているか、見積もりの工数が作業内容に見合っているか、納品物が保守可能な形になっているかを見る役割です。この役割は常時必要とは限らず、提案評価時と受け入れ検査時に集中的に稼働します。社内に該当者がいない場合の確保方法は、記事の後半であらためて扱います。

ベンダーロックインを避ける外注仕様の書き方

ベンダーロックインは、しばしばベンダー側の意図的な囲い込みとして語られます。しかし発注実務の現場で起きているロックインの多くは、意図の問題ではなく取り決めの欠落によって生じています。納品物に設計書が含まれていなかった、データの取り出し方法が決まっていなかった、API 仕様が文書化されていなかった。こうした欠落が積み重なった結果、他社が引き継げない状態になります。

公正取引委員会が公表した官公庁における情報システム調達に関する実態調査（2022年2月）でも、特定のベンダーを利用し続けざるを得ない状態を回避し、多様なベンダーが参入しやすい環境を整えることの重要性が指摘されています。デジタル庁の情報システム調達改革検討会 最終報告書（2023年3月）では、一者応札を防ぐための具体的な仕様書の記載案も示されています。公共調達の文脈で整理された論点ですが、民間の発注にもそのまま応用できます。

重要なのは、これらが技術知識ではなく契約文言で担保できるという点です。技術構成の優劣を判断できなくても、受け取るものと権利関係を明記しておけば、後から他社に移せる可能性は大きく上がります。

成果物として受け取るものを列挙する

「システム一式」という書き方では、何が納品されるかが定まりません。次の項目を個別に列挙します。

• ソースコード: 実行可能な形式だけでなく、ソースコード本体。バージョン管理リポジトリごと引き渡す形が扱いやすい
• 設計書: システム構成図、データフロー、データベース設計、外部連携の一覧
• API 仕様書: エンドポイント、リクエスト・レスポンスの形式、認証方式。機械可読な形式（OpenAPI 等）での提供を求めると流用しやすい
• データモデル定義: 蓄積するデータの項目定義と、採用した標準仕様との対応関係
• 環境構築手順: 開発環境・本番環境を再構築するための手順と設定値の一覧。特定の担当者しか再現できない状態を避けるため
• 運用手順書: 日常運用、障害時対応、データ更新の手順

これらの著作権および利用権の帰属についても、契約書で明示します。すべてを発注側に譲渡させることが常に最善とは限らず、ベンダーが汎用部品として保有する部分については「発注者が無償で継続利用でき、第三者に改修を委託できる権利」を確保する形も現実的な落としどころです。

データとAPIの権利・移管条件を契約に書く

システムそのもの以上に重要なのが、蓄積されたデータの扱いです。スマートシティ・MaaS では位置情報や利用履歴など、事業の資産となるデータが継続的に蓄積されます。

契約に書いておくべき項目は次のとおりです。

データの帰属: 事業を通じて収集・生成されたデータの権利が誰に帰属するか。基盤上に蓄積されたデータであっても、事業者側に帰属することを明記します。

持ち出し条件: データを一括でエクスポートする方法、対応する形式、要する期間と費用。「契約期間中いつでも、追加費用なく、標準的な形式で全データを取得できる」という条項があると、移行時の交渉が容易になります。

引き継ぎ時の協力義務: 契約終了時に後継ベンダーへ技術的な引き継ぎを行う義務と、その範囲・期間。あわせて、その作業に対する対価の考え方も定めておくと、実際の場面で揉めにくくなります。

個人情報の取り扱いと責任分界点: 位置情報や決済情報を扱う場合、取得・保管・削除の各段階でどちらが責任を持つかを明確にします。委託先での再委託の可否と、再委託先に対する監督責任の所在も含めます。

標準準拠の要求: 前述の相互運用性の観点を、努力目標ではなく要件として書きます。準拠していない独自拡張が必要な場合は、その範囲と理由を文書化させます。

実証実験（PoC）を本番運用へ移すための出口条件

実証を本番につなげるための最も効果的な打ち手は、実証を始める前に出口条件を決めておくことです。実証が終わってから「さて本番はどうしよう」と考え始めると、判断材料も予算も体制も揃っていない状態で議論することになります。

国土交通省の日本版MaaS推進・支援事業をはじめ、実証を支援する制度は複数用意されています。こうした制度を活用する際こそ、支援期間の終わりから逆算した設計が必要になります。

補助金・交付金の期間終了日から逆算する

出口条件は次の三つで構成します。

本番移行の判定基準。実証で測る指標と、本番移行を決断する水準を数値で定めます。「利用者数が想定の何割に達したら移行する」「運行事業者の業務時間が何時間削減されたら移行する」といった形です。この水準は、企画段階で決めた KPI と整合させます。

運用費の負担者と財源。本番移行後、毎年発生するクラウド利用料・保守費・外部サービス利用料を誰がどの財源で負担するかを、実証開始前に確認します。負担者が確定していない場合でも、「年間いくらまでなら負担可能か」という上限だけは押さえておきます。この上限が、実証段階でのシステム構成の選択肢を左右します。

判断の期日。補助金・交付金の期間終了日から逆算して、いつまでに移行可否を判断するかを決めます。本番移行には契約手続き・予算措置・体制準備が必要で、これらには数か月かかります。実証の最終日に判断していては間に合いません。終了日の3〜6か月前を判断期日として設定し、そこで判断できるだけのデータが揃うよう実証計画を組みます。

撤退基準とデータ・資産の扱いを先に決めておく

出口条件というと「どうすれば続けられるか」だけを考えがちですが、撤退基準を同時に決めておくほうが、結果として継続の確率は上がります。

理由は二つあります。ひとつは、撤退基準があると実証の設計が引き締まることです。「この水準に届かなければやめる」と決めた瞬間、その水準を測るためのデータ取得が実証計画に組み込まれます。曖昧な実証は、良い結果も悪い結果も測れないまま終わります。

もうひとつは、社内の合意形成が進みやすくなることです。経営層や議会に対して「うまくいかなければこの条件でやめます」と説明できる案件は、意思決定の心理的ハードルが下がります。継続を前提にした説明よりも、撤退条件を含む説明のほうが承認を得やすい場面は少なくありません。

撤退を選ぶ場合に備えて、次の点も決めておきます。

• 蓄積したデータをどう保管・活用するか（別事業への転用可否を含む）
• 構築したシステムの資産としての扱い（廃棄・保管・部分流用）
• 関係者・利用者への周知方法と時期
• ベンダーとの契約終了手続きと、その時点で発生する費用

これらを決めておくと、撤退が「失敗の後始末」ではなく「計画に含まれた選択肢の実行」になります。

スマートシティ・MaaS開発の費用構造と見積もりの読み方

複数社の見積もりを比較できない最大の理由は、各社が見積もっている範囲が違うことです。金額の大小を比べる前に、同じ土俵に載せる作業が必要になります。

初期開発費より運用費・データ利用料を確認する

スマートシティ・MaaS のシステムでは、初期開発費に注目が集まりがちですが、事業の持続性を左右するのは運用費です。運用費には次のようなものが含まれます。

見積もり依頼時に「初期費用と、本番運用開始後の年間運用費を分けて提示すること」「運用費のうち利用者数に応じて増減する部分を明示すること」を条件に加えると、比較しやすくなります。運用費の見落としは、交付金終了後に事業を畳まざるを得なくなる直接的な原因になります。

一括見積もりを分解して比較可能にする

「システム構築一式 ○○○万円」という見積もりは、そのままでは比較できません。次の粒度での分解を各社に求めます。

• レイヤ別: データ連携基盤、アプリ、管理画面、外部連携など、機能のまとまりごとの金額
• フェーズ別: 要件定義、設計、実装、テスト、移行、それぞれの金額
• 単価と工数: 役割（プロジェクトマネージャー、アーキテクト、エンジニアなど）ごとの人月単価と想定工数

この三つが揃うと、金額差の理由が見えてきます。単価が高いのか、工数見積もりが多いのか、そもそも含まれている範囲が広いのか。範囲の差であれば、含まれていない部分を別途手当てする必要があるかどうかを検討できます。

分解を求めても「一式でしかお出しできない」という回答が返ってくる場合は、その理由を確認します。合理的な説明があるケースもありますが、内訳を示せないこと自体がプロジェクト管理の粗さを示している場合もあります。

なお、金額の相場感を外部の記事や資料から得ようとしても、スマートシティ・MaaS は事業規模と対象範囲の幅が極端に広いため、参考になる水準を見つけるのは困難です。相場を探すよりも、自分たちの案件について複数社から分解された見積もりを取り、その差分を説明できる状態にするほうが確実です。

外部人材を組み合わせて発注側の判断力を確保する

ここまで、委託範囲・標準仕様・契約形態・成果物・出口条件・費用の読み方を見てきました。これらはいずれも「発注側が枠を決める」ことで機能します。しかし枠を決める過程でも、決めた枠に照らして提案を評価する場面でも、技術的な判断が必要になります。

冒頭で挙げた根本原因、つまり「判断できる人が社内にいない」状態への打ち手が、この最後の論点です。

選択肢は正社員の採用だけではありません。技術評価という役割は、常時フルタイムで必要とされるわけではないため、必要な局面に絞って外部の専門家に入ってもらうという組み立てが成立します。

技術評価者を短期・スポットで確保する

技術評価者に求める役割は、おおむね次の三つに整理できます。

アーキテクチャレビュー。提案されたシステム構成が、事業の要件と将来の拡張に対して妥当かを確認します。標準仕様への準拠、データの持ち方、外部連携の設計が主な観点です。

見積もり妥当性の検証。分解された見積もりを見て、作業内容に対して工数が過大・過小でないかを判断します。特に、記載されていない作業（データ移行、既存システムとの接続テスト、運用引き継ぎなど）の抜け漏れを指摘してもらう価値が大きい部分です。

成果物受け入れ基準の作成と検査。何をもって完成とするかの基準を事前に定義し、納品時にその基準を満たしているかを検証します。動作確認だけでなく、設計書と実装の整合性や、保守可能な形になっているかを見ます。

これらが特に効くタイミングは三つあります。RFP 作成前（発注する枠そのものを設計する段階）、提案評価時（複数社の提案を比較する段階）、受け入れ検査時（納品物を検収する段階）です。逆にいえば、この三点に絞れば、フルタイムでなくても発注側の判断力は確保できます。

短時間・スポットでの外部人材活用は、こうした「常時は不要だが不在だと困る」役割と相性のよい形態です。週数時間の稼働でレビューに入ってもらう、提案評価の期間だけ集中的に見てもらう、といった使い方が考えられます。副次的な効果として、社内の担当者がレビューの過程に同席することで、判断の観点そのものを習得できる点も見逃せません。

内製化に向けた段階的な体制移行

外部の技術評価者に入ってもらうことは、外部依存を増やすことではありません。段階的に社内へ判断力を移していくための入口として位置づけると、事業の持続性につながります。

現実的な移行の段取りは次のようになります。

第1段階（初回の発注時）: 外部の技術評価者が主導し、社内担当者が同席する。レビュー観点と質問の仕方を、実際の案件を通じて共有してもらいます。

第2段階（実証から本番移行の時期）: 社内担当者が一次評価を行い、外部評価者が確認する形に切り替えます。判断の根拠を社内で言語化できるようになることが目標です。

第3段階（運用フェーズ以降）: 日常的な判断は社内で完結させ、大きな構成変更や新規発注のタイミングだけ外部にレビューを依頼します。

この移行を成立させるには、外部人材を「作業を代行してもらう相手」ではなく「判断の観点を共有してもらう相手」として位置づけることが必要です。契約時の期待役割にレビューの言語化・記録を含めておくと、社内に知見が残りやすくなります。

まとめ

スマートシティ・MaaS 開発の外注では、技術構成そのものを発注側が評価できなくても、次の五つを発注前に決めておくことで、実証止まりとベンダーロックインの両方を防げます。

1. 委託範囲: サービス企画と KPI は自社で持ち、データ連携基盤は共同設計、アプリは委託、運用の担い手は発注前に確定する
2. 契約形態: 企画・実証は準委任、仕様が固まった実装は請負、運用は準委任＋SLA というフェーズ別の使い分け
3. 成果物: ソースコード・設計書・API 仕様書・データモデル定義・環境構築手順・運用手順書を個別に列挙し、権利関係を明記する
4. 出口条件: 本番移行の判定基準、運用費の負担者と財源、判断の期日、そして撤退基準を実証開始前に決める
5. 判断者: 意思決定者と技術評価者を発注側に置き、技術評価者は必要な局面に絞って外部から確保する

明日から着手できることは二つあります。ひとつは、本記事で示した四つのレイヤ（サービス企画・データ連携基盤・アプリ・運用保守）について、自社が持つ範囲と委託する範囲を表に書き出してみることです。埋まらない行が、現時点で判断材料が足りない領域を示しています。

もうひとつは、出口条件を1枚の資料にまとめることです。本番移行の判定基準、運用費の負担者、判断期日、撤退基準の四項目だけで構いません。この1枚があると、ベンダーとの会話も社内の稟議も、格段に進めやすくなります。

関連情報

外部人材を発注側の技術評価者として組み込む進め方については、外部エンジニア活用の戦略ガイドで役割定義・契約形態・稼働設計を整理しています。発注体制の検討にあわせてご覧ください。

委託範囲の切り分けや発注体制の整理段階でご相談されたい場合は、お問い合わせフォームからご連絡ください。要件が固まる前の段階からご相談いただけます。