コラム

ITベンダーが設備連携システム構築で設備統合する際に、注意すべきポイントについて述べたいと思います。

相手を尊敬する事

相手を尊敬する事設備ベンダーでその道何十年と仕事をしてきた担当者は、ちょっと見みには「異星人」（失礼！）のような感じを受けるかも知れません。多くの場合、説明内容は意味不明瞭、仕事の進め方は理解不能、使う言葉もチンプンカンプン、もちろん最新のシステム／ネット技術の話など通じません。しかしそれはお互い様で、相手側から見ればITベンダーの方こそ訳の分からない存在に見えるでしょう。
仕事を一緒にうまく進めるためには、まず異分野の相手をちゃんと尊敬し、また理解する事からスタートします。専門家は尊敬する事、これが大原則です。ついでに申しますと、仕事の終りまでには私共も設備ベンダーから尊敬されるように頑張りましょう。
良く「日本の底力」とか表現されますが、私が良くお付き合いしてきた大田区の中小企業の多くは、その道では驚くような専門性・競争力を持ったスペシャリスト集団でした。その点をまず十分に心に留めた上で、自分達と違う点が多々ある事を当然と認識します。そうした特定分野の専門家にしか分からない様々な専門知識・情報を、いかにしたら業務に適合した形で提供して頂くかを考える事が大切です。
この経験は、今は辛いかも知れませんが、私共が将来別の仕事をする際にも役立つ事と思います。

相手を理解する事

設備連携プロジェクトで登場する会社／設備は、実に千差万別です。名前を聞いただけでは、何をする会社／設備なのか分からない事も珍しくありません。別に皆様方がその道の専門家になる訳ではありませんが、最低限の事は知らないと議論・検討などで大きな勘違いをする恐れがあります。
最初の打合せ前に、あらゆる方法で設備ベンダーや設備仕様を理解し常識レベルの知識を身に付けたいものです。それでも分からない点は、遠慮だの恥だのは忘れて積極的に尋ねたり問い合わせたりしましょう。
私のお勧めは、インターネット情報を活用する事です。今では多くの企業が、ホームページ上で自社製品・技術の詳細な情報を提供しています。最初の顔合わせの前に出来る限り「ネット座学」をして、設備の仕様・機能・特長・実績などを入手します。場合によっては、製品カタログ（多くの場合はPDFファイル）をダウンロードする事も可能です。
その際のポイントは、その設備がどんな場所・目的でどういう形で使われているかの「使い勝手」で、具体的な導入事例が一番役に立ちます。ただし、いわゆる口コミ情報はかなり割り引いて読んだ方が安全です。
これは本線からは少し外れますが、ついでに会社案内・ニュースや業界情報なども収集しておくと、設備ベンダーとの打合せ時に思わぬ役に立つ事があります。

相手との違いを認識する事

設備ベンダーと機能・操作・通信などの仕様を打ち合わせると、仕事の進め方や成果物がIT世界の常識と大きく違う事に気が付きます。一つ例を挙げますと、たとえば文書化の方法論が「ITベンダー：仕様書」「設備ベンダー：図面」なのではないでしょうか？（注：私の感想です）
ここはもう、お互いに生まれ育ってきた「文化」が違う事を認識したうえ、IT主導で設備連携に必要な情報を抽出する手順を取るしかありません。ここは一番気を使う点であり、また皆様方の技術･経験が問われる場面でもあります。
私が経験した多くの設備では、一つに纏まった機能仕様書の代わりに各種の設計資料とりわけ設計図面やデータシートが提示されました。
IT側の目的のためには、それらを繋ぎ合わせて全体像を掴む必要があります。また、IT側では大抵トップダウン･アプローチ（＝全体から部分へ）が取られるのに対して、設備側では設備（機械）の制御仕様から全体像を組み立てていくように思われます。実際問題として、機能仕様として詳細な制御フローチャートのみが提示されて往生する場合も多いのです。
特に大きな注意点は、時として設計資料の中に大きな制約条件などがハイライトせず地味に埋め込まれている事です。
プロジェクトのずっと後の段階になって大きな不整合が発生し、IT側が「そんな話は聞いていない」と抗議するのに対して、設備側が「この資料の何ページにちゃんと書いてある」と反論する事が時々あります。半信半疑で見直してみると、まるでITとは関係ない（と思われた）単なる参照資料の片隅に、数百万円以上のコストインパクトのある重要事項が小さく注釈されていたりします。
いえいえ、相手側は決して騙そうなどと考えた訳ではないでしょう。しかし、仕様レベルの重要度について双方の認識が大きく異なると極めて危険ですので、その点には十分な注意が必要です。

