builderscon 2019に行ってきた(2)〜本編初日〜

シリーズ続編です。前回の内容はこちらをどうぞ。

note103.hateblo.jp

builderscon 2019のサイトはこちら。

builderscon.io

では順に。

朝のランチ券

本編初日の最初のミッションはランチ券をゲットすることでした。

blog.builderscon.io

例年だと、お昼の企画として「ランチセッション」というものがあって、昼休憩になると同時にその会場の前に行列ができ、並んだ順に弁当が配られて、受け取れた人だけがその弁当を食べながらスポンサー企業のトークを聞く・・みたいな感じだったんだけど、この方式だと、1つ前のトークが早く終わるほど有利というか、行列に並び遅れたらもう弁当を受け取れないので、ほとんど運というか賭けというか・・。

それで思い出してみると、ぼくは去年のビルコンではたしか2日ともこの弁当行列に並んで、しかしどちらも受け取れなかったんですよね。😭

なので、この「朝早く行った人ほど弁当をゲットしやすい」というのは非常にありがたくて、これなら弁当が欲しい人は朝に頑張れば確実にゲットできるし、昼前のトークが多少長引いてもソワソワせずに最後まで話を聞けるし、結果的に朝のトークも漏れなく聞けるしでメリットが多く、素晴らしい企画だと思いました。考えてくれた人、実現してくれた人、ありがとうございました。

で、ぼく自身はこの日はイタトマのスパゲティ券を頂きました。というのも、ランチセッションはこれまでにもすでに何度か体験していて、「こういう感じ」というのがわかっていたので、ちょっと違う体験をしたいなと。

10時になると同時に開場して、このタイミングで目論見通りイタトマランチ券をゲット。すると、最初に入ったスペースに朝食・コーヒーコーナーが・・。

f:id:note103:20190830100200j:plain
突然の朝食コーナー。コーヒーはこの左手

なんとスピーカーディナーで食事を提供したチームによる朝食があったのでした。

コーヒーはこちらの方々。(当日聞きそびれたので後日のTwitterより)

久しぶりにちゃんとしたコーヒー飲んだな・・という感じでした。ありがとうございました。

ちなみに1点、これは今回の不備ということではなく、今後に向けた小さな提言という感じですが、この日は最初のセッションが10:50からのオープニングトークだったのでまだ余裕があってよかったのですが、翌日は最初のトークが10時半からで、「10時から朝食コーナーに行って軽く食べてから10時半のトーク」っていう流れはちょっとせわしない感じだったので、教室のオープンよりも少しだけ朝食会場のオープンが早くなっていると、よりゆっくり楽しめるかなと思いました。

*もちろん、そんなことをすればそれだけスタッフさんが早くスタンバイする必要があって大変なわけですが、素朴な実感までに。

午前トーク

そして10時50分、主宰の牧さんによるオープニング。

f:id:note103:20190830105003j:plain

今回はこの写真にあるように、画面右上にスピーカー、右下にタイトルやハッシュタグ等の情報が常時出ている感じで、非常に良かったですね。とくに、右下の諸情報はトークの途中でも知りたくなることが結構あるので、便利でした。

その後、本編最初に見たトークはこちら。

builderscon.io

こちらはスピーカーディナーのときに見て、わー面白そうだな、と思ったので行きましたが、実際かなり面白かったです。

各種の事例を通して「ゲーム」の本質に迫りつつ、その分析を通してまた新たな謎や魅力に出会う、といった感じでしょうか。

最後の質問コーナーでは、簡単な質問をしました(内容は割愛)。初日の最初の発表だったので、なかなか手が挙がりづらいかな・・と。

質問するのって緊張するし、聞いてるときのモードから質問モードに切り替える必要があるので、避けられれば避けたいところですが、効果が見込まれるときにはそれなりに頑張ります。経験的には、スピーカーと近い場所(前列の方とか)にいるとやりやすいですね。あとは、よく緊張するときには人をカボチャと思えみたいに言いますが、ぼくの場合はその会場を自分とその人しかいない親密な空間だと思い込んだりします。

話を戻して、スピーカーの@qsonaさんはnoteで各種記事を書かれていて、builderscon関連だと以下がありました。のちほど見ておきたいと思います。

note.mu

ランチ

前述のイタトマに行きました。パスタは「何を選んでもいい」と言われたのでけっこう迷いましたが、定番っぽいトマトソースとモッツアレラチーズにしました。

f:id:note103:20190830130250j:plain

それなりに量はあるんですが、思ったほどヘビーではなく、サクッと頂きました。

店内には地元の方と思われる多彩な層がいて、でも席が空くのを待ったりする必要もなく、チケット数もちょうどよかったのかな、という感じでした。

午後トーク(1)

午後の最初はこちらを見ました。

builderscon.io

Mathematicaってまったく知らなかったので、雰囲気的に数学の話がメインになるかなと勝手に思っていましたが、思いのほかオブジェクト指向の話が多く出てきて、オブジェクト指向についてはPerlRubyの学習に際してそれなりに時間を割いて触れてきたので、案外理解のきっかけが多い内容でした。

語り口にも推進力があって、動くサンプルが多く用意されていたのも良かったですね。飽きる間もなくあっという間に終わりました。

その後は、同室でこちら。

builderscon.io

「形式手法」とは今回のbuildersconで初めて触れたキーワードでしたが、自分には全然関係なさそうでありながら、なぜか関係ありそう、興味をひかれるなあ・・と思って聞くことにしました。

果たして、内容的には想像以上にわかりやすいというか、出てくるコードは馴染みがないものが多かったですが、構文はそんなに複雑ではなく、かつ1つずつ丁寧に解説してくれたのでけっこう追いついて聞くことができました。

話の筋というか展開も共感・納得感が強いもので、なぜそういうことをするのか、とか、それに対してどういう事を考えて、今後どう展開していこうと思っているのか、みたいなところまで「なるほど」って感じで聞けました。(とくに前半の方)

その後は会場を移動して、こちらへ。

builderscon.io

大会場で60分、ひたすらRailsを中心に話していく感じでしたが、こちらもあっという間という感じでした。

具体的な内容については、知らない要素も多くてコレと言える核心を掴めていませんが、手元のノートにけっこう真面目にメモも取っているので、追って見返しながら勉強したいと思います。

一応、『マルチパラダイムデザイン』による以下。

問題に対して解決となるような構造を与える

これだけは覚えました(笑)。

スライドはこちらです。

speakerdeck.com

休憩部屋

その後のコマはお休み。ずっとトークだけ見ていると、他の人と喋ったり体を休めたりするヒマがなくなるので・・。

ということで、2階に用意された休憩室へ。この部屋はサイボウズさんプレゼンツで、今まで勝手に存じ上げていた同社の風穴さんとようやくご挨拶。

*風穴さんによる当日のツイート。

技術系ジャーナリストとして名高い方ですが、お話しできてよかったです。技術書典、行ったことないと言ったら行ったほうがいいと言われましたので(ただし午後)、行ってみるか・・と考え中です。

techbookfest.org

午後トーク(2)

午後、というかこの日の最後に聞いたのはこちら。

builderscon.io

一冊の本を読み切ったような重厚な発表でした。質疑応答も面白かったです。

なんというか、ある意味では泥臭いんだけど、でもこういうのが結局一番強い、というかそうであってほしい、みたいな感想を持ちました。手本になる本をしっかり読んで、そのエッセンスをつど参照しながら、自分たちの課題に向けてトライ&エラーを重ねていく、という姿勢。

言葉にしてみれば「そりゃそうでしょ」という感じなんだけど、実際に一つひとつそれをやっていくのって本当に胆力が必要というか。
ここで取り上げられている「Kyash Direct」は法人向けのサービスなんだけど、ぼくは個人向けの「Kyash」の方をけっこうヘビーユーズしているので、それとの関連なども想像しながら楽しみました。

