応用情報技術者試験を受けてきた

昨日2018/4/15、応用情報の試験を受けてきました。場所は東京情報大学というところです。

昨年10月に基本の方になんとか受かって、

note103.hateblo.jp

さて、これからどうしよう、応用も行くかどうか・・と悩んでいました。

悩んだ理由は、単純に「難しいかも」というのもありましたが、それとは別に、最近簿記2級の勉強を復活しているので、仕事に加えて異なる種類の勉強を2本同時にやるというのは、どっちつかずになって効率悪いかもな・・というのが大きかったです。

ただ、それでも今は基本情報技術者試験のための知識が一番残っているときでもありますし、今のうちにその辺をもう少し頭や体に定着させておきたい、という貧乏性的な気持ちがあったのと、あとはやっぱり、これは以下にも書きましたが、元々のこうした情報系資格試験を受けようと思ったきっかけとして、ちょまどさんが「基本も応用も合格した」という話が根っこにあったので、

note103.hateblo.jp
(例によって長い記事ですが、真ん中ぐらいで言及してます)

ひとつのキリとして応用まで行けたら綺麗だよなあ、という気持ちが根強くあって、結局申し込んだのでした。

しかしその後、やはりというか、けっこう頭の使い方が異なる2つの試験勉強を並行するのはきついというか、片方がわかりかけたときにもう片方をやらなきゃいけない、という感じでロスが大きいように思ったので、ちょうど4月に入ったぐらいから、思いきってより優先的な簿記の方に舵を切ることにして、応用の勉強はストップしていました。

そしてそのまま2週間ぐらい、時間ができるたびに簿記の勉強にすべてを費やしていたので、「もうこれじゃ応用、受けに行っても時間のムダだなあ〜・・。行けば丸一日つぶれるし、受験料はもったいないけど、休むか」と思っていたのですが、試験の前々日ぐらいになって、彼女から「応用はどうするのか」と聞かれて、「いや〜、迷ってるんだけどね〜・・」と、本当はもう行かないつもり95%ぐらいでしたが、ちょっと体裁が悪かったのであたかも迷っている風にぼんやり答えたところ、「行った方がいいんじゃないの」と言われたので「あ、はい」という感じで行くことに方針転換し、当日は朝からすさまじい暴風雨でしたが、もろともせずに(というか諦念と共に)行ってきた次第でした。

前回と前々回に基本情報を受験した会場は、たしか新習志野の千葉工業大学で、行く道すがら応用の教科書を読んでいる受験生もいたようだったので、当然今回もそこだと思っていましたが、結局そのように受験前日になって慌てて受験票に写真を貼り付けたり、会場の場所を確認したりしていたところ、今回は千葉の千城台というところにある東京情報大学で、初めて行く場所というだけでなく、アクセス的にもだいぶ時間や労力を費やしそうだとわかって暗澹たる気持ちになりましたが、実際にはJR千葉駅から大学前まで1本で行けるバスがそれなりの頻度で(日曜でも)走ってくれていたので、それほどの苦労はありませんでした。

とはいえ、当日は上記のとおり暴風雨で、基本的に皆同じバスで向かうだろうと思えたので、試験開始の1時間前には着くよう早めに出発したのも良かったのだと思います。

会場に着くと、基本情報のときとちょっと違うなと思ったのは、おじさんの割合が少し多かったことでした。

基本情報のときは、周りは若者ばかりで、高校生ぐらいに見える人も少なくなく、「うーん、やはりIT系の資格で、自分のように40代に入ってからわざわざ受けにくる酔狂な人はいないんかな」と感じ、「おじさんもどんどんこういう勉強したらいいのに、いろいろ役立つのに」などと偉そうに思ったりしていましたが、応用の会場には自分と同世代か、もしかしたらちょっと上かも、ぐらいの人もいて、ただこれは後から思いましたが、応用の場合は、これはこれでべつにぼくのような勉強とか趣味とかいう理由ではなく、仕事に関わるというか、この資格があれば昇進とか昇給とか転職とかに有利とか、そういった理由によるものかな・・とも思ったりはしましたが。

女性の割合は、あくまで感覚的なものですが、基本情報のときの方が多かったかな・・という気はしました。
やっぱり受ける世代が若くなるほど、女性の割合が多くなるのかな・・と、狭い観測範囲からざっくり感じているところです。

会場に到着後、ひとしきり筆記用具などの準備を終えた段階で、まだ試験開始まで45分ぐらいあったので、とりあえず何か飲み物でも買おうと思って構内を探しましたが、自動販売機がありません。

あれ、と思って入り口で案内をしていた職員の人に聞いてみたところ、今いる棟を一旦出て、向こうの何号館だかのそばにある、と教えてもらいましたが、その職員さんが指差す先、自動販売機のあるらしい場所と現在地との間には風雨が荒れ狂っており、今ここでそんなエネルギーを使ったら試験にもろ影響しそう・・と思って諦めました。

代わりに、昼ごはんのためにサンドイッチとおにぎりを買っておいたのですが、これは自分にはちょっと多くて、どちらかを残すことになるだろうと思っていたので、このうちおにぎりの方を食べてしまうことにしました。

以前からのささやかな知見として、のどが渇いたときには何かを食べると解消する、ということがわかっていたからです。
(食べ物にもよると思いますが)

思ったとおり、おにぎりを食べ終わる頃には水を飲みたい気持ちも消えていて、安心して試験開始を迎えられることになりました。

ちなみに、なぜそれらの弁当を用意した段階でお茶も買っておかなかったのかというと、それらはすでに前日のうちに買ってあって、家から持参したので、そのときに飲み物まで持っていくと荷物が重くなると思ったからでした。

もちろん、そうした前提には、会場である大学構内に自動販売機があるだろうという考えがあったわけですが、それがなかったので問題になったわけでした。

教訓としては、小さいお茶でもいいので、昼休憩までもつ程度の飲み物は持参しておいた方が安全だなということがわかりました。

午前の試験が始まって、すぐに思ったのは「イスが硬い・・」ということでした。

以前の会場ではとくに感じなかった気がしますが、今回はけっこう顕著な感覚で、途中で何度も座り直すなど、これをやり過ごすのには苦労しました。

資格試験に関わるセオリーみたいなもので、会場に座布団を持っていきましょう、みたいな話を聞いたことはありましたが、これまでの経験ではそういった必要性を感じたことがなかったので、自分には関係ないと思っていました。
しかし今回の経験で、今後はちょっとそれ、本格的に考えた方がいいなと思いました。

なお、一応フォローしておくと、今回の大学が他に比べてとりわけイスが硬いのかどうかはわかりません。
今回は「どうせ無理」という前提もあり、そこそこリラックスしていたので(緊張感が薄いというか)、その辺まで感覚が行き渡ってしまったのかも、とも思います。

その午前の試験、自分は計算の必要な問題が苦手だとわかっていたので、知識や記憶ですぐに答えられるものをまずどんどん回答(マークシートにマーキング)していきました。

具体的には、回答したものには問題用紙の問題番号の部分に◯とか◎とか△を付けて、すぐに回答できなかったものについては、「↓」とか「?」を付けていきました。

これらのマークは、以下のような意味です。

自信アリ
多分大丈夫
合ってるかもしれないけど間違ってるかもしれない
時間をかけて考えればわかる可能性があるけど、とりあえず後回し
皆目わからん。問題が何を言ってるのか意味不明

これで一度最後まで行ったら、そのまま逆方向にページをめくりながら(第80問から第1問に向けて)、マークミスがないかをチェックしていきました。

この際、「↓(後回し)」マークのうち、「ちょっと考えればできそう」みたいなものがあれば取り組んでしまい、回答が出たらそのままマークします。

これでまた第1問まで戻った頃には、全体の7割強ぐらいは埋まっている状態で、感触としては、「そこそこ出来てるじゃん」みたいな感じでした。

まあ、「自信があるもの」から順に埋めているので、当然といえば当然ですが、とはいえ、自信があるもの&そこそこ出来そうなものだけで7割以上埋まっているということは、この時点で合格基準点の60点を超えている可能性もけっこうあるわけで、にわかに「午前は行けるかも」と思えたのも自然なことだとは思います。

(ただし実際には、この時点ではまだ全然基準点を超えておらず、それどころかだいぶ厳しい状態に置かれていたことが帰宅後、自己採点をしてみてわかったのですが)

そこまで来たら、今度はまた第1問から、上記で「↓」や「?」を付けた問題のうち取り組みやすそうなものを選んで回答していきます。

ただし、ここであまりレイヤーを分けると後がつらくなりそうだったので、この段階ではもう「超絶難しい、当てずっぽうでやるしかない」か、「時間をかければできるかも」の2段階程度までに分けることにして、後者だったらその場で解く、という感じにしました。

これで最後まで行ったら、最後に残った「超絶難しい」グループに答えていきます。というか、当てずっぽうタイムなわけですが。

といっても、ここまで来るともう残り10問もなかったと思います。
それらについて、一応問題も読んでから、「それらしいやつ」を選んでマークしていきます。

後から自己採点をしてわかったことですが、この当てずっぽうグループが3〜4割程度当たっていたようです。

そしてこれも多分あとで書きますが、自己採点の結果は、80問中50問正解、基準点60点に対して62.5点だったので、これらの「まぐれ当たり」がなければ余裕で午前で落ちていたと思います。

さて、そんな状況とはつゆ知らず、「けっこう出来てんじゃん」とほくほくしていたこともあり、一旦すべての問題に回答し終えた頃から、基本情報の時にさえやらなかった「途中退室」を考えはじめました。

