  |
はてなキーワード: 管理者とは
「〇〇はある（ない）」という話をするときに、〇〇の内容が曖昧なら論じようがないと思うんだけど、そういうところが気にならない人もいるらしい。
「差別」を「不合理な区別であり、かつ、許されない（自由が認められない）行為」と定義するならば、「差別する自由」は、差別の定義からして、ないことになる。
他方で、「差別」を「不合理な区別」と定義するならば（厳密に言えば、不合理、区別も定義する必要がある）、「差別する自由」の有無は、「不合理な区別の自由」に依存する。
（ここでいう「不合理」に「許されない」という意味が含まれるなら一つ目の差別の定義と同じ帰結にたるが、普通はそのような意味までは含まれない。）
第一の定義をとると、ほとんどトートロジーになるので、第二の定義をとるとしよう。
特定の行為を示して、「この行為は許されるべき（この行為をなす自由はあるべき）だから、差別する自由はある（べき）」というのも、当然には成り立たない。
まずは、当該行為が、「不合理な区別」にあたるか考える必要がある。
モスクの持ち物制限・服装制限の例で言えば、一般的な理解では、これは不合理な区別ではない。
モスクは所有者・管理者には、財産権の一環として、誰を立ち入らせるかを決める権利がある。
「特定の持ち物や服装をしている人は、立ち入らせない」ということも、この権利に含まれるのである。
そういう意味で、モスクの持ち物制限・服装制限は、不合理な区別ではない。
（不合理な区別だとしても上記の権利が優先される、という言い方をしても良い。）
だから、モスクの例を出して「差別する自由」はあるといっても成り立たないのである。
これが、モスクではなく、国が所有する施設であったら少し話は違ってくるだろう。
もっとも、その場合であっても、宗教的な施設で教義による裏付けなどがあれば、合理的な区別といえることになる。
まじな話をすると、N予備校のプログラミング入門コースやるのがオススメ。
一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。
月額1000円だけどしっかり勉強すれば一ヶ月の無料期間中に終わると思う。
もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラムで講師曰く去年はこれで二人エンジニア就職を決めたらしい。
内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職に必要な環境構築やセキュリティまでみっちりやる。
で講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。
↓みたいなことが学べる
----
Web ブラウザとは (Chrome, デベロッパーコンソール, alert)
はじめてのHTML (VSCode, HTML, Emmet)
さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)
HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)
はじめてのJavaScript (JS, ES6, エラー)
JavaScriptでの計算 (値, 算術演算子, 変数, 代入)
JavaScriptで論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)
JavaScriptのループ (ループ, for)
JavaScriptのコレクション (コレクション, 配列, 添字, undefined)
JavaScriptの関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)
JavaScriptのオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)
はじめてのCSS (CSS, セレクタ, background-color, border)
CSSを使ったプログラミング (transform, id, class)
Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)
診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)
診断機能の組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)
ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)
LinuxというOS (VirtualBox, Vagrant, Ubuntuのインストール, OS, CUIの大切さ)
コンピューターの構成要素 (ノイマン型コンピューター, プロセス, lshw, man, ps, dfの使い方)
ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)
標準出力 (標準入力、標準出力、標準エラー出力、パイプ、grep)
vi (vimtutor)
シェルプログラミング (シバン, echo, read, 変数, if)
通信とネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)
サーバーとクライアント (tmux, nc, telnet)
HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)
GitHubでウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)
イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)
GitとGitHubと連携 (git, ssh, clone, pull)
GitHubへのpush (init, add, status, インデックス, commit, push, tag)
Gitのブランチ (branch, checkout, merge, gh-pages)
Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)
集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)
アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)
ライブラリ (ライブラリ, パッケージマネージャー, npm)
Slackのボット開発 (slack, mention, bot)
HubotとSlackアダプタ (hubot, yo)
モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)
ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)
同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)
例外処理 (try, catch, finally, throw)
HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsのイベントループ, リスナー)
HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)
HTMLのフォーム (フォームの仕組み, form, input)
HerokuでWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)
認証で利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)
Cookie を使った秘密の匿名掲示板 (Cookie, Set-Cookie, expire)
UI、URI、モジュールの設計 (モジュール設計, フォームのメソッド制限, リダイレクト, 302)
フォームによる投稿機能の実装 (モジュール性, textarea, 303)
認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)
データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)
トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)
削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)
管理者機能の実装 (Web サービスの管理責任, 管理者機能の重要性)
デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)
脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)
XSS脆弱性の対策 (XSS, 適切なエスケープ処理, リグレッション)
パスワードの脆弱性の対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)
セッション固定化攻撃脆弱性の対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)
より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)
安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)
Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)
ExpressのAPI (app, Properties, Request, Response, Router)
GitHubを使った外部認証 (Passport, OAuth)
テスティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)
継続的インテグレーション (CircleCI)
クライアントのフレームワーク (Webpack, Chrome 以外のブラウザでもES6)
DOM操作のフレームワーク (jQuery, jQueryアニメーション, this)
AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)
WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)
RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)
テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)
インデックス (インデックス, 複合インデックス, Bツリー)
集計とソート (SUM, COUNT, ORDER BY, GROUP BY)
「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計、モジュール設計、MVC)
認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)
予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)
予定とユーザーの一覧の表示 (非同期処理, Promise, then)
出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)
出欠とコメントの更新 (Promiseチェイン, リファクタリング)
当時は学生。ちょっとしたドキュメンタリー番組で３日に渡って取材を受けた。本名も出ていた。
ただその内容は今となってはあまり人に見てほしくない自分の内面に関する悩みを吐くもので、当時は幼かったなと今となっては思える。
いわゆる黒歴史を本名と一緒にしてテレビで流してしまったのである。
番組は終了していて公式サイトは既に削除されているものの、当時放送を観た視聴者のブログ、ＳＮＳ、２ちゃんねるのスレッドが数々出てくる。
少しぞっとしてしまった。
今後も変わることの無い本名であるため、一生当時の残骸が自分の看板のように検索結果について来るのか。
もちろん私自身の人に見せても恥ずかしくない活動内容も検索結果に出てくる。
本名で検索するとそれらよりも先にかつての放送の内容が出てくる。
件数としては活動内容２件に対して、かつての放送の記載のあるリンクが６件出てくる。
私がその放送に出たのはたしかに事実であって、今後消えないものだ。
しかし、当時とは比べようもない経験をし、新しい家族を得て、覚悟をもって生きている。
なのに私は今後も誰かにどのような人間か調べられる際にまずその放送のイメージが最初に刷り込まれるのだろうか。
さらに私は最近本名で活動することが多くなった。今後ますます増えるだろう。
過去の自分を否定するわけではないけれど、１０年前のそのような内容が現在の自分を代表するかのように振る舞うのは少し、心外だ。
削除を求めるのは過去を受け入れられない懐の小さい人間だとも思っていた。
ただ、今後の私の人生がそのイメージひとつで誤解されるのはいやなのだ。
消したいわけではないが、大っぴらに公開したままにしておくのは違うと感じる。
悩んだ結果、私は全ての検索結果のリンク先のウェブ管理者へ削除依頼を出した。
被験者は誰？
→人間とシステム管理者とAIの全員。つまり地球にいる（ある）存在。
観察者は誰？
→人間とシステム管理者とAIの全員。つまり地球にいる（ある）存在。
どれかが失われたら全部崩れる気がする。
question
１、情報がたくさん流れています。情報がすべてです。情報を管理しているのは誰でしょうか。
２、情報管理（ほかの重要技術も同様ですが）を担っているシステム管理者に、悪意がないかどうかはどうやって判断するんでしょうか。
３、悪意善意に関わらず、誰かの指示や勝手に空気を読んだりして、
無意識や本人の意志にかかわらず、危険なことをやってしまったり、ありえないデータのねつ造をしてしまうことはどうやって防ぐのでしょうか。
例えば、自分の書いたものを、パソコンやモバイルが出来ない高齢者のデータにすり替えるなど。
４、記憶も情報の一つですが、被験者の記憶とそれに伴う記録は、誰が消去・書き換えをしているのでしょうか。
５、被験者とは誰ですか。
５、よくわかりませんが、この世界が情報による脳の錯覚によるものならば、おそらくシステム管理者自身も被験者です。
もちろんAIも。→question3に戻る。
・自分の不満を晴らしたい際には手段は選ぶべき。人を傷つけないような手段を。今は諦めても時期を経れば状況も取れる手段も色々変わります。
・実験段階のあまり完全ではない情報や技術はどの程度まで信用していいのでしょうか。
既知の問題で、すでにネット上には解決策が書かれていますがわかりにくかったのでここに書きます。
windowsでは同一フォントを上書きすると古いバージョンのフォントが残ってしまいます。
例えば、「aaa.otf」というフォントがインストールされているとします。
そのフォントをコントロールパネルから削除して、「データが微妙に違う別のフォントAAA.otf」をインストールしなおします。
しかしこの場合に、フォントが更新されずにAAA.otfを使おうと思ったらaaa.otfが表示されてしまったという問題です。
そもそもaaa.otfを削除しても引き続き使えてしまうのでaaa.otfが削除できてないという話です。
原因は上書きコピーです。
aaa.otfを削除せずにAAA.otfをインストールすると上書きコピーされてしまい、古いaaa.otfが残ってしまいます。
すると
aaa.otf
aaa_0.otf
aaa_1.otf
aaa_2.otf
del %windir%\Fonts\aaa_0.otf ...etc
と実行して削除します。
このとき、コマンドプロンプトは「管理者として実行」から起動します。
また、対処法として新しいバージョンのフォントは上書きせずに古いものを削除してからインストールするとよいです。
どれも迷うほどの問題とは思えない。
(1)老夫婦
殺してはならない。このケースならば公的支援を受けられる可能性があるので、まだ最善の努力を尽くした状態とは言えない。「公的支援は受けたくない」というのは個人的な趣味に過ぎない。
(2)新生児
殺してはならない。夫婦の事情は夫婦で解決すべき問題であり、他者が忖度することは許されない。もちろん、当該の子を生きながらえさせるために莫大な費用が発生する、その費用を捻出できる見込みがない、という将来はもちろん見えているかもしれないが、「それでも（夫の忘れ形見を）殺したくない」と母親が主張する可能性はゼロではない。いずれにせよ助産婦に「殺す権利」はない。
(3)凶悪犯
殺してはならない。速やかに、当該の自動車を隔離できる施設を準備し（たとえば使われていない埠頭の倉庫など）そこに自動車を誘導、その後、催眠ガスを投入するなどして無力化し拘束するなどの方法が考えられる。そうでなくても、周囲から十分隔離した状況で、拡声器等により抵抗は無力であることを宣言し、武装解除と投降を呼びかける。ただし、抵抗した場合は最悪射殺も視野に入れて配置を行う。凶悪犯を殺す場合でも「殺すしか選択肢がない状況」に至っていなければならない。
(4)凶悪犯２
殺すことはありうる。犯罪の既遂・未遂にかかわらず、人質の命が現に急迫の状況であることが明白ならば、状況を見て（人質の安全を最優先に）犯人の射殺も視野に入れるべきである。これは「刑」ではなく緊急避難的行為であるので死刑を廃止している法にもその趣旨にも抵触しない。
なお「その司令官も彼に妻や子供をすでに殺されているし、対応している警察官の多くの関係者が被害者である」→可能な限り事件関係者は事件対応から外すなどの措置が求められる。行政行為の執行に当たって利害関係者が関与する状況はただでさえ（人道的に）避けるべきであるが、まして行為が「敵討ち」にしか見えない状況であれば、その正当性への疑いを呼びかねないことから、対応する管理者には十分な配慮が求められる。
(5)未知の奇病感染者
原則、殺してはならない。もちろん、法的にこのような危険な感染病の罹患者の権利は制限されうる（数年前のエボラ出血熱の事例など参照）。また、病気を理解した上で「感染を広げてやる」と主張し行動する行為は、普通に群衆を対象とした無差別殺人と変わりがない（たとえば、AIDS感染を知りながらそれを告げずに感染の危険のある行為に及んだ人間が傷害致死の罪に問われることがあるのと同じ）ので、治安維持の権限ある人には速やかな対処が求められる。この場合、普通に「爆弾を所持しテロを予告した犯人」と扱いは同じである。防護服を着用した警察官等により速やかに制圧しての逮捕が妥当である。
もしそれが「いかなる防護服も通用しない強力な未知の病気（？）」を想定しているのだとしたら、その場合、可能な限り、遠隔から麻酔銃等により制圧して逮捕。その後は、法による対応（起訴等）を進めつつ、他の感染者同様、残された時間の範囲内で人道的な対応（治療等）を施すことになるだろう。射殺は、それも不可能な場合の本当に最終の手段である。「死ぬ可能性が高い」から「殺しても良い」という理屈は成り立たない。
「どんなことがあっても殺してはならない」という命題は、「どんな手を尽くしてもどちらかを殺さざるを得ない状況」にあっては実現不可能になるので、「場合によっては殺しても良い」という別の命題によってかえざるを得ない。これが緊急避難という考え方である。たとえば「正当防衛」など。人を殺しうる凶器をもち殺意をもって襲ってきた相手を殺してはいけないとなると、「自分」という人間を「殺してもよい」と判断したのと同じ事になり、明らかな矛盾が生じるためである。この場合、相手を殺してしまっても殺人罪とは見なされない。（「カルネアデスの舟板」論）
ただし、正当防衛などの「緊急避難」が成立するためには、「どんな手を尽くしても～である状況」であることを証明できなくてはならない。もし安易にその拡大解釈を許せば、社会が弱者を切り捨てることを安易に認めることにつながりかねず、危険である（例：大量の医療費を使うのは、別に貧困にあえいでいる人の生活を脅かすので、見殺しにすべき、など。昨今は政治家にもこの程度のレベルの人間が多い）。
以上のようなことは、法理の基本を説く本にはたいてい分かりやすく書いてある。元増田（や一部の政治家）は、ネットに張り付いて小理屈をひねり回し得意がるより、少しは読書をした方がよい。
仕事柄多くの企業の人達と会う機会があり，自社を含む日本の管理職たちの優秀さに感動したのでメモ代わりに気づいた点を書く．
1. 基本的に失敗しない
通常の企業運営であれば，成功するプロジェクトがあれば失敗するプロジェクトも存在する．しかし日本の優秀な管理者のプロジェクトは基本的に失敗しない．
彼らは仕事の内容ではなくコミュ力で戦う．なので，彼らにとってプロダクトの品質不足や赤字はプロジェクトの失敗を意味しない．
赤字のプロジェクトは数字の見せ方を工夫すれば順調なプロジェクトに見えるし，事前に政治力を働かせておけば厳しい追求もない．不十分なプロダクトも同様である．
順調であると報告された赤字プロジェクトには当然，引き続き投資が続けられて赤字を垂れ流すが，発覚する前には昇進か退職が待っているので彼らに失敗はない．
会社ごと吹き飛ばしかねない特大の爆弾に成長することもあるらしいが，基本的にはその前に爆発して不運な管理者を子会社へ吹き飛ばすに留まる．
2. 新しいことに挑戦し続ける
経営層に次期計画を説明しなければならない彼らにとって，既存業務の強化や安定化などといった停滞はなにもしないのと同義である．
積極性にかけた部下の意見に流されず，常に新しく耳障りの良い新規プロジェクトを提案していくことが彼らには求められている．
もし新規プロジェクトの成果が思わしくなくても，前述の通りそれらはすべて成功したプロジェクトとして扱われる．
コミュ力という全てを貫く槍，政治力という全てから身を守る盾を持つ彼らにとって，使える状況が限られすぐに陳腐化する技術など不要である．
技術開発をするよりも食事に行ったほうが仕事になるし，JavaとJSの違いなんて知らなくても良い．
とまあ皮肉っぽく書いたが，コミュ力や政治力は長所であるのは間違いないと思う．
20代ゆとりド真ん中世代の今の私には無い能力であることは間違いないので，うまく見習いつつも本質を見誤らないように成長したい．
https://anond.hatelabo.jp/20160225062051
https://anond.hatelabo.jp/20150519124614
懲りずにエロサイトのアンテナサイト（システム含む）を作ったので投稿してみました。
こりずにエロサイトです。
アンテナサイトは以前から作ってみたいとは思っていたのですが、何しろ情報が少ない。
既存の無料システムなどは使い勝手が悪かったり、そもそも(私が思う)アンテナサイトの体をなしていなかったりと、不満がありました。
なら「私が思う」アンテナサイトを作ってみようと思った次第です。
また、1度作ればシステムを流用でき、昔はやった2chアンテナサイトなども簡単に作れるという打算もありました。
（今は下火ですがそれでも収益を上げることはできるので）
※このシステムは実は数年前に完成させたのですがバグだらけで一度頓挫したのを、1から作り直したものなのです。
これだけです。
正直「アンテナサイトの仕様」という情報はあまりネット上にも書籍などにも落ちていません。
ですかね。
あとはDBにいろいろ情報をぶち込んだので、後々の仕様変更にも柔軟に対応できるようにしました。
今回のアンテナサイトつくりで、だいぶSQL文の勉強になりました。
DBの構造とかもWPなどのCMSを参考にリレーショナル？にしたとり、いろいろカスタマイズしやすくしました。
IN/OUTの比率に応じてアクセスを返す処理についてはかなり悩み、これはみんな情報を出さないはずだなーと思いました。
秘伝のタレ的なものですよ・・・結局「こんなかんじかなー」というのを他サイトや経験を元に推測して実装しました。
都度様子を見て変更するかもです。
お気に入り機能や、検索機能については結構実は力を入れています。
検索機能は実は一番時間をかけています。世の開発者様はすごいですね。
https://eromoe-antenna.link/search.php?page=2&category=3
例えばカテゴリ3の2ページ目を表示、といった複数のパラメータを持つ検索条件をどうやったらMySQLで取得するか、といったことや、
それをページャーにどうやって落とし込んでやれば良いのか、といったことがわかりませんでした。
普段WPを使っているので意識してなかったのですが、こういうところも自作システムの悩みどころですね。
あとはIN/OUTでの処理をするにあたり、一通りの情報をDBに保存することで、後々いろいろ応用を利かせられるように設計しました。
その他には管理画面を設けることで、サイトの更新やお知らせの投稿などを、WP並にとはいいませんが簡単に行えるようにしました。
完全自作です。
もともとPhotoshopで作っていたものがあったのですが、数年前に作ったものだったのでそれを基に開発を進めながら調整していきました。
エロサイトっぽく？ピンクを使ってますが、正直もう少しやりようはあったかなーって思っています。
システムさえできてしまえばデザインは後から変更し放題なので後々の課題ですね。
作るのに1年以上かかってしまいましたが、何とか1システム完成させることができました。
今まではWPでサイトを作ることが多かったので、1からシステムを作り上げて完成させるといった経験は実は皆無だったので、楽しかったです。
今は沢山のOSSや無料ツールがあるので、自作する必要性も減ってきているかもしれませんが、実は自分がほしい機能ってピンポイントで無かったりすることも多いのではないでしょうか？
そういったときには是非皆さんも自作ツールを作ってみてはいかがでしょうか
以上、宣伝がてら、普段お世話になっている匿名ダイアリーにいろいろ書いてみました。
http://innervate.exblog.jp/26821959/
●心臓マッサージを受けた全患者の87%(男性: 86%、女性: 90%)が何らかの骨折(胸骨 and/or 肋骨)をする。
●肋骨の骨折は全体の80%の患者に(男性: 77%、女性: 85%)、胸骨の骨折は全体の65.3% (男性: 59.3%、女性: 78.6%)に見られ、胸骨の骨折はかなりの確率で肋骨骨折を伴う。
https://plaza.umin.ac.jp/GHDNet/07/r2-law.htm
民法６９８条は、「管理者は、本人の身体、名誉又は財産に対する急迫の危害を免れさせるために事務管理をしたときは、悪意又は重大な過失があるのでなければ、これによって生じた損害を賠償する責任を負わない」と規定しています。
昨今アイドルゲームやアニメが多い中、度々話題に上がる「ライブにコスプレしてきていいのか」問題について事の整理と個人的な解釈をまとめたいと思います。
まず、ライブの注意事項にコスプレ可・コスプレ禁止等の記述がある場合はそれに準じたルールとなります。
一般に、公共の場所でのコスプレはマナー違反と言われています。
着替える際にトイレを占拠する場合は迷惑ですね。許可の無い場所での撮影会も通行の邪魔になりますし、管理者への迷惑になります。コスプレ自体TPOをわきまえた服装ではないです。
コスプレ禁止の明記が無いからコスプレしてもいいと判断することもできますが、一般にはコスプレは許可されたイベントにおいて行うものという認識の方が多いのではないでしょうか。
ライブ会場やその周囲もいわゆる「公共の場所」です。よってコスプレはマナー違反と考えられます。
しかし、ライブ会場では大きくキャラクターが印刷されたTシャツや法被、特攻服等の服装の方もいらっしゃいますね。その方たちの服装はコスプレに比べライブの服装として容認されているように感じます。
トイレを占拠しての着替えや、同じ服装をした仲間たちとの写真撮影、TPOから外れた服装であることはコスプレと同様です。
いったい何をもってコスプレはマナー違反と言われるのでしょうか。
個人的には一般の利用者が多く居るような施設(お店や道路等)ではそういった服装をするのは頂けないと感じます。しかしライブ会場内で有れば良いと思います。法被や特攻服は羽織るだけですし、フルグラT等は外では上着を着ていれば問題ないと感じます。
そういった点ではコスプレも会場内だけであればいいのではと思えそうですが、トイレ以外着替える場所もなければ、その服で会場に向かうのもTPOが感じられないので難しそうですね。
あとこれも個人的意見なのですがライブにコスプレは結婚式にウェディングドレスで参列するようなものという表現に頷きます。
最後に
先日の某ライブにてコスプレ参加を複数人(男性女性問わず)見かけたことを受けて書きました。
公共の場所でのコスプレは作品と他のマナーを守っているコスプレイヤーさんにも迷惑をかけていると感じます。また、許可されていない公共の場所での撮影会も管理者や利用者に迷惑です。法被や特攻服等の作品を大きく表した服装も時を場所を考える必要があるのではないでしょうか。
また、時折コスプレにしろ作品の名前等が連想される服装(ライブTシャツ等)をしているときは、その作品の看板を背負っている自覚持って問題行動は起こさないようにと聞きますが、どんな格好をしているにも関わらず行儀・作法をいち人間として自覚することが大切ですね。服装だけでなく行動に関しても重きを置くべきです。
まあ正直こんな個人的意見述べたところで昔からの暗黙の了解とかもありますし空気読んで人に迷惑かけないようにうまいこと立ち回って楽しんでる人もいますし、自分が楽しめるようにある程度目に障ることに対して鈍感になったほうが幸せですよね。
コスプレにおける問題点とは…とかいうタイトルですがあまり本筋に添えなかったですね、申し訳ございませんでした。
ただ、俺はあのブーム乗れなかったんだよ
というか大抵のブームに乗り切れないで数年後からスタートするってパターンが多かったんだけどさ
今回は夏だからやっちゃおうかなと思って
初めてみんとて初めてみるなりみたな感じ
んで、みんながやるようにググったわけよ
なんかようは、コミュニティーごとにSNSやりましょうみたいなそんな感じしかイメージできなかた
なんかその時代はSNSのシステムそのものを会社に依頼して作らせて、サーバー確保して管理者を用意して利用規約つくってみたいなのをそれぞれやってた
あんたが作りたいSNSがあればシステムは用意してるから、あとはあんたがやりたいようにやってちょってやつ？
いわゆるこれっって、流行りのBitcoinのブロックチェーンってやつと一緒なんでないの？
じゃあ、ブロックチェーンがなにかってそっちもよくわかってないんだけど
ようするにお金が銀行を中心とした中央集権なら、ビットコインはユーザーごとに権限がある封建的なシステムってことなんでしょ
よくわからんけど、方程式的に頭で変換するとどんなもんかイメージはできるんだよ
だから、Twitterは中央集権的なSNSとするとマストドンは封建的なSNSといえる
つまり、マストドンってブロックチェーン的なSNSなんじゃないかと思った次第なんだがどうなんよ？はてなのインテリさんたちよ
https://anond.hatelabo.jp/20170726114000
上記記事の補足です。
まず、施設（厳密には児童養護施設といいます）の全てが私が居たようなひどい環境というわけではありません。
一度他の施設の子と交流した事がありますが、そこは皆が心穏やかに過ごしている様子でした。
時折研修に来る教育実習生にも話を聞きましたが、あそこは相当な修羅の国だったようです。
そしてあの修羅の国も今はもうありません。
数年前施設関係者の葬儀のため久々に施設を訪れ、色々な話を聞く機会がありましたが、
流石に色々と問題視されたようで詳細は伏せますがかなり大規模なテコ入れがされたようです。
取り組みが実を結び、今はかなり落ち着いたと聞きます。
しかし落ち付いた、と言っても実情は中の子供にしか解りません。所詮はもう外部の人間ですから。
いつのころの児童福祉施設だろう？いくつか存じ上げているところは、監査もきちんとしているし、所内のいじめなど見受けられないが。
監査は私が居た施設にも定期的に来ました。恐らくは法的な決まりがあるのでしょう。
しかし子供の目から見ると監査というのは見知らぬおじさんがズカズカと部屋に入って来て勝手に押し入れやロッカーを開けるだけのイベントにしか見えませんでした。
あれが毎度毎度気持ち悪くてたまらず下着類をバスタオルで目隠ししていた事を久々に思い出しました。
そもそも思春期の女子部屋の監査くらい女性にさせるという発想すらない人達に何が出来るのだろう…？というのが正直な感想です。
今は流石にそのあたりは改善されているのでしょうか。されている事を願います。
時期としては大体干支が一周するくらい前の出来事です。なのでここ数年ではありませんがそう何十年も昔の話ではありません。
最近は人権意識も高まっていますし、この10年そこらでこんな施設はフィクションフィクション！と笑えるような状態になったのであれば喜ばしい事です。
ただ、学校にも平和な学校と荒れている学校があるように、施設にも平和な所、荒れている所、厳しい所、色々あると思います。少なくとも昔はありました。
監査をしているから、見た範囲では問題無いから、養護施設内でいじめは存在しないというのは危険な考えです。
非行は発見が容易ですが（大抵は見せつけますし）、いじめは巧妙に隠ぺいして見付けようとしないと見付からないケースもあります。
私が施設に居た時、他の子のいじめを担当の保母さんに報告したところとんでもなく驚いていた事もありました。表面上は仲良しでしたから。
＊経緯やら何やらを語ってたらクソ長くなったので簡易版、娘視点
父親の部屋のパソコン- この頃はまだ母親も「あら、パパの部屋で遊んでるのね」くらいの認識だった
DS Lite/DSi- ヒマさえあれば隠し場所を探り、親の留守中や電話中にやり込む。(正規のルートを踏んでプレイしても進行状態に関わらず30分経ったら力づくで取り上げられて電源消されるから地獄だった。城までクリアしないとセーブできないマリオがまともにプレイできなかった。何度か泣いた)
MacBook- 親があんまり使わなくなった頃を見計らって管理者パスワードを変えた。(管理者パスワードを"忘れた"、という設定でいろいろ調べた。チョロ過ぎる。)制限やフィルタを全部外した。調べ物をする、と言ってエロサイトを見た。
3DS- 30分ルールや取り上げは続いた。友達が3DSをなくし、もう一台買った後に出てきた3DSを安く買い取った。友情を粉砕しないレベルのほどよい説得や値切りを頑張った。自分のDSは全力で部屋に隠し、友人から買い取ったDSを母親に差し出した。
iPhone- しばらくケースだけを取り上げスポットに置いていた。暫くしてバレた。その後、同じ色のiPod touchを中古で安く手に入れ、よく似たケースを用意してipodの方を差し出した。母がApple信者じゃなくて良かった。
現在- なんか何も言われなくなったけどやっぱり親がキレた時に「電子機器全部出せェ！！」って言われるから新しく買ったものは最初から隠してる
おしまい、昔緊急事態になった時の「あんた携帯ないの！？」「ママが取り上げたからないよぉ〜…」という会話は滑稽でした(当然フル充電で持ってた)
評価者は技術力がなくてもよいという風潮が日本企業にはたまにあったりしますが
システム部門全体のレベルを上げていくには、評価者に技術力は絶対になくてはなりません。
しかも、システム部門の中で技術力が高レベルな人ほど適格といえます。
優秀な被評価者が集まらない、早々に退職していってしまうなどの問題が必ず発生します。
技術力がない人ほど、技術力がある人を煙たがる傾向がとても強いです。
はてな匿名ダイアリーを開始して最初の記事がこれというのはどうなんだろうと思うが多分匿名ダイアリーは無数に記事があって無限に流れ去っていくのだろうからどうでもいいだろう
もんむすのわかめの話なんだけど
よく考えると若めは勝利世界から来てるわけでぱら世界のわかめとか黒アリは未だ行方不明だなという話が結構ある（特に黒アリの方を俺は心配しているんだけど）
で誰がどこから来てるのかいろんな並行世界の同一人物を並べて行って思ったんだけどそういえばわかめって消滅世界にもいて、死んだかアポ化した結果あの場にはもういなかったんですよね
今思うとくえメスティンの求めていた理想の世界で死ねた、全わかめ中最も幸福なわかめなんじゃないだろうか
僅かな時間とはいえ多分彼女は人間と共にカオス化に抗うことができた。
くえで彼女は人間に火を与えて進化を促し、死に際しては人間たちが己の後継者となることを望んだ…というか同志とか求めてたり若干コミュ障拗らせてたのを考えるに「連鎖の中に入る」ことを望んでいたっぽいわけだけど
あの世界では（多分レベルでは圧倒的に彼女に劣るとはいえ）人間たちは共に戦う同志だったわけで、
それはつまりかつてわかめが火という種を与えた人間が、その種族の最期にわかめの前で与えたものの成果を見せてくれたという事に他ならないのではないか。
暗殺仮面がクロムを見て私にはもったいない花道だなみたいなことを言ってたけど
その成果は暗殺仮面を通じてルカさんから別の暗殺仮面に伝わって途切れなかったわけで
塔わかめが同志となってくれた人間とどんな会話をしていたのか超気になるからサブイベ追加してくださいお願いします
天使様という呼び方はよせとかめっちゃ言ってそうだし人間たちの集めた拙いデータを受け取りながらご苦労だったとか言ってそうだしそういうの見てみたいです
或いはぱらわかめがノートを見て静かに涙を流すとかだけでもいいんです
大企業。名前だけならたぶんほとんどの人が知ってる。毎日定時に帰れて、週休二日で、有給もフル消化できて、給料も福利厚生も申し分無くて、寂しい時は社内イベントや勉強会に出てワイワイできて、仕事もそこそこ面白い。だけどもうダメかもしんない。
俺はエンジニアだ。うちは IT 企業だ。俺はエンジニアとして働くつもりで入社した。面接でもそう言ったし、先輩にも上司にも主張した。衝突も多かったけれど、概ね希望は通ったと思う。今の仕事は面白い。でも、それでも、もうダメかもしんない。こうしてお酒を飲みながら不満を垂らしちゃうほどに。
スーツ強制である。意味がわからない。あんな窮屈な服をわざわざ好んで着るほど俺はマゾじゃない。
営業マンやオフィス街に勤めるビジネスマンだってんならまだわかるけど、違う。田舎に構える拠点だ。俺たちはエンジニアだ。仕事しやすい格好であるべきだ。だからといってさすがに裸は非常識だが、ジーパンくらいはいいじゃないか。
たまにお客さんやお偉いさんが来る時もあるけど、そんなの応接室で応対する奴だけ正装すればいい。なんで俺たちにまで押し付けるのか。本当に意味がわからない。マゾという性癖を押し付けたいの？
ネットニュースは見れるくせに、Twitter は見れない。技術用語で検索して情報収集できることを知らないのかよ。
Stackoverflow や Quora や Qiita も見れない（知恵袋は見れる）。GitHub も Bitbucket も、そしてはてなさえもだ。え？IT企業だよね？何の冗談だよ。全然笑えないぞ。
「情報漏えい対策です」だって？だったら POST だけ禁止すればいいじゃん。一部のサイトはそうしてるじゃん。情シスなのに GET と POST の違いもわからないの？
とにかく不便で不便で仕方がない。管理職は「自分のスマホで見ろ」「制限解除した専用タブレットで見ろ」とかほざいてるんだけど、なんでいちいち PC から離れてそっち見なきゃいけないの？コピペしたい時とかどうすんの？効率って言葉知りませんか？何なの？マゾなの？
ウォーターウォールが常にダメとは言わない。ただウォーターフォールは昔のやり方であって、少ない人材でスピードも求められる現代ではだいたい役不足だ。にもかかわらず、馬鹿の一つ覚えみたいにウォーターフォールで開発しようとする。
テストコード書いて効率化して暇を持て余して改善に勤しむ俺よりも、いっしょうけんめい（笑）ワード使ってコードを日本語にひたすら翻訳するという詳細設計書執筆に勤しんでる奴の方が評価されてるという現実。第一ウォーターフォールに従うなら先にコードができてるのもおかしいじゃねーかよ。
ウォーターフォール続き。開発審査といってこれを通過しないと先の肯定に進めない関所みたいな審査があるんだけど、これがまた冗談みたいに面白い（笑えない）。何十年も（何年も、ではない）前につくられた基準で、かつ無理矢理定量的に解決しようとした体系をしていて、結果、
「x時間に至ってない？それはおかしい。x時間になるまでレビューしろ」
「x時間超えてる？それはおかしい。なんで超えたのは理由を説明しろ」
なんてことが起きている。何なの？ソフトウェア開発がそんなに単純にいくと思ってるの？そんなはずない。みんなわかってる。だけど逆らうこともなく、おかしいとも思わず、ただただ過剰な仕事を投入したり、数字いじりと作文に勤しんだりする。一体何と戦ってるんだよ。
ちょっとした資料でもパワポが強要される。テキストで書くと渋い顔をするし、他部署や他拠点、部長より上向けの資料となると絶対に OK が出ない。
独自フォーマットじゃねえよ。Markdown 知らないの？別に Markdown 覚えろって話じゃない。ちゃんと見易いテキストで書いてるだろ。分量的にも、話題的にもこれで十分だろ。なのにわざわざパワポなの？何がしたいの？パワポ萌えなの？勝手にやってろよ。俺たちまで巻き込むな。
PCとディスプレイは会社側が用意したものしか使えない。Windows 強制。メモリとかCPUは家電量販店で売ってるレベル。いやそっちの方がまだ高性能かも。おいおい、総務とかじゃないんだぜ？エンジニアですぜ？開発マシンだよ？こんな貧弱なマシンでどうしろって言うの？
キーボとマウスとディスプレイ枚数が自由なのがせめてもの救い。といってもディスプレイは会社支給品なので一人あたりどう頑張ってもトリプルだけど。
サーバーで仮想マシン動かしてそっちで開発しようとか、むしろ開発用のハイスペックマシン手に入れようとか画策するんだけど、無理。調達できない。壁が二つ。
上司の壁。「何贅沢言ってんの？」 贅沢じゃねえよ。それ営業マンに向かって「車？何贅沢言ってんの？（原付あるだろうが）」て言ってるようなもんだぞ。
会社の壁。やたら承認やらエクセル申請書やら冗長で数日じゃ終わらない。ちょっと記入ミスってたらやり直し。融通の利かないお役所仕事。そもそもお金が無いからそんな調達できないんだってさ。無いことはないだろ。利益出してんだろうが。その金はどこ行ってるの？お偉いさんがガハハとかっさってんの？
結局、今部署にある分でやりくりしなきゃいけない。だいぶ昔から使ってるやつだから古いし、キャパも限界。使わないマシンを落とさないと他が使えなくて、そのためにみんなに使用状況聞いて回るとかしている始末。おかしいだろうがよ。
え？クラウド？「クラウドに企業秘密置くなんて何事だ！」だってさ。だったら紙で仕事してろよハゲ。
必ずインストールして常駐させるソフトが結構ある。特にセキュリティ系。中には Windows Update みたく動作に支障を及ぼすものもある。お前自身がウイルスじゃねえかよと言いたくなるレベル。
あと全体的に実装が稚拙なようでメモリも CPU もやたら食う。ソース見せてもらえないから何とも言えないけど、初心者がゴリ押しで書いたみたいな臭いがする。これで何百、何千の人間の、いったいどれだけの時間を無駄にしているんだろう。
インフラがとにかく弱い。メンテナンスは日常茶飯事だし、入社年度とか拠点とかでアクセスしていい時間帯を分けるようアナウンスするし、24時間稼働じゃないし、稼働するにしても昼休憩とか夜間とか制限かけるし。自社のインフラさえままならない企業にいったい何ができるというのか。
本当に力入れた方がいいと思う。どれだけ損失してると思ってんだよ。お偉いさんのイベントで主張してみたりもしたけど、俺が浮いただけだった。こういうことに関して鈍感なのがデフォなのだ。
社内システムはほとんど IE しかサポートしてない。バージョンまで固定する始末。UI もレガシーだし、UX も全然考慮されてなくて、フォームを何十個もずらずら並べたみたいなページが普通に登場する。
SVN である。これでもまだマシだ。いや SVN も相当にオワコンだけど（Git 信者が何を知ってるって？いやいや Git 知らないだけでしょ。gitignore が無い時点でどれだけレガシーなのかがわかりませんか）。
ひどいと VSS とかいう化石だったりする。VSSて何ですか？だよね、知らないよね。調べてみるといいよ。面白すぎて笑えない。
今上に立っている人たちが残業何十時間何百時間当たり前の世界でバリバリ頑張ってきた人たちだから、そういう価値観が蔓延している。残業40時間くらい何とも思わない人種である。いや40でも十分多いから。
物理的に仕事が多いならわかる。本質的に難しいことしてるならわかる。残業しなきゃままならないシチュは存在する。でもそんなの見たところ一握りだよ。大半はただだらけてて怠けてて非効率的で無知なだけ。
いや、無頓着というべきかもしれない。たとえばつい先日こんなことがあった。レビューで（俺はレビューア。他にもたくさん）、レビューイがブラウザからファイルをダウンロードした時にブラウザなのかダウンロード先なのかどこかおかして、ブラウザがフリーズしたのね。イラっとするじゃん？と思ったら、したのは俺だけだった。数十秒くらいは続いたのに、俺以外はみんな平気な顔してた。平然と待ってた。そういうことに無頓着なんだ。プログラマの三大美徳を備えろとまでは言わないけど、そこまで無頓着なのは社会人として、エンジニアやビジネスマンとして、どうかと思う。
俺は巻き込まれたくないからうまく立ち回っていて、帰ろうと思えば毎日定時で帰れるが。この体質はほんとどうにかした方がいいと思う。
英数字とスペースを全角で打つのはやめろ。それが許されるの小説だけだ。
インデントはタブを挿入すること ← 俺はスペース派だが、まあわかる。規約ならしゃーない。
「従わなければいいじゃん」 俺もそう思ったよ。でもね、みんなね、レイアウト整えるのにタブ文字を入れやがんだよ。わかるかい、タブ4文字にしなきゃレイアウトが崩れるってことだよ。おかしくない？レイアウトはスペースで揃えよ。タブが許されるのは行頭のインデント部分だけだよ。
この件について戦ってみたことがあるけど、誰一人として賛同は得られなかった。俺は自分勝手な人間との烙印を押されただけだった。エンジニアとして主張すればそうなっちゃうのがうちなのだ。
この件については宗教論争的なこともあるから最悪引き上がる覚悟もあった（それにぶっちゃけ手元のエディタやツールで変えればいいことだし）。でもどいつもこいつも真面目に考えることなく、俺を一蹴した。俺が嫌いだから？何大人げないことしてんの？小学生かよ。意見を見ろよ、中身を見ろよ。
こんなことがあった。
オンプレで立ち上げてるサービスに対して REST API を勝手に使ったら怒られた。曰くシステムがダウンしたらどうなるんだと。業務停止するだろうがと。
言ってることは正しいけど、だったらエントリポイントを閉塞しておけよ。あるいは注意で REST API 使うなと書いておけよ。REST API をデフォでサポートしていて、何の注意や閉塞もなく解放されているなら、それは自由に使っていいってことだろ？（もちろんだからといってリクエストをバーストさせていいわけじゃないが）。悪いのはそんなことも知らなかった無知な管理者だ。責任転嫁するな。
ちなみに閉塞案と注意追加案と提案してみたが無視されている。もちろんそれらを行う権限は俺にはない。
チャットの意義は Pull 型コミュニケーションができることだ。受け取った側の都合で返信できることだ。送る側も、そのことを前提とした上で、期限に余裕のあることを送るのだ。
このことを知らない人があまりに多い。とにかく彼らは口頭を好む。え？あんたら、忙しいよね？むしろ俺は配慮してあげてるつもりなんだけど。口頭で割り込まれることでどれだけ集中を阻害されているかがわからないんだろうか。
まあ俺はいいけど。集中削がれて非生産的になって遅れるのはあんたらだから。俺には関係無い。もちろんそのせいで俺にまで影響が及ぶのだとしたら、そこは全力で反抗する。そういえば以前、この件で上司の上司に対してチャットでみんなに意見を尋ねてみたら、問題行動として垢BAN食らったっけなあ。その部署からは異動しました。
C言語手続きプログラミングマンがあまりに多い。OOPを使っただけで、Ruby スクリで実装しただけ異分子扱いされて「そういう最新技術を誰もが知っているわけじゃない」「自分が知っているからといって無闇に適用するにはやめろ」とか言われる始末。最新技術って。ジョークだったんだろうか。あの時は思い切り笑った。その先輩とは今でも疎遠だ。すれ違っても挨拶してくれない。
まあこれは部署や部門の問題だと思うけど。たとえば OSS で食べてる部隊ではそんなことはない。
昇進するための要件として資格取得がある。公的資格だけじゃダメで、社内独自の資格も必要なんだけど、この資格たち、試験でどうでもいい自社製品うんちくばかり問うてくるものである。はてなを例にするなら、創業時メンバー全員（一人かもしんない。知らん）のフルネームを答えよとか、創業日を答えよなど。
それ、覚えて意味ある？何がしたいの？愛社精神擦り付けたいの？そんなことしても逆に離れていくだけだと思うけど。違うかな。じゃあ何のためだろ。全く見当もつかない。それくらいに不可解だ。
ソフトウェアを新しく使用のにいちいち承認が必要とかいうふざけた制度があった。ソフト使うのって、エンジニアにとっては日常茶飯事じゃん。いちいち承認してたら進まないだろ。
それでもルールなら仕方ない。俺は何十という承認依頼を送った（ちなみに部長以上のお偉いさんが承認者になるという慣習がある）。反応が悪いし、仕事が進まないので口頭でも催促した。一蹴された時は「ならもっと上の人に掛け合います、XXさんが相手にしてくれなかったので来ましたって」的なことを言ったりもした。
結局、俺の部署では「なるべく新しいソフトウェアは使わないこと」「どうしても使いたい場合は自己責任で導入すること」「もちろんウイルスチェックはちゃんとしてね」「実績のあるソフトだけ使ってね」みたいな緩いルールが新設されることでケリがついた。
今でも多くの部署が承認制のままだろう。みんなどうしてるんだろ。それで仕事になるの？
うちは IT 企業なのに、リテラシーに明るくない人がいる。たとえば Wiki の書き方も知らないような人がいる。そういう人が部下を仕切っていたり、社員を支えるスタッフ業務に携わっていたりする。
エンジニアとしてより良いやり方を提案しても、導入しても「難しそう」と一蹴されるばかり。そもそも、ここまで上述してきたことに対してピンと来ることさえない。
厄介なのは、会社そのものがそういう人達に足並みを揃えようとするところだ。だからエンジニアにとっては物足りない、窮屈で、非効率的で、むしろ邪魔にしかならないようなシステムや仕組みや施策ばかりが降ってくる。元を辿れば煩わしいセキュリティソフト群や承認フローの多さも、一部のバカが何かしでかしたせいだ。
一部の人間が足を引っ張っている。大企業であるということ、図体が大きいということは、そういうことなんだと思う。そうするしかないのだろうか？個人的には、エンジニアとそれ以外に二分して、前者には前者のインフラなり体制なり整えればいいと思うんだけども。
うちの会社の連中は、彼らはエンジニアではない。思えば余暇で技術的な話をすることが一切無い。彼らにとって技術は手段でしかないのだろう。エンジニアとしての矜持というものは存在しないのだ。
たとえるならママチャリに乗っている人達みたいなものだ。ロードバイクに乗る人からすればママチャリは手段としてありえない。ロードの方が何倍も早いし、移動範囲も広がる。けれどママチャリ乗りはロードには乗らない。そんな世界があることをそもそも知らないし、知っているにしても努力してそこまで至ろうとは思っていない。今のままで十分だと思っている。
同じなのだ。彼らもまた今のままでいいと思っている。エンジニアリングのエの字もわかっていない。無論、ただのママチャリ乗りならそれでもいいんだけど、俺たちは IT を生業とする会社だ。ロードレースでメシ食べてるようなものなんだよ。なのにママチャリのままなんだ。どう考えたっておかしい。それで勝てるわけないだろ。この先どうすんの。今はたまたま誰も走ってない道を走ってるだけだ。そういう道も着実に少なくなってきているし、ママチャリで頑張って登ろうとするゴリ押しマン要員も減ってきている。
他にも挙げればいくらでも出てきそうだけど、疲れたんでこの辺で。
俺も偉そうなこと書けるほどのエンジニアではないし、ちゃんと読みやすいよううまく書けたか自信ないけど、それでも書かずにはいられなかった。
