 
|
はてなキーワード: 最適化とは
「受信トレイ フォルダが満杯のため、これ以上メッセージを保存できません。メッセージを保存する領域を空けるには、古くて不要なメッセージを削除するか、フォルダを最適化してください。」
ん？受信トレイは空なんだけど
とりあえず素直に受信トレイフォルダを「最適化」したら、受信が始まって、エラーは出なくなった。
社員の人から問い合わせを受けてから5分もかからず対処できたので、まあよしとしよう。
Thunderibirdは、無料のうえに出来がいいソフトだ。どんなソフトにも１００％は期待してないもん。
社会的機関の多くは、自らの氏名を道義的に絶対的のものとし、経済的な費用効果の対象とはしない。
経済の世界では、より大きな成果を得るために常に資源の配分を変える。すべてが相対的である。
しかるに社会的機関においては、より大きな成果などというものはない。より大きな善もない。
目的を実現できないということは、努力を倍加すべきことを意味するだけである。
飢餓撲滅運動のリーダーは、飢えている子供が一人でもいるかぎり、われわれの使命は終わらないとする。
可能なかぎり多くが発育不全にならないだけ食べられるようになれば、
われわれの使命は終わるとでもいおうものならば、リーダーの地位を追われるだけとなる。
しかし、目標が最大化にあったのでは、決して達成されることはない。
それどころか、達成に近づくほど一層の努力が求められる。
なぜならば、最適値を超えるや、得られる成果は指数関数的に小さくなり、必要とされるコストは指数関数的に大きくなるからである。
こうして社会的機関は、目的の達成に近づくほど不満を感じ、より一層活動に力を入れることになる。
さて問題です。
なぜでしょうか。
自称SEO対策屋のはてなブログで上位表示【SEO対策屋】(http://seoes.hateblo.jp/)はスパム屋と思われます。
id:koragon
http://b.hatena.ne.jp/koragon/のブックマークを調べてみる。
アメブロでYahoo Googleの検索エンジン上位表示をめざす (http://ameblo.jp/seoisland)内のページがとても多い。
赤ちゃんの名づけ応援団・ぴよぴよクラブ(http://www.naduke.com/)へのブックマークが見られます。
右下にSEO上位対策My Island(http://myisland.jp/)のバナー
http://myisland.jp/より、Amebaブログ上位対策屋のバナーが。このバナーはhttp://ameblo.jp/seoisland/へのリンクとして張られています。そういうわけでぴよぴよクラブ(http://www.naduke.com/)へのブックマークはセルフブックマーク。どうみても上位対策目的と思われます。
第6条(禁止事項)
6.ユーザーは、本サービスの「はてなブックマーク」を利用するに際し、以下のような行為を行ってはなりません。
http://www.asahi.com/business/update/0124/TKY201201240616.html 24日のニュース
http://www.meti.go.jp/press/20100820003/20100820003-2.pdf その発端ともいえる二年前の報告書
始まりは、ありがちな汚職だと思えた･･･その巨大プロジェクトの実体は！
1部～2部で内容が重複してるから、ストーリーだけ知りたい人は3部から読むのをお勧めする。図表もあるのでわかりやすい。
これについてのブコメやTwitterを見ていると不祥事を叩いたり、やめた事を批判して55億賠償しろって人も結構いるのだけど、なんかもうそういう問題よりも気になる点が山ほどある。自分の感想をまとめておく。不祥事そのものより、その裏にあるプロジェクト全体や日本の開発にありがちな問題にもっと注目されて欲しいのでそういう視点で書く。
入札前の情報漏れにしても、その後のNTTDとのやりとりにしても、情報漏洩やそれにまつわる金銭の動きは犯罪だ。けどもそれが行われた動機が私利私欲のためだけとは思えない。
共有されるべき情報が共有できるようにされていない。やりとりできるべき情報ができるようにされていない。必要な情報がちゃんと流れていないから、イレギュラーな方法で流れている。特許庁, NTTD, TSOL この三社間のコミュニケーションがどこも投げやり丸投げ気味で、慢性的に情報不足だった感が伺える。ここを改善する必要があるよね。
極秘情報は必要最小限にして、より情報の共有を図るべき、入札前に必要な情報は公開できるようにすべきって報告書でも書かれている。
入札での評価が金額偏重で、マネージメント力を評価してなかったって問題。マネージメント力を評価してないのマジやばい。あ、でもマネージメント力を評価するには、全体を理解できる人材が必要だよね。で、次の問題に繋がるんだけど。
報告書だと、上流の話しか出てこない。だから、｢設計もろくにできないで55億無駄にしたのか！｣って話になるけど、ちょっと待って。設計しかできない人間が山ほどいても捗るわけがないってことなんだよ。特に、このプロジェクトは既存システムを0から作り直すのだから、既存システムをよく理解して、また既存システムにかかわる技術者とよくコミュニケーションが取れて、それを設計に正しく咀嚼できるスキルの持ち主が必要で、設計しかできない人材ではなく全体を理解できる人材が必要だったはず。
既存システムをちゃんと理解できてない人間だらけになったということが報告書でも繰り返し指摘されてるけど、その根底には設計しかできない人間が山ほどいても捗るわけがないという問題があると思うんだ。
6年？そもそも設計に数年ってのが、もうそういうの無理が来てるって感じ？6年経つ間に色々変わっちゃう。
どうしても、がちがちのウォーターフォールでやるなら、もっと受注も小分けにして、まずは既存システムの仕様まとめプロジェクトから開始するのが良かったんじゃないかな。
6年まとめてどん！だと中断の決断もなかなかできないよね。
これだけプロジェクトが炎上していたのに、汚職がきっかけで調査が入るまで炎上がちゃんと認知されていなかったというのがやばくね？もし汚職が見つからなかったら、炎上のまま･･･
これは国のプロジェクトだから汚職で厳しい調査が入って、プロジェクト炎上まで色々赤裸になったという見方もあるかも。民間だったらもっとなし崩し的に炎上プロジェクトを続行するケースが多いように思う。
もうね、
ＴＳＯＬによる設計作業は ，平成１８年当初６０人体制でプロジェクトをスタートさせたが，翌年初めには遅延が 始まったため，順次増員を行い，同１９年３月には２００人，同年５月には４５０人体制とした。
(((( ；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
ＴＳＯＬは ，工程の遅れの解消に向けて，大幅な人員の増強でこれに対処しようとし，平成２０年１１月以降に は １３００人もの体制を整えたが
(((( ；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
あたりまえのこと。TSOLでも仕様をしっかり理解してる人は少数だったのに、増員の9割は下請けだったのだから、さらに破滅の様相が想像できるってものだよ。
大量の下請け同士の連携や情報共有がされていなかった。経験やノウハウの共有がなされていなかった。と報告書にある。なんでこうなっちゃうんだろうな。何のためのプロジェクト管理なんだろ。ノウハウの管理はもっと意識されるべきだよ。
人数増やしてプロジェクトが炎上するというのは、お約束すぎる。規模の大小や分野にかかわらず、開発をやった事のある人ならわかると思う。
開発や設計って？という人にもわかりやすいように説明する。
例えば、優れた売れっ子のマンガ家がいて、老練な担当者がついていて、名アシスタントがいて、才能ある若手アシスタントがいて、10人のチームでマンガを描いていたとしよう。一方、大して技術もない凡人を100人集めて、前出のチームと同じマンガができるとかと聞かれたらどう思うだろう？殆どの人はそれは無理じゃない？と思うだろう。1000人でも無理かもしれない。
開発も同じなんだよ、本質的にはね。
でもそう思われにくいのはなんでだろう？それは多分、開発に従事する人にはマンガ家のような才能や際立った技術は必要ないと思われてるからだ。言われた所を言われたようにベタを塗るだけがプログラマの仕事だと思われているからだ。実際それをプログラマなのだと定義している会社もある。技術はお金にならない低俗なものだという偏ったイメージもこの世界には蔓延している。それが上流偏重の問題なんだ。
売れっ子のマンガ家のような設計(マンガで言えばネームや原作)からプログラミングまでこなせる技術者、老練な担当者のようなプロジェクトマネージャ、名アシスタントのような匠のプログラマ、勉強熱心な技術者は実際に存在してる。並以下の人材を倍集めたって100人集めたって彼らと同じものができるわけじゃない。
でも、どんなプロジェクトにもそんなスター的な人材が確保できるとはいえないし、単純な増員で対応できるようにする必要が、日本の大きな会社や大きなプロジェクトではあった。それを可能にするのが分業化だ。工程を徹底的に分業化することで、末端のセクションの習得コストを出来る限り低くし、品質の維持も図る。言い方を変えれば、創作を出来る限り製造にするということ。
それによるデメリットは明確だよね。新しいアイデアが実現されにくくなる。時代の流れの速さに追いついていけない。個々の持っているスキルが生かされない、技術が評価されない。技術者のモチベーションが下がる。なにより、正しい分業化とマネージメントが行われずに盲目的に人数を増やすと、ただただ炎上にしかならないってこと。お金だけが莫大にかかっていくということ。
これは間違いない。
このまま続けていたら、沢山の技術者の尊い人生がデスマに捧げられただろう。数年間のどろどろの煮詰まった成果物は、黒歴史を語るまいとひた隠しに、更なる問題を生み出しながら使われ続けただろう。考えただけで悪夢だ。
このプロジェクトのやりなおしに、どれだけ前回の経験が生かされるのか、そこにこそ注目していきたいと思う。
時間ができたら後で読む
http://www.jpo.go.jp/torikumi/system/system_optimize_re.htm
実際の業務の内容がある
http://myatsumoto.hatenablog.com/entry/2012/01/26/082554 良いまとめ
価格決定権を出版社がカルテルで維持できないってのが最大の問題だと思うんだよね。
今までがいかに出版社にとって「恵まれた」環境であったのかがわかる。
小売店としてはまともな作品がまともな価格で、まともな数、リスクなく販売できる。
編集者は、作家と編集者の協力体制で作品を作っていくことができる。作者の数だけ編集も存在できる。
作家としてはまともな作家は、作品を書いてるだけでメシが食える。
（漫画家はぎりぎりの人も多いらしいけど、それでもアシスタントに金払ってなお、作品に専念できる）
それぞれ不満もあったろうけれど、とてもとてもいい環境だった。
電子書籍になったら、多分全部崩れる。 特定のタイプの人間しか生き残れなくなる。
特にitune storeやAndroid shopでの電子書籍での売り方を見てたら、こんなんで勝負できるか、と思ってしまう。
まず小売が死んじゃう。
今のところ、電子書籍がすごく安く提供されてるけどこれができる人って限られる。編集なんて尚更。
１「よく売れた本」「少なくとも紙で元がとれた本」でさらに利益を上積みしようというバックエンドのケース
もしドラの電子書籍版とか、女医セックスとか。ある程度価格を強めに設定できるけどそれでも書籍の半額以下。
２ 無名な人や、バックエンド商品を持ってる人が無料に近いダンピング価格で客をつかむケース。
最初から自分の本をフロントエンドと位置づけていて、安くても自分の本を手にとってもらって次回作以降に続けようとしてる。
フォレ○ト出版なんかで書いてた著者は、もともと本なんてただの客寄せです、って感じなのでどんどんこのパターン遣うんだろうけどね。
３ まともな価格で売れるのは、高田純次などの有名人が手慰み的にやってる場合。これだってバカ売れしたのはダンピングのおかげ。
平安時代じゃあるまいし、吉田兼好とか紫式部みたいな、宮廷生活で生活が保障されている人以外は本かけませんってんじゃ困る。
４ 作者自身のキャラクターが受けるなど、作品以外の商品展開が可能な場合
今はまだないけど、AKBのメンツが本を書くのもよし、ラノベがキャラクターアプリ販売とかと連携するもよし。
っていうか基本的に、なんかとのタイアップが前提であったり、「合同企画本」みたいなのがワラワラ出てくる気がするんだよね・・・。
ネットだと「小説家になろう」とか、ケータイ小説だと無数のサイトが展開されたみたいに
基本無料で読み放題のサイトがまぁスマホ最適化された形で提供化されるんだろうなぁ。
そんで人気が出たやつだけパッケージ化されて売れる、と。
ただこれだとバカ売れ作品ってのはそうそうでないと思う。 あと「王様ゲーム」糞すぎ氏ね。
１から５のドこに編集が生きる道があるんだろう。５をパッケージ化するところくらい？
編集さんってどういう所で頑張ってたんだろう。編集者ってどのくらい必要なんだろう。
「修正が聞かない本というパッケージ」において、ミスなく作品を世に送り出すため？
問題があったら後から直せばいいって考えたら、パッケージそのものに価値が認められないなら、
まともな作家がまともな価格で、かつ電子書籍ならではのギミックを搭載してチャレンジしたケースだと村上龍があるけど、
同じ価格だったら本のほうがよく売れた、というのも興味深いところだよね。
いやまぁ全部音楽業界ですでに言われてることだから今更感はあるけれど、
音楽は急激な変化に耐え切れず「今までだったらやっていけた層」が駆逐されて、
そこをAKB48やテレビ番組やアニメプロデュースのユニットが吸収しちゃってるってのがなんだか悲しいなーと思うのね。
というわけで結論なし。ここまで書いてるうちに出版するってどういうことなんだろうってことを全く知らないことに気づいた。
特に「編集者の仕事って何だろう」ってのが気になってきた。あれこれ読みます。
http://anond.hatelabo.jp/20111223110147
今でもごく一握りなのかもしれないけれど、すくなくとも数字的にみれば約３万人の作家がいるわけよね。多いと思うんだ。多すぎる。
「多すぎる作家の中で食っていける作家が一握り」というよりも、私が強調したいのは「現在食っていけている作家が十分すぎるほど多い」ということ。
これが、電子書籍の世界では今よりもっともっと減って必要最低限を下回るのでは、私が考えるような「あんまりイラない」作家しか残らなくなるのでは、と要らぬ危惧をしてみました。
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
いやいや、日本人的等身（６等身ぐらい？今は高くなってるかも）に対してはえる服を作るのが本道で、モデル体型じゃないと映えない服ってのもなんなんだろう。
もちろん、モデルは洋服を引き立てるためのものだが、本来洋服が人間を引き立てるためのもので、であれば、最も多い等身にたいして最適化されるべきだよなぁと。と思ったと。
そして、その、メジャーではない等身向けに作られた服がはえるという体型が、モデル体型でもてはやされているのもなんだかなぁと思いました。と。こっちは、まぁ、僕の勘違いもあるけど。
本来、洋服は人のためにあるってのが、どっかに行ってるんだというを、なんか、気がついた的。
田舎の会社にも就職難なので、かなりできる若者が面接にくるようになった。
正直なところ、バブル世代など一撃必殺なくらい仕事に熱心で理解力が比類ないくらいできる。
でもね、団塊世代が抜けた後のバブリーさんたちは、いきなり入ってきた新人ができすぎて気に入らないみたいだ。
バブリーさんたちは、自分たちの理解できる範囲でしか、仕事を考えないからだ。
若い世代の市場は理解できないし、その片鱗にも及ばない。
できないことを要求するとキレる。
右肩上がりを指向していた団塊さんはまだよかった。世代全体で未来が見えていたからだ。
新陳代謝が進まない社会は、全体の最適化にとって最悪の展開だ。
新しいことにチャレンジせずに地位と給料を守ろうとするバブリーさんたちに早く引退してもらわないと、どうにもならない世の中なのに定年延長でこの傾向は止まらない。
若い人は、このトンチンカンなバブル上司に嫌気がさして、1～2年で辞めていく。
新人2～3人分の給料をもらっている人をなんとかしないと世の中回らないないのにね。
面接にきたできる子たちにチャンスすら与えないままお祈りメールを送るのは気の毒だ。内需産業は日本中こんな感じなのかなと思ったお話でした。
そんじゃーね。
2010/05/16 23:40
こんにちは。昨日会った者です（これで特定するには情報不足だけど、まあわかるよね）。
で「幅優先探索でやる」という方針自体はいいと思うし、データ構造の作り方も基本は押さえていると思います（斜め読みしかしてませんが）。
ただ、コーディングの発想が「C で作る」という大方針から見て、少しちぐはぐな印象も受けます。データ構造の設計や操作の部分、汎用のライブラリを作ろうというのならあれでもいいと思うのですが、わざわざ汎用のライブラリを使わずに自分で専用の道具を一から作ろうというのなら、問題の性質を考慮して能率良くやることが大事です。
ところが、ここに載っているコードを見ると、見かけが C らしくなく、C++ や Java の劣化版のような印象を受けます。記法（マクロを大文字化しない、ルーチン名を大文字で始めるなど）だけの問題ではなく、データ構造の設計思想が「C で書く」という方針と矛盾しているように見えます。
もう少し具体的に言うと、そもそも C というのは現在 Web 系の世界などで流行のスクリプト言語類とは逆で、汎用言語でありながら低レベル（ハードウェアに近い）処理が簡単にできることに特色があります。つまり、組み込みを想定してプラットフォーム非依存のコードを書いたり、ハードウェアの特性を考慮して低レベルな最適化をやりたいというときに適しています。
そこでこの問題ですが、これを C でやるということは、処理速度や使用メモリ量の最適化が要求される状況、つまり迷路の大きさが途方もなく大きいような状況を想定すべきです。もっと言ってしまえばこの問題、たとえば画像処理などで似たような発想が要求されることがあります。このため、どうすれば時間のかかる処理を切りつめることができるかを考えてやらねばなりません。
このプログラムの場合、時間のかかる処理の代表格である malloc() が大量に使われています。これはいかにもまずいです。このような大量データを処理する場合の定石は、あらかじめ必要なだけメモリを確保しておいて、自分で割り当てることです。具体的には、必要と想定される量だけメモリを配列の形でどかっと確保しておいて、配列のインデックスをポインタ代わりに使います。そして、足りなくなったら倍々のような感じでメモリを realloc() してやればよいのです。
なお、そのような観点で言って、木の各節点の子の数は高々 4 （スタート地点が内点でないとすれば 3）であることを使っていることはよいと思います。ここで「子のリスト」とかを作ってしまっていたらこれはもうアホもいいところですから（容量の節約にすらなりません）。
そんな感じでしょうか。
とにかく、この手の問題は、アルゴリズムさえわかっていれば可読性もヘッタクレもないので、「短く書く」というような表層的なことよりも、何が求められているのかをよく考えて、柔軟に設計思想を考えることが大事だと思います。
2010/05/17 13:54
Oさんですね。専門的なコメントありがとうございます！cで書くと言いつつObjective-Cっぽい発想で書いていました。マクロの命名もその影響で、関数はImage Magickなどに似た命名規則になっている気がします。mallocを使いすぎると時間がかかるということは全然意識していませんでした。今度作るときはメモリ管理を自前で用意する発想を取り入れてみたいです。参考になるコメントありがとうございました！
自動車産業が抱える問題って、現在の日本の置かれた状況を象徴するものだよなぁ、と思い、少し掘り下げて考えてみた。「推測」と書いたのは、バックデータ・統計資料にわざわざ時間をかけてあたる暇はないので、状況証拠だけで考えていくということだ。暇な人、もしくは自動車産業関係者のマーケターの方、もしくはマクロ経済の専門家様、データを元にこの推測、といいますか仮説を検証してみてくださいませ。
「自動車の国内市場規模は縮小の一途。特に若者がクルマに興味を持ってくれない。」というのが、業界的に広く共有された悩みのよう。その典型的な事象の捉え方が痛いニュースのこの記事。
痛いニュース(ﾉ∀`) : “若者、車離れ” 日本国内で車売れない…トヨタ、本気でアイデア募集 - ライブドアブログ
この2ちゃんねるまとめブログで、板の題材として選ばれている記事がこれ。
国内で車売れない危機打開策 トヨタ本気でアイデア募集 (1/2) : J-CASTニュース
ま、痛いニュースとJ-CASTなので、、、、、でも、こういうメディアって、一般的な状況の捉えられ方やルサンチマン的なストレスを推し量るには本当に都合がいい。でもJ-CASTの元記事にはファクトデータも載っている。ちょっと引用してみると、
国内での販売は2年連続の減少だ。ダイハツ工業、日野自動車を含めたトヨタグループ販売は前期比同4％減の227万台と、米国販売との差が広がる一方だ。国内市場全体の落ち込みより減少幅が小さかったため、トヨタのシェア（軽自動車除く）は過去最高の45.8％まで上昇したが、トヨタ車単独で11万台の減では、シェア上昇も手離しで喜べない。
国内の自動車需要（全需）は、2006年度の軽を除いた日本国内の新車販売は前年度比8.3％減の358万台と、29年ぶりの低水準だ。登録車市場の低迷の原因としては、経済性や実用性を求めて軽自動車に人気が移っている影響とされてきた。しかし、軽を加えても同4.1％減の561万台であり、国内市場全体が収縮していることが鮮明になっている。
要は、
ってこと。ちなみにこの元記事は1997年という4年前のもの。
で、その対策として当時のトヨタは、
トヨタは06年末に社内横断的なチームを立ち上げ、国内低迷脱却のアイデアを懸命に探り始めた。
対策チームは、自動車という商品の枠内だけで解答は出さず、地域や社会全体の問題の中で消費を喚起する自動車を改めて模索している。携帯電話などの情報関連の支出が増えた若者の「車離れ」や、少子化による若年人口の減少による市場構造の変化を深刻に受け止め、車が売れなくなった構造要因に真剣に目を向けざるを得ない。地域ごとの特性や家庭の年代構成、消費者の行動なども踏まえて自動車市場全体を抜本的に洗い直そうというものだ。
少子化対策は政府でも有効策を打ち出せていない難題中の難問だ。それでも、トヨタの渡辺捷昭社長は「国内市場を活性化するためには、何よりも市場創造型のいい商品を投入することだ。地域の活性化を含めて、いろんな手を打っていきたい」と、社内チームの試みに大きな期待を寄せている。
というわけで、「国内市場をどうにか活性化させるための手を打ちたいと考え、具体的なアクションを起こしている」というメッセージを打ち出したわけですね。
それに対して2ちゃんねる側の反応はだいたい2分されていて、
となっている。
で、このあと2010年になってどうなったかというと、、、、市場動向、トヨタの対応、そしてネット民wの反応がツンダオワタ情報にまとめられている。（本当は産経新聞の元記事URLを引きたかったのだが、既に削除済み。というわけで、元記事の存在証明はないところはご容赦を。（だから、論文とかでは、データとしては使えないなぁ、、、増田で使うのが精一杯。）
豊田社長｢マスコミは若者の車離れと言うが、離れているのは私達メーカーではないのか｣ - ツンダオワタ情報
まずはトヨタがどのような手を売ったのかというと、、
トヨタは今年１月に「スポーツ車両統括部」を立ち上げ、スポーツカーの企画や開発に関する最終権限を経営陣から現場に移譲。スポーツカーの復活とともに、走る楽しみを演出する複数の
プロジェクトが始動している。足回りの良さにこだわった特別仕様車を相次ぎ発売。４人乗りで世界最小の「ｉＱ」６速ＭＴ搭載限定車は予約開始から１週間で完売。
９月３日。強い日差しの下、静岡県小山町の富士スピードウェイで、１台のスポーツカーが強烈なエンジン音を響かせていた。１２月から世界限定５００台で販売が予定されている高級
スポーツカー「レクサスＬＦＡ」（価格３７５０万円）。報道関係者らを対象にした試乗会が行われていた。ＬＦＡの最高時速は３２５キロだが、この日は１周４．５キロのコースを約２分で駆け抜けた。「ハンドルを握ったときにドキドキ、ワクワクするクルマをつくりたい」自らレースにも参戦する豊田社長は常にこう言い続けてきた。
つまり、
のようにスポーツカーに活路を見出そうとしているよう。
でも、その結果は、、、、「文中の」ファクトデータを洗ってみると、、
クルマが売れない。昨年の国内新車販売台数は約４６０万台と、ピーク時（平成２年）の６割程度にまで縮小している。景気低迷が一因だが、一般的には若者のクルマ離れが最大の理由とされている。調査によると、大学生の「興味ある製品」でクルマは１７位（２０年度）と、４０～５０歳代が大学生だった当時の７位から大きく後退している。
要は、
ということ。ただし、MTのiQは限定台数を売り尽くしたし、Wikipediaの記述を見るかぎり、LFXもきちんと台数は捌けているよう。要は、「作ったクルマはちゃんと売れたけど、市場全体の構造を変えるまでに至っていない」ってことですね。それに対するネット民wの反応は、1997年の痛いニュースから、全く変わっていないというのも面白いところだ。
結局のところ、市場の縮小は人口減少トレンド下では不可避。でも、せめて若年層にクルマを運転する楽しみを知ってもらい、高付加価値のクルマを継続して買ってもらえるようにすることで、市場構造の問題を少しでも緩和したい、っていうところだと思われます。少なくとも、ここまでに取り上げた情報ソースからすると、、、、ですが。
まず、「若者」という括りに対してツッコミがあるというのは、甘んじて受け入れよう。というか、全面的に納得せざるを得ない。で、話を単純化するために、母集団を「大学生」という括りに絞ってみることにする。大学進学率が上昇し、それによって「大学生」という母集団の性質が変化したという点については、「なぜ大学進学率が50％を超えたのか？ －大学進学人口と大学数との関連－」という小樽商科大学の学報掲載記事をご覧いただければ一目瞭然。（ああ、やっと真っ当なデータリソースを挙げることができた、、、ホッ。）
であれば、「大学生」よりも、より限定した形で母集団を設定しなければ、まともな時系列比較ができない、ということになる。でも、そんな統計はまともに存在しないだろうなぁ、、、、ということで、ここからは、私の実感という超主観的な状況証拠を絡めてで話を進めたい。私は30代半ばで、某都心から５０kｍくらいにある某大学を職場とする人間だ。で、自分の周りがみんな全くクルマに興味がないかというと、そんなことはない。R32スカイラインをシートを始めとしてひたすら改造しながら乗っている先輩、フランス製オープンカーに乗る後輩、馬鹿でかいアメリカ製SUVで駅まで送ってくれた後輩、、、、普通にいる。しかし、キャンパスの周りが整備され、駐車場の確保が難しくなったなどの事情もあるのだろうが、昔はその存在を確認できた30万円で買った中古車で大学に通い、金はなくともバス／電車という公共交通機関の利用を忌避するタイプの層は、ほとんど見ることができない。つまり、エンスー、とまではいわないかもいれないが、クルマに対しそれなりのお金を費やししている層は昔も今も、少数ながら存在していて、がんばってクルマに乗ろうという層がいなくなったということになるだろう。
30万円の中古車というと、当時の車種で具体的に言えば、10年オチのファミリアハッチバックとか、カローラⅡとかですな。当然乗り心地は良くないし、内装はパットしないし、、、でも、なぜわざわざそんなクルマを乗り回していたかというと、一番大きな理由は「クルマが無ければ不便だった」ということではないかと思うのですよ。この１５年ほどで、私鉄や地下鉄の延長、新規路線開業は相次いだし、JRも湘南新宿ラインなどの直通電車をバンバン投入した。職場近辺は、１５年ほど前までは、各駅停車しか止まらない私鉄の駅までバスで１５分。都心に行くには２時間じゃ利かないという状況だった。かつ周囲には自動車工場と関連施設、更には清掃工場とかしかない、街だったわけで、、、、そりゃ、がんばってバイトして、クルマ買うよなぁ。逆に言えば、今となっては、無理してバイトしなきゃ手に入らないならクルマなんて買わずに、大学が斡旋してくれるUQ Wimaxのルータでも買って、電車の中で課題をこなしている方がよっぽど効率的だ。
これと同じ状況が広く各大学で生じている。また、首都圏・関西圏のいたる大学で、文系を中心に、バブル期に都心から30〜50km圏に新たに取得した土地に移転させた学部を、都心部の本部キャンパスに戻すというプロジェクトが進められている。というわけで、大学生の多くがクルマに乗らなくなるのは必然、というべき状況なのだ。
"Fun to Drive"というのは８０年代〜９０年代（だったかな？）にトヨタが掲げていたコーポレートスローガン、というかキャッチコピー。今あらためて読んでみると、いいキャッチコピーだなぁと。クルマを運転するのはやっぱり楽しいと思う。車高の低い、重心の位置が決まっているクルマって、運転技術が下手な人間でも、走らせるとむちゃくちゃ楽しい。（助手席に乗る人はたまったものじゃないわけだけれど、、、）研究者の職場というのは、普通のホワイトカラーと比べて圧倒的に交通の不便な場所に設置されていることが多い。大学しかり、企業や行政立の研究所しかり。将来的にそういった職場で、ある程度の期間働くことになったとしても、個人的にはクルマで通勤するのはできるだけ避けたいと思う。だって、遅刻の心配しながら朝必死に高速を飛ばしたり、長時間デスクワークした疲れた体で夜道を長時間かけて走って帰宅なんてしたくないじゃあないですか。しかも、クルマに乗っている限り、酒が飲めないというオチまでついてくる。正直、Fun to Driveを実感するきっかけが、自分に巡ってくる機会なんてめったにない。
タイトな仕事に従事する層が通勤でFun to Driveを感じるというのはかなり厳しい。逆に言えば、サボってもいい授業を沢山履修していたり、帰り道にドライブデートする機会が多い学生というのは、Fun to Driveを感じるのにものすごく最適化された生活をしているのだろう。もちろん、クルマで通うことが正当化されるような大学に通っている場合に限るわけだけれど、、、、
それ以外では、「もともと自宅に乗っていて楽しいタイプのクルマがあって」「工場勤務で工場隣接の寮に住んでいるから平日は閉じ込められている。近所にろくに店もないから、週末はクルマで遠出するのが趣味。店がないということは、そもそも他にお金の使い道もないし、、、」という人くらいなのではないかと思いますよ。
まあそれでも、ものづくりニッポンの文化として、モータリゼーションは浸透し続けるべきだし、それは可能だとおっしゃる向きもあるだろう。であれば、自動車文化先進国といわれるヨーロッパの状況を見てみたい。
ヨーロッパに行くと、日本ではあまりお目にかかれないブランドのクルマをよく見かける。SKODA、SEAT、そして９０年代には多少日本にも乗っている人がいたけれど、、、的なOPEL、LANCIAなどもまだまだ現役だ。注目したいのはSKODAとSEAT。この２つのブランドはAudi同様VOLKS WAGENの一ブランドなのである。SKODAはもともとチェコ、SEATはスペインのメーカー。それぞれVWによって買収され、現在は中〜低価格帯のラインナップを担っている。逆にVWの高級ラインがAudi。VWは、ヨーロッパで最も販売台数が多い自動車メーカーだ。ACEA - European Automobile Manufacturers' Associationの、Year 2011 by manufacturer and by vehicle category (Enlarged Europe) <※注1：エクセルファイルへのリンクです, 注2:1月〜8月までの数値>によると、メーカーとしてのシェアは23.2%。で、問題は23.2%の内訳だ。VWブランドは全体の12.3%。高級ラインのAudiは全体の5.0%、SEATが2.3%、SKODAが3.6%である。VWはフェートンやトゥアレグなどの高級車（というか、実質中身はAudi A8・Q7ね、、、）はあれど、代数的にはごく一部だろうから、23.2%のうち、15%くらいはBセグメント以下の中小型車と推測できる。そしてVWグループの低価格帯のクルマにスポーツカーは極少数だし、Golfにしても他の車種にしても、ホットバージョンのグレードは売上のほんの少しだろう。
一方、スポーツブランド、エンスーな人御用達ブランドはというと、、、ALFA ROMEOで1.0%、PORSCHEで0.3%。ボンドカーASTON MARTINもヨーロッパでは８ヶ月間で1,664台(0.0180630955651735%)しか売れていない。（これだけ売れれば十分か、、、？）ちなみにみんな大好きフェラーリは、FIATグループの中でもその他扱いされていて、数値が出されていない。っていうか、その程度のもの。ヨーロッパは階級社会が未だに色濃く残る社会なので、先祖代々馬車に乗っているような人たちが、相変わらず週末の嗜みとしてポルシェやフェラーリ、はたまたブガッティやランボルギーニなどのカロッツェリアがリリースする少数生産の高級車に乗っているのだろう。ということは、ですよ。日本においてエンスー車のみをひたすら取り上げていたCar GraphicやNaviのような雑誌がそこそこ売れ、地方自治体立の図書館に配架され、なおかつテレビ朝日系で番組まであったというのは、どう考えてもおかしい事態、なわけですね。
というと、やっぱり車の運転が「好き」っていう人はそんなにいるように思えない。バック・トゥ・ザ・フューチャーの時代から、若者の憧れはSUVだったし、トヨタがアメリカの若年層を攻略するために導入したサイオンだって、ラインナップはxB(日本名Bb)、xD(日本名ist)だし。アメリカ市場といえば、、、のホンダの戦略車種だって、ELEMENTやCR-VにMDX。ようは、SUVをカリフォルニアサーフカルチャーに振るか、ニューヨークのヒップホップカルチャーに振るか、はたまた高級志向に走るかしか、手はなかったわけで、、、、
経済成長期というのは、来年は今年よりも所得が増える人が沢山いるという状態のことだ。経済的に余裕が出来てくると、多くの人間が考えるのは生活の質的向上を図ろうというものだ。その結果、未知の様々な趣味にお金と時間を突っ込んで見ることとなる（これ、現在の中国沿海部がちょうどそういう状態）。そういった状況下で、日本のメーカーはレビン／トレノ、MR-2、CR-X、ユーノスロードスター、FTOなど低価格でかなり走りが楽しめるスポーツカーを量産してしまうことに成功してしまう。ミドシップのツーシーターが200万円台前半とか、V−Tecエンジンを積んだ2ドアホットハッチが100万円台、車の歴史から見たら、おかしいだろう！ということですよ。更にホンダビートやダイハツカプチーノ、極めつけはマツダAutozam AZ-1。軽自動車なのに、ミドシップでガルウィング。とんでもなさすぎる、、、、
で、いろいろ手を出してみるものの、そこそこ収入が安定する頃には、自分の趣味や可処分所得に見合った趣味だけに落ち着いていく。ま、もともとクルマで女の子にもてようと思えば、そこそこの外車や国産車でもレクサスになるだろう。中途半端に月3万円のローンとほぼ同額の維持費をクルマに突っ込むくらいなら、3万円を衣服費に使い、残り3万円でデートに誘う店のグレードを上げた方がよっぽどモテるだろう。結局日本という市場は、相も変わらず500万円オーバーのクルマを買い続けてくれる一部の層と、下駄として使うための安くて丈夫なクルマを選ぶ層（しかも、子育て期限定でワンボックスを買う層も多いと見た、っていうか00年代前半は、２シーター乗っていた人が、パパになってSTEPWGNやセレナに乗り換えを余儀なくされるというパターンが本当に多かったのですよ）と、クルマなんてそもそもいらないっていう多くの層によって形成されることとなる。下駄クルマは利益率は低いし、韓国・中国勢がブランド力を向上させていけば、取って代わられる事態も当然ありうる（それを日本にやられた先例がアメリカだ）。国内市場で利益をあげ続けようと思うならば、高級車のシェアを取りに行くしかない。そういう意味でトヨタはLexusを止める訳にはいかないし、他社は実質国内市場はあきらめかけているんじゃない、、、としか思えない。高級車ラインを展開できなければ、日本は欧州・アジア向けモデルを導入するone of themの市場という前提で戦略を立てざるを得ない（実際、日産、ホンダ、マツダなんかはまさしくこの戦略をとってる。マーチが全量アジアからの輸入になるなんてね、、、、）。
で、以下のURLから1本のテレビCMをご覧頂きたい。トヨタグループの一員であるダイハツの企業CMだ。
テレビCM 企業CM「日本のどこかで 新しい町」篇【ダイハツ】
このCMの読み解きは、あくまでも僕の憶測にしか過ぎないのであしからず。
都会でクリエイティブ（たぶん美容師とか、ショップ店員とかかな？）な仕事をしていた瑛太が、突如田舎にIターン（Uターン、じゃないだろうなぁ、、、）して、ガテン系（工務店）の仕事を始める。そこで、これまで乗っていたアメ車のシボレー・カマロを第三のエコカーであるダイハツの軽（ミラ・イース）に変える。生活の変化と平行して、地元の郵便局員である吹石一恵との関係が始まり、、、、というストーリーなわけだけど、設定の１つ１つに企業戦略として重要な意味合いが込められていると思うのだ。（あくまでも推測だけど、、、）
都心にはダイハツが売り込む市場など、商用車以外に大して存在しない（それでも、乳幼児を抱えるお母さんが、電車に乗れなくなったから必要に迫られて車を買うというケースは結構ある（タントのCMを参照。それにしてもダイハツのCMは、意図がすっきりはっきりして清々しいほど。マーケ的お手本ですね。）。だから、当然第一次・第二次産業（の生産部門）が経済の中心であるエリア、もっとわかりやすく言い換えると、でっかいイオンモールが唯一のデートコースという地域が、ダイハツ（とかスズキとか）の主戦場となる。
そういったエリアは、都心とは異なる理由で市場の縮小が進んでいる。まずもって、人口減少トレンドがものすごく強いということ。都心の場合出生率は下がっても、人口流入が大きいので若年層人口の減少トレンドはかなり緩和されている（というか、江東区とか、横浜市なんかは、保育園入園の待機児童問題がぜんぜん解決されないままで、、、、）。でも、地方は加速度がついて若年人口が減っているというのがまず前提となる。
その上に自動車市場を冷やす意外な要因というのが、実はイオンモールの進出ではないのかな、と個人的には睨んでいる。こう書くと、「イオンモールこそが、駅前商店街衰退の最大の要因で、だからみんなクルマを保有せざるをえないのじゃないか」というツッコミがきそうだが、たぶん逆じゃないかな、と。地方の駅前商店街なんて、もともと若年層が楽しめる娯楽や、ファッションを提供する機能を持っていなかった。だから、暇な若者に出来る時間つぶしって、女の子を誘ってドライブくらいしかなかったわけだ。例えば、９０年代にものすごく売れたホンダ・S-MX は、フルフラットシートにできるだけでなく、ご丁寧にティッシュボックスまで備え付けてある。わかりやすくニーズのど真ん中をついていたわけだ。
それが、イオンモールができることで状況は一変する。シネコンやタイトーとかセガとかの大規模ゲーセンやROUND1で時間は潰せるし、服を買うのも、ワールドやイトキン、オンワードといったアパレル大手のちょっと低価格ラインのショップ、レディースならば宮崎あおいがCMしてるEarth music & ecologyとか、OZOC、Melroseとか。メンズならTK Takeo Kikuchiとか。ユニセックス＆チャイルドで、UNIQLOに満足しない層のために、GAPとか、無印とか、COMME CA ISMとかも入っている。ＡＢＣマートがあれば、靴も含めてそんなにダサくない、というか都心で売っているものと遜色のないものが揃ってしまう。そりゃ、裏原宿のテイストは無理だけど、池袋マルイやサンシャインシティくらいのレベルは買えてしまう。片道３０分でイオンモールにつけるのであれば、その短い時間にお金をかけるよりも、一日中過ごすイオンモールの中でお金を使ったほうが楽しいわけだ。つまり、人口が少ないだけでなく、残っている若者にもクルマに必要以上にお金をつぎ込むインセンティブがもはや存在しないということだ。
じゃあ、粛々とシュリンクする市場規模に対応するだけの資源投下をすべきか、、、というとそうは問屋がおろさない。それができない要因、それは地方に数多く存在する独立資本の販売店フランチャイジーだ。バブル崩壊後、自動車メーカーはそれぞれ、ドラスティックに販売網ネットワークを整理した。今となっては複数の販売チャネルを運営しているのは、実質的にはトヨタだけになってしまった。ただし、トヨタ・日産・三菱といったメーカーの場合、販社は一部自らが出資している法人が大半であり、スムーズに（とはいかないまでも、どうにか）店舗網の縮小、合併を進めることができた。ところが、ダイハツ、スズキ、スバル、ホンダ（の旧プリモ店）は、三丁目の夕日に出てくるような個人経営の自動車整備業にフランチャイジーとして販売を委託するという形態の店舗を数多く抱える。販売店網が密だということは、アフターサービス・メンテナンスの質を向上させることにつながる。アフターサービス・メンテナンスはアフターマーケットという業界用語があるくらい、利益率の高い市場なので、各社力を入れているわけだが、サービス水準を高めるためには、各店舗の士気が高められていることが重要だ。
販社としては、生涯価値の高い顧客、つまり長くお金を落とし続けてくれる顧客を捕まえたいというニーズを持っている。となると、地方にやってきた若年層というのが、一番欲しい顧客のプロファイルとなる。地方にやってきて、工務店という地域密着な仕事をし、地元の（たぶん）特定郵便局の職員とつきあって結婚して、、、というのは、まさしく地方の販売店にとって喉から手が出るほど欲しい顧客像だといえるだろう。こういう層に向けて、ストレートに刺さるCM、というのは、ミラ・イースの本当の想定顧客かどうかは関係ない。（実際、イースの車種CMは、ブルース・ウィリスを起用してダジャレを言わせているわけだから、瑛太のようなプロフィール、ではないことは明白。）「企業ＣＭ」して瑛太と吹石一恵が出演するCMを放映するということは、メッセージのターゲットは販売店フランチャイジーなのではないかな、と。
小見出しで結論は言い切っちゃいましたが、基本はこれ。自動車メーカーもボードメンバーや車種開発部門は既にわかっていてやっているはず。じゃなきゃ、瑛太が乗るクルマはミラ・イースにならないし、マツダのスカイアクティブテクノロジ搭載車やホンダのハイブリッド車に国内独自モデルが１つもない、なんて事にもならないはず。
ところが、販売部門、とくに販社といっしょにプロモーション計画を取りまとめる部門は、国内は縮小均衡で粛々とやっていく、なんてことは口が裂けても言えないはず。なので、国内販社向けマーケティング担当者が考えるべきは、シュリンクする市場環境下で、世界共通モデルをいかに低コストでローカライズして、他者のシェアを奪うのか、しかないのが現状なのだと思いますよ。正直、ね。
これ、意図して書いたかどうかは分からんけど、結果的にすげーDISになってるよなー。
むしろ、なぜ、インターネットや書籍、インタビューという出力が完全に自分次第の媒体で、自分の良いところだけ出さないのか理解に苦しみます。
→「お前（＝ハックル、以下同様）はインターネットや書籍やインタビューで自らボロを出している！」
つまりこの言葉（註：「人間は自分が見たいと思う現実しか見ない」）はそれ自身意味のない言葉で、他人を無根拠に非難する場合にしか使えません。岩崎さんは、誰かからこの言葉を言われたんでしょうか。そういうことをいう人のいうことは気にすることはないと思います。
→「お前は他人を無根拠に避難している！」（「岩崎さんは〜」以降はハックル先生の目に入らない）
かたや、才能でのぼりつめた天才。神様に祝福された触るものが全て黄金に変わる人間。かたや、努力と承認欲求でコツコツと経験と知識を溜め４１歳にしてやっと成功した努力の人。
→「お前は天才でも何でもない！才能もない！神にも祝福されていない！」
人に対して、“終わっている”という言葉を使うとき、色々な意味があると思いますが、もう伸びシロがない、成長しない、という事で言うのなら、それは終わりではなく、完了であり、すでに最適化されてると言う事なんじゃないでしょうか。
→「お前はもう成長しない！」（「完了」「最適化」うんぬんは以下略）
例えば、岩崎さんが“俺は岩崎夏海だ！”といえば、それは本物の岩崎夏海ですし、“俺はドラッカーだ！”と言えば、それは偽物のドラッカー/岩崎夏海、であると思います。
→「お前は『ベストセラー作家』でも何でもない、ただの『岩崎夏海』だ！」
第1章 並行プログラミングとGHC (上田和紀) 1.1 はじめに 1.2 ターゲットを明確にしよう 1.3 はじめが大切 1.4 GHCが与える並行計算の枠組み 1.4.1 GHCにおける計算とは，外界との情報のやりとり(通信)である 1.4.2 計算を行う主体は，互いに，および外界と通信し合うプロセスの集まりである 1.4.3 プロセスは，停止するとは限らない 1.4.4 プロセスは，開いた系(open system)をモデル化する 1.4.5 情報とは変数と値との結付き(結合)のことである 1.4.6 プロセスは，結合の観測と生成を行う 1.4.7 プロセスは，書換え規則を用いて定義する 1.4.8 通信は，プロセス間の共有変数を用いて行う 1.4.9 外貨も，プロセスとしてモデル化される 1.4.10 通信は，非同期的である 1.4.11 プロセスのふるまいは，非決定的でありうる 1.5 もう少し具体的なパラダイム 1.5.1 ストリームと双方向通信 1.5.2 履歴のあるオブジェクトの表現 1.5.3 データ駆動計算と要求駆動計算 1.5.4 モジュラリティと差分プログラミング 1.5.5 プロセスによるデータ表現 1.6 歴史的背景と文献案内 1.7 並行プログラミングと効率 1.8 まとめ 第2章 様相論理とテンポラル・プログラミング (桜川貴司) 2.1 はじめに 2.2 様相論理 2.3 時制論理 2.4 多世界モデル 2.5 到達可能性と局所性 2.6 純論理プログラミングへ向けて 2.7 Temporal Prolog 2.8 RACCO 2.9 実現 2.10 まとめと参考文献案内 第3章 レコード・プログラミング (横田一正) 3.1 はじめに 3.2 レコードと述語の表現 3.3 レコード構造とφ-項 3.3.1 φ-項の定義 3.3.2 型の半順序と束 3.3.3 KBLとLOGIN 3.4 応用――データベースの視点から 3.4.1 演繹データベース 3.4.2 レコード・プログラミングとデータベース 3.4.3 いくつかの例 3.5 まとめ 3.6 文献案内 第4章 抽象データ型とOBJ2 (二木厚吉・中川 中) 4.1 はじめに 4.2 抽象データ型と代数型言語 4.2.1 抽象データ型 4.2.2 代数型言語 4.2.3 始代数 4.2.4 項代数 4.2.5 項書換えシステム 4.3 OBJ2 4.3.1 OBJ2の基本構造 4.3.2 モジュールの参照方法 4.3.3 混置関数記号 4.3.4 モジュールのパラメータ化 4.3.5 パラメータ化機構による高階関数の記述 4.3.6 順序ソート 4.3.7 属性つきパターンマッチング 4.3.8 評価戦略の指定 4.3.9 モジュール表現 4.4 おわりに 第5章 プログラム代数とFP (富樫 敦) 5.1 はじめに 5.2 プログラミング・システム FP 5.2.1 オブジェクト 5.2.2 基本関数 5.2.3 プログラム構成子 5.2.4 関数定義 5.2.5 FPのプログラミング・スタイル 5.3 プログラム代数 5.3.1 プログラム代数則 5.3.2 代数則の証明 5.3.3 代数則とプログラム 5.4 ラムダ計算の拡張 5.4.1 ラムダ式の拡張 5.4.2 拡張されたラムダ計算の簡約規則 5.4.3 そのほかのリスト操作用演算子 5.4.4 相互再帰的定義式 5.4.5 ストリーム(無限リスト)処理 5.5 FPプログラムの翻訳 5.5.1 オブジェクトの翻訳 5.5.2 基本関数の翻訳 5.5.3 プログラム構成子の翻訳 5.5.4 簡約規則を用いた代数則の検証 5.6 おわりに 第6章 カテゴリカル・プログラミング (横内寛文) 6.1 はじめに 6.2 値からモルフィズムへ 6.3 カテゴリカル・コンビネータ 6.3.1 ラムダ計算の意味論 6.3.2 モルフィズムによる意味論 6.3.3 カテゴリカル・コンビネータ理論CCL 6.4 関数型プログラミングへの応用 6.4.1 関数型プログラミング言語ML/O 6.4.2 CCLの拡張 6.4.3 CCLに基づいた処理系 6.4.4 公理系に基づいた最適化 6.5 まとめ 第7章 最大公約数――普遍代数，多項式イデアル，自動証明におけるユークリッドの互除法 (外山芳人) 7.1 はじめに 7.2 完備化アルゴリズム 7.2.1 グラス置換えパズル 7.2.2 リダクションシステム 7.2.3 完備なシステム 7.2.4 完備化 7.2.5 パズルの答 7.3 普遍代数における完備化アルゴリズム 7.3.1 群論の語の問題 7.3.2 群の公理の完備化 7.3.3 Knuth-Bendix完備化アルゴリズム 7.4 多項式イデアル理論における完備化アルゴリズム 7.4.1 ユークリッドの互除法 7.4.2 多項式イデアル 7.4.3 Buchbergerアルゴリズム 7.5 一階述語論理における完備化アルゴリズム 7.5.1 レゾリューション法 7.5.2 Hsiangのアイデア 7.6 おわりに 第8章 構成的プログラミング (林 晋) 8.1 構成的プログラミング？ 8.2 型付きラムダ計算 8.3 論理としての型付きラムダ計算 8.4 構成的プログラミングとは 8.5 構成的プログラミングにおける再帰呼び出し 8.6 おわりに：構成的プログラミングに未来はあるか？ 第9章 メタプログラミングとリフレクション (田中二郎) 9.1 はじめに 9.2 計算システム 9.2.1 因果結合システム 9.2.2 メタシステム 9.2.3 リフレクティブシステム 9.3 3-Lisp 9.4 リフレクティブタワー 9.5 GHCにおけるリフレクション 9.5.1 並列論理型言語GHC 9.5.2 GHCの言語仕様 9.5.3 GHCのメタインタプリタ 9.5.4 リフレクティブ述語のインプリメント 9.6 まとめ
ソーシャルゲームはイノベーション。だがイノベーションは、すべてのユーザーが接続された単一のサーバーを使う、マルチプラットフォーム、マイクロトランザクション、コレクション中心のゲーム性、ゲームマネーとリアルマネーの最小限の垣根、スマートな課金システム、ゆるやかなコミュニケーションではない。ソーシャルゲームのコア技術。だがゲームや伝統的なオンラインゲームやウェブサービスなどが実現済み。だが人類史上ソーシャルゲームだけが実現した特徴。人間とボットが混在してもボットの存在が気がつかれない革新的な環境。ボットが人間に擬態して人間とゲームをプレイしてゲームを盛り上げるSF近似の環境が実現。ソーシャルゲームではユーザー同士の人間的なコミュニケーションを極限まで減少することでこれを可能に。革新的なことにもかかわらず不思議に語られない。すごく残念に思う。私が語ろう。
#
ボットは、パソコン MMO では周知の事実で違法がはびこっている。これから話すことは少し違う。ソーシャルゲームのボットは、ゲームメーカー自身によって開発された。ボットは、普通のユーザーには区別がつかない。仲間やあなたの競争相手のいくつかはボットと考えるのは簡単。多くの人が疑問に思う。人間とボットの区別がつかないはずがない。セカンドライフとパソコンのMMOのような環境でボットが人間のフリをするのは大変困難。MMOはすべてのプレーヤーの動きをリアルタイムに見ることができる。すべてのプレイヤーがどのように動作するかを誰もが見ることができる環境では、特異な行動パターンは際立って目立つ。ほぼ同じアクションが繰り返されるならすぐにボットとわかる。ありえない動作もすぐにわかる(超高速移動、不可能なタイミングの攻撃を続ける、など)。MMOのボットのためのチートツールは不自然ではない動きの再現に苦労。NPCキャラの移動は不自然。同じ場所しか歩かない。不自然に遠回り。隙間に入って抜け出れなくなるなど。人間の操作する自然な移動は非常に困難な技術。ボットが人間とパーティを組んで行動するのは不可能。ボットは会話できない。MMOはキーボードと共にある。ゲームのチャット機能も充実。チャットをするのは当たり前。完全な無言のユーザーは不自然な存在。協調行動は全く取れない。すぐにボットが露見するであろう。
#
対照的にソーシャルゲームでは人間とボットを区別する機能が軽視。あるいは未実装。他のプレイヤーの行動は目立たない。気がつかない。他のプレイヤーにあまり興味を持たないことでボットことに気がつかない環境。他のユーザーが何をしているのか分からない。ユーザーの仲間は行動記録を閲覧できる。ユーザーと対戦したユーザーとの試合結果は見ることができる。それは非常に断片的。ボスを倒した、ダンジョンをクリアした、などの結果しかわからない。他のユーザーのプレイの状態を把握することはできない。ソーシャルゲームでは装備の着替えを繰り返しているユーザーがいても誰も気がつかない。MMOで装備の着替えを繰り返しているユーザーがいたらすごく目立つ。ソーシャルゲームでは異常な行動パターンをとっていても問題にならない。目立たない。ボットにとても都合が良い。ソーシャルゲームでは移動に必要もない。移動はリンクのクリックだけ。人間らしい移動アルゴリズムは不要。ソーシャルゲームでは会話がとても軽視。他ユーザーへのコメントや掲示板がある。しかしあまり活用されない。ゲームに協力する戦略性が必要が薄いため。またキーボードが使えない。ずっと無言のユーザーも珍しくない。会話がとても少ない。ボットの理想的環境。ソーシャルゲームは最低限のコミュニケーションで成り立つことに最適化。それは同時にボットが人間に擬態することにも最適化。結果的にボットが人間に擬態できる環境が生まれている。結論。リンクをランダムクリックするだけでもボットが完成。それは不自然なゲームプレイが予想される。だが他ユーザーは気がつかないであろう。
#
ボットを活用しているのは違法ユーザーではない。ゲームの開発会社が用意している。運営している。言い換えればハック不要。無制限にデータベースへのアクセスが可能。実際にゲームを操作する必要ない。データベースに記録を行えば良い。SQLだけでボットを作ることが出来る。例えば、"ナンバーワンのユーザーの敗北を増やす"SQLの次の2行で実現することができます。余談。MySQLのサブクエリ限界は非常に気に入らない。「SELECT userid FROM usertable ORDER BY gold DESC LIMIT 1;UPDATE usertable SET lose=lose+1 WHERE userid=xxxxxx;」これは不十分。たかだか敗北数を増やすだけ。正しくは対戦相手と対戦ログもゲームルールに合わせた形で記録。データベースに勝敗結果を記録するプログラムが必要。これはゲームのプログラムに元々存在している。流用するだけで良い。PerlやPHPで実装されているだろう。対戦結果の偽装は簡単。
#
ソーシャルゲームはSNSプロフィールページと連動。ユーザーの顔画像クリックでプロフィールページに遷移。プロフィールページの偽装が必要。プラットフォーマーは己のSNSのデータベースへのアクセスが可能。ランダム名前で自動大量生成することは容易。ボットのプロフィールページを用意することは容易。ボットユーザーは、日記を書くことなく、まったくの無言で、熱心にゲームをプレイ。そのような特徴は正規ユーザーにも珍しくなく違和感はない。参入メーカーはSNSプロフィールページを大量に作成できない。正規プロフィールページを使い回す。その場合には、ゲーム上のH氏とG氏ののSNSのプロフィールが互いにV氏で同じ人に。これは異常。しかしユーザーは他ユーザーのプロフィールの対応を全てチェックしたりしない。発見される確率はとても低い。
#
閲覧者はボット開発の容易さには納得したと信じる。まだボットの必要性と活用には納得していない。これからの話しで納得できる。
伝統的ゲームは開発者の感覚を基準にゲームバランスを決定(マーケティングの無視を意味しない)。ソーシャルゲームはユーザーアクティビティに基づいて、科学的な分析でゲームバランスへのアプローチを決定。これはユーザーアクティビティのサーバーログが蓄積されるために可能。ユーザーアクティビティの分析結果がゲームバランスに反映。例。チュートリアルの進行状況50%で停止しているユーザーが多数いるという分析結果。その箇所のチュートリアルは高い障害ことが想定される。対策。その箇所を平易に修正。その箇所を短縮。その箇所を除去、など。結果、チュートリアルの進行状況50%で停止するユーザーは激減。課金でも分析は重要。課金アイテムのバナー画像を表示する例。ランダム分割したグループAユーザとグループBユーザに別々のバナー画像を見せる。しばらく続け、結果的により課金が多いグループのバナー画像がより最適。繰り返すことでより効率的なバナー画像が完成。
#
ゲームパラメータは簡単にデータを調整できる。しかしこれは不十分。人間同士のプレイの分析に適応できない。例。「開始直後に他のユーザーと対戦し3連敗したユーザーの70%はそれ以上プレイを続けない」という分析結果があると仮定。これはゲームパラメータでは解決できない問題。開始直後のユーザーは誰もが同じ強さ。ゲーム内で最弱。パラメータの調整とは別問題。解決策はボットの利用。開始直後のユーザーより弱いボットを用意。開始直後のユーザーはボットに優先的にマッチング。ボットの内部パラメータは開始直後ユーザー以下だかユーザーにはユーザーと同程度のパラメータに見せる。ユーザーは確実に勝利できるので3連敗してゲームを辞めてしまう可能性は激減。またユーザーは自分と同程度のパラメータの相手に勝利したと信じている。プレイを継続するモチベーションに繋がる。ソーシャルゲームプレイ中の人は確認推奨。理論上ユーザー全体の対戦での勝利数と敗北数は一致。上位のユーザーは勝利数のほうが多く下位のユーザーは敗北数が多い。コアユーザーでないのなら敗北数が多いのが正しい。もしもあなたが下位ユーザーにもかかわらず勝利数のほうが多いのであればあなたはボットに感謝する必要がある。逆の例:ロンチ直後のランキング上位にはボットを置く。それがないと初期ユーザーはすぐ上位到達。同ボットはゲーム人口が大幅に増加したら不要になることがおおい。
#
課金でも分析結果にボットを適用するのは重要。例。「課金未経験でしばらく連勝を続け宝物のコンプリートまであとわずかのユーザーに突然強力な一人のユーザーが連日攻撃し続け宝物を奪いにきたときユーザーは課金アイテムを購入して防衛する可能性が高い」という分析結果があると仮定。ユーザー心理は、今をしのげば他ユーザーには連勝を続けられると考える。今だけでもと課金を行う。これを再現するボットの開発は容易。データベースを検索して課金未経験でしばらく連勝を続け宝物のコンプリートまであとわずかのユーザーを発見。そのユーザーと対戦可能で勝利できるパラメータのボットを検索。ボットは前もって様々なパラメータで大量に用意しておくのは当たり前。発見したボットでユーザーと対戦し対戦結果をボットの勝利でデータベースに書きこむ。これでユーザーが課金する確率が飛躍的に高まる。課金未経験ユーザーに課金を経験させることは実に重要。一度同様のボットプログラムを開発したら後は全自動で継続的に動作するのは当たり前。分析とボットの組み合わせアプローチ。日本ソーシャルゲームの驚異的課金率の施策の1つ。
#
このようなパターンはユーザーアクティビティを分析することで無限に発見することが可能。ゲームの盛り上げと収益の最大化に大きく貢献。あと1つ例を。課金未経験ゆったりプレイユーザーにボットが仲間申請。ボットはゲームを情熱的にプレイ。課金も積極活用。仲間ゆったりユーザーにボットのプレイ結果がどんどん伝わる。多くのソーシャルゲームでは仲間のプレイ状況は断片的にユーザーに知らされる。中のプレイ状況は大きな刺激。仲間に影響されてよりプレイが活発に。「ユーザーのプレイ頻度は一番プレイが頻繁な仲間のプレイに近づいていく」分析結果への対応。地味であり効果は直接でないが確実にある。ボット数の効率化の観点から、1つのボットで100人以上のユーザーと仲間になるのが望ましい。ゲーム内の仲間人数制限をボットに限り解除。ユーザーがボットのプロフィールを見たときにボットことが露見すると冷めてしまう。表向きは仲間人数制限を解除していることが露見しないように。
#
伝統的なRPGゲームではユーザーの進捗状況に応じて十分な強度の仲間と敵を提供します。これとソーシャルゲームのボットは近似している。ユーザーモチベーションを上げるのが目的のは同じ。RPGのモンスターと敵はユーザーもコンピュータのAIの操作ことを知っている。それでも十分楽しいが。しかしそれが人間ならもっと楽しい。そこでMMO。しかし人間は己もプレイヤー。ユーザーに合わせて適度なパラメーターで楽しさを演出などしない。そこで人間に擬態したボット。ユーザーに合わせてゲームを盛り上げる。ユーザーは人間だと信じているのでモチベーションも最高に。あらゆるゲームの問題点が完璧に解決されている。ボットの役目はユーザーの退屈に刺激を与えること。ゲームがボットだらけ必要はない。賢いボット利用を。このようなボット効果はソーシャルゲームのユーザー間のバランスを調整しモチベーションを維持するために非常に大きいです。ボットはほとんど話題にされない。技術情報に積極的な企業もボットは不思議と話題にしない。結果。ソーシャルゲーム開発会社も知らないところが多い。ボットを利用するソーシャルゲームはむしろ少数派。ゲームパラメータ調整だけでは限界がある。ユーザーアクティビティのログ解析はハイレベルだが本当に重要です。ログの分析に基づいてボットが適切なアクションを残すことでユーザーを興奮させるのでゲームに活用してください。また歴史の人間とコンピュータの黎明期以来、初めてボットと人間の見分けがつかない世界の技術革新を達成したことに多くの技術系ユーザーは興味を抱くであろう。ソーシャルゲーム会社は技術者を積極採用中。その一端はより優れたボット開発。興味があるなら是非応募を。ソーシャルゲームの一層の発展を願う。
#
RubyのSymbolと文字列の違いを研究室の輪講用に書いたのですが，折角なので公開したいと思います．
元々学部生に対する輪講用に書いた物なので，若干上から目線ですがご了承ください．
文字列とSymbolはよく似ています．プログラマから見ればどちらも文字列です．違いを一言で説明すると『プログラムが扱う』文字列か，『プログラマが見る』文字列かの違いです．例えば変数名は『文字列』ですが，rubyのオブジェクトである『文字列』ではないですよね？
例えば，今あなたがC言語でお絵描きライブラリを作っているとしましょう．その中に，色で塗りつぶすfillという関数があり，色を青・赤・緑の3色から選べ，fillの引数でそれを指定できるとしましょう．
fillの引数の設定方法として一番単純なのが，0を青，1を赤，2を緑として，0〜2で選択させる方法でしょう．しかし，それでは，どの数値が何色か覚えないといけないし，fill関数を知らない人から見れば，どういう意味の引数かすらさっぱり分かりません．
ではどうするかと言えば，普通はBLUE = 0, RED = 1, GREEN = 2と適当に定数を設定して，その定数を引数で指定させますよね．
こうして，fill関数の引数が意味の無い数値から意味のある文字列に変わったことによってプログラムが分かりやすい物となります．さて，ここで注意してほしいのは，ここで言う文字列はプログラムが扱うオブジェクトとしての文字列では無いということです．fill関数の引数として，"BLUE"，"RED"， "GREEN"などとC言語の文字列を渡すということは普通しませんよね．それは，ここで言う文字列は，あくまでプログラマがプログラムコードを分かりやすくするために必要な文字列であって，プログラムがオブジェクトとして扱う（例えば，長さを求めるとかする）文字列ではないからです．
分かってきたでしょうか？
プログラムコード上では（つまりプログラマから見れば）どちらも同じ文字列（文字の列という意味で）ですが，実際に動くプログラムから見れば単なる数値と本物の文字列という大きな違いです．結局，fill関数の引数の具体的な値は何でもいいわけです．プログラマから見て文字列であればそれだけでよく，プログラムが動くときの実際のその中身は何でもいいわけです．これのために存在するのが，Symbolであり，:fooとひとたびSymbolを作成すれば:fooの実態は適当な数値となります．（この数値がいくらかなんていうことはもちろん気にする必要はありません）
そして，もちろん同じプログラム上では:foo == :fooはちゃんと成り立ちます．もうここまでくれば，Hashのkeyとして文字列でなくSymbolを使う理由が分かりますね．Hashのkeyはあくまで，プログラマが見る（プログラムコードを分かりやすくするための）文字列であってプログラムが扱うオブジェクトとしての文字列では無くて，keyの実際の値は何でもいい，からですね．（特別な場合を除いて）Hashのkeyに対してrubyのStringのメソッドを使うなんてことは無いですよね．
しかし，他の軽量言語ではSymbolなどなくHashのkeyとして普通に文字列を使うことが多いです．では，なぜrubyだけSymbolを使うのでしょうか．
その答えは一言でいうと，rubyの（プログラムコード上に直接書かれた，つまりリテラルの）文字列は他の言語と違いimmutable(不変)でない，からです．実際，pythonやjavascriptの文字列(リテラル)は破壊的に変更することはできませんが，rubyの文字列は破壊的に変更することができます． （'abc'.concat('d')の様に）
これがどういう違いを生むかというと，コード上に直接現れる文字列がimmutable(不変)であるならば，実行時に一つだけそのオブジェクトを作成し，後はそれを使いまわすという最適化ができます．
そうした時，Hashのkeyの様なプログラマから見た文字列というのは，プログラムコード上のリテラルとして現れるわけですが，これらは実行時に一つだけオブジェクトが作成され（特にコード上に現れる同じ文字列は全て一つのオブジェクトにまとめると），それらの比較はそれらに対する参照（そしてこれは大抵メモリのアドレスなど単なる数値）の比較で済むので，結局Symbolと同じ様な働きをするわけです．
本当はプログラマが見るためだけの文字列だけど，それをオブジェクトとしての文字列としても，Symbolと同じ様な働き，パフォーマンスが得られるならば，別にオブジェクトとしての文字列であってもいいわけです．
繰り返しになりますが，プログラマが見るためだけの文字列は，その中身・実態は何でもいいわけですが，その実態がオブジェクトとしての文字列でも十分なパフォーマンスが得られるならば，別にオブジェクトとしての文字列でもいいわけです．
さて，rubyに話を戻しますと，rubyはコード上に現れる文字列であっても，実行時にそのコードを通る度に毎回新たな文字列オブジェクトを作成します．
（以下のプログラムを動かすことで確認できる．）
def foo 'foo'.object_id end p foo, foo
つまり，rubyでは文字列が可変であるため，先に述べたような最適化ができない（または難しい）ので毎回新たな文字列オブジェクトが作成されるのです．
こうなると，先ほどの話とはうってかわって，プログラマが見る文字列はその実態は何でもいいのに，それを文字列リテラル（rubyのオブジェクトとしての文字列）にしてしまうと，毎回毎回文字列オブジェクトが作成されてしまうという非常にばかばかしい状況になってしまいます．我々はそれらの文字列オブジェクトに文字列としての操作は一切施さないのにも関わらず，です．
こういうわけで，rubyではプログラマが見るためだけの文字列にSymbolというruby特有のものを使うのです．
もちろん，プログラマが見るためだけの文字列を全て定数として（そしてもちろん中身は適当な値で）定義しても構わないわけですが，Hashのkeyとかで数多くのプログラマが見るためだけの文字列が現れることを考えると，とてもじゃないですけどそんなことは面倒でやってられないですよね．ですので，実行時に自動で適当な値にしてくれるSymbolというものが存在するのです．
以上で，Symbolについての説明を終えます．以下は蛇足です．
最初の方で出てきたfill関数をrubyで実装しようとしたとき，青・赤・緑の各色はその実際の値はなんでもいいのでrubyのSymbolを使って:blue, :red, :greenとしてもいいのですが，ライブラリとかでは大抵ちゃんと定数として定義されていることが多いです．
これは恐らく，定数として明示的に定義することで値の存在を明示でき，ドキュメント化の際にも役立つことによっているのでしょう．
しかし，あくまでこれは外部に公開するようなライブラリでの話であって，自分が使うちょっとしたプログラムならこういう場面でも精力的にSymbolを使っていってもいいと思います．ちなみに，僕ならSymbolを使います．
Symbolだと定義もいりませんし，定数は大文字ですから打つのが面倒ですし，あまりソースに大文字が入ると見た目がすっきりしません（主観）．
Symbolは非常に便利なものですので，その意義・用途を十分に理解して，Hashのkeyにとどまらず様々な所で使えるようになりましょう．
と思ってはや5年
あの子にフラれたおかげで、自分の至らないところを多々発見できた。
それを克服するためにカウンセリングに行ったり、自己啓発系の研修に参加したり、いろいろな本を読んで学習したりした。
あの子に出会った頃の自分は成長を諦めていたが、あの子のお陰でその短所を直したり受け入れたり、また長所を実感したり伸ばすことができた。
それによって成長を実感でき、今でも成長している自分が楽しくなっている。
特に覚えた事をあの子や自分に当てはめ、何度もシミュレーションを繰り返したのは学習に非常に役立った。
先日参加した婚活イベントでは参加した男20人の中で1番人気の評価ももらった。
何人ともつきあったし、逆プロポーズもされた(断ったけど)
今の俺なら当時のあの子を優しく癒せるようになった。
でももう二度と会うことはないんだろうな。
今の課題はあの子用に最適化された俺を、汎化するためにいろいろ埋める作業をすること。
2年前にした時は1ヶ月間抜け殻になった。
その時は偶然(こちらを認識しない状態で)あの子に遭遇して復活できた。
（つーかそんな確率でご褒美与えられたら依存症になっちまう・・・）
今回こそはともこちゃんを乗り越えたい。
その生き方って気持ちいいの？
それって疲れない？
それをハックするのが、「ライフハック」ってことだよ。
人生の定義自体をハックするんだよ。人生自体をハックするんだよ。
その前提をハックしないで、「人生の目的＝子孫を繁栄させること」って簡単に前提条件を受け入れちゃうの？
それってニヒリズムを絶対どこかで招くよ。
だって子孫を繁栄させることなんて、人生の目的として実感としてモチベーションにつながらないじゃん。
漠然と幸せにいきれたらなーって考えるか、徹底的に考えてニヒリズムを打破するか、どっちかしかないよ。
実感が大事なんだよ。
「Don't think, Feel」って状態にどうやって持っていくかってことなんだよ。
馬渕教室、新生ホームサービス株式会社、日本eリモデルなどのSEOを担当していると思われる株式会社マイスタンダード（代表取締役 武智建樹）は、ブラックな企業らしいです。
日本のブラックハットSEO会社一覧に株式会社マイスタンダードが掲載されています。
インデックス削除URL タイトル サービス名称 会社名 代表者名 住所 備考 http://www.seo-rankup.com/otameshi.html 業界最安値！関連検索ワード削除１キーワード１万円 関連検索ワード削除 お試しプラン 株式会社マイスタンダード 武智建樹 大阪府大阪市淀川区西中島7-7-3-702
ブラックハットSEOとは、SEO（検索エンジン最適化）における用語で、悪質な（非倫理的な）手法を駆使して検索結果ページ（SERP）の上位に表示させる技術または施策のことである。
ブラックハットSEOの典型的な手法としては、ユーザーに気づかれないようにWebページ内にSEO目的のキーワードを大量に埋め込んだり、ユーザーがアクセスしてきた際にWebクローラが巡回したWebページとは異なるWebページを表示させるような仕組みを埋め込んだり、コメントスパムなどの強引な手法で大量のバックリンクを獲得しようとしたりする方法がある。検索エンジンの多くはこうした手法はポリシーに反するものとしており、通常は何らかのペナルティが課されるが、悪質なWebサイトと判断されず検索結果ページの上位に表示される場合がある。
http://www.sophia-it.com/content/%E3%83%96%E3%83%A9%E3%83%83%E3%82%AF%E3%83%8F%E3%83%83%E3%83%88SEO