@ledsun blog

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

日本でアジャイルが流行らない理由

ポジション的なもの

個人的に、アジャイルは「(あんまり未来や遠くのことを考えるのをやめて)目の前にある問題を解決しよう」という思想と認識しています。

現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは? と、思います。

キーワード「エンタープライズ」が出てきているので、業務システムの話をします。

情けないぞアジャイルコーチ

私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。

サム・グッケンハイマーの一言

サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー

の方が

「ウォータフォールは一切メリットがないので止めておきなさい」

といったそうです。まあ、ポジショントークマイクロソフトは、これから日本で、Azureを使ったDevOpsを売りたいですよね?

自分の本当の心の中

統計を見ても、2015年のVersion One のサーベイを見るとワールドワイドで95%の企業がアジャイルを導入しているが、日本だと、同年のPMIの統計によると 31%が導入済みに過ぎず、明らかに遅れをとっている

うしおさんがMicrosoftの中の人である以上、ポジショントークとして扱うのが良いと思います。特に、この画像にde:codeのロゴ入っているのが、ひっかかります。

マイクロソフトの面接での出来事

彼は面接の最初にちょっとびっくりした声で私に聞いた Tsuyoshi、日本でアジャイル導入があまり進んでないって本当か?

DevOpsを売るに当たって、前提として「アジャイルが流行っていない」のどうしようか?みたいな、状況でしょうか? エンタープライズ向けに売ろうと思うと、由々しき事態だと思います。 上司の方の危機感の認識は日本市場に合っているのではないでしょうか?

最近ソフトウェアに詳しいアメリカの女性と話した時にウォータフォールの話をしたら「まだ日本ではウォータフォールなんてやってるの!そんなの誰もやってないよ!」と本当に驚いていた

なるほどー、そうなのかもしれません。 人類に達成可能である証拠なので、アジャイルを導入したい、自分にとっては朗報です。

ウォータフォールは起源から異なっていた

ウォータフォールの起源はどのようなものか?というと、Winston.W.Royceが書いた MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS という論文が起源になっている

私も、そうだと思っていました。久しぶりに見直した日本語のWikipediaに・・・

初めて「ウォーターフォール」という用語を用いたのはT.E.BellとT.A.Thayerによる1976年に発表された論文「Software Requirement」であり、B.W.Boehamが1981年に出版した本「Software Engineering Economics」においてウォーターフォールモデルのオリジナルはRoyceだと述べ、ウォーターフォール・モデルの起源がRoyceであるという誤解を広めた。

まじかよ!本日、最大の驚き!!

ウォータフォールを前提とするのが本当に日本のためだろうか?

1日に10回も100回も本番にデプロイできるようなオートメーションがなされたり、データセンターレベルで抽象化が進んで自動回復を行えるまでの環境が出来てる。Infrastrucute as Codeの対応をしている2200台のサーバーのセキュリティパッチをたった一人が15分で当て終わるような時代だ

1日に10回、本番デプロイする必要がある、業務には、どういう業務を想定されているのでしょうか? 個人的には思いつきません。

個人的な経験では 「1日待ってもいいから、ちゃんとテストして、バグで毎日の業務が止まらないことを保証してから、リリースしてください。」 と要望されることが多いです。

1日に10回、本番デプロイできる環境では、業務システムを使って業務を行う方たちも

  1. バグったらシステム管理者に連絡
  2. 再リリースまで休憩

な、やり方に慣れるのでしょうか? 米国に、そういう事例があるのであれば、是非知りたいです。

開発する立場としては、「とりあえず勘で直してリリースした。直ったかどうか、確認して」と言えたら、とても気楽だなと、思います。 正しいやり方かはわかりませんが、緊急回避手段が増えるのはありがたいことです。

自分の恥ずかしい体験談 私はインターナショナルでは無価値である

彼らは日本では体験できないほどアジャイルについて深く理解しており、私があげたどの想定課題も既に体験・解決済みだった。例えば、受け入れテスト駆動開発の話題を振っても彼らはそれを導入した時の事、発生した課題、どう解決したか?みたいな話をしてくれた

これは、うしおさん個人が、アジャイルな現場での開発技術についていけていない話な気がします。 現場で手を動かすのをやめるのが早すぎたのではないでしょうか?

アジャイルコーチのジョークに「もう何年もプログラムを書いていない」みたいな話があった記憶があります。 そのイメージです。元ネタを失念しました。

最も深刻なことは、「経験」を積めないこと

2003年の時点の私の経験は、米国でも価値のあるものだったと思う。では日本で経験を積んだ私が無価値になってしまった

私は外資系、できれば海外に住むことをターゲットに仕事を探していた

という目的に対しては、残念とは思います。

だけど、あなたの積んだ「経験」は、絶対に他人が詰んだ経験とは異なります。 異なる経験は異なる状況では価値があります。普遍的に無価値ではありえません。

「自分の経験は無駄だった」はただの思い込みです。無駄なのでやめましょう。

日本はソフトウェア開発の後進国

ChefのAlexが日本のソフトウェア業界が8年遅れだと言っていた。Samは5年遅れだと言っていた

これは間違いないです。日本人のGithubリポジトリをWatchしたことがありません。 本場で自分の力を試してみたい人は行けばいいと思います。 個人的には食の面で、移住には魅力を感じません。

海の近くで魚介が美味しくて、山の近くで水が美味しいと、食べ物は美味しいです。 シリコンバレーは割と食べ物がおいしいかもしれません。

自分が目指すビジョン

私のここ数年のビジョンは、日本と米国の技術やプロセスの導入スピードを同じにすることだ

なぜでしょう?

Samの野郎に、「日本は今や米国と同じスピードで遷移している」と言わしめたい

遅れていると言われるのが嫌だからでしょうか?