というのも、午前をフルで受け切ると、試験が終わるのが12時ちょうどで、午後試験は13時スタート、しかしその事前の説明は15分前ぐらいから始まってしまうので、昼食の時間はもちろんのこと、午後のための最後の詰め込みや、休憩を取る時間すら実質的にはほとんど取れないことになります。

今回はまともな試験勉強をしていない前提ではあったものの、やるからにはギリギリまで情報を頭に詰め込んでおきたいと思っていたので、そのまま「午前の回答を見返す時間」と、「午後のための勉強に使う時間(および休息)」とを天秤にかけて、より得点効率の高そうな後者を選びました。

といっても、その午前問題に回答しきって、マークシートの回答漏れやズレがないことを確認し終えたのは、退室可能なリミットである11時半の数分前で、まだ充分に見直しをしたわけでもなければ、これまでの試験で途中退室をした経験がなかったこともあり、やはりそこで出るのは不安が大きかったです。

実際、答案を提出してから、あれ、受験番号ちゃんと書いたっけ・・という不安に襲われましたが、上記のように、両方のメリットを取ることはできないので、それならそれで仕方ないと割り切りました。

初めての途中退室をギリギリで果たした後は、午前に確認した自動販売機の場所まで行って、お茶を買いました。

この時にはすでに雨は上がっており、風だけが勢いを増していましたが、それでも広々とした大学の敷地は懐かしいような、自由なような雰囲気があり、一瞬でけっこうリフレッシュできました。

会場近くの静かなスペースを見つけて、サンドイッチを食べながら午後対策の参考書を読みました。

午前問題に関しては以下の過去問を使いましたが(ぼくが実際に持っているのは平成29年度版ですが、ここでは新しい方を貼っておきます)、

(全文PDF・単語帳アプリ付) 徹底攻略 応用情報技術者過去問題集 平成30年度春期・秋期

(全文PDF・単語帳アプリ付) 徹底攻略 応用情報技術者過去問題集 平成30年度春期・秋期

  • 作者:五十嵐 聡
  • 出版社/メーカー: インプレス
  • 発売日: 2017/12/26
  • メディア: 単行本(ソフトカバー)

午後対策としては、以下を使いました。

平成30-01年度 応用情報技術者 試験によくでる問題集【午後】 (情報処理技術者試験)

平成30-01年度 応用情報技術者 試験によくでる問題集【午後】 (情報処理技術者試験)

  • 作者:大滝 みや子
  • 出版社/メーカー: 技術評論社
  • 発売日: 2018/03/13
  • メディア: 単行本(ソフトカバー)

後者の著者である大滝みや子さんの本には、冒頭で挙げた以下の記事にも書きましたが(再掲)、

基本情報技術者試験にうかった - the code to rock

基本情報の学習時にずいぶん助けてもらいました。

今回の本でもポイントが非常に絞られ、丁寧にまとめられ、なおかつとても親しみやすい語り口でスイスイ書かれているので、ともすれば悲壮感に包まれそうな直前の詰め込み作業にも、最小限の負担であたることができました。

そして実際、このときにパラパラとめくってはフムフムと眺めていた、「システム監査」のページに書かれていたキーワードがその後の試験にバッチリ出てくれて、かなり助かりました。
「試験によくでる」と謳われている本ですが、少なくともぼくにとってはまさにその通りでした。

ちなみに、前者の過去問集ですが、こちらは同書掲載の直近回である平成28年度秋試験、その1回分だけを80問すべて事前に解いておき、その間違えた箇所や、正解した設問でも意味のわからない選択肢やキーワードがあれば、対面ページにある解説に目を通すようにしていました。

対象を1回分だけにしたのは、単純に時間がなかったからでもありますが、それ以上に「一度間違えたところ」や「一度目を通した問題・解説」をくり返し読めるようにするためでした。

同じ時間を使って、新しい80問に取り組めばあと1回分(平成28年度春試験など)は解けたと思いますが、それよりも限られた問題をきちんと理解した方が効率がいいはずだと思いました。

あるいは、基本情報の勉強で使った過去問をもう一度確認して、苦手箇所を基礎から勉強し直すという方法も考えていましたが、これも結局は時間との兼ね合いで、応用の過去問に集中した方が手っ取り早く得点につながるはずだと思い、午前対策としては、その応用の過去問から直近の1回分に絞りました。

感触としては、その戦略は功を奏したように思われ、そこで出てきたのと同じ問題や、それに類する問題がいくつもあり、なにしろ直前に目を通していたので答えごと覚えているようなものもあり、午前をパスできたのは(あくまで自己採点ですが)そのおかげもあるかなと思っています。

昼休憩が終わり、午後に入り、イスが硬いなと思いながらもなんとか最後まで終えました。

今回の目標は、「午前合格、午後は回答欄を埋めきる」というものでしたが、残念ながら、午後に選択した問題の回答欄を埋めきることはできませんでした。

今回選択したのは、必須問題である第1問「情報セキュリティ」をはじめ、以下でした。

  • 問1 情報セキュリティ
  • 問2 経営戦略
  • 問9 プロジェクトマネジメント
  • 問10 サービスマネジメント
  • 問11 システム監査

じつは今年の3月頃、まだ日々の学習を簿記に振り切る前の段階では、第3問の「プログラミング」や、第5問の「ネットワーク」、それから第6問の「データベース」なども選択対象の候補に含めていました。

というのも、元々はその辺りの技術について詳しくなりたい、という気持ちが受験理由の一つにあったからで、逆に言うと、仮にマネジメント系の問題で合格したとしても、あまり達成感がないというか、そんなに嬉しくない・・という気がしていたからでした。
あくまで、技術的な分野で腕を磨きたいな、という。

しかし、今回の勉強時間でそれらに手を出すのは自滅と言うに等しく、おそらくトライしたとしても、わからなすぎてまったく面白くないだろうと思い、結局選択問題はすべて非技術系(ストラテジ&マネジメント系)で固めることにしました。

といっても、じつは第10問の「サービスマネジメント」というのが、基本情報のときには比較的相性が良かったカテゴリでしたが、この応用情報ではやけに難しく感じられることが多く、一方、第8問の「情報システム開発」を過去問で見たときには、存外スラスラ解けることがあったので、このどちらを取るかは当日に問題を見るまでわからないな、とも思っていました。

果たして、本試験の問題を見てみると、相性が良かったはずの「情報システム開発」の方はバリバリのプログラミング系、すなわち、オートマトン風の図や、擬似言語プログラム、あるいは聞いたことのないキーワード(サイクロマティック複雑度・・?)が踊り狂う問題になっており、ひと目で「サービスマネジメントにしよう」と決まりました。

マネジメント系をはじめとする、いわば文系的な問題では、問題文が小説のような架空の物語を舞台に作られており、これがなかなか面白く読めます。

そしてこの点は、「技術的な要素を避けられる」ということ以外の、これらの問題を選ぶ上でのメリットだと感じます。

ぼくは正直、他人が書いた長文を読むのは苦手なのですが(嫌いなのではなく、頭に入ってきづらいことが多いので)、どうしても読まなければならないのだとしたら、こういうフィクション仕立てのものの方が飽きずに読めて、楽しめます。

とはいえ、限られた試験時間を有効に使うためには、漫然と頭から読むのでは効率が悪いので、最初の1〜2段落だけ読んで概要を掴んだら(あるいは無理にでも掴んだ気になって)、先に設問の方にすべて目を通します。

そうすると大体、問題文中のどの箇所(空欄や下線など)に対して、どんな問いが投げかけられているのかがわかりますから、まずはその「問い」の方をある程度読み込んでから、そういう問いが来ることを前提に、問題文に戻って頭からスラーッと読んでいきます。

ちなみにこの際、問題文で空欄を問うものがあった場合、問題文全体を読まなくても、空欄を埋める選択肢や、その空欄前後の文脈だけで答えがわかる場合が少なくありません。
よって、それで埋められるところはこの段階で回答してしまいます。

応用情報の午後問題では、基本情報との大きな違いとして、記述式の部分が少なからずあります。

5字以内で答えよ、というものから、長いものだと45字以内、とかでしょうか。

これについては、多少は過去問や、上記の大滝さんの本などで「答え方」を練習してはいましたが、ぼくはこの「字数に収めつつ言いたいことを過不足なく言い切る」という作業で時間をかけすぎてしまったように思います。

じつのところ、この「字数に収めつつ言いたいことを過不足なく言い切る」というのは、ぼくが仕事でやっている編集作業のど真ん中で使うスキルなので、むしろ有利では? という気もしますが、ぼくの場合は、仕事であればとくに、ある程度納得行くまで直し続けたりするので、その「直しすぎる(時間をかけてしまう)」というのが足を引っ張ってしまったかなと。

もちろんというか、プロの編集者の中には、パッと見てパッと文字数に収める、みたいなスキルが高い人も多いと思うので、そういう人には有利かもしれないですが・・。

とくに今回の場合、第9問のプロジェクトマネジメントで、その文章づくりにちょっと時間をかけすぎました。

時間配分としては、本来1問につき20〜25分程度で進めて、残った30分程度を、後回しにした問題なり、見直しなりにあてようと思っていましたが、この第9問では、7〜8割ほど回答するだけでも35分ぐらいかけてしまい、時間の貯金をだいぶ使ってしまいました。

今「後回しにした問題」と書きましたが、この午後問題でも、午前と同様、時間がかかりそうな難しい設問には深入りせず、サクッと解けるものから埋めていきました。

結局は、その後回しにした問題を埋めるだけの時間を最後に確保できなかった、というのが途中答案になってしまった敗因なのだと思いますし、そのまた要因になったのが、プロジェクトマネジメントの問題だったのだと思います。

