2005年製のGibson ES-335を買いました #ギターの話です

別に「よし、買うぞ！」と思って楽器屋さんに行ったわけじゃないんですが、なぜか買ってしまいました。
はい、GibsonのES-335というギターです。

新品ではなく2005年製の中古です

いや、前からES-335は欲しかったんですよ。
Twitterでも欲しい、欲しいと言い続けてましたし。

昨日楽器屋さんでES-335を試奏してみたけど、すごく良かったわー。ストラトともレスポールとも違う、ほんのりふくよかで甘みのあるサウンドがサイコー。歪ませてもgood。欲しいけど高いしなー、うまく弾けないしなー、あんまり弾く時間ないしなー、うぇーん😭 #ギターの話ですhttps://t.co/7Sb5Tsqbsd

— Junichi Ito (伊藤淳一) (@jnchito) March 25, 2019

なんで買ったのかというと、連休中にこんなことがあったからです……。

ラブストーリーは突然に

先日妻と神戸三宮に買い物に行きまして。
妻は自分の服を見てくるというので、僕は一人で時間つぶしに楽器屋さんに行ったんです。

そこで最初に試奏したES-335が結構いい感じだったので、「じゃあ今日はES-335をいろいろ弾き比べる日にしよう」と思い、三宮の楽器屋をいくつか回って同じ価格帯のES-335を5〜6本試奏しました。
その結果、一番最初に弾いたES-335が一番弾きやすくて、一番いい音が出ている気がしました。

僕の背中を押した妻の一言

とはいえ、1本ウン十万円もするギターです。
いきなりそんな高い買い物ができるはずもなく、この時点では別にこのギターを買うつもりはありませんでした。

ですが、妻に「いいギターがあったんだよね〜」と話したところ、

「じゃあ、今持ってるギターを1本売って買ったら？」

と言われました。

妻にそう言われたときは「えー、そんな！今持ってるギターは手放したくない！！」と思ったんですが、やっぱり最初に試奏したES-335が気になります。

そこで、もう一度楽器屋さんに足を運んで、一番気に入っていたES-335を弾かせてもらうこと数十分。

「やっぱりこのES-335はいいなあ。・・・よし、買おう！！（今持ってるギターを手放して）」

と決意し、ギターを買い換えることにしました。

差額で見れば現実的な購入価格に

お店の人に僕が持っているギターの写真を見せて、ざっくり下取り価格を見積もってもらったところ、差額を2万ちょっと支払えばこのES-335が手に入ることが判明。

「じゃあ明日ギター持ってくるんで、このES-335はキープでお願いします！」

とお店の人に伝えて、その日は楽器屋さんを後にしました。

ラブストーリーは突然に（再）

翌日、下取りしてもらうギターを持って、僕は再び三宮に向かいました。
で、昨日キープしておいたES-335を買うために楽器屋さんに入り、何気なくギター売り場を見ていたところ、

「ん？こんなES-335、昨日あったっけ？」

と思いました。
見覚えがあるような、ないようなES-335が売り場に並んでいます。

店員さんいわく、「それねー、ちょうど昨日入ってきたES-335なんですよー」とのこと。
見た目も価格も僕がキープしていたES-335とほぼ同じだったので、「これもちょっと試奏させてください」とお願いして、新しく入ってきたES-335を試奏させてもらいました。

（♪♪ 試奏中）

「あれっ？もしかして僕が買おうとしているES-335よりも音がいいのでは！？」

（♪♪ 2本のギターを弾き比べる）

「やっぱり、新しく入ってきたES-335の方が音がいい・・・。よし、昨日のはキャンセルして、こっちにしよう！！」

と、急転直下で前日入ってきたばかりのES-335を購入することになりました。

楽器屋さんで2本のES-335を弾き比べる僕

ES-335は最高オブ最高😍

いやー、このES-335は非常に良いです！
楽器屋さんでもいい音がしていましたが、我が家の'64 CUSTOM DELUXE REVERB（ギターアンプ）と組み合わせて鳴らすとめちゃくちゃいい音がします。

イメージ的に近いサウンドはこちらの動画です。
（同じES-335ですが、こちらは1967年製のビンテージギター）

なんての？ホンマにエエ音や / ビンテージ６７年製ギブソンES335 / TFGD#29

