「statement」を含む日記 RSS

はてなキーワード: statementとは

2019-07-06

Mastodon創始者Gab対立が本格化

日本ではほぼ注目されていない言論の自由論争「GabによるMastodon参入問題」がついに本格化した。

Gabはこれまで北米オルタナ右翼巣窟と化し、ユダヤ教礼拝所襲撃の予告へ使われた結果、AppleGoogleプラットフォームWebサーバー関連企業から締め出されるという問題を起こしていた。

言論の自由」は尊いが、極右SNSGab」の存続は許されない

https://wired.jp/2018/11/02/gab-offline-free-speech-alt-right/

これらの締め出しによりGabフォークすることが自由であるコピーレフトなAGPLライセンス提供されるMastodonへ参入を表明するという施策を打ち出す。

Gab will become a Mastodon fork

https://news.ycombinator.com/item?id=20051043

それへ対してMastodon創始者のEugen Rochkoは不快感を示しMastodonコミュニティーとして声明を発表した。

Statement on Gab's fork of Mastodon

https://blog.joinmastodon.org/2019/07/statement-on-gabs-fork-of-mastodon/

しかしこのEugen Rochkoによる声明は一部に誤りがある。

Most servers in the fediverse are already blocking the Gab domains

分散SNSサーバー形成するFediberseネットワーク殆どサーバーGabブロックしている(意訳)

この点が誤っている。むしろなのだ

分散SNSサーバー形成するFediberseネットワーク殆どサーバーGabブロックしていないである

そもそもGabMastodonフォークすることが判明した際、まずEugen RochkoはMastodon自体Gabブロックする機能を追加しようとした。

しかし、これはAGPLライセンスの元で提供されている自由Mastodonには相応しくない判断としてMastodonコミュニティーはEugen Rochkoの提案棄却した。

GabブロックするかどうかはMastodonを含んだ各々の分散SNSサーバー管理者が判断すべきことであり、既にMastodonにはドメインブロックの仕組みがあるので、各々の分散SNSサーバー管理者の判断Gabブロックすべきだと反論されてしまったのだ。

Eugen Rochkoはこの反論を渋々了承し、今度は「MastodonクライアントアプリGabブロックする仕組みを導入しよう」とMastodonクライアントアプリ製作者たちへ対して提案した。

これもまた前述したAGPLの兼ね合いの反論が起きたが、一部のMastodonクライアントアプリ製作者は協調Gabドメインブロックした。

そして実際にMastodonフォークGabデプロイされていることを確認したEugen RochkoがMastodonコミュニティーとして出した声明が前述の「Statement on Gab's fork of Mastodonである

誤りがあると指摘した部分もそうであるが、Mastodonコミュニティー全体はこの声明に同意していない

Eugen RochkoはGabを憎むあまりAGPLとしては踏み込みすぎた発言を繰り返しており、度々非難されているのだ。

各々で違うルール運用されている分散SNSサーバー形成するFediverseネットワークには統一したルールはなく、当然ながら統一した意思というのも存在しない

コピーレフトなAGPLライセンスMastodonフォークしたGabはFediverseネットワーク自由に参入することが認められているし、Fediverseネットワークで(現地法令違反しない限りは)自由発言も認められている

Eugen RochkoがGabへ対して不快感を示すのは非常に理解できるが、Eugen RochkoがしようとするGabへの対策Mastodonを含んだ分散SNS自由を脅かすものになってしまっているのが問題である

MastodonGab問題自由を守るため自由を脅かす可能性がある」というリベラリズムにとって非常に興味深い現象に発展している。

2019-06-22

れい新選組立憲民主党 どちらが正しいか (自民党とどちらが正しいか追記しました)

参議院議員選挙が近づき、れい新選組山本太郎議員がした減税のためなら安倍内閣とも組むとの発言が支持者の間で炎上する一方、立憲民主党経済政策を発表するなど、経済ニュースになった1週間でした。山本太郎議員は「2%を目指して物価を上げる」を公約にし、立憲民主党は「上げるべきは物価ではない、賃金だ」を公約にしています。どちらが正しいのでしょうか?

おまんじゅうが10,000個の経済があったします。1コ100円ならGDPは1,000,000円です。

これが翌年90円に値下がりしたとします。数量が同じであればGDPは900,000円です。物価全体が下がることを「デフレ」といいます

名目成長率」はマイナス10%ですが、これは物価10%下落したからで、それを差し引いて考えた「実質成長率」は0%で、名目成長率<実質成長率となりました。

ところでおまんじゅうの値段が下がれば、同じお金おまんじゅうが余分に買えるようになったのだから、とてもよいことのように思います。でも、来年物価が下がるとしたら、企業は人を雇うでしょうか。お金を金庫にしまっておけば同じお金でも来年価値があがって余分に物が買えるようになるのだから、人なんて雇いませんよね。投資が落ち込み、雇われる人が少なくなります。雇われる人が少なく、お給料の総額が減れば物を買う人が少なくなり、次の年はさらに消費も落ち込みますさらに物の値段が下がるのだからますますお金は使われなくなります。こうして物価の下落と経済の縮小がらせん階段を下っていくように進むありさまを「デフレスパイラル」といいます企業の「内部留保」が増えているのはデフレからです。

民主党政権時代物価はほぼ全期間下がり続け、名目成長率は常に実質成長率を下回っていました。だから民主党政権時代は、現金を持っている人、安定した職がある人は「物が安くなった」と幸せでも、不安定な職しかつけなかった人、これから職に就こうとする人にとっては最悪で-デフレになれば売上も下がります仕入れも下がります。ただ同じように下がらないものがあります。それは「賃金」です。正社員賃金には下方硬直性があるからで、それゆえデフレ化で企業にとって一番負担に感じられるのは賃金です。だからデフレになると新卒採用不安定就労層の雇用が一番打撃を受けるのです。-安月給で長時間労働を強いるブラック企業が全盛でした。

物価が上がればどうでしょうか?お金を持ったままだと来年価値が減ってしまますから、人を雇ってより儲けなければなりません。だから企業はより人を雇うようになります

デフレ放置した民主党政権下で雇用ヘロヘロだったのも、2014年に成長率の名実逆転を解消し(17年ぶり)、2017年需給ギャップを解消した(9年ぶり)安倍政権下で雇用が劇的に改善したのも、経済学的にはまったく理に適っています(なお、先日朝日新聞に"年収200万円未満が75% 非正規リアル政治は"という記事がありましたが、この記事アベノミクスによっても雇用に成果がでていないというのであれば明確に誤りです。また雇用環境改善したのは少子高齢化や団世代の大量退職のせいだという人がいますが、それも誤りです。この記事はその点を説明するためのものではないので、詳しくは論じませんが、失業率の分母は生産年齢人口ではなくて労働力人口で、労働力人口民主党政権化では増えておらず、安倍政権下では増え続けているとだけ指摘しておきます。)。

党首討論で、枝野議員は、「経済数字の最終成績はどこなのかと言ったら、やはり実質経済成長率2010年から12年の実質経済成長率は1.8%。2013年から18年は1.1%。これが客観的経済トータルの総合成績であることは、自信をもって申し上げたい。」と発言し、安倍首相に「実質成長の自慢をなされたが、名実逆転をしている実質成長の伸びは、デフレ自慢にしかならない。」と諭されていましたが、まさにそのとおりです。立憲民主党物価を上げずに賃金をあげて雇用も増やすとしていますが、それは卵を割らずにオムレツを作りますといってるのと同じです。

では、上がった方がいいとして、毎年10%も20%も上がるのがよろしくないのは当然として、なぜ2%なのでしょうか?

理由は3つです。まず、それが経済成長にとって最適というのが現時点のコンセンサスからであり、為替レートの安定のためであり、デフレに陥らないためです。

世界各国の中央銀行インフレ目標は2%です。

FRBは「年2%」が物価の安定と雇用の最大化という2つのマンデートを達成するには最適としています

"The FOMC noted in its statement that the Committee judges that inflation at the rate of 2 percent (as measured by the annual change in the price index for personal consumption expenditures, or PCE) is most consistent over the longer run with the Federal Reserve's statutory mandate."

https://www.federalreserve.gov/faqs/money_12848.htm

ECB欧州中央銀行)は中期的に「2%を超えない、但しそこに近いところ」を目指しています

"The primary objective of the ECB’s monetary policy is to maintain price stability. The ECB aims at inflation rates of below, but close to, 2% over the medium term."

https://www.ecb.europa.eu/mopo/html/index.en.html

イングランド銀行イギリス中央銀行)もすべての人の将来の計画を立てるのに資するとして「2%」をターゲットにしています

"To keep inflation low and stable, the Government sets us an inflation target of 2%. This helps everyone plan for the future."

https://www.bankofengland.co.uk/monetary-policy/inflation

オーストラリア準備銀行オーストラリア中央銀行)も「2~3%」のインフレ率を目指しています

"The Governor and the Treasurer have agreed that the appropriate target for monetary policy in Australia is to achieve an inflation rate of 2–3 per cent, on average, over time. This is a rate of inflation sufficiently low that it does not materially distort economic decisions in the community. "

https://www.rba.gov.au/inflation/inflation-target.html

世界の中銀が2%にしているのはそれが経済成長と物価の安定のためには最適というのがコンセンサスからですが(1つめ)、そのなかで日本けがそれより低い目標を掲げるということは、ちょっと物価が上がると他国に先駆けて引き締めますと事前にアナウンスしているのと同じことになりますから、事あるごとに円高が進んでしまます(2つめ)。