ちなみに、プロジェクトマネジメントに時間がかかったのは、上記のような文字数の調整や、言い回しを適切にすることについこだわってしまった、ということもあると思いますが、同時に、その架空の世界に入り込みすぎた、というのもあるかなと思っています。

難しい設問には深入りしないように注意していましたが、問題世界の方に深入りしてしまったというか、つい時間を忘れて、その中の登場人物たちに感情移入してしまったような、そういう感覚がありました。

架空の世界を元にした問題文には、「退屈せずに集中できる」というメリットがあると書きましたが、そういう思わぬデメリットもありそうだとうっすら感じます。

空欄のまま提出、という残念な部分はあったものの、すべて終わったときの感覚としては、「思ったより、できたな」という感じでした。

「こりゃ、受かるな」というほどではないですが、前々日まで行かないつもりだった試験とは思えないほどの成果とは言えます。

帰り道には、ちょうどバスが出てしまったばかりだったこともあり、次の次ぐらいの停留所まで、バス通りに沿った一本道を歩きながら、最近なぜかハマっているサザンオールスターズの『バラッド』を聴きました。

バラッド '77~'82

バラッド '77~'82

このアルバムは、「いとしのエリー」「Oh! クラウディア」「Ya Ya」などの有名曲が揃っているベスト盤のようなものですが、個人的には「ラチエン通りのシスター」「涙のアベニュー」「恋はお熱く」「わすれじのレイド・バック」あたりを好んで聴いています。

こういうのを聴いていると、サザンは日本のブルースであり、ソウルだなと感じます。
猥雑で、なんでも取り込みながら国民音楽的なポピュラリティを醸し、なおかつ最後にはサザンでしかない音に仕上げてくるところには生真面目さすら感じますし、それより何より、桑田佳祐の歌はすごいです。生きているうちに聴けて良かったと思います。

気がつけば、永遠に続くかと思われた暴風はすっかり収まっていて、空は不穏な灰色に覆われていたものの、わずかに湿った春風に吹かれるこの帰途は、なかなか心地よいものでした。

帰宅後、頭が覚えているうちに午後試験の再現答案を作りました。

択一式の問題に関しては、持ち帰った問題にすべて回答がマークしてあるので、その必要はありませんが、記述式の方ではメモ程度にしか書き残していないものや、答案に転記した際に少しアレンジしたものや、試験の最後の方ではメモすら取る時間がなく、直接答案に書いたものも少なくなかったため、このままだと解答が発表されても自己採点をできないと思ったからです。

といっても、じつは普段は簿記にしても、前回の基本情報にしても、自己採点なんてやっても落ち込むだけだからと進んでやることはほとんど無いのですが、今回は元々どこか吹っ切れていたせいか、できるところまでやっておこう、みたいな意識高いモードになっており、やっておくことにしました。

必ずしも厳密ではないものの、ひとまずすべての再現を終えた頃、午前問題の解答が公開されました。

IPA 独立行政法人 情報処理推進機構:問題冊子・配点割合・解答例・採点講評(2018、平成30年)

午後問題の解答が公開されるのは、合格発表の5日前である6/15とのことで、おいおい、それなら自己採点用の答案、わざわざ作る必要なかったのでは・・とそのときに思いましたが、まあ答案用紙は戻ってこないはずなので、覚えているうちに再現しておけたのはやはり良い面もあったと思います。

と同時に、ここで午前分の自己採点も一気にやってみたところ、上記のとおり、合格基準点60点に対して、62.5点でした。

調子に乗って途中退室なんてしたわりには、思ったよりギリギリで焦りましたが、その後にあらためて正答・誤答状況を確認してみたところ、自信がなかったり当てずっぽうだったりした部分がけっこう当たっていて、それがなければ落ちていたのだとわかり、さらに焦りました。

自信アリの回答については、正解のものが多かったですが、「ちょっと自信ないけどたぶん大丈夫だろう」というものが案外どれもこれも間違っていて、これが実力というものか、と痛感しました。

午後問題については、上記のとおり、終わった時点での感触は「悪くない」という感じで、とくに択一系の(記述式ではない)問題についてはそこそこ自信があるつもりでしたが、この午前の結果を見るかぎり、やはり期待はしづらいな・・と思っているところです。

最後に免責事項を。

途中でいろいろと勉強法について偉そうに書きましたが、自分では通ったと思っている午前問題すら、まだ結果は出ていませんし、ましてや全体に関して言えば、「この方法を実践すれば受かる!」みたいなことはまったく言えませんので、あくまでそのような前提として捉えてほしいと思います。

さて、合格発表は6/20ということで、なんと2ヶ月以上先ですか。

記述式の答案がある以上、仕方ないと思いますが、基本情報の方が合格発表まで1ヶ月だったにもかかわらず、かなり長く感じましたので、この応用については、一旦「忘れておく」ぐらいの方がいいのかもしれません。

考えてみれば、それ以前に6/10、ぼくが現在、勉強分野としてはメインで取り組んでいる日商簿記検定2級の試験もありますので、まずはそこに向けて集中するべきでしょう。

ともあれ、以上、応用情報技術者試験を初めて受けた感想を、記憶の鮮明なうちに記録しておきました。

ボッチでもOK

こちらは「春のPerl入学式リレーブログ」の7日目の記事です。
blog.perl-entrance.org

ひとつ前は、 id:kousy さんによる以下の記事でした。
kousy.hatenablog.com

Perl入学式での経験が仕事につながるというのは、すごすぎますね! 敬服します。
東京でのプログラマー生活、ぜひがんばってください。

今回の記事では、ぼくが初めてPerl入学式に参加したときのことを書きます。

ぼくが初めてPerl入学式に参加したのは、38才の夏でした。
これは同時に、ぼくがプログラミングの講義に参加した最初の機会であり、また初めて「プログラマー」と呼ばれる人々に対面した日でもありました。

その時のことは、以下の記事に書いています。
note103.hatenablog.com

今でもそうですが、ぼくは当時からプログラミングにまったく関係のない仕事をしていて、IT企業に勤める知り合いもいなかったので、このときには一人で参加することになり、会場には知ってる人が誰もいませんでした。

緊張していたせいか、時間よりも少し早めに会場に着くと、サポーター(スタッフにあたる人々) の id:papix さんや id:mackee_w さんたちもちょうど同じぐらいに着いていて、同じエレベーターに乗って上の階まで一緒に上がりました。

papix さんたちにはその時に少しだけ挨拶をしましたが、その後は基本的にサポーターさんはサポーター同士で楽しそうに話をしていて、今だから言えることですが、ぼくはうっすらと疎外感のような気持ちを抱いていました。

なにしろ、ぼくは年齢的に他の皆よりひと回りも(あるいはそれ以上に)離れていましたし、ITに関係ない仕事をしているのでその話題もまったく意味がわからず、周りに知り合いもおらず、Perl入学式自体も初めてで、さらにはその年の第3回の補講という、中途半端な回からの参加でもありました。

言うまでもなく、その疎外感はぼくが勝手に感じていたもので、サポーターの人たちから嫌な態度を示されたとかいうことは一切ありません。

ただ、自分以外の人は皆知り合いで、その人たちが共通の話題について楽しそうに話している、というその状況が、なんというか、チョット厳しかったわけです。

そしてぼんやりと、「ああ、自分が来るところではなかった」という気持ちになりました。

「呼ばれてもいないのに、身の程も知らずに、なぜこんな冒険をしてしまったのだろう?」と。

「あと何時間、この状況に耐えればいいんだ・・」と。

しかしながら、ボッチでも構わないから参加しよう、と思ったのは自分自身です。

とにかく時間が終わるまで頑張ろうと、そこは38才、なけなしの社会性を発揮して、こめかみには脂汗を浮かべながら、また周りの受講生の人たちともポツポツ会話を交わしながら、最後までなんとか時間を過ごしました。

それまでの人生でも、一人でイベントなどに参加することはよくありました。

知っている人が誰もいない場所に、後先考えずとりあえず飛び込んで、そのままコミュニティとの付き合いが始まったり、意図せず仕事につながったりすることもありました。

そういう経験が知らぬ間に体に染みついていたのか、初めは「すぐにでも帰りたい」と思っていたはずが、講義後の懇親会にも参加することになり、受講生やサポーターの人たちと少なからずおしゃべりをしながら、結局会場が閉まるまで残っていました。

その何日か後に、YAPC::Asia 2013が神奈川県の日吉で開催され、その中で行われたPerl入学式出張版にも参加しました。

Perl入学式 @ YAPC - YAPC::Asia Tokyo 2013
YAPC::Asiaで行われるPerl入学式のワークショップについて色々インタビューしてみました! | YAPC::Asia Tokyo 2013

なぜ一度痛い目にあったのに、懲りずにまた参加したのかというと、じつはYAPC::Asiaのチケットの方を先に買っていて、その下見のようなつもりで上記の講義(第3回補講)を受けていたからでした。

そして、このYAPC::Asiaでもまた、基本的にはずっと一人でした。

YAPCでのPerl入学式には、サポーターはもちろんのこと、先の受講生も何人か参加していたので、今度はまったくの一人ではなかったものの、YAPC全体を通してみれば、前夜祭でも、初日の懇親会でも、大半の時間は一人で過ごすことになり、それが数日間にわたり続いたため、このときには疎外感というより、もう少し重々しい、とりとめのない孤独のようなものを感じていました。

ちなみに、YAPCにおけるPerl入学式の内容は、普段とはちょっと違う番外編のようなもので、入門というにはひねりの効いた、少なくともぼくにはなかなかハードルの高いもので、何をやっているのかよくわからないうちに終わってしまった、という感じでした。

