【読了】「おもしろい」アニメと「つまらない」アニメの見分け方

キネ旬総研エンタメ叢書 「おもしろい」アニメと「つまらない」アニメの見分け方 沼田やすひろ https://www.amazon.co.jp/dp/4873763924/ref=cm_sw_r_tw_dp_U_x_SGnGCbB0BQ3HF

タイトルの主語がとてもでかいがここ最近読んだ中ではトップクラスに自分の心にヒットした本だった。

アニメに対して「おもしろい」と感じるのは人それぞれなわけで、自分のように日常系アニメをあまり面白いと感じられない人もいれば日常系に癒しを求めて面白いと感じる人もいる。

しかしながら魔法少女まどかマギカやジブリ作品などの名作はたしかにおもしろいし、円盤の売り上げや興行収入などから世間的にもおもしろいと思われていることがわかる。自分もまどかマギカは見たが確かに面白く、とても感情移入した。そのような「おもしろいアニメ」はどのような法則の上で成り立っているのかを解説した本

おもしろいアニメとは

この本では面白いアニメを以下のように定義している

  • 一目惚れできるビジュアルをもっていること
  • ミスペンスがあること
  • 言葉の論理骨折がないこと
  • シナリオが13フェイズ構造をしていること

どれも納得させられたので自分の言葉でいかに書きたいと思う

一目惚れできるビジュアル

いわゆる「視聴に値する作画、キャラデザ、世界観をしているか」だと思う。普通、アニメを見るときは最初から作画が崩れていたりあまり可愛くないキャラクターだと多くの視聴者は継続して見ようとは思わないだろう。そのために、アニメは1話でなるべく視聴したいと思わせる絵作りをしないといけない。

簡単な解決策としては、有名なキャラデザの人と優秀なアニメ製作会社でかわいいキャラクターを作ることだと思う。キャラが可愛いとそれだけでかなりの人が視聴を継続してくれる。たとえばまどかマギカではあんなダークなお話なのにキャラデザに蒼樹うめ先生を適用したことで多くの視聴者と引き込んだと思う。

しかしながら脳死で可愛いキャラだけつくっていけばいいという訳ではない。昨今のなろう系や少し前の石鹸枠など、何かヒットした1本を追って、同じような世界観のアニメを生産しても最初の方は受けるかもしれないがだんだん飽きられると思う。著者の言っている一目惚れできるビジュアルとはぱっと見の世界観も含まれている。ぱっと見の世界観でストーリーが想像できてしまってはあまり物語に期待が膨らまない

ミスペンス

この本で言われている「ミスペンス」とは、「ミステリー+サスペンス」である。つまり多少ダークになってもミステリー要素がないと物語を楽しみにくい。まどかマギカの場合はワルプルギスの夜やほむらちゃんの存在がミスペンスで、その解決に視聴者は期待する。

しかしながらミスペンスのない「日常系」もヒットしているといえばヒットしている。なのでミスペンスとビジュアルは両立していないといけない訳ではなく、どちらかがぶっ飛んでよければ売れるのかもしれない。

論理骨折がないこと

これはあまり共感できなかったが、いわゆるキャラクターが話している言葉に論理的に違和感がないかどうからしい。例えばまどかマギカでキュウべぇがいきなり「魔法少女なんてどうでもいい」とか言い始めると、キュウべぇが当初言っていた目的と食い違い、視聴者は混乱する。そのようなことを論理骨折と呼び、論理骨折が起きると視聴者は視聴をする気を無くしてしまう。

論理骨折を起こさないためにはその論理に筋が通るように事前に伏線を貼っておくことが重要だ。ダーリンインザフランキスでは最終回あたりで急激に宇宙対戦になってSNSでは批判がみられたのは、それまで宇宙要素はほとんど視聴者には見せていなかったのに急に最後宇宙がでてきた論理骨折だったのだと思う。(ぼくはダリフラ好きです)

シナリオが13フェイズ構造をしていること

これが一番重要。この本で言われている13フェイズ構造とは以下である。

  • 第一幕
    • 1. 日常
    • 2. 事件
    • 3. 決意
  • 第二幕
    • 4. 苦境
    • 5. 助け
    • 6. 成長
    • 7. 転換
    • 8. 試練
    • 9. 破滅
    • 10. 契機
  • 第三幕
    • 11. 対決
    • 12. 排除
    • 13. 満足

アニメはこの構造でシナリオができていないとたいてい「つまらなく」なる。個人的に重要だと思ったのは3. 決意である。よくアニメで「3話で視聴を判断する」と言われるがこの3話までで主人公に「決意」させることで「目的」が生まれ、視聴者は主人公がその目的を達成するためにどう行動するのかが楽しみにになり、視聴の継続を決意する。3話で視聴をやめてしまうのは主人公に決意をさせなかったせいで目的がわからなくなり、物語を楽しみにならなくなるからだと思う

これらの面白さの成分をまとめてみると、視聴者が視聴をやめてしまうのは以下の法則になると考えた。

1話で視聴をやめてしまうのは一目惚れするビジュアルがなかったから、3話で視聴をやめてしまうのは主人公の目的が理解できなかったから、4〜8話で視聴をやめてしまうのはミスペンスがなかったから、9〜13話で視聴をやめてしまう(円盤を買う決意をしなくなる)のは最終回あたりで論理骨折したから。が多いように思った。

この本を読んでからアニメを見て見ると、アニメを見ていてなぜつまらないと感じるのかがよくわかるようになった。もちろんこの本だけで全てを語ることはできないが、このような解説がある本はなかなかないので良い本に出会えたと思う。アニメが好きな人はぜひ読んで見ることをおすすめする。

AWS ECRを使ってみる

毎回DockerfileをGithubから取ってきてbuildしてrunするのはやっぱりイケけてないのでAWSのコンテナレジストリことECRを使ってみます。

マネジメントコンソールからECRのページに行き、[リポジトリの作成]を押します。

リポジトリ名は***.amazonaws.com/<名前空間>/<リポジトリ名>みたいな感じでつけれます。名前空間はなくても大丈夫なようです。

リポジトリを作成できたら、イメージをpushするためにアカウント認証を行いましょう。awsコマンドはbrew install awscliなどでインストールします。認証をしていない場合はaws configureをしてください。

以下のコマンドでdocker loginできます

$(aws ecr get-login --no-include-email --region ap-northeast-1)

外側をかこっている$()をつけないとただdocker loginのコマンドが表示されるだけなので必ずつけて実行しましょう。リージョンはECRのリポジトリを作ったとこにします。

適当なDockerfileを用意し、ECRのリポジトリにタグをつけてdocker buildを行います。

cd <path-to-dockerfile>/
docker build -t ***.amazonaws.com/garicchi/test-1 ./

docker pushを行います。

docker push ***.amazonaws.com/garicchi/test-1

無事pushできました。


せっかくなのでpullしてみます。

docker pull ****.amazonaws.com/garicchi/test-1

無事pullできました。

docker build時やpush時に長いリポジトリ名を書かなきゃなのは辛いですが普通に簡単に使うことができました。

docker-composeではどうやってpullするのか気になったので調べてみると、aws ecr docker-loginをちゃんとしておくとあとはdocker-composeのimage:タグにレジストリのURLつきでイメージ名を書くと、pullしてくれるようです。

AWS ECR と docker-compose – Qiita https://qiita.com/iwai/items/ec4103890b983039163b

git log ancestry-pathについて

git logの–ancestry-pathオプションがよくわからなかったので調べて見た。

まずこんな感じのコミットログを考える

*   e3b7b68 2019-02-03 togai-r  (HEAD -> master) I
|\
| * 659e5da 2019-02-03 togai-r (br-1) H
| * bcb7e69 2019-02-03 togai-r G
| |\
| | * a8b93fa 2019-02-03 togai-r (br-2) D
| * | 9103739 2019-02-03 togai-r E
| |/
| * 71c4055 2019-02-03 togai-r B
* | 2a3c429 2019-02-03 togai-r F
|/
* 7963add 2019-02-03 togai-r A

ここでgit log –graph –oneline 9103739..e3b7b68を実行すると、以下が出力される。

*   e3b7b68 (HEAD -> master) I
|\
| * 659e5da (br-1) H
| * bcb7e69 G
| * a8b93fa (br-2) D
* 2a3c429 F

git logに<rev1>..<rev2>とrevisionを2つのドットで繋いで範囲にすると、「<rev2>の祖先のログから<rev1>の祖先を減算したログ」を出力する。

ここでgit log –graph –oneline –ancestry-path 9103739..e3b7b68を実行してみよう。

* e3b7b68 (HEAD -> master) I
* 659e5da (br-1) H
* bcb7e69 G

a8b93faと2a3c429コミットがログから消えた。–ancestry-pathをつけていない状態ではa8b93faと2a3c429があったのに、つけるとa8b93faと2a3c429が消えた。この2つのリビジョンの法則性としては2つのドットの前に指定した9103739の子孫ではないということだ。

–ancestry-pathの働きは、「2つのドットの後ろにつけたリビジョンの子孫でないものを削除する」というものになる。

つまり、git log –ancestry-path <rev1>..<rev2>は、「<rev2>の祖先から<rev1>の祖先を削除し、さらに<rev1>の子孫でないものを削除する」意味になる。

これは結果的になにをしているかというと、「<rev1>から<rev2>の間にあるコミットだけ抽出」という結果になる。

2つのリビジョン間にあるコミットだけを抽出したい時、git log –ancestry-path <rev1>..<rev2>は便利に使うことができる。

参考文献

https://stackoverflow.com/questions/36433572/how-does-ancestry-path-work-with-git-log

Macをサーバーにしてjenkins jnlpデーモンを起動させたとき、謎にterminatedになる現象

現象

Macをビルドサーバーとして、Jenkinsのjnlp slaveを起動していたのですが10数分〜1時間ぐらいで接続が切れる。

jnlp slaveはnohupとlaunchdでの起動試したがどちらも接続が切れる

jnlp slaveをフォアグラウンドで起動していると接続は切れない

masterのログをみても以下のようにしかでない

コネクションが切断されました。

<br>
java.nio.channels.ClosedChannelException<br>
	at org.jenkinsci.remoting.protocol.NetworkLayer.onRecvClosed(NetworkLayer.java:154)<br>
	at org.jenkinsci.remoting.protocol.impl.NIONetworkLayer.ready(NIONetworkLayer.java:142)<br>
	at org.jenkinsci.remoting.protocol.IOHub$OnReady.run(IOHub.java:795)<br>
	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)<br>
	at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59)<br>
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)<br>
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)<br>
	at java.lang.Thread.run(Thread.java:748)<br>

slave側のログをみても、「terminated」としか書いてない。

psコマンドでプロセスを見るとプロセスは生きている

原因

ssh接続を切っている間に、Macが自動スリープしていた

Macで画面共有を有効化しているとき、ssh接続をするとスリープモードから自動復旧するらしく、利用者側からはスリープしてるようにみえなかった

Macがスリープするので、プロセスも一時停止する→jnlp接続が切れる

対策

Preferences->省電力->ディスプレイがオフの時にコンピューターをスリープしない

にチェックをいれるだけ

感想

1週間ぐらい悩みました。つらい

Dockerコンテナ内でssh keyを使う

Dockerコンテナでビルドパイプラインなどを作っていると、コンテナ内からgit fetchしたくなります。しかしsshでgit fetchしようとすると、コンテナ内との鍵の管理がめんどうになります。

コンテナ内でssh用の鍵を使う方法としては

  1. コンテナ用の鍵を生成してbuild時にコピーする
  2. ホストの.sshをコンテナにマウントする

の2パターンが考えられます。

1の場合、ホストだけでなくコンテナ用の鍵をいちいち生成しなくてはならず、またGithubなどのdeploykeyに登録をしないといけなくなります。さらにDockerfileがgit管理されている環境ではコンテナ用のprivate keyをリポジトリにコミットしてしまう恐れもあります。

したがって2の場合を考えて行きたいのですが、普通に.sshをコンテナにマウントすると、.ssh/configのownerがホスト側のユーザーになってしまい、コンテナからsshしようとするとpermission errorになってしまいます。

解決策としては、マウント先は一時ファイルに.sshをマウントしておき、コンテナ実行時にコンテナのホームディレクトリにコピーすることで.sshのpermissionが正しくなります。

コンテナ実行時に.sshをコピーするために、ENTRYPOINTは以下のようなシェルスクリプトにします。

あとはdocker run時に.sshを一時ファイルへマウントすればOKです

docker run -v /home/user/.ssh:/tmp/.ssh