3つめの理由は、いったんデフレに落ち込むとなかなか抜け出せないからです。日本経営者アベノミクスデフレが解消しても内部留保を取り崩すことには慎重なままです。経営者マクロ経済学理解しているわけではないので、この20年間合理的だった経営=金をできるだけ使わない=が行動原理として染みついてしまっています。そして高齢化が進行し、低成長が常態になって、常にデフレ圧力がかかっている環境で、インフレ目標をたとえば1%などに設定して、低い物価上昇率をもって金融緩和を止めてしまうと、すぐにデフレに陥ってしまうのです。その失敗を日本2000年と2006年に経験済みで、最近だと昨年末ECBが同じミスを犯しました。

麻生財務大臣から財界幹部朝日新聞まで、ことあるごとに「2%なんて無理なんだからさっさとその目標放棄せよ」と提言していますが、彼らより山本議員の方が正確に経済理解しています

物価が上がった方がいいというのは、私たち生活で感じる直感とは異なります。私も物の値段は下がった方がうれしいです。但し、直感にしたがった行動が、悪い結果をもたらすことはしばしばあります法学経済学、社会学、それを知ることに学問価値があるのだと思います

追記

dc42jk 現在経済状況から金融緩和財政拡張政策の両方が必要だと思う。その両方を掲げているのはれいしかない。自民金融政策に触れてないし立民は金融引締めを示唆している。

まさに。賃金の上昇はどうしても物価の上昇に遅れますし、デフレ脳に染まった経営者を変えるのは簡単ではないので、デフレ脱却の過程ではどうしても、特に安定した雇用を得ていた層の実質賃金が低下します(新たに職を得た人が増えたので、総雇用所得は増えてはいますが)。それを補うために積極的財政支出が求められるのですが、1年目を除き高齢化に伴う社会保障費増以外の財政支出の拡大を渋ったのが安部政権の最大の問題点です。現在国債新規発行のたびに0.1%程度しかクーポンがつかないのにその4倍も5倍も札が入り(落札利回りはマイナス)、政府債務調達はただ同然、これはデフレ現象のものである民間部門の過剰貯蓄、特に企業ISバランスのI<S化と表裏一体です。ご指摘のとおり金融緩和とあわせて財政拡張をしない手はないのに、その両方を掲げているのは国債を財源に、奨学金をチャラにして、最低賃金1500円を政府補償し、公務員を増やし、公共事業積極的に行いますとしているれい新撰組だけです。

(ご参考)

日本財政政策選択肢オリヴィエブランシャール・田代毅(2019年5月

https://piie.com/system/files/documents/pb19-7japanese.pdf

「景気の回復が感じられないのはなぜかー長期停滞論争」ローレンス・サマーズ、ベン・バーナンキポール・クルーグマン、アルヴィン・ハンセン山形浩生翻訳)(2019年4月

https://www.amazon.co.jp/%E6%99%AF%E6%B0%97%E3%81%AE%E5%9B%9E%E5%BE%A9%E3%81%8C%E6%84%9F%E3%81%98%E3%82%89%E3%82%8C%E3%81%AA%E3%81%84%E3%81%AE%E3%81%AF%E3%81%AA%E3%81%9C%E3%81%8B%E3%83%BC%E9%95%B7%E6%9C%9F%E5%81%9C%E6%BB%9E%E8%AB%96%E4%BA%89-%E3%83%AD%E3%83%BC%E3%83%AC%E3%83%B3%E3%82%B9%E3%83%BB%E3%82%B5%E3%83%9E%E3%83%BC%E3%82%BA/dp/4790717313

"Macroeconomics"(12th Edition) " Robert J Gordon2013年

https://www.amazon.com/Macroeconomics-12th-Pearson-Economics-Hardcover/dp/0138014914

(未翻訳ですがアメリカ代表的マクロ経済学教科書です。IS-LM分析の箇所で日本に対する処方箋が取り上げられています。"combined monetary-fiscal policy expansion""The IS and LM curves shift rightward together"れいわの政策はそれに合致しています。)

追記2)

左派リベラルはほんとうに山本太郎に乗ってほしい。今まで何か提言する度に、財源はどうするんだ、そんなことして景気はだいじょうぶなのかと突っ込まれ、やれ法人税増税だ、富裕層増税だ、行政改革埋蔵金だと、見当外れなことを言うだけで(法人税は支払うのは企業ですが負担するのは庶民です。富裕層増税格差縮小の意味はあっても財源にはなりません。埋蔵金なんて結局みつからなかったし、公務員減らせば貧しくなるだけです)、結局有効提案を何ひとつできませんでした。何を言っても信用されないのはそのせいです。

そこに、自民党と異なる価値観を唱えながら、景気はむしろ良くします、財源はありますという政治家が現れました。しかブランシャールやサマーズ、ゴードンのような権威ある学者提案と軌を一にしている。これに乗らない手はないでしょ?

追記3)

立憲民主党は「アベノミクスによって事実上財政ファイナンス化した弛緩した金融政策について、市場と丁寧に対話しつつ、正常化を図っていく。」要するに、日銀による長期国債の買い入れ=量的緩和財政ファイナンスであり、やめますとしています。そのうえで消費税増税凍結を訴えています国債発行も減らして消費税増税分の2兆円もあきらめる、足りない分は金融所得法人税課税するというのだから、その二つの税金は大幅にアップするということになります金融所得に対する課税強化はリスクプレミアムを高めるので、日銀による買入れ縮小と同じく金融引き締め効果があります。すべての経済学の教科書に書いてあるとおり、法人税を支払うのは企業ですが、負担するのは庶民です。

彼らの政策を実現したらどうなるか。FRBが利下げを示唆し、ECB量的緩和への復帰を口にしているなか、日本だけ量的緩和をやめますリスクプレミアムを高めます金融は大幅に引き締めますというのだから円高が急速に進みます物価上昇率は下落し、またデフレに戻るでしょう。企業業績は悪化し、円高特に製造業が打撃を受け、そこに増税が追い打ちをかける。雇用シュリンクし、製造業海外移転拍車をかける特に地方高学歴でない層の雇用やこれから就職する人たちの雇用環境が大幅に悪くなります民主党政権のころの方が実質成長率が高かったから良かったと今でも主張する人たちなので当然なのかも知れませんが、彼らは要するに民主党政権当時に戻します、と言っています。同じく消費税増税に反対していても、デフレが最大の問題だとするれい新選組(「新撰組」じゃなくて「新選組」でした。ややこしいのは良くないと思いますが…)とは方向性がまったく違います

2019-04-05

anond:20190405062220

まず一番最初は「GOTO」を説明しましょう

 ← って、オイオイ、何が悲しゅうて今時BASICなんかの勉強せなあかんねんw

GOTO有害論」(Go To Statement Considered Harmful) から半世紀以上、出来るだけ GOTOを使わずに済ませる方向に頑張って来たと言うのに...

ダイクストラ大先生が聞いたら泣くでぇ

2018-07-13

楽天文句

結構前に楽天株式会社退職していました

noteテストを兼ねて。実は退職してからすでに1年以上が経過しているのですが、ようやく書きたいことがかけるようになったと思われるのでいまさらながら退職エントリを書いてみることにします。

TL;DR

文章にしてみたら、自分がどういう環境で働きたいかが整理できました。自分思考を整理する手段として退職エントリおすすめです。この文章にはそれ以上の価値はありません。

Safe Harbor Statement

ここに書いた内容は僕から見た一方的な内容であり、辞めたひとバイアスがかかっていることをご承知おきください。近しい人が見れば個人特定できてしまうような記述がありますが、個人組織誹謗中傷する意図はありません。

楽天でのおしごと

2011年4月新卒入社。ちょうど6年間、金融関連事業渡り歩きながらWebエンジニアをやってました。お客様に直接向き合うサービスを作る部署なので、開発も運用もやりました。工程でいうと要件定義/設計/実装/テスト/リリースとぜんぶやりました。役割でいうとリードエンジニアっぽい仕事プロジェクトマネージャプロダクトマネージャマネごともやりました。5年目くらいからいわゆる管理職兼任してました。

謝辞

やめる直前はとにかく退職することに全エネルギーを注いでいたうえ、決意を固めてから有給消化という名の出社拒否を行っていたので、お世話になったみなさまにはろくに挨拶もせず退職キメてしまいました。すみませんでした。6年間好きなようにやらせいただきました。自由奔放な僕を多岐にわたり支えていただいた皆様には大変感謝しておりますありがとうございました。

現職について

株式会社ディー・エヌ・エーでお世話になっています。相変わらずWebエンジニアです。素晴らしいタレントに囲まれて楽しくすごしていますエンジニア裁量が大きく、人材に対するリスペクトを感じます自由ライフスタイルマッチします。たのしいです。うぇるかむ。

よかったこ

現職での生活を1年やってみて、良かったなと思うこともまぁ少なくなかったので書きます

面白いことがたくさん起こる

良い意味アグレッシブ会社なので、思いもよらぬ業務提携がおこったり、わけわからんくらい事業が成長したり、(その逆もあったり、)「その発想はなかった」的な新事業が勃発したりととにかく様々なイベントに満ち溢れています。飽きることはないと思います

英語への熱量がすごい

内定式の直後くらいに英語公用語化がうちだされ、「入社日までにTOEICで○○○点とってきてね(とってこないとどうなっても知らんぞ)」的な脅しを人事にかけられました。おかしいな、ドメスティック会社を選んではいったはずだったんだが・・・英語ができない子だった僕は泣きそうになりましたが、さまざまなバックアップ会社提供してくれていたように思います。僕が在籍していた頃は英語一定ラインに達していないと安くはない代償(労基法との兼ね合いどうなってたんだろう?)を支払うことになっていましたが。僕は強要されないと勉強しないタイプなので、結果的英語スキルを身につけることができたのは良かったと思っています

福利厚生が圧倒的にすごい

