@ledsun blog

無味の味は佳境に入らざればすなわち知れず

続々・エンジニアの採用面接対策 コメントへの回答

学習力無力感

エンジニアの採用面接対策 - @ledsun blog

組織内での過去の経験から、相談が無駄だと思われてしまったケースもありそう "一人で不満を溜め込んで、やめることを決めてしまう人"

2018/02/02 18:36
b.hatena.ne.jp

おそらく、大抵の場合は、学習性無力感なのだと思います。 ただ、面接の場では、自社に所属すれば回復するのか、長期的な治療を要するものなのかは判断がつきません。 個人的なイメージでは、優しい人が周りにいるだけで改善するものではないように思えます。 一人でも否定的な物言いをする人がいれば、防御姿勢をとってしまうのではないでしょうか?

このタイプの人は、周囲に愚痴を言いながら、自分傷つけない相手かどうか試そうとする傾向があるように思います。 これは本人にとっては防御のための行動なのだと思いますが、愚痴を言われる周りの人間にはストレスです。

新しく採用する人のために、同僚にストレスを強いるのはなかなか難しいです。 自分が上司に「今度入ってくる人は学習性無力感なので、気をつけて接してください」と言われたら「なんでそんな人をとるのか?」疑問に思います。

「取引先の社長の子供で、採用すると今後数年間数千万単位の売上が見込める」と言われれば納得します。 「弊社が、今抱えている課題にフィットした経験を持っている」と言われれば、特定の課題を解決するまでの期間の有期契約で良いのでは?と思います。

給与と待遇

エンジニアの採用面接対策 - @ledsun blog

「一人で不満を溜め込んで、やめることを決めてしまう人」それって単純に給与や待遇に不満があるケースのような

2018/02/02 12:28
b.hatena.ne.jp

戦略的な給与体系をとるのであれば、給与は実績に応じて上げるのではなく、今後の成果への期待に応じて昇給すべきです。 社員の離脱を防ぐのに大きな効果があります。

この戦略を取れるのは成長フェーズにある企業です。 原資が必要です。 仮に、特定の社員の給与を上げるために他の社員の給与を下げると、下げられた社員の心理的なダメージは大変なものです。 数年内に回復しないと離職する確率が高いです。 成長の踊り場にある企業にとっては、戦略的な給与体系をとることは難しいでしょう。

その結果、社員の成長が給与と待遇を追い抜く可能性があります。 企業としては、成長を生かして新しいビジネスに挑戦すべきですが、ここでも原資が問題になります。 エンジニアとしては、自分をより高く評価してくれる環境にチャレンジするのが良いように思います。

この時、社員が所属企業の売上・利益の状況を理解していて、給与と待遇の改善は見込めないと判断しているのであれば、 相談なしで辞めてしまうのは止むを得ないと思います。

志望動機

エンジニアの採用面接対策 - @ledsun blog

志望動機を聞いてくるようなところには自分なら行かないかな。

2018/02/02 11:24
b.hatena.ne.jp

「志望動機」の質問から知りたいのは、会社に期待することです。 会社に期待することを1つも満たせない場合は、お互い不幸になるので、お断りしたいからです。

新卒採用の時のように、実績のない、比べようのない人材を比べるために使うわけではありません。 あくまで、職歴やスキルを優先して評価しています。 その上で、価値観が会社と著しくズレている可能性を懸念しています。

質問としては、雑に「志望動機」と聞くよりは、丁寧に 「(入社後に社員として)弊社に期待すること」を聞いた方が良いと思います。

写経

エンジニアの採用面接対策 - @ledsun blog

写経のちょい先レベルで書き捨てた物があればなんぼか持ってきてもらう感じかな>学習能力

2018/02/02 09:37
b.hatena.ne.jp

この発想はありませんでした。

個人的な予想では、

  • ほとんどない人
  • 小さいツール類を山ほど書いている人

に、綺麗に分かれると思います。

シニアエンジニアの採用であれば、後者にフィルタリングするのはありかもしれません。

それでも、自社の事業領域と、職務経歴の一致度を優先して評価すると思います。 中途採用の場合は、雇用から成果を出すまでの期間が短い方が嬉しいからです。

業務時間外の学習の強要

続・エンジニアの採用面接対策 コメントへの回答 - @ledsun blog

業務外に何をしようが自由ではあるが、実際にはそういった勉強時間を取らないとやってけないのでは。。。それが嫌なら勉強しなくて良い会社に行けば良い。

2018/02/02 12:58
b.hatena.ne.jp
続・エンジニアの採用面接対策 コメントへの回答 - @ledsun blog

エンジニア側から「あっブラックだ、やめとこ」と足切りされるやつだ > 「現職で、仕事に関する調べものを、仕事以外の時間でしたかどうか」

2018/02/02 11:16
b.hatena.ne.jp

コメントを見て気づきました。 これは合法的に「業務時間外の学習を要求」する方法です。

時間外の学習の強要 ブラック - Google 検索 を検索すると、経営者から「時間外の学習」を要求すると違法か、ブラック企業と言った趣です。

(上司でなく)一緒に働く予定のエンジニアとの面接の結果 「この人は自習しなさそうだから一緒に働きたくない」と拒絶されれば合法です。 まあ、恣意的に「自習しないエンジニアが嫌いな人」を面接官に起用して運用したら、グレーになると気もします。

大人力を要求されない場面であれば「教えてもらうだけで、自習する気がない人とは働きたくないのだけど、あなたは大丈夫ですか?」 と率直に聞くのが良いと思います。

続・エンジニアの採用面接対策 コメントへの回答

エンジニアの採用面接対策 - @ledsun blog

技術的なことについて自学自習できる人を見抜くコツが知りたい。簡単なテストをしてもあまり無意味な気もするし、めちゃくちゃ勉強はできるけど、仕事に全く活かせないorスピード感を掴めない人もいるし。

2018/02/02 07:56
b.hatena.ne.jp

技術的なことについて自学自習できる人を見抜くコツが知りたい。

面接中に確実に見抜く方法はないという前提で、 「現職で、仕事に関する調べものを、仕事以外の時間でしたかどうか」を聞くといいのではないかと思います。

本当に欲しいのは、現在の自社の業務の周辺知識ではなく、将来ぶつかる問題を(自力である程度)調べる能力かと思います。 (労働者に要求していいのかは法的に微妙ですが)「仕事に対して、要求された以上に興味をもって試したり調べたりして欲しい」のだと思います。

「現職では、業務内容に興味がないから調べたことがない」という人は怪しいです。 例えば「Deep Learningを勉強して試してみている」という人でも怪しいかもしれません。 現職と全く関係ないのであれば、自社に転職したあとも、自社の業務と関係ない流行っていることを自習するかもしれません。

これは、技術者としては、全く正しい姿勢です。 会社と一蓮托生するよりは、業務外は業務と関係ないことを勉強をした方が、技術者としての寿命は伸びそうです。 が、欲しがっている人材と一致しない可能性はあります。

簡単なテストをしてもあまり無意味な気もする

おっしゃる通り、自習能力をテストで判定するのは難しいと思います。 面接では、技術について好き嫌いと、その理由を質問するのが良いと思います。 例えば、

Rubyは好きですか?嫌いですか?それは、どういうところですか?」

Rubyの部分は別の言語でも、OSでも、アルゴリズムでも、フレームワークでもなんでも良いです。 応募者の職務経歴に載っていて、ある程度使っていそうな技術が良いです。 技術に対して、「意見」を持っているかどうかを確認します。

自分なりに「これはどう使うものか?」「自分の使いたいやり方にあっているか?」を考えながら、技術に接している証拠になります。 質問のコツは「良い・悪い」(客観的な評価)ではなく「好き・嫌い」(主観的な評価)を聞くことです。

主観評価を聞いていても、教科書的な回答をしてくる人には、ちょっと警戒します。 他人と違う意見をいうのが苦手な人がいます。 そういう人は、技術選択をする際に、自分たちの問題にフィットしているかより、世間の評判を優先する傾向があります。 技術理解度を確かめる質問だと、誤解されている場合もあります。即断はできません。

経験年数が2〜3年ぐらいで、比較可能な複数の技術を扱ったことがない人には、使えない質問かもしれません。

めちゃくちゃ勉強はできるけど、仕事に全く活かせないorスピード感を掴めない人もいるし。

「完璧主義でアウトプットを出すまで時間がかかる人を、採りたくない」状況を想定します。

面接の時点で「我々の扱っている分野は正解がわからず、トライアンドエラーで失敗を繰り返すことが多い。失敗した結果でも、同僚に見せなくちゃいけないし、恥ずかしい場面もあると思うけど、対応できる(耐えられる)か?」と、質問する(伝える)と良いと思います。

もっとストレートに表現するのであれば「どんどん失敗して、失敗を共有して欲しい。失敗を肥やしにして、周りの人を成功させて欲しい」と、伝えられると良いと思います。

当然、応募者には「それで失敗した自分は評価されるのか?」と疑問を持たれると思います。 胸を張って「評価します」と言いたいところですが、正直難しいです。

エンジニアの採用面接対策

paiza.hatenablog.com

に、面接で落とした理由があります。

最近は技術者が面接をすることが多いです。 技術者は採用面接に不慣れなことが多く、質問が下手くそです。 面接官側の不手際で、コミュニケーションに齟齬があって落ちていることもあると思います。

自分の採用面接経験での「こういうことが聞きたかったんだよ」という辺りを書きます。

実践すれば面接に受かることを保証するものではありません。

1位:自己表現(プレゼンテーション)力

職務経歴を聞かれて、一から十まで細かく説明しようとする人

面接の最初にお互いの緊張をほぐすために、自己紹介をしてほしくて使います。 面接官がどっから本題に入っていいのかわからないので、とりあえず聞いてみます。

30秒〜1分くらいで、簡単に説明してもらえれば良いです。 内容よりは、喋り方を見ています。 評価をするためよりは、これから会話をして行くときに「質問と回答のスパンをどれぐらいのリズムでやるか」などを考えながら見ています。

ここで落とすのは「うんざりするような自分語りが続いて、会話を成り立たせるのが疲れすぎる」場合ぐらいです。 苦手であれば1分間のトークスクリプトを用意して、カラオケボックスにこもって練習しましょう。 大事なのは時間の上限と、1つ1つの話題の区切り方です。正確性ではありません。

面接の場で、職務経歴を喋るときは、多少不正確な説明をしても問題ありません。 普通の面接官は、事前に職務経歴書を読んで質問したいことを用意しています。 職務経歴書の内容と、しゃべっている内容に気になる齟齬があれば、確認の質問をします。 その時、内容を修正してください。

