give IT a try

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

恥ずかしがらずにオープンな場で積極的に質問していきましょう、という話

はじめに

先日、Teratailに以下の質問が挙がっているのを見つけました。

Ruby - irbと打つと「can't find gem irb」とエラーが出ます。どうしたらいいでしょうか|teratail

質問の内容は、「rbenvのインストール後、irbを起動しようとするとエラーが出て起動しない」というものです。
質問者の方は拙著「プロを目指す人のためのRuby入門」の学習を進めようとして、この問題に遭遇したそうです。

エラーが出てirbが起動しない、という現象は今まで聞いたことがありません。
irbはRubyが持つ基本機能の一つだからです。

原因は僕もはっきりわからなかったのですが、"rbenv-communal-gems"というあまり聞き慣れないrbenvプラグインを使っていたので、もしかしたらこれが原因ではないかと推測しました。
そこで、「もしかすると"rbenv-communal-gems"が原因ではないですか?」回答を入れたところ、予想が的中したようで、irbが正常に起動するようになったみたいです。

質問者の方は「まさかの著者様からの回答、本当に感動しています。ありがとうございます!こんな事あるんですね」と喜んでおられました。

クローズドな場所での質問よりも、オープンな場所での質問の方が嬉しい

質問者の方だけでなく、質問を受ける側(つまり僕)としても、こんなふうに「みんなから見える場所=オープンな場所」で質問してもらえる方が嬉しいです。

その反対で、ときおりTwitterのDMなどで書籍「プロを目指す人のためのRuby入門」に関する技術的な質問を受けることがあるのですが、こういうクローズドな場所で質問するのはなるべく避けてほしいなあと感じます。

また、この話はネット上の質問だけでなく、IT系勉強会や講演会などでもほぼ同じようなことが言えます。

その理由について、僕が普段考えていることを以下につらつらと書いていきます。

個人的に質問してくる人はフリーライダーだ、という意見

ちょっと前に、ネットで以下のツイートが話題になったことがありました。

上のツイートの画像に書いてあることは以下のとおりです。

  • 海外から来日したある講演者いわく、講演の最後に「質問はありますか?」と尋ねても、日本人は誰も手を挙げない。
  • 講演が終わると名刺交換の列ができ、その最中に「実は質問が・・・」と切り出す人が数名出てきた(もしくは後日メールで質問してきた)。
  • その質問をみんなの前でしていれば、会場の全員が知識を共有できた。
  • 個人的なやりとりで回答を引き出そうとするのは、知識を独占しようとしていることと同じだ。こいつらはフリーライダーだ!(怒)

このツイートを見て、「なるほどなー」と僕は思いました。
たしかに個人的なやりとりで回答を引き出すのは、その人の知識を独占しようとしていることと同じになってしまいますね。

「恥の文化」にとらわれがちな日本人

もちろん、質問する側の気持ちもわかります。
質問する側の気持ちとしてはおそらく、

  • こんな初歩的な質問をみんなの前でするのは恥ずかしい。
  • きっと周りの人はみんな理解しているのに、自分だけが理解できていないに違いない。
  • こんな質問をしたら、みんなからアホだと思われてしまう。

と、こんなふうに思っているのでしょう。

日本人の行動様式は「恥の文化」で特色づけられていると言われます(参考)。
なので、「恥をかきたくない」という気持ちが湧きあがると、その気持ちが最優先されてしまいます。

僕も日本人なのでその気持ちはわかります。
が、技術コミュニティにおいてはその気持ちは捨て去った方が良いです。

あなたがわかってないことは、周りのみんなもわかってない

そもそも、「みんな理解しているのに、自分だけが理解できていないに違いない」と思っていることは、たいてい周りの人も同じように感じています。
ですので、そこで自ら手を挙げて質問をすれば、周りの人はきっと「よく質問してくれた!ありがとう!」と思ってくれるはずです(口に出して言う人は滅多にいないので実際のところはわかりませんが)。

講演者は質問が大好物

それに、講演会のような場面では質問がたくさん挙がった方が講演者は嬉しいです。
逆に質問がまったく出てこないと、講演者は「退屈だったのかな?」「全然理解できなかったのかな?」と不安になります。

つまり、積極的に質問することは、講演者を喜ばせることにもなるのです。

オープンな場所で質問してくれた方が時間の節約になる

