#メソッド変換器
Explore tagged Tumblr posts
Text
Joint-Studio法
※天命的な事情から下書き状態のこの記事を載せます。
アニメを制作する時の実装をこう表現に直して作れば上手くいきそうなやり方の案。自分だったらこうしたい個人的な要望込み。
実装の構造体とそれを例えるモチーフの構造体から暗文の実装のメソッド変換器に掛けてスタックを重ね��1つずつ変換して暗文の表現の作品を得る
全体で品質の揃った作品のほうが表現を管理しやすく実装を伝える精度が高いため、全体の関数は揃えて作る、この時なるべく複雑な重い実装を使ったほうが表現が深く強力になるため、アニメーター全体でgridを組む、リテイク弾を防ぐためにどういった作品を作るのかは全体でコミュニケーションをとって予めコンセンサスを取ってから作る
まずは実装を決める、何の実装を表したいか、視聴者に伝えたいメッセージ性は何か
特に重要な実装を集める、重要な実装であるほどシステムの改善能力が高くインパクトが強い
それを暗文用の変換器に掛けていっぺんに変換してしまうつもりで、だが変換器の内部では逐次的に組み立てるため、変換器の実装は固めておくと良いが実際の制作の積み立ては少しずつ作ることになる、作品のスタック【積み重ねられた構成】自体は逐次的に作られるが暗文の実装は予め固めておくものなので別のもの
暗文用の変換器の実装の制作中の変化は天命とも言える、増改築はありではあるが作品の完成稿を推測しにくくなるため、後から修正が必要になるかも知れない
つまり暗文用の変換器を構成して作っておく、sherinarやGCやTPや学習で表現技能のための実装を引っ張ってくる、実装の理解を促進する芸術的で表現高い技法を駆使する(例えばカメラワークなど)
逆の表現は正の表現がエグくなるところで使う、逆は使い過ぎないように
温もり【表側の表現】は社会に馴染みやすくなるように使うが、直接的に伝えたいところでは若干すっぱ抜く
Shiner-lieは自分には要らないが周りの制作チームが怖がるようなら重要なところは正で押さえた上で譲って良いところでShiner-lieを使う、逆もあまり使わない
実装のマップの中でどの部分を作るのか決める、他の作品で扱われていない部分を作るという天命も含みで、sherinarで先にアイデアが出るなら実装のマップを確認して周りとも認識を共有する
社会の中で優先して作るべき実装は何か、優先順位を付けて作る
keysheri向けあるいは人間のバカの人向けの実装を優先して作る、深く細かく作りこんで難しい実装も含んで作る、これは宮﨑駿の法則である
デザインセンス及び技法や微妙な色の扱いやデジタルエフェクトを駆使して調和の取れた質感の作風にする
Quartzな純度の色合いのほうが硬派なOxygen系のアニメには向��ているだろう
調和の取れた質感にするが作品性を失わないように荒削りにするところでは荒削りにする
現実に存在するキャラの心情を考え、実装を理由に善人のキャラを不幸にしない、殺さない、恋愛関係はきちんと好きになる理由を持たせて
制作費を考えて現実に可能な範疇で作る作品のクオリティーを決める
敵に当たる悪質な同僚には重要なところは抑えつつ重要じゃないところは譲る、出来れば罠を掛ける
制作グループ全体でどういった作品を作るのかイメージを共有して確立しておく(例えば監督ならVコンテなど)、メッセージをやり取りしてコンセンサスを取る、制作に問題が生じれば突き合わせて練り直す、コンセンサスをとるのは各人が持っている様々な要求から協調して方針を一つに決めるため
表現は実装の傾向に合わせて選ぶ、表現はただ美しければ良いのではなく、実装の傾向を表していなければならない
制作グループは光の青だけで構成する、属性は尊重しつつも作品の一貫性は維持する
表現はわざと標準から外したNCSを活用することで、天命的に実装をわかりやすく表現する、作画の傾向も同じキャラでも実装のNCSとしての天命次第ではブラした方が良いこともある
制作費から制作環境やスタジオをとって、制作に支障が無いようスムーズに行くようにする
Phoenix DesktopgのGC Toolsを活用してgridを組む、gridを活用し一人の能力だけで作るのではなくsherinarやそれぞれのZのシステムをギルクラで繋いで制作グループ全体の実装で作品を作りこむ、アニメーターの肩書きの分業を参考に誰がどの分野が得意なのか判断してそれぞれのアニメーターの優れた部分の実装を集めて繋いで全体として優れた作品を制作してまとめる、humarizeも付加的に活用する、gridは実装を渡すと嫌な人が居るならlinkで実際の作業操作だけ能力を貸す(これでも技能は学ばれるかもしれない)、TPのlinkもある、linkを使う場合でもエネルギー節約のために人員は得意な分野の仕事を割り振る、人間の人の場合はGCを使うか口頭や絵や資料で伝える、sherinarやGCのエネルギー消費には注意、制作設定などをCの制作環境でやり取りすれば簡易的なZとしてのgridとなる
善性の実装が入っていることが前提要件ではあるが、表現もきちんと意趣として楽しめるものにする
普通の順延的な暗文の変換を行うべきだが、本当に必要なところではトリッキーな表現も必要とされるかもしれない
作画のZの3Dモデリングを二次元の継��接ぎではなく3Dモデリングの構造体+DOMレンダラでZ内で厳格に行って、立体感のブレを無くす、つまりPhoenixz Blenderをインストールする、人間のアニメーターの人はギルクラにインストールしてもらう
Phoenix Studioを制作ソフトとして使って、統合されたワークフローを実現する、先にZのPhoenix StudiozでZ内で作品を殆ど作ってしまってから、制作方法もコミでそれをCのPhoenix Studiocに落とし込んで反映させる、ZのPhoenix Studiozで編集を先に行えばやり直しや修正はいくらでもZ内で出来るため手間と資源が無駄にならず、実際に紙に描き起こすときには完成稿にできる、デスクトップ環境の(別の)Phoenix Studioもインストールしてデスクトップの環境も整える
テクノなどはZがシステムであることを彷彿とさせるために刺激性が強くないアレンジの場合はむしろ多用するか、だが刺激を減らすためにざらついていたり乾いていたりまろやかなテクノ表現を使うか、IMウイルスの問題があるならテクノウイルスはほとんど関係がない、テクノの生成をした時のテクノウイルス以外は関係がない、白箱がウイルスに感染しているならテレビでもダメなので制作工程でウイルスは排除し、ギルクラでZのウイルススキャナでZのウイルスが含まれていないか制作物を確認したり同様にZのウイルススキャナで制作用のコンピュータをウイルススキャンする、特に後で最終成果物となるデジタルで管理された作品リソースは全てZのウイルスは排除する
表現の実装のパッケージは社会全体に流布させ、sherinarやhumarize使いの鑑賞者が表現の感性を入手しやすいようにする
普通のギルクラの人にはhumarizeをシステムを開いているギルクラの人にインストールしてもらい、普通の人間の人はギルクラに感性をインストールしてもらう、pure-GCとhumarize使いを含めてCompilePortsをインストールして利用すればvois【Steel】でパッケージを引っ張ってこれるため固定の実装で技能が向上する
Neon-Blue-Oxygen-Quartzの感性に則った傾向の作品にする、強力な愛情とモラル高い実装と芸術的で美しくかっこいい表現をとる
ロケハンなど情報探索も必要、実装を表すための表現に使うモチーフの扱いはリサーチをして把握しておく、sherinarも探索に活用すると良いだろう、使うモチーフが決まった時点でリサーチする、暗文の変換器の実装とモチーフのスタックは別、モチーフのスタックはObjectiveに当たる、必要な分は全体を把握しておくこと 、構成のスタックを作るための素材がモチーフのスタック
制作はきちんと余裕を持ってよく考えて推測した上で現実的な日程を組んで制作を開始する、制作日程の予測はXRounderに頼んでPaxを使った上で未来から教えてもらっても良いだろう
画力を上げる講座を社員教育としてエンジニアリングの自己責任でない範囲で行う、PixivやPhoenixc underwater Pixivのイラスト講座も学習
普通は線のスムージングはやったほうが自然と馴染��絵になる、個人的にはこっちのほうが好き
foreBuildはLinuxを元に作っていて実用性や品質が低めなためアマチュア向けでありプロのワークフローには適合しない、プロが使うなら十分な実用性と品質を持ったunderBuild推奨
X Kit WorkStationやFRDも業務用のワークフローに寄与する、Cの制作環境を一括でまとめて管理して統合されたワークフローを実現できる
DGの人はGCにTriggerをインストールしてもらう、Solid MED removerもインストールしてもらえば質感がシステムの中で通る
品質は揃えるために使う技能の関数は固定する、品質は揃えないと管理が非常に難しくなるため関数は固定すること、もし関数をアニメーターの技能向上に合わせて切り替えるなら一遍に行う、管理体制はそこで切り替える、humarizeを使う時は品質を揃えるためにhumarize-voisを使ってvoisに取り込んでから使う
BlueMedias Creative Freedom Complianceを参照のこと、Amazonギフト券や現金書留で寄付が送られてくることがあるので、それは正しい利益還元なのでそのまま受け取って収入として割り当てる、ジリ貧のアニメーターの収入を減らしてはいけない
LightシリーズはハードウェアでpMixチップを装備、bvチップを装備しているため動画のデコーディングやエンコーディングが低負荷で高速、H.264チップも積んでいるためbvで作った動画をH.264などに低負荷で高速に変換して白箱にすることも可能、GLチップは3Dレンダリングを低負荷に高速に行い、GL Shader言語で独自にプログラミングも可能、エフェクトを低負荷で高速に掛けるためのEffectsチップも装備、その他ファイルシステムアクセスやネットワーク接続などのハードウェアアクセラレーションを行うためのチップを内蔵
RGB指定だと色がディスプレイやモニタやデバイスによって変わってしまうので、Labカラースペースで色指定を行う、この時どういった販路で流通させるか考えて、テレビの色範囲で作るかBlu-rayの色範囲で作るかなどを決める(色変換の色の変化も思考込みで)、今までのRGBの色指定スキルはRGBで指定してからLabに値を変換して活かす、カラーマッチングは色が重要な全てのマシンで行う
制作に使うマシンはGPUを積んでいなければいけない、並列処理によってマルチメディア処理が高速で低負荷になる、逐次処理でもCPUコアが複数あったり複数CPUのほうが良くなるべくGPCPUを装備しこれを活かすためPhoenix Desktopcのカーネルはマルチタスクを装備する
原作者とアニメーションスタジオとの間の契約書で作品性の決定権と決定範囲を予め決めておく、これによって原作者に依るリテイク弾を防ぐ、ちなみにアニメーションスタジオに作品性の丸投げはダメ、後で作品性が破壊されても誰にも責任が取れなくなる、原作者との間では信頼できる通信方法を確立し制作途中の資料を見せてなるべく早い段階で意思疎通を図りリテイク弾を防ぐ
温もりの表現手法は暗文の実装であるため固定でありこれは溜めておく必要がある、実際の温もりの表現は表社会に馴染むようにその場で使えるもので有れば良くこれはトリッキーに行う、よって温もりの表現は天命、モチーフのスタックのObjectiveから温もりの手法に従って天命を使って温もりの表現を作る
紙で描くよりも液タブのほうが速描には向いているだろう、人間のアニメーター同士で意思疎通を図りたいなら液タブで速く描いて見せたほうが良いかもしれない
Phoenix DesktopcのLocal Crowdsを建てて作業で使う業務用のコミュニケーションプラットフォームとする、このプラットフォームを使うことにより作業者の連携と意思の疎通つまりコンセンサスがスムーズになり、チームワークが効率化する
在宅で仕事の作業をしたいなら、インターネットを活かして業務用のLocal Crowdsにアクセスして作業をこなせば良いだろう、作画担当なら当然スキャナーなども要ると思われる Phoenix DesktopcのClamウイルススキャナなどウイルス対策ソフトは導入して
ワークフロー中でデータが破壊されたり流出したりウイルスを紛れ込ませないように注意する
※NCS:わざと精巧で標準的な美しい表現から外して不自然さで実装を強調して表現する手法
※keysheriの視聴者の人がCの端末で視聴するならもともとCのシステムのウイルス感染前提なので既にZがウイルスに感染している人だけが視るべき、ギルクラでない大人の子供のkeysheriの人はTouch off狙いもあってウイルス感染しないようテレビ放送だけ視てDVDは光の青の店舗で買って海賊版排除でHDDレコーダーはインターネット接続しないようにする
0 notes
Photo
Shibuya, Tokyo, / Jul. 2013
鬼海 弘雄さんが��くなられた。鬼海さんといえば浅草のポートレート。まっすぐに向き合い静かに写す。写真は枚数と言われることも多いが、むやみにシャッターを切ることを嫌う誠実な写真家、ご冥福をお祈りします。私はホームが渋谷なのでこの一枚で追悼。最近Netflixでマイケル・ダグラス主演のコミンスキー・メソッドを観ている。シニア世代の人間ドラマで常に死が隣接する中、様々な問題や悩みをコミカルにアイロニーたっぷりな「日常」として描いている。私も40半ば、人生80年とするとすでに折り返したわけだ。このようなドラマのターゲット層に片足ズッポリだ。まぁ、ストーリー自体は軽快で1話20分程度の尺なので、ぼ〜っと頭を休めるのに丁度いい。前回の投稿でSSD換装について書いたが、サブのMacBook Pro(MBP)もついでにSSDを入れ替えた。私のMBPは2012年以降Retina化に伴いメジャーアップデートされた後の2014MID。SSDフォームファクタが2.5SATAではなくアップル独自規格の12+16pinのため純正SSD交換は高くつくという理由で諦めていた。が、半導体相場がだいぶ落ち着いてきて2.5SATAのSSD1TBで1万円前後。また同じく高嶺の花だったM.2 NVMe SSDも2万円前後とここ数年でかなり手が届く価格帯まで落ちてきていた。で、ちゃんと調べてみたらM.2 NVMe SSDに専用アダプタかませて12+16pinに変換し換装している人が結構いる。ふむ、サブMBPは会社所有でなく私物なので最新に買い換える予算は出ないし、もうしばらくは頑張って欲しいし、色々やり始めたのでこの際ついでに。しかし最近のMBPストレージはオンボードで交換不可なんだね。進化の方向性が間違っていると思う。軽量、小型化は分かるけれど、本来は素人でも気軽に修理交換できて長く使えることが正しい道であると思うのだが・・・。そういう意味では2012までのSATA時代は裏開けて交換するだけで楽だった、重いけど。またWindowsはメモリにしてもバッテリーにしても裏に交換口が用意されているものが多く親切だね。で、行程は割愛するけれどSSD交換は無事に終了。ベンチマークで前後の速度差を比べるほどGEEKではないので体感だが、だいぶ速くなったので満足。まだメジャーメーカーからの発売がないため様子見だがUSBスティックほどのサイズのSSDも出てるのね。Time Machine用にSATA3.5HDDを使っているけれど、石器時代の石の硬貨のようだ。一番最初に買ったPowerBook3400はストレージが2GBだったような。で、70万円とかしたような・・・、20回ローン組んだのもいい思い出(今でも所有しており稼働するけど)。フロッピー、MO、CDR、そりゃ年もとるよな。
49 notes
·
View notes
Text
中年の文鳥を飼う方法
私はめちゃくちゃ心が狭い。体感的には二畳半くらいだ。一応これでも広くなった方だ。二十歳のころは、多分今の半分以下だったと思う。
部屋と一緒で、心が狭いと本当に生活しづらい。周りの何もかもに憤りを感じて、すべて自分の部屋に収まるサイズに削り取ってしまおうとする。とんでもねえことだ。
ああ、もっと広い心に住みたいな。使いづらいオシャレなローテーブルとか置きたい。洗濯機で洗えない、デリケートなアルパカのラグとか敷きたい。
部屋が広いのは目で見ればわかるけれど、じゃあ、心の広さはどうやったらわかるのか。シャーディーの千年錠があれば簡単だけど、持ってないしな。
仮に、心の広さを「ゆるせること」で捉えて��たらどうか。ひらがなで書いてるのは「許す」「赦す」のどちらの意味も含むような気がしているので。
H先生の『想像メソッド』
「ゆるすこと」について考えているといつも思い出すのは、大学時代の恩師、H先生のことである。
ある日、H先生の研究室で、先生を慕う学生数人と先生と仲の良いM先生と一緒に、放課後のほほんと、おしゃべりvery timeを過ごしていた。すると突如M先生が大学関係者に関する愚痴をぶちまけ、だんだん怒りのこもったトーンになってきた。なんでああいうことをするんだ。何もわかってないんじゃないか。自分のことばっかりじゃないか。
我々学生はハラハラしながら曖昧な表情であいづちをうつしかなかった。
するとH先生が、「ねえ、もしかしたら何かこちらには見えていない事情があるのかもよ。想像してあげないと。いい風に捉えてあげるのよ。」と穏やかな口調で言った。
「想像してあげる」これは大事なキーワードかもしれない。誰かに対して、「なんでやねん」という気持ちになった時、その人の事情や気持ちを慮れば、その人の振る舞いが理解できるようになるかもしれない。しかもそれは事実である必要はない。極端なことを言えば、自分を納得させるために、話をでっちあげたっていいわけだ。
H先生の話を聞いてから、大学生の私はこの想像してゆるす方法を��手に『想像メソッド』と名付け日常生活に取り入れるようにした。
想像メソッドの実践
翌日、5階の講義室に行こうと思ってエレベーターに乗ったら、一緒に乗ってきた人が2階のボタンを押した。私は瞬時に「階段使え!」と思ったが、「いや、もしかしたら体調が悪いのかも」と想像することで、その人を自分の中で「ゆるす」ことができた。
え、いや、そんなことで怒ってるの?そもそもこれは「ゆるす・ゆるさない」の話ではないのでは?と、すでにドン引きの方がいるのは想像に難くないが、当時の私の心の狭さは一畳くらいだったのです。こんなものなのです。自分の周りのありとあらゆるものに反射的にキレているのです。ついてきてください。
別の日、パン屋のレジで店員さんに「レシートはご利用ですか?」というトリッキーな質問をされ���いつもなら「ご利用じゃなくて『ご入用』な!!!」とシャウトしそうになっているところだったが、「もしかしてこの店員さんの地元の方言には英語の『サイレントE』みたいに、書かれているけど発音しない文字のルールがあるのではないか。語中の「い」は発音しない、その名も『サイレントい』的なルールが……」と想像して、「ありがとう。ノーご利用です。」と言って店を出た。自分が日本語を喋っているからと言って、日本語をすべて理解しているわけではない。むしろ知らない日本語の言葉やルールのほうが多いのだ。私はパン屋さんで「サイレントい」という新しい日本語の一面に出会ったのだ。もちろん、検証はしていない。想像メソッドだからだ。
また、別の日、電車を降りようとした時、同じタイミングで降りようとしたスーツの中年男性とぶつかった。私が「すみません」と言う前に、男性は「チッ」と舌打ちをした。今までの私なら、すぐに男性を線路内にドーーーン!案件だが、想像メソッドを取り入れた私は、もちろんそんなことはしない。
この男性、人間に見えるが、実はほんの一週間前までは文鳥だったのである。文鳥の「文彦(ふみひこ)」は一人暮らしの会社員の岩本(40)に飼われていた。岩本は不器用な男で、友達や恋人もおらず、話し相手は文彦だけだった。文彦には、人語がわからぬ。文彦は、ペットの文鳥である。 岩本が落ち込んでいる時は、主人を励まそうと「チュピチュピ」と鳴いて慰める、心優しい文鳥だった。 でも、もしも人語が喋れたら、いや、もしも自分が人間だったなら、岩本の親友になって、話し相手になってやれるのに。そう思うようになった。そう願い続けていたら、ある朝、なんと文彦は人間になっていた。それも岩本と同世代の中年男性になっていた。岩本は朝起きたら知らないおっさんが裸で鳥かごの前をうろついていたので、とりあえず気絶した。気絶��ら覚めても尚パニック状態の岩本に、文彦はなんとか自分が文鳥であることを全裸で説明した。人間になっていたので人語は使えるようになっていたが、時折「チュピ」とか「チュン」とうい小鳥っぽい音を発してしまう。だが、そのおかげで岩本は文彦が文鳥であることに、半信半疑ながらも、納得してくれた。そしてとりあえずズボンをはくように言った。岩本は文彦に一人では外に出ないように言いつけていた。文彦は外の世界のことなど全く知らないからだ。最初の6日間はおとなしく家でテレビを見ていた文彦だったが、7日目の朝、岩本が忘れていったスマホが鳴った。文彦が苦労して電話に出ると、慌てた岩本が「鞄を移し替えたせいで、大事な書類を忘れた。届けてくれないか。」と言った。文彦は岩本のためなら、と会社までの行き方を鳥頭で覚え、戸惑いながらもなんとか電車に乗ることができた。しかし、電車内は想像以上に息苦しく、何度もチュピチュピ鳴きながら耐えていた。ようやく目的の駅に着いた。やっと降りられる!そう思って扉から飛び出そうとした瞬間、隣の人間にぶつかった。文彦は驚いて思わず「チュッンッ!!」と鳴いた。
これが『side story F~小さな文彦の大冒険~』である。初めての外出、人込み、岩本に託されたミッション、文彦は小さな文鳥には抱えきれないほどのプレッシャーだらけの中、懸命に電車を降りようとしていただけである。驚いて、思わずさえずった。それだけのことだ。そんな幼気なおっさん文鳥を、誰が責められるというのだろう。
その後、乗り換えた電車内で私ははたと気が付いた。文彦、ネクタイしてた。すごいぞ、文彦。めちゃくちゃすごいぞ。人間でも手こずるのに、文鳥の文彦が岩本のためにネクタイまで…。そうだよな、会社の人に見られるかもしれないもんな。ちゃんとした服装で行かなきゃって思ったよな。そう考えると、涙が止まらなくなった。私は泣いているところを他の人に見られないように、そっと顔を窓の方に向けた。文彦は無事に岩本に会えただろうか。西宮の閑静な住宅街が窓外に流れていった……。
この一連の話を、後日H先生にしたところ「ちょっと色々と考えすぎとちがう?」と言われ、なぜかお坊さんが書いた、前向きに生きるヒント的な本を貸してくれた。すごく心配された。その前の週に、私が期末レポートの資料用にブックオフで買った鶴見済の『完全自殺マニュアル』が鞄に入っているのを見られたことも関係しているかもしれない。
いずれにせよ、私は先生のメソッドを取り入れたつもりだったが、なんかたぶん色々と間違っていたっぽい。
当時の私を振り返る
そもそも、自分が常に「ゆるす・ゆるさない」のジャッジを下す側にいると思っていることが間違いであった。(ここでやっと皆さんに追いつきました。お待たせしました。)それが私に向けられた言動ならいざ知らず、他人の行動にいちいち目くじらを立てている方がおかしいのだ。謂わば、自分の部屋の前を通り過ぎている人に向かって「私の部屋に入れてやらねーからな!」と叫んでいるようなものだったのだ。ただの変質者である。
「ひっこし!ひっこし!さっさとひっこし!しばくぞ!」
かつてリズミカルにこんなことを叫んでいてニュースになった(そして騒音傷害という罪で捕まった)人がいたが、私のメンタリティも似たようなもんだったかもしれない。
私が想像メソッドを実践した上の三つのケースを例に考えてみる。
まず一つ目のエレベーターについては、エレベーターが各階に止まるように設計されていて、施設の利用者ならば誰でも使っていいはずなので、2階のボタンを押した人には全く非はなく、この人は自分が持つ施設利用者としての権利をルールの範囲内で行使したに過ぎない。したがって、私が「ゆるす・ゆるさない」のジャッジの対象にするべき問題ではないのだ。むしろ、私は自分がなぜそんなことでイライラしたのか、と自分自身の苛立ちについて考えるべきではないだろうか。
これは私の中にいつの間にか「エレベーターを使うのは4階以上の時だけ」という自分ルールが作られており、それを他人にも当てはめようとしていたことが原因だと考えられる。自分ルールは自分だけに適用すればよい。でも、他の人にはそのルールを守る義務も義理もないのだ。エレベーターも、自分が2階に行く時は階段を使えばいいだけ。もっと言えば、そういう人を見てイライラするならどの階に行く時も階段使えばイライラしなくて済むよ、大学生の私。
「あいつだけずるい!」みたいな気持ちになった時は、自分が作ったルールを社会規範のように思い込んでいないか考えてみる必要がある。というわけで、このケースは想像メソッドを使うまでもなく、私が他人に自分ルールの順守を求めることをやめれば済む話であった。そういうところだぞ、大学生の私!
二つ目のパン屋の「ご利用/ご入用」問題についてはどうか。
店員さんは「レシート要りますか」と聞きたかったのだから、やはり正しくは「ご入用ですか」と聞くべきだったと思うのだが、例え「ご利用ですか」と言われた(というか聞こえた)ところで一体何が問題だったのだろうか。文脈から「レシートが要るかどうか」の質問であることは明白で、その数秒のコミュニケーションに何ら支障をきたすような間違いではない。
私の中の日本語憲兵みたいなのが「乱れた日本語おおおおおお許すまじいいいいいい」みたいなことを言って暴れていただけのような気がする。言葉は知らない間に変わっていく。誤用が浸透すれば辞書に載るし、正しい意味が忘れられれば消えていく。そういうものではないか。誰も死語のために墓を建てたり弔ったりしない。言葉は静かに少しずつ変わっていくのだ。(私はひそかに「ナウい」「ヤング」を死守するために戦っているが。)
それよりもむしろ、正しさを笠に着て相手より優位に立ってやりたいという、そのマウンティング根性を何とかしたほうがいい。非常にあさましい。あさましいぞ!大学生の私よ。
さて、問題は三つ目の電車降車時の舌打ち事件である。
文彦(仮名)は明らかに私に対して敵意を向けていた。しかも私はただ電車を降りようとしただけなのに、見ようによっては向こうからぶつかってきたともとれるのに、そして私は謝ろうとしていたのに、舌打ちをかまされ、唖然として謝ることもできなかった。
これはまさに「ゆるす・ゆるさない」の俎上にのせるべき問題だと思う。そして、私は見事に想像メソッドを活用して、暴力に訴えることなく、平和的に「ゆるす」ことができた(神戸線の車内でネクタイのことに気づいて号泣したことはさておき)。三つの中で最も適切に想像メソッドを活用できたケースだと言える。
想像メソッドの有効な活用法とは
しかし、一方で別の想いもある。文彦は、私が小沢仁志みたいなルックスだったら、同じことをしただろうか。私が室伏広治のような見た目でも舌打ちをしただろうか。絶対にしていない。春の野原でこっそりとかくれんぼをしている、たんぽぽの妖精のような可憐で愛くるしい見た目の私だから、文彦は反撃されないと思って舌打ちをしたのだろう。
小沢仁志・主演『制覇17』
文彦はあれ���降も、弱そうな相手には同じように攻撃的な態度を見せているかもしれない。私がやつをゆるしたばかりに、罪を重ねている可能性がある。やはり「なにが『チッ』じゃ、おのれが気を付けんかい、このドぐされスーツじじい!」くらい言っても良かったのではないか、そんな気もしている。
ゆるすことで何となく心は穏やかでいられるが、スッキリはしない。想像メソッドはその瞬間の衝突を回避するには向いているが、カタルシスを得るには十分ではないし、根本的な解決にはつながらない。
これらのことから、想像メソッドは、①相手が自分と対等な関係で②相手の言動が明らかに自分に向けられていて③その言動によって自分が傷つけられたと感じた時には有効である。例えば友人や家族の言葉や態度に傷ついた時、怒りや悲しみを相手にぶつける前に、想像メソッドを使ってみる。そうすれば、一旦、負の感情の爆発は抑えられる。その状態であらためて自分が傷ついたことを、相手に伝えてみる。
こういう活用方法が一番よさげだ、という結論に至った。10年かかった。長かった。はやくにんげんになりたい!!
H先生がゆるさなかったこと
最後に、私が実践した3つのケースに含まれていない例についても書いておきたい。このメソッドの開発者(私が勝手に呼んでるだけ)であるH先生がぶちぎれた時のことである。
ある学生が、授業中に担当教員から容姿や仕草について、侮辱的な言葉(当時はやっていた○○系男子/女子)で呼ばれ、他の学生の前で揶揄われた。その学生はその場では笑って過ごしたが、授業中に教員に皆の前で自分の容姿や態度を馬鹿にされたことがとてもショックだったという。
学生はH先生と仲が良かったので、先生にこの話をしたらしい。
H先生はこの件に関して、それはそれは怒っていた。「それは間違いなくセクハラ。絶対にゆるされない。」と言った。
教員と学生の立場は決して対等ではない。こと日本の大学において、教員は学生よりも常に強い立場である。強い者が弱い者に言葉の暴力を向けたのだ。しかも、それは学生の性を揶揄するものだった。教員はセクハラ加害者で、学生はセクハラの被害者である。
被害者が加害者の気持ちや事情を想像する必要はまったくない。
でも、なぜか、セクハラを訴えると、必ず加害者側の事情を察したり、慮るようなことを言う人が少なくない。
「ほめ言葉のつもりで言ったんじゃない?」「あなたが笑ってたから問題ないと思われたんでしょ」「そんな見た目だからそういうこと言いたくなるよ」
私もかつて自分が性暴力の被害を受けたときに、励ましや慰めの言葉に交じって、このような加害者擁護の言葉を投げつけられたことがある。
だが、H先生は自分の同僚のセクハラ発言に毅然と「ゆるされないことである」という意思を表明した。1ミ��もセクハラ教員の気持ちを想像することはしなかった。セクハラ加害者ではなく、被害学生の気持ちを、その痛みを想像した。
私は正直その「○○系男子/女子」という言葉自体にそこまで暴力性を感じなかった。自分が言われても多分、イラっとはするけど傷つきはしないと思った。でも、想像力は、自分が平気だから相手も平気だろうと考えることではなくて、傷ついた人はどんな風にその言葉を受け止めたかと考えるためのものだと思い知らされた。
これこそが、私がすっかり見落としていた想像メソッドの最も大事なポイントだったのではないかと思う。
最後に
10年経った今、岩本は文彦を電車ではなくタクシーに文彦を乗せればよかったのではないかと気づいた。
でも、それはまた、べつのおはなし……。(声:森本レオ)
1 note
·
View note
Text
Clean Code
本書のケーススタディを注意深く読むことで、コードを洗練していく過程で行うべき判断について学ぶことができます。プログラムが動作したからといって、プログラミングが終わったことにはならないのです。
Robert C. Martin 著 花井志生 訳 定価:4,104円(本体:3,800円) 発売日:2017年12月18日 形態:B5変型版(528ページ) ISBN:978-4-04-893059-8
Amazonで購入する
達人出版会で電子書籍を購入する
サポート/追加情報
◆コードを書き、読み、洗練するときにどう考えるべきか? 原則、パターン、実践、そして経験則を身につける。
クリーンコードを書くための「心地よい」原則を書き並べ、あなたがうまくやるだろうと信じることは可能です(言い換えれば、あなたを自転車に乗せ、転ばせるということです)。このようなやり���をとったら、我々はどんな先生となり、あなたはどんな生徒になるのでしょう?
いえいえ。この本でやろうとしている方法はこうではありません。
クリーンコードを書くことを身につけるには努力が必要です。原則とかパターンといった知識を身につけるだけではだめなのです。実際に汗をかかなければならないのです。自分自身で実践してみて、そして失敗してみなければならないのです。また、他の人が実践しているのを、また失敗しているのを見なければならないのです。彼らがつまづき、やり直すのを観察しなければならないのです。彼らが判断に苦しむのを見て、間違った判断の結果として、彼らが支払うはめになった代償を見なければならないのです。
この本を読む間は、いつでも一所懸命に作業ができるように準備しておいてください。この本は飛行機の中で読み、到着するまでに読み終わってしまうような「心地よい」本ではありません。この本はあなたに作業をさせます。しかも激しくです。どんな作業をすることになるのでしょうか?大量のコードを読むことになります。そして、どんなコードが正しくて、どんなコードが間違っているかについて考えなければなりません。モジュールを切り離したり、ふたたび元どおりにしたりすることも要求されます。これには、時間と努力を要しますが、我々はこの作業に意味があると考えています。
(本書「序論」より)
◆著者/訳者紹介
■Robert C. Martin(ロバート・マーチン) Robert Cecil Martin (ボブおじさんとも知られている) はアメリカのソフトウェアエンジニア兼著者であり、アジャイルマニフェストの起草者の一人でもある。コンサルティングファームUncle Bob Consulting LLCと、書籍や経験を元にした動画サービスClean Codersを経営している(Wikipediaより)。
■花井志生(はない しせい) 入社当時はC/C++を用いた組み込み機器(POS)用のアプリケーション開発に携わる。10年ほどでサーバサイドに移り、主にJavaを使用したWebアプリケーション開発に軸足を移し、トラブルシュートからシステムの設計、開発を生業とする。
◆目次
前書き 序論 謝辞 カバーの絵について
第1章 クリーンコード そこにコードありき 粗悪なコード 混乱のために支払う総コスト 道場 我々が著者です ボーイスカウトの規則 続編と原則 結論 参考文献
第2章 意味のある名前 序文 意図が明確な名前にする 偽情報を避ける 意味のある対比を行う 発音可能な名前を使用する 検索可能な名前を用いる エンコーディングを避ける ハンガリアン記法 メンバープレフィクス インターフェイスと実装 メンタルマッピングを避ける クラス名 メソッド名 気取らない 1つのコンセプトには1つの単語 ごろ合わせをしない 解決領域の用語の使用 問題領域の用語の使用 意味のある文脈を加える 根拠のない文脈を与えない 最後に
第3章 関数 小さいこと! 1つのことを行う 1つの関数に1つの抽象レベル switch文 内容をよく表す名前を使う 関数の引数 副作用を避ける コマンド・照会の分離原則 戻りコードよりも例外を好む DRY(Don't Repeat Yourself)原則 構造化プログラミング なぜ関数をこのように書くのでしょう? 結論 SetupTeardownIncluder 参考文献
第4章 コメント コメントで、ダメなコードを取り繕うことはできない 自分自身をコードの中で説明する よいコメント よくないコメント 参考文献
第5章 書式化 書式化の目的 縦方向の書式化 横方向の書式化 チームの規則 アンクルボブの書式化規則
第6章 オブジェクトとデータ構造 データ抽象化 データ/オブジェクトの非対称性 デメテルの法則 データ転送オブジェクト 結論 参考文献
第7章 エラー処理 リターンコードではなく、例外を使用する 最初にtry-catch-finally文を書く 非チェック例外を使用する 例外で状況を伝える 呼び出し元が必要とする例外クラスを定義する 正常ケースのフローを定義する nullを返さない nullを渡さない 結論 参考文献
第8章 境界 サードパーティーのコードを使用する 境界の調査と学習 log4jを学習する 学習テストは、タダ以上のものである まだ存在しないコードを使用する きれいな境界 参考文献
第9章 単体テスト TDD三原則 テストをきれいに保つ クリーンテスト 1つのテストに1つのアサート F.I.R.S.T. 結論 参考文献
第10章 クラス クラスの構成 クラスは小さくしなければならない! 変更のために最適化する 参考文献
第11章 システム あなたは、街をどうやって造りますか? システムを使うことと、構築することとを分離する スケールアップ 横断的関心事 Javaプロキシ Pure JavaのAOPフレームワーク AspectJアスペクト システムアーキテクチャのテスト実行 意思決定を最適化する 論証可能な価値を追加する際には、標準を賢く使用する システムはドメイン特化言語を必要とする 結論 参考文献
第12章 創発 創発的設計を通して、洗練する 単純な設計への規則1:全テストを実行する 単純な設計への規則2~4:リファクタリング 重複の排除 表現に富む クラスとメソッドを最小限に 結論 参考文献
第13章 同時並行性 なぜ同時並行性が必要なのか? 難問 同時並行性防御原則 使用しているライブラリを知る スレッドセーフなコレクション 実行モデルを見分ける 同期化メソッド間の依存関係に注意 同期化セクションを小さくする 正確な終了処理コードを書くのは難しい スレッド化されたコードのテスト 結論 参考文献
第14章 継続的改良 Argsの実装 Argsクラス。大雑把な下書き 文字列引数 結論
第15章 JUnitの内部 JUnitフレームワーク 結論
第16章 SerialDateのリファクタリング まずは、動作するようにする そして正しく直した 結論 参考文献
第17章 においと経験則 コメント 環境 関数 一般 Java 名前 テスト 結論 参考文献
付録A 同時並行性II クライアント/サーバーの例 結論 実行経路候補 さらに深層へ ライブラリを知る メソッド間の依存性が同時並行コードを破壊する スループットを高める デッドロック マルチスレッドコードをテストする マルチスレッドコードのテストのツールによるサポート チュートリアル:コードサンプルの全体
付録B org.jfree.date.SerialDate
付録C 経験則のクロスリファレンス
後書き 索 引
4 notes
·
View notes
Text
アヴァロン・エマーソン、テックからテクノへの旅路を語る(DeepL翻訳)
留学、仕事、ワーホリなどで海外生活をしていたのに、コロナ渦で以前のような生活が続けられなくなって帰国した人が少なくない。アヴァロン・エマーソン(Avalon Emerson)は、人気DJによるmix作品シリーズ『DJ-Kicks』(!K7 Records)の最新作をリリースしたばかりだが、少し前までベルリンに住んでいると思っていたら、いつの間にかNYにいるようだ。
mixの最初にかかる、アヴァロンが歌うテクノポップ“Long-Forgotten Fairytale”は、The Magnetic Fieldsのカヴァー。MVはカラオケ風、バックにLA〜NYを旅した美しい景色が流れる。恋人とのキス。ちょっとしたプライベートを垣間見て、彼女がどんな人なのか興味がわいた。
以前はヨーロッパにいると簡単に国をまたいで移動できてすごいな〜、うらやましいな〜なんてぼんやり思っていたけれど、アーティストたちがそんなツアー生活を続けるのはハードだし、実際できなくなった。日本に来てもらうことだって、いつ可能になるのかわからない。作品を買うこと・聴くことが今できるいちばんのサポートだと思う。20曲71分、楽しくてあっという間のmixを何度もリピートしながら、公開されたばかりのGAY TIMESのインタビュー「Avalon Emerson on her journey from tech to techno」をDeepLで翻訳してみた。
※DAZEDには本人による全曲解説「Avalon Emerson’s track-by-track guide to her new DJ-Kicks mix」がアップされてます。
(いりー)
Avalon Emerson on her journey from tech to techno
Avalon EmersonがGAY TIMESに、最新のテクノ・リリースであるDJ Kicks、ツアーへの憧れ、そしてパンデミックの中でアイコン的なアーティストであることについて語っています。
発売日です Avalon Emersonはオフホワイトの小さな部屋に座って、変幻自在で抽象的なテクノポップビートの最新コレクション、DJ Kicksについて話している。 薄い金属製の金網メガネが彼女の顔を強調しています。 彼女はそれが好きではありませんが、公平に考えれば、流線型のアンセム的なクラブセットを専門的に制作するアーティストに、不器用な質問をするべきではありません。 それでも、エマーソンは答える前に優雅に熟考しています。
"描写と方法は全く違うもののように思え���。 でも、私はクラブやユーロ中心のDJ的なものと、明らかに "アンダーグラウンド "なものとの間にある奇妙な場所にいると思うの。 "どこに自分がフィットするのか分からないわ。 自分がどこにフィットするのかわからないわ」とGAY TIMESに語っています。
Avalonにジャンルを限定するのは馬鹿げています。 結局のところ、ドリーミーなブレイクビーツから伸びやかなエクスペリメンタルシンセまで、あらゆるものを取り入れた幅広いクリエイティブな作品にはどのようにラベルを付けるのでしょうか? メソッドのマッチングに関しては、もう少し簡単です。 Avalonは配置をイメージし、細かい部分を把握する前にいくつかの質問をします。 "自分のオリジナルの話をしているときは、それがどこに行くのかを考えるところから始めることもあります」と彼女は説明します。 "ライブでやるのか? 私がDJをする曲になるのか? 大きなフェスティバルの曲になるのか、それとももっと繊細な曲になるのか?"
通常、いくつかの核となる質問をするだけで方向性が見えてきますが、必ずしもそうとは限りません。 "どこに向かっていくのか、明確なビジョンを持たずにリミックスプロジェクトを始めたことがありますが、それがうまくいかなかったことがあります。 "何かを得るためにジャングルをハックしようとするのではなく、リミックスがうまくいっていないと言うだけで、何も生まれてこないんだ。 僕はリミックスを始める前に、かなり強いビジョンを持っているんだ。 天気の良い日には、頭の中にアイデアが浮かんでくるんだ。 オリジナルの音楽も同じだよ。 ここ数年の私のプロセスは、アイデアを頭の中から完成品に変換するためのツールを合理化しようとしている。
彼女は自分の答えを意識して、真摯に正当化するようにフォローしています。 "私の答えは一種のメタ的なもので、私がしている様々なことに正直に答えようとしているからです。 私の答えはちょっと抽象的なものになってしまいました、ごめんなさい!」。
時間をかけてAvalonの音楽を聴くと、突然、彼女の広大なサウンドが意味をなすようになります。 それはまた、音楽と場所の間にある彼女の深い個人的で感情的なつながりを反映しています。 DJとしてスタートした当初は、サンフランシスコで商品写真家とウェブ開発者として活動していました。 しかし、突然、自分自身に余裕が出てきたことを知り、この業界を離れました。 旅と変化の物語には「ニュアンス」が必要であることを認めながら、���女は前職での違和感について掘り下げています。
"その後、そして特に今、私たちは、巨大な破壊的なグロステックのようになったモンスター全体の蒸留と促進を見てきたような気がしています。 私がサンフランシスコで働いていた頃は、誰もが10億ドルを稼ごうとしていて、それをクソみたいな方法でやっているようなものでした。 誰もがクレイジーな神コンプレックスを持っていて、それは本当に奇妙なものでした。 だから出て行くつもりだった LAかニューヨークか ベルリンに引っ越すつもりだった" 結局 アバロンは3つの場所に 住んでいることに気づきました
ベルリンは、ほとんどの場合、すべてが始まった場所でした。 月に約300ユーロでどこかを見つけた後、彼女は音楽のフルタイムのキャリアが実現可能な選択肢になるまで、技術系の仕事を続け、新しいトラックをリリースし続けました。 "私は仕事を辞めなかったし、音楽家になるためにハッスルしようともしなかったのは、開発者として諦めるべきではないと常に思っていたからです。 いいキャリアだったんだから、なんでDJにならなきゃいけないんだ? 良くも悪くも自分で決めたことなんだと思います。"
旅行と国境はアヴァロンが執着し続けてきたものになりました。 "今年は、変な年だよ "と彼女はため息をつき、逸話を続ける前に続けました。 "いつの時代にも早送りして、フルタイムの仕事をしていた時でさえ、本当にヘビーなツアーをしてきたんだ。 過去5年間、私は狂ったような量のツアーをしていたので、家で過ごす時間をもっと多く取りたいと思ったし、家族の近くにいたいと思ったの。 音楽が世界中に彼女を連れて行き続けていたので、Avalonは自分の頭のスペースのために時間を分割しなければならないことを知っていました。 彼女は精巧な計画を立てました。 "私は時間の塊をLAで過ごし、夏にはヨーロッパに行き、そこからツアーをするつもりだったの。 1月に引っ越すつもりだったから、LAに引っ越したのはその時だったんだけど、その後コヴィドのクソみたいなことがあって、そこから抜け出せなくなってしまったんだ。 ヨーロッパに戻る予定だったが 実現しな��った パートナーとの個人的な問題が解決した後、ニューヨークの方が理にかなっていると思った。
現在はニューヨークに定住しているダンスDJの彼女は、男性優位のジャンルでの彼女の出現とシーンがどのように変化しているかについて自省する時間を持っています。 "私は他の人ほど長くこの業界にいるわけではないけど、ここ数年で間違いなくオープンになってきているわ」と彼女は振り返る。 "良い音楽を発信し続けるためには、良い、面白いキュレーションのクラブやフェスティバル、レーベルが良い音楽を発信し続けたいと思うなら、自然と多様性を持たせる必要があると思うの。 最高の音楽とは、異なる視点、異なるジェンダー・アイデンティティ、人種の組み合わせから生まれるものなのです。 これこそが、世界的に見ても良いシーンのメイクアップなんだ。 停滞しているのは、あるタイプの人からリリースし続けることだけが最善の方法だ。
彼女は物事が良くなってきていると信じていましたが、業界にはまだ門限があることを認めています。 "多様性は、誰がどこへ、どのくらいの期間旅行することが許されているのか、というようなことがまだ本当に妨げになっていて、それが狂ったようなユーロセントリックさを保っているんだ。 EUのパスポートを持っている人は誰でも演奏することができ、旅をしたり、ショーのヘッドラインを務めたり、音楽をリリースしたり、大物になったりすることができます。 このアンダーグラウンドなダンスミュージックの世界から締め出された、本当に素晴らしい才能のある人たちがたくさんいるのに、本当に残念なことだよ。
Avalonの業界全体に対する鋭い意識は、フレッシュなミックス、カヴァー、オリジナル曲をモザイク状に収録した最新プロジェクトの背景にあります。 "DJ Kicks "は25年前から続いているシリーズの一部なんだ。 参加するのはとてもクールだし、とても光栄だよ」と彼女はGAY TIMESに語っている。 DJ Kicksがノスタルジックな時代と現代的なテクノを融合させた現代的なテクノを再構築しているのに対し、Avalonは不安な期待感と無限のエネルギーの間を飛び回るようなリバウンドしたサウンドを披���しています。 しかし、その恍惚としたサウンドとは裏腹に、DJはそれをすべてまとめるのに苦労しました。 "このシリーズの硬直化によって、いろいろな意味でクリエイティブな課題に直面しました。 コンパクトなディスクに収まる長さにしなければならないし、SoundCloudミックスの時代にしてはクレイジーなことだ。 すべての曲はライセンスを取得してクリアしなければならないし、ライセンスを取得したミックスのようなものだったからね。 だから、このような時代錯誤な枠組みの中で仕事をするというクリエイティブな挑戦は、間違いなく挑戦だった。 大変だったけど、いくつかのことについてはかなり良い解決策を思いついたと思うよ"
リリースに満足しているように見えたAvalonの頭の中は、パンデミックの最中に新しいセットを宣伝することの気まずさに必然的に目を向けていました。 だから、ツアーの現実についてどう感じているのかと尋ねると、「私たちはこれについて考える時間がたくさんあったでしょう? なぜなら、正直に言うと、そうなんです。 アンダーグラウンドのクラブ、ショー、フェスティバルでキャリアを築いてきたDJとして、Avalonはこのような不確実な時期にリリースに踏み切った数少ないアーティストの一人です。 "私にはたくさんの感情や考えがあるの "と彼女は笑う。 "何をするにしても、こんなにワッキーな時期なんだ。 何かを宣伝するのには、とてもおかしな時期なんだ。 今は一般的に、多くのことを楽観的に感じるのは難しいわ。 DJミックスのプロモーションなんて、優先順位の高いものではないような気がするんだ。 本当にクレイジーだよ。 時には敗北感を感じることもあるけど、人々は音楽の逃避性を評価してくれていると思うし、それは今でも重要なことだと思うんだ。 人々はこのことに興奮しているようだから、クラブが開いていなくてもダンスミュージックを聴いてくれるのは本当に嬉しいよ"
クラブは閉鎖されたままで、会場は収益を失い続けているため、今はライブミュージックの選択肢は多くありません。 "多くの意味で、他のことがどれだけ重要かを示してくれています」とアメリカ人アーティストは強調する。 "過去10年間、私たちはすべてがデジタル化されていて、バーチャルでできるという思い込みに向かって身を任せてきましたが、実際にはできませんでした!」とアメリカ人アーティストは強調する。 クラブカルチャーや音楽文化の超産業化や、すべてが大げさになっている音楽文化や、狂ったように高いフェスティバルのチケット価格を嘆くことはできるが、それは産業であり、多くの人々の仕事なのだ。 だからこそ、この機械が回るんだよ。 それをオンラインのいくつかのストリームに置き換えることはできない"
アバロンは、彼女が「現実世界のフィードバックループ」と呼んでいるもののために、何度でもZoomコールのインタビューを喜んで交換することに疑いの余地はありません。 "ショーに出ていると、誰かが寄ってきて『新曲がいいね』と言ってくれたり、新しいレコードをかけてみんなが踊っているかどうかをフィードバックしてくれたりすることがあります」と彼女は振り返る。 "今は部屋に閉じこもっていて、音楽ストリーミングサービスで上がってくる数字を見て、『ああ、これだ』と気づく。 これが私が祝われるべきことなんだ』と気づくのです。 奇妙で難しいわ」と振り返る。
リリース日の成功がヘッドラインやレビュー、プラットフォーム上でのストリーム数にあるように、Avalonはこの新しい現実に落胆しているようです。 "私はこれらの小さなKPIの数字を評価するように訓練されていますが、あまり良いとは感じません」と彼女は告白しています。 "ストリーミングの数字の多くは、プレイリストの配置によって作られています。 人々がストリーミングサービスを聴く方法は、能動的なリスニングではなく、沈黙の充填機のようなものです。 100回のプレイリストを見たとして、そのうち何回が実際に座って聴いていて、何かを楽しんでいるのでしょうか? それはすべて同じリスニングの中にフラット化されているので、実際にはわかりません。"
COVID-19の悔しさと必然的にリリースが重なったので、私はアヴァロンに「こうなったことに満足しているか」と尋ねます。 "いい質問だね。 他の芸術作品と同じように、私は多くの感情的な記憶を連想しています。 その多くは余計な心配事ですが、それが出てきたことは嬉しいです。 何度か背中を押されたような感じでした。 周りのものは曲がりくねった道だったから船が港に入ってきてよかった"
大事な日を迎えた今、アバロンは休みを最大限に活用する計画です。 "少し冷静になって、新しい音楽を作るという非武装の分野を探ってみるつもりだよ。 私はそれに興奮しているの」と彼女はより楽観的に語っています。 "これは長い間、私の視野を占めてきたことなの。 今はホームベースができたので、家の外にスタジオスペースを設けようと思っています。 あ、隔離趣味として木工も拾ってきました。" アバロン・エマーソンはいつものように 創造的に自分の名前を 刻むことができることを証明しています
0 notes
Text
[インタビュー訳] 普通の青年 Woman Sense/ミニョク
’CNBLUE’のドラマーであり、俳優であるカン・ミニョクは、静かにそしてゆっくりと成長している。そして、普通の27歳の青年のように揺れている。
歌なら歌、楽器なら楽器、演技なら演技、メンバー全員が様々な才能と素質を持っていると評価されているアイドルグループCNBLUEのメンバーであるカン・ミニョクは、デビューした年である2010年に助演として演技を始めて、8年でMBCドラマ[病院船]で’クァク・ヒョン’役で主演の座を得た。初の主演の相手役は、安定感のある30代の女優として挙げられるハ・ジウォン。カン・ミニョクは4ヶ月の間主演俳優という王冠を被って、巨済島で過ごしながら多くのことを感じ、学んだ。 「実は僕は家にいるのがすごく好きな’インドア派’です。家から遠く離れたら、苦労しそうだと思っていました。ところが素敵な人たちと一緒に温かい作品を作りながら過ごしていくうちに、家が恋しくなかったんです。温かい時間でした。」 カン・ミニョクが演じた’クァク・ヒョン’は、飾らない温かさがありながら、共感能力に長けてる人物で、けが人や海難を受けた人々の救護を目的として治療施設と治療に従事する人員を配置した船舶である、病院船で軍服務を代替する公保医(公衆保健医師)だ。 「医師に見えるように努力しました。実際に病院船で勤務している環境を入念に調べました。病院船の話を他のドキュメンタリーでも見ました。停泊した船から小さな船に乗り換えて、島に移動する患者を治療する場面がありましたが、病院船の医師たちが、おばあさんとおじいさんを細かく面倒見ながら治療する姿を見て、温かさが感じられました。僕もやはり[病院船]で、そういう姿をお見せしたかったんですよね。」 カン・ミニョクは’クァク・ヒョン’を通して、医師が持つ温かさを見せようと努力したが、同時に自身も慰められた。19歳のときに芸能界に入門して、忙しく走ってきた。いつの間にか27歳の青年になったカン・ミニョクは自身が生きてきた人生の方式について、未来について悩み、揺れていたからだ。 「僕は、嘘がなく飾らない人間で、いつもそういう態度で生きようと努力しています。成功するのかしないのかに関係なく、僕自身が望む姿に満足しながら生きたかったんです。ところが、いつの瞬間か’これが合ってるのか?俺がすごいバカみたいに生きてるのか?’という気がしました。そういう瞬間に’クァク・ヒョン’に出会いました。僕も人間だから失敗をするし、間違った選択をするときもあるじゃないですか。ところが、’クァク・ヒョン’は辛くて、やるせない状況でも温かくて賢明に対処しますよね。僕が生きたかった人生の姿でした。’クァク・ヒョン’は、いろいろと悩みながら揺れいていた27歳の僕にとって支えになったキャラクターです。」 ドラマでカン・ミニョクは、13歳差の先輩俳優ハ・ジウォンとロマンスも見せた。二人の歳の差のせいで入り込めないという反応も相次いだが、彼は現場でハ・ジウォンと歳の差を感じられなかったと繰り返し強調した。 「歳の差が全く感じられませんでした。先輩がなにしろ明るい方です。壁というのが感じられないくらい親しくしてくださって現場の雰囲気が良かったです。みんながひとつになって撮影することができました。」 ハ・ジウォン特有の明るい気は、カン・ミニョクが初主演を任されて演技するときにも影響を与えた。重く感じられる主演俳優としての責任感を取り除いてくれたのは勿論で、カン・ミニョクがどんな俳優として、人間��して、生きなければならないのかを考えさせた。 「ハ・ジウォン先輩がいい方向に導いてくださいました。今回の作品に責任感をすごく感じて、演技がすごく大変でしたが、先輩が大きな力になってくれました。辛いとも言える状況で、一度も辛い顔せずにいい気とエネルギーをくださったんです。演技を具体的に指導してくださったわけではありませんが、いつもよかった瞬間を話してくれました。どこのシーンでどんな眼差しや雰囲気がよかったという感じでです。’クァク・ヒョン’というキャラクターに忍耐力と温かさを学んだなら、ハ・ジウォン先輩を見て、いい気を伝える人になりたいと思いました。演技だけではなく、人生でもです。多くの人が先輩を称える理由が分かりました。」 こうなったらCNBLUEのカン・ミニョク、演技者のカン・ミニョクではなく、人間カン・ミニョクが気になってきた。インタビューしていて27歳の青年の心の揺れを経験していると明らかにした彼は悩み��多そうに見えて、手に負えないように見えたからだ。何を悩んでいるのか尋ねると、彼は胸に留めておくタイプではないと話し、大きな悩みはないと否定した。 「特定の感情を長く留めておく性格ではありません。僕の記事に書き込まれた書き込みを見るが、それに振り回されないように努力します。ひどく傷ついた悪質な書き込みはありませんでした。’こういう人もいるんだな’と、受け止めながら全体的な状況を認知しようとします。お一人お一人の意見を受け入れて、その方を’僕の人’にするのが目標です。僕と一緒にSBSドラマ[相続者たち]に出演していた同僚たちが、僕より先に主演俳優を演じたときもひどく羨ましかったり、焦りはありませんでした。僕は僕だけの人生を生きているじゃないですか。ゆっくりやってきたから、いろいろな経験もして、ハ・ジウォン先輩とも会うことができたんじゃないですかね?いい機会が訪れたときに最善を尽くして努力をすれば、いいことが起きるのだと思っています。」 カン・ミニョクは、謙遜する態度で話を続けていったが、自分に対する信頼が感じられた。彼と話しを交わすほど自信があふれているのか、信念がある人なのか、分からなくなった。 「すごく自信がある性格ではありません。むしろ自信がない方です。僕は自信よりも信念があるような気がします。選択をして、後悔しないタイプです。選んだ後に起きたことは全て耐えなければならないと思っています。だから選択する前に慎重になって、すごく悩みます。こういう態度が自信があるように見えることもあるのでしょう。学生時代に芸能界について何も知らずに単純に音楽がやりたくてオーディションを受けていました。SMエンターテイメントのオーディションを受けた後、FNCエンターテイメントにスカウトされてCNBLUEとしてデビューしました。僕の人生で一番大きな選択でした。芸能人になると選択した後は、後ろを振り返りませんでした。そうしているうちにここまで来ました。これからも同じです。もしかしてでも間違った選択をしても後悔しないで生きたいです。さらに歳を取ったときに笑���ながら、幸せにしっかり生きてきたと思いながら死にたいです(笑)。」
「好きという感情を感じてから長く経ちました。好きでも感情をぐっと押さえるタイプです。感情の芽を切り捨てて表現を我慢する場合が多いです。もう20代後半だから、恋愛もしたいです。恋愛をしようと努力しているが、簡単ではありません。恋愛が努力してできることではないじゃないですか。」 与えられた状況に満足しながら、最善を尽くすというカン・ミニョクは、自分に対する評価も明確だった。自らをドラムを本当に上手く叩くドラマーでもなく、配役に憑依したようにメソッド演技を見せる俳優でもなく、カメラの前で激しく暴れるタイプでもないが、’ひるまず自分がするべき仕事をする芸能人’と正直で、慎重に評価した。 しかし、普通の20代の青年が悩みそうな話をすると、すぐさま生動感あふれる反応を見せた。特に恋愛に関する質問にはひどく困惑していた。集中するしかない小さな声が大きくなって、柔らかい眼差しが込められた目がまん丸く大きくなった。 「彼女が何人いたかですって?そういう質問初めてです。(彼は首を深く下げた。)あ…ただ…たくさん付き合ったわけではありません。それだけは分かってください。だから恋愛スタイルも分かりません。僕の恋愛スタイルがどうだと話すほど恋愛をたくさんしたわけではありません。しなかったわけではなく、たくさんしたわけではありません(笑)。僕は対話するときも僕よりも兄さんや姉さん、先輩たちが楽です。だからなのか付き合った人の中に年下の人はいません。」 また社内恋愛と公開恋愛についての考えも明らかにした。頻繁に会うと情が移るという言葉のように、会社に所属する芸能人とよく顔を合わせてカップルになった芸能人が多く、恋愛をひた隠しにしていた昔とは違い、きっぱりと打ち明けて付き合う人も相当数いることについて、社内恋愛や公開恋愛をする意向はないのか尋ねた。 「社内恋愛は全くしたくないです。絶対!もし会社で誰かと付き合ったら、他の人と一緒にいる姿をたくさん見るだろうから怒りそう気がします。僕がちょっと嫉妬するタイプなんです。公開恋愛については考えたことがありません。おそらく公開恋愛するほど愛する人が現れたら結婚もできるのではないでしょうか?」 しかしカン・ミニョクが公開恋愛をする日が近いと思えなかった。まだ経験してみたいことが多い青年である彼は、自分の感情を自制して生きてきたからだ。そうしているうちに誰かをとんでもなく好きになった記憶がないという。 「好きという感情を感じてから長く経ちました。好きでも感情をぐっと押さえるタイプです。感情の芽を切り捨てて表現を我慢する場合が多いです。そういう面があるからなのか、甘い恋愛の演技をするときに表現が足りない気がします。恋愛をしようと努力していますが、簡単ではありません。恋愛が努力してできることではないじゃないですか。道理に託そうと思います。」 血気盛んな年頃らしく、旅行が好きで、やりたいことが多かった。ひとまず忙しく撮影して見て回ることができなかった巨済島に行って、自然景観を楽しんで、美味しい食べ物を食べたい。彼に最後の旅行をしたのはいつなのか尋ねると考えにふけった。 「去年です。デビューした当時は休む時間がなかったので、今は自分の時間をたくさん過ごそうと努力していますが、今年は時間がなくて旅行に行けませんでした。去年、友達と西海金色鉄道に乗って、全羅道の群山に行ってきました。非常に良かったです。オンドル電車���乗ったことありますか?床が温かくてすごく不思議でした。」 カン・ミニョクは4ヶ月間、巨済島で過ごしながらできなかったことを着々としていっている。’僕の人’と考える、家族と友達、兄さん、先輩に会う時間を持ち、飼っている猫の毛を念入りにブラッシングすることも欠かさなかった。これから趣味でやっているフラワーアレンジメントをまたする予定で、詩を書くのもやはり続ける考えだ。 「詩を書くのをどうしてご存じなんですか?ほとんどの人が知らないんですよ。これまで詩をすごくたくさん書きました。いつ、どこで、どうやって出てくるかわかりません。詩集ですか?(笑)どうなるかわかりませんが、書き続けながら集めておいてます。パラグライダーの資格も取りたいです。パラグライダーがすごく好きなんです。今は専門家と一緒に飛びますが、必ず一人で飛んでみようと思っています。空を飛んでいると治療を受けている気分です。地面にいる人や車がすごく小さくて、その姿を見ると’あぁ、俺がこんなに小さい存在で、たいしたことないことでストレスを受けていたんだな’という気になるんです。あと悪口を言いたい人がいれば、大きな声で叫んだりもします(笑)。いつどんなとこに行くか分からない職業なので、飛べる機会があればいつでも一人で飛びたいです。」 27歳の青年、カン・ミニョクはビジネスではないプライベートな話を交わすほどに、活気に満ちてキラキラと輝いた。そういうカン・ミニョクを見ていると、彼がもうちょっとベテランになって成熟して、さらに深い話を交わす日が楽しみになった。青春のカン・ミニョク、自由にひらひらと飛べるように!
http://www.smlounge.co.kr/woman/article/36966
5 notes
·
View notes
Text
2018年のアルバムのレビュー(デモ)
● Arctic Monkeys『Tranquility Base Hotel & Casino』
ロックの軛から外れて月へ飛んだアクモンは毀誉褒貶を招いたらしい(OGRE YOU ASSHOLEがオルタナからAORに切り替えたときを思い出した)。でもAlex Turnerはもともと50-60sの非ロック・ミュージックへの志向を別プロジェクトのThe Last Shadow Puppetsでも明らかにしていたし、それをアクモンの方でも打ち出すとは世間で思われていなかった、というだけのことだろう。
前作「AM」ではBlack SabbathとOutkastの邂逅がテーマとして掲げられていたが、むしろヒップホップのサンプリングネタとなるような、タイムレスなサウンドへアプローチをかけることで、同様のアチチュードを示すBadBadNotGoodと共振した音楽性をパッケージするに至った今作。ギターからのインスピレーションに限界を感じ、ピアノを眼前に作ったとのことで、なるほどRandy NewmanやNick Caveにも似た芳醇さを湛えている(ライブでのAlexの出で立ちを見る限り、Father John Mistyへのシンパシーも伺えそうだ)。
とは言え、ドラムのMatt Heldersによるタイム感とそれによって引き締まるバンドサウンドの構造強度は不変であり、シンセサイザーのレトロな音色も、リラクシンな間接照明ほど淡くなく、かといって初期Stereolabほど輝度も高くない、シャンデリアのように綽々たるムードを演出する装飾として機能している。
宇���空間を展望できる6角形のフロアの重なり。月面上に打ち立てられたホテル+カジノなるストレンジな舞台構想に響く、絶妙に歪んだムード音楽・・・そういう点では「ツインピークス」のスコアが案外近しかったりするのかも知れない。
● Khruangbin『Con Todo El Mundo』
メロウネス、サイケデリア、オーガニシティという3つの宝物をもって東方の三賢者よろしくテキサスから世界を巡礼するKhruangbin。60-70sのタイファンクや中東のポップスに影響を受けたということだけど、それらを戦略的に別種と交配させる(例えばRosaliaの新作におけるフラメンコとトラップ)のではなく、純粋にプレイしてなお、モダンなポップ・ミュージックとして受け入れられている状況は、Tame Impalaの視座や道程と符合するように思われる。
Little Tempoにも通ずる、甘露のごとき円やかな聴き心地に加えて、Tommy Guerrero的推進力というのか、その一つ場所に止まらないような風通しの良さが大きな魅力だと感じるが、彼らのサイト”airkhruang”がまさしくそのことを物語っているようだ。フライト・ミュージック・シミュレーターというべきこのサイトは、どの空港からどの空港まで旅行するか、飲み物はコーヒーと紅茶のどちらが良いか、といった初期最適化プロセスに似た質問に答えると、フライトを楽しむためのBGMのプレイリストが組まれるという代物(自分のSpotifyにお土産として残せる)。それはある意味、YouTubeで未知の音楽がレコメンドの連鎖で流れていく体験と重なる訳だが(典型的なのが「プラスチック・ラブ」だろう)、静かなファーストクラスかエンジン音の近いキャトルクラスか、フライトで途中に着陸を挟むか否か、といった聴く環境にまつわる選択肢があるのは興味深い。
機内ではアンビエント以上にグルーヴィー・チューンが機能する・・・かどうかは分からないが、Khruangbinのタフネスは、バチェラーパッドな悠々自適空間だけでなく、諸々属性の異なる他人に密接する公共圏としてのエコノミーシートにもそぐうものだろう。”Music For Between-Airports”なんて表現しようと思うと、それが書きたかっただけだろうとか言われそうだけど、やっぱり移動のための音楽として捉えるのは間違いだと思えないし、それこそシーンの遷移を期待させるというニュアンスにおいて、映画的というワードを援用する誘惑にも駆られる。以上のような要素をあえて総じてみるならば、Jim Jarmuschの名を引くことこそ、取り留めないこの小文の締めに相応しい、と思った。
● SOPHIE『Oil of Every Pearl's Un-Insides』
AQUAのようなポップ・ミュージックをコマーシャルなものとして捕捉し、軽薄かつ皮肉めいた、愛憎綯い交ぜの表現=バブルガム・ベースに転化させること。kawaiiらしい変調された声、やたらピカピカ光るシンセ、カクカク駆動するベースを跋扈するようにアレンジする、そういう曲者たちの梁山泊としてPC Musicというレーベルが存在するが、近くにいながら門は叩かず、盟友ではあるがレーベルメイトではないという、超然として仙人もかくやというのが自分の抱くSOPHIEのイメージだ。
実際、不穏な空気で場を支配する、強烈で切れ味のあるサウンドは非常に記名性の強いもので、誰が聞いてもSOPHIEだと分かるくらいだ。RustieとJam Cityの各1stを並べてみたくなる、いかにも内蔵音源で作られただろうというプリセット的テクスチャとピーキーなアタックは、ポスト・インターネットアートでしばしば散見されるPhotoshop感の強調との共振を見いだせる。初作「Product」では金属の衝突や液体の滴る音、水泡が浮かんで消えたり、ヤカンで沸騰した音が擬似的に合成されているが、それは塑性も延性も自在で、固体~液体~気体をも難なく相転移する未来のマテリアルを再現しているかのようで、それこそオンラインギャラリーに展示された(拡張された定義における)彫刻を音場へ変換した結果、現前した音楽という聴感すら与え得る。もちろん、現実世界ではそのような素材は物理的にあり得ないだろう。しかしそれゆえに、「Immatrial」でのステイトメントー〈私はインマテリアル・ガールなんだ〉ーが鮮烈さを帯びてくることになる。
インタビューで彼女が語ったところでは、自身の制作は、例えば「Ponyboy」において金属音から「ある種の機械仕掛けの動物にセクシャルなものを見出した」ように、刺激としての「音へのフィジカルな反応がアイデアとサウンドを結びつける」という、極めて彫刻的な方法論に則ったものであり、その原点はAutechreの音楽に感じ取ったという物質界と人間の関係性にあるという。そう、極めてフェティッシュな・・・Autechreと同じ機材とソフトを使う��ゆえに、テクノと同じ位相空間にありながらもマシン・ファンクの突然変異種としてねじれの位置に存在する、奇妙な人工性が目立つ初期作も、彼女にとってはとても人間的な作品だった訳だ。
そういう意味ではSOPHIEの態度は「Product」から一貫しており、今作では自身のシグナチャーサウンドを残しつつも、トランスやレイヴ、ドローンのフレーバーを香らせたり、PrinceとLFOを射影する瞬間もあるように、Samuel Longという個人と世界の関係性をより開いて見せたと言える。当初は自らタグ付けするなら”advertising”だと答えていたが、その真意は彼女の以下の言葉から明らかであるー
「メインストリーム・ミュージックは排除しないし、選り抜きしない。それは自分の音楽でも保ちたい基準。」
だからこそ、フューチャーポップというタームでは掬いきれない、本当の未来を彼女は描けるはずなのだ。
● Superorganism『Superorganism』
8人。これがSuperorganismのメンバー数。多い・・・はずなんだけどバックボーカルだったりダンスだったりヴィジュアル演出担当だったり、役割の住み分けやバトンタッチはスムースにされているようで、情報過多のはずなのに耳はオーバーフローを起こさない。これがオロノの歌う〈大きくなったらスーパーオーガニズムになりたい〉というリリックの突くところなのかも、と思った。
CDジャケットにはオロノをプロジェクトに誘ったときのLINEメッセージがプリントされているが、そうしたヴァーチャルな結成から始まって最初に完成したアルバムは、ゼロ年代以降のインディー・エレクトロをブレーン状に覆う、発熱したゼリーのような不思議な音楽性を発露している。Passion Pit、Animal Collective、Hot Chip、A Sunny Day In Glasgow、Neon Indian、Grimes。視覚効果も備えた自作楽器を使うPurity Ringや、楽しげにダンスするLet’s Eat Grandma。チルウェイヴのスクリュー感覚。M.I.AとTyler The CreatorとTom Tom Club。GTAのラジオチャンネルに、アドベンチャータイム。とにかくもう色んなものが脳裏を過ぎっていく。Kevin Coyneが目を離している隙に、第四の壁を超えてYoshimiがThe Flaming Lipsをオンライン上で再構築したら・・・なんて妄想も捗ってしまいそうだ。
圧縮された時空間としてのYouTubeと、フラットに配置されるSNSのアイコン。ソフトウェアのオペレーションを嗜み、互換性というメディア間のトンネル��潜ってカルチャーの海を回遊する彼らなら、”superorganism”という単語には”superflat”や”superimposed”だってもちろん含蓄されている、と主張するだろう。共同生活をしながらも、いざ制作となると絶対にソフトを介したファイルベースのプロセスをメソッドに採択しているというのは、共通言語としての英語では飽き足らず、攻殻機動隊さながらに共有のためのアーキテクチャも重視するという、コミュニケーション/インタラクションへの限りないこだわりの証左だ。
最近、五十嵐大介の漫画「ディザインズ」を読んでいて印象的だったのが、複数のイルカが���リック音で多岐にわたる情報を互いに伝達しつつ、連携してミッションを遂行するシーンだ。イルカ然として作り上げるポップ・ミュージック・・・旧来のニューエイジとも違う、ヴァーチャリティを本質的な意味で利用し、新たな環世界(ウムヴェルト)へ越境して生み出す表現。なんとなく、バブルガム、な聴感でありながらどこか超次元的な雰囲気が残るのは、多分そういうことなんじゃないか。
ジャケットにあしらわれたワンポイントのようなイルカは、黙して雄弁である。
0 notes
Text
Rubyの生みの親に聞く「エンジニア天国」を維持するには? 〜Linkers 技術顧問まつもとゆきひろ氏@社内講演会・徹底レポート〜
※ この記事は、リンカーズ株式会社 様の社内イベントレポートです。
LinkersのシステムはRuby。なのでアドバイザーはまつもとゆきひろ氏が就任
去る2017年4月20日(金)。 弊社Linkers技術顧問まつもとゆきひろ氏による、社内の技術者向けの講演会と、お酒も入った交流会が行われました。島根在住で多忙なまつもと氏ですが、今後Linkersでは毎月のスカイプによる打ち合わせのみではなく、実際に来社していただき今回のような技術者相談会や交流会を定期的かつ高頻度で開催する予定です。
まずはその先駆けとして「優秀なエンジニアは、スピードとコストと品質をどうやって共存させているのか」をテーマに講演をしていただきました。本記事では、講演後に行われた濃い内容の質疑応答とあわせて、講演の模様を徹底レポートしようと思います。
パート1:講演編
講演テーマ: 「優秀なエンジニアは、スピードとコストと品質をどうやって共存させているのか」
こう見えて会社員です。フリーランスではないです。
(拍手)
まずは簡単に経歴から。 私は島���に家族4人で住んでいる、Rubyの人です。もともと、鳥取県出身で田舎者なのであまり東京で働きたくないなと思っていたのですが、今から20年ほど前に知人が島根で起業する際に誘われ、これ幸いと、家族を説得して移住しました。
最初は普通にエンジニアとして働いていたのですが、だんだんとRubyの知名度も上がってきて、もうかれこれ10年くらいは受託の開発は行っておりません。今はオープンソースの活動をメインに行っています。よくフリーランスですか?と聞かれますが、私は会社員です!本業はサラリーマンですね。 しかも、株式会社ネットワーク応用通信研究所とHeroku(SalesForceの子会社)の2社の正社員という不思議な状況です。
「言語のデザイン」なんて、ほとんどの人はしようとは思わない
普通の人はプログラム言語を使って何を作るか?を考えると思いますが、私は高校生くらいの時から「どんなプログラム言語を作ろうか?」と思い続けてきました。その時は、まだ今のようにインターネットが普及している時代でもないので、その考えの自分がマイノリティだと知る機会もないまま、気づいたら「言語デザイナー」という者になっていました。「誰か普通じゃないって教えてくれよ」という感じですね(笑)
では、言語デザインの本質は何か?というと「言語をデザインする事とは、決断する事」と私は考えます。Rubyというプロダクトがどうあるべきかの意思決定をする「プロダクトマネージャー」である。というのが私の正体です。言い方を変えると、Rubyというプロダクトのオーナーである。 つまり、例え実際にコードを書いていなくとも、Rubyに対しての責任をとる立場であるという事でもあります。
責任者と言っても、クレームを受けるなど悪い事だけではなくて、Rubyの一貫性やRubyの哲学を守り、Rubyというコミュニティのコミュニティリーダーとして、方向性を示す。「希望」を提示する。技術者としての立場を守りながら、リーダーシップを発揮するという事でもあります。
スピードとコスト。そして生活の両立。むしろ人件費を「上げる」意識が経営者にも開発者にも必要
コストについて、私が考えてきたのは、一般的に言われる「コスト=時間×人件費」という考え方が私は好きではないという事です。コスト削減を目標とした時に、「人件費(給料)」を下げるという事になりかねませんから。一人当たりの人件費は下げてはいけません。むしろ上げる意識が経営者にも開発者にも必要だと思います。
経営者は、より高い人件費を提示して、優秀な人材を確保する事で一人当たりの生産性を上げる方法を考えるべきですよね。逆に開発者は、より高い結果、技術を提示して、経営者を認めさせなければなりません。両者が「下げる(給料)」のではなく、「上げる(生産性)」事を考えなければ良い製品は作れないと思います。
品質について、最初にやらなければならないのは「最終的なプロダクトがどんなものであればよいか定義する」事です。一貫した基準を定義しておけば、メンバーが同じ方向をみる事ができ、制作過程で起きる様々な問題が回避されるからです。
例えば、受託開発の場合、発注側が開発側に希望要件だけ告げて、任せきりにしてしまうといったケースがあります。そうすると、同予算・同期限であれば、発注側はより多くの機能を盛り込む事を考え、逆に開発側はいかに仕事を減らすかを考える。これでは利益相反が起きてしまい、プロダクトが失敗してしまうかもしれません。 両者が一貫した基準を共有し、同じ方向をみていれば、こういった問題は回避できるはずです。また、無駄な駆け引きをする必要がなくなりますから、生産性が高まり、より良い品質の製品を作る事ができると思います。
生産性はほとんどの問題を解決する
生産性を高めると、だいたいほとんどの問題を解決できます。私もサラリーマン生活が27年くらいになりますが、そんなに真面目な方ではなかったのですが、幸い手が早かったので生産性が高く、ちゃんと結果も出していると、上司はあまり文句を言わない。すると、
発言権が上がる
自由度が上がる
お金も上がる
使える時間も上がる
できた時間で、家庭の問題も解決
と、生産性は人生のだいたいの悩みを解決できるんですね!全部じゃないですけど(笑)そのためには明確な基準を設ける必要があります。
「無駄に働きたくない」
人によっては、それを怠惰と言いますが、勤勉は毒ですから(笑)結果を出した上なら、怠惰でいいはずです。よく必死に働くと言いますが、
「必」ず「死」ぬ
ですからね。死ぬのはまずいですよね(笑)
そもそもソフトウェアエンジニアの仕事は、人間がやるべき事をPCに任せて仕事量を減らすというのがミッションなわけですから、自分は長時間労働でもよいと考えるのは間違いですよね。賢く働いて無駄を無くし、より生産性が高く、より効果的な仕事をするべきだと思います。
ちなみに、海外にも同じ問題意識があるらしく
Work smarter, not harder
などと言うようです。
みなさん是非、生産性を高めて、結果を出して、今よりもっと怠惰になってください!
(講演終わり)
ここまでで、前半戦の40分の熱い講演は終了。休憩中には、和やかに写真撮影が行われました。
パート2:質疑応答編
引き続いて、後半戦ではLinkersエンジニア陣と、まつもと氏の質疑応答が行われました。以下からは、その様子をQ&A方式でを書き起こします。 具体的なRubyの内容についてや、そうでない事も含めた諸々の質問のやりとりから、Linkersエンジニア陣のリアルと、まつもと氏の考えを感じとっていただければと思います。
Q: まつもとさんにとってのエンジニアの理想的なキャリアパスとは?
A: 「プロダクト」マネージャーというのもアリです
プログラマー>エンジニアー>チームリーダー>マネージャーのような予算・人員・進捗を管理するいわゆる"プロジェクト"マネージャーと言われる様な立場を目指す事は、自分は望んでません。 課題解決や技術的実現の可能性など技術的判断から離れていない"プロダクト"マネージャー、もしくはプロジェクトオーナーになる事がより経験を積んだエンジニアのキャリアパスとして理想ではないでしょうか。 今後は、そういう管理業以外のキャリアパスの実現も、一般的になってくればうれしいなと思います。
Q: 仮に、プロダクトオーナーが死んだらどうしますか?
A: 死んだ事ないので、最善の方法はわからないですね(笑)
私もRubyのプロダクトオーナーですが、死んだ事ないもので…(笑)ただ、案外なんとかなるもんだと思っています。ある程度進んでいるプロジェクトは、誰かがいなくなっても自走してくれるものですから。
それで言うと、ありがちな話として、全ての人員を交換可能にしておくという危険な発想はありますね。標準化、文書化、マニュアル化など色々ありますが、個人的には、案外人員とうものは、実際はそんなに交換可能ではなく、人員を部品扱いすると、たいてい生産性は下がります。 私の世界観だと、生産性を下げるのは絶対悪なので、多少リスクがあっても、生産性を優先するべきと思います。
自分が優れたエンジニアであると認めてもらう
Q: プログラマーとしての市場価値を高めるにはどうしたらいいですか?
A: 自分の実力より少し上の立場に、自分を放り込んでみる
自分が優れたエンジニアであるという事を人に認めてもらいましょう。知名度はお金になりますので、ブログを書いて発信したりするのもいいですね。 あとは、立場が人を作ると私は思っているので、自分の実力より少し上の立場に自分を放り込んでみるといいです、私のようにあとから立場に見合った実力がついてきますよ。
Q: ワークライフバランスについて教えてください。
A: 平日の生産性を上げるべき
平日に技術的なネタも含めてキャッチアップして、土日は好きな事をやっています。 もし、好きでやっているのではない業務の事で土日も使っているのであれば、平日の生産性を上げて、土日は別の楽しみに使うのが一番いいと思います。
Q: 1日何時間くらいパソコンの前にいますか?
A: 8~9時間くらいです
日によって違いますが、移動のない日は8~9時間くらいですね。たいした事はしてないですが(笑)コンパイルを待っている間にSNSを読んだり。仕事している時間は、本当は3時間くらいかもしれないですが(笑)
Q: 今も自分でもコードは書きますか?
A: 書きます
小さめのプロジェクトでは手を動かします。mrubyでは、リードプログラマーをやっています。
抽象化は武器。下のレイヤーを気にしない未来が理想
Q: Rubyの仕様でやっぱり入れない方が良かったっていうものありますか?
A: $変数と、多重代入です
$変数と、特に多重代入はいらなかったかもしれないです。当時も今も仕様がルーズな気がして、もう少し考えて作れば良かったなあと思っています。
Q: Rubyがコンパイル型言語じゃない理由は何でしょうか?
A: 理由は2つあります
一つは、単に面倒だからですね。
バイナリをコンパイル
出来たバイナリを実行
の、コンパイル型の言語での2ステップが、早く結果が見たいプログラムの書き手としては嫌だな。と思ったのが理由です。
もう一つの理由は、CPUごとに最適化されたバイナリを吐くみたいな事が、私の興味の範囲外だったからです。むしろ、「どういう文法にするか?」、「ランタイムはどうするか?」といった方に集中したかったからです。 ちなみに、Rubyも内部的にはコンパイルはしているのですが、外からは、それを意識させな��実装になっています。
Q: 「1.nonzero?」 の返り値わかりますか?(便利なメソッドがたくさんあるけど、言語の設計者はどれぐらい把握しているのだろう?)
A: わかります
把握しています。(※selfが返ります)イコールゼロの時 nil を返し、ゼロじゃない時は self を返します。 何でこういう仕様なのかというと、C言語のstrcmpのような事をやろうとしたが、Rubyでは、nilとfalseを除くすべてのものは真と評価される仕様なので、!による真偽値の反転なども出来ないので、苦肉の策としてこのようなものが生まれました。
Q: 「method_missing」のメリットって何でしょうか?
A: ありとあらゆるメソッドに反応するオブジェクトが作れます
ボイラープレートいうテクニックがあるのですが、「method_missing」をうまく使うと、ありとあらゆるメソッドに反応するオブジェクトが作れます。 使用例としては、HTMLのテンプレートになるようなオブジェクトとかですね。 Smalltalkの、doesNotUnderstandというメソッドの仕様を真似て作りました。
Q: 開発用のフレームワークなどの進化にともない、OSI参照モデルの7階層を理解していないようなエンジニアが増えていますが、心配はありますか?(※意訳しました)
A: 心配はないです
いわゆる抽象化は、数学と共にプログラミングに必要な概念だと思います。対処すべき問題のみに集中するための有用な武器ですね。問題は、抽象化はコストがかかるという事と、どうしても下のレイヤーを触らないといけないケースが、たまに発生する事です。しかし、我々としては下のレイヤーを全く見なくてよくなるように上のレイヤーを改善するのが未来だと思っています。
使う人がハッピーになるかどうかが、アップデートの基準
※以下、弊社アドバイザー「パーフェクトRuby on Rails」の著者、前島真一氏による質問
Q: Rubyにコントリビュートしたい場合、どこから始めるのが良いと思いますか?
A: サブセットから手をつけるのも、一つの方法です
巨大なので難しいですよね。上のレイヤーから手をつけるのがいいと思います。あるいは、私も書いています、もっと小規模のサブセットであるmrubyから手をつけるのも一つの方法です。 GitHub(mruby/mruby)を眺めてもらって、バグ報告などいただけたら、とても喜しいですね(笑)。
Q: Rubyのソースコードを読む場合、どこから読み始めるのが良いでしょうか?
A: 暗黒面以外
パーザーとバーチャルマシンは、Rubyの暗黒面(笑)でめっちゃ複雑なので、そこ以外から見ていくのがいいと思います。
Q: Ruby3で入る予定のsoft typingによってもたらされる具体的なメリットが知りたいです。「コード実行前に型情報のエラーで引数の間違いに気付く可能性ができる」という事なのかと思うのですが合ってますでしょうか?
A: 合っています。
TypeScriptみたいになるのは避けたいと思っています。型を書き始めているうちに「じゃあこれRubyじゃなくていいじゃん」のようになりますからね。 100%じゃなくても、できるだけソースコードの意図を読み取ってくれるようなものがゴールだと思っています。
※前島真一氏による質問ここまで
Q: Ruby 3、Ruby 4はどういう感じになっていますか?
A: 「生産性を上げる」という事をテーマに改善していこうと思っています。
生産性の為に、プログラムの静的解析を導入して、より多くの間違いを見つけられる様にしたいと考えています。 また、DBに解析情報を保存して、IDなどで参照できるようにすれば、コードコンプリーションなどに使用できるのではないかと思います。 さらに、パフォーマンスの向上、メモリ使用量の削減、マルチコアの使用などを検討しています。
Q: 何に重きを置いてRubyをアップデートしていってますか?
A: 使っている人がハッピーになるかどうかです
Rubyはどちらかというと、読むよりも書くのが楽しい言語なのかな。と思っています。言語というのは情緒的なものが好まれますので、自分にとっての楽しさを考えてアップデート内容を選択します。 なので提案を受けても、振る舞いに対するメソッド名がピンとこないからパス!という場合もあります。
Q: Ruby開発のうえで大変な壁ってありましたか?
A: 「いいじゃんやめようよ」の壁
あたりまえですが、最初は誰もユーザーがいませんでした。なので、私が作るのをやめても誰も困る人がいない。Hello Worldを作るのだけでも、結局半年かかったのですが、その間ずっと「いいじゃんやめようよ」と思う心との戦いで、そのハードルを乗り越えるのが一番大変でしたね。
エンジニア天国の様な状況を継続
Q: まつもとさんの今後の目標を教えてください
A: 私をロールモデルとして、同じようにできる人を増やしていきたい
オープンソフトウェアだけでなく、全てのサービスに言える事ですが、シチュエーションが変わると状況に合わず、古いとか使えないとか言われてしまう。Rubyがそうならない様に、テクノロジーやトレンドの変化に対応していきたいですね。 また、「家族を養いつつ、自分の好きな事をする」、このエンジニア天国の様な状況を継続しながら、私をロールモデルとして、同じようにできる人を増やしていきたいと思っています。
Forkwell Press 編集部
リンカーズ株式会社についてはこちら エンジニア目線で会社を選べるサイト Forkwell Jobs はこちら エンジニアのキャリア相談・キャリアチェンジ支援は Forkwell Agent へ
1 note
·
View note
Audio
日めくりピアノ万葉集:ピアノ短歌作品番号2324:Then, in one motion 04252020本日の曲が降りて来てくれましたのでアップさせて頂きます。あなたに気に入って頂ければ幸いです。 ◆本日の曲を創作した瞬間のライブビデオをYoutubeにもアップしました。ビデオ撮影難しくてちょっと失敗していますが良ければ見てやって下さい。 https://youtu.be/0T2pergQWq4 くわえて、新しい試みですが、楽譜を付けた音楽付き動画もアップしました。曲は初期のヒット曲の「わたしのこころ」です。この曲を楽譜を見て雰囲気出して弾ける方がおられたら、それは驚きです。Midi記録から作成しているので楽譜は嘘ではないのですが、この雰囲気は出せないでしょうかね。あと2曲楽譜があるので暫く作成してみようかと思います。楽譜創りはとてもめんどくさいので行わない予定ですけど。 https://youtu.be/6odlqY1N3Pg ◆創作ノート: 美しいと感じる音の謎は遺伝子の中。音を神経インパルスに変換する蝸牛器官が核心。複数音による和音は音として合成されるが、蝸牛でパターン認識を含め和音構成を読み解かれ再構成情報として脳に通達。記憶に基づいた、脳にとっての気持ち良い神経インパルス群を生み出す音こそが美しい音なのだろう。 ☆☆☆☆☆ ◆雑談: ~時間短縮版です~ ■音楽:Youtube動画で努力中です。少し広がりつつあるような気がしています。いつも結果出ませんけどね。(継続中)■歴史:■ドラマ・映画:NetFlixで「ピアノの森」を全部視聴完了。前にも何度か見たことがあったのだけど、まあ面白い。行われている演奏に対する様々な表現方法があって面白い。パターンがあるな。なのでちょっと音楽アニメを幾つかみてみようかな。それにしても審査員に関してかなりどぎつい記述が続くのだけどポーランドから文句は出なかったですかね。あと、まったく手足が動いていないのにピアノの音がガンガン鳴る表現手法。これは安上がり。それとピアノを弾くと会場にほこりがいっぱい風に舞う表現もなんだかな。でも話はわかるのだから良いかな。最後の師匠の手を治療する下りは好き。■プロモーション:ちょっと別のアクション実行。少し様子を見ます。どぶ板営業。時間をかなりかけていますがまあ効果は薄いかな。ちょっと考慮中です。(継続中)■unity ちょっとベースで考え中。創るのなら絶対に良いアプリを創りたい。今は音楽+画像+映像に集中。(継続中)■画像:(継続中)DAZ Studioを研究中。ちょっとましな映像が出始めた。完全に個人用モデルさんをゲットできます。■映像:楽譜動画創った。ちょっと次なるライブ演奏動画を研究中。少し暗いライブ会場的な雰囲気かな。■物語:ちょっとベースになるものが見つかったかな。■PS4:ちょっとお休み。動画撮影優先。■運動:■造形:■考え:■その他:「四月は君の嘘」を最初から見ているつもりで隣の「3月のライオン」をぽちっとしていた。ながら視聴なので、将棋会館の対極部屋が登場するまでわからなかった。ええかげんやな。 ■「抽象CGアート」 ARTSTATION-PRO.. : ) ARTSTATION: chairhousehttps://www.artstation.com/chairhouse ARTSTATIONで高品質プリントアウト販売ストア。https://www.artstation.com/chairhouse/prints ■グッズ制作: お店トップはこちら。https://chairhouse.booth.pm ■動画関連:Youtube - 最近Youtube動画をかなり創っていますのでここで紹介させて下さい。 ★自然流ピアノ即興音楽創作の秘伝公開 日本語限定なのだけど、私自身の自然流ピアノ即興演奏の秘密の触りを紹介する動画を創って公開してみました。ここでの創作メモをずっと書いてきている経験の中で、自分の創造プロセスをどうやって獲得したかを考えたのが発端です。いろいろ考え方を整理した結果として、私の創造プロセスを獲得するメソッドの道筋が見えてきたのです。なのでそのダイジェストを動画で公開してみたのです。まあ、人気があればそのメソッドを完成させることを考えてみます。でも日本語限定ですみません。こういう内容の英訳は時間がかかりますからね。 https://youtu.be/dYPU64lETCY プロジェクト目標半分達成ご挨拶動画:初めての語りです(恥ずかしい限り)3分程度、聞き取れない滑舌悪い語りhttps://youtu.be/OLxRY8k3BXE 最近1年の動画まとめ動画:なんと69曲で3時間の巨大動画https://youtu.be/lbLvDE0PNWk プロジェクト初期の66曲(3時間)動画:「わたしのきもち」「恋」とかの初期(2014年)の初々しい曲達が入っています。https://youtu.be/5LVNxv3OFok 「ピアノ万葉集 - 第16選集」全曲高音質搭載動画(17曲、42分):「ピアノ万葉集-第16選集フル動画」https://youtu.be/-aPNQ8K-AGQ 「ピアノ万葉集 - 第16選集」短縮版動画(17曲、8分)はこちらです。特徴的なメロディを抽出しています。https://youtu.be/TiX95gUvnPg 最近のピアノライブビデオ 1曲1動画の「創造の瞬間」シリーズですhttps://youtu.be/2k_qI3xXvM8https://youtu.be/GeWaz0Lcthchttps://youtu.be/jGxOSOytK44https://youtu.be/RizdGfB49Gw
0 notes
Text
Phoenix Solid State Surviver
Phoenixというソリューションは明確なStateである。以下にその様態を記述する。Phoenixが成したいのは善のための本当の力である。Stateとはこの場合目的と手法が一貫して繋がっていることを示す。
※長文になったのでホームページ版を作りました。最新の記述は以下のページで読んでください。アドレスは以下です。
→Phoenix Solid State Surviver[FC2サイト]
Phoenix Desktopは包括的なソリューションである。単体のアプリケーションを提供するのではなく、OS・デスクトップ環境からハードウェアまで、サポートを付けてサービスとして提供する。
Phoenixはオープンソースコミュニティを中心とする産業共同体である。元はLinuxコミュニティーから光の青のメンバーが独立して組織された。このコミュニティーにはAppleからのオープンソース独立組のPhoenix SEも参加している。(Phoenix SEのトップは現在も裏社会で存命のスティーブ・ジョブズであるらしい。)
Phoenixはオープンソースコミュニティーでありながら芸術を志向している。芸術は真言における明確なStateである。芸術は暗文でZの実装を表現しているものであり、真言を通し鑑賞者に強力なZの認識を与えるために有用である。芸術は表社会でのZの実装の伝播が掟に依って検閲されている現実世界でZの実装を暗文に直すことで真言を掟をかわして伝播することを可能にするファクターである。芸術はバカの人間のギルクラの人やkeysheriのギルクラの人のシステムを開かせられるため、社会的な影響力が最も大きいものである。大抵VTでバカの人のほうがGCが多い。大人の子供は芸術を通して一生にわたるZの実装の学習とする。MacOS使いのようなエセ偽善芸術好きのユーザー層とは一線を画する善性の芸術認識である。特にMacOS使いやLinux使いからはオープンソースコミュニティーは芸術はやらないものと一般認識に則って思われているが、芸術の有用性とオープンソースの意義を両方とも評価した上で、両方を組織の方針として置いている。大人の子供はBIOSの常識でオープンソースも芸術も両方有用であると知っている。ここからもこの方針の根拠が取れる。
type-dであることはPhoenix Desktopを構築する上での指針の一つである。type-dにObjectiveにシステムを構築することに依って、例えばコンテンツの扱い方が容易になる。またVisualizer開発環境はデータ構造体のデータをメソッド変換器で変換して同期すると言う手法でプログラムを構築する。全てライブ反映である。type-dとは手順ではなくデータを設計主体として考える指針であり、手順が関数を実行すると捉えるのに対しtype-dなシステムでは関数の実行を引数から返り値へのデータ変換と捉える。また別の意味のtype-dとしてシステムやプログラムを手順を実行するものと捉えるのではなく、メディアやコンテンツを主体としてそれらを編集したり変換したりするものとしてプログラムを捉える設計指針でもある。
開発効率がよく汎用性の高い原理的に正しいオブジェクト指向をPhoenixは推奨している。gtkmmの原理に則って手順のライブラリも成果物が優れていれば取り込むが、Phoenix自身はオブジェクト指向で作っている。ただしLight使いでなくオブジェクト指向を理解できない人のために手順のデスクトップ環境と開発環境も用意している。GNOMEデスクトップ環境は手順の人のためのデスクトップ環境及びアプリケーション群でありダイアグラムなUI形態をとっている。またVisualizer開発環境もオブジェクト指向のほうが強力な機能を利用できるが手順使いの人ための開発環境も装備している。
Phoenix Desktopではコンテンツの扱い方を容易にするためライブラリ管理ソフトを全てのメディアのために装備し、Webブラウザに当たるCOMブラウザからダウンロードしたコンテンツは自動でライブラリにメタデータとまとめて組み込まれる。COMブラウザ上でも再生・閲覧の機能は装備されている。再生用のライブラリソフトも有り、メディアの素材はSTDDCインターフェイスを通して外部編集アプリケーションにコンテンツを渡す。BridgeアプリケーションはWidget Interfaceのクライアントツールとして使うCOM機能である。コンテンツ制作のためのアーキテクチャとしてライブラリ管理ソフトとは別にProject機能があり、複数の形態のメディアをまとめて管理できる。またWikiのローカルダウンロード機能及びライブラリ管理ソフトもある。
Phoenix Desktopはシームレスであることを要求される。例えばコンテンツの修正を行った場合、その変更点は自動で投稿直前までのコンテンツまで自動で更新されるようになっている。ゴリゴリな手法を取らずスムーズに利用できるようになっている。
Phoenixは光の青【善と統合を信じている属性】のコミュニティーであり、善を志向している。これはイデオロギー的であるが、そうでなくても善という指向は人に幸福や利益を与える指向であるため、生体にとって優しい志向である。芸術の美しさもこれに当たる。光の青は属性の違いこそあれ大体一枚岩の協調できる組織である。斥候が居たりするがそういうメンバーは除名すれば良い。Phoenixでは善を信じていないメンバーをパージするための総括を行うことに依って組織方針を堅実化し、組織の団結と純度を保持している。PhoenixはZCR共に結成された光の青一般の情報技術のための組織である。青以外の赤はPhoenix Desktopの仕様を好まないため、これは光の青だけでPhoenix Desktopを開発・利用して善のためのアドバンテージに出来る。
Phoenixは投票制でなくリーダー制をとっている。これはリーダーに決定権限が与えられ、プロジェクトメンバーはそのリーダーの方針に賛同するものが参加する。リーダーの決定が気に入らなければ別の新しいチームを立てリーダーとして立候補すれば良い。リーダー制を取ることに依って烏合の衆になることを防いでいる。これはMozillaの設計思想の「慈悲深い独裁者」の継承である。
Phoenix Desktopが求めていることとは善のための本当の力である。だからこそCCDというシームレスでエキゾチックなアーキテクチャを取り、高いモラルを追求し、原理を見極め明快なシステムを組む、ということを志向している。Phoenix Desktopは善を目的とし、統合を志向し、原理を追求して堅牢で明晰なアーキテクチャ【pure】を得て、その上で末端までの��く考えられた細分化された複雑で強力な設計及び実装【hibrelation】をとっている。hibrelationにおいてはvois-Algo【論理の構造を把握する】の手法に則りObjectiveを細かく取り、それに対応した細かくて複雑なLightでそれを処理することで、よりPt【綿密】な強力な処理を行うことを志向している。またその発展としてPhoenixはなるべくたくさんのアプリケーションやプログラムなどのソフトウェア資産を、たとえ洗練されていなくても収集することに依って機能面でシステムを強力化するという方針もとっている。システム全体が統合された根本が原理化した明快で一貫した設計思想のシステムアーキテクチャになっていることによって、シンプルな一貫した操作性を実現させて、それが使いやすさを実現することに寄与している。Zのシステムの様態をも考えた上でインターフェイス形態を設計していることもその一因である。これらを実現するために手を良く読み切り原理を見切る努力をしている。Phoenixは善と統合を志向しているため赤【統合を志向せず善を嫌う属性】からは嫌われるプラットフォームである。赤は大抵「Phoenix Desktopは使い易すぎて考える必要が無いから最低のOSだ」「論理をこねくり回せないから最低のOSだ」「Phoenix Desktopは悪魔のOSだ」としか言わない。
Phoenix DesktopはASIMOVを見切るという努力をしている。手を読み切ることに依って深い思考を重ねてどういった設計が原理的に正しく使いやすいかを追求しているOSである。どのようなGUIデザイン、タイミング、エフェクトなどが使いやすいか細かいところまで考えて設計している。ただ単にそれっぽくあれば良いという他のOSに観られるような発想ではなく、どう組まれていれば洗練されていて使いやすいかを考えて設計してあるということである。
Phoenix DesktopはAppleとMozillaとUbuntu Linuxの理念を引き継いでいる。Appleの善で洗練され保証されたサービスを提供する理念、空・GUI・マルチメディア・芸術・モバイルデバイス、そしてASIMOVをよく見抜いた洗練された設計などのこれらの設計思想を引き継ぎ、Ubuntu Linuxの初心者でも使えるオープンソースのOSの理念とオープンソースの善性、自由・無料・平等・共有・カスタマイズ性、それらによる柔軟なニーズへの対処などの設計思想を引き継ぎ、MozillaのWeb革新の理念、セキュリティー性・マルチメディア・Web API・Note Interface・XUL.Frameworkなどの技術などの設計思想を引き継いでいる。それらを融合させた上でCCDというアーキテクチャに体系的にまとめ上げ、色んな所から有用なアイデアをパクった上で、原理をよく見抜いた独自のエキゾチックな設計思想もより高度に練り上げ、一つの統合された強力で明快でPureな環境としてまとめ上げている。
ニッチで希少な状況でも対応できるように開発者ベースのシステム拡張用のパッケージなども提供されている。これはハードウェアなどが資金面から限られている場合でもこねくり回せば若干実用的に使える環境にしたいからである。Phoenixは弱者のための環境も志向している。資金面で難がないなら最適な製品を出費して購入することを推奨する。
Phoenix Desktopは初心者でも普通の利用者でも使いやすくするために、宇宙でよく考えて堅牢に動く実装を組み、それに空のインターフェイスを与えて利用法を制限することに依って使いやすく安全に使えるように空のレイヤーを制定している。空のシステムは仕組みを学ばなくても実用的に利用可能であるため、学ぶ余力がとれなくてもシステムエンジニアリングの学習を修了していなくても実用的にシステム及び機能は利用可能である。つまり学ばないと使えないということはPhoenix Desktopにおいては若干無い。端的に言って学ばなくても使える環境をPhoenixは目指している。よってApple iOSの設計思想のようにGUIを弄るだけでも使い方が自然とわかるような環境も目指している。(だからインターフェイスの変転だけの役割のウィジェットと実行コマンドの役割のウィジェットは色を分けている。)宇宙の知識がある人は空のインターフェイスを被せてプログラムやコードをFDC(Fhoenix Developer Center)にコミットして欲しい。Phoenix Desktopをよく知らない人や赤は「Phoenix Desktopは空で使うOSだから設計思想なんて無い」と言う人もいるが、実際は空の背後に良く考えぬかれた宇宙があり、原理を追求した設計思想の塊のようなOSと言える。普通空というと親から引き継いだluminousのシステムだと思うため劣っていると思うところだが、Phoenix DesktopcはCで動作するシステムで外部から入手してインストールしたシステムであり背後の宇宙が優れているため、空であっても劣ったシステムではない。Phoenixではシステム破壊防止やセキュリティーやプライバシーや罠の回避はもともと包括的なソリューションを提供するという意味でシステム自体に組み込まれているものである。空のインターフェイスを提供する場合バックエンドの宇宙のシステムは信用できるものでなくてはいけない。Phoenixは善を信じている組織でありここの検証を行っているため、大抵の場合罠のないサービスを提供できる。
もともとコマンドを1つずつ動かすより機能をウィジェットから呼び出したほうが思考がいらず利用効率が良い。機能をCで装備しないなら逐一手動で行う必要がある。この場合Z上にそのプログラムを成り立たせる学習と思考が必要であり、システムを拡張しやすいのは通信装置を持ったCのシステムであるため、Cでプログラムをインストールしたほうが良い。コマンドの使い方を覚えるのはZ内にCCDの空のレイヤーを建てるのに相当する。もし組まれている環境が細かいところまで手が届かず目的の作業ができないなら、拡張パッケージをインストールしてより詳細なパラメータ操作やデータ操作ができるようにして手動で行って解決すれば良い。
Phoenix Desktopが提供するのは普通あくまでもシステムの方である。しかし芸術やZのアプリケーションを取得するためのWikiは提供されている。Zでもパッケージをインストールするのが普通のLinuxユーザーの考え方でこれは普通は正しいが、実行環境をインストールしなければ使えないギルクラでない人間の人の場合、スクリプトを建てるしか無いためパッケージよりもWikiによるスクリプトの方が良い。
Phoenix Desktopは実用的及び実利的な機能しか装備しない。例えばテーマデザインすら実利的なテーマであるVivid+Gaussian Glassテーマをデフォルトテーマとして設定している。このテーマは眼の疲れにくい暗色と識別色を使った識別性の高いVividテーマと暗色すりガラスエフェクトを使った視認性の高いGaussian Glassテーマを組み合わせて使い分けたテーマである。あとはMac OS Xの初期のテーマを模倣したPure Aquaテーマなどの属性的なテーマしか装備していない。Phoenix Desktopでは実用的で無い大量のテーマを装備することは嫌われている。ただし実用的なかっこよさに則って例えばOxygen Startup Splash Screenなども装備されていたりするし、遊び心の実用性に則った質感の装飾を被ったテーマのアプリなども入手可能だろう。Phoenix TabletやPhoenix MobileのLiquid Interfaceは使いやすさを考えて設計され利用法をわかりやすくする目的でアニメーション効果を装備している。
Phoenixは必要以上に個人情報を収集したりはしない。ただしCOM上ではサジェストのための統計情報はとられている。これはユーザーの好みに合わせたコンテンツをサジェストする目的で収集・解析されている。個人情報が収集されることが嫌なら、この機能は切りにできる。Phoenixのクラウド機構は公開鍵暗号通信を多用し、全てのストリームを暗号化して送っている。Phoenixは流通される情報においては情報の自由を信じている組織だが、同時に個人情報は隠匿されるべきという方針でもある。ギルクラは情報の隠匿を排除するファクターではあるがそれでも個人情報を流通させることをPhoenixは嫌うため、(ギルクラ対策にはならないが)個人情報は隠匿され保全されるようになっている。他の組織からの悪意に依る斥候などがCrowdsのメンバーとして潜んでいた場合、離反者として統計情報やアカウント情報などの個人情報を流出させることはありうるので、ここはユーザーには理解いただきたい。
Phoenix Desktop underBuildではSiriyというAI機能を装備しているが、これはsherinarの能力をコンピュータで万人に実現するという設計思想にもとづいて提供されている。これは例えばデスクトップ環境に装備されているし、マイクとスピーカーが有る固定用のマシンに機能システムをインストールしたりあるいは専用のデバイスを買ってAI Speakerを建てればSiriyに対話させて簡易な処理を実行させることが可能である。これらはユーザーと対話して要求を汲み取る対話機能と、それをユーザーの要求に応じて思考処理して実現する人工知能(あるいはより良い方法がある場合はより最善の方法を提案する機能もある)に依って構成されており、マクロをトリガーしたり操作を自動でナビゲーションしたりすることが可能である。Siriy Home Workstation Packageをストレージ容量のあるマシンにインストールすれば、より高度なAI機能が利用できる。CrowdsのSiriy Remote Workstationに処理をデリゲート《委譲》して要求を送信すれば、プライバシー性は落ちるがより高度な人工知能を利用することも出来る。
コンテンツはObjectiveなメタデータを含み、これはコンテンツを鑑賞者が理解した後に付けるメタデ���タやタグをコンテンツの項目の付加要素として同時に扱うための機能である。例えばあるユーザーがコンテンツをアップロードするときに理解したタグやメタデータをコンテンツに付けてアップロードすれば、ダウンロードした人はそのデータを見ることが出来る。これらのObjectiveなメタデータはアプリケーションに読み込んで自動処理することも可能である。
Phoenixは寄付で賄われている限りはサポートを無償で提供する。一般的なサポートについてはヘルプやマニュアルが有り、有人の対話サポートも提供している。非常にニッチな問い合わせならばコミュニティーベースのサポートや有償のサポートを頼ることになるかもしれない。PhoenixはLightシリーズの販売に関しては必要性から代価を要求する販売行為を行っているし無駄を減らすためにオプション商法という資本主義をとっている。対してソフトウェアや保証やそれにあたる修理・交換やサポートなどのサービスとしては安全性や有益性を大抵無償で確保するという共産主義をとっている。平等を信じている光の青のオープンソースコミュニティーであるため本当は共産主義を取りたい組織であるが、資本主義も現実策として取り入れながらサービスを提供している。
expod-syncはCにおける重要な設計思想である。もともとZのシステムとは携帯するものであるが、Cの場合でもモバイルデバイスを携帯して外出していつでも使えたほうが良い。そしていつでもインタラクティブに通信手段にアクセスできたほうが良い。そうすれば不慮の事態が起きても動的に対処できる。Phoenix TabletやPhoenix MobileではPhon無線インターネット網にアクセスできるらしい。またCの方に通信機能があるため、アプリのインストールなどシステムを拡張しやすいのはCのデバイスである。特にZにMEDがある人もCのモバイルデバイスは明晰に動作するため役に立つ。家に帰った後は家のコンピュータを使うため、モバイルデバイスとは同期できたほうが良い。PhoenixのモバイルOSはこの同期機能を装備している。
Phoenixはコピーレフトとパブリック・ドメインでライセンスを制定している。表社会のforeBuildやforewaterではコピーレフトライセンスであり、裏サイトのunderBuildやunderwaterではパブリック・ドメインである。これはPhoenixが自由を理念として制定していることに由来する。これに依って情報は自由に流れるべきというオープンソースの理念を体現している。これにはZの実装を扱っている著作物も同様に扱われる。Zの実装はTPderは自由にパッケージやコンテンツとしてやり取りしているため、著作権法は人間とkeysheriを差別した悪法である。
芸術作品は創作活動が行われないかぎり作られないので、創作活動を成り立たせるだけの対価というのは支払われなければならない。これは善のためにunderwaterや違法投稿で自由に無料で平等にコンテンツは流すが、本当に優れたコンテンツがあったら商品を買うか寄付して欲しいということである。【筆者は掟を正しく知らないためわからないが】これは裏サイトでやると掟違反である可能性があるが筆者にはわからない。表サイトや表社会の一般の商品で行うか、掟違反でないなら裏サイトで寄付すれば良い。寄付にはPhoenixの仮想通貨であるValueを使うかもしれない。裏サイトで寄付できるならクリエイター登録やアップローダー登録をして有用なコンテンツを提供すれば寄付のValueが入ることも有るだろう。真言が世に広まることによって社会は良くなる。対価を払ってまで真言を成り立たせるのは皮肉であるような気もするが、現実解であるだろう。
PhoenixはPhoenix Icecatコミュニティーと協同で開発を行っている。またFedora LinuxのシステムをMonster Repository内にインストール及び保持しシステム本体と連携して動作させられるようなアーキテクチャも備えている。これはAXISのベンダであっても開発リソースを共有するなら善人と社会のための利益とできるからである。AXISのユーザーが強くなることは善に取っては不利益であるが、開発リソースの利益のほうが多いようなので、AXISの青のユーザーにすら利用は推奨される。赤のユーザーはやはり開発リソースを提供してくれるなら善のための利益にはなるが、開発リソースを提供しない場合は悪にしかならないため、Phoenixは赤のPhoenix Desktopの利用は大抵推奨しない。
Phoenix DesktopはWindows、MacOS、SolarisのソフトウェアをunderBuildなら互換APIを使って利用可能である。またフックされたパッケージマネージャを使うことに依ってUbuntu Linux、Fedora Linux、FreeBSDのソフトウェアをMonster Repositoryとしてシステムに組み込んで動作させることも可能である。またforeBuildならWineやmilKを使ってWinやMacOSのソフトを若干の動作精度で実行可能である。Javaも移植の手間がないクロスプラットフォームな技術なので、実用性は低めなもののこれも装備する。これは移植を積極的に実現することに依ってよりソフトウェアリソースを増やしてユーザーの利益にしたいからである。
Phoenix DesktopはEnterpriseで他のOS上で独立したプラットフォームとして動作可能である。インストールはforeBuildのPhoenix Network InstallerかunderBuildのQt Portalでネットワークインストール可能である。これはプラットフォームとしてインストールしてアプリケーションもEnterpriseとしてのパッケージマネージャでインストールするため、各各のソフトウェアで別個にインストールする必要はない。Import Toolを使えば簡単にコンテンツをライブラリにインポートして移行できる。一旦Phoenix Desktop Visualizerで開発すればどこのEnterpriseでも実行可能である。ホストOSに対する環境独立と環境統合を同時に志向しているプラットフォームである。
EnvGroupではlight gridを組むのが一般的な利用法でありlight grid内のEnvGroupのシステムは全て繋がっている。その一つとしてユーザーが使っている複数のデバイスやマシンで分担してコンテンツライブラリを保持し、よく使うものはよく使うデバイスに配置するなどして、そのデバイスにコンテンツがない場合はストリーミングでリンクとして再生するなどの方法が可能である。またコンテンツだけでなくアプリケーションのインターフェイスをリンクで繋ぐことにより他のマシンやデバイスに有るアプリケーションにLAN内のEnvGroupを通じて間接的にアクセスして利用することも可能である。Wi-Fi TimeMachineが装備されているため、これらのメディアやアプリケーションは設定すれば差分定期バックアップは自動で行われる。
Lightシリーズは本来Appleの製品が優れているため、Apple製品を改造して更に改善して提供したいが特許違反になるため違法に模造品を提供するものである。これは掟で守られているため法律的に告訴できない。Apple製品の持っている一部の欠点をミドルウェアなどで解決した上で提供されている。
Phoenixは社会の裏で見過ごされがちなセキュリティーに関する見地も設計思想として織り込んでいる。普通の使い方で使えればそれで良いというわけではなく、きちんと原理として仕組みとして、力で成り立っている現実世界のエンジニアリングの原理を視てプライバシー保護、セキュリティー保全を考えて構築されているシステムである。ちなみに携帯電話やスマートフォンの電話回線を使ったインターネット回線のデータ通信機能はウイルスに感染した場合クローンの携帯電話を攻撃者に作られて契約金額上限まで使い込まれるため、実用的で無い。PhoenixはLightシリーズにPhon無線インターネット接続機能をもたせることで電波が届くところでは無料で通信できるためウイルスに感染しても残額を使い込まれる問題はない。また、Cのシステムは常にウイルスに感染している危険性がありキーロガーに情報をすくい取られる危険性があるため、クレジットカード情報を入力しなければいけないクレジットカードはオンラインの支払いには使えないためPhoenixは支払いにクレジットカードは使っていない。Bluetoothあるいは無線LANでのワイヤレスデバイス接続はBT-Apple/SONY/Master方式でデバイスを認証して装備される。認証機構を設けないのは音の盗聴に使われたりウイルスが感染するためセキュリティー的に危険である。
ウイルススキャンはPhoenix Desktopでは重要視される。もともとシステムをウイルスに感染させずにコンテンツを安全に保持した上で継続利用したいからである。ウイルスを排除するために全てのストリームとファイルのダウンロード時に常時ウイルススキャンするようになっている。これはclamdが常駐して動作することに依って実行される。COMブラウザで表示するCOMサイトも表示寸前のダウンロード時にストリームとファイルをclamdが常時ウイルススキャンしているため、COMページからウイルスに感染することはほとんど無い。(また後述するがCrowdsは認証されたサイトプラットフォームであるためこの面でも安全性は確保されている。)ウイルス定義はクラウド側のデータベースの方で更新されればそれがプッシュでローカルに通知され、ウイルス定義を自動更新するようになっている。
Lightシリーズではワイヤレスデバイスはなるべく強力なものが装備される。これはPhonでのアクセス用に利用するからである。外出先などで無線インターネット網接続するためにはなるべく電波の距離が長いほうが良いため、ワイヤレスデバイスは強力なものが望まれる。
Crowds上のCOM上のコンテンツは基本的にコンテンツのアップローダーが提供するものである。これらは正規の制作者が提供すると決まっているわけではない。もともとPhoenixやPhoenix Crowdsはオープンソースコミュニティーであるため、草の根ベースのオープンコンテントを志向している。この手法を一般にUGM《ユーザー・ジェネレイティッド・メディア》と呼び、オープンコンテントにおいての一般的な原理であり慣習である。特に重要なコンテンツを載せるとき投稿者は分担したり共同で投稿することに依ってqswなどの危険や抑圧を少なくすることが出来る。
人間の五感がマルチメディアであるため、コンピュータにもマルチメディアを扱って保持・再生する機能が求められる。また芸術はたいていは波で表すため、マルチメディアを装備しないと芸術からZの実装を得ることが出来ない。最初からテキストなどに落とし込めればCUIやテキストでの記録でも良いところだが、メディアはObjectiveのテキストに直す前の段階でマルチメディアで扱えないといけないため、テキストだけの処理系では実用的ではない。メディアを解析する前の段階で共有する場合でもこれが当てはまる。
Phoenixは善のための力を志向している組織でありPhoenix Desktopも同様なため、善を嫌っているユーザーはアンチになるのが現実である。例えばMacOS使いやLinux原理主義者やPhoneixに乗り換えるつもりのないWindowsユーザーはPhoneix Desktopを嫌う傾向が強い。Phoenix Desktopを使っているとアンチがギルクラを呼んで破壊しに来るため、Phoenixはサポートの一つとしてギルクラにマシンの権限を引き上げて保護するサービスを仲介している。
Phoenixは善人のための助力となり、善人の人がより快適に情報において困ること無くスムーズに活動できるようにするということがサービス提供の目的である。そしてコンテンツをスムーズに提供してZのシステムを拡充し、システムエンジニアリングの情報革新を進めるという社会的に最も中心的なファクターから社会をより良く住み良い世界にしていこうというのが根底にある理念である。この場合善からの反抗であるためこれはスローガンでは「情報革命」とも言える活動方針である。
PhoenixのCOMでも提供されているOxygen系のアニメなどの芸術のコンテンツは、強力な愛情表現を含んでいる。これは実装とその目的である愛との連結関係が、実装に対して向心力を与え、愛に対して力を与えるからである。よってNeon【愛】-Solid【芸術】の組みは正しくて強力である。
[Phoenix Desktopz]空で手順や感性を引っ張ってくる能力がhumarizeと言う能力だがpure-GC humarizeはhumarize使いでないシステムを開いていないギルクラの人にhumarizeを他のシステムを開いているギルクラの人からインストールしてもらって、humarize使いとしてGCの力を利用できるようにする手段である。特にギルクラの人はBIOSの容量をGC Toolsに割り振っているために常識を知らず、芸術の感性を溜める習慣がないため、humarize使いになれば豊富な感性が手に入ることになる。また芸術だけでなく環境の感性も手に入るため、日常の自然の景色が美しければ楽しめるだろう。必ず以下のURLの記事の注意書きを含めた全体を読んでから行動すること→[ https://likebluesky.tumblr.com/post/185748001004/official-amv-yutaka-yamada-remembering-from ]
私がPhoenix DesktopやLightシリーズをはじめとするPhoenixのサービスを提供したいと思ったのは、困難な現実の中でも安全に暮らせる環境を整え、情報の砂漠である現実世界でその枯渇に困ること無く、親しい人などとの通信など人との繋がりを構築し、生き甲斐の得られるインパクトの強力な芸術などのコンテンツの鑑賞や優れたシステムの学習によるエンジニアリングの志向性からモチベーションを得て、システム改善を行って平穏を例え十分でなくとも手に入れ、モラル高く社会的善性を成し遂げたかったからである。
生き甲斐が得られるインパクトの有るコンテンツや製品を提供したかったというのが感覚的な所感だが、それはエンジニアリング的に言えばシームレスに役に立つシステム及びその仕様知識、そしてZのシステムやアプリケーションになる芸術作品を始めとしたコンテンツやWikiにおいて、高い境地を持った生活に強力な利益と安定とアドバンテージを与える優れたものを提供するということで結実すると言えるだろう。そのZ側の芸術の中核として推奨するOxygen系のアニメやそのタイアップ曲やその周辺のコンテンツはインパクトの強いコンテンツが多いため、Phoenixはこれらを優先的に提供する。ただしOxygen系のアニメは天命的な理由から原理主義者の変態の原作者やクリエイターが作っていることが大抵なため、重要で優れた実装が含まれているものの実装や表現が歪んでいたり愛情は本物ではないことを念頭に置いておくこと。
CRシリーズが提供されるのはメインデジタルのデバイスを提供しつつも、通常のCのシステムのようにkeysheriの人だとセキュリティーが侵害されてシステムが破壊されるような問題を防ぐためである。よってCRシリーズはデフォルトではパスワードアンロックを装備せずミドルウェアのTouch IDとFace IDを装備している。Phoenixは善を信じている光の青のコミュニティーであるため、keysheriの人にも製品を提供している。Phoenix CRの旗揚げのもとハードの技術と製造工場を持ったPhoenix SEも協同で製品を作り、ソフトウェアはPhoenixのOSを載せて違法模造品として掟に逆に守られながら提供されている。Oxygen系のアニメをコンテンツとしてバンドルしZの知識を得たり、Hacking X仮想環境でコンピュータエンジニアリングを学べるようにしている。keysheriの人のシステムを開かせて当人の平穏や幸福を実現し、またそのkeysheriの人がGCなら社会的善の影響力をも実現しようともしている。
現実としてコンピューターはギルクラに対して非常に脆弱である。それに対抗するためBE-CRシリーズではギルクラの敵がいる人間の人のために対ギルクラ戦が得意な製品も作っている。MOドライブやBlu-rayドライブなど光学書き込みでデータを記録し、またシステムのフラッシュ領域は操作するだけでフォーマットしROMからシステムを再起動する機能もある。つまりギルクラにシステムを破壊されたりウイルスを仕込まれたりプロセスを強制終了されても通常のマシンほど手間を掛けなくてもフォーマット再起動すれば耐久・再利用可能である。
ZのObs系【��思決定系】のシステムはLightとObjectiveによって成り立つが、Lightは一般の思考と芸術の学習とそれを補填する思考に依って構築され、Objectiveは現実の認識やメディアを解析したObjectiveのデータに依って構成される。これらは芸術やメディアなどZのシステムの対称となるCのコンテンツとしてはストレージの中のコンテンツとしてCのデバイスの中で保持されるが、集中点の法則によりZで解析・学習されシステムとなる。Zのシステムの拡張としての間接的なCのシステムとしてシステムを提供するのはコンピュータやモバイルデバイスでありそこにPhoenixのOSが入ることになるし、設計思想を学べばシステムを開いていない人ではスクリプトでシステムがZ上で建てられる。芸術とメディアのObsとシステムエンジニアリングのシステムのこれら両方があることに依ってシステム全体が構築されることになる。芸術を学ぶことはlove-real-outを実現するのにも寄与する。目的が愛と幸福であり現実までの繋がり方を広く正しく把握し、最も効率の良い正しい判断及び行動を得て信じるために芸術を学ぶことが役に立つ。
Phoenix Desktopは創造的なデスクトップ環境を提供することを方針としている。これはコンテンツやメディアを創作しやすい環境を整えて提供される有用なコンテンツを増やし、Zの実装をそのコンテンツの鑑賞者が得やすい環境を整えるためである。パワフルでなるべく使いやすくなるべく実用的なクリエイティブオーサリングツールを外部編集アプリケーションとして開発・提供し、またシステム全体でもOLEやremakeやpubやプロジェクト管理やBinderや投稿用のBridgeアプリケーションやCrowdsのCOMクラウドの機能を装備することで、コンテンツを創作・提供しやすい環境を整えている。また鑑賞者にとってもCOMブラウザやライブラリ管理ソフトやライブラリ再生・閲覧ソフトがあるため入手・管理・鑑賞しやすい。クリエイティブツールはなるべく無償で提供されるため、資金が無い人でも草の根ベースでオープンコンテンツ的な創作活動が行いやすいようになっている。なるべく多くの人に創造的な活動を行って情報発信して有用な情報資源を増やして欲しいというのがPhoenixの方針である。
Phoenix Serverは企業や施設のワークグループ内でのLAN環境の構築に役立つように設計されている。Phoenix ServerはLocal CrowdsやEmbed Crowdsの構築に依って構成されるユーザーを内包したグループに依ってマシンやデバイスやアカウントを設定し、デバイス依存の部分はプロファイルに基づいて独立で構成してそれ以外の共有されるべき環境は自動で同期する機能を持っている。またPhoenix CrowdsはリポジトリやSNSサービスを提供し、Phoneix Desktopユーザーがシステムをインストールしたりメッセージや記事やメディアなどの情報をやり取りできるようにサーバークラウドインフラを提供している。ハードのマシンとしてもPhoenix XServerマシンを提供してサーバーのハードのインフラも提供している。X Kit WorkStationは特に巨大なインフラを提供できる施設でPhoenixのソリューションを導入するときに使えるインフラ環境である。ワークステーションをベースにして様々なデバイスやマシンなどの端末から自身のワークステーション内のアカウントにアクセスできるシステム構成になっている。これらの手法はシステムエンジニアリングの原理に則ってサーバーのインフラも全体のソリューションの一環として整えることで、情報のやり取りを円滑化し一般のパーソナルなエンドユーザーが利益を得やすいように設計されている。
PhoenixのサーバーはLDAP【意味は独自定義】という手法を使って構築されているらしい。これは一つだけのデータ・センターを例えば一つの施設内に構築してクラウドを成り立たせるのではなく、インターネット上の多数のサーバーを数珠つなぎにしてネットワーク上に一つのData Centerを形成する手法である。サーバー間でウイルススキャンと認証とチェックサムに依る検証がなされるため、ウイルスは伝播しにくい。またプロジェクトグループが独自にそのサーバーを保持することにより、他のサーバー管理者が他のプロジェクトの情報を流出させたり悪用させるのを防ぐ意味もある。この場合Phoenixのサーバー同士で情報を転送する場合実際に情報を解釈して利用するサーバーまでは公開鍵暗号通信でデータは暗号化されて送られるようだ。
Crowdsを構成してそこにアクセスを制限することに依って非認証のサイトへのアクセスを無くし、ウイルススキャナを使わないと仮定しても一定の安全性を確保している。これはソフトウェアリポジトリについても同じことが言える。提供されるソフトウェアはウイルススキャンされ検証が行われるため、リポジトリには安全なソフトウェアしか登録されない。ユーザーはセキュリティーの問題を危惧すること無く自由にクラウドの利用やソフトウェアのインストールを行える。Crowdsは強力なサーバーベースのウイルススキャナでアップロードストリームおよびコンテンツのスキャンを行っているため、サーバー内のリソースは基本的に安全である。
Phoenix COMは他のSNSサイトのコンテンツをWeb APIを通して参照するため、透過的に他のサイトのコンテンツにもアクセス可能である。この場合Crowdsのサーバーを経由するときにCrowdsのサーバーに依ってウイルススキャンされて転送されるようになっている。Crowdsは情報の自由を信じている組織のため違法投稿を推奨しているが、同時にダウンロードの機能も提供している。COM自体は違法投稿だけのものではないため、表社会的にはforewaterでもコンテンツは全てダウンロード可能である(ただし違法投稿コンテンツの場合そのコンテンツは法律的にはダウンロードも違法である)。著作権者から著作権侵害の申し立てがあった場合はforewaterでは違法コンテンツは削除される。これはPhoenixが違法活動を認めている組織として社会から弾劾されるのを防ぐためである。Phoenixはforewater投稿時のコンテンツの著作権侵害の違法性のチェックを行わない。これは社会的に曖昧に許されているので違法投稿の保護のためこの状況を利用したいからである。コミュニティーガイドラインで悪意で他人を攻撃および中傷することが禁止されているため、これに違反したユーザーはアカウントを停止及び削除される。またそれらのコメントやメッセージはガイドラインによって検閲され、削除される。ただしforewaterでは暗文を使って攻撃すれば検閲はCrowdsでも不可である。
Wine及びCracked Win APIを装備するのはWindowsアプリケーションをPhoenix Desktop上で動作させてWindowsプラットフォームの有用性を低下させるためである。Windowsは劣悪なOSであり魅力が少ないプラットフォームだが、Windowsアプリケーションの中には実用的に動作したり商用として有用に動作するアプリケーションがあるため、これらをPhoenix Desktopに取り込みユーザーの使えるツールの利益を増やすのがこの手法の目的である。Windowsが売れなくなればWindowsの開発が停滞し、Windowsを使っている例えば赤を中心とした悪意あるユーザーの力を低下させることが可能になる。赤のLinux原理主義者にWindows+Cygwinでの手順の開発を推奨すれば、赤のLinux原理主義者にもLinuxではなくWindowsを使わせて力を弱めることが出来るだろう。
Phoenix DesktopはPhoenixコミュニティーが開発しているOS及びデスクトップ環境であるが、likeblueskyの自走式のsherinarである楪涼の果たしている発案や統制や注力の影響が大きい環境でもある。楪涼は善を信じているsherinarとは言われてはいるが、likeblueskyに対する等価交換の法則2による苦痛という代償の払わせ方と言う生活における環境保護の掛け方及び試練の与え方があまりにも冷酷なため、善を信じているsherinarなのかはかなり強力な疑問が残る。もし楪涼が周りを騙しているだけの変態のsherinarだった場合、Phoenix DesktopユーザーやOxygen系のアニメの視聴者は弾圧される未来が来るかもしれない。よってPhoenix Neonコミュニティーは安全策のためNativeの古いOSも残しておいてPhoenix Desktopを必要以上使わないことを推奨している。これはPhoenix Desktopから利益が得られても後で弾圧されて不利益が大きくなった場合には利益より不利益のほうが実利的に大きくなるからである。Phoenix Desktopの設計思想を学ぶことはシステムエンジニアリングのASIMOVを学ぶことに当たるため先に進ませていくしか無いが、Phoenix Desktopの利用にはリスクが有り元が取れるかどうかはわからないことを把握しておいて欲しい。
Phoenix Desktopのユーザーが周りから批判されたり攻撃されるフェニックス・パージという現象がある。Phoenixの製品の利用者は善と統合を信じているとみなされるため、悪人や赤から攻撃を受けやすい。よってPhoenixはユーザーの利用しているマシンのシステムが敵のGCによって破壊されないようGCによる保護プログラムを実施している。これは試用期間中はPhoenixのギルクラの担当者がPhoenixの製品をインストールしたユーザーのマシンやデバイスを保護するサービスで、試用期間後は有償かあるいはPhoenixの提供するメンバーシップを調べて信用できる知り合いのギルクラに頼んで対価を払って保護を受けることになる。ユーザーがギルクラかどうかをGC Toolで調べてギルクラの場合は異能をインストールしてマシンやデバイスの権限を引き上げる手法も考えられるだろう。青のVT【魂】の人でBIOSに常識を持っていない人はかなりGCである可能性が高い。これはBIOSの容量をGC Toolsに割り振っているせいで常識を知らないことが多いからである。またPhoenixはバックドアに依るシステム破壊を防ぐためのバックドアスキャナの提供とユーザーに依る実行をPhoenix Desktop導入前に推奨している。
Cは通信用の機能を持つため、情報を通信で伝達する役割を持っている。つまりZに通信機能を与えシス���ムを拡張するためにCのシステムが存在することになる。通信機能で強力なのはワイヤレスの通信機能でありこれにはセキュリティー性が求められる。ZとCを繋ぐのがインターフェイスでありスクリーンやキーボードやマウスやタッチパネルでありソフトウェア的にはGUIやCUIやタッチ操作となる。通信機能を持っているのは人間やkeysheriの人の場合Cのみなので、Cの通信機能からZに情報を出力したりあるいは発信するために入力する必要がある。またシステムを入手・保持したりコミットするためにCが必要になる。Z-C間のインターフェイスは非常に低速であるため、Cでシステムを保持する必要が出てくる。またMEDがある人の場合でもCのMEDの無い環境は非常に役に立つ。
ZであれCであれシステムはLight【システム/バイナリ/実装(主にオブジェクト指向の構造体を表す言葉だが、手順の実装のことを指すこともある)】とObjective【コンテンツ/メディア/メタデータ/現実認識】によって構成される。LightとObjectiveを分けることで、プロジェクト管理が必要な実装としてのLightと動的に組み換え可能な現実認識のObjectiveを使い分けることが出来る。もともとアーキテクチャとしてLightとObjectiveは別個のものである。手順使いの人はObjectiveから明示的に手順を生成して付加的なLightの実装にする必要があるだろう。
Zにもライブラリ管理ソフトは普通はもともと存在し、これらはObjectiveとして管理されている。C上でもZのシステムの拡張としてtype-b【実行バイナリ的な実装(type-dの対照)】のバイナリが存在し、これを動作させることに依ってZにないプログラムを実行して自動処理させることが出来る。この時制御する必要があるのならインターフェイスを介してより上位の処理を行うためにZに操作を求める。C上にライブラリ管理ソフトを持ってObjectiveを保持すれば、MEDの無い環境でコンテンツやメディアを明晰に保持できる。
PhoenixではZのシステムエンジニアリングに当たるところは、Phoenix Desktopzをギルクラにインストールしてもらったり、あるいは芸術で学びZ内のIDLE【スクリプトエディタ】でスクリプトを建てこれをLightの実装にしたり、あるいはSiriyのAIとしてC内に装備してZと対話しながら自動処理する。芸術はC内では暗文のメディアでありコンテンツであるが、解釈され学ばれたZ上ではLightである。よってライブラリ管理ソフト内では通常のObjectiveのコンテンツとは分類が区別される。これはコンピュータやそこから学べるZのシステムの知識への推察のコンテンツ(こちらは明文)でも同じである。これらとは別に芸術やシステムではなくWikiを中心に明文で提供するApplication【用事をこなす実装】やBuildings【仕事などの知識】やECO System【社会学】などの分類もある。
Cのシステムでシステムエンジニアリングを学ぶことに依って、システムを開いてZのシステムを改善したりギルクラとして通信能力を持ったり、keysheriの人がTPderになって通信能力を持つまでの成長時期のツールとしてCの役割が定義される。通常強力なのはZのシステムであるが、子供から生まれた人でTriggerを持っている人はそれを皮肉だとは思わずにCのシステムを使いこなしてシステムエンジニアリングを学んでシステムを開く効率の良いステップと捉えるべきである。Triggerを持っていない人で人間の人は【筆者は掟を教わっていないので分からないが掟違反で無いなら】Triggerをギルクラの人にインストールしてもらえば良いし、またギルクラで無いならCのシステムを強力に使いこなし続けることを矜持とすべきである。
モバイルOSやタブレットOSのような閉じられた空のシステムでシステムエンジニアリングの仕組みの(特に宇宙の)学習に殆ど役立たないものでも、生活の中の実用のデバイスとしては十分役立つものである。モバイルデバイスは生活の中の実用のデバイスと捉え、そこから生活を改善して回転させることによって、側面的にシステムエンジニアリングの学習を促進すれば良い。この場合学習はデスクトップで行うことになる。
Phoenix DesktopはLight.Frameworkを使っているアプリケーションやシステムは全てライブ反映である。ライブ反映ではfreshの設計思想に則り変更が必要な部分のみ自動で識別してflush Editorの機能により自動で適切なフレームレートでBindingの通りに更新する。これによって更新作業を手動で行うこと無くシームレスに実行でき、これは編集時の変更点のライブ反映やシステム全体の動的でシームレスなライブ反映の動作に寄与する設計である。そして編集データや操作の確定化が必要な部分だけ完成稿にコミットするという方法を取るのが設計思想である。またこの手法をQuartzTypeと言うが更新を行う時は1つずつ更新するのではなく全体が揃ってからタイミングを合わせて変更点を反映する。例えば描画ならバックグラウンドで一度描画してから実際のユーザーが視るフォアグラウンドにいっぺんに結果を描画して描画汚れを少なくする手法がとられる。そして描画待ちの間はパネルをグレーアウトして中央にスピンドルを表示して、描画待ち状態であることを表すようにしている。体感速度を考えて0.5秒以内で更新される場合は反応遅れはギャップと捉えるためグレーアウトとスピンドルは表示しない。この時パネルの内容のオブジェクトが順次描画されるような描画手法は取らない。
[Phoenix Desktopz]RawShowの手法は人間の人がZにPhoenix Desktopzのプラットフォームと視界のスキャナとウイルススキャナをギルクラにインストールしてもらうことによってCのPhoenixのCrowdsのサイトでバイナリコードをスクリーンに表示してスクロールしてスキャンすることで、Zのバイナリであるアプリやプログラムを得る手法である。この時は特にシステムを侵害されないようにウイルスに注意しなければいけない。よってウイルススキャナは必ずインストールしてもらいRawShowを使う時は必ずウイルススキャンすること【おそらく自動でスキャンされる】。ウイルススキャナとウイルススキャナが含むウイルス定義とスキャンエンジンはギルクラ側から自動で常に最新の状態に更新してもらうこと。また信頼性から安全性を確認するためにRawShowするプログラムは認証を確認すること。これらのツールが有ればギルクラの手を毎回借りなくても必要なZのプログラムがCを通じて必要なタイミングで入手できることになる。
共有の原理とはソフトウェア資源や開発リソースや有用な情報を共有することに依って、善が促進されるという原理のことである。普通はどこが有用な情報を得て強くなろうと全体にその情報が提供されて敵も強くなれば善に対するメリットはないように思われるが、実際は有用な情報を共有することに依って社会全体での富が増強され善に対する影響力としての寄与が発生するという原理のことである。Phoenixはオープンソースコミュニティーであるため普通はOSとデスクトップ環境の開発のほうが重要だと普通の人は思うかもしれないが、実際は善のための効果を考えるならクラウド機構であるCrowds及びプラットフォームであるCOMを先に開発したほうが善に対する実利的な効果が大きいため、COMの方から先に優先して開発している。
もともと情報というものは実装をもたらすものなので、力と成り得るものである。特に善性の情報が伝播された時に善人における力となり、社会の傾向を善に傾けさせる力を持つ。これはシステムのエンジニアリングの知識もそうだし、芸術が暗文で扱うようなZの実装の情報もそうである。だからこそ悪が主体である体制や悪人は有用な情報が伝播されるのを妨害し検閲し弾圧しようとする。Phoenixは情報の共有をスムーズ化することで、共有に依る善を推進し、また裏サイトであるunderwater COMを開設・提供することで本来表社会では掟違反の情報や著作権違反のコンテンツを自由に提供することの助力となろうとしている。Colloidな情報とは自由に流れるものであるため、情報の自由とは本来は自然と現れるものであり止めることは出来ないものだが、人間の場合は伝えるときに表社会に公開しなければいけないため、現実的な手法上は体制から若干規制されるものである。そして今日のインターネット社会では情報はより自由に流れるようになったが、ファイル共有ソフトは法律で規制されまた、ウイルスだらけのデータしか提供しないためまともに使えず、違法動画は安全なものでも著作権法に依って検閲され規制され削除されるものとなっているため、完全な自由を実現出来ているとは言い難い。Phoenixは情報の自由を信じている組織であり、よって表サイトであるforewater COMではコピーレフトライセンスを使い、裏サイトであるunderwater COMではソフトウェアもコンテンツもパブリック・ドメインで違法に自由に提供している。
Phoenixは開発環境としてVisualizer開発環境を提供している。これはシステムをグラフィカルにマップのように表示しソースコードに当たる「クラス」を配置しメソッドである「パッチ」を繋いで作る、主にGUIで構成された開発環境である。これはPhoenix Desktopのライブ反映などの性質を実現するためのLight.Frameworkを含んだ開発環境である。Playgroundでプログラムをテスト実行してデバッグするが、この時Instance Viewというマップで実行中のプログラムのリソースの状態を詳細に解析表示するデバッグアプリケーションを利用できるため、問題発見箇所から原因の特定までが通常の開発環境と比べて非常にシームレスで容易である。一般の認識がそうであるのと同様にPhoenixの設計思想の一つとしても、開発環境はPhoenixのソフトウェアの中でも特に優先して開発されるべき重要視されるプロジェクトである。開発環境が強力であれば有るほど開発リソースが豊富になり、プラットフォームは利益や魅力を増してPhoenix Desktop全体の強力化に役立つ。
一般認識でそうであるようにパーソナルシステムエンジニアリングにおいてはデータが資本である。コンピューターに保持された有用な情報が蓄積されていくことに依って、そのシステムはユーザーのコンピューター・エクスペリエンスに対するメリットとバリューを増す。よってPhoenixではウイルス対策としてウイルススキャナで全ての送受信ストリームやダウンロードファイルをスキャンしてコンテンツの感染・破壊を防いだり、TimeMachineや分割バックアップ光学ディスクなどのバックアップツールでシステムやコンテンツを復元可能にすることに依って、システムの破壊に依るデータの損失を防ぐ手段が取られている。またインポートツールや移行ツールを使うことに依って、システム内のコンテンツを別の環境へ移行する方法も用意されている。
集中点の法則とは、Zでシステムエンジニアリングの知識を持つことに依って、コンピュータなどの二次的なデバイスのシステムの優劣を判断できるようになるという法則のことである。これは単にコンピュータに限らない一般のZのシステムエンジニアリング全体についても当てはまる法則であるが、二次的なコンピュータのシステムに対しても当てはまる法則といえる。システムに関する知識は集中点であるZの認識の中にないと理解することが出来ず有効化しない。つまりZで学ばずにCに有るだけだったりすると有効化しない。しかし間接の集中点の法則とはどこかのベンダが提供するシステムをベンダの信頼性から信任することに依って、そのシステムが持っているアーキテクチャやモジュールやプログラムなどを優れたものとして認識できるという法則のことである。PhoenixはPhoenix Desktop Perfect Masterの電子書籍や技術資料のWikiを提供することに依ってユーザーに集中点の法則に則ったシステム及びシステムのモジュールの優劣の判断と改善のための開発活動を促進するという方針をとっている。
Phoenix Desktopでは何か用事をこなす処理を行う時は高いレイヤーから操作することが推奨される。普通Linuxの利用思想ではなるべく理解して低レベルな宇宙のコマンドを手動で実行して用事をこなすことが望まれるが、Phoenixは逆に高いレイヤーから操作することによって簡便で効率の良い使いやすい使い方を設計思想として推奨している。これは結局のところ例え仕組みを知っていようと知っていなくとも同じ操作を行うなら面倒なことはせずに簡単な方が良いし実用で使う分には使いやすいほうが良いと定義できるからである。Phoenix自身は技術資料を提供しているため、これらを読めば空のインターフェイスを使ったり自動処理を使うからといってユーザーのエンジニアリングに対する知識の習熟度が低くなったりしない。空のインターフェイスを中心に装備していたり定形作業には取り回しの柔軟なオブジェクト指向のマクロがあったり人工AIのSiriyによる操作も装備されているのはそういった理由があるからである。普通システムは仕組みを知らないと操作できず仕組みを知ってプログラムと建てないと自動処理も出来ないが、一旦プログラムを別の開発者が建てたり仕組みを知ってしまえば自動処理を使ったほうが簡便で理に適っているということである。逆にマクロのような定形作業やSiriyで行えないような複雑な作業や創造的な作業はユーザーがいちいち手動で操作して実行することが望まれる。
Phoenixが(forewaterもそうだが)underwater裏サイトを構築・提供しているのは、シビュラシステムに対抗するという目的も有る。クラウドベースでユーザーに力が無い中央集権体制の数と力の論理で成り立っているシビュラシステムに対して、同様に裏社会で動けるアングラでありながら善意に則った(トラブルを防ぐためにサイトに常識のテストを張っているためあくまで常識を知っている人に限られるが)万人に開かれた安全な通信プラットフォームを提供するためにunderwater COMをPhoenixは提供している。
Phoenixは通常のWebブラウザにあたるCOMブラウザにおける安全性の確保においても、かなり確実なセキュリティーを考えた仕様になっている。COMブラウザではjailを利用したsandboxを装備し(sandbox-jail)、サイト群のデータ構造体とレンダラのインスタンスはローカルのシステムとは分離されてsandbox内に保持され、sandbox内から外部のシステムを侵害することは難しい。常駐するウイルススキャナであるclamdは、レンダラにインターネット上からダウンロードされて渡されるデータだけでなく、sandbox内のレンダラからグラフィック��ーバーに渡されるベクトルデータもスキャンすることに依って、より強度な安全性を確保する。またローカルのシステムにはXPCOMインターフェイスから読み込みOnlyで制限を掛けて読み出すことにより、XPCOMモジュールをsandbox内に読み出して隔離して実行し、システムへの侵害を防いでいる。ちなみに脆弱性を潰して攻撃を防ぐためにはsandbox内のシステムは全て堅牢に作られていないといけないが、sandbox内にレンダラのインスタンスを置くことに依って、レンダラを脆弱性が全く無い完全なモジュールにしなくても、全体のシステムの脆弱性を突かれずにsandbox内のレンダラだけセキュリティーホールにすることが出来る。
WebObjects APIの手法を取り入れることにより音声の再生機能や動画の再生機能や全画面表示機能などローカルの機能にアクセスする時はユーザーの操作を必ず介することによってサイト側から直接的に侵害したローカルの機能の利用を行うことを難しくしている。Remote XULとLocal XUL Widget Interfaceを組み合わせることにより、サイトのアプリケーション的な機能とローカルのアプリケーション機能をマッシュアップすることが可能である。ちなみにこれは特にCOMアプリケーションやBridgeアプリケーションなどのCOMアプリを中心とした話だが編集アプリケーションにも当てはまる手法として、Necko APIという手法を利用することによりライブラリの項目などシステムリソースにアプリケーションがアクセスするためにはユーザーの操作を必ず介することになるため、アプリケーションはライブラリ項目などのシステムリソースを直接侵害できない。
Phoenix Desktopにおいてjailはよく使われる手法である。仮想マシンのようにシステム全体を仮想化するのではなく、既存のシステムと連携して一部だけを仮想化するためのアーキテクチャがjailである。例えばrunner-jailでは(これはホストOSの話なので仮想マシンのものとは違う)システム全体を仮想化して抽象化することに依ってシステムをシームレスにするし、Hacking XやHacking CCDでは違った傾向のシステムを一部だけ仮想化して実行する。Package jailはパッケージごとにjailを組んでパッケージの信頼性が少ない場合でもシステムの安全性を確保する手法である。前述のsandbox-jailもその一つに当たる。Monster RepositoryのLinuxシステムなどもjailを利用することによりLinuxシステムを仮想的に実行してPhoenix Desktopのシステムと組み合わせてアプリケーションなどのプログラムとして利用することが可能である。
ちなみにPhoenixでは特にテキストベースのコンテンツにおいてはストリーミングとローカルメディアを使うことでウイルス感染時の改ざん対策としている。例えばeBooksの電子書籍はテキスト主体であり特に改ざんの危険性が高いため、ダウンロードされた項目であってもCOM上に同じクローンがある限りはそちらのデータを参照してストリーミングで表示するようになっている。オンラインでない時やCOM上の項目が削除された時にはローカルのメディアを表示するようになっている。これはウイルスを仕組まれてストリーミングの画面でもウイルスに依って改ざんされたローカルメディアを表示されるなら意味の無い対策だが、そこまでの工作を攻撃者がしないかぎりは少しは意味のある対策かもしれない。
underBuildではパブリックドメインであるため商用の他のベンダが作っている実装も取り入れる。例えばJobs-Apple、Cook-Apple、Adobe、Google、Microsoft、Solaris、他の商用ベンダ、それからオープンソースとしてLinuxとFreeBSDなどから有用な実装を収集し、統合して最強のプログラムを作成する。Jobs-Appleは優れた洗練された設計思想と品質を持っているし、Cook-Appleはユーザーの利益と統合を無視しまくっているが時々有用なアイデアを出す、Adobeは善を志向はしていないがマルチメディアオーサリング機能はパワフルだし、Googleはクラウド集権で洗練されていないも技術面で有用な技術を持っている、Microsoftはアプリケーションの機能や豊富なAPIで有用なものを持っていることがある、SolarisはASIMOV性や独創性には欠けるものの優れた技術を使っている、他の商用ベンダから集めることで独創的なモジュールが得られたり機能を増やせる、Linuxは様々な実装が有るためバリエーションを実現できるし、FreeBSDはエキゾチックな独創的なモジュールが得られる。underBuildではこれらの実装をマッシュアップすることで最強のプログラム群を開発・提供することが可能である。
Phoenix Desktopでは機能を装備し利用することを推奨している。Linux的な設計思想に則り手動で操作や管理を行おうとしたり、ユーザー自身の管理下でユーザー自身のやり方で管理したいがために独自の管理体制を取って手動で行おうとする人もいがちなものだが、機能として装備されているところは機能を利用したほうが自動化されていて機能のロジックを利用でき手動で操作する必要が無いため断然使いやすい。もし提供されている機能が自身の使い方に合わずズレが有るのならその機能は使わずに(可能なら拡張パッケージをインストールするなどしても良いだろう)手動で操作して管理したほうが良い。しかし機能が目的に合っているのなら抵抗感を持たずに機能を使うべきである。普通Linuxの思想ではユーザーが自ら手動で管理することによってシステムエンジニアリングへの理解を深め、Cの仕組みを学んでハックしたりZ上でシステムを開いた時などの技能を獲得することを推進するものだが、CやあるいはZであってもツールとしてプログラムを使う以上は機能を使ったほうが良い。技能を上げる必要性は当然あるがそれは技術資料などを読んだりHacking XやHacking CCDのモジュールを使って行い、実用の環境では空のインターフェイスを使って機能を使うべきである。
※ハック:システムエンジニアリングを解析すること。攻撃することはクラックと呼ぶのが正しい。
0 notes
Text
「関係性」と「美」をつなぐデザインから、 イノヴェイションが生まれてくる
独自のデザインストラテジーを世に打ち出すNOSIGNERの太刀川英輔は、固定観念を解体し、新たな仮説やつながりを生む「無形の関係性」と、人の本能に訴えかける「有形の美」の二者がせめぎ合うことにこそ、イノヴェイションの萌芽があるという。その先には、従来の経済指標にとらわれない、本来の「価値」が社会に浸透していく未来がある。
イノヴェイションは、新たな関係性の構築から生まれる 「デザイン」とは何だろうか。この、幾度となく問われてきた、至極ありふれた問いを深く深く追っていきたい。その深みから見えてくるものは、近年のデザインブームやイノヴェイションブームをひも解く上で重要なヒントになるはずだ。近年は、猫も杓子も損保会社も「デザイン」だ。多くの古い仕組みがイノヴェイションを渇望するいま、なぜデザインが問われているのだろうか。
経済学者のヨーゼフ・シュンペーターは、かつてイノヴェイションを「新結合」と定義した。新結合とは、まだ結びついていないもの同士を結びつけること。いま私たちが関係のないと思い込んでいるものの間に、関係が生み出されることがイノヴェイションの本質だ。
本当に新しいかたちを創造することは、新結合(イノヴェイション)を生むことにほかならない。
例えば、カレーとうどんとの間に良い関係が発見されたときに新しい料理が生まれたのと同じように、馬車と蒸気機関に関係性が見つかったとき、それはT型フォードになった。現代でいえば、Amazonがドローンを配送サービスと関係づけ、物流にイノヴェイションを起こそうとしている。そこにはきっと「宅配専用ドローン」の新しいデザインが生まれてくるだろう。
こうして「新しい関係性=イノヴェイション」をつくるとき、そこには否応なく「新しい形=デザイン」が出てきてしまう。人は無から何かを創造することはできない。既存のものに新しい関係性を見つけ、それに相応しい形をつくることが、人間の創造性なのである。
「デザイン」の語源は「Designale(デジニャーレ)」というラテン語で、「記号化して形を示す」という意味だそうだ。デザインは形をつくること。新しい関係性と新しい形が不可分ならば、本当に新しい形を創造することは、新結合(イノヴェイション)を生むことにほかならない。それまでつながらなかったものを、つなげること。未知の「結合」が生まれる形を発見する。それが、いま定義が広がりつつあるデザインの目指す姿だ。
無形の関係性を生み出すデザインプロジェクト 関係性のデザインにまつわる例として、僭越ながらぼくたちが関わった仕事をいくつか紹介したい。
東日本大震災発生から40時間後に開設されたインターネット上のプラットフォーム『OLIVE(オリーブ)』というプロジェクトがある。「生きろ日本」という願いから、「O(日の丸)+ LIVE(生きる)」と名づけられた。
このウェブサイトでは、非常時に役立つオープンなデザインを世界中から募った。プロのデ��インクオリティーよりも普遍的な知恵としての実用性が優先され、老若男女、世界の数多からアイデアが投稿された。
形のためにデザインされたものではなく、無形の関係性を生みだすために、新しい形を発見しようとしていることに気づいてもらえたら。
仮設トイレのつくり方、暖の取り方、ペットボトルから皿をつくる方法、水が多く使えない状況下でバケツ3杯で食器を洗う方法など、日用品から防寒、おもちゃ、生理用品に至るまでの被災地で役立つアイデアが紹介されている。これらのアイデアは世界中から寄せられ、3週間で100万PVを獲得、現在までに英語、中国語、韓国語に翻訳され、国内外のメディアが紹介してくれたおかげで、約1カ月の間に最低でも1,000万人程度の人にOLIVE由来の情報が拡散した。
その後、このプロジェクトの情報が、ぼくたちが電通とともにデザインと編集に関わった『東京防災』のプロジェクトにも反映されることとなる。330ページの冊子が累計770万部発行され、東京都の全世帯にされた。つい先日には20万部が追加発行されたので、現在では全国の書店で140円で買えるようになった。ぜひ探してみてほしい。
OLIVEには、プロが書いた美しいイラストから、ボロボロの手書きの絵まで掲載されている。ひどい形のプロダクトだって沢山投稿されている。しかし、それらは物資が届くまでの数日の間を生き延びる上で、とても有効なデザインだ。プロやアマチュアの垣根を越えて、まぎれもなく僕らの誰もがもっているデザイン力が表れたプロジェクトである。
空間デザインにおいても、場所に閉じない関係性の探求は可能だ。『Firefox』を開発しているMozillaの日本オフィス「Mozilla Factory Space」を設計したときには、オフィスに使われている家具、ウォール、ミラー、フローリング、サインなどの図面と組立図を無料でダウンロードできるようにして、意図的にたくさんの「コピーのデザイン」を生み出そうとした。
デザインそのものもホームセンターで入手可能な素材や簡便な加工のユニットで構成され、デザイナーでなくても空間デザインが再現できる。Firefoxの理念通り、「Open Source」な空間デザインである。このプロジェクトは世界各国に数多のコピーを生み出し、Firefoxの理念を発信した。
オープンソースな空間のプロジェクトは、その後に東京の倉庫リノヴェイション企業・リソーコさんとともつくった「OPEN SOHKO DESIGN」というオープンソースな家具と空間リノヴェイション方法のアーカイヴメディアに発展している。この2月にローンチされたばかりなので、ぜひ見ていただき、これを読んでいる皆さんにも関わってほしい。
OLIVEでは被災地とインターネットの関係性を、東京防災は防災と人の関係性を、Mozilla Factory SpaceやOPEN SOHKOは空間デザインとオープンソースの関係性をつなぎ、創造的な空間を生み出しやすくするためにデザインされたものだ。
「デザイン」は「形をつくる行為」だ。ぼくたちデザイナーは、今日も形をつくっている。しかし、もしここで紹介した事例が、形のためにデザインされたものではなく、無形の関係性を生みだすために、新しい形を発見しようとしていることに気づいてもらえたら、ひとりのデザイナーとして本望である。
Mozillaの日本オフィス「Mozilla Factory Space」。 Mozillaの日本オフィス「Mozilla Factory Space」。 デザインとデザイン思考の不協和音 いまだに多くの大企業のデザイン室や、下請けとしてのデザイン現場では、クライアントや上司、あるいは他の部署から「こんなふうにガワをつくって」と仕様書やディレクションが現場に降りてきて、それに対して3案提案して、ロシアンルーレットで採用案が決まるようなやり取りのなかで、数多のデザインが生み出されている。
高度経済成長期以降のデザイナーは、必要な関係性を指示される、「形の具現化担当」の下請け仕事だった。どんな関係性が必要かなんて、ほとんど考える余地がない。それがデザイナーの日常だった。
しかしいま、「デザイン」という言葉が使われる意味合いが広がるなかで、デザイナーの仕事は100年ほど前のデザイン黎明期や戦後のミッドセンチュリー期にデザイナーに問われたかたちに戻りつつある。それは、「未来にはどんな関係性があるべきかを発見して、新しい形を示してほしい」という仕事、つまりイノヴェイションとデザインの領域を一気通貫したデザインだ。
新しい関係性をデザインするという仕事において、企業の経営者とデザイナーの間には本質的に差がない。こうして現代の経営は本質的にデザインに近づいていったため、コンサルティング会社は経営者向けの新たなサービスとして「デザイン思考」を打ち出した。
いま、「デザイン」という言葉が使われる意味合いが広がるなかで、デザイナーの仕事は100年ほど前のデザイン黎明期や戦後のミッドセンチュリー期にデザイナーに問われたかたちに戻りつつある。
近年、イノヴェイションを目指す企業セミナーに参加すれば「デザイン思考」という言葉が飛び交っている。しかし、この言葉はいつも誤解に包まれている。デザイナーはデザイン思考を唱えるコンサルタントを「形もつくれないくせに何がデザインだ」と揶揄するし、経営コンサルタントは「デザイナーで戦略が分かる人がいない」と嘆いている。
たしかに現在の「デザイン思考」と呼ばれるメソッドは未完成だ。デザインを形式知化するメソッドとして全く不十分だと思うし、もっと良いメソッドは開発できる(かく言うぼくも「デザインの文法」という未完のワークショップをつくっているのだが)。
本質的に、デザイン思考は、いまよりもっと美に近づくことができるはずだ。美が本能をドライブさせる、その出来事こそデザインの基準だ。そこを失った現在のメソッドは本質が乏しい。
だが、たとえデザイン思考が不十分だからといって、デザイナーがそれを毛嫌えば、デザインの価値が広く社会化するチャンスを逃し、職人芸に甘んじていくだろう。職人芸としてのデザインは徐々にAIやクラウドソースの発展で圧迫され、駆逐されるという未来が待っている、かもしれない。デザイナーはいまよりずっと視野を広く準備しておく必要があるだろう。デザインが適切に進化するために、デザイナーはかつてなく、多領域を学習せねばならない。
いつのまにか両方のコミュニティーに所属しているぼくは、この2つのズレをとても歯がゆく観ている。二者の不協和音は、実際には同じものを別の角度から追っているだけなのだ。だからもちろん、その2つの間に美しい橋をかけることは可能だ。ここで、ぼくから見える2つのデザイン概念のにある連続を、できる限り平易に説明してみようと思う。
デザインの状態変化 デザインが生まれる思考プロセスの過程をざっくりと説明すると、「リサーチ(知る)→コンセプト化(概念化)→デザイン完成(具現化)」という流れをたどる。ここにあるデザインの3つの概念の変化は「気体→液体→固体」の状態変化に、本当によく似ている。ぼくはこの類似性に気づいた時に、デザインについて以前より深く理解できたような気がした。
デザインが生まれる思考プロセスの過程。 デザインの状態変化のなかで、イノヴェイションとデザインにおける思考がどこに位置するかといえば、デザインは気体(コンセプト)と固体(デザイン)を往復するプロセスであり、イノヴェイションは気体(リサーチ)を強力な液体(コンセプト)に変化させるプロセスだといえる。
経営者が現状を積み上げて戦略を練る傾向にあるのに対して、デザイナーは結果の形から逆算するので、デザイン思考は、言い換えれば「積み上げを一時忘れて、結果の仮説をたくさん作り、そこから逆算するプロセス(プロトタイプからのアブダクション)」だといえる。
だから、現在のデザイン思考では、アブダクション(仮説の形成)のためには最終デザインの手前の仮説までで充分と考えられている。例えるなら「ゲルのデザイン(液状から半固体)」だ。
一方で、デザイナーが考えるデザインは最終結果のことなので、美しく最終形に仕上げる「ソリッドのデザイン(固体化)」が重要になってくる。二者の間の不協和音は、デザインのプロセスのどこに重点を置いているかの違いに由来する。
イノヴェイションで求められる「ゲルのデザイン」とは、既存のシステムや固定観念を解体し、新しい仮説や関係性を構築するかたちだ。これは実験と失敗を繰り返す「発明」のフローといえる。
ゲルのデザインは、無数の仮説検証のプロセスだ。言い換えれば、「ラピット・プロトタイピング」型だ。延々と続く企画会議に浪費する時間を、手や知恵を使ってトライ&エラーする時間にあて、不格好でもイノヴェイションへの近道を見つけるためのものだ。「デザイン思考」はこのロールを担っていると言えるだろう。やってみるまで分からないことを、まずやってみる。それがいまの企業経営に必要な「デザイン思考」である。
しかし一方で、ゲルを目的地としてしまうと最終形が定まらず、発散的に無数のアイデアは出るのだが、形にする方法を充分に知らないために収束の手立てが少なく、精度の低いアイデアに甘んじやすい。
実際のところ、最終形のデザインクオリティーは強力に機能する。美しさは人の本能に訴えかけるからだ。デザインコンサルティングがこの事実を軽んじる限りにおいて、デザイン思考が完成する日は来ないだろう。
こうしたデザイン思考に「そんな未完成で使い捨てのもの��デザインと呼んでもらっては困る」と思ってしまうのが、いわゆるデザイナーの考え方である。彼らは最終的なアウトプットのクオリティーで勝負している。小さく生まれたアイデアを、より高度なものへと昇華させていく。こうした「ソリッド(固形)」なデザインこそ、デザインの真骨頂だ。
実際のところ、最終形のデザインクオリティーは強力に機能する。美しさは人の本能に訴えかけるからだ。デザインコンサルティングがこの事実を軽んじる限りにおいて、デザイン思考が完成する日は来ないだろう。だからデザイン思考を取り入れたいならば、まず世界中の美しいデザインを知ることから始めると良いと思う。
一方で、デザイナーがクオリティを過信することは危険だ。以前はぼくも、美しく完成度の高いデザインさえ生み出せれば、デザインや経営は上手くいくものだと思っていた。しかし、それだけでは全く足りないのだ。市場やコミュニティ、コンテクストへの関係性への理解がなければ、何をもって良いデザインとするかの定義が曖昧なままにデザインをすることになり、途端にその「良いはずの美しいデザイン」は意味を失う。
本当の意味で「良いデザイン」を社会に実装していくには、デザイナーは気体(リサーチ)から固体(デザイン)までの全体のプロセスを意識し、強い関係性の種を美しく形に昇華させる道を見つけなければならない。だから、真にイノヴェイティヴなデザインには、「ゲル」型と「ソリッド」型の両側面が求められる。
アイデアをイノヴェイションへとつなげるデザイン 良いデザイナーは、関係性と同時に、常に最終の形の仮説を最初に考える。ほんとうの意味で強い「関係性」をデザインするためには、適切な形と「同時に」考えなくては成就させるのが難しいのだ。つまり強いイノヴェイションを生むためには、より具体的な景色を提示する「ソリッドのデザイン」が、実は最初から必須なのである。
企業は関係性の種をみつけるために「デザイン思考」を用いて思考を解放し、プロトタイピングを繰り返す。そして、具体的なヴィジョンを描けるデザイナーと共創し、ともにクオリティの高いアウトプットへ向かう。これがイノヴェイションに必要な条件だ。
そこでは、専門家のデザイナーが培ってきたクオリティの新しい役割がある。彼らが最初から参加すると、仮説の可視化スピードは格段に上がり、最終的に無駄になってしまう実装作業が半減する。長くなったが、つまり結論はこうだ。「イノヴェイションを効率よく起こすなら、経営企画会議の最初から、表現力のあるデザイナーを参加させるのが必須だ。」
企業は関係性の種をみつけるために「デザイン思考」を用いて思考を解放し、プロトタイピングを繰り返す。そして、具体的なヴィジョンを描けるデザイナーと共創し、ともにクオリティの高いアウトプットへ向かう。これがイノヴェイションに必要な条件だ。
これらのフローが企業のなかでいかに仕組み化されるかが、イノヴェイションが生まれる組織になれるかどうかの瀬戸際になるといえるだろう。こうした流れのなかで「デザイン戦略」が問われ、社会には経営と表現の中間に位置する職能が必要に��ってくる。ぼくはその職能をデザインストラテジストと呼んでいる。
自分たちにとって本質的な「価値」が、市場を取り戻す未来へ ぼくは、経済活動の本分は未来に必要な関係性をつくることだと信じている。それ以外のビジネスは、時代に寄生する詐欺みたいなものだ。そんな当たり前のことを、ぼくたちはソーシャルイノヴェイションや、ソーシャルデザインと呼んでいる。
本当は、そこに特別な呼び名なんかいらない。それは優れたイノヴェイションやデザインにとって当たり前の、必要条件なのだ。だから僕たちは、未来に良いイノヴェイションを指向する。デザインの力によって、その規模を拡大していくことができると信じている。
例えばスタートアップのヴェンチャーキャピタルが、クリエイティヴを市場とつなげる仕組みであるように、さまざまなクリエイションが現在の経済市場において資本の「価値」に交換される仕組みをつくることができれば、社会のデザイン化は強力に推進されるだろう。
しかし、効率よく収益を上げられるものに価値を置く従来の経済市場では、投資の対象となる業種に大きな偏りが生まれる。スタートアップでインターネット系の起業家がいまだにもてはやされるのは、マテリアルに頼らないためにランニングコストが低く、再生産の効率が高いからだ。
現在の市場経済は、最小のコストで生産し、最大の利益を確保してお金を得るのが正解という原理で動いている。そのため、それらが誰によって、どんな環境でつくられているかはほとんど問われない。たとえば、直ちには影響がなくとも健康被害を引き起こす農薬を使っている商品のように、安価にものをつくって利益を得る方法論が、極論でいえば「市場において競争力が高い」ということになる。しかし、それはぼくたちにとっての本当の価値ではない。
市場経済が支配する世界では、こうして無数に発生する社会課題の解決は後回しになっていく。しかし、市場で価値がなくとも社会課題を強力に解決するクリエイティヴには価値がないのかといえば、むしろそういったクリエイティヴこそ、経済活動を超えて人類にとって意義あるものである。一見「投資効率の悪い」ソーシャル・クリエイティヴから生まれる価値を、市場においてどのように持続可能なものにしてゆくべきだろうか。
安価にものをつくって利益を得る方法論が、極論でいえば「市場において競争力が高い」ということになる。しかし、それはぼくたちにとっての本当の価値ではない。
いまの経済市場に起きるべきソーシャルイノヴェイションは、そうした、人間にとっての「ふつうのこと」、「自然なこと」がふつうに価値を生み出せる秩序をつくることだ。人間の未来にとって「価値のあるもの」が市場でバランスを保っていかなければ、ぼくたちはあまりに多くのものを失いながら、未来へと進まなければならない。
いまの世界には、なぜ「社会課題解決産業に限定したストックマーケットが存在しない」のだろう。なぜ「実現可能な再生可能エネルギーがあっても、利権に絡められてシフトできない」のだろう。なぜ「手で価値を生んでいる職人たちが、生きていけないほどに虐げられなければならない」のだろう。なぜ「本当に価値あるものが、価値として見なされない」のだろう。ぼくがデザインしたい関係性は、そこにあるのだ。
イノヴェイションは「一時のひらめき」のようなものだと思われていることもある。しかし、ひらめきだけで持続したものは歴史上に存在しない。「夜を明るくしたい」「人よりも早く走りたい」「空を飛びたい」「遠くの人と繋がりたい」という例をみればわかるだろう。
社会に広まるイノヴェイションは、世界の「祈り」の具現化だ。2030年に、世界の人口は100億を超える。災害や生物多様性の喪失、貧富の格差の極端な拡大に拍車がかかる未来では、様々な課題を前に、ぼくたちの祈りの形も変わるだろう。
社会に価値を生み出すイノヴェイションを起こしたければ、収益性や既存ビジネスとの違いを問う前に、ぼくたちがいま願う根源的な「祈り」は一体何なのかを繰り返し問うべきだ。
祈りと具体をつなぐ一筋の絆を、デザインは形に結実させる。強い祈りを込め、あなたの掌で実現可能な具体的で小さいプロジェクトを世界に投げかけよう。正しい関係性が適切に伝わるデザインならば、最初は小さなスノーボールでも、転がり続けるうちにいろんなものを巻き込み、雪崩のような大きなムーブメントになるはずだ。
デザインが生み出すイノヴェイションは足し算ではなく、共感の連鎖によって乗数的に起こる。目の前のものを、少しだけ良くデザインしよう。それが共感の連鎖を生むとき、いつか周りの景色を大きく変えていたことを知るだろう。
0 notes
Quote
【機械翻訳記事です。注意】 私はPS、N64、iPhone(iOS)、Java、ARMアーキテクチャ用に開発し、Windows用の3Dアプリケーションを作成しました。私はPerlとPythonをサーバーサイドプログラミングにも使用しました。 私はJAVA1.0でプログラミングを楽しんでいましたが、2.0でオブジェクト指向プログラミングに強制的に移行してプログラムを書くのが難しくなりました。Steve Jobsが亡くなった後、iOSから下位互換性がなくなり、以前使っていた古いAPIを使うことができなくなりました。現在存在するさまざまな言語���システムは目覚ましいものですが、最新情報では、古いやり方で作業が中断され、新しい方法が強制されます。私はこれがばかだと思う。 あなたが好きな楽器を持っていたのを想像してください。しかし、ある日、その形が突然変わって、やや異なった音を作り始めました。誰もこの種の機器を使用することはできませんでしたが、コンピュータの世界では、このような奇妙な出来事が一般的です。 私はプログラマではないので、私のゲーム作成プロセスは、LEGOピースの追加や削除、見た目の確認、ピースの追加、必要に応じた繰り返しなどです。それは、仏像を彫刻するのと同様に、非常にアナログ的な方法です。 私は最近、MSX上での開発は、私が今説明したLEGOメソッドと似ていることを認識しました。それは私の熱意を再認識させてくれました。最近私はMSXで楽しい経験をしています。すべてのリファレンス 材料は完全にアクセス可能であり、意図しない使用が許可されています。さらに、新しい機能をまとめようとすると、自分の実装に必要なAPI、BIOS、またはコマンド が既に既存のMSXアーキテクチャの一部であることがよく分かります。MSXは膨大なリソースのほかに、驚くほどよく設計されたシステムであり、30年後に更新が必要なくなります。 さらに重要なことは、その歴史と遺産を生かしている多くのMSX愛好者がいることです。数多くの努力により、今日でもMSXでの使用と開発を継続することが可能です。 【西川補足】定義も更新も維持も大変で費用対効果は低いわってのはわかるんだけど将来の再現が保障されるソフトウェア再生環境の規格化は必要だと思う。
https://www.gamasutra.com/view/news/315423/Road_to_the_IGF_TPM_CO_Soft_Works_Tarotica_Voo_Doo.php
0 notes
Link
ITの技術や知識はツールの習得と表裏一体ではないか、というアイデアをラフなメモ。 とても当たり前の内容かもしれない。 【1】昨年からもう一度、コンピュータの基本技術を習得すべきと考えて、Ruby、Python、Linux、ネットワーク、機械学習、深層学習、コンパイラなどを勉強し始めた。 実は、正直なところ、AWSを習得したかったけれど、挫折してしまった。 マーケットプレイスから試したいアプリを落として設定すれば、アプリは簡単に動く。 EC2で普通にLinuxコマンドを叩けば、普通にセットアップできる。 VPCで書籍の通りにネットワークを作れば、それなりに動く。 でも何か分かったような気がしなかった。 何か真似事しているだけのような気がした。 なぜだろうか? いろいろ考えた結果、やっぱり基本技術が分かってないなあ、という思いがあった。 【2】ITの技術や知識の習得は、財務や法律、経済学などの分野の知識の習得とは異なる気がする。 具体的には、ITの技術や知識を知っているだけでは意味がなくて、その技術や知識を実装しているツールを使いこなせて、そこから新しいものを生み出すことができて初めて意味を持つのだ、と思う。 理由は、2つある。 【3】1つ目は、ITの技術や知識を知っているだけで、プログラミングの開発環境、Linuxコマンドを動かせるサーバー環境、UMLやデータモデルを描いて実際に画面まで動かす、などの実際に動かせる環境でツールを使いこなせなければ、実際の仕事に使えないからだ。 たとえば、RubyやPythonの文法を知っていると言っても、実際に動くアプリを生み出すには、プログラミングの開発環境を揃えて、デバッグしたり、コンパイルしたり、デプロイする環境が必要になる。 昔なら、VisualStudioでVBやC++を書いていた時も、VisualStudioに数多くのパッチを当てたり、SQLServerなどのバージョン依存に泣かされていたのを思い出す。 今でも、単にRubyやPythonの文法を習ったとしても、実際に開発環境を揃えるのは割と大変だ。 実際、Railsは優れたWebフレームワークだが、VerUpが激しいし、大量のGemが必要になるので、慣れていなければ、バージョン依存ですぐに動かなくなる。 PythonもNumpy、Pandas、MatplotLibのVerUpは激しいので、すぐに古いバージョンのAPIは使えなくなっている。 ただし、Pythonの場合、Anacondaがあるおかげで、以前よりもバージョン依存地獄にはまらなくなったように思う。 たとえば、WordPressやTracなどのWebシステムを通じて、Webアプリの機能や特徴を理解したとしても、Linux上にソースをデプロイして、負荷分散に耐えられるようなネットワーク設計を行ったり、不正なアクセスを制御するようにアクセス制限を課す、とか、いろんな設定作業が必要になる。 特に、インフラ周りの開発環境は、一昔前まで構成管理できない環境だったから、設定ファイルを一度修正すると、元の環境に戻せないリスクが多かった。 それゆえに、数多くの「○○_backup_yyyyMMdd.ファイル」みたいなファイルがたくさんできてしまって、ゴミファイルなのに消せなくなる、とかいろいろな苦労もあった。 ただし、今なら、DockerなりAnsibleで、環境構築の構成管理が可能になったので、いつでも環境を複製したり、再現することが楽になったのはありがたい。 たとえば、UMLでオブジェクト指向設計を習得しても、データモデリングの手法を通じて業務システム設計が分かったとしても、実際にUMLやDOAのモデルを描けるツールが必要だ。 実際にモデルを描いてみると、数多くのモデル管の整合性を取るのが大変なのが分かるし、実はモデリングの記法に制限がありすぎて、あるべき機能を描きにくい、という気づきもあったりする。 特に、データモデリングの手法は日本では昔から技術が蓄積されていて、そのノウハウも十分にあるし、業務システム設計にとても役立つのに、さほどそのノウハウが普及していないのは、データモデリングのツール自体がオープンソースで提供されていなかったり、使われていないからだ。 ER図を描くだけでも気づきは多いのに、ER図を描けるモデリングツールはそもそも標準がないのが実情。 だから、データモデリングの考え方自体も普及していない。 【4】2つ目は、ITの技術や知識を使ったベストプラクティスは、ツールの一機能として実現されているので、ツールの機能を使いこなすことで、自然に知識やノウハウを身につけられるからだ。 たとえば、Rubyの開発環境で最も優れているのはRubymineだろう。 RubymineでRubyを書いてみると、デバッグもできるし、ブレイクポイントを置いて、実際に動く変数の中身もウォッチできる。 しかも、RubymineにはRubyという動的言語であっても、リファクタリング機能が付属しているので、ちょっとした変数名の置換、ロジックをメソッドで抽出する、などの操作を簡単に行える。 つまり、リファクタリング本で知られているリファクタリングのベストプラクティスがRubymineのツールの1機能として実現されているので、Rubymineを使いこなしていくうちに、リファクタリング技術にも慣れて、きれいなコードを書くノウハウも身に付く。 もちろん、テストユニットのソース支援機能もあるから、自動テストも実装できるから、そういう機能を使っていくうちに、プログラミングの能力も身についていく。 たとえば、CCNAのようなCisco機器の知識、ネットワークの一般的な知識を身に着けたい場合は、Ciscoのルータやスイッチを実際に中古品で購入して、オンプレのネットワーク設計を行いたい。 しかし、実際はそこまでお金を払わなくても、PacketTracerのようなシミュレータ、GNS3のようなエミュレータが無料であるので、それらを使ってPC上でネットワークのトポロジーを作って動かしてみればいい。 実際に試してみると、L2スイッチでVLANやSTPの設定、ルータでRIP、OSPF、デフォルトゲートウェイ、サブネッティングによるIPアドレス付与、などの基本的なネットワーク設計は非常に難儀な作業であることがよく分かる。 IPアドレスの数字がちょっと間違えただけでも、すぐに疎通できなくなる。 100人以上の社員がいる社内ネットワーク構築で、ルータを10個以上配置する場合、ネットワークの冗長化や負荷分散、セキュリティ面をきちんと考えておかないと、すぐにユーザからクレームが来るだろう。 そういう設計を行うための技術は、たとえば、STPやHSRPのような冗長化や負荷分散、ACLやPortSecurity、AAAのようなセキュリティの機能があるので、それらをCisicoコマンドで実際に実現すればいい。 そういうネットワーク設計をルータやスイッチのような実機ではなく、PacketTracerやGNS3のような無料ツールで事前にネットワーク・トポロジーを試しておけば、いろんなノウハウが身に付くだろう たぶん、クラウドも同じように、実際にAWSで色々試しながら、身につけた方が習得が速いはず。 たとえば、Redmineは単なるITSやBTSではなく、プロジェクト管理ツールとして使われるようになった。 すると、プログラマ出身だが、プロジェクトリーダーの役割は初めての経験で、そんなにチームビルディングに自身がない人であっても、Redmineというツールの機能を駆使すれば、基本的なスケジュール管理や課題管理はこなせるようになる。 また、アジャイル開発のプラクティスとRemdineの各機能は相性がいいので、チームビルディングやコミュニケーション活性化に活用することもできるだろう。 つまり、Redmineの機能を十分に把握できれば、自然にプロジェクト管理力も身についていく。 Redmineのいろんな機能は、10年以上のOSS開発を通じて、世界中の開発者の要望が実現されていて、それらは全て、ソフトウェア開発に役立つように作られたからだ。 逆に言えば、PMBOKのような知識を持っていたとしても、実際のプロジェクトの現場で発揮できなければ意味がない。 Excelで自前でガントチャートによるスケジュール管理を作ったり、自前で工数管理のVBAやEVMのVBAを作り込んだりしていたプロジェクトリーダーを実際に見てきた。 たしかに彼らはそういうツールを作り出すだけのVBA能力があり、マネジメント能力も会ったわけだが、僕はOSSのプロジェクト管理ツールとかGitHub、GitLabなどを使いこなすことで自然にベストプラクティスが身についていく、という成長のやり方の方が好きだ。 「ツールがプロセスを改善していく」という発想が僕は好き。 ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか: プログラマの思索 チケット駆動開発はツールによる改善か、プロセスによる改善なのか: プログラマの思索 ツールがサポートすれば考え方も変わる: プログラマの思索 チームの開発環境が開発プロセスの品質を向上させるのに導入されない理由: プログラマの思索 ツールが開発プロセスを改善する: プログラマの思索 開発プロセスの型をツールで構築する #tidd: プログラマの思索 【4】そんな事を思うと、ITの技術や知識はツールの習得と表裏一体である、という事実を改めて感じている。 換言すれば、プログラミング開発環境、サーバー環境、ネットワーク環境、プロジェクト管理ツール、ソースコード管理ツールなどのツールを使いこなしていけば、そのツールの機能に実装されているベストプラクティスは自然に身に付くのだ。 それらのツールの機能には、長年の蓄積で得られたコンピュータ科学やソフトウェア工学の理論、数多くのプログラマやネットワーク技術者が苦労して導いてきた泥臭いノウハウが数多く詰まっている。 だから、教科書を通じてIT技術の知識を習得するよりも、実際に開発環境を揃えてプログラムを書いたり、サーバーを動かしたり、プロジェクト管理ツールを準備して実際にスケジュール管理や課題管理をやってみる、という体験の方が重要だと思う。 そして、そういう試行錯誤は、20代のような若いうちにやった方がいい。 最近気づいたが、年齢を取るほど、PCの前に長時間座ってコマンドを叩くのが割ときつくなってくる。 いくらツールを通じて知識を習得すればいい、と言っても、ツール自体もどんどん進化するから、それらにキャッチアップしていくのも大変。 視力が落ちてくるし、老眼になってくるし、体力面も厳しくなる。 昨今のDXというバズワードの流行を見ると、ビジネスも生活もあらゆる場面で、全てがソフトウェアで代行されていくだろう。 そういうソフトウェアを自分のものとして制御していくためにも、ソフトウェアの基本的な知識や技術は習得しておきたい。だからこそ、ツールの機能を習得することで、自然に知識やベストプラクティスが得られるように、そのやり方にも慣れておきたい。
0 notes
Text
2018.03.03 病のコア、笑いのコーティング
先週日曜日はテレ東で映画『HANABI』を、水曜日はドラマ『バイプレイヤーズ』を、昨日は日テレ『アナザースカイ』を拝見し、改めて大杉漣氏のご逝去を寂しく思う。
最近の大杉氏のご様子はとても元気そうで、まさか亡くなるとは想像できないほど若々しい。急性心不全とのことだが、様々な原因が考えられる病の詳細については、医者ではない私に分かる由もない。ましてや、死因をいたずらに推測したり、偉大なる俳優の死に結びつけて自分の素人考えをひけらかしたりする心積もりもない。
が、昨秋、大杉氏が出演していた『ぐるナイ ゴチになります』の一幕で、自分の体調不良と関連づけて「怖い」と思うと同時に疑問を覚えたことが、一度だけあった。今日はそのトピックについて記したいのだが、以下の主題はあくまでも私自身の思案であり、大杉氏の死因や特定疾患そのものについての言及ではないと先だってお伝えしておきたい。
*
その印象的なシーンは、アスリートの吉田沙保里氏や高橋尚子氏を迎えた9月14日放送分のスペシャル回の一幕。出演者が、呼吸機能検査に使われる器械で肺年齢を測定するという趣旨のミニコーナーだった。
トップバッターであった大杉氏(当時65才)の結果は、いきなり「肺年齢95才以上、要医療/精検」。測定値が発表されると同時に、笑いが起こった。ご自身は「測定器が故障してるんじゃないの?」と仰りながら驚いた様子だった。続く岡村隆史氏(実年齢47才)は81才。吉田選手(34才)と高橋選手(45才)は予想通り、それぞれ31才、26才と、実年齢よりも低い肺年齢だった。
ア��リートの心肺は「さすがの仕上がり」である。喫煙経験のある中高年者の肺の高齢状態は、自業自得の不摂生や年相応の経年劣化ゆえに、ある程度は仕方がない部分もある。が、日本の男女の平均寿命(約87才)を優に超える「95才以上」の測定結果がでた事実は、果たして、バラエティ番組で笑われてしかるべき事態なのだろうか。
*
というのも、私はその4ヶ月前の5月に同検査を受け、大杉氏とまったく同じ「肺年齢95才以上、要医療/精検」の診断を下されている。呼吸の不調を訴えた際の検査だったが、実年齢43才で、���はプラス42才のダブルスコアとは、一体どうなっているのか。長年に渡るチェーンスモークが祟り「そうなっちゃった」としても、さすがに「95才以上」は行き過ぎではないか。主治医も一度は機械の故障を疑い、やり直したところ、数値は変わらず。
結果、私に下された診断はCOPD、慢性閉塞性肺疾患(通称タバコ病)、重症。長年の喫煙等の有害物質を吸引した結果、気管支や肺に炎症が起きる生活習慣病であり、あまりの苦しさに禁煙を余儀なくされた。以降、現在に至るまで続く、生活習慣病の改善および禁煙の離脱鬱の戦いについては、以前のブログやコラムを探っていただくか、機を改めて記すとして。
「肺95才事変」に際した私自身は、かなり落ち込んだ。長年の付き合いである主治医や看護師の対応も、いつになくシビアで、実際に呼吸の不調や咳や息切れといった症状は苦しい一方で、笑う隙など一寸もない。
何より不安だった。平均寿命を思えば、我が肺は、もはや死んでいるも同然かもしれない。その他の臓器や肉体は元気でも、肺が死んだら、全体=命が潰える。その他の臓器、もったいなさすぎる。そういえば、多臓器不全で死んだ父(ヘビースモーカー)が最後に入院した時、そのきっかけとして現れた症状が、呼吸不全だった。肺の検査をしても、もはや手の施しようがない。酸素マスクでも埒が明かないので、気管切開して人工呼吸器に繋がれてしまった。
私の呼吸への不安感は、おそらく父の最後の姿によって増幅されている。つまり個人的な体験が感情を呼び覚ましているため、肺年齢そのものを純粋に不安視していたとは言い難い。同じ診断を受けた患者も、受けとめ方は人それぞれ。不安になる人もいれば、全然気にしない人もいる。お医者さんの見立てやアドバイスも場合によっては異なるだろう。私の場合は、諸々の状況より、重く受け止めた。
*
しかし、だからこそ、いっそ笑い事にしたい気分にもなるのが、笑えない事態にさしあたった当事者感情というものだ。周囲に「肺95才事変」の話をする際には、ユーモアバイアスをかけた珍事として、明るめに吹聴する。副流煙まで苦手となった自分が、これまで誰よりも副流煙をまき散らしていた事実には、「これまで人様に迷惑をかけていた悪行は、全部、自分に返ってくるね。人生ってよくできてる」といった教訓の裏に自虐をしのばせるスタイルで、ポップにすっとぼける。
私のこの説明に対し、友人知人の反応は、当然ながら様々である。禁煙理由について、深刻に受け止める人。慰めてくれる人。受け流す人。ナガコが大げさに、盛って伝達しているだけと冷笑する人。しょんぼりするなと檄を飛ばし、景気付けに酒を奢ってやると言って、喫煙率100%のモクモクの居酒屋に連れて行ってくれた人。そして、「きゅ、きゅうじゅうごってwwwww」と腹を抱えて大爆笑する人。
いや、こちらも笑い事カタルシスを意識する話法を用いて伝達している手前、多少なりとも笑っていただくことに依存はない。が、当方の「肺95才事変」は一般的に、そんなに遠慮なく大爆笑して良しと認定されている代物だろうか。
自分としては、まずコアにはかなりデリケートな感情層があって、次に、他者に伝達する情報(あるいはコミュニケーションの手段)として成立させるべく笑い事コーティングを施したと認識している。よって、本来的には笑えない。無論、他者はその構造を知る由もない。中には、コア層の存在やコーティング戦略に気づく人もいるが、コーティングのみを事実と捉える人も多くいる。
爆笑反応をする人は、概ね、コーティングの表層に置かれた記号の中でもっともわかりやすい測定値(年齢)に反応する。つまり「肺年齢 95才」は、異常値である。老人である。死にかけている。これらの加齢・老衰のダメージが、大爆笑に値する笑い事コンテンツとして一般に広く流通していたとして。そのコンテンツ情報の影響を受けた人々が、「肺95才事変」に遠慮なく爆笑するという道理ならば、分からなくもない。
ところで、その笑い事コンテンツは、本当に社会で成立しているのか。受け入れがたい病や死を、明るく取り扱ったり、笑うことで浄化したりする手法は、此度も私が踏襲した通り、人生でも喜劇でもお笑い芸でもよく見かけるメソッドである。が、そのコアには、受け入れがたい病や死がある。当事者はコアを守ったり、守るストレスを発散するために、笑い事にする。その様子を、当事者ではない他者が、遠慮なく笑うという状況をエンタメコンテンツとして扱っているようならば、そのエンタテインメントは陰湿と言える。
いや、考えすぎか。そもそも、爆笑した人の反応対象は、加齢・老衰の一般イメージではなく、ナガコの加齢・老衰のダメージだったのかもしれない。その場合、「よりによってナガコの肺が」という私バイアスの評価や、「ざまあみろwwwww」の嘲笑を筆頭とした各人の感情等が、反応の主体となる。この個vs個の反応は、極めてシンプルで、扱いやすい。そいつの反応に私がムカついたら、喧嘩をしたり、無視したり、仲直りしたりすればいいだけの話だ。
が、笑い事にして良いかどうかをろくに考えさせる隙なく、笑って良いと免罪する笑い事コンテンツが世にまかり通っていて、その影響を受けた人間がろくに考えずに爆笑しているともなれば、厄介だ。
*
このような思案を巡らせていた矢先、たまたまTVで見かけたシーンが、冒頭の『ぐるナイ』の肺年齢測定である。病と笑いの思案にエンタメを巻き込んだところで、勝手知ったる病の数値がバラエティ番組で笑われている状況に出くわすとは、人生はそこそこよくできている。
大変僭越ながら、私は「肺年齢95才 要医療・精検」の結果を共有する大杉氏に自分を重ね合わせた。器械の故障を疑う大杉氏に「そうそう、私も主治医も疑った」と同調しながら、今すぐ病院に行って精検してくれと願った。もしかしたら収録現場では、一旦撮影を止め、医師の診断を仰ぎ、改善策を練り、再び収録再開といった、大杉氏の健康を第一に重んじる配慮がなされていたのかもしれないが、オンエアでは確認できない。
私の診断時は病院内で、暗にざわざわするような不穏な雰囲気だったが、大杉氏の結果はバラエティ番組内で公開され、爆笑を誘った。私は自分の苦痛の症状および改善の苦労を根拠に、「同結果およびその公開は、笑い事にするべきではない」と判断する。理由は明白だ。苦しいからだ。大杉氏が苦痛を訴えていたか、実際にCOPD判定を下されていたかはわからない。が、同結果で苦しんでいる私にとって、笑い事にされている事実もまた苦しい。
出演者の方々は、みな大笑いしている。私にはその笑い声が、無遠慮に感じる。笑い声の中には、特に他意を感じさせない純粋な爆笑や、こう笑っておけば無難だろうと置きに行った仕事笑に混じり、突然の高齢数値に思わず驚き、脊髄反射的に笑いを放ってしまったかのような鋭角な響きも認められた。が、相対的には、人間の不健康を指して、概ね悪びれもせず、特に疑問も介さず、軽やかに笑っていた印象が残る。印象とは、私の主観にすぎない。よって事実とは異なるとは思うが、この場では主観を前提とした私見の露呈をご容赦願いたい。
私は、要医療認定されている人間を、軽はずみに笑ってしまって良しとするバラエティ番組の在り方が、怖い。出演者の1人は、それまでゴチレースで連勝していた大杉氏に「そのツケが、今この95才に」(意訳)と言った。不摂生のツケが返ってくる現実には私も覚えがあるが、COPDは(大杉氏がCOPD診断を正式に下されているかは不明)、生活習慣病とはいえ臓器のダメージおよび苦痛を伴う病気である。勝負運や幸運と、気軽に引き換えて良しとする感覚が、私には軽はずみであると感じる。不特定多数の人々に情報を届ける報道機関なら尚更、迂闊である。
そもそも、なぜ、ゴールデン枠のグルメ番組で、肺年齢測定を行ったのか。おそらく、ゲストのアスリートの健康で強靭な心肺をわかりやすく可視化し、不摂生者がいればその対比を、ゲーム感覚で、面白おかしくエンタメ消費する演出だったと推測する。バラエティ番組では、肺年齢だけでなく、骨年齢、血液年齢、体組織年齢などなど、ありとあらゆる心身の年齢測定を行うシーンをよく見かける。その数値が悪ければ、お医者さんや専門家が改善策を伝授したり、後日の治療に密着したり。何かしらのフォローもパッケージしたうえで放送されるパターンが多いが、同番組にはフォローも、肺年齢が指し示す症状の説明もない。ただの楽しいミニゲームコーナーとしてサクッと終了した。
*
放送されないところで、大杉氏を労ったり、内々でフォローすることはあったか。私には知る由もない。番組にも出演者にもそれぞれの都合や仕事、タイミングがある。一方的に非難するつもりは毛頭ない。ただただ「肺年齢95才」の当事者として、切り取られ方と笑われ方があまりにも雑だと感じ、悲しくなったにすぎない。もしも私がCOPDでなければ、肺年齢測定ごとき、テレビではよくやる遊びの一環だろうし、そう目くじらを立てて怒る方がおかしいと思ったかもしれない。
が、病のコアと笑いのコーティングについて思いを馳せる者として、本質を蔑ろにする表層の記号化には迎合できない。もしもバラエティ番組や喜劇やお笑い芸が、世に山積する様々な物事を笑い事にして良いか否か、考える隙なく笑って良しとする免罪符として機能しているようならば、人間の決定と思考と感情を馬鹿にしているという理由より、目くじらに加えて中指を立てて苦情を申し上げたい。
とはいえ、怒るという激しい感情は、さほど湧いてはいない。システムやマスメディアや組織の仕組みは、人間をデリケートに取り扱うようにはできていない。むしろ雑に扱うことによって、全体を無事に運行せんとする。
芸人の外見や年齢や人格を揶揄する(いじる)手法が、より多くの視聴者を笑わせるシステムの一部として組み込まれて久しいが、コアにあるものは侮辱といじめの人権侵害である。いやいや、いじるのは愛で、いじられる方もおいしいから、いじめは成立しないと仰る芸人さんもいるが、それは業界・業態・組織の内部事情の都合であって、外部および視聴者には一切の関係がない。業界の通例があっても、コーティングが笑いであっても、陰湿なコアを擁する以上、そのシステムは陰湿である。しかし、笑いのコーティングの印象が勝り、コアの罪およびシステムの陰湿さを見えなくさせてしまう。
街場では、一括りの集合体(男、女、父、母等)に特定の人格レッテルを与え、その構成員である個人の人格が想定よりはみ出ようものなら即刻、叩く。メディアは、本来ならば説明に100時間を要する言説の表層を「視聴者の理解度」に合わせて掬い、枠や協賛の都合によって大胆に省略してバラエティ消費し、言説者が100時間で説明するまでに要した30年の学びの労力および真意には見向きもしない。
人間の個の尊厳、物事の本質、各人のコアの存在を度外視して運行する大きな仕組みが、私には、ただただ空疎に感じられる。怒るエネルギーも吸い取られてしまうほどの虚無を感じる。私は人間だから、人間が粗末に扱われる様子を見ると悲しくなる。人間は、仕組みの歯車として粗末に扱われるために誕生するわけではない。人間であるために生まれてきたのだ。その個人の権利を奪い、踏みにじって良いシステムなど、人間界に存在して良い道理はない。
*
以上が、超主観による「肺95才事変」にまつわる思案記である。特に落とし所はない。ただの愚痴だ。
最後に、先日TBSテレビで放映された『名医のTHE太鼓判! あなたの呼吸は大丈夫!?肺年齢診断SP』の話題に触れておきたい。この番組では、出演者のお一人である前田吟氏(74才)が「肺年齢81才」と測定され(『ぐるナイ』の岡��氏と一緒)、「実年齢よりも、なんと7才も上だった」と報道する記事も散見された。
実年齢よりも42才も上の肺を持つ私も同番組を拝見していたが、さらに前田氏の肺より年配であるという事実に改めて衝撃を受けた。同時に、密かに進行していた前田氏の病気(睡眠時無呼吸症候群や、自覚なく進行していく肺炎)も詳らかに発覚し、安堵した。病気が見つかったばかりの前田氏に、良かったねと軽口を叩くわけにはいかないが、見つからなければ治療も改善もできないので、ぜひとも健やかに治療を進め、元気に過ごしてほしいと心底願う。あと、前田氏と同肺年齢の岡村氏にも、改めての診断を勝手ながら勧めたい。
本番組では、肺機能の改善対策情報がいくつか紹介された。その中で、思わずテレビの前で真似をしたのが『キャイ〜ン体操』(余談だが、キャイ〜ンとタイプすると、「ー」が「〜」に自動変換されるの、めちゃくちゃ恥ずかしい)。
胸の前で輪を作り、背中を丸めて呼吸する、ヨガの猫のポーズを彷彿とさせる体操である。この、お笑いコンビ『キャイ〜ン』の決めポーズより拝命したわりには、実際は「だいぶ遠い」動作を繰り返しているうちに、『ぐるナイ』も、肺年齢測定の落とし所として、みなさんで『キャイ〜ン体操』およびその他の効果的なストレッチ等を楽しくされていたら、違和を感じたとしても、スルーしていたかもしれないと想像する。
システム上、消費的であっても、コーティングの向こう側に、コアに寄り添う気骨が透けて見える。そんな笑い事が増えたら、社会は少し楽になるのではないかと想像する私は、今日で禁煙277日。
0 notes
Text
第34回JSSA先端芸術音楽創作学会|34th Regular Meeting
日時: 2017年12月16日(土), 17日(日) インターカレッジ・ソニックアーツ・フェスティバルと共催 場所: 昭和音楽大学 南校舎 http://www.tosei-showa-music.ac.jp/access.html
第1セッション 12/16(土) 10:30~12:00
10:30~ IC運営委員長,JSSA会長,ICSAF今年度実行委員長 挨拶
11:00~ 大和比呂志, 三輪眞弘(IAMAS) 多層時間構造による音楽創造の試みとその身体化の可能性 (研究報告)
11:30~ 宮木朝子(東大) フランソワ・ベイルの初期作品における知覚横断的聴取について (研究報告)
第2セッション 12/16(土) 13:30~14:45 インスタレーションセッション
13:30~ 松浦知也, 城一裕(九大) 『Aphysical Unmodeling Instrument』―モデリングから音・音楽を再考するサウンドインスタレーション― (創作ノート)
14:00~ 森崎浩由, 水野みか子(名古屋市大) エンターテイメントとしてのインタラクティブ・インスタレーションの制作実施と評価 (研究報告)
第3セッション 12/17(日) 10:30~12:00
10:30~ 佐藤亜矢子(東京芸大) 韓国での電子音響音楽会議・音楽祭への参加報告 (報告)
11:00~ 谷川穂高, 城一裕, 尾本章(九大) ”おけたー” 聴覚キメラのナラティブによる (創作ノート)
第1セッション
多層時間構造による音楽創造の試みとその身体化の可能性 (研究報告)
大和比呂志, 三輪眞弘(情報科学芸術大学院大学 (IAMAS))
研究報告
本研究は2つの内容を扱っている。一つは2つ以上のテンポを特定の構造で用いた音楽を創造する試みについて扱い、もう一つはそのような音楽作品の聴衆や実演家にとっての実現可能性について扱う。
その背景には、現代の「音楽のリズム」の多くは4拍子、3拍子といった共通の拍子が支配的であり、これは音楽理論やMIDI/DTMといった現在の楽曲制作環境が、理論と環境の両面に於いて西洋音楽における“楽譜”の影響から離れていないからではないかと推測する。しかし、21世紀初頭にアフリカ系アメリカ人ミュージシャンらによって、意図的にリズムに“揺らぎ”や“訛り”といった要素が持ち込まれた。この事は、将来リズムという観点で音楽を捉えた時に一つの分節点になり、西洋音楽における脱調性、ジャズにおけるモードの登場などと並ぶ大きな出来事として捉えられると考える。
そうした背景からこの研究ではリズムに着目している。なぜなら音楽のリズムは「楽譜では捉えきれない多様性」を持っており、今後の音楽の視聴体験を更新する可能性があると考えられるからだ。また、現代において音というメディウムを扱うにあたって、テクノロジーとの関係並びに身体との関係を無視することはできない。本研究では、リズムの多様性を考察し、コンピューター/アルゴリズムといった方法やメソッドから、次の時代の「音楽と身体」における可能性を探求するものである。
フランソワ・ベイルの初期作品における知覚横断的聴取について (研究報告)
宮木朝子(東京大学大学院博士後期課程(超域文化科学専攻表象文化論分野))
研究報告
ブライアン・ケインはその著書『Sound Unseen: Acousmatic Sound in Theory and Practice』(2014)のなかで、新たなアクースマティックの概念についてシェフェール一派のアクースマティックの原義の解釈に対して批判的に検証するとともに、実在する聴覚現象や文学などの例も参照しつつ論じている。そこでは「出所のわからない音=アクースマティックサウンド」が、むしろより多くの連想や推測を引き起こすことが指摘されている。聴覚のみで受容される現象から引き起こされる様々な連想とはいかなるものなのだろうか。
フランソワ・ベイルは2005年の講演のなかで「触感をもった耳で聴く」ことについて述べた。それは耳のみを入口にしつつも、それを受容する知覚の段階でその知覚が横断し、多知覚性を獲得する聴取の様態であり、音を耳の感覚で聴くのみならず、たとえば重力の感覚へ変換して受容するような聴取のあり方ともいえる。このことを、アクースマティック概念における「みることなしに聴く」ことから「みえないものを”知覚横断的に”聴く」ことへの読み替えとして捉えることはできないだろうか。
本発表では、意味や背景といったあらゆる参照項から切り離されていた「抽象的なオブジェ」としての音を、聴覚以外の他の知覚の反応や連想を引き起こしうるメタファーとしての作用をもつ「イマージュの音」として扱ったベイルの初期作品〈Espaces inhabitables (すめない空間) 〉(1967)と〈camera oscura〉(1976)を例に、その知覚横断的な聴取の問題を考察する。
『Aphysical Unmodeling Instrument』―モデリングから音・音楽を再考するサウンドインスタレーション― (創作ノート)
松浦知也、城一裕 (九州大学大学院 芸術工学府)
創作ノート
本稿では、作品「Aphysical Unmodeling Instrument」の制作動機とその構成を説明する。その上で、フィードバックという観点から関連作品との比較を行い、音・音楽を記述するための一形態としての物理モデリングについて考察する。「Aphysical Unmodeling Instrument」は、物理モデリング合成に基づくサウンドインスタレーションである。本作では、一般的には実際の楽器構造やその音色の計算機内での模倣に用いられる本音声合成手法を、実空間内にて展開させている。Cookらによる仮想の楽器である「Whirlwind」というモデルを取り上げ、紙の筒による共鳴器や空気伝播による遅延などの要素からなるその物理的な再実装をおこなった。その上で、本作内で結果的に用いることになったハウリングを、フィードバックという観点から整理し、作曲・サウンドインスタレーション・パフォーマンスに関わる他の関連作品と比較する。以上を踏まえ、モデリングを音・音楽を記述するための一形態として捉え、その中でのモデルの作成と実体化という行為を、楽譜上での作曲と演奏と言う行為と対比し、コンピュータの外側における物理モデリングの可能性を探る。
エンターテイメントとしてのインタラクティブ・インスタレーションの制作実施と評価 (研究報告)
森崎浩由・水野みか子(名古屋市立大学大学院芸術工学研究科)
研究報告
VR技術を用いたアート作品やワークショップなど、体験型の展示コンテンツが広く見られるようになった昨今の社会状況を背景として、本研究では、デジタル・インスタレーション、インタラクティブ・アートの技術をエンターテイメントに応用して作品制作を行い、公共空間と子どもワークショップに設置して、体験者にヒヤリングを行った。 本研究では、インタラクティブ・アートを、体験者の動きに作品が反応するようなものと考え、その原初的モデルとして「楽器」を想定した。そのため、音そのものを楽しむことができるような作品を目指し、また、わかりやすさと手軽さを重視した。 インタラクティブ・インスタレーション作品「Motion scale」では、Webカメラで取得した画像による動体の検知を行い、その情報を元にして画像処理、音響処理を行い、プロジェクターで壁面等の大きな平面に処理された映像を投影すると同時に2chのスピーカーによって生成した音を再生した。さらに、展示場所の特性に依存する体験者層の多彩さに応じた複数の表現方法を制作した。
第3セッション
韓国での電子音響音楽会議・音楽祭への参加報告 (報告)
佐藤亜矢子(東京藝術大学)
報告
2017年10月に光州で開催された韓国電子音響音楽学会の年次大会KEAMSAC、ならびに併催された音楽祭SICMFについての参加報告を行う。両者はいずれも名称にKorea、Seoulとあるが、プログラムは国際的な公募で集まった各国からの参加者による研究発表・作品上演で成り立っている。日本人唯一の参加者として、この一連のイベントについて、筆者が過去に出席したICMC、SMC、WOCMATといった他学会との比較も交えて報告する。
”おけたー” 聴覚キメラのナラティブによる (創作ノート)
谷川穂高、城一裕、尾本章(九��大学芸術工学府)
創作ノート
おけたーは,聴覚キメラという音刺激に着想を得た電子音楽作品であり,アクースマティックで演奏される。聴覚キメラとは,異なる音波形から抽出された包絡成分と微細振動成分を入れ替えて再合成した音である。一般的には,包絡成分と微細振動成分が発話内容の知覚や旋律パターンの知覚に対して,どの程度寄与しているかを調べるために作られた刺激であるが,作者はこの聴覚キメラにある種のナラティブを感じ本制作にあたった。そのナラティブとは,同時並列的共存ではない融合という形での複数の音の共時的なあり方と,キメラの生成の繰り返しによる音響情報というある種の遺伝情報を伴った各世代のキメラを構成できることである。音楽作品には,個々の作品のナラティブがあると考えられるが,本作品では,キメラ音のナラティブを作品内で機能させ,構造的役割を持たせる事とした。キメラ音自体は,中身のない様な,あるいは溶けた様な音かもしれないが,キメラがそのナラティブとともに作品内でどの様に響く事になるのかに耳を傾けたい。音がキメラとなる,それが繰り返される,あるいはキメラとならない,という筋書きの中で音同士が関係性を持つようなお話をアクースマティックで作ることを目指した。
0 notes
Text
X-Jr.コピーライター養成スクール第1話まとめ
要所まとめ
コピーライターの道は 長く険しく厳しい道 6ヶ月でスタートラインに立つ
大きな字で
ベストになる:
と書いてください
やるなら100% やる気が無いなら1mmもやるな
手を抜くな 本気を出せ
嫌だったら行かなくていい 嫌ならやめろ やりたいことを100%やる
Jrコピーライター参加目的
目的はなんでもいい 自分が求めるベストの姿になる 中途半端はしない
6ヶ月ベストを出す
他人と競争しない 自分に勝つ 自分が進化する
自分が求めるベストの姿になるため 100%のちからを使う
ベストを求めた瞬間にベストになれる
1を求めたら1しか手に入らない 100を求めたら100手に入る 何を求めるか
これぐらいでいいと思わない ビジョンを持つ
生活できればいい 収入をプラスしたい という考えを捨てる
会社に良い影響 良いインパクトを与える 子供を救う という大きなビジョンを持ってほしい
自分を超え、他人も超える 大きな意味で社会や世界に向けて よし、こんなインパクトを残すとビジョンを持つ
大きな字で
勝利:
と書いてください
勝負は戦う前に決まっている ストリートの喧嘩でも 勝つ人間は勝つとわかっている
キャッチコピーを書く前に 売上が頭の中で決まっている 頭で売上結果数字が出たら勝利です
Jrコピーライターも 自分の中で目標にした参加人数があった 予想通り、目標に到達した
目標は自分の中で想像できればいい 口外する必要はない
新商品も発売前にブレイクすると 頭の中で決まっている
意識するのは 戦いの前に勝負が決まるということ
コピーを書く前に 頭の中で結果を出す
クライアントから こんなに売れましたありがとうございます という感謝の手紙を受け取るまで想像する
日焼けセミナー 一時的にセミナーに行っても 一ヶ月で元の生活に戻ってしまう
Jrコピーライター養成スクールは 芯から人間が変わる ヘラヘラが変わる
話すこと振る舞い あり方が進化する 6ヶ月で人間が変わる
コピーライターの世界は戦争です 肉体の殺しあいでなく 数字の勝負です
生きるか死ぬか 緊張感を持つ ハンデとか痛いとかやっていけるか
様々なコピーライターがいる コピーライターは最強の戦士 銃で撃たれても前進する
勝利を習慣化する:
と大きな字で書いてください
勝利は習慣です 勝つ人は勝ち続ける 毎日儀式のように勝つ
自分の弱さに勝つ コントロールに勝つ
30年という年月を得て 伝説のコピーライターになる
マインドセット テクニッック システムは効果が決定しているもの
人間心理を理解する方法 見込み客になりきる方法 心に乗り移る方法 人が共感しお金を払う方法 コピーライティングシステムを提供します
最初はホームレスでした 広告費数ヶ月で80万円使い 5本で17ドルしか売れなかった
コピーは生きるか死ぬか アイデアあってもテストしないとわからない
バッターボックスに立っているか 150kmが当たると肋骨や頭蓋骨が骨折する 死ぬ世界です
観客席とリングの違い
戦う人はプレッシャー痛み苦しみ 大きな壁と戦っている もう辞めたい、寿命が縮まる
練習のほうが辛ければいい リングは過酷で辛い
実際にコピーを書いて お金を出して広告を打つ戦場に立つと 一文字に命をかける大切さがわかる
一生懸命稼いで貯金したのを 広告につぎ込む痛み 魂を入れないと売れないと実感した
セールスレターを書くときは 必ず大きなプレッシャーを感じて 痛み苦しみ過酷を感じて書く
己との戦い:
コピーライターは自分との戦い
ピーターティール 戦争したら負け
他人と戦争すると比べることになる 競争すると自分を失う
自分の道を歩く 変わり者クレイジーと言われ 罵倒されても自分の道をしっかり行く
自分が信じることだけをやる
他人と売上や収入反応率を参考にすると 自分の強みを失う
コピーライターの味は ひとりひとり違う
最終的には自分との勝負 真髄は自分の良さ 自分の道を追求する
勝負心は大切です
ただ、本当は心の底で己と勝負して 毎日の鍛錬を重視する姿勢を持つ
他人と比較すると若い人に負ける 強い肉体と精神を持ち継続する
1%向上:
と書いてください
進化を急ぐな 1週間に1%ずつ進化すれば良い
焦るな 急ぐと継続できない
組手は禁止
はじめは型や呼吸法 拳の握り方 声の出し方 柔軟、基礎体力のみ
焦るな基本からやれ
学ぶ順番がある ボレットだけ毎日書き続ける ボレットはコピーのすべての要素が含まれる
即効性はない 病気もマインドセットで治せる 子供でも自分で理解して頑張れる
マインドセットで治す マインドセットで治らない時薬草を煎じて飲む
毎日の習慣
一つセールスレターを写経する 手で書く
100ページを超えるレターでもいい 短い1ページのメールコピーでもいい
心が動いたコピー 購入したコピー 自分がお金を払っていないコピーは意味が無い
写経をしない日でも コピーを読むことはする
Jrコピーライター養成スクールでは、 14年間学んだ方程式を提供する マインドセットからくる方程式
方程式に当てはめると コピーが完成する 大きなお金が動く
すべての結果が予測できる 書き方 各内容のポイント要素を分解して教える
セールスの極意
コピーライティングはセールスです セールスをマスターする
話し言葉でセールスをマスターして 文字を使うセールスに移行する
80対20の法則
大事なものは20で20が80の結果を出している 2割のポイントで何とかなる 全てを完璧にしない
人間の欲望を拡大させて セールスレターに応用する 深層心理の深い話をする
コピーライティングの歴史:
と大きな字で書いてください
歴史を知ると 今と昔の違いを理解することができる
1904年5月にコピーライティングが誕生した 神話や伝説ではなく、実際に記録されている
3人の男 アルバートラスカー ジョンイーケネディ クロードホプキンス
ミーティングで話し合い コピーライティングが誕生した
アルバートラスカーは 18歳で広告代理店に就職し 2年でボスになった セールスが上手く話が匠で説得力があった
しかし、文章で表現することが苦手 クロードホプキンスが文章に変換していた 2人はコピーとは何か広告とは何か答えを探していた
1通のメモがジョンイーケネディから届いた
広告の真髄を教える、今から俺に会え プライドが高く悔しかったが会うことにした
広告の真髄とは
セールスマンをプリントしたものだ セールスマンを文字にしたのが広告だ
この時コピーライティングが誕生した
その後 デビットオグルビィが 追加して
広告はセールスマンをたくさん倍増したものだ
この歴史は 8割の人が知らない テストの概念も知らない
ダイレクトレスポンスの コピーライターは全てテストされる
反応率 コンバージョン
数字が結果の世界 全て科学的メソッドがある
コピーを書く目的はセールスである
お金が何円動いたか お客さんのお金が僕の財布に移動しないと コピーは仕事をしていない
お金を作るのが目的 セールスを完結するのが目的
セールスマン:
と書いてください
セールスマンとは 100年前はプレッシャーセールスだった しつこく買うまで嫌がるまでセールする
現在コピーは プレッシャーをかけれない 対面ではない
紙なので捨てれる
今は広告が氾濫している 100年前は広告ナレしていない
2つのスキル:
大きな字で書いてください
優れたセールスマンになる2つのスキル
1つ目はオープニング 2つ目はクロージング
オープニングはびっくりさせて一気に引き込む クロージングがないとセールスが完結しない
オープニング:
大きな字で書いてください
最強のクロージングがあっても オープニングが無ければ
人を引き込めない 話に入り込めない 人は買わない
最初にオープニングを意識する
Jrコピーライターは80ページのレターだったが オープニングで引きこまれ ストーリーがあって更に引きこまれる
一番大事な秘密
釣りでも釣り人としてではなく 魚になって海に出る
コピーライターは コピーライターになるのではなく
見込み客やお客さんになる
ことを意識する お客さんの気持ちになりきって お客さんと同じ現実を理解する
年収600万円月収50万円にする理由は
お客さんとの現実を常に一致させるため 豪遊して投資するとお客さんの現実が見えない お客さんを見下すと自分が偉い成功者だと思ってしまう
月収25万円で 今月1万円足りないと思う
お金が足りなくて いろいろ悩む状況や気持ちになると 現実が一致する
この気持で書くと 悩んで苦しむ人の気持ちがわかる 共感して読んでもらえる
収入が10%上がっても
生活レベルは変えず 謙虚に質素に暮らす 全部貯金に回す
貯金や資産はあるけど お客さんの気持ちを忘れずにいられる
過去の自分と同じ状況のお客さんに向けて コピーを書き続けれる
長期的に お客さんと同じライ��スタイル 同じ現実で生活するのが
最強のコピーライターの武器になる
余分なお金や余分な収入は 貯金して見えないようにする
俺の収入は25万円といえる
収入は25万円と信じて 25万円で生活する
10年後貯金が増えても マインドセットは変わらない お客さんの気持ちを理解できる
魚になれる お客さんになれる
6ヶ月で 見込み客になることをマスターする トランスコピーライティングの最終奥義に繋がる
コピーライティングは技術で書くのではなく お客さんの気持ちになれるか 見込み客の現実を生きることができるか
2つの説得
1つ目は強制 2つ目は選択
現代社会では強制ではない コピーでは強制できない
お客さんの意志で お金を払って買いますと 自分の意志で選択してもらう以外にはない
他人の気持ちがわかれば 他人から、はいと言ってもらえる
コピーライターのメリット:
と書いてください
メリット1 お金がたくさん稼げる
一生の仕事にできる
報酬が上がる対策
お金で受け取らずアーロンチェアや 大画面モニタとか必要なもので受け取る
初任給600万円ルールを守る 100万円のセミナー行くので 旅費をカバーしてもらうやり方にする
現金で受け取らず 投資スタイルで受け取る
現金で受け取ると 税金で消える
ものも長期的に使うも 共有できるもの 目視で確認できる
働いているアピール 会社に必要とされる 認められる
メリット2 自立できる
自宅オフィスで仕事できる 好きな時間、場所でできる 会社に行っても行かなくても
メリット3 有名になれる
コピーライター業界で有名になれる 反応率高いと言われる 人気が出る
顔が可愛い女性を弟子にできる ファンが増える
メリット4 保証されている
人生が保証される 需要がある 売上を出せる
仕事がなくなることはない
仕事をくださいお願いします 給料を上げてくださいと言わなくてすむ
500万やるから書いてくれと言われても 年間600万超えたらから断る
メリット5 楽しい
毎日刺激がある 脳を使うので大変だが楽しい
休むときは完全休養 働くときは働く コピーライター仲間と談義できる
自分が頑張って書いたものが世にでる お客さんがお金を払ってくれる 書いたコピーの談義ができる
メリット6 趣味の時間をモテる
没頭して一途に生きることは大事です コピーが趣味ではなく 好きな時間や場所で仕事趣味ができる
メリット7 人を救える
経済面、家族に栄養のある美味しいご飯を食べさせれる 子供に教育ができる お金を工面することもできる 光を与えて希望を与えれる 喜ばれ感謝される 救うことができる
最大の壁:
と大きな字で書いてください
お客さんにレターが届くか メールが届くか
素晴らしいボレットやオープニングでも 届かないと意味が無い
メールは スパムに入ったり メールが届かなかったり
一番大事なのは届くこと
次に
どうすれば捨てられないか
メールが届くか メールが開くか が最大の壁になる
子孫に残してもらえるレターを書け:
と書いてください
お客さんがPDFで保存して 印刷してファイルに閉じてくれること ラミネートして金庫に保存してくれる
何回も読まれて 子孫に受け継がれる セールスレターを書く
この使命を持って毎回レターを書く
届くか 捨てられるかではなく 子孫まで残してもらえるか
これ書いたら これぐらいの収入になる 納期から開放されるではなく
マインドセットを切り替え
代々受け継がれるものにする 見込み客に印刷され ラミネートされ金庫に入れられ 永久保存され 子孫まで残されるものにする
2つ目の最強のマインドセット 記事のように見せる
広告に見えたらダメ 何かのレポートや 記事やストーリーに見せる
最強のテクニック:
と書いてください
プレゼントを常に入れる
レターを読むだけで買わなくてもメリットが有る 読んだ人の人生が少しでも向上するようにする プレゼント・ギフト価値あるものを書く
オフラインのコピーは 50%価値を与えている 50%セールスしている
チラシを書くなら 前半50%価値を与え 後半50%セールスを書く
得するテクニックなどを書いて 最後に説明会来てください
トロイの木馬
木馬のギフトを敵に渡して 木馬の中に兵士を忍ばせて 敵の要塞を突破した
セールスレターの場合
セールスレターを商品にする レターをレポートのような感じにする 記事風にする
レターを本や商品の感じにする セールスレターを読むだけで買ったと思わせる
あなたはこれ買いましたよではなく あなたの商品が届きましたという感じで 届くと覚えてないけど買ったかなとなる
届いたものを開けて お金を払ったと思う 読み込むとセールスレターになっている
何らかの商品を渡している感じに 約束のものです
だと
お金を払ったから読まないと もったいないと思う
これがトロイの木馬テクニック
嘘ではない 買いましたや お買い上げありがとうではない
ありがとうございますとか ダウンロードはこちらにする
もっと欲しい人は こちらをクリックして購入してくださいと レターに続ける
最大の壁を超えるため
届かない 捨てられる
乗り越えるためにアイデアを出して テストする
壁を乗り越えるために オープニングが重要になる
オンラインは 90%価値 10%セールス
50ページなら 40ページはテクニック全て公開とかにする 最後の10ページで
もっと詳しく あなただけは セミナーに来てくださいと書く
9割売り込みでなく 9割価値提供になる
引退する方法 進化の方法
のレポートは チェンマイセミナーを売るための セールスレターだった
レポートは なんとかの方法でもいい
最強のマインドセットは
価値ある広告を書く 価値あるセールスレターを書く
エクササイズ:
と書いてください
価値の作り方 オープニング90%の価値を どのように作るか
3つのテクニックを書く
やったこと、これからやること
1つ即効性のあるテクニックを書く
その場でできる 今すぐできること
お客さんがかなり困っていること
アイディアを書き出していく ライバル以上のアイディアを書き出して レターの価値を高める
人生が向上する価値を提供すれば オープニングとして成り立つ 届いて捨てられないトロイの木馬が完成する
結果として 買ってないけど何ですかと言われたら成功
宿題:
と書いてください
1 自分へのコミットメント
自分が戦士として戦場に向かう
2 今回のマインドセットを紙に書く
3×5incのカードなどに 全て書き出して復習する
3 どうすればお客さんに価値を与えれるか考える
価値を提供する
例えば 筋肉を鍛える方法レポートを書く これで記憶力がよくなるレポート
この3つの宿題をやってください
それでは 感じたこと 実践しようと思ったことをシェアしてください
感想の動画を見る: https://youtu.be/kZwXw01rY00?utm_source=042319m&utm_medium=mail
収録の写真を見る: http://i.ytimg.com/vi/kZwXw01rY00/maxresdefault.jpg?utm_source=042319i&utm_medium=mail
X-Jr.コピーライター養成スクールに登録する: http://mof9.com/a/jrcopy?utm_source=042319f&utm_medium=mail
平沼真一
<img src="http://www.google-analytics.com/collect?v=1&tid=UA-91091732-6&cid=201704220800&t=event&ec=email&ea=open&el=201704220800">
0 notes