HOME > ソフテックだより > 第380号(2021年6月16日発行) 現場の声編「ソフトウェア開発の理想と現実」

「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。

ソフテックだより(発行日順)のページへ
ソフテックだより 技術レポート(技術分野別)のページへ
ソフテックだより 現場の声(シーン別)のページへ


ソフテックだより 第380号(2021年6月16日発行)
現場の声編

「ソフトウェア開発の理想と現実」

1. はじめに

私は今年19年目の中堅社員です。
入社して現在まで、様々な分野のソフトウェア開発を経験しておりますが、一番多いのはPLCソフトウェア開発となります。
PLCソフトウェア開発も多く案件を担当してきましたが、開発規模が大きければ大きいほど、仕様決定の遅れや設計時の考慮不足といった要因によって、当初思い描いていた理想通りに進まないこともあります。

今回のソフテックだよりでは「ソフトウェア開発の理想と現実」というテーマで、筆者が過去に経験したPLCソフトウェア開発を例に、開発現場の奮闘振りを紹介したいと思います。

2. 事例紹介

今回紹介するのは、過去に筆者が経験したPLCソフトウェア開発案件です。
ネットワークで接続された約40台のPLCが、上位PCからの指示をもとに連動して動作する食品工場向けのシステムでした。(システム構成は図 1参照)

システム構成
図1.  システム構成

筆者が経験した案件の中でも一位二位を争うほど規模が大きく、プログラム製作担当者も大人数。一時期は10人ほど関わっていました。

それぞれのPLCが制御する装置は異なりますが、処理の起動や停止の仕組みや異常監視処理、外部信号の入出力処理など、プログラムの作りを共通化できる部分は多くありました。
それらは「標準プログラム」として、プログラムの作りを合わせることに決めました。
標準プログラムを用意することで、特に大人数で開発する今回のような案件ではメリットが多く生まれます。以下の通りです。

  • ・製作者以外の人が見てもプログラムを理解しやすい。
  • ・共通化部分のプログラム品質を予め確保しておくことができる。
  • ・開発メンバーへプログラム製作の指針を示すことができるので開発効率を向上できる。
  • ・共通化できない独自処理の製作に注力できる。

製作フェーズに入り、この標準プログラムの開発を優先的に行いました。

3. 理想

標準プログラムを作るにあたって、色々な目論見が頭の中を駆け巡っていました。

  • ・PLCソフトウェア開発は、長年に渡って数多く経験していたので、この案件を自分の集大成にしよう。
  • ・今後長きに渡って使い続けられるような、最強の標準プログラムを開発しよう。
  • ・バグを作り込まないために一番良いことはプログラムを作らないことだ。
  • ・ケアレスミスを減らすため、手作業を極力減らしたプログラム製作手法はないものか。
  • ・昨今AI、AIと言われているが、PLCプログラムは毎回一から手作業でコーディングすることが多い。
  • ・ラダープログラムを自動生成することはできないか?

色々考えを巡らせた結果、設計書に定義されたプログラミングに必要な情報(デバイスアドレスなど)を読み取り、標準プログラムを自動生成させることを思いつきました。
自動生成にはExcel VBAを用い、PLCで動作するラダープログラムの元となる、リスト形式を呼ばれるプログラムを自動的に生成させることにしました。
リスト形式のプログラムは、三菱PLCのプログラミングツールGX Works2で読み込むことで、ラダープログラムに変換することが可能です。

VBAプログラムもある程度得意としていましたので、目的のモノは比較的容易に作ることができました。
設計書から自動生成するため、設計書に間違いが無い限りケアレスミスが入り込むことはありません。
共通処理は自動生成に任せられるので、PLCごとの独自機能の開発に集中すれば良い。
いいことばかりのように見えました。

4. 現実

この案件は、私が経験した中で一位二位を争うほど規模の大きな案件と冒頭で述べました。
更に、過去に経験したことがないぐらいスケジュールが厳しい案件でした。

スケジュールの厳しさから、外部機器とのインタフェース仕様といったPLCプログラム開発に必要不可欠な内容が完全に決まらないまま、仮の状態でプログラム製作に入らざるを得ない状況でした。
ある程度の変更も想定してはいました。

