エンジニアリングファイルのコラボ:複数チームのワークフロー

チームごとにルールが違うとき、エンジニアリングのコラボレーションは崩壊する。機械チームはローカルVaultに保存し、電気チームはGitにコミットし、ファームウェアチームはJiraチケットにバイナリを添付する。その一方で、プラハの製造エンジニアは最新の筐体STEPファイルを待ちながら、Slackで互いに矛盾する3つのバージョンを受け取っている。個人情報保護法（APPI）が定める安全管理措置の観点からも、技術情報の漏洩リスクは無視できない。効果的なマルチチームワークフローには、単一の信頼できる情報源、明確な引き渡しポイント、そして社外の請負業者も含めた全員が使えるツールの組み合わせが必要だ。

なぜエンジニアリングファイルは通常のバージョン管理を拒むのか

Gitはテキストを美しく扱えるが、バイナリCADファイル、FPGAビットストリーム、PCBレイアウトには苦手意識がある。500MBのSolidWorksアセンブリはGitリポジトリをすぐに肥大化させ、CADビューアなしではdiffも意味をなさない。Git LFSはバイナリをオブジェクトストレージにプッシュすることで助けになるが、コミットよりも機能や設定で考えるエンジニアには依然として扱いにくい。PTC Windchill、Siemens Teamcenter、Autodesk Vault、Aras Innovatorのような専用システムは、チェックイン／チェックアウトのロック機能で同一パーツの同時編集を防ぐ。小規模チームならOnshapeやFusion Teamがクラウドネイティブの同時編集と自動バージョン管理を提供する。

ドメインごとの単一の信頼源

ドメインごとに1つのシステムを選び、それをルールにする。機械設計はVaultかWindchillに。電気回路図はAltium 365かGit管理のKiCadに。ファームウェアはセマンティックバージョニングを付けたGitに。機械図面はリリースのたびにPDFに書き出してレビューフォルダに配置する。要件とテスト手順はPolarion、Jama、DOORSに。リンクは最新の先端バージョンではなく特定のリビジョンを指すというルールを守れば、監査も容易になる。「Rev Cの筐体（MECH-4512）」という表記は監査可能だが、「最新のVaultバージョンの筐体」は監査できない。

専門分野間の引き渡しポイント

摩擦は境界に生まれる。機械は電気にブラケットを渡してケーブルクリアランスを確保させる。電気は基板のアウトラインを機械に渡して筐体フィットを確認させる。ファームウェアはフラッシュイメージをテストに渡す。これらの引き渡しにはフォーマットの取り決めが必要だ。MCAD-ECADにはIDX（ProStep）が中立フォーマットとして機能し、基本的な確認にはPMI付きのSTEP AP242が使える。ファームウェア配信では、バージョン文字列・ビルドタイムスタンプ・GitコミットSHAを埋め込んだ.hexまたは.binファイルをQAに渡すことで追跡を可能にする。すべての引き渡しにはSHA-256チェックサムと署名（Gitタグ、PGP署名付きリリースノートなど）を付ける。

実際にサインされるレビューワークフロー

エンジニアリング変更レビューはすぐにメールスレッドに退化する。構造化されたフローはこうなる。著者がパッケージをアップロードし、レビュアーはレビュー期限に合わせた有効期限付きリンクを受け取り、ダウンロードしてマークアップし、コメントを1つの文書にまとめ、著者がリビジョンBを公開する。ReviewStudio、Bluebeam Revu、Adobe AcrobatのPDFマークアップは図面のコメント統合を担う。コードはGitHubやGitLabのプルリクエストが同じ役割を果たす。異なるツールを使うレビュアーが混在するクロスディシプリンレビューでは、コメント権限付きのフラット化PDFと共有転送リンクの組み合わせが、全員を1つのプラットフォームに強制するより効果的なことが多い。

社外パートナーや請負業者との共有

社内PLMは契約エンジニア、試験所、サプライヤーの技術チームにはなかなか拡張されない。3週間のコンサルのためにWindchillのシートをプロビジョニングするのは得策ではない。転送ツールがこのギャップを埋める。STEP、PDF図面、BOM .csv、署名付きreadmeを含むパッケージ化リリースを、E2EEリンクで社外パートナーに送る。リンクは契約終了時に期限切れになるよう設定し、知的財産の監査目的で内部に転送記録を残す。経済産業省（METI）の輸出管理規制やITAR、EARに関わる企業秘密の素材では、輸出管理担当者が時系列の記録を必要とする。

命名規則・タグ・メタデータの整備

一貫した命名規則はどんなツールよりも混乱を防ぐ。PROJECT_SUBSYSTEM_PARTNUM_REV_DATE.extのようなスキームは並べ替えと検索を容易にする。すべてのリリースに署名済みGitタグかPLMリリースラベルを付ける。バイナリアセットと並べて著者・レビュア・承認者・リリース日をサイドカーJSONまたはYAMLに記録する。名前変更が図面改訂を必要としないように、ファイル名には個人名より役割ラベルを使う。

大規模テストデータを効率的に管理する

振動試験から生成される環境試験レポートは10GBから100GBにも達することがある。熱画像データを加えればさらに増える。PLMシステムはこの量には対応しておらず、時系列データ向けに設計されてもいない。AWS S3、Backblaze B2、WasabiなどのオブジェクトストレージにGB当たり月5〜24ドル程度で生データを保存し、試験レポートにはポインタのみを記録する。クラウドアカウント外のコラボレーターには、有効期限付き署名URLかE2EE転送でサブセットを共有する。ライフサイクルポリシーで古いデータをGlacierやアーカイブ層に自動移動できる。

ツール選定で全員を縛り付けない

大企業はフルのPLMスイートを導入する。スタートアップや小チームはGit、クラウドCAD、転送ツールを組み合わせる。実用的な中間解としては、社内でVaultかOnshapeを使い、すべての社外引き渡しには暗号化転送サービスを使う方法がある。WeTransfer ProやDropbox Transferは機能するが、いずれもデフォルトではエンドツーエンド暗号化を提供しない。HexaTransferはクライアントサイドのAES-256-GCM暗号化と最大10GBの無料転送を提供し、受信者はアカウント不要で利用できる。社外の請負業者との連携に最適な構成だ。

https://hexatransfer.com — 無料、アカウント不要、最大10GB。