Born Too Late

好きな Doom Metal のバンドを紹介していく

2015-12-12 05:25:13

Doom or Be Doomed!
その昔、就職活動中に Leaf Hound Records の小林トレノさんに「社員にしてください」とお願いして断られたことのある @yuya_takeyama です。

この記事は METALバンド Advent Calendar 2015 の 12 日目の記事です。
昨日は Natsumi Akai さんの「we have a tank」ウォー・メタル、Sabaton!! でした。

さて、今日の記事ですが、今日は土曜日・安息日ですね。
そして安息日といえば黒い安息日・Black Sabbath ですね。
というわけで Black Sabbath を始めとするドゥームやその周辺ジャンルのバンドを、特に脈絡なく紹介していきます。
ドゥームメタルというジャンルは聴いたことある・興味あるけどどれから聴いていいかわからない方はどうぞご覧ください。

元祖 Doom Metal、Black Sabbath

Doom Metal の元祖にして Heavy Metal の始祖、そして 1990 年代のグランジブームにもそのルーツとして再評価・リスペクトを集めるなど、長きに渡って活躍しています。
一言に Doom Metal といっても様々な形がありますが、Black Sabbath 自身も初期のサイケ・ブルーズ寄りのハードロックを聴かせる 1st、War Pigs や Iron Man にタイトル曲といったヘヴィかつキャッチーでもある代表曲を詰め込んだ 2nd、ヘヴィネスの追求を押し進めた 3rd・4th、プログレ的な実験性も取り入れた 5th・6th、音楽的にもバンドの方向性的にも崩壊と向かった 7th・8th など、10 年足らずの短い期間でどんどん音が変化しています。

そしてその後は Rainbow 脱退後の Ronnie James Dio を迎えると様式美メタルへと大きく変わり、そちらでも成功を納めるものの、ドゥーム性は完全に失われてしまう。
その後、元 Deep Purple の Ian Gillan が加入して発表した Born Again においては Ozzy 時代ともまた違う悪魔的メタルを聴かせてくれたこともあったものの、その後はまた様式美メタルへと戻っていく。 (中でも 1990 年の Tyr は超名作なんだけどここでは割愛)

アルバムをオススメするとすると、いろいろあり過ぎて困るんだけど、やはり最初は 2nd の Paranoid
が一番聴きやすく、よりヘヴィなのがよければ 3rd の Masters of Reality や 4th の Vol.4 に進んでもいいし、もっと古臭いハードロックが聴きたければ 1st の Black Sabbath を聴けばよいでしょう。

Black Sabbath に次ぐ古参にして未だ現役、Pentagram

結成は Wikipedia によると 1971 年、その後度々の名称変更やメンバー変遷を経つつも現在も現役としてライブ活動を行うベテラン中のベテランバンドです。
アルバムデビューは意外と遅く、1985 年にリリースされた Pentagram (後に Relentless) が 1st だが、これが名作中の名作。Black Sabbath に通じるキャッチーさと沈み込むヘヴィさが共存した 1 曲目 Death Row、絶望的なリフが印象的な All Your Sins、一転してアップテンポな Sign of the Wolf (Pentagram) 等名曲が目白押し。他にオススメするとすれば、より埃臭いサイケなブルーズロックが好きな人には First Daze Here: The Vintage Collection や First Daze Here Too といった 1970 年代に録音されたデモ音源がオススメ。Too の Disc 1 は割とキャッチーな曲が多く、The Rolling Stones の Under My Thumb のカバーなんかも入っている。だけどこの時代で一番オススメなのはコンパクトながらもリフが恐ろしく印象的な Forever My Queen。

Doom Metal を体現するバンド、Saint Vitus

Pentagram よりは遅れるものの、1978 年代に結成し、1980 年代以降に活躍、メンバーを変えつつ現在も活動している。
Pentagram と並び称されるぐらいにリスペクトを集めるバンドだが、これまでの 2 バンドに比べると段違いのアンダーグラウンド感を持っている。
元々 Black Flag の SST Records からアルバムをリリースしており、音楽的にも影響を受けていることから、そういった出自である。

Saint Vitus の特徴といえば、Dave Chandler の極度にスローかつノイジーなギターもそうだが、ボーカルの Scott Wino Weinrich も紹介しないわけにはいかない。
元々は線の細いハイトーン系ボーカルが前任で、そのときはそのときでいい曲を出していたりするものの、一般的にはこの Wino (ワイノ) こそが Saint Vitus のフロントマンであり、Doom Metal を体現してきた男とされている、と思う。
Wino は Saint Vitus 以外にも、リーダーとしていくつものバンドを率いており、優秀なシンガーであるだけでなく優秀なギタリストでもある。
Saint Vitus では残念ながらギターを弾くことはあまりないが、強烈な個性を放つボーカルも唯一無二で、Saint Vitus の音楽的イメージを強烈に形作っている。

