森ビル開発史マップを作った

「新・都市論TOKYO(集英社新書)」という本を読んでたら、森ビルの歴史が面白そうだなーと思ったので、調べてまとめてみました。

森ビルは六本木ヒルズのような大規模再開発を手がけるデベロッパーですが、その歴史は西新橋の小さな貸しビル業から始まったそうです。

時代ごとに、どんな場所で、どんな規模の開発をしてきたかを知るために、森ビルが手がけたビルやプロジェクトを年代ごとに色分けした地図を作りました。日曜日の朝からNHKの将棋中継も見ないでまとめました。

■1960年代   ■1970年代   ■1980年代   ■1990年代   ■2000年代   ■2010年代

古いほど青く、新しいほど赤くなるように色分けしています。データは森ビルのサイトからひっぱってきましたが、もう建ってないビルは載っていないので残念ながら全部ではありません。ただ傾向は分かるんじゃないかと思います。

都心についてはこれがだいたい全体図ですが、小さすぎてよく分からないので時代ごとにズームしながら見てみます。

1960〜1970年代

■1960年代   ■1970年代   ■1980年代   ■1990年代   ■2000年代   ■2010年代

右上の「西新橋」の文字の近くの青緑色の四角が、森ビルが1956年に最初に建てた「西新橋2森ビル」です。

SAMSUNG CSC

後から竣工した「西新橋1森ビル」もすぐ近くの外堀通り沿いにありましたが、今は取り壊されてしまいました。

その後、1960年代から1970年代にかけては虎ノ門付近に多くビルを建てたようです。青と紫の四角がよく見えます。この時代のビルには「虎ノ門35森ビル」のように名前に数字がふられていたため、ナンバービルと呼ばれたとのこと。

1978年のラフォーレ原宿は、初めての商業施設であり、初めて港区の外でおこなった開発でもあったようです。この頃からちょっと手を広げ始めた感じですね。

 1980〜1990年代

■1960年代   ■1970年代   ■1980年代   ■1990年代   ■2000年代   ■2010年代

この時代の大きな成果は、左にある紫の大きな領域、1986年のアークヒルズです。

SAMSUNG CSC

アークヒルズは、赤瀬川原平の「超芸術トマソン」で「ビルに沈む街」としてまさに開発中の様子が取り上げられた場所でもあります。有名な煙突写真が撮られたのとほとんど同じ場所に、アークヒルズの煙突が建っているのは偶然と思えない、ということが本にも書かれていますね。SAMSUNG CSC

このアークヒルズが、単一のビルにとどまらない面的な開発の足がかりとなりました。

次の大きな開発は1999年のお台場ヴィーナスフォートでだいぶ間が開くんですが、別にさぼってたわけじゃなくてずーっと次の準備をしていたようです。

2000年代以降

■1960年代   ■1970年代   ■1980年代   ■1990年代   ■2000年代   ■2010年代

地図左下、2003年の六本木ヒルズは、森ビルとして最大の開発になりました。計画開始は1986年だそうで、まさにアークヒルズ竣工の年なんですね。それから17年間も、ずーっと六本木ヒルズの準備をしていたと。

roppongi

何百人もいる地権者を説得してすこしづつ買い上げたりとか、森ビルのプロジェクトはこんなふうに長い時間をかけてようやく実を結ぶということがあるらしいです。

2006年には表参道ヒルズの再開発もありましたが、こういう派手な開発ばかりじゃなく、2009年には芝三田森ビルという小さなかわいいビルを建てたりもしていて、なかなか好感度アップです。

2014年の虎ノ門ヒルズは、森ビルがこれまで虎ノ門周辺で手がけた小さなビルに囲まれた、少なくとも場所的には原点回帰の開発となったんですね。地図を描いてよく分かりました。

丸の内をどかんと払い下げられた三菱と違って、森ビルは何もないところから少しづつ自力で港区を開拓していった。一案件に17年もかけたりして。なんとなく悪者のイメージありましたけど、そういうところはすごいなーと思います。

