カテゴリー: テクノロジー

  • 現代祭事の合理性(その3)

    お祭りには防災訓練、準備としての機能。神社仏閣には地域住民が避難でき、城としても使えるような立地の合理性があることをみてきた。その3では、技術の伝播、継承の場としての神社仏閣を考えたい。

     

    日本を代表する出雲大社と伊勢神宮、諏訪大社間では掘立柱建物と、礎石・土台建物、高床建築や平屋建物などの建築様式の戦い、さらには稲作などの主食物の伝播の戦いであったとも考えることができるのだが主題からそれるので今回はおいておく。

    今回は、神社が技術の伝播や継承に重要な役割があったのではないかという示唆だ。

    式年遷宮のような露骨な伝承のことをいっているのではなく、注連縄や、鳥居のような些細な様式についてである。

     

     

    建築構造物としての鳥居

    なぜ鳥居が建てられるのかという問いに宗教的には結界で神威を封じる結界だとか、神様の領域の境界だという答えがあるかもしれない。だけども、それらの答えは現代科学のもとに生きているおっさんには、熟練技術者が新米に細かい説明がめんどくせぇし、言ってもわかんねぇだろうから「おまじないだから覚えとけ」って言い含められたのと似たようなものだとうがった見方をしてしまう。

     

    現代につたわる鳥居には何パターンかあるが、あれはいったいなんなだろう?
    共通要素はなんだ?
    鳥居の最低限の共通要素は、「自立している2本の柱と、それを繋ぐ2本の梁があること」だと考える。
    では、なぜそんなものを建てよう、建てたほうがよいと考えたのだろうか?

     

    鳥居の種類、分類はいろいろまとめられてはいるが(※文末に引用あり)、なぜそのように種類が増えたのか、なぜそのような構造物が建てられるようになったのか「そもそも」の合理性を説き教えてくれるものはない。
    なぜ鳥居を立てようと思い、それが様式として継承されてきたのか?

    そういう宗教だからという答えは思考の放棄だ。

    鳥居のようなものを建てたほうがよいと考えた故人が居て、それが継承されてきたからには、そこになんらかの合理性があったに違いない。日本人には見慣れてている鳥居だが、そもそもあれはなんだと考えたことあるだろうか??
    調べても鳥居についてはあまり資料がないのが残念。
    しかたないので仮説を立てる。

    あれは、歴史の一点に登場した、稀代のウイザード級ハッカー(連中)がつくりだしたテクノロジーをロストさせないための「おまじない」ではないか。

     

    なぜそのように考えたかというと、あんなシンプルな鳥居に、木造家屋をつくるのに必要な技術要素がてんこ盛に盛りのフラッグシップモデルになっているからだ。

     

    2016-01-14-16-53-01

    これは近所の八幡にある木造の鳥居だ。
    メインの大鳥居は石造りなので木造の小さいほうを撮影した。
    ちょっと装飾がゴテゴテしているが、まずはこの写真をじっくりみて、いったいこれはなんなのか考えてほしい。
    木造6本足基礎石オス型屋根付き鳥居型。
    土台、基礎石の上に柱が立てられていて、それに横木の梁を通していて、上はのっかる形で留めてある。おそらくホゾが掘ってあって組み上げてあるのだろう。
    横梁が抜けないように楔(くさび)もみえる。金の円盤っぽいものは釘隠しだろうか?
    木が腐らないように、切口が金属でカバーされていて、この鳥居に限っては屋根までもついていて、わーぉって感じ。雨仕舞用の水切りや、垂木(たるき)の鼻隠しっぽいものまでついててやり過ぎかっ!って感じもする。
    でもね、こんな簡単な構造物に昭和ぐらいまでの木造建築物の主要要素の大部分を含んでいるんだよね。
    鳥居は釘や留め金をつかわずに組み上げられ、柱だけで自立している。

    つまり木造の鳥居を建てられるならそれを真似すれば普通の家の構造体も建てられることを意味する。
    作りを真似るだけでよいものが、誰からも見える場所にあるところがミソ。
    鳥居はそれだけで先輩職人の技を見て盗む、学ぶことができる見本現物だ。

     

    文字も動画もなく、学校も徒弟制度もなかった時代。
    技術を持っている職人が弟子を残さずその地域から移動したり、不慮の死などでいなくなるたびに、技術が当代のみでロストしてしまう。しかし、鳥居のような、このようにやればよいという見本、現物が残れば、それを見本教師とすることができる。

     

    鳥居は風雨にさらされ痛みも激しく、家よりも頻繁に修理補修がなされる。はずだ。と思う。
    傷んだ鳥居を立て直すたびに、構造が分解、リバース・エンジニアリングされて修繕した人物らに技術が伝播していく。余計な装飾がないので、構造を学ぶのに適した見本だ。
    その構造は習熟訓練の教材としてもとてもよくできている。

     

    鳥居を自立させるために、穴を掘ってそこに立てる掘っ建て建築様式や、添え足をつけて、基礎石建築どちらの方式をとるにしても、技術練度が低ければ鳥居を自立させることができないし、横棒(梁)を渡すことができない。
    低い技術力ではすぐに倒れてしまうし、横棒も上にのせたりでっぱりに引っ掛けたりするだけではすぐ落ちてしまう。

    日本は台風も地震もある地域だから石組みよりも倒れない木組み技術が必要とされた。
    もし、見よう見まねで自立する構造物を建てられたとしても、技術力が低ければ小さな鳥居しか立てることができない。その本質がわかっていなければ割り箸ですら鳥居を構造物として再現することはできないだろう。

    鳥居というシンプルなものを建ててみせるだけで、製造物の耐久テストをおこなうことで技術練度の公表もできる。

     

    ちなみにこちらは正面の石造りの大鳥居。

    2016-09-09-11-51-16

    このサイズの石造りの鳥居を安全に自立させておくことができるのであれければ、杭打ビルも建てられるよね。

     

    伊勢神宮でおこなわれる式年遷宮は技術をロストさせないための工夫らしい。
    しかし、あれは大掛かりなピンきりでいったらピン側、トップノッチ連中のための技術の伝承だ。
    民草、民衆の家屋を立てるのに最低限必要な木造建築の技術はどのようにおこなわれたか?
    字が読めない人にでもわかるように、誰からも見えるようにするための教材としての鳥居だ。

    もしかして鳥居はそれとは知られずに文字にも指導者にも頼らず技術者の伝承につかえるすげぇ教材システムとして機能してきたのではないか。

    だとすれば、考えたやつすげぇと思うのである。
    まっ、買いかぶりかもしれないんだけどね!

     

    メス型鳥居

    上で紹介した八幡の鳥居は下側の梁が飛び出ているのでオス型と呼んでいる。
    でていないものはメス型と呼んでいる。個人的な命名。
    子ども頃に不思議におもっておとーちゃんに聞いたことによると主神が男なら下の梁がでているオス型、女神だとメス型だと言っていたが真偽はわからない。
    天照大神とか、弁財天とかはメス型なので、たぶんそれであっているような気もするけど、微妙に違う気もする。

    こちらは今話題の築地市場場内の鳥居。

    2016-09-08-10-38-17

    石造り2本足自立掘っ建てメス型丸鳥居型。

    水があるところの神様は女の神様が多いので、たぶん女神のような気もするけど、どうでしょうね。
    魚河岸水神社かな。祭神は弥都波能売神(みづはのめのかみ)なので女神っすね。
    最近の建築物は石造りなので、鳥居も石造りのものが多い。
    コンクリートや、石材の加工技術がないと作れないが、2本足がたも恐らく昔はほとんどが木造であったものと考えられる。

     

    2本足なので、穴を掘って埋めてまわりを固めることで自立をさせている。
    電信柱のような建て方だね。

     

    竪穴式住居の時代からつかわれてきた建築方法だ。
    !!いまの、いままで縦穴式って書くんだとおもってたよ!!
    縄文時代程度の建築技術でも自立した構造物をつくれる。

     
    メス型の鳥居は下側の梁がとび出ていない。
    釘やカスガイをつかわずにこの梁を留めるためには、ホゾ組の加工技術が必要になる。
    上の梁も落ちないようにするためには同じ技術が必要だ。
    梁を2本渡すことで、斜め方向の揺れで倒れることがなくなる。
    もし、鳥居の梁が1本だったら構造体としてすごく弱いし、凸凹の受け側が逆になっても構造として安定しない。

    シンプルな構造にして洗練されている。

     

    豊洲に建造される神社の鳥居にはぜひ子々孫々のためメンテナンスのための地下ピットを盛り込んでほしい。

     

     

    白木鳥居

    こちらは福島県の大内宿にある高倉神社。藁葺きの建物群からもわかるとおり、タイムスリップしたような村。

    img_0606 img_0615

    より原初の鳥居の構造を現代に伝えているように感じる珍しい白木タイプの鳥居だ。

    木造2本足自立掘っ建てメス型白木丸鳥居型。
    とても特徴的な鳥居で、どちらも左が根っこ部分の太さを残したままのせている。

    内側から見れば左頭とかなのかな??

    ホゾ組もより原始的で、太い柱に細い丸太の頭をそのままつっこんで組み上げているように見える。

     
    余談だが、こちらの神社、内殿にあがっていくと鳥居が足6本のオス型になる。

    img_0617

    オス型、メス型の混在は珍しいなと思った。

     

    朱塗り、黒塗り

    同じく福島よりさざえ堂があるところの中腹の神社。厳島神社。

    img_0557

    一番最初に登場した鳥居と同型の6本足同型だが、こちらは朱塗り。

    木造建築物は朱塗りなど塗装をほどこすことで、より腐食に強くなる。広島宮島の厳島神社の鳥居は、満潮になると海のなかに建つが、もしあれが白木だとあっというまに腐食してしまうだろう。

    漆や柿渋や表面を炭化させたり木酢液をつけたりするだけで、腐食には強くなるので、そういう工夫、技術の集大成だろう。水場に近いところで、無垢の鳥居をたてておくことでアジャイルテストが繰り返された結果習得された技術かもしれない。

    ここの祭神は市杵島姫命は弁才天と習合されていてどちらも女神だけど、こちらもオス型。やっぱオス型、メス型は主神の性別じゃないのかな??

     

    朱塗りに対抗して、こちらは珍しい黒鳥居(黒門)
    井の頭公園のはじっこにあるやつ。

    写真が手元にないので、三鷹の観光案内所のホームページから


    http://www.mitakanavi.com/spot/park/inokashira_benzaiten.html

    枕木なんかと同じ木酢液による黒かな?それとも炭??

    井の頭公園は弁財天なので女神だけど、オス型。やっぱり祭神の性別関係ないかも・・・。

     

    鳥居の数が封じている社格だとか神威の強さを表しているとか聞いたんだけどほんとかね?
    本殿にいくまでに鳥居の数が多いほうが強い神様だとかなんだとか。
    伏見稲荷とかどんだけ強いんだよっていう。

     

    ま、ちょっと主題とずれちゃったけども、今回いいたかったことは、鳥居は大工(見習い)に構造体技術を伝承するための合理性をもった見本だったんじゃないかなという仮説でした。
    同様に注連縄とかも、藁で縄を編むものの技術見本。

    できるだけ太くされていて撚りの構造がわかりやすいようになっている。

    縄が伝承できるようになると、エリアログとなるご神木を切らせないための目印にできたり、一石数鳥だよね。
    場所によっては、編み上げた縄でさらにそこから編んだワラジとかが奉納されていたりするでしょ?

    そもそも御神体の鏡や剣なんかが、産業革命がおきるまでは最先端テクノロジーの塊。

     

    そんなわけで、神社仏閣っていうのはそのご当地の技術展示会を常設しているコンベンション・センターだったのではないかなというのが、今回の仮説でした。仮説だけぶんなげて証明なしで終了。

    どうかな?どうだろう??

     

    参考

    鳥居の構造



    http://blog.livedoor.jp/takamimusuhinokami/archives/421685.html
    魚河岸水神社遥拝所の概要
    http://www.tesshow.jp/chuo/shrine_tsukiji_uogashi.html

     

    福島県:歴史・観光・見所(ホーム)>飯盛山>厳島神社
    http://www.fukutabi.net/fuku/iimoriyama/itukusima.html

     

    井の頭弁財天(大盛寺・黒門)
    http://www.mitakanavi.com/spot/park/inokashira_benzaiten.html

  • iコンピテンシ・ディクショナリと無意識的無能

    情報処理試験やらでお馴染みのIPAさん「いまオシ」のiコンピテンシ・ディクショナリ(以下、iDC)のセミナー聞いてきました。オレが聞いてどうするという感じなのだけれど、聞いたというか、主催側なので・・・。

     

    規模的に60人以上技術者を抱えている受託や派遣型のソフトハウスぐらいからは効果を発揮するんじゃないかなと感じました。業務上ISOとかPマークとかを取得しないといけないような会社にはいいとおもう。iDCはITスキル標準(ITSS)みたいな何かです。2014/7に試用版を公開して、2015/6に2015版を公開、ちょうど今頃に前年の取り組みや実績があがってきた感じです。

     

    プレス発表 企業の目的に応じた人材育成に利用できる「i コンピテンシ ディクショナリ2015」を公開
    https://www.ipa.go.jp/about/press/20150630.html

    ここらへんは情報システムユーザースキル標準(UISS)、組込み技術者スキル標準(ETSS)などわちゃわちゃしているんですが、ここらへんがまとまってきた感じなんでしょうか?流行りもの感はぬぐえませんが、それだけ要望が強い分野でもあります。
    iDCは主にタスクディクショナリとスキルディクショナリから構成されていて、業務遂行にあたりスキルセットを確認するためのチェックツール(というよりリスト)になっています。なんかIT系のヘッドハンターとかがヒアリングしながら値踏みしていくときのチェックしていくシートっぽいよね。

     

    これをつかって抱える人材の弱点や強みの確認や、人材育成や教育にやくだてていきましょう。ということです。
    印象としてはPMBOK(ピンボック/プロジェクトマネジメント標準知識体系ガイド)ぽいなーと。設計のときに相互互換は考慮したというようなことは言っていました。

     
    ただ、なんかこういう評価項目がupWorks(oDesk/海外のクラウドソーシングのサービス)とかにあったら、外国の人、特にインド人とかは全部に◎をつけてゴリゴリっとアピール返してくるよね、と。そういうときどうしたらいいんだろうね?

    学習には段階があって、よくいわれているのは、

    1.無意識的無能:できないことがわかってない状態
    2.意識的無能:できないことがわかっている状態
    3.意識的有能:意識すればできる状態
    4.無意識的有能:意識するまでもなくできる状態

    とかになっているって言うじゃないですか。(たしか本当は5段階)
    こういう自己申告によるチェックリストの場合、

    「できないことすらわかっていない人物」と「できることを意識する必要もない人物」が、同じ自己評価になる可能性があるんですよね。

    例えば、
    Q「(戦略) 市場機会の評価と選定 > ビジネス環境分析手法 > ニーズ&ウォンツの把握」

    無意識的無能くん「◎だろ、余裕ダシ!フンイキでびしばし伝わっし!いつもやってっし!!」
    無意識的有能さん「☓かな。難しいんだよね。こないだも顧客の要望汲み取りきれなかったし…」
    なんて具合いに、予想される成果から判断すると評価が逆転する可能性すらある。
    そもそもできる子のほうが状況把握が正確なので評価が厳し目になる。
    「できる子」は条件が出揃わない状況で安易にできるとか言えないもんですし。

     

    それに、「できる」と言っても、アウトプットが金になるレベルとゴミにしかならないレベルは実際には混在する。そんで、業界や所属会社によってはゴミでも金にできたりするのが、またなんとも・・・難しいところ。
    プログラミングも成果物と実績でしか評価できないという点では、小説家や作曲家とたいしてかわらないのだけれども、「漢字が書ける」「バイエルンが弾ける」を持ってして、同じスキルやタスクを処理できるものとしてあつかっていいものか?
    正確にその部分だけを反復して市場で競争するわけではないから、外形評価も自己評価もとても難しい。
    それに同じ作者だって名作と駄作は混在する。
    定量的な何かがないと、スキルセットとしてはインディケーター(ものさし)の問題がつきまとう。
    人間も負荷をかけてベンチマークをとることぐらいはできるけれども、やはり表層的にならざるを得ない。

    「握力20Kgなのに大車輪ができるのはおかしい」とか、コンピテンシーディクショナリがビッグデータになるほどデータを貯めてスキルやタスクの相関が見えるようになっていけば、無意識的無能と無意識的有能の区別がつくようになるかな?

     

    でもコワーキングとかコライティングとかの協創の未来を予想すると、寄与度がどうこうだとか、いばらの道になるかもしれないし、どうなんだろーねー。

    人から評価されたり評価したりする世界から遠のいちゃってるので、鈍って答えが出ません。

     

    どうおもいます?

  • music hackday tokyo 2015 完走 #musichackday #mhdt2015

    「おい、どうした疲れてんな、まっすぐ歩けてねぇぞww」って、地元の商店街に帰ってきたら近所の店長に声をかけられたんだけど、それもいたしかたのない話し。24時間テレビの裏で24時間プログラミングするという体力勝負のイベント帰りなのだったのだぜよ。

    http://www.musichackday-tokyo.org/

    徹夜明けのテンションで、「100人も集まって2日間もコーディングしてたら200人月だな!」とか言っちゃったんだけど、200人日の間違いでした。謹んで訂正するのでゆるしてください。

    さて、私の参加した即席チーム「歌うドラムbyヒゲメガネ」ですが、残念ながら賞を受賞するには適いませんでした。
    「機能はつくれたけど、バリューは作れなかった。」私談。
    エンジニアだけのチーム構成になっちゃったので、テクノロジー偏重になってしまったのは、楽しかったけど、至らなさを感じ反省した点でもあります。技術的にはケッコウな未来に挑んだと思うんだけど…。

    歌うドラム by ヒゲメガネ
    http://hacklog.jp/works/3378
    「歌うドラム」はあなたの動作や音に合わせてミクさんが歌ってくれる楽器です。例えば「歌うコンガ」「歌う顔」「歌う手」などさまざまな応用ができます。

    担当したのは、オーディオの波形をタイミングに変換してサーバー側に送信する(html5)ところと、受け取った音データをクライアント側でバッファ再生して同音再生するところ。
    どちらも昔つくった奴の流用なんだけど・・・。

    センシングIFとして、JINS MEMEやOMRONにも挑んだんだけど、会場に数百人居てBluetooth何台あるんだってぐらい認識するのと、数時間かけてSDK系で他のチームも苦戦しているのをみて諦めてしまいました。というか隣のチームに他のハッカソンでomronに挑んでSDKあれこれしてたら終わってしまったっていう苦い思い出話しをしてくれた某たぷくんがしてくれて、githubに遺産をあげてくれてたのだけど、何もできあがらない可能性も怖くて勇気が出ませんでした。

    他のチームのハックはこちら。

    <作品名 URL>
    1 OPERALOID by SANMA http://hacklog.jp/works/3414
    2 ランダムプレーヤー with Beacon by Loop-Sessions http://hacklog.jp/works/3413
    3 ROUTE MUSIC by -D http://hacklog.jp/works/3412
    4 Music of Game! http://hacklog.jp/works/3409
    5 Dj Faces by Dj Takaaki http://hacklog.jp/works/3405
    6 にゅうみっくby みゃっくばんど http://hacklog.jp/works/3399
    7 Black pepper by Black Red Hot Chili peppers http://hacklog.jp/works/3397
    8 Squeeze Music by GoGyo http://hacklog.jp/works/3396
    9 おんぱしゃ♪ by 音波社 http://hacklog.jp/works/3391
    10 Crysta -クリスタ- http://hacklog.jp/works/3385
    11 DJ MEGANE by LiveMatch from NEXT http://hacklog.jp/works/3384
    12 眠たい僕の代わりに子供に読み聴かせしてくれる by七辻屋 http://hacklog.jp/works/3383
    13 ORFes by オルフィスト http://hacklog.jp/works/3382
    14 SoundLine by NoMusicNoLifeLog http://hacklog.jp/works/3380
    15 CliMix [クライミックス] http://hacklog.jp/works/3379
    16 歌うドラム by ヒゲメガネ http://hacklog.jp/works/3378
    17 エドガーのええ動画 http://hacklog.jp/works/3376
    18 農クワット by mant http://hacklog.jp/works/3375
    19 Call & Response http://hacklog.jp/works/3374
    20 MINOKONASHI byプライズ欲しい http://hacklog.jp/works/3373
    21 あなたのお供にPepperエアギター by Pepper Guys(仮) http://hacklog.jp/works/3370
    22 Tacitenn – Simplest Multi-angle View Creating For Best Performance http://hacklog.jp/works/3369
    23 ATEFURI http://hacklog.jp/works/3368
    24 OXO – オグゾー by Mash and Room http://hacklog.jp/works/3367
    25 MANDALA by WILD LIFE http://hacklog.jp/works/3366
    26 ODORE by BON BORN http://hacklog.jp/works/3365
    27 nemimi by Kirinsan.org http://hacklog.jp/works/3363

    個人的ピックアップ

    3 ROUTE MUSIC by -D http://hacklog.jp/works/3412
    オルフェっていう光る靴ディバイスで進んだ方向の国の曲を再生していくという、靴だけじゃなくてアイディアも光ってました。

    5 Dj Faces by Dj Takaaki http://hacklog.jp/works/3405
    omronに挑んでハックしたので尊敬。
    顔認識センサで顔の向きや遠近で掛かっている音楽にフィルター系のエフェクトをかけて行きます。
    複数人再生で同時再生ができます。プレゼンがすごく面白かったです。

    8 Squeeze Music by GoGyo http://hacklog.jp/works/3396
    トラブルが重なって発表が一番最後になったチームだけど、優勝をかっさらいました。
    ムードなどを解析するAPIで曲の感情分析をおこない、それを元にカクテルをつくる装置です。
    Maker Faire に並んでたら、受けるだろうなとおもってたんだけど、見てわかるに勝るプレゼンス力はないですね。

    13 ORFes by オルフィスト http://hacklog.jp/works/3382
    大勢のチームでデザイナーやダンサーやらで構成されていて、見た目にインパクトがあるガジェットを選択していたので、受けそうだなと思ってたのだけど、デモを中心にプレゼンしたらよかったのにと思った次第でした。

    15 CliMix [クライミックス] http://hacklog.jp/works/3379
    ページのめくる速度とスクロールの速度から、クライマックスに音楽のハイライトがくるようにするというアイディでした。漫画のクライマックスを高精度で判定できてたらすごいことだなと思いました。漫画のコマの大きさや、書き文字の大きさなどで判断するそうな。
    漫画と音楽というコンテンツの親和性からお金の匂いを感じられたようですよ。

    16 歌うドラム by ヒゲメガネ http://hacklog.jp/works/3378
    司会「肩も凝ってきたので背伸びしましょうか」
    からの、「はんずあっぷ!くらっぷゆあはんず~!」と、ドラムドンドンって初めてしまったのだけど、あそこでドラムで魅了できるほどの腕前があればなんとかなったかな……。

    17 エドガーのええ動画 http://hacklog.jp/works/3376
    会場の今日一番の大爆笑をかっさらって行きました。
    カラオケとかで、ムービーと曲があってないよっていう問題を解決するために、
    歌詞をのkeywordを使って、google apiで関係がある画像を取得・・・。
    世界の終わりのドラゴンナイトからエロゲーやらなにやらの様々なネタ動画を織り交ぜた素敵なMPVができあがって、みんだニコニコした世界になりました。前座を温めたかいがあったぜ。

    18 農クワット by mant http://hacklog.jp/works/3375
    音楽の未来が行き過ぎて2085年にまで行ってしまった彼ら。
    音楽とは耕すことだという謎理論に辿り着き、中間発表で「今はクワを買いにいっているところです」という展開がさらに謎を呼び、発表の寸劇は個人的には大満足でした。テレビの取材だったらこのシーンを採用します。

    19 Call & Response http://hacklog.jp/works/3374
    私評価では一番スキルと完成度が高いハックだったのじゃないかと感じました。

    1.楽曲の音源を取得
    2.docomo 音声入力APIを利用し、音源の歌詞を言語データに変換
    3.言語データをdocomo 対談型APIに与え、歌詞に対しての返答を取得
    4.返答のデータをVOCALODUCERに与え、自動で返答を歌詞にした楽曲(mp3)を生成
    5.生成された楽曲を再生

    さらっと機能が書いてありますが、同じような機能実装をやったからわかりますが、ハッカソンでこの完成度まではなかなかたどり着くものではありません。

    21 あなたのお供にPepperエアギター by Pepper Guys(仮) http://hacklog.jp/works/3370
    一番激しく、pepperをチューニングしていました。壊れるーー

    22 Tacitenn – Simplest Multi-angle View Creating For Best Performance http://hacklog.jp/works/3369
    前日のブログでも書きましたが個人的にはもうひとつ挑みたかったジャンルの多視点映像です。
    なにげに撮影をお手伝いしました。

    ピックアップしなかったのも多くありますが、どれも面白かったり興味深かったです。

    togetterにもまとまってます。
    http://togetter.com/li/864762

    反省点

    遅刻しました。ごめんなさい。
    伝えるアビリティ大切。
    会場の入退室厳しかったです。
    椅子が硬いところでの徹夜は死にそう。
    メタ情報系のAPIが多くて前回みたいなEcho NestやsoundcloudのようなAPIがなかったのが残念です。
    チーム参加が半数以上居た感じですが、前回のmusichackdayに一緒に参加した人たちの当落率は2/5で、エンジニアだけしか受からなかったので残念です。
    そのわりに個人参加のデザイナーやプランナーの参加が5~6人と超少なくてチームビルドに苦労しました。しかもオルフェとかそういう派手なガジェットに数人固まってしまって、結局獲得できなかった…。