そういうこともあって、「やっぱりYAPC、俺には早すぎた・・」という後ろ向きな感想を持ちましたが、なぜかその後もPerl入学式には参加し続けることになり、翌年の4月からはサポーター側に回ることになりました。

ある種、痛切ともいえるボッチ体験に遭遇しながら、なぜその後もやめずに続けられたのかと考えると、結局のところ、その疎外感とか、孤独感とかいったツラさは最初に味わうものが一番大きくて、その後は痛みに慣れるというか、弱まるというか、軽減される一方だから、ということが言えると思います。

喩えてみると、バンソコウをはがす時に、最初にピャッとはがしてしまえばそれで終わるというか。

あるいはインフルエンザの予防接種を受けるときに、「はい、チクッとしますよ〜」とか言われて、「ひえ〜!」と思っても、その数秒後には全部終わってる、みたいな。

新しい体験がもたらす痛みは、最初の方ほど強く、しかし後は弱まる一方で、やがてそれは心地よい自分の居場所になっていきます。

この記事の前半で、エレベーターに乗ったときの話を書きましたが、今思えば、サポーターさんはサポーターさんで、普段はそれぞれ別の職場で仕事や生活をしていますから、Perl入学式という場で、気の置けない友人たちに久しぶりに会えたなら、普段はできない楽しい会話に時間を使いたくなるのはごく自然なことです。

当時のぼくからすれば、「自分と自分以外」という物の見方しかできていませんでしたが、実際には、サポーターにはサポーターの、特別な場としてのPerl入学式があったわけです。

普段の生活習慣から離れた場に、一人で飛び込むというのは、不安もあると思いますし、実際、人によってはツライ思いをすることもあるかもしれませんが、その次の瞬間から、欲しいものは確実に手に入ってきます。

ぼくの場合、それはプログラミングの技術でした。

だいぶ時間はかかりましたし、今なおかかっていますが、当初では考えられなかったほど、その技術を自分のものにし、それを楽しんでもいます。

プログラミングの勉強を始めるときに、一緒にやってくれる友達は不要です。
自分の体ひとつあればOKです。

Perl入学式では講義資料を広く公開していますし、

講義資料 - Perl入学式 | Perl Entrance

全国各地でも開催していますので、もし都合が合えば、いつでも参加してみてください。
www.perl-entrance.org

ノンプログラマーのプログラミング活用法

去る3月3日に沖縄で開催されましたYAPC::Okinawaでの発表内容をスクリーンキャスト形式で新たに収録してみました。

www.youtube.com

ただし、めっちゃ長いので(85分)各チャプターの頭出しをしたリンクも以下に並べておきます。
興味に近いところなどありそうでしたら、適当につまみ見してください。

  1. はじめに: https://youtu.be/jJZD3k6-q0c?t=0s
  2. 自己紹介: https://youtu.be/jJZD3k6-q0c?t=3m45s
  3. Vim: https://youtu.be/jJZD3k6-q0c?t=13m46s
  4. Shell: https://youtu.be/jJZD3k6-q0c?t=31m38s
  5. Perl: https://youtu.be/jJZD3k6-q0c?t=50m54s
  6. Excel: https://youtu.be/jJZD3k6-q0c?t=1h1m40s
  7. ふり返り: https://youtu.be/jJZD3k6-q0c?t=1h18m12s
  8. まとめ: https://youtu.be/jJZD3k6-q0c?t=1h22m1s

冒頭でも少し説明していますが、今回は発表の録画も録音もしてなくて、一応スライドは公開しているけどDEMOも多用しているので、スライドだけだと一部しかわからないし、まあ「そういうものだ」と割り切るのもアリなんだけど、実際はかなり準備していった話だからこのまま終わってしまうのもな〜・・と思って、このような形で再現してみました。

YAPC本番では40分以内に収めるためにいろいろトピックを削ってしまいましたが(Shell編の文字列検索とか)、今回はそれも含めて基本的には全部入りにしたので、そういう意味ではフルバージョンです。

と言いつつ、これも今聞き直してみたら「あ〜、あの話忘れた」「こう表現すればよかった」といった部分がポロポロ出てきているので、これはこれでひとつの未完成版というか、新たなライブ盤というか、YAPCとはまた別の即興的な何かかな、とも思います。

あとはYAPCの本番だとやっぱり、聞いている人たちの反応コミでの面白さみたいなのがあったので、その意味でも現場でのパフォーマンスとは別物といえば別物な気もします。

とはいえ、当日聞いてくれた人にとってはその補足というか、その日の内容を思い出したり、カットされた話を知るものとして聞けるかなと思いますし、沖縄まで行けなかった〜という人には、スライドではわからない部分を聞いてもらえる機会になると思うので、記憶がなくならないうちになんとか形にできて良かったなと。

なお、この発表に関するざっくりした話(というかスライド作成の過程など)については前回の記事に書きました。
YAPC::Okinawa 2018 ONNASONの記録 - the code to rock

発表スライドはこちら。
The Non-Programmer's Programming Techniques // Speaker Deck

その他、個別具体的なトピックについてはまだまだ語り足りない面もありますが、とはいえキリがなさそうなのでしばらくナシかな・・。

それよりはむしろ、イベント前後の前夜祭、ハッカソン、お土産屋めぐりなどについてまだ書いてないことがいろいろあるので、次に時間ができたらその辺りを書き残しておければ、という感じです。

最後になりますが、このような機会を作ってくれたYAPC::Okinawa運営スタッフおよび関係各位、参加者の皆さん、そして何より時間を割いてB会場で聞いてくれた方々、ありがとうございました!

YAPC::Okinawa 2018 ONNASONの記録

2018/03/03に沖縄県恩納村で開催されたYAPCに参加してきた。
yapcjapan.org

今回はなんと、スピーカーとしての参加。
http://yapcjapan.org/2018okinawa/timetable.html#/detail/10

初めはこの一連の出来事を時系列にまとめようと思っていたのだけど、あまりにもトピックや感想が多すぎて、ちゃんと書こうと思ったら完全に「仕事」になりそうだったので、頭に浮かんだ順に即興的に書いていくことにした。

スライドができるまで

今回、ぼくが発表したスライドは以下。

speakerdeck.com

ただし、当日の発表ではDEMOを多用しているので、このスライドに載っているのは全体の半分からせいぜい3分の2程度。

それは今回のスライドを作るときに強く意識していたことで、発表時にただスライドを読み上げるだけみたいな、紙芝居のように「スライドをめくりながらそれを見て喋る」みたいにはしたくなかった。

理想としては、スライドには見出しだけを列記する。そしてその一つ一つについて、画像なりDEMOなり、あるいは身ぶり手ぶりで説明してく、みたいにしたかった。

だから、スライドだけを見ても面白くもなんともない、現場にいないと(あるいは動画などで発表の様子を見ないと)意味がわからない、そんな感じにしたかったし、それで良いと思っていた。

(実際には、スライドだけを見てもある程度内容を想像できるようになっているとは思うのだけど。ただ事前の方針として、「後からスライドを見る人のために現場では不要な説明を加えたりしないようにしよう」と思っていたということ)

なにしろ今回一番大事にしたかったのは、わざわざ40分もの間ぼくの発表に付き合ってくれる人たちで、その人たちが「うひー、退屈だな」と思わないようにする、というのがほとんど最大のミッションでもあった。

スライドに書かれた文字が読み上げられるだけ、というのはなかなかツライ。大学の授業でもそういう先生が時々いた。
逆に、「その場にいないと得られない情報がどんどん飛んでくる」というのはスリリングで面白い。

だから、構想を練って項目を立てている最中もスライド化のことはなるべく考えず、Keynoteを立ち上げるのも可能なかぎり後に回した。

シャドープレゼンテーション

構想の練り方としては、だからスライドを作りながら考えるのではなく、かといってメモ帳やノート系のアプリを使うのでもなく、とにかく実際に喋ってみた。

頭の中にあるネタを喋りきって、それをすべて録音して、それを自動音声入力でテキスト化して、それをtextlintでざっくり表記統一して、それをプリントアウトして、それを眺めながら紙のノートにパラパラと見出しを書き出して、それを見ながらまた喋る。

これをたぶん3〜4周やった。

とにかく喋る&録音する、というのはシャドーボクシングならぬシャドープレゼンテーションみたいな感じ。

話を聞いている人たちのことを思い浮かべながら(その人たちは皆ぼくの発表に好意的だと設定しつつ)、その人たちに語りかける。

これはちょっとラジオにも近い。目の前にはいない、でもたしかに存在するはずの人々を想像しながら喋っていく。

だからこれは、「ポッドキャスト風ブレスト」とも言える方法で、それをやりながらどんどん構想を煮詰めていった。

ノートにプロットを書き出しつつ構成する、というのも試してはみたのだけど、プロポーザルを見てもわかる通り、ネタがあまりにも多すぎて、まともに精査していたら時間がいくらあっても足りないし、単純にもの凄く疲れそうだった。

その点、とりあえず思うままに喋るだけなら、頭の中はほとんど無意識というか、自動操縦のような感じになって、あまりくたびれずに膨大なアイディアを吐き出せたと思う。

加えて、喋りながら構想を練ると、60分も90分も喋っているうちにどんどん体が疲れてきて、また気分的にも飽きてくるので、この段階でネタの淘汰も進んでいく。

この話、そんなに無理してまで言わなくてもいいな・・みたいなストッパーが自然にかかるというか。

先にスライドを作り込んでからそれを実践するという順番だと、頭で考えた計画に体を従わせる感じになるが、この方法だと先に体の限界を設定しておいて、その条件を考慮しながら構想を作っていく感じになって、より現実的というか、結果的にではあるが、案外効率的だったように思っている。

ミニマルなスライドのメリット/デメリット