アルバムとしては代表曲目白押しの Live から入門し、気に入ればこのブログの名前になっている Born Too Late を聴いてもらいたいところだけど現状入手が難しいのが残念なところ。
Apple Music なら普通に聴けるのでそっちで我慢してください。

ドゥームとハードコアとブルーズの融合、Eyehategod

Eyehategod は Doom Metal というよりは Sludge というジャンルに括られることが多いと思いますが、あえてこちらで。
Sludge というのは Doom と Hardcore の融合で、Black Flag 辺りをルーツとした圧殺するかのようなリフを特徴としたジャンルです。
Eyehategod は割と不思議で、そんな Sludge とブルーズが高密度で混ざり合ったような、それでいてやはり容赦のないリフ・シャウトとグロテスクなジャケが特徴のバンドです。

基本的には遅い曲をやるバンドですが、ハードコアをルーツにしていることもあって速い曲もたまにあってそれもまたたまらなくカッコいいです。遅かろうと速かろうとどうしても Eyehategod の音になってしまうのは不思議といえば不思議だけど、だがそこがいい。

アルバムとしては 2nd の Take as Needed for Pain、4th の Confederacy of Ruined Lives もいいし 14 年ぶりに出たセルフタイトルもまた最高だったので、だいたいどれ買ってもいいと思います。

ホラー映画の世界を具現化、Blood Farmers

Blood Farmers は僕の人生において最高の Doom Metal バンドであると断言できます。かの Leaf Hound Records が最初にリリースしたのが、1991 年のデモ Eyehategod の再発 (ただし、ボーカルのみ再録) でした。
ヘヴィかつグルーヴィーなリフ、Dave Depraved によるフリーキーなギターソロ、10 分を超える曲もそれと感じさせない構成の妙と演奏の熱、どれをとっても唯一無二の存在です。
メンバーが重度の B 級ホラー映画ファンで、ほとんどの曲・アルバムが映画をモチーフにしているところもポイント。
Blood Farmers というバンド名も Invasion of the Blood Farmers という映画から取られたもの。
曲のイントロ・アウトロでも映画のワンシーンが引用されたりと、アルバム全体の雰囲気はホラー映画のそれに統一されている。

3 枚出ているアルバムのちダントツでオススメなのは Permanent Brain Damage だが残念ながら現在は入手困難なので、見つけたら即救出しましょう。
それ以外は公式サイトから変えるようです。

他にも聴いてみたい場合

挙げればキリがないのでとりあえずこの辺で。
他にも聴いてみたい、という人は入門系の動画とかを探してみると良いのではないでしょうか。

あとは音楽ライター山ちゃんの Stoner Discography でいろいろなバンドを知ってもいいし、新しい情報が必要なら 2ch のドゥーム/ストーナー/スラッジスレなんかに行ってみるのも良いでしょう。

それでは今回はこの辺で。
Doom or Be Doomed!

Quipper に入社してました

2015-11-02 07:00:36

2018/06/09 追記:
現在Quipper は積極採用中です。詳しくはコーポレートサイトかキャリアトレックをご覧ください。

ちょうど 2 ヶ月前に退職についてについて書いていたけど、その翌週の 9 月 7 日から Quipper で働いていた。

初出社 & 初プルリ済みです pic.twitter.com/PvmeYlgKpb

— Yuya Takeyama (@yuya_takeyama) 2015, 9月 7

入社当日に Twitter に書いたりしていて、全然隠していたわけではないのだけど、さすがに入って直後だと「転職したぜイエーイ！」で終わる個人の日記レベルのことしか書けないだろう、ということでしばらく放置していた。
いまは入社から 2 ヶ月ほど経ち、日々の仕事や社内の雰囲気にも慣れてきたので、そういうところも紹介も添えて「転職してたぜイエーイ！」的な個人の日記を書いておこうと思う。

Quipper について

Quipper の事業内容については日本国内ではまだまだちゃんと知られてないと思う。僕自身も面接を受けに行って話を聞きにいくまでは、教育関連をなんか海外でやってるらしい、という程度しか知らなかった。
ただ、最近は買収の件もあっていろいろ記事もでているので、そちらを見てもらうのが良いと思います。

何故 Quipper を選んだか

