制御設計の設計工程について

今回は、FA設備の制御設計の設計工程ついて考えてみたいと思います。

自動化設備の制御ソフトですが、みなさんは毎回きちんと要件定義と設計を行っていますか？　ここでいう設計とは、プログラムをコーディングする前の机上での設計を指しています。制御ソフトはPLC言語が多いと思いますが、たとえPLCプログラムであっても、『要件定義 → （机上）設計 → プログラム実装 → 実機検証』というステップを踏みましょう。

製造業界での制御設計の実態

製造業界では、要件定義や設計が不十分なままプログラム実装をしているケースが多いのではないでしょうか。なんなら「装置が組み上がってからが、ようやくプログラム作成の本番」という人や会社もあるのではないでしょうか。

以前、私が勤めていた会社もそうでした。

• 要件定義が適当。顧客要求仕様が曖昧なままにプログラムを作ってしまう。

• 机上での設計が不十分なままコーディングに入る。コーディングしながらプログラムの基本構造を考えている。　

• 装置が組み上がった後に、装置を動かしながらプログラムの調整や手直しを行っている。

このような状態が当たり前になっており、非常に効率が悪いと感じていました。設計工程を『設計・プログラム実装・デバッグ』と大まかに別けたときの割合は、おおよそ以下のような状態でした。

設計　　　　　：1
プログラム実装：5
デバッグ　　　：4

しかもこれだけではなく、装置出荷後の不具合も多かった為、客先で発生したバグ対応も含めると、1案件あたりの制御設計部隊の全体工数は相当多い状態でした。

製造業での悪しき習慣の改善を試みる

これでは駄目だということで、制御設計工程に対し、次のような目標を掲げました。（因みに当時の私は設計課長という立場でした）

設計　　　　　：6　(1)
プログラム実装：2　(5)
実機検証　　　：2　(4)

※括弧内は目標を掲げた当時の割合

この目標を掲げた当初、制御設計メンバーからあがった声は
「製造業の装置設計では、そんなの無理」
「現実的ではない。理想論だ」
というものでした。

実はこういった声があがる理由は分かっていました。その理由とは、

• そもそもの納期が短い為、悠長に机上で設計なんてしている暇が無い。（いきなりコーディングから始めないと間に合わない）

• 営業から伝え聞く仕様も不明確な場合が多いし、お客様も仕様を変更することが多い為、要件定義フェーズなんてやっても無駄。

というものです。

なので、この目標を実現するには、営業にも協力してもらい、顧客に対して、

• 受注交渉段階で仕様を明確にする

• その仕様を考慮し、現実的な納期を設定する

という交渉を行う必要があります。

今までの営業の仕事の取り方は、仕様も曖昧且つ、非常に短納期というものでした。なのでまずは営業を説得し、営業と十分な連携を取ったうえで注文を取るように進める必要がありました。

しかし、ここにも壁が…

皆さんの予想通り、営業からも同じような反発の声があがりました。
「他の業界ではそうかもしれないけど、製造業ではそんなの無理」
「理想論」
てな具合に（笑）

それでもなんとか営業を説得し、最終的には理解してもらいました。

「本来のあるべき設計工程どおりに進めるとソフトの品質は上がる。そうすることで出荷後の不具合対応に取られていた工数も削減できる。その結果、全体工数も下がり、次の仕事に取りか掛かる為の時間も短くなる」
てな具合に。

そしていざ実践

【要件定義】

まずは要件定義を徹底的にやり、お客様とこちらとの仕様の齟齬を無くしました。仕様が明確になるまで、お客様とキャッチボールを続けました。

【設計】

設計工程では、机上設計を徹底的にやりました。設計資料を充実させ、資料の中身が論理的且つ矛盾が無くなるまで、徹底的にレビューを繰り返しました。レビューでOKとなるまではコーディングは一切禁止です。

HMI（装置のユーザーインターフェース画面）に関する設計も徹底的にやりました。画面構成を機能と関連付けたうえで、使い勝手が悪く独りよがりな設計になっていないかを徹底的に見直しました。本来、ユーザーインターフェースとは、操作に矛盾や無駄が無く、そして何よりシンプルであるべきです。

プログラム実装

ここまでやったうえでやっとプログラム実装、つまりコーディングです。事前に徹底的に設計を行っているので、コーディングはすぐに終わります。だって、充実した設計資料をそのままプログラムコードに置き換えていくだけですから。

実機検証

最後は実機検証。総仕上げです。

因みに、従来は実機が出来上がった後の制御設計部隊が行う作業を「デバッグ」と呼んでいました。この呼び方を改めました。デバッグではなく「実機検証」や「実機確認」と呼び方を変えました。

本来、実機が出来上がってからの作業とは、「十分に設計した内容が、その通りであるかを実機を使って確認する」為の作業です。今までやってきたような、実機で動作させながらプログラムの調整を入れたり、書き換えるのではありません。正しく動いて当たり前なんです。とはいえ、人間なので何かミスもするでしょう。そういったミスが無いかを確認する為の作業が「実機検証・実機確認」です。

デバッグという呼び方を変えたのにはもう一つの狙いがありました。

それは制御設計メンバーのマインドセットを変えるためです。デバッグと呼ぶということは、それは「バグありきの作業」というマインドセットで仕事をしていると私は思います。

そしてこのように改善した結果、出荷後の不具合も全体工数も大幅に削減することができました。案件をこなすごとに、設計の精度も上がっていったので、最終的には以前と比べて不具合も工数も半分以下になりました。

理想を理想のままにしないために

ここまで読んでいただきありがとうございました。
皆さんの会社ではいかがでしょうか？

これを実際に実行に移すとなると、社内で様々な壁が立ちはだかると思います。それこそ私が食らったような「そんなの理想論だ！」という反発も出ると思います。

でも、理想を追い求めないと、いつまで経っても工数削減も不具合削減もできません。そして、理想を現実の物にするには覚悟も必要です。

頑張って理想を追い求めていきましょう！　では！