読者です 読者をやめる 読者になる 読者になる

Murga

個人的に言いたいコト・主張・気持ち。

学習コストの見積もり方とスキル不足への危機感

エンジニア必須スキル 日本の SE 効率化 ストレス
  • 数百あるファイルの先頭に今日日付を付与する一括リネーム処理
  • 毎月決まったファイルをインプットに作る資料
  • エクセルファイルの印刷範囲を統一する設定

みたいな作業を、バッチスクリプトもマクロも書かずに手作業して、案の定「途中で間違いに気付いた」とか「このファイルだけやり忘れてた」とか言ってる連中ばっかりな SIer にいる。

パソコンが最も得意なのは同じ作業の繰り返しだし、プログラマやエンジニアが持つべき美徳は「同じことを繰り返したくない」という怠惰だ。

それなのに、手作業で何時間もかけて低品質なことをやり続けている。

これが、まだ新卒で入ったばかりのプログラミング未経験者なら、「バッチとかマクロとか勉強しなね」で済むけど、上司がこういうこと平気でやってて、部下への作業時間見積も手作業でやる前提で出してくるからタチが悪い。俺がスクリプト書いて5分で終わらせてやると、それを一つひとつ目視確認して何時間もかけてたりして泣ける。

自動化しない人たちの心理

上に書いたような作業はいずれも、Windows バッチスクリプトなり VBA なりで1・2行、ループ処理の記述のために改行しても10行満たないようなレベルの簡単な処理だ。それなのに手作業を続ける連中は何を考えているのか。

彼らの言い分はこうだ。

  • 「VBA 書いたことなくて分かんないから、勉強に時間かかりそうだし…」
  • 「バッチスクリプトに間違いがあったら困るから…」
  • 「一気に色々自動で動くと何が起こったのか分からないから…」

この人たち本当にプログラマ兼システムエンジニアなんだろうか?

やったことなくてもやらんかい

何か一つでもそれなりに言語経験があって、パソコンがどう動いているのか、プログラミングとはどういうことかという認識があれば、どんな言語だろうと、やろうとしていることが「書けない」なんてことはないのだ。

現にコイツらは、開発言語問わず、「詳細設計書」なる、日本語で全ての処理を手続き的に書く、無用なドキュメントを作っているではないか。ということは、「要するに何がやりたいのか」は日本語なり擬似コードなりで書けるはずだ
(いや、もしかしたらこれは、「実は日本語でも自分たちが作りたいものを書けてなんかいなかった」で終わる話なのかもしれないけど。)

擬似コードが書けたなら、あとは対象の言語でどういう API (メソッド) を使えばそれが実現できるか、そこだけググればいい。何も言語仕様全てを押さえてからでないと1行もコードが書けないわけではないのだ。

それを、「やったことないからやらない」とはどういうことか。10年以上この仕事してて、やったことないことをそのまま放置する方がよっぽど悪いことだろうが。

ついでにいうと、バッチスクリプトが分からないというこの上司が、開発案件の中で作られたバッチファイルをコードレビューしている。こいつはレビュースキルもないのにレビュアーをやっている。詐欺じゃねえかこれ?

間違いがあっても平気なように準備しときゃいいだろ

次に「スクリプトが間違ってたら困るという話。間違っていたら、誰がどんな風に困るのだろうか?

一括リネーム処理が、間違ってファイルを消してたら困る?それってバックアップ取ってないの?てか動作確認すらせずにスクリプトを実ファイルに適用してんの?

スクリプトを書いたら実ファイルではなく適当なテスト用ファイルを作って試せばいいし、実ファイルをいきなり変えるのが危険ならファイルを別の場所にコピーして、変換したファイルを置き直せば良いだろう。

間違いがあっても大丈夫なようにしておくのはエンジニアが当たり前のように持つべき考え方。間違えても仕組み的に影響がないようにするとか、こうやればやり直せるとか、そういう不測の事態に備えておくのは当然だ。

「作業中にちょこっと書くスクリプト」における、エラーに対する考え方にもズレがあるかもしれない。

