製品開発の協力会社のBCPを確認する5項目｜災害・停止時の開発中断に備える

製品開発を外部の協力会社と進める場合、技術力や品質、納期対応力だけでなく、災害や設備停止などが起きたときに開発を継続できる体制があるかも重要な確認事項です。設計、試作、評価、部品調達、治具製作、量産準備などの一部を協力会社に依存している場合、その会社の業務停止が自社の開発日程へ直接影響する可能性があります。

特に注意したいのは、協力会社そのものが全面的に停止するケースだけではありません。担当者が長期間不在になる、特殊設備が故障する、通信環境が利用できなくなる、材料が入荷しない、外部の加工先が停止するなど、一部分の機能が失われるだけでも開発工程が止まることがあります。

こうしたリスクに備える考え方として重要になるのがBCPです。BCPでは、想定外の事態が発生しても重要な業務を継続し、停止した場合にはできるだけ円滑に復旧できるよう、人員、設備、情報、拠点、調達などの対応を事前に考えておきます。

ただし、協力会社から「BCPを策定しています」と説明を受けるだけでは、自社の製品開発を守れるかどうかまでは判断できません。自社案件に関係する工程について、何が停止する可能性があり、どのような代替手段があり、どの情報を使って再開するのかまで具体的に確認する必要があります。

この記事では、「製品開発 協力会社」で検索している設計、開発、調達、生産技術などの実務担当者に向けて、協力会社のBCPを確認するときに押さえたい5つの項目を解説します。協力会社選定時だけでなく、開発開始後や量産準備段階でも使える考え方として整理していきます。

製品開発の協力会社でBCP確認が重要な理由

製品開発では、すべての工程を自社だけで完結させるとは限りません。構想設計は自社で行い、詳細設計を協力会社へ依頼するケースもあれば、試作加工、基板や筐体の設計、評価、部品調達、治具製作などを外部へ委託するケースもあります。専門性の高い工程ほど、特定の協力会社が重要な役割を担うことも珍しくありません。

このような開発体制では、一つの協力会社の停止が、その工程だけの問題では終わらないことがあります。例えば試作品の製作が停止すれば、試作完了後に予定していた評価も始められません。評価が遅れれば、その結果を反映する設計変更も後ろへずれます。さらに、量産仕様の確定や部品発注まで影響すれば、一つの停止が製品開発全体の日程へ広がる可能性があります。

開発工程には前後関係があります。そのため、停止した工程そのものの期間だけを見るのでは不十分です。後続工程を開始する条件になっている作業が止まれば、その影響は連鎖します。特に発売日、展示予定、顧客への納入時期、量産立ち上げ時期などが決まっている製品では、開発途中の停止を後工程だけで吸収することが難しい場合があります。

また、開発中断の原因は大規模な自然災害だけではありません。局所的な停電、火災、浸水、通信障害、設備故障、建物の使用制限、感染症の拡大、人員不足、物流停止、材料不足なども業務継続に影響します。会社全体は動いていても、自社案件を担当している設備や担当者だけが利用できなくなれば、実質的にはその案件が停止することがあります。

このため協力会社のBCP確認では、「会社として事業を継続できるか」という大きな視点と、「自社案件を継続できるか」という具体的な視点を分けて考えることが重要です。

例えば、協力会社に複数の事業所があっても、自社案件に必要な設備が一つの拠点にしかなければ、拠点分散の効果は限定的です。複数の設計者が在籍していても、自社製品の設計経緯を理解している担当者が一人だけであれば、担当者不在による停止リスクがあります。

BCPは書類の有無だけで評価するのではなく、開発工程のどこに依存が集中しているかを見つけるための確認として使うことが大切です。技術力や品質力が高い協力会社でも、重要工程が一人、一台、一拠点、一社の調達先に集中していれば、その点は別途リスクとして管理する必要があります。