初めにブレスト的に、一旦最後まで喋ったときには90分ぐらいかかった。

理想としては、40分の持ち時間のうち、最後に5分の質疑応答を入れるとしたら発表自体は35分に収める必要があるから、ほとんど1時間オーバーしてる。

さすがにこれはまずい、と見出しのメモを見ながらあれこれ削って、やがて70分になり、50分になり、「ここから先は同じ方法では削れないな」と判断したところで、ようやくスライドを作りはじめた。

この時点で全体の構成はほとんど頭に入っていたから、スライドの初稿は1時間もかからずできたのではなかったか。
かなりあっさり最後まで行って、びっくりした。

とはいえ、この段階では上記のとおり、見出し中心の簡素な内容だったから、枚数も少ない。たぶんその時点では20枚ちょっと。

スライドの枚数が少ないと、短時間で作れるし、修正もラクだし、1枚あたりのクオリティも上げられるから、そういう意味ではメリットが大きい。

ただし、そのぶん本番ではスライドをカンペ的に使うことができないから、当日のプレッシャーや負担が大きくなる。
これはトレードオフで、実際ぼくも発表直前まで、本番で内容を全部忘れてしまったらどうしよう? という不安がつきまとった。

スライドの言葉

初稿ができた後は、少しずつ画像を足したり、説明文を補足したりして推敲を重ねた。
これにより、スライドの枚数も、1枚あたりの文字数も増えていった。

その作業をしていて気づいたが、スライドを作りながら物を考えると、「スライドの中の言葉」で思考するようになっていく。
言い換えると、その「スライドの言葉」を使わなければ論理が進まなくなっていく。

「スライドの言葉」とは、普段ぼくらが誰かに直接話しかけるときの「言葉」とはちょっと違って、スライドの中の世界だけで鳴り響く言葉だ。
これを使い始めると、スライド上の文字は加速度的に増殖していく。

その言葉を使うこと自体は悪いことでないけれど、文字数が増えるのは良いことではない。
単純に見づらくなるし、何より前述の「スライド読み上げプレゼン」まで一直線だ。

それはまずい、ということで、そこからまた文字を削ったり、枚数を減らしたり、最大限の抵抗はしたけれど、やはり終盤のまとめに至るあたりでは、そういった説明的な言葉が優勢になってしまった感がある。

いらすとや回避

スライドに文字をなるべく載せない方策としては、DEMOやスクリーンショットを使うこともそうだが、イラストを活用することも考えた。

この点、いらすとやさんに行けば大抵のフィーリングはイラスト化されていて、これはたしかに依存しやすいというか、めちゃくちゃ便利なツールだなと思わされた。

ただ、各所でいらすとやさんのイラストを使ったものを見ていると、中にはハイコンテクストにうまく活用している事例もあるものの、あまり多用すると誰の発表なのかわからなくなるというか、そもそもいらすとやさんのイラストというのはけっこう記名性が高いように感じられるので(匿名的ではないというか)、発表を乗っとられてしまうような危惧があった。

そこで2番めの案として、自分で手書きしてみることを考えた。

具体的には、以前にきしだなおきさんのブログで見た、こちらのような感じ。
d.hatena.ne.jp

さらさらっとルーズリーフのような紙に絵を描いて、そのままポンとプレゼンしている。スゴイ。

しかしどうも簡単には真似できない。ざっと描いてみることまでは出来ても、ぼくだったらその後の推敲であーでもないこーでもないとかえって時間をかけてしまいそうで、今回はそれだけの時間はないな、と思い直して諦めた。

それでふと「あー、これしかないか」と思ったのがGitHubやSlackでもおなじみのemojiを使うことで、ためしにKeynoteに入れていったら、思いのほか効果的だった。🤗

主張しすぎることもなく、かといって地味すぎることもなく、また微妙なフィーリングもそこそこ表現できて、何より簡単に入れたり外したりできる。

おかげで、文字ばっかりの状態に比べて少し楽しげな感じになって、おそらくはそれが奏功してウケた部分もあって*1、ホッとした。

客層とテーマのマッチング

沖縄までわざわざITカンファレンスに行くような人といったら、その時点で大半がエンジニア/プログラマーだろう、とはぼくも思っていた。

にもかかわらず、ぼくの発表は「ノンプログラマーがどうやってプログラミングを役立てているか」というものだったから、客層とマッチしないのでは? という懸念があった。

普通に考えたら、そのテーマから想定される客層というのは、「これからプログラミングを始めてみたいノンプログラマー」であり、その関心はと言えば、「自分がプログラミングを導入したら普段の仕事がどれだけ捗るのか?」みたいなことだろう。

しかし一方で、ぼくの今回の発表の価値というのはそういうところだけにあったのではなく、これはプロポーザルにも書いたことだが、「大半のプログラミング技術に関する情報はプログラマーが発信しているが、ここではノンプログラマーの私がそれを発信する」という点に意味があった。

通常、プログラミングに触れるノンプログラマーは、つねに「教わる側」であり、教わる側は言葉を持たない。

「わからないな」と思ったとき、それは「わからない自分が悪いのだ」と思ってしまいがちだ。

しかし実際には、ノンプログラマーがプログラミングに触れるとき、そこではいろいろなことが起こっている。
わからないのは、「教科書が間違っているから」かもしれないし、「教え方が悪いから」かもしれないし、「カリキュラム(勉強の仕方)が合ってないから」かもしれない。

ぼくはプログラミングを始めたのが38才を過ぎてからで、今では43才になろうとしているから、まあこれは年齢のせいというよりも性格のせいかもしれないが、いずれにせよ、自分の考えを伝えるための言葉を少しは持っている。

だから、変だなと思ったら「変だ」と言うし、しょうもない成果物でも「できた!」と言うし、YAPCトークにも応募する(それも今回で2回め)。

結果的に、普段あまり人々が聞く機会のない発表が実現したわけで、これは誰が聞いても新鮮であるには違いない。

残る問題は、ぼくがそこでどれだけ「純度の高い情報」を提供できるかということで、だからその点には神経を費やした。

もしそこで、ノンプログラマーにも背景がわかるように・・と終始基礎的な話をしていたら(ターミナルの立ち上げ方とか 、Vimの初期設定の手順とか)、一緒に聞いているプログラマーには退屈な時間になってしまうだろうし、かといって専門的な話をしようとしても中途半端になるだけだろう。

だから、とことん「自分が面白いと思ってる話」だけを取り上げることにした。

枝葉的な解説は最小限にとどめ、自分自身がエキサイトするような事象を集めて、そのことだけを話そう、と。

その純度が高ければ高いほど、つまりぼく自身が「この話、面白い!」と思えれば思えるほど、発表はきちんと聞き手に届くはずだと思って、そうした。

懇親会の終わりに話したこと

入門書のジレンマ

発表が終わり、懇親会になり、その終盤、朝からつづいた雨も上がり、会場から一人また一人と夜の庭へ出ていくのが見えた。

それにつられるように、ぼくも会場からフラフラと出ていったところで、ぼくの発表を見たという人から声をかけられた。

その人は、自分もプログラマーではなく、今回スポンサーをしている会社のひとつに勤めているのだと言った。

それからしばらく、いろいろと嬉しい感想をもらいながら、上に書いた「ノンプログラマー発の技術情報であることに意味がある」みたいな話をした。

ぼくらノンプログラマーが技術情報に触れようとしたとき、それを書いているのはつねにプログラマーなのだと。

その人は、プログラマーが書いた入門書などを読んでもわからないことがあると言い、ぼくは「それは自然なことだ」と言った。

プログラマーはノンプログラマーではないがゆえに、ノンプログラマーがどこでつまづくのかをわからないのだと。

もちろん、中には例外的な人もいて、結城浩さんなどはその例にはあたらない。

結城さんはつねに、読者が「今どこにいるのか」を考えながら書いているから、相手がプログラマーであろうとノンプログラマーであろうと、読者を置いてけぼりにはしない。

逆に言えば、わかりづらい入門書とは、読者が「今どこにいるのか」を想像できていないのだ。

何であれ、情報を整理して他人に伝えるときには、膨大な、かつ茫漠とした情報の海の中から、必要と思える要素を取捨選択しなければならず、それはつまり不要な部分を省略しなければならないということだ。

わかりづらい入門書というのは、そのとき、省略してはいけない部分を省略してしまっている。

ビルの上の階まで上がろうというとき、適切な高さの階段が均等に積まれていれば誰でも上がっていけるが、所々に異様に高い段差があったら、上がれない人が出てくる。

入門書を書くような人というのは、すでに専門家として何年もキャリアを積んでいる人だから、「どの階段を省略したら入門者がついてこれなくなるのか」を想像しながら書いていくのが難しいのかもしれない。

だからこそ、自分のようなノンプログラマーが技術情報を発信することには何らかの価値があるだろうと思うし、そのときもたぶんそういう話をした。

プログラマーとノンプログラマーを分けるもの

そのときに話したことをもう一つ書いておくと、これは本来、今回の発表にも入れたいと思っていたのだけど、とても時間が足りなくてカットしたもので、「プログラマーとノンプログラマーの違いは何か?」という話。

また喩え話になるが、ノンプログラマーによるプログラミングが「趣味の魚釣り」だとしたら、プログラマーによるプログラミングは「漁業」である。

趣味の魚釣りと漁業との違いは、「誰のために魚を獲るのか?」ということで、言い換えれば、「獲った魚を食べるのは誰か?」ということだ。

漁師は自分たちの食べ物を確保するために漁をしているのではなく、不特定多数の他人が食べる魚を獲っている。

一方で、趣味の釣り人は自分が楽しむために魚を釣っている。

