  |
はてなキーワード: 転送とは
さすがにこれはボったくりすぎ
秋葉原では500GBで5000円切ってる、2TBで1.8万切ってる
エレコム、PlayStation 5向けのヒートシンク搭載PCIe Gen4対応M.2 NVMe SSD
エレコムは1月26日、PlayStation 5への対応をうたったPCIe Gen4対応M.2 NVMe SSD「ESD-IPS」シリーズを発表、1月下旬に販売を開始する。価格は500GBモデルが3万2241円、1TBモデルが4万6376円、2TBモデルが8万4568円だ（いずれも税込み）。
ESD-IPSシリーズ
PCIe Gen 4に対応したM.2 NVMe SSDで、PlayStation 5への装着に適したアルミ製ヒートシンクを標準で搭載しているのが特徴だ。転送速度はPlayStation 5接続時でリード最大6100MB/s。PC接続時でリード最大7200MB/s、ライト最大2500MB/sとなっている。
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【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から見ると単に１つのプロセスが稼働している扱いになる。
【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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
ただし、すぐには渡せないし、今年度来てない先生とかは勘弁してね。
もちろん中身を覗いたりしないよ。
あと授業期間中に送ってくれると嬉しい。
内容証明郵便の件やオープンレターについてはちゃんと読んでないので何の意見もないんだが、大学に非常勤講師のレターケースはない、
手紙を渡すまともな方法はないとかいう言説を見かけて頭に来たので書いている。
私は田舎の私立大学の事務職員で、郵便の受付・整理もやっている。
ていうか非常勤講師宛の手紙とか実際来るが？ 普通に渡しているが？
うちはレターケースがあるのでそこから取ってもらっているし、レターケースがないとして事務文書を渡す手段を作ってない学校とかあるの？
学事暦の連絡とか授業の成績評価依頼とか、事務文書なんかたくさんあって、それらを渡す手段作ってないとかやってられないだろう。
今はコロナ禍ってこともあってメールや郵送での連絡も増えてるけど、メール連絡がメインになったのはここ10年くらいで（早くても15年くら
いだろう）、それより古い大学はそれまでの渡し方があったはず。
本人が大学に来ないと受け取ってもらえないのは確かで、下手すると1か月2か月かかってしまうので、「すぐに何かをやめてくれ」というよう
な連絡をするには向かない。とはいえ、3か月くらい来ないのが確実なら転送するか、他の文書とまとめて本人宛に郵送するけどね。
ていうか、非常勤講師っていうと若い不安定な身分の研究者を思い浮かべるのかもしれないけど、大物や名誉教授も一時的に講義を
担当するという身分としてはまとめて非常勤講師の扱いなんだから、非常勤講師という立場に敬意を払わないとかありえないからね。
そりゃ気に入らない教員もいるけれど、全員を等しく教員として尊重して扱っているよ。
なので、そういう人たちの手紙を勝手に開けるとか、そんなこと絶対しない。書留が来たら（もちろん未開封のまま）事務所の金庫に
しまって本人に連絡して手渡しする。
内容証明郵便は来たことないけど、本人住所に転送をかけるかもしれないし、近々来る予定なら預かるかな。
この程度、田舎の小規模大学でもやってるんだから、都会の大規模校がやってないわけないぞと。
そちらの大学はやってないの？ 本当に？
GPUでもやっているのは知ってるんだが、グラフィックがリアルになるのに動きや物理シミュレーションが気になって仕方ない。
人の表情筋とか、布のシワとか。
レイトレも出来るようになったと言うわりに、違い分からんくらいだし、かといって精度上げると何時間かかるだって状態だし。
デスクトップPCってPCIスロット多いのにGPUが3スロット埋めて終わりで拡張性がない。
物理シミュレーション用の半導体でも出てきて拡張性追加してほしい。
GPUはGPUで、CPUから離れているからメモリを別途積まないといけないわ、メモリ積むから価格は上がるわ、
使ってる電話ってーのが別に事務所のはビジネスホンじゃないいわゆる家電話いわゆらなくてもなんだけど、
これ子機と親機で
なぜかなと思ったら
で、
そこでよ。
問題が発生するんだけど、
これそれぞれのデータを送りあったら上書きされちゃうのかな？問題。
無いデータだけ都合良く追加してくれるのかしら？
まあ試したらいいんだけど
いままで試す時間がなく
このまますごしていた感じよ。
はて？登録したのに名乗らないのはなぜ？って思っていたら、
親機には登録されていない子機だけのデータだと名前を言ってくれないみたいなのね。
たぶん恐らくそう言うことだと思うわ。
今の世の中自動的に何でも調整してくれると思ったんだけど
勝手に調整してくれないのは、
こう言ったなんか昔ながらのテクノロジーの電話なのかしら？って思ったわ。
まあよく分からないけど、
週明けは忙しいんだけど、
電話私苦手なのよね。
はぁ。
まあ弱音を吐いていても仕方ないので
そう言う時はもう出ないに限るわ。
って出なかったら出なかった出また掛かってくるので、
とりあえず
要件があったら、
メール出来てくれた方が助かるんだけど、
どうも困るのよね。
しかも今読んでメールそれ受信していたところだとなおのさらよね。
今見てたつーの！って言っちゃいそうだわ。
なんかもうちょっと電話まわりのテクノロジーがなにかこうもっと電話嫌いな人にも便利になってくれたらいいのになぁーって思うわ。
事務所ついてほっと一息まず入れたいじゃない。
ヒーコーは欠かせないわ。
グレープフルーツ1玉買ってきて
果汁搾って炭酸割りよ！
冷たいけど朝のシュワシュワいいわね。
炭酸も欠かせないわ。
すいすいすいようび～
今日も頑張りましょう！
| 規格名 | 仕様書上の名称 | マーケティング名 | 転送速度 | 形状 | 策定年 |
| USB 3.0 | USB 3.2 Gen1 | SuperSpeed USB | 5Gbps | Type-A Type-B Type-C Micro USB | 2008年 |
| USB 3.1 | USB 3.2 Gen2 | SuperSpeed USB 10Gbps | 10Gbps | Type-A Type-B Type-C Micro USB | 2013年 |
| USB 3.2 | USB 3.2 Gen2×2 | SuperSpeed USB 20Gbps | 20Gbps | Type-C | 2017年 |
見やすいように区切ってみたで。
小林秀雄はそう言われてるの知ってたんだけど。
https://www.youtube.com/watch?v=Fzrr1MIZiFY
なんか知らない人多いな。
そして知の巨人多いな。
AWSとかAzureとかGCPは内部ネットワークはunmeted（無課金）だからつまりクラウド自体の料金も安くなるメリットがあるんだよな。
10MBのファイルを100回ダウンロードするだけで1GBに達してしまうが、VDIなら画面情報の差分を圧縮して送ってるだけなので8時間の勤務で300MBとかですむ。700MBの差で100人社員がいたら1か月の転送量は1.4TBになってクラウドの追加料金がかかる。（たいていクソ高い）
ただし、VDI先のマシンでユーチューブとかにアクセスされると画面情報の差分もふえて転送量が増えてしまうから、URLブロックとかが必要かも。それについても端末に設定するんじゃなくてVDIのマシンに一括設定すればいいだけだから、遠隔設定が不要でラクになる。
このあたりの説明、わかってくれる人はわかってくれると思う。
リクルートにおける VDI の導入、運用、コロナ対応、そして今後の ICT 環境を紹介する連載。
今回は、VDI 導入を振り返り、中長期の PC 環境の構想をお伝えする。
23 →目次に戻る
“ ネットワーク状況によっては使えないシーンがある点 ” は、VDI なら避けられない問題です。特に外出中は、ス
マートフォンによるテザリングで VDI に接続する際に、エリアや移動状況によっては通信環境が安定せず、通信が
切断されたり、通信速度が遅くなったりするなど、VDI がスムーズに動作しないシーンがありました。この課題に
対しては、スマートフォンのテザリング容量の観点なども含めて検討し、対処してきましたが、完全には解決でき
ませんでした。そこで、VDI では業務遂行がどうしても困難なユーザーに限定し、さらに高セキュリティ業務以外
での利用において通常の PC（FAT PC）を配布するようにしました。
もう一つの課題 “ ビデオ会議実施時の不具合 ” については、もともと VDI とビデオ会議の親和性は良くない点
が前提にあります。ビデオ会議の場合、クラウドサービスを使うことが多いと思いますが、通常の PC なら、クラ
ウドサービスと PC 上のビデオ会議ソフトウェアが直接つながり、ユーザーは快適にビデオ会議ができます。一方、
VDI の場合、クラウドサービスと VDI 上のビデオ会議ソフトウェアがまず接続され、その後 VDI から VDI 専用端
末（シンクライアント端末）に音声と動画が転送される形になります。音声も動画もいわば二重でデータ転送さ
れる仕組みなので、劣化してしまうのは避けられません。具体的には、音声が途切れ途切れになったり、動画が
また、システム管理の観点でもデメリットがあります。通常の PC では、ビデオ会議ソフトウェアの機能でクラウ
ドサービスとのネットワーク接続状況をチェックしてくれて、最適に通信する仕組みなのに対し、VDI ではそのよう
な機能は使えません。ビデオ会議ソフトウェアにその機能が搭載されていても、VDI から VDI 専用端末に通信す
る段階でそれらの機能が無効化されてしまうのです。その結果、VDI 上でのビデオ会議は通常よりも多くの通信
量が発生してしまい、外出時などテザリングの容量を圧迫することになっていました。
しかし、最近ではビデオ会議のこうした課題の回避策として、クラウドサービス各社が VDI 用のソフトウェアを
リリースしてくれるようになってきました。VDI 用のビデオ会議ソフトウェアを VDI にインストールして、一部のソ
フトウェアコンポーネントを VDI 専用端末にもインストールします。そうすることで、VDI と VDI 専用端末が協調
してビデオ会議端末として動作し、クラウドサービスと VDI 専用端末とが直接つながる構成になり、従来に比べる
と音声や動画の劣化が大幅に避けられるようになってきています。
24 →目次に戻る
中長期の PC 環境を構想する――“ 中長期 ” という新たな観点の導入
以上をまとめると、いまの VDI 環境では当初想定したメリットは得られたものの、ネットワークとビデオ会議に
おいてそれぞれの課題があります。ネットワークの課題は、一部ユーザーに FAT PC を配布することで、ビデオ会
議の課題については VDI 用のビデオ会議ソフトウェアをインストールすることで解決できます。いまの VDI 環境
を評価するマトリクスを作って検討してみると、VDI 用のビデオ会議ソフトウェアがうまく動作すれば、VDI 環境
をそのまま継続するのが妥当なように見えました。とはいえ、そのような “ カイゼン策 ” を施しながら、VDI をい
まの形のまま続けるべきなのでしょうか。そして、そのような思考プロセスに本当に問題はないのでしょうか――。
われわれは検討時に、新たな視点を導入することにしました。それは “ 中長期 ” 視点です。2015 年においては、
3 つの課題という、“ いま、ここ ” における課題に対する解決策として VDI を採用したものの、今後長きにわたっ
て会社を支えていくPC 環境を構想するに当たり、それだけでは不十分ではないかと考えました。リクルートは創
業から 60 年以上がたちました。今後も長きにわたり、カスタマーやクライアントの皆さんのためにより良いサービ
スを提供し続けることになるでしょう。それには短期的な視点だけではなく、中長期でのあるべき PC 環境を描い
て、それに向かっていまどうすべきかを考えなければならないと思ったのです。
そのためには、まず働き方が将来的にどうなるかを想定しなければなりません。次期 PC 環境を検討していたの
はコロナ禍前でしたが、ゆくゆくは「完全に場所を選ばない働き方」になるだろうと予想していました。キーワード
で示すならば、「Anytime/Anywhere/Securely/Work Digitally」という表現になるでしょうか。そのような働き方
を実現する PC 環境については、既にいわれて久しいですが、クラウド中心の方向性は変わらないでしょう。加えて、
今後は多種多様なデバイスが出現すると想定しました。いまは PC や VDI が中心であり、補助的にスマートフォンが
使われているというのがビジネスにおける PC 環境の実情だと考えます。では、今後はどうなるのか――。
スマートフォン中心になるという見方もありますが、学校では情報教育が進みノート型の端末が支給されており、
家庭においてはスマートスピーカーが広まり、AR/VR（拡張現実／仮想現実）もゲームなどを中心に広がってき
ています。また、企業では製造業などで AR/VR が使われる事例も出てきており、IoT デバイスもいろいろなユー
スケースが生まれてきました。
そう考えると、ユーザーが使う端末は、どれかの端末に収束していくのではなく、2in1 あるいはクラムシェル型
などの PC、スマートフォン／タブレット、AR/VR デバイス、スマートスピーカー、IoT などいろいろなデバイスを
使いこなしていく世界になるのではないかと考えます。業務のさまざまな場面で、いろいろなデバイスの中から最
適なものを選び、さまざまなクラウドサービスを使いこなし業務をしているイメージです。それらを使うことで、場
所を選ばず、どこにいても対面同様のコラボレーションができるでしょう。さらには、AI（人工知能）技術などを
活用しながらユーザーの業務を支援するなどして、高い生産性を生み出すことができる環境になっていくのではな
25 →目次に戻る
中長期視点で考え、いま行動する――「クラウド＆マルチデバイス環境」へ
われわれは、このような環境を「クラウド＆マルチデバイス環境」と呼ぶことにしました。中長期的には「クラ
ウド＆マルチデバイス環境」になるとして、VDI の EOSL 契機に対応しなければならないわれわれの次の PC 環
境はどのように整えたらいいのでしょうか。
大事なのは、「中長期視点で考え、いま行動する」ことです。中長期視点だけを考えれば、一気に「クラウド＆
マルチデバイス環境」にすべきでしょう。ところが、われわれの環境内にはまだレガシーシステムが残っており、一
気にクラウドだけを利用する業務形態に変えるのは困難でした。また、検討した結果、現時点では VDI に勝るよ
うなセキュリティ確保の仕組みは見当たりませんでした。そのため、情報資産の囲い込みができるという点で、高
セキュリティ環境に対しては継続して VDI を活用することにしました。
セキュアな環境以外の用途においては、“ いま ” のことだけを考えれば、ビデオ会議の部分のみを改善して VDI
環境のまま、次期 PC 環境を作る方向もあり得ました。しかし、それでは今後の PC 環境が VDI に固定化されて
しまうことになります。VDI 環境をいままでと同様にオンプレミスで作るには、初期に大きな設備投資が必要とな
り、また一度構築してしまうと使い捨てるわけにもいかず、それをしばらく運用し続ける必要があります。今後い
ろいろなクラウドサービスやデバイスが出現すると、活用したいと思う方も多いでしょうが、既に VDI を使ってい
る場合、VDI の代わりに別のものをすぐに使うということはなかなかできません。そういう意味で、PC 環境が固
定化されてしまうことになるのです。
中長期の環境に一気に切り替える方針でもなければ、現在のことだけ考える方針でもなく、「中長期視点で考え、
いま行動する」方針で検討した結果、次期 PC 環境は「クラウド＆マルチデバイス環境」を目指すための第一歩
と位置付け、「VDI と FAT PC のマルチ環境」を構築することに決定しました。先述した通り、レガシーシステム
が存在し VDI 以上に情報の囲い込みができるソリューションがない中で、VDI から離れ、一気に中長期的な将来
像を目指すのは困難です。とはいえ「将来像に向けた環境をいま作るべき」と考え、VDI と FAT を業務特性に応
じてユーザーに配布するマルチ環境に刷新することにしました。つまり、高セキュリティ業務ユーザー向けにはセ
キュリティを確保した「セキュア VDI」、それ以外の一般ユーザー向けには FAT PC を配布することにしたのです。
将来的にはマルチデバイスといっても、いまだ PC がメインなので、まずは PC を配布し、その上で今後 AR/VR
デバイスといった他のデバイスも検討していきたいと考えています。
なお、VDI 環境としてはもう一つ、機能更新がない固定的な OS を必要とするレガシーアプリ向けの環境も VDI
で用意することにしました。用途が限定されていることから、社内では「特定用途 VDI」と呼んでいます。
26 →目次に戻る
以上をまとめますと、働き方は中長期的に「完全に場所を選ばない働き方」へと変わり、それに応じて PC 環
境は「クラウド＆マルチデバイス環境」になっていくでしょう。われわれも VDI の EOSL のタイミングで変わって
いかなければならず、将来に向けた第一歩として、次期 PC 環境は「VDI と FAT PC のマルチ環境」を実現する
ことにした、ということになります。
なお、コロナ禍において、われわれは現在の VDI 環境下でビデオ会議の改善を試みました。先述した VDI 用
のビデオ会議ソフトウェアの導入を検討し、一部導入したのです。その結果、ビデオ会議の音声と動画の品質が
極めて改善されることになったものの、2 つの課題が新たに見つかったのです。
1 つ目は、普通のビデオ会議ソフトウェアと VDI 用のソフトウェアとの間に機能差があった点です。この課題は
今後解消されるかもしれませんが、われわれが導入した段階では VDI 用のソフトウェアが機能面で劣っていました。
2 つ目は、導入／管理コストです。1 つのビデオ会議システムしか使っていない場合は問題ないかもしれません
が、複数使っていたり、今後新しいシステムの導入を考えようとしたりすると、ソフトウェアの導入、管理に都度
以上 2 点については、いま検討されている方のご参考になれば幸いです。次回は、リクルートがいままさに取り
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 と同じよう
に利用できる」という汎用（はんよう）性の高さがあり、これが他の方式より優位な点となっています。一方、仮
想ブラウザ方式は、用途が限定されるものの、ユーザーにとっては利便性が高く、初期コストの観点では仮想デス
ビジネスや教育現場において、ときには1000台以上のパソコン端末を管理しなくてはならないケースがあります。この際、各端末を一元管理するために用いられるのが「ネットワークブート（＝ネットブート）」です。
今回は、大学や専門学校などの教育現場にも採用されることが多い一元管理システム「ネットワークブート」の概要と導入するメリットについて紹介します。
通常、コンピューターを使用するためにはWindowsやmacOSなどのオペレーティングシステム（OS）を各端末に導入する必要があります。これに対して、情報処理のほとんどをサーバーで行い、ユーザーが操作する端末自体の処理を必要最小限にする運用方法を「シンクライアント」といいます。「ネットワークブート」はシンクライアントの方式の1種であり、構築したネットワークを通じて、サーバーからOSなどの情報を取得して起動するシステムのことです。原則、ログイン情報を打ち込むだけでネットワーク内のどの端末からでも、アプリやファイルなどの環境を再現できるため、パソコン教室に設置するデスクトップパソコンなど不特定多数が使う環境に適しており、教育機関に採用されやすい理由の1つです。
ネットワークブートと同じ意味で使われることが多い「ネットブート（Net Boot）」ですが、厳密にはネットブートはmacOSの機能の1つで、macOS Serverからの指示によって構築したネットワーク上のMacを起動・操作するシステムのことです。
この機能によって遠隔からのソフトウェアのインストールなども行えます。
ネットワークブート型と比較されることが多いシンクライアント方式の1つです。仮想環境に作成したデスクトップ環境をネットワーク環境下の各端末に転送して操作する方法で、ネットワークブート型よりもカスタマイズ性が高いことが特長です。また、ネットワークブート型よりも少ないリソースで運用が可能である一方、サーバー上で処理しなければならないのでサーバーの負荷やライセンス料が増大する傾向があります。
教育機関での利用においては、基本的に生徒は全員同じ環境で授業を受けたり、作業したりする可能性が高いため、VDI型の高いカスタマイズ性は必要ないケースが多く、ネットワークブート型が採用されることが多いです。
シンクライアントソリューションである「ネットワークブート」は、データなどをサーバー側で一元管理できるので、活用することでセキュリティ面や管理の効率化などに大きなメリットを得られます。
パフォーマンスが高い
端末側のCPU・メモリで実行するので、導入したiMacなどの性能を十分に活用できます。ネットワーク環境のPC台数が増えても、高速ブートが可能なので高いパフォーマンスが期待できます。
インストールするアプリケーションや端末側で利用する周辺機器に、原則、制限がなく使い勝手が良いのもネットワークブートのメリットです。「ローカルディスクがないPC」という感覚で利用できます。
管理が容易
詳細は導入先やシステムによって異なりますが、ネットワークブートと運用管理システムを組み合わせて一元管理することで、各端末の状態を簡単に把握できるほか、ログの採取、サーバー設定・更新の自動反映などが可能になります。これにより、少数の担当者でも運用管理が容易になるでしょう。
セキュリティの向上
近年、ネットブートが注目されている理由の1つが、セキュリティ性が高いことが挙げられます。各端末のデータはサーバーで管理するため、ユーザーが利用する端末にはデータは残りません。このため、データの流出などを未然に防ぐことができます。
これらのメリットに加えて、教育現場ではクラス替えなどがあって従来とは違う端末を生徒が使うケースでも問題なく、同じ環境で利用することができるほか、必要台数分の有料アプリケーションなどを購入すれば良いので、全生徒分のライセンス料などを払わなくて良いといった特長もあります。
ネットブート環境を構築するためには、導入先の独自のシステムとの連携や構築方法をしっかりと把握して仕様書にまとめる必要があります。規模によっては検討から運用供給まで1～2年かかるケースもあるので、ネットブート環境の構築の豊富な実績と経験がある業者選びが重要になります。三谷商事は1000台以上の大規模ネットブートを構築するなど、教育機関への導入実績を長年にわたって積み重ねています。大学や高等専門学校への導入事例をまとめているので興味のある方は確認してください。
※関連ページ：導入事例
通勤電車に揺られるあなた。紫煙を眺めて貴重な休憩時間を浪費するあなた。コロナ前から巣ごもり派のあなた。「少年ジャンプ＋」はいかがでしょう。
「ハイパーインフレーション」の精子もとい製紙法お勉強回、最高でしたね。「ゲーミングお嬢様」のウマ娘回は腹がよじれて死ぬかと思いました！
ただ、悲しいかな、連載作品は時間やコインの閲覧制限があり、過去回をストレスなく好きな時に楽しむことはできません。
そこでオススメしたいのが読み切り作品群。ジャンプ＋の読み切りがはてなブックマークを賑わせるようになって久しいですが、その数じつに900件以上！
お気に入りの読み切り作品は、原則、好きな時に何度でも無料で読み返せます。
（藤本タツキ先生の「ルックバック」やへじていと先生の作品群等、例外はありますが。。）
あまりに読み切り作品が多すぎて、はてブを盛り上げた作品もあれば、時流に乗らずただ通り過ぎていった作品もあります。
今日はせっかくですので、読み切り作品のほぼ全てを読んだ私が「この作品を語りたい」だけを基準にいくつか作品を紹介します。
※はてなブックマーク数は2021年12月30日12時現在。作品ごとにリンクを貼ったところ、SPAM扱いされたので解除しました。申し訳ない。
これぞ若さ。これぞジャズ。作中のセリフをもじった読者コメント「拗らせた中学生みたいなマンガの才能」に尽きます。
悩める主人公が、学生特有の沼のような人間関係に沈む一方でジャズとの出会いが並行して進み、ハレの舞台で全てを解放する。
主人公の表情の機微や光の当て方、仕草、小道具の一つ一つに張り巡らされた作者の意図は、練り込まれた展開と相まって唯一無二。
感情の流れや勢いを感じる演出力、もっといえば「説得力」が異様に高い。１点、画力は明確な弱点「ではありません」。
蛇足：最近、絵が「綺麗」ではない人の作品を見るにつけ、すぐに「画力をつけろ」「原作側に回れ」という人がいて、気になっています。実際、その方が向いているケースもあるとは思いますが、少なくともこの作品に関しては、明らかに絵柄も含めて漫画として完成しています。例えば施川ユウキ先生の「鬱ごはん」を真鍋昌平先生が描いたらどうなりますか。日本の自殺者数を増やして何が楽しいんですか。画力はリアリティの演出（説得力）であって、「鬱ごはん」で語られるような、日々の生活に潜む不安やアンニュイな微かな感情は、あの絵柄でソフトに描き出すことで、ほのかな共感を得られるのだと思います。商業（万人受け）を念頭に置かなければならない編集部が「画力」を望むなら、アニメ化するなり実写化するなり、別媒体での展開を考えればよかった。one先生の「モブサイコ100」はその好事例では。あと、エントリーページが3つに分かれているせいで、見事にはてなブックマークやらの登録先が分かれてしまっています。せっかくの名作なのに、編集部が下手。
はてなブックマーク数：522
世のすべての名作はジャンプ編集部に集う。そう思わされるのに十分なインパクトををもった作品でした。
激烈なバトルシーンや感情の爆発があるわけではない。ただ、ストーリーが緩やかに進み、迎えるべき結末を迎え、静かに、祈るように幕を下ろす。
主人公たちの考え方や感情が少しずつ入れ替わる様子の演出も見事。最後のカラーページとモノローグは、どこか心の隅を掴んで、いつまでも放してくれません。
蛇足：この手の作品は、これまで「アフタヌーン四季賞」に集まっていたような気がします。ジャンプ＋のように毎日追加とまではいきませんが、定期的に良い作品を読むことができます。鏡ハルカ先生の「手指の鬼」や山素先生の「時間跳躍式完全無劣化転送装置」が私のオススメです。みんな読もうね！
はてなブックマーク数：21
レトロフューチャーなディストピアSF。あるいは家族愛を描いた、始まりの物語。
掲載日が2017年1月1日と5年前だったこともあって、覚えている方は少ないかもしれません。
書き込まれた背景や装置はもちろん、キャラクターの豊かな表情、特に作者の特徴が出る口元が私は好きです。
最後の終わり方がまたニクい。この家族に幸あれ。そう思わずにはいられません。
蛇足：作者である森屋シロさんはその後、「檻ノ中のソリスト」を連載されています。単行本？もちろん買いました！途中、2年間の休載を挟まれた際は続きがもとい作者の体調が気が気でありませんでした。無事に完結させてくださったことに感謝の念しかありません。休載といえば、山本章一先生の「堕天作戦」とさかめがね先生の「憂鬱くんとサキュバスさん」はいつまでも待っています。待っていますから・・・！
はてなブックマーク数：211
除霊を描いたホラー作品、ではなく主人公の成長を描いた王道バトル作品。第２話はどこですか・・・？
丁寧に積み重ねた主人公の生きづらさを一気に吹き飛ばすカタルシス。こんなに格好良い失禁シーンを見たことがない。
対化物のバトルものは昔からあるのに、ちょっとした設定やエピソードでこんなにユニークに仕上がるのかと純粋に驚きました。
あと、個人的に祓沢さんのキャラクターが好きです。デザインも性格も、不器用にバットを振り回す姿も。
蛇足：ホラー系作品といえば、マンガワン（裏サンデー）が豊作です。先に紹介したモブサイコ100はもちろん、田口 翔太郎先生の「裏バイト：逃亡禁止」や、えろき先生・コノシロしんこ先生の「うしろの正面カムイさん」など、オリジナリティあふれる佳作が次々に登場しています。他の媒体では泉朝樹先生の「見える子ちゃん」も好きです。あれ、私がホラー系作品が好きなだけ・・・？
はてなブックマーク数：248
拙者、ラブコメ大好き侍。義によって助太刀致す。ご都合主義？ 切り捨て御免！
真面目で消極的な主人公と、表情豊かで快活なヒロインの掛け合いは、ニヤけずにはいられません。
ヒロインが主人公に近づいた目的をあれこれ想像させての見開き（p38）は、十分な説得力がありました。
ヒロインの魅力度やラブコメとしての完成度が群を抜いています。こういうのでいいんだよ。
蛇足：私が初めて心を動かされた読み切り作品は、2004年頃に妹が買った「りぼん」に掲載されていた、おおいま奏都先生の「恋してハニー」でした。快活な主人公が生むドタバタはもちろん、当時のりぼん作品では群を抜いて絵も話も上手かった。特に柔らかなスクリーントーンの使い方は感動ものでした。今でも十分に通用するクオリティだと思います。ちなみに私が初めて買った単行本は、当該作品が掲載された単行本「たたかえ！ハニー」でした。最近、そのことを思い出して電子書籍を購入しましたが、肝心要のスクリーントーンがスキャンで完全に潰れてしまっていました。ですのでみなさん、紙の単行本を買いましょう！
はてなブックマーク数：646
腐女子の怨念、ここに極まれり。隅から隅までギャグの息遣いを感じます。p38はみな同じ思いでしょう！
大石浩二先生の作品「トマトイプーのリコピン」に突如掲載された読み切り作品。存在自体がギャグであると同時に、単品での完成度が高い！
はてなブックマーク数：269
ハードボイルドかと思いきや、炸裂するシュール系ギャグがたまりません。コメディ、で良いんですよね・・・？
はてなブックマーク数：184
はてなブックマーク数：148
下ネタ系ファンタジーコメディ。魔法少女はどこの世界も受難続きですね・・・。
はてなブックマーク数：87
はてなブックマーク数：56
SFミステリー作品。随所に差し込まれた小粋なユーモアもたまりません。
はてなブックマーク数：682
誰がなんと言おうとSF作品。これほど的外れな編集部コメントも珍しい。最後の安堵感は、いろいろな作品に触れた大人でなければ味わえないものなのでしょう。
はてなブックマーク数：1
読者コメントにあるとおり「美少女に頼らないキャラ設定」が良い。続きが読みたくなる作品です。
はてなブックマーク数：2
ファンタジー設定はもちろん、どこか抜けたところのあるヒロインの造形や性格が素敵です。
はてなブックマーク数：6
不思議なお姉さんは時代を超えて愛されます。特徴的な絵柄も相まって、不思議な読後感のある作品です。
読み切りには連載では味わえない、単発ならではの魅力があります。
仮想システムを構築するにあたり、CIFS しか使えない NAS をバックアップ用に選定してきた SI 屋さんが居たので、CIFS と iSCSI のどちらが早いのか、試してみました。
テストに使う NAS は QNAP の Turbo NAS TS110
http://www.tekwind.co.jp/products/entry_6719.php
です。もう６年以上愛用して、カビが生えてもおかしく無い程に古いし, Marvell 800Mhz という低スペックな Qnap NASです。 100Mbps 時代のモノです。
昨年、HDDがお亡くなりになったので、3Tb の HDD に交換しました。ファームウェアはこんなに古い機械でも、QNAP シリーズの最新バージョンが利用できます。
iSCSI は、今あまり見なくなりましたが SCSI ケーブル規格や、SASケーブル接続のハードディスクを、一般的なIPネットワークで規格で仮想化したものです。
マウントするホストシステム側は iSCSI initiator, ディスクストレージの機能を提供する側を iSCSI Target と呼びます。
ホストから「マウントするしない」はイニシエータ側のソフトウェア的な操作で行います。これは便利な機能で、ディスクの故障などで、一時的に物理的に取り外さなければいけない場合でも、ホストからの操作だけで実際のケーブル結線の脱着を行う必要がないので、今時での SAS の外付けディスクドライブの様に、ホストもシャットダウンして電源を切り、結線を外して修理、交換する、という必要がないので、ディスクデバイスの修理をホストの電源を止めないで実施できると言う、実に便利な事ができます。
という事で、仮想環境では実に使いやすいストレージデバイスなのです。
マウントするホスト側から見ると単純に SCSI/SAS のハードディスクに過ぎません。iSCSI のストレージをマウントしてからは、通常の増設ディスクの様にフォーマットして、ホスト側で使う一般的な XFS, ext4, NTFS などのフォーマットでフォーマットする必要があります。
Linux の iSCSI ターゲット側からは、内部にターゲットとして使う「巨大なファイル」が、どん！ とあるだけです。この巨大ファイルを、イニシエータ側に仮想ディスクイメージとして提供しています。当然シンプルな仮想イメージなので、ファイルそのものをバックアップコピーすれば、ストレージのイメージそのもののバックアップができます。
※ qnap NAS の場合、iSCSI イメージは、 /share/HDx_DATA/.@iscsi.img の下にドンと作られるようです。
[Solved]How to mount iSCSI file?
https://forum.qnap.com/viewtopic.php?f=180&t=25322
[/share/HDA_DATA/.@iscsi.img] # pwd
[/share/HDA_DATA/.@iscsi.img] #
[/share/HDA_DATA/.@iscsi.img] # ls -l
-rw------- 1 admin administ 6442450944 Nov 12 2017 iSCSI-2015ace1-5a078d66.000
-rw------- 1 admin administ 1073741824 Jun 24 09:52 iSCSI-lun4-5d0de534.000
-rw------- 1 admin administ 107374182400 Nov 4 2015 iSCSI-nss01-56399e1a.000
-rw------- 1 admin administ 5368709120 Nov 11 2017 iSCSI-nss2015-5a06cf6d.000
-rw------- 1 admin administ 21474836480 Jun 22 17:11 iSCSI-test-56b3ce90.000
-rw------- 1 admin administ 5368709120 Jun 22 17:11 iSCSI-test-56b3ce90.001
[/share/HDA_DATA/.@iscsi.img] #
※ とても重要
CIFS/NFS のファイル共有NAS と違い、iSCSI でマウントして一つのターゲットを制御できるのは、一つのホスト、一つのイニシエータだけです。複数のホストからイニシエータでマウントする（できちゃいます）と、ファイルの排他制御は行われないので、ファイルシステム自体の不整合が起こります。
つまりファイル共有という目的には向いていない、という事です。あくまでも iSCSI ターゲットはネットワーク上の仮想ディスクです。
もっとも、一つのホストからマウントしてファイルを保存して、いったんオフラインにして、ターゲットを別なホストからマウントする、という事はできます。また、ターゲットは一つの iSCSI デバイスで複数作れるので、１台の iSCSI 装置に複数のターゲットを実装して、複数のホストから別々のターゲットイメージをマウントする事は問題ありません。
極端な話、ホストのハイパーバイザーは USB メモリやSANブートさせて、後はマウントした iSCSI の仮想イメージ上で、仮想マシンを動かす、HDDレスなハイパーバイザー運用もできます。
物理的な転送速度は、ネットワークの速度とディスクデバイスの性能に依存します。当然 10Gb base のネットワークカード、HUB、高規格なケーブルを使えば、論理的な性能は 10Gbps です。大抵は NAS の性能がそこまで出ないのですけどね。ヨドバシカメラあたりで売っている 4,000 円程度の 1G HUB でも、そこそこの性能が出てしまいます。
距離は、IPがつながればどこでもなので、ホストコンピュータとメインのストレージを自社のサーバールームに置き、イニシエータを動かし、バックアップ用の iSCSI ターゲットをデータセンターに置く、なんてこともできます。
【送料無料】QNAP TS－431P2（ホワイト） NAS 4ベイモデル クアッドコア CPU ／ LAN 2ポート搭載 （TS431P2）
価格:56,145円
感想(0件)
iSCSI の耳慣れない言葉に LUN （論理ユニット番号 : Logical Unit Number）というのがあります。
昔の SCSI は、 SCSI バスアダプタに７番のIDを振り、残りの 0 ~ 6 のディスクや CD, Tape などに ID を振り分ける物理的な３ビットのディップスイッチやジャンパ端子が付いていました。これが SCSI アドレスです。
これが実に難物でした。特に、複数の SCSI バスアダプタカードをデュプレクス設定する場合、割り込み番号も別々にするので、手が滑ってジャンパピンを飛ばして床を這いまわって探したり、難解なディップスイッチを前に数日悩んだものです。
つまり一つのSCSIバスには 0~７の合計８台（うち大抵７番はSCSI バスカード）の物理ユニットデバイスがつながって別々に見えたという仕組みだったわけです。
ところが SCSI バスを使った Raid コントローラが出てくると、ディスクの鈴なりが、一つの物理デバイスに見えてしまうわけです。これを「論理的な仮想番号」に分割して、システムからは、単一の鈴なり Raid ディスクを複数の論理番号に分割したわけですね。
これが LUN というヤツです。
iSCSI 機器のターゲットも、内部のソフトウェア的に複数の論理デバイスに分割して、複数のホストコンピュータから複数の物理デバイスのように見せかけるわけです。
別々な LUN は一つ、あるいは複数の iSCSI 機器によって、複数のホストに別々のディスクデバイスとして見せかけるンです。
https://en.wikipedia.org/wiki/Logical_unit_number
Qnap NAS の場合、iSCSI ターゲットはウィザード形式で簡単に作成できます。EXT4 ファイルシステム上で、オンラインでも簡単にサイズの拡大ができるので、 Windows の Storage Server のように NTFS の VHD 形式ではないので、そこそこ性能が出ますが、いかんせん古さと遅さは否めません。
Qnap NAS の iSCSI ターゲットの設定は、偉そうな Linux 系サイトに書いてある程、面倒なことはありません。ストレージマネージャから iSCSI タブにあるウィザードに従って iSCSI ターゲット名に任意の名前を付けると IQN にその文字列が追加されるだけです。わざわざ vi エディタに「正確に」綴りを間違えずに設定する必要もありません。ここでは Chap 認証は付けませんでした。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16405779.jpg
機械は古いのですが、逆に言うと、「古くて遅い」ため、サーバーとNASとの接続プロトコルの性能差が、如実に現れる事になります。
QNAP TVS-951X 10GBASE-T/NBASE-Tポート内蔵
Windows10 の Microsoft 製 iSCSI イニシエータは「コントロールパネル」＞「システムとセキュリティ」＞「管理ツール」の中にあるので、ここで、設定済の iSCSI 「ターゲットを」 「検索」して選んで「接続」します。Chap 認証を付けておいた場合はターゲットで設定したパスワードが必要でしょう。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16412132.jpg
新規に作成して、接続した後は、フォーマットされていないため、ディスクマネージャからフォーマットして使います。ちなみに、フォーマットして利用した iSCSI ターゲットの仮想ディスクは、他のマシンでマウントすることもできます。つまりHDDを取り外して、他のPCに繋げる事と同じことですね。
ＰＲ
ちなみに opeSUSE で使うにはこんな感じになりました。
open SUSE Leap 15.1 で iSCSI NASを使ってハマった
https://islandcnt.exblog.jp/239328437/
一番イラつくのは、巨大なファイルの転送でしょう。という事で 3G 程ある SUSE Linux のインストール用DVDの ISO ファイルを CIFS でコピーしてみます。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16414334.jpg
３分１１秒かかりました。１Gビットネットワークで 12～3% 程度の帯域を使って通信しています。明らかに古いNAS の性能が足を引っ張っているようです。
スループットは 150Mbps 程度で全体の最大１５％程度でしょうか。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16415832.jpg
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16422170.jpg
初速は出るのですが、その後は、ボロイ TS-110 の性能がモロに出ます。それでも 20 MB/s から 25 MB/s 程度は出ています。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16423835.jpg
２分２５秒でした。 大体２０％程度のスループットです。
--
数字に弱い私の脳みそですが、 iSCSI は CIFS より 1.5倍くらい早い、という事が言えます。
Zabbix で QNAP TS-110 の I/O を見てみると、前半の CIFS アクセスより後半の iSCSI アクセスの山が高い事がよくわかります。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16425860.jpg
CIFS を使ったリモートディスクのマウントは、他のPCからもアクセスができる、というメリットがありますが、iSCSI は単一のホストからのアクセスしかできません。<--- これ重要.... -- もっとも、ターゲットストレージを複数作って複数のサーバーから異なるデータ領域にアクセスはできますが -- バックアップ用途や、サーバーの増設ストレージとして考えれば、良い選択であると言えます。
もっとも、iSCSI デバイスそのものは、ターゲット単位で別々なホストから接続できます。しかし同じターゲットで別々のホストからイニシエータから繋ぐと、とても笑いごとにならない事態になるので、普通やりません。
ハイパーバイザー同士で一つのターゲットを共有してライブマイグレーションはしたことはあります。
こうした性能のわずかな違いが、仮想化システムのハイエンドな領域で違いとなって出てきます。なお Qnap でも openiSCSI でも Windows Storage Server でも取った領域そのままのサイズのでかいファイルが作成されるようです。
国産 NAS の「ハイエンド」と称する「LANxxxx」などのモデルでは Windows Storage Server を使って NTFS フォーマットしています。Windows Storage Server は見た目 Windows サーバーそのものなのですが、ところどころちゃんとデチューンされているようで、SOHO向けが限度です。
こういった国産 NAS メーカーの製品カタログでは、「ハイエンド」は Windows Storage Server を搭載して、低価格のNASは Unix 系のシステムで「低価格」を謳っていますが、そもそも、上位モデルは、CPUやメモリの性能が高いものが使われています。性能が違うのは当たり前なのですが、あまり性能が出ないだろうと思います。
Windows Storage Server じゃなくて、ちゃんとした Windows Server と CAL 買えよな、という事なのですね。
このあたりは独自OSを NAS としてチューニングした Qnap や Synology, asuster などの iSCSI 機能付きの NAS を中規模ネットワークのミドルレンジの NAS として利用したほうが良いと思います。
仮想環境でのネットワークアタッチストレージ(NAS)は、本回線（構内LAN）とは切り離し、ストレージ専用のネットワークとして独立して運用させるのが基本です。サーバーとNAS間で凄まじい通信が発生します。サーバーNICが２ポート以上のものが推奨されます。
iSCSI はあくまでもネットワーク上のストレージのみの機能を提供するものであり、ファイル共有の手段ではない、という事です。
NAS をCIFSで使うと NAS が持つ独自のアクセス権限を設定しなければなりません。セキュリティも当然 NAS 独自の機能で設定します。
iSCSI はあくまでも「外付け SCSI デバイス」のネットワーク版なので、マウントする側のOSそのもののファイルシステム、セキュリティ機能、アクセス制限がホスト側の機能をそのまま利用できます。セキュリティ的には、マウントする際のパスワード制限しかないので、独自のストレージネットワーク内に配置すべきで、ユーザが使う構内ネットワークに配置すべきではありません。
それが起こったのです。ゼロクリックの脆弱性と特別なコードを使用して、Webサイトを介してあなたのデバイスをハッキングしました。
このエクスプロイトは、特別に作成された一意のコードを使用してチェーンで機能し、このようなタイプの攻撃は検出されません。
Webサイトにアクセスしただけで感染してしまいましたが、残念なことに、私にとっては非常に容易いことです。
あなたは標的にされたのではなく、そのWebページを介してハッキングされた多くの不運な人々の一人になったのです。
これはすべて8月に起こりました。そのため、情報収集には十分な時間がありました。
数ヶ月間、私のソフトウェアは、あなたの習慣、あなたが訪問するウェブサイト、ウェブ検索、あなたが送るテキストなどの情報を静かに収集していました。
他にもまだまだありますが、これがどれほど深刻であるかを理解していただくために、いくつかの理由を挙げました。
明確に言うと、私のソフトウェアはあなたのカメラとマイクも制御しました。
あなたを主演とした価値あるPORNHUBビデオをいくつか作成しました。
すでに十分に待ったので、これに決着をつける時が来たと思い立ちました。
こちらが私からのご提案です。 これを、私が希望するコンサルティング料金と名付け、これまでに集めてきたメディアコンテンツを削除したいと思います。
そうでなければ、私はあなたの連絡先に最も有害なコンテンツを漏らし、変質者が見ることができるようにそれを公開ウェブサイトに投稿します。
あなたも私も、これによってあなたが被る損害の大きさを認識しています。あなたのプライバシー保護にあたってそれほど多くの金額は要されません。
私はあなたに個人的な関与をしません。そのため、私が所有するあらゆるファイルやあなたのデバイス上のソフトウェアが、転送を受けた直後に削除されることについてご信頼ください。
私の適切なコンサルティング料金は、ビットコインで送金される1750ドルです。 振込時の為替レート。
この金額をウォレットに送る必要があります BTC 1muUe7DXGm3bs2XtbhYwYYH6aUWCASsSN
定められた料金は変更できません。2営業日以内に支払うものとされます。 支払いを受け取る事だけが重要です。
言うまでもなく、プライバシーを侵害されたく無ければ、誰かに助けを求めようとするのはやめてください。
支払いを受け取るまであなたの動きを全て監視しています。 契約の期限を守れば、二度と私から連絡が来ることはありません。
どうぞ良い一日をお過ごしください。
たとえばこれ。
リモートデスクトップ（RDP接続）の通信量の目安は？何ギガ使う？
2021/2/7 情報家電 0
テレワークや在宅勤務などでWeb会議やオンラインミーティングをする機会も増えているだろう。
また、会社のサーバやPCに接続を常時することにより、どのぐらいの通信量が必要なのか、すぐにギガを消費してしまって速度制限を受けてしまうことにもなる。
リモートワークをするための方式はいろいろあるが、今回はリモートデスクトップを利用した場合の通信量について紹介をしよう。
リモートワーク、テレワークをする際の一つの方法として、リモートデスクトップ方式がある。
リモートデスクトップ（Remote Desktop）でRDPと略される接続方式だ。
利用方式としては遠隔（リモート）にあるパソコンを操作することできる機能で、WindowsやChromeなどで標準機能として備わっている。
つまり、会社にあるパソコンを自宅に設置したパソコンから操作をすることができる。
また、データ自体は会社のパソコンに保存され、画面だけ転送されるので、セキュリティが比較的高い方式だ。
そのため、多くの会社でリモートデスクトップ（RDP)を利用して出張時や自宅でのｔで仕事をしている。
リモートデスクトップ（RDP）接続の場合の通信量目安は1時間当たり300MB程度となる。
あくまでも目安となり、画質や操作頻度などにより大きく変わる。
今回は仮に1時間あたり300MBとすると、9時～17時（8時間）利用をすると、2.4GB（2400MB)が必要となる計算だ。
つまり、一般的な企業で平日仕事をすると2.4GB/日の利用になり、1か月（20日勤務）となると以下の計算となる。
1時間 300MB
8時間 2.4GB（2,400MB)
20日間 48GB（48,000MB)
上記のように平日月～金を4週間働く場合の1か月間すべてをリモートワークすると、48GBの通信量が必要となる試算だ。
この48GBを通信するための通信設備がないと、リモートワーク、テレワークは成り立たない。
実際に、通信量を考えずに7GB契約のモバイルWiFiで仕事を始めたが、最初の3日ぐらいは快適に使えていた。
4日目からは通信制限がかかって「256KB」でしか通信ができなくなり、画面が動かない、仕事にならないという状況となった。
そのため、自宅でテレワークをする人は50GBぐらいは利用できる通信手段を考える必要がある。
また、無制限Wifiと言いながらも3日で10GBを超えると翌日は通信制限がかかるプランなどもあるので、注意が必要だ。
そのため、モバイルWiFiを利用する場合の最低限の条件は以下の通りだ。
速度が安定していて、早いもの
2019年の時点では「リモートデスクトップ転送量」とかでググってもほとんど参考になる日本語情報はなかった。
やりたくないって言ってるのに他にやれる人がいないからって理由だけで、プログラマーもどき的なことをやらされていたが、大概のクソだった。
営業が納品1時間前にボタンや要素を増やせとか言ってきて、その後、5分おきに内線かかってきて「なんでそんなに時間かかるんだよ！ただボタン増やすだけだろ！」ってキレられる。
ボタンが20個くらい増えるんだぜ？納品1時間前に。そのボタンを増やすことで整合性が崩れてどんなバグが出るか分からないし、普通なら最低3日は欲しいだろ。それ言うと、「できない理由を並べ立てるな！お前と話してるとイライラする！」と電話ガチャ切り。そしてまた5分後に内線がかかってくる。
グラフィックはデザイナーがやるんだが、こいつらもクソで「1poin右にずらしました。全部の素材の差し替えお願いします」とか平気で言ってくる。その素材もこちらの使用に合わせて提供されているならまだしも、GB単位のイラレファイルを投げつけられるだけ。イラレは使えないから素材書き出してくれって言ったら「それくらいやってください！こっちは忙しいんです！」ってこちらもキレる。
会社の経理もクソだった。各案件ごとに貢献度に応じて、売上成績を分担するんだが、営業7割デザイナー3割、俺0。
これについても抗議したら、SE的な仕事は社内マニュアルに記載がないので按分する根拠がないのでできませんと言われた。
そして年度末には個人の売上成績が振るわないことを理由に3時間位、上長になじられる。
あまりにクソすぎて1年でやめた。しかし辞める前に、SEの仕事の保守を無償で永久に引き受ける義務を負うと言う念書を書かされた。金払ってくださいと言ったけど、社内マニュアルにないので対応できない。そもそもその仕事を始めたのはお前なんだから最後まで責任取れの一点張り。やりたくでやったわけでもないのに。しかし書かないと退職を認めないと言われたので仕方なく書いた。
退職日の帰りに携帯解約して、新規に契約し直し、親族以外に新番号を知らせなかった。社内連絡用に使ってたLINE、Googleアカウント、会社の人間と繋がっていたSNSも全て閉鎖して、市内とは言え引っ越しもした。引っ越しの際には郵送物転送の手続きも取らなかった。会社の同僚と共通の友人もいたし、少なからず好感も持ってたが、こちらも全部切り捨てた。
もうとにかく、あの会社に一切合切、関わりを持ちたくなかった、狭い業界だから、同業界では働く限り関わらざるを得ないので、収入の激減を飲んで全く別業種に転職した。
今は底辺職場で非正規で生活保護以下の給料で働いてる。全盛期から比べれば月収は5分の1にまで落ちたし、いつ切られるか分からない不安定な身分。それでも気が楽だ。仕事らしい仕事は1日1回あるかどうかだし、そもそもそれもほとんどマクロ化してワンクリックで済むようにしてる。
勿論、マクロを使っていることは一切他人には言ってない。難しい顔してウンウン唸るふりをして、定時後10分くらい残業してから退社してる。仕事なんか昼前には終わってるんだけどね。
このコロナ禍で弊社も既に虫の息で人員削減って話が出始めている。俺はまずクビだろうね。あるいは週2～3くらいの出社になるか。どちらにしえも生活はできない。
どうするかね、精神疾患の診断書貰って、生活保護+障害者加算を狙うか、会社都合で退職になれば失業保険が貰えるんだっけ？まぁコロナは災害だから会社都合にはなりませんとか言ってるし、生活は詰みそうではある。