逆に、協力会社側に完全な代替体制がなくても、図面や仕様、試験条件などを自社と適切に共有できていれば、停止時に別の選択肢を検討しやすくなります。BCP確認では、停止そのものを完全に防ぐことだけを目標にするのではなく、停止したときに影響を限定し、開発再開までの手戻りを減らせる状態をつくることが重要です。

確認項目1　停止時に影響する開発工程と依存関係を把握する

最初に確認したいのは、協力会社の業務が停止した場合、自社のどの開発工程まで影響するのかです。BCPの確認というと、防災設備や緊急連絡網などに目が向きがちですが、発注側にとって最初に把握すべきなのは、自社案件との依存関係です。

例えば「詳細設計を委託している」という把握だけでは十分ではありません。実際の業務には、要求仕様の確認、構想の具体化、部品選定、図面作成、試作手配、組立確認、評価結果の反映、設計変更など複数の作業があります。その中でどの作業を協力会社が担当し、どの作業が止まると後続工程を開始できなくなるのかを整理します。

特に確認したいのが、代替しにくい工程です。特殊な知識を持つ担当者だけが設計判断を行っている場合や、特定の設備でしか加工できない部品がある場合、その部分が開発の停止要因になりやすくなります。

属人化も重要な確認ポイントです。担当者本人しか設計の背景を理解していない状態では、図面が残っていても別の担当者へ簡単には引き継げません。なぜその材料を選んだのか、なぜ特定の寸法にしたのか、過去にどの案を検討して採用しなかったのかといった判断経緯が共有されていなければ、担当者交代後に同じ検討をやり直す可能性があります。

設備についても同様です。試作加工機、測定設備、評価設備などが一台しかない場合、その設備が止まることで関連工程も止まる可能性があります。単純に設備台数を見るのではなく、自社案件で要求する加工範囲、精度、試験条件などを別設備でも満たせるかを確認する必要があります。

さらに、工程間の依存関係も把握します。例えば加工設備そのものには代替機があっても、その前工程で使用する専用治具を一つしか保有していなければ、治具が損傷した時点で工程を継続できなくなることがあります。治具の製作図面がなく、製作方法を特定担当者しか知らない場合には、復旧にも時間がかかります。

試験や評価でも同様です。評価設備を別拠点へ移せても、試験条件、試料番号、途中までの結果、判定基準などが整理されていなければ、同じ状態から試験を再開することは難しくなります。

BCP確認では、工程を大きな業務名だけで整理せず、実際に開発を動かしている情報、人員、設備、治具、材料などまで含めて依存関係を見ることが重要です。

また、協力会社が停止した場合に自社側でできることも同時に考えます。試作が一時停止したとしても、その間に次の設計検討を進められる場合があります。評価設備が使えなければ、先に資料整理や別項目の検証を進められるケースもあります。

つまりBCPでは、停止をゼロにすることだけではなく、ある工程が止まったときに他の工程まで一緒に止めない工夫も重要です。開発スケジュールと協力会社の担当業務を対応させ、停止した場合にどこへ影響が波及するのかを事前に整理しておけば、優先して対策すべき工程を判断しやすくなります。

確認項目2　人員・設備・拠点の代替手段を確認する

二つ目に確認したいのは、人員、設備、拠点の代替手段です。設計データさえ保存されていれば開発を継続できるとは限りません。製品開発では、専門知識を持つ人員、試作や測定に使う設備、作業場所などが必要になるためです。

まず人員については、主担当者が業務を継続できなくなった場合の体制を確認します。複数人が案件概要を理解しているのか、技術的な判断内容を記録しているのか、代替担当者が必要な情報へアクセスできるのかが重要です。

単純に「担当者が複数いる」というだけでは十分とは限りません。例えば一人が設計を担当し、もう一人が管理業務だけを担当している場合、設計担当者の代替にはならない可能性があります。非常時に本当に業務を引き継げる人がいるかという視点で確認する必要があります。