現職もそれなりに規模の大きい会社ですが、比べてみても福利厚生レベルは圧倒的です。朝昼晩の食事無償提供されてました。会社建物の中にジムコンビニカフェマッサージクリーニングをはじめそのまま生活できそうな設備が整っています研修も充実しています特にエンジニアにとって魅力的なのは海外カンファレンス会社お金で参加できることです。「いいから行け」的にぶっとばされます

事業バラエティがすごい

楽天という会社は中にいても自分たちの会社がどんな事業をかかえているのかわからいくらいにたくさんの事業を持っていますEC金融が有名ですがそれ以外にも大小様々なサービスがあります新規事業への挑戦も常時おこなわれていますライフスタイルも開発スタイル事業ごとにかなり多様性があり、希望すれば社内異動だけでだいたいのやりたいことをかなえることができます

給料が高い

いまでいうとインパクトは薄れましたが、僕が入社した頃はかなり高い水準の初任給を出していたように思いますし、その後もありがたいことに高い評価を頂いていたので(同職種・同年代のなかでは)お給料は高かったほうだと思います

よくなかったこ

主に辞めた理由です。当然にネガティブな内容なので有料にして伏せておきます楽天転職検討している人とか僕の愚痴をよみたい奇特な方向けです。

エンジニアの扱いがよくなかった

これは部署にもよるのでしょうが、僕がいたところではエンジニア立場が悪かったように思います。たぶん僕の被害妄想です。とはいえ、現職と比べると圧倒的に裁量は小さかったですし、ビジネス職のメンバーとの関係も良くなかったと感じます。なんでもかんでもエンジニアが悪いことにされる傾向にあったり、筋の通らない理不尽要求にNOといえるような環境ではなかったとは思います

上司がやっている仕事が楽しそうに見えなかった

僕はたいへん素晴らしい上司にめぐまれていました。そのおかげで好き勝手やってこれたのですが、尊敬する上司仕事は(僕にとっては)つらそうに見えました。自分が将来同じ仕事をやりたいかなと考えると胃がキリキリしてきて絶対イヤだったので。

日本語が使えるとディスアドバンテージ

社内には外国籍メンバーがたくさんいます日本語がまったくできないやつも一定数います。そんなエンジニア日本語サービスを作っています。わからない言語サービスを作るというのは大変なことです。間違った言葉が書かれていても間違っていることに気づけません。利用規約に間違った記述があった日には大変なことです。英語公用語なので、英語が使えても評価されないというのはまぁ受け入れましょう。ただ、かわりに日本語が使えることが評価されるかというとそうではありません。ただ単に日本語がわからないやつの代わりに仕事が増えるだけです。ビジネス人間日本人ばかりで英語使わないことが多く、調整系のタスク忙殺されるのが嫌になったので。

会社がでかいのでイケてない制約がたくさんあった

システムインフラは構築はどこの部署にお願いして、root必要DB操作はまた別などこの部署にお願いして、それが何営業日必要で、とかシステム開発時の制約とか部署またぐ作業リードタイムがなんぼとかいちいちめんどくさい上に新しいことをやろうとすると面倒なことがたくさんあったので。

会社がでかいのでアレなやつが一定数いた

僕が最後に携わっていたサービスが世の中に出たのでちょっとみてみたのですが、平成も終わろうとしているのにjQueryバリバリ2000年台初頭構成Webアプリが完成していました。僕が置いてきたReact+マイクロサービスアーキテクチャは無事闇に葬られていました。僕のチームがコミットしていたリリース日よりも10月遅れリリースでした。どこからともなくさっそうと現れた「そんな複雑なシステム運用できない」などとのたまう向上心のなさそうな、他人アイデアケチをつけるのがうまいベテラン(?)エンジニアがすべてをひっくり返してしまったようです。(そいついかにアレかを13くらいの言葉説明できるのですが長くなるのでやめておきます)その人物提示した見積もりは我々がそれまでに費やした工数3分の1程度だったので、そのとおりに行っていれば去年の夏には終わっていたはずなのですが。そのエンジニアがアレなのは言うまでもないとして、そいつのアレさを見抜けない上長や、IT企業にいながらエンジニアがなにを大事にしているか理解できずに無茶苦茶判断をするビジネス人間に囲まれ仕事をするのが辛くなったので。おかげさまで僕の最後仕事はその案件作成したすべてのソースコードの破棄でした。メンバーには申し訳ないことをしました。

評価理解不能だった

退職を決意した最も大きな理由ひとつです。前職最後の人事考課の結果が極めて不満だったので。「どう考えてもこの人達より僕の評価が低いことはないだろう」と思っていた同じ職位の人間よりも評価が低かったうえに、それに対する納得の行く説明も得られなかったので。その当時僕の評価担当していた上司は非常に管掌が広かったので、いち部下の評価まで細かいことを気にしている場合ではなかったのかもしれませんが。その瞬間この会社に対する信頼は地に落ちました。

半年待ちたくなかった

その後、非公式な場で「評価がまずかったのは申し訳なかった。半年耐えてほしい(※楽天では評価が年2回)」というようなことを何人かの上司から言われましたが、それはつまり半年待った結果として正当な評価を受けられる」という僕がただ半年間不当な評価を受け入れるだけで、特段メリットがない提案でした。そこに対してどのような補填がなされるかといった説明はなく、耐えた後に得られるものも大したことはなさそうで、しかそれから半年間の仕事も特段熱意を注げるようなものではなかったので。

朝会という制度がどうしても気に食わなかった

毎週1回(事業によってはそれ以上の頻度で)朝会があります。朝8時からです。そんな時間に起きたくありません。裁量労働だろうがなんだろうが関係ありません。出社しないとどういう扱いを受けるかはここには明言しないでおきます労基法以下略)。それはヨコにおいておいても朝8時です。内容がつまらないとかではないですが、いちポンコツ社員としては「8時に始まるから7時58分までに出社しなさい」といわれて間に合うように起きることと天秤にかけるほどの重要性が最後まで見いだせなかったので。(というわけで、僕はこの制度が残っている間は絶対楽天に戻りません。)

英語化無理しすぎだろとしか思えなかった

応募者に要求している英語ハードルが高い(割に待遇が良くない)ので、優秀な日本人採用することが極めて難しくなっていたように思います。そのかわり英語はできるけどそれ以外は普通な人物はたくさん応募してきていた印象です。所詮国内に根ざした企業なので、実務で必要になる英語レベルはそんなに高くないです。なので英語ができない人のカバーをするのは難しくありませんが、優秀なエンジニアがいないのを何とかするのは極めて困難でした。会社方針のせいで本当に採用したい人が採用できず、自分目標にしたいと思える人物切磋琢磨したいと思える人物が同じ組織に現れず、いろんな意味で先がなさそうだったので。

管理職は向いてなかった

上司からお話を頂いたときは嬉しかったですし、それなりの使命感をもってやっていたつもりでしたが、いま思い返すと管理職の道を選んだのは失策でした。できることは増えましたが当然にやらなくてはいけないことも増えました。僕がやりたいことではありませんでした。とはいえ当時はやりたくないといいだせる状況でもなかった(と思っていました)し、自分キャリアアップにつながるなら...と打算的なことを考えてもいましたが、僕の考えは甘かったということが後にわかったので。

というようなことを考えていたら働く意欲がなくなったため

以上のような経緯により、それまで持っていたモチベーション迷子になったので。面白いこともまぁまぁあり、ストレスもある環境でした。「それでも会社必要としてくれるなら...」と思っていましたが、「お前の代わりなんかいくらでもいるよ」という空気を感じた途端に熱が冷めました。

まとめ

正直、辞めた当時は自分判断が正しいのかどうかに結構なやみました。勤めていた時はそんなに悪くないと思っていたのですが、現職を経験して思うのはやっぱり楽天エンジニアエンジニアリングするのには向いてないということです。社内政治が得意な方にはおすすめです。

2018-06-14

え?スエズ運河通行料たかすぎっ

1隻あたり平均三千万円〜くらいかかってるらしいが、高すぎない?

これじゃぁ、気軽に旅行にもいけやしない。

2008年統計では21,415隻が通過し、総計53億8100万ドル使用料が納められた。 1隻あたり平均料金は25万1千ドルであ

https://ja.wikipedia.org/wiki/スエズ運河

2017年も同じくらいっぽい。

CAIRO, Jan 4 (Reuters) - Egypt’s Suez Canal revenues rose to $5.3 bln in 2017 from $5 bln in 2016, a statement by the Canal authority said on Thursday.

https://www.reuters.com/article/egypt-economy-suezcanal/egypts-suez-canal-revenues-rise-to-5-3-bln-in-2017-statement-idUSL8N1OZ3UO

2014年情報

> 地中海紅海をつなぐスエズ運河が3年連続通行料の値上げに踏み切る。2012年に3%、13年に5%値上げしており、これに続くものだ。今回の値上げも3~5%とみられており、結果、11年時と比較すると1割近いコストアップとなる。

> スエズ運河通行料は、例えばLNG(液化天然ガス)船であれば1隻1回につき5000万円かかる。1年間に日本の海運会社スエズ運河に支払う通行料の総額は400億円に上る

https://diamond.jp/articles/-/51373

パナマ運河 wikipediaより

> パナマ運河通航料は、船種や船舶の積載量、トン数や全長など船舶の大きさに基づきパナマ運河庁が定めている。 1トンにつき1ドル39セント、平均で54,000ドル。 かつて、アメリカ合衆国連邦政府パナマ運河管轄していた時代には、運河通航料はスエズ運河と比

べても非常に低く抑えられていた。

https://ja.wikipedia.org/wiki/パナマ運河

2017-09-20

科学万能主義への批判への批判への批判