稀に、職務経歴書に書いてあることをそのまま質問してくるなど、職務経歴書を読んでいない風の面接官もいます。 その会社はやめましょう。 その会社には、会議の前に資料を作成・共有し、共有された資料を読んでから会議に臨む文化がありません。 非効率な会議が多い会社です。

2位:志望意欲・やる気

転職理由が年収や福利厚生などの「条件面をよくしたい」だけで止まっている人

この質問は、「会社に期待すること」を知りたくて聞いています。 「会社に期待すること」を全て満たせるわけではありませんが、全く満たせなかった場合はすぐ辞めてしまうでしょう。 それを防ぎたいと思って聞いています。

ここで落とすのは、「うちの会社は、君が思っているような会社じゃないぞ」と思う時です。 直接言えることもありますが、大人の事情で直接言えずに落とすこともあります。

ただ、この質問には罠があります。 「志望意欲」の1つの質問で、実は2つのことを聞いています。

  1. 業界・業種を選んだ理由
  2. 会社を選んだ理由

本来は、「この業界・業種を選んだ理由は?」「その中でうちの会社が良いと思った点は?」と二段階で聞くべきです。 が、あまりにもありふれた質問なので、雑に「志望理由はなんですか?」と聞いてしまうことが多いです。 この場合は、丁寧に両方答えましょう。

「まず、業界・業種を選んだ理由は・・・。次に御社を選んだのは・・・」

業界・業種

「業界・業種を選んだ理由」は、素直に業界・業種に期待することを話しましょう。 「サービスを使う側から作る側に回りたい」「受託開発より長いスパンでサービス開発に携わりたい」などです。 一般論なので、そんなに深く突っ込むことはありません。

突っ込むとしたら、「業界・業種」への期待が現実と違いすぎる場合です。 例えば「サービスを当てて億万長者になりたい」な理由の場合は、「受託開発業界に来ても遠回りすぎるからやめとけ」な思いを抱きます。

会社

「会社を選んだ理由」は、競合が何社かある中で、その会社を選んだ理由です。

BtoC

BtoCのサービスを提供している会社であれば、「サービスを使ったことがあって好きだから」みたいな理由ができていいですね。

面接の前に試しにサービスを使ってみるのは重要だと思います。 サービスのコンセプトやユーザが気にくわない会社はやめましょう。 自分が嫌いなサービスの開発に携わるのはストレスがたまります。 短期であればいいですが、長期的な関係を築くのは厳しいです。

BtoB

BtoBの会社であれば、待遇面の話でよいと思います。 「働き方に共感した」「教育制度が充実している点に期待している」などと言えば良いと思います。

企業のインタビュー広告などあれば、それを見て共感したとか言うとポイントは稼げるかもしれません。 ホームページにある「会社の理念」がどうこうな話は、新卒採用の場合はわかりませんが、中途採用の場合は興味がないです。

大望

もし大望があるのであれば、可能な限りでかい話をしておいてもらった方が良いように思っています。 「御社の〇〇で業界の悪習を変えたい」や「御社の〇〇で、XXの生活を変えたい」のようなレベルでも良いと思います。 面接官が「会社の求めているレベルより理想が高すぎる」「こんなに意識が高いやつがうちの会社に入ると苦労する」と思えば落としてくるはずです。

自分が「御社の〇〇で業界の悪習を変えたい」と思っている時に、会社の幹部が「そういうのはどうでもいいので売上を増やしたい」と思っている会社に入ると、あまり幸せにはなれないように思います。

3位:技術的な取り組み・技術探究心

やってないことに対して「やりたいです」「やる気はあります」と言うだけの人

この質問で聞きたいのは、技術的なことに対して、教えてもらうだけでなく、自分から調べる能力があるかどうかです。 要するに、「自習する力があるか」と「それを技術に向ける関心があるか」を確認しています。

これには2つの理由があります。

  1. 技術の変化が早すぎて「誰かが正しい技術を調べて展開する」で対応できない業界事情
  2. 自習力を教える方法がわからない

業種の転換をしたい面接者の場合は、

  1. Web業界に行きたいです
  2. そのために何をしていますか?
  3. 具体的にはなにも・・・

となることがあります。 この場合でも

  1. 現職で、社内教育で学んだこと以外に、自力で調べて問題を解決したこがある
  2. Web業界に興味があって、こんな媒体を見ている

と言う話をしてもらえれば大丈夫です。

1をやったたことがない人は、マジで技術者に向かないと思うのでやめておいた方がいいと思います。

2の媒体があまり技術方面でなく、ビジネス方面だった場合は、「業界・会社に期待していることが合わない」可能性を考えます。 「泥臭いことの方が多いけど大丈夫?」のような質問します。

プログラミング未経験者の場合は、プログラミングをやってみてから全く合わないことが判明することがあります。 この質問とは別の対策が必要だと思っています。

4位:忍耐力

転職回数が多い人

人を採用すると、

  • 転職斡旋業者への報酬
  • 教育費用
  • 事務手続き費用
  • 営業費用

などなどかかるので、できれば一度雇った人には長期的に働いて欲しいです。

ここ知りたいのは「やめると決める前に、不満点をあげるなど事前の相談をしてくれる人」かどうかです。

一人で不満を溜め込んで、やめることを決めてしまう人は、 採用コストはかかるわ、会社としてフィードバックは得られないわで、雇っても嬉しくありません。 辞めること自体が悪いわけではありません。

「あまりにもヘビーな環境だったが、相談したが職場転換などしてもらえなかったので辞めました」というのは十分な理由です。

5位:責任感・当事者意識

転職理由が「やりたいことができないから」「周りが悪いから」だけの人

ここでは「一緒に仕事をして気分が悪くなる人」でないことを見ています。

落とすのは、面接官が「周りが悪いから」の対象になったことを想像した時に 「自分の仕事には関心を持つ価値がない」「自分の仕事を馬鹿にされた」と感じた時です。 面接の場で、特定人物の悪口を言うのはやめましょう。 面接官は人間なので「人への悪口」は自分に飛んでくることを想像します。

現職では今後、金融系の受託開発事業のみに絞られていくことが決まっています。このままでは自分が将来のために身につけてきたスキルも無駄になってしまうと感じたため

のように、会社の方針とのミスマッチを理由にするのが良いです。

本当のところ、知りたいのは「問題を上司にでなく同僚にだけ言う人」かどうかです。 不満や問題を会社の事としてエスカレーションできない人は、職場の文化を破壊します。 とは言っても、実際に愚痴っぽい人は、面接官のように立場が強い人には何も言いません。 面接の場でこの性質を見抜くことは、とても難しいです。

2017年にやった技術的なチャレンジ

d.hatena.ne.jp

をみて、なるほどと思ったので、自分の成果も棚卸しをしておきます。

一年を通して

一年を通して見ると、Rubyを使ったHTTPサーバーで非同期に結果を返し、ブラウザで非同期に受け取った結果を画面に反映した一年でした。

2016年に比べて成長を実感するのは、一見難しいことを簡単に実装できるようになったことです。 「DOM更新アルゴリズムの実装」「同時処理リクエスト数制限の実装」は一見難しそうです。 やる前は、「正しく動くようにするのに1〜2週間はかかるかな」と思いました。実際にやってみたら数日で実装できました。

まだ、自分でも何が変わったのかはよくわかっていません。 必要な要件から、問題の核心をより小さいサイズに絞り込む能力が身についたのかもしれません。

伝統武術のでいう「心・技・体の体」ができたような気がします。 そのつもりで、今年は体を生かして、技を増やそうと思います。 今までやったことないことに、色々チャレンジしようと思います。

チャレンジ

UIのデザイン変更のためにDOM更新アルゴリズムの共通化

LODQA : Question-Answering over Linked Open Dataユーザーインターフェースの大幅な修正を行いました。表示項目は今までの開発経験により絞り込めていましたが、リンクドデータに馴染みのないユーザ向けに配置や表示順を工夫する必要がありました。特に検索結果を詳細に表示するのではなく、サマリーをまとめて表示する変更を行いました。

これまで検索結果の表示は、受け取った結果を随時、末尾に追加するのみでした。ブラウザのDOM APIを使って、DOM要素を追加して表示を更新していました。サマリー表示のためには、追記の他に既存DOM要素の中間への挿入が必要になりました。

そこでReactのVirtualDOMのような差分更新アルゴリズムが欲しくなりました。一方、すでにHTMLテンプレートとしてHandlebarsを使っていました。これをJSXに置き換えることは避けたいです。

そこで、DOM更新アルゴリズムを自前で実装し、DOM APIを使ったDOM要素更新処理を置き換えました。これにより、アプリケーション上のDOM更新のロジックは新規作成と更新が全く同じになりました。プレゼンテーションロジックの記述量が減ったため、修正工数も減りました。大幅なユーザーインタフェース変更に対応することができました。

この時作ったDOM更新アルゴリズムの説明は

ledsun.hatenablog.com

にあります。

サーバサイドのクエリ生成・実行処理の無限リスト化

LODQA : Question-Answering over Linked Open Data では

  1. 自然言語(英語)の質問からSPARQLへの変換
  2. 登録されている全てのSPARQLエンドポイントへの問い合わせ

を自動で行います。ここで問題になったのは特定の英文をSPARQLに変換する際に、サーバ上のメモリをGB単位で消費することでした。その英文からは、50万を超えるSPARQLを生成してしまいます。

そこでRubyEnumeratorクラスを作って

  1. SPARQL生成
  2. SPARQL実行
  3. クライエントへの結果送付

を逐次的に行う実装に修正しました。 これによりサーバのメモリ消費を、同時処理リクエスト数によらず、100MB程度に抑えることができました。

サーバ処理を並列化するときに懸念されるのは、レスポンスの悪化です。 クエリのボトルネックはSPARQLエンドポイントにあります。 SPARQLの生成に比べるとSPARQL実行の方が10倍以上遅いです。 サーバのレスポンス低下は、ユーザーから見ると誤差の範囲でした。

Wampリクエスト処理の並列化

IoT機器と通信を行うRailsアプリケーションを作成する際にWampRailsというGemを使いました。 性能上の要件を満たすために、Wampリクエスト処理の並列化をしました。 WamapRailsはEventMachineに依存しているため、EM.deferメソッドを使ってマルチスレッド化することで並列化を実現しています。 これによりRailsの1リクエスト=1スレッドというRail Wayを外れることになりました。

まず、高負荷時に応答を返せるように、同時処理数に上限を儲けました。 たとえば、Rails+Pumaではワーカスレッド数で同時処理リクエスト数を制御しています。 同様の制限を行います。 WamapRailsは非同期にレスポンスを返すためにDeferインスタンスを生成します。 この生成処理を利用し、Deferインスタンスの同時生成数を管理することで、同時リクエスト数制限を実装しました。