ちなみに、これは次の記事に書きますが、翌日最初に聞いたのがクレジットカードのプロトコルの話だったので、図らずもこういった決済を扱う系のサービスの裏側を想像しやすくなって、その辺も想定外でまさにbuildersconのテーマ「知らなかった、を知る」だなあという感じです。

ああ、あともう1個。この発表は基本的に、スライドに書かれている文を読みながら、順に説明していく感じで、ぼくは普段はこういうプレゼンって「スライド上の文言」と「実際に話す言葉」がずれているほど面白いって考えるタイプなんですが、この発表はスライド内容もすごく作り込まれていて、かつ情報量がめちゃ多いので、この読み上げスタイルの方が合ってたかな、という印象を持ちました。一概に、読み上げは駄目、とは言えないなと。この辺の考え方は更新されました。

WEB+DB PRESS』編集長と感想戦

本編終了から懇親会までの空き時間、『WEB+DB PRESS』編集長の稲尾さんと遭遇しまして、しばらく先日の寄稿について感想を述べ合ったりしました。

note103.hateblo.jp

あそこまでやる人、普通いないっす。みたいな話になって、「(やっぱり・・)」と :sweat_smile:。それで余計に思いましたが、たしかにぼくもだいぶんコストをかけたわけですが、やっぱり編集チームにも多大なコストをかけさせてしまったなあ・・とあらためて恐縮。とはいえ、内容としては良いものになった、という点でおおむね意見は一致(たぶん)。

相変わらずお忙しいようでしたが、「この後は懇親会も行かれますか」と聞いたらもちろんそうで、過去の寄稿者さんへの挨拶に加えて、次に原稿を書いてくれそうな新しい書き手も探したいとのこと。さすが・・。こうした普段/不断の活動があの雑誌を支えているんだなあ、とあらためて敬意を抱きました。

懇親会

そのまましばらく知人と喋ったりぼんやりしたりしているうちに、同じ構内で懇親会スタート。

料理はスピーカーディナーや朝食と同じチーム。もりもり料理が出てきて、なくなる端からまた追加。プロフェッショナル!

f:id:note103:20190830185555j:plain

そして地味ながら感動したのはこのトレイ。

f:id:note103:20190830190013j:plain
完璧に取りきった様子

ドリンクを挿せるようになってるんですね〜。これがないと、ドリンクと皿を持っただけで両手が埋まってしまって食べることができないので、テーブル必須になっちゃうんですが、これがあるとテーブルがなくても片手に皿&ドリンク、もう片方の手で食べられて、テーブルいらず! すごい発明です。

たぶん、その分少しケータリングの単価も上がるのではとも思いましたが、選べるなら絶対これにしてほしい・・と思うぐらい良かったです。

そのドリンクですが、牧さん行きつけのバーが出張してくれたそうで。

f:id:note103:20190830185103j:plain

ぼくは2番と5番を飲みました。バーの方々、スポンサーの皆さん、ありがとうございました。

初日の雑感

ということで、本編初日をふり返りました。

この日のトークはすべて日本語でしたが、だから余計にというか、なるべく今までに見たことがないような、自分からかけ離れたものを見るように意識しました。
しかしそのわりに、けっこう要素としてはすでに知っていたり、関心が近いものが多かったのが面白かったですね。

風穴さん、稲尾さんといった編集界の諸先輩方に会えたのもよかったです。編集魂(?)が図らずも磨かれました。

朝食・コーヒー・懇親会といった食事系も途中で不足したりすることもなく、食べたいだけ食べれて大変満足でした。

ちなみに、終会後は翌日に向けてサクッと宿へ帰りましたが、川(荒川?)で続きをやっていた人たちもいたようでした。ぼくはもうお酒は十分でしたが、水を持って参加してもよかったな、と後から思いました。とはいえ、それをやったら翌日それなりに大変だったかもしれず、この辺はタイミング次第ですが・・。

最終日についてはまた別記事にまとめます。お楽しみに。

builderscon 2019に行ってきた(1)〜スピーカーディナー&前夜祭〜

2019/8/29〜8/31に東京は北千住の東京電機大学千住キャンパスにて開催されたbuilderscon 2019に参加しました。

https://builderscon.io/builderscon/tokyo/2019/builderscon.io

感想ブログ、後になるほど書くのが大変になるので、早いうちにワッと書いていきます。
ただし、参加日すべてについて一気に書くのもめちゃ大変そうなので、何回かに分けて書く予定です。

マイスポンサー

先日のRubyKaigiに続き、今回も私が所属するヴェルク(株)の支援により、コンプリートパック・チケットにて参加できました。イベントには全日フルで参加しつつ、このうち会社の営業時間・営業日とかぶる部分は出勤扱いにしてもらいました。心からの感謝と尊敬を捧げます。

DAY0: スピーカーディナー

まずは前々夜祭的なこちらから。

blog.builderscon.io

スピーカーディナーは言ってみればbuildersconの目次のようなイベントで、本編でスピーカーの皆さんがどんな話をするのか、というのを事前にリサーチできる機会になっていてとても良かったです。

主宰の牧さんによれば、本番の2日間ってスピーカーにとっては自分の発表のことで手一杯で、他のトークのことを気にする暇がなかったりするだろうから、その補完的な情報交換とかもできればいいよね、みたいな目的もあるようでした。

ぼくはじつはこのちょっと前に各種事情によりやや疲れていたものの、コンプリートパック・チケットにこれの参加権も入っていたので、「行かないともったいないよなあ・・」と思ってエイヤと参加したのですが、結果的にはそれが大正解で、仮に来年コンプリートパックがなかったとしても、この会があればマストで参加します。そのぐらい本編をより楽しむための材料にあふれていました。

参加者の割合的にはスピーカーの方がずっと多くて、ちょっとびっくりしましたね。非スピーカーの自分、少数派じゃん、と。

とはいえ、だからといって寂しくなるようなヒマもなく、各スピーカーによる1分間ピッチや後述のような要素を終始楽しみました。

健康トーク

本編とはコンセプトが合致しないけど牧さんが聞きたいから、という理由でこの日唯一長めの時間をとって発表されたのが@mogettaさんで、スライドはこちら。

docs.google.com

いやー、素晴らしかったですね。ぼくは全然筋トレその他、こういったことに関心はなかったというか、関係ない世界だと思っていましたが、だいぶ引き込まれました。

スライドも非常に作り込まれていて、参考文献集としても良いものだと思いました。

ちなみに、弊社にも筋トレにけっこう本格的に取り組んでいる人がいるので、このあと社内にシェアしておきます(笑)。

フード

フードもおいしかったですね。とくにおにぎりに生ハムとキュウリが乗ったものと、ゆで鶏にネギソースがかかったもの、あとデザートのチーズケーキがちょっと忘れられないぐらいおいしくて、本編の方の朝食&懇親会で同じチームが料理を提供していたので、そのときに声をかけてその旨伝えたほどでした。ありがとうございました。

f:id:note103:20190828190355j:plain
スポンサーのハートビーツさんによるご挨拶

f:id:note103:20190828191230j:plain
食べてる横でどんどん料理を追加していくスタイル。カッコイイ

f:id:note103:20190901202229j:plain
問題のチーズケーキ。Twitterでもだいぶ好評だった

DAY1: 前夜祭

どこを「DAY1」とするかちょっと迷いましたが、公式サイトではこの日から開催期間としているので、これをDAY1とします。

この日は最初、終日会社を休むつもりだったのですが、時間を確認したら18時スタートということだったので(前夜祭なので当然でしたが)、さすがに1日休むのはどうか・・と思って13時までは自宅でリモートワークをして、それから準備に取り掛かかりました(それまでまったくやってなかった)。