担当者交代に備えるためには、日頃から設計判断や変更内容を記録しておくことが有効です。最新版の図面だけでなく、その状態に至るまでの経緯を残しておけば、別担当者も状況を理解しやすくなります。これはBCPだけでなく、通常の人事異動や退職、長期休暇などへの対策にもなります。

設備については、主要設備が停止したときに代替できるかを確認します。同じ名称の設備が複数あったとしても、加工可能な寸法、精度、測定範囲、試験条件などが異なれば、そのまま置き換えられるとは限りません。

さらに、設備が故障した場合の復旧手段も重要です。交換部品を確保しているのか、保守担当へ連絡できる体制があるのか、主要設備に日常点検や予防保全を行っているのかといった運用によって、停止期間は変わります。

専用治具や測定具も見落としやすいポイントです。設備は無事でも、治具が破損してしまえば同じ条件で加工や検査を続けられないことがあります。再製作に必要な図面や仕様が保存されているか、必要に応じて別の場所でも製作できるかを確認しておくと、復旧方法を考えやすくなります。

拠点については、一つの事業所が利用できなくなった場合に別拠点へ移せるかを確認します。ただし、「別拠点があります」という説明だけで安心するのは避けたいところです。

自社案件に必要な設備があるのか、その設備に稼働余力があるのか、担当者を移動できるのか、治具や材料を移送できるのかといった具体的な条件まで考える必要があります。代替拠点に設備があっても、既存案件で埋まっている場合には緊急時に受け入れられない可能性があります。

設計業務であれば、通常の事業所を使えなくても別の場所から作業を継続できるケースがあります。その場合も、設計データへのアクセス権限、通信環境、必要な情報の保管状況などが整っていることが前提になります。

BCPの実効性を確認するときは、「代替できます」という回答だけではなく、誰が、どこで、何を使って、どの工程から再開するのかまで具体化できるかを見ることが有効です。平常時から移管方法が整理されている協力会社ほど、実際の停止時にも対応を開始しやすくなります。

確認項目3　設計データと開発記録のバックアップ体制を確認する

三つ目は、設計データと開発記録のバックアップ体制です。製品開発では、設備が復旧しても必要なデータが失われていれば、停止前の状態から業務を再開できません。

対象となる情報は、完成した図面だけではありません。要求仕様、三次元データ、部品情報、試験条件、評価結果、不具合記録、設計変更履歴、議事記録、製造条件、検査条件、治具図面、材料情報など、開発判断や作業再開に必要な情報全体を考える必要があります。

まず確認したいのは、重要な情報が一つの場所だけに保存されていないかです。同じ建物内の機器だけにデータを保管している場合、火災や浸水などによって同時に利用できなくなる可能性があります。事業継続を考えるなら、主要情報を別の環境から復旧できる仕組みが必要になります。

バックアップの頻度も重要です。開発途中では図面や仕様が頻繁に変更されることがあります。バックアップ間隔が長い場合、復旧後に最新変更分を失い、大きな手戻りにつながる可能性があります。

ただし、すべての情報を同じ頻度で保存すればよいわけではありません。更新頻度や重要度に応じて、失っても許容できる情報量を考えることが重要です。日々更新される設計データと、ほとんど変更されない基礎資料では、必要な保全方法が異なる場合があります。

バックアップは存在するだけでは十分ではありません。必要なときに実際に復元できるかも重要です。保存対象から重要なデータが漏れていたり、復旧方法を知っている担当者が不在だったりすれば、非常時に十分な機能を発揮できません。

また、設計変更履歴はBCPの観点でも重要です。最新版だけを保管していて、なぜその設計に変更したのかが記録されていない場合、別担当者が引き継ぐと過去の検討をやり直す可能性があります。

例えば材料変更の理由が調達性だったのか、強度だったのか、加工性だったのかが分からなければ、非常時に代替材料を検討するときにも判断が難しくなります。変更内容だけでなく、変更理由や確認結果を記録することが、開発再開のしやすさにつながります。