今回の転職活動では、もちろん Quipper 以外にも何社か受けていた。といっても合計 5 社しか応募していないのだけど、技術力が高く、エンジニアとして学べるところの大きそうな会社から選んでいた。
Quipper については、中の人たちのブログ等での露出で以前から技術力の高いスタートアップとしてのブランドが確立していたと思う。

その次に意識していたのは、海外との関わりのありそうな会社であること。エンジニアをやっていく上では英語力がネックになることも多々あったので、仕事で英語力が必要とされる会社が良いと思っていた。
その点では受けた会社は様々で、海外進出を目指している所、海外進出しているところ、海外にユーザがいるところなどあったけど、Quipper については海外で創業して海外に多数のユーザを抱えており、GitHub 上でのコミュニケーションはほぼ全て英語、という環境で文句なしだった。
それなら最初っから海外に行けよ、というツッコミもありそうだけど、日本にいて日本人に囲まれた安全圏でありながら適度に自分を追い込める、という意味ではこれ以上の環境はなかなか無いと思う。

あとは社内の雰囲気が良かったのも選ぶ上でポイントになったと思う。面接を受けた数日後に Quipper Drinkup (まぁぶっちゃけると採用イベント) というのに誘われて行ってみて、いろんな話を聞くことができたし、その他にも「良ければ」ということでエンジニア中心とした食事の席を用意してもらって、そこでもいろんな話をした。
イギリスにいる CEO や、インドネシアにいる日本人スタッフとの Skype 面談の機会をもらえたのも何気に大きかった。既に内定はもらって他社と迷っている段階だったので、採用への本気感を感じて大きくなびいたのを覚えている。ベンチャーとはいえ、社員数的にもサービスの規模的にもスタートアップの域はとっくに脱している会社だったので、直接の面談ができるとは思っていなかったし。

Wantedly での転職活動について

転職活動はほぼ Wantedly だけで行った。最初はいくつかのサービスを使ってみよう、と思いながらの中でとりあえず使ってみて、良かったので結局 Wantedly だけで全て終えた。なのでぶっちゃけ他のサービスと比較して本当に良かったのかどうかはわからないと言えばわからないのだけど。

その中で Wantedly の中の人から直接お話を聞く機会ももらえて、いろいろ聞かせてもらっておもしろかった。単に仕組みを提供するだけでなくて、就職活動という仕組みの雰囲気それ自体を変えようとしているようだったし、おかげで堅苦しい履歴書・職務履歴書を機会はほとんどなかった。 (なくはなかったけど、Quipper はなかった)
いろんな会社のいろんなすごい人たちと直接話せる機会をもらえて、それだけでも楽しい転職活動だった。相手の会社に、ブログ記事や勉強会での発表を通じて僕のことを知っている人がいる、ということもあって、そのおかげでいろいろスムーズだったので、アウトプットしてきてよかったと実感した。

その辺についてはまた別の機会に書きたいと思っている。

Quipper で働いてみて

オンライン主体のコミュニケーション

コミュニケーションのほとんどは GitHub と Slack で行なわれている。これはエンジニアやプロダクト寄りの非エンジニアの人はもちろん、ビジネスの人やカスタマーサポートの人、そして CEO も同様。プロダクトに関する意思決定はほとんどオンラインから見えるようになっていて、とてもオープン。
拠点がタイムゾーンをまたいで複数あるので、そもそもそうでないと難しい、というのもあると思う。

そういう環境なので、ちょっと前に台風のニュースがあって「このあと天気大変らしいですね」って Slack に書いたところ、あとは帰ってやろう、ということになっても全く問題がなかった。その日はそのままシュッと退社してスーパーでコロッケを買って帰って家でちょっと続きをやっておしまい。

天気ヤバそうですね、って Slack に書いたら、じゃあこのあとの定例ミーティングも中止してみんな帰ろう、ってなって弊社最高☺️

— Yuya Takeyama (@yuya_takeyama) 2015, 10月 1

もちろん口頭でのコミュニケーションやミーティングもやるし、Google Hangouts 等で海外とつないでのミーティングや情報共有もあるけど、そういうのも含めてアジェンダや資料がちゃんと共有されるので、入社前の情報もちゃんと追いかけることができる。

メールはたまにカレンダー上のスケジュールへの招待や、いくつかのウェブサービスからの通知とかが飛んでくるぐらいでほとんど使わない。

Pull Request によるコードレビュー

GitHub の Pull Request でコードレビューして CircleCI で CI まわしてイイ感じに開発してイエーイみたいな話は今でこそ当たり前に聞くけど、その辺のトピックでいうと Quipper は割と早い段階で、それもかなり具体的な方法論も含めて知られていたように記憶している。

