| @旅行/散歩

パルテノン神殿

2015年6月22日

振り替え便は 8:10 と聞いていたので 6 時に起きて飛行機に乗る準備をした。 7 時前にチェックアウトして空港に向かうと、昨日見た顔の人たちが何人かいた。タクシー代の精算を済ませ、搭乗手続きをして飛行機に乗ると、エーゲ航空のスッチーたちは何事もなかったかのようなにこやかな表情を浮かべていた。

アテネには一時間足らずで着いた。なんとこの日は天気が悪く、アテネ到着時は雨が降っていた。

アテネ到着

前日にアテネの宿を手配できなかったため空港に着いてから空港の無料 WiFi を使って予約しようとしたが、アテネ空港の WiFi は 60 分間しか無料で使えず、結局空港のパソコンを使って予約した。

アテネ空港はギリシャ到着時に食事したときにめちゃくちゃ高くてどうしたもんかと思っていたが、空港の外に出て空港職員等で混雑するサンドイッチスタンドに入ると、 €2.5 で食べ物が買えた。ここでコーヒーを飲みながらほっと一息つくことができた。

その後メトロでアテネの街中へと向かう。アテネ空港は成田と同じで、名前こそアテネだけど全然アテネじゃない場所にある。電車で 40 分くらいかかった気がする。

Athens city view from Acropoli

アテネの市街についてまずびっくりしたのが、街並みのヨーロッパっぽくなさだった。道が広くて路上駐車の車がたくさんあるのはヨーロッパっぽいんだけど、道路の舗装は適当でゴミや動物の糞が散乱しており、マンションのすべての側面には汚らしいバルコニーがくっついていて植物やらなんやらをみんな好き放題外に出しており、非常に猥雑だった。ヨーロッパというより東南アジアにでも来たような景観だった。

Athens

またアテネはサントリーニ島やミコノス島に比べて圧倒的に緑が多く、湿度も幾分か高いようだった。普段は 6 月に雨が降ることはなく異常気象だと泊まった宿の主人は話していたが、モンスーン気候に慣れた身からすると、乾燥の激しいサントリーニ島やミコノス島は過ごしにくく、雨降りのアテネはとても過ごしやすく感じられた。

Athens

アテネの宿はアクロポリスなどといった主な観光地にも歩いて行ける場所にあるものを選んだ。 €107 だったが安くても一泊 €200 オーバーだったサントリーニ島からすると別天地という感じだった。部屋は広く風呂は豪華で、たっぷりと暖かいお湯のシャワーを浴びることができた。

宿にはチェックイン時刻よりも早く着いたので、荷物を置いて観光へ出かけた。レストランに入ってメニューを見るとサントリーニやミコノスの観光地レストランの値段に比べるとずいぶん安い。しかもハンバーガーを頼んだらパンが一枚でハンバーグが二枚のやつが出てきた。ギリシャ人、こんな経済観念だから経済崩壊するのでは、と思いつつ、アテネサイコーと叫びながら子牛のハンバーグを食べた。

パン一枚に肉二枚

食事のあとは街をうろつき、最初携帯の SIM を買った ΓΕΡΜΑΝΟΣ を見つけたのでプリペイド SIM のチャージができるかどうか聞いてみた。サントリーニ島のショップでは、追加チャージはできるが翌月にならないとできない、という説明を受けていた。しかしキャリアの COSMOTE のウェブサイトを見てもどこにもそのような記述はなく、おかしいなぁと思っていたのだった。 €6 で 500MB のチャージを頼み、携帯を出すように言われたので Pocket WiFi を出すと、「その端末ではこの SIM カードを使うことができない」と言われて一瞬雲行きが怪しくなったが、自分たちが持っている iPhone は SIM ロックがかかっていて Pocket WiFi 経由でないとインターネットに接続することができないことを説明すると「OK」と言って追加作業をやってくれ、再びインターネットにアクセスできるようになった。

その後街を散策し、子どもが喜びそうな蒸気機関車型の観光バスを見かけたので乗ってみることにした。大人一人 €5 で、アクロポリス周辺の主立った観光地を周遊でき便利だった。乗り降り自由らしいので乗り降りしてプラカ地区やシンタグマ広場に行ったりすることもできる。我々はその勝手を知らずに漫然と一周してしまってもったいなかった。

アクロポリス バスから見たアゴラ

バスに乗ったあとにパルテノン神殿に上ってみたが、正直なところ圧巻だった。今回の旅行ではアテネはスルーする予定だったがエーゲ航空がキャンセルになったせいでアクロポリスを訪れることができたのはある意味幸運だったかも知れない。

パルテノン神殿

パルテノン神殿を観光していて初めて知ったのだが、パルテノン神殿は風化であのように朽ちているのではなく、 17 世紀にヴェネツィアによる砲撃を受けてあのようになった、とのことだった。当時でもすでに 2000 年以上の歴史を経ていたパルテノン神殿を破壊するなんて罰当たりなことだと思ったが、 Wikipedia によると、当時ギリシャを支配していたオスマントルコは、ヴェネツィアもパルテノン神殿の歴史的価値に敬意を表して砲撃すまいと高をくくって女子どもを避難させ、アクロポリス内に弾薬庫を作って弾薬を貯蔵していたのだそう。しかしヴェネツィアは一切斟酌せずパルテノン神殿に砲撃を浴びせたらしい。