ホッテントリにあったhttp://mubou.seesaa.net/s/article/453600893.htmlを読んだ感想です。

正直に言って、私にはこの著者及びブコメの皆さんは、科学万能主義に侵されているように感じました。

反証可能性下りはまあいいんですが、気持ち悪いのはこの部分です。

一人、あるいは仲間内だけで勝手に「正しい」と言っていることよりも、皆で「正しいかな?正しいかな?」と議論され続けられているものの方が信頼できる。多分当たり前のことですよね?

その辺のことが分かっている人であれば、間違っても「科学は万能である」とか「科学絶対である」なんてことは言えない筈なんです。逆に、「万能も絶対存在しないから、その時点でなるべく妥当だといえることを「正しい」と考えようね」というのが科学、という風に言ってもいいかも知れません。まあこれも随分ざっくりした話なんですが。

残念ながら、科学というのは「何かが正しい」と結論付けるものではないし、ましてや判断基準に「仲間内での正しさ」のような曖昧模糊とした概念が入る余地はありません。

科学的な手続きというのは、全て統計に基づいたものであるべきです。すなわち、ある命題Aが真である確率統計的に与えるのが科学です。実際には、95%信頼区間や、nσで議論されることも多いですが。(もちろん数学論理学は違いますけど、観測に基づく科学、という意味です。)

おそらく、普通の人が「科学事実」といって想像するのは、原子分子があることだったり、あるいはバファリンを飲むと頭痛に効くことだったりするかもしれません。それらのstatementが極めて真であるように思われるのは、様々な測定により、統計的に非常に高い確率(おそらく、少なくとも前者に関しては99.999…9%と、9が101000乗個以上続くような確率よりも下手したら大きいと思います)が保証されているからです。

しかし、新しい学説に関してはこのような確率保障されません。例えば太陽系外惑星存在するかとかタミフルを飲んで異常行動するか、というようなstatementに対する真偽の確率は、もっとずっと低くなります

で、だからこそニセ科学がはびこるわけです。彼らの正しくなさは、科学的にはそんなに高いわけではないのです。(99%以上の精度を持ったことを人体に対して言うには、誤差のコントロールがかなり大変だと思います門外漢なので詳しくないですが…)まともな科学者は、ニセ科学を間違っているとは断言できないわけです。

(まあ正直いえば、ニセ科学とはされていませんが、「納豆が体にいい!」みたいなのもわりかし同じようなレベルの話だとは思います。)

ということで、私の感想をまとめると、

そもそも、「科学的に正しい」という概念はない。それは科学万能主義です。

観測事実に対し、何かが絶対に正しいと断言できるのはニセ科学者だけ。

です。

(この手の、「科学解釈」みたいな記事を見るにつけ、◯◯界隈で、『絶対に✕✕である』と断言している先生方の影響で、間違った科学観が広まっているのを危惧しています。)

2017-05-25

[]一応マニュアルのとこ

http://anond.hatelabo.jp/20170524171732

id:yosukegatzさん

FAQはあくまFAQだからね。手続き正当性をなぜFAQでみているのか、どの部分を持って手続き問題がある、とツイート主がおっしゃってるのかわかりませんが、マニュアルにちゃんと書いてあって、ふつうに執り行われてる手続きであるとは思いますよ。そもそも国連特別報告者はあくまで準司法quasi-judicialで、問題提起大事だって書いてあるし、これが初動なわけだから、内容が不適切だとおっしゃるなら質問にちゃんと答えりゃいいんですよ。とりあえずツイート主が言ってることは根拠がないですよ。むしろ人権侵害がある国にこそ公開でやることで回答する動機づけをしてるのは明らかだし。

国際機関を含む多国間交渉の場は利害も考え方もまちまちだから手続き大事で、そこを外すと何も進まなくなる。日本政府問題を指摘しつつも誠実に対応する(ことが求められる)が、他の国(人権侵害のひどい国)なら「回答する前に書簡政府攻撃に使われた」として回答拒否の口実にしてくるはず。

これは実例に照らして真反対。緊急性や重大性が低く、相手がちゃんと回答してくる可能性が高い場合にこそconfidentialにしている。

今回の書簡基本的には「質問」であり、当該政府からの回答に加え、別途行ったその他の調査内容と合わせて検討し、国連人権理事会報告書を提出するのが特別ラポルトゥールへの委託内容。その報告書はまだ単なる個人作成文書であるがこの時点で公開されて議論対象となる。書簡公開はルール違反

これも事実誤認ルール違反じゃない。ちゃんと書いたように,マニュアルに認められている。

送られた書簡とそれに対する受け取った回答の文章は、受任者が対応した報告書作成するときまで機密にするか、受任者が、特定の状況によって、それ以前に行動が必要であると決定する。

37. The text of all communications sent and responses received thereon is confidential until such time as they are published in relevant reports of mandateholders or mandate-holders determine that the specific circumstances require action to be taken before that time.

プレスリリースを即座にすることも認められている。

重大な懸念や、政府書簡に対して本質的な回答が出来ない状態が続く場合などの適切な状況では、受任者は個人で、あるいは他の受任者(特別報告者、作業部会など)プレスリリースプレスカンファレンス、その他の公的意見表明などを行う場合がある。

一般的に言って、受任者は政府との対話の中で、プレスリリースなどのプレス向けの声明を発出する前にそのことを明らかにするべきである。受任者が、書簡の中で、プレスリリース等をすぐにおこなう意向を示したい時は、書簡の中にそのような意向記載することが出来る。受任者は、懸念された国からの応答に対しても公平に明らかにするべきである

49. In appropriate situations, including those of grave concern or in which a Government has repeatedly failed to provide a substantive response to communications, a Special Procedure mandate-holder may issue a press statement, other public statement or hold a press conference, either individually or jointly with other mandate-holders.

50. In general, mandate holders should engage in a dialogue with the Government through the communications procedure before resorting to a press release or other public statement. When a mandate holder sends a communication with the intention of issuing a press release shortly thereafter, such intention could be indicated to the Government in the communication. Mandate holders should indicate fairly the responses provided by concerned States.

とされているように、初動が一方的に公開であることは別に認められているし、反論公平性は、反論文を同じ場所に掲示することで保とうという意思が見える。

また前に書いたように、イギリスのSnooper's charterについては、就任直後にガーディアンインタビューでいきなり問題提起しており、不必要テロ危険性をマスコミ翼賛的に報道している状態に苦言を呈しているけど別にイギリスは「反論の機会もなしにメディアでしゃべるなんて!」とも批判もしてない。(なぜインタビューされたかというと、このケナタッチ氏の就任は、アメリカメルケルとかを盗聴してたことが明らかになったのちだったので、親アメリカ派のエストニア候補が反対されたという経緯でヨーロッパではその就任が注目されていた。)そしてイギリス政府は、ガーディアン政府見解を送り、ガーディアンもそれを掲載した。ただそれだけの話なんだよ。

 当然指摘は一方的になされるので、誤認があるなら反論すればいいだけなんだよね。我が国対応が際立ってみっともないだけ。

とりあえずツイート主はFAQじゃなくってマニュアルを読んだ方がいい。

2016-07-25

gitにおけるコミットログ/メッセージ例文集100

私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくま単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。

要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのであるググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか

仕方なく自分でまとめたので、増田に垂れ流しておく。

はじめに

ここで挙げているコミットログは全て実際のコミットログから転載である。当然ながら各コミットログ著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユース範囲なら許してくれるだろうと考え名前プロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。

抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリGitHubSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した(あわせて前処理として、コミットログ冒頭のタグ情報は消去した)。

結果として対象としたリポジトリは以下の通り。

atomのみ5400件抽出していたため、計25400件のコミットログベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。

こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である個人的に「うーんこの」と思った表現も、散見される場合は載せた。

ということで、以下用例を羅列していく。

用例集

オプションフラグメニューを追加した
ファイルを追加した
メソッド機能を追加した
実装を別のものへ切り替えた
  • Use args.resourcePath instead of args.devResourcePath
  • Use arrays instead of while loops
  • Use auto instead of repeating explicit class names
  • Use weak pointer instead of manual bookkeeping
  • Change all uses of 'CInt' to 'Int32' in the SDK overlay
  • Change Integer#year to return a Fixnum instead of a Float to improve consistency
新しく何かに対応した/機能上の制約を取り払った
何かを使うようにした
より好ましい実装に改良した
何かを出来ない/しないようにした
  • Don't bail reading a metadata instance if swift_isaMask isn't available
  • Don't exit until the parent asks for an instance
  • Don't include Parent pointer in Nominal/BoundGeneric TypeRef uniquing
  • Don't use MatchesExtension for matching filters
  • Don't use ES6 class for AutoUpdater windows class
  • Don't use MatchesExtension for matching filters
  • Avoid `distinct` if a subquery has already materialized
  • Avoid infinite recursion when bad values are passed to tz aware fields
オブジェクトの内容や挙動確認やすくした
Assertを追加した
不要コードを除去した
コードを移動した
名前修正した
さなバグタイポ修正した, 警告を潰した
バグや好ましくない挙動修正した
テストコメントドキュメントを追加した
テストを削除した
テストコメント修正した
ドキュメント修正した

表現傾向とまとめ

以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。

Add1149
Fix1014
Update584
Remove566
Use382
Don't260
Make228
Move178
Change103
Rename85
Improve76
Avoid68
Allow65
Implement60
Handle58

コミットログの基本形はもちろん動詞 + 名詞である名詞固有名詞複数形、不可算名詞が多いが、単数形場合冠詞は a が使われるか、あるいは省略される。the はまず使われない。

何かを追加した、という表現では非常に広く Add が使われる。メソッドからテストドキュメントに至るまで大概これでまかなえる。