うーんと・・・「ファッションアジャイル野郎が!」と言ってみたいですね(汗

エバンジェリストに期待すること

「遅れている」や「遅れがもっと広がる」という、脅しは必要はありません。 FUDは嫌いです。

  • アジャイルやDevOpsを取り入れた米国や英国の業務システムが、どうすばらしいのか
  • アジャイルやDevOpsが、日本の業務システムが抱えている問題を解決し得るのか

を伝えて欲しいです。

事例さえあげてもらえれば、あとは我々SIerが発注者に売りこみます。

日本でアジャイルが流行らない理由

個人の考えです。

  1. 予算確保にシステムの仕様が必要
  2. システムの発注が請負契約
  3. 発注企業のシステム担当者が、一つのシステムに専任していない
  4. 発注企業のシステム担当者が、コンピューターサイエンスの知識を持っていない
  5. 発注企業の業務担当者が、システム開発に専任していない

予算確保にシステムの仕様が必要

95%の会社がアジャイル開発やっているなら、これ教えて下さい。本当に。 システム開発を始める際に、会社内でプロジェクトの期間と目的と予算は決めているはずです。

どういう風にプロジェクトを初めて、どういうときに中止するのか。 リスク管理のやり方が真似できれは、日本の企業もアジャイルな発注ができるはずです。

公共案件の予算管理にも適用できると、大手SIerアジャイルに移行できるのではないでしょうか?

システムの発注が請負契約

よく言われます。これは分割納品にすれば割と回避できます。

ただし、最終納品では揉めることがあります。 発注時の仕様と違うものを納品するには、発注会社のシステム担当者が社内を説得する必要があります。 できなかった場合に、納品のためのごちゃごちゃした作業が必要になります。 プロジェクトは炎上します。

社内を説得できる人は、とっくに「アジャイルのようなこと」をやっています。

「予算確保にシステムの仕様が必要」と同根です。 発注会社(のシステム担当者の上司)はアジャイルなプロジェクト管理をする方法がわからないのです。 開発側の技術や環境の問題ではありません。

発注企業のシステム担当者が、一つのシステムに専任していない

  アジャイルなプロジェクトで1週間に1回リリースすると、発注企業のシステム担当者の時間が足りなくなります。 毎周、検収して次の週のストーリーを考えるのは無理です。

これは、発注企業のシステム担当者が、一つのシステムに専任していないからです。 他の業務に追われています。

この状況では「1日に10回本番デプロイ」魅力にはなりません。 DevOpsを使いこなすためには、発注企業は、システム開発の費用にシステム担当者の人件費をもっと増やす必要があります。

検証環境に「1日に10回本番デプロイ」できると、ソフトウェア開発者にとっては便利です。 手で受け入れ試験を回せるので、システムの理解が捗ります。

発注企業のシステム担当者が、コンピューターサイエンスの知識を持っていない

  • ディスクは遅くて、ネットワークはもっと遅くて、メモリはちょっぱや
  • 1万レコードは問題ない。10万レコードはちょっとおもい。100万レコードは重い。1億レコードは色々頑張らないと無理

みたいな感覚を持っていてもらえると、コスト感が通じやすくて嬉しいです。愚痴です。

端から見ていると、業務システムのプロダクトマネージャーは、とても難しい仕事に思えます。

  • 商売の理解。システムをどう活用すればもっと儲かるのか
  • 業務の理解。どういうシステムなら業務がまわるのか
  • コンピュータサイエンスの理解。どういうシステムなら低いコストで作れるのか

すべての知識を持ったプロダクトマネージャーは、非常に稀有に思えます。 数千万円程度の投資をして、外部から登用するか、社内で育てる必要があるように思えます。

それで商売上の価値があるのかは、私にはわかりません。

発注企業の業務担当者が、システム開発に専任していない

日本では当たり前です。業務担当者は、

  • 開発初期のインタビュー
  • 開発終盤の受け入れ試験での確認

ぐらいに参加。システムが稼働し始めてから、本格的に使って混乱します。 慣れてくると、本当の要望が出てきます*1

米国では、「業務設計担当者とアジャイルに開発して、現場の人はマニュアルにしたがって操作するだけ」なのでしょうか? 気になるところです。

「システムを段階的に導入して、現場の業務担当者のフィードバックを生かして、システムを育てていきたい」 と、常々思います。 受託開発では、納品後はシステムはソフトウェア開発者の手を離れます。 「現場の業務担当者のフィードバック」を受ける機会はあまりありません*2

*1:出てこなかったり、謎の思い込みから、明後日の要望がでてきたりするることもあります

*2:プロトタイプを触ってもらってフィードバックを受けることはあります。ただ、本気の要望かというと違う気はします。システム導入への恐怖感は減ります。業務担当者にプロトタイプを触ってもらうことは、システム担当者にはメリットがあると思います

とてか04に参加しました #toteka

d.hatena.ne.jp

椎葉さんの発表がぐっときた

すごかった。 「失敗したチームメンバーがいた時に、笑ったらいかんよ」と説明すると言っていました。 「そこまでやるのか。やると意味があるのは想像できるけど、自分ではできない」という意味ですごかったです。

懇親会で聞いてみました。

実際の説明はもう少し丁寧に「悪気がなくても、思っているのとは違う伝わりかたをするので気をつけてね」 とするそうです。

なんでそこまでやるのか? 「自分が抜けた後も、走る続けられるチームを作りたい」からだそうです。 自分とは立場が違うので無理して真似る必要はなさそうです。

(「チョットデキル人に訊け!」の話題と関係しています。)

track8さんの発表が面白かった

想像できない使用環境に起因するバグをどうやって想像すればよいのか?という話でした。 純粋に楽しめました。

「チョットデキル人に訊け!」が興味深い

「すごいなー」と思ってどうするの?

勉強会ですごい人の話を聞いて「すごいなー」と思ったときにどうすればよいのか、というご相談。

チョットデキル人の回答は忘れちゃいました。 その後自分で考えたことを...

自分が真似できない理由は8割が「自分がその問題に直面していないから」の気がします。 能力が足りていないのは2割ぐらい。

自分の「忍者式テスト」体験を振り返ります。

  • 10年ほど前に「忍者式テストすげー」と思った。そのときは品質保証の手段だと思っていた
  • 5年ほど前に、真似してみたがうまくいかなかった。このときは人力テストハーネスとして使っていた。が、テスト量のコントロールとテストのアップデートができていなかった
  • 2年前に「忍者式テスト」を上手くできた。開発者がテストしたので、集中できないほどのテストはやらなかった。つまらないテストもやらなかった。

10年近く真似できなかった、一番の原因は「忍者式テストで解決したい問題」を扱っていなかったからでした。

(その間にリファクタリング力が上がったのも多少は関係していると思います。)

というわけで、「すごい人のすごい技」はそのうち使えるシチュエーションにぶつかるので、心のメモ帳に書いておけばOKです。 使えるシチュエーションにぶつかっていないのに、真似するのは

ハンマーを持つ人には、すべてが釘に見える。 (アブラハム・マズロー

です。気をつけます。

テストがうまくなりたい

「テストが上手くなりたいモチベーション」が、チョットデキル人が三人とも違って面白かったです。

秋山さん:

プログラマーの頃は上手くなりたいとは思っていなかった。テストを専門にやるようになって、よりチームに貢献するために上手くなりたくなった。

関さん:

上手くなりたいなんて思ったことはない。必要だからやっている。

関さんの、仕事とプライベートをきっちり分けて、仕事に対しては、かっこよさやファッションを持ち込まずに、ひたすらプラグマティックに振る舞うのがすごいです。

和田さん:

最強のプログラマーになりたいので、テストも上手くなりたい。

和田さんはさすがの厨二力です。感嘆しました。 和田さんは、相手のレベルに合わせて、誤魔化しなしの正しい説明をリアルタイムでするのが、すごいです。

モカ・マタリ・アールマッカ

モカ・マタリ・アールマッカというブランドのコーヒー豆を調べたメモ

モカとは

イエメン産とエチオピア産のコーヒーをモカと呼びます。 モカの名称は港の名前に由来します。

モカ とは、イエメンの首都サナアの外港であるモカからかつてコーヒー豆が多く積み出されたことに由来する、コーヒー豆の収穫産地を指すブランド

モカの港からは、イエメン産のコーヒー豆の他、対岸のエチオピア産の豆も一緒に輸出されたため、両国産のコーヒー豆を合わせて「モカ」と呼んでいる

モカ - Wikipedia

モカ港

今はモカ港からコーヒーは出荷されていません。

現在、コーヒー豆集散地の機能は無く

モカ - Wikipedia

豆の特徴

モカ香と酸味が特徴のようです。

モカ香: イエメン、エチオピアのコーヒーのみが有する独特の香りです。ヨーロッパではワインフレーバーと表現されますが、少し違う、と感じながら的確な表現が見つかりません。

味: 柔らかい酸味が特徴。深めに焙煎しても柔らかい口当たりの苦味になります。

辻調おいしいネット / カフェ・マニアックス

生豆の品質はあまりよく良く無いようです。焙煎者の手間(ハンドピック)によるところが大きそうです。

外見: 粒(小粒のものが多い)と色が不揃いで、高級品でも欠点豆が多数混入し、一言で言えば貧相なコーヒーです。

辻調おいしいネット / カフェ・マニアックス

モカ・マタリとは

モカの中でも、モカ・マタリは耳なじみが良いです。コーヒールンバの歌詞に登場したためのようです。

コーヒールンバ」に唄われていたためか、日本でも人気が高い

モカ - Wikipedia

それは素敵な飲みもの コーヒー モカマタリ

西田佐知子 コーヒー・ルンバ 歌詞

産地

イエメンのバニーマタル地方で生産された豆をモカマタリと呼びます。

イエメンのベニーマタール地区で産出される最高級銘柄

イエメン コーヒー豆の詳細

イエメン国内でも、昔から最も優良なコーヒーを産出する地方

アラビア語で「バニー」は「子孫」、「マタル」は「雨」を意味します。  直訳すると「雨の子孫達」となり、名前からも雨に恵まれた地方であることが想像できると思います

「モカ・マタリ」は、本来、このバニー・マタル地方で採れたコーヒー豆のことだけをいいます

「モカ港から輸出されるバニー・マタル」の「マタル」が名詞化して「マタリ」となり、「モカ・マタリ」と呼ばれるようになった

バニーマタル3地域のコーヒー of 待夢珈琲店

豆の特徴

モカ香がなく、フルーティな酸味とスパイシー香が特徴のようです。

味は、甘みが特に豊かで、フルーティーな酸味があり、柔らかく、下にまとわりつくような脂肪感があります。香りは若草の爽やかな香り(特にニュー・クロップが強い)や色々なスパイシー香があり、一般にいわれているモカ臭はありません

バニーマタル3地域のコーヒー of 待夢珈琲店

「醗酵層の歴史が独特の酸味を産む」伝説があります。

モカマタリ独特のフルーティな香りと,甘酸っぱい味わいの秘密は収穫から珈 琲豆に加工される工程で,醗酵層に入れられるところで発生するようです。

イエメンのばあいはアラビカ種であっ ても自然体で天日乾燥(アン・ウォッシュト)され,脱穀機で乾いた果肉部分が削ぎ落 とされます。 果肉の下にはパーチメントという薄くて堅い皮があって,それを剥ぐ手段として醗 酵層に入れられパーチメントが醗酵によって柔らかくなるまで待ちます。 柔らかく名った時点で取り出され,精米機のように豆同士で擦り泡さてパーチメント と豆の表面にこびり付いているシルバースキン(銀皮)という薄皮が剥がされ珈琲豆と いう製品になる

イエメンでは醗酵層が100年前の状態のまま使 われているので,永年積もり積もった発酵菌が繁殖して独特の香りを付けるのだという 報告を聞きました。あのモカマタリの独特の甘酸っぱい香りと味わいは,醗酵層100年の歴史なんです

商品詳細|Dream Coffee(ドリーム コーヒー)

モカ・マタリ・アールマッカとは

欠点豆のおおいモカの中では選別が厳しく、扱いやすい豆が揃っているそうです。

現地で豆の大きさの大きいものだけを手作業で選別した極上豆をアールマッカと呼びます

イエメン コーヒー豆の詳細

イエメンで最新式のイタリア製選別機を所有する輸出業者が、原料の買い付け後、標高2700メーターの清涼な気候の丘陵地帯で保管と選別を丁寧に行っています

10月から2月にかけての収穫期に、3~4回程度、完熟チェリーのみを手摘みで収穫しています。そののち、各家庭の屋根で1週間ほど天日乾燥。そのチェリーはエリアごとの集売・脱穀業者に買い取られ、それを輸出業者が買い取ります。アールマッカを供給している輸出業者は買い取ったチェリーを最新の選別機でしっかり精選

商品のご案内|自家焙煎珈琲豆の製造直売・通販・卸「みずむら珈琲」

マタリの最高級品の一つとして流通している。イエメンの特徴的な短形の豆で、粒もかなり揃っていて、欠点豆も少ない。酸味も綺麗で味の濁りもなく、モカとしては扱い易い優れたコーヒー。ボディは強いが、なぜかモカ香は弱い。あまり徹底したハンドピックはしない方が良いかも

辻調おいしいネット / カフェ・マニアックス

価格

焙煎後で、100g 660〜850円で流通しています。

中間業者を中抜きすると受発注者はWin-Winになるか? 事例:クラウドワークス

結論

中間業者を中抜きは不可能。よりよい中間業者による代替えを目指そう

事例:クラウドワークス

crapp.hatenablog.com

にて、受注者側から見たクラウドワークスの問題点が挙げられています。

クラウドワークスは発注者のためのサイト

クラウドワークスとは、そもそもエンジニアの為に作られたサイトじゃなく、むしろクライアント(発注者)がエンジニアを安く買い叩くためのサービスに過ぎなかった

また

発注する側の手数料は一切かからず、仕事を請けた人間のみが手数料を徴収されるというシステムも印象が良くない。「クラウドワークスが発注者の為のサービス」だと言われる所以

中間業者中抜きへの期待

クラウドワークスにおいては、クライアント(発注者)とエンジニアは直結する。現実世界では、クライアント(発注者)とエンジニアの間に、仲介会社やエージェントなど「余計なもの」が入る。それなら、現実世界ではピンハネされている分だけ、エンジニアの取り分が増えても良さそう

よくある期待です。自分も意味がありそうに思います。

先人の失敗

絵や音楽

プロのクリエイターが、Gumroadで直接取引したときは、既存の流通業者を挟むより値段が安くなりました。

ascii.jp

1回目は初速がすごかったけど。2番目のは今日(アップロード当日の2月21日)の夕方までに16人。前のは57人。2枚合わせて、トータルで108ドルくらい。 とりあえず9000円くらいは儲かったよ

トップクラスのプロイラストレーターでこれです。

伝統工芸

伝統工芸でも起きました。こちらはどこで読んだか覚えていません。

問屋を飛ばした結果

  1. 受注が安定しない
  2. 安い仕事も受ける
  3. 高い仕事も単価が下がる

という話だったと記憶しています。

価格維持力が失われる

実際には期待に反し、価格維持力が失われています。 なぜでしょうか?

中間業者が必要な構造

クラウドワークスの価格低下構造

クラウドワークスでの、価格下げ圧は

  1. 受注側:新規参入者が技術力が低い分安く受ける
  2. 発注側:新規参入は価格と品質のバランスがわかりません。価格で受注者を比較して安い受注者を選ぶ

が考えられます。 この結果、(平均した)案件価格は下がります。

受注者は増える

受注者が少ない市場では案件価格があがるため、新規参入者が増えます。 労働市場は常に受注者が過多になる圧力があります。

受注者が極端に多い市場になると、案件価格が下がります。

価格下げ圧が強すぎると市場は縮小

価格下げ圧が強すぎると、安さを見込んで新規参入の発注者が増えます。 取引される案件の優良率が下がり、経験のある受注者がいなくなります。

まさに

割に合う案件がない

経験のある受注者がいなくなってしまうと、発注者は安く発注できても納品されないリスクを負います。 リスクの高い発注は本業には使えません。 お遊びや片手間の案件なら使えます。 案件の価格は下がります。

案件の平均価格が下がれば、市場は小さくなります。

中間業者の機能1 参入障壁(受注者のフィルタリング)

受注者が増える圧力を止める必要があります。 そこで、中間業者を挟んで受注者を一定以上のスキルにフィルタリングします。

これは同時に価格の維持にもつながります。 受発注者が直接つながるよりwin-winになります。

中間業者の機能2 案件のバッファリング

伝統工芸など、市場規模が成長しない場合は、発注の波を受注者が吸収するのは厳しいです。 中間業者による発注のバッファリングが必要です。

クラウドワークスさまへのご提案

クラウドワークスさまが、受発注者を幸せにするために必要なこと

  1. 受注者を精査して技術が低すぎる人をフィルタ

また、質の良い受注者を集めるため

  1. 発注内容を精査して価格が低すぎる案件をフィルタ

しかし、この作業は案件が増えると、必要な労働力が増えます。スケールしません。

そうだ、クラウドソーシングで外注しよう!(笑

参考リンク

人はなぜ憎しみを抱くのか

要約

なぜ憎しみを抱くのか

  1. 幼少期は親が居なくては生きていけない
  2. 自分の感情と親の意向が矛盾することがある(お腹が空いて泣くvsうるさい)
  3. 生きるために親の意向を尊重する
  4. 親の意向と矛盾する自身の感情を良くないものとして認識する
  5. 感情豊かな人を見ると、自身の感情を思い出す。抑えられなくなる
  6. 憎む

なぜ親は子を憎しみを抱くように育てるのか

  1. 社会のルールや規律を守ることが子供のためと信じている
  2. 子供の感情を直視して相手できない時がある(子を愛する能力に欠けている時がある)
  3. 信じる価値観や、それを守る良い親像を作るために「お前のためだ」と理由付けする

権威主義的な親に育てられた)憎しみを抱いた子はどうなるか?

  1. 父親の権威による支配から逃れようとする
  2. 父親より強力な権威(軍国主義・宗教のリーダー)の支配下に入る
  3. 極右団体のメンバーになる

なぜドイツではナチスが支持を得たのか

  1. 権威主義的な教育(シュレーバー教育)がドイツで流行った
  2. 多くの子が憎しみを抱くように育てられた
  3. (無意識に)憎しみを共有できる人が増えた
  4. 憎しみを肯定する(攻撃の理由付けをする)強いリーダーが求められた

シュレーバー教育は、本書に記載なし。以下を参照してください。

19世紀末、徹底的に子供をしつけるというシュレーバー教育がドイツで流行していた

東京大学東洋文化研究所

感想

精神分析学一般の話として読むとピンときませんでした。 ドイツでナチスが流行った理由の分析として読むと興味深いです。

著者のアルノ・グリューンはドイツ生まれのユダヤ人です。 ナチス時代のドイツに住み、迫害を避けデンマーク経由でアメリカに亡命しました。 ドイツを蔑んで(旧東ドイツでの極右団体による外国人排斥活動など)、アメリカを持ち上げる傾向があります*1

訳者の方が心理学または精神分析学の人でなく、文学の方です。「自分の中の他人」や「親からのテロ」などの訳語が、心理学または精神分析学方面としてふさわしいのかよくわりません。個人的にはわかりにくいと感じました。

単著に見えますが、インタビューをまとめた本です。 体系化されているわけではないので、論理としてはわかりにく点があります。

そもそも古い本です。「権威主義的な教育を受け傷ついた青年が、オイディプスコンプレックスを解消するために、極右活動に参加する」というのは、少しステレオタイプな感じを受けます。 現代の精神分析学でどのような解釈をされているのか気になるところです。

経緯

「生きる技法」の参考文献

本当は「才能のある子のドラマ」を読もうと思ったのですが、その時あまり良い出品がなかったためこっちにしました。

「生きる技法」を読んだ理由

何年も前に羽生田栄一さんが串田幸江さんにオススメしているのを見て、アマゾンのWishlistに入れていました。 誕生日にもらったので読んでみました。

*1:アメリカにも、差別的な活動をする人は、それなりにいそうなものです

日本Kindle化計画 その3

バックエンドサービスの選び方

日本Kindle化計画ではストレージにRedisを使っています。 公開するために、どのサービスのRedisを使うか決めたいと思います。

なぜRedisか?

以下の理由で、Redisを選択しました。

  • セットとハッシュぐらいのデータ構造で十分
  • 今の所1KB程度使っている。100倍使っても大したデータ量にはならない

Redisのホスティングサービス

無料の一つ上のプランの価格で選びました。

予算見積もり

日本Kindle化計画の予定する収入源はAmazonアフィリエイトです。

  1. 現在のKindleアフィリエイト8%
  2. 漫画が平均500円とする
  3. 一冊あたり40円
  4. 5$=615円払うには月に15冊以上購入してもらう必要があります

大きな収入は見込めません。 無料で始められ、仮に負荷が増えた場合もなるべく安いランニングコストで解決できるサービスがほしいです。

サービス本体はHerokuで動かす予定です。Heroku add-onも調査に含めています。

Redis To Go

老舗

Redis Labs

知名度No.1

Heroku Redis

Herokuの公式add-on

15$/月 Heroku Redis - Add-ons - Heroku Elements

Amazon Elasticache

AWSで使うなら

$18/月

選んだサービス

Herokuで使うならRedis To Goが良さそうです。

東京Node学園祭2015に参加しました #nodefest

本編短評

Node Discussionがめっちゃくちゃ面白かった

  • @domenicさんはbabelが好きじゃない*1。moduleはもっと好きじゃない*2
  • Node.jsにES6 moduleサポートが入る目処は立っていない。そもそも仕様が決まっていない。
  • power-assertはNode.jsのコアに入らない。コアのassertはNode.js自身のテスト用という位置付け。Node.jsは標準ライブラリを持たない方針なので、標準ライブラリにも入らない。

講演

  • Paypalでは800人のNode.jsエンジニアが働いている(!)。NASAでも使われている!!
  • npm preversion/postversion便利そう!
  • @kosamariさんがクソかっこよかった!Node学園祭は女性の発表が毎年パワフル
  • 来年のNode学園祭にはDouglas Crockfordさんが来るかも!?(Paypalの中の日本人が交渉してくれるらしい)

懇親会で

@t_wadaさんに聞いた情報

babel6が結構、大変らしいです。

プラグイン機構が変わりすぎてプラグインの対応に11月中ぐらいは時間が掛かりそう。 それが終わっても、プラグインの実行順序を定義する方法がないので、プラグイン間で衝突が起きそうらしいです。

power-assertなどを使っているbabelユーザーの人は、しばらく5のまま様子を見た方が良いのかもしれません。

二次会で

@fossamagnaさんに聞いた情報

最近Node.jsを始めたそうなので「コールバックなAPIはどう?」と聞いたら 「マルチスレッドの設計するよりはマシ」的な回答をいただきました。

なるほど、言われてみれば、スレッド間のシーケンス設計は面倒臭かった思い出があります。 それに比べればコールバックヘルは面倒くさいだけなので良いのかもしれません。

@rvaggさんに聞いた情報

正確には会長(@yosuke_furukawaさん)に通訳してもらって聞いた情報です。

Node.jsにコントリビュートするにはFLAKYテストの修正が取り込まれやすいそうです。 FLAKYテストというのは、成功したり失敗したりするテストのことです。 どのテストが対象かは、下をのURLを見るとわかる

よっしゃ、コントリビュートのチャンスや!

帰り道

Podcastを確認したら、本当にNodeUp: A Node.js Podcastから@dshawさんの声が聞こえました。 @dshawさんの英語は文末が跳ねるから、聞き取りやすいです。 それでも聞き取れませんが。

飛び込みLT

東京Node学園祭飛び込みLT

めちゃくちゃ受けなかったけど、顔とアカウントが一致していない人に話しかけてもらうきっかけになったので良かったです。 こういう道具は常に用意しておくのが良さそうです。

*1:好きじゃないというか、標準として扱われていることに困惑している

*2:好きじゃないというか、やられすぎている

道具としてのプログラミング、目的としてのプログラミング

プログラミングの学習曲線

Ruby on Railsはプログラミングではない! | それでも人は夢を見るの話です。 Ruby on Railsの有料講習を受けたが、受講前にイメージしていたプログラミングと、受講後の自信の能力のギャップに驚いている方の話です。

これは学習曲線の問題な気がします。

自分がプログラミングの勉強を始めた頃の話です。 入門書を読みながら、Perlをぽちぽち入力して掲示板CGI動かしてみました。 ですが、その次にどうすれば、イメージしているプログラミングに近づけるのかわかりませんでした。(その時は)挫折しました。多分、元記事の方も同じような状態なのだと思います。

一つの課題をクリアしたものの、次に何をすれば理想のプログラマに近づけるのかわからず戸惑っているのではないでしょうか?

プログラミングで世界を変えるということ

その後、自分がどうやってこの壁を越え、プログラミングを道具と認識したのかを振り返ってみます。

大学の授業や新人研修でのプログラミングの勉強はしました。課題を解くことはできました。それでも、コンソールに表示するプログラミングと、世間に溢れている(当時は今ほど無いけど)WEBやGUIのプログラミングが遠すぎて、やはりプログラミングが何かよくわかりませんでした。 結局、仕事で3000行ぐらいのプログラム書いたときに、やっとプログラミングが何かわかった気がします。

何が本質的な課題なのでしょうか? あるいは量でしょう。基本的な文法に悩まなくなった時に、プログラミングで解決したい課題に悩むことができます。

おそらく、もっとも重要なことは

現実に存在する課題を解決するプログラミングを書くこと

でしょう。練習問題を解いても、世界は変わりません。現実の課題を解くと、世界をプログラミングでちょこっとだけ変えることができます。

世界を変えることは、小さな変更を繰り返すことです。

職業プログラマのすすめ

プログラマとして就職すると、絶えることなく「解決すべき現実の課題」を提供してもらえます。 しかも、プログラミングスキルに合った規模に分割して「ここだけ書いて」と教えてくれるので、ハードルがぐっと下がります。

ある若者は、自分で書いたプログラムを、実際に使って喜んでいる人を目の当たりにして、プログラミングに対する意欲がガラリと変わりました。これは「自分がプログラミングで世界を変えたこと」を実感したからではないでしょか?先輩技術者と一緒に、現実の課題を解決するのはおすすめです。

他人の課題を解決するのに飽きたら、自分で好きな課題を見つけて解決すればいいのです。それはもしかすると、世界を大きく変えるかもしれません。

Ruby on Railsの複雑度が問題?

Railsはプログラミングでは無いのか | サークルアラウンド株式会社ではRailsの抽象度の問題と解釈してSinatraをすすめています。

なるほどSinatraの方が少し簡単ですし、過去にSinatraの方が簡単なのにと愚痴ったこともあります。 Railsは覚えることが多いので「プログラミング初心者には大変だなぁ、Sinatraの方がまだ良いなぁ」とは思います*1

また、課題を取り組みながら仕組みを、わかりやすく説明してもらえれば、Ruby on Railsの使い方だけでなく、Webアプリケーションの仕組みやデータベースを使う意義などを理解できるかもしれません。

それでも、言われた通りにプログラミングするのと、現実の課題を解決する道具としてプログラミングするのはちょっと違うような気がします。

プログラミング研修の限界

研修課題には解決できない(かもしれない)問題は出せません。また、現実の課題をプログラミングで解決可能な形に解釈するには、独特のコツが要ります*2

現実の課題を解決する形でプログラミングを学んでいくコースを、2ヶ月18万円で提供するのはちょっと難しそうです。

一ヶ月90万を半年間払っていただければやります。人によっては60万円ぐらいでやってくれるかもしれません。 ただし、ゴールは対象者の資質によって大きく変わりそうです、保証できません。 こういう条件で申し込んでくる人はいなさそうですね。 そんなわけで、ビジネスとしては成り立ちません。

まとめ

プログラミングで世界を変える最短経路は

  1. 職業訓練と割り切ってRuby on Railsの勉強をする*3
  2. プログラマとして就職する
  3. お仕事としてプログラミングする
  4. インターネット世界の構成要素を知る
  5. 世界を変える

以上です。身も蓋もありません! プログラミングを楽しんでね!

*1:プログラミング初心者にとってはSinatraRailsのControllerはどっちも難しいかもしれません

*2:恐ろしいことに、このコツは日々変わります。そのお陰で職業プログラマは食いっぱぐれません

*3:別のプログラミング言語でも、別のフレームワークでもライブラリでも、就職に役に立ちそうであれば、なんでもいいと思います

日本Kindle化計画 その2

APIデザイン的な悩み

「ASIN登録用APIで、即座にKindleの有無をチェックしに行くべきか?」

メリット

即座にフィードバックが得られる

デメリット

APIを公開できない(公開版を別にデザインする必要がある)

  1. Amazon APIに呼び出し制限がある
  2. 並列して実行すると呼び出し数を制御できない

公開版を考えると...

  1. 非同期処理にして、結果をあとで受け取ればできる
  2. 即時性がなくなる

背景

ASIN登録用APIに必ず求めること

  • ASIN(正確にはISBN10)でない文字列を無視する
  • ASINを含むURLからASINを取り出す
  • ASINを検索候補として保存する

実装して試しに幾つかのURLを登録したところ、Kindleの有無チェックが欲しくなりました。

結論

翌日、もう一度使ったらいらなくなりました。 APIの使い方に迷っていただけのようです。

日本kindle化計画 その1

背景

占有体積コストがバカにならないので、漫画を極力Kindleで買うようにしています。 Kindle版は紙の書籍より遅れて登録されます。 紙の書籍を発見されてから、Kindle版が出ているかどうか定期的に確認する必要があります。

既存のKindle化チェックツール

既存のチェックツールがあります。

ざっくり、以下の点が僕の要望とミスマッチです。

通知方法がメール

  • kindlize-itは通知方法がメールです

以下、Kindle Alertのみの話です。

ログインが必要な理由が書いていない

  • ツイッターID確認のためだとは思う
  • 他人のIDを登録しても大した悪さはできない気がする・・・
  • メンション自体は自由に飛ばせる
  • 全く使っていない人はブロックすればいい
  • 使っている人に、自分の好みでないものを勝手に追加されると辛い気はする
  • 削除できないのが問題な気もする

キーワード検索

  • 使う時点で、紙の書籍があることは知っています
  • asinを直接指定したい

検索結果にkindleがあるか載っていない

  • 毎回amazonへのリンクを開くの?
  • kindleがあっても登録できてしまう・・・

自分への通知が登録済みかどうかわからない

  • ストーキングに使える?
  • twilogで検索しても一緒なので、過去に対しては意味がない

どういう通知が来るのかわからない

  • 直近のツイートが表示されていると良さそう

APIがない

  • Chrome拡張から登録できない

その他

  • 検索結果がconfirm?
  • なぜ1アカウントずつツイートなんだろう?他人のアカウントが見えたらまずい?
  • ハッシュタグが入っていればいいのに
  • 既にkindleが出ているものも通知してくる

自作

とりあえずチェック部分だけ作りました。 まだデータ投入は生クエリです。

さっそく、入力データをミスりました。 次は、入力インタフェースを作ろうと思います。

辛さ

AWSTwitterの二つのAPIで6個の秘密情報を管理するのが辛いです。

#TestingFrameworkMeeting に参加しました(1) - テスティングフレームワークの歴史

参加した時のメモです。

t-wadaさん

Testing Framwork Meeting

テスティングフレームワークの歴史

http://www.slideshare.net/everzet/bdd-in-symfony2/42 のスライドがベース。

有史以前

make checkのように、テストを自動化する風習はあった。 開発者はそれぞれ秘伝の手法でテストコードを書いていた。

JUnit

Kent BeckJUnitを書いた。

プロダクトコード書いてから、テストコードを書くまでの時間が短いほうが、 プロダクトコードに対する気づきが得られ、それをプロダクトコードに反映できることがわかった。

テストコードをさらに早く、プロダクトコードより早く書いた。 テストファーストが生まれ、ユーザーの視点でプロダクトコードを設計できるようになった。

自動テストがあれば、設計して実装してから、実装だけを直せる。 サイクルをもっと短くし、テストファーストリファクタリングを繰り返すテスト駆動開発(TDD)が生まれた。 *1

JUnitの語彙assertEqualsがテストコードを支配した。

JUnit Pocket Guide - O'Reilly Media がテスティングフレームワーク作者ののバイブルになった。

BDD

テストコードが表しているのは、テストではなく仕様であると考える者達が居た。 Dan Northは、それにbehavior driven development(BDD)と名付けた。

RSpecが生まれ、振る舞いを記述するための語彙、should, expect ... 、が増えた。 各プログラミング言語にXSpecが生まれ、語彙が乱れていった。

また、自然言語のように書けテストコードをのように動く仕様で、 お客さんと一緒に仕様を書くことを考える者達が居た。 Fitが生まれ、cucumberが生まれた。

BDD派は、前者がSpec BDD派へ、後者がScenario BDD派へ分派していった。

power-assert

RSpec3が生まれた。テストコードの語彙がさらに増え、いろいろな書き方ができるようになった。 テストコードを書くのに学ぶべきことが増えた。

多くのRuby on Rails使用者は、Rails本体とRSpec、両方の変化の速さについて行くために苦しんだ。

テストが失敗した原因をわかりやすくするために、 語彙を増やす以外にテスティングフレームワークができることはないか考えた者が居た。 Groovyにspockが生まれた。 そこにはPowerAssertと呼ばれる力があった。

Condition not satisfied:

name.size() == length
|    |      |  |
|    6      |  7
Scotty      false
魅惑的(Fascinating)なテスティングフレームワーク Spock - A Memorandum

エラーに失敗した時だけ饒舌なassertが生まれた。 ASTをごにょごにょして、t-wadaさんがJavaScript版のpower-assertを作った。

evolve slowly

テスティングフレームワークは、直接的にプロダクトコードを改善しない。 10年くらいのペースで変わるのが望ましい。

議論

語彙と階層
  • RSpecの語彙の多さは、目的が仕様記述言語を目指しているから。 多くのユーザーは階層化と語彙の多さは分離して欲しいが、わけて使えない。 それで批判に繋がっているのでは?
  • RSpec以降のライブラリは階層と語彙を分けれるようになっている。(例えば)mochaは階層化だけを提供していて、assertライブラリは別に組み合わせて使う。
学習コスト
  • RSpecのシェアが大きすぎるので、学習コストの批判が目立っているのでは?
  • 政治的な理由でRSpecを選択していることもある。それで批判されやすいのかもしれない。
日本語でシナリオBDD
  • cucumberは正規表現で実装されている。日本語で使える可能性や価値はあるのか?
  • 過去に、「なでしこUnit」を作った。日本語の語順と制御の順が合わないので、そんなに嬉しくなかった。
テストコードのレイヤーが増えること
  • (プロダクトコードと異なるプログラミング言語で描かれている)cucumberを使った、テストは落ちたときに原因を探すレイヤーが増えて辛かった。
  • JavaのテストコードをGroovyで書く人たちがいる。テストコードを書く効率はあがる。
Reads like as spoken language
  • RSpecには読みやすさを提供する目的があったのでは?
  • JUnit4でisが入って読みやすくなった。覚えるコストは増えた。これは二律背反、当分解消できそうにない。
Expamleとしてのテストコード
  • Expamleとしてのテストコードを考えると、TDDではプロダクトコードに近く例としてわかりやすい。 BDDで仕様記述に近いと、例として使えなくなっていく。
  • Exampleとしてのテストコードは一部なので分けて考えた方がよさそう。 Haskellにはdoctestという、公開するAPIにExampleとしてのテストコードをつける文化が生まれている。公開しない部分はhspecで書く。
  • Goでは、Exampleとしてのテストコードを書くツールがある。

simple vs easy

power-assertの設計思想について。

で、衝撃を受けたという話。

  • Simple 客観的
  • Easy 主観的

SimpleとEasyは混同しやすいけど、分けて考えた方が良い。 原則はSimpleを目指し、EasyはEasyを提供する別レイヤーを提供すると良い設計になる。

実際にソフトウェアを作る時は、怠惰・短気・傲慢の怠惰を元に、 簡単さを求めて作り始めて、複数の簡単さの競合に気づいて、「シンプル」と「簡単」に分けるようになることが多い 。

qunit-tapの開発では、当初Easyを求めて「自動的にQUnitを探す」設計にしていた。 多様な環境に対応できなかったので、Simpleな「QUnti引数で受け取る」設計に変えた。 結果、より多くの人に使いやすくなってユーザーが増えた。

リンク

つづき

は、書かないかもしれません。

*1:詳しくはわからないがXP本の1版と2版の間の、どこか

ゴー・ノーゴー課題の原著論文を発見

最近の小学生における高次神経活動の特徴 : go/no-go 実験における誤反応と型判定を基に

計測方法

Pavlov, I. P. 理論(ハ・エス・コシトヤンツ,1955)に基づいて 
Luria, A. R.(1969)により考案された方法

形成実験

「いまから,みなさんの目の前のランプがこの色(赤色)に光ります。この色に光ったら,
すばやくゴム球を握ってください。消えたらパッと離してください」との指示を与え,
10 回の練習を行った後,直ちに 3 ~ 6 秒間隔で,1 回 0.5 ~ 1.5 秒間の光刺激を5 回呈示した

分化実験

次に,「今度はこの色(黄色)に光る時もあります。でも,その時は握ってはいけません。先ほどと同じ,
この色(赤色)の時だけすばやく握ってください」と の指示を与えて,
4 回(go task:2 回,no-go task:2 回)の練習を行った後,直ちに go task と no-go task を
ランダムに呈示した(分化実験)。
この時の光刺激の 呈示間隔と時間は先の形成実験と同様であるが,刺激回数は go task,
no-go task とも 11 回ずつとした

逆転分化実験

最後に,「最後は先ほどと反対です。この色(黄色)の時にすばやく握ってください。この色(赤色)の時
は握らないでください」との指示を与え,4回(go task:2 回,nogo task:2 回)の練習を行った後,
直ちにgo taskと nogo task をランダムに呈示した
この時の光刺激の呈示間隔,時間,回数は,すべて分化実験の場合と同様とした

各型の分類基準

分類型 分化実験 逆転分化実験
不活発型 no-go taskに対する誤反応3個以上かつgo taskに対する誤反応1個以上
興奮型 no-go taskに対する誤反応3個以上かつgo taskに対する誤反応0個
抑制型 no-go taskに対する誤反応3個未満かつgo taskに対する誤反応1個以上
おっとり型 no-go taskに対する誤反応3個未満かつgo taskに対する誤反応0個 no-go taskに対する誤反応3個以上もしくはgo taskに対する誤反応1個以上
活発型 no-go taskに対する誤反応3個未満かつgo taskに対する誤反応0個 no-go taskに対する誤反応3個未満かつgo taskに対する誤反応0個

考察

元来,ヒトは 5 つの型の中でも最も幼稚な型といえる「不活発型」からスタートし,加齢とともに子ども
らしい「興奮型」の時期を経て,次第に成人らしい「活発型」に移行していく(正木・森山,1971;
西條ほか,1981)ものと考えられてきた

これはあまり違和感を感じません。

1998 年調査の結果では,小学校に入学する頃になっても「不活発型」が 5 ~ 6 割にも達しており,
かつその後の推移をみても,男子ではなかなかこのタイプの子どもたちが減っていかない様子から
「学校崩壊」と呼ばれているような事象が起きてしまうのもある程度うなずけるのではないか,
と推察されている(野井,2006)

これはちょっとだけ違和感があります。

感想

go task 11回試行中1ミスで不活発型が興奮型に分類されるのがシビアに思えます。 ですが、結果を見ると、抑制型の出現率は10%前後です。妥当なのかもしれません。

実施環境(明るさ、環境音)によって結果が左右されそうな実験に思えます。 複数の対象群を比較しても意味はないのかもしれません*1

前記事

ledsun.hatenablog.com

*1:ソフトウェア工学でも「異なるソフトウェアを作る異なるスキルのエンジニアで構成されたチームを、同じ計測方法で計測すれば比較できる」と考えてしまうミスが、しばしば起こります

ゴー・ノーゴー課題

はじまり

あまり共感できなかったある本のP20に

旧ロシアの生理学者・パブロフさんの理論に基づいて、子どもたちの大脳前頭葉の特徴を
前頁の表2に示した5つのタイプに分類し、判定しています。
この調査は、「go/no-go実験」と呼ばれているもので

という記述がありました。どういう調査方法なのか調べてみました。

ゴー・ノーゴー課題

認知心理学に「ゴー・ノーゴー課題」というものがあるそうです。

ゴー・ノーゴー課題では、単純な反応を抑止する能力を測定する。
参加者は、ゴー試行(例えば、画面上にQ. P, Tの文字)ではできる限り早く反応(ボタン押しなど)を、
ノーゴー試行(例えば、画面上にXの文字)では反応を抑止するように教示される。
ノーゴー試行でどの程度エラーを産出したかが指標となる

そして

児童期以降は、成人と同じStroop課題やゴー・ノーゴー課題が用いられ、
12歳から16歳頃までに緩やかに発達することが示されている

児童の成長に伴い、エラーが減るようです。 もとは前頭前野の働きを調べる方法だったようです。

前頭前野に損傷のある患者は,ノーゴー反応が求められても,運動反応をしないように抑制することが
困難である。

いずれにせよ、「ゴー・ノーゴー課題」自体には、「5つのタイプに分類」は含まれていないようです。

出典

前出の本でデータの出典が「子どものからだと心白書2006」とありました。 子どものからだと心白書2013を参照したところ、P132 に最近の調査結果が掲載されていました。

調査結果のみで、調査方法は記載されていませんでした。

感想

「ゴー・ノーゴー課題」の計測結果をどのように「5つのタイプに分類」するのか興味深いところです。

また、今の所はイワン・パブロフと「ゴー・ノーゴー課題」の関連も発見できていません。 こちらも気になるところです。

アドテク情報調査中

なぜ今アドテクが流行っているのか?

広告主と消費者のマッチングが適切になると

  • 広告主は少ない費用で売り上げに繋げられる
  • 消費者は全く興味がない広告を見ないで済む

win-winになります。

2014年からネット広告を取引する電子市場が成立しはじめました。 広告主と消費者のマッチングアルゴリズムの工夫次第では、広告の効果を増やせる可能性が出てきました。

そもそも広告市場は巨大です。 5兆円を超えています。ネット広告は1兆円に迫る勢いで成長しています。

ネット広告取引の歴史

以下の順で取引手段が増えました。

  1. 純広
  2. アドサーバー
  3. アドネットワーク
  4. アドエクスチェンジ

純広

広告を売るメディアが、広告枠を売ります。 一般的には広告代理店が広告主に「枠」を売るようです。

アドサーバー

広告をメディアのサーバーからでなく配信サーバーから配信サーバーします。

  1. 広告主はメディアの直接入稿しなくてよい
  2. メディアは期間ではなく表示回数で広告を売れる

アドネットワーク

メデイアは表示数以上に広告を売ることはできません。 見込み表示数より少し少なめに広告枠を売るため、在庫が余りがちです。 在庫の余り分だけ、アドネットワークから出稿を買います。

アドネットワークが複数の広告主から出稿受けておきます。 在庫の余り分なので、あらかじめ安めの価格で売ります。

  1. メディアは余剰在庫がなくなる
  2. 広告主は安い価格で出稿できる

アドエクスチェンジ

アドネットワークでの余剰在庫取引量が増えてくると、普通の広告枠もリアルタイムに取引したくなりました。 そこで出てきたのがRTB(リアルタイムビッディング)です。 広告枠を1表示単位でオークションします。

メディアと広告主がリアルタイムオークションに対応できるシステムを持っていません。 それぞれのシステムを提供するサービス会社を

  • SSP(サプライサイドプラットフォーム)
  • DSP(デマンドサイドプラットフォーム)

と呼びます。

これらの広告取引エコシステムをひっくるめて、アドエクスチェンジと呼びます。

知っておきたい略語

参考図書

ザ・アドテクノロジー データマーケティングの基礎からアトリビューションの概念まで

ザ・アドテクノロジー データマーケティングの基礎からアトリビューションの概念まで

広告用語から説明があって、広告業界初心者にやさしいです。 この記事は、この本からの受け売りです。

DSPはなぜアドネットワークに勝てないのか: 『枠から人へ』は間違いだった

DSPはなぜアドネットワークに勝てないのか: 『枠から人へ』は間違いだった

売上金額でアドエクスチェンジ業者とアドネットワーク業者をみると、未だアドネットワーク業者の方が圧倒的だそうです。 なので、「アドエクスチェンジは真新しいだけで、アドネットワークを完全に置き換えるようなものではない」という趣旨の本です。

ただアドネットワークの代表として上がっている業者が、下記カオスマップではモバイル向けです。 アドネットワークが優位なのもスマートフォンブームによるものかもしれません。

参考URL

アドテク業界では業界地図のことをカオスマップと呼ぶらしいです。 2015年版は複雑すぎます。初心者には2013が優しいです。

海外で枝豆が人気とかいう話を聞いて

そもそも枝豆も食べる食習慣がないのだろうか?

枝豆の歴史 枝豆の総合情報サイト えだまめ日和 によると

未成熟大豆としての枝豆を食べるという食文化は、長い間、アジア諸国独自のものでした。
1991年に出版された *3「New Crops」に「EDAMAME」がアジア特有の新作物として紹介されています。
したがって、この時期までは一般的にアジア以外の諸国では食物としての「枝豆」は知られていなかった
とみてよいでしょう

1991年まで、大豆を枝豆として食べる文化は、アジア以外に知られていなかったらしい。

大豆は?大豆は一般的なんじゃないの?

世界の大豆(生産量、消費量、輸出量、輸入量、価格の推移) によると

大豆の主要な生産国は

  1. アメリカ
  2. ブラジル
  3. アルゼンチン

大豆を作っているのに枝豆にしないのはなぜ?

大豆の歴史|世界の大豆生産国の変遷 によると

ヨーロッパでも大豆を栽培してみようという動きが出てきましたが、
登熟までに必要な日照時間が足りないなどの理由で栽培が難しく、断念しています

ヨーロッパでは生産できないようです。確かに主な生産地に入っていません。 枝豆を食べる習慣がないのも納得です。

では、アメリカでは?

20世紀に入ると大豆は食料の他にも工業原料としての大豆油にも注目が集まりました。
大豆油は石鹸、クレヨン、ローソク、洗剤、ペンキ、ワックス、潤滑油、インクなどの原料として
用途が広がっていき、ヨーロッパ、アメリカは大豆油確保に真剣に取り組み始めました

生産当初は大豆油の原料扱いだっため、食べ物としての認識していなかったのかもしれません。

牛乳、牛肉、卵を生産するための畜産飼料に大豆タンパクが有効であることを見出した

次に飼料用になり、やはり、食べ物ではなかったのかもしれません。

また、南米も

大豆の購入先を失ったソ連はこれに対抗して南米のブラジル、
アルゼンチンに資金を投入して大豆調達の道を広げていった

と、あります。

結論

大豆は(アジア以外では)食べ物ではなかったようです。