  |
はてなキーワード: 手続とは
ここのところ姓の変更手続きに時間と手間を費やしている。金融関係や仕事関係の変更を済ませ、先日、習い事の教室のことを思い出した。ここでは名札を用意して机の上に置くのである。先生にも、他の生徒さんにも私の正しい姓を覚えてほしい。
授業終了後立ち寄った受付の対応は最悪だった。「もう手続きをしたのだから終了まで旧姓でいいでしょう、変更するには本部に問い合わせなければならないし」と言うのである。本部って何なんだろう？ 本部にどうこうってこの人たちの仕事で私には関係のない話なんだけど……と思いながらも、まあ手間をおかけするのだしと低姿勢で「変えられませんか」と尋ねると、「変える前と後が同一人物だと証明する必要も出てくるので手間でしょう」となんだかよくわからないことを言う。「変更に住民票など必要なら出しますよ」と言っても、本部が……手続きが……と言って変更を渋るのだ。
要するに本部に問い合わせるのが手間らしい。何度も「本当に変えたいんですか｣｢手間ですよ｣と繰り返され、私も意地になって「変えたいです」と繰り返した。｢何で変えたいんですか」とも聞かれ、｢ここでは前の名前でいいでしょう」とも言われた。いいわけないだろうが。
結局私が諦めないので名札と出席簿の姓は変更することになった。事務手続き上は旧姓のままかもしれないが、それは向こうの問題で、私は授業料を納めた領収書があるからもうどうでもいい。
渡された名札用の画用紙にマジックで名前を書くと、事務員は前の名札を抜いて「これは処分していいですね」と言った。そして私の目の前でビリビリに破ったのである。
驚いた。そんなに仕事が増えるのが嫌なのか。女性のためのDV相談室なんてチラシを置いてる公的な機関だよ。ほんと、驚いた。呆れた。
引いて入金してんじゃなくて、ATMで金額入力後の手続きを間違った可能性が高い。
差額を入金して貰え。
会社であれば、向こうはちゃんと経費で落ちるし、契約を結んだ担当者が文句を言われることはない。
ただ「振込担当の人に言って欲しいんですけど〜」と伝えないと、相手が事情を理解できなくてチンプンカンプンかもしれないが。
赤色の郵便局の振替用紙（払込取扱票）だ。あれは受け取り側が手数料を払う。
こういう風に手数料を負担する行為は、お金の振り込みを確実にするためのコストとして存在する。
不正による解雇となれば不正である証拠が必要で、不正だと思いますから解雇しますってのはできないから、手続き上こうなるのは当然。
科学者のポエムが出てきた時にどうかと思うという擁護は通るのに、
科学者の処分の問題も同じように一般人には関係ないという擁護が通らないのは不思議だなと思う。
むしろこの問題は、不正論文やコピペ論文が何年にもわたって放置されていました。という事が一番の問題であって
小保方さん個人の進退はそれに比べたらさしたる問題では無いのに
世間の目は、科学というシステム、理研というシステムの問題より個人の進退なんだから、もうちょっと社会というものに興味を持ってほしいなぁと思うよ。
「本が売れないのは図書館のせいだ」というのがホッテントリ入りしていた。
で、コメントで
「前から図書館ってあったのに、何言ってるのこの人？」的反応が多数だったが、
というのも、数十年前と比べて、図書館の蔵書数もサービスも全く別物であり、
先日読破した図書館に関する本に、政令指定市の貸出冊数の推移が出ていた。
これを見ると、図書館利用の伸びが著しいことが実感できる。
例えば横浜市の年間貸出冊数は、
１９５９年 ２３千冊
１９６１年 １８千冊
１９６５年 １２千冊
１９７０年 ５８千冊
１９７５年 ５０７千冊
１９８０年 ２，３２５千冊
１９８５年 ４，２６０千冊
１９９０年 ５，３２３千冊
１９９５年 ９，１４３千冊
２０００年 １０，８９３千冊
２００５年 １１，６５９千冊
２０１０年 １１，１２２千冊
という具合であり、自分が子供だった頃（７５年）の２０倍の冊数に達している。
・貸出冊数の上限が拡大
・期間延長に柔軟に対応
・「深夜まで開館」が増えた
・貸出予約ができる
・市内他館からの取り寄せができるようになる
・従来はその市区町村に住民票があった人しか図書館カード作れなかったのが、
・バーコード・ICタグ化で、貸出時に行列せずにスムーズに借りれる
・サテライト館が増え、徒歩圏内に図書館が存在するようになってきた
「本の売上の推移」と「図書館の貸出冊数・蔵書数・館数の推移」と「図書館に投入される税金額の推移」を
http://anond.hatelabo.jp/20140430023142 がFtMの方だったのでMtFである自分自身の話など。
5年ほど前に大学を卒業し、普通に新卒として就活をしました。某上場日系企業に内定をもらいました。
その時はすでに精神科に通院していたので、内定後に人事にカミングアウトしました。
人事には「その外見で女性は無理がある」「通称名の使用(当時は改名前でした)も認められない」などと散々言われました。
上司と人事は把握しているがその他には大声では言わない、しかし同期はだいたい知っている。 中には露骨にオカマ扱いしてくる人もいましたが、概ね普通の男性として生活していました。
結局3年ほどでやめました。ホルモン治療をするかしないかぐらいの時期だったので、ここに勤務中は外見の変化は特にありませんでした。
退職してから何人かの友人に「どう扱って良いのかわからないと悩んでいた」と言われました。
次の会社では、特にカミングアウトをせずに過ごしてみようと思って、男性として就活した上で入社時の書類にとりあえず通称名の使用だけを希望して提出したら、黙って却下されてすべて戸籍名で名刺やメールアドレスが作られていました。
まだ外見的に女性として生活するのは厳しい状態だったのですが、戸籍の改名をする都合上通称名の使用実績が必要なので、改めて事情を話して通称名の使用だけを人事に願い出てみたところ、許可されました。ただ、入社してしばらくしてから名前やメアドが代わり、さらに上司から部署全員がいる前でカミングアウトさせられた(改名の事情を説明する必要があったとのこと)ので、結局全員が知ることとなりました。
最初は完全に男性として働いていましたが、ホルモン治療が進み、勤めるうちに何人かの女性社員とは仲良くなり、いわゆる女子会のようなものに参加させてもらったりもしました。
トイレは徐々に他の部署など事情を知らない人が、男子トイレで私の姿を認め引き返したりすることも発生するようになり、非常に気まずかったです。
その次の会社では、普通に女性として就活して採用されました。しかしながら健康保険や年金などの手続き上どうしても戸籍上の性別を伝える必要があったので、人事には伝えました。
人事には「積極的にはカミングアウトしたくはない」「女性として仕事したい」と言いました。これが認められ、普通に女子トイレを使い女子社員として働いています。
スポーツジムにも会社の女子社員と一緒に行き、女子更衣室で一緒に着替えています。シャワーが個室なのでこれがギリギリ可能です。
なお健康診断は近所の病院に行ったところ、名前と電話の声で完全に女性として準備してあったようで、健康保険証を提示して診察券を作るときに発覚し、本来であればわりとオープンな空間での診断が行われるはずだったのですが、別スペースでの個別対応となりました。逆にこういう対応してもらえるほうがありがたい人もいると思うので、おすすめです。東京ミッドタウンクリニックです。
結局見た目次第なので、見た目をがんばって磨くしかないと思いました。残酷ですが現実です。
ちなみに日本より海外のほうがハードル低いので、日本で微妙にパスするなぁと言う時は海外に行ってみると周りの反応変わっておもしろいかも。
「いつ手術するの？」「セックスどうするの？」とかそういう質問ばっかりするのはやめてください。主に男性からそういう質問を受けます。
あと今はパスして女性として生活しているので、三人称は「彼」じゃなくて「彼女」にしてもらえるとうれしいかなぁ。
日本企業はLGBTというかトランスジェンダーへの対応は全く慣れていないし、カミングアウトすると「余計な仕事を増やしよって」という対応をする人もいました。
その一方アメリカ系の会社は履歴書に性別欄もないし、概ね好意的に対応してくれました。アメリカ系おすすめです。
ソフトウェアエンジニアは売り手市場なのと、わりとリベラルな会社が多いと思うので、性別や性的マイノリティであることを理由に採用を取り消されたり、職場での昇進に影響することはその他の業種にくらべればかなり少ないような感じです。その点は非常に幸いです。
ちんこついているので女風呂はどうしても入れないので、本当にやむを得ない場合には男風呂に入ります。だいたい追い返されそうになったり、周りの人がじろじろ見てきます。知り合いと出会うであろう都内の入浴施設は使いません。そもそもなるべく避けるようにしてます。
とある支払いのために郵便局を訪れたのだが、手続きのためには局内に置いてある用紙へ少々記入しておくことと、支払いだから当然現金を用意する必要があった。だが新春の受付は二年連続で人の意向を読めない人らしく、こっちが準備出来てねえってのに窓口の整理番号を印刷した紙を押し付けようとする。というか今年ははっきり断ったのに、あろうことか整理番号を押し付けられたので、まだ要らないと言って一度突き返した。
補足すると、窓口が混んでいても整理番号は準備ができてから手に入れるつもりだったし、更に言うなら窓口は空きまくっていたので、整理番号をもらった瞬間に呼ばれる状況だった。あのまま整理番号を受け取っていたら、窓口に行って準備ができていませんと謝るという、なんとも恥な事態に陥ってしまうわけで。なんだったんだあの受付は。
……来年もまたこんなやりとりが起きるのかなあ。
http://ameblo.jp/tokutake-satoko/entry-11835477480.html
なぜ、女性が非正規に押し込まれているのか。
番組中でも言っていたけど、いまだに「女性労働者は父親か夫に養われているのが前提」。
なぜ、シングルマザーが増えているのか。
ビフォー均等法の世の中では、殴られようがモラハラされようが、離婚すると食えないので女は別れなかった。
女の働き口が増えたことにより、女には離婚するという選択肢が提示された。
暴力やモラルハラスメントは「夫婦ってそんなものでしょ」という認識だったが、世の中の認識がDVに変わり、離婚理由として認められるようになった。
シングルマザーを作り出しているのは、時代の変化を無視して殴り続ける・モラハラし続ける男である。
なぜ、生活保護が利用されていないか。
貧困下に居るとメンヘラ化することが多い。窓口で断られるのが怖くて申請ができなくなる。
単純に制度を知らないとか、メディアで叩かれている様子を見ておびえたりとか、手続きのやり方がわからないといった理由もある。
信じられないくらい手続きが下手糞な場合、重度のうつ状態か、軽度の知的障害の可能性もある。
母親が看護師なら母子家庭でもさほど貧しくないが、その他の職業の場合、ほぼ貧困化している。
貧困家庭の父親は産ませっぱなしのゴミであることが多い。浮気して離婚して慰謝料未払い・養育費踏み倒しという連中も多い。
なぜそんな男どもが子孫を残しているのか。ビッチっぽいブスを（最初だけ）丁寧に口説くからだ。
はてなに居るような男はプライドが高く、美人しか女として認めておらず、ブスを見下し、誰のことも口説かない。
シングルマザーになるような女は、自分の価値を認めてくれる男なら誰でもいいくらいに思っている。
クソ男は落ちそうな女を見抜くのがうまいのだ。そうして金も払わず子供だけ産ませていく。
★ブックオフのビジネスモデルは、一定スペックの古本なら買い取り価格も売り出し価格も均一化したこと。
細かく言えば、古本に多少の価格差がつく筈だが、査定要員の人件費をカットしたのがミソ。
宅急便も、サイズ毎に価格均一化して、料金計測要員人件費をカットしたのがブレークのきっかけ、と聞いている。
★この「一定スペックを満たしていれば、均一価格」というビジネスモデル、不動産に応用できないか？
「１００坪以上なら、面積に関係なく、場所に関係なく、古家付きか否かに関係なく、日当たりに関係なく、
「俺の土地はそんなに田舎じゃない、もっと高く売れる筈」という人は、そのサービスを利用しなければいい
★例えば「５０万円均一不動産サイト」を国土交通省が立ち上げる。
田舎の土地を売り出したい人は、そのサイトに土地情報をアップする。
田舎の土地を５０万円で買いたい人は、そのサイトを閲覧し、１０００件近い物件掲載から、お目当ての土地を入手する
５０万円程度の土地なので、仲介手数料の法定上限額が少額で、不動産業者を介在させられない（不動産業者の人件費倒れ）、
という事情もある。
個人間取引なので、価格交渉トラブルは避けたい。だから５０万円均一にして、トラブルを避ける。
★想定売り主は、「タダでもいいから、親の遺産の土地を早く手放したい」的な人。
「自分は都会住まいなので、田舎への交通費や、権利書類の用意だけで数万円かかる、だからタダでも手放したい」という人。
★逆に想定買い主は、「なんでもいいから、田舎に土地が欲しい」という人。
以前北海道で、荒野を１万円でセールスしたら、購入希望が殺到したらしい。
ヤフオクで「なんでこんなガラクタに？」という高値が付いたりする。
ただ、「ガラクタマニアが小遣いで出せる額」のアッパーは数十万円じゃないか、と。
（１００万円だと、心理的抵抗感がある）
だから５０万円均一にしておく。
★厳密に言えば、
「１００坪５０万円なら、１５０坪は７５万円に、２００坪は１００万円にならなければオカシイ」。
しかし、いちいち土地を実測するのは、土地家屋調査士の人件費が無駄。
「１００坪以上あるかどうか？」のエビデンスは、グーグルアースで代用すればいい。
★「別にタダにしてもいいのでは？」との意見もあるが、５０万円程度の対価がないと、
（つまり、売り出そう、というインセンティブを喪失してしまう）
一方、買い主側にもある程度の対価を要求した方がいい。タダだとイタズラ目当てが横行する
ゆーすけべーさんが以前に作ってたimeeroみたいな感じです。画像Blogをスクレイピングしてエロ画像を効率的に見るサイトです。
なお、先程解約手続きを済ませたので4月末くらいに見れなくなります。エロサイト自体にあまり興味がなく、ローンチしたらやる気が無くなったのです。
テスト駆動開発がやりたく、DSLに強いロック魂を感じたRSpec。
はやりに乗ってBootstrap。
特にCapistranoは名前がキュートでやっていることがカッコイイのでどうしてもやりたい技術でした。
あと、メインとなるRailsはこの記事に書いているスキルの中で唯一経験が無かったというのが一番の理由です。Rubyが好きなのもありますけどね。
いやぁ、退職しようとすると会議室で8時間説教されるって都市伝説じゃないんですね〜。
ところで転職活動をした感覚だと、今より給与が2倍出るところでも簡単に内定が出ることが分かりました。
転職活動やエロサイト作成を通して精神的な余裕も出ましたので、もう少しSIerそのものの問題、仕事の進め方などを熟考した上で、本当に正しいSIerのあり方を考えたいと思います。無理そうなら逃げます。
以上、よろしくお願いいたします。
私はAmazonで物を売っていた。
そう、残念なことに過去形で。
一方的に停止させられてしまったのだ。
Amazon.co.jpにより一時停止されています。]
正直なところ、理由はよくわからない。
メッセージの詳細を見ると
「以前当サイトにて
関連があると判断しました」
と書いてある。
警告をもらうようなことは、しているつもりがないし
本当に心当たりがなかったので
それはわかってるけど、理由がサッパリわからないことを伝える。
「申し訳ありません、それはこちらでもわかりません」
全く連絡手段を持たないらしい。
どんな企業だよとか心のなかでは思いつつ、
そこへの連絡先を聞くと
「公平性を保つため、メッセージでのやりとりのみとなってます」
末端オペレータをチクチクやっても問題は解決しないので
なにかマズイことがあるなら、改善しなければならない。
・勝手ながら一方的に判断して閉鎖したよ。
・残ってる注文の処理はそっちで勝手にやってね。
・FBA倉庫（Amazonに委託販売する時に使う倉庫）にある荷物は
・販売客からのクレーム処理のため、売上金はしばらく返さないよ
そんな内容だった。
その内容の下に、問い合わせ用のボタンが付いている。
早速、こんな内容で送ってみた。
「全く心当りがないので、
なにかマズイことがあるなら教えて欲しい。
ぜひ改善してストアの再開をしたい」
調査内容はセキュリティの問題上開かせません。
アカウント再開はできません。」
なん・・・だと？
こちらはアカウント（ストア）が再開しないと
飯の種がなくなるので、当然必死だ。
これを受けてamazonに返信してみた。
「ご回答、ありがとうございます。
どのような規定に触れたのか知らないことには、
二の轍を踏む可能性がございます。
今後の改善策として教えていただけませんでしょうか。
どうぞよろしくお願い申し上げます。」
正直、内心ムカつきながら書いてるけど
ここは我慢我慢。
で、返事が来た。
再開はできかねる旨、ご連絡申し上げます。
ご了承ください。」
正直なところ、かなり避けたい事態だった。
だが、このメールには続きがあって
要約するとこうだ。
・Amazon内で行われる活動をモニタし、調査する権利があるが義務ではない。
・Amazonが不適切だと思った行為に対して、あらゆる処置を行います。
（Amazon内での出品停止などにとどまらず、財産の差し押さえとかもやれるらしい）
・これらの規約違反について、Amazonは絶対的な裁量を保有します。
なんとか関係改善の糸口がつかめないかと三度目メールを送ってみた。
正直、自分でもしつこいとは思っているんだけど
これがないと収入が消えるのでどうしようもなくなる。
「申し訳ありませんが教えてください。
どういう意味なのでしょうか。
私個人に対して、なにか重大な規約違反があったのでしょうか。」
「アカウントも2度と作らせねーよ？」
と言われると、一体どんな恐ろしいことをしたのか不安になる。
今度の返信は早かった。
及びその関連アカウントについては、
総合的な判断より閉鎖の処置を行わせていただく場合がございます。
同様の処置を取らせていただく可能性がありますことをご理解ください。」
そもそも、関連アカウントって何？みたいな感じですが
試しに、隣にいた親戚の人に頼んで
新しいストアを作ってもらうことにした。
が。
理由は聞かないでください」
という内容の赤文字とともに、申請が途中で止まる。
ここはレンタルオフィススペース。
おそらく・・・と思ってダメ元でアカウントスペシャリストにメールを送ってみた。
アカウント停止を解除していただけないでしょうか。
何卒、ご検討ください」
一番最初のメールが帰ってきた。
一行だけ「重ねてのご案内となりますが」と付け加えられて。
次々とアカウント閉鎖に追い込まれているが
もちろん最初の一人以外は心当りがないに違いない。
先週、オフィスを逃げるように引き払った。
自分にとって唯一の救いは、
他のオフィス仲間も、なんとか立ち直って欲しいと本当に思う。
私はともかく周辺の人間だけでもなんとかならないかと思ったから。
だが。
何回か言葉のやりとりを交わした後
「どうにもなりませんね。
ネットバンキングのオプションである、「ワンタイムパスワード」が「パスワードカード」に変更になった。
そこで罠にはまったので書いておく。
“契約者番号”（１０ケタ：決められた数列）と、
“ワンタイムパスワード” （機械生成のランダム数列）によってログインしていた。
その新しいワンタイムパスワード発行機“パスワードカード”を更新登録する際に、新しい暗証番号を決める事を強制される。
「４ケタ」の新しい暗証番号を決めるように言われるのだが、ここにまず一番目の罠が潜んでいて、それまで使っていたパスワード８ケタよりも短い４ケタのパスワードを決めさせられる時点で、感覚的に「何か新しいパスワードが必要なんだな」という意識になるのだが、これが実は今まで使用していた第一暗証（８ケタ）の代わりの番号だというのだ。
自分でも後から理解して意外だったのは、この“４ケタに減る”という事態が与えるその心象だ。
同じ桁数で文字列を変更しろと言われるのとは全く違った印象で、私は何の疑いもなく“全く新しいパスワードを作らされている”と完全に思いこんでいた。
それは、同じ用途の同じパスワードで「桁数を減らせ」などという指示がこの世にあり得るとは微塵も思っていなかったせいもある。そして当然、その様なことを念入りに忠告する仕組みにもなっていなかった。
セキュリティの問題が叫ばれる昨今、認証の手続きが複雑になるならまだしも暗証番号の類においてまさかの、
“桁数が減る” という事態に対し詳細な説明も無い。
その場合に働く憶測、
「それまでの８ケタの暗証番号はそのままに、何か別の場面でその新しい４ケタの数列が必要になるのだろう」
と自然に考えてしまったのは、日常的に“アカウント作成”に慣れすぎてしまった為だろうか。
銀行側はそのパスワードを“第一暗証”という統一名称で呼んでいるようで、その名称は唯一であるのでそれを提示しておけばユーザーはその“第一暗証”について操作するのだと自然に考えると思っているらしいのだが、そもそもその“第一暗証”という呼び名がこちらにあまり浸透していない事も事態を混乱させた。
こちらとしてはサービスごとに決めさせられる英数字 数ケタの暗証番号はどれもこれも“パスワード”で、それが“第一暗証”と呼ばれているかどうかはなかなか意識の近いところには無い、遠い記憶の彼方を探ればそういえばそんな呼び名だったかも…と思える程度のものだ。
そしてさらに事を複雑にするのは、キャッシュカードの暗証番号、通常皆がATMで入力する４ケタの暗証番号だ。
まず“４ケタ”という印象からして紛らわしいのに、さらにSMBCでネットバンキングをする場合、たまにこの暗証番号が必要になる事がある。どういう時に必要なのか忘れたけど、確かECサイトなどで銀行振込を直接呼び出す系の時だった気がする。ああもう！
さらにさらに！通常、SMBCのネットバンキングを利用する場合に使うログイン画面で、先ほど出てきたパスワード“第一暗証”（４ケタ）を入力する欄が、同じ“第一暗証”という名称のパスワードでも顧客によって、８ケタの人と４ケタの人が混在しているため、入力欄は“第一暗証”という名前で“８ケタ受付”になっている。
今までずっと使っていた８ケタのパスワードが弾かれる！
「あれ？」 再度入力、弾かれる！
「うわ！ ヤバい、なぜだなぜ弾かれる！？、しかしおそらくチャンスはあと1回…なんだっけ、パスワード変えたんだっけ！？」
「でもこの入力欄８ケタだよなあ…８ケタ…うーむ、あれじゃないとしたら何だ！？」と。
そこで第一暗証を新しくした事を忘れてしまった、もしくは理解していない人間が、まさか４ケタにした事など思い出すはずがない。むしろ８ケタであることを確認してしまう。
そしてこれはマズいと思い、サポートに電話してみる事にした。ガイダンスに従いピポパして進む。
いくつか進んだところで、
「お客様の情報を確認する為、契約者番号と“４ケタの第一暗証” を入力して下さい」
ここで明かされる衝撃の事実！４ケタ！いま４ケタって言った！
ログインにキャッシュカードの暗証番号を入力するシステムに変わったの！ クソが！！！
そ
し
て
、
「“第一暗証”が確認できません」
ん……？
ここでやっとサポの兄ちゃんに繋がる。
「えっと、えっと、あの、暗証が、４ケタの、あの番号が８ケタじゃなくてえっと最後になんか言われた気がしてあのその」
（……深呼吸……）
「この電話でさっき４ケタの暗証って言われたんですけど、４ケタの暗証ってアレでしょキャッシュカードの？」
サポ「いえ、新しいパスワードカード登録時に新しく決めた第一暗証４ケタで」
「えっと第一暗証ってログインの時のアレ？あれ８ケタじゃないの？」
サポ「いやですから新しい第一暗証４ケタ決めてもらったやつあんべ？」
ここら辺でうっすら思い出してくる
「え、でもあの４ケタってまだ別の新しいなんかパスワード的なそんな感じのアレじゃないの？」
サポ「それ、第一暗証だしログイン時に入れてた８ケタの代わりだし。4ケタになったし。」
「うわああそかああああ、分かりづれええええええ！！でもまだ2回ミスだから大丈夫だよね？行ってくる！」
サポ「あ、ちょいまち確認するわ。あーお客様さっきこの電話でミスったのもカウントされますんで計３回ミス、みごとネットバンキングストップです乙ｗ」
まじなんだよそれ。心当たりある人はきよつけてに。
元増田です。読んでくださってありがとうございます。
２つ目の記事は初見です。面白そうですね…あとでじっくり読みます。
実は元記事の「レシピ」の項は、「関数型料理」にインスピレーションを受けて生み出したものです。
でも、レシピは本質的に手続きだと思います。手続きがコード上に表れないのは、時に、人間にとっての読みにくさにつながります。
ミュータブルな状態
http://anond.hatelabo.jp/20140411133900
http://anond.hatelabo.jp/20140411144631
http://anond.hatelabo.jp/20140411150212
名前をつけて識別している対象が、その状態が変化しようとも、ブレない、ということが重要です。
ファイルハンドラみたいに、内部の状態を隔離して扱えば、ちゃんとオブジェクト指向になる、と考えています。
先日の会見は見ていないし、展開を詳細に追っているわけでもないけど、TLに流れてくるTWとかを見てると、どうも分かっていない人が多いような気がしてならない。
＞理研の規定によると、「悪意のない間違い」は不正に含まないとされており、小保方氏はこれを根拠に、不正ではないとの主張を申立書で展開した。
【ＳＴＡＰ細胞】研究不正「悪意」争点に 理研「捏造」ＶＳ．小保方氏「勘違い」 - MSN産経ニュース http://sankei.jp.msn.com/science/news/140408/scn14040822020001-n1.htm
＞室谷：それは私のほうからお答えさせていただきますが、その問題につきましてはまだ将来の仮定の問題につきますので、それを前提にお話をさせていただきたいと思いますが。この問題が研究不正ということが認定されましたら、この理化学研究所の懲戒手続き、懲戒規定上の問題というように移っていく可能性はあります。手続き上は付されるということになる可能性が強いと思っております。
【質疑応答・全54問】小保方さんSTAP細胞記者会見全文 「ねつ造と言われた気持ち」「ぶりっ子報道について」ほか | ログミー[o_O] http://logmi.jp/10299
このように現在、「STAP細胞が再現できるかどうか」という問題などとは別に、「小保方氏への処分が適切なものだったか」という問題が生じている。
＞愛知淑徳大の山崎茂明教授（研究発表倫理）は「科学の不正を監視する米研究公正局は、誠実な誤りでないものを不正と定義しており、悪意の有無は問題にしていない。悪意がない間違いだから不正ではないという小保方氏の主張は、国際的には全く通用しない」と話している。
【ＳＴＡＰ細胞】研究不正「悪意」争点に 理研「捏造」ＶＳ．小保方氏「勘違い」 - MSN産経ニュース http://sankei.jp.msn.com/science/news/140408/scn14040822020001-n1.htm
＞残念ながら「悪意」が無かったことを立証するのは難しいだろう。ここでの「悪意」とは「故意」と同義だからだ*1。博士論文からのテラトーマ画像の使い回しは、一つ一つの画像を取り違えたものではなく、ページそのものをスキャンして複数の画像を丸ごとコピーした可能性が極めて高い。これでは、客観的に見ても明らかに「故意」、すなわち「悪意」があったと判断されうる。
小保方さんに「悪意」が無かったことを立証することは可能か http://horikawad.hatenadiary.com/entry/2014/04/08/002241
「学術論文においては手続きが重要であり、画像の改変や使い回しがあれば、たとえ結論が正しくとも不備を追及されなければならない。それでこそ学術研究の健全性と信頼性は保たれる」という意見には私も全く同感だ。
ただし問題は、この「手続き」が学術研究だけでなく労使関係においても遵守されなければならない、ということだ。
報道によると、理研の規定では「悪意のない間違いは不正でない」とされているらしい。
先の引用で、ある教授は米研究公正局が「不正」をどう定義しているか紹介し、「小保方氏の主張は、国際的には全く通用しない」と述べている。
しかし法律論としては、外国の権威ある研究機関による定義や国際的な学術研究での慣例よりも、理研の規定した文言が何より重要となる。
またある研究者は、小保方氏は「「悪意」が無かったことを立証」しなければならないが、それは「難しいだろう」と述べる。
しかしこれは逆で、理研が「これは悪意ある行為であり、不正だ」と判断して処分したのであれば、悪意の有無について立証しなければならないのは理研であって小保方氏ではない。
小保方氏はまだ提訴すると言っていないが、法廷闘争も視野に入れていることは明らかだ。
訴訟になった場合、裁判官がどういう判決を下すかは分からない。
理研による処分は裁量範囲内とされて小保方氏が敗訴することも有り得るが、逆に小保方氏が勝訴することも有り得るだろう。
今回の事件では、小保方氏と同年代の若手研究者が特に憤慨しているように見える。
「自分たちがこんなに苦労しているのに、小保方氏があんなインチキ研究で職を得たり時の人になったりしたのは許せない」という気持ちは分からなくもない。
しかし、今回理研の処分に溜飲を下げて快哉を叫べば、「組織の看板に泥を塗った若手研究者は不当処分してもよい」という悪しき前例を作ることにもなりかねない。
それは現在、小保方氏憎しで燃えている若手研究者にとっても、決して好ましいことでないだろう。
こういうことを書くと、「小保方氏を擁護しやがって」と思われるかも知れない。
誤解のないように言っておくと、私は小保方氏を擁護したいのでなく、若手研究者の被雇用者としての権利を擁護したいのだ。
なお、私の主張が理解できない人やもっとよく理解したい人は、先に引用したログミーの「懲戒規定に抵触する行為では？」の個所を見てほしい。
私はここでの弁護士の説明に全く同感だ。
id:minamiyama1994 さん、反論してくださってありがとうございます。
Haskellファンのご意見がいただけて嬉しいです。元増田です。
記事全体で「関数型言語」と呼ばれているものは「関数型言語一般」ではなく「Haskellや一部OCamlの話題を含むごくごく一部の言語」の話である
わかりにくくてすいません。記事では「関数型言語」の話はしていません。「関数型プログラミング」の話をしました。
「関数型言語」は範囲がよりボンヤリとした表現です。たとえばC言語が関数型言語かどうかをみても賛否両論にわかれるでしょう。
私が記事を書いた目的は、”関数型プログラミングに縁のない人に関数型プログラミングをわかりやすく紹介したい”でした。
その目的のため、「関数型言語」という表記を注意深くとり除き、代わりに「関数型プログラミングをサポートした言語」という言い方をしています。
このスタンスの上で、
”関数型プログラミングをフルにサポートした言語”の代表として、Haskellを紹介し、
”関数型プログラミングへのサポートが片手落ちな言語”として、LispやErlangなどを扱いました(それらのファンの皆、ごめんなさい)。
関数型プログラミング初心者の方は、それらの差異なんてどうでもよい、と考えるのではないでしょうか。
関数型プログラミングとは何が良いのか、を大雑把に知りたい。
そうなのではと考えて、あえて区別せずに記事を書きました。
「たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて」？ モナドはそんな限定的用途のものではないし、パーサの理解とは無関係だ(単にライブラリの設計の問題)。それにApplicativeスタイルのほうがパーサが書きやすいという人もいるだろう
id:minamiyama1994 さんの仰るとおり、モナドはパーサー以外の多くの応用があります。
現状多くのパーサーがモナディックパーサーとして書かれています。モナディックでないパーサーは、あまり多くのユーザーには使われないでしょう。
モナドなどの抽象的な構造が幅を利かせてるお陰で、ライブラリに秩序が生まれ、ユーザーはそれを使いやすく・読みやすくなっている、というのが私の言いたかった主張です。
(なお細かいことで恐縮ですが、ある種のモナディックパーサーはApplicativeでは書けません。その点をお忘れですよ)
「テキスト処理」に対して
お前それShellやPerl、RubyやPythonの前でも言えるの？
「GUI」に対して
この二つは、先人が不利な環境ですごく頑張った成果が現状なのだ、と思っています。
本質的には関数型プログラミングの強みが活かせる分野のはずです。
「個人の技量の話題」
「レシピ」に関しては、関数型プログラミングのスタイルでは、手続きを手続きとして自然に表現できるのに対し、オブジェクト指向ではできない(DSLチックなものになってしまう)、ということを言いたかったのですが、
わかりにくかったですね。
「書きやすい」
(*)関数の例で、関数型プログラミングの無駄の無さを示せた、と思ったのですが…
マヂですか…反論のためのでっち上げとかじゃなくて(失礼)？(追記: Haskellの方が「短く書ける」、のタイポだそうです)
Haskell布教のために有休とって４時間かけて書いたのにーw
撲滅…
ｼｮﾎﾞｰﾝ(´・ω・｀)
なんで育てなきゃいかんのだ。
近年、関数型プログラミングの重要性はいろんなところで叫ばれています。
Javaの最新バージョンに関数型プログラミングに関する新機能が加わりました。
Rubyも昨今、関数型プログラミングへのサポートが手厚くなってきています。
プログラミングの教科書の大手、オライリー社から、Javascriptで関数型プログラミングを行うための解説書が発行されました。
関数型プログラミングへの注目度は高まってきています。
おそらく、みなさんは既にオブジェクト指向が何か、を知っています。
でも関数型プログラミングとは何か、胸を張って語れる人は、周りに見当たらないかと思います。
実際、オブジェクト指向によってプログラミングする方法は、わかりやすい解説があちこちにある一方で、
関数型プログラミングとは何か、何が良いのか、ということについての、よいまとめは見つけることはできませんでした。
この記事を読む方の中で、「関数型プログラミングを取り入れるか・取り入れないか」で切実に悩んでいる人は、おそらくいないでしょう。
この記事はあまり細かいところに立ち入りません。関数型プログラミングを使う側の立場に立って、利点や向き・不向き、それが導くスタイルを書きました。
みなさんは鳥のように飛んで、高い空から、関数型プログラミングとは何か、何が良いのか、を見渡してください。
オブジェクト指向的アプローチは、名前をつけてプログラムを整理する。
関数型プログラミング的アプローチは、汎用部品でなんとかする。
Googleが近年リリースした言語、Goには、”継承”を直接サポートする仕組みが無いことが話題になりました。
また、Mac OSXの基幹ライブラリCore Foundationは、ライブラリ自体はC言語で書かれているにもかかわらず、その設計方針は明確にオブジェクト指向です。
その本質とは"名前をつけて対象を識別し、それを扱うこと"、にあります。
最もプリミティブなオブジェクト指向の対象は、ファイルハンドラです。あるファイルを開いて、読み込んで、あるいは書き込んで、ファイルを閉じる。
これらの処理をまとめたら、わかりやすいですよね？
対象に関する処理を、対象の周りにまとめる。これがオブジェクト指向の基礎的な理念です。
識別することとイコールで比較できることは、とても良く似ています。
イコールによる比較は、オブジェクト指向では鬼門であることが知られています。
PointクラスのインスタンスとColoredPointクラスのイコール演算をどう決めればいいかに、正解はありません(詳しくは"effective java"をご参照ください)。
また名前をつけて識別する対象は、フワフワしていてはいけません。
たとえば、"軍人の階級"をオブジェクトにしたとしましょう。"大佐"クラスのある兵士は名前のフィールドや、性別のフィールドを持っているでしょう。
ところで彼が昇格したときに何が起こるでしょうか。
新たに"少将"クラスのインスタンスが作られます。"大佐"クラスを破棄する前に、名前、性別、その他沢山のデータを引き継がなくてはいけません。フィールドを増やしたい場合はその都度コードに修正を加える必要があります(*)。
なるべくイコール比較を避けたい。対象は不安定なものではいけない。では何に名前をつけて、識別するか。そこにオブジェクト指向技術者の熟練度が現れるのです。
一方、関数型プログラミングでは、特定の何かに名前をつけるより、極力、汎用部品でなんとかしようとします。
関数自体をリストなどのデータ構造に詰めることもよく行われます。
実は、関数型プログラミングというのは本質を表していません。
関数をはじめとして、リスト・ツリーのようなコンテナ、手続きを抽象化したもの、回路を抽象化したもの。
あらゆる対象を値として、合成し、ときに分解し、新しい値を作ります。
変数に適用する処理を作りあげることが、とても簡単だからです。
四則演算が定義されたデータを詰めたデータ構造もまた、四則演算可能だったり。
誤解を恐れずに言うと、オブジェクト指向がトップダウンなのに対し、関数型プログラミングはボトムアップです。
関数型プログラミングをサポートする言語には、沢山の汎用部品が定義されています。
このような構造をインターフェイスとして、様々なライブラリが組まれているので、
たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて、
パーサーを理解できれば、JSONパーサー・ XMLパーサー・markdownパーサー・C++パーサー ... などを理解するのはとても容易です。
理解しやすいこと。これが関数型プログラミングの大きな利点です。
追記:
また、汎用部品と型のお陰で、ライブラリのドキュメントが圧倒的にひきやすい、というメリットも有ります。
Haskellな人がPythonにトライした結果 - Togetterまとめ
関数型プログラミングは「厳密な事前設計を必要とするため、簡単なことをやるのにも時間が掛かる」。
＞＞ map (*2) [1,2,3] [2,4,6]
邪魔な”儀式”や、"おまじない"のコードが徹底的に撤廃されているためです。
関数型プログラミングのコードは、潔癖かつ濃密です。
たとえばC言語でint hoge(int x,int y)が定義されているとき、hoge(3)はなんの意味も持ちませんが(コンパイルでコケますが)、関数型プログラミングでは意味があり、実際に有用です。
上の例では、「掛け算をする」(*)関数は、二引数関数ですが、それに引数を渡して作られた「2を掛ける」関数(*2)は、一引数関数になります。
関数型プログラミングでは、「簡単なことは簡単にでき、複雑なことは複雑にできる。ただし、間違ったことは殆どできないか、全くできない」。
また、静的型付けの力によって、コード補完は非常に強力になっています。インテリセンスの比ではないです。
たとえば、関数中のある表記の型を任意に表示できます(GHC/TypedHoles - HaskellWiki)。
やがてやってくる未来には、プログラムをテキストエディタで書くことは時代遅れになっているでしょう。
統合環境のサポートで、バグやミスの少ない、スムーズなプログラミングができます。
そしてその環境で動くプログラミング言語は、関数型プログラミングをサポートした言語なのです。
以下の様な兆候を感じたら、あなたはそのプログラムを関数型プログラミングで書くべきです。
一般に、オブジェクト同士の相互作用が複雑になるほど、オブジェクト指向では手に負えなくなっていきます。
そういうときは、オブジェクトを直接扱わず、替わりにその"相互作用"を扱うことで、複雑さを軽減するアプローチが有効です。
それこそが関数型プログラミング的アプローチです。
特にオブジェクト指向が有効なのは、プログラミング初心者がそのコードをいじるかもしれないときです。
関数型プログラミングは、強固さと柔軟さの代償として、高い学習コストを伴います。
オブジェクト間の相互作用が複雑でなく、着目している(名前をつけている)概念が安定しているとき。
そして、プログラムをいじる人たちの間で共通理解が図れているならば、オブジェクト指向が有利です。
遅延評価という機能によって、レガシーな言語で扱えなかった、巨大な数を扱うことができます。
関数型プログラミングで書かれたプログラムは、正確さが要求される、金融関連の業界で使われています。
手続きとしてパーサーを記述できるので、テキスト処理プログラムはより理解しやすく、メンテナンスしやすいものになります。
関数型プログラミングを知らない人は、「正規表現でおk」と言いますが、
彼の書いた複雑な正規表現は、半年後には(書いた本人でさえ)理解できなくなっていることでしょう。
手続き一般を扱うことができるので、途中で割り込みのある手続きの表現も容易です。
関数型プログラミングをサポートしていない言語ではコルーチン(ファイバー)などをつかってなんとかするしかありません。
さもなくば、非並行処理では普通に関数として記述できるところを、並行処理のために、Builder,Strategy,Command,Interpreterパターンを駆使して書き直すことになります。
Javascript使いの方は、Deferredなどの構造を使うでしょう(http://qiita.com/KDKTN/items/4c6986049d204f0645d8)。
C++使いの方はBoostで頑張りましょう。破滅的に解りにくいコンパイルエラーメッセージと格闘してください。
もう少し簡単な例をあげます。
あなたは、あるレシピにしたがって、自動的に料理を行うマシンの制御プログラムを書いているとしましょう。
1. まず玉ねぎを炒める。
2. 飴色になったら、肉を加えて炒める。
3. 野菜を加える。
4. 水を加えて煮る。
5. スパイスを加える。
…できませんよね？何故ならば、各ステップの"間に"、マシンのロボアームの位置や動きを調整する処理が必要だからです。
これをオブジェクト指向でやろうとすると、各ステップの副作用として、それらの処理を行うことになります。
そうすると、マシンが二機に増えた時などの変更量は、絶望的なものになります。
あるいは関数として表現するのを諦め、手順全体をDSLで記述できるようにします。
このアプローチは関数型プログラミング的です。しかし関数型プログラミングをサポートした言語の助けなしでは、そのDSLを記述するために沢山のユーティリティーコードを書かなくてはならないでしょう。
オブジェクト指向的アプローチでこの問題をエレガントに解こうとすると、クラス化の粒度を上げる事になります。
野菜クラス、フライパンクラス、ボイルクラス、フライクラス、焼き加減クラス、アームクラス、野菜の大きさクラス、切り方クラス、焼き方クラス、"焦げたよ"クラス、etc...
こうすると早晩レシピはプログラムのコード上から消え去ることになります。上記のたった5行は、依存性注入のオブジェクトグラフを構築するコードに取って代わることになります。そこには沢山の挙動の制御がオプションとして付記されているのです。
カレーなど、ある種のレシピに限定することで、見た目の理解しやすさを得ることができますが、一方それは表現力を損なうことを意味します。
C言語などではマクロを使うこともできますが、それは結局、関数型プログラミング的アプローチの意味するところと同じになります。すなわち、補助のために沢山のコードを書くことになるでしょう。
iOSのAppstoreアプリは、"無料"と書かれたボタンを押すと、それが"インストール"ボタンに変わり、それをもう一度押すと、ダウンロードの進捗を表すインジケータに変わり、それを押すとダウンロードをキャンセルできます。
このように、位置は同じなのに、ステートに依って見た目と機能が変わるボタンは複雑です。
これをオブジェクト指向で実現しようとすると、
という下らない問題にぶつかります。
一方関数型では、"機能"、"見た目"、"状態"、を独立に扱って、それらを合成してボタンを作るので、迷うことはありません。
「同じ位置にあるUIオブジェクトは、コード上で(インスタンスとして)独立して、他から干渉を受けない」
この条件が満たされているうちは、オブジェクト指向でGUIを実現することに無理はありません。
しかし、携帯端末のような小さい画面で、多くの機能を達成するためには、UI要素はコンテキスト依存的に複雑になりがちです。
近年、PCのディスプレイの大きさは、頭打ちになってきました。
画素数は増えているのですが、MacにおけるRetinaのように、複数ピクセルでひとつのドットを表すようになってきています。
これは、ひとつの画面に置かれるボタンなどのUI要素の数は、これから先の未来で増えることはない、ということを意味します。
したがって、未来のGUIのプログラミングは、注意深く機能をピックアップして制限するというデザイナーの努力を脇におけば、
関数型プログラミングの力を頼るしか無いでしょう。
つまり…
Haskell さいこうなのおおおおおおおおおおおおおおおおおお!! おしっこ漏れちゃうのおおおおおおおおおおおおおおおおおおおお(゜∀。)ﾜﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬ
1. google:すごいHaskellたのしく学ぼう を注文する。
2. Download Haskell を自分のPCに導入する。
3. コンソールにghciと入力して、対話型コンソールを立ち上げる。
4. 次の関数をコンソールに打ち込んで、結果を見る。即値で書かれているところとかをいろいろ変更してみて、感動する。
take 4 $ map (*2) [1..]
追記:
いかがでしたか？
ちまたには、関数型プログラミングの利点は変数が無いことだ、とか、より安全だから、とか、より速いから、などという妄言が満ち溢れています。
オブジェクト指向と関数型プログラミングは、水と油ではありません。プログラマは自分のプログラムに最適なアプローチを選ぶことができます。
一般にはあまり知られていないことですが、Haskellにもオブジェクト指向へのサポートがあるんです(Lensライブラリ、これを使用したサードパーティ製ライブラリも最近増えてきています)。
この記事を読んだオブジェクト指向プログラマのあなたが、少しでも関数型プログラミングに(そしてHaskellに)興味を持ってくださって、ホームセンターの大人用オシメのコーナーが大賑わいになれば幸いです。。
来年から施行されるマイナンバー法（行政手続における特定の個人を識別するための番号の利用等に関する法律）を口語訳してみました。とりあえず１章から４章まで。
http://law.e-gov.go.jp/announce/H25HO027.html
この法律は、行政事務を行う人が個人番号（または法人番号）を使って、特定の個人（または法人などの団体）を識別できる情報システムを活用して、効率的に仕事ができるようにするために必要なことを定めるよ。
また、他の行政事務を行う人との間で、すばやく情報のやりとりを行えるために必要なことを定めるよ。
これによって、行政運営が効率化されるよ。また、社会保障分野の公正な給付と税金の徴収がきちんと行われるようになるよ。役所への届出や申請をはじめとした手続が簡単になったり、身分証明が簡素化されたり、国民のみんなの利便性を向上するために、必要なことを定めるよ。
このほか、個人番号や個人情報の取扱いが安全にきちんと行われるよう、以下の法律に関する特例を定めるよ。
１．個人番号と法人番号を使うときは、次のことを意識しないといけないよ。
２．個人番号と法人番号を使って何かするときは、社会保障制度、税制、災害対策に関する分野が便利になるように考えてね。あと、一応それ以外の分野でも便利になるように考慮してね。
３．本人確認が簡単になるから、個人番号カードをどんどん使ってね。でも個人情報の漏洩にならないよう注意してね。
４．情報提供ネットワークシステムは、個人情報をやりとりするのに便利なものだからどんどん使ってね。将来的に個人情報以外の情報もやりとりするから、その辺も気にしてね。
１．国は、基本理念にのっとり、個人番号がちゃんと取り扱われるような取り組みをするよ。
２．国民のみんなに理解してもらえるよう教育活動とか広報活動をするよ。
また、国と連携して、地域ごとの特色に応じて個人番号を利用するよ。
個人番号と法人番号を利用する事業者は、国や地方公共団体の取り組みに協力してね。
１．市長は、住民票に住民票コードを載っけたときには、すぐに個人番号をその人に連絡しないといけないよ。そのときは、通知カードで連絡するよ。
２．市長は、住民の個人番号が漏えいしちゃって、他の誰かに悪用されそうだったら、個人番号を変えてあげて、その人に教えてあげないといけないよ。そのときは、また通知カードで連絡するよ。
３．市長は、住民が個人番号カードを受け取れるように住民への連絡をちゃんとしてね。
４．通知カードを受け取った人は、転入手続きをするときに、通知カードを役所に持ってこないとダメね。転入によって実際の住所と通知カードの住所が違ってきてしまうので、訂正しないといけないから。
５．上記以外の理由で通知カードの記載内容と実際の情報が違ってしまう場合は、１４日以内に役所に届け出てね。（たとえば、結婚とかで名前が変わるときとか）
７．通知カードが自宅に届いたら、希望者には個人番号カードを渡すから、一回役所に通知カードを返してね。
１．市町村は、ある国民に個人番号を割り当てたいときは、地方公共団体情報システム機構（以下、機構で統一）にあらかじめ連絡してね。そのときは、機構で住民票コードを元に個人番号を作るよ。
２．機構は、市町村から個人番号の生成を求められたときは、コンピュータシステムで個人番号を作って、市町村に教えるよ。
生成される個人番号の条件を以下に挙げるよ。
３．機構には、個人番号の生成と市町村へ通知するためのコンピュータシステムを設置するよ。
１．個人番号の利用して良い範囲は、別のところ（別表第一）で定めるからそっち見てね。
２．地方公共団体は、福祉、保健、医療、地方税、防災関係の事務で個人番号を利用していいよ。ここに挙げていないその他の事務でも、条例で定めれば個人番号を使っていいよ。委託された事業者も同じね。
３．個人番号が載った書類を扱う事務の人は、必要に応じて個人番号を使っていいよ。委託された事業者も同じね。
以下の法律でもそう定めるよ。
４．所得税法で決められている一部の人は、大きな災害などで地方公共団体の財政がやばいときは、国が手助けするから、そのときに個人番号を利用していいよ。(激甚災害に対処するための特別の財政援助等に関する法律)
５．個人番号を含む個人情報は、その提供を受けた目的を達成するために使ってね。だけど、第十九条第十一号から第十四号までのいずれかに該当してないとダメだよ。
１．個人番号利用事務または個人番号関係事務の委託を受けた業者は、発注元がOKを出したときに限って、再委託してもいいよ。
２．個人番号利用事務または個人番号関係事務の委託を受けた業者は、以下の規定が自動的に適用されるよ。
個人番号利用事務等の委託するときは、個人情報が安全に管理されるよう、委託先をちゃんと監督しなくちゃいけないよ。
個人番号を扱う事務をする人は、個人番号が漏えいしたり、個人番号が失われたりしように、ちゃんと管理しなくちゃいけないよ。
個人番号を扱う事務をする人は、窓口に来た人や役所などで個人番号にかかわる事務をする人が、同じような書類を何度も提出しなくても良いように、お互いに連携をとって、情報を共有しないといけないよ。
１．個人番号を扱う事務をする人は、事務処理をする上で必要があるときは、本人または他の個人番号を取り扱う事務をする人に、個人番号の教えてもらうができるよ。
２．個人番号を扱う事務をする人は、事務処理をする上で必要があるときは、機構で保存されている本人確認情報を教えてもらうことができるよ。
どんな人でも、他の人（家族とか一緒に住んでいる人を除くよ）に対して、個人番号を教えてもらうことは禁止だよ。
個人番号を扱う事務をする人は、本人から個人番号を教えてもらうときは、その人から個人番号カードまたは通知カードと一緒に、身分証明書を提示してもらうようにしてね。代理人の場合もその人が本当に代理人かどうか確認するようにしないといけないよ。
１．市長は住民が個人番号カードを欲しいと申請してきたときに、個人番号カードを交付してね。そのとき、通知カードは返してもらってね。
２．個人番号カードを持っている人は、最初の転入届を役所に持って行くときに、個人番号カードを役所に提出しないといけないよ。
３．住民から個人番号カードの提出を受けた役所は、個人番号カードの記載内容に誤りがないか確認して、誤りがあれば訂正するなりして、その後に住民に個人番号カードを返してね。
４．個人番号カードを持っている人は、カードの内容に変更があったときは、１４日以内に、役所に届け出ないといけないよ。そのときは、個人番号カードも一緒に提出してね。
個人番号カードは、以下に挙げる機関が本人確認に利用できるよ。また、カード内部にはカード表面に書かれた内容が記録された部分と違う部分に、事務処理で使うためのデータを保存することができるよ。
個人番号カードを扱う事務をする人は、カードの内容が漏えいしたり、失われたりしように、ちゃんと管理しなくちゃいけないよ。
特定個人情報っていうのは、個人番号を含んだ個人情報のことね。
どんな人も特定個人情報を提供しちゃいけないよ。ただし、以下の場合は除くよ。
どんな人も、他人の特定個人情報（他人の個人番号を含むものに限る。）を収集したり、保管しちゃいけないよ。ただし、第十九条に該当する場合は除くよ。
「情報提供ネットワークシステム」とは、行政機関同士がオンラインで相互に接続されたコンピュータシステムのことね。暗号化とその他の仕組みによって、通信内容は簡単には復元できないようになっているよ。「情報提供ネットワークシステム」は、総務省が設置して、管理するよ。
１．総務省は、特定個人情報保護委員会と話し合って、情報提供ネットワークシステムを設置するよ。
２．総務省は、情報照会者から特定個人情報を要求されたときには、情報提供ネットワークシステムを使って、情報提供者に対してそれがあったことを教えるよ。ただし、次の場合は除くよ。
１．情報照会者も情報提供者も、特定個人情報のやりとりがあったときは、以下をログとして記録しないといけないよ。
２．情報照会者と情報提供者は、以下のいずれかに該当する場合には、情報提供ネットワークシステムに接続されたコンピュータシステムに記録し、一定期間保存しておかないといけないよ。
３．総務省は、特定個人情報を求められたり、提供したときは、情報提供ネットワークシステムに記録し、一定期間保存しておかないといけないよ。
総務省と情報照会者や情報提供者は、情報提供等事務に関する秘密が漏えいしないようにコンピュータシステムの安全性と信頼性を確保してね。
情報提供等事務や情報提供ネットワークシステムの運営に関する仕事をする人は、そこで知った秘密を漏らしたり、盗んだりしたらいけないよ。（仕事を辞めた人も同じね）
今日付けで昇進した。俺が課長だ。上司はアホかと思う。仕事はまったく面白くない。そんなやつを昇進させたらダメだろ。嘘でも意識の高い奴を救い上げてやれよ。内示出されて断らなかった俺もクズだけどさ。
さて、これで幹部みたいなもんである。俺は共犯者だと思う。一緒に悪いことをしようと誘われたように思う。だまして採用して、つぶれるほど使い倒して、つぶれたら自己責任だと言ってほうりだそう。そう誘われたように思う。そんな声が聞こえた。
世の中にはつまらない仕事がいっぱいだ。でも、誰かがゴミを回収して、自販機にジュースを入れ、電気を作り、ガラスを作り、封筒を作り、紙袋を作り、保険を売り、電話で質問に答える。海苔を作り、滑走路を掃除して、本を印刷して、信号機を作り、トラックを運転して、血圧を測り、瓶を洗い、白菜を育て、タンカーを動かし、税関手続きを済ませる。プログラミングをして、サーバーを構築して、ネットワーク機器を設定して、ケーブルを這わす。料理を作って、運んで、皿を洗って。そんな人たちが、自分の仕事をたのしくはないものの、必要なものだと信じて、せめて自分は信じて暮らしていく。
仕事は面白くない。それは不幸なことだ。そして俺みたいなのの下の人間は俺より幸せになってほしい。ちょっとでも仕事をたのしいと思ってほしい。俺はもう、面白くもなければ、たのしくもなく、金以外に得るものはない。その金だって独身の俺には、残るばかりだけれど。もし、仕事が面白かったら、世の中が、世界が、金が、職場が違って見えるのだろうか。
そんなことを辞令を貰って思った。