一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typocrash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である

Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合Make sure が使われる(こちらはthat節が取れる)。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う(Ensure はさらに重い表現っぽい)。

また、Fixtypo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメントコメントテストに使われ、本体コード修正に対しては使われない。本体コード修正にあわせてテスト更新したなら Update が使われる。ただ、テスト機構それ自体バグ修正したなら Fix である

無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)からのもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合Don't use を使うことが多い。

何かをしないようにしたなら Don't を、内部実装効率化なら Make A + 比較級/形容詞Improve が使われる。

中身の変更を伴わない単なる名前の変更なら Rename A to B、コード機能論理上の場所を移動させたなら Move A to B である

この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。

余談

コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である

一方で、シンプル単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。

おわりに

8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体効率のいい学習になるという話と同じだと思う。

このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。

2016-03-19

HPVワクチン副反応に関する3/16の発表に関して

初めに

HPVワクチン脳障害が!というニュース話題を集めている。

マスコミ各社で大体の論調は同じだが、最もブクマ数が多そうなのは以下の記事である

子宮頸がんワクチン副反応「脳に障害」 国研究班発表 (TBSJNN)

http://headlines.yahoo.co.jp/videonews/jnn?a=20160317-00000008-jnn-soci

まず言っておくとすれば、マスコミ記事は強くミスリードを誘うものであるという点だ。

詳しくは後述するが、元の資料では「脳に障害」が起こったとは書かれておらず、またそれがワクチン副反応であるという根拠も書かれていない。

記事大本である資料厚労省の以下のページから入手できる。

ヒトパピローマウイルス感染症予防接種後に生じた症状に関する厚生労働科学研究事業成果発表会

http://www.mhlw.go.jp/stf/shingi2/0000116636.html

子宮頸がんワクチン接種後の神経障害に関する治療法の確立情報提供についての研究 池田修一氏 発表資料PDF23,903KB)

http://www.mhlw.go.jp/file/05-Shingikai-10901000-Kenkoukyoku-Soumuka/0000116634.pdf

以下ではこの資料を元に今回の発表の内容について解説していく。

なお、特に注釈がない場合HPVワクチンという単語サーバリックスガーダシルの双方を指すものとして扱う。

池田氏らの発表について

資料は3部分に分割できる。

 (1) HPVワクチン副反応"疑い"の症例についての報告

 (2) 患者のHLA型調査

 (3) マウスを用いた実験

(1) HPVワクチン副反応"疑い"の症例についての報告

信州大学受診した123名の患者の中からHPVワクチン副反応否定できない98例についてその症状を詳しく見て報告した、というものである

主な病態としては、末梢性交感神経障害(起立性調節障害{OH、POTS}、複合性局所疼痛症候群{CRPS})、

高次脳機能障害(学習障害、過睡眠、奇異な麻痺)、自己免疫疾患の併発(RA、SLE他)が挙げられている。

なお、自己免疫疾患の併発については根拠が弱く、資料中でも疑問符付きで述べられていたことを付け加えておく。

また、HPVワクチン副反応否定された(他疾患と判断された)25例についても、

一部の疾患(てんかん、SLE、若年性関節リウマチ)はHPVワクチンに関連しているかもしれないと仄めかしている。

個々の患者データ自体は、それが副反応で有るにせよ無いにせよ有用ものであり、患者の救済・治療観点から重要である

しかしながら問題点もあり、その最たるものが「副反応否定できない」が途中で根拠なく「副反応」にすり替わっていることであろう。

この研究はControl(非接種群)と比較をおこなっておらず、各症状が接種者に特有なのか、接種者で発症頻度が高いのか等は分からないのにも関わらずだ。

さらに、他疾患との関連については、論文(*1)を引用してHPVワクチンでは自己免疫疾患や横断性脊髄炎の発生リスクがあると述べているが、

その論文では「他のワクチンと比べて発症頻度は高くない」と結論付けられているため、誤読意図的ミスリードが疑われる。

(2) 患者のHLA型調査

症例報告で自己免疫疾患の併発が示唆されたことに関連付けてなのか、患者のHLA型鹿児島大と信州大で調査したという内容である

その結果、HLA-DPB1*0501の頻度が一般的日本人の頻度より高かったと述べられている。

鹿児島大のデータ(n=19)ではDPB1*0501の頻度(恐らく保有率)が84%、

これに2名を追加したデータ(n=21)では保有率が85.7%、遺伝子頻度が57.1%であった。

Controlの遺伝子頻度は40.7%であり、患者側で有意に高かったようだ(P<0.001)。

信州大のデータ(n=14)では、DPB1*0501の保有率が71%遺伝子頻度が46%であった。

Controlの遺伝子頻度は38.4%で、記述がないことから、恐らく有意差は無かったと思われる。

上記で保有率遺伝子頻度を強調表示したが、それはこの2つが混同して語られているからだ。

ごく単純に説明すると、保有率の方はヘテロ接合でもホモ接合でも保有者1名として(つまり個体単位で)計算するが、

遺伝子頻度は遺伝子プール内の対立遺伝子の頻度で計算するため、ヘテロ/ホモ接合の割合によって保有率と遺伝子頻度は異なる値を示すことになる。

鹿児島大のデータを例に出すと、患者21名のうちDPB1*0501のホモ接合が6名、ヘテロ接合が12名であり、

保有率は(6+12)/21=85.7%なのに対し、遺伝子頻度は(6×2+12×1)/42=57.1%となる。

マスコミ各社の記事で見られた「8割で同じ型を保有」というのは保有率のことであろうが、

それと比較している一般的日本人のHLA型遺伝子頻度で示されている。

したがって、異なる指標比較していることになり、これは印象操作以外にほとんど意味のない行為と言える。

遺伝子頻度で見れば、一般的日本人のDPB1*0501の頻度は38.4~40.7%で、患者群が46~57.1%となり、それほど高いようには思われない

(少なくとも、「普通は4割なのに患者は8割!超高いじゃん!」というマスコミ報道よりは)。

また、健康日本人(Control)のDPB1*0501遺伝子頻度が55% (*2) や64% (*3)の論文存在している。

一応、鹿児島大のデータでは患者側で有意に頻度が高いという結果(10遺伝子座も調べてる割に有意水準が少し高いように思われるのだが)

が得られたことから、DPB1*0501が副反応"疑い"の症状と関連している可能性は否定できない(実際にワクチン副反応かは別として)。

今後、より精確な調査が望まれる。

(3) マウスを用いた実験

この実験概要と結果は以下である

自己免疫疾患を生じ易いNF-κBp50欠損マウスに、インフルエンザワクチンB型肝炎ワクチンHPVワクチン(サーバリックス)、

PBS(Control)を注射した結果、サーバリックス接種群のみ海馬自己抗体の沈着が見られた。

また、(恐らく)サーバリックス接種群でのみ末梢神経に病変が見られた。

マスコミ(少なくともTBSの)記事で「脳に障害」とされたのはこの海馬への自己抗体の沈着である

しかし、あくまで沈着していただけであり、これによって脳に障害が起こったとは少なくとも資料中では全く述べられていない。

しかもこれはマウス実験であり、ただちにヒトの脳に適用できるものでもない。

TBS記事中では池田氏発言も示されているが、

 「子宮頸がんワクチンを打ったマウスだけ、脳の海馬記憶の中枢に異常な抗体が沈着。海馬記憶の中枢)の機能障害していそうだ」(国の研究班の代表 信州大学 池田修一医学部長) (太字・下線は引用者による)

の2行後には

 「明らかに脳に障害が起こっている。ワクチンを打った後、こういう脳障害を訴えている患者共通した客観的所見が提示できている」(国の研究班の代表 信州大学 池田修一医学部長) (太字・下線は引用者による)

と、推測から断定への鮮やかな飛躍が見られる。

これがマスコミ誘導切り貼りによるものか、御本人の認識なのかは不明だが、どちらにせよ不注意な発言であろう。

また、話の流れ的にも「少女たちに何が起きているのでしょうか。」からマウス実験の内容に飛ぶのはおかしくはないだろうか。

どちらかと言えば症例報告の話((1)の内容)につなげる方が自然に思えるのだが。

さらに、マウスに接種されたのはHPVワクチンのうちサーバリックスのみであり、もう一方のガーダシルは用いられていないのは疑問である

HPVワクチンを主眼に据えている以上、ガーダシル実験をしていないというのは考えにくいのだが、何か理由があるのだろうか。

総評

資料全体の批評としては、一言で表すと「言い過ぎ」である

個々の内容(症例報告、HLA型調査マウス実験)はいずれもまっとうなものであり、特に今回の症例報告は患者治療を進める上でとても有用であろう。

後二者も研究のとっかかりとしては十分な内容である

しかしながら、各症例HPVワクチン副反応である根拠なく断言し、HLA調査では「ワクチン副反応の予防法の確立」等、

マウス実験でも「神経障害機序の解明」等のHPVワクチンによる副反応自明とした表現が目立つ。

プレゼン資料で少し強めのことを言ってしまうというのはよくあることだが、それにしてもこれらは言い過ぎなように思われる。

薄弱な根拠HPVワクチンの害を喧伝することは、患者救済という観点から見ても決して適切な方法ではない。

願わくは、不用意な発言は避け、研究内容に相応の穏当な表現でもって語っていただきたいところである

最後

今回のニュースブクマでよく見かけたのが「WHO安全声明は間違っていたのか」「ワクチン擁護者はどんな言い訳をするのか」等のコメントである

ここまで読んでいただいた方なら分かっているとは思うが、池田氏の発表からは各症状がHPVワクチン副反応であるとは言えない。

それを言うには、ワクチン接種者と非接種者を比較して、各症状の頻度が接種者で高いことを明らかにする必要があるのだ。

