ネタバレになりそうな気もするゴジラ キングオブモンスターズ感想

godzilla-movie.jp

うまいこと時間が調整できたので、初日にさっさと見てきた。予告やちらほら流れてくるvsシリーズっぽいというお話に少し胸を踊らせて、19時からの回に。

結論からいうと、これは売れそうだなぁと思った。ハリウッドが作った大娯楽映画。派手なシーンも多く、あのキングギドラやラドン、モスラがこれでもかと動きまくって見せ場も多い。音楽も伊福部昭のあのテーマを盛り込みつつ、面白い仕上がり。監督自身がおそらくほとんどのゴジラ映画は見てるんだろうなぁと思えるオマージュの数々、特撮好きがこぞってどれが元ネタか探そうとするだろう。話のネタとしては申し分ない。これを見るにあたって予習はいらないと思うが、もし数々のオマージュが何かを知っておきたいのであれば、この辺を最低限押さえておくといいんじゃないだろうか。

ゴジラ

ゴジラVSデストロイア

ゴジラVSメカゴジラ

三大怪獣 地球最大の決戦

怪獣大戦争

怪獣総進撃

空の大怪獣　ラドン

モスラ（1961）

ストーリーもまあこういう荒唐無稽さというのは頭を空っぽにしてみる映画としては気にしなくてもいい、と振り切った感じになってるので気にしない人は気にしなさそう。マッドサイエンティストっぽい人たちはそれこそ初代の芹沢博士とか、メカゴジラの逆襲の真船博士とかもいたわけだし、復讐に燃える人と言えばvsスペースゴジラの結城さん*1とかもいたりあまり気にならず。

オルカの扱いなんかは怪獣総進撃の怪獣ランドとか怪獣大戦争のあれとかに近いのかなーとか。それこそ各地に怪獣が出現して暴れ出すというところなんかは、まんま怪獣総進撃でキラアク星人に操られた怪獣が世界各地に現れて破壊を尽くすというところに他ならず。そういや声に反応するネタだと84年のゴジラもそんなんだったなーとか。流石にモナークと環境テロリストそれぞれのザルさはなんなんだろうと思ったりしましたが、モナークがヘリで基地に着陸するところとか、完全にvsメカゴジラだしそういうメカ描写も面白いところはあった。もっとやるなら東宝特撮らしくメーサーとかああいうの出してくれてもいいのよ。

関西に住まうvsシリーズドンピシャ世代としてはエンディングのGodzillaのカバーに嬉しくもあったりした。

読売TV「ゴジラ復活作戦第2号」タイトル

読売ＴＶ「ゴジラ復活作戦」タイトル

vsシリーズっぽいというは確かにそうかと思える。2014年のギャレゴジやシン・ゴジラとは違う手触りでエンタメとしてのゴジラ映画であり、昭和のシリーズやvsシリーズに近い。いわゆる怪獣プロレスを求めている層だとドンピシャなんじゃないだろうか。

---

とかつらつら書いてきたけど、個人的には、最後まで映画にのれなかった。自分自身vsシリーズドンピシャで、昭和シリーズも全部見てきた。要素要素で見ると好きなものもたくさんあり、そういう細かいところをつつく楽しみ方もできてたし、南極でのギドラ登場〜ゴジラとのバトルシーンやラドンのソニックブームなんかもすごかった。

そう映像はすごいものがあった。

すごかったけど、なんか自分にはグッと来なかった。

何がしっくりきてないんだろう？ 見終わってから考えてみたのだが、映画として没入しずらい構成に感じた。序盤の方はそうでもなかったのだが、南極のバトルあたりから全体的な流れを感じずとりあえず見せたいシーンを繋げまくったという印象が残っている。また人が足元にいる中、怪獣たちのバトルが繰り広げられる箇所がやたらと多かった。おそらく物事がシームレスに繋がってるということなんだろうけど、怪獣の取っ組み合いをちゃんと見たいのに度々視点が人の方にいってしまうので、途中で意識が途切れてしまった。あとやたらカメラが近いので、もうちょっと空間を持たせて作ってほしかった。

役者さんたちもいいキャラしてるなーというのが多くていいんだけど、結構な脱落者が出てしまって色々もったいないなーと思ってしまう。そこらへん文化の違いなのかもしれないけど、芹沢博士の重みが薄らいでしまってなんだかなーという気持ちです。