どちらが偉いわけでもないが、他人の口に入るものを扱う以上、責任は漁師の方が遥かに重い。
それゆえ、面倒なこともたくさんしなければならないし、多くの技術を身につける必要もある。

どれだけ多くの魚を獲れるかという意味で、趣味の釣り人が漁師に勝てる日は来ない。やっていることのケタが違うのだ。

くり返すが、これはべつにプログラマーがノンプログラマーより偉いという話ではない。

視点を変えて、たとえばぼくは今編集を生業にしているけれど、その分野で言ったらぼくの方が漁師ということになる。

だから考えるべきは、趣味の釣り人が魚を釣るように、ノンプログラマーのぼくがプログラミングをかじったところでそれが何になるのか? ということだ。

その答えはある。

ぼくにとってのプログラミングはどこまでも趣味に過ぎず、その技術が毎日大量のトラフィックを重い責任のもとにさばいているプログラマーのそれを超える日は永遠に来ないが、それでもプログラミングを通してぼくの本業の生産性が高まったら、それはめぐりめぐって、プログラマーを含む社会への貢献を果たすことになるだろう。

何もプログラミングの世界で職業プログラマーに勝つ必要などなく、自分の生産性を上げたり、あるいは自分の人生を豊かにしたりできれば、それだけでも充分意味のあることなのだ。

ジェロニモと私

最後にもうひとつ、これを書いてこの記事を終わるが、その会話の最後の方で、「結局、ノンプログラマーがプログラミングを習得する方法としては、やっぱり仕事に取り込むっていうのが効果的なのでしょうか?」みたいな質問をもらって、それについてあらためて考えられたのもよかった。

ぼく自身がなぜプログラミングを続けてこれたのかと考えたら、それは「仕事に役立つから」というより、プログラマーの人たちがいつもなんだか楽しそうで、「あんな風になりたいな〜・・」と思ったからだった。

これは以前、吉祥寺.pmというイベントで発表したとき、そのスライドに入れるつもりだったものの結局時間がなくて削った話なのだけど、『キン肉マン』という漫画に出てくるジェロニモというキャラクターがいて、彼は本当は人間なんだけど、超人のテリーマンたちに憧れて正義超人の仲間に入って、しかしその後悪魔超人たちと闘ってメタメタにやられてしまう。

そこで出てくる名ゼリフに、「だってオラは人間だから」というのがあって、ノンプログラマーでプログラミングなんてやってると、そんなのばっかり。

プログラマーと自分とではまったくいる場所が違うというか、素地が違うというか、土台が違いすぎるので相手にならない。ツライ。

だけど、大事なのは勝つとか負けるとか、誇らしいとかみっともないとかではなくて、そのジェロニモテリーマンとかキン肉マンとかに対して抱いたような「憧れ」があるかどうかなのだと思う。

プログラミングをやる理由が「仕事に役立つ!」というだけだとちょっと弱くて、それだけだと「だって人間だから・・」みたいな感じでつぶれちゃう。くじけてしまう。そんな気がする。

だけどそこに、「憧れ」が残っていたら続けられる。というか勝手に続いていく。

それはべつに特定の誰かに対するものでなくても、ぼくだったらテクノロジーを味方につけることで稀に体験する、「それまで100日かかっていた作業が5分で終わった」みたいな劇的な変化への憧れというか、希求がいつもある。

ぼく自身が経験的に責任をもって言えるのはそこまでなんだけど・・と、そういう話をした。

その他のトピック

上記の機会では、相手の方からのコメントが本当にどれもクリエイティブ&丁寧なものだったので、普段考えていることをどんどん話すことができて、他にもたくさん面白い会話をしたのだけど、ひとまずここまで。

YAPC::Okinawaについては、前夜祭やイベント翌日のハッカソン、その後のお土産屋めぐりや、そもそものプロポーザルに至る話など、まだまだトピックはあるのだけど、その辺はまた時間ができたら、続編として書いてみたい。

*1:P19.「Finderは疲れる」というあたりなど。

tigの車輪の再発明

複数ファイルが立ち並ぶディレクトリにおいて、1つまたはいくつかの限られたファイルだけを`git add`したいという場合、いちいちそのファイル名を打ち込んでいくのがメンドイ。

https://i.gyazo.com/2ea3f4f42a20f00f66837cef4191a00e.gif

こういう時、peco的なものでバッとリストを出して、インクリメントに対象を絞り込みつつ直感的に選択できないものか? と思っていた。

で、こういうのを作った。(コマンドは`ga`)

https://i.gyazo.com/b41528b638db51e86643b50d41c2f6c1.gif

Perl製。
とくにリポジトリを公開したりしていないので、生コードはこんな感じで。
(.bashrcと組み合わせる)

# .bashrc
function gi {
    local arg="$@"
    local pick=$(perl /path/to/gi.pl)  #パスは任意の場所で

    if [ -z "$pick" ]; then
        echo Canceled.
    elif [ -z "$arg" ]; then
        echo Input a command.
    elif [ ! -z "$pick" ]; then
        git $arg $pick
        if [[ "$arg" == add ]]; then
            echo Add $pick
        fi
    fi
}
alias ga="gi add"
alias gr="gi reset HEAD"
#!/usr/bin/env perl
#
# gi.pl
use strict;
use warnings;
use feature 'say';

my $status = `git status`;
my @msg = split /\n/, $status;

my $msg;
my %msg;
my $marker = '';

for (@msg) {
    if ($_ =~ /\AChanges to be committed:/) {
        $marker = 'staged';
    }
    elsif ($_ =~ /\AChanges not staged for commit:/) {
        $marker = 'not staged';
    }
    elsif ($_ =~ /\AUntracked files:/) {
        $marker = 'untracked';
    }

    if ($_ =~ /\A\t(.+)\z/) {
        $msg = $1;
        if ($marker eq 'staged') {
            if ($msg =~ /\A(.+):\s+(.+)\z/) {
                $msg{$2} = 'staged';
            }
        }
        elsif ($marker eq 'not staged') {
            if ($msg =~ /\A(.+):\s+(.+)\z/) {
                $msg{$2} = $1;
            }
        }
        elsif ($marker eq 'untracked') {
            if ($msg =~ /(.+)\z/) {
                $msg{$1} = 'untracked';
            }
        }
    }
}

my @result = ();

while (1) {
    my @list = ();
    my $list = '';

    for (sort keys %msg) {
        push @list, "$msg{$_}:\t$_";
    }
    $list = join "\n", 'OK', @list;

    my $selected_line = `echo "$list" | peco`;
    chomp $selected_line;

    my $selected_status;
    my $selected_file = '';

    if ($selected_line =~ /\* (.+):\t(.+)\z/) {
        $selected_status = $1;
        $selected_file = $2;
        shift @result;
    }
    elsif ($selected_line =~ /(.+):\t(.+)\z/) {
        $selected_status = '* '.$1;
        $selected_file = $2;
        push @result, $selected_file;
    }
    delete $msg{$selected_file};
    $msg{$selected_file} = $selected_status;

    if ($selected_line =~ /\A(OK|)\z/) {
        if ($selected_line eq '' || ($selected_line eq 'OK' && scalar(@result) == 0)) {
            @result = ();
        }
        last;
    }
}

print "@result";

`gi`の後に何らかのgitコマンドを入れれば、選択したファイルに対してそれをする。

ここでは事前にエイリアスを設定して、`ga`と打てば`git add`、`gr`と打てば`git reset HEAD`になるようにしている。

何度も試しながら、結局半日ぐらいかかった気がするが、ひとまず「ん〜、いいじゃん、こういうのが欲しかったのだよ」と満足できる感じにはなった。

が、そこまで来てからふと、「しかし普通のプログラマーたちが毎日そんなメンドイことをしてるはずがないな……皆どうしてるんだろう?」と思った。
まあIDEや各種エディタ、あるいはGUIツールを使っている人なども少なくはないだろうけど、ターミナル操作で済ませている人も多いだろうしなあ、と。

そこでようやく、時々耳にするtigというツールを使えば似たようなことが出来るかも? と思い至り、簡単に調べてみた。

qiita.com

上記でほぼ把握。自分の手元でもやってみた。

https://i.gyazo.com/0d10e3b193ff13468148dca7ca2da9a9.gif

最初に`tig`と打つと、`git log --oneline`的な画面が出てきて、そこで`S`(Shift+s)を打つと`git status`の情報が出てくる。

そこでjk(上下)移動しつつ目当てのファイルの上で`u`を押すと、さくさくステージ/アンステージしてくれる。
めっちゃお手軽!

Vimとほぼ同じ動かし方なので、直感的に使える。
pecoのようなインクリメントな絞り込みはできないけど、必要十分とは言えるだろう。

何より、上記ではaddだけやっているけど、このtigにはその他のgit系機能も盛りだくさんである。
先ほど`git blame`を試してみたけど、これもけっこう目覚ましい体験だった。

これがあるとわかっていれば、わざわざ冒頭のようなコードも書かなかったなあ……と一瞬思ったが、でもどうだろう。

初めからtigを使っていたら、tigの「使い方」には詳しくなったかもしれないけど、コードを書く技術は上がらなかっただろう。

ぼくが望むのは確かに「直感的に`git add`すること」だったけど、同時に「コードをより上手に書けること」も求めていて、言い換えると、ぼくが最終的に求めているのは道具の「使い方」ではなくて「作り方」を知ることなのだと思える。

最新のガジェットやそれらを「使いこなす」ことにあまり興味を持てないのもそのことと関係している気がする。

さらに突き詰めて考えるなら、ぼくが欲してるのは「自由」なのだとも思う。