全体の地図はここから見られます:「森ビル開発史マップ
間違いなどあればご指摘ください。

参考:森ビル公式サイト「ビル一覧

追記:

フォトグラファー/ライターの大山顕さんが、森ビル開発史マップを年代ごとにアニメーション化したものを作られました。

故郷に錦を飾った森ビル | 「住宅都市整理公団」別棟

森ビルの開発の場所や規模がどう移り変わってきたかが、アニメにすることでとても分かりやすく表現されていてすごいです。ぜひ見てみてください。

ISUCON4本戦にチーム「ナイスカロリー」で参加して4位に入賞しました

ISUCON というのはITエンジニア向けのコンテストで、課題となるウェブアプリケーションをチューニングしまくって、出来る限り多くのアクセスをさばけるようにしようというものです。

第4回めとなる今回は、主催がLINE、出題はクックパッド、インフラはテコラスさんという贅沢なものでした。参加者は3人1組のチームで、今年は185組が予選に参加、そのうち上位28組がLINE本社で開かれる本戦に参加することができます。

同僚の @h_nakamura、@kawataso とともに「ナイスカロリー」とういい加減なチーム名で予選に参加したところ、主に同僚二人の活躍でなんと予選突破、11月8日(土)にLINE本社で開かれる本戦に参加できることになりました。

SAM_9184

 

LINE本社といえば渋谷ヒカリエです。こんな環境で予選突破した猛者たちと本戦を戦うことになり、当日はたいへん浮足立っておりました。

会場はこんな感じのおしゃれな場所です。

IMAG0189

 

さっそく窓際のよさそうな場所を確保しました。真ん中に写ってるのが同じチームの二人です。

11時にコンテストが開始されると、レギュレーション、つまりルールが公開されます。これをちゃんと読んでおかないと、後になって「そんなルールがあったの?」ということになって時間を大量にムダにするので、とにかく熟読しました。実装言語はいくつか選択できるのですが、慣れているPHPにしました。

課題となるウェブアプリケーションの見た目はこんなでした。

スクリーンショット 2014-11-10 10.44.22

 

動画広告配信のウェブアプリです。まずこれがどんなアプリなのかを把握しないといけません。おおよそ次のようでした。

  • 広告主は、広告の表示場所(スロット)と、クリックされた後のリダイレクト先URLを指定して、動画を入稿する
  • 広告を掲載するサイトは、スロットに登録された動画から1つを選んで表示する。
  • ユーザーが広告をクリックすると、リダイレクト先へジャンプする。
  • 広告主は、広告が表示された回数、クリックされた回数のレポートを閲覧できる。

動画についてはサンプルが用意されているのですが、出題チームががんばってつくったなーという感じの伝わるほのぼの映像となっていました。

スクリーンショット 2014-11-10 10.51.39

どんなアプリなのかがだいたい分かったので、つぎは計測します。チューニングの鉄則として有名な言葉が「推測するな、計測せよ」です。どこにボトルネックがあるのかコードから推測するのは効率が悪いし、はずれることも多い。とにかく計測が大事です。

ボトルネックを計測するために予選のときから準備したのは、

  • ウェブサーバーのアクセスログに応答時間を追加し、LTSVで出力する
  • LTSVを処理し、一回のベンチマークでアクセスされたURLごとの処理時間の合計を出す

ということです。URLごとの合計時間は、PHPの初期実装では次のようでした。

POST /initialize HTTP/1.1 0.082
GET /me/final_report HTTP/1.1 0.32
POST /slots/*/ads 29.944
GET /me/report HTTP/1.1 40.462
GET /slots/*/ads/* 50.821
GET /slots/*/ad 52.249
GET /slots/*/ads/*/redirect 53.722
POST /slots/*/ads/*/count 59.053
GET /slots/*/ads/*/asset 380.54

右端の数字は、合計の処理時間のマイクロ秒です。これを見ると最後の GET /slots/*ads/*/asset にもっとも時間がかかっていることが分かります。