さらに音が良いだけではなく、とっても弾きやすい！
いい音 + 弾きやすいギターは最高です。
最近ちょっと下がり気味だったギター熱が、これでまた再燃しそうです🔥

新しく教本も買いました

僕が買ったES-335はジャズっぽい音が一番似合いそうだったので、ジャズギターの教本を買いました。

イントロからエンディングまで! 完奏方式で完全制覇! “使える"ジャズ・ギター (CD2枚付) (リットーミュージック・ムック)

これで僕もジャズギタリストですね。（練習しろ）

参考：下取りに出されたのは、この子です

ちなみに今回ES-335と引き換えに下取りに出されたのは、こちらのレスポールカスタムです。

見た目も美しく、いろんな思い入れがあったのですが、泣く泣く手放すことにしました😢
いい人に拾ってもらうんだよ〜、レスポールちゃん。

まとめ

というわけで、今回のエントリでは新しく買ったES-335を紹介しました。
宝の持ち腐れにならないよう、練習がんばります〜。

ギブソン ES-335プレイヤーズ・ブック セミアコ大集結! (ギター・マガジン)

Oh!Yeah!/ラブ・ストーリーは突然に

【動画付き・プレゼン初心者向け】忙しいITエンジニアのためのKeynote講座

はじめに

先日登壇したTama Ruby会議01で他の登壇者さんとしゃべっていると、「スライドの枚数がめちゃくちゃ多くなってしまったんですよね〜」と話されている方がいました。
詳しく話を聞いてみたところ、どうやらサンプルコードを強調表示する矢印やテキストボックスをシュパッ、シュパッと順に表示させるために、それぞれ1枚ずつスライドを用意していたようです。

たとえば、こういう効果を実現するには4ページ必要になる

ですが、こうした効果はKeynote（Mac用のプレゼンテーションソフト）のアニメーション機能を活用すると、1枚のスライドの中で矢印やテキストボックスを順番に表示させることができます。

とはいえ、ITエンジニアのみなさんはコードを書くのが仕事であって、プレゼンテーションソフトの使い方を覚えるのが仕事ではないですよね。
ですので、アニメーション機能のことを知らなくても仕方ないことだと言えます。

そこでこのエントリでは、プレゼンテーションソフトの使い方を勉強しているほど暇ではないITエンジニアのみなさんに向けて、アニメーション機能をはじめ、僕がよく使っているKeynoteの便利機能や使い方のコツをいろいろ紹介していきます。

対象バージョン

この記事ではKeynote 9.1（2019年7月時点での最新バージョン）を対象とします。

【もくじ】

動画を見るのが一番早いから動画を見て！！

と言いながら、実は紹介したい機能は一通りYouTube動画の中で紹介しています。
このエントリは動画がメインであって、ブログの内容はオマケです。

ブログは概要を紹介するだけに留めますので、詳しい説明は以下の動画をご覧ください。

ここから下は動画の中で話している内容に簡単なまとめです。

リストを1つずつ表示させる

リストのテキストを1つずつ順番に表示させるときは、アニメーション > イン > エフェクトを追加 > 出現（またはその他のエフェクト）を選択します。
また、デフォルトだと表示形式が「一括」になっているので、これを「1件ずつ」にするとリストを1つずつ画面に表示させることができます。

2つ以上のオブジェクトを同時に表示させたいときは「ビルドの順番」を指定する

矢印とテキストボックスを同時に表示させるときなど、2つ以上のオブジェクトを同時に表示させたいときは、「ビルドの順番」を指定します。
ドラッグアンドドロップでオブジェクトのビルドをグループ化すると、グループ化したビルドのオブジェクトを同時に表示させることができます。

写真を丸く切り抜く

写真を丸く切り抜きたいときは、以下の手順で行います。

1. 「図形」から丸のオブジェクトを選択してスライド内に表示させる
2. デスクトップなどから画像ファイルを「丸オブジェクト」にドラッグアンドドロップする
3. サイズを調整して完了ボタンをクリックする

円の大きさを変えるときはシフトキーを押しながらドラッグする

ちなみに、きれいな円や正方形を保ったままオブジェクトの大きさを変えたい場合は、シフトキーを押しながらドラッグします。