標準プログラムを自動生成するという理想的な開発手法で2〜3プログラムを作ったとき、雲行きが怪しくなってきました。
後から決まりだした仕様が、想定を徐々に超え始めたのです。

標準プログラムを設計書から自動生成させる。
この手法は、何をやるにも設計書を修正してからプログラムを生成し直さなければならないということ。
もしもプログラムを先に変えて、設計書を修正し忘れたら大変なことが起きるのが目に見えています。
プログラムと設計書を自動同期させる機能があれば理想の理想なのですが、そんなもの作っている時間など到底ありません。
そうこうしているうちに、プログラムの変更が先立ち、設計書が後回しになるというダメな状況に陥っていきました。

このような状況では、プログラムを自動生成できるのは初めの一回きり。
一度標準プログラムを吐き出したら最後、もう自動生成なんてできません。
今までと何も変わらず手でプログラムを組んでいく。
自然にいつもと変わらない開発となっていきました。

挙げ句の果てには、標準プログラムで考慮していなかった機能追加まで必要となってしまいました。
もう目も当てられません。
結局ラダープログラムの自動生成という理想は理想のままで終わってしまいました。

5. 失敗の原因

目の付け所は悪く無かったと、今でも自分に言い聞かせています。

ただ、当時の状況を振り返ると、最大の失敗だったのはプログラム製作ではなく、上流フェーズの対応にあったと思います。
ソフテックでは「品質は上流で作り込む」を基本としており、入社当初からずっと言われ続けていることでした。
要求仕様、外部設計、内部設計、プログラム製作とソフトウェア開発はフェーズ分けして進めていきますが、本案件の場合は、要求仕様すら完全に確定していない状態でプログラム製作を進めざるを得ない、通常ありえない特殊な状況でした。
いくら標準プログラムをしっかり作ったところで、仕様が変わればプログラムも変わってしまいます。
大きな手戻りがいつ発生してもおかしくない状況にも関わらず、プログラム製作効率のことだけを考えていたのが問題であったと思います。

たとえ要求仕様や設計内容が変わっても、何でも吸収できるような標準プログラムを作ればよかったのでは?という考えもあるかもしれません。でもその考えでは、実際には動かないプログラムを多く生み出してしまうこととなります。
具体的には、異常発生時の停止パターンを、装置を「いかなるときも即停止させる」「決められた処理まで進めてから停止させる」「停止させない」の3つ用意したとして、要求仕様が「いかなるときも即停止させる」と決まれば、2つのプログラムは全く無駄となってしまいます。
使わないプログラムを実装するというのは、プログラムステップ数や処理時間の制約があるPLCプログラムではご法度です。無駄な開発工数を使ってしまうこととなります。

6. 最大の収穫

理想とは大きくかけ離れた開発ではありましたが、それでも収穫はありました。

まず1つは、普段は一から組んでいたPLCプログラムを設計書に定義された内容から生成させることができたこと。手作業を不要で動作するプログラムを生成することができました。
「できる」と思い描いたことが実際に動いたときには、ソフトウェア開発の面白さを感じるところだと思います。

そして最大の収穫は、「品質、生産性を上げるために大事なことは、手戻りの少ない仕事の進め方に他ならない」ということに改めて気づかされたということです。

今回の例のように、プログラム製作フェーズだけに着目して、いくら開発効率アップしようと頑張っても、手戻りが1つ2つ発生することで、削減した工数をすぐに食いつぶしてしまうことが身をもって分かりました。
「品質は上流で作り込む」ことがいかに重要であるか、改めて理解しました。

7. おわりに

いかがでしたでしょうか。
ソフトウェア開発は、目に見えないものを作るという特徴がありますので、仕様書やソフトの動作という形でしか、なかなかお見せする機会は無いかと思います。
今回紹介したように、ソフテックではより品質が高いソフトウェアをいかに効率良く開発することができるか、開発プロセスにおいても日々改善を重ねてきております。その奮闘振りが少しでも伝われば幸いです。

(M.S.)


関連ページへのリンク

関連するソフテックだより

ページTOPへ