最新のガジェットに興味がないとは書いたが、そうは言ってもiPhoneが初めて日本で発売されたとき(2008年の6月とかだった)、ぼくはまだソフトバンクで機種変更してから半年ぐらいしか経っていなかったけど、迷わずiPhoneを予約してすぐ交換した。

じゃあなんだ、新しいガジェットに興味あるじゃないか、とも言えるが、それを買ったのは「絶対的に未知の体験を死ぬ前に味わっておかなくてはならない」と思ったからで、それは「現在という束縛からの逃避・逸脱・自由」を求めてのことだったと思える。

他人が作った道具を使うというのは、結局どこまで行っても作り手の想定の範疇から抜け出せない行為のように感じられて、あまり強い欲求が生じないのかもしれない。

たとえば作り手がその大元のルールを変えてしまったら、せっかく覚えた使い方も無効になってしまう。その不自由さがいやなのだ。

それよりは、シンプルで小さな道具を自分なりに組み合わせて、他の誰も使わないかもしれないが自分に最適化された、自分にとって最高の道具を作り、それまでの人生で味わったことのない体験をしたい、という気持ちがある。

プログラミングにはそういう欲求を駆り立てるものがあるようで、「作ること」と「それを使って体験すること」とのバランスが絶妙に感じられる。

[PR] YAPC::Okinawa で発表します

その話と直接の関係はありませんが&次にいつブログ書けるかわからないのでこのまま書いてしまいますが、3/3に沖縄で開催されるYAPC::Okinawa 2018 ONNASON で登壇することになりました。

yapcjapan.org
http://yapcjapan.org/2018okinawa/talks.html#/detail/10

チケットは完売とのことですが(おめでとうございます!>各位)現地に行かれる皆さんにおきましては、ご興味ありましたらぜひお越しください!

ノンプログラマーのためのPerl 〜 forと正規表現を使ったお得なセット

こんにちは。こちらはPerl入学式アドベントカレンダーの20日目の記事です。
(おっと日付が……🙇)

qiita.com

はじめに

あらためまして、まずここで「Perl入学式」について簡単に説明しておきますと、Perl入学式とは、Perlまたはプログラミング自体の未経験者に、Perlを通してプログラミングの基礎をお教えしましょう、という無料のプログラミング講座です。
www.perl-entrance.org

ぼくも2013年の8月、同年度第3回の補講から、まったく素人の状態で生徒として参加しまして、
Perl入学式#3補講に行ってきた - 103

その翌年春からはサポーター(運営側)に加わっています。

……といっても最近は地理的な問題などもあり、リモート参加が大半なのですが。
継続的に現場で開講しているメンバーの皆さんには、本当に敬服するばかりです。

さて本日は、ぼくのようなノンプログラマー、つまり普段の仕事ではプログラミングとは関係のないことをしている人*1が、プログラミング言語Perlを学ぶことによって、どんな便利なことになるのか、みたいな話をします。

といっても、その便利さをすべて説明しようとしたら大変な時間と文章量が必要になりますので、今回はその中でもとくに「これは」というところに絞って説明します。

for文

多くの場合、ぼくが普段の仕事をしているときに、「んー、こりゃプログラミングの力を借りた方がよさそうだな!」と思うのは、

テキストファイルAの内容に何らかの処理を加えて、テキストファイルBとして保存する

みたいなことをやりたい時です。

具体例を挙げてみると、たとえば以下のような名簿があったとして、

ジョン・レノン
ポール・マッカートニー
ジョージ・ハリスン
リンゴ・スター

このすべての文末に敬称「さん」を付けたい、という場合。

いやもちろん、このぐらいなら自分で書けばいいんですが、これが何百人もいたら大変なので……ということ。

こんなとき、ぼくだったらこんなコードを書きます。

#!/usr/bin/env perl
use strict;
use warnings;

my @band = qw/
ジョン・レノン
ポール・マッカートニー
ジョージ・ハリスン
リンゴ・スター
/;

for my $member (@band) {
    print "$memberさん\n";
}

まず配列 @band に4人の名前を入れて、これをforループで回しつつ、出力時に「さん」を加えています。

実行してみると……
gyazo.com

はい、できました。for文、めっちゃ便利ですね。

このfor文については、Perl入学式の講義資料より以下をご参照ください。
https://github.com/perl-entrance-org/workshop-2017/blob/master/2nd/slide.md#for文-配列

qwについては以下をどうぞ。
https://github.com/perl-entrance-org/workshop-2017/blob/master/2nd/slide.md#qw-ショートカット

if文、正規表現

さてしかし、現実の世界では、このように元のデータすべてに同じ処理をするという機会はそうそうなくて、この内の「ある条件に合致するもの」だけに処理を加えたい、ということが多いです。

たとえば、この中で名前の最後に「ン」が付く人だけ敬称を「様」にしたい、という場合にはどうすればいいでしょうか?

そのような時には、こう書きます。

#!/usr/bin/env perl
use strict;
use warnings;

my @band = qw/
ジョン・レノン
ポール・マッカートニー
ジョージ・ハリスン
リンゴ・スター
/;

for my $member (@band) {
    if ($member =~ /\z/) {
        print "$member\n";
    }
    else {
        print "$memberさん\n";
    }
}

実行。
gyazo.com

はい、できました。

