私は工場の自動化をするために、ソフトウェア設計の
企画書を作ってソフト設計者と打ち合わせしていた。
しかし、ソフト設計者がどういう点を問題視して
質問してきているのか、その真意を理解することができなかった。
原因はソフトウェアを作ったことがないからだった。
<ソフトウェアとは>
ソフトウェアとは後から変更できる柔軟なもので、
その反対のハードウェアは後から変更できない固定的なものだ。
例えば、パソコンはハードウェア、Windowsはソフトウェア、
スマホはハードウェア、LINEはソフトウェアとなる。
<ソフトウェアを理解するためにデバックしてみた>
ソフトウェアを作るのが一番の早道だが、
仕事で設計するということはできなかった。
理由は限られた設計期間で、低品質のものは作れないからだ。
そこで、ソフトをデバックするという仕事に関わった。
デバックとは 「原因は分からないけど、なんか、おかしい」
というプログラムを見つけて直していく作業だ。
デバックをして驚いたことは、プログラムの意味がわからないと
まともに動かすことさえできないことだ。
例えば、ベルトコンベアAを動かすというプログラムがあるとする。
「動け」と命令してもベルトコンベアAは動かない。
なぜかというと、ベルトコンベアAが動いていいという条件が
満たされていないからだ。例えば以下のような条件が必要だ。
1.非常停止ボタンは押されていないか
2.次のベルトコンベアBは動いているか
動いていなかったら、ベルトコンベアAを過ぎたら
モノが止まってしまうので、そもそも動かしてはいけない
3.運ぶモノの位置を知らせるセンサーは正常に動作しているか
4.ベルトコンベアを動かすモータは正常な状態か
5. コンピュータとベルトコンベアAはちゃんと情報共有できているか
6.「動け」という命令はきているか
本番はお客様の工場では、ベルトコンベアや非常停止ボタンもあるし、
位置を知らせるセンサーもあるが、
出荷前の状態では何もついていないコンピュータだけだ。
何がどうなっているかわからない。
これをコンピュータ上で条件にあたる命令を
ソフトでわざわざ模擬的に作って動作確認しなければならない。
条件の一つでも満たしていなければ動かないように
設計しているはずなのに、たまに動いてしまったりする。
この誤動作を見つけ、なぜ起こるのかを考え
プログラムを直す作業がデバックとなる。
これをするとソフトがわからないという状態から、
こんな面倒なことをしているんだということが腹に落ちてくる。
「なんか、おかしい」を見つけて直すとソフトはどのような視点で
作られているのかがわかってくる。