それだけあってか、コードレビューはかなりちゃんと回っている。よく他社だと Slack でレビュアーを自動アサインするイケてる bot 作ったぜウヒョーみたいな話も聞くけど、Quipper にはそういうのは全くない (たまにこの件はあなたにも目を通して欲しい、ぐらいの感じで指名して mention することはあるが)。唯一あるのは「書いた本人以外がレビューしてマージする」というルールだけ。その点について僕が入社して質問したことで初めて Wiki に明文化されたものの、それまでは「そういうもの」としてまわっていたらしい。ウヒョー！
レビューはもちろん日本人同士だけでやるわけではないので、英語で行うし、拠点間の時差もあるが、みんな積極的にしてくれる。なのでこちらもしっかりレビューしなくては、ということで、自分にわかることは積極的に書くようにしている。そういう善意ドリブンっぽい側面もあるだろうけど、それ以上に、コードレビューという活動の重要性がカルチャーとして染みついているというのが一番大きいのだと思う。

ちなみに、僕の隣の席には Ruby の某処理系にコントリビュートしまくるパッチモンスター的な人がいて、よく鋭い指摘を受ける。その人はすごい Rubyish なコードを書くので、かなり勉強になっている。

英語

先に書いた通り、GitHub や Slack 上でのコミュニケーションは英語を主体として行われている。大学の卒業以降、これまでにちゃんと英語を勉強してきたことはないものの、英語の記事や技術書を読むようにいていたり、TOEIC の点数も日本人の平均よりは取れていたけど、入ってみるとやはり結構苦しい。
とにかく Google 翻訳・検索に頼らないと生きていけなくなってしまった。
日々便利な表現を他の人からパクリながら英文を書いているので、ちょっとずつはできるようになっている気はする。 (そう思いたい)

そんな中ではあるけど、ちょっと前にデプロイフローの改善について長文を書いて社内の合意が取れて早速取り入れられたり、今も別の提案を行って大体議論がまとまってきたりしてきている。そういう小さな成功体験を積み重ねて頑張っていきたい。

英会話については、幸か不幸か今の所必要とされる機会はあまりない。これは人によって違って、オフィス内でもよく海外のメンバーと英語で会話している様子が聞こえてきたりする。
数少ない機会としては、イギリスにいるメンバーが社内で使っている内製 CSS フレームワークについて発表してくれたことがあって、事前に用意された資料を補助線になんとか頑張って聞いていた。海外の技術系 Podcast を少しでも聞くようにしていて良かったと思った。

これは最近の話だけど、英語学習に関して会社から支援を受けられるということなので、リクルートがやっている英会話サプリを始めてみた。英会話サプリはひとことでいうといわゆる Skype 英会話的なサービスで、フィリピン人の先生から英会話の授業を受けられる。
何回か受けた感じでは、1 回 25 分話すだけでも結構疲れるけど、先生が雑談もまじえつついい感じに盛り上げてくれるので、結構楽しくやっている。
好きなバンドを聞かれてフィリピンの Juan de la Cruz の名前を挙げたところ、現地でもちゃんと伝説的ロックバンドとして認知されていることがわかって良かった。

自由な雰囲気

Quipper に入って予想以上によかったのが裁量労働であること。前の職場ではよく遅刻していたけど、今は遅くて 12 時ぐらいに出社していればいいので、今のところ遅刻はゼロ。出社時間は人によってバラバラだけど、僕は大体 11:30 前後に出社して、21 時か遅くても 22 時過ぎには帰っている。
とはいえもうちょっと早い時間にずらしてキラキラ感を出していきたいところ。10 時出社はいまのところ入社日が最初で最後になってしまっている。これはなんとか改善したいところ。

オフィスの雰囲気も自由で、ソファに座って仕事している人がいたり、じゅうたんが敷かれたリフレッシュスペースで寝そべって仕事している人もいる。休憩時間にはフーズボールとかで遊んでいる人もいる。
リフレッシュスペースはミーティングにも使われるのだけど、すごくゆったりできるので人気スポットであり、ミーティング終了後もそのままそこで仕事を続けている人が多い。
東京オフィス全体での情報共有を行うシェア会でも、会場を外のお店にするかリフレッシュスペースにするか Slack で投票を行ったところ大差でリフレッシュスペースに決まった、ということもあった。

写真はそのリフレッシュスペースで寿司を食い酒を飲みながらのシェア会の様子。
入社直後だったので自己紹介したりした。

自己紹介で、応募したきっかけとして中の人のブログ等へのアウトプット見てきて気になっていたことが大きかったので自分もやっていく気持ち、という話をした。 pic.twitter.com/lIQK9vXlYn