行間を調整して情報を視覚的にグループ化する

これはKeynoteの使い方ではなく、デザイン一般の話です。
行間を狭めたり広げたりすることにより、「情報のひとかたまり」を視覚的に強調することができます。

↓ 行間を調整しないと、「情報のひとかたまり」がわかりにくい

↓ 行間を調整すると、「情報のひとかたまり」が視覚的にわかる

行間はフォーマット > テキスト > 間隔で調整できます。

ソースコードのシンタックスハイライトはRubyMineからコピペで実現

今回、スライドの中で使用したソースコードはシンタックスハイライトが適用されています。

これはどうやったのかというと、RubyMine上で作ったソースコードをKeynoteにコピペしただけです。

RubyMine上で編集したソースコード

ブラウザやVS Code上のコードをコピペ、でも良さそう

動画の中では「RubyMineからコピペ」以外の方法を紹介しませんでしたが、今試してみたら「ブラウザのコードをコピペ」でも色情報がそのままコピーできました。

以下はQiita上のソースコードをKeynoteにコピペした例です。

また、僕は試していませんが、「VS Codeでも色情報をコピーできた」と読者の方から情報をいただきました（@makicamelさん、情報ありがとうございます！）

選択しにくいオブジェクトは「オブジェクトリストを表示」で選択する

スライドの作り方によっては、あるオブジェクトが別のオブジェクトに重なってしまい、下側に隠れたオブジェクトを選択しづらい、ということが起きたりします。

こういう場合は画面右上の「表示」から「オブジェクトリストを表示」を選ぶと、リストの中から好きなオブジェクトを選択することができます。

オブジェクトのグループ化

あるオブジェクトとあるオブジェクトは常に同時に移動させたい、という場合はオブジェクトのグループ化を利用します。

たとえば以下は「四角オブジェクト」と「星オブジェクト」をグループ化する例です。

グループ化すると、常に「2つで1つのオブジェクト」として扱えるようになります。
（2つ以上のオブジェクトをグループ化することもできます）

Commandキーを押しながらドラッグすると自由にオブジェクトを動かせる

矢印オブジェクトの先端や終端を移動させようとすると、Keynoteが勝手に矢印オブジェクトを他のオブジェクトに吸い付けてしまい、思った位置に矢印を動かせない場合があります。
そういう場合はCommandキー押しながらオブジェクト（白い四角の部分）をドラッグすると、好きな場所に矢印の先端や終端を動かすことができます。

矢印オブジェクト以外でも、Keynoteが「余計なお世話」で勝手にオブジェクトの位置を変えてくる場合は「Commandキーを押しながらドラッグ」で自由にオブジェクトを移動させることができます。

その他、スライド全般に言えるアドバイス

テキストを絶対に折り返さない

僕のスライドでは「絶対にテキストを折り返さない」というこだわりがあります。

これは以下の理由からです。

• スライド内のテキストが長文になるほど、聴衆はスライドの文章を読むのに必死になり、登壇者の話を聞かなくなるから
• スライドに言いたいことを全て書いてしまうのであれば、講演として話す意味がないから（それならスライドを印刷して配ってしまえば良い）

こうした理由からスライドのテキストはシンプルにまとめて、言いたいことはできるだけ口頭で伝えるようにしています。

折り返すなら読みやすい位置で

（僕はやりませんが）折り返しが発生するぐらい長いテキストを書く時は、最低限、読みやすい場所で明示的に改行を入れるようにしましょう。

❌
私は長いテキストをどうしても書きた
いので許してほしい

⭕️
私は長いテキストをどうしても
書きたいので許してほしい

会場のスクリーンに合わせた縦横比を選ぶ

スライドを作り始める前に、会場のスクリーンの縦横比を確認し、その縦横比に合ったスライドを作るようにしましょう。
縦横比が一致しないとスクリーンに余白ができてしまうので、貴重な表示スペースを有効活用できません。

特にソースコードを表示したりするときは、画面を目一杯使ってコードを表示しないと、後ろの席から見えにくい小さな字になってしまったりすることがあります。

リハーサル中に一番後ろの席から自分のスライドを見てみる

