Drafts

@cm3 の草稿置場 / 少々Wikiっぽく使っているので中身は適宜追記修正されます。

最近、Twitterでよくワードブロックする

(最近、まじめな職務系の話をしてたけど、今日は単に愚痴っぽい何か)

基本炎上事案って苦手で、その苦手さはいろんな側面があるけれど、「もー、その話何度も出てるよねー?」って言いたくなる意見を怒りみたいな重い感情乗せて言ってるの見るのが嫌いなのかも。「世の中が変わらないから同じことをずっと言い続けていかなきゃ」って思考回路なんだろうし、それが有効か無効かっていえば(自分であまり考えることのないとか)ある種の人たちにとっては有効だったり、その話題に新規参入する人たちにとっては有効なんだろうけれど。「もしかして、何か自分の気づいてない大事なこと言ってるんじゃないかなー」ってTwitterのリプとか辿って、結局公文式みたいに「それは〇〇って定番の反論と、その反論に対する××って定番の再反論と」みたいな答えをどれだけスピード早く思い浮かべられるかみたいな競技っぽくなって、その割にだいたいのツイートがill definedな言葉遣いをしているので解釈の部分に疲労した挙句、「なにこの新規性の無い議論」ってことが多くてしんどい。

あと、問題解決って形式を取らないで、言葉の殴り合いみたいになってるのが、野蛮で非生産的な感じで嫌い。

…ってところまでは、僕にとっては新規性の無い言明なんだけど、ここからが最近やりはじめたことと気づいたこと。

炎上に対するツイートでタチが悪い(?)のが、たまに、新規性があったり、説明がめっちゃ上手かったり、新しい角度の意見があることで。知的新規性の報酬が大きすぎて、射幸性の高いガチャに(時間を)過剰課金みたいな状況になるから、抜け出したくてブロックしなきゃな―と最近遠慮なくブロックするようにしている。その時にどういうワードをブロックするかが問題で、抽象的なワードをブロックすると影響範囲が広いので、商品名とか具体的なワードでブロックして、durationを7 daysにするという運用をしている。炎上があった時に年単位で昔の事案と比較してちょっと遅れてブログで解説するような人の意見は大抵ある程度有益で(脊髄反射してるんじゃなくて、その話題についてある程度考え続けているということだからね)duration も大事かも。

で、ついでに気づいたのは、問題解決って形式で整理された議論になってないと、自分でそれをやろうとして無駄に疲れてしまうのは、ある程度誰でもそうだと思ってたけど、たぶん僕はそれが極度に強いんだろう。論文の引用に関しても、その総体として議論が体系化されにくい現状にもフラストレーションを抱えていて、それは知識共有の研究において一つのモチベーションにもなっているくらいだし、議事録を整理して目的のある何かを運営することにパフォーマンスを発揮しがちだし、こんなことに強く悩まされるのはちょっと特殊な性分が原因かもしれないなと。つまり、知識が文脈を超えて共有・利用可能に整理されてないと気が済まない、吐き気がする、みたいな。2011年ごろその欲望に忠実なテーマを先生にやりたいですって言って、問題がill definedだからやめとけって言われて、紆余曲折あってテーマが決まったという経緯がけっこう忘却の彼方にあったんだけど(7年も経ってるよ)もう少しそういう自分の特性を意識しといたほうが幸せになれるかもなぁ。

ResourceSync について最近あったQA

口頭でどこかで答えたりしたことをメモっておいてツッコミ可能にしておく。

ResourceSyncって何?(ツイッター的140字)

ResourceSyncとは:OAI-PMHの後継と目されている静的連携のためのプロトコルで、sitemapsを拡張したもの。メタデータだけじゃなくてコンテンツも同期の対象にしうるとこと、情報発信側からのプッシュが可能なことが特徴。まだ普及していないが幾つか実装はある。詳しくは http://current.ndl.go.jp/ca1845 参照

ライブラリとかソフトウェアの実装状況は?

は上の記事にも載ってるけど、一番使いやすそう。他、時期的に上に漏れてる話として僕が把握しているのは

(こういうのは Scrapbox とかで Wiki 的にupdateすべきだ…)

resumptionToken の代替は?