もしこれをスレッドプールとして実装した場合は、スレッドプールのテスト自体の工数がバカになりません。 さらに、Pumaのスレッド管理、EventMachineのスレッド管理が既に存在するので、運用上スレッドに何らかの問題が見つかった場合に、原因切り分けが困難になるでしょう。

次にDBコネクションの解放処理を追加しました。 RailsではRackミドルウェアで使用済みのDBコネクションを解放しています。 WamapRailsのための作成したスレッドは処理を終了しても、Rackミドルウェアを呼び出すことはありません。 これもDeferインスタンスを活用し、レスポンス返送時に、明示的にDBコネクションを解放することで対応しました。

RailsのDBコネクションプールの統計値を取得

あるRailsアプリケーションで複数のデータベースを扱いました。

この時、Google Cloud Platform上のデータベースとのコネクション状態がActiveRecordのコネクションプール場では検知できない現象に悩まされました。 実際のコネクションが切断されていてもコネクションプール上では切断が検知されず、実際にSQLが発行されるときになって例外が出る現象に出会いました。

残念ながら、原因を特定するに至りませんでした。 アプリケーションの特性上、GCP上のデータベースは参照機会が限られていました。 データベース利用終了時にコネクションを明示的に切断して対応しました。

この調査の際にActiveRecordのコネクションプールの状態を取得したかったのですが、Rails 5.0には適当なAPIがありませんでした。そこでRails5.1に追加された、ActiveRecord::ConnectionAdapters::ConnectionPool.stat をバックポートして使いました。

その他

Redmineプラグインの作成

ledsun.hatenablog.com

IoTゲートウェイモデリング

ledsun.hatenablog.com

技術同人誌執筆

ledsun.hatenablog.com

ledsun.hatenablog.com

「有名な統計力学ゲーム」をcanvasで表示してみる

今回のテーマ

前回の

ledsun.hatenablog.com

では、やり取りの結果をSVGのレーダーチャートで表示しました。 SVGではやり取りが1000回を超えると快適に表示できませんでした。 今回は、canvasのレーダーチャートに表示します。

チャート

See the Pen statistical_mechanism_on_canvas_chart by shigeru.nakajima (@ledsun) on CodePen.

さすがはcanvas、圧倒的な描画性能です。 やり取りを一万回ぐらいやるとバランスよく星型になるのがよくわかります。

ちょっとした工夫

canvasであっても1万回描画すると*1それなりの時間がかかります。 そこで複数回のやり取りをまとめて描画しています。 かつ、やり取り回数が多い時は、たくさんまとめて、少なく立ってきたらまとめる数を減らして描画しています。 これで

  • 1千回で1秒
  • 3千回で3秒
  • 1万回で7秒

ぐらいの比率で描画しています*2

やり取り回数が多い時は、たくさんまとめて、少なく立ってきたらまとめる数を減らすための計算式が

Math.ceil(Math.log(残り回数)) + 1

です。logを取って、残り回数の桁に比例*3して、まとめる数を増やしています。 最後に1を足すのは、log(1)が0だからです。まとめる数が0回だと無限ループします。

考察

「有名な統計力学ゲーム」の驚きは、「公平なルールに見えるのに、実際に運用すると不公平(偏り)が生まれる」です。 これは「公平になるには、たかだか数百回のやり取りで十分だろう」という思い込みを利用したトリックに思えます。

「宝くじは、超長期的には損するが、短期的に得することがある」という仮説が考えられます。 このルールを見たときにも同様に 「長期的には公平であるが、公平になるまでには偏りは生まれる」までは予想できます。

実際に手で試してみると、数十回〜100回程度やり取りしても、公平になりそうな雰囲気が出てきません。 「もしかして、このまま続けても不公平なままなのでは?」という疑問が出てきます。 ここに驚きを感じます。

1000回試すと、偏りが持ち回りになる様子がわかります。 これで、もっと続ければ公平になりそうに思えてきます。 実際は、3000回やり取りしても、公平にはなりません。 これは当初の「たかだか数百回」の予想とは大きく違っています。

*1:正確には1万回setTimeoutを呼ぶのに掛かる時間です。

*2:実際の時間は実行環境、ブラウザを開いているPCの性能、に依存します。

*3:厳密には比例ではありません

「有名な統計力学ゲーム」をレーダーチャートで表示してみる

今回のテーマ

前回の

ledsun.hatenablog.com

では、分配アルゴリズムの実装と結果を数値で表示しました。 今回は、アルゴリズムには変更を加えずに結果をレーダーチャートで表示します。

チャート

See the Pen statistical_mechanism_on_chart by shigeru.nakajima (@ledsun) on CodePen.

毎回のやり取りの結果をクリアせずに上書きしています。コインの偏りの時系列変化が見えるようになりました。

考察

頂点が尖る人(コインを多数獲得している)が時系列で変わっていることがわかります。 やり取り回数を増やせば、満遍なく全ての人が尖るのではないでしょうか?

現在の、やり取り回数は1000です。 1000回では、頂点が尖らない人がいます。 何回まで増やせば偏らないことが確認できるでしょうか?

今回はSVGを使って実装しています。 SVGでは、polygon数が2000個、頂点数が2500個ぐらいで、描画が明らかに遅くなります。 一度のやり取りの描画に1秒以上かかります。 試しに3000回やり取りしてみても、頂点が尖らない人がいます。 もっと回数を増やす必要があります。

  • canvasなら、もっと多くの頂点が描画でき、もっと多くのやり取りを表現できるでしょうか?
  • やり取りの毎回のコイン数を描画せずに、偏りの推移を表現できるでしょうか?*1

*1:「大沢流-手づくり統計力学-大沢-文夫」第2−2節では、トップ回数と0の回数で表現していました。

受託開発デザインパターン 「止められなければ実装する」

背景

受託開発中です、二次請より低い階層におり仕様の決定権を持っていません。 発注元の、仕様の決定が遅れています。 協力会社を使っていて、何もしない空き時間でも費用がかかっています。

フォース(こんな問題がある)

仕様を決定する人は決断力を欠いている傾向があります。 提案された、仕様を否定する決断力も欠いています。

仕様決定待ち時間中も費用は掛かりますが、発注者は「作業をしていない時間は費用が発生しない」と認識していることが多いです*1。仕様決定後に、空き時間で浮いた費用を使って、実装作業を要求することが多いです。

解決方法

「今ある資料から、こういう仕様だと推測しました。○月×日までに仕様変更を提示しない場合は、この仕様で実装します。」と宣言します。 発注元に、止められなかった場合は、提示した仕様で実装します。 納品日がくれば、提示した仕様に従った実装を納品します。

成果物を作成すれば、費用を請求できる可能性ができます。 半額でも支払ってもらえれば、残りの作業は残り半額分の作業で済みます。

仕様を決定する人は、決断力を欠いている傾向があるので、「○月×日までに仕様変更を提示する」決断ができない可能性が高いです。

副次的な効果

もし「仕様は決められないが、その間の費用を払いたくないので作業も止めてくれ」と言ってもらえれば、実装開始日の予定を設定し、その日まで協力会社を解放できます。 費用が抑えられます。

下書き

*1:請負契約の場合は、費用は発生しません。が、請負契約の場合は、契約締結時点で仕様が決まっているはず・・・

「有名な統計力学ゲーム」を実際に試してみる

有名な統計力学ゲーム

底本

の演習問題1「サイコロとチップ」です。

  1. 人数が多い場合は6人グループを作る。6人以下の時は1人何役かする。グループ内の各人に1番から6番まで番号を付ける。
  2. サイコロを2つ、チップを30枚用意し、テーブルの真ん中(場)に置く。
  3. サイコロを振り、1が出たら1番目の人が場からチップを1枚とる。同様に、2が出たら2番目の人が、3が出たら3番の人が…というように場からチップを1枚とる。これを30回行い、場にあった30枚のチップを全部配る。
  4. 各自が持っているチップの枚数を記録。
  5. やり取りをした後に各人の持つチップの数がどう変化するかを予想する。
  6. やり取りを開始する。1セットにつきサイコロを2回フル。1回目に振ったときに出た目の番号の人は場にチップを1枚出す。2回目に振ったときに出た目の番号の人は場のチップをとる。例えば、1回目に3の目が出て、2回目に5の目が出た場合は、3番目の人がチップを場に出し、五番目の人がチップをとる。このチップのやり取り1回で1セット。
  7. 最低でも25セット(平均値の2乗)、できれば150セット(平均値の2乗 x 人数)やり取りを繰り返す。
  8. 途中でチップが0枚になる人が出ても続ける。0枚の人がチップを出す目が出てもチップを出す必要がないが、チップをもらえる目が出た時はチップがもらえる(借金はしない)。ただし、0の人がチップを出す目が出た時も1回やり取りしたとカウントする。
  9. やり取りを全セット終了したら、各自の持っているチップの枚数を記録する。
  10. やり取りをする前のチップ数と、やり取りをした後の各自のチップ数を比較する。

面倒なので、初期状態では5枚ずつ均等に配りました。 影響はないと思っています。

See the Pen statistical_mechanism by shigeru.nakajima (@ledsun) on CodePen.

考察

偏りが生まれることはわかりました。 なぜ偏るかは、よくわかりません。

偏り方になんらかの法則はあるのでしょうか? 乱数から偏りが生まれているはずなので、ないはずです。

グラフで描画したら何か新しいことがわかるでしょうか?

2017年TOEIC戦記

2017年の目標

2017年の目標は、TOEIC800点。

結果

受験日 得点 LISTENING READING
4/27 645 - -
9/10 745 430 315
11/19 605 315 290
12/10 705 380 325

達成はできませんでした。善戦しました。 試験によって50点ぐらい上下するらしいです。 それ以上の振れ幅ですが、現在の実力はだいたい700点のようです。

勉強方法

英会話学校

一番効果が大きかったのは英会話学校です。 6月7月にマンツーマンコースでTOEIC対策をお願いしました。 40分x70コマ、¥433,986で、100点上がりました。

体感では、変なところでつまづいたり、ある時突然パワーアップしたりせず、線形に効果が出ました。 英語教育の歴史は長いので、すでにかなり最適化されているのだと思います。 学習方法としては効率的に思えます。 一回の課金額が大きいのが勇気がいるところです。

個人的な経験では、週一の学習は、授業内容を一週間で忘れ、次の授業時間を前回の内容を思い出すのにほとんど使ってしまうので、効果が低いように思えます。 すくなくとも週2の学習機会がある方が良さそうです。 受託開発をしていると、繁忙の波が読めないので、安定した案件の時に短期コースをやると時間が調整しやすかったです。