WHO安全声明(*4,5)は、HPVワクチン接種者と非接種者では自己免疫疾患等の発症率に有意な差は無いという疫学的な調査の結果に基づいてなされている。

調査対象の疾患のなかに池田氏らの症例報告にもあるPOTSやCRPS等も含まれており、そのリスクも接種者と非接種者で差は無かった。

これらは日本国外での調査であるが、国内においても名古屋市の約3万人の調査(*6)では、接種の有無による疾患リスクの増加はほとんどないことが示されている。

また、池田氏の発表資料と同じページに載っている牛田氏の発表資料(*7)も必見である

その主な内容は、器質的な原因に由来しない疼痛への対応治療ケアに関するものであるが、

子供起立性調節障害や慢性疼痛といったHPVワクチン副作用として疑われている症状が、もともと一定の頻度で存在していたことも示唆している。

以上より、今回の池田氏らによる研究発表は、HPVワクチン安全性について既存評価を覆すものではないということがお分かりいただけたと思う。

この文章が、報道を聞いて不安になった方や情報齟齬で混乱している方の助けになれれば幸いである。

なお、批判的に扱ってはいるが、池田氏らの研究の内容自体は素晴らしいものである(特に症例報告)ことは重ねて申し上げておく。

もし間違いや事実誤認等の不備があれば指摘していただけるとありがたい。

追加情報

さて、この文を書き終えたところで、既にこのニュースについて言及したブログを見つけてしまった。

先鞭をつけることは叶わなかったわけである畜生

以下二つとも、有益情報が多々含まれているため、本増田よりこれらを読んだ方が良いかも知れない。

HPVワクチン 接種後体調変化の報道 と その周辺 2016年3月 (感染症診療原則)

http://blog.goo.ne.jp/idconsult/e/7279d93d6ce526b5ed61b40d8a7a01b8

HPVワクチン副反応?に対する報道(2016/3/16)についての物言い (simbelmynë :: diary)

http://simbelmyn.hatenablog.com/entry/2016/03/18/164401



参考文献

*1 Slade et al. (2009) Postlicensure safety surveillance for quadrivalent human papillomavirus recombinant vaccine. JAMA, 302, 750-757.

*2 Onuma et al. (1994) Association of HLA-DPB1*0501 with early-onset Graves' disease in Japanese. Hum. Immunol., 39, 195-201.

*3 Matsushita et al. (2009) Association of the HLA-DPB1*0501 allele with anti-aquaporin-4 antibody positivity in Japanese patients with idiopathic central nervous system demyelinating disorders. Tissue Antigens,73, 171-176.

*4 Global Advisory Committee on Vaccine Safety Statement on the continued safety of HPV vaccination (12 March 2014)

http://www.who.int/vaccine_safety/committee/topics/hpv/GACVS_Statement_HPV_12_Mar_2014.pdf

*5 Global Advisory Committee on Vaccine safety Statement on Safety of HPV vaccines (17 December 2015)

http://www.who.int/vaccine_safety/committee/GACVS_HPV_statement_17Dec2015.pdf

*6 名古屋市⼦宮頸がん予防接種調査 解析結果(速報)

http://www.city.nagoya.jp/kenkofukushi/cmsfiles/contents/0000073/73419/sokuhou.pdf

*7 慢性の痛み診療教育の基盤となるシステム構築に関する研究 牛田享宏氏 発表資料PDF:3,890KB)

http://www.mhlw.go.jp/file/05-Shingikai-10901000-Kenkoukyoku-Soumuka/0000116635.pdf

2016-02-02

トランプさん支持のTwitter垢にDL飛ばしまくるRick Wilsonさんて素敵やん

“single men who masturbate to anime.”

This is an intentionally incendiary statement that Wilson says he made distinctly to troll Trump’s followers.

2015-11-12

参考訳:拡散したJavaシリアル化の脆弱性についてApache Commons声明

原文:https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread

原題Apache Commons statement to widespread Java object de-serialisation vulnerability

翻訳日:2015年11月12日(午後にタイトル日本語しました)

----

2015年11月1日 火曜日

Apache CommonsJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント

著者:Bernd Eckenfels(コミッター), Gary Gregory(Apache Commons副責任者)

AppSecCali2015 でGabriel Lawrence (@gebl) と Chris Frohoff (@frohoff) によって発表された "Marshalling Pickles - how deserializing objects will ruin your day" は、信頼されないソースからシリアル化されたオブジェクトを受け取るときセキュリティ問題をいくつか明らかにしました。主な発見は、Java オブジェクトシリアライゼーション(訳注:seriarization/シリアル化/直列化=ネットワークで送受信できるようにメモリ上のオブジェクトデータバイト列で吐き出すこと。シリアル化されたJava オブジェクトRMIなどのリモート通信プロトコル使用される。)を使用する際に任意Java関数の実行や操作されたバイトコードの挿入さえもを行う方法説明です。

Frohoff氏のツールである ysoserial を使って、Foxglove Security社のStephen Breen (@breenmachine) 氏はWebSphereJBossJenkinsWebLogic、OpenNMSといった様々な製品調査し、(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/) に各々の様々な攻撃シナリオ記述しています

両者の調査活動は、開発者Javaオブジェクトシリアライゼーションに信頼を置きすぎていることを示しています認証前のシリアル化されていないオブジェクトにも。

Javaにおけるオブジェクトのデシリアライゼーション(訳注:de-serialization/非直列化=ソフトウェアで扱うことができるように、送受信されたデータを元に戻すこと)が行われるとき、大抵は想定された型にキャストされ、それによって、Javaの厳しい型のシステムが、得られた有効オブジェクトツリーだけを保証しています

不幸にも、型のチェックが起こるまでの間に既にプラットホームコードが生成されて、重要ロジックは実行されてしまっています。そのため、最終的な型がチェックされる前に、開発者コントロールを離れた多くのコードが様々なオブジェクトの readObject() メソッドを通じて実行されてしまます脆弱性のあるアプリケーションクラスパスから得られるクラスの readObject() メソッドを組み合わせることで、攻撃者は(ローカルOSコマンドを実行するRuntime.exec()の呼び出しを含めて)機能を実行することができます

これに対する最も良い防御は、信頼されていないピア通信相手)とは複雑なシリアルプロトコルを使うことを避けることです。ホワイトリストアプローチ http://www.ibm.com/developerworks/library/se-lookahead/実装するように resolveClass をオーバーライドするカスタム版の ObjectInputStream を使うと、影響を制限することができますしかしながら、これは常にできることではなく、フレームワークアプリケーションサーバがエンドポイント提供しているような時にはできません。簡単な修正方法がなく、アプリケーションクライアントサーバプロトコルアーキテクチャを再検討する必要があるため、これはかなり悪いニュースです。

これらのかなり不幸な状況において、エクスプロイトのサンプルが見つかっています。Frohoff氏は、 Groovy ランタイムSpringフレームワークApache Commons コレクションからクラスを組み合わせるサンプルのペイロードに gadget chains (ガジェット・チェーン)を見つけています(訳注:provided)。これはこの脆弱性エクスプロイトのためにより多くのクラスを組み合わせられることは完全に確実なことで、しかし、これらは今日攻撃者が簡単に得られるチェーンです。

(Twitter画像)https://blogs.apache.org/foundation/mediaresource/ce15e57e-94a4-4d7b-914c-8eb8f026659c

この脆弱性のために利用される(訳注:blamed)ことができない確かな機能実装するクラスができ、安全性が信用できないコンテキストにおけるシリアル化を利用されないようにするような既知のケースの修正ができたとしても、少なくとも分かったケースだけでも継続的修正していくことが要求されますモグラ叩きゲームを始めるだけであるかも知れませんが。実際にはこれは、オリジナルチームが Apache Commons チームに警告が必要だと考えていない理由で、それゆえに比較的、活動開始が遅れました。

Apache Commons チームは InvokerTransformer クラスのでデシリアライゼーションを無効化することによって commons-collection の 3.2 と 4.0 のブランチにおける問題対処するために、チケット COLLECTION-580(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136&r2=1713307&pathrev=1713307&diff_format=h) を使っています議論されているやるべきことのアイテムは、変化させる仕組み毎(per-transformer basis)に、プログラマティックに有効にするような機能提供するかどうかです。

これには前例がありますOracle と OpenJDK JRE の一部であったり、バイトコードを挿入して実行することを許したりする com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl クラスで、セキュリティマネージャー定義されているとデシリアライゼーションを拒否します。

これはシステムプロパティ jdk.xml.enableTemplatesImplDeserialization=true とすることで無効にできますApache Commons Collection は、本来よりもこの実行モデルは一般化していないため、セキュリティマネージャー存在独立したこの機能無効化することを計画しています

しかしながら、明確化のために述べておくと、この便利な"ガジェット"は、唯一知られている方法でもなければ、特に未知のものでもありません。そのため、インストールされたものを強化されたバージョンApache Commons Collection に置き換えることが、アプリケーションをこの脆弱性に対抗できるようにするわけではありません。

このブログポストレビューのために Gabriel Lawrence に感謝したいと思います

Apache Commons Collection は、Java コレクションフレームワークに加えて追加のコレクションクラス提供する Java ライブラリです。InvokerTransformerコレクションにあるオブジェクトを(特にリフレクション呼び出しを通じてメソッドを呼び出すことで)変換するために使うことができる Transformer ファンクションインターフェース実装の一つです。

一般のSallyによる2015年11月10日午前10字15分にポスト | コメント[1]

コメント

OracleWeblogicセキュリティアラートを発行しています

http://www.oracle.com/technetwork/topics/security/alert-cve-2015-4852-2763333.html?evite=WWSU12091612MPP001

