ラダーのちょっとしたこだわり
「MOV K0 D0000」は[RST D0000」
好みかなぁ。
「HFFFF」を「K-1」
なんかかっこいいけどやらない。
「DBL D0000 D0000」は「* D0000 K1 D0000」
既存ソフトの流量ばかりしているので、結果的にこうしている。
「> D0000 K1」は「< K1 D0000」
比較は全て「＜」こっち向きに揃える。既存ソフトを直すことはない。
「= D0000 K1」は「= K1 D0000」
比較は左側に定数かなぁ
いやぁ本当にちょっとだったなぁ。
PLCのプログラミング国際標準規格IEC61131-3の呼び名は「スシフライ言語」です。
ＰＬＣのプログラミン言語と言えばラダーだけど、電気標準国際会議（IEC）でＰＬＣの標準プログラミミング言語が決められ、その他に４つの言語を入れて、IEC61131-3とIECの規格番号として決められた。
IEC 61131-3（あい・いぃ・しぃ - ）とは、電気標準国際会議（IEC）が1993年12月に発行した標準規格で、PLC用の以下の5種類のプログラム言語を定義したものである。
義したものである。* ラダー・ロジック（LD言語）
* シーケンシャル・ファンクション・チャート（SFC言語）
* ファンクション・ブロック・ダイアグラム（FBD言語）
* ストラクチャード・テキスト（ST言語）
* インストラクション・リスト（IL言語）一連のIEC 61131のうち、第3部でこの規格を定めている。
http://ja.wikipedia.org/wiki/IEC_61131-3
IEC61131-3の言語５つをどう呼んでいるかと言えば自分はIECプログラミング言語と無茶な呼び方をしている。で、世間一般ではみんな呼んでいるのかと思ってネットで調べてみたら、「PLCのプログラミング国際標準規格IEC61131−3」あたりで落ち着いている。どうやら。海外でもそんな呼び方をしていて、それをそのまま翻訳している感じだ。
この５つ標準言語を普及させたい、この呼びづらい言語名をどうにかするべきだ。てことで名前を決めてしまいます。ラダー、ＳＦＣ、ＦＢＤ、ＳＴ、ＩＬのそれぞれの言語のカタカナの頭文字を取って「スシフライ言語」とします。
ラダーソフトの作成方法
前職ではデバックを行う部署が別にあった為に、机上デバックという無理やりなことを行って試験を行う部署にラダーソフトを送り込んでいた。実際には机上デバックなど大してしておらず、いつもギリギリになって無理やり提出していたものだった。
今の会社に転職してからもしばらくは、ラダーを全て書いてからデバックを行う（ラダー暦１０年目で初めてデバックを経験するのだが）、これが全然動かないし、デバックしていく内になんでこんな作りにしてしまったのかと後悔するはめになる。かなり作り直しもした。
２、３年経った頃だったかに馬鹿な自分に引け目を感じながらも、ある程度のプログラム単位ごとにプログラミングそしてすぐデバックを繰り返して完成するスタイルに辿りつく。どこか引け目を感じつつ。
しかし、ラダーソフトを１０年以上やってようやく以下の文章に出会い考え方が一変した。体に電流が走ったような感覚だ。
『ハッカーと画家 コンピュータ時代の創造者たち』の著者であり天才的なハッカーであるポール・グラハムはその書籍の中で静的型付けの言語とそうでない言語を比較しながらこんなことを書いています。
自分(ポール・グラハム)は大学で、プログラムは紙の上で完全に理解しなければいけないと学んだけれど、それは無理だった。おもむろにめちゃくちゃなコードを書き始めて、それを次第に形にしていくというやり方が好きだとあります。「デバッグとは書き間違いや見逃しを捕まえる最終段階の工程だと教わったけれど、実際に私がやっていたのは、プログラミングそのものがデバッグという具合だった。」と。
それと同時に、当初ポール・グラハムは、自分が世間一般で良いとされている方法論で物を作ることができないことに引け目すら感じていたのだともあります。
実は、このポール・グラハムが感じていた引け目というのと同じ類ものを、僕もずっと感じ続けていました。
http://d.hatena.ne.jp/naoya/20050518/1116425594
自分と同じような作り方をしている人がいて、それに引け目を感じる必要がないことを教えてくれたのだ。ソフトの作成方法も「それぞれが選んだスタイル」で「それぞれのひとつのラダーライフ」を進んで欲しい。
引用分の引用している本。
「ONE」が入ってます。
ソフトウェア開発で伸びる人、伸びない人
SEの教科書を読んで読みたくなったこの著書だが、いくらかこの本のおかげで自分の修正するべきところが見えたのでよかった。
ソフトウェア開発で伸びない人の章で、自分に当てはまるかなと思えた部分が「解決策偏重」と言う項目で、技術習得を躍起になってやるのだが、その技術の世間一般に言われているうたい文句以外の自分の評価を持っていなかったかなと。あったとしてもこの辺が面倒とかやりづらいとかの操作性とか他の技術との作業面での優越を考えていただけだった。開発するシステムに対してこの技術はどのように役に立つのかなど考える必要があった。その辺りを踏まえ、新しい技術がシステムに対して役に立つかを考慮が足りず、システムをいかに作るかにばかり目がいってしまい、その後の保守性、拡張性などの考慮が足りない傾向の修正が必要だと感じた。
ソフトウェア開発で伸びる人の章で、言語力、人との関係などまだまだ磨かなければならないなと思える項目がある中で、構造力が特に足りないなと感じた。システムをいくつかの機能に分けて、それを積み上げるような作り方をしていた部分があったかなと。よく難しい問題があった場合に、その問題を分解して細かい問題として１つ１つ解決するといいと言ったことを聞いたことがあると思うが、システム全体を難しい問題と捉えて、小さな問題（機能）を一つ一つクリアするような作り方をしていた。各機能の相互関係を踏まえ構造していく能力が足りないように感じた。
この本の良いところは、いくつかの問題点を教えてくれた上で、その部分を見直すための推薦図書を載せている所なのだが、解決策偏重と構造力については本の推薦がなかった。
だが、本の推薦は無いものの「保守」への考慮とその経験が重要としているかと思う。現場に行けと。現場経験が足りないと考えていたので「結局はそこかぁ」と感じた。
１部はソフトウェア開発で伸びる人、伸びない人だが、２部はソフトウェア開発で幸せになれる人、なれない人となっている。これは昨今注目のキーワードとなりつつあるライフハックがこんなことを教えてくれるのかなと思った。
最後に著者があとがきで引用している文を引用したいと思う。自分は毎年今年の目標を元日に書初めにしているのだがその目標をあらためて思い出させてくれた。以下は引用の引用になるのかな。どうぞ。
まじめに努力していくだけだ。これからは、単純に、正直に行動しよう。知らない事は知らないと言おう。出来ない事は出来ないと言おう。思わせ振りを捨てたならば、人生は以外にも平坦なところらしい。磐の上に、小さな家を築こう。
太宰治「正義と微笑」
最後の部分はよう分からん。
SE の教科書 〜成功するSEの考え方、仕事の進め方
最近の自分の中で新書ブームなので手に取った一冊なのだが、よくあるＨＯＷＴＯ本と思いきや、これがバグを少なくするにはどうすりゃええんよと考えてた自分には考えさせられる一冊だった。
自分がやってきた仕事の中で１番バグが発生するシチェーションは現場での変更。そしてあたり前の事のことだが短納期が上げられる。ただ、これは自分の能力不足であることも事実なのだが、その前にこのシチエーション自体を無くすという発想がなかった。というかあきらめていた。
これらのシチュエーションを無くす上での筆者が重要視しているのはコミュニケーション不足及びマネンジメント不足。仕様書を作成して「ちゃんと書きました」では済まずに結局は仕様変更となったりすることはよくあることだが、それ自体をなくするべき方法を提案している。
自分も、仕様書を見てくれないから、仕様書もおざなりになってしまい、仕様書が読みづらくなり、仕様書が読みづらいから仕様書を見てくれない。という負のループにつながっているように思う。これらのことも踏まえて現場対応で直して結局うまくいった現場も数多いので、それが当たり前になっている部分がある。（注：うまくいくのは小規模のもの）
マネンジメント不足に対する言説がとても考えさせられたので引用。
問われる経営者の責任
突き詰めていくと、プロジェクトが失敗する原因の多くは、かなり直接的にその組織の経営者にあるといえます。たとえば、できるかどうかもわからないような開発を受注して、社員に無理矢理やらせている経営者や、顧客がいくら理不尽を言っても交渉に行かない上司、そして数字だけを見てその上司を「よし」としている経営層等、例をあげればきりがありません。上司が嘘をついて受注したのに、謝りに行くのはなぜか実作業者だったり、あげくの果てには「それが仕事というものだ」。(P68)
このあとにプロジェクトマネジメントはＳＥよりも経営者やプロジェクトマネージャなどのＳＥの上位者がより勉強する必要があると説く。そしてそれは現実的ではないので、他の「現実なこと」で置き換えられるが成功させる大きな要因と言っていて、さらにできるＳＥもしくはプロジェクトマネージャはたいてい上位の人々に動いてもらうかを、常に考えていると言っている。
ここが悩み所なのだけど、そもそも短納期ってのはよくあるものと思っているけれど、それを上位の人々も思っているので、短納期でも簡単に仕事を受けてしまう傾向があり、顧客もそれを知っていて短納期で普通に頼むというまた負のループが発生しているのだから、ちょっとどうにかならんかなと考えている。最近、忙しくて短納期のものはやむなく断わり続けていることがプラスにならないかなとほのかな期待はあるのだけれど。