単純に考えれば、もう一回40万円課金すれば800点超える見込みです。

勉強時間

英会話学校で一番大きいのは、45時間超の勉強時間を半ば強制的に確保できることです。 40万円をドブに捨てるのは痛いので、やる気が出ます。

TOEICの点数に一番寄与率が高いのは勉強時間のようです。

参考: 電通大新入生に1時間/日の 英語学習を勧める根拠

問題文の背景

2番目に良いのは、問題文のシチュエーションを質問できる点です。 例えば、アメリカの野球スタジアムでは、Webでチケットを予約してチケットカウンターで受け取って入場するのが一般的だそうです*1。 これを知らないと「チケットをカウンターで受け取る?買うのではなく?」というように、問題文が正しく読めていたのに、読み取りに何か勘違いがあるのではないか悩みます。その結果、時間を無駄に使ったり、間違った回答を選んでしまったりします。

英会話学校は、英会話の学校なのでリスニング能力は上がりやすいです。 リーディングは直接的には上がらない点が欠点です。 リーディングの速さはTOEICの点数に直結するので悩みどころです。

リーディング

リーディング対策も色々試してみました。 点数として効果は上がっていないので、必ずしも良い方法ではないと思います。

テキストは NEW TOEIC® Skills 2 | ABAX ELT Publishing を使いました。 特別これがいいということはなく、英会話学校で教材として買ったものを、そのまま使いました。

当初、問題空間を網羅するという作戦を立てたにも関わらず

8分よりさらに速く読むことにとらわれ

問題文を速く読む方向に最適化していきました。 よくないですね、局所最適化の罠です。 この結果が705点です。

当初の作戦通り、たくさんの長文問題を読んで問題空間を網羅する作戦が良さそうです。

*1:日本でも、小さなライブハウスのチケット取り置きは、同じ流れです。野球のチケット購入については詳しくないのです後、大きなライブハウスのように、「ぴあ」などのチケット業者を介して事前にチケットを買いコンビニで発券するイメージを持っています

キャッシュカード落とした

銀行のキャッシュカードをATMに置き忘れました*1

朝、ATMに行って入金し、夜に財布の中にキャッシュカードがないことに気がつきました。 ATMの置き忘れの確率が高いのですが、気づいた時間が遅すぎるため、日中の移動中にどこかで落とした可能性もあります。

次の日、ATMから一番近い公共施設、駅の改札に行って聞いてみました。 キャッシュカードの落としものはあるものの名前が一致しないそうです。 また、この駅では改札外での落とし物は、駅の外なので、交番に誘導するそうです。

交番で確認したらありました。 管轄の警察署にありました。 前日の朝、届けられ、聞きに行った日にはすでに警察署に移動されていたようです。 警察の落とし物照会は電話でした。 2018年、平成も終わろうという年に電話です。 電車の落とし物紹介は電子化されていました。 なかなか驚きです*2。 結局、ATMに置き忘れで届けてくれた人がいたそうです。 届けられた時刻は、落としてから、30分も経っていませんでした。 親切な人はいるものです。

一応、銀行に電話してキャッシュカードを止めていました。 その時、不正利用がないことも確認してくれました*3。 生体認証を登録していたので、不正利用される確率はほとんどありません。 生体認証は、銀行に連絡するまでの間も安心感があっていいですね。

これから、銀行窓口でキャッシュカードを再開してきます*4

*1:今まで、忘れたことがないので驚きました。加齢による衰えでしょうか?

*2:災害に強いインフラを使うという考慮があるのでしょうか?それとも単に予算不足なのでしょうか?

*3:口座情報はマネーフォワードに登録していたので、スマートフォンアプリで確認済みでした

*4:お届け印と本人確認書類が必要だそうです

DOM更新アルゴリズムを実装しました

github.com

動機

virtual-domの良さ

Reactに代表されるようにGitHub - Matt-Esch/virtual-dom: A Virtual DOM and diffing algorithmを使うと、デザイン変更時に、JavaScriptのロジックを考えずに、HTMLとCSSを考えるだけよくなることがわかっています。

一方でvirtual-domはGitHub - hyperhype/hyperscript: Create HyperText with JavaScript.形式のAST(抽象構文木)を自分で作る必要があります。そこでReactではIntroducing JSX - Reactという新しい記法を作って、HTMLライクに記述できる様にしました。

JSXの悪さ

JSXには2つ問題があります。

  1. HTMLではない
  2. Babel · The compiler for writing next generation JavaScriptでJSXからJavaScriptに変換する必要がある

最初から、Reactを使うのであれば問題ありません。 既存のWebアプリケーションに部分的に適用する場合は、BabelとJSXの投入は大きな変更です。 JSXは、HTMLのようでHTMLではありません。HTMLからJSXに置き換える作業が必要です。 ワークフロー上、Babelを使っていなかった場合は、新規にBabelを使用する必要があります。

HTMLを入力とする

そこで、HTMLを入力としてDOMを更新する関数を作成しました。 Handlebars.js: Minimal Templating on Steroidsの様なHTMLを生成するテンプレートエンジンを使っている場合は、生成したHTMLをそのまま入力値として使えます。 テンプレートエンジンを使っていない場合でも、現在表示しているDOMを、Google Chromeの開発ツールを使ってHTML形式でコピーすることで、流用できます。 この場合は、動的に置き換えたい値をテンプレートリテラルやテンプレートエンジンを使って置き換える作業が必要です。

設計

大方針

  1. GitHub - inikulin/parse5: HTML parsing/serialization toolset for Node.js. WHATWG HTML Living Standard (aka HTML5)-compliant.を使ってHTMLをASTに変換
  2. ASTを辿ってDOMに反映

細かい知見

appendChildはツリーの帰り道で行う

DOMにNodeを追加すると、その度にNode追加後の表示要素の場所を再計算します。 Nodeを追加する際は、Nodeとその子Nodeを作成してから、Node.appendChild - Web API インターフェイス | MDNします。

ツリーを辿る順序では行きでNodeを作成し、帰りでNodeを追加します。 ロジックとしては、子Nodeの更新が終わった後に、appendChildします。

Nodeの型の変更

DOMは既存のNodeの型を別の型に変更できません。 例えばdivspanに変更できません。またElement(HTMLタグ)をTextNode(タグの中身)に変更すること、その逆もできません。

型が変わった時は、新しいNodeを作成し、Node.replaceChild - Web API インターフェイス | MDNを使って既存のNodeと入れ替えます。

boolean attributes

Nodeにはboolean attributesという属性があります。

例えば

  • disabled="disabled"
  • checked="checked"

です。 これらはDOM上の属性をelement.setAttribute - Web API インターフェイス | MDNで変更しても、ブラウザ上の見た目には反映されません。

Node.disabledなどの、個別のプロパティを併用する必要があります。

やっていないこと

リストへの挿入時の最適化はしていません。 liタグなどで作ったリストに、最後尾への追加でなく、途中への挿入をした場合、それ以降の要素は全て変更したとして扱います。

経緯

Ruby でつくるRubyを読んでASTの辿り方を学んだ

ledsun.hatenablog.com

わずか120行のソースコードを写経するだけで、ASTの扱い方が理解できる本です。

update-dom-tree基本戦略は、この本のASTの扱いと一緒です。 ASTを辿ると同時に評価し、DOMに反映します。

virtual-domは、差分検知と更新の二段階に分かれています。 変更を検知したNode以下を作り直し、replaceChildします。

Node.jsのスクレイピング情報を整理してHTMLのASTを得る方法を学んだ

qiita.com

スクレイピングのは

  1. HTMLの取得
  2. HTMLの評価

の2要素からなります。 このうちHTMLの評価ではHTMLのパースが必要です。 色々な方法があります。この時の知見からparse5を選択しました。

  1. pure JavaScript
  2. メジャーなライブラリで使われている
  3. 更新が活発

の3点を重視しました。

結果

デザイン変更の自由度の上がりっぷりは最高でした。

  1. HTMLでイメージに合ったUIを作る
  2. handlebarsを使ってデータとテンプレートに分ける
  3. update-dom-treeを使ってビュークラスを作る
  4. モデルクラスを作って、データ更新のAPIとイベントを作る

という手順でコンポーネントが作れます。 UIの

  • 表示項目
  • 表示イメージ
  • データの取得方法

が固まっている時に、サクサク作れて便利です。

実装にかかった時間は、初期実装とデバッグを合わせても丸1日程度でした。 それに比較すると、デザイン変更の自由度の上昇はかなり大きな利得です。

記録

忍者式テストとは?

「忍者式テストの定義が知りたい」という意見を観測しました。 実践者の一人として、現時点の理解を記録します。

簡単に言うと?

忍者式テストは、手動テスト手法の1つです。 開発者が、日々のテスト実施を通して

  • テスト項目
  • ユーザーとしての視点
  • テスターとしての視点

を育てていく手法です。

どういうときに向いている?

どうやって実施する?

  1. 毎日、全てのテスト手順を最初から最後まで実行する
  2. テストを実施しながら、テスト手順を修正する
    1. 間違っているテスト手順を見つけたら修正する
    2. 足りていないテスト手順を見つけたら追加する

準備

最新のプロダクトをユーザー(の立場)で操作できる環境

  • 本番環境である必要はありませんが、本番と同じ機能が動く必要があります
  • データはダミーでもいいですが、本番と差が少ない方が違和感に気づく効果が大きいです
  • APIしかないプロダクトには向きません

手動テスト項目

  • 最低1つで十分です
  • テスト項目の網羅性や効果は気にしなくて良いです。バグが見つかるテスト項目でなくて構いません
  • テスト実施者が再現できる手順であれば良いです。プロダクトに対する知識のない人が、再現できるテスト項目である必要はありません

毎日の作業時間(数分 〜 1時間)

  • 最初は数分で終わります。物足りない感じすらあります
  • 1時間を越えると、集中力が切れます。おすすめしません

嬉しさ

小さなテスト手順書から始められる

  • 網羅性の高いテスト手順書をつくるには、プロダクトの機能への理解が必要です
  • プロジェクトに参加したてで、プロダクトへの理解が半端な段階から始められます

発見がある

毎日テストを実行すると色々な発見があります。

テスト手順に対して

  • テスト手順の順序の非効率さ
  • テスト手順のわかりにくさ
  • テスト手順と違う操作をしてみたくなる

テスト手順と違う操作をしてバグが見つかったとき、その手順は新しい有効な(バグが見つかる)テスト手順です。 新しいテスト手順として、テスト項目に追加しましょう。