修復中のパルテノン神殿

そのような状況になったパルテノン神殿を修復しようという動きはギリシャ独立後の 19 世紀中頃からあって様々手を加えられているが、 1800 年代後半から戦前にかけての修復は、古代の手法を忠実に再現するのではなく、鉄を使って無理矢理修復するという手法で、そのせいでかえって他の部分に負荷がかかり、現在は 19 世紀から 20 世紀前半にかけて行われた誤った手法の修復で傷んだ箇所を正しい手法で直しているところなのだそう。

修復されたパルテノン神殿

そういえば順調に行けば今頃訪れていたはずのドゥブロヴニクも、一時はヴェネツィアによって支配され、イタリア文化を受容しているのであった。ヴェネツィアとは地中海沿岸でやりたい放題やってたんだなぁ。

パルテノン神殿をゆっくり時間をかけて観光したあとは、一旦宿に戻ってシャワーを浴びて休憩した。三人とも何を食べてもトマトとオリーブオイルとハーブの入っている地中海風の料理に飽きていて、汁付きの麺類が食べたいと、アジア料理の店を探してアテネ一番の繁華街のシンタグマ広場へと向かった。

遅い時間にわざわざやってきたのに嫁さんが目をつけていたアジア料理屋は看板を掲げておらず、あるはずの場所には別の中華屋があって営業していた。店の前でひとしきり夫婦げんかをしたあと、あきらめてこの店に入って中華料理を食べることにした。

この中華屋が正解で、酢豚もチャーハンも中華麺もどれもうまかった。変な香辛料は入っていないし唐辛子辛くもなく、日本人にとって非常に食べやすい味付けだった。青島ビールを三本飲んでも会計は €30 程度で、一食で €70 ほどかかっていたサントリーニ島と大違いだった。しかも店の女将の中国人が非常に親切で店も清潔で、まるで日本に帰ってきたかのようだった。

中華屋の麺

食事を追えて最終一つ前の地下鉄で宿に戻り、倒れ込むように眠りについた。

2015年6月23日

翌朝は宿を出る際に領収書の宛名書きの件で嫁さんが宿のレセプションともめて、そのせいで夫婦げんかをしてしまった。一旦別行動をとることにしたのだけど、一人でアクロポリスのベンチに腰掛けているとなんかいろいろどうでも良くなってしまって、嫁さんから届いていたメールを読んで昨晩食事をした中華屋のあるシンタグマ広場で合流することにした。

昨晩 0 時近くまでいた中華屋には同じ面々がいて店を営業していた。この人たちはよく働くなぁと感心しながら店に入って食事を注文した。ギリシャ人は働かないと日本のマスコミでは言われるけど、アテネのこの中華屋の人たちも、サントリーニ島のホテルの人たちも、朝早くから夜遅くまでとてもよく働いていた。実は EU の中でギリシャ人の労働時間は結構長い方だという記事もある。新聞やテレビで見るのと実際に訪れてみるのではずいぶん事情が異なるなぁという思いを強くした。

昨夜の店内には現地のギリシャ人の客しかいなかったが、この日の店内には中国人だらけだった。

中国人の観光客はギリシャにいっぱいいたが、不思議なことに彼らは昼間はそこかしこにいるのに、夜になると潮が引いたかのようにさっと姿を消す。それは見事なものだった。夜の街を出歩いて中国人の姿を見かけることはないし、盛り場に行っても夜に中国人の姿を認めることはできない。

ミコノス島で二日連続通ったレストランの面白ウェイター氏によると、中国人はあまり良い旅行をしていないそうで、一泊ずつ街を転々とするのだそう。ひょっとしたら毎朝早い時間に宿を出て次の街に向かわなければならないから彼らは夜の街に姿を見せないのかも知れない。

プラカ地区

食事のあとはシンタグマからプラカ地区の土産物屋を冷やかしたりしながら宿のある方向に向かって歩いた。途中土産物を買うため嫁さんとアクロポリスのあたりで別れ、自分は一人で宿まで預かってもらっていた荷物を受け取りに行った。

プラカ地区

地下鉄駅で嫁さんと合流して、再びアテネ空港に戻り、自分が行ってみたかったクロアチアのドゥブロヴニクに向かった。待ちに待ったときが来た、という感じだった。

| @旅行/散歩

Little Venice

2015年6月19日

Santorini to Mykonos

サントリーニ島からミコノス島への移動は3時間程度だった。乗船したのは Hellenic Seaways の Highspeed 4 という船で、高速フェリーのためデッキに出て外を眺めることができなかったが、船内は広く、売店もあり、エコノミークラスでも客席は足下が広々しており快適そのものだった。アテネ−サントリーニ間をフェリーで移動するのは時間がかかるので時間に余裕のあるバックパッカーとかでないと難しいかもしれないが、ミコノス−アテネ間であればちょうど良いと感じた。

Continue reading...

| @旅行/散歩

フィラの景色

2015年6月15日

