give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

【書評】『絶対に音が良くなる「ギター調整」』を読んでみた

最近、数年ぶりに実家からFender USAのストラトキャスター(たぶん1978年製)を持ち帰ってきました。

ただ、なんか音がモコモコするというか、シャキッとしないというか、抜けが悪いというか、「ストラトだし、もうちょっとカラッと乾いた音にしたいんだよな〜」と思っていたところ、最近こんな本が発売されていることを知ったので、さっそく買ってみました。

読んだ感想

ギターの鳴りや音色を「2倍音」と「3倍音」という倍音の特性に着目し、どちらの倍音を増やすかをギターの調整によってコントロールしていく、というアプローチはちょっと科学的で非常に興味深かったです。

が、本書は最初から最後までひたすら「2倍音が〜」「3倍音が〜」という話題に終始していて、「なるほど、ようわからん」となってしまいました。

いや、理屈はしっかり説明されているので、説明を読む限りは「なるほど」という気はするのですが、そもそも「2倍音」「3倍音」という音の響きが完全にイメージできないので、「○○すると3倍音寄りの音になります」と言われても、「ふーん……」という気持ちになりました。

(そして、僕のストラトを「カラッと乾いた音」にするには2倍音寄りにするのか、3倍音寄りにするのか、どっちなんだい??)

百聞は一聴にしかず。具体的な音の違いを耳で確認したかった

いや、「2倍音」「3倍音」の音の特性も説明されていますし、その特性を理解するための具体例(アーティストの楽曲)も紹介はされているのですが、僕としてはそれよりもYouTube動画なり、付属CDなりで音の違いを聞きたいと思ってしまいました。

たとえば「デジマート地下実験室」みたいな形で調整前後の音の違いを聞き比べることができたら、とても良かったのに、と思います。


www.youtube.com


www.youtube.com


www.youtube.com

もちろん、「自分のギターで試せばいいやん」という考え方もできますが(本書の中でも「すぐ試せるし、元に戻せる」とは書いてありました)、そうは言っても自分のギターで試行錯誤するのには、それなりにまとまった時間が必要です。
専門職の人ならともかく、趣味でギターをやっている人間はなかなか時間の捻出が難しいと思います(あと、「すぐに戻せる」と言われても、下手に素人がいじると元に戻せなくなるリスクもありそう)。

最終的には自分で試行錯誤する必要はあるとは思うものの、せっかくの書籍なので、「○○する前と、したあとの音色はだいたいこんな感じ」というサンプルを提示してくれたら良かったのにな〜と思いました。

本のタイトルと内容のギャップを感じた

あと、「ギターの調整」というと、ピックアップの高さ調整とか、弾きやすさの調整とか、いろんな観点があると思いますが、前述の通り本書は終始「ギターの調整で倍音をどうコントロールするか」という点だけにフォーカスしています。
それゆえ『絶対に音が良くなる「ギター調整」』という本のタイトルが内容にマッチしてない(読者が受け取るイメージの幅が広すぎる)と感じました。

本書を読む前はタイトルから汎用的、かつ入門的な内容を想像したのですが、実際に読んでみると「倍音のコントロールに特化した本」という印象を受けました。

僕がタイトルを付けるなら、

『2倍音・3倍音を制御して好みの音色に変える「倍音駆動ギター調整術」』

みたいな感じでしょうか。
もしこんなタイトルであれば、読み終わった後も違和感がなかったように思います。

繰り返しになりますが「ギター調整」というキーワードだけでは汎用的な内容を想像してしまうので、本書の専門性・特殊性をうまく表現できていないように思います。

まとめ

というわけで本エントリでは『絶対に音が良くなる「ギター調整」』の書評を書いてみました。

「2倍音・3倍音を制御して好みの音にする」という観点や発想はこれまで自分の中になかったので、とても興味深いと思った一方、「ちょっとでもいいから実際の音を聞きたい!」と思ったのと、「倍音調整以外のギター調整の話題も知りたかった(もっと初心者向けで、もっと幅広い話題をカバーしてくれるのを期待していた)」と思ったのが、個人的にはちょっと惜しかったです。

なので、ギター調整をすでにある程度自分でやっていて、そこからさらに新しい視点を取り入れたいと考えている人にとっては本書は良いと思いますが、僕のように「初心者なのでイチから教えてほしいっす!」という人は、先に別の本を読んだ方がいいかもしれません。

ちなみに以下はAmazonでそれっぽいキーワードで検索したメンテナンスに関する本です。
どれも実際には読んでないので内容の保証はできませんが、ギター調整初心者の人はこうした本の中に自分の目的にあった本があるかもしれません。

プログラミング初心者さん向けに技術力を上げる記事を寄稿しました (Software Design 2023年3月号)

お知らせ

Software Design 2023年3月号(現在発売中)の「ITエンジニアスキルアッププログラム」という特集に、「テクニカルスキルを磨く」という記事を寄稿しました。


どんな話が載ってるの?

プログラマ・ITエンジニアとしてこれからどんどん成長していきたい初心者さん向けに、以下のような話を書きました。

  • 技術をどう学ぶべきか
  • プログラミング力以外にエンジニアとして必要とされるスキルは何か
  • 学びをさらに深めるためには何をすべきか
  • 勉強が苦しい・しんどい、と感じたときはどうすれば良いか
  • etc

スキルアップの方法についてはもっといろいろ書きたい内容があったのですが、限られた紙面なので「その中でも特に」と思う内容を厳選して記事にしています。それゆえ、結構「濃い」内容になっているので、「これからやってくぞ!」と思っているプログラマのみなさんにぜひ読んでいただきたいです。また、新人の指導に当たっているエンジニアにも参考になる部分があると思います。

みなさんぜひチェックしてみてください!

謝辞

本記事を執筆するにあたり、フィヨルドブートキャンプメンターの井上夏樹さん、受講生の 益子浩太さん、rira100000000 さんに原稿のレビューをしていただきました。

「なるほど、そう言われてみると確かに」とか「あ、確かにそれも大事!」と思うような有益なフィードバックをたくさんいただいたおかげで、記事がさらに良いものになりました。みなさん、どうもありがとうございました!

あわせて読みたい

今回の寄稿記事に書いた内容は、先日発表した「良質な技術記事を量産する秘訣」にもちょっと関連があります。
両方読んで実践すれば、スキルアップの効果がさらに高まるはずです💪

blog.jnito.com

雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発

(この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました)

僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト(TDD)で開発するとは限りません。
今業務でやってるタスクはこんなふうに進めてます。

雑に動くものを作る
  ↓
見た目をきれいにする&機能を作り込む
  ↓
テストを書く
  ↓
リファクタリングする

この順番で開発する理由を以下に述べます。

雑に動くものを最初に作る理由

最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。

これはこれから作ろうとしているものの認識が合っているかどうかをPO(プロダクトオーナー)に確認するためです。
実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。

また、開発者としてもコードを書きながら「あれっ、こういう場合はどういう仕様にしたらいいんだろう?」という考慮漏れの仕様が見つかったりすることがあります。

Tips: あとで作り込む部分は忘れないように適宜TODOコメントを入れておくと良いです。

その次に見た目をきれいにしたり、機能を作り込んだりする理由

方向性を確認したら、見た目や機能の詳細を作り込んでいきます。

この時点でテストを一緒に書いていくこともありますが、「テストを書くのは時間がかかりそうだな」と思ったら、テストを全く書かずに進めることもありますたとえば、その機能に関連する既存のテストがなく、テストコードをゼロから書かないといけない場合などです。(一方、「これはテストを先に書いた方が、手と目で動作確認を繰り返すより速くなりそうだな」と判断することもあります。よって、書く、書かないはケースバイケースです)。

こうする理由は万一、何らかのトラブルでスケジュールが遅れそうになったときに「テストもないし、コードも汚いけど、最悪この状態でリリースすることは可能」という状態に持っていくためです(あくまで最悪のケースですよ!!)。

「テストをがんばって書いてたら当初のリリーススケジュールをオーバーしてしまった」よりも、「テストはまだ書けてないけど、とりあえずリリースはできた。順番が逆になったけど、リリース後にテストを書こう」の方がビジネス的には望ましいはずです。

補足:テストを書かずにリリース=不具合を残したままリリース、ではない

テストを書かずにリリースするときでも、最低限以下の2点はクリアしておく必要はあります。

  • 追加した機能についてはしかるべき担当者が手と目で動作確認している(=手動テストはクリアしている)
  • 既存の自動テストはすべてパスしている

つまり、「テストを書いていない」というのは「デグレしないことを担保する自動テストがないだけ」の状態です。
決して「手動テストすらやらずに、不具合の可能性を残したままリリースする」という意味ではありません。

もちろん、「テストを書かずにリリース」はあくまで最後の手段であって、やむを得ない理由がない限りやっちゃダメです🙅‍♂️

最後にテストを書いてリファクタリングする理由

一通り実装が終わったらテストを書きます。テストファーストならぬ、「テストラスト」ですね。

一通り実装が終わって「最悪このままでもリリースできる状態」になっているので、精神的な余裕をもってテストを書くことができます。

ちなみに「リファクタリングをしてからテストを書く」のではなく、「テストを書いてからリファクタリングする」というのがポイントです。

リファクタリングは「リファクタリングの前後でプログラムの挙動が変わらないこと」が大前提です。
この「挙動が変わらないこと(リファクタリングが原因でプログラムが壊れたりしないこと)」を担保するためにはテストコードの存在が必須です。

もしテストより先にリファクタリングをやってしまうと、挙動が変わらないことを開発者自身の手と目で担保しなければなりません。
これは非効率ですし、うっかりミスでプログラムを壊してしまう恐れもあります。

参考:コードレビューも分割して良い

作成する機能が大きいときは上記のステップが終わるたびにプルリクエスト(PR)を作成して、コードレビューしてもらいましょう。
すなわち、

雑に動くものを作る
  ↓
PR作成&コードレビュー
  ↓
見た目をきれいにする&機能を作り込む
  ↓
PR作成&コードレビュー
  ↓
テストを書く
  ↓
PR作成&コードレビュー
  ↓
リファクタリングする
  ↓
PR作成&コードレビュー

とするわけです(テストとリファクタリングはまとめてコードレビューでも可)。
あ、もちろんコードレビューが終わってもmainブランチにはまだマージしませんよ。mainブランチにマージするのはリファクタリングが完了してからです。

特に「雑に動くものを作る」段階で一度コードレビューしてもらうことは重要です。
なぜなら、コードレビューを受けることで技術的な方向性の根本的な誤りを指摘してもらえるかもしれないからです。

また、最後にまとめてPRをどーん!!と作成すると、diffが大きくなりすぎてレビュアーが苦労する可能性もあります。
PRはなるべく小口化することを心がけてください。

テストファーストで作ることはないの?

いえ、もちろんテストファーストで作るときもあります。
僕は以下の条件がどちらもYESになったときにテストファーストで開発します。

  • プログラムの仕様が明確である(作りながら「どうしようかな?」と考える部分がない)
  • その仕様を担保するテストコードをすらすら書ける自信がある(=テストを書くコストが低い)

たとえば、「 "alice@example.com" を "a...e@example.com" のように、ユーザー名の最初と最後の1文字だけ残してマスキングするメソッドを作れ」という要件があったりした場合は、上の2つの条件を満たすので次のようなテストコードを先に書いてしまいます。

RSpec.describe User, type: :model do
  describe '#masked_email' do
    context 'ユーザー名が3文字以上' do
      example do
        user = User.new(email: 'ken@example.com')
        expect(user.masked_email).to eq 'k...n@example.com'

        user = User.new(email: 'alice@example.com')
        expect(user.masked_email).to eq 'a...e@example.com'
      end
    end
    context 'ユーザー名が2文字' do
      example do
        user = User.new(email: 'me@example.com')
        expect(user.masked_email).to eq 'm...e@example.com'
      end
    end
    context 'ユーザー名が1文字' do
      example do
        user = User.new(email: 'x@example.com')
        expect(user.masked_email).to eq 'x...x@example.com'
      end
    end
  end
end

上のテストコードは何もドキュメントを見ずに、テストも一切実行せずに、エディタ上でひたすらコードを打ち込んだものです。
あとはmasked_emailメソッドを実装してテストを全部パスさせればいいだけですね。

こういうケースはテストファーストで開発するスタイルが有用です。

不具合修正するときもテストファースト

他にも不具合を修正するときもテストファーストで修正します。
具体的には以下のような流れです。

エラーを再現させるテストコードを書く(この時点ではテストの結果はRED🚨)
  ↓
エラーを修正する(場合によっては修正する前に、デバッガも併用しながらテストを実行してエラーの原因を調査する)
  ↓
テストがパスすることを確認する(テストの結果はGREEN✅)

テストを書いておけば不具合の再発も防止できるので一石二鳥です✌️

あわせて読みたい

そもそもテストコードってなんで必要なんだっけ?という基礎から学びたい方はこちらのスライドをどうぞ。

RSpecを使ってRailsのテストをすらすら書けるようになりたい!という人は、「Everyday Rails - RSpecによるRailsテスト入門」をどうぞ。
leanpub.com