中途半端に Java 経験がある人間だと、NullPointerException に極端に怯えたりして、なんでも try / catch して例外を握りつぶす癖が付いていたりするが、例外やエラーというのは、正しくない処理が発生した時点で処理を中断してくれるものだ。だから、時には例外を踏まえた分岐を作ったりせず、「この作業範囲では例外は出ないはず」という状態を前提にコードを作り、それでも例外が出た時は前提条件がおかしいのだ、と区別できるようにしておく、といった考え方ができると良いだろう。

本番リリースするプログラムでないなら、別に間違いがあってもいいし、仮に間違えても平気だと言えるようにしておけばいいのだ。間違えたら最後、取り返しのつかないことになる、なんてモノにしようとする方が悪いのだ。

自分で組んどいて何が起こったか分からないとは

もはや何も言えない。自分が作ったものが作ったとおりに動く。うまくいっているならそれが当然だろう。

もし間違いがあって、結果が想定と異なる時に、どういう異なり方がありうるかも、書いたコードから事前にある程度想像できるだろう。move コマンドしか使ってないのに format が行われることはないだろう、でも違うフォルダに移動される可能性はあるかもな?とか。

やらない理由は並べ終えましたか?ご苦労さん。

技術をもって仕事してて、技術力で金をもらってるはずなのに、スクリプト言語は分からないから書かないとか、パソコンが自動でやることは分からないとか、ましてや「機械がすることは信用ならない」なんて言い方、間違ってもするもんじゃない。それは機械じゃなくてお前が悪い

結局のところ、ただ自分がやりたくなくて、それを学ぶ気もなくて、新しくなにかするよりも今までと同じことを続けた方が楽だと見積もった結果なのだろう。

学習コストの見積もり方がズレている

今この作業を手でやれば1時間だけど、自動化するバッチスクリプトを初めて書こうとすると、言語仕様を押さえてバグを取って、トータル2時間かかりそうだ。だから手作業にしよう。一刻を争う緊急事態ならそれも仕方ないと思う。

でも、そういう緊急の期限がないなら、今日のところは2時間かけてスクリプトを書いてみたらどうだ?結局その仕事、毎週定例作業でやってるんでしょ?だったら今日は2時間かかるかもしれないけど、来週は5分だよ。

先程も書いたが、別に言語仕様全てを知る必要はなくて、「ここではループ処理でリネームだけできればいい」なら、その時は IF 文すら知らなくたっていいのだ。

最近ならやりたいことをどうやればいいのか、正解となるコードもネットに山ほど存在する。もしかしたらコピペするだけでもやりたいことができるかもしれない。本当に手作業よりも言語学習の方が時間がかかるのだろうか?

何が言いたいかというと、新しいことを学ぶのは、思うほど時間がかからないし、大した苦労でもないということだ。それを頑なにやろとしないのは、今より楽で便利な方法があろうとも、今までどおりの不必要で無駄な苦労をしたい特異な人たち、ということになろう。

勿論、やりたいことのレベルが上がれば大変になることもあるだろう。調べるのに1日かかったけど目的のものがまるで実現できない、なんて状態になるなら、その前に時間で区切って諦めて手作業に戻った方がいい。

でも、エンジニアが携わる仕事において、プログラムで解決不可能な問題はほとんどないはずだ。それに、自分がこうしたい、と思う程度の問題なんて、大体既に誰かもっと頭のいい人が考え尽くしてるはずだから、その文献を調べて真似ればいい。そうすれば自分は楽してその便益を享受できるし、それを改善してより効果的なものにもできるはずだ。

第一、自分が無知であることを怖くは思わないか?

「いや、俺そういうの分かんないから、できないんだよねえ。」

エンジニアなら二度とそんなセリフ吐くな。お前はもうエンジニアじゃねえ。

自分に何とかする能力、技術がないと思うなら、勉強しなきゃいけない。それで金もらってんだから。知らないままでいようとするってのは、金をもらう資格がないってことじゃねえか。

スキルがないのによくヘラヘラしてられるな、とぼくは逆に恐ろしくなる。技術のない技術屋なんて、無能じゃん。俺なら恥ずかしくてそんなヘラヘラしてらんない。

もっと気軽に、今の手作業を自動化する方法を調べてみないか?少しは自分のこと考えてみないか?