14 日夜 8 時に福岡を出発して羽田でカタール航空のアテネ行きに乗る。カタールで乗り換えてアテネに 15 日の昼に到着した。

アテネに着いてまずは現金を引き出そうと ATM に新生銀行の PLUS マーク付きカードを入れてみるが、引き出すことができない。 10 年前にヨーロッパを旅行したときは新生銀行のカードでドイツでもチェコでも、円預金を現地通貨で引き出すことができた。同じようにして現金を引き出そうと思い、 ATM にカードを入れるが、事前にインターネットバンキングかなにかで手続きを行っていないと、海外 ATM での引き出しができないようだった。そういえば一時期新生銀行のカードをスキミングして海外で不正に引き出すという犯罪が横行したので、何も設定してない場合は海外での引き出しができないようなルールに変わったのかも知れない。日本では羽田の三井住友銀行の両替所で €60 両替しただけだったのでユーロを現金でほとんど持っておらず、またギリシャの両替レートは日本で €1 = ¥141 だったものが €1 = ¥151 もして最悪のレートで、到着するや否や空港の到着ロビーで派手に夫婦げんかをした。

Continue reading...

| @散財

5月末に家を建てて半年ほど住んで得られた知見を共有します。

2014-05 清貧会館 / Holy poverty Insutitute May, 2014

家を建てた理由

子どもが生まれた

最初は賃貸で引っ越そうとしてた

  • 子育てには車が必要だから
    • 西松屋(車でしか行けないような所にしかない)に行きたかった
    • おむつやミルク缶やベビーカーは車じゃないと運べない
  • 駐車場の安い郊外に引っ越して車買おうとしてた(当時住んでた所は駐車場代高かった)
    • 結局引越費用高くてやめた(40万くらいした)

中古マンションでも探すことにした

  • 中古マンション探すけど良いのは高かった
    中古なのに新築分譲時より高いのとかある

それなら新築マンションでよいのでは、と思った

  • しかし新築マンションは業者が好きになれなかった
    • 偉そう
    • 息がくさい
    • すぐローンの審査申し込ませようとする
    • 考える時間を与えずハンコ押させようとする
  • 買いたいタイミングでよい物件が出回ってなかった
  • マンションは管理費や修繕積立金、駐車場代が重荷になりそうだった
    ローン完済しているのに駐車場代と修繕積立金と管理費合計で毎月4万とか払うの嫌だった
  • 子どもの実家がマンションになるのが想像できなかった
    自分が田舎育ちのため

中古の一戸建て考えるようになった

  • 中古の一戸建てのリノベーションを建築家に相談したら土地買って家建てるのとかかるお金あんまり変わらないと言われた
    土地買って家を新築することにした

土地を買う際に得られた知見

土地の申し込みは同時に何人かが申し込んでいる可能性がある

  • 早くローンの申し込み・審査を済ませないと他の人に買われてしまう可能性ある

基本的に不動産屋は信用できない

  • 腹黒い

よい土地を見つけたら建物を含めた総予算を出さないといけない

  • 土地を決めてからゆっくりプランを練るとかできない
    • 土地を買うときに家全体の総予算を決めていないといけない
      土地を買うタイミングで建設会社も決めてだいたいのプランを固めておく必要がある
    • いつか家を建てたいと思っている人は、「まだ土地もないし家のこと調べるにはまだ早い」などと考えずに具体的な予定はなくても建築雑誌とか本とか読んどいた方がいい
      自分は家を建ててから中村好文さんの本を何冊か読んでとても後悔した。

土地の選び方はとても重要

  • 土地は 土地を買ったことがある人に相談 してから買うのがよい
  • どこのメーカーで建てるかよりもどこにどんな土地を買うかが重要
    • 建物は住んでるうちに価値が減っていく
    • 土地は基本的に価値が落ちない 不動産資産 = 土地の値段 (家は無価値と考えた方がよい)

よい土地の条件

  • 土地のかたち
    • 正方形か長方形がよい
    • 三角や台形はだめ
  • 土地が面している道路の道幅
    • 広い道路に面していると土地が狭くても車出し入れしやすい。道幅 6m 以上の道路(車がすれ違える)がよい
    • 道幅が広いと日当たりがよくなる
  • 道路が公道に面しているか
    • 私道にしか面していない土地は家が建てられないことがある
  • 道路に何メートル接しているか
    • 長く面しているほどよい
  • 道路と土地に段差がないか
    • 隣地よりも土地が低いと日当たりが悪くなる
  • 日当たり、方角
    • 東南角地が一番日当たりよい

中心街まで何分とか駅から徒歩何分とかばかりに目が行きがちだけど、車の出し入れのしやすさが土地の価値になる。土地のかたちがいびつだったり、道路と変な角度で接していたり、接している長さが短かったり、接している道路の道幅が狭かったりすると車の出し入れがしにくい。また面している道路は公道であることが望ましい。接している道路が 私道や持ち分共有の私道だと権利関係が複雑で揉める ことがある(揉めた)。

住宅ローンを組む際に得られた知見

地銀か都銀かネット銀行か

  • 地銀の方が申し込みや審査は早い(対面でやりとり)
  • 金利はネット銀行の方が安い(対面でやりとりできないから多分時間はかかる)
  • 都銀は地銀より金利安いけどネット銀行よりは高く、審査は地銀の方が早い