発注側としては、協力会社だけが保有する情報と、自社でも保有する情報を整理しておく必要があります。途中成果物をすべて常時受け取る必要があるとは限りませんが、協力会社が長期間停止した場合に何も参照できない状態は避けたいところです。

開発開始時に、どの情報をどの時点で共有するのか、正式な成果物として何を受け取るのか、設計変更履歴をどのように残すのかを決めておけば、BCPだけでなく通常のプロジェクト管理も行いやすくなります。

ファイルの整理方法も見逃せません。必要なデータが存在していても、担当者独自の名称で保存され、どれが最新版なのか分からない状態では、緊急時に探索するだけで時間がかかります。

BCPにおける情報保全の目的は、単純にファイルを消失させないことではありません。担当者や作業場所が変わっても、必要な人が必要な情報を取り出し、開発を続けられる状態にしておくことです。

確認項目4　緊急時の連絡・判断・復旧手順を確認する

四つ目は、緊急時の連絡、判断、復旧手順です。災害や設備停止が発生した直後は、協力会社側でも状況を把握できていない可能性があります。その中で誰が情報を確認し、誰が発注側へ連絡し、どのように復旧方針を決めるのかが整理されているかを確認します。

通常時には営業担当者や開発担当者が窓口になっていても、その担当者自身と連絡が取れなくなることがあります。そのため、主担当者以外の連絡経路を用意しているかが重要です。

連絡を受ける発注側でも、確認したい情報をあらかじめ整理しておくと初動が速くなります。緊急時には、単に「会社が停止しています」という情報だけでは開発計画を見直せません。

自社案件に関係する担当者の状況、建物や設備の状態、設計データへのアクセス可否、試作品や材料の状態、停止している工程、継続可能な工程などが分かれば、どの対応を優先するか判断しやすくなります。

一方、災害直後に正確な復旧日時まで求めることは現実的ではない場合があります。現場確認が終わっていない段階では、設備の損傷状況や物流の回復状況を判断できないためです。

そのため、最初から確定した復旧日を求めるより、現時点で分かっていることと、次に状況を更新できる時点を分けて共有する運用が適しています。情報更新の間隔が分かれば、発注側も開発計画の見直し時期を決めやすくなります。

また、発注側自身の意思決定手順も重要です。協力会社が一時停止したとき、どの程度まで復旧を待つのか、いつから代替手段を検討するのかを事前に考えておくと、問題発生後の判断を早められます。

代替部品への変更、評価方法の変更、別の協力会社への一部移管などには、自社内の承認が必要になる場合があります。通常時と同じ手続きしか認められていなければ、協力会社側が代替案を提示しても、自社の承認待ちによって開発が止まる可能性があります。

重要案件では、緊急時の判断権限についても整理しておくと実務的です。どの範囲なら担当部門で判断できるのか、どの変更から上位承認が必要になるのかを決めておけば、停止時の対応を進めやすくなります。

復旧の定義についても注意が必要です。例えば加工設備が再稼働したからといって、必ずしも開発を再開できるとは限りません。測定設備が使えない、担当者が不足している、必要な材料が届いていない、データへアクセスできないといった問題が残っていれば、実際の工程は動きません。

そのため、BCPでは「設備復旧」と「業務再開」を分けて考えることが重要です。自社案件の再開に必要な人員、設備、データ、材料、治具、通信環境などがそろった時点を実質的な復旧と考えます。

緊急連絡網を持っているだけでは、製品開発のBCPとして十分とはいえません。連絡後にどの情報を集め、誰が判断し、何を優先して復旧するのかまで確認することで、停止期間を短くするための準備になります。

確認項目5　調達先や再委託先を含めたBCPと見直し体制を確認する

五つ目は、協力会社自身だけでなく、その先にある調達先や再委託先まで含めて継続性を見ることです。

製品開発では、協力会社に被害がなくても、その会社が利用している材料や部品、外部加工などが停止することで自社案件が止まることがあります。