ネット上での質問に関していえば、Teratailやスタックオーバーフローのような場所で質問してくれると、僕のような技術書の著者にとっては「他の誰かが答えてくれるかも?」という期待ができます。
DMで質問されると自分以外に答える人がいないので、確実に自分の時間が奪われてしまいます。

加えて、TwitterのDMや、Facebookメッセンジャーのようなチャットツールはたいてい技術的なやりとりをするようには作られていないため、コードやエラーメッセージを貼り付けられても読むのがしんどい、というデメリットもあります。(下の写真を参照)

f:id:JunichiIto:20190703112509p:plain:w300
過去に届いた質問DMの例

なので、技術的な質問はMarkdownのような技術者にとって使いやすいフォーマットを使ってもらう方が、お互いやりとりしやすく、時間の節約になります。

追記その1:あなたが質問すると他の人のハードルが下がる

IT系勉強会などで周りの人が「質問したいけど、恥ずかしくて質問できない」という状況だった場合、あなたが先陣を切って質問することで、他の人がぐっと質問しやすくなることがあります。

・・・という話を以下のツイートで見かけて「たしかに!」と思いました。

追記その2:適切な質問かどうかは講演者 or 司会者の判断に任せましょう

「その場では上手に疑問点が整理できなかったので、懇親会で個人的に質問してしまった」という以下のツイートを拝見しました。

もちろん、質問の内容によっては講演者が回答に困ったり、やたら時間を食ってしまったりする可能性はあります。
ですが、もしそうなった場合は講演者が「あとで個人的にお話ししましょう」と言ってくれたり、司会者が「ちょっとその質問はまたあとで」とやりとりを中断してくれたりするはずです。

ですので、何か疑問に思った点があれば、とりあえず質問してみて、講演者や司会者の反応を見る方がよいと思います。

追記その3:運営側も参加者の心理的安全性を高める工夫を

ここまではずっと参加者に対して「恥を捨てて積極的に質問しよう」というお話をしてきました。
しかし、暗黙の了解として参加者一人一人に「恥を捨てて積極的に質問する努力」を期待するのはなかなか難しいです。

ですので、運営スタッフも勉強会のオープニングで「質問はみんなのため、講演者のためですよ」と呼びかけて、参加者の心理的安全性を高めるようにした方がいいと思います。

実際、先日主催したTokyoGirls.rb Meetupでもそのようなトピックをオープニングスライドに盛り込みました。

f:id:JunichiIto:20190702100424j:plain
TokyoGirls.rbのオープニングで使ったスライドの1コマ

その甲斐あってか、各講演のあとには参加者からたくさんの質問が挙がっていました。

追記その4:質問がなければ、代わりに感想を伝えましょう

本当に疑問点がなかった場合、そして会場の誰からも質問が挙がらなかった場合は、「これは質問ではなく、ただの感想なのですが・・・」と、感想だけでも講演者に伝えると良いです。
何かしらフィードバックを伝えることで、壇上で質問を待っている講演者の「つまらなかった?」「わかりにくかった?」という不安な気持ちを和らげることができます。

追記その5:このツイートの言うとおり

こんなツイートを見つけたので貼っておきます。まさにそのとおりですね。

まとめ

というわけで、このエントリではオープンな場所で積極的に質問していくことの重要性を書いてみました。

上で述べたように、積極的に質問をすることは自分のためではなく、周りの人や講演者を喜ばせることにもつながります。
「恥ずかしい」と感じるのはあなたが日本人だからです。「恥の文化」に染まっているからです。

「質問したい、でも恥ずかしい」と思ったときは、意識的に自分の「恥」を窓から放り投げるように心がけましょう😉

技術記事を書くことで得られる5つの効能

先日、Qiitaの技術記事を書いているときに、ふと「そういえば、技術記事を書いてると、こういういいことがあるよなー」と思ったので、それをつらつらと書いてみます。

題して「技術記事を書くことで得られる5つの効能」です。

f:id:JunichiIto:20190620073425j:plain

効能1:自分の理解が深まり、知識が定着する

「いいかげんな内容やウソは書きたくない」、「できるだけわかりやすく書きたい」と考えると、中途半端な理解や知識を必死に埋めようといろんなことを詳細に調べます。
その結果、記事を書く前よりもさらに自分の理解が深まって、知識が定着します。

効能2:「これ読んどいて」で説明が終わる

コードレビューとかをしていて何か指摘を入れたくなったとき、そのトピックに関して過去に自分で書いた記事があると、「この記事を読んで修正してください」の一言で済むことがあります。