プロダクトに対して

プロダクトに違和感を感じる時があります。

  • 作っている時は気づかない
  • 初めて使った時もわからない
  • シナリオで操作すると、前の画面と今の画面の機能が矛盾していることに気付いたり
  • 違和感は、(仕様の)バグかもしれない

違和感を見つけたら、違和感の原因を考えましょう。 もっと良い機能やインタフェースが見つかるかもしれません。

ユーザーの立場や気持ちへの理解が深まります。 作るのが面倒で使って嬉しい機能を作るモチベーションになります。

新しいバグ

  • Testing vs. Checking « Developsense Blog の話
  • 自動テストでは、違和感を検出できない
  • 明確なassert違反しか発見できない
  • assert違反はテストが壊れているだけで、バグとは限らないかもしれない

assert違反から学べることは、プロダクトコードのミスか、テストコードのミスです。 違和感からはプロダクトを使う背景や、ユーザーの気持ちが学べます。失敗した時の嬉しさは、自動テストより手動テストの方が多いです。

バグを埋め込んでから発見するまでの時間が短い

毎日、テストを実施するとしょうもないバグを翌日に見つけることができます。 昨日の作業は覚えているで、デバッグが簡単です。

一週間後に気付いたときは、一週間前に実装した機能を思い出すのは一苦労です。 脳みそのワーキングメモリが節約できます。

何ではないの?

  • 自動テストではない
  • 完璧なテストハーネスではない
  • テスト項目がをふやす続けると、どこかで減らす必要がある。が、減らす方は扱わない
    • つまらないテストを減らすのがよい
  • しばらく実施していないテストの戻し方は扱わない
    • ラウンドロビン
    • ランダム入れ替え
    • プロダクトコードの変更箇所に応じて選ぶ

忍者式テストだけでは、そんなに長い期間は戦えません。 状況に応じて、工夫を追加していきましょう。

歴史

sho.tdiary.net

歴史上に「忍者式テスト」が出現したのは、2004年です。

その他の参考情報

忍者式テストを最初に初めて名前をつけた、咳さんの2014年のスライドにも書いてあります。

名前

タケカワユキヒデ氏の英単語の学習方法に、「毎日に最初から覚えたかどうかチェックして、一定時間で到達できた場所で進捗を管理する」な手法があり、それが「忍者式」を冠していて、そこから「忍者式テスト」と名付けたそうです。

いつだったか、咳さんに聞きました。正確な内容は覚えていません。

おまけ

Clojureを学ぶ

RICH HICKEY氏の発言がめちゃくちゃ面白かったので、Clojureを学ぶことにしました。

この資料は、RICH HICKEY氏の発表を解説してくれる勉強会の資料のようです。 clj-nakano.connpass.com 該当会には参加していませんん。

環境を作る

leiningenというものを作ると環境構築が簡単なようです。

MacではHomebrewからインストール可能です。

brew install leiningen
lein --version
Leiningen 2.8.1 on Java 1.8.0_25 Java HotSpot(TM) 64-Bit Server VM

REPL

REPLがあります。 lein replで起動します。