ちなみに、会場は家からそこそこ近かったものの(会社より近い)、それでも片道1時間ぐらいかかる距離だったので、会場と同じ北千住に宿を3泊取っておきました。

なので、この時にはその分の着替えを用意したり、充電器や常備薬などをまとめたりとなんだかんだで用意するものが多くて出発はギリギリに・・。

北千住駅にいきなりハマる

その後、駅すぱあとで調べながら北千住駅に着くまでは余裕でしたが、駅がまさにダンジョン。この駅の複雑さ・問題性については、以下のグレイト記事を事前に読んでいたので一応頭に入っていたはずでしたが・・

blog.builderscon.io

それでもまだちょっと甘く見ていて、何も考えずにホームから一旦「普段どおりに」階段を降りたら、なんか景色が変。「普通だったら」あるはずの方向や場所に『出口』の表示もなければその雰囲気すらない。どこに向かっても別のホームにしか行けない、別の電車にしか乗れない仕組みになって見える・・。

・・オ、俺は外に出たいんだ!出口!出口を教えてくれ!と、軽くパニックになりながら(もう前夜祭の開場時間を過ぎてたので)、「あ、そっか、最初に階段を降りてしまった時点でもう間違っていたんだ・・」とふと気づいた頃、ちょうど『出口』と書かれた中途半端な大きさの看板が目に入って、それが「もう1回ホームに上がっとけ」と道順を示していたので、観念して再び階段を登りながらあっちこっち行きつつようやく出口へ。

件の記事にもちゃんとこのように書いてあったのですが、読めてなかったですね・・。

プラットホームから下り階段・エスカレータを利用すると千代田線方面に向かってしまいます。くれぐれも下らないようにしましょう。

しかし帰りにも思いましたが、北千住駅の道案内って、かなり頑張ってるとは思うんですが、基本的に「すでに駅の構造を知ってる人」がその認識を確かめるために書かれてる感じで、「初めて来た人」にはだいぶ効果が薄い気がしますね。

たとえば東武スカイツリーラインって半蔵門線とつながってるんですが、それを示す解説がほとんどないので、元々そのつながりを知ってる人じゃないとどこに行けばいいのかまずワカランな・・と思いました。

前夜祭トーク

なんとか駅を脱出した後は、荷物が多かったので一旦宿にチェックイン。おそらく会場ではノベルティをもらえるはずなので、必要最小限のものだけ持って会場へ。

会場で受付。コンプリートパックのネームカード&各種ノベルティをもらって場内へ。今回のノベルティ、大ぶりながら軽いリュック付きで、これはナイス!さっそく通勤で使いたい、いや使います(笑)。シンプルな作りでとてもいい。

場内で缶ビールとつまみを取って着席。その後はトークを聞きました。

1つ目のトークはこちら。

https://builderscon.io/builderscon/tokyo/2019/session/66e6dcca-9639-11e9-a530-42010af01081builderscon.io

イベント全体を通して1発めだったのでけっこうプレッシャーあったのでは、と思いましたが、すごく力が抜けたイイ感じのトークで楽しみました。技術的にも「うわあ、こんなことできるの」と目が覚める感じで、とくにホロレンズって実際にどういう風に動くのか、テレビとかネットでは見たことがあったものの、目の前で使っている人って見たことがなかったのですごい新鮮でした。早くもbuildersconっぽい。

とくに、笛を吹いたらホロレンズ経由で信号が送られてドローンが飛ぶ、という最後の例。かなりウケました。この突飛な発想はなかなかできない。才能を感じます。

2つ目はこちら。

https://builderscon.io/builderscon/tokyo/2019/session/65b0f244-9639-11e9-a530-42010af01081builderscon.io

MySQLでパウンドケーキ(とクッキー?)を焼くというもので、元になった記事はこちら。

gihyo.jp

あのガムテープでオーブンを常にオンの状態にしておくというハックがウケました。あとはMySQLの2つめのイシューで「MySQLではトーストを焼けない」というのがあったらしくて、その辺の知見も面白かったです。(これも上記記事で解説されています)

3つ目はこちら。

https://builderscon.io/builderscon/tokyo/2019/session/67fc059c-9639-11e9-a530-42010af01081builderscon.io

おそらくこの日一番の「盛り上がったで賞」という感じでしたが。発表の元になった記事はたぶんこちらで、

qiita.com

結果としてはこのような感じでしたが(ビルコン用に用意された動画みたい)。

www.youtube.com

www.youtube.com

もうこの発表はね・・とにかくトークが面白かったですね。圧巻。どうすれば人が笑うのか、という構造をある程度わかってて話を進めている感じがあって、非常にリラックスしながら終始笑いながら聞きました。

そして4本目。

https://builderscon.io/builderscon/tokyo/2019/session/605eed5a-9639-11e9-a530-42010af01081builderscon.io

じつはというか、これはちょっと複雑な問題をはらんだ発表で、後からCoC(行動規範)絡みの議論がしばらく起こりました。

会場で聞いていたときの素朴な感想としては、初めのうちはマッチングアプリの概要や課金の仕組みみたいなものを見ながら「そんな風になってるのか〜(知らなかった、を知ったなあ)」と感心して聞いていましたが、途中ぐらいからちょっと説明の中で女性をモノ扱いしているように感じられてしまうくだりがいくつかあって、「ん〜、なんか・・居心地わるいな」と思い始めていました。

なんというか、この話って会場にいる女性、普通に嫌なんじゃないかな・・と。

その後、感想ツイートなどで問題性を指摘するものがいくつか出てきて、「ああ、やっぱりそう思ってた人けっこういたんだ。ですよね・・」という感じになったり。

ただ、上記で「複雑」と書いたとおり、案外現場にいると、サッと動いて「それアウト!」とも断定しづらい事情はいくつかあって、第一にトーク全体の方向としてはあくまで技術にまつわる話をしているので、その「主題は技術」という前提が、ある種反応を「遅らせた」みたいなところがあったように思っています。

それから、これはどこか反フェミニズム的な考え方にもつながりそうなんだけど、結局そのマッチングアプリって「どっちもどっち」感が醸されているというか、「たしかに男性も女性をモノのように見るかもしれないけど、逆も然りじゃん?」という見方を許すサービスでもあるので、「あくまでマッチングアプリに関する話です、出てくる女性も女性全般を想定しているのではなく、このサービスの利用者に限定した話です」みたいな見方もありうることを考えはじめると、「もしかして許容すべきなのか・・?」と思えてしまう部分もあるというか。

まあ後から冷静に考えれば、「聞いてる側が微妙になってる時点で駄目でしょ」とは簡単に言えるわけだけど、現場で即ストップするというのは、よほど事前にそういう状況を強く想定していないかぎり、難しかったんじゃないかな・・というのが現時点でのその現場に対する考えです。

それから、今回の発表者およびその段取りを進めた人たちはおそらくまだ若い人たちで、きっとそういうことに慎重になるだけの知識や経験が少なかったのだろうとも思います。となれば、それはもう各個人だけの問題ではなく、彼らを取り巻く会社・友人・家族などの社会的な不備であり問題でもあるわけで、その意味でも個人を責めるのではなく、関わる人々全体の責任として受け止めるべき部分もあるのかなと。

なお、この問題に対して「何が悪いのかわからん」的な反応もゼロではないようですが、それについて言えることはシンプルで、わかろうとする気がない人には何を言っても無駄です。なぜなら、その人は何を言われても「それじゃわからん、俺を説得してみろ」とさえ言えば常に勝てる無敵の人だからです。

だから大事なのは、そういう不毛な戦いをすることではなく、共に幸せに暮らせる社会を作るために力を合わせていける相手と、議論を積み重ねながら、より豊かな場所を作り続けることだと思います。

次回予告