レギュレーションを読むと、どこに何点の配点があるかということが分かるので、それをもとにもっともスコアに効いてくるボトルネックを順につぶしていくということをひたすら繰り返すことになります。

本戦ではサーバーが3台ありました。動画をとにかく数多く配信することがスコアアップにつながるようでしたので、キャッシュサーバーを前に2台を置いて1台をアプリサーバーとするというようなチューニングをしていたところ、5位以内くらいに浮上するようになりました。

スクリーンショット 2014-11-08 13.30.43

 

コンテストのあいだは、こういうランキングが随時更新されるのです。「ナイスカロリー」が僕らです。

いろいろやっていたのですが、どんなチームもまだ1万点を超えないという状況の中、「チームフリー素材」というチームがいきなり30万点を出して衝撃が走りました。その後その点数は消えてしまったので、ベンチマークのバグかな―とおもってやりすごしてしまったのですが、本当はバグじゃなかったようです。後で分かるのですが、実はそこがポイントでした。

コンテストの終了間際になり、ぼくらのチームはベンチマークのスコアが安定しない、というよりベンチマークの出す原因不明のエラーにより0点になるという状況がずっと続きました。その状況が改善しないまま19時に競技終了。これはもうだめか、最下位か・・と思いながら発表を待っていると、なんとちゃんとスコアがつき、しかも14448点で、4位でした!

56f563d4
ぼくらのチームです。写真はISUCON公式ブログからお借りしました。

しかし、1位のチームはなんと61万点。ぼくらの40倍です。じつはベンチマークプログラムが賢くて、Cache-Control ヘッダを適切にかえしていれば、次から同じ広告は取得しに来ないので、結果的に広告をたくさん配信できた、ということだったようです。33万点というスコアを見てその可能性に気づいたのはトップのチームだけだったようですから、ぼくたち参加者は出題者に完敗したような気分です。

ともあれ、たくさんの参加者の中に身をおいて、純粋にエンジニアとして競争するというのはいままでにない経験で、得るものが多かったです。優秀なのはチームの他の二人でぼく自身はあんまり何もしてなかったとはいえ。

最後になりますが、LINEの主催チーム、クックパッドの出題チーム、テコラスのインフラ提供チームのみなさんには感謝の言葉しかありません。傍から見ていても本当に大変そうでした。特に出題チームの3人は、前日から徹夜したうえで、当日もベンチマークの不具合対応などで終始忙しそうでした。次回も開催されるようですが、ぜひ主催側に無理のない形やスケジュールで開催していただければと思っています。ありがとうございました。

Io言語の if then else の実現方法がかっこいい

Io っていうプログラミング言語の if then else の実現方法がむちゃくちゃかっこよかったのでメモ。

まず if then elseの見ためはこんな感じ。

if( 4 % 2 == 0 ) then( "偶数" print ) else( "奇数" print )

この場合は、4を2で割った余りが0なら「偶数」と表示され、そうでないなら「奇数」と表示される。この if then else はこういう構文があるわけじゃなくて、メソッドチェインで実現されてる。そこがかっこいい!

具体的には上のコードはこんなふうに評価される。まず先頭の if( 4 % 2 == 0 ) は実は if メソッドを引数「4 % 2 == 0」で呼び出すという意味で、4 % 2 == 0 は真なので true オブジェクトが返る。なのでこうなる。

true then( "偶数" print ) else( "奇数" print )

つぎに true then( ”偶数” print ) が評価される。これは true オブジェクトのthenメソッドを引数「”偶数” print」で呼び出すという意味だ。これは引数を評価したうえで nil を返す。まず、引数の「”偶数” print」は「偶数」という文字列のprintメソッドを呼び出すという意味なので、「偶数」という文字が表示される。そのうえで nilが返るからこうなる。

nil else( "奇数" print )