もしリハーサル時間に余裕があれば、何枚か自分のスライドを一番後ろの席から見て、スライドの見やすさをチェックしてみてください。
自分でチェックすると内容がわかっている（＝見にくくても見えている気がしてしまう）ので、できればスタッフの人や他の登壇者を呼んで「スライドの文字、ちゃんと見えますか？」と質問するとさらに良いです。

Tama Ruby会議01では、「サンプルコードの緑色の字が見づらい」というフィードバックがあったので、講演開始までに急いで文字の色を修正しました。

↓ 修正前（文字列を表す緑色の字が見づらかった）

↓ 修正後（会場で急いで文字色を修正した）

海外の無料テンプレートを使うといい感じのデザインになるかも

"keynote template free"みたいなキーワードでググると、海外のKeynote用無料テンプレート集がたくさん見つかります。

Keynote標準のテンプレートやAzusaテンプレートを使うと、他の人とかぶることがあるので、他の人とちょっと差を付けたいときは海外の無料テンプレートを探してみると良いかもしれません。

ちなみに今回僕が使ったのはこちらのテンプレートです。
Free Keynote Templates - Business Strategy Pitch Deck

アニメーションはほどほどに

アニメーション機能を使い始めると面白くていろいろ遊んでしまいたくなりますが、派手なアニメーションを多用しすぎると聴衆に「ウザい」と思われてしまい逆効果になります。

僕は「原則として、表示と非表示のシンプルなアニメーションだけを使う」「それ以外の動きのあるアニメーションは、ここぞというタイミングだけに使用する」というポリシーにしています。

動画を見るのが一番早いから動画を見て！！（再）

冒頭にも書いたとおり、動画の方がより詳しい説明になっています。
実際にスライドを作ろうとしている人はこのブログだけでなく、動画の方もチェックしてみてください。

まとめ

というわけで、このエントリではITエンジニアのみなさん向けに、もしかしたら知らないかもしれないKeynoteの便利機能や使い方のコツをいろいろと紹介してみました。

Keynoteを使ってスライドを作ろうとしている人は、この記事を参考にしてカッコよく、わかりやすいスライド作りにチャレンジしてみてください！

参考図書：プレゼンの心構えや、スライドデザインを学べる書籍

このエントリはKeynoteの使い方に主にフォーカスしましたが、ツールによらない「プレゼンをする上で大事な考え方や心構え」を学ぶには「パワー・プレゼンテーション」という書籍がオススメです。
絶版になっているため新品では買えませんが、Amazon等で中古本が安く買えるので、買っておいて損はないと思います。

ちなみに、上で説明した「スライドの文字を折り返さない」という考え方もこの本の中で説明されていたものです。

パワー・プレゼンテーション (グロービス思考シリーズ)

また、テキストや図形の配置、マージンの取り方など、視覚的なスライドデザインについては「ノンデザイナーズ・デザインブック」の内容が参考になります。

ノンデザイナーズ・デザインブック [第4版]

あわせて読みたい

スライドの内容そのものについてはこちらのエントリで紹介しています。
blog.jnito.com

Tama Ruby会議01で「テストコードの役割」について発表してきました #tamarubykaigi01

はじめに

2019年7月6日、渋谷のGMO Yoursさんで開催されたTama Ruby会議01で「なぜテストを書くの？（または書かないの？） 〜テストコードの7つの役割〜」という発表をしてきました。

スライドはこちらです。

このエントリではこの発表の紹介やイベントの感想を書いていきます。

この発表テーマを選んだ経緯

スライドの9枚目にも書いたとおり、もともとは「RSpecを題材にしたテックな話を」とお願いされていました。

しかし、ネットなどを見ていると、「テストって難しい」「RSpecがわからん」と言っているプログラミング初心者さんたちは、テストについて何か根本的な思い違いをしているんじゃないか？という漠然とした疑問や懸念を僕は持っていました。

テストにおける「土台となる考え方」を会場のみなさんと共有したかった

そういう状態でRSpecのテクニック的な話をしてもどこか歯車がかみ合わないというか、発表を聞いた直後は「なるほど、完全に理解した」と思っても、数日経つと結局めぐりめぐって「テストって難しい」「RSpecがわからん」と同じことを言い始めるような予感がしました。
なので、「魚を与えるよりも魚の釣り方を教える」ではなく、「魚の釣り方を教えるよりも、なぜ魚を釣るのか、それは魚でないといけないのか」という話をしたいなと思いました。

また、僕自身、テストを書くときは「○○○だから書く」と何か一つに理由が定まっているわけではなく、あるときはこういう目的で、またあるときはこんな目的で、と、テストを書く目的がいくつかのパターンに分かれていることをなんとなく感じていました。
ただ、これも「なんとなく自分の頭の中にある」というだけで、きれいに整理整頓したことはありませんでした。
そこで、この機会に「なんとなく自分の頭の中にあるパターン」を整理して言語化しようと思いました。

せっかくたくさんの人が集まるいい機会のなので、表面的なテクニックよりもあえて「土台となる考え方」を語って、参加者のみなさんとそれを共通認識として共有する方が価値があるんじゃないか、そして、Tama.rbというRubyコミュニティも比較的初心者向けのRubyコミュニティなので（たぶん）、参加者層を考慮してあえて「基礎の基礎」を語ることはそんなに悪くないのでは？と思い、今回はこのような発表テーマを設定してみました。

当たり前のことをあえて明文化することの価値

とはいえ、発表をする前は「簡単すぎる」「基礎的すぎる」「テック要素が薄くて物足りん」とdisられるんじゃないかと、ちょっと心配していました。
ですが、蓋を開けてみると思いのほか好評だったようで、「このテーマを選んで正解だった」と胸をなで下ろしました。

みなさんの感想はこちらのtogetterページにまとめられています。

ところで、僕は以前どこかで「テーブル設計における正規化理論は、効率良くデータを保存しようとすると誰もが行き着く当たり前の考え方だ。しかし、これをあえて言語化、明文化したことに正規化理論の価値がある」というような話を聞いたことがあります。
自画自賛するわけではないですが、今回の僕の発表も「テストを長年書いている人なら、誰でも経験則として当たり前に思えること」をあえて明文化したことに価値があったんじゃないかなーと思っています。

はじめての基調講演

今回の発表はTama Ruby会議01における基調講演（キーノート）として依頼されたものでした。
基調講演をお願いされたのは今回が初めてで、何をすればよくわかっていなかったのですが、「基調講演の役割は、参加者全員の意識を統一して、あとに続く発表へスムーズにつなげていくことなんじゃないか」と僕は考えました。

そこで、今回の発表では「普段通りの発表 + 最後にこのイベント全体について当てはまりそうな話」という構成にしてみました。
おそらくですが、「基調講演っぽい発表」にはなったんじゃないかと思います。（実際に参加されたみなさん、どうでしたか？）

自己紹介タイムはなし！

あと、これは余談ですが、今回は実験的な試みとして「自己紹介をまったく入れない発表」にチャレンジしてみました。
Twitterの反応を見る限り「で、あんた誰？」とは言われなかったようなので、これはこれで成功だったかもしれませんw

登壇中の僕です（photo by @katsumata_ryo）

イベントの感想等

ここからあとは、Tama Ruby会議01で印象に残っている話をいくつか書いていきます。

持ち時間＝10分制が意外と良かった

Tama Ruby会議01で面白いなと思ったのは基調講演の僕と五十嵐さんを除いて、各発表者の持ち時間が10分間だったことです。
最初は「LTでもないのに、持ち時間10分は短すぎるのでは？」と思いましたが、実際に聞いてみると意外とそうでもありませんでした。
持ち時間が短いぶん、いろんな人の発表が聞けるというメリットがあるので、これはこれでアリかもしれません。

人数は少ないものの、女性の方が元気そうだった

僕は「女性が参加しやすい（でも女性限定ではない）Rubyコミュニティ」である、TokyoGirls.rbの主催者なので、女性の参加率もちょっと気になっていました。
ぱっと見た感じ、女性の参加率は1割ぐらいかな、という印象です。

当日の会場の様子です

理想は男女半々、最低でも3割ぐらいは女性に参加してほしいと考えている人なので、「やっぱりまだまだ女性は少ないなあ」という感はあります。

ただ、参加していた女性エンジニアは、みなさんアクティブで元気そうという印象を受けました。
登壇者の中に女性が2人いたのも評価したいポイントです（しかも、お二人とも短い経歴のわりに骨太な発表だった！）。