変動金利か固定金利か

  • 繰り上げ返済をじゃんじゃんするつもりの人は変動金利がよい
  • 基本的に固定金利(フラット35)は変動で組めない(銀行の審査だめだった)人向け
  • バブルのときでも金利は4%くらいだったらしいので金利が10%とかになることは(日本国債が暴落しない限り)ない
  • 変動と固定ミックスでローン組める銀行もある

持ち金全部突っ込まない

  • 住宅ローン金利は異常に安い金利で金を借りられる制度なので、手持ちの資金を極限までつぎ込むより少し多めに借りて手持ち資金を残すのが賢い

上場企業に勤めてるときに組むと審査通りやすい

  • 前勤めてたブラック企業だと収入はちゃんとあったとしても審査通らなかったかもしれない(会社が無名だから)
  • 上場企業だと金利優遇とかがあったりする
    • 東証一部上場の会社だったらさらにもっと金利優遇されたりするのかもしれない

家を建てる際に得られた知見

  • 総予算から土地の値段と引っ越し代や家具代を引いた分しか家には当てられない
  • 家の建設費と別に外構工事費がかかる
    • 家に残り予算全額つぎ込むと工事現場みたいなどろどろの土地に暮らさないといけなくなる
  • 金に余裕があるなら建築家に設計してもらうといい
    • 建築家はいろいろ考えてる
    • 例えば二階のベランダと床に段差を作らないようにするのは木造建築では難しい。建築家だと何とかしてそういうのを実現してくれる。
    • 建築家入らないと住設メーカー(リクシルとか)のカタログハウスみたいになってしまって味気ない
    • 延べ床面積はそんなに広くないけど暮らしやすい間取りみたいなのを考えてくれる
    • 依頼主がよく分かってないニーズを、依頼主の家族構成、趣味、仕事内容をヒアリングすることで引き出してくれる
    • 建築家に頼まず地場の工務店に自分たちが注文したとおりの家を建ててもらったけど何となくしっくりこない
    • 無駄に空きスペースがある
    • 要望通りになってはいるが所詮素人の要望なのでプロに考えてもらった方が良かったのかもしれない

とは言え最近の家はよい

  • 断熱性高い
    • 床暖房もソーラー温熱システムもついてないが居間のエアコン稼働すると家中暖かくなる
    • 24時間換気システム(最近の家はつけないといけないらしい)のおかげで家中の空気が循環していて一部屋だけ寒いとかがない
    • 最近の家はペアガラスがデフォルトなので窓際にいても寒くない
    • 前の賃貸マンションは窓際が寒くて死にそうだった
  • 台所が広いのがよい
    • 料理する気になる
    • でかい冷蔵庫が買える

家を建てて後悔している・心配な点

2階建ては狭い

  • 延べ床面積 100m2 とかあってもマンションの 100m2 とは違う
    • 階段部分の面積も延べ床面積に含まれる
    • ワンフロアで 100m2 あるのと 50m2 が上下に連なっているのでは感覚的な広さが全然違う

手放しづらそう

  • 給料減って住宅ローン払えなくなったときすぐ売れないかもしれない
    • 中古の木造建築はなかなか売れない
    • マンションは比較的すぐ売れる
  • 売っても高く売れないかもしれない
    • 木造建築を売るときは無価値と考える必要がある
    • マンションはそこそこ古くても場所さえよければよい値段で売れる

台風や地震や空き巣が心配

  • マンションなら台風や地震には勝てそうだし、オートロックなので空き巣も一戸建てほどは心配しなくてよさそう。一戸建ては帰省や旅行をする度心配になる
  • 修繕積立金を徴収されない代わりに何かあったら自分で捻出しないといけない

固定資産税高い

  • 想定外だった

町内会

  • 町内会費高い
    町内会費高すぎて嫁さんは町内会脱退するとか言ってる(できるのか)
  • 町内会の清掃活動とかに出ないといけない
    めんどい

家を建てて(郊外に引っ越して)よかった点

  • アホみたいに高い駐車場代払わなくてよい
    • 立体駐車場じゃなくなったので好きなときに車出せる
  • 庭があるので夏はバーベキュー出来る
    • スーパーで買った激安ブラジル産鶏肉も炭火で焼くと涙が出るくらいうまい。生きててよかったと思える。
  • 郊外に引っ越したので驚くほど静か
    • 地域の祭りとかあったりして和む
    • 近所付き合い面倒だけど野菜もらえたりもして便利
    • 常にどぶっぽい臭いしてた都会の空気吸わなくてよくなった

いつかはかっこいい家を建てたいと思ってる人には上にも書いたけど建築家の中村好文さんの本をおすすめします。

| @労働

この記事は 闇アドベントカレンダー、 22 日目の記事です。何書こうか迷って担当日に書けなかったので三日ほど遅れてしまったけど書きます。


2011 年の 10 月から FANIC という音楽配信サービスの開発に携わっていたのだけど、サービスを成長させることができず、 2013 年の 8 月にサービス終了した。