— Yuya Takeyama (@yuya_takeyama) 2015, 9月 9

日報カルチャー

日報を書かないといけないというルールはないのだけど、割と多くの人が毎日のように書いている。
なのでカルチャーと表現してみた。
以前は Qiita:Team が使われていたのだけど、僕が入社したときにはいろいろな理由で GitHub 内の専用リポジトリに Issue として書かれるようになっていた。

Qiita::Team やめた

前職では日報を書くのは義務だったけど、そんな中サボっては怒られて、また書いてはいつの間にかサボって、を繰り返していた僕が誰に言われるでもなく書いているのはおもしろい。モチベーション3.0 っぽい感じで、楽しいから書いているという感じ。

日報では業務内容の報告や最近困っていることの連絡はもちろん、業務の枠からははみ出るけど技術的におもしろいネタだったり、雑談ネタからポエムまでいろいろあって、社内コンテンツとしてとても充実している。
オフィス近くにとあるパティシエの店がいかに素晴らしいかという長文ポエムもあれば、ランチパスポート買うといろいろ安くたべれて便利、という話があれば、あの店は先着 3 名しか使えない罠、という返信が来たり、旅行に行くからお土産の希望募集、とかで社内コミュニケーションにおいても大きな役割を果たしている。
つい最近は CTO が流行に乗ってプロダクトマネージャーについての長文を書いていて、それはブログに公開した方がいいのでは、と思ったりもしたけど、読みたい人はこの辺に行くともしかしたら読めるかもしれない。
(余談だけど CTO のことはずっと前にブログ記事で知ってからずっとウォッチしていたので、今その人の下で働いているのは不思議な気持ち)

買収に関して

これについては気になっている人も多いと思う。僕の場合は面接を受けている中で買収について聞かされ、内定をもらったの時点ではそれも含めてどこに入社するか考えていた。
正直に言うと、不安はそれなりにあった。単純に日本有数の大企業に買収されるのだから、ベンチャーっぽい雰囲気ではなくなってしまうのでは、というようなことはニュースを見た少なからざる人が感じたのではと思う。

だけど入ってみると全然そんなことはなかった。
コミュニケーション的には完全に Quipper に寄せる形で相変わらず GitHub/Slack 主体だし、エンジニアの意見も最大限尊重されて、すごく居心地のいい環境になっている。
僕は買収前の状態は知らないのでフェアな意見を言える立場ではないけど、それでも入社前後での悪い意味でのギャップは特になかったと思う。

ちょっと前にリクルートマーケティングパートナーズ社内のクローズドな技術勉強会に観客として参加させてもらったこともあったけど、エネルギー溢れる人が多くて刺激になったし、内容的にもレベルがすごく高かった。Quipper とはまた違った雰囲気のエンジニアカルチャーがあって、そういう人たちと交流が持てるのは嬉しいことだ。

自分の将来について考えさせられる

これは Quipper のことというよりはごく個人的なことだけど。
転職活動を始める前後にしてもそうなのだけど、自分の将来とかキャリアとかそういうことを一層考えさせられる状況になっている。
前いた環境だと自分はエンジニアとしては大体なんでもできる人、みたいなキャラとして認知されていたこともあってあんまり意識せずに来てしまったと思う。

もともと面接のときも「自分が全体の中で下の方になれる環境に行きたい」というのを言ってはいたのだけど、下の方どころか一番下になってしまった。
もちろん、エンジニアに限っても役割やスキルセットは一様ではないので、単純にこの人はあの人より上だの下だのと比較することはできないのだけど、自分にしかない強みみたいのがあまりになく、ちょっと泣きたくもなる。
今まではジェネラリストを目指していたけど、もうちょっと専門的なスキルも身につけた方がいいのでは、ということを Soft Skills: The Software Developer's Life Manual を読みながら考えたりしている。

とはいえそれを求めてやってきたというのと、インターネット越しに自分が井の中の蛙に過ぎないことはわかっていて飛び込んだ環境なので、まぁそんなもんだろうという諦めのような開き直りのような気持ちもありつつ楽しくやっている。
給料をもらいながら Be the Worst な機会を得られたことにただただ感謝するばかり。

終わりに

怒られないギリギリの範囲でめいっぱい書いたつもり。
結構長文になってしまった。
こんなに誰が読むんだ、って感じもするものの、Quipper に少しでも興味のある人に届くといいな、というのと、いい環境で楽しくやっているぜイエーイ！という気持ちで書いてみた。

