ぷろぐら×でざいん

エンジニアは非エンジニアの気持ちがわからない(3)

エンジニアは非エンジニアの気持ちがわからない(3)

エンジニアは非エンジニアの気持ちがわからない(3)

システムは完璧?

同僚 : たぬきさーん、データの更新ができないのですが?
同僚 : たぬきさーん、ここ動かないんですがー?

たぬき: おぉ、確認して修正しますねー
同僚 : お願いします(また、バグかよ…)
たぬき: 修正終わり次第、報告しますね(またバグかって思われてるんだろうな。つらたん)


システムはそもそも完璧な存在であり、人の命令に対して確実性の担保された結果・アウトプットを出してくれるものなのでしょうか。

例(1万行の明細の仕訳)

良い例で思い浮かぶのが1万行に渡る明細から仕訳処理を人の手で行うと、数字が合わなかったり、勘定科目が間違ってしまうという失敗・ミスが起きそうな気がしますね。また膨大な時間がかかり、人件費をそこに割くのは現代において無駄な気がしますね。それをプログラムに行わせると、100%ミスなく、確実な結果を出してくれる上に作業が一瞬で終わる…本当なのか?

検証

検証1 (誰が作ったの)

作業が人の手作業と比較すると断然早いのは同意しますが、正確無比の結果を出せるところは少し懐疑的になった方が良いかも知れません。
まず、システムが誰によって作られたものか考える必要があります。今は「人」が作っていますね。その「人」は完璧な存在なのかという問いに対しては殆どの方が「No」と仰って下さると思います。どんなに優秀な社長・プログラマー・著名人でも何らかしらの失敗・ミスをするものだと思います。

検証2 (本当に正しいの)

プログラムは人が出した命令に対して素直な結果を出力してくれます。では、その命令自体が本当に正しいかを検討する必要があります。明細の仕訳をそのまま考えると、勘定科目の出力は正しいか、計算ロジックは間違っていないか、端数の扱いが会社の方針に即しているかなどなど、検討すべき項目は山ほどあるものだと思います。上記の検証と被っているかも知れませんが、この検証2では要件が正しくプログラムに落とされているか、または要件が漏れていないかだと思っていただければ幸いです。

検証3 (そもそもの業務は正しかったのか)

さて、人のマニュアル作業を正確にプログラムに落とし込んだ際に、実はそもそもの業務作業が間違っていましたということはあったりなかったり… 端数は全て切り捨てでした、税金計算は業務では合計でやっていましたが違ってましたなどなど。

結論

プログラマー、システムエンジニア、呼び方はそれほど重要ではありませんが、多分我々の今の仕事は人の代替となる仕組みを完璧に近い形で提供することだと私は思っています。なのでバグが起きた際は自分自身の想定不足、テスト不足、検討不足と思って真摯に受け止め少しずつ修正していき完璧に近づけていくことが重要だと思います。お客様に金銭を頂戴する以上は完璧なものでなければならないという考え方は間違いだとは思いません。ただ、重要なのはバグが起こった際は素直に咀嚼し、謝罪し、修正し、信頼を崩さないことだと思う今日この頃です。
また、マインドセットはもちろんバグフリーのシステムを作るぞーというところにピン留めしておくことも大事かもですね。

理(ことわり)と経験を基に新しき物を構築してゆくは たまらなく楽しい これが私にとっての数奇なのやもしれぬ(徳川家康・第七服第七十五席より)

関係はあまりないですが、へうげものオススメです!


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です