設備制御系作成支援のソフトウェア(2)

<(1)からの続き>

第一の問題は、その低水準言語であるラダーを書いて、設備の制御系のソフトとして使うには、それなりのスキルが必要とされることだ。
低水準言語だから、可読性は低い。
ニモニックで直接プログラムしている様なモノだ。
だから、ラダーは、コーダ-の頭の中で、手続き型にも、論理型にも、関数型にも、コーディング出来る。(僕の少ない経験では、関数型にコーディングされたのはみた事がないけれど…)
他人の書いたラダーは、コーディング規約を厳格に共有していない限り、それでどんな動作をしようとしているのかを、見てすぐに理解出来る人間はいないだろう。
実際に設備は、立ち上げ・運用の中で、開発時から作り込まれた潜在的なバグ対策、仕様変更・追加に伴うソフト改造を続けていく事になる。
可読性が低い事は、開発時のコーダーをその作業に縛り付ける。
だから、ラダーのコーディング、維持メンテは、それぞれの設備に特化した特殊スキルになりうるし、逆にそれによる仕事の継続性を期待する技能者も多い。

しかし、これは設備開発に於いては課題になる。
一つは、設備の動作は、アーキテクト(設備開発においては機械設計者が担当する事が多い)が決める。
このアーキテクトと実際のコーダーの間の意志疎通が、大抵の場合上手くいかない。
お互いの領域に対してある程度理解が無いと、意志疎通は無理なのだが、互いにラダーを特殊技能と思っているから、踏み込んだ話が出来ない。
コーダーは機構設計や全体アーキテクチャの事を考えないし、アーキテクトはコーダーの作ったコードをチェックしようとしない。
だから、コーダーのスキルが低くアーキテクトの要求に応えられない場合、またアーキテクトの出す仕様が不十分だった場合、彼らはその齟齬を解決する事ができなくなる。
他のスキルが高くてアーキテクトもコードも判る作業者を投入するしかない。

簡単な案件でも、非常に属人的な開発しか出来ない。

第二の問題は、そういう形で人力で、属人的なコーディングしているから、いつまでもコーディング規約を作って運用するとか、コード生成を自動化、または半自動化して合理化するとかいう方向に話が進まない。
アーキテクトが書いた仕様に基づき、大まかにコーディングをして、後は実際の設備が出来た所にそれを入れて、アドホックにバグ取りをする。
そのバグ取りをするのが、自分達のスキルと勘違いしてる。
バグを出さず、一発で動くコードを短時間で作るのが本当のスキルだと思うのだが、そうはなかなか考えない。
アーキテクトの方も、そんなモンだと考えて、自分の出した仕様の不備をコーダーが補っている事なんて考えもしない。

これでは、設備制御のソフト作成に時間がかかって仕方ない。