さて、いつもの私ならこのまま脇目もふらずに翌日(本編初日)の話に入っていくところですが、各日の午前・午後および懇親会などのトピックが待ち構えていることを考えると、記事がかなりの長尺になることが予想され、かつその推敲(というか修正)も大変な量に膨らんでいきそうなので、一旦ここまでにします。

この後の内容的には、たとえばWEB+DB PRESSの寄稿でお世話になった編集長の稲尾さんとお会いしたり、同じく編集系で凄腕技術編集者・執筆家でらっしゃる風穴さんとお会いしたり・・などの話は忘れず書いておきたいところです(忘れないようにメモ)。

あとは朝食、昼食、懇親会・・(食べ物ばっかりですが)とかもたぶん含めます(メモ2)。

お楽しみに!

ふり返る『WEB+DB PRESS Vol.112』寄稿録

少し前にもお知らせしましたとおり、8/24発売の『WEB+DB PRESS Vol.112』のリレー連載「Perl Hackers Hub」に寄稿しました。

note103.hateblo.jp

記事のタイトルは、「自作ツールによる日常業務効率化 〜 初歩的なコードだけで身近な問題を解決!」です。Perlの連載なので、ここで言う「ツール」とか「コード」はPerlのそれですね。

その他、掲載誌の目次など詳細情報については下記をどうぞ。

gihyo.jp

執筆に至る経緯など、大まかな話は前回書いたので、今回はその具体的な内容についてまとめてみたいと思います。

執筆初期の諸問題

なにしろ『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だけで書かれた単純な、しかし自分の実作業を飛躍的に効率化してくれたツール群を紹介しました。

まあ、あまりにもシンプル過ぎて、これを「ツール」と呼んで良いのか、という問題もありそうですが・・とはいえ、ここで紹介しているコードは、ぼくが実際の仕事の作業をする中で「これプログラミング使わずに全部手作業でやっていたらめっちゃ大変だったろうなあ」と実感していたものばかりで、なおかつぼくのプログラミング初期の頃から使っていたものなので、記事の最初はとにかくこれを取り上げなきゃ、と思って紹介しました。

ちなみに、ここで取り上げた各ツールの利用シーンとしては、ぼくがフリーランス時代に手がけていた音楽全集の編集作業がかなりの割合を占めると思います。

commmons.com

それもあって、記事中では当時の詳しい素材データなどもわずかながら例として出していますので、クラシック音楽好きの人には面白がってもらえるのでは・・と少し思っています。

2. シェルコマンドを組み合わせる

ここではMacのopenコマンドをはじめとするシェルコマンドを、Perlと組み合わせる事例を紹介しています。

しかし考えてみると、ぼくが普段書いてるコードって、だいたいここまでに扱ってる技術ばっかりで、それより複雑なものってほとんどないのですよね。

ほんとにプログラミング始めて1〜2ヶ月ぐらいの人でも十分に書けるものだと思うので、そういう意味では(とくに非エンジニアの人には)参考にしてもらえるかもしれません。

具体的なところだと、「複数ファイルの行数や文字数をカウントする」で紹介しているツールは上記の編集者時代に頻用しましたし、あるいは「複数のWebサイトを一斉に開く」とかは我ながら単純すぎてちょっとバカっぽいなとも思いますが、でも地味に便利なんですよね。今でも時々使います。

3. ほかのツールを組み合わせる

メインはこの章だと思っています。ぼくが普段めっちゃ使ってる自作ツールを次々紹介していますので。

とくに、このブログでも何度か紹介しているchocoというツールがありますが、

GitHub - note103/choco

今回扱ったツールの中で何かひとつだけ選べと言われたらこれを選ぶぐらい、ぼくにとっては必須のものなので、これを紹介できたのは良かったなと。

プラス、このツールではその主要な機能を提供するものとしてpecoが使われているんですが、

GitHub - peco/peco: Simplistic interactive filtering tool

そのpecoを開発している牧さんが今回のメイン監修者だったので、なんというか・・今にも逃げ出したいような😱でも非常にありがたいような、得がたい経験をさせてもらいました。

あとは、ぼくがプログラミングを始めた初期の頃から公開しているcarvoというゲーム?みたいのがあるんですが、

GitHub - note103/carvo

これは冷静に考えると便利ツールでもなんでもないんですが(笑)、しれっと含めることができてよかったかなと*1

あとはAgっていう文字検索ツールを手軽に使うためのツールとか。

finds/find-word.pl at master · note103/finds · GitHub

これもかなり使用頻度が高くて、作り始めたときよりも今の方が使ってるかも、というぐらいよく利用してます。

4. 最小限のコードで書く

最後の章はこちらですが、ここでは今まさに会社で自分の業務のために使ってるツールを紹介しています。

少し前にTwitterでこんなことをツイートしましたが、

そこで言ってるのがこのツールです。

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」というイベントに参加したときに、編集長の稲尾さんが登壇しているのを見てざっくりは知っていたんですけど、

gihyo.jp

まさかそのフローを自分も体験できるとは(笑)5年前の同会場では想像もできなかったですね。(細かいフローはだいぶアップデートされてると思いますが)

GitHubの良いところは、とにかく前のバージョンを残せる、見返せる、というところだと思います。もちろん、消したい過去も残るわけですが、基本的には同じ目標に向かって進むひとつのチームですから、仮に恥ずかしい間違いや操作ミスがあっても、それはそれでべつにいいや、という感じで遠慮なく使わせてもらいました。

Issueなどの機能もけっこう初めの方からバリバリ使って、思ったことはなるべくそのつどオープンに伝えるようにしました。この辺は生来の空気読まない気質が良い方に作用したかなと思っていますが、まあ同時に、その意見言い過ぎなところがいつまでも執筆・編集が終わらない遠因になったのかも・・という気も今してきましたが。

話を戻すと、GitHubを使うとテキストベースで正の情報をアップデートしていけるので、それがありがたかったです。最終的には、本番デザインに組んだデータの方が正(最終版)になるわけですが、それでも簡易的なレイアウトや文字数はギリギリ最後の方までGitHub上のプレーンテキストでチェックできるようになっていたので、この辺はやっぱり技評さんならではの技術力と言いますか、助かりましたね。

コミュニケーション

編集チームとのコミュニケーションも円滑で良かったです。編集長の稲尾さん、この1コーナーにここまでコミットしてくるのか(笑)と驚くぐらいすごいスピードで動いてくださって、これがプロの仕事・・という感想でした。硬軟のバランスというか、アメとムチの出し方というか(笑)あれよあれよという間に執筆モードに誘導され、必要な環境がセットされ、気がついたら集中して取り組んでる、みたいな感じでした。

工程の後半は同編集部の渡邉さんに担当してもらいまして、こちらも毎回迅速なレスポンス、かつぼくのめんどくさい相談にも深いレベルで検討&回答してくれて、ありがたかったです。

とくに良かったのは、お二人ともレス(返信)が確実に来るんですよね。というのも、個人的にはレスって、べつに「早ければいい」というものではなくて、一番良いのは「想定どおりのタイミングで来る」のが良いレスだと思っていて、その意味で最悪なのは「めっちゃ早いときもあればまったく来なくなるときもある」というやつで、逆にその日のうちに返事が来なくても、毎回「午前の問い合わせには翌日午前、午後の問い合わせには翌日午後に返事が来る」みたいにパターンが一定なのがありがたいというか。あるいは事前に予告されていて、そのとおりに返ってくるとか。
そういう、ある意味基本みたいなところがきちんとされていてありがたかったな、と。

監修の牧さんにも、pecoの使い方でどれだけ怒られるかと戦戦恐恐としていましたが(←大げさに言いました)、改善点の提案なども論理的・丁寧に示してもらって、とてもやりやすかったです。

終わりに

ということで、丸々4ヶ月ほどにわたって取り組みました執筆もようやく終わりまして、またこの解題をもって本件全体についてもひと区切りかなと思います。

あらためて、今回の機会を与えてくれた id:papix さん、編集部・監修者の皆さん、ありがとうございました。
そしてまだ見ぬ読者の皆さん、どうぞお楽しみください。『ノルウェイの森』で小林緑が言った、以下の言葉を捧げます。

そのだしまきよ。心して食べてね。

WEB+DB PRESS Vol.112

WEB+DB PRESS Vol.112

  • 作者: 樋口剛,篠田典良,谷口慶一郎,大沼由弥,豊島正規,三村益隆,笹田耕一,牧大輔,大原壯太,門松宏明,鈴木恭介,新倉涼太,末永恭正,久保田祐史,池田拓司,竹馬光太郎,はまちや2,竹原,粕谷大輔,泉征冶
  • 出版社/メーカー: 技術評論社
  • 発売日: 2019/08/24
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

*1:一応、「初歩的なコードを組み合わせて自分に必要なものを作った」という意味ではテーマの範疇だと思っていますが。

*2:印刷所にデータを渡すこと。

『WEB+DB PRESS Vol.112』に寄稿しました(2019年8月24日発売)

掲題のとおりです。

gihyo.jp

発売は8/24とのことなので、あと3週間ぐらいでしょうか。余力があれば、またその頃に何か書きたいですが・・(無理かも)

初めに本件のお話を頂いたのはたぶん3月頃で、Perl入学式の名誉校長であります id:papix さんから、こういうのやりませんか、とお声がけ頂きまして。

具体的には、Perlハッカープログラマーの方々が連綿と受け継いでこられたリレー連載「Perl Hackers Hub」の第57回を担当しました。

タイトルは『自作ツールによる日常業務効率化 ―― 初歩的なコードだけで身近な問題を解決!』ということで。

まあ、これしかない、というか、こういうテーマでしか書けることがないのですけど、どうなんでしょうね、書き始める前には、第一にこんな話でいいのかどうか、第二にそれでいいのだとしても、現実世界でこれ、最後まで書き切れるのか体力的に・・などなど、いろいろ不安もありましたが。

結果的には、編集長&担当編集氏のスーパーご活躍と、メイン監修を務めて頂きました牧大輔さんのおかげで、「へ〜、思った以上に、思ったとおりの感じになったじゃん!」という感じになりました。
関係各位、本当にありがとうございました。

ぼくは今現在に至るまで、プログラマーとして仕事をしたことは一度もないんですが、この連載って基本的にプロ・プログラマーの方が記事を書いてらっしゃるので、硬軟の違いはあれど専門的な技術のことを扱うのが普通なところ、今回はやっぱり、異色といえば異色なものになったんじゃないかな・・と思います。

ただ同時に、ゆってもPerlの連載ですから、Perl成分はそれなりに濃いとも思います。何しろ、これまで5年ほどにわたり書いてきたPerlのコードをばりばり載っけましたので。

内容的には、そのノンプログラマーであるぼくが普段、自給自足的に作っては使っているプログラムについてあれこれ紹介している感じです。とはいえ、プロではないので、ねえ、まあ、難しいじゃないですか、どの辺をどの辺まで出すかっていうのは・・わかりますかね、結局、普段ぼくは自分だけが使う目的のプログラムを、自分だけが読む前提で書いているので、人様に、ましてやプログラマーである読者さんに(それもお金を払って読むような人たちに)見せるようなコードなんて書いてないんですよ(笑)。誰からもレビューとかされてないんですから。

なので、その辺のバランスというか、出すところと引っ込めるところのバランスを取りつつ、でも読み物としてはある程度、「貴重な時間を使って目を通してもそれなりには満足できる」ようなものを書ければ・・という感じで頑張りました。

しかしどうなんでしょうか、面白いんでしょうかね・・編集長氏は面白かったと言ってくれましたが・・ぼく自身はもう時間かけすぎてよくわかっておりません。

とはいえ本誌、ぼくはもう趣味のプログラミングを初めた頃からなので、2013年とか、2014年ぐらいには読み始めていたはずで、その頃から触れていた連載でしたから、まさかそのリレーの一員に加われるとは〜・・という感じでしたね。

編集チームもザ・プロの仕事。という感じで。ぼくも一応、編集の仕事をしていたはずだったんですが、この本物のプロを目の当たりにしますと、自分がやってたのは編集ではない編集的な何か、というか。讃岐うどんじゃないうどん、というか。そんな感じだったのかなと思いましたね。べつにどっちが上という話ではなくて、別物だったなあ、と。

しかしこんなブログをまだ続けているように、ずっと普通に、誰にやれと言われるまでもなくやってきたがゆえのコトだよなあ、と思います。ぼくはプログラミングを仕事にこそしていませんが、でも結局、向いてるのかなという気はしますね。ある種の才能というのか。やめない才能、苦もなく続けられる才能、疲れない才能、みたいな。まあ環境要因だったり、たまたまだったり、という要素も含めてのことですが。自分ではとくに努力と思ってやってるわけではないですからね・・はたから見れば頑張ってるように見えているかもしれないことも、べつに頑張ってるわけじゃなくて気がつけば普通にやっているだけで。それが向いてるということなのかなと。

ともあれ(まとめ)、いろんな貴重な経験をできた忘れがたい機会でありました。冒頭にも書きましたが、また発売前後でもう少し内容に踏み込んだことも書ければ〜・・とも思っていますが、それはその、ほんとに機会があればということで。

あらためまして、関係各位、ありがとうございました。読者の皆さん、発売をお楽しみにお待ちください。

WEB+DB PRESS Vol.112

WEB+DB PRESS Vol.112

  • 作者: 樋口剛,篠田典良,谷口慶一郎,大沼由弥,豊島正規,三村益隆,笹田耕一,牧大輔,大原壯太,門松宏明,鈴木恭介,新倉涼太,末永恭正,久保田祐史,池田拓司,竹馬光太郎,はまちや2,竹原,粕谷大輔,泉征冶
  • 出版社/メーカー: 技術評論社
  • 発売日: 2019/08/24
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

プログラミング入門者向けのサンプルコードで異なる名前を付けられるはずの複数の変数に同じ変数名を付けてしまう問題

Perl入学式の受講生だった5年前にも同じようなことを言っていたので変わってないな自分・・と思うとともに、この問題じたいがある種普遍的なのかな、という気も。

以下、掲題の件について簡単にまとめてみたいと思います。

Rubyで言うと、たとえばこんなサンプルコード。

class Foo
  def initialize(name:, price:)
    @name = name
    @price = price
  end

  def show
    return "#{@name}: #{@price}"
  end
end

bar = Foo.new(name: "apple", price: 100)
puts bar.show

結果は以下。

apple: 100円

引数としてクラスの外部から内部へ値を受け渡すためのname, priceと、クラスの内部でその値を操作するインスタンス変数のname, priceがそれぞれ別の変数であるにもかかわらず同名で記載・使用されています。

こういったことはPerlの入門者向けサンプルコードでも起こりがちで、なにしろPerlではスカラー変数でも配列変数でもハッシュ変数でも、それぞれ別の変数なのに同じ単語を使えるので、たとえばこんなことになります。

#!/usr/bin/env perl
use strict;
use warnings;
use feature 'say';

my $apple = 100;
my @apple = (101, 201);
my %apple = (foo => 102, bar => 201);

say $apple;
say $apple[0];
say $apple{foo};

結果は以下ですが、

100
101
102

問題は、この中の

say $apple;
say $apple[0];
say $apple{foo};

と並んでる3つの「$apple」は全部別物だということですね。まったく相互の関係はありません。

これ、混乱しませんか??

ぼくは初心者のときにこう思いました。「なんでわざわざ同じ名前付けるの!?」

上記の例で関係がある(同じ変数名でなければいけない)のは、以下の組み合わせです。

# 配列とその要素

@apple
$apple[0];
# ハッシュとその要素

%apple
$apple{foo};

同じ変数名を使うなら、こうした「同じ変数名でなければいけない組み合わせ」に限るべきで、なぜわざわざ配列とハッシュを同じ変数名にするのだ・・とただ苦しむばかりでした。

まあ実際には、ぼくもやがて初心者を卒業というか、初心者であることに飽き始めた頃、「なるほど、コードを書くときはこんな風にいろいろ揃えてしまった方がラクに感じることもあるのだな」と理解するようになりましたが、とはいえ、初心者にこれは酷だろうという気持ちには今も変わりはありません。

では、そのPerlのコード、どう直したら読みやすくなるでしょうか?
一例ですが、こんな風にすればどうかと思います。

#!/usr/bin/env perl
use strict;
use warnings;
use feature 'say';

my $apple = 100;
my @orange = (101, 201);
my %lemon = (foo => 102, bar => 201);

say $apple;
say $orange[0];
say $lemon{foo};

これだったら、どの変数がどこに動いているのか。それぞれの代入した値がその後にどこで使われているのか、追いやすくなります。

ようは、「同じ変数名でなければいけないものだけ」を同じ変数名にするということです。

コードには色が付いていません*1。そのようなとき、色分けをする代わりに適切な変数名*2を付ける必要があるのではないか、と思うわけです。

上記を踏まえて、あらためて最初のRubyの例に戻りますが(再掲)

class Foo
  def initialize(name:, price:)
    @name = name
    @price = price
  end

  def show
    return "#{@name}: #{@price}"
  end
end

bar = Foo.new(name: "apple", price: 100)
puts bar.show

これ、たとえば以下のようにすると、どの値がどの変数を通してどこへ動いているのか、わかりやすくなると思います。

class Foo
  def initialize(name_arg:, price_arg:)
    @name_var = name_arg
    @price_var = price_arg
  end

  def show
    return "#{@name_var}: #{@price_var}"
  end
end

bar = Foo.new(name_arg: "apple", price_arg: 100)
puts bar.show

この問題、ようは読み手のトレースする力の程度に合わせる、ということなのだと思います。コードを書いているプログラマー自身は、どの変数がどの値を抱えているのか、頭の中ですでに追えている状態なので、変数名によって値の経路を示す必要はもうなくて、むしろ別の理由、たとえば異なる中身を持った変数同士が同種の属性や役割を背負っていることを示すために、同じ変数名を付けてカテゴライズしておきたい、みたいな考えがあるのかもしれません。

しかし入門段階の人は、普通はそういったトレースをする力が十分にはないがゆえに、変数の名前からその中身の値を想像しようとしますから、異なる値・異なる変数であるにもかかわらず同じ名前がついていると、混乱が生じやすいということではないかなと。

このあたりの問題を認識した上で、その状況に応じてどうするべきなのか(異なる中身を持つ変数同士に同じ名前を付けるのか、それをしないのか)を考えられると、より良いかたちで書き手と読み手のコミュニケーションが成立しやすくなるのではないか、と思っています。

*1:エディタ等のシンタクスハイライトで色を付けることはできますが、それは個々の設定によるので、結局書き手が見ているのと同じ色付けを別の読み手が見ることはできません。

*2:ここで言う「適切さ」とはそのコードが読み書きされる背景によって変わるものだと思います。プログラマーの間だけで読まれる前提ならば、上記のような配慮は不要かもしれません。ここではあくまで「入門者にとって適切な」変数名について書いています。

TokyoGirls.rb Meetup vol.1 に行ってきた

TokyoGirls.rb Meetup vol.1 に行ってきました。

techplay.jp

昨年11月にフリーランス編集者からRailsを使うIT企業(のカスタマーサポート)に転職したので、今後はRubyコミュニティとの接点を増やしていきたいな、と思っていました。

その一環として、昨年後半には大江戸Ruby会議07に参加して、今年の春にはRubyKaigi 2019に参加するつもりですが、前者の大江戸の方で見たしなもんさんがこれに参加する、という話をTwitterで見かけて抽選に応募したところ当選。という流れで、同イベントに参加してきました。

現場の雰囲気については、ハッシュタグを追うとある程度わかるかもしれません。

https://twitter.com/search?vertical=default&q=%23tokyogirlsrb&src=typd

以下、簡単に感想を。

かなきゃん(@_kanacan_)さん

元アイドルにして携帯キャリアのエース販売員。中学のときの技術の時間? にHTMLを教わったというぐらいお若い方でウルトラカルチャーショックを受けましたが、それ以上に生き方・考え方みたいなところに刺激を受けました。

speakerdeck.com

たくましいとか強いとかしたたか、みたいなことはいくらでも言えるんだけど、今回この発表から感じたもっと本質的なところを一言で言うと、自分が何を欲しいのか、どうなりたいのか、みたいなことをすごく自覚している、あるいは自覚しようとしている、ということですね。これ、ぼくにはすごく欠けているところです。これがないと、ただフラフラ流されるままというか、本当はもっと欲しいものがあるのに、他人から「君はこれでいいでしょ?」と言われたら「あ、はい・・」みたいになってしまうんですよね。

印象的だったエピソードもいくつかありましたが、とくに残ったのはSmartHRに応募するときの話で、駄目かもしれないけど、失敗したらそれはそれでストーリーになる、というところ。ここで言う「ストーリー」というのは、仮に落ちても、その2年後ぐらいにもっと力を付けてから「一度落ちたけど、また挑戦しに来ました!」って行けばかつての失敗もストーリーとして価値を持つ、みたいなこと。これを考えて実行できるのはスゴイと思いました。

だって、そんな風に考えられるようになったら、すべての失敗は成功の一部になりますよね。

実際には、そんな風に考えたりトライしたりできるっていうことは、そのウラに何十倍もの失敗があるんだろうと想像します。それも全部引き受けながら、トライを続けるその生き方には大いに学ぶところがありました。

*参考記事として紹介された以下のブログ、あとQiitaも読み応えがありました。

しなもん(@sinamon129)さん

前述の大江戸Ruby会議07で一度発表を見ていて、それがものすごい面白かったので、今回の目当ての一つはしなもんさんの発表でした。

speakerdeck.com

果たして、その大江戸のときの話とある意味ワンセットというか、合わせて読むと一段深く楽しめるような、やはり今回も非常に面白い発表でした。

*大江戸Ruby会議07のリポートとしなもんさんのスライドは以下。

障害対応・深夜メンテナンスはすごい人がやってる印象、だからそれに憧れていた、という話。ぼくはプログラマーではないですが、すごいわかる気がしました。たぶん、そのすごい人たちもまた、そういう作業を陰惨な雰囲気で、ではなく、どこか充実した感じでやっていたのかな、という気もします。で、そういう人に自分もなりたいな、みたいなことを感じたのかな・・とか。

印象に残ったのは、できる先輩同士がやってるのを見ながら「その話、どこ見ながら言ってます?」みたいにツッコミながら追いかけていた、という話。たしかに言われてみればめちゃ効率いい方法だけど、自分だったら現場でそんな風に考えたり聞いたりできるかなあ・・と。

単純に、そういう合理的な方法を考えて実際に行動に移す、というのができてスゴイ、と感心しました。自分の今後にも参考になりそうだな、と。

スポンサーLT

スポンサーLTでは万葉の鳥井さんの発表が印象的でした。

speakerdeck.com

というのも、万葉には働き手を支えるいろんな仕組みがそろっているという話が次々出てくるんだけど、これがけっこうどれもヴェルク(昨年ぼくが転職した先)を想起させるんですよね。

ヴェルク株式会社 - board・データ分析・受託開発

*ちなみに、転職したときのぼくのブログは以下です。
http://note103.hatenablog.com/entry/2018/11/10/172527

社員それぞれの都合を最大限生かせる仕組みを用意する感じというか。あるいはぼくなりにもっと原理的なところを言うなら、社員をとことん人間扱いする、みたいな感じでしょうか。

おまけに、どちらもRailsを使ってる・・!

あえて言うと、万葉さんの方は女性の働きやすさという点でより特徴的かなと思いました。
ぼくはプログラマーではないですが(再)プログラミングの本はいくら買ってもOKと言ってもらっているので、万葉さんの以下を読みつつ、新入社員教育用カリキュラムもやってみたいと思っています。

github.com

よう(@youchan)さん

じつは今回のイベント、しなもんさんやかなきゃんさんの発表を見たいというのも大きかったですが、タイムスケジュールを見て一番期待していたのはこちらのようさんの発表で、期待に違わぬとても面白い内容でした。

youchan.org

最初に印象に残ったのは「千葉の人、いますか?」という質問で、なぜなら今は千葉のRubyコミュニティがない(アクティブではない)ので、とのこと。ぼくは千葉の人で、しかもけっこう近いところにお住まいだったので、え、だったらそれ作るの参加したい・・と思いました。(今度また何かの集まりに顔を出したらお声がけします・・)

期待していたというのは、Ruby入門みたいな話だったからですね。それは言語の勉強という意味でも、コミュニティへの入り口という意味でも。

「すべてがオブジェクト」とはRubyを語るときよく語られることですが、今回初めて「あ、なるほど・・」という腑に落ちた感じが少ししました。(まだあまりRuby自体触っていないので、本当に少しですが)

ぼくは今まで5年ほど、Perlを趣味レベルではありますがずっと触ってきたので、その辺も思い出しながら聞いていました。関数型言語と絡めたあたりの話も興味深かったです。

それから後半の、男性中心なのも問題だけど、だからって女性だけなら良いってわけでもない、偏るのが問題。という話、まったく同感でした。

問題は、そういった状況が必ずしも悪意によって生じるのではなくて、むしろ大抵の場合は単に無意識・無自覚のうちに起きてしまう、ということなのかなと。であればこその大人力・思慮・配慮が求められるということなのかなと。

言い換えると、つねに思考停止せず、より良い環境を実現するための方法を想像したり、考え続けたりすることが必要なんだろうな・・と。

そうそう、あと余談ではありますが、ようさんはRabbitを使っていましたね。

Rabbit - A presentation tool for Rubyist

やっぱりつくづく、登壇者だけでなくお客さんにもプレゼンの進捗が可視化されてすごいツールだなあ・・と思いました。少し前に自分でも使おうと思ったものの(YAPC::TokyoのLT)、ちょっとデザインのカスタマイズが難しい・・と思って諦めたことがあったので、あらためてもう少し触ってみようと思いました。

かとりえ(@katorie)さん

最後のかとりえさん、終盤の子育てを絡めた部分は時間の都合もあって概要のみという感じでしたが、具体的なチーム作業のことも多く触れつつ、全般的には女性がどんな働き方をしていけるか、ということについて一番現実的・実感的なイメージを伝える内容だったという印象を持ちました。

speakerdeck.com

Web業界・エンジニア界への惹句としてキラキラした美辞麗句はそこいら中にあって、あたかもこの業界に入りさえすればそれが実現するかのように思ってしまいがちだけど(だから気をつけて、とかなきゃさんも言っていた)、本当に必要なのは誰が具体的にどんなことをして、その結果としてどんな今があるのか、という話で、これからそういう業界に飛び込んでみたいと思っている人たち(とくに女性)にとっては貴重な話だったのではないかな、と思いました。

すべての発表が終わった後、懇親会の方は今回はパスしました。ケータリングのすごい良い匂いがしていましたが、体調が今ひとつだったので。とくに食事の席は外しておいた方が無難かな・・と。

しかし懇親会はボッチ対策でグループ分けの工夫があったようですね。

すげーアイデアだ・・とハッシュタグを見ながら思っていました。(もし残っていたらVimグループでした)

雑感

女性メインでありつつ、男性の参加も一定割合まではOK、というこのシステム、素晴らしいと思いました。

とくに印象的だったのは、質疑応答でどんどん女性参加者が発言していたことですね。それも、手元のメモを見ながら、というなんだか真面目な感じ・・すごい良いなと。

しかしこんな風なシステムだと、女性ばかりが優遇されるような雰囲気が醸されてしまうのでは? という懸念もありそうですが、この辺のコンセプト的なことについては、個人的には主催の伊藤淳一さんによる以下のブログ記事に大元のことが書かれていると思っています。
blog.jnito.com

とくに、以下2点ですかね。

  • 日本のITエンジニアの世界は、まだまだ比率的に男性の方が圧倒的に多い
  • いろんな勉強会や初心者向けのイベントもあるが、そういった場所でも男性が多いので、(主催者がいくら「女性でもOK」と強調しても)女性にとっては敷居が高い

あとは、少し前に自分の別ブログで抜き書きをしたのですが、作家の森博嗣さんによる以下の言葉も近いことを言っていると思います。

男女平等などの流れで、「女性ばかりを優遇しすぎではないのか? それでは平等ではない」と反発する声もあるのですが、これは、これまでの歴史を知らない発言だと言われてもしかたがないでしょう。つまり、それくらい女性を優遇する仕組みを押し出しても、まだまだ平等ではない、という歴史です。真っ直ぐ走るためには、ハンドルを真っ直ぐにすれば良いわけですが、今まで右に進んでいたら、左にハンドルを切らないと真っ直ぐにはなりませんからね。
森博嗣数奇にして有限の良い終末を』より/太字は原文ママ

今はまだ、ここで言う「ハンドル」を真っ直ぐにしたままでは足りない状況なのかな、と。その意味でも、とても意義深いイベントだったと思います。

あらためまして、スタッフの皆さん、登壇者さん、参加者の皆さん、おつかれさまでした。楽しい時間をありがとうございました。

なぜアウトプットするのか

2013年からPerl入学式(Perlによる無料のプログラミング講座)でお世話になっている id:xtetsuji さんから、ぼくがアウトプットを続ける理由は何か? という質問というか、お題をもらって、しばらく考えていました。

ここで言うアウトプットとは、直近で言うと去る1月終盤に行われたYAPC::TokyoでのこのLTとか。

note103.hateblo.jp

あるいは昨年の今頃に発表したこちらとか?

note103.hateblo.jp

その他にも、このブログをはじめとするネット上での各種意見もそれに含まれると思います。

あとは、いろんなイベントに顔を出してもいますね。去年だけでも、上記以外にbuildersconとか、大江戸Ruby会議07とか、Vimconfとか。

*大江戸Ruby会議については最近公開されたるびまのこの記事がとても良かったです。シェアさせて頂きます。
magazine.rubyist.net

で、そういうイベントでまた、いろんな人に自分から話しかけたり。これもまたアウトプットかなと。

さて、それで最初の質問に戻りますが、なぜそんなことをするのか? という話ですが。

それに対する答えのいくつかは、最初に挙げたYAPCでのLTスライドに書きました。曰く・・

  1. やったことや考えたことを忘れちゃうから、メモがわりに。
  2. 見知らぬ人への手紙。どこの誰かもわからない人に知見の共有。
  3. 自慢したいから。
  4. 恥ずかしさよりも、それをやりたい気持ちの方が強くなるから。

ということ。

とくに、最後のはある意味一番大きいかなと思っていますが、これってじつは「なぜアウトプットしないのか?」という視点から捉えることもできて、ぼく自身のことを考えると、「ああ、あのとき、なんであれをやらなかったんだろう!?」と思ったときの答えは、結局「失敗したくないから」とか「絶対に恥ずかしい思いをしたくないから!」ということだったと思います。

実際には、何かを「やらない」理由なんて100でも1,000でも挙げることは可能で、いくらでもやらない言い訳なんてできるけど、でもやっぱり最後の最後には「失敗したくない」という理由に行き着くはずだと思っています。だって、絶対に失敗しない唯一の方法は、それをしないことですから。試合に出なければ、100%負けません。間違いない。

だから、「なぜアウトプットするのか?」という質問は、単純にそれをひっくり返せばよくて、「失敗してもいい」と思えた時というか、「失敗したくない」と思う以上に「それをやりたい」とか「実現したい!」と思った時があったからですね。

でも、その「実現したい!」っていうのも、そう書くとなんだかポジティブに聞こえますが、実感的にはもっとしょぼい感じというか、ようは「もったいない」って思っちゃうんですよね。たぶん、ぼくがアウトプットする理由の第一ってこれかも、と今思いました。

人生は有限で、チャンスは一度だけではないかもしれないけど、でも生きてる時間が限られてる以上は何度も巡ってくるわけじゃないから、次のチャンスはもう生きてるうちには来ないかもしれない、じゃあ、今やっとくしかないんじゃない? みたいな。

それで、渋々というか、仕方なくというか、「二度とできないぐらいだったら、いま頑張ります・・気乗りはしないけど・・」みたいな感じですね。

その意味では、なんというか、捨て身になっていることも多い気はしますね。それまで丹念に育ててきた何かを一気に全部捨てて次の場所に行く、みたいな。そのことにあまり躊躇がないというか。

ぼくは美大に入って、将来何をしたいとかまったく考えないまま大学4年間を過ごして、卒業してもまだ何も決めず、30を過ぎた頃にようやく継続的な仕事をもらえるようになって、でもそのまま43歳になるまで一度も定職につかずに生きてきて、ようはずっと「なんとかなるっしょ」のままやってきた感じがあるんですよね。

その根無し草感というか、べつにカッコつけるつもりはまったくないですが(とくにカッコよくないですか)、実際本当にそんな感じだったので、あるとき突然どっかに飛び込む、チャレンジする、ということに対して抵抗感が少ないところがあるかなと自己分析します。明日から突然それまでの全部がなくなっても、まあ、わかりました、なんとかします、みたいな。

あるいは別の言い方をすると、「痛くない」という感じ。失敗したり、恥ずかしい思いをしたり、指をさされて笑われたりしてもべつに構わない、いやもちろんめっちゃイヤだし、傷つくし、全然積極的にそんな思いをしたいわけではないけど、それでも「まあそんなに、痛くない」という感じ。ある意味鈍感というか、無感覚ということなのかもしれないですが、でもそのある種の耐性みたいのができてきて、それで前半の方で言った「アウトプットしない理由」の方が、「やりたいこと、味わいたいこと」に比べて相対的に小さくなってくれているのかな・・と。

もうひとつ、これは先日、rubyist.club という数年前にやっていたポッドキャストの以下のエピソードを聞きながらふと思ったことなのですが、

rubyist.club

その中でゲストの@bash0C7さんが言っていたことで、「ロックスターに憧れていても、客席から見ているだけでは届かないから、どんな形でもいいから舞台から客席を見る側でありたい」と言っていて、ああ、それちょっと似てるなと。(実際の文脈とはちょっと違うかもしれないんですが)

上記の捨て身の感覚というのは十代後半ぐらいからあった気がするんですが、それとは別に、ぼくが自分の人生が大きく変わった分岐点として今でも思うのは、たしか28歳のときに菊地成孔さんの音楽私塾に申し込んだときで。その申し込んだ瞬間のことは今でも覚えていますが、雪の日で、古い貸家の暖房をつけてもなかなかあったまらない部屋でブルブル震えながらそれこそ捨て身で「絶対駄目だよなあ」と思いながらエイヤと申し込んだら50分後に入学OKの返事が来て。

その数週間後に第1回の授業があって、初めて目の前に現れた菊地さんを見て、あ、今までスクリーンの向こうにいた人が、現実でつながった。あれ、てことは今ぼくはスクリーンのどっちにいるんだ? こっち側? 向こう側? いやどっちでもないのか? みたいな。その日のその瞬間から、何かその「こっち」と「向こう」を分ける透明なガラス板みたいのが音を立てて砕け散った感じで、こんなふうに言うとあまりに綺麗にまとまってしまうんだけど、それがもしかするとぼくがアウトプットする側に入ったときだったのかな、という気も少ししますね。

実際、その菊地さんとの出会いがきっかけで、ぼくは編集者的な作業をするようになって、それが元になって大谷能生さんと共著で本を出すことになって、その経験を踏まえて後藤繁雄さん、坂本龍一さんとの仕事にも連なっていったわけで。

で、ここからがまた大事なトピックなんですが、そういう経験をする中でぼくがつくづく思っていたのは、結局そういう才能あるミュージシャン、クリエイターのような人たちとどう関係を結ぶかといったときに、やっぱりお客さんとして付き合うというのは、ぼくにはどうしても不合理というか、もったいなく感じられて、なぜならお客さんとしてアーティストに触れられるのってほんの一瞬だけで、にもかかわらずその「一瞬」を手に入れるためにかなりのコストを支払うことになるんですよね。あくまで個人の感想ですが。

じゃあどうすればいいのよ、と言ったら、その菊地さんの時のように生徒になるとか、あるいは坂本さんの時のように仕事相手になるとか。

まあ後者の方は運や他人の要素も大きいので、やりたいからってそう簡単には実現できないかもしれないですが、ただいずれにしても、ぼくはそういう巨大な才能をお客さんとして味わうのではなくて、もっとその人たちの近くで、もっとダイレクトに体験したいと思っていて、そのためには、彼らと対等な関係になるしかないと思っていました。言い換えると、たくさんいるお客さんの中の一人ではなくて、交換不能な役割を持ってその場に混ざるということなんですけど。

で、それってさらに言い換えると、結局自分もクリエイターになるしかないということなんですよね。自分も作る人になるしかない。なぜなら、お客さんとしてではなく現場に混ざるということは、その才能ある相手から「君には何ができるの? 何を作れるの?」と聞かれるということだから。現場の一員になる以上は、その輝く才能をただ近くで受け取って楽しむだけではなくて、自分からも何らかの才能を燃やした結果を提供しなきゃいけないから。対等な関係というのはそういうことだから。

つまり、リスクを取るということですね。相手にもっと近づきたい、まだ見たことがない巨大な才能の輝きを、生きているうちにもっと見たい、間近で見たい! と思ったら、自分もその人に何かを提供できる人になるしかない、「君には何ができるの?」と聞かれたときに提示できる何かがなきゃいけない。上手くいけば大きなリターンがあるけど、失敗したらもう立ち上がれなくなるほど傷つくかもしれない、というそれがリスクというもので、でもその輝きを本当に体験したいなら、リスクを取るしかない。

上記のポッドキャストでは「客席から舞台を見るのではなく、舞台から客席を見たい」と言っていましたが、ぼくの場合はそれで言うと、「客席からロックスターを見るのではなく、同じ舞台の上からロックスターを見たい」という感じでしょうか。

そう考えると、その後、38歳にしてそれまでまったく馴染みがなかったエンジニア界隈の人たちとつながりを持って、みんな坂本さんのことは知っていてももちろんぼくのことなんて1ミリも知らない人たちに囲まれて、なんのアドバンテージもなく、むしろどちらかといえばマイナスからのスタートみたいなところから、こんなふうに「どうしてアウトプットするの?」なんて質問されるぐらいコミュニティの人たちと親しくなれたりしてきたのは、そういう考え方だったり、経験だったりを重ねてきたからかな、という気もします。

以上、今度 id:xtetsuji さんとそれについて喋るときのためにメモとして書き出してみました。