元プログラマー、現在無職の管理人ヒロユキと申します。
GIGAZINEでプログラマー関連の記事などをサーフィンしているときに、以下の記事を見つけました。
https://gigazine.net/news/20130729-reasons-good-programmer-must-be-lazy-and-dumb/
怠け者で愚かな人間ほど優秀なプログラマーに向いている理由
怠け者のプログラマーは自分の仕事を減らしたいがために、便利なツールやソフトを作成することがあります。
また、単調で、繰り返されるだけのコードを書かず、余分なものをそぎ落とす傾向があるとのこと。
自分が楽をしたいがために生み出される努力から作り出されたツールは、生産性をあげるのに一役買ってくれるでしょう。
私も、コピペして永延と作業することが大嫌いなので、何回も繰り返すことになりそうな作業については必ずツールを自作して対応していました。
平均以上のプログラマーの方であれば「何を当たり前のことを言っているんだ？」と思われるかもしれません。
しかし、実際の職場では半数くらいの人は単純な作業を愚直にやっているように思いました。
もし、あなたがあまり自作ツールなどを作らないプログラマであれば非常にもったいないので今すぐマインドを変えたほうがいい理由を記載していきたいと思います。
ツールを作らずに手作業するプログラマ
前述のとおり、プログラマーという自動化を専門とする職業についていながら、自分の単純作業を自動化しない人が半数くらいはいる感じがします。
これは、経験年数の多さにはあまり左右されないように思います。
新人のプログラマーでも、「これは自動化しておけば後で楽できるな」と思いツールを作成したり、もしくは既にネット上に存在するツールなどで対応できないか考えたりできる人もいます。
一方でベテランでも、あまりそういったことはせずに、なんとなくコーディング作業している人もいます。
要は「仕事で楽をしたい」という気持ちを持っているかどうかが重要だと考えています。
極端なことを言うと、私は「コーディング以外は絶対しないぞ」くらいの気持ちで臨んでいた時期もありました。
ツールを作る最大のメリットは モチベーションの維持
すごく簡単な例でいうと、プログラムのコンパイルやデプロイなどは必ずバッチ化していました。
（まあ今だと、Jenkinsパイプラインとかを使用していて、そもそも不要だったりするケースがほとんどだと思いますが…）
「いやいやメモ帳とかに必要なコマンドをコピーしといて、手で打てばいいじゃん」と思われるかもしれません。
実際に、 生産性はそれほど変わらないかもしれません。
では何故やるのか？
単純作業を手作業でやると心が消耗するからです。
バッチを叩いたら終わりというのと、コマンドを1つ1つ入力しなければいけないのでは所要時間は同じでも、心理的負担が段違いなのです。
そして、バッチを作成すること自体が「自分の作業を効率化してるぜ！！」という有能感に浸れるため、仕事が楽しくなる1つの要因になります。
ただルーティンワーク的に作業しているより、こういった工夫で少しでも楽しくしたほうがモチベーションも上がると思いませんか？
くだらないように見えて、割と重要な要素な気がします。
その他にもメリットはたくさんある
手作業を減らすメリットはまだまだあります。
- （内容によっては）時間短縮になる
- 他の案件で使いまわせる
- ミスが減る
- 保守が容易になる
- 雑魚と思われない
1つずつ詳細を記載していこうと思います。
（内容によっては）時間短縮になる
これは言うまでもないかもしれませんが、手で作業した場合は10分かかる作業でもプログラムを組めば10秒で終わることも多いです。
その作業が繰り返しやる作業であるほど、ツール作成にかかった時間を回収しやすいです。
他の案件で使いまわせる
私は、SIerでWindows環境で作業することが多かったのですが
- DB定義書をEXCELで書く
- DDLを作る
- DDLからコードを作る（DAOみたいな インターフェースとか）
当時はフレームワークによるマイグレーションとかもありません。正直、ウンザリするほど上記作業をやりました ( ˆ꒳ˆ; )
あとはWBS管理の自動化とか
MarkDownやEXCEL仕様書からコード生成とか
テストデータをDBにぶち込むとか
結局、似たようなことをやることが多いので、1度ツール化してしまえば、その現場にいる限り長く使いまわせるというのはありました。
ミスが減る
昔、新卒で入社した会社の先輩から
「ツールを使用してデータを作成する？そのツールにミスがあったらどうする？単体テストするの？」
みたいな詰め方をされたことがありました。
確かにツール作っても、大抵どっかにバグがあって修正する羽目になります。おそらく手でやったほうがリスクは少ないです。
しかしプログラムは何がダメだったか明確になるのでブラッシュアップすればミスを潰しやすいのです。
手作業でミスした場合は、原因と対策を打つのが面倒なので、長い目で見ればツールを使用したほうが良いと思います。
ただ、以前にコード自動生成ツールが原因でバグを起こしたときに、思いっきり自分のせいにされたことがありました。
「ツール化すると必ずミスはある」という考えておくのも重要です。
保守が容易になる
例えば、「仕様変更によりインポートするCSVファイルのレイアウトが微妙に変更になりました」とかはよくあります。
仮に単体テストが200ケースくらいあったとき、全てのテスト用CSVデータを手で直すとしたら大変です。
おそらくシェルとか使って直すと思いますが、そもそもテストデータの作成自体をツールなどに頼っていれば、ツールを少し改修するだけでよいです。
雑魚と思われない
自動化している人が凄いとは思わないですが、明らかな単純作業を必死で頑張っている人がいたら、どうしても下に見てしまいますね。
プログラマ以外で例えると、「PCでの入力について、コピペを使用せずに全部手打ちでやってる」みたいな感じです…。
デメリットもある
メリットについて記載をしてきましたが、デメリットもあるかと思います。
- 作成に時間がかかる
- ミスした時に責任問題になる
- チーム内に展開すると面倒なことになる
1つずつ詳細を記載していこうと思います。
作成に時間がかかる
作成するツールの内容にもよりますが、前に例を出した「DB定義書(EXCEL)から DDLを作る」なら半日くらいは欲しいですかね。
一方で普通に作る場合であれば、1時間あれば余裕そうですよね。
つまり1時間で終わる作業に対して半日も使っているわけで、スケジュールの圧迫は必至です。
その後はツールを使用して時間を取り戻せると思いますが、朝会などで毎日進捗確認がある場合などは辛いですね。
「こいつ作業めちゃくちゃ遅いなあ」って絶対思われます。
ミスした時に責任問題になる
実際に発生した問題なのですが、MarkDownの仕様書からコードを自動で作るみたいなことをやっていた時に、重大なミスがあったことがあります。
その時、チーム内でそのツールを使用していたため手戻りが多く発生してしまいました。
「不確実なツールを使っていたので手戻りが発生しました」なんてのは報告する羽目になり、客先のリーダーから激しく叱責されました。
チーム内に展開すると面倒なことになる
ツールをチーム内に展開するとサポートデスク並みにQA対応する羽目になります。
「このケースで動かないんだけど」
「フォーマットが変わったから対応させてよ」
こちらは善意で提供したのに、まるで自分が客であるかのようにサポートを求めてきます ( ˆ꒳ˆ; )
私は誰にも展開せずに1人で使う
デメリットに記載した「ミスした時に責任問題になる」、「チーム内に展開すると面倒なことになる」という経験から、私は自作ツールは自分のためだけに使うということを決めています。
他人にツールとかないかは滅茶苦茶聞くけどな！！
この辺は自己防衛や戦略の部分もあるので、せこいですが、この方針で対応しています。
特にツールを展開した後の責任問題は怖いですよ。
まとめ
- ツールを作成することで 「自分の作業を効率化してるぜ！！」 というモチベに繋がる
- その他にもいろいろなメリットがあるので是非ツール化しよう
- 責任問題が怖いので、私はチーム内には展開しない
ここまで書いていた中で思ったのですが、Web系の企業とかだと アジャイルやCI/CDが普通になってきているため、「そもそも全部コードでやる前提」になっているのかもしれないですね。
ウォーターフォールの場合は、コーディングの前に詳細設計は必ず来るので、その辺を効率化するための個人施策は持っておくべきかと思います。