このif文と、それに付いてくる正規表現(「=~」とか「//」を使って色々やっているもの)については、同じくPerl入学式の講義資料から以下をご参照ください。

if文
https://github.com/perl-entrance-org/workshop-2017/blob/master/2nd/slide.md#if-else文

正規表現
https://github.com/perl-entrance-org/workshop-2017/blob/master/4th/slide.md#正規表現

__DATA__

さてここで、一旦冒頭の話に戻りますが、普段の仕事(プログラミングとは関係ないそれ)をしていて、時々欲しくなるのは、

テキストファイルAの内容に何らかの処理を加えて、テキストファイルBとして保存する

という能力です。

上の例でいうと、テキストファイルAにあたるのは

ジョン・レノン
ポール・マッカートニー
ジョージ・ハリスン
リンゴ・スター

で、処理後のテキストファイルBにあたるのは

ジョン・レノン
ポール・マッカートニーさん
ジョージ・ハリスン
リンゴ・スターさん

になります。

ただ、さすがにこんな風に、処理したいデータ(ここではその4名)を毎回コードの中に埋め込むというのは面倒というか、できればコードはコード、素材データは素材データとして分けて扱いたいので、上記に加えてぼくが多用するのが「__DATA__」という記法*2です。

さっそく、それを使って書き換えてみましょう。

#!/usr/bin/env perl
use strict;
use warnings;

my @band = <DATA>;

for my $member (@band) {
    chomp $member;
    if ($member =~ /\z/) {
        print "$member\n";
    }
    else {
        print "$memberさん\n";
    }
}

__DATA__
ジョン・レノン
ポール・マッカートニー
ジョージ・ハリスン
リンゴ・スター

はい。だいぶスッキリしました。
結果は先ほどと同じですが、一応実行してみましょう。
gyazo.com

いいですね。
こうすることによって、対象のデータがいくら変わっても、それは「__DATA__」より下の部分で書き換えればよくなり、それより上のコード部分を触る必要がなくなります。

また、この方法だと1本のスクリプトファイルで完結するので、コードもデータもそれぞれ手軽に書き換えられて便利です。

じつのところ、ぼくが普段の仕事に関連して書くコードの大半は、これのバリエーションです。

たとえば、少し前に、別のアドベントカレンダーでこんな記事を書いたのですが、
note103.hateblo.jp

この後半で紹介している、本の脚注データを分析するコードにしても、途中でハッシュを使ったりはしていますが、基本形は上記と同じであることがわかるかと思います。

実際には、もう少し踏み込んだことをしようとすると、コードとは別に置かれた素材ファイルを読み込んだり、結果を別のファイルに書き出したり、あるいは任意のディレクトリにあるファイルを読み込んだりもしたくなってくるのですが、まずは上記のようなことができるだけでも、かなりいろんな作業が効率化するので、入門者の方は試しにこれらのセット(for + if + 正規表現 + __DATA__)を自分の環境で動かしてみてはいかがでしょうか?

ちなみに、環境構築を含む第1回からの講義資料は、以下にまとまっています。
講義資料 - Perl入学式 | Perl Entrance

ということで、本日の記事は、以上です。

明日の……ではなくて、本日のご担当はgomaaaさんです!

Perl入学式のアドベントカレンダー、ひき続き、お楽しみに。
qiita.com

*1:ぼく自身は本の編集をしています。より詳しくはこちらをどうぞ。→ note103 - note103 - Scrapbox

*2:『初めてのPerl(第6版)』によると、厳密には「ファイルハンドル」と呼ばれるようです。ファイルハンドルとは、Perlの処理世界と外部世界(おそらく素材のテキストデータなど)を結びつけるコネクションの名前、とのこと。詳しくは同書をどうぞ。

初めてのPerl 第6版

初めてのPerl 第6版

編集とプログラミングと私

こんにちは。こちらは「編集とライティングにまつわるアレコレ」アドベントカレンダーの2日目の記事です。

adventar.org

昨日は本企画の発案&主宰の id:mohri さんによる以下の記事でした。

mohritaroh.hateblo.jp

GitHub Desktop、なかなか良さそうですね。

こういったGUIツールは何となく使い方を覚えるまでが面倒。という先入観があって触ってなかったですが、思っていたより直感的に使えそうなので一度試してみようかな〜と思いました。

あと、GitHubありきではなくてローカルファイルの版管理ツールとして使ってみるという視点も新鮮でした。

私にとっての「編集」

さて、今回の大テーマは「編集とライティング」ということですが、ライティングはともかく「編集」というのはけっこう大ざっぱというか、幅の広い概念ですよね。

たとえばぼく自身が抱く印象としては、「編集」と言ったら「翻訳」に近いというか、左っかわのテーブルに置いてある「素材」を目の前で何やらこねくり返して、右っかわのテーブルに「仕上がり」としてポンと置いていく、変換していく、みたいな作業を思い浮かべます。

これは文字校正とか、文章全体の構成を組み換えるとか、あるいは文字起こしなんかも近いでしょうか。
(文字起こしは音から文字への変換なので)

しかし一方で、メディアの編集といったら企画とか営業みたいな側面もありえるでしょうし、取材なんていうのもけっこう独自のメソッドというか、世界観がありそうです。

ぼくの場合、対談や座談会をテキスト化するために現場に立ち会う、みたいなことは時々あるものの、やはりどちらかというと前者の翻訳的なこと、仕事場にこもってモノが仕上がるまで出てこない。みたいな作業が多くて、後者の、いわばゼロからイチを立ち上げていくような作業にはあまり馴染みがないので、ここでは馴染みのある前者の方を念頭に置いて書いていきます。

(ここまで前置きでした)

この記事のテーマは……

さて、今回のアドベントカレンダー、当初はこんなに速攻で埋まるとは思っていなくて、きっと一人で何個か書くだろうと勝手に思っていたので、だったら最初はVimの小ネタをサクッと書いて、あとは空き状況によって書けるものを書くか〜、とか思っていたのでしたが、あっという間に全席埋まりましたね。 😅

よって方針を変えまして、この記事ではVimを中心としつつもプログラミング全般みたいなことを視野に入れ、最終的には上の方で書いた、ぼくにとっての編集作業みたいなことをぼんやり醸していけたらいいかと思っております。

これに際して、じつは最初に「編集(やライティング)のアドベントカレンダー」と聞いて、んー、まあネタとしてはこの辺か? と思ったのがあるので、とりあえず見出しだけ列記してみますと、こんな感じで。

1. 便利なショートカットあれこれ
2. 便利なExcel関数あれこれ
3. 私のメール術
4. Vimでどんなことをしてるのか
5. シェル(bash)でどんなことをしてるのか
6. Perlでどんなことをしてるのか

まあ、これで6日は消費できるかな、とか思っていましたが、上記のとおりもうそんな席は残っていませんし、かといってこれを全部1本の記事に詰め込んでいたら書くのも読むのも大変なことになりますから、今回の記事ではその中から4番目のVimと6番目のPerlについて、要点をつまみつつ書いてみます。

ちなみに、そんな経緯でこの後は、しばらくプログラミングにまつわる話が続きますが、実際には上にもあるように「私なりのメールの書き方」とかもネタに入れていたぐらいなので、今後に続けて書かれる方におきましてはこういう技術ネタに縛られず、好きなことを書いてほしいと思っています。

(まだ前置きでした)

Vimでサクッと書き換える

さて、もう何度も書いてるのに今さらですが、こちらをお読みの皆様は「Vim(ビム)」ってご存じでしょうか?

いや、ぼくも他人に語れるほど知ってるわけではないですが、えーと入門的には、やはりドットインストールあたりが親切でしょうか。

https://dotinstall.com/lessons/basic_vim

ちなみにぼく自身がVimに触れはじめたのは、以下の記事の頃でした。2013年。

ここ数日のvim - 103

ようはテキストエディタでありまして、ぼくで言ったらVimの前にはCotEditorというのを使っていましたが、

coteditor.com

まあMacだったらテキストエディットというのもデフォルトでありますし、そういうメモ帳的なものですね。

ただ、このVimというのは単なるメモ帳にはまったくとどまらず、文字を打ち込む以上のことがあれこれできてしまいます。

具体的には、たとえば上に書いたこれ、今回のためのネタ帳ですが。(再掲)

1. 便利なショートカットあれこれ
2. 便利なExcel関数あれこれ
3. 私のメール術
4. Vimでどんなことをしてるのか
5. シェル(bash)でどんなことをしてるのか
6. Perlでどんなことをしてるのか

この行頭のナンバリングに続く「ドット」の部分を、「閉じ丸括弧」に変えたい! というときにどうするか。

まあ、このぐらいの行数だったら手動でポチポチ書き換えてもいいわけですが、これが100行も200行もあったらどうでしょうか。けっこうキビシイですね。

もちろん(というか)、上記のCotEditorをはじめ、エディタに付属している検索&置換機能を使う手もあるわけですが、とりあえずVimだったらこうします。

gyazo.com

はい。その変えたいところ(ドット)を直接さわるようにして、一列分フイッと変えてしまいました。

べりー、便利!

これがもし、検索&置換用のウィンドウにわざわざ入れていくと、こんな感じになると思うのですが。(Googleドキュメントを使ってみます)

gyazo.com

たしかに、これもわかりやすいんですが、でも「今ある状況」と「求める結果」との間にその置換用ウィンドウが挟まってしまって、ちょっと直感的ではありません。

しかし、Vimならば上のとおり、あたかも直接自分の手で対象をさわっているかのように、書き換えていくことができるのです!

(……)

大丈夫でしょうか。大丈夫ですね。

Vimで知りたい情報をカウントする

さらには、Vimを使えばもっと面倒な作業だって簡単にできてしまいます。

例として、こんな素材を持ち出してきましたが。

f:id:note103:20171201023132p:plain

これはぼくが今メインでやっている仕事の「commmons: schola(コモンズ・スコラ)」という、坂本龍一さんがかれこれ10年近く続けているライフワーク的音楽全集で使っている脚注のデータですが。

commmons scholaについて | commmons:schola(コモンズスコラ)-坂本龍一監修による音楽の百科事典- | commmons

このシリーズ、CDブックの形態ですでに第16巻まで刊行していまして、いま第17巻を絶賛制作中なのですが(ピークです)、それゆえ脚注も16巻分のデータが溜まっていまして、上記はそれをスプレッドシートで管理している画面の一部です。

で、その左端の方、A列に数字が並んでいますが、それが巻のナンバーで、B列にある見出し語句が第何巻に掲載されたか、ということをA列から読み取れるようになっています。*1

では、この全データ(2008行ありました)のうち、第6巻の脚注は何個あったんだろう? というときにどうするか。

まあ、そのスプレッドシートの機能をちょこちょこ使えばカウントできるかもしれないですが(知らないのですが)、Vimを使うなら、こうします。

1. まず内容をVimに全コピペして
2. コマンドラインモード(というのがあります)で以下を打ち込む

:%s/\v^6\t//gn

と、このように出てきます。(一番下の方を見ておいてください)

gyazo.com

はい。104個ありました。

Perlで知りたい情報をカウントする

しかしそうなると、6巻だけじゃなくて、他の巻の注釈個数も全部一気に知りたい、という欲も出てきます。

果たして、そういう場合にはどうすればいいでしょうか?

前述のとおり、このシリーズはすでに16巻出ていますから、同じことを地道に16巻分(厳密にはあと15回)繰り返すべきでしょうか?

もちろん、そうするのも自由ですが、思い出してください。我々にはPerlがあるのでした!

(……)

はい。結論から言いますと、じつはつい数日前に、実際にその情報を知りたくてそのためのコードを書いたからここでネタにしているのですが、そのときにはこういうものを書きました。

#!/usr/bin/env perl
use strict;
use warnings;

my @array = <DATA>;

my $num;
my %count;

for (@array) {
    chomp $_;
    if ($_ =~ /\A(\d+)\t/) {
        $num = $1;
        if ($num == 16) { $count{$num}++; }
        elsif ($num == 15) { $count{$num}++; }
        elsif ($num == 14) { $count{$num}++; }
        elsif ($num == 13) { $count{$num}++; }
        elsif ($num == 12) { $count{$num}++; }
        elsif ($num == 11) { $count{$num}++; }
        elsif ($num == 10) { $count{$num}++; }
        elsif ($num == 9) { $count{$num}++; }
        elsif ($num == 8) { $count{$num}++; }
        elsif ($num == 7) { $count{$num}++; }
        elsif ($num == 6) { $count{$num}++; }
        elsif ($num == 5) { $count{$num}++; }
        elsif ($num == 4) { $count{$num}++; }
        elsif ($num == 3) { $count{$num}++; }
        elsif ($num == 2) { $count{$num}++; }
        elsif ($num == 1) { $count{$num}++; }
    }
}

use DDP {deparse => 1};
p %count;

__DATA__

冗長!

……ともあれ、詳細は割愛しますが、この最後の「__DATA__」と書かれた下に件のリストをまた全コピペして、実行するとこんな風に出てきます。
(画面の下半分を見ておいてください)

gyazo.com

ヒュー! 一発で出てきましたね。
6巻もちゃんと104個になっています。

(8巻多すぎ……)

まとめ

いかがでしょうか?

本記事はVimPerlの入門を目的としたものではなく、いち編集者であるぼくが、普段どんなふうに自分なりの作業をしているのか、ということを紹介するものだったので、いろいろな細かい手順や前提を驚異的なまでに省略してしまいましたが、こうしてプログラミングを絡めると、日々の地味〜な作業も飛躍的に効率化され、なおかつ目覚ましいほどのクリエイティヴィティを味わえる! みたいなノリが少しでも伝わりましたら幸いです。

ちなみに、ぼくがVimにのめり込むきっかけになった話や、Perlをはじめとするプログラミング入門についてなどは以下にもちらちら書いていますので、ご興味のある方はぜひどうぞ。

ということで、本日の記事は以上です。

最後までお読み頂き、ありがとうございました!

明日のアドベントカレンダーのご担当は id:minesweeper96 さんです。
お楽しみに!!

adventar.org

*1:同じ語句でも巻によって内容が違うので、「エディ・コクラン」なんかは複数記載されています。