カテゴリー:Project

モノづくりIT融合に取り組むITエンジニアリング
7つの方法

私はこれまでに数多く、自動化設備と生産管理システム統合して、工場を立ち上げるプロジェクトに携わり、モノづくりIT融合に、「IT」側から取り組んできました。工場の技術方針、運営方針に基づいて、「建屋」「設備」「人」「運用手順」「IT」を統合して工場を立ち上げます。
私の役割は、IT担当として、統合ポリシーを実現化することです。統合方針の策定から、設計・実装・据付を経て、最後は連動テストで、実装結果を評価し、工場立ち上げを行いました。
モノづくりIT融合をエンジニアリングしたパーフェクトな製造工場
それらの経験から、設備ベンダーに共通して見られる考え方や進め方に対してどんな精神(マインド)でITエンジニアとして対応し問題解決してきたか7つの実践事例をご紹介します。皆様が似た場面に遭遇した際に、少しでもご参考にして頂ければ誠に幸いです。
1.設備の運転・運用を理解すること、文書化すること
2.知らないことはあらゆる手段で情報収集する
3.全員が共通の言葉・図で確認すること
4.共通データベース・共通化・標準化に取り組む
5.お客様にとって最も効率的な可能性を追求する
6.全体最適とトップダウンの視点を持ち続ける
7.議事録書いて守ること、根拠にすること
工場建設 エンジニアリング体制の例

知らないことはあらゆる手段で情報収集する

モノづくりIT融合の現場

設備ベンダーの担当者は、仕事相手も自分と同じレベルの知識を持っている事を期待します。当方は、インターネット情報しか知らない状態で臨む場合もあり、時として認識レベルが違い過ぎて険悪な雰囲気になります。連携のためには設備の理解が必須ですので、あらゆる方法で可能な限り勉強します。大切なのは設備仕様そのものではなく、どう使うか、どう動かすか、どんな指示を出せるか、どんなデータを取れるか、などの「使い勝手」です。一つ重要な課題が「エラー対応」で、設備故障、通信障害、停電・復電、パラメータエラー、操作ミス、..などの対応策を全員で検討します。通常のシステム開発プロジェクトでのエラー分析(WHAT IF)の経験が、ここで非常に役に立ちます。

全員が共通の言葉・図で確認すること

現代のIT用語はカタカナと略号のオンパレードで、それらを知らないと議論一つ出来ません。IT技術者はそういう専門用語を何気なく使う傾向が強く、設備側では全く理解不能という事になります。これは「逆も真なり」で、設備ベンダー側でも自分達の業界用語を並べ立てて話をします。一番怖いのは理解出来ない事自体ではなくて、お互いに誤解してそれに気がつかない場合です。「何となく分かった積もり」は極めて危険なので、納得の行くまでしつこく確認します。言葉や考え方の誤解を避けるためには、単に口で喋るだけではなくイメージ併用で説明する事、自分の理解を書き物で確認する事です。たとえ面倒臭くても初めに用語集を作り、関係者全員が同じ用語を同じ意味で使うようにします。

共通データベース・共通化・標準化に取り組む

生産管理と設備の融合のための共通化・標準化

単一の設備ベンダーだけで製造ラインが完結する場合は、そこが責任を持って全ての調整を行えば済みます。内部はブラックボックスですので、ある意味自分のスタイルで自由に仕事を進められます。しかし、大きな製造ラインでは少なくとも数十社の設備ベンダーが参加して、設備同士でまたシステムとも連携します。
設備ベンダー各社が「自分流」を貫くと収拾がつかないので、誰かが全体で統一が取れるように調整する必要が出ます。1つのシステム基盤に複数の設備を接続するための、通信方法、通信プロトコル、確認手順、データ構造、などのインターフェース(I/F)規約を共通化・標準化を行う基盤・手法を提供することは、ITエンジニアの活躍の場面です。設備側の開発負担を軽減するとともに、運用後の変更管理を容易に実現できるようにしました。
エラー対応の手順が標準化されると運用負担を軽減できます。設備担当会社は設備の枠をはみ出すことはできないため、ITエンジニアが果たす役割は大きいです。

お客様にとって最も効率的な可能性を追求する

お客様にとって最も効率的な可能性を追求する

多くの設備に、専用の制御・管理システムが組み込まれています。設備・システム連携のためには、通常そこに通信I/F(機能)を追加します。ところが時として、設備担当者から、「標準システムなので一切変更出来ない」という返事が戻ってきます。設備側の返答を素直に制約条件として、特殊I/Fを増やしていくと、コスト上昇、品質低下、保守問題などが懸念されます。変更できない理由を聞いてみると、設計資料が残っていない、内容を理解出来る人間がいない、変更ツールがもうない、対応ハードがもうない、などの理由だったりします。とにかく駄目な理由を探し出し、対応策を考えます。場合によっては、外付けI/Fシステムの追加も検討します。
なぜか、という理由も含めて共有することで次の対策が検討できます。

全体最適とトップダウンの視点を持ち続ける

エンジニアリングの視点

これは設備に限りませんが、専門家は自分の世界に強い思い入れを持つため、難しい取組課題を見つけると深掘りしがちです。何しろ専門家ですから、その一部分だけに着目すれば素晴らしい解決法を考え出します。しかし、それがプロジェクト全体として一番良い事だとは限りません。些か大袈裟な表現ですが、常に「全体最適」と「トップダウン」を目指します。それを実現するためには、課題に関連する全ての要求仕様や制約条件を理解します。その上で、時間、コスト、品質、妥当性などのバランスを取った解決方法を見つけ出すのです。ある意味、これは一歩後戻りして仕事の進め方を見直す結果となりますが、その道筋を示すことで、合理的な判断ができます。大きな問題が眼前に立ち塞がっている局面では、どうしても人海戦術などで即効性を求めがちです。道筋と合理性を合わせて説得する技術も求められます。

議事録書いて守ること、根拠にすること

昔気質の専門家は人間同士の触合いを大切にする一方で、議事録などの約束事を無視する事が時々あります。一度会議で合意して議事録にまとめても、後になって平気で破られたのでは困ります。とにかく割り切って、正確無比な議事録を書くように努めます。その内容は大きく「明確化」「決定事項」「宿題」「参照資料」などとし、会議での個別発言を一々書く事は避けます。理想的には、会議の席で議事録を出席者全員でレビュー&確認するのがベストです。それが時間的に無理であれば、出来るだけ早い機会にドラフトを提出し期限を切って各位に確認/コメントして頂きます。もちろん、一度合意された議事録は決定事項として全員が守る事は、プロジェクトレベルでの約束事となります。 異なる領域のエンジニア間の融合は、特に、スタート地点でお互いの分野の情報収集と理解を進めることにより、相互の理解、納得がいくコミュニケーションが可能になります。
さあ、皆さんも7つの実践を参考にし、モノづくりIT融合を実現してください。必ず、成功されることを期待しています。

ITコンサルタント
佐野 優治
キヤノン、東洋エンジニアリング、YMP-iを経て現在はITコンサルタントをしています。主な経験分野は、電子機器制御、ラボオート(LA)、連続プロセス制御・監視、バッチプロセス制御・監視、自動車製造ライン、製造管理システム(MES)、医薬製造向け現場連携・SCADA、生産管理システム、など。根っからの「現場好き人間」で、設備⇔システム融合をライフワークとしています。
著者メールアドレス: sano.yuji@mbm.nifty.com (ご意見、ご感想などお気軽にお寄せ下さい。)

関連アプリ

エンジニアリング 設計・構築内容の変更が、関係各社で、もれなく共有され最適解に向けて、協働で意思決定を行います。
チームマネジメント チームでの仕事は、協働ワークそのものです。課題管理・進捗管理・会議運営の連動と日常業務の可視化によって、適切なマネジメントが実行できます。
サービスデスク ITIL準拠のサービスデスクをご提供します。ユーザの高度な要求に対して、スピーディに対応できます。

 

 

Projectのその他の記事を読む

ビジネスコラムのカテゴリ

Webサイトトップページへ戻る

ビジネスコラム「製造業SETQ部」記事一覧へ戻る

お問合せ・資料請求・メルマガ購読
  • お問合せ
  • 資料請求
  • メルマガ購読

おすすめ記事一覧

関連記事一覧

  • コラム・対談
  • よくある質問
  • EBCとは

ページTOPへ