OAI-PMHでは、3.5の Flow Control に resumptionTokenを使ってちょっとずつリソースを取ってくる実装がmust指定されている 。今こういうのは必要なくなっているのかというと、確かに回線は安定したし、太くなったし、必要は薄れているんだけれど、ResourceSync は zip で固めたコンテンツも流すんだから、その分ダウンロードが途中で切れるとかいう問題も発生しうると思う。最も大事なのは、ResourceList も複数に分けることができるのだから、ある程度は適切なサイズになるように設計すること。そして、適切なサイズのダウンロードに失敗するようなら、もう一度取りに行けばいい話。

一応、巨大ファイルの断続的ダウンロードについての解決策も、もう一つ低レイヤーの解決策が普及してきていて、HTTP range requests を使えばよいと思う。

増分同期で from で指定したいのはこっちが前回いつとりに行ったかじゃない?

ResourceSync にも Resource List の at や Change List の from といった情報があるがこれは情報を出す側の視点であって、取りに行く側からはどれを取りに行ったらいいかが OAI-PMH より複雑、というのはそれはそう。差分を処理したいときには、Change List Index から順に辿っていって、ダウンロードが必要か必要じゃないかを1つ1つ判別しつつクロールしていくことになる。resync/resync at master · resync/resync にも from オプションがあったりして、そういう利便性はライブラリレベルで解決されるべきだし、そういう方向性になっている。基本的にコストをハーベストする側に載せているので、ハーベストする側が実装を工夫する必要があるケースは他にもあると思う。

PubSubHubbub の実装は必須なの?

まず、PubSubHubbub (PuSH)じゃなくて、今は WebSub に名前変わってる。それを使う Change Notification と Framework Notification が "Additional" Specifications になっているので、必須じゃないです。Hub になるとこをどこが担うの?とか組織連携的な課題があるので、研究実験や必要性を検討した上で必須だという結論に至った実装でない限り、実装は後回しで良いんじゃないかな。

だったら OAI-PMH から移行する動機は?

  • 十分な大きさの画像サムネイルを同期したいでしょ?
  • アーカイブ」ならEADが大事だったりするし、メタデータの構造やファイルフォーマットはもっと自由に書きたいでしょ?
  • もう、グーグルに拾われないとそもそも流入が望まれないのでSEOも運営上大事で、sitemaps 互換なのでSEOにもなる。

(僕はデジタルアーカイブや研究資源データベースに関する相談で聞かれるので、そういう偏りのある回答ではある)

sitemaps から、連携の必要性に応じて増築していって、ある時点で整理するという形でもよいかも。

ジャパンサーチがOAI-PMHでデータ取るって聞いてるんだけど

tl;dr OAI-PMHは必須じゃないし、ResourceSync ベースでもなんとかなりそうだよ。

僕も、OAI-PMHとウェブサイトから手動でアップロードの2つだって聞いてる。でも、ジャパンサーチ(仮称)の連携フォーマット(案) の冒頭の方に、「連携を容易にするため、原則、ファイルベースでの連携を行う(OAI-PMH は必須としない)」と強調されているように、ファイルベースになるなら ResourceSync も親和性が高いのではと期待はできる。「複数のファイルをzip形式で圧縮したファイルにも対応する。」となっているが、余計なファイルが含まれているとエラーになるようなので、ジャパンサーチ専用にファイルを生成する必要はでてきそう。それが特定の Resource List Index から自動生成できるだろうから、Resource List Index の URL を入れると、必要なファイルが返ってくるというものを誰かが作れば済む話ではある。「連携機関のメタデータモデルをそのままの形で受け入れる。メタデータモデルは原則として自由であるが、最低限の必須項目(①オリジナル(ソース)データの一意の ID、②名称/タイトルの 2 項目)がある等の制約を設ける。」というのも先ほどの自由なメタデータ記述を阻害しないように設計されている。

学術や官公庁の外注ではオープンソースソフトのクラウドサービスを組み合わせるべきという話

表題の基本的な理由は以下の通りだ

  • 年々厳しさを増すセキュリティ対応の要請に対して、自前のシステムや自前でのオープンソースホスティングが高コストになりつつあり、それがクラウドサービスの値段を超えることが多い
  • モノリシックに作ると、何らかの理由でリプレイスする際に全体をリプレイスする必要があり、高コスト。また、プロトコルやファイルフォーマット対応が遅れがちであるため、データの移行も困難になりがち。
  • どこも若手の人的資源が足りておらず、それをメンテナンスに関わるあまり生産性の無い業務に割くのは愚か。
  • 日本のIT業界も人材が足りておらず、0からなんでも作ってクオリティを担保するようなことは不可能。できるところに集中して取り組むような、体制でプロダクトを作るべき。