サービスが死ぬのは技術者がクソだということだけではないと思う。市場とか外部環境に左右されるし、企画とか売り方がダメなことの方が多いと思う。しかし現実に自分はプログラマーとして FANIC というサービスの死に荷担してしまった。弔いになるか分からないけど、 FANIC で何がよくて何が良くなかったのかを書いてみたいと思う。

FANIC とは

FANIC は主にアマチュアのミュージシャンをターゲットにしたホームページ作成&音楽販売サービスで、アーティストは自分の公式ホームページを簡単に作ることができ、楽曲をアップロードして試聴公開したり、リスナーに販売することが出来た。月額利用料は 315 円で、曲が売れたときに手数料 15.75 % が従量課金される仕組みだった。 2012 年の 1 月に公開して、 2013 年の 8 月 31 日にサービス終了した。

FANIC に携わることになった経緯

ペ社に入社したのは 2 年前の 10 月だった。前の職場がどうしようもないブラック企業だったことは前に書いた。

会社の開発環境が地獄のレガシー環境だったので面談で社長に Subversion やめて Git 使いたいと言ったら、「会社が気に入らないならさっさと辞めろ」と言われたので、何とか反省して心を入れ替えたふりをしながら職探しをしていたところ、 Rails 、 Node.js 、 Redis 、 MongoDB 、 Nginx 、 AWS みたいな福岡の求人にしては珍しくナウいキーワードで募集していたのがペ社の Dazaifu Project だった。

プロジェクトの紹介ページが何となく面白そうだったのと Rails で仕事できそうだったので応募した。小さなチーム、大きな仕事を読んだり、RubyKaigi 2010 に行ったこともあって、DHH や RubyKaigi で登壇していた人達みたいにとにかく Ruby で仕事したいという思いが強かった。前の職場でも Ruby を使いたかったけど ColdFusion や Flex など旬を終えたプロプライエタリなテクノロジーばかりを触らないといけなくてとにかくつらく、わらをもすがる思いで求人応募フォームを送信した。

8 月に応募して 9 月に内定が出て 1 ヶ月後にペ社に入社した。入社するまで配属先を知らなかったんだけど、 Dazaifu Project の物販系と音楽系の二つのサービスのうち音楽系の方に配属されることになった。それが FANIC だった。

FANIC で良かったこと

一つのプロジェクトに集中できる

受託の会社とかだと受託案件があって、案件ごとにメンバーがアサインされるから同時並行的に二つか三つを掛け持ちで担当するということがあるけど、自社サービスの会社では基本的に一つのサービス(案件)にかかりっきりで仕事をすることができた。これがとても良かった。午前中に A 社の対応をして午後から B 社、夕方からまた A 社のタスクに取りかかって 20 時から終電まで C 社対応、みたいな複数の仕事の切り換えがない。タスクの切り換えにはオーバーヘッドが発生するから、一つのことにかかりきりになれる自社サービスの仕事はとてもやりやすかった。加えてプログラミング言語はずっとやりたいと希望していた Ruby だったので言うことなしだった。会社に行くのが楽しかった。

ナウでヤングなアーキテクチャー

求人に上に書いたようなナウいキーワードを混ぜていたのは先輩の @linyows さんで、FANIC はインフラは AWS を利用し、データベースに MongoDB 、音楽や画像は S3 に保存して、WAV や AIFF でアップロードされた音楽ファイルを試聴用の MP3 に変換するバッチ処理や、画像を S3 から取り出すリアルタイムリサイズサーバーは Node.js で実装してあった。フロントエンドのアプリケーションは Rails で構築されていて、自分は主に顧客管理とか決済部分なんかを開発した。

ペ社では通常、インフラを担当する専任のチームがサーバーの面倒を見る。しかし Dazaifu Project はスモールスタートを掲げていたので、インフラも @linyows さんが一人で構築していた。今自分が配属されているサービスは結構でかくて、サーバー管理はインフラチームが担当し基本的に自分たちで設定を変えたりサーバーを構築したりすることはない。ちょっと Nginx の設定を書き換えるのにも申請書出してハンコリレーしたりしないといけない。おかげで凡ミスで 500 エラーみたいなことにはなりにくい仕組みになってるんだけど、リリースのスピードを上げにくい。そういう状況からすると、 FANIC でミドルウェアのバージョンを上げるのなんかも部署間の調整が必要なくさくっと出来たのはとても良かった。加えてデータベースが MongoDB だったため、データ構造の変更が柔軟に出来たのも良かった。

社内でいち早く CoffeeScript 使ってみたほか、ペアプログラミングもやってみた。かなり疲れるけど集中して取り組めるし、プログラマー間で仕様を共有できるのでこれは良いものだと思った。 FANIC のおかげでずいぶん成長させてもらったと思っている。

FANIC でつらかったこと

FANIC ですべてが良い方向に向かっていたかと言えば、決してそうではなかった。技術的にもプロジェクト運営的にも、苦しい部分が多々あった。

MongoDB で金の計算

技術的にはまず MongoDB で金の計算をするのがつらかった。

