無職日記 (1)
Quipperを退職しました & 求職中です - fujimuradaisuke's blog から一週間弱経ちました。
ありがたい事に沢山のお声掛けを頂きました*1。大変申し訳ないのですが、全てのご連絡にお返事できていない状況です…すいません！気がつけば今月のランチ・夕食の予定がほぼ埋まってしまいました。
で、7/24-7/28まで福岡に行きます。Rails Girls Fukuokaでコーチ。その後7/30から20日ほどタイ中心にアジアのどこかに行く予定です。シンガポールは確定、あとはスリランカかな。
今は部屋でこれを聞いてます。60分間、ひたすらミニマルに変化し続ける音楽。スーフィーの音楽を思い出しました。ジャケがかっこいい。 www.youtube.com
wishlistからTシャツと本を送って頂きました！ありがとうございます。記念に着て自撮りを行いました。次の仕事の初出勤はこのTシャツで臨もうと思います。
*1:退職エントリ公開初日で60件くらい
Quipperを退職しました & 求職中です
一言でいうと: Quipperを退職しました。Quipperの皆さん、本当にどうもありがとうございました！現在求職中です。ご興味あれば me@fujimuradaisuke.com か https://facebook.com/dfujimura までご連絡ください。Ruby、JavaScript、チーム開発のリード、などができます。wishlistはこちら
2015年6月末日をもって、Quipperを退職しました。
立ち上げ当初のMercariを体を壊して*1辞めて*2入院して手術受けて退院、さて今後どうしようと悩んでいるところで、ひとまずフリーランスで働こうとQuipperで働き始めました。2013年6月でした。
当初からフリーランスはあくまでモラトリアム期間という位置づけで、いずれは正式に会社に入るつもりでした。働いてみるとQuipperは想像以上によいところで、9月には正社員になっていました。教育という事業領域、グローバルな体制という点もさることながら、何よりメンバーが素晴らしかったのが決め手です。
Quipper在籍中にやったことを、立場で切って大きく分けるとこの二つでしょうか。
- ベネッセさんとの大規模実証実験で開発チームリーダー
- プロジェクトの仕組み作りとか、協業体制作りとか、開発チームの運営とか。
- 東京開発チームのリーダー
- 採用とかメンバーの配置とか面談とか。あと、オフィスが3つある(London/Manila/Tokyo)ので、その分担の相談とか。どちらかというと裏方。
一番の実績としては、ベネッセさんとのプロジェクトが無事完遂し高い評価を得たことになるのかな。もちろん全く事故ってないとは言えませんし*3、今思い出しても心がムズムズする反省点もあります。そもそも僕個人の実績ではなく、チームの実績だし。とはいえ、開発チームのリーダーとして在籍していたプロジェクトが「成功です！」と関係者に評価されていることは、客観的に見て実績と考えてもよいだろう、と判断することにしています。
あとQuipper Schoolのリリース体制を整備したりしてました。もちろんコードも普通に書いていました。
ちなみに退職の理由はよくあるタイミング的な問題です*4。Quipperは先日リクルートに買収されましたが、これは関係ないです。個人的にはリクルートと仕事するのはとても楽しみだったし、素晴らしいチームになれると思っていたので、残念です。
次の仕事は決まっていません。のんびり勉強しつつ*5、Quipper在籍中に蓄積した思考を解きほぐして、じっくり次の仕事を決めるつもりです。やることとしては、今までしてきた仕事を考えると、技術と組織の掛け算で事業に貢献するって感じになるかな思います*6。けど、よい目的と信頼できるメンバーがいれば、関わり方はなんでもいいかなーと*7。
ということで、エンジニアもしくはそれに類する職種の人間をお探しの方、ご興味あれば me@fujimuradaisuke.com か https://facebook.com/dfujimura までお気軽にご連絡ください。下に略歴をまとめておきました。お昼も都合がつきますので、ランチのお誘いお待ちしています。
Quipperは素晴らしい会社です。崇高なゴール、興味深い事業領域、安定した高い技術力、先進国・新興国含めたグローバルな体制、なにより最高のメンバー。なかなか離れがたいです。が！僕は僕の道で高みを目指して頑張っていこうと思います。
辞めた人間が宣伝するのも妙ですが、Quipperは各ポジションで絶賛採用中なので、興味を持たれた方は是非連絡してみてください。
- Quipperで新しい学びの形を創造したいWebエンジニア募集 - Quipper Ltdの求人 - Wantedly
- Quipperで新しい学びの形を創造したいiOSエンジニア募集 - Quipper Ltdの求人 - Wantedly
- Quipperで新しい学びの形を創造したいAndroidエンジニア募集 - Quipper Ltdの求人 - Wantedly
- Quipperで新しい学びの形を創造したいUIデザイナー募集 - Quipper Ltdの求人 - Wantedly
最後に、渡辺さん、中野さんをはじめQuipperの皆さん、社外のお世話になった皆さん、本当にどうもありがとうございました！今後のQuipperと皆さんの発展を心より願っております。何か今の立場で協力できることがあれば、遠慮なくご連絡ください*8。
ということで、皆様今後ともどうぞよろしくお願いします。
略歴
早稲田大学第一文学部哲学専修を卒業。大手ERPパッケージソフトの導入エンジニア（2次請け）としてソフトウェア開発を始める。Rubyがやりたくなり、とあるITベンチャーに7人目の社員として入社、Ruby on Railsを使うようになる。一年後業績不振のためレイオフされ(およそ半年後会社もなくなった)、groovesに入社。Rubyをメイン言語とする開発チームを中心人物として立ち上げる。その後Aimingに入社、認証サーバー、分析基盤などのチームを経て、Unityで作られたゲームをHTML5へ移植するプロジェクトに開発チームリーダーとして参画、なんとかリリースにこぎつける。その後フリーランス、Mercariなどを経てQuipperに参加。東京開発チームのリーダーとしてベネッセとの共同プロジェクトを成功に導くなどする。
プログラマーとしてはRubyを最も得意とする。JavaScriptを用いたシングルページ・アプリケーションの開発実績も多数ある。チーム開発をリードする経験も複数ある。プライベートでは主にHaskellを書いており、オープンソース・プロダクトへの貢献がいくつかある。
PS: wishlistを作ってみたので、貼っておきます。僭越ながらよろしくおねがいします。どちらかというとご笑覧向けのおもしろリストになっております。 http://www.amazon.co.jp/gp/registry/wishlist/3Q71MJUSPEEX8/
*1:扁桃炎が扁桃周囲膿瘍になり慢性化しました。最終的に2週間周期くらいで再発しててまじ辛かった。排膿のため口に注射針を入れて喉から膿を抜くんですが、それが痛いし怖い。あと一回再発することに5回点滴に通わないといけなくて超めんどくさかった。挙句の果てにMRSAが出たりした。扁桃腺が怪しい方はどうぞ切除をご検討ください！当たり前ですが、治ります。再発もしません。切除手術を受ける基準としては年4回発症だそうです。ちなみに今は完治して健康です。
*2:とんでもないタイミングで抜けたので、本当に申し訳なく思ってます…。
*3:ソフトウェア開発プロジェクトは大体そうだと思いますが。
*4:知りたい方は個人的に聞いてください。
*5:戸次大介『数理論理学』 を読む予定。論理学の知識が中途半端なので脱半可通したい。これ以外にも不足している／ずっと興味がある領域の知識を補おうと思ってます。『離散数学―コンピュータサイエンスの基礎数学』と『ふつうのLinuxプログラミング』をちゃんとやり、『プログラミング言語の基礎概念』は勉強会も開催されてるので読もうかなと。
*6:技術に振るかマネジメントに行くか？って話しについては、過去の経験から見るに、どこに行ってもマネジメント的な仕事をは避けようがない雰囲気なので、両立主義者として生きていくことにしました。そもそもマネジメントというか組織のことは興味もあるし、嫌いではないです。
*7:どんな事業がいいの？って問いについては、僕はヴィジョナリータイプではないので、熱量と千里眼のある(法)人と出会いたいです！業界的には、学生時代からインフラストラクチャーを支えたいという気持ちはあります。エネルギーとか交通とか。スタートアップ向けエンジニアという今の自分のスキルセットが直球で活かせる業界ではなさそうなんですが。投球スタイルを変えるのも面白そうではある。
『12大事件でよむ現代金融入門』 と『コンテナ物語 』を読んだ
出張中＆帰りの飛行機で読んだので軽く感想文を。
倉都 康行『12大事件でよむ現代金融入門 』
1970年以降の国際金融システム史。12の事件が時系列に解説される。金融を中心とした国際経済のしくみがわかる。著者はその現場にいた人。それでか、平易な文体の中にも生々しさがある。この手の本でありがちな「新自由主義が悪い」って論調にではなく、あくまで中立的に書かれているように思える。きっと著者が現場で金融というシステミック・リスクと戦っていたからだと思う。そういう語り口もあってか、好きになれる本だった*1。歴史の本としても教科書としても読める。良書でした。ちょっと消化不良なので再読すると思う。
マルク レビンソン『コンテナ物語 』
箱に荷物を詰めて送るようにしたら物流コストがめっちゃ下がった。けど導入は組合が反対したり標準化でもめたりして大変だった。箱の発明もだけど、それをがんばって導入したマルコム・マクリーンは偉い！って本。色々な人が褒めているだけあって、ものすごい面白い。
この本は幾つかのトピックから読める。
一つめは「起業家としてのマルコム・マクリーン」。ちょっと儲かるとすぐ借金したり資金調達したりして新しいことをやる。お金の突っ込み方がダイナミックで面白い。こうやって会社運営ってするんだあ…という。
二つ目「実録・機械に仕事を奪われた」。かつて沖仲士が手動で船から荷物を下ろして仕分けしてトラックに詰めていた。この仕事はコンテナを導入するとかなり無くなってしまう。なので沖仲士の組合はめっちゃ反対する。けど時代の変化には勝てない。という話。
最後「コンテナリゼーションがいかにして海運を効率化したか」。要はバッチサイズを一定にして作業を標準化するとスループットが上がる、という。トヨタ生産方式を思い出した。20世紀後半の生産性改善の定石なんだろうか。ソフトウェア開発プロジェクトにも活かせそう。
あと、ブルックリンのレコード屋で買ったこれが最高だった。ニューヨークのラテン・ソウル。ほんと良い。
Joe Bataan - I Wish You Love, Part 1 & 2 - YouTube
*1:その点、最近の水野和夫は辛い。『人々はなぜグローバル経済の本質を見誤るのか』は名作だったと思うんだけど、それ以降はこの本でデータから導いた結論に本人が乗っ取られちゃってる感じ
宮崎市定『アジア史論』が超面白かった
戦後日本を代表する東洋史学者が、西はシリアから東は日本まで含めたアジアを中心に世界史を論じる。文明間の交通を軸に話を進めるのでとにかくダイナミック。
シリアが古代より世界のハブだった、とか、プロテスタントの改革は既にイスラム教が成し遂げていたスキームの横展開だったとか、中世は近代のための準備期間だった、とか。中世に成功しすぎたイスラム世界は、その成功が故に没落も悲惨だった、とか。今のイスラム世界の辛い感じを見てどう思うんだろうな。
僕はウォーラーステインをちゃんと読んでないんだけど、その影響を受けたと思しき人の本を読む感じだと、とても似ているように思う。ということでニーアル・ファーガソン、水野和夫あたりが好きな人はハマるはず。
以下、面白い所を抜書き
p.8
また文化の影響ということが、いつも清水の中にインキを垂らしてこれを染めるようにばかり行われるとは限らない。人類は叡智を持った生物なので一を聞いて十を知り、単にヒントを与えられただけで奥義を悟ることがあり得る。
p.37
所詮、イスラム教とキリスト教との間には近世と中世との相違が横たわっていた。ルーテルの宗教改革こそは、中性的キリスト教をして近世的水準にまで向上させようとする運動に外ならなかった。そしてその説くところはと見れば、進行の根拠を根本経典たる『聖書』に求めようとし、聖徒の軌跡を含む一切の迷信を排斥し、僧侶は単に宗教的知識の宣布者たるべくして進行の媒介者であってはならず、また彼らの結婚生活を承認すべし等と説く。それらの事柄は、いずれもそのの規範を当時のイスラム教に見出すことが出来る。
p.74
『論語』や『孟子』はその主人公の伝記の一部分として歴史的に読むべきものであろう。（中略）現今の時勢にも間に合う所だけ読んで利用しようというのでは意味をなさぬ。それでは鏡に向かって、自分の姿のある角度だけを移すのと変わらない。
p.293
一個の閉ざされたる社会における平和の維持し難きは、一個人の閉ざされたる平和の維持し難きと同断である。これは倫理でもなく、道徳でもなく、ただ歴史が教うる現実なのである。
p.318
一般的に言って好条件は複雑な条件の結合の中から生れる。何とと言っても、手持ちの駒が豊富なでなければ完璧な布陣はできないものだ。そして豊富な持駒は、狭い局地で取り揃えることはできにくい。一番いいのは公益だ。交易ほど経済的で効果的なものはない。
ニューヨークにいる / Visiting New York City
仕事でニューヨークに滞在しています。3/13まで。 ブルックリン、ウィリアムズバーグの北にある、グリーンポイントという街でシェアハウスを借りた。元々ポーランド人街なので、ポーランド系のスーパーとかレストランがある。あと、TØRSTという素晴らしいビアバーがある。
予定としては
Darkside NYCのライブ
1349のライブ
SteffiとDVS1の出るパーティー
Rust-NYC
New York Haskell Users Group
あたりに行きます。
I'm now visiting New York. It's a business trip. Will back to Tokyo Mar 13.
My house for this visit is at Greenpoint, Brooklyn. This is a Polish town. I should have a try some Polish food. Also I found outstanding brew pub called TØRST.
My plans:
Show: Darkside NYC
Show: 1349
Party: Steffi and DVS1
Meetup: Rust-NYC
Meetup: New York Haskell Users Group
ミラン・クンデラ『冗談』
年明けすぐのマニラへの出張で読もうと思って持ってバッグに入れていきました。
行きの飛行機で引き込まれ、マカティの若干黴臭いホテルの部屋でサン・ミゲルを飲みながら読みふけり、帰国してすぐ自分の部屋で読了。
最後のページで全てが完成する。作品としてのあまりの美しさに感動して、しばらく言葉が出なかった。僕が今まで読んだ小説の中でも最高のものの一つでした。
あまりに印象に残る箇所が多かったので、抜き書きをしました。しかし、僕の抜き書きを見てしまうことで、それぞれと正しい形で、つまり作品の中で出会うという、人生で一度しかない機会を奪ってしまうという事は、凄まじい罪悪に感じられます。このインスタグラムの下から抜き書きです。見るのは読了後でお願いできればと…。
p.58
いくつもの顔をもっていたのは私が若かったからで、じぶんが何者で、どういう人間になりたいのかじぶんでもわからないからだった。
p.58
愛というものの心的・身体的な機制は複雑極まるものだから、若い男は人生の一時期、もっぱら自力を集中しなければならない。そのため愛の対象、つまり愛する女性を取り逃がしてしまう（これはちょうど、若いヴァイオリン奏者が演奏中に指使いのことを考えなくてもいいほど達者にならないかぎり、作品の内容に集中できないのと同じことだ）。
p.124
それから彼女は手を上げたのだが、その上げ方と言えば、これまで一度もそんな仕種をしたことがなく、どうやっていいのか分からないのに、ただ別れのしるしに手を振ることだけは知っていて、不器用ながらもそんな動作をしてみようと決心した人のようだった。
p.138
おのれの悲惨を自覚したところで、それで同類達の悲惨との和解が生じるわけではない。めいめいが他人のうちにみずからの卑俗さを見て仲よくするときほど、嫌なことはない。私はそんなべたついた友愛をどう扱っていいのかわからないのだ。
p.216
「王様！あんたには眼は要らないさ！おれが全部話してやる」
p.303
新聞はかさばらず、なんならゴミ箱に捨てることだってできる。同じようにつまらないものでも、ラジオにはそのような情状酌量の余地はない。カフェやレストランにまで私たちを追いかけてくるばかりか、耳に絶え間なく音の栄養をあたえないと、生きている気がしない人々の家を訪問しても変わりないのだ。
p.390
手に持ったカンテラを激しく振りかざしながら海岸をうろつく者がいれば、それは精神が錯乱した人間かもしれない。しかし夜、針路を失った小舟が大波に弄ばれるときなら、その者は救い主になる。
p.474
延期された復讐は奸計に、個人の宗教に、神話に変わり、日に日に当事者自身から離れていく。当事者たちは復讐の神話のなかで不変でも、じっさいには（動く歩道はたえず動いているから）、もはや以前の彼らではなくなっている。
新しいリリースプロセスをデプロイした
今やっているサービス、ちょっと障害が増えてきたので、リリースプロセスを変えました。
ざっくり言うと、今までmasterを全部デプロイしていたのを、金曜日以外の毎日一回、手動の確認をしてリリースするようにした。実際のドキュメント(Wikiです)を日本語にしてダイジェストで紹介してみようと思います。
ちなみにこのサービスは複数のアプリケーションがあって、今回対象にしたのはそのうちの主要な3つのみです。
ブランチ戦略
developを本流として、そこにトピックブランチからプルリクエストを出す。masterは常に本番環境に自動的にリリースされる*1- 急ぐときはHotfixとして
masterに直接プルリクエストを出してもOK*2。
リリース手順
- HipChatで「リリースするよ」ってアナウンスする
developからmasterにプルリクエストを出す- 手作業でテストして、チェックリストを埋める
- 問題があったら課題管理システムに起票
- 凄いやばそうな問題があったら相談する
- プルリクエストをマージして本番環境にリリースする
- HipChatで「終わった」ってアナウンスして終わり
リリースチームについて
- 開発者＆非開発者のペアを一週間でローテーション
- リリース体制自体を担当する開発者＆非開発者が一人づつ*3
- リリースのない金曜日はプロセスのふりかえりをする
- リリースは開発者ではなく、非開発者が主導
経緯と歴史
複数アプリケーションにまたがるEnd to endテストをやりきれないのと、テスト対象以外の障害やイケてないところを検知できるっていう手作業のメリットを享受したいな、といったあたりが理由です。 もちろん全部自動化したいんですが*4、このタイミングでは手動のリリースプロセスを導入するのがコスト的にもサービスの品質向上という面も良さそうでした。
ちなみにこのプロセスは以前別のプロジェクトでやっていたものをちょっと変えただけ。そのプロジェクトでうまく行った実績があったので、ある程度自信を持って進められた。
2014年12月の前半くらいに他の仕事をしつつプランニングと制度についてふんわりと考え始めました。先述のプロジェクトでやっていたことをざっと文書化してそれを元に相談しつつ、12月半ばくらいから周知を開始。フィードバックがあった部分や不足していた部分を詰め、自動化とChatOpsの仕組みなどを調査・整備、年明けにやわらかい状態でスタート。そこから一週間で一気に制度としくみを詰めた感じです。 まだ詰め切れてない部分はあるものの、走りながら治せる程度にまとまりました。
やってみて思いますが、サービスの事をよく知ることができる、改善点が見つかる、など、手動のテストにも特有のメリットがありますね。今更ではありますが。実は全体のEnd to endテストもあるので*5、今後はそれをこのプロセスに組み込んで機械と手作業それぞれの良さを活かせる仕組みにしたいなーと思ってます。