例えば協力会社が試作品を組み立てられる状態でも、重要部品が届かなければ作業は進みません。特殊材料、専用部品、外部加工、表面処理、熱処理、試験などを特定の一社に依存している場合、その先の停止が自社の開発日程へ影響する可能性があります。

そのため重要部品や重要工程では、供給経路がどの程度集中しているかを確認します。ただし、単純にすべてを複数の会社へ分散すればよいわけではありません。

製品仕様や品質上の理由から、特定の調達先しか利用できないこともあります。その場合には、一定量の在庫を確保する方法、早期に発注する方法、代替品を使う場合の評価方法など、別の対策を考える必要があります。

開発段階では量産と比べて使用量が少ないため、調達リスクが軽視されることがあります。しかし、試作に必要な一つの部品が入手できなければ、評価そのものを開始できない場合があります。量が少ないから影響も小さいとは限りません。

特に、調達に時間がかかりやすい部品や、仕様変更による代替が難しい部品については、開発初期から供給停止時の対応を検討しておくことが重要です。

再委託工程も確認します。協力会社が設計から製作まで一貫して担当しているように見えても、一部の加工や検査を外部へ依頼していることがあります。

重要な工程を再委託している場合、その委託先が停止したときに代替できるかどうかは、自社案件の継続性に関係します。機密性や取引条件などの理由で詳細な情報をすべて開示できない場合でも、重要工程に単一依存があるか、代替方針を持っているかを確認することは有効です。

そして、BCPは一度確認すれば終わりではありません。開発期間中には、担当者、設備、工程、拠点、材料、調達先などが変わる可能性があります。

試作初期には大きなリスクではなかった工程でも、量産準備が進むにつれて重要度が高くなることがあります。逆に、設計確定によって代替方法が明確になり、リスクが下がることもあります。

そのため、仕様確定、試作開始、主要評価完了、量産準備開始などの節目に、依存関係を見直すことが有効です。

協力会社側でBCPの訓練や更新を行っているかも確認材料になります。計画書を作成していても、連絡先が古くなっていたり、代替担当者が異動していたり、代替拠点の設備条件が変わっていたりすれば、緊急時に想定どおり機能しない可能性があります。

BCPは固定された文書ではなく、実際の開発体制に合わせて更新される仕組みとして考えることが大切です。

BCPは復旧時間と許容できる停止期間まで考える

協力会社のBCPを比較するときは、対策の有無だけでなく、停止した場合にどの程度で業務を再開できそうかという時間軸で考えることが重要です。

同じ「代替手段あり」でも、すぐに切り替えられるケースと、治具の再製作や設備調整が必要なケースでは、実際の開発への影響が異なります。

例えば設計業務は比較的早く別環境へ移行できても、試作設備の復旧には時間がかかる可能性があります。反対に設備自体は使えても、材料が届かなければ加工できません。業務ごとに停止要因と復旧条件が違うため、一つの復旧期間だけで会社全体を評価しないことが重要です。

発注側でも、どの程度の停止なら許容できるかを整理します。

ある工程は数日の停止であればスケジュールを調整できても、一週間を超えると後続工程に大きく影響するかもしれません。一方、別の工程は設計確定まで時間があり、短期間の停止であれば開発全体にはほとんど影響しない場合があります。

こうした違いを整理すれば、すべての工程に同じレベルのBCPを求める必要はありません。停止時の影響が大きい工程ほど重点的に対策し、影響が小さい工程では過剰な対策を避けるという考え方ができます。

また、完全復旧だけを待つのではなく、一部だけ先に再開する方法も考えます。

試作設備が使えなくても設計検討を進める、主要試験ができなくても別の評価項目を先行する、一部の加工だけ代替先へ移すなど、工程を分けることで全体停止を避けられることがあります。

重要なのは、「いつ元どおりになるか」だけを見るのではなく、「どの業務なら先に再開できるか」という視点を持つことです。

