  |
はてなキーワード: ハンズとは
機会があって予備校の数学の授業と司法試験の授業受けたのだが草生えましたわ
『オンライン学習にして予備校から優秀な講師引っ張ってきた方がコスパ良い』
『授業は予備校講師に任せて、公立教師はわからない子や逆にもっと学びたい子のフォローと化学実験や家庭科のフォローや体育のフォローだけやっとけ』
・・・って思ってたが、ここまでわかりやすさ＋エンタメ性にはっきりと差がついちゃうのかよとね
確かにわかりやすい予備校の授業でのみ勉強してきたヤツは考える力がつかないことも起こり得そうではあるが、
専門課程に進む前に知識を詰め込む、あるいは何かをする(たとえばプログラムとか)ための知識を得てる段階で考えるも何もねーだろうよ
公立の雑な授業・大学教員の研究の片手間の授業を受けたらからってどうこうなるレベルのものじゃない(そもそも高等教育もリベラルアーツとほぼ遠い)
社会で不自由しないために・詰め込んだ知識を活かすために、最低限は考える力を鍛えなければの場合も、
公立の雑な授業・大学教員の研究の片手間の授業をもって考える力を養うをやりました！とか怠惰なことはやらずに
極端に思考力が弱い人がいると言う前提に立って訓練メニューを用意すべき
あと思考力を養う授業では『理解しました』といっても、極端に思考力が弱い人は覚えた数式を具体的にどう使うのかはわからないとかフツーに言い出すので、
アメリカみたいに世界中から優秀な若者が勝手にやってくる＋資源があるなら学位商法やっててもオッケーだが
みずほフィナンシャルグループは米グーグルと提携し、デジタルサービスをてこ入れする。2022年度中にも、グーグルのクラウド上で顧客の取引データを分析し、投資信託や住宅ローンの提案など顧客ごとに適したサービスを提供する。
みずほ、Googleと提携 DXで顧客サービス抜本見直し: 日本経済新聞
https://www.nikkei.com/article/DGXZQOUB182BH0Y2A310C2000000/
「パソコンの先生」としていろんな企業に研修に行っていると、どこも基盤となるITを知らない人たちに「でぃーえっくす」としてPythonだAIだIoTだ学ばせようとするんだよね。
世の中の「システム」というのがサーバー、ストレージ機器などでできていて、それがネットワークでつながっている、データは誰かが設計したとおりにDBに蓄積される、ということを知らない非エンジニアの人たちに、クソ人事が「Pythonで機械学習！データ活用してデジタル変革！」とか打ち出して研修を受けさせることがとても多くてね。基礎がない人たちに何を教えても、ハンズオン用に用意されたデータを解答例どおり操作できるようになるだけで、何ら自社の実際のシステムに基づいたデータ収集、加工、分析はできないのに、「研修を開催した」という実績が人事の点数になって、給料になる。人事は何件研修を開催した、という実績じゃなくて、それで社員は何ができるようになったか、という成果で評価されてほしいよね。
みずほも、今やることはクラウドだ顧客データだDXだという上っ面じゃなくて、土台の堅牢なシステム基盤を要件定義、設計できる人材を育てることだと思うんだけどね。
私はかつて、DeNAで契約社員として3年ちょっとの間、働いていた。当時 (今もそうかもしれん) 、DeNAではゲーム以外の収益の柱になる事業を模索していて、いろいろとエッヂの立った謎なサービスやアプリがリリースされてはひっそりと閉じられていく、ある意味では面白いうねりの中にいた。commだとかGroovyみたく壮絶にリソースを投入してコケたサービスもあれば、Showroomのように分社化して巣立っていった成功例もあった。
そんな、会社としていろいろ試していたフェーズで、Flatというどう考えても収益化できなさそうなSNSアプリがどさくさに紛れてリリースされた。
これは閉じられた匿名掲示板的なSNSで、ローンチ直後はDeNAの従業員だけが利用できたのだと思う。
誰でもスレッドを立てることができ、コメントをみんなが投稿し、いいねで馴れ合うという、機能としてはありふれたものだった。
ただ、後に他のテック企業の人も利用できるようになり、mixiやサイバーエージェント、DMMとかの人たちと交流できたのは楽しかった (各企業のドメインのメアドを持っていないと会員登録時の認証メールを受け取れないようになっていた) 。
スレ主やコメントを投稿した人が誰なのかは分からないが、どの企業の人なのかは表示されていた。アップデートで、同一スレに複数のコメントを投稿するとそれらのコメントが同一人物の投稿だということまでは分かるようになっていたと思う。
「IT用語に『夜の』をつけてエロくする」みたいな大喜利のスレッドがあって、私が投稿した「夜の多分、大丈夫だからリリース」がスレッド内でトップのいいね数を獲得したのはいい思い出だ。
そんなFlatであったが、「全社集会の内容を教えてくれ」みたいな内容で、見るのもコメントするのもDeNAの従業員限定の設定で私が立てたスレッドがあった。全社集会は半期に一度のオールハンズなのだが、なぜか正社員しか参加できないという縛りがあって、どんな雰囲気でどんな内容が話されているのか興味があったのだ。
誰かが「内容は正社員限定の機密だから話せないし、そんなふうにカジュアルに聞くべきではない」とコメントした。私は正社員限定なのは単に会場のキャパ (社内には全員が集まれるスペースはないので、どこかのホールを借りて開催していた) の問題だと思っていたし、内容の一部、たとえば何々への貢献で誰々が表彰された、だとかはわりと普通に共有されていたので、少なくともDeNA社内では秘密でもなんでもないと思っていたので、どんな文言だったかは忘れたが「いいじゃん、そんなケチくさいこと言わずに教えてよ」みたくコメントしてしまった。
それに対して、私の態度がよくない、みたいなコメントが付き始め、それが段々とエスカレートしていった。
「お前なんかぜったいに正社員になれるわけがない」だか「そんなんだから正社員になれないんだよ」みたいなコメント。(別に正社員になりたいだなんて言ってないし、辞めた後で知ったのだが私の給与は並の正社員よりも高かった)
一番ひどかったのは「こいつ (渋谷ヒカリエの) 何階で働いてるんだろう? (自分と同じ) 23階だったら嫌だ。ぜったいに関わりたくない」というコメント。
最終的には何十人かの人から、私の人格を否定するコメントを頂戴することになった。
当時の私の精神状態はなかなかに不安定で、同僚たちの中に私と知らずに私のことをケチョンケチョンに言い放っている奴がいる、というのを意識しながら仕事をするのはなかなかに辛いものがあった。
何年も経った今、振り返ってみて、確信を持って言えるのは、私はインターネットで誹謗中傷を受けたのだということ、そして、それに対してサービスの運営も人事も、なにもしてくれなかったということだ。
当時の私はどうすればよかったんだろう。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
汚言症増田くんが文章読めない＆読まない＆短時間で複数トラバのはいつものことなんだけど(何度指摘しても懲りないよな)
誰もハンズラボで働いてたなんて書いてないし趣旨はそこじゃない
それはそれとして
ワイくんは下記なら何度も書いてるね。夢見るヤツ多いから
関連増田：
GAFAの広告が出てきて、辞める確率が2倍で年収も2倍とか出てたけどワイさんの部門は誰も GAFAM で年収2倍になっちゃいなかったし、
ブラック企業ほどポコポコ人辞めて無かったが？ぶっちゃけ内資のアミューズメント(パチンコ)の方が給与良いが？
https://anond.hatelabo.jp/20201101070057
東急ハンズが東急から売られてしまうからもう東急を名前に入れられないのだという。
そうだね日立工機が日立から売られたらもう日立入れられないのと同じだもんね。
でも東急ハンズのブランドのなんともいえない微妙なおしゃれ感高級感は東急だからだと思うんですよ。超高額商品が売ってるわけではないが、ほぼ定価でしっかりしたものを売り買いしている、そういう感じがね。
でもカインズが買うからカインズハンズではあまりにもハンズのイメージが小さくなっちゃいます。
なのでタチを抜いたらハイコーキなのでこれからもコーキって呼んで、みたいになんか近い感じがいいと思うんですよ。
サンキューハンズとかラッキーハンズだとちょっと昭和っぽいし安っぽいですかね。
高級ハンズはちょっと低級がありそうで嫌ですね。上級ハンズもですね。
わけあって今の会社に出向した後、3年目で正式に移籍をした。今年はかなり仕事が忙しかったが、正式移籍で給与が1.5倍ぐらいになったので、けっこう旅に出たり百貨店回ったりとそれなりに生活に余裕ができてきた。それはとても嬉しいことなのだが、困ったことに物欲が満たされると、精神の健全化を図るように体が要求してきた。平均帰宅時刻が23時とかいう激務に見舞われたからかもしれない。それで帰省で貯まったマイルを生かして各地を回っていたのだけれど、それでもどこか満たされない。
幸いにして浮気している暇さえないので、というよりむしろ奥さんや子供と離れれば離れるほど、その大切さがわかったり、愛しさが増すばかりであった。月1回ペースで帰省していたが、帰ったときには家族第一で、子どもともできるだけ遊んで、子どもが寝てる隙には奥さんとしまくった。多分付き合い始めた頃レベルでした。
で、するに越したことはないけれど、奥さんを抱きしめているだけでも随分満たされた。フリーハグとか一時期流行ったけれど、あれはきっとオキシトシンが分泌されているのだろう、人にとって人を抱きしめるというのは、実は結構重要な行為だったのだ、と気づいた。
家族でない人を合法的に抱きしめるには、風俗行ったり、そこまでしなくてもリフレでもできると思ったが、料金もそこそこするし、何より奥さんに後ろめたい気持ちもあり、おそらく満足できないだろうと思った。
そうだ、抱きしめるものがあればいいのだ。そう思った俺は抱き枕を買うことにした。
都内某百貨店へ見に行ったが、正直抱き枕を探すのは恥ずかしかった。抱き枕といえば、奥さんが妊娠中に抱き枕を使っていたが、お腹の支えにしたり腕の支えにしたり、身体の痛みを軽減するために使っていた。しかし俺はどうだ。奥さんを抱きしめられないのが寂しいから抱き枕が欲しい、なんてなんとも軟弱な理由ではないか。俺は酒を少し飲んで理性を鈍らせてから行くことにした。抱き枕を探しているおっさんにも店員はさっそく応対してくれた。このあたり、やはり百貨店はありがたい。試着室ならぬ試眠室？ベッドが置いてある半個室の、なんだか怪しい風俗みたいな（失礼 部屋に通され、まずはロフテーの機能重視のものと、やや安価なものを出してもらって試してみた。しかし私は機能よりも奥さんのぬくもりを求めており、つまり奥さんの姿形に似ている抱き枕を探している、がそんなこととても言えない。ここまで書いてダッチワイフならどうか、と思ったが、別に人間的な造形や、ましてや穴を求めているわけではない。それに機能重視のものは3万円すると、かなり高かった。これならハンズで売ってるビーズクッションのほうがマシだ。さすがに検討するというと、もう一つ西川の抱き枕があると言われ、そちらも試してみる。西川にもやはり機能重視のやつと太いやつ、細いやつとあって、それぞれ試したところ、なんと太い抱き枕が奥さんの背丈ウエストとそっくりなのだ。特に正しい位置に当てたとき（抱き枕は大腿に挟んで使用する）太い側の位置がちょうど奥さんと正対して抱きしめたときの頭の位置に一致して、思わず一目惚れしてしまった。値段も8千円と手頃な額で、ほぼ即答で「これにします」と言ってしまった。持ち帰るには少し大きかったが、構わず持ち帰った。
そしてさっそく自宅で使ってみたが、とんでもなく心地よかった。座椅子に座りながら抱きしめると、ソファで奥さんとテレビ見ながらふざけて抱き合ったときのようであったし、もっとしっかり抱きしめると対面座位のようである。俺はふざけて膝の上に奥さんを乗せることがあったが、足りないのは50kg超の重みだけである。寝る時も横において抱きしめると、案じたとおりに太めの部分が完璧な位置に来る。ニヤニヤしながら思わず腰を振ってしまった。絶対見られたくない、変態そのものである。しかし俺はめちゃくちゃ幸せだった。
俺は嫁と特に早朝することが多い（深夜は子どもが寝静まるよう、寝たふりをして過ごすのだが、どちらかかそのまま寝落ちてしまうのだ）のだが、朝起きて隣に抱き枕がある。抱きしめる。めちゃくちゃ気持ちいい。愛おしい。こんなにも抱きしめたかっただなんて。こんな幸せな時間がずっと続けばいいのに、と日曜だったの1時間ぐらいゴロゴロしていた。
まさかこんなに抱き枕一つで気持ちが変わるとは思っていなかった。しかし、明日はまた会社であるが、果たして俺は明日の朝まともに起きられるのだろうか、非常に心配である。
東急ハンズ池袋店では4～5年ほどアルバイトをしていました。もともとは夏休みの短期バイトでしたが、特に離れる理由がなかったのでそのまま継続してズルズルと続けていました。
なぜ東急ハンズだったかは覚えておらず、たんに学校からほど近くて昔から馴染みがあった池袋というだけで選んだ気がします。池袋には中学の頃から通っていましたが、自分にとっては本と家電の街でした。あと駅が複雑。新宿駅などよりダンジョン感はありませんが、西の東武に東の西武っていう初見殺しで有名な罠や縦に長くて迷いやすい構造は初めての人には難しい駅だと思います。
今回の閉店は自分の中では寂しい気持ちでいっぱいです。ハンズの思い出というより池袋という街に対する思いいれなのかもしれません。ハンズの帰りは決まって近所のラーメン屋によったり、休日の昼間ならば真向かいの松屋で食事をしたりしていました。資格試験では決まってロッテリアやマックで遅くまで勉強していましたっけ。家電類もアキバなどより池袋のビックカメラが主でした。
ハンズは自分にとって、池袋という街に滞在しつづけた理由の1つであり池袋の人と直に接する機会を得られる貴重な場所でした。
そんなハンズ池袋店が閉鎖してしまうというニュースを聞いたときは、コロナ禍ではあるもののもう一度行きたいという気持ちが募りました。けれど既に東京までは片道でも2時間は掛かる場所にいる自分にとっては物理的に距離がありますし、そもそも今年の8・9月は東京に足を運ぶことすらできない状況でした。さらにこの頃は家族の妊娠が発覚したことでますます遠出することが不可能となり、結局10月31日の閉店に間に合うことは叶いませんでした。
アルバイトをしていた当時、私の仕事場は主に１・２階。当時は１階が季節ものコーナーで２階はバラエティや健康グッズがおいてありました。私はその品出しバイトだったのです。
冬も夏もあの白ワイシャツに紺のパンツ、それと緑色のおそろいの腰エプロンをして作業をしていました。
当時の２階には、「アニメグッズ」「ジグソーパズル」「コスプレ衣装」「ダーツグッズ」「ケータイストラップ」「健康グッズ」「卓上プラネタリウム」などが狭い中に敷き詰められていました。本当にバラエティ色たっぷりでそれに合わせて大型イベントのたびにお客様がごった返しており、そうでなくともにぎやかなフロアでした。だからたまに他のフロアによると自分の担当のフロアと違って随分静かに感じたものです。
１・２階のスタッフは基本的にひとまとめにされており扱う商品もこの２つのフロアで持ち合いになっていました。なのでフロア同士で商品の入れ替えが行われており、夜中に什器を移動させるなど結構大変だった記憶があります。扱うものも多岐にわたるためか最上階の事務所の廊下には自分たちのフロアの什器が商品を付けたまま所狭しと並んでいる光景がよくありましたね。多分他のフロアからはかなり迷惑がられていたと思います。
当時よく取り扱っていたものとして、変な貯金箱がありました。顔面の貯金箱で硬貨を口にあてるとそのまま飲み込んでしまう貯金箱です。他にも猫がダンボールから手を伸ばして硬貨を引き込むものとか、まあそういう変わり種の貯金場がでかい机の上にピラミッド状に積み上げてあったこともあります。他にはおでん缶とか無限プチプチとかも扱ってましたね。懐かしいな。
あと、北海道フェアも１階で行っていたのですが、ロイズとかのポテトチップスチョコとかも売れ残りが結構出たので事務所の休憩室前で従業員価格で手売りされてました。なので飽きるくらい食べた思い出があります。
クリスマスや夏休みとかは人がごった返しており、品出しするだけで大変な思いをしましたね。
当時エヴァの劇場版が大ヒットしたこともあって、UCCの缶コーヒーが馬鹿みたいに売れていたんですが、あれを補充したり並べるのも地味に大変だった気がします。
そうそう、最後まで猫カフェには行くことがありませんでした。なんで当時行かなかったんだろう
色々あって、だけど結構前の話なので覚えていないことも多いですけど、私にとっては池袋という街を定点観察する一番の場所でした。３７年間、お疲れさまでした。
いまはもう従業員でもなく池袋に立ち寄ることはなくなってしまい、その中で池袋もだいぶ様変わりしたようです。ハンズの休憩時間に食べていた松屋やデニーズはもうないらしく、頻繁に行っていた丸善の本屋も既に閉業しています。知らぬ間に色々なものがなくなっています。思い出のハンズもなくなりますます回顧の中にしかない池袋。
「クリーム色で細い線が書いてある小さい紙束が萌えである」という理由でハンズで買ったミニ6穴メモリフィルは全部捨てよう
うむ、KNOXのも当たり前に大量にあるな、捨てよう
そうねBINDEXの手触りがよくてね、プロジェクトチェックリストのビジネスっぽい横掛け具合がなんとも、いいやポイ
軽 く て 薄 い ス ー パ ー ラ イ ト ペ ー パ ー C R E A M 横 掛 ポイ
RaymayのDavinciのクリーム色の無地ノートリフィル、無地だからポイで
ハンズのメモリフィル無地（※こっちはウラ面！注意！）……表裏あんのコレ。あっ手触り違う。いいやポイ
ああああ！BINDEXのミニ6穴サイズリフィル G301 DAILY PLAN(フリー)！
これの話していい？この丸くて細字で2色刷りのキュートにまとまった自分で日付書くタイプのフえっ時間ない？やだしまっとく
野帳がある。使ったやつが混じってる。これ見て火口よ。あらやだ太字で死ね。これ確かトラディオプラマン買ったときので、そうそう次のページは赤のやつで書いてある。ポイ
アピカの事務用箋。これのいいところはミニサイズなところで、終売だと聞いたので使いもしないのに3冊買った。どうしようかなあ
ボストンノート（長型）だ。前も増田に書いた気がするけど長型カムバック。売れなかったんだろうな…ニーモシネとかあるしな…野帳でもなんとかなるしな…
ARTEMISのルーラー付きメモプランナー。表紙が定規でがばっと開いた裏表紙がカレンダー。破っていくとフタが閉まらないという些細な欠点を除くと好きなメモ。カレンダー2007年だなコレ。ポイで
クリーム色好きならLiFEのメモ持ってないのかって、持ってるよ、でも持ってるペンと合わなくてねえ、だってこれ裏写りするじゃん！3冊ポイ！