コードレビュー以外でも、「先日こんな問題に遭遇しました。みんなも気を付けて!」と、社内に周知するときに役立ちます。

効能3:自分が思い出すのに便利

記事の読者が「未来の自分」になることもよくあります。
僕はしょっちゅう"正規表現 qiita"みたいなキーワードで自分の記事を検索して読み返しています。


効能4:有益なコメントが付くかもしれない

記事に間違いがあったり、さらに良い方法があったりすると、詳しい人がコメントをくれることもあります。
「しまったなあ、自分はまだまだ理解不足だった」と少し恥ずかしくなる気持ちはたしかにありますが、それ以上に「いい情報が手に入った!得したぞ!」と、僕はポジティブに考えるようにしています。

効能5:文章力が向上する

これは技術記事を書いたからといって即座に効果が上がるわけではありませんが、長年にわたってたくさん記事を書いているとちょっとずつ文章力が向上してきます。
仕事でメールを書いたり、Slackで同僚と会話したりするときなど、生きていく上では何かと文章を書く機会はたくさんあります。
文章力がなくて困ることはあれど、文章力があって困ることはないはずです。

その他・間接的なメリットやご利益

打算的な気持ちや下心をもって技術記事を書くことはどうかなと思いますが、記事を書いていると以下のような「間接的なメリット」や「ご利益」があるかもしれません。

他の人が喜んでくれるかもしれない

自分が困ったことは他の人も同じように困っている可能性が高いです。
自分が困っていたことと、その解決策をわかりやすくまとめておけば、他の人たちから「ありがとう」と感謝されるかもしれません。

バズるかもしれない

すごく役立つ記事や技術的に面白い記事だと爆発的な人気が出てバズるかもしれません。
その一方で、とんでもなくおかしな内容やモラルに欠ける内容を書くと炎上する恐れもあります。
「バズ」と「炎上」は表裏一体な点に留意しましょう。

「あの人はすごい人」と評価されるかもしれない

有益な技術記事をたくさん書いていると技術力を第三者に評価され、それが転職や昇給に役立つかもしれません。
さらに、商業誌からの執筆依頼や、IT系イベントでの登壇依頼が来ることだってあるかもしれません。

ただし、「転職したいから」「有名になりたいから」といった動機で技術記事を書いても、大した見返りは得られないでしょう。
むしろ、見返りを考えずに記事を書く方が、めぐりめぐって自分の評価に役立つはずです。
少なくとも、僕自身はそんなふうに考えています。

まとめ:より高い効能を得るために、「楽に書けない記事」を書こう

というわけで、このエントリでは僕が考える「技術記事を書くことで得られる効能」をあれこれ書いてみました。

ただ、効能を得るためには、ある程度の書き手(つまり自分自身)の努力が必要です。
楽に書ける記事には大した効能はありません。

楽に書ける記事というのは、たとえば以下のような記事です。

  • 「自分用メモ」と称して、第三者に分かりやすく説明する努力を放棄した記事
  • 技術記事というよりも、ただの日記になっている記事(今日は〜を勉強しました。明日は〜をやります、みたいな記事)
  • APIドキュメントや技術書の内容を切り貼りしただけの記事(悪い言葉でいうと劣化コピー)

逆に言うと、めちゃくちゃ調べて、めちゃくちゃ時間をかけて書いた記事ほど、高い効能が得られます。

ただし、ここでいう効能とは、あくまで前半に書いた「5つの効能」を指します。
時間をかけて書いた記事ほどバズりやすいとか、そういう話ではありません。
(そもそも、他人からの評価は基本的に自分では操作できないパラメータです)

もちろん、何を書くのかは個人の自由ですが、「何でもいいから書けばいいことがある」というわけではないので注意してくださいね😉

参考:最近Qiitaに書いた記事あれこれ

「実際僕がどんな技術記事を書いていたのか」という具体例を示すために、ここ最近書いていたQiita記事をいくつか紹介しておきます。


タイトルのとおり、13桁のISBNコードを10桁に変換するプログラムをRubyで書いてみました。


仕事でめちゃくちゃハマった不具合があったので、その内容を3つの記事に分けて書きました。


よく見かける「おまじない」について、「それってほんとうに必要なの?」と問いかけて見た記事です。


たとえコンソールプログラムであっても、MVCを意識して作った方がいいよ、という話を書きました。


「Rubyの関数とメソッドの違いって何?」という疑問をTwitterで見かけたので、僕なりの回答を書いてみることにしました。