決済部分の開発で MongoDB の Embedded Document でかなり苦しめられた。契約 Collection の中に Embedded Document として請求と入金があるという構造だったけど、契約日と入金日が月をまたいでいて、一つの契約 Document 内にある Embedded Document をそれぞれ別の月の入金と請求とする必要があり、かなり苦しい感じだった。前受金の概念とかも Document 指向のデータベースで対処するのは地獄的な感じがした。Document の中に何でもスポスポーと Embedded Document を突っ込んでいけるのは便利なんだけど、親 Document と Embeded Documet を別の文脈で使おうとするときに困難が生じると思った。

MongoDB を大規模に利用している CA 社も JOIN ができないので金関係だけは MySQL でやっているという話を聞いたことがある。金の計算をするときに JOIN の代わりに Map Reduce する必要があったけど、自分が開発に利用していた頃の Mongoid (MongoDB 用の ActiveRecord 的なやつ)は Map Reduce に対応しておらず、 Rails のモデル内に Map Reduce 用のクエリ(MongoDB のクエリは JavaScript で書かないといけないので Rails のモデル内にヒアドキュメントで JS が書いてあるという地獄っぽい感じになる)を書いたりした。Map Reduce しないのであれば二重 Loop でグルグル処理を回さなければならず、毎度これを Ruby にやらせるのはパフォーマンス的にしんどかった。総じて MongoDB は大量のデータを集計したりするのには向いてないかなーという印象を持った。それぞれを独立したドキュメントとして利用する機会が多いタイプのアプリケーションには向いてる気がする。設定情報の保存とかブログ記事の保存とか。金系のデータが沢山入っていてそれを月ごとに集計してどうのこうのとかやるときがつらい。

Mongoid のため便利 gem が使えない

Rails エコシステムの中で MongoDB は少数派だから、様々な便利 gem が ActiveRecord に依存していて使えないことがあったのも困った。たとえば ActiveAdmin が ActiveRecord に依存しているために利用することができず、顧客管理を一から実装しなければならなかった。なければ作る or Pull Request 出して取り込ませる、というようなマッチョマンじゃないと Rails でレールから外れるのは厳しいと感じた。

リーンスタートアップできていなかった

プロジェクト運営的には、チームの目標とか優先順序の付け方とかがハッキリせず、行き当たりばったりな開発・運用になっていたのがつらかった。

2012 年の春、『リーンスタートアップ』が流行ってた。みんな本買って読んでて、社内で antipop さんによる講義とかもあった。でもリーンスタートアップは本当に難しくて、誰でもリーンスタートアップ読めば新規事業で成功できるわけではないと思う。サービスの企画立案者が有能なだけでは不十分で、起業家に加えて、極めて優れたエンジニアが付帯していないと厳しいと思う。自分たちに必要だったのはリーンスタートアップを読むことではなかった気がする。全然そのレベルに到達していないという感じだった。

思い込み・お問い合わせベース開発

リーンスタートアップには、仮説の検証をものすごい速度で行ってフィードバックループを回さないといけないと書いてあるけど、そもそも自分たちには仮説の検証方法が存在していなかった。本に書いてあるとおりに様々な仮説を素早く検証していくには、企画担当者がやりたいと思ったことを一週間くらいで実装して次々に仮説を検証していかないといけない。A/B テストをやるにしても、A/B テストをやるための仕組み作りが大変だと思う。オープンソースで使えるものに Cookpad の Chanko とかあるけど、 MongoDB がネックになって利用できなかった。自分たちでそういう仕組みを作るにはかなり多くの時間を作らなければならなかったと思う。結局思いつきやお客さんからのお問い合わせベースで開発する機能が決定されて実装されていった。お問い合わせが結構あったから 1 ヶ月以上かけて実装してみたのに全く使われない機能とか、これは絶対に行けるはずと自分が思い込みで提案して実装したのに全く使われない機能とかあって、全然良くなかった。

ちなみに↓のスライドではてなブログのリーンな開発風景が紹介されてるけど、情報収集のところで紹介されてる手法を真似しようとするとかなり大変だと思う。雑魚いエンジニアしかいないとここまでやるのは難しい。

技術的に正しいことをしようとこだわりすぎて中途半端になっていた

入社した頃、テストを書くという習慣がプロジェクトになかった。プロジェクトに加入した初期の頃から自分はなるべくテストを書こうとしていて、テストを書く習慣を定着させたつもりだったけど、これも良かったのか悪かったのか分からない。テストを書くとどうしても時間がかかってしまう。 TDD BootCamp Fukuoka Vol.2 できしだなおきさんが言っていたんだけど、テストコードがあるとプロダクトコードのメンテナンスに加えてテストコードのメンテナンスも必要になる。そうすると俊敏に動くということが難しくなる。自分はテストを書くことに時間をかけすぎてしまってサービス開発のスピードを鈍らせていたような気がする。

テストを書いたりリファクタリングをしたりしないのは正しい行いではないと思うけど、会社に雇われて給料をもらっている以上、サービスを成長させることがエンジニア云々以前にサラリーマンとして大事だと思う(『情熱プログラマー』とかにも書いてある)。特にプロジェクトの最初の段階では、技術的な理想を追求するよりも、不完全でも良いのではやく製品を投入して一つでも多くの仮説を検証して学びを得ることの方が重要なのではないかと思った(Minimum Viable Product)。