BCPでは大規模災害を完全に防ぐことはできません。しかし、担当者の複数化、データの保全、代替設備の検討、調達経路の把握などによって、停止後の選択肢を増やすことはできます。

その選択肢が増えるほど、一つの障害が製品開発全体の長期停止へつながる可能性を抑えやすくなります。

協力会社選定時だけでなく契約と日常運用にBCPを組み込む

協力会社のBCPは、選定時の確認表だけで終わらせないことが重要です。実際に開発を始めると、選定時には見えていなかった依存関係が明らかになることがあります。

契約前には、会社全体としての基本的な継続体制を確認します。主要拠点、重要設備、データ保全、緊急連絡、代替人員などを見ることで、事業継続に対する基本的な考え方を把握できます。

開発開始後は、自社案件固有のリスクへ確認範囲を広げます。主担当者だけに情報が集中していないか、専用治具をどこで管理しているか、最新版の図面をどのように共有するか、試作条件や評価結果をどこまで記録するかといった運用を確認します。

契約や発注条件では、成果物の範囲を明確にしておくことも重要です。

完成時に図面だけを納品してもらう契約なのか、途中の設計データや試験記録も共有するのかによって、停止時に発注側が利用できる情報量は変わります。

また、案件終了時の引継ぎもBCPと関係します。開発終了後に保守や追加改良を予定している場合、協力会社にしか分からない情報を残したまま案件を終了すると、その後の担当者変更や事業停止時に対応しにくくなります。

開発完了時には、最終図面だけでなく、必要に応じて評価結果、変更履歴、製造条件、治具情報などを整理し、後から参照できる状態にしておくことが大切です。

日常的な打ち合わせの記録もBCP対策になります。口頭で決定した内容をそのままにせず、重要な設計判断や変更理由を記録しておけば、担当者が突然交代した場合でも経緯を追いやすくなります。

BCPは災害時だけの特別な仕組みではありません。通常時の情報共有、文書管理、担当者の引継ぎ、設備保全を丁寧に行うことが、結果として緊急時の強さにつながります。

その意味では、協力会社のBCPを見る際にも、立派な計画書があるかどうかだけでなく、普段のプロジェクト管理が整理されているかを見ることが重要です。

日常運用が属人的で、設計変更が記録されず、ファイルの所在も不明確な状態では、緊急時だけ整然と対応することは難しくなります。

反対に、通常時から情報と役割が整理されている協力会社であれば、設備故障や担当者不在など比較的小さなトラブルにも対応しやすくなります。

協力会社と共同で開発中断リスクを減らす

BCP確認では、発注側が協力会社を一方的に評価するだけでは十分ではありません。開発継続には、発注側にも準備が必要です。

例えば協力会社が代替設備を確保できても、自社側が最新版の承認図面を提示できなければ作業を再開できません。代替部品を提案してもらっても、自社内の判断に時間がかかれば、結果として試作工程は停止したままになります。

まず発注側でも、自社が保有すべき開発情報を整理します。要求仕様、承認済みの図面、重要な設計変更、評価条件など、業務再開に必要な情報を適切に確認できる状態にしておくことが重要です。

次に、緊急時の判断体制を考えます。通常時には定例会議で判断している事項でも、緊急時には次回会議まで待つことが大きな時間損失につながる場合があります。

代替材料の評価を開始する判断、別工程へ切り替える判断、開発日程を変更する判断などについて、必要な責任者へ迅速につなげられる体制を整えておくと対応しやすくなります。

代替先候補についても、重要工程では平常時から一定の情報を持っておくことが有効です。

実際に常時二社へ発注する必要はなくても、どの工程が他社へ移しやすく、どの工程が移しにくいのかを理解しておくだけで、緊急時の選択肢が増えます。

開発中断後に初めて代替先を探す場合、仕様説明、設備確認、品質条件の確認、秘密情報の取扱いなど、多くの調整が必要になります。事前に切替の難易度を把握しておけば、どの工程から対策すべきか判断しやすくなります。