機能仕様の決め方

設備連携システム全体の出来は、設備、IT、通信、データ、使い勝手などが複雑に関連して決まります。お客様（エンドユーザー）が最終的に使うシステムは、IT寄りでも設備寄りでもなくその両者のバランスを取って全体としてうまく融合されている必要があります。
個々の設備の運転・制御は設備側で行うとしても、製造ライン全体の監視・管理やデータ管理は製造管理システムなどで行う例が多く見られます。その場合、システム側で余り個別機械の特性・特長に囚われ過ぎるのはNGです。
出来る限り統一的・汎用的な運用・操作が出来るように、お客様や各種設備ベンダーと考え方を調整しましょう。たとえば特定ロットの製造履歴を通して追跡・管理するなど、お客様がより大きな視点でシステムを把握出来る事が大切です。
現実的な注意点として、機能仕様を設備ベンダーの「ラダーシーケンス図」上で議論する事だけは、極力避けるようお勧めします。
制御設計の手段としてはラダーが役に立つのかも知れませんが、機能設計のためには余りに細か過ぎまた可視化の面からも大いに問題があります。今ではマクロ機能などを持つラダーもありますが、それよりは誰にでも無理なく理解出来る表現方法と共通文書の採用をお勧めします。

通信インターフェース（I/F）の考え方

設備連携でどんな通信I/Fを採用するかは、どのプロジェクトでも大きな検討課題です。業界標準、簡単明快、高い信頼性、実績が豊富、デバッグ機能が優れている、などの各種要求から総合的に判断する必要があります。もし自社で多数の構築実績を有するお勧めの通信I/Fがあれば、取り敢えずそれを出発点として提示する事になります。
その際の極めて大きなポイントが「トラブル対応」です。
システム設計・開発で良く言われるのは、正常ケース1に対して異常ケースはその数倍～数十倍(!)もの労力を要する事、そしてトラブルシューティング（問題の原因究明）に一番多くの時間を費やす事です。自社システムについては自己責任で対応すれば済みますが、他社システム（設備）との接続では得てして責任の押付け合いになり勝ちです。それに設備数が多いと、正常ケースだけでも余程気をつけないと「場合の数」地獄に嵌ります。
効率アップやデバッグ性のためには、出来る限り個別対応を避けて「統一した通信I/F」と「同一のトラブル対応ロジック」を組み込みます。そのためには、お客様や設備ベンダーの協力も頂きまた最大限の努力を費やすべきです。
もう一点、たとえ通信エラーを回復出来ず一旦キャンセルしたとしても、後に何らかの手段（注：手動でも可）により再試行出来るロジックだけは、IT・設備双方に組み込んで下さい。通信エラー⇒データ消失、という最悪の事態だけは断じて避けたいものです。

接続テストの注意点

設備ベンダーが用意する各種のテスト仕様書は、単体機器については本当に素晴らしい資料です。しかしこと接続テストに関しては、必ずしもIT側で期待するようなレベルにはなっていない例が多いのです。どうしても信号レベルや単独データで考えてしまいがちのようで、異常ケース処理や一連のロット／バッチ処理で抜けが出る例を多数見てきました。
たとえITベンダーにとって余分な負担となっても、ここはIT側主導で接続テスト仕様を作成・提示しましょう。
その際の注意点として、接続テスト仕様は社内テスト時点から同じレベルとする事、また工場出荷前に実機／テスト機同士で相互接続テストを行う事、テスト結果とりわけ異常ケースは網羅的に記録する事、お客様にも立ち会って頂く事、などがあります。
またこれはITベンダー、設備ベンダー双方に対して言える事ですが、設計当初から出来る限り多くのデバッグ手段を組み込む意識が求められます。それにより、たとえ接続テストで両者がうまく繋がらず原因究明する際にも、「自分は正しい」事を簡単に証明出来ます。
とりわけ重要な設備については、お客様やプロジェクトマネージャーとご相談のうえ、IT担当者が設備ベンダーのテストサイトまで行くようにして下さい。
私はこれまで接続テスト立会いを中心として、国内各地さらには海外にまで各種の設備ベンダーを訪問してきました。その都度、社内テストに立ち会って良かった（助かった！）、というのが実感です。
一つだけ残念なのは、毎回とんぼ返りで観光など一度も出来ない事です．．．。