今は積極採用モードは一旦落ち着いているらしいものの、この先またいろいろあると思うので、興味のある人はオフィスに遊びに来たりしてみると良いのかも。
(2018/06/09 追記: 現在Quipper は積極採用中です。詳しくはコーポレートサイトかキャリアトレックをご覧ください)
どんな人がいるかはこの辺からわかるので、繋がっている人がいれば話しかけてみてください。

Web エンジニア 6 年 5 ヶ月やってたどり着いた価値観

2015-09-01 07:55:42

Web エンジニアとして経験を積むことでいくつかのプログラミング言語やツール・ミドルウェアの使い方を覚えたりもしたけど、それらのうちいくつかは 10 年後ぐらいには陳腐化してしまっているかもしれない。
だけどそれらを通じて身につけた価値観や哲学はもっと普遍性を持っているような気がする。

大学を卒業し、Web エンジニアとしての職を得て 6 年 5 ヶ月、日数にして 2344 日経ったので、現時点での頭の中にあるもののダンプを残しておく。
どこかで聞いたようなことばかりで新鮮味はないと思うけど、自分で実感を持ってたどり着けたことには意味があるはず。

プログラミングについて

言語はいろいろなものを試してみる

毎年新しい言語に挑戦せよ、というのは確か dankogai さんの講演をまとめた記事で読んだはずなんだけど、記事が見つからない。
キーワードをもとに検索してみたら達人プログラマーにもそういうことが書いているらしい。 (読んだことないけど)
あとはプログラマが知るべき97のことにも学び続ける姿勢に同じようなことが書いてあった。 (これは昔読んだ)

振り返ってみると僕が社会人になって覚えた言語は PHP/Ruby/JavaScript/Golang の 4 つだけなので、毎年は覚えられていない。
一応つまみぐいしてちょっと書いてみたり、読むぐらいならなんとなくできるものでいうと C/C++/Perl/Python/Haskell/Clojure なんかもあるし今は Elixir に手を出している。
まぁこれらで何かを作ることはほぼできないし、明らかに足りてはいない。

そんな中途半端な状態だとしても、まがりなりにもやってきた価値は感じている。
Rubyist を自称する人が好んで引用する (というのは偏見かもしれないけど) サピア＝ウォーフの仮説によると、言語は考え方に作用するとされていて、複数のパラダイムのプログラミング言語を体験したことのある人なら、結構納得できるんじゃないかと思う。

異なる文法を覚えることも大事だけど、それによって同じ問題に対して異なるアプローチができるようになることはもっと大事。
もちろん、アプローチが違うからこそ文法も違うのだろうけど、その点はよく意識する必要がありそう。

言語設計者の思想や、コミュニティの共通認識を理解することも大事。
最近でいうと、個人的には「なくていい抽象レイヤはない方がいい」ということを Golang に教わったと思っている。

そして、言語ごとによく使われているツールやフレームワークについてよく知ることも、問題解決や発想の幅を広げてくれる。
Python の WSGI や Ruby の Bundler を知り、それらが解決しようとしている問題を理解できれば、その知識はあらゆる言語で再利用できる。

小さくて組み合わせられるものを作る

まぁ UNIX 哲学ですね。
オブジェクト指向においては単一責任原則というものがあるし、関数型プログラミングは小さな関数を組み合わせて大きな問題を解決するスタイルが一般的。
モノリシックアーキテクチャに対するマイクロサービスアーキテクチャが持つ価値というのも、レイヤは違えどかなり似ているんだと思う。
(という話を先日 Kyobashi.go という Golang の勉強会でしてきた)

もちろん、より専用性の高い、複雑で大きなソフトウェアにだって価値はあるし、そういうものが必要なケースだっていくらでもある。
だけど日々出会う問題の多くはもっと汎用的な、grep とか awk とか sort とかでもかなりのレベルで解決できる。
専用のツールに比べて多少パフォーマンス上のオーバーヘッドがあったとしても、使い方を思い出すのに苦労しない分、むしろ効率だっていいのかもしれない。

実装よりもインターフェイスに注意を払う

これも UNIX 哲学に関連する。
小さくて組み合わせられるものというのは UNIX 的なコマンドに限らない、ということは既に書いた通り。
UNIX コマンドにおいてこれを実現しているのはパイプやファイル、終了ステータスといった標準的なインターフェイスである。
そういったインターフェイスをうまく使いこなすことが、組み合わせやすいツールの実装を可能にする。