自分のプロダクト感を持てていなかった

サービスに対して、「自分たちのプロダクトだ」という感覚が希薄だったと思う。そもそも hitode909 さんのスライドみたいにドッグフード食べてなかった。自分の FANIC 上のページは検証用に作ったインターネット上のゴミみたいなページだった。

みんなビラ配りとかオフィス外での宣伝活動とかに消極的だったし、このプロジェクトがぽしゃったら失職する、みたいな危機感が希薄だった。自分は机に座ってプログラミングできればそれでいいみたいな感じがあった。口ばっかりで手が動いてなかった感がある。

地元の野外フェスとかに行ってビラ配るとかオフラインでの宣伝が必要だったのかもと思う。終わるって決まったとき、やりきった感がなかった。これでうまくいかないなら仕方がない、と思えるところまでやれてなかった。

エンジニアであってもプロジェクトの当事者意識を強く持たなければならないのだと思う。いまいくら自分たちが稼いでいて、あといくら稼ぐと黒字になるのかとか、どのくらいのスピードで成長していかなければならないのかとか。

チームの雰囲気が良くなかった

一番の苦しかったのはこれだと思う。

いま思い返してみると、 1 年半の間でチームのメンバーが揃って食事をしたのは 1 回くらいしかなかった。お互いへの理解が欠如していたような気がする。雰囲気悪かったからサービスが崩壊したのか、サービスがうまくいっていないからギスギスした感じになったのかは分からない。ただ、雰囲気の良くないチームが作る製品が良いものになることは基本的にないと思う。

FANIC を離れたあとも、会社を挙げて永和システムマネジメント社の講習を受けてスクラムに取り組んだりしてる。しかし結局どんなプラクティスを導入しようとも、チーム内でコミュニケーションが取れていないと技術的に見過ごすことの出来ない問題に気づけず非常に大きな手戻りが発生したり、仕様上の大どんでん返しがやってきたりする。技術的に足りない部分があったとしても、コミュニケーションが機能していたらカバーできたのではないかと思う。

結論

結論としてはチームで寿司を食べたりするしかないと思う。銀しゃりのまばゆい輝きが、うにやいくらの神々しい光が、鋭利な刃物のように光るサバのにぎりが、闇を照らしてくれる。

上にぎり 1.5 人前


この記事は闇 Advent Calendar 2013 - Adventar 22 日目の記事でした。 23 日目は hurutoriya さんで、今日の担当は @udzura さんです。

| @技術/プログラミング

公開している Lokka の DB (MySQL) のデータを、手もとの Lokka の DB (SQLite) に取り込むときに毎回やり方を忘れるので書いておきます。

今回は MySQL to Sqlite converter という gist のコメント欄に書いてある以下の方法を試した。

sudo gem install sequel
sudo gem install sqlite3
sudo gem install mysql
rbenv rehash
sequel mysql://user:password@host/database -C sqlite://db.sqlite

これでデータを MySQL から SQLite に変換できた。Lokka をローカルで起動してアクセスしてみるが記事が表示されない。DB の中にはちゃんとデータが入ってるし、管理画面から記事一覧を表示するとちゃんと記事が表示される。どうも Post.published[] を返すみたい。

手でクエリを投げてみると