提供されている回避策は、T3プロトコルへのアクセス(とリバースプロキシーにおけるT3メソッドフィルタリング)です。

2015-10-06

SVOCのOを先行詞として前に抜き出すことは可能なのか

SVOCのOを関係代名詞の先行詞として前に抜き出せるかどうかについて。

この論点について考えるきっかけになった英文(「東大ディープ英語」Chapter2①)

Newton' s second law of motion,

though it took centuries of difficult factual and theoretical research to achieve,

behaves for those committed to Newton' s theory (SEEM)

very much like a purely logical statement that no amount of observation could prove wrong.

※SEEMは不要

この英文のうち、

a purely logical statement that no amount of observation could prove wrong.

の部分が問題となる。

thatが関係代名詞であることは、本の中で明記してある。

proveは、SVOCの文章を作れる。

c〔+目的語+(to be) 補語〕〈…が〉〈…であると〉証明する.

用例 These papers will prove him (to be) innocent.

これらの書類から彼が潔白であることが証明されるであろう (cf. prove 1a, 1b).

http://ejje.weblio.jp/content/prove

Oを抜き出せるとすると、もとの文章は、

no amount of observation could prove (a purely logical statement) wrong.

役割を書くと、

S no amount of observation

V could prove

O (a purely logical statement)

C wrong.

たぶん、この理解で正しい。

同じ著者の別の本だと、先行詞のもともとの位置が黒丸で明記してあるのを発見した。

http://www.place-inc.net/details/seidoku/images/ch2_no013.pdf

proveとwrongの間、つまりSVOCのOを先行詞にして抜き出されてることをきちんと書いてる。

あと、『イソップ童話』の英文解釈っていう本の中にSVOCのOを先行詞にした例文があることを

Google先生が教えてくれた。買おう。

2015-08-06

とうとう人類幸せに導くpgbouncer1.6が公開された

みんな大好きPostgreSQL

複数DBマルチテナントシステムを構築するなら忘れてはいけないコネクションプーリング

大量コネクションを扱うなら都度forkやpre-fork式ではちょっと辛い、イベントベースが好ましい。

もうお分かりですね。pgbouncer1.6の話題です。

PostgreSQL界隈では有名なコネクションプーリング実装が2つあります。 pgpool-II と pgbouncer。

ざっくり言うと高機能の pgpool-II に対して、軽量・大規模向けの pgbouncer という棲み分けがあると言えるでしょう。