これまで同様、これは nilオブジェクトに対する elseメソッドの呼び出しになるんだけど、nilはelseメソッドに対してなにもしないので、「奇数」という文字は表示されない。これで if then else がみごとメソッドチェインで実現されたことになる!

なお、ふつうの言語なら上の例で elseメソッドに引数「”奇数” print」が与えられたら、まず引数を評価してから elseメソッドの本体に渡すので、「奇数」はどうしても表示されちゃう。Io の場合は引数の評価が遅延されるのでこういううまいことができる。

ちなみに else と then を逆に書いても問題なくうごく。つまり、

if( 4 % 2 == 0 ) else( "奇数" print ) then("偶数" print )

と書いても大丈夫!具体的に評価を追って行くと、さっきと同じように冒頭の if がまず true になる。

true else( "奇数" print ) then("偶数" print )

trueオブジェクトにelseを呼ぶと、引数を無視して単にtrueオブジェクトを返すから、

true then("偶数" print )

こうなる。これはさっきもやったとおり “偶数” と表示されるので、これで終わり。なるほどーって感じだ。

if then else が制御構造じゃなくてメソッドだっていうのはどうやら Smalltalk に由来していて、それっぽい ifTrue() とか ifFalse() っていう書き方も別にあるようなんだけど、ぜったいこっちの if() then() else() のほうがかっこいいと思う。

主役のせいでキャプションがずれる

駅で電車を待ってたら、目の前の看板で冨永愛さんが片桐はいりさんになっていた。

1

これは違う。片桐はいりさんはこんなエラじゃなかったはずだ。と思ったら、左隣では本物の片桐はいりさんが寺島しのぶさんということになっていた。

なるほど、これはキャプションがずれてるんだ。

2キャプションのずれはちょうど赤線のようになっていた。一番右の松尾スズキさん辺りでは合ってるのに、左に行くに従ってずれてる。なんでこんなふうになっちゃったんだろう?

よく見ると、一番左に「大森南朋」と名前だけがあって写真がない。これがカギだ。もっというと、これはキャプションじゃなくて、写真とは独立に役者名を並べたテキストが、偶然キャプションに見えていただけなのだ。

じゃあ大森南朋さんの写真はどこにある。

3

なるほど。すべては主役の写真だけを別枠にしたせいだったのか。

今日、気づいたこと。

主役のせいでキャプションがずれる。

江戸の海岸線を散歩する

新潮講座で「東京『江戸の海岸線』散歩」というのをやります!

  • 東京「江戸の海岸線」散歩(全3回)
  • 2013年 10/12、11/9、12/14(毎月第2土曜日)13:00~15:30
  • 第1回「品川・高輪篇」、第2回「八丁堀・鉄砲洲篇」、第3回「小名木川・深川篇」
  • 受講料+教材費 9675円(3回分)
  • お申し込みはこちらから

今日は第1回の品川の下見をしてきました。場所は旧品川宿。

SAMSUNG CSC品川は目黒川の河口に沿って中世から栄えた町でした。
なのでもともとの本場はいま品川駅がある辺りじゃなくて、もうちょっと南。新馬場駅とかの辺り。

SAMSUNG CSC

品川が湊として栄えたのは、目黒川が上図左みたいに蛇行してたから。蛇行によって海側に砂州ができて、自然と防波堤みたいになり、船も泊めやすかったという経緯で湊が発展したようです。

京急の北品川駅あたりを通る旧東海道は海岸線のすぐぎりぎりを通ってたので、道から海側を見るとこんな感じ。

SAMSUNG CSC

すとーんと落ちてる。300年前はこの先がもう海でちゃぷちゃぷしてました。

旧東海道筋は、さすがに江戸時代から残ってる建物はほとんどないものの、昭和の始めくらいの雰囲気のものは結構残ってます。

SAMSUNG CSC

見事な銅板葺きの看板建築。

SAMSUNG CSC

それに煉瓦塀。なかなか素敵でしょう。

「東京『江戸の海岸線』散歩」。ご参加お待ちしてます。