ツール開発のすゝめ ーDevelop Fun実践編ー


## まえおき ： ソフトウェア開発を楽しむ

ソフトウェアエンジニアを職業としているのであれば、
プログラミング（に限らず設計など含めたソフトウェア開発）を楽しめるかどうかは非常に重要なことだと思います。

では、どういう時に楽しいと感じるでしょうか

・書いたコードが自分の意図したとおりに動いた時

・プログラムがうまく動かない原因がわかってそれを直せた時

・作ったものを他の誰かが使ってくれた時

上記のような、ものを作ることが楽しい、という場合や達成感や充実感を味わうことで楽しい、と感じることができるのではないかと思っています。

## そうはいっても

プログラム初心者だったり経験が浅い場合、こういった体験を味わう機会よりも
うまくいかなくて挫折する機会の方がよっぽど多いと思います。

特に弊社のように長年メンテナンスされているシステムの場合、
動作の仕様だったりすでに動いているプログラムの構造だったりを把握できていないと、
たとえベテランの開発者であっても苦戦することが多いでしょう。

・いざ直してみても先輩からダメだしをされて凹んだり

・なかなか直せなくて期限に間に合わなくて凹んだり

・やっとのことでリリースしても別の不具合が発生して凹んだり

成功体験を積むことができない／失敗によって臆病になる／プログラム自体が嫌になってしまう

　→　プログラムが上達する機会が減る

という負のスパイラルにハマってしまうのではと思います。

## ツール開発のすゝめ

そこで僕がおすすめしたいのがツールの開発です。

ツールってなんか出来る人がバリバリ作ってる、みたいなイメージを持つ人もいるかも知れませんが、そんなことはありません。

ほんとに小さな事ができるツールでも良いのでまずは作ることから始めてみましょう。

むしろ簡単に作れそうなものから始めないと完成を見ずに挫折してしまうかもしれません。

### 日常の困ってることを解決しよう

意外とツール開発を勧めても何を作ったら良いかわかりません。と言われることが多いです。

そういう人は、

これ毎日手作業でやってるけどめんどくさいな…

このサイトよく使うけど入力欄せまくて不便…

といった自分が日常の中で困っていることからツールの開発ネタを探してみましょう。

作れれば自分が楽できるようになるし、作れなくても誰も困りません。

期限もなければどんな書き方をしていても良いので、ちょっと息抜きに10分15分時間を使って作ってみるのも良いでしょう。

### 好きな技術なんでも使えるよ

普段の開発であれば、プロダクトで使っている言語・技術で開発するのが当然です。

それ以外の言語・技術を使う機会は全くないといっても良いかもしれません。

ツール開発であれば（無料であれば）制限なく言語・技術を選択することができます。

今流行の言語を追いかけても良いですし、ネットなどで情報の集めやすい言語を選ぶというのも調べ物をする上では非常に有利です。

もちろん業務で使う言語・技術でツール開発をするというのも良いと思います。

ただ、それに縛られる必要がないのがツール開発の良さなので、頭を切り替えてなんでも駆使してやりたいことを実現しましょう。

言語・技術に縛られずに開発するというのもとても良い刺激になると思います。

### 設計・実装にこだわろう

これはプロダクトのフェーズにもよるかもしれませんが、設計だったり、全体の流れを通した実装だったりをする機会がなかなか巡ってこないということがあります。

設計の経験がないのにいきなり機能開発をやることになって四苦八苦することもありえない話ではないと思います。

なのでツール開発にちょっと慣れてきたら、来たるべき機能開発に備えてツールの開発の時にも設計や実装に（ムダに ←ココ重要）こだわってみるのも良い経験になります。

やりすぎたデザインパターンの適用だったり、ちょっとこじれた実装をしても、誰にも文句は言われません。

僕はプログラミングはいかにソースを書いたかによると思っています。

書いてみないと、使ってみないとわからないことも多いですし、色々試すことで引き出しが増やせるようになることでプログラミング技術は向上していくはずです。

### あとがき : ソフトウェア開発を楽しむ

色々と書きましたが、プログラムをした時の「できた！」という喜びをちょっとでも味わって、もっと難しいこともやってみよう！と思ってもらえたら幸いです。

## おすすめ

これだけだとQiitaの記事っぽくないかなって思ったのでツール開発する上でのおすすめを少し

ツールを作ろうと思ったらおそらくJavaScriptが実行環境という面で一番手っ取り早く簡単だと思います。

ブラウザさえあればいつでもすぐに開発やデバッグが可能です。

ですが、それをツールとして提供する場合、スクリプトを実行してもらうのもスクリプトの管理をするのも手間がかかります。

### スクリプトを実行してもらうためにおすすめのツール

[ScriptAutoRunner](https://chrome.google.com/webstore/detail/scriptautorunner/gpgjofmpmjjopcogjgdldidobhmjmdbm?itemlang=it&hl=ja)

特定の（ドメインの）サイトを開いた時に特定のスクリプトを自動で実行してくれます

社内で利用しているRedmineに特定のプロダクト限定の入力補助のような機能を実装する時に実際に利用しました

・ボタンを押した時にテンプレートを入力してくれる

・入力欄をそれぞれいい感じに広げてくれる

・不具合や機能強化などの分類によって項目名を変えてくれる

といったようなちょっとした機能がサクッと作れて導入も非常に簡単でした

### スクリプトを管理するためにおすすめのサイト

[jsdelivr](https://www.jsdelivr.com)

cdnとしてよく使われるJQueryなどのライブラリーの参照用のサイトと思われがちですが

Githubなどで公開されているスクリプトであれば自分が作成したスクリプトでも数秒でcdnを通してアクセスできます。

<pre>
https://cdn.jsdelivr.net/gh/ユーザー名/プロジェクト/スクリプトのパス
</pre>

ソースなどを更新してすぐにcdnに反映したいときはcdnの部分をpurgeに書き換えれば更新できます。

<pre>
https://purge.jsdelivr.net/gh/ユーザー名/プロジェクト/スクリプトのパス
</pre>

### スクリプトを提供する上でのちょっとしたテクニック

提供後にスクリプトを更新したい、ということはたびたび発生するでしょう

ですが、JavaScriptの提供の場合、ブラウザを通してのアクセスになるのでキャッシュされてしまいます。

更新自体はGithubで更新しておけばよいのですが、ユーザーに利用してもらうにはキャッシュの破棄をお願いしなければならず
随時更新して新しい機能を使ってもらうということができません。

ブラウザのキャッシュはクエリ文字列を含めてURLとしてキャッシュされるので、

クエリーパラメータとして日付を入れておくと1日単位でのキャッシュにすることができます。

そこで、別のスクリプトを1枚挟んで、日付入りのURLでスクリプトをロードするような形にするとキャッシュの期限をコントロールできます。

提供するスクリプトは以下のような内容にしておいて、実際の処理は内部で読んでいるJavaScriptに書きます。

<pre>
var d=document;
var s=d.createElement('script');
var da = new Date();
var md = da.getMonth() + '' +  da.getDay();
s.src='https://cdn.jsdelivr.net/gh/user/project/program.js' + '?timestamp=' + md;
d.body.appendChild(s);
</pre>

これで実際に処理を書いているJavaScriptの方を随時更新、リリースしていけば、利用している側にどんどん新しい機能を利用してもらえます。


いろいろと一個に書くことつめこみすぎたかな

まいっか