インターフェイスといえばオブジェクト指向言語にはまさにそのままの名前の機能が備わっている。
PHP でいうと Traversable というイテレータを入出力にする関数を組み合わせることであらゆるリスト効率的に行えるし、PHP 5.5 で実装されたジェネレータもまた Traversable を実装したイテレータなので、まったく同じように組み合わせることができる。
(ということを去年の PHP カンファレンスで話した)

HTTP をリクエストを引数としてレスポンスを返す関数として抽象化し、各プログラミング言語レベルのインターフェイスを与えることで WSGI/Rack/PSGI ミドルウェアとして Web アプリケーションを効率良く拡張できる。
RESTful な Web サービスにおいては、GET/PUT/DELETE といったインターフェイスごとにべき等性や安全性といった制約を持たせることで、リトライやキャッシュ化が容易になる。
そして URI というインターフェイスを通じてリソースが表現できることによって、あらゆる情報を簡単にリンクでつなげたり、API として機械的に処理することもできる。

インターフェイスさえ正しければ、中の実装がどれだけ複雑でわかりにくくても、それを利用する限りにおいては何の問題もないし、なんならテストを書いてリファクタリングすることもできる。
だけどインターフェイスが間違っていれば、その実装がどれだけ正しくて頑健でも、それを組み合わせて利用するのはすごく難しくなってしまう。
その問題を解決するにはリファクタリングではなくリストラクチャリングが必要で、そのためにはより多くの苦労やリスクが伴う。

情報共有について

情報は有用なだけでは広まらない

苦労して書いた社内ドキュメントが読まれないと、社内のどこかで無駄を生むかもしれないし、起こってほしくない間違いが起こるかもしれない。
そういう有用・重要なドキュメントでも、意外と読まれていなかったりする。

社内用に Gyazo クローンを作って、クライアント (Gyazowin+ というのを使った) のインストール方法や使い方を社内 Wiki に載せたことがあった。
周囲のエンジニアはすぐに便利さを理解して使ってくれたが、それ以外の部署の人達にあまりリーチできていないことに気づいた。
画像を表示するページの脇に使い方の Wiki にリンクを貼ってはいたけど、アクセスログを調べてみるとそこまで来た人が半年で数人に満たなかった。

そこでとにかく社内 Gyazo の存在に気づいてもらおうと、Wikipedia のジミー・ウェールズ風に自分の似顔絵 (社内 Gyazo を積極的に使っていた同僚に書いてもらった) バナーを作って、画像を表示するページの上部にデカデカと表示した。
これだけだと社内 Gyazo を使う人のいないクラスタだとやはりリーチできないので、そのバナーを印刷して、QR コード付きのポスターを他部署の壁に勝手に貼ったりした。
まぁこれはちょっとした奇行みたいなものだけど、それなりに話題になって DAU/MAU ともに着実に増加した。

あとは部署ごとに簡単なエヴァンジェリストみたいな人を決めて、新入社員に積極的に社内 Gyazo の存在や使い方を知らしめてもらうようお願いしたりもした。
入社間もない、人となりも知らない人が社内 Gyazo を使ってくれていることが増えて、スクリーンショットがないせいで問題点の伝わらないバグ報告に苛立つことも減ったような気がする。

インターネットな人たちの間では Gyazo の便利さは自明だけど、普通の企業だとそうじゃなかったりする。
そういう文化差を考慮したり、攻めるべきポイントを押さえて戦略的に情報を広める努力が必要になる。

シェアするのは自分の為

社内の Wiki を書いたり、ブログに記事を書いたり、ライブラリを GitHub に公開したり、勉強会で発表したり。
これらが周囲のメンバーや技術コミュニティの人達を助けることはあるし、逆に他の人がシェアした情報に助けられることはよくある。
そして他人の役に立っている、と実感できるとそれがエネルギーになることもある。

だけど単にシェアするだけでこういう効果が得られるとは限らないし、効果を心のそこから実感できることは少ないかもしれない。
効果を実感できないと、モチベーションもだんだんと下がってしまう。

こういうときは他人のためとかはとりあえず置いといて、ただ自分のために、将来の自分に向けてシェアすれば良い。
作ったソフトウェアの最初のユーザが自分であるように、シェアした情報に最初に助けられるのは自分。
人間はすぐ忘れるので今日役にたった Tips を 2 ヶ月後には思い出せないかもしれない。

そして情報を記事やスライドとしてまとめることで、自分の不理解が浮かび上がってきたり、理解をより進化させることにも繋がる。
他人の発表を 10 回聞くよりも、1 回だけ自分で発表する方が身になる。

問題解決について

仕事は問題解決の連続

