中国のソフトウェア会社と付き合う前に確認する7項目

見るべきは進め方ではなく、相手の中身

オフショア開発の失敗要因として語られるのは、多くが進め方の問題です。要件の粒度、進捗共有、検収の取り決め——これらは発注側の運用で改善できます。一方で、運用をどれだけ整えても埋まらない差もあります。相手が工場の現場を知っているか、日本語の文書を出せるか、納品後に連絡が取れるか。これらは相手側の属性であり、契約後に変えられるものではありません。

つまり確認作業は二層に分かれます。上の層はプロジェクト管理、下の層は供給者の適格性です。本記事が扱うのは下の層——契約前に相手の中身を確かめる7項目です。7項目すべてに書面で答えられる会社は、実際にはそれほど多くありません。逆に言えば、この7項目は候補を絞り込む道具として使えます。

契約前に確認する7項目

• ① 工場の現場経験があるか——IT 受託開発の実績ではなく、PLC・フィールドバス・電気制御に触ってきた経歴を確認します。設備からデータを取る工程は、Web システムの開発とは別種の作業です。自動車・家電・食品のような量産ラインで、どのメーカーの PLC をどのプロトコルで接続したかを具体的に聞けば、経験の有無はすぐ分かります。
• ② 日本語で文書を出せるか——打ち合わせに通訳が付くかではなく、規格書（式様書）と操作説明書を日本語で納品できるかを確認します。現場のオペレーターが読む文書が日本語でなければ、稼働後に使われません。中国語・英語・日本語の三言語で工程資料を出した経験があるかを聞くのが確実です。
• ③ 納品文書が体系になっているか——単発の設計書ではなく、企画から保守までの文書一覧が用意されているかを見ます。プロジェクト方案書、技術協議書、規格書、I/O 分配表、アドレス割付表、ネットワーク構成図、画面設計説明書、操作説明書、データベース定義書、データインターフェース仕様書、テスト報告書、検収資料、保守リスト、年間保守報告書——このような一覧を先に提示できるかどうかが分かれ目です。
• ④ 情報セキュリティとデータの取り扱い——接続方法（VPN・専用回線）、アクセス権限の管理、操作ログの保存、ソースコードと図面の保管場所、データを日本国内に留めるのか中国側にも置くのか。秘密保持契約の文面だけでなく、日々の運用手順として説明できるかを確認します。
• ⑤ 小範囲の試行を受けられるか——最初から全体を発注せず、設備1台やライン1本に範囲を絞った試行を引き受けるかを聞きます。試行を断る、あるいは試行と本開発の費用構成を説明できない会社は、範囲の切り方に慣れていない可能性があります。試行の成果物が本開発にそのまま使えるかも合わせて確認します。
• ⑥ 検収基準を技術協議書に書けるか——「機能を実現する」ではなく、データ遅延の上限、帳票の集計定義、通信復旧後のデータ欠損有無といった測定可能な条件を契約文書に書き込めるかを確認します。書けると即答する会社と、口頭で保証する会社の差は大きいです。
• ⑦ 納品後の保守と応答をどう約束するか——問い合わせ窓口、応答時間、年間保守の作業内容、ライン変更時の対応方法、報告書の提出頻度。年間保守契約の雛形と保守報告書のフォーマットを持っているかを見れば、継続支援の実態が分かります。

7項目のうち①②③は相手の属性、④⑤⑥⑦は契約で詰められる部分です。属性側が満たされていない場合、契約をどれだけ丁寧に書いても現場側の負担は減りません。

IT 受託型と現場背景型の違い

同じ「ソフトウェア開発会社」でも、IT 受託を主業としてきた会社と、工場の現場から立ち上がった会社では、得意な工程が異なります。どちらが正しいという話ではなく、工場系のシステムで工数がどこに溜まるかを知っておくための対照です。

上表は傾向の対照であり、個別の会社の評価ではありません。実際には両方の性格を併せ持つ会社もあります。判断材料は会社の分類ではなく、①〜⑦への回答内容です。

納品文書は「後で決める」ではなく先に確定する

工場系のシステムで揉めやすいのは、稼働後に「この文書がない」と気づいたときです。担当者の異動、設備の更新、二期の追加開発——いずれの場面でも、手元にある文書の範囲がそのまま自社で対応できる範囲になります。文書は納品物の付属ではなく、それ自体が納品物です。

確認の仕方は単純で、契約前に「納品する文書の一覧を出してください」と依頼するだけです。一覧が出てこない、あるいは「一般的なものを出します」と返ってくる場合は、体系がない可能性が高いです。体系のある会社は、以下のような分類で一覧を提示できます。

• 企画・契約系：プロジェクト方案書、技術協議書、規格書（式様書）——範囲と検収条件を定める文書
• 設計系：I/O 分配表、アドレス割付表、ネットワーク構成図、画面設計説明書——どの信号がどこから来て、どう表示されるかを定める文書
• 運用系：操作説明書、データベース定義書、データインターフェース仕様書——稼働後に現場と情報部門が使う文書
• 検証系：テスト報告書、検収資料——合意した基準を満たしたことを示す文書
• 保守系：保守リスト、年間保守報告書——稼働後の作業範囲と実施記録を残す文書

小範囲の試行で観察する5つの点

①〜⑦を書面で確認しても、実際の相性は分かりません。範囲を絞った試行を先に置くと、資料では見えない部分が短期間で見えます。体系のある会社は診断・試行・実施・検収・保守・拡張という区切りで案件を進めるため、試行だけを切り出す依頼にも対応できます。

試行の対象は設備1台またはライン1本で十分です。観察するのは成果物の出来だけではなく、以下の5点です。

• 質問の内容——現場条件を確認する質問が来るか、要件書を鵜呑みにして進めるか
• 応答の速さと形式——回答が口頭のみか、文書と図で残るか
• 文書の粒度——試行段階の資料でも、後から読み返せる水準にあるか
• 変更が発生したときの扱い——影響範囲を示してから対応するか、黙って作り直すか
• 日本語文書の実態——機械翻訳の出力に近いか、現場のオペレーターが読める文章になっているか