~ lein repl                                                                    ~
nREPL server started on port 58165 on host 127.0.0.1 - nrepl://127.0.0.1:58165
REPL-y 0.3.7, nREPL 0.2.12
Clojure 1.8.0
Java HotSpot(TM) 64-Bit Server VM 1.8.0_25-b17
    Docs: (doc function-name-here)
          (find-doc "part-of-name-here")
  Source: (source function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
    Exit: Control+D or (exit) or (quit)
 Results: Stored in vars *1, *2, *3, an exception in *e

user=> 

Hello Woldしてみます。

user=> (println "hello world")
hello world
nil

1から10までを足す

簡単なお題で練習してみます。

足し算

user=> (+ 1 2 3 4 5 6 7 8 9 10)
55

和の公式で

user=> (/ (* (+ 1 10) 10) 2 )
55

再帰呼び出し

user=> (defn sum
  #_=>   [list]
  #_=>   (if (= (count list) 0)
  #_=>     0
  #_=>     (+ (first list) (sum (rest list)))))
#'user/sum
user=> (sum [1 2 3 4 5 6 7 8 9 10])
55

再帰が深くなる場合は、末尾最適化をしないといけないらしいです。

reduce関数

user=> (reduce + [1 2 3 4 5 6 7 8 9 10])
55

redmine.tokyo 第13回勉強会勉強会参加録 #redmineT

redmine.tokyo

に参加してLTしてきました。

speakerdeck.com

経緯

Pluginを作ってツイッターで自慢したら

お誘いを受けたのでLTしてきました。

学んだこと

Redmineの開発状況

開発は継続していました。以前に Issues - Redmine で、残チケット数が4000を超えているのを見て「開発止まっている!?」のかと思っていました。

開発リソースは潤沢ではなく、メイン開発者のJean-Philippe Langさんはフルタイムではなく、ほかのメンバーも5,6人程度のようでした。

開発自体は進んでいて次の4.0.0でRails5.1に移行予定だそうです。

Redmine Plugin開発者

勉強会の場にいただけで10人以上はいるようでした。 半分ぐらいの人は社内用の自作で公開していませんでした。 株式会社アジャイルウェアさんやAnkosoftさんのように、仕事でPlugin開発をしている人もいました。

その他の知見

大変面白かったです。運営と発表と参加者の方々には感謝です。

はてなブックマーカによる「アニメ史上に残るオリジナル展開」

集計対象

anond.hatelabo.jp

に対する

b.hatena.ne.jp

はてなブックマークコメントを集計しました。

コメント数

名前 票数
プラネテス 10
鋼の錬金術師 10
喰霊 7
ドラゴンボール 6
攻殻機動隊 5
蒼き鋼のアルペジオ 5
うる星やつら 4
こどものおもちゃ 4
みなみけ 4
アイドルマスター 4
セーラームーン 4
幽遊白書 4
くまみこ 3
ぼくらの 3
サザエさん 3
デビルマン 3
ミスター味っ子 3
月姫 3
聖闘士星矢 3
赤ずきんチャチャ 3
魔法先生ネギま! 3
ガングレイヴ 2
シャーマンキング 2
トライガン 2
ピンポン 2
モーレツ宇宙海賊 2
僕だけがいない街 2
名探偵コナン 2
四畳半神話大系 2
少女革命ウテナ 2
機動戦士ガンダム 2
無責任艦長タイラー 2
血界戦線 2
CLANNAD 1
GA 芸術科アートデザインクラス 1
HELLSING 1
UN-GO 1
W3 1
ef 1
true tears 1
けいおん 1
こちら葛飾区亀有公園前派出所 1
とある科学の超電磁砲 1
はれときどきぶた 1
らきすた 1
アークザラッド 1
カードキャプターさくら 1
ガンスリンガーガール 1
ガールズ&パンツァー 1
キカイダー 1
ギャラクシーエンジェル 1
クレヨンしんちゃん 1
サクラ大戦 1
ジョジョの奇妙な冒険 1
スクライド 1
ソウルイーター 1
ゾイド 1
デスノート 1
ハンターハンター 1
ハーメルンのバイオリン弾き 1
ビューティフルジョー 1
プリキュア 1
ポケモン 1
マイメロ 1
マジカルプリンセスホーリーアップ 1
マジンガーZ 1
ママレードボーイ 1
ムーミン 1
メイドインアビス 1
メダロット 1
リアル鬼ごっこ 1
ルパン三世 1
ローゼンメイデン 1
不思議の海のナディア 1
俺の妹 1
南国少年パプワくん 1
咲-saki- 1
坂道のアポロン 1
境界の彼方 1
天地無用! 1
奇面組 1
封神演義 1
新世紀エヴァンゲリオン 1
最強ロボ ダイオージャ 1
未来少年コナン 1
極黒のブリュンヒルデ 1
機動戦艦ナデシコ 1
海のトリトン 1
瀬戸の花嫁 1
灰羽連盟 1
琴浦さん 1
空鍋 1
精霊の守り人 1
西の善き魔女 1
貴族探偵 1
逮捕しちゃうぞ 1
遊戯王 1
鉄腕アトム 1
鉄腕バーディー 1
銀魂 1
響け! ユーフォニアム 1
風の谷のナウシカ 1
魔女の宅急便 1
魔法の妖精ペルシャ 1
魔法陣グルグル 1

全コメント

プラネテス

ID コメント
hiruneya プラネテスは忍者回だけ本当つまらなくて何これ状態だったんだが、原作読んでたのでこれってまさか…と思ったらやっぱりそのまさかで、おしっこチビりそうになった。忍者…
rozetta99 まとめ:最高→鋼錬一期、プラネテス、ことちゃ、喰霊零/アニメじゃないけどセーラームーン実写ドラマ。亜美ちゃん闇落ち展開に驚いたがキャラが深掘りされて面白かった。
nununi プレネテスの暴走も、ダークな無印ハガレンも、超絶百合な喰霊も全部好きなわたくし
voodoo5 プラネテスアニメはオーディオコメンタリーも良いので、ぜひ配信じゃなくてDVDかブルーレイで見てほしいな。田中さんのああいったラジオっぽいおしゃべりが聞けないなんて悲しい。
barbieri プラネテスアニメはテクノーラ社の面々が楽しくて良かった
ytn プラネテス」はアニメが原作を超えた数少ない好例だと思う\「精霊の守り人」は鍛冶屋とか村祭りとか短い原作を支えるためのディテールとしてオリジナル展開が上手く機能してた\アニメ版月姫、実は結構好き。
kotetsu306 酸素ボンベはハチのじゃなくてハチの元カノ(名前忘れた)のだぞ / ピンポンのアニメ版の、チャイナが高校の仲間と打ち解けてカラオケやってるシーンは良かった
tekitou-manga プラネテスアニメ版も決して悪いとは思わないけど、原作信者としてはゴテゴテしすぎ感が否めない。アルペジオに関してはイオナが没個性お人形ちゃん化してて・・・。映像的には派手で迫力あって好きだけど
ustam タナベは別人だったよなあ。ハチマキもアニメはキチガイすぎた。最悪のオリジナル展開は『僕だけがいない街』。原作の方も実写公開に合わせて無理やり終わらせた感あったけど。
a2de 田名部がハチの酸素ボンベ見てはぁはぁ/クレア「あなたの愛は薄っぺらいのよ」

鋼の錬金術師

ID コメント
GHBq96 原作に対してリスペクトはしつつ遠慮は一切せずアニオリ世界線を最後まで描ききったという意味でアルペジオは評価したい。ハガレンFAも結構好きよ。
agokirisamurai ハガレン1期→シャンバラ
rozetta99 まとめ:最高→鋼錬一期、プラネテス、ことちゃ、喰霊零/アニメじゃないけどセーラームーン実写ドラマ。亜美ちゃん闇落ち展開に驚いたがキャラが深掘りされて面白かった。
nununi プレネテスの暴走も、ダークな無印ハガレンも、超絶百合な喰霊も全部好きなわたくし
by-king ハガレン1期、企画立ち上がりが単行本2巻のときであるという事実からすると、よくあそこまで持っていったなというべきだと思う。/ 響けユーフォ1期12話、完全アニオリにも関わらずテーマの根幹を捉えていて衝撃的。
wacok ハガレン一期の映画かなり好き
topiyama 鋼錬1期の方が好きだったりする
marunabe いきなり歌と無関係のキャラが弾き語り始める封神演義…。ハガレンは原作ファンだけど、アニメ一期も嫌いじゃないよ。
babamin 古いけど、聖闘士星矢の『アスガルド編』は良作かと。海皇編への前哨戦にもなってるし。/ハガレン1期は、會川昇らしい少年期ジュブナイル物で良かった。ただシャンバラは、安い社会派ノリが鼻につきすぎてダメだ。
srgy ハガレンとか。賛否両論みたいだけど、個人的には原作未読だったし悪印象はないな

喰霊

ID コメント
rozetta99 まとめ:最高→鋼錬一期、プラネテス、ことちゃ、喰霊零/アニメじゃないけどセーラームーン実写ドラマ。亜美ちゃん闇落ち展開に驚いたがキャラが深掘りされて面白かった。
nununi プレネテスの暴走も、ダークな無印ハガレンも、超絶百合な喰霊も全部好きなわたくし
nbnr 喰霊零は2話以降がいいんじゃないか。原作の漫画家は感謝してるだろ。
bigburn アルペジオ喰霊零、あとは超電磁砲の一期かな
t-cyrill 喰霊 - 零 - 原作は見てない
tana_bata 喰霊零はすごかった。一話で公式サイトのブラフページで紹介してた嘘主人公陣全滅はホントすごかった。
kaionji 喰霊かな

ドラゴンボール

ID コメント
bzb05445 ドラゴンボール(Z含む)のアニオリ展開、作ってる人達を慮ってしまい楽しめなかったな。
vlxst1224 ストーリーの展開とはちょっとズレるがアニメ版ドラゴンボールについた「Z」の称号はとてもしっくり来たし、戦闘力も人種も異なる混沌とした自軍を「Z戦士」という分かりやすい概念でくくったのは上手だったと思う
dmekaricomposite ドラゴンボールZのガーリックJr.の逆襲とグレートサイヤマン編。前者は一種のゾンビものとしてハラハラドキドキできる。後者は正体を隠すヒーローもの+ラブコメ展開が楽しい。
Millishinku ドラゴンボールの漫画読み直したら記憶ほどトランクスと悟天が仲良くなくて違和感すらあった
c0ntinue こんな質問ノータイムでドラゴボでしょ。君たち大丈夫?
inferio 悟空とポポの修行

攻殻機動隊

ID コメント
tetsu23 鉄腕バーディー。アニメ版のオリキャラが後に漫画に逆輸入された。あと攻殻機動隊
wow64 攻殻機動隊とか灰羽連盟とかかね。原作短い方がアニメで創造する余地があって良さそうに思える。原作を丁寧になぞるだけのアニメは飽きてきたかも。
lliilliilliill 攻殻はアニメの方が好き
TakamoriTarou …?みなみけにアニメオリジナル話なんてなかったような? みなみけ1期、おかえり、ただいまと3期やってるけど、そんなにないよね。  ないよね(目をそらす  攻殻機動隊だと思います
AQM トグサ

蒼き鋼のアルペジオ

ID コメント
GHBq96 原作に対してリスペクトはしつつ遠慮は一切せずアニオリ世界線を最後まで描ききったという意味でアルペジオは評価したい。ハガレンFAも結構好きよ。
sirobu 劇場版アルペジオは原作のイオナの良さをスポイルしてる気がして俺はダメだった。メディアミックスだとナデシコとかスクライド辺りはメディアによって話が全然違ったなぁ
momonga_dash 劇場版 蒼き鋼のアルペジオ -アルス・ノヴァ- Cadenzaのこと?!
tekitou-manga プラネテスアニメ版も決して悪いとは思わないけど、原作信者としてはゴテゴテしすぎ感が否めない。アルペジオに関してはイオナが没個性お人形ちゃん化してて・・・。映像的には派手で迫力あって好きだけど
bigburn アルペジオ喰霊零、あとは超電磁砲の一期かな

うる星やつら

ID コメント
miruna 最高も最悪もビューティフルドリーマー一択では?私は最高の方で。
Cujo うるせいやつらにたいりょうに。。。ちばしげるのめがねとか。。。(れいがふるすぎ/おわるまでかんとくがげんさくをしらなかったぜのぐらしあをあげるべきかまよったけどひかえる(してない
fusionstar よかったのはミスター味っ子かなー。 うる星やつらのメガネ関連は賛否両論あるよね。 デビルマンはオリジナル展開とかいう問題じゃない?
dydr おっさんとしては、「うる星やつら」かな。特にメガネ。

こどものおもちゃ

ID コメント
rozetta99 まとめ:最高→鋼錬一期、プラネテス、ことちゃ、喰霊零/アニメじゃないけどセーラームーン実写ドラマ。亜美ちゃん闇落ち展開に驚いたがキャラが深掘りされて面白かった。
Hanatoyume こどちゃとチャチャは、子供ながらに「????????」と困惑してしまうくらいには謎展開だったな。ばびっとのハイテンションには毎回ひいていたし、真面目に戦うチャチャもコレジャナイ感がやばかった
moons ブクマにもある「こどものおもちゃ」のアメリカ編とか好きだったなあ。「天地無用!」のミホキヨとかはオリジナル展開、なんだろうか
Ri-fie こどものおもちゃ』は、オリジナルストーリーをはじめ、原作からはみ出たところが恐ろしく面白かった。オリジナルキャラのばびっとが、紗南とともに一番輝いているって、どういうことだ、と。

みなみけ

ID コメント
allezvous ガンダム(富野の小説に比して)極黒のブリュンヒルデは今一歩か/みなみけのフユキはヤシガニ・キャベツ並みのレジェンドになっててすごいな
narukami みなみけ観てない(原作は読んでたが)ので最悪は「ぼくらの」だと思っている
mouseion かつてみなみけおかわり肯定派だった自分はその後おかえりとかを切った(理由は否定意見が集中して嫌になったから)。でも先日一挙放送を見た時明らかにおかわりだけ別のアニメだったので見直した。悪い意味で。
TakamoriTarou …?みなみけにアニメオリジナル話なんてなかったような? みなみけ1期、おかえり、ただいまと3期やってるけど、そんなにないよね。  ないよね(目をそらす  攻殻機動隊だと思います

アイドルマスター

ID コメント
uunfo アイドルマスターじゃないの?
nisshin-k ゼノグラ....
Cujo うるせいやつらにたいりょうに。。。ちばしげるのめがねとか。。。(れいがふるすぎ/おわるまでかんとくがげんさくをしらなかったぜのぐらしあをあげるべきかまよったけどひかえる(してない
inazakira 赤ずきんチャチャとか。月姫のスパゲッティとか。アイドルマスターのロボットのやつとか。

セーラームーン

ID コメント
sbedit1234 安パイと思って見てた全国の幼女が号泣、そのまま引き付けを起こしたり過呼吸起こしたり夜泣きを始めたりでママ大激怒のセラムン無印終盤じゃね?プリキュアとは格の違う荒々しさ。
rozetta99 まとめ:最高→鋼錬一期、プラネテス、ことちゃ、喰霊零/アニメじゃないけどセーラームーン実写ドラマ。亜美ちゃん闇落ち展開に驚いたがキャラが深掘りされて面白かった。
tabidachi_nam セーラームーンはシリーズ通して、それこそキャラとある程度の設定だけ使って話は原作通りにはやらなくて、あれだけウケてたんだからスタッフ陣はかなりの有能だったと思うのよね。旦那の幽白のオリ展開も好きよ。
sigrain 話のメインじゃないけどセーラームーンのなるちゃんとネフライトセーラームーンアニメの中でも特に印象に残る展開

幽遊白書

ID コメント
tabidachi_nam セーラームーンはシリーズ通して、それこそキャラとある程度の設定だけ使って話は原作通りにはやらなくて、あれだけウケてたんだからスタッフ陣はかなりの有能だったと思うのよね。旦那の幽白のオリ展開も好きよ。
hilda_i 最高→『魔女の宅急便』って原形とどめてなくてすごいと思うわ。/微妙→幽遊白書の蔵馬VS時雨回。冷静に観ると雰囲気だけで突き進んでてストーリーが意味不明な上に魔界整体師時雨が訳の分からない投身自殺してる。
sekisetsu_ibuki 幽☆遊☆白書の100話好きだ。
YU_Trash こち亀の婦警二人組と、幽白のコエンマの横に居る青鬼は良いオリキャラだったと思う

くまみこ

ID コメント
hetyo525 ボクのいちばんは「くまみこ」。BD版だと大幅に修正されていて別物なのでかなしい…。
possesioncdp くまみこの話はやめろ
box88 最近ならくまみこのセリフとか?

ぼくらの

ID コメント
narukami みなみけ観てない(原作は読んでたが)ので最悪は「ぼくらの」だと思っている
syrup350g ぼくらののアニメ自体は賛否両論くらいの評価で良いと思うけど、設定だけ聞かされてたのか原作の重要な点をネタバレかましたのがな…
papasss 「ぼくらの」はアニオリ展開もすごかったしアニメスタッフの炎上もすごかったしすごかった

サザエさん

ID コメント
dzod アニメ史上というなら花沢さんと李苺鈴かね
reijikan アニメ史上に残るといえば、サザエさんのお隣さんの引越し(違)
fncl 長編ストーリー物の前提なんだろうけど、サザエさんルパン三世クレヨンしんちゃん辺りも相当オリジナル展開してるのでは。

デビルマン

ID コメント
RM233 デビルマン。アニメが良くないという意味じゃなくて、原作の神懸かり方がヤバイ。
nomitori 逆にマンガ側の最高なオリジナル展開はデビルマンやろな
fusionstar よかったのはミスター味っ子かなー。 うる星やつらのメガネ関連は賛否両論あるよね。 デビルマンはオリジナル展開とかいう問題じゃない?

ミスター味っ子

ID コメント
hobbling ミスター味っ子のラスト展開。作者が悔しがって、ミスター味っ子2のラストを同じ状況(味皇の廃人化)にしてさらに上回る展開をやろうとしてた。/
fusionstar よかったのはミスター味っ子かなー。 うる星やつらのメガネ関連は賛否両論あるよね。 デビルマンはオリジナル展開とかいう問題じゃない?
nost0nost ミスター味っ子だろ 余りにも偉大すぎて原作がアニメに寄った稀有な作品

月姫

ID コメント
shiori_lov カレーじゃなくてパスタ食べてる
ytn プラネテス」はアニメが原作を超えた数少ない好例だと思う\「精霊の守り人」は鍛冶屋とか村祭りとか短い原作を支えるためのディテールとしてオリジナル展開が上手く機能してた\アニメ版月姫、実は結構好き。
inazakira 赤ずきんチャチャとか。月姫のスパゲッティとか。アイドルマスターのロボットのやつとか。

聖闘士星矢

ID コメント
maxk1 聖闘士星矢で思いだしたけど作者はオリジナル展開にちょっとイラっとしてたように思える
ykhmfst2012 聖闘士星矢アスガルド編。最高。スチール聖闘士とドクラテスはなかった方向で...。/ 既出だった。
babamin 古いけど、聖闘士星矢の『アスガルド編』は良作かと。海皇編への前哨戦にもなってるし。/ハガレン1期は、會川昇らしい少年期ジュブナイル物で良かった。ただシャンバラは、安い社会派ノリが鼻につきすぎてダメだ。

赤ずきんチャチャ

ID コメント
shun_libra 最高だったのはOVAの逮捕とサクラ大戦、最低だったのはTV版の逮捕とサクラ大戦。異論は認める。/ チャチャは原作未読なので、単純に毎回爆笑しながら見てた。なんであんなに笑えたのかは今以て謎。
Hanatoyume こどちゃとチャチャは、子供ながらに「????????」と困惑してしまうくらいには謎展開だったな。ばびっとのハイテンションには毎回ひいていたし、真面目に戦うチャチャもコレジャナイ感がやばかった
inazakira 赤ずきんチャチャとか。月姫のスパゲッティとか。アイドルマスターのロボットのやつとか。

魔法先生ネギま!

ID コメント
arisane ネギま! 放送当時、原作ヒロインはまだ生きてたのに、アニメオリジナル展開で死んで火葬されて葬式までやられた
Fushihara 火葬
inoken0315 脊髄反射的に「火葬」の2文字を挙げる人が一定数居そう。

ガングレイヴ

ID コメント
tomokixxx オリジナル部分の出来がよすぎて原作に沿った部分が「浮いてる」「微妙」「なんでこんなトンデモ展開入れたの?」と評されたガングレイヴ(原作単品で見ると良きB級作品ではあるんだが)
megomego ここには入らないかもしれないけど、あえてガングレイヴ

シャーマンキング

ID コメント
pachikorz アニメ版シャーマンキングの最終回があまりにもあんまりだったので視聴後悔しさで号泣してたら母に「そんなに好きになれるものが見つかってよかったじゃない……」慰められた中坊時代のアイタタ歴史。
hinail シャーマンキングの最終回は子どもながらに怒った。そののち原作の終盤にはもうついていけなくなってた。

トライガン

ID コメント
homarara トライガンは原作が雷泥と戦ってた時アニメ化したから、後半は仕方ないと思う・・・
uturogi_soy トライガン一択。

ピンポン

ID コメント
kotetsu306 酸素ボンベはハチのじゃなくてハチの元カノ(名前忘れた)のだぞ / ピンポンのアニメ版の、チャイナが高校の仲間と打ち解けてカラオケやってるシーンは良かった
mokuyuu テレビアニメのピンポンだとキャラの成人後が見れるよ、本当に秀逸なアニメオリジナルエンド。誰かが死んだり、ひどい目にあうアニメではないのにエンドロールでも余韻で涙が止まらなかった。

モーレツ宇宙海賊

ID コメント
Librakun 劇場版モーレツ宇宙海賊すき
kori3110 モーパイ(サトタツ原理主義者)

僕だけがいない街

ID コメント
sharia 僕だけがいない街」は原作読まないと犯人の思考回路が理解できないけど、そこを一切カットしてしまったアニメ版は、気持ち悪さが残らず、逆の意味でいい原作破壊だった気がする。知りたきゃ原作読め(キモいけど)
ustam タナベは別人だったよなあ。ハチマキもアニメはキチガイすぎた。最悪のオリジナル展開は『僕だけがいない街』。原作の方も実写公開に合わせて無理やり終わらせた感あったけど。

名探偵コナン

ID コメント
tatuyan そういやコナンの高木警部もアニメオリジナルだったな、あとから逆輸入されたけど。/ 個人的にガッカリしたのは「西の善き魔女」のアニオリ展開。
OTAKUPAPA 未来少年コナン」や「不思議の海のナディア」は原作破壊しまくって好き放題やっているが、アニメのほうが断然面白い。「ガンスリンガーガール」二期は原作に忠実だが、一期のほうがはるかに傑作

四畳半神話大系

ID コメント
kamayan1980 「なぜ繰り返すのか」という箇所をあえてぶん投げた原作と、熱くてどうしようもない理由をつけたアニメの四畳半神話大系
axkotomum 四畳半神話大系

少女革命ウテナ

ID コメント
versatile ウテナだろう
haburashi13 ウテナ

機動戦士ガンダム

ID コメント
allezvous ガンダム(富野の小説に比して)極黒のブリュンヒルデは今一歩か/みなみけのフユキはヤシガニ・キャベツ並みのレジェンドになっててすごいな
perl-o-pal 正史以外のガンダム

無責任艦長タイラー

ID コメント
usomegane 無責任艦長タイラーは90年代ベストアニメに入れていいレベル。原作小説も面白いが主人公のタイラーをおっさんから若者に変更したのはどう考えてもアニメ的には正解。
kohgethu アニメ版「無責任艦長タイラー」なんてほぼオリジナル展開だよ。挙げ句にアニメ版のが人気になっちゃって原作者が未だに拗れているレベルだよ。/奇面組のアニメ版の最終回。原作とは正反対で面白かったな。

血界戦線

ID コメント
kuro_pp 血界戦線はストック不足のためにオリジナルやったと思うし悪くなかったが、なんだかんだで2期やれてるし足りたんじゃないかと思っている
dalk 血界戦線1期(主に5話と最終話)

CLANNAD

ID コメント
mw-matrixa CLANNADテニス回は当時ひとりで喝采をあげた。ハーレムに走らず双子のドラマに昇華されててほんとよかった。「オーバー」もあいまって、もう

GA 芸術科アートデザインクラス

ID コメント
wasarasan なるほど、GA

HELLSING

ID コメント
sunayuki HELLSINGのTV版はまだ許してないよ?

UN-GO

ID コメント
CDG UN-GO is 最高 (坂口安吾を原作と言い張る

W3

ID コメント
weep いつだったか、WOWOW手塚治虫の「W3 (ワンダースリー)」のアニメ最終回を観たけど、漫画版よりひどくて訳がわからんかった。 なんとか放送に間に合うよう急いで頑張って作った感だけは伝わった。

ef

ID コメント
ysksy efの1期は原作と過程が違っててハラハラしたな。

true tears

ID コメント
nekoluna true tearsはタイトル以外全部オリジナル展開

けいおん

ID コメント
karikari1255 らきすたとかけいおんとか、元ネタが4コマのもののアニメ化はほぼ前編オリジナルみたいなもんなので対象外なのかな

こちら葛飾区亀有公園前派出所

ID コメント
YU_Trash こち亀の婦警二人組と、幽白のコエンマの横に居る青鬼は良いオリキャラだったと思う

とある科学の超電磁砲

ID コメント
bigburn アルペジオ喰霊零、あとは超電磁砲の一期かな

はれときどきぶた

ID コメント
sjn はれぶた。史上に残るかは分からぬが。マイメロも上げたいが何を以って原作として良いか未だ知らず。

らきすた

ID コメント
karikari1255 らきすたとかけいおんとか、元ネタが4コマのもののアニメ化はほぼ前編オリジナルみたいなもんなので対象外なのかな

アークザラッド

ID コメント
eringix アークザラッドのアニメは色々どうかと思う部分もあるものの、1の主人公とヒロインを生存させてくれたのは本当にありがとうございました

カードキャプターさくら

ID コメント
dzod アニメ史上というなら花沢さんと李苺鈴かね

ガンスリンガーガール

ID コメント
OTAKUPAPA 未来少年コナン」や「不思議の海のナディア」は原作破壊しまくって好き放題やっているが、アニメのほうが断然面白い。「ガンスリンガーガール」二期は原作に忠実だが、一期のほうがはるかに傑作

ガールズ&パンツァー

ID コメント
sdtrd 逆にアニメのコミカライズでのオリジナル要素が素晴らしいガルパンvarianteを挙げときたい。

キカイダー

ID コメント
nejipico 石森(石ノ森)原作(キカイダー除く)。漫画原作は放映と同時に連載を始め放映終了と共に投げっぱなしで終了する。(主人公がウォーとかマザーとか叫んで終わり)

ギャラクシーエンジェル

ID コメント
motoP ギャラクシーエンジェル

クレヨンしんちゃん

ID コメント
fncl 長編ストーリー物の前提なんだろうけど、サザエさんルパン三世クレヨンしんちゃん辺りも相当オリジナル展開してるのでは。

サクラ大戦

ID コメント
shun_libra 最高だったのはOVAの逮捕とサクラ大戦、最低だったのはTV版の逮捕とサクラ大戦。異論は認める。/ チャチャは原作未読なので、単純に毎回爆笑しながら見てた。なんであんなに笑えたのかは今以て謎。

ジョジョの奇妙な冒険

ID コメント
backstar88 ジョジョの第3部のアニメで家出少女との別れのシーンを入れたのは良かった

スクライド

ID コメント
sirobu 劇場版アルペジオは原作のイオナの良さをスポイルしてる気がして俺はダメだった。メディアミックスだとナデシコとかスクライド辺りはメディアによって話が全然違ったなぁ

ソウルイーター

ID コメント
perfectspell ソウルイーターのラストかな。良かった。

ゾイド

ID コメント
FutureIsWhatWeAre メダロットゾイドがまだ出てないとは

デスノート

ID コメント
umai_bow ドラマだけど劇場版デスノートの決着は原作より好き

ハンターハンター

ID コメント
zashikin ハンターハンター軍艦島は良かった。

ハーメルンのバイオリン弾き

ID コメント
ss-vt ハーメルンのバイオリン弾き(全編)

ビューティフルジョー

ID コメント
jou2 ビューティフルジョーというカプコン原作のタツノコプロのヒーローアニメを挙げたい。傑作

プリキュア

ID コメント
sbedit1234 安パイと思って見てた全国の幼女が号泣、そのまま引き付けを起こしたり過呼吸起こしたり夜泣きを始めたりでママ大激怒のセラムン無印終盤じゃね?プリキュアとは格の違う荒々しさ。

ポケモン

ID コメント
galboss ポケモンスクール、サトシゲッコウガ、そもそも最初のポケモンピカチュウ

マイメロ

ID コメント
sjn はれぶた。史上に残るかは分からぬが。マイメロも上げたいが何を以って原作として良いか未だ知らず。

マジカルプリンセスホーリーアップ

ID コメント
sds-page マジカルプリンセスホーリーアップ

マジンガーZ

ID コメント
privates マジンガーZがボロボロになってる遠くで、グレートマジンガーが飛んでる。子供心にパニクった思い出。

ママレードボーイ

ID コメント
warulaw ママレードボーイの六反田に彼女ができる展開は熱くなった。

ムーミン

ID コメント
mohno 子供はみんな喜んで見てたのに原作者からダメ出し食らって二度とみられなくなってる初期「ムーミン」とか?:-p

メイドインアビス

ID コメント
gohankun 最近だとメイドインアビスの最終回、電報船飛ばすシーンは良かったなあ。展開というより演出の範囲だろうけど。

メダロット

ID コメント
FutureIsWhatWeAre メダロットゾイドがまだ出てないとは

リアル鬼ごっこ

ID コメント
discordance アニメじゃないんだけど、園子温監督「リアル鬼ごっこ」は、監督が原作未読で作っていてオリジナル展開しかない。個人的には結構面白かったです。

ルパン三世

ID コメント
fncl 長編ストーリー物の前提なんだろうけど、サザエさんルパン三世クレヨンしんちゃん辺りも相当オリジナル展開してるのでは。

ローゼンメイデン

ID コメント
ariyake ローゼンメイデン一期では。蒼星石のくだりとか

不思議の海のナディア

ID コメント
OTAKUPAPA 未来少年コナン」や「不思議の海のナディア」は原作破壊しまくって好き放題やっているが、アニメのほうが断然面白い。「ガンスリンガーガール」二期は原作に忠実だが、一期のほうがはるかに傑作

俺の妹

ID コメント
sakamata 『俺の妹がこんなにかわいい訳がない』で、妹がラノベ書く話があったけど、原作者自身を馬鹿にしたようなエピソードでなかなか酷かった。あれオリジナルなのか、原作者の自虐なのかわからなかった。

南国少年パプワくん

ID コメント
pianopop_on 南国少年パプワ君でシンタローがサービスに諭され日本へ帰ったところまではいいが、その後事件が起きずそのまま終わった事に驚愕した。

咲-saki-

ID コメント
dubmi 展開と言うより演出の部類かなー。咲-saki-で咲が池田にわざと振り込む前に点棒入れを開くシーン

坂道のアポロン

ID コメント
genbara-k 坂道のアポロンの最終回は、カットする場面の選択によって原作とは異なる結末(渡辺信一郎的美学)になってると解釈してるんだが、そういう意見全然見ないんだよな。

境界の彼方

ID コメント
shiju_kago 当時原作が1巻しか出ていないので原作準拠なのは1話Aパートまでだった境界の彼方という実質オリジナルアニメ。

天地無用!

ID コメント
moons ブクマにもある「こどものおもちゃ」のアメリカ編とか好きだったなあ。「天地無用!」のミホキヨとかはオリジナル展開、なんだろうか

奇面組

ID コメント
kohgethu アニメ版「無責任艦長タイラー」なんてほぼオリジナル展開だよ。挙げ句にアニメ版のが人気になっちゃって原作者が未だに拗れているレベルだよ。/奇面組のアニメ版の最終回。原作とは正反対で面白かったな。

封神演義

ID コメント
marunabe いきなり歌と無関係のキャラが弾き語り始める封神演義…。ハガレンは原作ファンだけど、アニメ一期も嫌いじゃないよ。

新世紀エヴァンゲリオン

ID コメント
minetty99 瞬間風速で言うならエヴァ

最強ロボ ダイオージャ

ID コメント
ssids 最強ロボ ダイオージャ(そういうことじゃない)

未来少年コナン

ID コメント
OTAKUPAPA 未来少年コナン」や「不思議の海のナディア」は原作破壊しまくって好き放題やっているが、アニメのほうが断然面白い。「ガンスリンガーガール」二期は原作に忠実だが、一期のほうがはるかに傑作

極黒のブリュンヒルデ

ID コメント
allezvous ガンダム(富野の小説に比して)極黒のブリュンヒルデは今一歩か/みなみけのフユキはヤシガニ・キャベツ並みのレジェンドになっててすごいな

機動戦艦ナデシコ

ID コメント
sirobu 劇場版アルペジオは原作のイオナの良さをスポイルしてる気がして俺はダメだった。メディアミックスだとナデシコとかスクライド辺りはメディアによって話が全然違ったなぁ

海のトリトン

ID コメント
mugi-yama トリトンはマンガとアニメそもそも別物だからダメ?

瀬戸の花嫁

ID コメント
shikiarai 歴史には残らないけど瀬戸の花嫁とか

灰羽連盟

ID コメント
wow64 攻殻機動隊とか灰羽連盟とかかね。原作短い方がアニメで創造する余地があって良さそうに思える。原作を丁寧になぞるだけのアニメは飽きてきたかも。

琴浦さん

ID コメント
shijuushi 史上に残るかどうかは別として、アニメの改変版の方が良かったのは「琴浦さん」。さすがに、マンガ版の連続殺人犯は別の人だったというのはちょっと……

空鍋

ID コメント
sangping 空鍋

精霊の守り人

ID コメント
ytn プラネテス」はアニメが原作を超えた数少ない好例だと思う\「精霊の守り人」は鍛冶屋とか村祭りとか短い原作を支えるためのディテールとしてオリジナル展開が上手く機能してた\アニメ版月姫、実は結構好き。

西の善き魔女

ID コメント
tatuyan そういやコナンの高木警部もアニメオリジナルだったな、あとから逆輸入されたけど。/ 個人的にガッカリしたのは「西の善き魔女」のアニオリ展開。

貴族探偵

ID コメント
msdbkm アニメは思いつきませんでしたけど、ドラマなら貴族探偵

逮捕しちゃうぞ

ID コメント
haibane 逮捕しちゃうぞとか、あの漫画が原作と言われても意味不明だった

遊戯王

ID コメント
tanukichi087 アニメ版遊戯王のオリジナルはどれも本当によくできてたよ。今では懐かしいバーサーカーソウルのくだりも、本編だと涙なしに見れない。

鉄腕アトム

ID コメント
atuyesaman 白黒版鉄腕アトムの最終回は伝説だと思う。 まあ、原作も泣けるけど。

鉄腕バーディー

ID コメント
tetsu23 鉄腕バーディー。アニメ版のオリキャラが後に漫画に逆輸入された。あと攻殻機動隊

銀魂

ID コメント
techonair なぜ銀魂が出てない(ざっと見)…と思ったけど、銀魂は展開がオリジナルなんじゃなくてアニメならではの演出がすごかったんだよなァ、と。

響け! ユーフォニアム

ID コメント
by-king ハガレン1期、企画立ち上がりが単行本2巻のときであるという事実からすると、よくあそこまで持っていったなというべきだと思う。/ 響けユーフォ1期12話、完全アニオリにも関わらずテーマの根幹を捉えていて衝撃的。

風の谷のナウシカ

ID コメント
Fuetaro 最悪のアニメオリジナル展開は風の谷のナウシカ。あんな素晴らしい漫画原作なのに駄作に貶める投げやりなエンディングを作者本人が苦し紛れにやってしまうとかマジありえんわ。

魔女の宅急便

ID コメント
hilda_i 最高→『魔女の宅急便』って原形とどめてなくてすごいと思うわ。/微妙→幽遊白書の蔵馬VS時雨回。冷静に観ると雰囲気だけで突き進んでてストーリーが意味不明な上に魔界整体師時雨が訳の分からない投身自殺してる。

魔法の妖精ペルシャ

ID コメント
b-zou3 魔法の妖精ペルシャでしょう。原作では魔法のまの字も出てこない。

魔法陣グルグル

ID コメント
hiruhikoando グルグルファーストの最終回は呆れたけどニヤッとしちゃった。

集計方法

元データはAPIから

curl 'http://b.hatena.ne.jp/entry/json/https://anond.hatelabo.jp/20171113140500' > bookmarks1.json

辞書作り

やはり苦戦するのが辞書作りです。 特にアニメ作品のタイトルは通称で書かれることが多いのが難点です。

今回は既存の辞書を流用してみました。

ニコニコデータセット

ニコニコデータセットは、アニメのタイトルは取れるのですが、キャラ名とドラマのタイトルが取れなかったのでやめました。

はてなキーワード

はてなキーワードは、キャラ名や通称まで入っているので便利そう、と思い使ってみました。 487387単語と、単語によってはその読みが含まれます。

コメントに含まれるキーワードで辞書を作ると、約509単語の辞書が作れます。 結果的には、これは多すぎました。

実際の作品数は105件です。 内容も作品名とは関係のない一般的な単語が多く含まれます。

かえって作品名の名寄せ作業が大変になります。 ブックマーク数は259件を全部見た方がましです。 (コメントあり件数に直したい)

mecab-ipadic-neologd

mecab-ipadic-neologdも作品名もキャラ名を含みます。 またドラマのタイトルも含みます。

大きいのは、単語の分類が取得できるところでした。 固有名詞に絞って、コメントに含まれる単語で辞書を作ると、269語の辞書が作れます。

あとはいつも通り地道な名寄せ作業をしていきます。 コメントに正式名称が入っていない場合は、検索して埋める必要があります。 それ以外の作品名のブレや、キャラ名で作品を指している場合は手作業で名寄せしていきます。

最終的には165語まで減りました。 mecab-ipadic-neologdを使っても、100語ぐらいは、無効な単語が入ってきます。 そこをどうやって防ぐかは今後の課題です。

github.com

のようなアニメ作品専用の辞書を使う方が良いのかもしれません。

ソースコード

集計に使ったスクリプト

github.com

に置いてあります。

不明なコメント

アニメ史上に残るオリジナル展開

空飛ぶ北海道

2017/11/13 23:35
b.hatena.ne.jp

「空飛ぶ北海道」がどの作品を指しているかはわかりませんでした。