sqlite> select * from entries order by created_at desc limit 1;
             id = 960
        user_id = 1
    category_id = 5
           slug = eye-pro-is-shit
          title = Eye-Fi Pro を買ったけどクソだった
           body = [hitode909さんの日記](http://hitode909.hatenablog.com/entry/2013/05/24/093749 "hitode909の日記")...
           type = Post
          draft = 0
     created_at = 2013-10-06 07:28:00.000000
     updated_at = 2013-10-06 13:11:23.000000
frozen_tag_list =
         markup = redcarpet

draft = 0 なので表示されそうなもんなんだけど、よくよく調べてみると SQLite には Boolean 型がなくて、DataMapper は SQLite に Boolean 型のデータを保存するときは t/f の文字列で保存するみたい。これは盲点だった。

結局 draft = 0draft = 'f' に変えてあげればすべての記事を表示できるようになった。

| @技術/プログラミング

一月くらい前から Lokka の master ブランチを自分のブログ用のブランチに merge してサイトをデプロイすると謎の白画面が出るようになっていて困っていた。現象は極めて謎で、ローカルの開発環境(RACK_ENV='development')では見られず、本番(RACK_ENV='production')だけで発生した。HTTP ステータスコードは 1054 が返ってきたりする。なんか変な gem でも入れてしまったかなと休みの日に動作検証したりしていたんだけどついぞ分からなかった。

SQL 弱者なので気がついてなかったんだけど、2月15日の commit で Site モデルに新しいフィールドが追加されていた(Add default markup in admin/site/edit · 2243dc5 · lokka/lokka ※この機能便利すね)。なので bundle exec rake db:migrate しないといけなかったわけだった。ローカルで動いている開発環境(データベースは SQLite)では Migration なんて行ってないんだけどエラーは出なかった。本番は MySQL で動いていて、こちらでだけエラーが出るようだった。

しかしいざ migrate しようとすると失敗する。

bundle exec rake db:migrate
Upgrading Database...
rake aborted!
Invalid default value for 'updated_at'

のようなエラーが出る。updated_at のデフォルト値がおかしいらしい。このときのテーブルの構造を見てみると以下のような感じだった。

mysql> desc entries;
+-----------------+--------------+------+-----+---------------------+-----------------------------+
| Field           | Type         | Null | Key | Default             | Extra                       |
+-----------------+--------------+------+-----+---------------------+-----------------------------+
| id              | int(11)      | NO   | PRI | NULL                | auto_increment              |
| user_id         | int(11)      | YES  |     | NULL                |                             |
| category_id     | int(11)      | YES  |     | NULL                |                             |
| slug            | varchar(255) | YES  |     | NULL                |                             |
| title           | varchar(255) | YES  |     | NULL                |                             |
| body            | text         | YES  |     | NULL                |                             |
| type            | text         | NO   |     | NULL                |                             |
| draft           | tinyint(1)   | YES  |     | 0                   |                             |
| created_at      | timestamp    | NO   |     | 0000-00-00 00:00:00 |                             |
| updated_at      | timestamp    | NO   |     | CURRENT_TIMESTAMP   | on update CURRENT_TIMESTAMP |
| frozen_tag_list | text         | YES  |     | NULL                |                             |
| markup          | varchar(255) | YES  |     | NULL                |                             |
+-----------------+--------------+------+-----+---------------------+-----------------------------+

調べてみたところ MySQL の Mode が NO_ZERO_DATE になっている場合、MySQL は timestamp 型のフィールドのデフォルト値に 0000-00-00 00:00:00 みたいな値を設定することを許さないらしい。 mysql - Invalid default value for 'create_date' timestamp field - Stack Overflow

検証用に別にテーブルを用意して bundle exec rake db:setup してみたところ、以下のような構造のテーブルができた。

mysql> desc entries;
+-----------------+------------------+------+-----+---------+----------------+
| Field           | Type             | Null | Key | Default | Extra          |
+-----------------+------------------+------+-----+---------+----------------+
| id              | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| user_id         | int(11)          | YES  |     | NULL    |                |
| category_id     | int(11)          | YES  |     | NULL    |                |
| slug            | varchar(255)     | YES  |     | NULL    |                |
| title           | varchar(255)     | YES  |     | NULL    |                |
| body            | text             | YES  |     | NULL    |                |
| markup          | varchar(255)     | YES  |     | NULL    |                |
| type            | varchar(50)      | NO   |     | NULL    |                |
| draft           | tinyint(1)       | YES  |     | 0       |                |
| created_at      | datetime         | YES  |     | NULL    |                |
| updated_at      | datetime         | YES  |     | NULL    |                |
| frozen_tag_list | text             | YES  |     | NULL    |                |
+-----------------+------------------+------+-----+---------+----------------+

created_atupdated_atdatetime 型になるらしい。なので以下のような ALTER 文を実行した。

mysql> alter table entries modify column created_at datetime, modify column updated_at datetime;
mysql> desc entries;
+-----------------+--------------+------+-----+---------+----------------+
| Field           | Type         | Null | Key | Default | Extra          |
+-----------------+--------------+------+-----+---------+----------------+
| id              | int(11)      | NO   | PRI | NULL    | auto_increment |
| user_id         | int(11)      | YES  |     | NULL    |                |
| category_id     | int(11)      | YES  |     | NULL    |                |
| slug            | varchar(255) | YES  |     | NULL    |                |
| title           | varchar(255) | YES  |     | NULL    |                |
| body            | text         | YES  |     | NULL    |                |
| type            | text         | NO   |     | NULL    |                |
| draft           | tinyint(1)   | YES  |     | 0       |                |
| created_at      | datetime     | YES  |     | NULL    |                |
| updated_at      | datetime     | YES  |     | NULL    |                |
| frozen_tag_list | text         | YES  |     | NULL    |                |
| markup          | varchar(255) | YES  |     | NULL    |                |
+-----------------+--------------+------+-----+---------+----------------+

これで最新のコードをデプロイしても真っ白画面になることはなくなった。以前遭遇した更新時に created_at の値が更新されてしまう問題 もフィールドの型が timestamp だったのが原因なのだと思う。SQLite から MySQL への移行は一筋縄では行かないことが分かった。

DataMapper はソースコード内の記述内容から動的に Migration を行えるけど、ActiveRecord みたいに $APP_ROOT/db/ ディレクトリに Migration ファイルを作ってくれたりしないので DB スキーマの変更が必要なことに気がつきにくい。便利だけど不便な感じがする。Rails で $APP_ROOT/db/ 以下にアホみたいにファイルが出来ていくの嫌だと思っていたけど、スキーマ変更に気がつかずコードをデプロイしてウェブアプリケーション停止みたいな自体は防げると思った。

ブログ書こうと思ってパソコン開いて「ついでに最新版の変更を取り込むか」とかやるとデプロイできなくなったりして書きたかった記事が書けず残念な感じになる。はてなブログでブログ書いてて画面が真っ白になったらひとでくんさんに不具合報告して直してもらえば良いので楽だと思う。