また、協力会社と定期的にプロジェクト状況を共有することも重要です。

開発が進むにつれて、初期には存在しなかった専用治具が追加されたり、特定の部品に依存する設計になったりすることがあります。仕様変更によって代替先が限定されることもあります。

こうした変化をBCPにも反映しなければ、選定時に確認した内容と実際のリスクがずれていきます。

協力会社とのBCP確認は、相手の弱点を探すためだけに行うものではありません。どこで開発が止まりやすいかを発注側と受注側で共有し、それぞれが準備できる対策を決めるための活動として位置付けると実務に生かしやすくなります。

その結果、BCPは大規模災害だけでなく、通常時の設備故障、担当者交代、材料不足、急な工程変更などへの対応力向上にもつながります。

まとめ

製品開発の協力会社を選ぶときは、技術力、品質、実績、対応可能な工程だけでなく、業務停止時に開発を継続または復旧できる体制があるかを確認することが重要です。

一つ目の確認項目は、停止時に影響する開発工程と依存関係です。協力会社へ任せている業務を具体的に分解し、特定の担当者、設備、治具、材料などに依存していないかを確認します。停止した工程だけでなく、後続工程へどこまで影響が広がるかを見ることがポイントです。

二つ目は、人員、設備、拠点の代替手段です。代替担当者や別設備、別拠点が存在するだけではなく、実際に自社案件を引き継いで作業できるかまで確認します。代替時に必要となる情報、治具、材料なども含めて考える必要があります。

三つ目は、設計データと開発記録のバックアップ体制です。図面だけでなく、要求仕様、設計変更履歴、評価結果、試験条件、部品情報、治具情報など、再開に必要な情報が失われない仕組みを確認します。保存していることだけでなく、別担当者が必要な情報を取り出して使える状態であることが重要です。

四つ目は、緊急時の連絡、判断、復旧手順です。主担当者と連絡できない場合の連絡経路、被害発生後に共有する情報、代替案を判断する責任者、実際に業務を再開できる状態の定義などを整理しておけば、問題発生後の混乱を減らしやすくなります。

五つ目は、調達先や再委託先を含めたBCPです。協力会社自身が稼働していても、重要部品や材料、外部工程が停止すれば開発は進みません。重要な調達先や工程への依存度を把握し、代替困難なものについては在庫、早期手配、代替評価など別の対応方法を検討します。

また、BCPは契約前に一度確認して終了するものではありません。設計、試作、評価、量産準備へと進むにつれて、重要な人員や設備、調達先は変化します。開発の節目で依存関係を見直し、現在のプロジェクト状況に合った対策になっているかを確認することが大切です。

そして、協力会社のBCPだけを強化しても十分ではありません。発注側でも、最新仕様や承認図面を確認できる状態を整え、重要な判断を行う責任者を決め、必要に応じて代替先へ情報を引き継げる準備を進める必要があります。

BCPで目指すのは、あらゆる停止を完全に防ぐことではありません。予期しない問題が発生しても、重要な情報を失わず、影響する工程を把握し、選択可能な代替手段を使って開発を再開できる状態をつくることです。

製品開発に現地調査、設備設置、試験、施工確認などの現場業務が含まれる場合には、現場で取得した情報の継続的な管理も重要になります。担当者が交代したときや業務が一時中断したとき、どこで何を確認し、どの状態まで作業が進んでいたのかを把握できれば、再開時の確認作業を減らしやすくなります。

現場写真、位置情報、施工記録を管理できるLRTK Phoneを活用すれば、現地で得られた情報を記録として整理し、後から確認しやすい状態をつくることができます。協力会社のBCPを検討するときは、人員や設備の代替だけでなく、開発や現場で生まれる重要情報を途切れさせずに残し、必要なときに参照できる仕組みまで含めて整えることが、開発中断リスクを抑えるうえで重要です。