ふり返る『WEB+DB PRESS Vol.112』寄稿録
少し前にもお知らせしましたとおり、8/24発売の『WEB+DB PRESS Vol.112』のリレー連載「Perl Hackers Hub」に寄稿しました。
記事のタイトルは、「自作ツールによる日常業務効率化 〜 初歩的なコードだけで身近な問題を解決！」です。Perlの連載なので、ここで言う「ツール」とか「コード」はPerlのそれですね。
その他、掲載誌の目次など詳細情報については下記をどうぞ。
執筆に至る経緯など、大まかな話は前回書いたので、今回はその具体的な内容についてまとめてみたいと思います。
執筆初期の諸問題
なにしろ『WEB+DB PRESS』なんて言ったらもう何年も前から読んでいましたし、ぼくが知っているプログラマーのうち読んだことがない人なんてどれだけいるの？ というぐらい知られた雑誌ですから、話をもらってから引き受けるまでは一瞬でしたが、いざ取り組んでみると想定外の問題がいろいろと噴出・・。とくに工程前半のテーマ設定には苦労したので、その辺りから。
テーマ検討
最初に話をもらった時点で大まかなテーマとして提案されたのは、「大掛かりではないけどつど便利に使えるPerl活用法」みたいな、「小道具としてのPerl」みたいな、いずれにしてもまさにぼくがいつもやっているようなことを、そのままちょっと紹介して、という感じだったと思います。
これについてはぼくとしても、自分が書けるとしたらそんなネタだろうな〜と思っていましたから、「ではそれで。」という感じでスムーズにスタートしたのですが、実際に書き始めてみると、いやこれってそんなにシンプルなテーマでもないな・・ということがわかってきました。
というのも、第一にどうしてぼくがそういう「小ネタ的なプログラム」を量産しているのかと考えてみると、それはぼくが「大掛かりなプログラムを書けない（そのための技術がない）」からで、つまりそうした小さいプログラムの背景には、ぼくが「非エンジニア」であることが密接に関わってるんですよね。
だから、対象のコードについて何か書こうとすると、どうしてもその説明の中で自分の非エンジニア的な側面について触れざるを得なくて、でもこれって文章全体を通してみるとけっこう邪魔というか、テーマをボヤけさせるノイズにもなりがちなんですね。
もう一つ、今回は既存ツールの概要やTIPSを紹介するのではなくて、自作のコードを示しながら解説する体を取ることになるので、ということは上記の「小道具としてのPerl」や「非エンジニアである私」といった要素に加えて、「自作ツールのお披露目」という、これはこれでちょっとレイヤーが異なる要素が生じてきます。
で、当初はこの辺りの切り分けをほとんどしないまま、「まあ、とりあえず書いてみましょう、なんとかなるっしょ」みたいな感じでスタートしたので、初稿ではまさにそれらが渾然一体となったものが仕上がってしまったのですが、その問題点をメイン監修者の牧さんからズバッと指摘されまして、それで対象とするテーマをグッと絞り込むことになりました。
それでどうしたかと言うと、ある意味では最初期のテーマ（「小道具としてのPerl」）に立ち戻りつつ、「非エンジニア」の要素は最小限まで減らして、話の軸としては「初心者でも扱えるPerlの基礎構文だけで、便利なツールが作れる！」みたいなことにフォーカスすることにしました。
どうもぼくの性格・指向的には、ついあっちこっちに話題を飛躍・拡散したくなりがちなんですが、とにかく「基礎構文だけで便利なツール」という点に軸足を置いて離さない、ということを考えるようにした、という感じでしょうか。
で、この原稿はたしかアウトライン（見出し案）を3月から書き始めていましたが、このテーマに定まったのは・・結局5月の半ばぐらいでしょうか。その間もけっこう休みなく書いていたので、だいぶ時間がかかりましたね。
懸念と対策
さて、そんなふうに具体的に書き進める中で、テーマとは別に、いくつか新たな問題が出てきました。
と言っても、これはあくまでぼく自身が問題視していただけで、他の人から言われたわけではないんですが、簡単に言うとぼくのコードの正当性というか、妥当性というか、信憑性みたいなものが不安だなと。というのも、ぼくが普段書いてるコードって完全に自分の中に閉じているもので、一応GitHubに公開しているものも少なくはないですが、その内容が間違っていたからって誰が困るものでもないので、ようは他人のレビューというものをほとんどまったく受けてないのですよね。
なので、そんなコードをいきなりWEB+DBに載せるなんてできるわけがないし、直すったってどこから直したらいいのか😇という感じなので、こういう悩みは他のプログラマーの人が執筆する場合に比べて、けっこう独自のものだったのではないかなあ、と思います。
もちろん、そのために監修の皆さんがいらっしゃるというか、掲載にあたっては事前にコードもチェックしてもらえるわけですが、とはいえ対象によってはそれなりに膨大なコードになるので、実際にそれを全部手元で動かして確認してもらうとかはちょっと現実的ではないし、仮にそれをやってもらったところで「直せ」と言われて直せるとも限らないし、さらにはそんなふうにコードを直したら当然文章の方だって影響を受けるはずだし、というのでこれもまたなかなか大きめの懸念に。
で、じゃあどうしたかと言うと、とにかく誌上に出すコードは可能なかぎり初歩的・基礎的なものにとどめて、コード周りの推敲が最小限になるようにしました。
これによって、コードとそれに伴う文章を延々直し続けるような事態は避けられますし、文章もメインテーマの「基礎的なコードだけで便利ツールを作る」を維持しながら仕上げることができます。
デメリットとしては、一部のトピックでは具体的なコードを示せず、「あとはGitHubを見ておいて」みたいになっているので、そこで技術的な物足りなさや違和感を感じさせてしまう可能性もあるなとは思いましたが、それはもう、すみませんがそういうものとしてお受け取りください、という感じで割り切ることにしました。
記事構成
そんな感じで徐々に固まっていった記事の中身は、大きく4つの章で構成されています。
1. 基礎構文でツールを作る
2. シェルコマンドを組み合わせる
3. ほかのツールを組み合わせる
4. 最小限のコードで書く
それぞれひと言で言ってみると、1番では主にPerlだけで書いた超シンプルな初心者的コードを、2番ではそれにシェルコマンドを組み合わせたものを、3番ではpecoなどの他のツールを組み合わせたものを、そして4番では再び超シンプルな小ツールを紹介しています。
この章立てもかなり終盤の方まで編集さんと議論しながら詰めていったのですが、原則的には、「単純なものから複雑なものへ」とか、「昔のコードから最新のコードへ」みたいな時間の流れを意識して組みました。
記事解題
といった前段を踏まえつつ、以下ではその各章で取り上げたトピックや関連リンクなどを記していきます。
1. 基礎構文でツールを作る
ここでは上記のとおり、Perlだけで書かれた単純な、しかし自分の実作業を飛躍的に効率化してくれたツール群を紹介しました。
まあ、あまりにもシンプル過ぎて、これを「ツール」と呼んで良いのか、という問題もありそうですが・・とはいえ、ここで紹介しているコードは、ぼくが実際の仕事の作業をする中で「これプログラミング使わずに全部手作業でやっていたらめっちゃ大変だったろうなあ」と実感していたものばかりで、なおかつぼくのプログラミング初期の頃から使っていたものなので、記事の最初はとにかくこれを取り上げなきゃ、と思って紹介しました。
ちなみに、ここで取り上げた各ツールの利用シーンとしては、ぼくがフリーランス時代に手がけていた音楽全集の編集作業がかなりの割合を占めると思います。
それもあって、記事中では当時の詳しい素材データなどもわずかながら例として出していますので、クラシック音楽好きの人には面白がってもらえるのでは・・と少し思っています。
2. シェルコマンドを組み合わせる
ここではMacのopenコマンドをはじめとするシェルコマンドを、Perlと組み合わせる事例を紹介しています。
しかし考えてみると、ぼくが普段書いてるコードって、だいたいここまでに扱ってる技術ばっかりで、それより複雑なものってほとんどないのですよね。
ほんとにプログラミング始めて1〜2ヶ月ぐらいの人でも十分に書けるものだと思うので、そういう意味では（とくに非エンジニアの人には）参考にしてもらえるかもしれません。
具体的なところだと、「複数ファイルの行数や文字数をカウントする」で紹介しているツールは上記の編集者時代に頻用しましたし、あるいは「複数のWebサイトを一斉に開く」とかは我ながら単純すぎてちょっとバカっぽいなとも思いますが、でも地味に便利なんですよね。今でも時々使います。
3. ほかのツールを組み合わせる
メインはこの章だと思っています。ぼくが普段めっちゃ使ってる自作ツールを次々紹介していますので。
とくに、このブログでも何度か紹介しているchocoというツールがありますが、
今回扱ったツールの中で何かひとつだけ選べと言われたらこれを選ぶぐらい、ぼくにとっては必須のものなので、これを紹介できたのは良かったなと。
プラス、このツールではその主要な機能を提供するものとしてpecoが使われているんですが、
GitHub - peco/peco: Simplistic interactive filtering tool
そのpecoを開発している牧さんが今回のメイン監修者だったので、なんというか・・今にも逃げ出したいような😱でも非常にありがたいような、得がたい経験をさせてもらいました。
あとは、ぼくがプログラミングを始めた初期の頃から公開しているcarvoというゲーム？みたいのがあるんですが、
これは冷静に考えると便利ツールでもなんでもないんですが（笑）、しれっと含めることができてよかったかなと*1。
あとはAgっていう文字検索ツールを手軽に使うためのツールとか。
finds/find-word.pl at master · note103/finds · GitHub
これもかなり使用頻度が高くて、作り始めたときよりも今の方が使ってるかも、というぐらいよく利用してます。
4. 最小限のコードで書く
最後の章はこちらですが、ここでは今まさに会社で自分の業務のために使ってるツールを紹介しています。
少し前にTwitterでこんなことをツイートしましたが、
今月発売のWEB+DB記事の最後で紹介しているツール、今まさにめちゃ頻用して安堵している。紹介したけどもう使ってない、というのはつらいので
— Hiroaki Kadomatsu (@note103) 2019年8月5日
そこで言ってるのがこのツールです。
GitHubだとここに公開してありますが、
finds/find-file-open.pl at master · note103/finds · GitHub
あまりにも短いので誌上でもほぼ全部載っけています。
詳しい用途については記事で解説しているので、そちらをご覧頂きたいですが、とにかく出社して編集仕事をしているときは必ず使っているので、そのつど「ああ、作ってよかった」と思っています。
実工程のふり返り
ここからは、現在の目で工程全般のふり返りを。
執筆・編集工程
ええと、曲がりなりにも過去10年にわたって編集の仕事をしてきて、その間にはプロの執筆家の方々と毎日のようにやり取りしたり、その原稿を読んだり、時には自分でもテキストを書いたりしてお金をもらってきたわけなので、最初はどちらかと言うと、同誌に寄稿する他のプログラマーの人たちよりも自分の方が「本業の人」として取り組んでいる自負があったのですけど、いやあ・・やってみるとめちゃめちゃ大変で、「本当にみんな、こんな大変なことをいつもやってるの？？」という思いが何度も湧き上がりました。
上記のとおり、この作業はたしか今年の3月からスタートしていて、まあ仕事をしながらではありますけど、でも土日はかなり使っていたし、平日も仕事から帰宅後に深夜まで及んで対応したりして、それでも入稿*2の数日前まで修正してましたからね・・。
普通に本業で編集・執筆やっていたときと同じぐらいの労力および時間を費やしてようやく間に合いました・・みたいな感じだったので、ほんとに他の執筆者も編集さんもみんなすげ〜な〜・・というリスペクトの気持ちでいっぱいです。これで税別1480円、めちゃめちゃ安いですよ（笑）。180ページほどの中にとてつもない価値と手間が詰まっています。
GitHub
以下はどこまで詳しいことを公開していいのかわからないので概要までですが、今回の記事はGitHub上で進行しました。これもありがたかったですね。
ぼくは基本的に、日本語テキストの編集もじゃんじゃんGit管理（というかGitHub管理）できたほうが良いと思っているので、環境的には申し分なかったです。
ちなみに、WEB+DB編集部がGitHubを使っている、という話は以前に「GitHub Kaigi」というイベントに参加したときに、編集長の稲尾さんが登壇しているのを見てざっくりは知っていたんですけど、
まさかそのフローを自分も体験できるとは（笑）5年前の同会場では想像もできなかったですね。（細かいフローはだいぶアップデートされてると思いますが）
GitHubの良いところは、とにかく前のバージョンを残せる、見返せる、というところだと思います。もちろん、消したい過去も残るわけですが、基本的には同じ目標に向かって進むひとつのチームですから、仮に恥ずかしい間違いや操作ミスがあっても、それはそれでべつにいいや、という感じで遠慮なく使わせてもらいました。
Issueなどの機能もけっこう初めの方からバリバリ使って、思ったことはなるべくそのつどオープンに伝えるようにしました。この辺は生来の空気読まない気質が良い方に作用したかなと思っていますが、まあ同時に、その意見言い過ぎなところがいつまでも執筆・編集が終わらない遠因になったのかも・・という気も今してきましたが。
話を戻すと、GitHubを使うとテキストベースで正の情報をアップデートしていけるので、それがありがたかったです。最終的には、本番デザインに組んだデータの方が正（最終版）になるわけですが、それでも簡易的なレイアウトや文字数はギリギリ最後の方までGitHub上のプレーンテキストでチェックできるようになっていたので、この辺はやっぱり技評さんならではの技術力と言いますか、助かりましたね。
コミュニケーション
編集チームとのコミュニケーションも円滑で良かったです。編集長の稲尾さん、この1コーナーにここまでコミットしてくるのか（笑）と驚くぐらいすごいスピードで動いてくださって、これがプロの仕事・・という感想でした。硬軟のバランスというか、アメとムチの出し方というか（笑）あれよあれよという間に執筆モードに誘導され、必要な環境がセットされ、気がついたら集中して取り組んでる、みたいな感じでした。
工程の後半は同編集部の渡邉さんに担当してもらいまして、こちらも毎回迅速なレスポンス、かつぼくのめんどくさい相談にも深いレベルで検討＆回答してくれて、ありがたかったです。
とくに良かったのは、お二人ともレス（返信）が確実に来るんですよね。というのも、個人的にはレスって、べつに「早ければいい」というものではなくて、一番良いのは「想定どおりのタイミングで来る」のが良いレスだと思っていて、その意味で最悪なのは「めっちゃ早いときもあればまったく来なくなるときもある」というやつで、逆にその日のうちに返事が来なくても、毎回「午前の問い合わせには翌日午前、午後の問い合わせには翌日午後に返事が来る」みたいにパターンが一定なのがありがたいというか。あるいは事前に予告されていて、そのとおりに返ってくるとか。
そういう、ある意味基本みたいなところがきちんとされていてありがたかったな、と。
監修の牧さんにも、pecoの使い方でどれだけ怒られるかと戦戦恐恐としていましたが（←大げさに言いました）、改善点の提案なども論理的・丁寧に示してもらって、とてもやりやすかったです。
終わりに
ということで、丸々4ヶ月ほどにわたって取り組みました執筆もようやく終わりまして、またこの解題をもって本件全体についてもひと区切りかなと思います。
あらためて、今回の機会を与えてくれた 
id:papix さん、編集部・監修者の皆さん、ありがとうございました。
そしてまだ見ぬ読者の皆さん、どうぞお楽しみください。『ノルウェイの森』で小林緑が言った、以下の言葉を捧げます。
そのだしまきよ。心して食べてね。
- 作者: 樋口剛,篠田典良,谷口慶一郎,大沼由弥,豊島正規,三村益隆,笹田耕一,牧大輔,大原壯太,門松宏明,鈴木恭介,新倉涼太,末永恭正,久保田祐史,池田拓司,竹馬光太郎,はまちや2,竹原,粕谷大輔,泉征冶
- 出版社/メーカー: 技術評論社
- 発売日: 2019/08/24
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