ある業者にサービスのクラウド化を勧めたときに、「やっぱ時代はクラウドなんですかねー」と言われてしまったので、「そういう流行の話をしているのではなくて、同じお金をお互いにとって有効に使いましょうという話です。たとえば、個々の機関の個別のセキュリティ対応とかになると、そちらのエンジニアも碌に技術が身につかず楽しくもない作業をさせられて、こちらも学術的に何の売りにもならないところに高額を払うことになる。クラウドならそれをそちらのサーバ側の更新で済ませて、そういう作業は月額料金に反映させることでセキュリティ対応コストは各機関で分担することができる。その分、他の新しいことを外注できると、そちらもウリになる技術が増え、こちらも学術的成果が増えます。」と説明してしまった。

「しまった」と言っているのは、業界の歪な構造もわかるからである。ちょっと最近読んで感動したレポートがあって、MRI | 所報 No.55 | 図書館システムを取り巻く課題と今後の展望 ここにもOSSクラウドの話が書かれている。2012年。その中にこういうくだりがある。

年間のシステム関係費は100万未満から3,000万円以上まで著しい差があり、かつ、万遍なく分布していることは注目される (中略) 図書館システムについては、「図書館側の予算額に応じて費用を請求する」ということがまことしやかに囁かれるが、その疑念を強める結果である。

これは企業側の搾取だとは言い切れないし、図書館側の無能とも(図書館単体では)言い切れない。このレポートも三菱総研という「企業」が書いているので前者はよくわかっていて、「金額的な「相場観」をほとんど持っていない可能性」などを指摘している。これは上側は当然、下側もそうで、自治体は過度な緊縮財政で「出費を抑えました!」と吠えたりすることがあるが、出すべきところに出さないと業務は持続可能に回っていかないのは当然なので、もちろんどこかに適正な額というのが存在するはずであり、下がれば下がるほど良いというものではない。また、業務のクオリティというのは測りにくく、この適正な額を発注側が推測するのは事実上不可能である。図書館側の無能とも言い切れないというのは、ウィルダフスキー『予算編成の政治学』 とかを念頭に発言しているが、図書館単体ではそれを推し量る情報と能力と推し量った時に得られる利得という環境を持ち合わせていないという構造的な問題であって、各図書館の発注金額を共有することによって、この予算編成の実践そのもののサイクルの中でより適正に発注できるようにするといったような、図書館群としての工夫をしない限り、単体では「ちゃんと相場観を身につけましょう」とレクチャーしたところでそれは難しいであろう(もちろんこの素晴らしいレポートはそんなことは言っていないし、「ユーザ会」の結成といった提言をあとで出したりしている)。

話をもどすが、こういう状況が学術や官公庁の発注で生じている中で、出せるところから取るということを企業側もやらざるを得ず、それとクラウドでありがちな月額〇〇円というオープンプライスの提供は相容れないのだ。学術の話に至っては、「選択と集中」という政治的ストラテジーがその問題をさらに加速させている。

解決策の一つはクローズドプライスでクラウド提供することだ。例はあるだろう、僕が最近見たのは LYRASISがArchivesSpaceのホスティングでまずは連絡を とやっているのとか。ちなみに、カスタマイズは別料金ってのは多くがやっている(そもそもカスタマイズすべきではないけど)。しかし、ここまでの碌でもない状況を踏まえてあえてクローズドプライスに乗ってバラバラの金額を出すことができたとして、その状況がオープンになると、まあ、昨今だと市民の皆様に叩かれる。東大、京大の無駄遣い!となる。市の税金や科研費とか使うと、オープンにせざるをえない(し、オープンにすること自体は良い効果がたくさんある)ので、漸次的に解決するのではなく、この解決策を捨てて根本的解決に至らねばならなさそうだ。

  • 公共の利益にかなうような利用に対して、長めの無料期間を設定することで、少額しか払えないような組織がその無料期間の業績を元に予算申請できるようにする
  • Bountysource 的な仕組みで、システムの課題を各機関側が出して企業にハントさせる。ハントされなかった場合に予算執行できないのが問題になるので、なるべく細かい問題に落とすこと、問題を練るフェーズを設けることが必要になる。これによって、他の組織にとっても問題になってる課題を多く予算配分されてる機関が出せばよいということになる。

くらいが思いつくところ。

「ノン・カスタマイズを基本としてシステムを構築することを目指すべき」ってさっき上げた報告書にも書かれていて、これは周りでも最近よく聞くんだけど、特に引くようなソフトウェア工学箴言とかもなく、こういうマネジメントレベルの話をもっとだれかちゃんと偉い人が語って、バズらせて、みんなが参照するようにならないといけないと思う。報告書、図書館システムにとどまらず結構一般的ないいこと言ってると思うので、公益事業によるシステム外注の6箇条みたいな形で

  • メンテナンスや追加発注などを含めPDCAサイクルをまわす
  • ノン・カスタマイズのシステムをAPIなどを活用して組み合わせ、独自開発の部分は絞り切る
  • 同業者で情報交換をする
  • OSS 利用を検討する
  • システムの共同化を検討する
  • クラウド利用を検討する

あたりはもっと広まってほしい。

その他参考:

Docomo キッズケータイ F-03J を大人が4カ月使ってみたレビュー

f:id:cm3ak:20180430210828p:plain

背景

  • ケータイなくしたので、新しいケータイとして買った。スマホは持っていない。
  • iPad miniWiFi で普段使っている。家にもインターネット引いてるし、職場でもWiFi 使えるし、外でも WiFiルーター 持ってる。050の電話番号も別途持ってはいる。
  • 事前に感じていた必要性は、「SMSによる認証を可能にすること」「個人の電話番号として書くことができ、快適に話せる電話番号を持つこと」

Pros

  • かわいい
  • 機能が絞られているので、電話以外でダラダラいじることがない。
  • 本体代も維持費も安い。契約を新規契約にすれば本体代がタダ(契約手数料とかがあるので初期投資は3261円、月額989円)。

f:id:cm3ak:20180430205636p:plain

  • SMSの受け取りができるので、international なウェブサービスでよく用いられる SMS による認証が可能。050の電話番号でできないのはこれ。
  • 通話音質はもちろん良い。WiFi による050通話はまだまだこの点がなー。
  • 端子は microUSB なので lightning ケーブルみたいに断線のたびにお高い出費を要求されない(100均で質のいいのが売っている、lightning も最近100均で売っているが質が悪い)
  • アラーム機能がある
  • Bluetooth でつなげば iPad などから電話帳などを管理、追加できる(「親子のきずな」という名前のアプリを用いる)

f:id:cm3ak:20180430210902p:plain

  • 電源のオートオン、オートオフ機能はないが、「本体設定」>「音・バイブ」>「マナーモード設定」>「自動 設定」で、マナーモードの自動オンオフがあるので、夜中にかかってくる電話に起こされることはない
  • 電池の持ちがよい。平均20日くらい持つ。

Cons

  • このキッズケータイというよりストレート型全般のデメリットだが、カバンに入れておくと勝手にボタンが押されて発信していることがある。メニューキー長押しでロックがかけられるが、かけ忘れやロックすら勝手に外れることがある。他の人のYahoo!知恵袋やブログでは警察に勝手にかかってしまったとの報告も(機種が違うかもしれないが、緊急電話へのショートカットキーがあるのでかかりやすい)。僕も旅行会社等に3回、ある先生に1回、かかってしまった…。今は、ケースを使うことで対処している。個別連絡先のショートカットキー登録はしていない。

f:id:cm3ak:20180430210256p:plain

  • 「〇〇の人は1を、それ以外の人は3を」…みたいなのができない。意外と登場機会がある

    • 郵便などの再配達依頼。これはぽすくまによるLINEでの依頼など代替手段がある。
    • b-mobile SIM カードの開通。これは弟の電話を借りた。
    • 銀行のパスワード再発行。これはハガキの郵送による手続きにした。
  • 入力は中央のキーを方向キーとして使い数字や文字を選ぶ方式

    • 文字入力は面倒すぎるのでできないと思ったほうがいい
      • 最近は LINE や Facebook Messenger を連絡手段として使うことが多く、WiFiの通じる環境ならば問題ない。
    • 電話をかけるたびに電話帳に登録する必要があり、それも面倒。意外と機会がある
      • 何かのサービスに係る電話、例えば飲食店の予約で1度切り、しかも取れるともわからない電話番号登録するのはありえないが、出張先でそういう需要に見舞われたとき、職場の固定電話はなく、これを使わざるをえない。
      • 人との待ち合わせ
      • ここらへんは、Wifiで用いる iPadSMARTalkと併用すると少しマシかも。