Web エンジニアやプログラマに限るまでもなく、全ての仕事は問題解決であって、それによって価値が生まれ、対価が発生する。
プログラマが他の職業と比べて特殊だとすれば、その特殊性は解決のための手段をものすごく安価にハックできるというところにあると思う。
だからプログラマは問題解決に自覚的になることで仕事の価値を文字通り何倍・何十倍にもしていけるし、それができないと競争上すごく不利になる。

問題を解決するには、前提として問題発見と問題定義が必要になる。
それぞれを意識することで、より効率良く、意味のある解決にたどり着ける。

面倒くささに自覚的になる

Larry Wall のプログラマの三大美徳のひとつに「怠惰」というのがある。
労力を抑えるための努力を惜しまないことがプログラマに必要な資質である、ということのようだ。
言い方を変えれば、面倒くささに自覚的になれば、解決すべき問題が見えてくるし、単純な作業を無意識に繰り返しても苦痛でない人はあまりプログラマに向いていないように思える。

僕は周囲を見回すと、面倒くささへの無自覚さに驚かされることが多かった。
面倒な手続きの多いインターフェイスを、みんな文句ひとつ言わずに使いこなしている。
多分、最初は多くの人が面倒に感じていたんだろうけど、繰り返し利用するうちに慣れてその面倒を忘れてしまったりするんだろうと思う。

身の回りにある面倒の多くはそんなに大したことではなかったりする。
例えば検索するためのフォームだったら、入力欄にフォーカスを当てるためにクリックするのが面倒なので autofocus 属性を付ける。
画面上の値をコピペして検索ボタンを押すのが面倒だったら、値自体をリンクにして、クリックするだけでよくする。
「1-clickを0-clickにすると革命になる」という言葉もあるけど、そういうチャンスは滅多にないし、技術的にも簡単ではない。
「n-clickを1-clickにする」だけでもいろんなことがなかなか快適になるし、そういう細かいところに気づけるだけでも他の人に差を付けることはできる。 (商売になるならそれでも十分)

「問題は何か」を常に意識する

小さな問題点に気づけること、それらを丁寧に正していくことは大事だけど、そういう小さい改善を積み重ねても全体としての問題の解決につながるとは限らない。
より大域的に問題を意識し、その解決にとって意味のある改善なのかを見極めないと、時間ばかり失われてしまう。

「問題は何か」ということは名著ライト、ついてますかの中でもしつこいぐらい繰り返し問われている。
それぐらい人間は手段と目的を履き違えやすいし、あらゆる手段が安価に手に入りやすかったり、手段の追求が知的好奇心を刺激したりするので、プログラマは特にそういう状況に陥りやすい。
そういう目的と手段の逆転がモチベーションを生み、そうやって新たな技術が生まれているということも見逃せないけど、今すぐ目の前の問題を解決する必要のある状況かどうかは見極める必要がある。

面倒を技術で解決するのも「怠惰」だし、一見問題だけど解決してもしょうがないものを解決しないのも「怠惰」だ。

問題解決は枝刈り

これは特にデバッグのときに役に立つことで、必要のない枝を刈ることを意識することで、素早く問題を解決できる。
例えば Web API にアクセスするスマートフォンアプリが思った通りに動作しない場合、まずは問題がクライアントサイドなのかサーバサイドなのか、というところから切り分けられる。
クライアントサイドだとしても例えば WebView の中の問題なのかネイティブ層の問題なのかそれともそれらのブリッジ層の問題なのかということに切り分けられるし、サーバサイドであればプログラムの問題なのかミドルウェアやネットワークの問題なのかとなる。

こういう切り分けを常に正しく行えるとは限らないし、そのための情報が足りていないということもあるかもしれない。
それでも一旦問題を仮定し、それ以外の可能性を排除することで、その仮説の検証にフォーカスできる。
仮説が間違っていることが検証できれば、それはそれでひとつ枝を刈れたことになるので、一歩前進したことになる。

そして仮説は高いレイヤから作り、その検証は低いレイヤから行う。
サーバサイドの問題だと仮定した場合、例えば mitmproxy のような HTTP プロキシで HTTP 通信を覗くことが役に立つだろうし、クライアントサイドの問題だと仮定した場合は Web インスペクタで DOM を覗いたり、デバッガのブレークポイントで変数の中身を覗くことが役に立つ。
低いレイヤから考えると見るべきポイントは無限にあるので、やはり高いレイヤからの枝刈りによって対象箇所を絞ることが大事ということになる。

まとめ

これらのことを学ばせてもらった EMTG 株式会社を昨日 2015 年 8 月 31 日をもって退職しました。
次の職場は全然違う業界ですが、これらの価値観はきっと役に立ってくれることだろうと思います。
それではまた。