はてなキーワード: フェーズとは
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策(不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス)を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能)
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策(不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス)を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能)
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
ツイフェミだかなんだかしらんが方々に噛み付くか底が浅い(とブコメで指摘される)持論が飛び出すインタビューばかりがはてブに上がってくるわけだけど。
この方々の今の活動の先に男女が調和をもってニコニコと手と手を取りあい平等に社会を形成している未来が待っているようには到底思えないわけなのだが。
今は平和のためのやむをえない闘争状態なの?古い価値観とやらが根絶されるまでこの態度なの?悪いのはアップデートされない男と男の味方をする女なの?今の男児・女児は新しい価値観のもと仲良くやっている比率が増えているの?それはフェミニストたちがギャンギャン周りに噛み付いている結果なの?
古い価値観の俺はフェミニスト(と呼ばれるだけの別物かもしれない人たち)の活動を見るたびにだんだん女性が嫌いになるというか仲良くするコストを払うより忌避するほうが楽だなという感情がいや増しているわけなんだけど。
でもそれも輝かしい未来のために必要なんだったら多分価値観のアップデートは難しくてできないだろうけれど嫌われつつ後ろ指差されつつ古い人間として侘しく去っていこうと過渡期に生まれた人間として思えると思うんだ。
だけど現状はそんな未来は見えなくて、今、フェミニストたちの「攻撃」が次々に成功していく先の未来は息苦しさしかなくて。男女が仲良くしている姿がさっぱり見えてこない。
今、CMやポスターや創作キャラの発言に噛み付いている人たちはその行動の先に男女のニコニコがはっきりと浮かんでいるんだろうか。
それともその前段階として、直接的には男女の調和平等とは関係ないけれど邪魔な古い価値観を解体する作業なのか。
解体。そうかも。すでに出来上がった完成品をわざわざ壊すというのは例外はあるけどモノを壊すという単純に嫌な気持ちが生まれる(壊れるのが楽しい部分もあるけど)。逆に平地からモノが作られている過程は楽しくてワクワクするよね。
フェミニストは今はずっと「建設的」作業をしているのではなく、ただただ嫌われる解体作業だけをしているのかしら。
でもまあそれでも今の破壊的なフェミニストが古い価値観をスクラップにしきった後に温和な平和を築くとは見えないよね。
今が攻撃的フェーズであったとしても未来の優しさをチラ見させてくれないと卑屈ないち男としてはどんどん女が嫌いになっちゃってそんな自分にうんざりする。
フェミニストが男と繋ぐための手を差し出すのはいつなんだろうな。
少なくとも今のフェミニストを見るのは苦痛しかないから、成功でもあきらめの妥協でもいいからさっさと男と仲良くする行動を始めてくれって思います。
──「富野由悠季の世界」展を拝見して、富野由悠季監督のキャリアをあらためて振り返っていただくと、ご自身でも言及されているように『機動戦士Vガンダム』以降のお仕事はフェーズが変わったのではないかと感じられます。それまでほぼ毎年のようにオリジナルアニメの新作を手掛けていた富野監督が、新作から数年遠ざかり、久々に発表された作品が『ブレンパワード』でした。ガンダムシリーズから新たな路線に踏み出したのは、何がきっかけだったのでしょうか。
富野:『ガンダム』を20年近くやってきて、はっきりと行き詰まりを感じました。行き詰まりを感じた一番の理由が「ニュータイプ論みたいなものを立ち上げておきながら、それをハウツーとして示すことができなかったこと」です。『ガンダム』をやっているうちに冷戦は終わったのだけれども、じゃあ冷戦が終わったからと言って世界中がまとまっていくかというと、まとまってはいかなかった。具体的に言うと、それぞれ主要国家のトップにいる人物たちが、必ずしもニュータイプ志向を持ってる人ではなかったという現実を突き付けられたからです。それで挫折するしかなかったということです。
だからもう『ガンダム』をやっていられないと思った。あと、『ガンダム』は構造だけで見ると、旧来の戦記物に則っているわけだから、戦記物ができる人や好きな人に任せれば良いと思いました。20年くらいやってきて、戦記物はやっぱり体力的に若くなければできないということもあって、年を取ってから戦記物をフォローしていくには、古代史を扱うような歴史的な学識を持つ必要があるということが分かってきた。そこでどうしようかなと考えたときに『ブレンパワード』に行きついたということがあります。
――今、富野監督は「ニュータイプ論のハウツーが確立しなかった」ことに挫折を感じたとおっしゃいました。富野監督は人々の多くをニュータイプにしたかったということなのでしょうか。
富野:いや、多くの人だけではありません。人類そのものがニュータイプにならないと、これ以後一万年という単位で人類は存続しない、人類を存続させるためには人の革新……というよりも、社会の革新をしなければならないんだと考えています。ですから、総体がニュータイプにならなければいけないということです。
――富野監督はガンダムシリーズでニュータイプを新しい感覚を持つ人類として描いています。劇中では、ときには距離や時間を超えてさまざまなことを感知したり、意思疎通をしたりする。具体的にはどんな人間の到来を期待していたのでしょうか。
富野:それについては、実はこの数年で具体的にニュータイプが現われたということが分かりました。
――なんと…! それはどんな人なのでしょうか。
富野:将棋の藤井聡太竜王とか大谷翔平選手です。将棋も野球の世界も勝負事です。何億通りの手がある中で、藤井竜王は勝つ手を選ぶことができる。僕は将棋のことがまったくわからないけれど、「この人がニュータイプなんだ」ということがわかった。それに気づかせてくれたのは先代の竜王であり、永世七冠である羽生善治さんの言葉です。羽生さんは、藤井竜王のことを「自分があまり見たことのない局面でも対応力というか、適応力みたいなものが高い」と評していまする。天才が、新たに現われた天才のことを評価しているんですよ。
大谷選手は大手術を受けた後でも基本的な身体のケアをつづけ、社会人としての基本としての勉強をつづけています。しかも壁を相手に投球練習は毎日つづけている!! 彼のスポーツマンとしての基礎の積み上げこそニュータイプ的と言えます。時代の移り変わりとともに、レベルの違う才能と人物が出てくるんだと感じられる好例です。ほかにも、工学の部分でも蒙が啓かれるような事例を承知しています。それは電動航空機の開発です。まだ決して大型機ではないのだけれど、それがすでに開発されているということは、僕のような世代にとってはもう腰が抜けるような事例でした(2018年7月、JAXA、航空系企業、電機系企業、経産省が航空機電動化コンソーシアムを設立)。工学や電気関係では、そういうことが起きている。そういう開発者たちは30代や40代だろうと思うけれど、彼らのような人たちに続く若い世代は、さらに違うものを作ってくれるでしょう。
――新しい想像力を持った人たちが、新しい時代を切り開く。富野監督が待ち望んでいたのはそういう方々だったんですね。
富野:藤井聡太竜王や大谷選手を見ていると、ギトギトしていないでしょう(笑)。ギトギトした人間が何億人もいたら、地球が潰れていくんです。ニュータイプにならなければ、地球は保全できないという考え方は、つまりそういうことです。おそらく、あらゆるジャンルの新進、若手の世代はこういう人たちがいるだろうと思います。僕がとくに想定しているのは現代のコロナ禍を経た、現在5歳や6歳の子どもたちです。免疫学的にも、彼らの中からニュータイプが出てくるのではないか。そういうふうに期待をしています。
『ブレンパワード』以降は、「当たり前に暮らすということの重要性を、アニメでもやるべきなんじゃないの?」という思いが大きくなった
――『ブレンパワード』についてもう少しお聞かせください。『ブレンパワード』の制作前は、ニュータイプにたどり着けなかった挫折感があったということですが、その中で富野監督が『ブレンパワード』にたどり着いたのは、どんなことがきっかけになったのでしょうか。
富野:挫折感から、僕は鬱病を患ってしまって、一年近くほとんど外に出られなかったんです。そこからリハビリをしていく中で、何を考えるかというと「なんで人間は鬱になるのか」ということでした。そこでたどり着いた答えは、健全、つまり普通の生活をしないと鬱になってしまうんだということです。それだけのことだと思ったんです。この健全とは何かというと、自分ひとりだけの問題じゃなくて、親子関係、子どもから両親がどう見えているか、周囲の人間関係も含めてのことです。普通であるということ。そういう当たり前の環境を維持するということ、それが人の暮らしにとって一番大事なんだということがわかった。
そのときに企画していた作品のタイトルが『ブレンパワード』だった。ブレーンという言葉を使うことで、知的な方向に行こうと思っていたんだけど、「いや、そうじゃないんだ」と。知的な回路を形成するためには、当たり前の健全な生活をしていないとやっていけないんだとわかった。じゃあ、その最もシンプルな話、つまり親子の関係を正面切ってやってやる、と思ったわけです。それで主人公たちの家庭環境(主人公の伊佐未勇とクインシィ・イッサーの姉弟は、研究者である父母から顧みられなかった)やジョナサン(・グレーン)みたいなキャラクター(優のライバル。ジョナサンは母のアノーアに屈折した愛情を抱いている)ができあがったんです。だから、東京が水浸しになっている、みたいな話がやりたかったというわけではないんです。
――地球の各地が自然災害で荒廃しているという『ブレンパワード』の世界観は、当時としてもインパクトがあったと思います。
富野:なんでああいう設定がいるのかというと、要は「アニメとしてのだまし絵」なんですよね。その設定があったほうが、アニメっぽく見えるから。あくまで技法論にすぎなくて、別に水浸しになった事件を描くわけではない。そうではなくて、ものすごく簡単に言っちゃうと「ママは僕のことを優しく育ててはくれなかった」という親子関係のことをドンとやっちゃうことが、一番良いことなんですよ。そういうものをアニメとして描く中で、もう少しだけ、リアルなものと接触できる作品を作れないかと思っていたんです。
――人間関係の中でも一番シンプルな「親子関係」に焦点を当てることで、普通のこと・健全なものを模索しようとしていたんですね。
富野:先ほどの質問に基づいて言うと、『ガンダム』は旧来のメカもの、戦記物の体裁に則っている部分があるんだけど、『ブレンパワード』以降は基本、心の問題……つまり「当たり前に暮らすということの重要性を、アニメでもやるべきなんじゃないの?」という思いが大きくなっています。僕が「『ガンダム』の富野」だったことで、ずっとそれができなかった。『ガンダム』の後期では自分でプロダクションを立ち上げて、新たな作品に出資しようと考えたこともあったけれど、僕にはそれをするだけの能力がなかった。実務者になれなかったという自分の能力論もあったうえで、スポンサーに理解してもらえるように、永野護くん(メインデザイン)に手伝ってもらったりして、なんとか『ブレンパワード』をかたちにした、ということです。だから、中途半端なところはあると思いつつ、とにかく『ガンダム』から脱出するための作品でもあったとは言えます。
思想や理念があったから、技術者たちを動かすことができた。だから、アニメのことだけを考えていたらダメなんです
――『ブレンパワード』ではメインデザインのいのまたむつみさん、永野護さん、音楽の菅野よう子さんといったベテランだけでなく、脚本の浅川美也さん、カナン・ギモス役の朴璐美さん、のちの『∀ガンダム』ではデザイナーとしてゲーム業界から安田朗さんといった才能を、アニメ作品に起用しています。その背景には、富野監督にとってはどんな思いがあったのでしょうか。
富野:これは『ガンダム』から教えられたことです。僕がやったことではなくて、当時の録音監督(松浦典良)の采配で古谷徹さん(アムロ・レイ役)と池田秀一さん(シャア・アズナブル役)を呼んでくれた。他の声優さんも、声優専門ではない方が多かったんです。そういう人選を見せられていましたから、それこそ20年30年経てば今度は僕がやらなければいけないことだろうと、当たり前のように思えたわけです。それでやってみたというだけのことです。むしろ思ったよりも、それが成功していないという意味では、本当に人を見る目がない、育てる力がないという自覚をしています。
――富野監督作品参加以後も、みなさん大きな活躍をされています。
富野:結局、上手く行っている人たちっていうのは、もともとそういう才能を持っていたんですよ。全部、彼ら彼女たちの力なんです。僕が彼らに刺激を与えたとか、インプットしたという記憶はあんまりありませんね。人を育てるということは、本当に難しいことです。これはわからないんですが、おそらく触っちゃいけないんです。触らないで、出会ったときの関係で、その人の持っているものを見つけだす。それ以上のことをしては絶対にいけないんです。これは実をいうと、愛の問題にもつながってくるんです。
――愛ですか!!
富野:愛し合っちゃうと、一点しか見えなくなるんです。正しく接することができなくなる。その瞬間にとらわれてしまって、相手が今後どうなっていくのかを考えられなくなる。正しい距離感で、この先を考えて相手と正しく接していくものでしょう。ちゃんと愛を育むことが大事なんです。
――そういった愛のお話は教育論にもつながりそうですが、そういった考えは、富野監督はアニメ制作の中でお気づきになり、考えを深めていかれたのでしょうか。
富野:もちろんです。僕は基本的に絵を描けないし、原画や動画を今もチェックしているのですが、腹が立ちますもん。「なんでアニメーターは画が上手なんだろう」「なんで線が綺麗に描けるんだろう」って。しかも、彼らは平気で何十枚も描いてくるんですよ。
――ははは。
富野:でも、そういう優れた技術を持っている人たちがいるから、僕は作品を発表できるのであって、技術を持っている人たちの総代に立つには、技術論ではなくて、理念を持たなければいけないわけです。そういう思想があったから、ここまでやって来られたんでしょう。
――思想があるから、約50年にわたるキャリアで監督として活躍してこられたとおっしゃるわけですね。
富野:思想や理念があったから、技術者たちを動かすことができた。だから、アニメのことだけを考えていたらダメなんですよ。「マンガ絵が好きだからって、マンガが描けると思うな」という考えにもつながります。この話って、何にでも通用するでしょ? 僕が文化功労者のお礼のコメントの中に「アニメのストーリーテリングは万能である」と書いたけれど、そういうことなんです。あれは良い文章になったなと思っています。僕がアニメの制作を通じて描いてきた思想は、どんなものにも通じる。それがあるから作品に公共的な意味が出るんだと思っています。
俺、今地方の自社サービス開発企業に勤めててその中ではテックリード的な立場で、
Saasのシステムを設計フェーズから1から構築したこともあるし、
他にもレガシー目なサービスにDDDやクリーンアーキテクチャ的思想を導入したりTDDの構築と運用へあたっての体制構築や教育を主導したりとか
面接官「うわ。こいつ、実績何もなさそう。面接官受けしそうな言葉ならべてるだけやな・・これ。この人は”面接が”上手い人なんだな。。」
今地方の自社サービス開発企業に勤めててその中ではテックリード的な立場。
Saasのシステムを設計フェーズから1から構築したこともあるし、
他にもレガシー目なサービスにDDDやクリーンアーキテクチャ的思想を導入したりTDDの構築と運用へあたっての体制構築や教育を主導したりとか
メンバーのスキルに偏りがある状態でも品質維持するための体制をなんとか作ったりとか
小さい企業ながら割と経験詰めたし今なら転職とか余裕だよなーって思ったがなかなかうまくいかない。
今のところ3社受けて全部1次面接落ち。受けたのは転職サイトのトップページに一番大きく載ってるような人気企業だから倍率は結構高い気はする。
今のところフルリモートで初年度年収550万~600万くらいを目指してる。多分500万くらいまで水準下げれば求人めっちゃ増えるし余裕な気はする。
あっちからスカウトが来て、競合ではないけど似たようなサービスを俺も構築した経験があったから
御社の製品の○○機能(リリースされたらプレスリリース打つくらいの機能)と似たようなものを営業にほしいと言われてから2日後にはテストカバレッジ率100%の状態でリリースまで持っていきましたとか、
当時はリソース足りず自分一人でほぼ全部対応してたけど爆速でリリースサイクル回して1年で機能数的にも競合製品に負けないくらいまで成長させましたとかこれ以上ないくらいアピールしたよ。
なーにが行けなかったんだろう。やっぱコミュ障なのが影響してんのかなぁ。「えーっとまあ」とか「なんか」「えーーそうですね…」みたいなのが多いのは自覚してる。
フルリモートで給与も高水準だと倍率高いから、もしかしたら20人中の1人や2人採用で第3位だったとかかもしれない。
何をどう変えたらいかなぁ。
転職指南書に書いているようなHPの企業理念読んで面接官が喜びそうなことを事前に作文して頭に叩き込んでおくみたいなことはやりたくないんだよね。
俺会社じゃ面接官する側だけどポートフォリオとか職務経歴しょぼいのに口だけ凄いこといってると
「ああ、この人面接官喜ばすための言葉を事前に作文してきたんだろうなーーー」「この人は”面接が”上手い人なんだな」とかやっぱ内心思っちゃうし
まあ応募して落とされて凹んでまた応募してを繰り返すしかないのかな。
VDI(仮想デスクトップ)代替ソリューションの分類や、それぞれの仕組み、検討ポイントなどを解説する本連
載「テレワーク時代のWeb 分離入門」。 第1 回、第2 回でテレワークと Web 分離の方式の特徴を解説しました。
今回のゴール
用途の観点で各方式を分類すると下図のようになりますが、どんな組織にも共通する「おススメの方式」はあ
りません。
(出典:ネットワンシステムズ)
今回は、読者の皆さんが自組織にマッチする方式を選定できる状態をゴールとして、「結局、 どれを選べばいい
のか」という疑問に回答します。
フローチャートで分かる、
VDI 代替ソリューションの分類や、それぞれの仕組み、検討ポイントなどを解説する連載。最
終回は、VDI 代替ソリューションの方式選定における 4 つのポイントを解説して、各方式を比
較します。
(2021 年03 月04 日)
26 →目次に戻る
これまで多くのユーザーと会話してきた経験から、おおよそのケースで次の4 つのポイントに論点が集約されます。
2. データを処理するマシンがローカルマシンで大丈夫かどうか
これらを基に、方式選定に使えるフローチャートを作ってみました。
(出典:ネットワンシステムズ)
「 ブラウジングだけを安全に実行できればよいのか、それともブラウザ以外のアプリも安全に利用させたいのか」
テレワーク用途では、前者でよければセキュアブラウザ方式に、後者でよければそれ以外の方式にふるい分け
できます。Web 分離用途では、前者が仮想ブラウザ方式、後者がそれ以外の方式となります。
27 →目次に戻る
【ポイント 2】データを処理するマシンがローカルマシンで大丈夫かどうか
次に、「 情報漏えい対策をどこまで強固なものにしたいか」という観点での要件です。
プログラムの実行環境が手元のPC となる場合、データも手元のPC に保存されます。つまり、手元のPC を
「 ディスクを暗号化している、生体認証を有効にしている、だから大丈夫」と言い切れるならいいかもしれません
が、「技術の進歩によって将来的に突破されるかもしれない」といった懸念を払拭(ふっしょく)できない場合、仮
想デスクトップ方式やリモートデスクトップ方式のように、遠隔にあるマシン上で作業できる仕組みを導入する必
要があります。
その一方、将来の懸念よりも、例えばコストなど別の部分を重視したい場合は、会社PC 持ち帰り方式(VPN
なお一般的に、リモートデスクトップ方式とVPN 方式はテレワーク用途のみで導入されますが、仮想 デスクトッ
プ方式とアプリラッピング方式は、テレワークと Web 分離、どちらの用途にも利用できます。
【ポイント 3】データを処理するマシンが物理PC で大丈夫かどうか
【 ポイント 2】で「遠隔にあるマシン上で作業させたい」となった場合は、3 番目の検討事項として、業務継続
性を考えるとよいでしょう。
リモートデスクトップ方式の場合、社内の自席にPC が物理的に存在することが前提です。そのため、自席 PC
一方、仮想デスクトップ方式の場合、マシンが仮想化されており、多くの環境において仮想マシンが動作してい
るサーバ群はn +1 などの方式で冗長化されています。そのため、非常に強い障害耐性があります。
障害耐性を高めたい場合は、仮想デスクトップ方式がベストです。業務が停止するなどのリスクを運用でカバー
できる場合は、リモートデスクトップ方式を選ぶことになるでしょう。
28 →目次に戻る
【 ポイント 2】で「手元のマシン上で作業させてもOK」となった場合、3 番目の検討事項として、再度情報漏
えい対策について考えます。【 ポイント 2】では、PC ごとデータが盗まれてしまった場合を想定しましたが、ここ
手元のPC でプログラムを実行するということは、つまり「端末の脆弱(ぜいじゃく)性を突いたゼロデイ攻撃
を受けるリスクが存在する」ことです。脆弱性を突いた攻撃を受けると、多くの場合、情報を抜き取られてしまい
ます。
従って、例えば VPN 方式を導入する場合、「EDR(Endpoint Detection and Response)で脆弱性攻撃対
策を実装する」「端末のロックダウン化によってデータを保存させない」「実行できるプログラムを制限する」「屋
外の公衆Wi-Fi を利用できないように制限する」「多要素認証を導入する」などの対策を併せて導入する必要が
あります。
このような徹底した対策を継続して運用できる組織に限っては VPN 方式も有効な選択肢ですが、筆者としては
VPN 方式は安価かつ容易に導入できるので、昨今のテレワーク需要が高まる状況では、多くの組織で上記のよ
うな徹底した対策を取らずに導入してしまったと思います。取 り急ぎの暫定処置としてVPN 方式を導入してしまっ
た場合は、これを機に腰を据えて見直してみてはいかがでしょうか。
• 参考リンク:日本経済新聞「在宅時代の落とし穴 国内38 社がVPN で不正接続被害」
また、国内に限った話ではありませんが、Verizon Communications のレポートによると、やはりVPN トラ
フィックが増加傾向にあるようです。VPN 方式の普及に伴って、悪意ある攻撃者による被害数も増加すると思い
ます。
• 参考リンク:Verizon Communications「Verizon Network Report」
29 →目次に戻る
ここまで、要件をベースとした考え方を記載しました。選定すべき方式が大まかに見えてきたところで、ここか
らはそれぞれの方式を横に並べて、共通の項目に沿って比較します。
この比較によって、方式選定の次のステップとなる製品選定において「見落としがちな落とし穴を見つけて対策
を考える」といった検討を具体的に進めることができると思います。
以降の表の見方を説明しておきます。緑塗りのセルがポジティブな内容、赤塗りのセルがネガティブな内容、黄
塗りのセルはどちらともいえない内容です。また、それぞれの表の下部には、主に赤塗りのセルに関する特記事項
なお単純に、緑塗りセルの多い方式が優れているわけではありません。対象業務の内容やコスト、運用体制、セ
キュリティ、業務継続性など、いろいろな観点からトレードオフで方式を選定することになります。
できる作業
(出典:ネットワンシステムズ)
仮想ブラウザ方式とセキュアブラウザ方式では、例えばファイルサーバの操作といった、ブラウザ以外のアプリ
は使えません。多くの場合、Windows の統合認証など Windows に依存する機能も利用でません。
また、印刷に関しても確認が必要です。製品ごとにサポート内容に差が出るポイントなので、方式選定の次の
30 →目次に戻る
(出典:ネットワンシステムズ)
会社PC 持ち帰り方式(VPN 方式)とリモートデスクトップ方式は、端末のアップデート、故障時の交換など、
端末台数が増えるに従って、それに対応できる人員数を確保する必要があるので、運用コストが増大する傾向に
あります。
その半面、仮想デスクトップ方式は初期コストが高額ですが、メンテナンス対象はマスター OS のみであり、仮
VDI の運用ナレッジが豊富なSIer に依頼することで、作業内容の質を落とさずにコストを圧縮できる効果が期
待されます。
(出典:ネットワンシステムズ)
仮想ブラウザ方式やアプリラッピング方式、セキュアブラウザ方式は、「 Web ページが正常に表示されるかどう
か」などの動作確認を、あらかじめ実環境で実施しておく必要があります。この動作確認は、運用フェーズにおい
また、特に仮想ブラウザ方式は、「 ブラウザタブを開き過ぎるとサーバ基盤の負荷が高騰して Web ページの閲
覧速度が急激に低下する」といったサイジング関連のトラブルが発生しやすくなります。
31 →目次に戻る
(出典:ネットワンシステムズ)
マルウェア対策については、会社 PC 持ち帰り方式(VPN 方式)やリモートデスクトップ方式、仮想デスクトッ
プ方式は、EDR やアンチウイルスソフトの導入などが別途必要です。一方、仮想ブラウザ方式やアプリラッピン
グ方式、セキュアブラウザ方式は、「 利用終了後に環境ごとデータを削除する」「 exe 形式のファイルの実行を禁
重要情報の盗聴については、リモートデスクトップ方式や仮想デスクトップ方式、仮想ブラウザ方式(画面転送
型)は、画面転送型なので、暗号化通信が仮に復号されたとしても、実データが盗聴されることはないという強
みがあります。
最後に、不正アクセスについては、多要素認証システムと組み合わせるなどの対策がどの方式でも必要です。
ログインに関わる操作が増えることで利便性は低下しますが、昨今の状況を鑑みると、多要素認証の導入は必須
といえます。
おわりに
これで 3 回にわたる連載は終了です。いかがだったでしょうか。
セキュリティと利便性はトレードオフの関係にありますが、筆者は「仮想デスクトップ方式」と「仮想ブラウザ
仮想デスクトップ方式と仮想ブラウザ方式は、「 導入によってセキュリティレベルを大きく低下させることはな
い」という点が最大のポイントです。その上で、仮想デスクトップ方式には「従来のクライアント OS と同じよう
に利用できる」という汎用(はんよう)性の高さがあり、これが他の方式より優位な点となっています。一方、仮
人間の成長ってそういうもんなのかもしれないなってふと思った。
昔教職を取るときに習った発達心理学か何かでは子供はまずお母さんべったりからスタートする。
その後、お父さんなどほかの家族を探索する。
その次に親が見ている前でほかの子供と遊ぶというフェーズが来る。
そのうち親から離れて遊び、ちょっと不安なことがあると親元に戻ってくるというのを繰り返すとなるらしい。
結局は探索する距離が大きくなり、離れていられる時間が長くなるだけで人間はこれを繰り返しているのかもしれないなと増田の投稿を読んで思った。
https://b.hatena.ne.jp/entry/s/anond.hatelabo.jp/20211210174346
ただし、本件について版元であるサイゲの判断の是非については言及しない。
理由は、広い目で見れば業界全体の問題だとは思うけど、あくまで本件は申請を行ったディーラーの代表と版元の問題だと思うから。
また、おそらく本人もサイゲも本件が騒ぎになるようなことは望んでいないと思う。(あくまで自分の想像だけど)
ここではブクマカの浅い認識を是正するために、版権立体物イベントの当日版権まわりについて解説する。
まず、立体物(フィギュア、ソフビ、ぬいぐるみ、グッズ、など)は同人誌のたぐいとは扱いがまったく異なる。
基本的にアニメや実写作品の立体物の販売は、アマチュアといえど正式な版権を取得してのみ販売されることが一般的であり、これに背いて同人誌のように勝手な判断で販売することは許されない。
同人誌等の二次創作については作品ごとのガイドラインを定めるところも増えてきていると思うが、ここに立体物が含まれることは稀であり、一部中華資本の作品を除いてはほとんどがガイドライン上も勝手な販売は許されていない。
立体界隈の住人はほとんどがこのルールを正しく守っていて、ワンフェスやトレフェスなどの造形イベントに出展されている作品はすべてこのルールに基づいて版権を取得したもの。(作者のオリジナル作品と一部フリー版権を利用した作品はのぞく)
しかし、いくら版権が必要と言っても、アマチュアのディーラーも含めるとそれなりに数がいて、すべての作品を通常の版権手続きの手順で処理するのは不可能であり、版権元にとってもディーラー側にとっても負担が大きい。
だからといって同人誌のような無法状態にするわけにもいかず、解決策として生み出されたのが当日版権システムである。
当日版権についての解説はwikipedia辺りを読んで欲しい。
今回はトレフェスオンラインだがワンフェス、ホビーラウンドも同様に、この当日版権の仕組みに乗っかっている。
いくら手続きが簡略化されているとは言え、版元も許諾を出す以上はそれなりの審査を行う必要がある。
流れ的には、
うちはこの作品のこのキャラをこういう素材や仕様で作りますよ、OKかどうか確認してね、とまず申請を行う。
まず作ること自体がOKかどうか確認してくださいねというフェーズ。
仮申請でOKが出たものについて、ここで初めてディーラーは版元に対してキットの元となる原型の写真、または最近はデジタル原型が多くなってきたのでそのレンダリング画像を送付する。
正面、背面、左側面、右側面、その他アピールポイントまたは付属品等、の計5点の画像が必要となる。
ブコメにキットか完成品が必要だの、3Dモデルがまずいだの、しっぽの位置がわからなかっただのあるけどこれは間違い。
ガレージキットは基本的に原型を複製して作られたキットなので、許諾の審査は原型で行うし、デジタル原型の場合はレンダリング画像でルール上問題ないし、すべての方向から見え方を確認するために多数の画像を送っている。実物を送ることもない。
肝心の原型の完成状態なんだが、基本的には「ほぼ完成状態」のものが求められている。ただここは版元によって基準が結構違くて、ポージングと全体的な衣装の雰囲気だけわかればOKですよのところもあれば、ほぼ完成状態じゃなくちゃ絶対駄目というところもあり、そこは色々。ただしその基準は前もって知らされるものではないし、なるべくそのルールに則って完成状態で臨むべきものとなる。
本申請に基づいて版元がこれで販売してOKまたはNGを審査する。
ここでNGとなればどれだけ制作が進んでいようと、たとえ複製してしまって莫大な費用がかかっていようと販売は許されない。
ちなみにNGだった場合の理由はほぼ明かされない。今回のウマも理由は当のディーラーも知らないと思う。
OKの場合、ここで誓約書の提出が求められるイベントもある。誓約書=正式な契約と見ても問題ないのではと思っている。
当日版権の許諾が降り、販売許可が出たものはイベントで販売するための準備に進むことが出来る。
ここはそのキットの仕様や数量によって異なるんだけど、どんなに安くても数万、大手のディーラーならおそらく数十万の費用が余裕でかかる。
また、その版権元のライセンス形態に基づいて規定の版権料を支払う必要もある。
ちなみに許諾が降りたものについてはなんらかの理由で販売しなかったり、たとえイベントが中止になっても版権料の支払いは発生する。
晴れて許諾が降りた作品についてはこの日そのイベント限りで販売が出来る。
提出物はキットの完成見本の写真だったり、キットそのものだったり、一番きついのは完成品そのものの提出が求められることもある。
そして万が一、制作が間に合わなかった等の理由により許諾が降りた作品のサンプルがここで提出できない事態になると、厳格なペナルティが与えられ、下手するとイベントへの参加が今後永久的にできなくなる。しかもそれはディーラー単位で課されるので、同じディーラーで活動しているメンバー内にそういう人がいるととんでもないとばっちりを受ける。一緒に活動する人は選ばないといけない。しかもそれでも後追いでサンプル提出は求められる。
それだけ厳格なルールに則って版元とディーラーは契約を結んでいるってこと。
新刊落ちましたテヘ。。。みたいな甘い考えは絶対に許されない。
こんな流れ。
それで本件は、3の許諾が一度降りたのだが、5の直前になり急に許諾が取り消されてしまい、4(と原型製作)でかかった莫大な費用がパーというのが泣き所という話。
心情的には非常にディーラー側には同情するし、自分もやってるからこそわかる費用感とか、何よりそれまでの作業の苦労を考えると涙無しには語れない話になってはしまうんだけど、当日版権が非常に脆いシステムで、版元の好意によって成り立っているシステムであることも加味するとなんとも言えない。
サイゲも悪気があって行った行為ではなくて、なんらか事情で急遽発生した不幸な事故みたいなものではないだろうかと推測している。
件のディーラーの人はつらいと思うけど元気を出してまた頑張ってほしい。
あと、肝心のフィギュアの出来が云々言っているブクマカもいるが、原型を監修して許諾したのにキットの完成見本の出来が悪くて直前に許諾取消なんて聞いたこと無いし、それはアマチュアも多くいるこの界隈に対してはあまりにも無慈悲。なのでそれは無いと思われる。
以上。
助け合いも色々種類というかフェーズみたいなものがあると思うけど、「助けを求められないと助けが必要だと気づけない」がやっぱりクリティカルでこういった状況を減らすためには無限に金と時間、そして人材が必要になる。一方でそう言う状況に人を追い込むのは実に簡単。また悪意がなくてもそう言う状況を作ってしまうこともあるのでたちが悪い
ただこの「助け合い」を無料(or ローコスト)でやろうとすると、「助け合うために」と言って自分たちの利益のために他人を蹴落とす行為を正当化するようになったりするので「助け合い」が常に正義というわけでもない。ネトフェミとかにありがち
あつ森でね。
別荘地にカフェ作れって言われて作ったんだけども
完成したらそれまで別荘地に招いた動物から店員を2人選ぶフェーズに入って
俺は、遊んだら面白そうな男や、見た目カッコいいアニキしか招いてなくて困ってしまったよ。
筋肉がどうこういうゴリラや、大学生男子みたいな犬がウェイトレスとか
いや、ないわ。
現実でも、スタバのバイト店員が男しか居なかったら、たぶん敬遠されると思う。
日頃からルッキズム批判やジェンダーレス主張を繰り広げるプロ増田たちは、あつ森やる時も、付き合う動物を見た目や性別で選ぶことなく遊ぶんだろうか。
俺は無理。てかみんな無理だろ。
男女平等社会実現したいマンは、是非ともあつ森をプレイして、己の思想をゲーム上に再現してみてくれ。いろいろ実感わくんじゃねぇのこれ
友達は場所が遠くったりフェーズが変わったりして遊ばなくなっていまいる場所に気軽に遊べるめちゃくちゃ気の合う友達がいないのが鬱の理由なのかな…😭
一人でなんでもできるけど、だれかとやりたい性格なことに最近気づいた
最近はKPOPにハマってるんだけどチームみんなで尊敬しあって活動してる姿をみるといいなぁと思う(すごく大変だろうけど)
それみてると結婚したくなってきた
あああああ 誰か結婚しない…?
尊敬できていろんなこと一緒にできる人がいい
そのほかあると嬉しい条件
手を動かす趣味ある人で、仕事頑張ってて、ゆっくり穏やかに喋る人で、感情の起伏がなくて、ぐちぐちしなくて、できればイケメン、30前後、私のこと溺愛、わたしも好きになれる
むりだ😮💨
難しそう