pgpool-II は最近日本トレジャーデータ社の Prestogres ( https://github.com/treasure-data/prestogres ) という痺れるようなプロジェクトベースとして採用されていることで名前を聞いたことのある方もいるのではないでしょうか。

pgbouncer は少し古いですが LastFM( http://www.lastfm.jp/user/Russ/journal/2008/02/21/zd_postgres_connection_pools:_pgpool_vs._pgbouncer )の事例が有名でしょう。Instagram も使ってますネ。

pgbouncerは現行のバージョンは1.5系で、最新は1.5.5です。1.6系は8月1日リリースされ、複数DBマルチテナントシステムに向けた大規模な機能強化が行われています

この1.6系では複数DBマルチテナントシステム開発者にとって嬉しい機能がたくさん搭載される予定です。本番運用に投入する前に一足お先にリリースノートを読んで夢を感じましょう。

バージョン2013年ぐらいからリリースノートは準備されているのにさっぱりリリースされなくて関係者をやきもきさせていました。(想像

記事では以下のリリースノートをもとにザックリ読み解いたものです。

http://pgbouncer.github.io/2015/08/pgbouncer-1-6/

主要新機能

接続ユーザーパスワードハッシュDBからロードできるようになった

プーリングモードの設定をデータベース毎、ユーザー毎に設定できるようになった

データベース毎、ユーザー毎にコネクションの最大接続数を制御できるようになった

・新しいコネクション確立を避けるための DISABLE/ENABLE コマンドが追加された

・新しい推奨のDNSバックエンド c-ares が追加された

設定ファイルに include ディレクティブを追加した

ではリリースノートをそれぞれ細かく見ていきましょう。

接続ユーザーパスワードハッシュDBからロードできるようになった

新しく以下のパラメータが追加された

1.5までのpgbouncerは userlist.txt というテキストに静的に接続ユーザを書かなければいけませんでした。

これは動的に接続ユーザーが増えるようなマルチテナントシステムを構築するのに不向きという事です。

この機能はその悩みを解消するための機能と言えるでしょう。

プールモードデータベース毎、ユーザー毎に設定することができる。

タイトルがすべてを物語ってます。柔軟にできますねぇ('∀`)

ただ、私にはちょっと有用な利用シーンが思いつかなかったです。

たとえば分析ユーザーではトランザクションなんて使わないので statement モードにしてコネクションの消費を抑えたりできるという事でしょうか。

データベース毎、ユーザー毎にコネクションの上限を設定できる。

max_db_connections と max_user_connections という設定が追加されます

テナント毎にユーザーを分けているような複数DBマルチテナントシステムにとって必須といえる機能です。

特定ユーザーリクエストコネクションをすべて占有されてしまい、他のユーザーサービスできないという事態を避けることができるようになるでしょう。

新しいコネクション生成を防止する DISABLE/ENABLE コマンドを追加。

特定データベースの新しいコネクション確立を抑止・再開することができます

新しいDNSバックエンドとして c-ares を導入した。

c-ares名前解決の非同期化を行うためのライブラリです。c-ares名前解決をブロックしないし、いろいろな方式名前解決に対応している唯一のプロダクトとのこと。

名前解決をブロッキングしてしまうようではpgbouncerのような大規模向けシステムでは役に立たないのだというpgbouncerの強い意志を感じる。

というか、ドキュメントを見る限り pgbouncer は名前解決にかなりこだわりを持っているらしい。それだけそこが重要ということでしょう

個人的には困ったことがないのでそこまでだわる理由はよくわからない。)。

SHOW CLIENTS, SHOW SERVERS で remote_pid を出すようになった。

UNIXドメインソケットで接続しているクライアントと、TCPまたはUNIXドメインソケットで接続しているサーバーでremote_pidを取得できるようになりました。

tcp serverの場合、pid はキャンセルキーから取得できる。(?ドキュメントから意味が読み取れず)

キャンセルキーとは何でしょうね。ちょっとリリースノートから判断できませんでした。

pg_cancel_backend とかに使えるPIDだよという事なのでしょうか。

ネガティブDNSキャッシュのために dns_nxdomain_ttl を分割した。

DBの数なんてもはや何台あるかわからない。ホスト名の解決はもはやDNSで行っておるよという皆様にとって必須機能

…なのでしょうがちょっとこの機能必要となるようなシステムとはどんなものなのか、私も未経験なのでよくわからないです。

クライアントIPアドレスポートapplicationネームに追加する

この設定は application_name_add_host=on にすることで有効となる。

今や接続アプリケーション名がWebだとかBatchだとか区別できるだけで問題が解決するような時代ではない。

どのホスト(ポート)レベル区別しないと。という事なんだろう。

「おお、Webサーバーから死ぬほど重いクエリが飛んでる、今すぐ調べないと!で、どのWebサーバーよ?100台あるんだぜ」みたいなときに助かりますね。

設定ファイルに外部ファイル読み込みディレクティブを追加することができるようになります

設定ファイル大規模化してくると、切り出して整理したいという要望はどうしてもでてくるもの

データベース毎、ユーザー毎に設定できる項目が増えてきたので必要になったという事でしょう。

以上。

以降はバグフィックスとかクリーンアップだとかで自分はあまり興味がないので各自読むように。

本番運用突撃するPostgreSQL界の猛者の報告待ってます

2015-04-06

https://developer.mozilla.org/ja/ブラウザコンソール

             _.-~-.
           7''  Q..\
        _7         (_
      _7  _/    _q.  /
    _7 . ___  /VVvv-'_                                            .
   7/ / /~- \_\\      '-._     .-'                      /       //
  ./ ( /-~-/||'=.__  '::. '-~'' {             ___   /  //     ./{
 V   V-~-~| ||   __''_   ':::.   ''~-~.___.-'' _/  // / {_   /  {  /
  VV/-~-~-|/ \ .'__'. '.    '::                     _ _ _        ''.
  / /~~~~||VVV/ /  \ )  \        _ __ ___   ___ ___(_) | | __ _   .::'
 / (~-~-~\\.-' /    \'   \::::. | '_ ` _ \ / _ \_  / | | |/ _` | :::'
/..\    /..\__/      '     '::: | | | | | | (_) / /| | | | (_| | ::'
vVVv    vVVv                 ': |_| |_| |_|\___/___|_|_|_|\__,_| ''

Hi there, nice to meet you!

Interested in having a direct impact on hundreds of millions of users? Join
Mozilla, and become part of a global community that’s helping to build a
brighter future for the Web.

Visit https://careers.mozilla.org to learn about our current job openings.
Visit https://www.mozilla.org/contribute for more ways to get involved and
help support Mozilla.

---

If you don't want to see this message next time, run this JS statement:

    Tabzilla.disableEasterEgg()

が出力されて一瞬びっくりした。

2015-03-10

Twitterサングラススパムサイトメモ

floridaglass.net

Domain Name: FLORIDAGLASS.NET

Registry Domain ID: 1735502527_DOMAIN_NET-VRSN

Registrar WHOIS Server: whois.godaddy.com

Registrar URL: http://www.godaddy.com

Update Date: 2014-05-04T01:24:36Z

Creation Date: 2012-07-24T17:44:15Z

Registrar Registration Expiration Date: 2015-07-24T17:44:15Z

Registrar: GoDaddy.com, LLC

Registrar IANA ID: 146

Registrar Abuse Contact Email: abuse@godaddy.com

Registrar Abuse Contact Phone: +1.480-624-2505

Domain Status: clientTransferProhibited http://www.icann.org/epp#clientTransferProhibited

Domain Status: clientUpdateProhibited http://www.icann.org/epp#clientUpdateProhibited

Domain Status: clientRenewProhibited http://www.icann.org/epp#clientRenewProhibited

Domain Status: clientDeleteProhibited http://www.icann.org/epp#clientDeleteProhibited

Registry Registrant ID:

Registrant Name: Randi Shannon

Registrant Organization:

Registrant Street: PO Box 570263

Registrant City: Miami

Registrant State/Province: Florida

Registrant Postal Code: 33257

Registrant Country: United States

Registrant Phone: +1.3054914597

Registrant Phone Ext:

Registrant Fax:

Registrant Fax Ext:

Registrant Email: randishannon@gmail.com

Registry Admin ID:

Admin Name: Randi Shannon

Admin Organization:

Admin Street: PO Box 570263

Admin City: Miami

Admin State/Province: Florida

Admin Postal Code: 33257

Admin Country: United States

Admin Phone: +1.3054914597

Admin Phone Ext:

Admin Fax:

Admin Fax Ext:

Admin Email: randishannon@gmail.com

Registry Tech ID:

Tech Name: Randi Shannon

Tech Organization:

Tech Street: PO Box 570263

Tech City: Miami

Tech State/Province: Florida

Tech Postal Code: 33257

Tech Country: United States

Tech Phone: +1.3054914597

Tech Phone Ext:

Tech Fax:

Tech Fax Ext:

Tech Email: randishannon@gmail.com

Name Server: NS11.DOMAINCONTROL.COM

Name Server: NS12.DOMAINCONTROL.COM

DNSSEC: unsigned

URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/

For more information on Whois status codes, please visit

https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en

DR-1 Statement of Organization

https://webapp.iecdb.iowa.gov/PublicView/organization/Candidates/Shannon,%20Randi_Shannon%20For%20Senate_2018_closed_2014/Shannon,%20Randi_Shannon%20For%20Senate_2018_DR1_05-21-2012.pdf

Randi Shannon

Marketing Director, Youngevity Life Sciences

319-804-9163 – RandiShannon@Gmail.Com

http://randishannon.com/nano_bio_balancer.php

http://randishannon.com

2014-04-09

http://anond.hatelabo.jp/20140409134135

SQL組み立てで変数入れる場合は必ずprepared statement使えよって思うけど。

SQLインジェクションが発生しない場面もあるとは思うが、紛らわしいので、SQL組み立てに文字列変数直接入れ込むのは禁止したい。

2014-04-06

メリットデメリット分析落とし穴

日本では物事をメリットデメリットの両面から考えることを子供の頃から教わらず、教科書などには公正さを期するため物事の良い点悪い点の両方が書かれていることがあるとはいえ、そうした両面的な考え方が身についている子供が多いとは言いがたい。受験勉強にしたって勉強内容の公正さに対して疑問を持つことなく丸暗記に近い勉強ばかりしている有様である

これが社会に出ると丸覚えは機械的作業を行うだけの底辺労働者しか通用せず、高い結果を出すには学習内容の公正さを疑う視点が求められてくる。ここに至ってメリットだけでなくデメリットも考えねばならないことをようやく教わるのである。曰く、おいしい話には裏がある。「これはいける!」という新しい策を導入する時にはちゃんと悪影響の可能性も考えましょう。物事の悪い部分ばかり見て手を拱いていてはいけませんぞ、などなど。

一方、欧米では子供の頃から学校ディベートやライティングをしっかり教わり公正な思考力を鍛えられるし、家庭でも社会の暗部を見せられさまざまな視点からライフプランを考えるように促されることが多いというのは、アメリカかぶれの評論家が口を揃える有名な話であるディベートでは政策(やそれに類するもの)に対して賛成と否定の両派に分かれて激論が酌み交わされる、いや取り交わされる。本心は賛成派でも否定派のチームに入れられることやその逆のパターンも多い。こうして賛成にも否定にも回れるような柔軟で両面的な思考法が身につく。さら1980年あたりから欧米では多民族国家であることや同性愛問題の表面化などを背景にdiversity(多様性)を尊重する思潮が強まり民族や性や思想多様性学校でも明確に教わるようになった。最近Mozilla CEO性差別的法案を支援して問題になった件で「Mozilla Statement on Diversity」という声明を出したのは記憶に新しい。このように物事の両面性・多面性を重視する風潮・思考法になっている。

ttps://blog.mozilla.org/press/2014/03/mozilla-statement-on-diversity/

日本人の多くは社会に出ると「国際社会だし欧米のように多面的思考をしないといけない」と耳が痛いほど聞かされ、その一環としてメリットデメリットを考えることが大切なんだなと学び成長していくわけである。そしてメリットデメリットさえ考えてれば多面的思考法が出来ていると勘違いしてあぐらをかいている人も多い。

しかし、メリットデメリット分析には根本的な落とし穴がある。

1つには可変性である。例えば、自社の管理システムに新製品を導入する時には導入するメリットデメリットを考えてメリットが大きいと判断されれば導入するという単純な思考プロセスで問題ない場合もあるが、新しい人材を取り込む時には必ず成長性を考える必要がある。ある分野が得意だからってさらに伸びるとは限らないし、ある分野が苦手だからって苦手克服できないとも限らない。人材ならまだ分かりやすいが、管理システム場合はどうか?システム時代とともに適応していけるような柔軟性を備えているか、また経験にしたがってブラッシュアップしていけるような成長性を備えているか。そうした可変性も加味しなければならない場合が多い。

子育て学校教育においても、長所を伸ばすという聞こえのいい古い考え方が未だに蔓延しているが本当にもっと伸びるのかと言いたくなる。得意分野だと成功体験を積みやすい?いやいやそれは他人と比べるからで、比べなければ得意で伸びにくいものより苦手でも伸びやすもののほうが伸びしろがあるため成功体験を積みやすいのは明らかだろう。大切なのは成長の楽しさが得られるかどうかであって、得意なものをやるよう押し付けることではない。そのためには得意でもどれが伸びてどれが伸びないのか、苦手でも伸びるものがあるのではないか、伸びるとしてどれくらい伸びるのか、といった一段階緻密な検討を経て合理的に判断をしないといけない。なんでもかんでも得意分野を持て囃すような風潮はもう終わりにしよう。

これまで見てきたように良い所と悪い所だけ見て両面的に考えてるぞとドヤ顔する風潮は打ち破られるべき悪しき因習と言える。逆に言えばこれからの熾烈を極める国際社会競争においてきちんと可変性を加味した多面思考ができる人間けが生き残るとも言える。

メリットデメリット分析の2つ目の落とし穴もっと根本的なもので、定性分析であるである分析名前がついているから数理的な分析だと勘違いやすいがそうではない。多くの場合メリットデメリット分析定性的分析、つまり物事の良し悪しに関わる性質を列挙しているに過ぎない。だからメリットデメリットを量的に比較するのは難しく、比較できたとしてもそれはこじつけになりがちで、結局「メリットのほうが多い」「デメリットのほうが多い」といういい加減な形で分析結果を利用されてしまやすい。たまたまメリットのほうが多く思いついただけかもしれないし、数え方の問題で多いだけかもしれないし、数が多いだけで重要度の低い項目だらけかもしれないのに。

実はこれは、賛成派(メリット)と否定派(デメリット)が戦う競技ディベートにおいてもしばしば問題となる点であるディベート勝敗ディベート経験のある審判理屈をつけて決めているに過ぎない。論拠の数が多いから説得力があったとか、質問されて答えに窮したか説得力がなかったとか、おおよそ論理とは無関係価値判断で決まることが多いのだ。

ディベートだけでなく2ch信者VSアンチの論争にも言えることである。それが偏った事実の寄せ集めであるかどうかにはお構いなくとにかく論拠の数を沢山用意しておき、次々と論拠を提示しては主張を繰り返して圧倒し、反論・質問された時にも用意した論拠で即レスするようにすれば、たいていスレの風潮を支配できるという、あの荒らしまがいのやり口を思い出してほしい。この手の荒らしが手強いのは殆ど場合において定量的擁護または叩きを行うためのデータ存在しないか少ないからだ。そんな時は膨大な定性データ粘着的な調査力で収集して印象操作で圧倒するのが比較的容易である

2013-12-05

英語ネイティブだけのものじゃない!

大学院生向けの英語論文の書き方講座が大学で開かれていた。そこで講師をしていた女性白人)が最悪だった。

日本人英語の文章はひどい」

「ノンネイティブ英語の文章はわかりにくい」

いか日本人英語(の文章)がオーガナイズされていなくて、理解しがたいかを延々と語っていた。


校正を頼まれるとうんざいするとか。本当はやりたくないらしい。それでそんなに言うからには凄いことを言うのかなと思って身構えていたら

結局残りの時間はThesis statementとTopic sentenceの話。なんだそりゃ。確かに重要だけど、うちの大学の1年目で習うような内容だ。

こんなのネイティブだろうがそうでなかろうが、少し勉強すれば分かる。


こんな初歩的なことをもってノンネイティブ英語は駄目だとか日本人英語は読む気にならないとはちゃんちゃらおかしいわ。

アカデミックライティング技術を習得する機会は確かにネイティブのほうがノンネイティブよりも多い。

ただその技術自分勉強努力して習得するもので、ネイティブに与えられた才能なんかじゃない。

からネイティブけが書ける文章なんてない(少なくとも学術的な文章では)。そうやって色々な国の人が書けるようなスタイル

築き上げたか英語が多くの学問における共通語になったんだ。英語ネイティブだけのものじゃない!思い上がるな!

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん