  |
はてなキーワード: ポリシーとは
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
ググれば大抵のことはヒットする
…
でもさー、本当は考えてそこに到達するのが楽しいんじゃん？
ゲームクリアできない、なんでだ？どこだ？ここか？こうすればいいのか？あっうまくいった！ってのがいいのでは？
最初から正解見て、その通りやって、俺は失敗しませんでした、って威張るの、時間の無駄じゃない？
…
その程度のことも自分の意思で選べないやつにコントローラーを握る資格はないよ。
プレイヤーになるのは諦めて漫画やドラマだけ体験して生きていけばいいんじゃないの？
選択することを楽しめることがゲーマーの必要絶対条件だからね。
たとえそれが「攻略情報をなぞる」ということの選択であっても、それを自分の意志で選択して選択したことに自分で責任を持てるなら立派なゲーマー。
前者は、選択しないプレーヤーをなじっている。攻略をなぞるのを選択の放棄のようにみなしている。
後者も、選択しないプレーヤーをなじっている。ただし、攻略をなぞることも選択、とみなしている。
個人的には後者のロジックを批判したい。縛りプレイ至上主義者を「自分の意思で選べないやつにコントローラーを握る資格はない」と罵倒しているようだが、主義というならその主義を選択した時点でそれは意思なのではないか。その選択に責任を持っていない／楽しんでないと断ずる理由もない。同じように、漫画やドラマを体験することを意思で選択して、その選択を楽しめたなら、彼も定義上ゲーマーになってしまう。後者の批判を受けての前者の返信はまだ無いが、「漫画やドラマを体験するのと攻略をなぞるのは何が違う？」という疑問は当然湧いてくると思う。縛りプレイ至上主義者・漫画ドラマ視聴者は選択してない、だけど攻略をなぞるプレーヤーを選択している—— 選択している、の基準が恣意的だと感じる。たとえば、攻略なぞり至上主義者というのがいたらどうなるのか？ 常に最善の効率プレイをしなければならないという強迫観念に駆られ、いつでも攻略情報を参照するのをポリシーにしているそのプレイヤーは、立派なゲーマーか？
理知的な意見だと思うが、ならば具体的にはどうすればいいのか？
「『女の敵は女』は蔑視的な偏見だし、良くない」と思ったら言ってもいいのか。 商品の取り下げに反対すればいいのか。それとも商品展開する側が取り下げずに強行すべきなのか。
小山田圭吾が五輪の作曲担当を辞任すると決まったとき、我々は反対すべきだったか。あるいは、辞任に追い込むような激しい批判を抑えるべきだったのか。
私は、ポリシーとして増田には努めて批判的なコメントは書かないようにしている。自分の後ろに石を持った聴衆が並ぶ怖れがあるし、そうなると記事自体を削除してしまう筆者が出てくるからだ。
フェミニストで表現の自由の戦士だけど、「声を上げるだけ」それでいいと思っている。
批判が通らなかったなら、それ以上は何もしない。怒りを収めることも諦めることもないけれど、エスカレートしてはいけない。あくまで声を上げるだけに留める。
県警は、議連の抗議を受けて「撤回に議連の抗議の影響はあったと思う」のように言っていた。一方で謝罪要求は突っぱねた。
同じように議連に、数万件の署名での反論が来たとき彼女らはそれをおざなりにした。
誰かがもし、死んだ魚のような目をして突きつけられた要求に従うしかないのなら、要求などすべきではない。
従うか無視するかを選ぶ精神の自由が確保されているからこそ、批判も自由にできる。
あの事件では誰も表現の自由を侵していなくて、その自由の範囲で異なる立場の人間がそれぞれに、大切にしているものを… 女性の尊厳を・表現の自由を、守ろうとした。
入口で独り客であることを告げると、一人席に案内された。両サイドはパーテーションで区切られている。
店員が軽く説明し、メニューと、トングや箸が一式入った箱と注文用のiPadなどを置いていった。
底が三分割されている皿があったのでこれは何かと尋ねるとタレを入れるんだそうな。
なぜ３つに分かれているかは聞きそびれた。
iPadで最初の肉と標準サイズのごはんを注文すると、退屈するまもなく席に運ばれてきた。
独りで行動することには慣れているが独り焼き肉ははじめてだった。
肉を1枚1枚焼いて、食う。
焼いてる時間を待っている間は虚無だ。
それを繰り返す。ちょっとした修行というか儀式のようにも感じはじめていた。
しかも肉とご飯のペースをうまく配分しようとしたつもりが失敗し、けっこう残ってしまった。
ご飯を残すのは俺のポリシーに反するが、もうおなかいっぱいで肉を頼む気にならなかったので
冷たいご飯だけを食べた。
私がＫ市を退職する時点で係争中だった。判決はどうなったのだろう。もはやどうでもいい。考える価値もない。
彼は、当時40代後半の職員だった。建築系の部署で働いていた。働きぶりは有能で、能力評価ではどの項目も標準以上だった。
そんな彼が、なぜ問題職員だったかというと――性格だ。後に性格ではなく、脳機能の障害の一種であることが判明するのだが、とにかく苛烈な性格だった。
キレたい時にキレ散らかし、毒を吐きたい時に吐き、暴力を振るいたい時に振るい、不謹慎なことを言いたい時に言い、不埒なことをしたい時に埒をあけていた。かと思えば、機嫌がいい時、常識的な発言をする時、的確な助言や指示を行うこともあり、そのおかげか、これまでトラブルを起こしても小さい処分で済んでいたようだ。
ある年の春だった。
建築系の部署には珍しく、大学を出たばかりの女の子（Ｓさんとする）がＣ郎さんの部署に配属された。ただ一人の女性職員だ。そのほかは男性である。
その子の働きぶりは良好だった。10コ上の先輩（Ａとする。男性。既婚）に付いて回り、仕事をひたすらに覚えていった。パワポの腕に覚えがあり、デザインセンスが抜群だと査定資料に書いてあった気がする。
精一杯頑張る子だった。愛想もいい。新人にふさわしい活発さで、気立てがよく、イベントや研修会の仕事もそつなくこなした。仲間受けも上司受けもいい。花見などの親睦行事にもよく出ていた。
……年末になる頃だった。そんな彼女の指導役だった10コ上の先輩であるＡが、あろうことかＳさんに手を出していたことが判明した。きっかけは人事課への匿名の投書と証拠写真（※こういう文書は大抵、職員からの密告である）で、隣の市にあるホテル街で手を繋いでうろつく２人の姿が写真に映っていた。
こうとなっては対応せざるを得ない。人事課の女性職員の付き添いとともに、Ｓさんを面談室に呼んで話をしたところ――Ｓさんとの行為に及んだのは、Ａと、Ａの隣の席のＢと、島の奥側に座っているＤ係長と、Ｂの向かいに机が位置するＣ郎さんの４人に及ぶことが判明した。特に、Ｃ郎さんは（状況は省略）無理やりにＳさんとの事に興じ、埒を明けていた。
さて、どうしたものか。ここまでの不倫案件は前例のない事態であるため、賞罰を扱ったことのある職員５、６人の間でも意見が割れた（賞罰の扱いが難しい案件については、人事課以外でいい意見を出せそうな職員も話に入れる）。
結論を述べると、４人ともに厳重処分（全員、３ヶ月間の減給10％。Ｄ係長はそのうえ１ヶ月の停職。Ａは僻地に出向。Ｓさんは事務系の部署に異動。本当は免職処分にもできたが、替えの効かない専門職の部署だったので考える必要があった）となったのだが、Ｃ郎の態度があまりに酷すぎた。
何を言ったかは伏せるが、反省の色が全くなく、Ｓさんを無理やり行為に誘ったにもかかわらず、「Ｓが悪い」「なぜ俺がこんな目に」「合意の上だろう」と宣っていた。
Ｓさんの代わりに来た年配の女性職員がいたのだが――ミスの多さに頭にきたＣ郎は、彼女の頭を分厚いファイルで殴打したのだ（いわゆるキングファイル）。
周りの職員がすぐにＣ郎を取り押さえようとした。さらにキレて怒鳴り散らすＣ郎を、その階にいた市民や業者が冷たい目で見ていた……と報告書に書いてあった。
ほかにも、Ｃ郎は過去にもこうした問題行動（突然キレたり、非常識な性的発言をしたり、ふてくされたり）を起こしてきたという。
この暴力事件の指導面談の時のＣ郎は、上に述べた報告とはうってかわって物静かだった。やはり、その時々によって気分が変わるようだ。
「今回、Ｃ郎さんは傷害という罪を犯しました。過去に、何度も職員や企業や市民を傷つける発言をしていますね」
「必要だからやった。非常識でもなんでも、やるときはやらねばならない。嘗められたら負けである。本人を傷つけてでも、罪になることでも、組織のために必要なこともある」※私のメモには方言があったので、標準的な言葉に直している。
「嘗められようと負けようと、人として不適切な言動をしてはいけません。カチンときても我慢しないと。みんな見てるんですから。特に私達は公務員です。公務員は24時間法律を守って生きていく必要があります。水清ければ魚棲まず、といったことは組織にも当然あろうとは思いますが、今回のＣ郎さんはあまりにもひどい」
「わかってはいるが、現実はそういうわけにいかない。杓子定規に捉えるべきではない。後輩への指導として、やるべきことはやらないといけない」
「昔はそれでよかったかもしれないが、今は」
「どれだけ時代が変わっても同じだ。それに、私は実際に結果を出している。私が基本設計を手掛けた公共施設は５つ以上ある。十分Ｋ市に貢献している。建築の弟子だって何人も育ててきた」
「今は関係ありません」
「なぜなのか？ わからない人だ」
平行線だった。埒があかない。他の職員にも聞き取ったところ、やはり若手の頃から感情的に不安定なところがあるようだ。
慎重に議論を重ねたところ、Ｃ郎に下された処分はＡ夫と同様の諭旨免職だった。依願退職しなければ懲戒免職処分を行う。だが、依願退職を受け入れれば年度末での退職を認め、退職金も満額出すというものだ。
Ｃ郎には、建築技師としてのキャリアがあった。民間でも使える資格を多数保持している。事務吏員の場合は、この年で辞めることになれば当然露頭に迷うが、彼の場合は再就職が可能であると元転職エージェントの視点から判断した。
Ｃ郎さんを切るべきか切らないべきか、幹部の間で幾度も話し合いの場が持たれた。が、これまでの不良行為があまりにも多すぎた。
Ｃ郎は労働組合に加入していなかったので、組合からの反発はほぼなかった。ただ形式的に、「職員に対する威圧行為であり、許容されるものではない」との文書での通知があった。
度々になるが、労働組合がここまで形骸化した組織であると知って失望することがよくあった。彼らはいつもそうだ。「当局は〇〇弾圧の意図をもって」「〇〇攻撃には屈しない」「労働者がよりよく働いていけるための権利を」などと、いつも組合の広報や定期総会で息巻いているが、実際に行動に出ることはない。
昔は知らないが、私が居た〇年間では、職員側への不利益変更（職員定数や給与の削減）を行っても強硬手段でブロックされたことはないし、彼らが出した申入書の要求事項をすべて拒否したとして、特段何も言ってくることはなかった。
繰り返しになるが、彼らはあくまで政治団体なのだ。〇〇党などの上位団体に献金を納め、メーデーといった形で政治活動への労働力を提供し、そのほか票の取りまとめを行うことで自らの政治的意図を実現するための政治的アクターである。
その機能の補完的な一部として、職員同士による互助的、連帯的な機能を有している。そのことをわかっている職員は、労働組合に加入しない意思を貫いていた。全体の２割ほどだったろうか。
さて、Ｃ郎は自分で弁護士を探してきて、法廷で決着をつける道を選んだ。私が退職する時点で未決着だった。とっくに決着は付いているだろうが興味はない。
最後に、Ｃ郎がどうしてあんなに異常な行動を取っていたのか説明する。一言で表すと、『障害』だった。彼の異常行動は『性格』に起因するものではなく、（詳細説明は避けるが）脳の一部に異常があって、脊髄反射的にその人が思ったことを即、言葉や行動に移してしまう。そんな障害があった。だから、ミスが多い女性職員の頭をキングファイルで殴るといった行動を取ってしまった。
もっと早く言ってくれればよかったのに。
法廷ではなく、せめて面談の時にそれを告白していたら、こちらとしても配慮することができたのだ。私は、能力が低いという理由だけで職員の免職処分を決めたことはない。能力があろうとなかろうと、仕事への意欲が皆無だったり、他者を傷つける言動を行ったり、組織にとって不名誉となる行為（主に犯罪）をしたり――そういった、能力よりも、もっと深いところに問題がある者に限って組織から駆逐する。それが私のポリシーだった。
（蛇足１）
どれだけいい成果を挙げたとしても、違法行為やハラスメントをしていいわけではない。当人に起因する、組織に対するプラス効果によってマイナス効果を相殺することはできないのだ。プラス３とマイナス２が併存することはあれど、相殺して１にはできない。プラスはプラス、マイナスはマイナスとして在り続ける。
われわれはすべて、誰かが眼を開けてくれなければ、目を閉じて世の中を歩き廻っている傾きがある。
さて、私が新卒で勤めていた会社は若々しい社風で知られており、よくも悪くも調子に乗った社員がそれなりにいた。すでに時効と思われるので、当時の記憶をそのまま辿ってみる。
具体的な仕事としては、飲食店や小売店に飛び込み営業をかけて自社求人誌に情報を載せてもらうのだが（追記：もうわかった人もいるだろうが、旧リクルートジョブズだ。問題のある行動が多い分社のひとつであり、近年同じく問題を起こしたリクルートキャリアとともに本社に合併された）、契約条件の交渉の時に調子のいいことを言って相手を騙したり（上司と話をさせろと言われてもブロックする）、人事関係だと、面接を受けに来た転職希望者を鼻で笑って次の質問に移る（時間がないから早く切り上げたい）。そんな連中が同期に何人も居た。
十数年後、私が営業所長に昇進した時には、そういった連中は駆逐されていた。悪行は長続きしないことを30半ばにして知った。今でも肝に銘じている。だが、彼らは別の意味で会社の役に立っていた。若手の営業所員が調子に乗った言動を取った際、その駆逐された連中の末期を語って聞かせることで、組織の癌の発生を抑止する役割を暗に果たしていた。
（蛇足２）
Ｃ郎さんの裁判の結果は見ていないが、障害を抜きにしてもＫ市敗訴の線が濃厚だ。明らかに能力不足や人格に異常がある職員でも免職処分にすることは原則できない。民間における解雇規制、従業員をクビにするのが「相当難しい」とすると、公務員の場合は「不可能に近い」となる。
https://www.tokyo-sports.co.jp/social/politics/452874/（東スポ）
橋本徹氏が大阪市長の頃に、勤務査定が著しく低い職員数名をクビにしたという記事だが、クビにされた職員が抗わなかったからできたことだ。職員側が何らかの事情で弱っていた、あるいは生きる力に欠けていたからできた。裁判に持ち込めば職員側が勝訴していただろう。それくらい公務員を免職させることは難しい。
ではなぜ、こちらが負ける公算が高くてもＣ郎に対する裁判の道を選んだのか？ それは、他の問題職員をけん制するためだ。「Ｃ郎は度重なる指導にも従わず、挙句の果てには傷害事件を起こして免職処分になった。あなたも同じことをすればこうなる」というメッセージを全職員に対して発したのだ。
これにより、問題職員の側にいる連中に対して――まともな態度で勤務する姿勢がない人間の末路はこうなる、馬鹿なことをすれば相応の顛末が待っていることを伝えた。
https://business.nikkei.com/atcl/seminar/19/00030/060600020/（日経ビジネス）
次は民間企業の例だ。数年前に㈱カネカという企業で労使の育休トラブルがあった。増田の諸兄なら覚えておられることだろう。
㈱カネカで実例のなかった男性社員による育休取得を行うことで、マイホーム購入やわが子の保育園入園など、子どもを育てる準備を整えたばかりの人がいた。その彼に対し、育休復帰直後に地方出向（※彼は断った後に退職している）を命じたカネカがネット上で袋叩きにあった事件だ。
上にあるのは、カネカが事件後に発したＩＲである。これを読んだハイレベル増田民の方々は、おそらくこう思われたことだろう。「これは現役社員へのメッセージでもある」と。
現役社員に対して、カネカは裏のメッセージを伝えている。「育休を取りたいなら取っていい。彼と同じ運命をたどる可能性はあるが」という、表にできない本音だ。
なお、ＩＲの中味自体も信ぴょう性がないことに注意すべきだ。ここに書かれていることは、カネカの外部から確認できるものではない。カネカ内部の細かい部分の意思決定（男性社員への処遇の理由など）は調査を受けてもバレようがないため、ＩＲに嘘を書いている可能性もある。いや、外部から確認できない時点で嘘ではない。『カネカにとっての真実』である。
https://president.jp/articles/-/25254（プレジデント）新卒1年目で解雇された地方公務員の主張
地方公務員の例になる。今は有料記事になっていて途中までしか読めないが、要約すると、「四国にある本山町が、社会人適性の低い職員を試用期間で解雇した」というものだ。公務員のクビを切ることは普通は不可能であり、この本山町も、「今しかない」と決死の思いで断行したのだろう。
裁判に訴えれば、この男性は免職を回避できたのではないかと感じる。試用期間においても解雇権濫用法理が適用されるからだ。困った時に誰にも相談しなかったり、相談相手を間違えたり、相手の言うことを鵜呑みにすると彼のようになる。身につまされる記事だった。
2021/1/4 これ以下（約500字）を修正
参考先としたブログを書かれた方が、当項の内容が正しくないものと認識されていることがわかったため修正します。ご迷惑をおかけして申し訳ありませんでした。
この項の要約（抜粋）は次のとおり。
・〇〇商事とか、〇△重工とか、△△電工とか、誰もが知っている一流企業にあっても、上で述べた本山町のような社会的間引きを行っている。適性のない人間を採用してしまった場合、組織としての非を認め、当人に退職を促す。
・Ｋ市の採用試験では、一流企業を辞めて試験を受けに来る人を疑ってかかる慣習があった。それも当然であり、採用後のハズレ率が７割を超えているからだ。たとえ一流企業の出身であっても、社会的間引きに遭う人間が活躍できるほど公務員業界は甘くない。
反論は認める。
曖昧な記憶だが90年代後半から女性の社会進出が徐々に増え出して
DINKSとか流行りのように流行りだしたり女性に管理職や社会進出が増えたのは、
その当時は生きる為の生活手段が結婚して永久就職という手段しか大きく残っていないという事を背景に
それを女性雑誌で、その生き方がとても良いとメディア側、特に女性雑誌が書き立てたからだと思う。
男尊女卑、男女同権、女性進出は新しい生き方、管理職も与えられて当然、出産による職場リタイヤのデメリット・・・、それらを書き立てられれば影響力はあるし、メディアが面白おかしく演出構成をデバフ掛ければ更に影響は増すだろう。
こんな人と結婚するぐらいならしなくてもいいかなという生き方を選んで
未婚のまま適齢期突き進んでやっぱりした方がいいなと言う高齢女性は多い。
それはお互い様だろう。
条件がいいのはお互い思う所だ。
その辺を変にごまかしちゃいけない。
女も若いとか美人とか要素の一つとして言われるのは当たり前だろう。
それでも結婚前提でデートしてみようかとか親交を深めて行く上で
ああプラス部分も多いからいいねと会社の就職とか業務を行うように
深めて行く。
そこで高年齢向けメディアが年齢以外の魅力でまだまだイケてるとか書き出して、
結婚するだけが人生ではないという男に頼らない生き方と言うのは間違ってないし、
うちの父親の様な暴君の夫に人生我慢しっぱなしという人も数少なく居るだろう。
そう言った意味で家庭を墓場という場所で耐え続けるなんて心が痛い。
結婚なんてしない方がとか3高とか条件爆上がりでサビ残で働くだけで精一杯の時代に
女性と会う機会すらガチ減りして、さらにメディアで都合良い記事を読んで自称自分磨きした人が出てくる。
地獄だ。
未婚の女性が居るからあってみろと言われ、悪い想像がありつつも
会わなければ始まらないと思い、互いに高年齢ながら会ってみたが、
結果として残念だった。あちらにはあちらの意見があるはずなので
何とも言えないが乗り気では無いように感じた。
大事にしたいというのは分かる。
妥協すれば後悔するだろう。
するも地獄でしないも後悔。
まあメディアを鵜呑みに乗っかる人も全てでは無いし極論ではあるが、
未だに未婚で結婚できなかった人が居るのは、そういうメディアに乗っかって踊らされて
祭りの後の様な人も居ると思う。
好条件の内に先に進む人もいるけれど
カーストの下に行けば行くほど条件も悪くなり、ついでに考えも狭くなる。
そんな人ほど安易な耳障りの良い雑誌の何気無い記事が影響しがちと思う。
そんなのに心動かされんなよ。
子供を産むのは早い方が良いと言い放ったのが、
そこそこお互いが若い年齢でカップル成立して家庭を作ると言うのも
キチンとメディアでも伝えて欲しい。
今はパワーカップルと言う生き方を選んで上手く生きている方々も居る。
羨ましくも良い事だ。
結婚デメリットが多い今の世の中ではあるが、社会が総じて変わっていって欲しい。
そう望む。
ユーザー側のデザインとポイントバラマキにみんな騙されてるけど
楽天の倉庫連携とかExcelベースなんだぜ。WEBベースじゃないんだぜ？
amazon信者ではないけど、最後に参入したamazonのシステムの完成度にビビったね。
何がすごいってシステム的に全て解決してくれて何がエラーでどのように対処すれば良いかの指摘が完璧。
マニュアルもなくて直感でCSV更新も出来るようになって１カ月足らずで楽天・ヤフーに匹敵する売上立ったしなんだこれ。
あ～対人サポートないからでしょとか思うやん？24時間サポートしてくれて何なら深夜でも電話よこしてくれる神対応。
楽天・・・タダイタデンワガコミアッテオリマス～アナタハゲンザイ１０ニンマチデスシバラクマチクダサイ～・・・１時間とかザラ。んでサポで解決出来ず後日回答します～ワカリマセンデシター
ヤフー・・・サポート無し！AIチャットで検討外れな回答のみ。
でも国内企業には頑張ってもらいたい！頑張ってもらいたいけど・・・・amazonには勝てんわ。企業努力とか資本力とか以前にもっと根本的な考え方・ポリシーが違いすぎる。
以上しがない出品者より
そう思うようになった理由がほんと変。
十数年前に、Webで二次創作をすることを私は覚えた。同人活動という趣味があることは、もっと子供の頃から知っていたけど、顔の見えない相手と交流しながらそれをやるという事は、自分のパソコンを持つまで知らなかったのだ。たぶん2008年くらいの事だったと思う。
その翌年くらいにpixivが二次創作オタクの間で爆発的に人気になって、民族大移動みたいに個人サイトからpixivに移っていった。当時の、個人サイト衰退末期くらいの頃に、私が「二次創作活動」が嫌いになった原因がある。
携帯無料ホームページサービスにて、自分の二次創作サイトを初めて持った時には、それなりに楽しんでいた。だが、ジャンルを通して交流の幅を広げていく度に、なんか変だな？ と気づいた。ジャンルの人達、猫も杓子も「かの国」の悪口をブログに書き込むのだ。日常雑記に隙あらば「かの国」disを書き込む。創作をサボり萌語りを休んでも、「かの国」disだけは休まない。要は、ジャンル全体が広く浅く時にはかなりディープにネトウヨ化していたのだ。
二次創作という趣味の場で、それとは全く関係のない政治活動が活発に行われている。それ自体が私にはとても不快なことだった。私はネットの門戸が一般人にも開かれた時の2ちゃんねるの文化に浸かり込んだ人間ではない。けれども、同世代や自分よりも少し上の世代でネットにずぶずぶの人達が、2ちゃんねるを通して右翼思想にどっぷり浸かり込んでいることは一応知っていたので、まぁそういう人達とWeb上の二次創作オタクの多くがカブっているのだから、二次創作界隈が右寄り（一時期はスーパーライトだったと思うけど）なのは仕方のないことなのかと諦めた。
毎日のようにジャンルの仲間達のお友達サイトを見てまわる日々。多くの二次創作者がブログに脈絡もなく「かの国」disを紛れ込ませているのを目撃する日々。そんな日々の中で、最高にヤバいスーパーライト二次創作オタクのサイトを発見してしまった。ブログ開いて秒でそっ閉じ。一目見てコイツはヤベェと思うくらいの極まりっぷりだった。一体何がこの人を突き動かすのだろう？ と疑問がむくむくと膨れあがった。当時は何だかよくわからねぇがヤベェなこの人……と思うだけだったけど、今思えばあれは一種の布教活動のようなものだったのだろう。おかしなブログ記事の数々は気の触れた者のご乱心ではなく、わざと信者獲得のために書かれたもので、二次創作の方はメインではなく釣り針だったのではないだろうか。
同ジャンル者のサイトを転々と見ていくと、ジャンルのオンリーイベントの記録なんかが出てくるわけだが、キレキレスーパーライトのブログ主が、あんなにヤベェ言動ばかり繰り返している割に、他人から遠巻きにされるどころかむしろジャンルの中心でカプとか関係なくちやほやされており、記念写真のど真ん中に美少女のコスプレをしてダブルピースで映っていたりする。アフターにも勿論参加していて、他のジャンル者とキャッキャと交流しているのがわかる。
だが、スーパーライトはスーパーライトとしての活動の手を弛めることはない。時々怖いもの見たさでその人のサイトを覗いたが、常にガンギマリ状態で一つもぶれないようだった。
そんな人を平然と受け入れるジャンル。懐が深いとか、器がでっかいとか、言えるのかもしれない。が、些細なことで揉めては敗者を叩き出しているので、別に緩くて平和という訳でもなかった。
ずっと、もやもやとした居心地の悪さにつける名前もなく、何となくこいつらと一緒にされるのは嫌だと思い続けてきた。だから私は二次創作はするけど二次創作を通して他人と交流することはろくにせず、書いた作品をpixivに投げ捨てるように投稿するくらいだった。
最近、ネットニュースやはてブを見て色々思うことがあった。色々端折って結論だけ言うけど、二次創作界隈という境界のぼんやりとした集団というのも、何か別の活動に使おうと思えば使えるのであり、ただ推しカプのエッチな二次創作が見たいという助平な私欲の為にポリシーも捨てるという人が多くいたりする、ということなんだと思った。
そうとわかったので、二次創作からは本格的に足を洗うことにした。
国際基督教大学（ICU）に2020年9月、「オールジェンダートイレ」が設置されました。
このトイレは、いわゆる「多目的トイレ」や「誰でもトイレ」のように“大きめの個室が1つある”ものではありません。一般的なトイレのように個室が連なっており、ジェンダーに関係なくすべての人が利用できるものになっています。
男女別トイレの「使いづらさ」や「居心地の悪さ」を訴えていたセクシュアルマイノリティの学生たちの声に応えて設置されました。
オールジェンダートイレの設置に携わったICU学生部長の加藤恵津子教授は、「オールジェンダートイレは、人権を大切にするICUのポリシーの体現でありメッセージでもある」と語ります。
