Bluetooth + ノイズキャンセリングなヘッドホンBackBeat PROが良い感じだった
この記事は今年買ったもの Advent Calendar 2015の18日目の記事です。
今年買ったノイズキャンセリング+ワイヤレスなヘッドホンBackBeat PROがかなり良い感じだったので紹介します。
なぜ買ったのか
- 片道2時間という長時間通勤をするようになり、以下の問題が発生した
- それまで使っていたワイヤレスイヤホンのバッテリー２時間では足りなくなってきた
- 周囲の騒音に晒されている時間が増えてイヤホンだけではしんどくなってきた
- バッテリー持ちの良いイヤホンを新調してもよかったが、もともとノイズキャンセリング商品に興味があったので買ってみる良いチャンスだと感じた
どうやって選んだのか
- ノイズキャンセリングヘッドホンの売れ筋価格帯である2万円前後の商品はコード付きが多かった
- しかし電車の中で使用する以上ワイヤレスがいい
- ノイズキャンセリング + ワイヤレスでそれぐらいの価格帯だとソニーのMDR-ZX770BNが2015年7月当時話題になっていてレビューがメディアに多く掲載されていたが、「品質は価格相当」「ノイキャン＋ワイヤレスなら許せるレベル」みたいな論調が多く、どうも微妙な気がした（店頭で試したわけではない）
- そんな時にBackBeat PROのレビューをたまたま読んだ所、音質もノイキャンの性能も悪くなく、バッテリー持ちは24時間あってヘッドホン使用時にもボタン一つで外部マイクをオンに出来たりとか色々通勤時に便利そうな機能があったので、思い切って購入した。
どこで買ったのか
使ってみてどうか
価格は約3万円とソニーのMDR-ZX770BNより1万円弱高かったが、それ相応の価値はあると感じた。
- 音質は3万円のヘッドホンの音かというとその辺は微妙だが、少なくとも電車での通勤時は問題なく使用できるレベル
- ノイキャンはかなり優秀で、特に電車に乗っている時の低音をかなりカットしてくれる。電車に乗っている時にノイキャンをOFFにするとそのギャップにびっくりする
- バッテリーの持ちは非常に良い。往復で4時間使ってもバッテリーは半分も減らない。また、3時間ぐらいの充電でフル充電できる。
- 操作もシンプルで使いやすい。
テキストチャットにおけるコミュニケーションの難しさについて #remoteadvent
この記事はリモートワーク Advent Calendar 2015の13日目の記事です。
tl;dr
- リモートワークにおける主要なコミュニケーション手段は「テキストチャット」
- テキストチャットでなかなか意思疎通ができない時のストレスはかなり大きいが、少しの工夫でかなり改善できる
- お互い思いやりを持ってテキストチャットを使うことでストレスの少ないリモートワークライフを
前情報
- 筆者はwebエンジニアでフルリモートで仕事をしていました
- 普段の業務にSlackなどのテキストチャットツールを使用していました
チャットで全ての業務上のコミュニケーションを賄うということについて
リモートワークをしていると「それで問題は起きないのか？」という質問を今でもいろんな人から聞かれますし、リモートワークを始める前まで自分も疑問視していました。
なので、リモートワークを始める前は、実際の業務はビデオチャットとかを多用して口頭でのコミュニケーションが多いんだろうなーと思っていましたが、実際は業務上のコミュニケーションはテキストチャットで大体何とかなっていました。
エンジニアという仕事は、テキストでのコミュニケーションが多い職種です。仕様はドキュメントに記載され、成果物も一種のドキュメントであるソースコードだったりインフラ作業のログだったりします。だからもともと相性がいい、といえばそうなのかもしれません。もちろん、複雑な仕様を説明したりするときには、テキストや画像だけでは限界があるのでビデオチャットを使います。
質問が難しい
しかし、テキストチャットで長文のやり取りを続けるのは、会話よりもずっと労力がかかります。少なくとも自分は、50文字ぐらいの文字数で伝えなければならないことであればチャットより口頭で会話した方がずっとラクだと感じます。
特につらいと感じるのは１回で伝わらない時で、その場合以下のようなやり取りが行われます。
- メッセージを送信する
- 相手からの受信を待つ
- 相手に意図が正しく伝わらなかった模様
- 再度メッセージを送る
- やっぱり伝わらないので再度伝え直す
2の「相手からの受信を待つ」というのは、場合によるがその間何も出来ないということを意味します。
作業を再開しても再開後１分で返事がきてまた中断されるので、この間うまくチャットと自分の作業の間で自分の意識を行き来するスキルが要求されます（あるいはすぐに返事しなくてもいい情報を見極めるスキル）。慣れたとしてもやはり作業を細切れに中断されるのはなかなかにつらいものがあります。 逆もまたしかりで、相手からの質問の意図をこちらが読み違えると同じやりとりを今度は相手にも強要することになってしまいます。普段物理的に会うことが少ない関係で、すぐに口頭でフォローすることも難しいので、こういうやり取りはお互いのストレスの原因になる可能性があると思っています。
具体例として、自分がよく直面したエンジニア同士のうまくいかないパターンのコミュニケーションでは以下の様なものがありました。
エンジニアAとエンジニアBのチャットである。
- エンジニアA「@B これは何でしょうか？ https://github.com/xxxx/yyyy/pull/4169/files#diff-fd8ab12」
※URLはgithub上のPRのdiff上のとある行を指定している - エンジニアB「@A ああ、この修正を入れた意味ですか？それは○○が×××で（中略）△△です。」
- エンジニアA「@B いやそうじゃなくて、□□なのに（中略）という意味で聞いたんですが。」
- エンジニアB「@B ああ失礼しました。それは■■の場合(中略）です。」
- エンジニアA「@B なるほど了解です。理解しました。」
なんてこともない話ですが、エンジニアA→エンジニアBからの質問が1回で正しく伝わっていればやり取りは1往復で済んだはずです。
また、2往復になるにしても、エンジニアB→エンジニアAへ回答する前に、質問の内容に不明瞭な点があるなら一度そこで質問して不明瞭な点を確認することでエンジニアBは2回説明する手間を省けたはずです。
ビジネスメールの基本に解決策がありそう
この問題を解決するためにいろいろ試行錯誤した結果、自分が行き着いたのはいわゆる「ビジネスメールのマナー」でした。（筆者は新卒でSIerに入社していて、当時は社内外のコミュニケーションには主にメールを使っていました）
自分が新卒の時に新卒研修で教わっていたことを思い出すと、以下の３点のことが重要だと教えられました。
- 最初に「相手にどういう行動を起こして欲しいか」を完結に書く
- 1行は長すぎず、かつ過不足無く
- 最後に相手をねぎらうような言葉を入れる
これを元にさきほどのやり取りを改善するならこんな感じになるでしょうか。
<質問の仕方を修正する>
- エンジニアA「@B ちょっと確認したいんですが、この修正はこのPRの別の部分と重複してるように見えたので不要かなと思ったんですが、どうでしょうか？ https://github.com/xxxx/yyyy/pull/4169/files#diff-fd8ab12」
- エンジニアB「@A ■■の場合に(中略）です。」
- エンジニアA「@B なるほど。理解しました。」
<回答する前に質問の意図を明確にする>
- エンジニアA「@B これは何でしょうか？ https://github.com/xxxx/yyyy/pull/4169/files#diff-fd8ab12」
- エンジニアB「@A すみません一応確認ですが、この修正の意図が分からないという質問でしょうか？」
- エンジニアA「@B はい。□□でやってるから不要じゃないかなと。」
- エンジニアB「@A なるほど。それは■■の場合に(中略）です。」
- エンジニアA「@B なるほど。理解しました。」
前者の例はやり取りが1回になって時間短縮になりました。 後者の例ではやり取りの回数は同じですが、エンジニアAが2回説明していない分、エンジニアAの手間は少く、スムーズに回答できるのでお互いのレス待ちの時間も短くなることが期待できます。
このように、ほんのわずかな言葉の使い方次第でテキストチャットでの質問をスムーズに行うことができるようになります。 言われてみれば当然ですが、普段業務で忙しいと省略してしまうような言葉をほんの少し添えるだけでお互いの時間をかなり節約することができます。そのことに気づいてからは私はテキストチャットで質問するとき、される時は常に気をつけるようにしています。
テキストチャットもまたビジネスコミュニケーションである
テキストチャットはメールほど形式張ったものではないのでついカジュアルな文章で書いてしまいがちです。これはテキストチャットの良いところでもありますが、仕事上で重要な事は確実かつ迅速に伝える必要があります。
エンジニアにとっては、設計について議論するとき、コードレビューで指摘するとき、質問るときに発生するコミュニケーションは、すべて仕事上での重要なコミュニケーションです。同じチーム内であれば、「ビジネスメール」ほどの格式張った形式は不要だと思うしそんな文化になって欲しくはないと思いますが、仕事上のコミュニケーションにおいては確実に要件を伝え・伝えてもらえるコミュニケーションスキルを身につけておくべきだと私は感じます。
日報 2015-12-03
午前中にやったこと
- 今年一発目のアドカレを予約投稿して拡散した
- 引っ越しの荷造り続き
- 艦これ秋イベE-5乙ラスダン
[WIP] Erlang勉強
資料
今日の成果
- [done]第二章 moduleの定義
- [wip]第三章 関数の構文 ガード句まで
log
- repl中のcurrent path移動は
cd(PATH) - erlangをjvm上で動かすerjangという言語もあったとか。。
- repl上でコンパイルするときは
compile(MODULE)又はc(MODULE) - :tada:
25> useless:greet(male,"Tarou"). Hello, Mr. Tarou!ok 26> 26> useless:greet(female,"Tarou"). Hello, Mrs. Tarou!ok 27> 27> useless:greet(femal,"Tarou"). Hello, Tarou!ok
日報 2015-12-02
やったこと
- 引っ越しの荷造りしてた
- ギター弾いてた
- NHK受信料の住所移転手続きした
- 不要なメルマガを片っ端から解除した
- その他諸々の事務手続きをした
- 髪切りに行った
所感
家にいるとだらけるので家にいてはいけない
岩手と栃木でエンジニアしてた所感 #ruraladvent
この記事は地方在住ITエンジニア（元・地方在住も可） Advent Calendar 2015の3日目です。
岩手県と栃木県でそれぞれリモートワークをして暮らしていた時の所感について書きます。
「地方でエンジニアとしてリモートワークして東京のクライアントと仕事したい」という人の参考になれば幸いです。
なお、地方で一人暮らしでリモートワークという暮らし方をしていた理由については長くなるので本ブログの別エントリーでいつか書きますが、特に深い家庭の事情とかはありません。一言で言うなら「好奇心でやってみた」程度です。
また、地方に引っ越す前は神奈川県川崎市で3ヶ月ほどリモートワークをしていた時期があります。
岩手県盛岡市での一人暮らし編
2014年10月～2015年4月末まで岩手県盛岡市でアパートを借りて一人暮らししていました。
北国ぐらしは車が必須だった
長らく首都圏で暮らしていたので車は持っていませんでした。なので、最初から車がなくても生活が成り立つような利便性の高いところに住んでいましたが、結論から言えばやっぱり車があった方が良かったです。
岩手県盛岡市という土地柄もありますが、盛岡市街地でも冬は最低気温-10℃、最高気温が0℃とかになって、1日中外出したくなくなるくらいの気候の日が多く、その中を徒歩で出かけるのもなかなか厳しいものがありました。そのため、歩けば10分、自転車で数分のような距離の場所ですら外出が大変でした。引っ越すに当たり、車を買わないことは織り込み済みだったので車がなくても生活できる利便性の高い場所（一人暮らしが多い岩手大学周辺）を選んだのですが、それでも厳しいレベルでした。
私は岩手大学出身で、盛岡で4年間「自転車＋徒歩」だけで生活できていた経験があったので、車がなくても問題無かろうと思っていたんですが、流石に歳を取ったのか、はたまた在宅で仕事が出来てしまうということからの甘えからか、外出するのになかなかの思い切りが必要でした。
では地元の人はどうやってこの問題を回避しているか？というと、やはり自家用車を所有することでした。。というか自分も何度も車を持つことを勧められましたが、ずっと盛岡に住み続けるか分からなかったのと、維持費の問題で車を持たない決断をしていました。が、無理してでも車を持っていればまた状況はいろいろ変わっただろうなと思います。
平日の夜をどうやり過ごすか
大学を卒業してからも、盛岡を中心に趣味の活動をしていたこともあって、盛岡に知り合いは結構いましたが、朝9時から遅い時は夜11時まで自宅にこもって仕事をしている私と地元の企業に務める知り合いとではどうしても生活のリズムが合わず、平日に会うことは非常に難しくなります。
土日は趣味の活動等で会うことが多くなりましたが、平日はどうしても会うことが出来ないので孤独に夜を過ごすことになります。この辺、今考えればもう少し工夫できたような気もしますが、当時は仕事が忙しい時期だったことも重なって引きこもりがちになってしまっていました。
もし今同じような環境で暮らすとするなら以下の様な対策を取ると思います。
- 遅くまで仕事をしないように時間を仕事の調整する
- 仕事関係なく外に出て夜間に参加できるコミュニティで出会いを求める
- 誰かと共同生活してずっと1人でいる状態を避ける
ちなみにこの問題、都市部でリモートワークしてても同じ問題が発生するのでは？と思われるかもしれませんが、都市部だと遅くまで仕事をしてその後飲みに行く生活スタイルの友人が結構いたので、夜にお互いの仕事が終わってから都内で合流して飲むとか、勉強会に行ってそこで会うとかが簡単に出来たので、そこまで暇をもてあますようなことはありませんでした。
なお唯一良かった点として、家から徒歩15分ぐらいのところにカラオケがあって、平日の夜はいつも空いていたので1人で行ってギターを思う存分弾くことができました。住んでいたアパートは壁が薄すぎて日常生活の生活音ですら全て筒抜けという恐ろしい状態だったので、近所にカラオケがあったのは本当に助かりました。
栃木県栃木市での実家暮らし編
2015年5月～2015年11月末まで栃木県栃木市の実家で親と同居していました。
とりあえず車はなくても何とかなる
実家暮らしなので、ということもありますがすぐ近所にコンビニやスーパーがあり、少し歩けば駅まで行けるので車がなくても普段の生活には困りませんでした。徒歩＋電車で十分自分が必要とする行動範囲を移動できるようになったので、移動の問題は解消されました。
東京に日帰りで行けるのは大きい
例えば栃木から渋谷までだと2時間半程度で行くことが出来ます。なので土日の勉強会や、都内の友人に会いに行くぐらいは余裕でできるようになりました。なんだかんだで東京は便利で、岩手に行く前の自分は「ネットがあればもはやリアルTokyoなぞ不要！Amazon万歳！ネット万歳！」とか思ってたアホな私ですが、勉強会はどうやったって東京が圧倒的に多いし、著名な人に会って話を聞こうと思ったら東京に行くしか無いケースが多いのが現実です。 もともと自分も渋谷javaという勉強会を定期的に主催していた身なので、またその勉強会の運営に関われるようになって、再びいろいろな知見を得られるようになったのも良かったです。結局のところ、まだ自分は東京で学ぶことがたくさんあったんだなということを思い知らされました。
ギター弾き放題！！！
一戸建てでかつご近所もめっちゃ離れてるような環境なので思う存分ギターが弾けます。これは本当に良かったです。音楽活動するなら地方に拠点を持つのがベストなんじゃないかと思うくらい、早朝から深夜まで弾けます。好きな時間に楽器を弾くなんてのは就職してからずっと出来ていなかったので、この点を考えるとホントに地方の一戸建てに住むのはベストな選択です。
技術書難民
まぁAmazonで買えばいいんですが、地元の本屋が淘汰されつくされてしまい、私が読むようなIT系の技術書が地元で全く買えないような状態になっていました。盛岡では運良くエムズエクスポ盛岡店が出来ていて、わりと新し目の技術書にありつくことができたので思う存分立ち読みができた購入できたので良かったのですが、栃木市には残念なことにオライリー本のようなマニアックな本を売ってる本屋がありませんでした。
仕方なく基本Amazonで全部買ったり東京に行った時に（なんだかんだで週１は東京に行っています）大きめの書店に寄ったりしています。あと最近はkindle版の技術書が増えたのでkindle版がある場合は積極的にそちらを活用しています。あとはbookscanのプレミアムライト会員にもなっているのでamazonで中古で買ってそのままbookscanに配送してスキャンしてもらう、なんてこともやっています。
地方でリモートワークしてみてどうだったよ
こうやって書いてみるとメリットよりもデメリットの方が多くなってしまった印象を受けるかもしれませんが、首都圏と比べると生活環境の良さは地方が圧倒的でしたし、人と会わない時間が長くなることで自分のこれまでの人生や将来についてなどの普段考えないことを思索する時間を取れたり、趣味に没頭できたりといろいろと利点もありました。
いろいろ振り返って思うのは、常に人とのコネクションを切らさないようにすることだと思います。私は首都圏で働いていた時は、基本仕事での人間関係でしたが、仕事外でも会うような仲間が常にいましたし、孤独を感じるようなことはありませんでした。
それが地方に行ってできなくなったのは、自分が地方でコネクションを作る努力を怠った為だと考えています。今考えれば、地方にいる間はいろいろ理由を付けて新しい場所や分野で人と会うことを避けてしまっていたような部分もあり、今後も同じことを繰り返してしまう可能性があるので、もう少し自分の興味の幅を広げて新しい人脈を常に広げていくよう心がける必要があると感じました。
そのことを学ぶことができただけでも、この１年半地方でリモートワークを続けてきた意味はあったのかなと思います。
日報 2015-12-01
[WIP] Erlang勉強
資料
今日の成果
log
- erlangの文末はピリオドで終わる。REPLの場合はピリオド+スペースで行末を表す。
- erlangの
=はパターンマッチ演算に使用される。代入演算子ではない。 - パターンマッチ演算の左辺の変数がunbindな場合のみ左辺の変数に右辺の値を束縛する。
_は常に未束縛の変数として機能し、パターンマッチングではワイルドカードのように振る舞う- タプルの第一要素にアトムを含むタプルを
タグ付きタプルと呼び、型チェックみたいな使い方ができる（でもそれエラーになってプロセス死ぬんだけど。。erlangの死んだ奴は生き返らせるな理論に基づくとそれでいいのかな？） - ファッ！？
36> [97, 98, 99]. "abc"
- リスト内包表記！そういうのもあるのか
- リスト内包表記の生成式ではパターンマッチングの時のerrorは無視されて単純に式に渡されないだけになるだと！なるほどこの場合はタグ付きタプルが効果を発揮するな！
- リスト内包表記で生成式にバイナリを使う場合はファットアローを使う
[WIP] Clojure勉強
資料
今日の成果
- [done] Leigngenが入ってなかったのでbrewでインストールした
- [done] Leigngenでプロジェクトを作ってInteliJIDEAでimport出来ることを確認した
その他
- 新宿御苑行った
- マンションの鍵を受け取って試しに開けに行った
- 忘年会に出た
目標がないならまずは地味なエンジニアを目指してみるのもいいかも？という話
ワカモノは悩んでいるらしい
自分は今年で旧エヴァのミサトさんと同い年という感じで若くないせいか、たまに自分より年下の知り合いに会うと、仕事の悩み相談みたいな展開になることが多い。
会社もバックグラウンドも年齢もそれぞれ違う彼らの悩みは多種多様であるように聞こえていたのだが、最近ある共通点に気づいた。「このままじゃいけない」と無意識に思い込んでいる点である。
今以上にスキルをつけなければいけない、成長しなければいけない、ユニークな仕事をしなければならない、など人によって異なるのだが、なぜか「～なければいけない」の思いを持っていた。
そしてもう一つ共通しているのが、その「～なければいけない」の目的が見えないという点である。何となく焦っているのは分かるのだが、その焦って行動した結果によって自分が何を得たいのか。これまで色んな悩み人と会ったが、共通してそれが見えてこなかった。それとなく中長期的な計画を訪ねてみても、明確な答えが帰ってきたことは一度もない（それが分からないから悩んでるんだろうけど）。
とりあえず今を生きるのは精一杯、しかし現状に対して不満や不安を感じている。少し前の自分もこんな感じだったので人のことは言えないのだが、まぁそういう傾向がある人が自分の周りには多かった。
「地味なエンジニア」のススメ
そんな感じなので、悩み相談とはいうものの結局は彼らの職場の愚痴を聞いてやることしか出来てない訳なんだけど、今何かアドバイスするなら、いきなり凄いことをやることを目標にするんじゃなくて、今目の前に積んであるタスクを一生懸命やって、結果を積み上げ続けて信頼されるようになりなさいよ。以上。
…平凡過ぎる、この老害が、ダメエンジニアが、万年草なしgithubアカウントが、と罵りの声が至る所から飛んできそうだけど、決してブログだからといって適当なことを言ってる訳じゃなくて、マジでこれをちゃんと続けられない人が多いんだってばよ。
オッサンに片足突っ込んだ自分がこれまでのキャリアを振り返ると、長く生き残ってて周りから信頼されてる（ここがミソ）エンジニアって、まず目先のことに最大限取り組んで、ちゃんと結果を出して、それを積み上げて今がある人ばかりだった。逆に、消えていった人や、歳だけ取って成果を出せない人はその逆が多かった。
どんなに地味な仕事、例えばwebappのtemplateファイルを1行修正するだけの文言変更とか、デザイナーの代わりに1日中延々とデザイナが作業した修正分をmasterマージし続ける仕事とか、1日中SQL打って本番データを調査するとか、そういう地味な仕事だって誤字も無くつまらないバグもなく確実にこなしてる。で、時々客観的に見てもすごいと思われる重要な仕事しっかりこなして、周りから賞賛される。けど、普段は大体地味で目立たない仕事を嫌な顔せず淡々と続けてる。だから結果的に周りから凄く信頼されている。
そういう「淡々と」頑張るエンジニアがチームを支えているという構図を何度も見てきた。もちろんその人だけがチームを全て支えている訳ではないが、そういう精神的屋台骨的な、困ったときの駆け込み寺みたいなポジションの人が必ずチームにはいたし、エンジニア、非エンジニア問わず信頼されていた。
もし今自分の目標がないならば
別に、すべてのエンジニアが、今自分がいるチームから信頼されるようなエンジニアになりたいと思ってる訳ではないと思う。誰にも真似できない技術を身につけてそれを元に食っていくことが目標だったり、1人で密かにすごいものを作って一発当てることが目標、みたいな人もいると思う。あるいはエンジニアは新卒入社から２～３年で辞める予定で、将来は企画とかプロマネとかコンサルとかにジョブチェンジしたいという人もいると思う。（なお新卒時の自分はSEを経てITコンサルになるつもりだった）
目標は自由であっていい。そりゃ自分の人生なんだから。
けど、もし今、何の目標もなくて何となく焦ってしまっているようであれば、まず自分の目の前に置かれている、退屈かも知れない仕事をこなすことに集中して、それを積み上げていくことに集中してみても、きっと損はないよということを言いたかった。
自分にしても、プログラミング自体ちゃんとやるようになって5～6年だし、未だに大した技術力もアタマもないのにここまでやってこられたのは、目の前のタスクをこなすことにいつも全力で集中してきたからだと自負している。積極的に新しいことを勉強してきた訳じゃないけど、目の前の課題を解決するためにあれこれ模索してきた結果として、それなりにスキルもついてきている。途中、全く悩みがなかった訳ではないけど、目の前のタスクに全力で取り組んで結果を出して今自分がいられる場所を形成し続けることがこれまでの自分の生存戦略だった、とも言えるかも知れない。
