  |
はてなキーワード: フルスクラッチとは
malaは最近セキュリティのことばかりやっているが、元々はインターフェースの人だった。彼は最速インターフェース研究会というブログで名を馳せたのだし、代表作のlivedoor Readerはインターフェースこそが素晴らしかったのだし、そういえば「インターフェースエンジニア」を名乗っていた。
おそらくmalaはインターフェースに対してまだ未練があるはずだ。口では「今はセキュリティこそが大事なんだ。なぜならセキュリティこそがコンピュータにおける批評行為なんだ」と言っているが、実際には何らかの理由でインターフェースから足を洗ったのだろう。忸怩たる思いがあるのだろう。心中察する。
今、日本で最もインターフェースの革新に挑戦しているのは誰か。間違いなくshi3z氏その人である。普通だったら、新しいインターフェースを作ろうとしたらWebサービスや、今だったらスマホアプリを作るだろう。それが普通の発想だ。しかし彼は違った。ハードウェアをゼロから作ってしまった。OSもフルスクラッチで作ってしまった。なければ作ればいいじゃない。完全なるDIYの精神だ。もはやアメリカの建国精神のようですらある。
そしてmalaは今、手を持て余している。足踏み状態が続いている。ライブドアはなくなった。ライブドアという会社は賛否のある会社だったが、エンジニアを大事にする企業という意味では一目置かれていた。そもそも創業者のホリエモンの「少しでも速いWebサービスを作れ」という哲学が後にlivedoor Readeの成功に結びついた。しかしライブドアは今はもう無い。確かにLINE株式会社は素晴らしい。だがあまりにも大衆の方を向き過ぎではないだろうか。LINEやNAVERまとめは、どちらかというとmalaが毛嫌いしていたサイバーエージェント寄りの路線のような気がする。それより、malaはハッカー用のツールが作りたい。
livedoor Readeは日本中のハッカー達に使われている。そしてenchantMOONもハッカーによるハッカーのためのハードウェアだ。それなら、malaがenchantMOONの開発に合流しない理由はない。malaならそのまっ更な地平に、創造的なインターフェースを作れるはずだ。malaの第二の冒険はここから始まるんだ。
興味深い研究ですね。
大規模化していくと、（複雑すぎて）設計図通りに出来ない奴が増える。
これは別に大規模にしようがしまいが、設計図の請け負うべき部分の大きさによるでしょ。
むしろ、大きな全体の小さなモジュール1つであれば、それ自体の中で確実にメモリ作業を閉じる様な設計にしておけば
良いわけで、
勿論、それが全体の設計と合わせて大変な事は分かるけど、
大規模化していくには必要な事で、その辺は上の設計の腕の見せ所でもあるでしょう。
ん〜、って言っても、フルスクラッチったってさ、全てが全て、"新しい"わけじゃないでしょ？
結局今までにある何らかのシステムのコピー的な部分は絶対にあるわけで、
逆に今までにある資産を一切使わずに作る、ってのは単なる趣味で仕事としては効率悪すぎるわけで。
これは単に納期や見積もりが甘いだけなんだから、かっこつけて文句いうところじゃないでしょ？
勿論、現場の人間が期限決めてるわけじゃないからそれに合わせてやってる俺らは凄い、って言いたいのは分かるけど、
つまりはそういった体力勝負でやってる、ってことは、これまで土方で体力だけで仕事もらってきた人間と何も変わらない、ってことだよ。
むしろ、土方のあんちゃんとかは、欝になりました、辞めます、なんて簡単に言わないからよっぽどちゃんとしてると思うけどね。
単に回すだけの資金が無いだけなのに、そういうこと言わないの。
使う側からすると、徹夜しなければ作れないレベルの会社に出すことがデスマーチの原因だ。 検品するコストや結合テストをするコストは０じゃない。
大規模化していくと、（複雑すぎて）設計図通りに出来ない奴が増える。
バグをバグで直しておいて（つまりたまたま通っているだけで、条件を変えるとまたバグる）治りました。という人が異常に多い。
とくにメモリ破壊エラーとかは、通常のやつに作れても、治せない。
ようするに、作ってるんじゃなくて、破壊してる奴が多い。
メンテナンスならともかく、フルスクラッチに近い仕事は少数精鋭で作るしか無い。
それを経験すると、そもそも、（難しい部品の）設計図を回さないって事が始まる。
昔は、それでも、子会社を喰わせるために、簡単な部品の設計図だけを下請けに回してたけど、
今後はそういうのは無くなっていくだろ。
使う側からすると、徹夜しなければ作れないレベルの会社に出すことがデスマーチの原因だ。 検品するコストや結合テストをするコストは０じゃない。
コンセプト指向を明確に持っていたのにどうしてこうなっちゃったんだろう。
特にPS3。PS4になって単なるゲームのコンソール機に退化しちゃったって感じ。
さらに3D-GUI(XMBの進化系)を前提にしてフルスクラッチで作成したプログラムを使えば、
糞プログラムでは、考えられないほどの
快適性と効率が得られるようになるよ。
お前らもなんだかんだ言って、今使ってるパソコンを捨てて
まあ見てなって。
もう一生来ないよ。その役目は世界的にはXbox Oneが引き継いじゃったみたい。
出遅れたWPとWindows8を推進しようと、Microsoftは統合するためもっと積極的に動くだろう。
スマホが普及してPCの販売台数が落ちている今、このコンセプトは
現行世代が登場した頃よりもずっと受け入れられやすい下地ができてるかもね。
http://www.yamdas.org/column/technique/hatenablog.html
なお、タイトルに PART I とあるが、このネーミングはメル・ブルックスの『珍説世界史 PART I』にちなんだもので、PART II 以降は存在しない。つまり、あなた（ソフトウェア企業）が絶対すべきでないことは、Joel Spolsky にとってこの文章に書かれることだけなのだ。それは何か？
まぁ、そんなわけないんだけどね。
「最近のはてなの体たらくへの失望感に名前を付けたい」というだけの文章にマジレスするのも我ながらどうかと思うし、気持ちは分からなくもないんだが、最近は「はてブ」以外全く使ってない俺でも、長年お世話になってきたはてなに対してそれなりに愛着というものがあるわけで、ディスられるばかりの流れに少しばかり反抗を試みたい。これは、それだけのエントリだ。
というわけで、以下に書くのは、技術の話でも倫理の話でもない。どうか気軽に読んでほしい。
実例を挙げる。
今やワールドワイドな影響力を持つ勝ち組ソーシャルサービスのTwitterだが、彼らは、ここ数年でバックエンドの大半をスクラッチから完全に書き換えた。しかも、RubyからJavaへと、使用言語すら変更してしまった。
http://d.hatena.ne.jp/teppei-studio/20110709/1310168002
もう一つ。Tumblrも、LAMPアーキテクチャからJVMベースへ切り替えた。その過程で、Twitterがオープンソース化した技術を取り入れたりもしている。
http://blog.kyanny.me/entry/2012/02/19/002256
『「古いコードはクズだ」というのは錯覚だ』というJoelの意見は、一面では正しいが、他の面では間違っている。なぜなら、あるソフトウェアに求められていること（要件）は、時間と共にどんどん変化するからだ。
書き直そうが、書き直すまいが、一番ダメなソフトウェアとは「ユーザの要求に応えられないソフトウェア」だ。規模や環境の変化によって古い技術の技術的限界に直面したり、ビジネス環境の変化に追随する必要が出てきたのなら、「スクラッチから書き直す」のは立派に一つの選択肢だ。
はてなダイアリーの最初のバージョンがどういうものかは俺もよく知らないが、おそらく「LAMP」がエッジなキーワードとして持て囃されていた頃に書かれたプロダクトなんじゃないかな（間違ってたら突っ込みを）。それから時代は下り、Ruby on Railsに代表されるCoCなフレームワークの登場を経て、今や大規模分散や非同期を前提としたアーキテクチャが当たり前の時代。当然改修はしているだろうけど、MySQLを職人芸で負荷分散していた時代からは大分遠いところに来たのは間違いない。
何より、はてなダイアリーといえば「はてな記法」とカスタマイズの自由度の高さがウリだったわけだが、これらの存在が、今や機能追加や改良の妨げになっているとしても不思議じゃない。
はてなブログ開発の動機として「今どきの技術で、最初からやり直す」というのがあるのは間違いないが、それは「スクラッチからの書き直し」だから悪手なのだろうか。結局のところ、レガシーコードのメンテナンスを続ける場合と比べてどちらがより低コストか、という話の結論によるとしか言えない。
はてダのソーシャル要素といえば「トラックバック」と「idコール」と「キーワードリンク」だったわけだが、全部Twitter（とTogetter）に持っていかれたよね、という話。
だから、「はてダver.2」や「ブログ2.0」を望む声が大きいのは理解できるけど、ぶっちゃけ、そんなもんに開発リソースを突っ込んでも勝ち目なんか無い。んで、それに代わるアイディアを持ってる奴はどこにもいないと。だから、既存コードの改良ではなくスクラッチから書き直し、スモールスタートでフィードバックを受けながら方向性を考えていく、という方向性はそんなに間違っていないと思う。
ただ、現状を放置すると「それTumblrでできるよ」という話にしかならん、というのはその通りで。それ以外だと、もしgithubがblogサービスを始めたりすると、かなり客を持っていかれるのではないかという予感はする。いっそのこと、Tumblrのデッドコピーから始めるのが一番早いのかもしらんね。
少し別の話を。
これは、Twitterのgithubレポジトリだ。上でも書いた通り、Twitterはサービスをスクラッチから書き換えた。で、その過程で開発した内部向けのフレームワークを、どんどんオープンソース化している。彼らが、内部の技術をきちんと体系化して再利用可能にしていることの証左と言える。
一方、はてなのgithubレポジトリ。正直、サンプルとかプラグインばかりですね、と。
色々と理由はあるんだと思うが、一つ思うのは職人芸頼りで自分たちの技術を体系化するという部分が弱いんじゃないか、ということ（はてな発のオープンソースで広く使われてるのって何かあったっけ？）。
先ほどから散々「書き直していい」と主張しているが、誰かが言っていた通り、技術の本質を捕まえきっていない状態でフルスクラッチをやっても、失敗する可能性は高い。はてなブログがどちらなのかは、中の人にしか分からないことだけど。
はてなが経営的にあまり状況がよろしくない、という推測はおそらく当たっているのではないかと思う。
タイムラインで、誰かが「まっとうな方法で収益化する方法を真面目に考えるべきだった」と言っていたのを見た。それをしていれば、今回のような事態を招くことは無かったのだろうか。
だが、「まっとうなビジネスモデル」とは何だろう。実際問題として、ここ最近成功しているネットサービスのビジネスモデルで「ターゲティング広告」と「マスなユーザベースから抽出したビッグデータを解析して売る」以外で何か有力なものはあっただろうか。FacebookにせよTwitterにせよ、収益化の原動力はユーザ行動解析だったりするわけだ（彼らがオープンソース化に積極的なのは、インフラ技術が差別化の源ではない、という面もある）。
まぁ、あとはガチャだが、どちらにせよ現状では高木先生の逆鱗に触れるようなものしかないよね。
そんなわけで、それらに代わる第四のマネタイズモデルを思いついた人は、ぜひ近藤さんに教えてあげると良いんじゃないかな。あればだけど。
今後はてながどうなるかは分からないけど、一つ希望したいことがあるとすれば、故伊藤計劃氏のダイアリーがこの先も保全されることを望みたい。
それは、エントリを全て魚拓しろ、という話ではもちろんない。彼の生前に書かれたエントリは、当時の「はてな」という生態系を構成する一部でもあるわけで、そこから切り離して文章だけをアーカイブしてもあまり意味がない。
よくあるトラブルは、 『こういうつもりじゃなかった』で何回修正させられるか？
１００回修正したら１００倍値段かかるけど？（ラフに）という話。
発注慣れしてると、発注する方が自分の希望をうまく言えるから、少ない修正回数で決められる。だから当然安い。
もちろん、ヒアリングしろよ！悟れよって話もあるが、ヒアリングしたり、悟ったりするのは硬度な技術なので技術料をいただくから高くなる。コンサル料ってやつだな。
名前が売れているところは看板守らなきゃいけないから、逃げられない。だから、まぁ ご新規さんは修正回数多めに見積もって高くなる傾向にある。
ただ、数百万持って行っても逃げる奴は逃げる。
あとよくあるのは、安い＝修正効かない。とかだな。イメージと違っても直してくんない。もしくは、修正にかねかかる。
結局、値段よりも人としての信頼関係。
あとは、フルスクラッチよりも既存のパッケージ流用とかのほうが安い。
よこから失礼。
As3なら無料のFlashDevelopで十分だよ。純正品より使える。FlexSDKも無料だから、実質無料でコンパイル環境は整う。
Adobeのやつも買ったがFlashDevelopのほうがいい。
あと、HTML5 vs Flash とかいってるけどさ、ちょっとWEBにも動きがほしいよねレベルのFlashはどうせ消えるでしょ。HTMLコーダーが食えてた時代が終わったみたいなもの。だいたい情報系の言語スキルなんて５年も持たないって。
ばかでもつかえるエディターが出ればすぐ終わるよそんなもの。HTML5もそう。
生半可な人がそこに活路をもとめて漕ぎ出したところでエディターが出るまでの寸暇のアドバンテージもない。
そんな範囲のことが飯の種になるわけないじゃなぃぃ？
誰かがつくったものを真似して、誰でもできるようなことになっちゃったら制作単価下って食い合いになって終わりさ。
Airアプリでも書けって。だいたいHTML5と比較するのにFlash語るのにAir含めないってどうかしてるよ。
ただFlexで書くならフルスクラッチでゴリゴリ書けるひとじゃないと何もできないから、組み合わせるだけのプログラミングしかできない人はまだお呼びでないだけ。しかもScriptなのにコンパイルだからネット上でナレッジシェアされないしね。
FlexはActiveXやAppletと比較するべきで、プラットホームのHTMLと比較すんのはどうなのかなと思うよ。
あと、おまえらSilverLight馬鹿にしてるけど、日本にはこれが使えるエンジニアほとんどいから結構需要あるんだぜ？
MS以外の某大手もプッシュしている。
つまり、何がいいたいかっていうと、どんな言語、ツール使おうが、その上位１０％にでも食い込んでりゃ食えるよ。
というかプログラミングの上位で食ってる人が特定の言語が使えないなんてことはないよね。
もしそう思ってるんだったら、後から来たのに悠々と追いぬかれるよ。
環境のせいにしてちゃ伸びないんだぜ。
いまいるところでまず嚢中の錐になってくだせぇ。
大学時代、研究室史上最高のプログラミング実力者と言われ、就職後も有能な技術者として褒めそやされるものだろうと考えていた。
しかし、現実はそう甘くなかった。私の職業技術者としての実力は、せいぜい同期のド素人よりはましといった程度だった。
何故こんなことになったのかというと、答えは簡単で、私は、私自身の作ったものか、私個人が気に入ったライブラリ、ルーチンしか使えないような人間だった。開発現場とは、何かを作る場所というよりは、組み立てる場所で、私にはその能力が致命的に欠けていた。
思い返せば、私は確かにライブラリを使ったことが少ない。ライブラリが出回っている分野でも、わざわざフルスクラッチで組み上げるなんてことをよくしていた。私は、多くの技術者が触れられない部分にまで触れられる自分の実力に多少の優越感を持ったものだったが、何のことはない、ただ他者の作った車輪を使いこなせず、同じ成果を得るために、二倍も三倍も時間をかけて、わざわざ不恰好な車輪から作り直していただけだった。
おそらく過去に1億回くらいは言われたことなんだろうけど、
顧客ごとにほぼフルスクラッチでシステム作り上げるなんて、どこの王族相手の商売だよと。F1かと。
その辺の普通のリーマンが「俺専用の車を新規開発してくれ。500万円で。」とか言ったら「馬鹿か？」と言って終わりだろうに。
車なんて1車種あたり開発費数百億だろ。システムなら固定資産系の費用はかからないが、それを除いたって100億くらいはかかってるだろう。
SIでそれだけの予算のプロジェクトは全体の0.0001%でもあるか？
IT技術者はプロフェッショナルじゃないとか、プロジェクト失敗率が高すぎるとか言うけど、プロの仕事に見合う対価を払える構造に全くなってないんだから、それなりの人材しか集まらないのは当たり前だろって思う。
個々人が優秀だったとしても、個々の仕事にかけられる時間や集中力が圧倒的に少ないんだからそれなりの成果しかでねーよって思う。
発注側は費用対効果計算するときにプロジェクト失敗率とかシステムの実効的な稼働率とかを考慮に入れてリアルオプションかなんかで評価してみろと言いたい。無理だろうけど。
色々、本を読んだり、試したりしているが、難しい。
今までやってきた方法論と考え方をある程度、整理するために、自分の考えを書きながらまとめていこうと思う。
議論はしたくないが（ハイ、チキンです）、ご意見をいただけると嬉しい。
正直、純文学は俺自身よく分かっていないので、エンタメ小説の話という事を前提に読んでいただければ、と思う。
まず、物語のパターンに対する有名な言説として、『村上龍の「穴に落ちた主人公が、穴から這い上がる」「 穴に落ちた主人公が、穴の中で野たれ死ぬ」の2つしかない』というのがある。おそらく、これはエンタメ小説の基本形だと思う。「そもそも穴はどうしてできたのか？」「主人公は本当に穴の中にいるのか？」「そもそも主人公はなぜ主人公なのか？」のようなことを延々と逡巡するのが純文学かも知れない（純文学は読まないので、間違っていたらごめんなさい）。純文学は、（面白い／鋭い／ビビットな／より本質的な）問題提起自体が重要であって、それを読者に考えさせることが主題である……様な気がする。ただ、純文学の作者にせよ、物語の基本を踏まえたうえで、あえて外すからサマになるのであろう、とは思うが。
話を元に戻すと、エンタメ小説の基本を俺なりにさらに単純化させると、「主人公が問題を解決するか／しないか」であると思う（以前、増田の「５分で物語を作れるにようになるコツ（p://anond.hatelabo.jp/20091002081424）」が話題になっていたが、この増田の考え方はそれほど間違っていないと思う）。ただし、エンタメ小説は、エンターテイメントである以上、読者を楽しませなければいけない。問題が解決するにせよ、しないにせよ、きちんと納得の行くオチにすべきであろう。そうしないと、読者は満足感を得られないだろうし、満足度が低い店に行かなくなるように、ファンもまた離れていくと思う。
もちろん、将来のファン離れを心配する前に、やる事があるのではないのか？というのはごもっともな意見だと思うが、やはり、自分でも読んでいて面白い物語を書きたいし、途中まで書いていて、自分でも面白くないなあ、と思った事がたびたびあるのでその辺を考えていきたい。
では、面白さとは何か、という話になる訳だが、「主人公が問題を解決するか／しないか」に絞って下に挙げてみよう。
（１）基本的に、読者は「主人公が問題を解決するか／しないか」分からないから、ハラハラドキドキする。サスペンス性（→suspense 不安感。特に、映画や小説などで、観客や読者が危機的な場面にはらはらする感情）。あるいは、大抵のエンタメ小説の場合、「主人公が問題を解決してしまう（読者も基本的には楽しむために読むので、ハッピーエンドも望んでいるはず）」ので、どのように解決するのかという点が重要。
（２）問題設定の面白さ（舞台設定／キャラクター設定／問題の大きさと主人公の能力のバランスなど）。”奇（変わっている事）”であり、”妙（巧妙さ。全体のバランスも含めた緻密な設定）”なほど、評価が高いのではないか？ジャンルがＳＦやミステリの場合、いかに凝った問題設定と解法を用意するかがキモになると思われる。ただし、あまりにもぶっ飛びすぎていると、読者が感情移入できなくなる問題も発生するような。
（３）間口の広い感情移入の仕組み。感情移入できない主人公の小説というのは、エンタメ小説の”てい”をなしていないのではないだろうか。主人公に感情移入出来なければ、他人事と捉えられてしまい、熱中して読んでもらえなくなる。想定している読者になんらかの”共感”を持たせるような主人公を用意すべきではないだろうか？（例えば、何らかのコンプレックスを持たせる）
（４）展開のドラマチック性。（１）の”サスペンス性”にもつながってくる話だが、「読者が想定している期待度を超えるという意味で、予想を裏切る」展開が重要になるのではないか。展開が二転三転して、劇的な勝利（問題解決）をするというのが理想かも知れない。もちろん、より読者にドラマにのめり込んでもらうためには、（３）の”間口の広い感情移入の仕組み”が必要でないかと思われる。
つまり、教養小説（ビルドゥングスロマン）的側面。通過儀礼（イニシエーション）としての小説。これこれこういう理由で、彼は”強く””大人に”なったのさ、というお話としてのエンタメ小説。
また、面白さとは何か、を追求していくと、以下のような視点も考えられはしないだろうか？
（１）読者の想像力を喚起させる事
例えば、文章レベルで言えば、情景が浮かんでくること。読者に、痛み／恥ずかしさ／快感などの感覚を想起させ、リアリティを持って受け止めさせ、疑似体験させる事。”体験的なもの”として、読者に受け取ってもらえるか。文脈レベルで言えば、展開の読めない”不安”感、手に汗を握る”緊張”感、問題解決による”達成”感などを過去の展開の蓄積により実現しているか？
（２）読者の欲望を刺激する事
例えば、女の子の描画。ポルノでも萌えでも女の子のかわいらしさをどういう風に表現し、読者の想像力を喚起させるか。あるいは、食べ物の描画。うまそうな食べ物をうまそうに（文章で）描画できるか。カッコイ戦闘機をどう格好良く（文章で）描画できるか。外には、ファッションなど。粋なファッションを粋に表現できるか。読者が関心がある事柄に対して、いかに”幻想”を抱かせ、”欲望”を感じさせるか、という点。
（３）教養としての側面
さりげなく、”うんちく”を混ぜる。例えば、中世ファンタジー物だったら、朝食は貴族しか取れなかった事を説明しながら、朝食を要求する元貴族の商人の心理を読者に想像させるなど（ライトノベル「狼と香辛料」にそんなネタがあったはず）。個人的には、少々苦手。資料用に読んだ本で気に入った設定はメモっておくなどしているのだろうか？
（４）虚構と現実の境界性
例えば、伝奇ものの面白さ。現実の実在の人物（や場所？）がファンタジーで出てくるというハイブリット感。あるいは、２ｃｈのどこまでネタか分からない感というか。
（５）比喩表現の面白さ
暗喩と直喩。村上春樹は独特の比喩表現で有名になった訳だが。（１）の”読者の想像力を喚起させる事”や（２）の”読者の欲望を刺激する事”に密接に関わってくる。例えば、「彼女の組んだ腕の上には双丘が気持ちよさそうに並んでいる」の様な表現などはどうだろうか。
（６）気の利いた会話
最近流行りの会話劇だが、コントや漫才、ネット上のやりとりなど、トレンドの文脈をある程度押さえつつも（気に入ったネタはストックしておくべきか）、表面だけの真似に留まらないために、自分の言葉による体験的要素も問われるのではないか。
（７）説得力のある説教
ガンダムの富野氏の説教くらいに説得力がありつつ、面白い説教するためには、独自の価値観を持っている必要がある。大抵の人は人生経験を積めば、それなりの一言を持っているはず。一人の人間としての成熟性が問われる、のかも知れない。
（８）笑いの要素
ギャグ／ユーモア／パロディ／言葉遊びなど。個人的に苦手な要素である。自分の場合は、どうも野暮ったくなってしまう。センスや基礎教養が問われるからかも知れない。とにかく面白いと思う話を大量に読み、小話を書いたりして、自分にあったやり方を発見するしかないのではないか。自分の場合は、実にどうでも良い事を真剣に議論していく話がウケが良いようだ。
（９）恐怖の要素
笑いと恐怖は近いものがある、と言われている。（８）の”笑いの要素”がうまく書ける人は、恐怖もうまく書けるのではないか。これも個人的には苦手な要素だ。ホラー映画も苦手だし。単に読者のトラウマを刺激しても、嫌われるだけだろうし……。ただ、最近のトレンドにはこの要素が絡んでくる作品も多いのではないか。また、サスペンス性を上げるという面でも重要な要素であろう（ジェットコースターのようなスリルと快感の関係というか）。それから、演出技法としては（１）の”読者の想像力を喚起させる事”と関連性が高いと思う。スティーブン・キングなどを読んで勉強すべきかも。
（１０）恋愛的な要素
いわゆる一つの萌え要素、と言う訳でもないが（ほら、スベった）、自分の中にある理想のヒロイン像を具現化して駆け引きを思考実験するという意味では、裸になって踊るようなものだと思う。慣れれば快感になるのかも知れない。ただ、個人的には最近、食傷気味。
（１１）バイオレンス
闘争本能を刺激する要素。”読者の想像力を喚起”させ、重みのあるリアリティとして受け取ってもらえないと、単なる茶番になるような気がする。
……ひたすら要素を羅列してきたが、要するに、”読者の感情や価値観を揺さぶる”という点が重要なのかも知れない、と思った。
（文字による心理操作によって衝撃を与える、という意味では、詐欺師に近いものがあるというか。嘘をつくのがうまい人間がお話を作るのが上手、というのも頷ける。本来、エンターテイナーというのはそういうものなのかも知れないが。ヤクザな業界というか。現在最強の任天堂さえ。というか、任天堂こそが勝つべくして勝っている”名博打打ち”なのではないか。そもそも、経営という概念自体が（ｒｙ）
あと、話題になっている、うまい＝面白いでない、という件について。
テクニックは描いた量に比例する（作品の）魅力は考えた量に比例する
物語の中だるみについて。
途中からなんだか間延びしている、なんだか乗れない、と感じたとき、物語の推進力が低下している。
主人公を追い込んだり、障害を増幅したりして、推進力を高める必要がある。すなわち障害やクリア条件を上げていくのである。
主人公は最後のゴールに簡単に到達してはいけない。ハードルが最初よりも下がってはいけない。敵が最初よりも弱くなってはいけない。
考えてみれば、続刊の出ない、あの小説やあの小説も、すでに、主人公を危機に陥れる「強い敵（難しい問題）」が取り除かれてしまったのではないか。あとは、シミュレーションゲームの終盤局面のように力押しで何とかなる状態というか。主人公がリアルに死ぬ／臨死体験するくらいの危機が常にある状態で、最後の最後で、”おおかた”の問題が片付くのが理想かも知れない。
文章力の磨き方。
基本かも知れないが、自分の好きな作家の文章を写す（タイプする）。良さが理解できない作家の文章を写しても多分、意味は無いと思う。文章を写すだけのヒマがない場合は、ラインを引きながら読むだけでも違うような気がした。逆に思ったのだが、好きな作家の文章をラインを引きながら読んでいると、作者の認識力の限界を見切る事がたまにある（例えば、そもそもの問題設定の矛盾とか、作者のルーツ（根源）はどこにあるとか）。その辺が大切なのではないか。また、好きな作家は最低二回読むべきかも知れない。
（Ｗｅｂより引用）
正しく見るためには二度見よ。
美しく見るためには一度しか見るな。
実は、優れたツリーの裏側に何十枚もの「デッサン」がある。
例えば医者コントってテーマを決めたら、オーソドックスな医者コントを、だーっと全部考える。
それだけでも充分おもしろいっていうネタにしておきつつ、更に松本がやった作業って言うのは、 部分部分で、どれだけ予想できる笑いを裏切るかって作業。確かにこれでもおもしろいけど、ここはこうやったらもっとおもしろい、こうやったらもっと裏切ってる…そういうのを延々繰り返していって、どれが一番ベストな裏切りかなぁってことを積み上げて、ネタを磨き上げていくんだって。
例えば、小説の創作手法にシミュレーション的手法を取り入れるということなのかも知れない。つまり、何回も思考実験を繰り返して、ドラマチックな展開のものだけを商品化する、という考え方。確かに、小説は元々、思考実験的な物を含んでいると思う。
その他。
「最初からフルスクラッチすると、効率が悪すぎる（１から作るのは大変であり、ベーマガのプログラムを改造しながらプログラミングを覚えていったように、まず改造する）」「問題を小さく切り刻む」「リファクタリング」的な要素を考えると、二次創作のＳＳをとにかく大量に書き、慣れてきたら、規模を増大させていく、徐々に設定も作り込んでいく、の様な方向になるのではないか。
まだよく分かっていない事。
あかほりさとるの新書に、「見たいシーンを書け」と書いてあったが、全く別のＷｅｂ上の指摘で、「最近のドラマは、脚本家が見たいシーンだけ繋げていった感じで、物語的な山場や整合性が軽視されているのではないか？」のようなものがあった。その辺の解決法。
文章の勉強以外であまり再読をした事がないので、よく分からない。
何かを創り出そうというタイプの人間には多かれ少なかれ、精神的な「欠損」があります。
その欠損を埋めようとするところから、何かをクリエイトしたいという欲望や欲求が生まれてくることが多いのです。
もちろんそれだけじゃないけど、そういうケースはしばしば見受けられます。
問題はその欠損をどこまで「普遍的なもの」にまで高めていけるかということだと思うんです。
中にはその欠損の欠損性にいつまでも拘泥しているという人もいます。
それでは本当の芸術にはなりませんよね。そのためには、人はもっと広く世界を見なくてはなりません。
人生は長期戦ですから、ゆっくりとしっかり息をしながら、前に進んでいってください。
まとまらないけど、以上。
補足。
（１）確かに、とりあえず、稚拙でも一作書き上げるという考えもありかも知れない。試してみるか……。
（２）色々本の紹介、ありがとうございます。
（３）Ｗｅｂからの引用元を書かないのに、他意はありません。面白いと思った文章は個人的にスクラップしているのですが（ローカルのメモ帳にコピペするだけ、のようなもの）、ＵＲＬまでは保存していませんでした。申し訳ないです。
（４）確かに、あるパターンの繰り返しや場面転換の組み合わせというのは、あまり考えた事がなかったですね。なるほど。……少し見通しが立った感じです。ミクロレベルとマクロレベルの視点を重視しすぎて、中規模レベルのパターン認識がうまくいっていなかったようです。皆さん、ご意見ありがとうございました。（さらに追記すると、これは上に書いたあかほりさとるの新書の話にも繋がってきますね。それなりに問題意識を持っていたけれど、もう一押し足りませんでしたね＞自分）
くたたんは「フルスクラッチ指向」で、任天堂は「枯れた技術の水平思考」だ。だから、任天堂が正義だ。妊娠大勝利！ということを言いたい訳ではないのだが。
とは言え、素人が妄想するに、もし、「成功から没落への流れ」があるならば、以下のような物ではないかと思った。
(1)先端業界ではなく、"周辺"業界において、何らかの商品企画が立ち上がる。もちろん、金がないので、技術的には、チープな既存技術の組み合わせである。日本の場合、開発者の現場感覚のアイディアの妙が問われる。「枯れた技術の水平思考」。米国の場合、壮大な未来的ビジョンの中の尖兵としての立ち位置である。前者の場合、会社の上層部は大して理解も期待もしていない。後者の場合、理解も期待もある程度している。ただ、両者とも、安い掛け金を賭ける分散投資の駒の一つでしかないし、"周辺"業界なので、一癖も二癖もある屈折した人材が集まっているのは変わらないかも。
(2)日本の場合：「たまたま当たる」。当たったので、ゴテゴテと付加機能をつけて、バージョンアップしながら商品の寿命を延命する。当たらなかったら、次の商品開発に向かう。米国の場合：地道に理想に向かってバージョンアップが続けられる。ある日、追加した付加機能がユーザーから素晴らしく評価され、いきなり「歯車がかみ合う」。それでも、当初の壮大な未来的ビジョンに向かってバージョンアップしていく。いくらバージョンアップしても、ユーザーに評価されず、兵站が尽きたら、次の商品開発に向かう。
(3)日米共通だが、徐々に部分部分をフルスクラッチ化していき、他者が追いつけないようにする。
(4)日本：付加機能をつけすぎて、ゴテゴテしてくる。一般的に、日本の場合、ボトムアップ型であり、ビジョンがそもそも明確でない場合が多い。右往左往しながら進んでいく。ウリに出来るような付加機能がなくなったら商品寿命はおしまいに近い。米国：米国の場合は、トップダウン型で、当初の計画のビジョンが達成されたならば、日本と同じようにゴテゴテと余計な機能をつけ、迷走する場合が多い。逆に言えば、任天堂は、「枯れた技術の水平思考」の本家だけあって、フルスクラッチのリスクの罠からうまく逃げているように見えるし、アップルは、そのたびに新しいビジョンを提示するという逃げ方をしているように見える。細かいバージョンアップの積み重ねと比較的リスクを抑えた許容範囲内の冒険/実験をするのが大切であり、トレンドになっているような気がする。良く悪口を言われているSCEでも、ファームウェアの細かいバージョンアップは評価されているし、MSのフリーの開発環境などもかなり評価されていると思う。
(5)その商品を打倒するような「イノベーションのジレンマ」が起こり、打倒される（可能性が高い）。
わかってない人がそこらじゅう（顧客企業の責任者とか）にいて、IT屋を困らせてるケースがとても多いんだけど。
システム開発って「製造」じゃないのよ。機械が勝手に決まった設計図に従って車作ってくれるようなもんじゃないわけ。
車で言うと「設計」に対応するんだよ。
シャーシの規格をどうするか、特別仕様を盛り込むためにどうするか、エンジンはどれを使うか、あるいは一から開発するのか、
タイヤは？ホイールは？アクセルとブレーキの機構は？ボディは？素材は？色は？オプションは？
各顧客ごとにフルスクラッチで新車種を開発するようなもんなんだよ。
それだけでもう「やってらんねーんだろうな」って想像できない？
帰宅。
気持ちが楽になりました。
以下チラ裏
業務系って技術は全然いらないと思うんですよ
意味不明なテーブルに対して、仕様も解らないのに延々とSQLを考えて、
hoge=higeで検索されてるよねっていう不毛なテストを延々繰り替えして、
スケジュール間に合わなくて怒られて、（まぁこれは俺が仕事できないのが悪いんだけど）
最後の最後でドバッとフルスクラッチで書き直す。あほか
むしろ、技術的なことより、業務仕様に詳しくないとやってらんないと思うんです。
で、
正直、そういうのに興味はまったくないし、
なんかこれってITって言うのか？とか思ってたり。
1年間ずーっと。
とにかく、もっと技術的なことをやりたい。
今の会社の先輩、上司を見てても、年がら年中客先を転々してて、
あんなふうにはなりたくない。嫌悪感すら覚える。
漠然としてるけど、もっといい環境があるんじゃないのかとか思う。
ということでそろそろ退職届け書き始めます。
M男です。
初めは小学生の頃か。
実物のスペースインベーダーの記憶はない。
しかし、それを皮切りにアーケードゲームのみならず、ゲームウォッチ、ケームセンター嵐などを経て、ファミコンが登場する「ゲーム」の時代だった。
「ゲーム」がコンピューターゲームの意味になった時代だった。小学生も「コンピューター」にワクワクした。
21世紀はコンピューターにより人工知能ができる。そんな時代だった。
でも、アルファベットを知らない小学生にBASICは難しかった。ぴゅう太がせいぜいだった。
「PRINT」で文字を表示する。「GOTO」で行き先を変える。それは分かった。でも何をすればよいか分からなかった。
だから「ベーマガ」で16進数を打った。でも動かなかった。何度も調べ、直し、試した。デバッグした。
でも動いた。自分の入れた文字で数字でコンピュータが動いた。自分で動かした。動かせた。
高専に進んだ。Turbo Pascalでコラムスもどきを作った。
小学生のころから6年が過ぎていた。
Turbo Cも使った。IDEで使うそれは、インタプリタのノリだった。
FM-Rでレイトレースもした。一晩かけて、エラーが起きていた。
でも、構造化プログラミングを学んだ。ポインタも学んだ。マシン語の知識が役立った。
Solarisも使った。EmacsやXも使った。オブジェクト指向も知らずC++にも触れた。
awkやsedで正規表現を学んだ。そしてperlに出会った。
コラムスもどきを作ってから6年が過ぎていた。
perlで掲示版の書き込みをチェックし、madokaで遊んだ。CGIを書いたりした。
perlと出会ってから6年が過ぎていた。
はてなに出会った。JavaScriptに出会った。
Bookmarklet、greasemonkey、Ajax。オブジェクトだらけだった。
初めはゲームだった。でも最初だけだった。
気が付いたら24年が経っている。
今、pythonで書いている。
ようやく、言語の違いには慣れてきた。でも、まだLISPを使った事はない。
道はまだまだある。未知の世界につながっている。
作りたい物が本当は何かは分からない。作れる物が本当は何かは分からない。
どんなふうに動くのかは分かってない気がするけれど、分かっている事もある。
それが今の私のstatusだ。
未だに泥がどうたらこうたら言ってるやつは
http://anond.hatelabo.jp/20080717201617
平日は他人の書いた仕様書通りに実装して、土日は参考書通りにデモ実装して喜んでる暇があったら、自分の頭で一からアイデア考えて、すべての工程を自分でやれ。
土日に他人のWEBAPI使ってちっさいコード書いて自己満足してる暇があったら、フルスクラッチで大きなアイデアを実現してみろ。
ライブラリが使えるだけなのにプログラミングが出来ますって言っちゃっていいのかな？なんて引け目感じてる暇があるなら、さっさと自分で新しいライブラリ書いてみろよ。
ワンライナーが、コンパイラ依存が、言語仕様が、とかム板やブログで無駄な煽りをやってる暇があったら、何か他人に役立つものを自力できちんと最後まで作れ。
RSSリーダーの更新ボタン連打してる暇があったら、まだやられていないアイデアを目を皿にして探せ。
梅田モチオさん最高っとか余裕こいてる暇があったら、自分で起業して玉砕してみろ。
お前らのモヤモヤした悩みはお前らの行動によってしか解決されないんだよ。
起きてる間ずっと自分の頭で考え、決定的なアイデアに集中し、わき目も振らずに最後まで実装できたやつだけが、
偉そうにふんぞり返ってるアホをぶちのめせるんだよ。
未だに泥がどうたらこうたら言ってるやつは
http://anond.hatelabo.jp/20080717201617
平日は他人の書いた仕様書通りに実装して、土日は参考書通りにデモ実装して喜んでる暇があったら、自分の頭で一からアイデア考えて、すべての工程を自分でやれ。
土日に他人のWEBAPI使ってちっさいコード書いて自己満足してる暇があったら、フルスクラッチで大きなアイデアを実現してみろ。
ライブラリが使えるだけなのにプログラミングが出来ますって言っちゃっていいのかな？なんて引け目感じてる暇があるなら、さっさと自分で新しいライブラリ書いてみろよ。
ワンライナーが、コンパイラ依存が、言語仕様が、とかム板やブログで無駄な煽りをやってる暇があったら、何か他人に役立つものを自力できちんと最後まで作れ。
RSSリーダーの更新ボタン連打してる暇があったら、まだやられていないアイデアを目を皿にして探せ。
梅田モチオさん最高っとか余裕こいてる暇があったら、自分で起業して玉砕してみろ。
お前らのモヤモヤした悩みはお前らの行動によってしか解決されないんだよ。
起きてる間ずっと自分の頭で考え、決定的なアイデアに集中し、わき目も振らずに最後まで実装できたやつだけが、
偉そうにふんぞり返ってるアホをぶちのめせるんだよ。
