  |
はてなキーワード: メソッドとは
マジレスで解決策を書く。他の人も参考にして欲しい。
元増田の記事： http://anond.hatelabo.jp/20160220112047
※文末に、ブックマークコメントへの返信を追記しました（2016/02/21）。
メタブコメにも書いたんだけど、文字数が足りなくてわかりにくいと思ったので。
shields-pikes のコメント / はてなブックマーク
http://b.hatena.ne.jp/entry/279614518/comment/shields-pikes
自分も男子高出身で、大学の途中までは絵に描いたような勘違い系の非モテだったので、気持ちはわかるし手助けしたい。
自分のブログには、この手の恋愛系のネタは投稿したくないので、ここに書く。
元記事の増田は「彼女を作ること＝告白して交際」を表向きの目標にしてるよね。
これが最大の間違い。
告白して交際という手順が有効なのは、ギリギリ奥手な大学生の処女童貞同士の交際まで。
それ以降の年齢や経験者なら、告白しない方がセックスの成功率は上がるし、その後で付き合える。
10代の時に奥手な女性相手に限り告白が有効なのは、女性が初めてのセックス相手に、「自分を裏切らない＝すぐに捨てない」という意味での信頼感を求めるし、初めての交際というプロセス自体に夢を抱いてるから。そして、一度でも交際と別れを経験すれば、それらが儚い幻想だと気付く。まあ、本当はそこからが恋愛のスタートなんだけどね。まあ、その話は今回は関係ない。
そもそも、彼女を作ることって、増田にとってそれ自体が目的なの？
たぶん、後者の手段でしかないのに、それを必死に隠そうとしてるんだと思う。
本来、異性とのデートはそれ自体が楽しみ＝目的なのに、増田はまるで営業活動のように契約にいたるための手段にしてるよね。
つまり、相手の女性とのデートを心から楽しんでないのが、丸わかりなんだと思う。
デート3回目で告白なんてのは、何の意味もないノウハウ。大事なのは、相手の気持ちがついて来てるかどうかでしょ。
相手の気持ちがついて来てたら、1回目で交際が始まることもあるし、1回目でセックスしてもいいし（流石にこれは一晩限りになりがちだけど）、1回目でプロポーズしてもいい（まあ、そんなのは奇跡だけど）。逆に、相手の気持ちがついて来てなければ、何回目のデートでも無理。
そうすれば、交際は結果としてついて来る。大人になったら、その順番の前後は誤差だ。
もし、ガチで結婚願望があるなら、思い切って経済力を強みにしていきなり結婚自体を目的にしてもいいけど。
でも、今までデートした相手とすぐに結婚する、ってところまで腹くくって無いでしょ。
いや普通は、そんなの出来るわけないよね。相手の一生を背負う＆背負わせるわけだから。
相手のことを本気で好きになってもいないなら、そこまでの腹はくくれないはず。
相手が好きだ、相手とセックスしたい、という気持ちを言葉と態度でストレートに伝えればいい。
増田にとって、告白して交際OKもらえる、ってのは性的接触（キスやセックス）をしてもいい許可がもらえるってことだと内心思ってない？
だって、それ以外の交際の楽しさ（楽しく会話、一緒におでかけ）ならすでにデートで体験できてるわけでしょ。
デート自体が目的のひとつなら、100人の好みの女性とデートするなんて、楽しくてしょうがないはず。
でも、手段でしかないから、結果につながらない営業活動の改善を続けてるばかりで、全然楽しそうじゃないよね。
交際＝セックス許可証という発想が、相手にバレバレなんだと思うよ。
普通はそこまで考えてる男はそんなにいないけど、たぶん増田はそういう発想になった上で、紳士な行動で体裁を取り繕ってる気がする。
それは相手にとっては重いよ。
だって、デートしても自分が好かれてる手応えがない相手から、突然「あなたといつでも何度でもセックスできる権利がもらえる、セックス許可証に契約印を押してもらえますか？」と迫られるようなものだから。
だったら、とりあえず何回かのデートで気が合いそうなら、試しにセックスしてみた方が気が楽なはずなんだよね。
ということで、前置きが長くなったけど、ここからが本当の具体的なアドバイス。
告白よりも先に、まず、デートでいい雰囲気になったら手を握れ。
デートが本当に楽しめる相手となら、デートを重ねるうちに相手も自分を好きになってくれるはず。それは3回目とか関係ない。とりあえず、目標としてデート中に手を握ること。
手を握っても嫌がらない、握り続けていても違和感がない相手なら、その先に進める。
次は、自分または相手の部屋に行って（どちらも一人暮らしじゃなければカラオケ辺りで）、いい雰囲気になったら肩でも抱いてキスしろ。
行けそうなら、そのままセックスまで持って行ってもいい。
交際しないと絶対にセックスしないタイプの女性なら、キスした後に、私のことどう思ってるの的な話になるはず。
最低でも、手をつないだ後に告白だ。順番を間違えるな。
これは、手順の話じゃなくて、接触からの反応こそが、相手の気持ちをはかるための唯一の目安だからだ。
相手とのデートを心から楽しむことが大事だし、そこには当然手をつないだりの接触も含むわけで。
その時点で、性的な接触も含めてこの人と付き合ってもいいな、付き合いたいな、と思わせないとしょうがない。
その意味で、複数回のデートを了承してくれてるのは、嫌われてはいない証拠。
でも、まだ気持ちが不確かな時点で、イエスかノーかの契約を迫られるのは、プレッシャーなんだよ。
まずは、手をつなぐのが不自然じゃなくなったら告白するところを目指したらいいと思うよ。
インフルエンザで倒れていて暇なので、乱筆長文で書いてしまった……。
--------------------
追記：
予想以上に反響が大きくて驚いた。
みんな草食じゃなくて、食い方のマナーを気にし過ぎて拒食症になってるだけなんじゃないのかな。
みなさんとタミフルのおかげで、インフルエンザの熱も下がってきました。
＞勘違いして強引な誘い方をする人が増えそう
決して、強引な誘い方を推奨してるわけではない。むしろ逆。相手の反応を見ながら（ここが最重要）、嫌がってなければ少しづつ先に進めるべし。手をつなぐのは、犯罪にならないギリギリのラインの試金石なのでオススメしているだけだ。
もちろん中には、好意があっても手をつなぎたがらない子や、特に無反応で嫌がらないけどその先にも進めない子もいる。そこは個性だ。ただ、経験が少ない男性にとっては、会話のニュアンスで読み取るよりも確実な方法ではある。
手をつなぐタイミングは、お店を出た帰り道とか、階段の昇り降りとか、交差点渡るときとかに、手を差し伸べて「はい」って言えばいいよ。好意を持ってて察しのいい子なら、そのままつないでくれる。相手の子が「何？」って聞いてきたら「手をつなごう」って言えばいい。それでも断られたら「それじゃ、行くよー」って普通に歩き始めればいい。何も恥ずかしいことはない。
そりゃそうだよ。恋愛工学とやらは、本来の理想的な恋愛展開のエッセンスを抽出して濃縮したものを、短時間にセックスまで至るためのメソッドとして濫用してるんだから。
恋愛工学とやらは、セックス人数を増やすための効率を最適化するためだけに特化したメソッドなんだろ？ でも、この記事で書いたメソッドは、本当に好きな相手と出会えた時に付き合える確率を上げるためのメソッド。だから、本当に好きな人と出会えて付き合えて結婚できたら、もう使う必要のないメソッドなんだよ。
この手の恋愛メソッドは万能じゃないのは当然。一人一人の違いを楽しむのが恋愛だからな。でも、個人ごとにアレンジするとしても、初心者には基本パターンの定石が必要なんだよ。
例えば、どんなに消費者のニーズに合致したいい商品でも、パッケージや宣伝や販売方法がまずければ売れないだろ？ 目的を達成するためには、何年もの地道な失敗と経験の積み重ね、または先人に学んだテクニックが必要なんだよ。いわゆるリア充達は中学生くらいからずっと恋愛の修行を積んで20代になる頃にはLV90（イメージです）くらいになってるんだから、LV1の童貞無課金ユーザーが手ぶらで戦場に向かったところで、かなうわけがない。仮に、相手が多少好意を抱いてくれてても、チャンスを逃しちゃうんだよ。だから、乗り遅れて時間がない大人は、攻略情報wikiと課金で武装しつつ、臨むしかないの。
最後に、元増田くらい積極的に努力しても空回りしてるのは、むしろ特殊例なので、普通の非モテ男子は誰でもいいから女性の知人とデートの練習をするところから始めるといいと思います。デートの練習は超大事。
自分の気持ちを偽らずに、相手の気持ちを想像することを忘れずに、正しい方向に努力を続けていれば、その先は確率と時間の問題なので頑張ってね。イケメンかどうかとかは、恋愛には微塵も関係ないから（東大生じゃないから就職できない、って言ってるのと同じくらいの甘え。）。
ソフトウェアの規模や種類によって最適な作り方ってのは決まってくるから
ユーザのニーズに合わせてどんどん拡張していくようなWebサービスだと、設計書細かくつくっても開発が遅れて競争に負けてしまっては意味が無い
法律や規定で動作ががっちり決まっていて、何十年単位で運用するような金融とか公共系のシステムなら、プログラムの細かいところまで日本語で記述した資料があったほうがいい
とか
それでも、標準的な言葉の意味が知りたいなら、IPAの試験でも勉強するとか
あとは、プログラミング言語の進歩で表現力が上がってくるにしたがって、プログラムのそのものをドキュメントにする必要性は減ってきてると思う。
C言語より前の時代のSIerだとフローチャート必須だったらしいけど、今は流石に無いでしょ。
Ankiに代表される暗記系アプリは受験生が陥ってはならない罠だ。とにかくカード作成が手間すぎる。搾精ならされてみたいかもだけど作成はマジカンベーン。
あれを嬉しがって使ってる輩はおおよそまともじゃあない。重度の安本丹かまともに勉強したことがない仁丹飴かのどちらかだ。
いま声を大にして言いたい。今年の受験生はもう手遅れだが来年受験するそこの君、もう今日からAnkiを卒業しよう。
兎にも角にもありえぬ沼アプリ。はやくしろー抜け出せなくなっても知らんぞー。
海外ミリオネアのクイズ王がAnki活用してたからって凡人が真似しちゃイカン。カード作ってる間に覚えるからなんてたわ言はもう聞きたくない。亀毛兎角の与太話。
手間手間手間。とにかく手間だ。手マンはいいけど手間はイカン。手間暇かけてどうすんの。
.
最も効率良い暗記法は、復習タイミング管理アプリの活用ではなく、参考書への直接の復習タイミングの記入である。
つまり所定の日数前の所定の記号がつけられた事項を復習し記憶度に応じて記号を更新する。これが概要だ。
.
復習タイミングは初見の直後、翌日、7日後、30日後、90日後の5種類。「正」の字を使って欄外にタイミングマークを記入する。
簡単のため、5つのマークをm1, m2, m3, m4, m5とする。また、昨日、7日前、30日前、90日前のことをd-1, d-7, d-30, d-90とする。
つまりこういうことだ。何か覚えたい事項があればそこにm1の印をつける。そして一区切り勉強したら直後におさらいし、m2の印をつける。
また、毎日復習のためのまとまった時間（寝る前が最適）をとり、学習記録でd-1, d-7, d-30, d-90の学習範囲を確認し、
該当範囲をパラパラとめくりながら、それぞれm2, m3, m4, m5の印がついた事項を復習する。そして、記憶度に応じてタイミングマークを更新する訳である。
.
飲み込みの早い人は以降の詳細は読まなくてよいが一応アプリ好きの粗チン野郎と粗マン女郎と犬畜生も対象としているので運用ケースを説明しておこう。
マークの更新は基本的に番号をプラス1する。m3ならm4になるという具合。ただし理解が良好なら飛び級しても良い。
また理解が不良なら覚え直しとしマークの筆順の最後の画を二重線にする。ここではm3'等と表記する。m3は7日後の復習だったがm3'は14日後の復習だ。
マークの視認性や復習の煩雑さを考えて覚え直しは1度までとする。また、諸般の事情でm1,m2の覚え直しはしない。
つまり、毎日復習すべき範囲は先述のものに加えd-14, d-60, d-180だ。
.
20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。
今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。
一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。
以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。
受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていないから追加請求もできない。時間（工数）をかければ良い成果物ができるかもしれないがそれを説明して顧客に嫌な顔をされたくないから、限られた工数の中での最善を尽くす。最善を尽くす、聞こえは良いが要は手を抜く。
つまり、どう頑張っても売上は同じなのだから、良いもの・価値を生むものを作ろうと考えない人が多い。社内で開発者と呼ばれる人間もそうだし、マネジメント層はそういうものづくり志向を持った人をリスク扱いすることもある。
これが諸問題の根源で、いかに述べるような組織・プロジェクトが出来上がっていく。
マニュアル作業の正確さをかたくなに信じてる人だらけで、ITとは何なんだと考えさせられる。
私は定型作業を効率化しようとjsやrubyでスクリプトを書いたりしていた。テストデータを開発用DBに突っ込んだり、テキスト処理して整形したり、Excelからコード生成したりするよくあるやつ。
あるとき上司に肩越しに自分の作業を覗かれて「何やってるの？」と聞かれ、そういうスクリプトを作ってると答えたら、工数とリスクの話をされた。曰く「そのスクリプト作るのに何日かかるの？工数に乗ってないよね？」「スクリプトのテストもちゃんとしないと結果が正しいって保証できなくない？」と。この時はイラッとして「30分でできる数十行のスクリプトだし自分の作業工数内で完結する。むしろ後工程や別の人でも同じことを再現性できて楽になる」とか真面目に説明してプログラムも見せたが、読もうとはせず（読めないので）1時間無駄にした。
前述したようなビジネスモデルだから、営業力と、予定工数で無難にプロジェクトを終えるマネジメント力が大事。IT企業だが開発者は自社で持たない。不況の時に待機コストが発生するリスクがあるし、自社で抱えるより単価の安い開発者が人材派遣系の企業や下請けにいっぱいいるから。
社長があるとき社内広報で「技術は買うものだ」と言っていた。文脈で明らかに技術＝技術者のことだったので、使い捨ての人売り業と揶揄されていることへの自覚が無いと思う。
そういう人が集まっているor残っている組織なので開発者はほとんどいない。20〜30人ぐらいの課に1人ぐらいの割合でstaticおじさんがちらほらいるぐらい。大体20代からプロジェクトリーダーという立場をやり始め、だんだん大型の案件を扱えるようになっていき、後は出世ゲーム。部長のお気に入りが課長になり、部門長のお気に入りが部長になる。その繰り返し。
開発案件でのBP（ビジネスパートナー、委託先、派遣、下請け）比率は自分の周りだと1:5ぐらいが多い。プロパー社員一人が5人の開発を仕切る、みたいな形。案件規模によりだいぶ差があると思う。この比率が高い＝マネジメント力のある組織と考える会社はこの数字を上げようと必死で、比率の低い組織は評価が下がる。
私は開発が好きだったのでエンジニアとして生きていきたい、というようなことを評価面談の度に伝えているが、その度に会社の目指す方向を説かれてモチベーションが下がる。
上述の通り、案件で接する開発者は基本的に社外の人間なのだが、彼らの技術力と意識の高さにはものすごいばらつきがある。言われたものはなんでもこなせる人、何でこの歳まで技術者やれてるんだと疑う人、このプロジェクトはおかしいと良い意味で騒ぐ人、何も意見を言わない人、CっぽくJavaを書く人、人当たりは良いが技術力がいまいちな人、すぐ休む人、バグやミスを隠す人…etc。
まぁ色んな人がいるのはどの業界のどの職種も同じだが問題は質だ。私の主観になるが本当にエンジニアとして尊敬できるレベルの人は1%いるかいないか。というのも、ほとんどの技術者は長年SIやその周辺企業と付き合ってきているので同じ体質に染まっているのだ。顧客が良いといえば良いという態度（この場合の顧客は私が所属する企業）、請負の場合は工数を超えない範囲で手を抜く姿勢、その他諸々。技術力だけをひたすら磨き続けてきたという人はごく一部だけだったし、そんな人でもGitHubアカウント持ってない・ブログやってない・OSSに貢献したことない、といった具合でクローズドな世界で生きている。
そうした技術者とやっていく中で最も厄介なのが教育コストだ。案件のあるなしで人が都度入れ替わり、新しい人が来るたびに同じシステム・技術要素の説明をして何とかやる気が出るようモチベートして、というのを繰り返すのに疲れた。私の会社固有の変なルールの説明はてきとうにしておいて、私は技術が好きな仲間が欲しかったので今のシステムの課題と技術面での改善や展望をよく話す。が、あまり食いつかれることはない。これは私の問題だが、そうした期待と落胆のループも疲弊の一因だ。
ある時、一つの課に6年近くいるというBPと一緒に仕事をする機会があった。その課にはプロパーの技術者が長いことおらず、彼がその課の技術的中心を担っているという話だった。抜けられると途端に色んなものが崩壊するからという理由で、その人の派遣元にはかなり高額の単価を支払っていたと聞いた。課員が口をそろえて「あの人はすごい」「何でもできる」というので初めはかなり期待していた。
だが、拍子抜けした。あまりにも仕事が雑なのだ。コミットされたコードはTODOコメントだらけだし、バグがあまりにも多かった。一度も実行されずにコミットされ、他の人がチェックアウトした時点で判明したバグなんかもあった。それでも声が大きく、プロパーが技術を知らないのをいいことに自分のブランディングに完全に成功していた。客先にも顔を出し、信頼を得ているらしかった。「自分は設計が得意でテスト以降の工程には興味が無い」と言っていた。確かに彼が関わった各システムには独特の概念が埋め込まれた設計があったが、その複雑な設計は保守性が低く、他の開発者が触ると容易にバグを引き起こしていた。
また、彼はJavaの有名なフレームワークであるStrutsを拡張したいわゆるオレオレフレームワークを開発しており、それの出来は悪くなかったと思う。そのフレームワークに欠けているものをうまく補うような形になっていた。だがフレームワークのバージョンを上げると壊れるというのが残念な点で負債になりかけていた。
私は異動したが、彼は今でもそこにいると聞いた。
（最低限のものしか作らないから）安くて早い！という触れ込みで売っているので、テストの工数が異常に少ないことも多い。特にテストコードを書くなんてもってのほか。そういう世界でやってきた人ばかりなので、30や40超えたマネジメント側は「テストコードって何？」状態だ。大型の改修案件が来た時にはコア機能だけでもテストを書いていこうと見積段階から社内で提案したが「顧客に『そんなメリットあるなら何で今までのプロジェクトではやってないの？』って問われるから、絶対言うなよ」と拒否された。
保守案件をやっていた頃、時間を捻出してコソコソとテストコードを書いたりしていた。その案件を離れてしばらく後、ある時リポジトリを覗いたら私が書いたテストコードがばっさり消えていて驚いた。コミットログから課内のstaticおじさん的な人が消したとわかったが、そのコミットコメントが「現在使用していないコードを削除」だった。これはもう問う気も失せて何も言えなかった。
先述したようにテストがそもそもないプロジェクトが基本なのでリファクタできないのだが、たとえテストがあったとしても勝手なリファクタは許されない。ソースコードは顧客の持ち物なので同意なしに改変することはいわば契約違反なのだ。たとえ内的品質が向上してコスト削減に繋がるとしても、そのためにお金を支払う顧客はまずいない。
私がいたどの案件にもコードレビューがなかった。リーダーと開発者数人という構成の場合、まず開発者は全員下請けでリーダーは技術の心得がない場合が多い。そうなると彼らの成果物の良し悪しを図るのは目に見えるシステムの挙動と実施されたテスト結果のExcel報告書だけになる。これが非常に非効率で、少しコードを読めばわかる明らかなバグや仕様理解の齟齬が頻発していた。特に受入試験と呼ばれるリリース直前の顧客側での最終確認や本番稼働中におけるhotfixは全機能をきちんとテストせずにデプロイされることが多く、そのhotfixがさらなるバグを引き起こしたりもしていた。
そもそもテストを書けという話だがテストが無いプロジェクトに足すのはかなり大変なので、レビューサイクルをきちんと回すだけでもかなり変わる。実際、私が入った案件ではすべてのコミットに目を通すようにし、明らかな問題は都度指摘することで品質の向上に繋がった。欲を言えば他の開発者にもレビューしてもらいたいが、下請けの彼らの工数を増やすことは嫌がられる。
無難にプロジェクトをこなすことと新しい技術を試すことの両立こそ技術者の腕の見せどころだと思っているが、ほとんどの場合それは許されなかった。新規にせよ継続にせよ案件を受注する段階で営業やマネジメント層と顧客間で「今回は過去に実績のあるこの技術でやります」という契約が結ばれているからだ。その技術（言語やフレームワーク）がいかに古く、保守性も将来性もないものだとしても受注できればよいし、その技術のサポート切れか何かの拍子で再度リプレイス案件でも受注できればさらにラッキーぐらいの考えでいる。
また横に倣えが加速してさらに悪い事に、同じアーキテクチャ・ネットワークを再利用するために既存のサーバに新システムも相乗りすればよいという発想も珍しくない。「資産の再利用によりコスト削減」という触れ込みだったが、ただでさえスケールしない低スペックのオンプレミスサーバ上で複数のアプリケーションサーバを運用した結果、予想通り耐障害性が下がった。
また、Oracleのライセンスが高いという理由で一つのDBインスタンス上に10数個のシステムが同時稼働しているなんてこともあった。1つのシステムが高負荷なクエリを投げたせいで関連する全システムが共倒れになったこともあったがOracleのバグとして報告していた。
新人の頃にOJTでstaticおじさんの下に付いたことがあった。そのとき担当したのはPerlでデータ連携用のバッチを書くという開発業務だったのだが、最悪の思い出だ。
まずプログラム構造仕様書というのを書かされた。メソッド単位でのモジュールを全てExcel上に記述し、処理の順番と内容を説明するという謎資料だった。あまりに意味がわからなかったので「UMLのクラス図を書けばよいのですか？」と聞いたら「Perlにクラスなんて必要ない。構造化プログラミングを研修でならってないのか」と返ってきた。「俺が前に書いたPerlのバッチがあるから参考にしろ」と言われ、あるリポジトリをチェックアウトして見てみると1ファイル4,000行の.plがいくつか並んでいた。その時の私は何もわかっていなかったのでそういうものかと思ってしまったが後で調べて明らかにおかしいと気づいた。
また、そのプロジェクトのメイン言語はJavaで、Eclipseを使っていたのでPerl用プラグインを入れてコーディング・デバッグをしていたらやめろと言われた。理由は「Eclipse上で動くPerlが信用できない。サクラエディタで書いてプリントデバッグすれば充分だ」と言われた。その時の私は何もわかっていなかったので、プラグインの品質が悪いとかそういう話かと思い「じゃあvimで書きます」と言ったら「サクラエディタにしろと言っただろ！」と一喝され、vim vs サクラエディタという史上類を見ないエディタ論争が起きた。
SI業界の中では高いのかもしれないが決してよくはない。4年目（たぶん25歳）ぐらいで残業込みで年収400万にやっと届いたがそこからほとんど変わっていない。30歳の先輩に聞いたところ「500万前後、残業してない場合の月の手取りは未だに20万切ることがある。残業抜きでは新婚生活が厳しい」と言っていた。いわゆる年功序列がきっちりしていてこのまま続けてもしばらくは給与が伸びないということがわかった。
個人での貢献で差がつくのは±10万程度。その程度ならいっそ無くてもいいのでは、と思う。というかそもそも生産性をきちんと評価する制度が存在しない。これはどの組織でも難しい問題だと思うが、形骸化した評価制度で上司の気に入った人間にS評価を付けているだけならいっそ止めたほうが時間の無駄にならなくてよい。
会社から貸与されるノートPCは低スペックすぎて開発には使い物にならない。なので開発者は基本的にデスクトップを使用せざるを得ないのだがこれもメモリ4G、1.2GHz程度で大したマシンでもない。本当に開発する気がない。
いつの間にかどこかで意思決定がされていて、関与する機会がほとんどない。だがほとんどの社員がそれで良いと思ってる。失敗しても自分が決めたことじゃないから上層の責任だ、そう言えるので楽だから。
情報共有をしない、というか意図的にしないようにしているとまで感じる。連絡はメールと添付ファイルベースで行っているし、共有のファイルサーバなんてのもあったが一部のフォルダは権限を持った人間しか見られない。何で他の部や課が行った過去の見積や提案資料が自由に見られないんだよ。
ソースコードのリポジトリも同様。外部に公開しないのはまだわかるが、プロジェクト外にすら基本は公開していない。別に奪われて困る大した技術もない。
会社が用意した提案資料共有サイトみたいなのもあったが、それに至ってはもっとひどい。課長以上もしくは部長から承認を与えられた者のみ閲覧可能。共有とは。
どうでもいいことを決めるにも承認や根回しや説得が必要になる。それがプロジェクトの利害関係者ならまだわかるものの、まったく関わっていない上長（課長や部長、時には部門長）を通さないと進まないという異常さ。
利益率向上のためにコスト削減ということがしきりに言われており、過剰なコスト削減対応が生産性の低下を招いている。たとえば顧客に見せる資料以外は白黒で印刷しろ、みたいなルール。色がないために情報が伝わりにくい。というかそもそも印刷せずに各自のノートPCで見ろという話だが、先述したようにノートPCは低スペックすぎるので多くの社員がデスクトップを使っている。ITとは。
本当に無駄としか思えない承認・申請フローの煩雑さに加え、使っているシステムの使い勝手も悪く、ひどい日は一日がそうした事務作業で終わる。しかもそのシステムは自社で以前開発したものだというから泣けてくる。こんな作業が定常的に発生するのでいっそ事務員を派遣で雇うべきという提案が何度もされたが、課の予算をオーバーするから無理だという回答しか返ってこない。
表向きは社員の健康促進という触れ込みで残業時間削減を全社的に取り組んでいる。残業減らせと声をかけただけでは誰も帰らないので、勤怠システムと入退館管理システムを監視し、削減できていない組織や人間の評価を下げるようになった。
その結果、サービス残業が復活した。30時間を超えると部長に説明しないといけない、50時間を超えるとその上へ…みたいなループ。表向きの残業時間削減・コスト削減としては成功したかもしれないが、社員の残業時間を管理するとかいう無駄な仕事を増やしたし、管理される社員のストレスとサービス残業に繋がったので下策だと思う。
他人の残業時間をExcelにまとめる仕事があって、そこに給与が発生してると思うと泣きたい。
そもそも無駄な作業や工数至上主義で作業効率が悪いから残業しているので、残業が少ない奴が偉いと一斉に舵取りしただけでは生産性をちゃんと評価できていないことに変わりはない。一昔前の残業多い奴は頑張ってて偉い、というのと本質レベルで何も変わっていない。
勉強を好きになるには面白いと思った箇所に線を引き、面白くないけど覚えないといけない箇所には線を引かないか別の色で線を引くのがオススメなんだよねこれが。
これは俺の兄が慶応大学医学部に一発で受かった受験必勝法ではないが、俺が資格マスター＆アドバイザーとして採用しているメソッドではあるのだ。
面白いと思った箇所にだけラインマーキングしているとどんどんそのマーキングしておる本が面白くなっていくという誠に面白い現象が起きるのである本当に。
だって面白いと思える部分がハイライトされているわけだからね当然だよね。何周も本を読むほどガンガンズンズングングンゲームのごとく面白い本に仕上がっていくのはこれ自明の理なり。
.
しかしながら勉強なんて面白いと思えねーよと名前を忘れたけどある著明な宗教家に言われて愕然としたことがある。
なぜ面白いと思えないかというと常識やレッテルや先入観でべったべたに世界を埋め尽くしたような認識のフレームワークを築城もとい構築しているからといえる。
はぁ～仮初めにも宗教家というのは本来先入観から自由であらねばならないがそれがいつしか綛糸のごとくもとい高手小手のごとくぐるぐる巻きに己を縛りあげて魂の牢獄を築いてそこに安愚楽をかいている状況なのは想像に難くない。
.
そんな人は迷わずリゲインを飲んでまず面白いと思える感性から作っていきたい所であるが、スレッドの雰囲気から察するにそちらの手法を詳しく紹介するのは止めておいたほうが良さそうなので、
今回は即効性の高い方法として目新しさに着目するメソッドを勧めておこう。佶屈聱牙かつ晦渋混濁なる小難しい参考書が面白いと思えないのは措くとしてもだ君、逆に考えるんだ。
難しいからこそ目新しい記述だらけだろォからそこに着目する。こんな細々とした知識やら難解な理論を頭に入れないとIKENAIのかYOなんて考えるのでわなく初体験の玉手箱や～と考えなさい。
初体験という事実を意識したそのときヒト脳は最もk s kしフル回転する。そして実際のところ人生は初体験の連続であるからして何も退屈することはないのであるよ決して。やるなら今でしょ。
.
で、どうだね？初体験を探そうとすると奇妙なことに、視界が突如パーッと開けて明るくなるかのような感覚が得られただろうか？いやそんな訳はないと思うだろうが本当なの！
何もいかがわしい話でもいやらしい話でもなくて、頭がフル回転すると視界って広く明るくなると思うんだけどどう思う？思い当たる節があるんじゃなかろうもん？
何故そんな不可思議な現象が起きるかというとそれは目新しさを探そうとし気付こうとすると必然的にアナタは世界を入念に観察しようとするのでより大量の情報が目に飛び込んでくる。
だから視界が広く明るくなったかのように錯覚するって寸法さあ（適当）。
.
これで点と線が繋がったことにお気づきか。面白いと思う箇所に線を引く勉強法と面白いと思うための未だ嘗て無いメソッドと塩少々を混一もとい渾一させて御覧。
前者は本エントリタイトル通り「受験必勝極秘メソッドではない」が、後者を合わせることで受験必勝極秘メソッドになったことにお気づきか。いや公然と広言しておいて極秘もクソもねーわなｗ
○朝食：なし
○昼食：おにぎり三つ
○調子
最悪。
仕事には行った。
行ったが、仕様変更やら何やらで全く進まなかった。
どうせ朝令暮改なので最終決定の明日以降にゆっくり残業して片付けようと思うので、今日はさっさと帰った。
それにしても腹が立つ。
昨日僕が休んだんだ内に誰かが進めてるだろうと期待していたが、案の定僕任せにしてほったらかしていた。
それならそれで共通メソッドを作るところを僕のスケジュールに加味しといてくれよ、イライラするなあ。
設計が緩くて何したらいいのかわからんのも嫌だけど、露骨に嘘が書いてあるのは本当に面倒くさい。
最悪なのが、設計者の機嫌が常に悪いから、質問しにいくのが怖い。
どうも手戻りが発生するのが嫌なようなのだが、そもそも設計者がちゃんと設計しないから手戻りするんだから、僕に当たられても困る。
さらに「もうレビュー終わってるし」とか言うんだけど、いやいや関係ないからね、じゃあこの嘘まみれで実装していいの？ ってなる。
僕はもう根本的に人と会話をするのが滅茶苦茶苦手なので、こうも設計書にぽろぽろミスが出てきてそれを会話しないといけないのは、本当にツラい。
掲示板とかWikiとかチケットみたいな、会話しなくても共有できるシステムが欲しい。
むきゅー。
最近お母さんが変？iOS/Android「ママはストーカー」が配信
http://www.gamer.ne.jp/news/201601140078/
なにこれエロい。
「モンスターハンター ストーリーズ」の第2弾PVが公開。「モンスターハンターフェスタ’16」の関連ステージを収録した映像も
http://www.4gamer.net/games/298/G029812/20160114085/
児童向けでしょ？ とスルーしてたけど、ちょっと面白そうだな。
僕はモンハンは、PSPの無印、2nd、2ndGと、WiiのGと、3DSのTriGをプレイしてて、
理由は色々あるんだけど、一番大きな理由が「シビアなアクションに疲れてきた」です。
なんだけど、モンハンの世界観は好きなので、こういう別路線から遊べるゲームはちょっとやってみたいかも。
大好きなダイミョウザザミの有無で購入を決めようと思う。
○朝食：なし
○昼食：おにぎり三つ
○調子
むきゅー！
お仕事さんを頑張った。
なんか共通メソッドの製造の割り振りをしていないという衝撃の事実が判明し、
「共通メソッドを作るのは、製造していってそれが始めて必要になった人が全体に周知して作り始める」という仕組みが導入された。
ぶっちゃけかなり面倒くさいのでわざと手を抜いて他の人が作ってくれるの待ったろかいな？ とも思ったけど、
全員がその態度だと巡り巡って面倒なことになりそうなので、渋々手を上げて僕が作ることにした。
したんだけど、メールとかwikiとか掲示板とかメッセンジャーみたいな便利グッズが無いので
「みなさん聞いてください、あっいやこっちの島の人だけでいいです、はい、あの共通メソッドのpiyopiyo1は僕が作ります、とりあえずメソッドのガワだけ作ったので呼ぶ人はpiyopiyo1って書いといてください、え？ はあ、はい、はい、じゃあpiyopiyo1じゃなくてpuyopuyo1になります、あっ引数は設計書通りですが、なんか型の定義が漏れてたので共通設計書書いた人はint型って明記しといてください、えっ？ intだと不味い？ なんで？ はあ、はい、はあ、え？ ああ、はい、はい、わかりました、じゃあクラス作るので呼ぶ人はまだ呼ばないでください。引数に渡すクラスの定義もまだなので、え？ ああ、ごめんなさい、すいません構造体作るのでとりあえずpiyopiyo1付近はちょっと保留にしておいてください、え？ ああはい、すいません、えーっと結論としてはpuyopuyo1付近は保留です」
みたいなことを全員に伝わるように大声で話して、
隣の席のインド人に分かりやすい日本語でもう一度話しするだけの簡単なお仕事こなす。
その後も同じようなことを二回ぐらいやった。
それと、プログラムの仕事あるあるで、今までもたびたびあったことなんだけど、
設計書に書いてあることがどうにも筋が通っていないように感じる（例えば、生年月日は必須項目なのに、リードオンリーで書き込み不可とするみたいな設定）
↓
色々ドキュメントを読み理解を深めるもやっぱり間違ってる気がする（例えば、他の項目を入力するとマスタ引きされて自動で入力される的なやつとか）
↓
↓
お客さんの業務がうんたらかんたらな特殊仕様が明らかになる（例えば、実はそもそもGUIでは編集オンリーで新規追加はさせないだとか）
その特殊仕様について全部仕様書に書くのは労力的に難しいのはわかるから、
一言申し送りというか、設計者さんと会話する時間をとって欲しいなあ。
今は別に和気あいあいとした雰囲気だからいいけど、これが機嫌悪い人だったり、そもそももう居ない人だったりすると俄然面倒くさくなる。
みたいな話を深堀さん似の同僚に話したら
「設計書に書いてあることが間違ってても責任は設計者にあるから私たちは気にしなくて良い」って言われた。
それもそうだなあ、と思ったので明日からはあんまり細かいことを気にせずに適当に書こうと思う。
と決心をした直後、
（「文字を青く赤くする」みたいな日本語としても破綻してる感じの記述）
「これも無視して作ったろかいな」と思うも、渋々設計者に聞きにいく。
そしてその上、似たようなことを僕の設計書でもやらかしてて、作る人に質問されて、
「あーもう面倒くさいなあ」ってなりました。
（自己弁護するとその点に関しては別の人が作業の横展開でまとめてやったときのミスで、僕自身が書いたものじゃないんだけど、まあ最終チェックしたのは僕だから僕のミスでもあるっていうなんとも面倒くさい）
いや本当よくあることだし、これが嫌とか、これがムカつくとじゃなくて、
この程度をコミュニケーションっていうと営業の人とかお客さんと仕様を打ち合わせる人とかに怒られそうだけど、
人と喋ったりするのが苦手なので、疲れるんですよね。
（チケット管理的なことをしてるプロジェクトだとそれ書いてIDコール的なのするだけで良いから楽で好きなんだけど、あれも結局ややこしくなってくると会話しなきゃいけないから、ちょっと楽程度なんだよなあ）
ネットでたまに「プログラマーは人と喋らなくても出来るから、コミュ障向け」みたいな言葉を見かけるけど、
プログラマーでこれなら、他の喋るのがメインのお仕事はどんなにツラいんだろう？ と怖くなってしまいます。
稲船氏のXbox One/PC新作『ReCore』は「今年後半に向けて準備中」
http://www.gamespark.jp/article/2016/01/06/62884.html
うん？ いつのまにWinでも出ることになったんだっけ？ となった。
PVの雰囲気がとっても楽しそうだけどゲーム性がなにもわからないから、早くプレイ動画がみたいですね。
舞台「カードファイト!!ヴァンガード」公演スタート、プロジェクターや役者を使ってカードバトルを再現
http://www.inside-games.jp/article/2016/01/06/94695.html
これ面白そうだな。
残念ながら東京まで行く予算はないから見に行けないけどDVDはちょっと欲しいかも。
プラチナゲームズ最新作『Scalebound』が2017年に発売延期
http://www.inside-games.jp/article/2016/01/06/94665.html
ってあれ？ プレイ動画出てたりするし、リコアより早いんじゃね？ とか予想してたら来年かー。
落ち着いてきたので、備忘録がてらまとめた。実際は50冊くらい読んだ。
どうしても恋人とヨリを戻したいと考える人に「復縁は信じていればきっとできます」と
「復縁ってそんなにできるもんではないよ」を同時に言ってくれるタイプの本。
基本的には、「これを読んでる間は相手に余計なことをせずに済んで、そのうち落ち着く」という効能を持つ。
http://www.amazon.co.jp/dp/4804703691/
恋愛ユニバーシティ（http://u-rennai.jp/）を主宰するぐっどうぃる博士の著書。
まさか自分がこんなこっ恥ずかしいサイトと本を何度も読むことになるとは……。
失恋したてのころに友人3人にこの本をすすめられ、私の復縁本を巡る冒険が始まりました。
まあぶっちゃけ本当に復縁したい方は、これ一冊をえんえん読み続ければ十分だと思います。
他の本に書いてあることはこの本とあまり変わりません。
そのうえで、単に復縁にとどまらない「恋愛の基本」や「人生をうまく乗り切る思考法」、
「SNS時代の駆け引き」について書いてあるので、そもそも特に失恋していないうちに読むのがベストだと思います。
さっき復縁したい人はこれ一冊をえんえん読めばいいと書きましたが、それは別に復縁ができる、
という意味ではないのは、読めばわかる。
http://www.amazon.co.jp/dp/4804704086/
川越にある復縁で有名な占い館のおじさんの本。9年間休まず更新しているというブログ「恋愛日記」
（http://okikawa-blog.com/）が結構おもしろかったので購入。ぐっどうぃる博士ほど復縁に特化
した本ではないですが、そのぶん、失恋段階にいない人でも楽しんで読める。
http://www.amazon.co.jp/gp/product/4835628586/
ウェブのインタビュー記事（http://wotopi.jp/archives/32034）がおもしろかったので購入。
ぐっどうぃる博士の本などよりも、復縁をしたい女性それぞれの状況にあわせた復縁メソッドが細かく指南
されているので、ぐっどうぃる博士に飽きてもっと細かいテキストで気を紛らわせたい人におすすめかも。
http://www.amazon.co.jp/gp/product/B00OC6THR0/
Drタツコ・マーティンという何やら仰々しい名前にひかれて購入。
読んだけどべつに嬉しい奇跡は起きなかった。さっきから言ってますが、ぐっどうぃる博士をえんえん読んでも
気が紛れなかった場合には一回読んでみるといいんじゃないかという感じです。
とくに復縁にはフォーカスせず、恋愛全般のノウハウや考えかたを指南している本。
そもそも今回の交際はどの時点で間違っていたのだろう、という「間違い探し後悔」
地獄におちいらせてくれますが、次の関係への糧にもなるはずです。
http://www.amazon.co.jp/gp/product/B013EVNKDK/
元ホストクラブオーナー男性が書く「だまされない」ための恋愛指南本。
著者の経歴上、ホストクラブで貢いだり、ヒモ男に積極的にカモられてしまったり、遊び人の男に
ひっかかてしまうパターンの女性に向けて書いているテイストだが、それ以外の男性、女性にも
十分当てはまる要素がもりだくさん。「自分の女友達にやらないことは彼氏にもするな」とか……。
http://www.amazon.co.jp/gp/product/B01463ZUKG/
「引き寄せの法則」とか出てくる結構スピリチュアルな本ですが、「バツ2経験アリ」
http://www.amazon.co.jp/gp/product/B00LUG174Q/
ご存知心屋仁之助さんが女性の恋愛にフォーカスして出している本。
「『すあし』な女がモテる」という理論はたしかに……と思わされました。
http://www.amazon.co.jp/gp/product/B00INIGAR8/
アンチ復縁本ですね。さまざまな事例を取り上げつつ、ゴマブッ子さんが喝を入れてくれます。
復縁本を読み飽きて心が多少回復してきたころに読むと効果的かと思います。
精神論よりも何らかの科学的なアプローチで失恋の心の痛みを解決したいフェーズに入ると読みたくなるジャンル。
まあ、1）2）を飛ばしてここから読めるくらいのがいいと思います。
http://www.amazon.co.jp/gp/product/B00Y07B7GU/
「私にはあの人しかいない……」「どうしてこんなに愛してるのに嫌われたんだろう」
「なんでダメ男ばかり好きになっちゃうんだろう？」などなどに当てはまる人にとてもおすすめです。
依存症と言われると、ごくごく一部の人のことに思って手にとりにくいと思うし、実際誰にでも多少はそういう傾向はあるわけで、
それをすべて「依存症」と断じるのはどうかと思いますが、自分のなかの「そういう傾向」を認識することは大事。
http://www.amazon.co.jp/gp/product/B00SY8ZJYC/
妖怪男ウォッチのぱぷりこさんもすすめていた岡田尊司さんの本。おもしろいし読みやすいしとてもおすすめです。
失恋する前に読んでおきたかった本NO1ですね……。まあすべてパーソナリティのせいにするのもどうかと思うんですが（笑）、
そこらの占いや相性診断よりは全然理路整然としていて、一定のロジカルな裏付けがあり、人間関係に役立てやすいかと。
個人的には同じ著者の『愛着障害』（http://www.amazon.co.jp/dp/B009KZ435E/）の本に、
非常に身に覚えのある話が詰まっていて、そのなかでもさらに回避性の人たちにフォーカスを当てた
続編『回避性愛着障害』（http://www.amazon.co.jp/dp/B00HK6ZSL8/）とともに、何度も読み返しました。
http://www.amazon.co.jp/dp/4788914840
これもやはりぱぷりこさんもご紹介されていた越智啓太さんの本ですが、「外見の美しさ」
と恋愛における人々の心理にフォーカスした内容で、とてもおもしろかったです。
人間ってかなり「進化のため」にあらゆる認知を行っているんだなあと思うと、恋愛についても、
「じゃあしかたねえかなあ」という気持ちになることができます。まあそれをうまく利用して
http://www.amazon.co.jp/gp/product/B00RUVI7DO/
加藤諦三先生の本。「神経症八方美人」「愛情飢餓感」「心理的便秘」などの
失恋にかぎらず何かに行き詰まっている人、ストレスを感じてる人におすすめ。
最終的には文学に感情移入して登場人物の感情発散シーンを読むとめちゃくちゃ胸がすきますね……。
http://www.amazon.co.jp/gp/product/B00A4BCLCU/
初恋のイチと自分に言い寄ってきてる二の間でゆれうごく主人公の心が細やかに描かれています。
そもそも20代まであんまり恋愛をしてこなかった人には、「失恋」とは別の「喪女」という角度で刺さりまくると思います。
http://www.amazon.co.jp/gp/product/B009GPM4PE/
山本文緒さんの小説。とある常軌を逸した女性の半生を描いた話なのですが、「うわ〜ありえないでしょ」と思いつつも、
誰でもやっちゃいそうというか、人間って結構簡単に常軌を逸しちゃうよなあという反面教師になります。
http://www.amazon.co.jp/gp/product/B00WG4B30O/
ひさしぶりに読んでもおもしろい。それにしても映画ではコリン・ファースとヒュー・グラントに迫られるんだよな……最高だ。
http://www.amazon.co.jp/gp/product/B00RT8YI1S/
コミックエッセイ。よりやばい状況の人が淡々と人間関係の崩壊のようすを描いているのは胸に迫るものがある。
http://www.amazon.co.jp/gp/product/4091919189/
「お前の恋愛がうまくいかないのは10代のころに芦原妃名子を読んでいないからだ」と友人に罵倒されて購入。
いや〜〜〜〜〜女のメンタルがヘラる瞬間みたいなのがいたるところで描かれていて死ぬ。
http://www.amazon.co.jp/dp/B015QPNP1O/
まあ、すべてのことは吉野朔実があらかじめ書いているな……と思いました。
まわりが悲しむから→知らんがな
それでも俺は止める→言葉じゃ止められないがな
インドの子供の方がツラいぞ！→は？インドの子供が俺の人生おくってたら泣いて帰りたがるわ不幸は相対化できねぇぞハゲ
おっぱい揉ませてあげる→ただの肉に興味ねぇから肩揉んでやるよ
五万円あげる→マジかよやったぁ死ぬの止めるね
三ヶ月後
死にたい…
※1
かまってほしいんですよね？→かまってもらったらなんか解決すんの？しないだろそんな自明なことなのに他人に構ってって求めねーだろバーカバーカ
※2
「しにたくないから宇宙ハンターになる！」←社会的にしんでるだろ
※3
本当は死ぬ気がないメソッド→簡単に死ねるようにしてからに言ってくれあと俺以外の自殺志願者もやればいいんだろやればに追い込むからやめろ
※4
やってみればいい→電車に飛び込んでしねずに車いす生活やら首吊り不十分でベッドぐらしやらになったらおまえ養ってくれんの？
※5
体が本体だ→これ脳科学的にはあるらしいけど認めると犯罪者への罪どーすんのみたいな話にもなるからキワドい
※6
自殺企図を持つ人を説得すると留まるデータが→マジか初めて知ったわ、風潮的にはメンヘラには触るなが正解になりつつあるのにな、なお未遂者は何度も繰り返す模様
※7
死にたい奴は家を飛び出してでも死ぬ→昔やって失敗したんだなこれが
※8
やっぱ怖いんじゃーん→死ぬのが怖いんじゃなくて失敗した時のリスクが怖いだろ犯罪しない理由と一緒、死にたいときに死ねる身体じゃなくなるって怖い
「つまり自分が実現可能だと思っていたら、それは逃げではない？」に対して「違うよ」というのは
「違うよ、逃げだよ」
「逃げとは違うよ、逃げではないよ」
どちらの意味にも取れるでしょ
「違うよ、逃げだよ」をAとし「逃げとは違うよ、逃げではないよ」Bとすれば
俺がAの意味で取れば「Bということだよｗｗｗ」Bの意味で取れば「Aということだよｗｗｗ」「読解力無しｗｗｗさすが低能ｗｗｗ」と言ってくる高能様メソッドだったに違いない
パターン化してるよね
そうでないならAかBかどっちか答えといてね
☆(007)ダメダメな人生を変えたいM君と生活保護 (ポプラ新書) 池上 正樹
なぜこの店で買ってしまうのか ショッピングの科学 (ハヤカワ・ノンフィクション文庫) パコ・アンダーヒル
33の法則 イノベーション成功と失敗の理由 オリヴァー・ガスマン
愛着障害 子ども時代を引きずる人々 (光文社新書) 岡田 尊司
☆儒教ルサンチマンの宗教 (平凡社新書 (007)) 浅野 裕一
サードプレイス―― コミュニティの核になる「とびきり居心地よい場所」 レイ・オルデンバーグ
陽のあたる家~生活保護に支えられて~ (書籍扱いコミックス) さいき まこ
排除型社会―後期近代における犯罪・雇用・差異 ジョック ヤング
☆働かない―「怠けもの」と呼ばれた人たち トム ルッツ
父が子に語る世界歴史〈2〉中世の世界 ジャワーハルラール ネルー
☆クリエイティブ喧嘩術 (NHK出版新書 408) 大友 啓史
コギトピノキオの遠隔思考 ソウルドロップ孤影録 (ノン・ノベル 1003) 上遠野 浩平
竜との舞踏 1 (氷と炎の歌 5) ジョージ・R.R. マーティン
子どもの難問 野矢 茂樹
☓つねに結果を出す人の「勉強脳」のつくり方 イ シヒョン
☆アーミッシュの赦し――なぜ彼らはすぐに犯人とその家族を赦したのか (亜紀書房翻訳ノンフィクション・シリーズ) ドナルド・B・クレイビル
この世でいちばん大事な「カネ」の話 (角川文庫) 西原 理恵子
統計学を拓いた異才たち(日経ビジネス人文庫) デイヴィッド・サルツブルグ
☆売り方は類人猿が知っている(日経プレミアシリーズ) ルディー 和子
☆☆国をつくるという仕事 西水 美恵子
林竹二著作集〈8〉運命としての学校 (1983年) 林 竹二
フィンランドに学ぶべきは「学力」なのか! (かもがわブックレット 169) 佐藤 隆
オッリペッカ・ヘイノネン―「学力世界一」がもたらすもの (NHK未来への提言) オッリペッカ ヘイノネン
コミュニケーション力を引き出す (PHP新書) 平田 オリザ
話し下手でも7割聞くだけで相手を惹きつけられる会話のコツ46 野本 ゆうき
Rules of Attraction Bret Easton Ellis
生きることのレッスン 内発するからだ、目覚めるいのち 竹内 敏晴
△ラノベのなかの現代日本 ポップ/ぼっち/ノスタルジア (講談社現代新書) 波戸岡 景太
俺のイタリアン、俺のフレンチ―ぶっちぎりで勝つ競争優位性のつくり方 坂本 孝
まことに残念ですが…―不朽の名作への「不採用通知」160選 (徳間文庫) アンドレ バーナード
足代小フューチャースクールのキセキ 徳島県東みよし町立足代小学校
ホテルはメイドでできている(1) (ジュールコミックス) 野崎 ふみこ
ホスピめし みんなのごはん(2) (ジュールコミックス) 野崎 ふみこ
りはめより100倍恐ろしい 木堂 椎
「自分の子どもが殺されても同じことが言えるのか」と叫ぶ人に訊きたい―――正義という共同幻想がもたらす本当の危機 森 達也
「奇」の発想―みんな『少年マガジン』が教えてくれた 内田 勝
ファンタジーを読む (岩波現代文庫 〈子どもとファンタジー〉コレクション 2) 河合 隼雄
メディアを語る (別冊思想地図β ニコ生対談本シリーズ#2) 川上 量生
(003)世界の美しさをひとつでも多くみつけたい (ポプラ新書) 石井 光太
☆☆津波の墓標 石井光太
鳥貴族「280円均一」の経営哲学 大倉 忠司
☆OLたちの「レジスタンス」―サラリーマンとOLのパワーゲーム (中公新書) 小笠原 祐子
「金縛り]の謎を解く 夢魔・幽体離脱・宇宙人による誘拐 (PHPサイエンス・ワールド新書) 福田 一彦
「なんで英語やるの?」の戦後史 ——《国民教育》としての英語、その伝統の成立過程 寺沢 拓敬
秘訣は官民一体 ひと皿200円の町おこし (小学館101新書 19) 五十嵐 幸子
「町おこし」の経営学―ケーススタディー・地域経済活性化 官と民の新たな関係 三井物産業務部「ニューふぁ~む21」チーム
☆なぜ富士宮やきそばはB-1グランプリの覇者となりしか？ Ｂ級ご当地グルメで500億円の町おこし 渡辺英彦
中小都市の「B級グルメ」戦略―新たな価値の創造に挑む10地域 関 満博
習慣の力 The Power of Habit チャールズ・デュヒッグ
波間の国のファウスト:EINSATZ 天空のスリーピングビューティ (講談社BOX) 佐藤 心
ネット上で話題の「恋愛工学」がよく分からないので工学生に直接メソッドを聞いてみた【ぐるなびWEBマガジン】
↑これ読んでウワー恋愛工学生やべーワハハって笑ってたんだけど、
そのあとふと興味本意でTwitter見に行ってちょっと背筋が凍った。
もちろんただネットで記事を読んだだけの私に、本人たちの心情など推し量るしかできないが
読んだ限りでは、このライターさんはほんっっっとうにこのやり取りが不愉快だったんだろうと感じた。
その上で、怒りを感じた箇所については、双方の発言のみで主観を極力挟まずに描写している。
私にはこれは、「もう二度と関わりたくない、ツッコミ入れられるような隙さえ作りたくない」という態度に見えた。
さて、そのような感想をもってライターさんのTwitterをふと覗いたところ、
“恋愛工学”を否定するなら、もっと精緻に否定してもらいたい件 ～恋愛工学・ぐるなび事変～ - かえるくん総合研究所,
という3点が目についた。
怖気をふるうほどの嫌悪と恐怖を感じた。
あの文章を読んで、「プロレス(=ある種の信頼関係に則って行われる喧嘩『芸』)」と自称して「わかってててやってる」風の空気を醸し出そうとし、
「ぐるなびさんの企画勝ち」などと「俯瞰できてるオレ」の演出に余念がない。
そこに見えるのは、どこまでも「オレ」がどう思われるか、についての余念なき自己チェックだ。
その割に、ライターさんからにじみ出ている(ように見える)嫌悪感には一切気づいていない、
目の前にいる女性がいかに嫌な思いをしたか、その日どんな気持ちを抱えて帰ったか、
そんなことを想像する気がない。
その人がどんな感情を抱えているか、何を考えているか、そんなことは考えない。
そんなことをいちいち考えてたら「やれない」のだ。
恋愛工学界隈ではこの記事をきっかけに「服装」が話題になったらしい。
バカか。
かっこいいスーツでも着てたら、同じ話題でも相手を不愉快にさせなかったとでも思うのか。
結局ここでも「相手」のことなどみていない。ブコメなどから見えた「俺たち」をみているばかりなのだ。
女に対して積極的になれるオレ。
女とやれるオレ。
そんな素敵な、オレ。
その目の前の「女」に顔はない。
CurrentControllerがミソ。
xls = XLOPEN("ファイル名", XL_OOOC) // Pro版でない場合はCreateOLEObjectに置き換えれば動くかも？
sheet = xls.CurrentController.ActiveSheet
sheet.getCellByPosition(0, 0).CharColor = "&H0000ff"
sheet.getCellByPosition(0, 0).CellBackColor = "&Hffff00"
http://hermione.s41.xrea.com/pukiwiki/index.php?OOoBasic%2FCalc
原文：https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
原題：Apache Commons statement to widespread Java object de-serialisation vulnerability
翻訳日：2015年11月12日（午後にタイトルを日本語にしました）
－－－－
Apache CommonsのJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント
著者：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) 氏はWebSphereやJBoss、Jenkins、WebLogic、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]
コメント：
Oracle は Weblogic にセキュリティアラートを発行しています：