結局のところ、映画としての緩急を感じられなかったのが、自分がのれなかったところなのかなと思う。良くも悪くもずっと高カロリーの油物が立て続けにくる映画。そこに自分はさっぱりとしたサラダ類などがほしかった。そんな気持ちです。

---

ただ来年にはコングとのマッチが控えていて、果たしてどうなるのかという期待は今から持っている。実際に今回のゴジラはかなり評判いいみたいだし、今後も作られていくことになるかもしれない。そうやって火を絶やさないようにはしてほしいと思う。多分見にいっている。

*1:のちにシン・ゴジラで官房長官

二週間ぶりにまた風邪ひきそう

昨日人混み行ったのがあかんかったか……悲しみ。念を飛ばしておく。

【第3類医薬品】南天のど飴U 54錠

THE IDOLM@STER MILLION THE@TER GENERATION 04 (特典なし)

エンジニアのためのデザイン思考入門 を読んだ

エンジニアのためのデザイン思考入門

会社の行き帰りにちまちま読んでいて、またまただいぶ時間がかかった。

デザイン思考ってなんぞやというところから、適当に買ってみたのだが結構面白い話が読めてよかった。東工大でのデザイン思考を実地で学ぶための授業、東工大生のみならず別大学の学生や企業もごちゃ混ぜのワークショップ。そこでの環境づくりや運営方法、ワークショップを進めていくための方法、実際に授業を受けた人のコラムなど、WhyからHow to、感想まで書かれてる。

ユーザーインタビューを通じて共感し、ユーザー自身が気がついてないニーズを見つけていく。繰り返しのプロトタイプ作りでフィードバックをもらい、煮詰めていくというところは割とソフトウェア開発でも聞く話であるので、そうよねとすんなり納得できた。環境づくりにしても、すぐに試せるような場所にしたり雑談できたりと大事にされていることである。

何より多様性やデザイン思考が根底となる文化が大事、共通言語を持つこと、チームメンバーへの信頼感があるようにしていかなければならない点などは、アジャイルやDevOpsなどでも共通する話であるなと思いながら読んでいた。*1実際に文中にアジャイルやソフトウェア開発でのプロセスに言及されているので、そういったものも参照されてるのだろう。

raydive.hatenablog.jp

raydive.hatenablog.jp

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

Effective DevOps ―4本柱による持続可能な組織文化の育て方

DDDなんかでもユビキタス言語をドメインエキスパートとの共通言語としたり、Event Stormingで多数の視点からイベント・コマンドを洗い出すなどの話もあったりする。

raydive.hatenablog.jp

raydive.hatenablog.jp

こういうのはやはり問題解決のためになにをすべきかを考えていくと、自然と似通っていくのかな。

閑話休題。

一方でデザイン思考のみだと、気づいてないニーズとはいえ、根っこの部分は他者に依存しているので全く新しい発想にまでたどり着くのが難しいのかなと感じた。*2コラムにてデザイン思考と合わせてクリティカルデザインという思考についても触れられており、新しい発想に繋がるように思える。

まあそんな感じで、話題の共通点を色々見つけることができて面白かったです。

エンジニアのためのデザイン思考入門

エンジニアのためのデザイン思考入門 [ 東京工業大学エンジニアリングデザインプロジェクト ]

エンジニアのためのデザイン思考入門【電子書籍】[ 角征典 ]

*1:Effective Devopsまだ全部読みきれてない

*2:誰も思いつかない発想を自分が発想するという前提自体が間違ってるのかもしれないが

Mistel BAROCCO MD650Lを自宅用に導入した

Mistel BAROCCO MD650L 分離式 メカニカルキーボード 英語配列 Cherry ML Switch ML1A 採用 アイボリー/グレー MD650L-LUSMGAB1

以前にKinesis Freestyle2を導入して、分割キーボードいいなーとなっていたのだがやはり机のサイズに比べてかなり大きいことが問題で。

raydive.hatenablog.jp

本を広げたりすることを考えるとやっぱりサイズ的には小さい方がいいよなーと、Mistel BAROCCO MD600もチェックし社内で使ってる人に触らせてもらったりしたが、キーボードの高さが微妙。

MiSTEL BAROCCO MD600 分離式 メカニカルキーボード RGBバックライトモデル 英語配列 62キー CHERRY 青軸 ホワイト MD600-CUSPDWWT1

Mistel Barocco Ergonomic Split PBT RGB Mechanical Keyboard with Cherry MX Nature Switches,Black [並行輸入品]

パームレストつければいいのだけど、机のスペースを空けたいのでどうするかしばらく悩んでいたのだけど、ロープロファイルなスイッチを使ったMD650Lがいつの間にかAmazonに売ってるのを発見して思わず買ってしまった。

この文章もMD650Lで書いているのだけど、腕が机で支えられる上に肩をすぼめなくてすむのでとてもいい。姿勢が悪いところはあるので、なるべく背筋を伸ばしてやっているが若干肩の張りがましになったかなぁと思う。何よりスペースが空くので、本を広げたりしながらキーボードを打つことができるのはほんとありがたい。めっちゃいいです。

Domain modelling made functional Chapter3を読む

raydive.hatenablog.jp

続き。

Chapter 3 A Functional Architecture

この章からドメインをソフトウェアアーキテクチャに変換していくところに入る。その前にソフトウェアアーキテクチャ自身もドメインだよねと、用語を定義するためにC4モデルを導入する。C4モデルの自分の理解としてはこんな感じ。

本の例だと、境界付けられたコンテキストとして今着目しているOrder-Taking ContextをDeployableなContainerとして話を進めている。*1境界付けられたコンテキスト間のやり取りにDTOやキューを導入したり、またコンテキスト間の決め事に三パターンあげている。

• Shared Kernel
• Customer/Supplier (Downstream contextが基準作って、upstreamがそれに乗っ取る)
• Conformist (Upstream contextが提供しているものに、downstreamが合わせる)

このコンテキスト間の決め事はエリック・エヴァンスのドメイン駆動設計にも書かれてるが、この本のまとめが端的なので読みやすいかもしれない。外部システムとのやりとりには腐敗防止層もでてくる。ここまではよくあるDDDだが、52ページの"Avoid Domain Events within a Bounded Context"でFunctionalなデザインについて述べられる。さらにはオニオンアーキテクチャまで発展するのだが、この辺り伝統的なレイヤー化アーキテクチャとの比較になっているので、Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)とか読んでると納得度は高そうに思える。

raydive.hatenablog.jp

次の章からF#を使ったFunctionalなアプローチが始まるようなので、楽しみにしておこう。

ひとまずこの辺まで。

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# (English Edition)

Domain Modeling Made FunctionalTackle Software Complexity with Domain-Driven Design and F#【電子書籍】[ Scott Wlaschin ]

*1:前の章でマイクロサービスはちょっと……みたいな論調だったけど、ちょっとそれっぽい気もする。もっと筆者が想定しているよりも粒度が細かいのだろうか？

Domain modelling made functional Chapter1, Chapter 2を読む

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

今Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# (English Edition)という本を読んでいる。自分で理解で端的に書くならば、ドメイン駆動設計をFunctional Programmingに落とし込んでいくためのどう考えるか・どうするか？を述べている本だと思う。今、社内で輪読会が行われていて、これがとても面白いのでちょっとばかり自分の理解のため、忘れたときのために書き残しておく。

全体的にどんな本かは、以下のQiitaに素晴らしいまとめがあるのでこちらを読めば良いと思う。自分も参照しています。

qiita.com

Chapter 1 Introduction Domain-Driven Design

第1章はDDDの大事な大前提をギュギュッとまとめつつ*1、Event Stormingを用いてドメインイベントを洗い出し、ワークフローを浮かび上がらせていこうとしている。

面白いなと思ったのは、エリック・エヴァンスのドメイン駆動設計だとインタビューなどを通してエンティティや値オブジェクトにビジネスロジックを集めようとするが、ここではイベントとそのイベントによって生成されたコマンド、コマンドを入力としてワークフローが駆動され、またイベントが発生し次のコマンドに……という動的な流れそのものに着目しているところ。このあたり自分の納得度が高く、この考え方はいいなと思った。

Event Stormingによってイベントをさらに拡大させ、大きなドメインをサブドメインへ分割する話や境界付けられたコンテキストの発見へと至るのは感動がある。ただどうやって境界付けられたコンテキストを見つけ出すかは、

This is an art, not science

となっていて、この部分機械的に解決はできないのね。難しい。

あと、ユビキタス言語を生きたドキュメントとしてちゃんと残しておくのはいいことだ、と書かれておりモデルと実装を一致させるDDDにおいても、生きたドキュメントは必要だろうと自分は考えていたので、ポイント高い。

Chapter 2 Understanding Domain

第2章からは、ドメインエキスパートへのインタビューでいろんな質問を通して、一つの境界付けられたコンテキストを深掘りしていく。最初に読んでて思ったのは、当たり前ではあるのだが、ドメイン駆動設計の大枠に則って話を具体的に進めているので、Functionalでなくとも参考になる部分が多いなということ。データベース、つまり技術的な詳細に引っ張られないようにする、技術的な言葉ではなく通じる言葉で質問するなど、オブジェクト指向でのDDDでも大事なことだ。

深掘りを経て、新しいユビキタス言語が追加されたり、Event Stormingでは見つからなかった新たな境界付けられたコンテキストを見つけたりした結果が、36ページのワークフローになる。この図を見たとき自分は集約がこれに置き換わったのかなと思ったが、実際にEvent Stormingではワークショップを通して集約などを見つける手法だと後から知ったので、自分の感想はいいところをついていたようだ。

というところでここまで。次はChapter3を読んでいきたい。

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# (English Edition)

Domain Modeling Made FunctionalTackle Software Complexity with Domain-Driven Design and F#【電子書籍】[ Scott Wlaschin ]

koboにもあるんだ……

*1:開発者の仕事とは何かやメンタルモデルの共有の大事さなど

業務システムデザイン勉強会に行ってきた #kyotoui

connpass.com

内容的に面白いものが多く、色々ためになった。ずいぶん前にUXの勉強会で社内システムはそれほどUX考えなくても……なんて話もあったが、いやいやそんなことはないと言える発表が多かったと思う。

どれも面白かったが、アクセシビリティ、エンジニアのための情報設計、視覚言語とUIは骨太の内容。エンジニアのための情報設計はDDDを想起したりしたけど、むしろワークフローやデータをどう取り扱うかの観点から似たような考え方になるのかもしれない。Mackerelを例にした「線」から始まる視覚言語については、実際に目にしているプロダクトであるので説得力のある内容だった。考え方として取り入れていきたいな。*1

メモ

みやすいデザインにするための基礎知識

@883_issan 10分

• 業務系 => 長時間使う、効率に直結
  • 直結
• 視認性
• 可読性
• 明視性
• 誘目性
• 識別性
• 文化圏や人種で違うこともありそうだけど、そこんところどうなんだろうか?
  • いくつかそういうのを書いてるところあるな
  • 例：海外向けサイト制作のヒント。人種・文化による色の見え方の違い。 | コラム | Web制作 株式会社ワンゴジュウゴ WAN55 （東京・千代田区）
• とはいえそこまで幅広く使われることは想定してないのかな

社内システムにおける「使いやすさ」の重要性

@furusin_oriver 10分

• 使いやすいシステム？
  • 起動速い、レスポンスが良い、ぱっと見でわかるUI
  • 個人的に速さは正義だと思ってるので、正しい
• やるたいこととシステムが一対一
  • いろんなコストがかかる
  • 連携できるようにしないと解決しない
• 使いにくさ
  • 社員が働く時間はコストである
  • ここわかってない人多いよね、人が動くのはコストがかかる

アクセシビリティの改善について

ヌーラボ 中川さん 30分

• 詳しい人大事
• エラーメッセージわかりやすくするの、アクセシビリティ問わず大事だよなぁ
• 詳しい内容はブログにまとめられてるので、こっちをみてね（宣伝）
  • はじめようアクセシビリティ改善！Backlogで行っている取り組みをご紹介 | 株式会社ヌーラボ(Nulab inc.)

エンジニアのための情報設計

@tan_go238 20分

• データモデリング手法 RDRA
• 業務システムのUIデザインの難しいところ
  • 取り扱うデータが多彩で大量、登場人物が多く複雑
  • UIデザインするのに情報設計がいる
• ビジネスは定性的、ビジネスとデータの間にデザインがある
• データからデザインを想定
  • なんか余計固定化されそうな気がする
  • ドメインモデルと捉えればそう間違いでもないか
• DDDっぽい香りだけど、DB設計見るのはなんか固定化されそうに思える
• UItとしての統一感あるのは正しい
• 検索設計の仕方はその通り

視覚言語とUI

@takuwolog 15分

• 視覚言語
  • UIなどを構成する最小単位の視覚的に意味を持ったスタイル
  • WebだとCSSでかけるので、そこに意味を込めていく　例：ある線 => form
• 2pxの線はformにのみ使っている
• 点線のform その場で編集できる
• 他色々な視覚言語の組み合わせで、UIが形作られる
• ふわっとしたドキュメントがあるらしい
  • ふわっとしてるのは、新しい視覚言語が追加されたりしてメンテが大変なのでかっちりとはしてないようだ
• 面白い

*1:フロントエンドやってないけど……