そういう意味では「女性エンジニアがもっとグイグイとRubyコミュニティを盛り上げてくれる余地は十分にある！」と感じました。

TokyoGirls.rb Meetup vol.2も開催せねば！

懇親会では女性エンジニアの方から「TokyoGirls.rb Meetupの2回目はやるんですか？1回目がすごく良かったんで、また行きたいです」と質問＆リクエストも受けました。

はい、やります！（断言）

ただし、なかなか手が回らなくて開催はもう少し先になるかもしれません。
ですが、「1回やって終わり」にするつもりはありませんので、もうしばらくお待ちください！！

顔と名前とTwitterアイコンが一致しない問題

懇親会等では「伊藤さん、いつもチェリー本やQiitaでお世話になっています！」とたくさん声を掛けてもらいました。
そんなふうに声を掛けてもらうのは、ちょっと気恥ずかしい反面、大変ありがたいです。

ただ、非常に申し訳なく思うのが、ほとんどの人について「ごめんなさい、僕はあなたのことをよく知らないんです」状態になってしまうことなんですよね・・・。
でも、イベントが終わったあとにふと振り返ってみると、「あ、もしかしたら、あのとき声を掛けてくれたあの人は、もしかしたらこのTwitterアイコンの人だったのかもしれない！（でも、もはや確認するすべがない・・・）」と思うことがちらほらありました。

Twitterアイコンがわかれば、まだ何とかなるかも？

Twitterでよくいいねやリツイートをしてくれたりする人は、なんとなく「よく見かけるTwitterアイコンの人」という形で僕の記憶に残っていたりします。
なので、名札にTwitterアイコンをドカーンと大きく載せてくれていれば、僕も「あ、このアイコン見たことあります！」と、話しかけてくれた人を認識できていたかもしれません。

ですので、イベントの主催者さんは、参加者各人のTwitterアイコンシールを作って名札に貼ってもらう、みたいなことをしてくれると、懇親会での参加者同士のコミュニケーションがさらに盛り上がるかもしれません。
（僕も次回のTokyoGirls.rbとかで、ちょっと検討します）

ちなみに余談ですが、僕はこんなふうにオフラインで会ったときに「顔と名前とTwitterアイコンが一致しない問題」を極力避ける目的もあって、あえて実名と顔写真アイコンでネット活動をしております。

SNSも実名と顔写真アイコンにしておけば、覚えてもらいやすいですよ！

まとめ

というわけで、このエントリではTama Ruby会議01での僕の発表内容と、このイベントの感想をあれこれ書いてみました。

素敵なイベントを主催してくれたTama.rbのみなさん、会場や美味しい料理・飲み物を提供してくださったスポンサーのみなさん、そして参加者のみなさん、登壇者のみなさん、どうもありがとうございました！

次回は渋谷を離れて、多摩地域での開催ですかね？
僕の好きなTMネットワークが多摩出身らしいので、多摩開催も期待しています！w

参考文献

スライドの中で紹介していた、各種書籍のリンクを載せておきます。

テスト駆動開発

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

はじめて学ぶソフトウェアのテスト技法

leanpub.com

ちなみにスライドの33枚目に出てきたRGB変換プログラムのコードは、拙著「プロを目指す人のためのRuby入門」からの抜粋でした。

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)

あと、僕の発表スタイルは「パワー・プレゼンテーション」という書籍の影響を大きく受けています。
自分も上手に発表できるようになりたい！と考えている方はチェックしてみてください。

パワー・プレゼンテーション (グロービス思考シリーズ)

来月の登壇内容を思案中。スライドの構成を考えるときはいつも「パワー・プレゼンテーション」という本を読んで、初心を思い返すようにしています。
あなたのブログに「WIIFY(ウィッフィー)」はありますか？ - アウトプットの価値は受け取る側のメリットで決まる、というお話 https://t.co/rR838gXGCx pic.twitter.com/HroDvutAFH

— Junichi Ito (伊藤淳一) (@jnchito) June 16, 2019

あわせて読みたい

この発表で使ったスライドの作り方（Keynoteの便利テクニック）をこちらのエントリで紹介しています。
blog.jnito.com