その他

  • ネットができないので MyDocomo の登録が携帯からできないが、契約時にショップでやってもらえる。
  • dカードでの引き落としにしたら、dカードの年会費はタダになってポイントがたまる。クレカをあまり無駄に持つのは(管理が行き届かなくなって)良くないけれど、僕はちょうど必要性が生じていたので契約した。
  • 大学入学時に親名義の携帯を譲り受けて以来、名義変更を行っていなかったので、今回「親から独立している」ことを理由に名義を自分のものにしつつ、「キッズ」ケータイを契約するという冗談のような手続きをした。

東京でスーツケースを預ける

I'll write in Japanese first. At the end of this entry, there is short information of ecbo.io, which is IT integrated service for making cafes your coin lockers available in Tokyo area.

海外旅行スーツケースサイズのコインロッカーはそれほど多くない。新宿西口にそれなりにあるが渋谷は絶望的で、またカプセルホテルやラブホは荷物を預かってくれないことが多いなど、東京は大きなスーツケースを持った海外旅行者には不便な街である。

そこで、カフェなどにスペースを一律料金でレンタルさせて、検索・予約・支払いの仲介をサービスとして立ち上げたのが ecbo (cloak.ecbo.io) で、非常に良いセンス。考え方がリクルートっぽい(人と人を仲介する効率化を図っているので)と思ったが、代表取締役社長は90年生まれでUberでインターンということで、新世代ですね。

僕は試しということで1200円分-300円のクレジットと呼ばれるクーポン(みなさんも僕のプロモコード ecbocloak-7TOkNLu4 を入れていただくと300円引きになる)で利用した。900円中、店に入ってたのは840円なので(こういうの気になるので店員の手元を覗く癖があるw)60円がマージンとして ecbo に行っているようだ。1/15は設定料金として変なので、おそらく、元値1200円の5%=60円がマージン料金で固定されているのだろう。

僕にとっては、さしてスーツケースの大きさを気にせず預けられるのが何よりものメリットだ。3連続で出張とかになるとかなり嵩張るので。コインロッカーと同じ価格帯と言っているが、大きいスーツケースで600円は安い。

僕が使った時、システム不具合でチェックインができず、チャットで質問して待たざるを得なかった(先進的なウェブサービスは問い合わせがチャットになっていることが多く、大好きだ)。そういう時に、とりあえず預けられるとか、ワークフローを定義することで、店や客がストレスなくサービス利用できるよう検討することを進言させていただいた。

en

ecbo cloak (in English) is the service for storing your luggage in local shops and cafes, in the same price range as a coin locker. You have to register credit card number, then you can search, reserve and pay for ecbo cloak online.

This is my Promo(tion) Code: ecbocloak-7TOkNLu4

You can get 300 JPY discount by inputting this code

f:id:cm3ak:20171120101853p:plain

音楽について思い出語りとメモ

2000年、僕は高校1年生。ヒットチャートはこんな感じ。

f:id:cm3ak:20171105215842p:plain

History.txt によると「制作開始 1997年 6月中旬頃」であり1998年には使えるソフトになっていたCherry という midi シーケンサがあって、それが図書館にあった Vector の添付 CD の中に入っていた。当時月Piをたまに買ってた僕は TSUNAMI とか SEASONS とか らいおんハートとかを midi で作って、耳で覚えて弾いていた。楽譜はもちろん読めたが、暗記するのが苦手だったのだ。

2003年、大学1年生。入学時の寮の先輩がクラオタで、Scriabinとかが好きだったのの影響もあってRussian Piano House (←リンク切れ) というサイトにハマる。僕はSzymanowskiにハマる。このサイトの方は所蔵していた楽譜をひたすら midi にして定期更新してくれていた。この記録を書き始めたきっかけもこのサイトが消えていることについて考えを巡らすためだ。

2007年、修士1年生。楽譜を買うお金が無い僕に衝撃のサイトが登場した。IMSLP/Petrucci Music Library: Free Public Domain Sheet Music。実際は2006年に登場していたが、有名になったのは2007年で、閉鎖騒動と復活も経て、現在に至っても大量の楽譜をアーカイブし続けてくれている神プロジェクトだ。柏キャンパスのホールに忍び込み、夜な夜な曲を弾いていたのは僕です。

博士くらいから少し音楽にブランクがある。一つは環境の問題でピアノを弾く環境がなくなったこと。もう一つは、修士時代にウクライナKPIカプースチンを弾き、中国の清華大学との交流会でジブリを弾き、どちらでもとても人前で聴かせられるものではなく、当時付き合っていた彼女にフラれる遠因の一つにもなったくらいで、自分の力量に絶望したというのがある。友人がギターの伴奏や連弾に誘ってくれたりでキーボードで弾くことがあったが、それもお遊び程度。

2013年、就職2年目、Berklee音楽院が提供しているCourseraのJazz Improvisationで単位を取る。研究上で機械学習の単位も取ったが、趣味でMOOCSの単位を取り切ったのはこれが初めてで、人工知能学会全国大会の時も、カラオケボックスに鍵盤ハーモニカを持ち込んで録音し、課題提出を乗り切った。友人から漫画を貸されハマった「坂道のアポロン」、アニメも2012年に放送され、このBerkleeの授業を受け、とJazzに本格的にハマっていったので、上手い下手ではなく、コミュニケーションの一つとしての音楽というものに幻想を抱いた(結局、仲間を見つけられず今に至るまで楽しむ機会が無い)

京都に移ってから、音楽の研究をしていて「ららら クラシック」に解説者として出ていた人と話した際に MusicXML の話になって MusicXMLいじる - Drafts という記事を書いている。2015年。その後も MuseScore で思い付きを書き留めたり程度はしていて、F.Chopin Piano Concerto No.1, Op.11 Mov.3 Bar 144-147 - Draftsみたいな記事も書いている。Cherry に比べて、音符で入力できて楽譜としても使える時点で幅が広がった。

キーボードからMIDI入力もできるので、かなり高性能なのだ。

消えたサイトとその代替

先ほどのロシア音楽のmidiたちは消えてしまった。Internet Archive から見てチェックしてみると、いくつかは現在 IMSLP に楽譜があるし、YouTube にもマイナーな演奏があがっている。

そうやって新しい形で代替されていく部分と、代替しきれない部分があって、量的にはこの元のサイトはかなりマイナー志向だったので、やっぱ無いものもあるという単純な不足と、感想や解説文がなかなか秀逸だったという2つの点で代替かなわない部分がある。一瞬、うちで引き取ってデータベースにしてあげようかとも思ったのだが、まあそんな時間はないかと思い直して連絡を取るのをやめた。

楽譜に関してはIMSLPがある、網羅性についてもそれは個人より音楽大学図書館の仕事だろう。間に個人が介在していただくことは多々あろうが。midi的なものについても、手書きからは困難だが、現在の印刷版ならOCRできる日が間違いなく来るだろう。ある程度手作業の修正は必要になると言えども。そうやってデジタル化することの意義は、分析がしやすくなるとか演奏補助などのアプリケーション、機械学習による音楽生成のデータになる等々の利便がある。単に聞くのならば、YouTube にどんどんとマイナーな曲が上がっていけばいいだろう。IMSLP や YouTube の永続性についてはまた考えないといけないのだけれど。

趣味としての音楽演奏はどう生き残るのか

いきなり何を言い出すのだ、と思うかもしれない。

家事としての料理が生き残っているのはコスパの問題に違いないとほぼ確信しているのだが、趣味としての料理もその手軽さと日常的要請に支えられている。ここで僕は決して「それを美徳とする規範に支えられている」なんて言いたくない。経済合理性がある条件下で美徳に化けたもの(であることは全く立証されていないので単に僕の仮説なのだが)を、まるで美徳が支配的であるように描くのが嫌だから。大学1年の時に授業で挙げられたバタイユの「善」概念の事例が幸福追求ですべてエミュレートしきれることを指摘するレポート書いた人だからね。宗教と科学の連続性を「予期(ry 脱線するからやめよう。

Skypeのグループ通話で音楽やっていたことも少しあった(2010年)。でもズレが大きすぎて、なかなかできるものではない。産総研の後藤先生がインターネット越しのセッションの話をされてたのも2010年だから(参考: CiNii 論文 -  第54回 後藤真孝氏インタビュー : 好きな研究をやり続けるために(学生フォーラムInter-View))、同時期に「研究としては存在するけど民生用に十分なクオリティで存在しなかった」状態で、いまでもググってもみつからない。音楽のコラボレーションとしては非同期で重ね合わせるのが「弾いてみた」に「歌ってみた」が重ねられるようなニコ動上の営みとして存在する(参考: CiNii 論文 -  動画共有サイトにおける大規模な協調的創造活動の創発のネットワーク分析  ニコニコ動画における初音ミク動画コミュニティを対象として:ニコニコ動画における初音ミク動画コミュニティを対象として、これも2010年)MOOCSで勉強して、非同期で演奏して、全体的に同期性が失われていく。趣味が多様化して個々を支えられるだけのリソースが無くなれば必然的なのかもしれない。身体性等同期性にまつわる機能を求めるならば疑似同期を追及するしかないだろう。

ピアノは一戸建てを所有するのが当然の世代にしか個人で所有するのに向かない

f:id:cm3ak:20171105231431g:plain

from [しんきん経済レポート]2010年No.6 10万台を割り込んだピアノ生産台数| しんきん経済研究所

圧倒的に演奏者人口が多いのはピアノなのだが、弾ける環境が無い。一時期、趣味でつながるシェアハウスというのに可能性を感じていた(例: シェアハウステーマ別物件特集 | シェアハウス東京のポータルサイトなら『SHARE PARADE』)数部屋で一件、音楽ホールを貸し切るとか、学校の音楽室を夜間開放して、修繕費+αをコミュニティが持つとかね。でも、ゲストハウスに泊まるところから、結局カプセルホテル+バーが一番いいんじゃね?と思い始めたりしたのと同じで、普通に大人のカルチャーセンターでいいんだよね(ただし、講師が来るのはたまにだけでいいから安くしてくれとか、出張多いと休会できないの辛いとか、いろいろ不満はあるんだけど)。

安い他の楽器(例えばオカリナやピアニカ)に移動するというのもあるし、僕はピアニカもかっこよく吹けるんだよと布教してたことあるけど(Adiós Noninoとかラテン音楽を情感たっぷりにピアニカで弾けば大抵イメージが覆る)、そういう形を社会全体で目指すのは文化の死だと思う。ちょっと本節冒頭の話題に戻るけど、文化生成力を経済性や徳が支配するようになってしまったら終わりなんすよ。そこらへんは最近劣化した記事を見て呆れはするものの(ブクマにもあったけど良い3箇条の背景となってる語りが酷い)、宮台さんが繰り返し指摘しているミメーシスみたいなのは文化の生成力として重要だと思う。

結論無いですよ?何か期待して読んだ方には悪いのでビジネスアイデアだけ置いておきますね( っ・ω・)っネットとかで安く学んだり練習したりするのと上手く組み合わさったプログラムをカルチャーセンターやカラオケに寄生する形で立ち上げて一山あてましょう。以上です。

例文:会議の特別セッションのチェアの依頼

ある程度親しい人に対して会議の特別セッションチェアをお願いしている。英語力はヤバいが、内容の例文としてご参考まで。

Dear ***,

Hi, (個人的な挨拶、こないだはありがとうとか)
I hope your preparation for the workshop is going well. 
Btw, I'm writing this message to ask you to manage
 one more special session at 会議名 :-)

セッションに関する情報、URLなど

I'll help preparation 
(making ML for sending a message to those presenters and
gathering 1 slide Power point from presenters) and the session also, 
but a session chair who can manage this fast-tempo session is needed.

Then, I have a favour to ask you.
Would you mind to chair セッション名 on 日付?

I very much hope your acceptance, many thanks in advance.

Best,
***

ポイントとしては

  • 僕が誰か思い出してもらう
  • 既にしてもらっている協力事項についての謝辞
  • 冒頭に簡潔にお願いの事項を書く
  • イメージがわくようにセッションの情報を提供
  • 自分もしくは他のメンバーが手伝えるならば何を手伝えるかを伝える
  • どういう人として、相手を指名しているのか「君が必要なんだ!」
  • お願い定型文

って感じですね。こういうやりとり上手いなって思ってる某先生に「〇〇の件はお願い、僕にCCしてください」「××は僕から依頼文送りますんで」って言って、このテンプレを盗みました☆

関連: