第153回 設計部門BOM改善コンサルの現場から～その82～ソフトウェアのE-BOM管理の考え方 問題提起編

ソフトウェア系の問題点

生産用自動機製品、つまりメカ系・エレキ系・ソフトウェア系（主にPLC）のシステムで製品が成り立っている場合、ソフトウェア系は大別して以下のような現象が設計部門・生産部門を悩ませます。

外注に丸投げしている場合は、構造的に変革しないと問題解決はできません（Ex. 社内設計に持ち込む。外注を使用しても良いが基本的なソフトウェア設計は自社で行う。＝モジュール・サブルーチン設計は外注に委託する 等々）。

これらの問題点は最近のテーマではなく、リレー制御盤からPLCというCPUに進化し、結果、それらを制御するソフトウェアの必要性が始まって以来、継続しているのです。
「何とかしなくては……」と設計部長も含めソフトウェアに関わる設計者も長年考えていましたが、「先送り」されてきた課題です。制御系の複雑化、IoT、外部通信、AIとの連携等々、ソフトウェアの構造が複雑化して、とうとう身動きが取れない状態になってきてしまいました。

ソフトウェア系に対する基本的な考え方

今回は詳細なE-BOM構築ではなく、あくまで問題提起の共有としましょう。

理由は、PLCなどの旧態の制御から最近は組み込み型の非常に自由度の高い分散制御系に移行しつつあるためです。
これはIoT、AI、これらをつなぐコミュニケーション能力が求められて、さらに高価なPLCをそれらの要求に合わせて拡張し続けることは、原価（コスト）競争の側面から将来性に対する見通しが難しい状態なのです。「PLCは高価なモノ」という既成概念から脱却して、いかに「コスパの良い制御系を設計するか」が問われています。

従って、これらの具体的な解決のための詳細を説明する前に、先述した問題が解決できてからの話となるわけです。

まず、必須とするシステムとして流用化・標準化設計プラットフォームの存在があります。
理由は、ソフトウェア系エンジニアの蛸壺設計からの脱却が必要だからです。この辺りの説明は、省いても、このコラムの読者は理解してもらえるでしょう。

最も可視化や共有が難しいソフトウェア

次のような会話を何度も耳にします。設計部長とソフトウェア開発担当者とのやり取り……
部長「A君、今開発中のソフトウェアは何パーセントぐらいまで行ったの？」
担当者「85%程度です！」
部長「もう少しで完成だな！」

しかし、いつまでたってもこの85%が続き……
部長「本当にいつ完成するの？？？」
となります。

メカ系は図面
エレキ系は回路図
によって進捗（しんちょく）度は想定できます。

しかし、ソフトウェアは蛸壺設計を行っているソフトウェア設計者の頭の中にありますから、進捗や完成度はうかがい知れない「やぶの中」なのです。
さらに困難を極めるのが、不具合（＝BUG）の量です。設計を行う以上、完璧な設計成果物は望めませんが、先述した可視化の可否によって、設計部長としてはBUG量の想定は難しい判断となります（A氏、B氏、C氏……と過去の実績から想定する？）。

納期は迫り、顧客が立ち合いに来て、設計部長が対応することになります。
顧客「メカもエレキも完成しているように見えるけれど……」
部長「実はソフトウェアがまだ完成していないのです」
顧客「あとどのくらいで完成するの？」
部長「85%～90%完成と担当者は言っています」
顧客も愚かではありませんから「それでは実機を当社工場に設置してください。それからソフトウェア設計者も一緒に派遣してもらい、当社現場で稼働させてくれませんか？」
この言葉には設計部長はあらがえません。「分かりました……」

悲しいかなソフトウェア設計者のA氏は、実機と共に顧客の現場に「出荷」されてしまうのです。
日本だけとは限りません。東南アジア、欧州等々、とにかくBUG取り（＝DEBUG）が終了して、稼働率立ち合いに合格するまで帰社はかないません。行ったきり1年近く帰社できない「捕虜生活」を強いられる実例も見たことがあります。

他のソフトウェア設計者を代替派遣しても、A氏の頭の中にあるパッチ＋スパゲティ状態のソフトウェアに手も足も出せません。
さらに心配なのがA氏の行く末です。1年も「捕虜生活」を強いられて、思うことは「この会社は私を守ってくれなかった」という会社に対する忠誠心や信頼の消失です。
A氏の退社は時間の問題となってしまうのです。

どこにこの問題の核があるかは理解してもらえると思います。
ソフトウェアという最も可視化が難しい設計成果物のマネジメント手法に対する熟考の欠損です。

そのマネジメントの重要施策（視点）とは……

少なくとも、この四つの視点をどのように流用化・標準化設計プラットフォーム上でルール化していくのか？
この検討が大変重要だと考えています。

まずは現状の問題提起としての切り口を共有してください。この問題を乗り越えられることがソフトウェアの可視化、共有化の必要十分条件ですし、「蛸壺設計」からの脱却です。

以上