その他、これまでに書いたQiita記事は以下のページに載っているので、興味がある人は覗いてみてください。

アルテオンのディナウディオ(DYNAUDIO)サウンドシステムを試聴してみた結果

はじめに

最近、車を買い換えました。
新しく買ったのはフォルクスワーゲンのアルテオン(Arteon)という車です。

f:id:JunichiIto:20190605111529j:plain
ボディカラーはチリレッドメタリック

ところで、アルテオンはメーカーオプションとして、高級オーディオメーカーであるディナウディオ(DYNAUDIO)のサウンドシステムを選択することができます。

f:id:JunichiIto:20190605083826j:plain
参考:「アルテオン」に新グレード! DYNAUDIOも選択可能に - 8speed.net

僕も妻も無類の音楽好きなので、「ちょっとでもいい音で音楽聴けるなら、このオプションも付けてみたい!」と思いました。
ですが、実際に試聴して比較してみた結果、いくつかの理由があって今回は見送ることにしました。

というわけで、このエントリではディナウディオ製のサウンドシステムを聴いてどう感じたのか、そして、なぜ標準オーディオを選択したのかについて書いてみようと思います。

ディナウディオの第一印象=あれ?音が悪い??

ディナウディオのサウンドシステムは、行きつけの販売店が「1日試乗」として貸し出してくれたアルテオンに付いていました。

f:id:JunichiIto:20190605105602j:plain
1日試乗で借りた白いアルテオン

「やったー!この試乗車、ディナウディオが付いてる!さぞかしいい音で鳴ってくれるんだろうな〜😆」とウキウキしながらいつも聴いてる音楽を鳴らしてみたところ・・・

あれ?・・・なんか普通?いや、むしろ音悪くない??

と思ってしまいました。

僕だけではなく一緒に乗っていた妻も同じ感想で、「これだったら標準オーディオの方が良くない??」と2人で話していました。

音がこもって聞こえる?

ディナウディオで音楽をかけると、全体的に音がこもって聞こえます。
ボーカルはどこか膜の向こうで歌っているように聞こえて、前に出てきません。

もしかしてイコライザーの設定が悪いのかな〜?と思って、いろいろ設定を変えてみるのですが、大きな変化がありません。
バス・ミドル・トレブルのようなイコライザーは付いているのですが、設定を変えてもそこまで大きく音質が変わらず、「気持ち、変わったかな?」と感じる程度です。

「もう、ディナウディオ、全然ダメじゃん!このオプションはバツ!!」・・・と言いたいところですが、わざわざお金を出して取り付けるオプションの方が標準オーディオよりも音が悪いというのはちょっと不自然です。
なので、急いで結論を出すのではなく、もう少しこのオーディオを研究してみることにしました。

すると、次のようなことがわかってきました。

相性のいい音源と悪い音源の差が激しい

J-POPや洋楽、ジャズやクラシックなど、いろんな音源をディナウディオでかけてみたところ、「お、これはすごくいいじゃん」と思える音源と、「うーん、やっぱりこもって聞こえる」と思う音源がハッキリと分かれました。

最近流行りのJ-POPをかけると、先ほど述べたような「こもって聞こえる」「膜の向こうでボーカルが歌ってるみたい」という聞こえ方をするものが多かったです。

一方、生楽器が中心のジャズや、R&Bテイストのモダンな洋楽などは、「すごく自然に聞こえるし、音の分離や全体的なバランスもいい」と感じました。

どうやら、中音域にいろんな楽器音が鳴っていたりする音楽だと、ピコピコ、ジャカジャカした音がボーカルの邪魔になって、ボーカルを奥に引っ込めてしまう傾向があるようです。
そういった音楽よりも、音と音の間に隙間やゆとりを十分もった音楽の方が、ディナウディオとは相性が良いように思いました。

なんとなくの想像ですが、ディナウディオは元の音源を一切味付けすることなく、フラットかつストレートに出力しているのかもしれません。
それゆえに、相性のいい音源と悪い音源に極端な差が生まれているような気がしています。

なお余談ですが、関係者の方が僕の感想とほぼ同じ内容をコメントしているページも見つけました。

DYNAUDIO JAPAN代表取締役の前田正人氏によれば、同社は「サウンドに手を加えることなく、アーティストがスタジオで耳にしたものだけを、原音に忠実に再生できるスピーカーを開発している」とのことだ。

VWと再タッグを組む「DYNAUDIO」のサウンドは、マニアならずとも感涙レベル! - CARSMEET WEB

音量を上げた方が気持ちいい

そして、相性のよい音楽に関しては、小さい音量で聴くよりも、音量をぐっと上げた方が気持ちよく聞こえました。
というのも、音量を上げた方がサブウーファーから引き締まった重低音をより鮮明に引き出せるからです。

また、音の密度が濃いというか、音の情報量が豊富なので、音量を上げると普段はあまり意識しないリバーブの余韻なども感じ取ることができます。
もちろん、オーディオの基本性能が高いので、音量を上げても音が割れたり、バランスが崩れたりすることはありません。

というわけで、「相性のいい音源」を「大音量」で聴くと、「おお、これはすごい!めっちゃいい音だ!!」とハッキリ感じられました。
まさにこれが「アーティストがスタジオで耳にしている音」なのかもしれません。
(その代わり、ボリュームを50%ぐらいまで上げているので、車外に音が漏れまくってしまいますが・・・😅)

標準オーディオは音源との相性を意識しなくて済む点がマル

一方、ディナウディオではない、標準オーディオはディナウディオの長所と短所をひっくり返したような特徴があります。
すなわち、

  • 音源との相性の良し悪しがほとんど気にならない(どんな音源でも平均点レベルの音がする)
  • でも、ややドンシャリ(=低音と高音を強調)気味に味付けされている気がする
  • 小さな音量で聴いても、まあまあいい音で聞こえる
  • その代わり音量を上げても大して感動は得られない
  • サブウーファーがないので、低域はディナウディオに比べると少しぼやけがち(が、そこまでひどいものでもない)

といった感じです。
また、高音域が少し耳障りに感じることがあるので、僕はイコライザーの設定でトレブルを少し削って聴いています。

最高か?と言われると、最高とまでは言えないのですが、それでも日常的に聴くぶんには必要十分な音で聴ける気がします。
標準オーディオの場合は、何よりも音源との相性を気にしなくて済むところが一番うれしいです。

結論:僕は標準オーディオで十分だと思った

このように比較した結果、僕は標準オーディオで十分だと思いました。

決定的だったのは、やはり相性の良し悪しです。
ディナウディオの場合、相性の悪い音源は明らかに「こもる」「ボーカルが引っ込む」という症状が出てしまうので、音源によってどうしても気持ちよく聴けないものが出てくるのが難点でした。
僕も妻もその日の気分でいろんなジャンルの音楽を聴きたい人なので、相性のいい音源だけをずっと聴き続けることはできません。

ディナウディオの、相性のいい音源をかけたときの気持ちよさや、サブウーファーから聞こえてくるクッキリした重低音はとても魅力的なんですけどね〜。
ですが、車はあくまで車であって、専用のオーディオルームではないので、そこまでがんばって高音質を求めなくてもいいかな、と僕は(そして妻も)思い、今回は標準オーディオを選択することにしました。

とはいえ、自分で試聴してみるのが一番です

このように僕は今回「標準オーディオで良い」という結論を出しましたが、だからといってディナウディオがダメと言うつもりはまったくありません。

普段からディナウディオと相性のいい音源を中心に聴く人であれば、ディナウディオはかなり有力な選択肢になると思います。

また、「こもる」「ボーカルが引っ込む」というのもあくまで僕と妻がそう感じただけなので、人によってはそこまで気にならないかもしれません。
ですので、このオプションを検討されている方は僕のブログを読んで「へー、ダメなんだー」と思うのではなく、実際に試聴して聞き比べてみることをオススメします。

参考:個人的に相性がよいと思った音源あれこれ

参考情報として僕が個人的にディナウディオと相性がよい、と思った音源をいくつかあげておきます。

÷(ディバイド)

÷(ディバイド)

Two Against Nature

Two Against Nature

Quintessence

Quintessence

相性の悪い音楽はあえて載せませんが、「中学生の息子が最近よく聴いてるJ-POP」とだけ書いておきます😅

おまけ:ディナウディオのBluetoothスピーカーが気になる

ディナウディオ自体の品質の良さは今回の試聴でもわかったので、車内以外の場所でディナウディオを聴くのはアリだな〜と思ったりしています。

ネットを調べてみると、どうやらディナウディオからBluetoothスピーカーが発売されているようなので、最近はこれがちょっと気になっています。
今の仕事場にこれを置いて音楽を聴いたらどうなるのかな〜??
これも一度試聴してみたいです。