  |
はてなキーワード:プログラマブルとは
ここで言う「プログラミング初級者」とはプログラミングの記述が上から下へ向かって順番に処理されること、条件分岐やループという概念があることを理解しており、RPGゲームが作れる「RPGツクール(現RPG Maker)」や学童向けプログラミング環境「Scratch」、「ナビつき! つくってわかる はじめてゲームプログラミング(ナビつく)」、ADVゲームが作れる「吉里吉里(もしくは吉里吉里2)」、過去にBASICやC、HSP、Javascriptあたりでプログラミングへ挑戦し挫折したなどなど、ある程度の「プログラマブルなロジック」構築の経験がある者を指します。
ある時、筆者はふと思いました。「生成AIはなんだかんだで膨大なテキスト情報を処理している事がキモだよなぁ」とありきたりなことを。
そして、同時にプログラミング初級者の弱点として「現在記述されているコードの管理においてテキストと実際の処理フローが脳内で一致しない」「プログラミング言語ごとに定められているルールや関数予約語の把握が困難」なのが問題とも考えました。
前述したプログラミング初級者の弱点の考え自体は車輪の再発明であり、「Scratch」や、より高度な「UML」が既に存在しており、特筆すべきことは何もありません。
しかし、「Scratch」や「UML」、なんなら「RPGツクール」や「吉里吉里」などに無い点として、現代では自然言語処理が大幅に向上した生成AIが実用の域にまで到達しつつあるのが従来とは異なる点でした。
つまり、自然言語を混ぜ込みやすいテキストベースの言語、かつ、処理を記述するとフローが視覚的に理解しやすい言語、可能であれば情報量が多くて一部の界隈で広く使われている言語があればプログラミング初級者も気軽にプログラミングできるのではないか？と発想しました。
コンピュータ(コンパイラやインタプリタなどソフトウェアを含む)が解することができる言語にはプログラミング言語以外にも様々あり、今回取り上げるのは「データ記述言語」と呼ばれるものです。
データ記述言語の中でもグラフ作成へ特化しており、特にフローチャート作成で真価を発揮する「DOT言語」というものがあります。
早速ですが、実際に手を動かしてみましょう。ちなみにDOT言語はGraphviz OnlineというWebツールがあるため別途に何かしらをインストールして環境構築する必要はありません。便利な世の中ですね。
上記のGraphviz Onlineを開くと、既に左側のDOT言語で記述された内容が、右側で作図されています。DOT言語はこのような図を作図するためのデータ記述言語です。
一旦、左側の記述をCtrl+Aで全選択をしDeleteなどで全削除し、下記の内容をコピペしてみましょう。
digraph graphname {
A -> B;
}
DOT言語の詳細な使い方は様々なWebサイトやブログ記事、Qiitaなどへ譲るとして、A - > Bの見た目から発想の転換をしてみると処理Aから処理Bという流れに見えませんか？
DOT言語は生成AIを利用する上で有利なテキストベースでありながらグラフを作成できるのがキモであり、例えばこのA -> BがA「Webページを開いたら」 → B「Hello, Worldと表示する」という風にできるのであれば処理のフローが可視化されており本当に素晴らしいことです。
ここでプログラミングの有識者は「DOT言語をUMLなどに見立てて処理を記述するのは良いが、プログラミング初心者は求めた結果を出力するロジックやアルゴリズムを発想する知見や経験値が圧倒的に足りていないのが問題ではないか？」と至極真っ当かつ反論の余地がない問題点の指摘をすると思いますが、そこで活きるのが生成AIです。
生成AIは初級者プログラマ個人のロジックやアルゴリズムの作成能力へ無関係にロジックやアルゴリズムを生成できる(可能性が少なくともある)ので、処理のフローをDOT言語で記述することにより処理フローから初級者プログラマが求めるプログラムを生成AIへ推論させ生成させるというのが狙いです。実際に試してみましょう。
digraph graphname {
A[
label = "Webページを表示する"
];
B[
label = "Webページを表示したらHello, worldとテキストを表示する"
];
A -> B;
}
プログラミングの有識者はこの時点で「なるほど、自然言語の記述をそのままDOT言語に入れ込んでしまうのか」と気付いたのではないかと思います。
このDOT言語をGoogle Gemini 2.5Flashへ「下記のデータ記述言語のDOT言語で記述された処理フローをJavascript言語へ変換をしWebページ上へ「Hello,world」を表示したいので変換をお願いします。」と命令すると以下のコードが生成されました。
<!DOCTYPEhtml>
<html lang="ja">
<head>
<meta charset="UTF-8">
<metaname="viewport" content="width=device-width, initial-scale=1.0">
<title>Hello World Page</title>
</head>
<body>
<divid="output"></div>
<script>
//Webページが表示されたら（DOMが完全に読み込まれたら）実行される
document.addEventListener('DOMContentLoaded', function() {
// "Webページを表示する"ステップは、このHTMLファイル自体が表示されることで達成されます。
// "Webページを表示したらHello, worldとテキストを表示する"ステップ
const outputDiv = document.getElementById('output');
outputDiv.textContent = 'Hello, world';
});
</script>
</body>
</html>
フローを記述する利点は、ロジックやアルゴリズムを発想する知見や経験値が足りなくとも、フローのステップが明確に分かれているので生成AIが処理を切り分けて推論してくれることであり、そしてプログラミング初心者自身がフローチャートを視覚で確認できるので「Aを処理したらBを処理する」と切り分けて考えやすいことです。
また、求めている結果ではなく誤った結果が生成されても、A - > B - > Cとフローを細分化していくことで生成AIの推論精度を高めていくことができるのも利点です。
より生成AIへ精度の高い推論をしてもらうために補足情報を付加するのも有用です。
digraph graphname {
A[
label = "Webページを表示する"
];
B[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機"
];
A -> B;
}
labelの記述内容もcommentの記述内容も生成AIが推論のための情報として利用するので誤った結果が生成されてもA - > B - > Cとフローを細分化しなくとも良い場合があります。
DOT言語を知るプログラミング有識者が「DOT言語の仕様を考えれば確かにそうだが、その発想はなかった」と言っていただけるであろうDOT言語コード例だとこういう記述方法もアリです。
digraph増田コード {
最初の処理[
label = "Webページを表示する"
];
次の処理[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機"
];
最初の処理 -> 次の処理;
}
ノードの名称へ自然言語を採用することにより、例えばゲームプログラミング時に「キャラクターがジャンプする」という読んだそのままな処理のためのノード、というか一般的に言うオブジェクトを作成することが可能で、後は->で繋げて処理をさせられます。
ちなみに別のノードを作成する際に「"キャラクターがジャンプする"から継承する」の様なことをcommentなどへ記述しておくと生成AIが推論して継承します。なんならcommentなどへ「キャラクター画像にimage.gifを使用」などと記述しておくとファイルの読み込みもします。
更にDOT言語にはカスタム要素という仕様が存在しており、DOT言語の仕様で定められた予約語以外も使用が可能です。
digraph増田コード {
最初の処理[
label = "Webページを表示する"
];
次の処理[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機",
font_style = "フォントを太字のボールド体、色を赤(#FF0000)とする"
];
最初の処理 -> 次の処理;
}
生成AIはカスタム要素の名称からも推論を発揮し、上記の場合であればフォントスタイルを指定していると推論をするので生成AIの推論精度を高める補足情報として機能します。
つまりこれはカスタム要素の名称として"Action"などの名称を採用すると"動作"として推論をし、"decision"ならば"条件分岐"ですし、"input"ならば"入力"ですし、"loop"ならば"繰り返し"ですし、"Type"ならば"種別"です。
より詳細に process[type="Action"] などのノードを作成してどんどん生成AIの推論精度を高めていくことが可能であり、そろそろ察してきているかと思いますが 処理[種別="動作"] と自然言語で記述しても機能します。
プログラミング有識者は更に「プログラム言語自体の予約語、例えばJavascriptを生成する事を前提にlengthを名称にすると配列を使おうとするのか？」と疑問に感じるでしょうがお察しの通りで生成AIは配列を使おうとするので、敢えて使いたいプログラム言語の機能や外部ライブラリなどがある場合は補足情報として機能する形で記述しておくと生成AIは推論へ利用します(まぁそこまで知識ある方なら該当のプログラム言語使ったほうが手っ取り早いと思いますが)。
以上をもって「生成AIを利用したプログラミング初級者向けの温故知新な提案」を終えたいと思います。
色々とツッコミどころには筆者自身が気付いていて。例えば「結局はDOT言語の仕様を覚えないといけないのでは？」とか「プログラミング初級者に任せると生成前のソースであるDOT言語コードがスパゲッティになりそうだよな」とか「面倒くせぇから普通にプログラミング覚えろや」とか理解してますし至極真っ当かつ反論の余地がないと思ってます。
今回の提案のプログラミング有識者向けの本質は「生成AIへ向いた中間言語の発掘」であり、「DOT言語ならそこそこ普及してるしプログラミング初級者でも扱えるんじゃね？」と業務中に発想したものを書き留め公開いたしました。
何かプログラミング有識者の皆さんからより良い発想があれば参考にしたいと考えていますのでよろしくお願いいたします。以上。
Permalink |記事への反応(36) | 19:36
Not Financial Advice。個人的メモ、現状の文字起こしと雑な未来予想。自分もWeb3ヤーとして整理したかった。
根源的にビットコインは規制で禁止することはできないので、できるところから規制されるトレンドは今後も続くだろう。目下、短期のナラティブはETF承認である。AML/CFT観点でビットコイン現物の流通はなるべく制限したい規制当局側と、ビットコインのエクスポージャーが欲しいだけの大多数の投資家の思惑の両方が、現物ETF承認という形で結実するのである。その後、ビットコインETFが高い流動性を持つようになれば、既存金融機関はビットコインETFを担保にした金融サービスや派生金融商品を展開できるようになる。
また、大手マイニングプールと、（すでにマイニングプールの株主となっている）ETF取扱金融機関が提携する未来もありえるだろう。例えばマイニング収益はプール参加者のウォレットアドレスに引き出されることはなくなり、プール参加者の証券口座にETF残高として入金されるようになる。これはプール参加者と規制当局どちらにも利点がある。プール参加者にとっては、ブロックチェーン手数料や秘密鍵保管といったブロックチェーン特有のリスクを負わなくて済むし、ビットコインETFを通して既存金融の多種多様な流動性へ容易にアクセスできるようになることも喜ばしい。規制当局にとっても、本質的に規制できないマイナーとBTC現物が切り離されることは喜ばしく、win-winなのだ。すでに大手マイニングプールはマイナーにKYCを求めているので、マイナーは分散思想よりも規制された安定を選んでいる。マイナーが投資家保護環境の整ったETFに乗り換えるのは合理的な選択なのだ。
ビットコイナーの思想とは相反するものの、市場原理とは相反しない力が優勢となって働くことで、ビットコインはATHを迎えるのである。
マイニングプールが結託して51%攻撃を起こすことは、マイニングプールにとっても合理的ではないので、少数マイナーの寡占状態が直接的にビットコインを破壊に導くとは考えにくい。しかし、大きな金額を動かさないといけない巨大プールは既存金融に保護されざるを得ず、規制の圧力に対しては脆い。同じ51%でも1 ✕ 51よりも25+26の方がCensorshipResistanceやOpennessといったブロックチェーンの本源的な価値は損なわれやすい。なのでマイナーに寡占が起こることを問題視しないのも間違いである。
https://x.com/nook_ethereum/status/1696476655475171759
仮の話だが、完全に当局の規制を受けてコーポレートが牛耳る、本源的な価値を失ったビットコインが、toobig to failな状態でゾンビ化した時どう振る舞うのだろうか？そのタイミングで古参クジラは離脱して一時的に売り圧が発生する気もするが、そのままトリクルダウンとなるほどのトリガーかというと分からない。これはビットコインに使われる暗号の危殆化などのリスクと一緒で、起こるまで想像ができない。そのフェーズはP2P電子決済システムビットコインという壮大な社会実験の重要なハイライトになるに違いない。
ビットコインのブロックスペースを使って、レイヤー2上で好きなブロックチェーンを誰でも立てられるようにする新機能。まだ提案段階の機能だが、賛否両論を招き、界隈を真っ二つにしている。
ちょっと前に流行ったStacksの仕組みと異なり、BTCを子チェーンにオプトインするような仕組みも備える。もちろんオプトアウトもできる。
ただし、Drivechainが認められると、ビットコインのスケーラビリティを向上させるソリューションとしてのLightningネットワークの意義がかなり失われる。Lightningは”P2Pで”高速決済したい人が使うための機能という、かなり思想が強い人向けの錆びついた技術になり得る。
Drivechainの提案自体は昔からあったが、最近になって流行り出したのは単なるナラティブ作りであろう。ordinalsやStacksもそうだが、新しい技術はそれだけで盛り上がりやすい。ordinalsの場合だと、昔から追っていた人は、自分が優位でいられる情報が非対称的な時期に、短期で出口流動性（イナゴ、養分）をたくさん集めて、たんまり儲けて売り抜けることができた。
ちょうどBitcoin, not Cryptoな時期で、Drivechainのような特大アップデートがあればナラティブとしては強力だ。しかし、だからこそ、どうしてもDrivechain利権の存在を勘繰ってしまう。Lightning利権とも対立しそうだ。
Lightningはビットコインにマルチシグだけあればできる機能だが、Drivechainはソフトフォークとは言え、これだけのために新規のオプコードやメッセージの追加など、開発リソースをかなり費やす大幅なアップデートなので非常に図々しい。ソフトフォークをexcuseにすればなんでもありだと言うわけではない。
今更dAppsが走るサイドチェーンを作っても、Ethereumで起きているようなゴタゴタをビットコインに持ち込むだけで、Bitcoin, not Crypto神話を汚すだけになるだろう。
実質管理者のいるDeFiも規制の煽りを受けて存続は難しくなっていくだろう。ハッキングやインサイダー、スキャム（詐欺）、ラグプル（持ち逃げ）から投資家を保護できないファイナンスは、たとえゲイリー・ゲンスラーがSEC長官を退任したとしても長期的には必ず規制対象になる。また、そうはならなくとも投資家の方から勝手に離脱していく。
しかしながら、オフショアで規制の及ばないチェーンを舞台に、リスクを恐れない投機家の間でDaFi（DarkFinance、闇金融）に転じたDeFiがしぶとく生き残るのはどうしようもない。
ただ、そのようなDeFiはもう社会生活の金融インフラになることはないだろう。結果的に今のDeFiはDaFiかCeFiに分岐していく。
CeFiという語彙は以下のツイートから使わせてもらった。ブロックチェーンを使っているが、規制もされている金融サービスくらいの意味だ。
https://x.com/kimurayu45z/status/1695988782871498898?s=46
ブロックチェーン上の金融サービスに規制をかける場合、どのようなものになるだろう。まずCeFi事業者に対する当局による管轄、投資家のKYCは必須になる。そうなってくるとブロックチェーンでやる必要はあるのかいよいよ分からなくなってくる。かの有名なWhy Blockchain？の声がまた聞こえてくるのだ。
少なくとも、トークンでガバナンスするような機能をプロトコルに組み込む必然性はなくなり、ガバナンストークンは株や証券に近いものになっていく。また、仮にアプリケーションどころかL1チェーン自体が規制されれば、PoSなどのトークンベースのコンセンサスアルゴリズムはもはや茶番になる。
ユーザー目線でも、KYC済みのアドレスをスマートコントラクトに登録してまで、入札や取引したい投資家がどれくらいいるのか今のところ分からない。
もしもかつてのDeFiバブルが違法事業者の非合法的な取引で盛り上がっていただけの幻想だった場合、KYC後のクリーンなCeFiにどのような実需があるのだろうか。
MEVというのは、ブロック生成者が承認前のブロック内の取引を盗み見れることをいいことに、他人の取引を先取りしたり、順序を利己的に入れ替えることが可能である性質から生じる、ブロック生成者が独占できる収益源泉のことである。
https://keccak255.substack.com/p/mev
MEVがあるせいで、ブロック生成行為が中央集権化しやすくなったり、ユーザーのサービス体験が低下したりするため、dAppsが動くブロックチェーンにおいては重要な課題だ。
もちろん技術的に解決するSuaveのようなソリューションが提案されているのだが、分散化にメドがたっているわけではない。また、問題が外部化するだけで本質的な解決にはなっていないのではと思う。
Suaveについて参考までに
https://writings.flashbots.net/mevm-suave-centauri-and-beyond
また、MEV利権がすでに巨大化している政治的な事情もあり、問題はかなり複雑化している。このように込み入った問題を、さまざまなステークホルダーの思惑が入り混じる、非効率的な分散ガバナンスで解決するのは前途多難と言わざるを得ない。
チェーンのTVLが巨大化し、RWA（real world assets）などのMEVファクターがチェーンのエコシステムの隅々まで組み込まれれば、MEVがもたらすマイナス・サムの影響はユーザーにも感じ取れるくらい甚大なものとなるだろう。さらに、可視化できないリスクを嫌う大手投資家の参入を阻むことにもつながる。
そうなったとき、パブリックブロックチェーンの夢は雲散霧消するか、中央集権が正当化された世界でregulatedなブロックチェーンが生き残っていくかのどちらかになる。
一旦DaFiやCeFi、MEVのことは忘れて、全てが解決して、DeFiがそのままメインストリームになった社会を想定してみる。そこで注目したいのは、チェーンに閉じたDeFiでは信用創造ができず、分散型ステーブルコインなどの場合は常にover-collateralized（過剰担保）させなければならない点だ。つまりロックされた資本以上の価値が市場に再投資されない。原資本は再投資のたびに指数関数的に薄まっていく構造になってしまうのだ。
そのような先細りの金融インフラの上に展開される資本主義及び自由市場経済社会が、規制された金融に基づいた現状の社会よりも、高い資本効率と経済成長率を達成できるのかは甚だ疑問である。
一昨年のDeFiバブルの正体が、USDTなどの法定通貨担保型のステーブルコインがチェーン外から流入することで起こったに過ぎなかったのだとすれば、DeFiの世界はCe要素なしには拡大できないということになる。実際、USDT、USDCなどの法定通貨担保型のステーブルコインの時価総額は無視できないほどに巨大だ。そういった規制アセットの流入なしにはリターンが期待できない構造的欠陥がある限り、DeFiは規制を拒んで信用収縮の道を選ぶか、信用創造のために規制を受け入れてCeFi化していくしかない。
分散や自己主権といったブロックチェーンの思想を全く気にしない大多数のユーザー目線で見ても、国際送金や金融取引が瞬時に透明性高く行えるブロックチェーンが便利なのは間違いない。しかし、それは既存の金融サービスが規制というかなり重いハンデを付けられた状態で戦ってくれているからそう見えるだけで、ブロックチェーンという技術自体がイノベーションだからではないのではないか？つまり、仮に規制の側が妥協して、金融業界がリバタリアン並みの自由化を勝ち取った時、ブロックチェーンは、例えばApple銀行のような大規模なWebインフラを使った金融サービスに技術として勝てるのだろうか？
もしも、ポンジスキームやスキャムであることが明らかなミームトークン、発行主体を名指しできるXRPや、ガバナンストークン全般が、規制されない（もしくは証券ではない）と判決された場合、Apple銀行がプログラマブル・トークン発行プラットフォームを立ち上げればブロックチェーンは競争に負けてしまうのではないか？秒間取引処理数が少なくて、手数料も高く、ウォレットも使いにくいブロックチェーンの優位性はどこにあるのだろう？
とはいえ実際に既存金融が完全自由化することはありえない。あり得るのは、既存金融業界とブロックチェーン業界が融合していく中で、その両極からの声を取り入れながら、長期的には両者の境界線が最も曖昧となるような規制環境が整備されていくシナリオだ。それはトークンの証券化かもしれないし、証券という概念が古くなるような全く違う新しい法概念や規制のフレームワークの誕生かもしれない。そうなったとき、果たしてブロックチェーン技術が市場で競争力を持つのかは、改めて問われなければならない。使いやすさより分散思想を優先するユーザーなんて殆どいないはずだ。
日本のWeb3界隈は、昔から霞ヶ関を巡回する界隈と海外組の界隈に二分されていたが、最近は海外からの出戻り組が増えてきたように思える。かつてJapan色がなかったAstarが最近はJapanを押し出すことが増えてきたので、これも出戻り組と言えるだろう。京都で開催されたIVS Cryptoでは、かつての海外組が、今後は日本にもコミットしていくしたたかな姿勢も見せていた。
Astarが政府機関やJTCと手を取り合って、提携関係や共同研究関係を結び始めたときは、何をしているんだと正直思っていた。しかし、当時から規制側に歩み寄らなければブロックチェーンは存続できないと読んでいたのか、単なる嘘から出た誠なのか、こうなった今では一定の妥当性が理解できる。
とはいえ規制と近づきすぎるとパブリック・ブロックチェーンの特性が邪魔するはずなので、その擦り合わせは茨の道だろう。Why Blockchainの最前線で闘う姿勢は評価したい。
渡辺氏も、もしAstarがダメになっても、日本は偉い人と仲良くしておけば何とかなる国なので、かつてのホリエモンのような毒を出さなければ、どこかしらの利権に入れてくれるだろう。そこら辺を踏んでいるのか、彼のポジショニングは上手いなと思う一方で、FTXのサムが破滅直前まで政府と蜜月関係を結ぶのに奔走していたことを思い出させるから少々怖くもある。当局に近づくと不透明性が増すので、個人的にはまだASTRに買いを入れる勇気が持てない。
さて、クリプト・コミュニティ一般の話だが、これも昔よりは成熟してきたと思う。悪しき通貨が自然淘汰される市場原理が働いたというのもあるが、個人の中にも、かつては歯に衣着せぬ物言いでオピニオンリーダーになったインフルエンサーが、今ではバランスの良いコメンテーターになったりと、心境の変化なのかポジショントークなのか、変化を感じざるを得ない。日本人垢にも外国人垢にもそんな人は多い。
例えばVitalik氏は、かつては大衆向けに過激なことを吐いていたが、最近は難解な理論の提示にとどまり、過激な使い道を見つけるかどうかは受け手の自由ですよ、という我関せずな態度に改まった。
むしろ危ないのは、陰謀論界隈や極右派をバックにした米国会議員をはじめとするすでに過激なコミュニティが、ビットコインやWeb3に活路を見出そうとしていることだろう。余計なポリコレリスクを抱えると面倒である。
このタイトルは煽っているように聞こえるかもしれないが、流行りに乗っただけで煽ること自体は本意ではない。ジブリのあの映画を見た頃、こんなこと考えてたんだなぁと後でエモくなるための筆者なりのギミックなのだ。もし不快な思いをしたクリプトに携わる人や投資家の方がいれば、そこは大目に見ていただきたい。
凄く面白い。まだ大して本数は見ていないが話に聞いていた通り、世界への解像度がグッと上がる気がする。昔から色んな人の視点を知りたいとは思っていたものの、それをゲームと言うメディアを通じて実現するのは実にクリエイティブな発想だと思った。と言うかそもそもゲームをこういう形で利用すると言う発想に目から鱗が落ちる思い。
視聴中の印象は100分de名著に近い。でも100分de名著はゲストの言説が綺麗にまとまっているが、ゲームさんぽは非常にざっくばらん。だからこそ思った事をそのまま口に出すかの様な生々しい、と言うより加工していない生の活きの良い考えを聞く事が出来て良いと思う。100分de名著は非常に手間の掛かったフルコース料理、でゲームさんぽは素材の味を活かしてる感じ？ちょっと違うかもしれないが、取り合えずさておく。
また、なむさんの話の聞き方及び引き出し方は非常に好感が持てるしコミュ力が高く感じる。生臭坊主と紹介されており本当にお坊さんなのかまでは知らないが、そうだとすれば説法を説く人だけに人の心の開き方や話を引き出す質問が上手で、だから逆に教えを受ける側になっても凄くコミュニケーションが上手なのかなと感じた。そういう意味でこの動画における注目点はゲストの所見だけでなく、なむさんの振る舞いそのものにも有ると思う。それだけに案内人がなむさん以外だとやはり少し魅力が落ちる印象。
以下、観た回の感想
②～⑤、⑦もそうだが、著名人って感じじゃない人がゲストの回は気楽な雑談味が強く、肩の力が抜けてリアルにその人の視点を語ってくれている印象を受けてグッと惹き込まれる。くだらない事で笑ってアイスブレイクし、肩肘張らずに出た生の所見は直感的に理解し易い。上述した様に丁寧に丹寧に調理されたフルコース料理の様な高説は大変味わい深いが正直理解するのに体力を使う。
この回は特別非常に関心する話続出って感じではないが(そもそもそう言うコンセプトの動画では無いと思うが)、ガラスが割れる様からプログラマブルマテリアルの話になり、そんなハイテクな技術があるのにわざわざ割れた壺を大事に展示しとくのには文化的な意味が有るのかもしれない、という発想に行き着くのはゲームさんぽの神髄だと思った。
孤食に対する忌諱が凄い。やはり家庭科の先生は家族と言う存在に対し相当重きを置いているのだなと感じた、まぁ当たり前だけども。
あとは困った事をする大人に対しては、発達が終わっているから自制心を働かせて頑張るしかない、という精神論で終わらせてしまっているのが物足りない感じ。この先は家庭科の範疇ではないって事なのかも。家庭科の取り扱う範疇という物に対して少し考えてみたくなる、これもまたゲームさんぽの魅力だなぁ。
普通に面白いんだけど、取り分け印象に残る会話は無い。ただ今後ゲームをする上ではつい音響を意識しちゃう様になるのかもしれない。それこそが世界に対する解像度が上がると言う事である意味コンセプト通りの回。あ、7.1サラウンド風ヘッドホンの話は豆知識でした。
滅茶面白い、ゲームさんぽ初見の人は①を見た後にこの回を観て欲しい。この回からでも良いんだけど基本フォーマットを理解した方がより動画に浸れるかなと思う。環境工学を学んだ人の視点を知れると言う興味深さの点でも、単純に馬鹿笑いする意味でもこの回は今の所観た回の中で一番面白い。
(サスティナブル的に考えると)この町はダメだな→いやまだそう判断するの早計→(10秒後)いやこの町やっぱダメだわ→でも将来も考えて…→(10秒後)いやこの町やっぱダメだわ、の流れは最高。滅茶苦茶笑った。
(町の全体像が見れた上で環境工学を学んだ方の見解としてこの町は)どうすか？→凄い凄い、良い景色→え？、も漫才かと思う位笑った。
③と同じ印象。どちらかと言うとレゴに関する所見よりも19歳の東大生くんの少したどたどしい会話自体が可愛いらしいし興味深かった。
⑥気象予報士・石原良純さんと『ブレス オブ ザワイルド』をやってみたら、天気の仕組みがよーーくわかった！
正直石原良純氏に関して今までテレビ番組で観た印象としては余り面白くない人って印象だったんだけど、やっぱり本職の話となると印象がグッと変わるね。急に教養深い人に見えた。気象学を学んだ人には風が見える、って話はまさしくゲームさんぽのコンセプト。あと何かと酷い扱いを受けるリンクに同情する様な発言をするのが案外優しい面も有るんだと感じた。
ただまぁ、やっぱりゲストが著名人だけにちょっと所見と言うより語りが多いかなぁ。ゲームさんぽでなく石原良純氏が語る気象学って感じの内容になっちゃってる。ちょっと堅いんだよねぇ…。なむさんも遠慮してる感じする。もっと友達と下らない事喋ってる感がある方が動画に浸り易いんだよね。
⑦弁護士・水野祐さんと、極悪非道なゲームの世界で「法律」の意味について考えた。
⑥と打って変わってご知人？なのかな？飲酒しながらの撮影と言う事でかなりゆるーい回。④ほどじゃないけど④に近い、興味深くも有り単純に馬鹿笑いも出来る回。結びとしての音楽業界は法律面からみた時に時代の先を行っていると言う話を例に挙げた所からの法律は縛るだけの物と思わないで面白く活用出来ると良い、そういう世界になれば良いなっていうゲストの話は自分には無い視点だったなぁと思った。
⑧現役のスナイパーとFPSをやってみた
実は一番最初に観た回。大変面白いんだけど、①～⑤、⑦に比べるとやっぱ堅い、ゲームさんぽってコンセプトとして大分バラエティ寄りだと思うんだけど、この回はかなり教養番組寄りって感じがする。ゆるさが無い。なむさんが案内人じゃないってのも大きいかも。なむさん雰囲気作りも話の広げ方も本当上手なんだよなぁ…。
でも色んなメディアで触れて知った気になってるスナイパー感と言う物がかなり崩れる良い回。教養番組と感じるだけあって、披露される知識量としてはこれまで観た回の中でも随一な気がする。
⑨【ゲームさんぽ／龍が如く】歌舞伎町のキャバレー経営者が語る、夜の世界の一流接客術
まだ半分しか観てないんだけど、感想を書きた過ぎて思わずココに登録してしまった位かなり面白い回。ゲストの会長が話し上手。まぁやや石原良純氏回の悪い所と同じ感じも出ちゃってるが、やっぱり夜の世界で一財築き上げた人間の話は一事が万事興味深い。何というか知識や経験に裏付けされた自信が良い所見を生み出している。ゲーム内の女の子の顔写真を観ただけでその子からどの様な印象を受けるか、そしてどの様に扱うべきか考えが浮かぶ、ってのが良い。所詮ゲームなんだから単なる妄想に過ぎないんだけど、それでも恐らく会長のそれは当たっている可能性が高いんだろうなって思わせる。勿論会長自身の才能も大いに有ろうが、きっと何百何千と女の人と会って得た経験が単なる妄想じゃないリアルな想像にするんだろうな。
あとYouTubeの米欄に有ったけど、水着を着させた時に目がエロくなってるのは笑う。やはり女好きじゃなきゃこの業界はやってけないよね。
それにしてもホント会長自身がキャバ嬢なんじゃないかと思う位話し上手。何度も対比に使って申し訳ないが石原良純氏はどこか上から感を感じるが、この会長さんは尋常じゃない程偉い人の筈なのにそれを一切感じさせない位謙虚。じゃあ卑屈かって言うと全然全く。寧ろ自信に満ち溢れた発言は聞く者に敬意を抱かせるに充分。こういうコミュニケーションが取れる人になりたいなぁ。
長くなったのでここまで。
https://www.slideshare.net/TokorotenNakayama/dxdevopstechlive
↑の記事を要約すると、DevOpsのうち、Opsの大半ないし大部分が、クラウドの「コンピュータがコンピュータを制御する仕組み」によってプログラマブルになり、DevがOpsを扱えるようになったってことでしょ？
それこそAppleによって、ソフトがハードを完全に支配下に置いちゃったみたいな。
でもさあ、開発も運用もやった経験があるから言うけど、それってプログラマの傲慢じゃねーの？
言い換えれば運用や構築に携わる人間は、クラウドをメンテする下請け以外要らんってことでしょ？
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 45 | 11134 | 247.4 | 37 |
| 01 | 27 | 5537 | 205.1 | 99 |
| 02 | 33 | 2961 | 89.7 | 29 |
| 03 | 20 | 6772 | 338.6 | 118 |
| 04 | 21 | 4125 | 196.4 | 43 |
| 05 | 4 | 1882 | 470.5 | 349 |
| 06 | 22 | 1895 | 86.1 | 47.5 |
| 07 | 38 | 3367 | 88.6 | 30.5 |
| 08 | 71 | 4867 | 68.5 | 37 |
| 09 | 134 | 7930 | 59.2 | 31 |
| 10 | 268 | 12186 | 45.5 | 29 |
| 11 | 180 | 17147 | 95.3 | 34 |
| 12 | 192 | 15434 | 80.4 | 29 |
| 13 | 137 | 6078 | 44.4 | 24 |
| 14 | 94 | 5764 | 61.3 | 37.5 |
| 15 | 160 | 9684 | 60.5 | 38 |
| 16 | 178 | 10832 | 60.9 | 32 |
| 17 | 132 | 9616 | 72.8 | 44 |
| 18 | 97 | 8494 | 87.6 | 35 |
| 19 | 66 | 7323 | 111.0 | 36 |
| 20 | 116 | 13628 | 117.5 | 37 |
| 21 | 109 | 14381 | 131.9 | 52 |
| 22 | 87 | 13104 | 150.6 | 54 |
| 23 | 115 | 10865 | 94.5 | 33 |
| 1日 | 2346 | 205006 | 87.4 | 34 |
首長竜(8),ネス湖(32),ネッシー(54),UMA(12),チャゲ(9), たき火(3), 鎖鎌(3),運転士(3),ペルー(3), 具体例(3),守護霊(3),個体(14), 青葉(13),トヨタ(7),徴用工(6), 一律(7),本質(25),フェミニスト(37), me(6),ゾンビ(6), 未(13), 辛さ(8),フェミニズム(17),学費(9),消滅(9), 謝る(6), 水準(6),生物(12),スタッフ(11),資産(10),韓国人(10),メディア(15),概念(17),寿司(12)
■なぜ皆「生活費以上のお金を稼ぐこと」にそんなに興味を持てるのか /20190905234604(27), ■ノーコメントっているの？ /20190906102044(15), ■フェミニストだけど質問ある？ /20190906170707(12), ■日本の人口10億人にしたい /20190906183425(12), ■どうしたらデキ婚できるかな。 /20190906131352(9), ■はてな民って超馬鹿だったんだな /20190905002238(9), ■世の中の謎設計、謎行動 /20190905230316(9), ■女子のリーダーに「お前それでもチンコついてんのかよ」って言われた /20190906111904(7), ■パワハラ研修を受けたけど、オレの感覚がおかしいのか？ /20190905231959(7), ■ /20190906102030(7), ■黒染め禁止でいいけどさ。 /20190906140902(7), ■ /20190906115705(6), ■名言格言は大体プログラマブル /20190905203132(6), ■Aという環境ならば人間はBをする みたいな情報が欲しい /20190905183211(6), ■紙の付録が作りたいんじゃ /20190906192605(6), ■営業をもっと敬えや /20190906221222(6), (タイトル不明) /20190906084217(6), ■危うく寿司屋で「ごめんなさい」するところだった /20190906022752(6), ■昨日、目黒女児虐待事件の傍聴をしてきた。 /20190906202317(5), ■anond：20190905230316 /20190906123852(5), ■増田にコテハンが生まれない理由 /20190905223653(5), ■なんか面白い本ない？ /20190906155933(5), ■ゾンビ映画ってゾンビを根絶しないまま終わるけど人類全員ゾンビになったらその後ゾンビはどうすんの？ /20190906165357(5), ■自分の意思で買った動物を野に放すクズはさぁ /20190906100230(5)
6582200(2764)
小学校で必須化されるプログラミング教育は激しく誤解されている。
小学校段階において学習活動としてプログラミングに取り組むねら いは、『プログラミング言語を覚えたり、プログラミングの技能を習得 したりといったことではなく』、論理的思考力を育むとともに、プログラムの働きやよさ、情報社会がコンピュータをはじめとする情報技 術によって支えられていることなどに気付き、身近な問題の解決に主体的に取り組む態度やコンピュータ等を上手に活用してよりよい社会を築いていこうとする態度などを育むこと、さらに、教科等で学 ぶ知識及び技能等をより確実に身に付けさせることにある。
これが学習指導要領になり、教科書になり、現場に降りてくると……
児童にコンピュータでプログラムを作成させるのはダメ！と忖度されて、アンプラグドな実践花盛り。
改訂第二版の例示では、スクラッチで作った「仮想プラグラミング炊飯器」が登場。ドリル教材なんだけどねぇ。
現場の先生に「プログラマブル○○シミュレーター」を製作しろってのも無理があるしなぁ。
文句があるならお前が作れとか言われそうなので……スクラッチでなんか作るのは無理でしたorz
お子様が大好きなカードでプログラミングして、EXCEEDMODEL ZAKU HEAD のモノアイを こいつ動くぞ！ にするぞ。
https://www.jiji.com/sp/article?k=2018111500727
今も値引きシール貼り換えして店員さん大忙しだけど（鮮度CHKや陳列整頓がてら…）、製造日〇〇日（あるいはロットとかシールのマークとか）は幾ら、と価格表を掲示することで、奥から取ったりされて徒労に終わったりしないし、なにしろ我々お客的に公平でしょう？
生鮮中食なら、価格表を数時間おきに書き換え・張り替えすればよいし。
いちばん大変なのはレジ（レジ装置）との連動よね（インストアコードに価格直入力とか無理になるから。レジこそクラサバ型とかデータプログラマブルなものとかに改良すべし）
アマチュア無線やFM放送によって法律に違反した電波帯利用、強度電波によって放送される無許可ラジオ。
当然ながらバレると摘発され罰金刑を貰うが、無線局の運営者が学生だったりすると注意だけで済むことがある。
アマチュア無線をやっていると「ラジオやったら面白いんじゃね？」と発想しやすいため(未成年なら尚更)、アマチュア無線全盛期ではかなり問題になった。
ただし、地域のアマチュア無線コミュニティが大抵は遵法派が多いので、地域のアマチュア無線コミュニティメンバーから摘発される前に無線上で注意することが少なくない。
クロスベアリング法などによって不法無線局(≒自宅)は簡単に割り出されるので、法律は守ったほうが良い。
この件で代表的なものは「FM西東京事件」が有名。運営者は大学生だった。
超極狭エリアでのみ受信できるFM放送で、実際のところコチラがサブカル放送のメイン。
大半が音楽を垂れ流すミュージック系ラジオであったが、普段は音楽を流しつつ、番組表を作りトーク系ラジオもやるという局もあった。
リスナーからのメッセージは郵便局に私書箱を設置して受け付けるスタイルがほとんど。
稀に地域のアマチュア無線おじさんがやる気を出し地域のイベントで情報提供を行う目的でラジオ放送したりするのに使われたこともある。
この特性から同人誌即売会などでもミニFMは限定的に開設されることも多々ある。コミケ参加者はバッテリ駆動できるFMラジオ受信機を持っていくと新たな楽しみが増えるかも知れない。
長らく個人によるサブカルメディア放送はミニFMが主要なプラットフォームであったが、ブロードバンドの登場によりミニFMからインターネットを通じて放送するPodcastへ移行する者が増えた。
WMAやMP3で収録し配信するスタイルは非常に気軽で様々なPodcastチャンネルが生まれたが、Podcastブームの煽りを受けてあまりにもPodcastチャンネルが生まれすぎて混沌と化す。
そして同時に今までリアルタイム放送をしていた者達からするとPodcastの感覚が掴めない、配信する環境を整えられないという欠点が存在していたので、Podcastにリスナーを取られたミニFM局が終了するなどが相次いだ(ミニFMの終焉の原因がPodcastかは不明)。
Podcastは全盛期よりもリスナーが減ったとは言え、幾度かの転換点を迎えて今日も続いている。
ブロードバンドの進化のお陰でリアルタイム配信が可能となったことで誕生した音声配信サービス。
日本では「らじおちゃんねる(後のねとらじ)」がブームとなり認知度が上がり、更にTVワイドショーで紹介され一部の一般人にすら認知されるようになった。
２ちゃんねるの実況板文化から派生したインターネットラジオを介した声によるTV放送実況は文字ベースの実況からの1つ転換点だったと言える。
極少数例ではあれど、ゲームを同時に起動してボイスチャットのように利用してMMORPGなどをプレイする用例や、ビジュアルノベルゲームをみんなでプレイするなどの用例もあった。現在で言うゲーム配信に近い。
こちらも全盛期と比較してリスナーは減っているが今日も続いているが、個人的な印象としてPodcastの方がリスナー人口は多いように感じる。
インターネットラジオが登場した頃にはミニFMはほぼ壊滅状態にあり、現在では極々一部の趣味人によってのみ期間限定で運営されていることが多い(有名な老舗もいくつかはある)。
様々なメディアを埋め込みつつ、プログラマブルなプラットフォームとして開発されたシステム。
２ちゃんねるを中心に爆発的流行をし、現在のWebクリエイターの中にはFlashで注目された者も居る。
現在でいうところの「コラボ」も数多く行われ、様々な表現の実験の場となり、今でも参考になる発想が多い。
企業Webサイトでの採用事例も多く、インターネットの一時代を築いたと言っても過言ではない。
現在は惜しまれながらもAdobeのFlashサポートの終了予定発表やHTML5の登場なども合わさり採用はゼロに近いものとなっている。
Youtubeに感化され、２ちゃんねる実況板の影響を取り込んだ動画に文字を表示するスタイルを確立したのがニコニコ動画。
当初は違法動画のアップロードサービスと化して居たが、MAD動画ブームを皮切りにクリエイティビティの発露の場として成立する。
Flashからの移行組も数多くおりニコニコ動画の黎明期を支え、次代にその技術を伝えた。
２ちゃんねるDTM板のVOCALOIDスレでしか注目されていなかったVOCALOIDが初音ミクの登場によりニコニコ動画で再評価され爆発的ブームが起こる。
初期のVOCALOIDは２ちゃんねらー全体で言えば知らない２ちゃんねらーの方が圧倒的に多い状態であり、何ならDTM板住人であってもDTMMagazine読者くらいしか知らないレベルであった。
更にはMikuMikuDance(MMD)の登場により、Flash時代ではマシン性能の兼ね合いで難しかった個人による3D表現が本格化。
現在のVtuberに近いMicrosoftKinectとの連携によってMMDモデルを動かす試みなどが始まる。
そしてニコ生がリリースされるとリアルタイムゲーム実況が確立され、現在のYoutube LiveやTwitchの萌芽とも言える状態だった。
一部では現在でいうところのVLOGを投稿する者もおり、様々な試みがなされた。
しかし運営側の迷走の伴いサービスのコンセプトや品質が陳腐化し、対応が後手になってしまいユーザが離れるという事態に陥った。
現在ではユーザ目線での改善に力を入れているらしく今後どうなるかが注目される。
そして現在、個人によるサブカルメディア放送はYoutubeがメインのプラットフォームへとなっている。
特徴的なのがニコニコ動画では登録者すべてがいわゆるニコ厨と呼ばれていたのだが、Youtubeでは動画投稿者がYoutuberで視聴者がリスナーと呼ばれている点である。
ニコニコ動画からコンテンツをそのまま移行したYoutuberも数多いが、元々ニコニコ動画へ投稿していた者は実写系が少ないという特徴がある(一部例外も居る)。
ニコニコ動画が自らコケたという部分もあるが、堅実に強化とユーザビリティの向上に努めたYoutubeは日本のサブカル層も無視できなくなり、今日のYoutube人気を決定付けた。
ニコニコ動画時代では少なかった顔出し実写系動画が増えたり、マシン性能の向上によって実現を果たしたVtuberの登場など個人によるサブカルメディア放送は転換点にあると言って良い。
プラットフォームの移行が発生するかはわからないが、これまで顔出しを拒んできたサブカル層が徐々に顔出しするという動きが昨今では起きている。
日本ではこれまで大手メディアの影響などにより社会全体でのオタク蔑視の時代があったりなど海外に比べてサブカル層は顔出ししにくい環境であったとされてきたが、世代交代が進んできたのかサブカル層の顔出しが起きている。これは良い環境変化だと言える。
この次に何が起きるか？と言えばおそらくは「実名活動・顔出しの敷居がより下がる」程度にしか予測はできないが、様々な選択肢が増えることは歓迎したい。
視点を変えれば旧来のサブカル層が若い世代が持つ印象に救われつつあるわけだが、その若い世代に技術を継承したのは何だかんだで活動を続けてきた旧来のサブカル層なので、今後とも持ちつ持たれつという関係を築けていけたらなと思う。
そして続けて現れる今の若いサブカル層の技術を継承した次代・次々代の子たちがどんな風にクリエイティビティを発揮するか楽しみでならない。
IMEはinput method editorの略称で、機能としては「かな漢字変換」だけを有するものと思われているが、
ATOKのような多機能なIMEのばやい、もっと広い用途に使っている人も数多い。やばい業界人であれば、
ATOK is launcher.は、Yes We canに比肩するくらい、もはや常識と言って良いくらいだ。
詳細な実用例は他誌に譲るが、単語コメントを用いれば、言葉の辞書的な意味、注意点、豆知識などかなり広範な用途に利用できるのは知っておいて損はない。
また、辞書ファイルからの単語一括登録によって、プログラマブルな辞書登録も可能と言える。近年では、ATOK Syncも地味な盛り上がりを新たに見せている。
とりわけ、受験生は学習のお供にATOKを活用するといいだろう。ATOKと連携したジーニアス電子辞典を活用できるだけでなく、
上記のランチャー的使い回しを覚えておけば、今後の人生勉強にも活用できることは請け合い。
電子辞典しか使わない人間には、語学学習に役立つ程度の認識だろうが、決してその応用範囲は語学にとどまるものではない。
老婆心ながら一点言い添えておくが、一括登録でマージされた辞書ファイルは、
ATOK2013であれば、%UserProfile%\AppData\Roaming\Justsystem\Atok26\ATOK26U1.DIC 等に保存されている。
これを単語の一括出力により、単語コメ含め全単語の全情報をテキストファイルに変換でき、これなら他ソフトと整合を保ちやすい。
そんでもって、Microsoft は持っている。僕同様、みんなも知ってると思うけど、なんと驚くべきことに、Microsoft はそれをよく理解していない。実に。でも彼らは、純粋に、偶然、プラットフォームを提供するビジネスから始まって成長してきたから、プラットフォームを分かっているんだ。彼らはその領域で30数年やってきた。msdn.com に行って、少しの間ブラウジングしてみればわかる。もし見たことが無ければ、驚く準備をしておいた方が良い。なぜならそれがとてつもなく巨大だからだ。何千の、何千の、何千ものAPI コールがある。彼らは巨大なプラットフォームを持っている。実際の処大きすぎて、全く統率が取れていないけれど、少なくとも彼らはやっている。
Amazon は自分のものにしている。Amazon のAWS （aws.amazon.com ）は途方も無くすばらしい。行ってみてご覧よ。クリックして回ってみるんだ。全く恥ずかしくなる。僕らはこれらのひとかけらも持ち合わせていない。
Apple も、明確に、自分のものにしている。彼らは基本的にクローズな選択を、特にモバイルプラットフォーム周りでしているけれど、アクセシビリティを理解しているし、サードパーティ開発者の力もよく分かっていて、自分たちのドッグフードを食べている。それでさ、わかるだろ？。彼らは実に見事なドッグフードを作る。彼らのAPIコールはMicrosoft のそれに比べて実にクリーンで、ずっと昔からそれを維持している。
Facebookも持ってる。だからこそ心配になるんだ。ぐうたらな僕をここまでして書かせた理由はそれだ。僕は元来ブログするのも、プラスする（って言うのかどうか知らないけど）のも嫌いだ。そもそもGoogle+はぶっちゃけ話をするのにはひどい場所だけど、とにかくやらなきゃならない。Googleに成功して欲しいと思ったらね。で、僕は成功して欲しい！。まあ要はFacebook が僕を呼んでいるし、きっとそっちでやるほうがずっと楽なんだろうけど、Google は僕にとって家だし、だからこういう家族同士のお節介焼きのようなことをやっていこうよと言ってるわけだ。（訳注：この辺の訳怪しい。トラバで指摘いただいたのがすてきだったのでまるっと差し替え！。"アドバイス"thx ！）
Microsoft とAmazon 、それにFacebook （たぶん。実際僕はよく見ていないんだ。だってすごく落ち込むからね…）の提供するプラットフォームに驚いた後に、 developers.google.com に行ってちょっとブラウズしてみて欲しい。ね？大きな差だろう？。まるで君の5年生の甥っ子が、巨大で強力なプラットフォーム企業がもしリソース的に独りの小学5年生しか人を割けないって時に作るようなものをデモしてみなさい、なんていう宿題でもでっち上げたみたいな感じだよ。
どうか悪く思わないで欲しい。 Developer relations チームが、これを外部に提供できる形にするためにとんでもない努力をしてきたってことを僕は分かっている。僕が知る限り、彼らはとにかくケツを蹴り上げつつけている。なぜなら彼らはプラットフォームを理解しているからさ。プラットフォームに対して実に冷淡で、しかも時には敵対心さえあらわにされるような環境の中で、彼らは英雄のように努力している。
僕は率直に、 developer.google.com が外部の人にとってどう見えるかを説明しているだけさ。全く幼稚に見えるだろう。 MapsAPI は一体どこにあるっていうんだ？。いくつかはなんだかよくわからないラボプロジェクトとやらに入っている。で、いざたどり着いてみれば、そこにあるAPI は全くけちな代物だ。まさに本当の意味でドッグフードだ。オーガニックなんかとは無縁だね。僕らの内部API に比べれば、まるで不格好な別物だよ。
Google+ についても、悪く思わないで欲しい。到底彼らだけが違反者ってわけじゃない。文化的なものが絡んでいるんだ。僕らが内部でやってることっていうのはさ、基本的には、惨めでマイノリティなプラットフォーム部隊が、無敵で予算も自信もたっぷりのプロダクト部隊に多かれ少なかれ負け続けている、そんな戦争なんだよ。
ゼロから構築したプログラマブルなプラットフォームになるべきなんだってうまく気づいたチームってのはみんな弱者さ。 Maps やDocs なんかが思い浮かぶ。Gmail もなんとなくそっちの方に進みはじめたように見える。でも彼らがそのために予算を獲得するのは実に難しい。なぜなら、それは僕らのカルチャーじゃないんだ。 Maestro の予算なんか、 壮大なMicrosoft Officeプログラミングプラットフォームの足下にも及ばないちっぽけなものだ。ふわふわ毛皮のうさぎちゃんと、T-Rex の対決みたいなものさ。Docs チームだって、このスクリプティング機能が無ければ Office に太刀打ちできないってのはよく分かっているんだ。でも残念なことに、予算が付かない。つまりさ、そうじゃないとは思うんだけど、現状 Appsスクリプトが Spreadsheet だけで動作して、API の一部としてキーボードショートカットすらない。まさにチームが愛されていないって思うしか無いよね。
皮肉にも、Wave は偉大なプラットフォームだった。冥福を祈りたい。でもプラットフォーム的な何かを作るっていうことは、そのまますなわち成功を意味するって訳じゃあ無い。プラットフォームにはキラーアプリが必要だ。Facebook そのもの（つまり、 wall やらfriends やらなんやらというデフォルトの機能）が、Facebookプラットフォームのキラーアプリだ。そして、Facebookアプリが、Facebookプラットフォーム無しで成功できると結論づけるのは、深刻な誤りだと僕は思う。
みんなは、外の人たちがGoogle は傲慢だって言い続けているの、知っているよね？。僕はGoogler だ。だから、みんなと同じように、外の人たちがそう言っているといらいらとする。僕らは全般的に見て全く傲慢じゃ無い。僕らは、まあ、99%は傲慢じゃない。僕はこの文章をこう始めた（遠い記憶をさかのぼってよ）、Google は「正しいことだけをする」って表現した。僕らはよかれと思ったことだけをしている。だから、人々が僕らが傲慢だって言うときは、まあ大抵彼らを雇ってあげなかったときか、僕らのポリシーに不満があるか、まあそんなようなところじゃないかな。彼らはそれで気分が良くなるから、傲慢だ傲慢だと言っているんだろう。
でも、もし僕らが、僕らは全ての人に対して完璧なプロダクトをデザインする方法を知っているだなんて、そんなスタンスを取るんだとしたら、僕を信用してくれて良いと思うけど、結構そういう話を聞くんだけど、僕らは飛んだ間抜けになる。それを傲慢って言ったり、無邪気さって言ったり、なんて言ってもいいけど、結局の処、それは愚かさに他ならない。全ての人にとって完璧なプロダクトなんて、無いんだ。
デフォルトフォントサイズを設定できないブラウザについて話してこの話題を締めくくろうか。アクセシビリティへの侮辱ってやつについて語ろう。つまり、いずれ僕は年を取って、ほとんど目が見えなくなる。事実そうだと思う。僕は人生でずっと近視だったし、40歳にもなれば今度は近いものが見えなくなる。そうなればフォントの選択ってのは生死を分ける重要なポイントだ。それは君を完全にその製品から追い出してしまう。ところがどっこいChrome チームってのははっきりと傲慢だから、彼らはゼロコンフィギュレーションプロダクトなんて言ってて、まったく厚かましくも、もし目が見えなかったり耳が聞こえないなりなんなりするなら、お前はファックユーだぜってなもんだ。残りの人生、全てのページを表示する度に Ctrl-+ を押せって言うんだよ。
これは彼らの問題じゃ無い。みんなの問題だ。僕らが徹底してプロダクト企業だということが問題だ。僕らは広くアピールするプロダクトを作った。例えば検索がそうだ。そのあまりにもひどい成功が、僕らの目をくらませてしまった。
Amazon もまたプロダクト企業だった。だから。 Bezos にプラットフォームの必要性を理解させるのには、外部の力が必要だった。その力ってのはどんどんと蒸発していく利幅だった。彼は追い詰められて、脱出方法を考えなければならなかった。でも彼の持ちえたものは、エンジニア達とコンピュータの群れだった。そこからどうにかマネタイズするには…？。結果論だけれど、そうして彼はAWS にたどり着いたわけだ。
Microsoft はプラットフォームとして始まった。だから彼らにはたくさんの習慣があった。
でも、Facebook は…、彼らは僕を不安にさせる。僕はエキスパートではないけれど、でも、彼らは最初プロダクトとしてスタートして、そしてそれをうまく成功につなげていたことは確かだ。だから、彼らがどうやってプラットフォームへと変革を遂げたのか、僕にはわからない。それは比較的昔のことだったろうと思う。Mafia Wars のようなものが現れる前に、彼らがプラットフォームにならなければならなかった時よりもずっと昔。
たぶん彼らは僕らを見て、こう自問したのかも知れない。「どうやったらGoogle を倒せる？。Google に足りないものはなんだ？」
僕らが直面している問題はとても大きい。僕らがキャッチアップを始めるには、めざましい文化的な改革が必要だ。僕らは内部的にもサービス指向なプラットフォームを持っていないし、同じように外部的にもそうだ。この「自分のものにしていない」感じは、まさに会社全体を覆う風土病だ。PM は分かってない。エンジニアも分かってない。プロダクトチームも分かってない。誰も分かっていない。たとえ一個人で分かっている人間がいたとしても、もしそれが君だとしても、僕らがそれを総力を挙げて緊急事態として扱わなければ、これっぽっちも意味が無いんだ。僕らはプロダクトをローンチして、それを後から魔法のように美しい外部拡張可能なプラットフォームに成長させられる、そんなふりをし続けることを、やめなければならない。何度もやって、だめだったじゃないか。
プラットフォームの黄金律「自分のドッグフードを食べろ」はこう言い換えることができる。「プラットフォームから始めろ。そしてそれをなんにでも使え」（訳注："アドバイス"thx ！）。後からちゃんとやるなんて不可能だ。少なくとも、簡単には無理だ。MS Office をプラットフォーム化した人たちに尋ねてみればいい。あるいはAmazon をプラットフォーム化する為に努力した人たちに。遅れてしまえば、正しく立て直すのに10倍の苦労が必要になるだろう。ごまかしはできない。内部アプリが特別な優先アクセスを受けられるようなバックドアを秘密に仕込むなんて、どんな理由があっても不可能だ。難しい問題から、まず最初に解決しなければならないんだ。
僕は遅すぎると言いたいわけじゃ無い。けれど、待てば待つほど、致命的な遅れへとどんどん近づいてゆく。
この記事をどう纏めて終えればいいか、正直よくわからない。言うべきことは全て言ったと思う。この記事はできあがるのに6年かかっていると言える。僕が紳士的ではなくて申し訳ないと思う。プロダクトやチーム、個人を僕が誤解していたら申し訳ないと思う。もし僕らがたくさんのプラットフォームを実は作っていて、僕や、僕が話した人たちみんなが偶然知らないだけだったとしたら、申し訳ないと思う。
でも、僕らは今すぐに始めないとならない。
この努力は僕がGoogle に来る為にAmazonを離れた2005年半ばも続いていた。でももっとずっと進化していたよ。 Bezos が命令を出してから僕が離れるまでの間に、Amazon は全てにおいてまず最初にサービスを考える企業へと文化的に変化していった。外部の日の目を決して見ることの無いような、スタッフへの内部的なデザインも含めて、今ではそれがデザインというもの全てに対しての基本的なアプローチになっている。
その時点では、彼らはもはや解雇の恐怖からそうしているわけではなかった。つまり、もちろんビビってはいたけれど、ドレッドヘアの海賊 Bezos 様にご奉仕するのは日常生活の一部だからね。そうじゃなく、彼らはそれが正しいことだと理解したから、サービスを提供しているんだ。確かにSOA のアプローチには長所も短所もあるし、短所を書き出してみたら切りが無い。でも全体として、SOA ドリブンのデザインというものこそが、プラットフォームを可能にする、これは正しいことだ。
これが、 Bezos が彼の指令書で企んだことだった。彼はチームの健康状態なんて興味もなかったし（今もそうかも）、使われている技術もそうだったし、結局の処のどう取りかかるかなんて結果ができあがるまで気にもしていなかった。けれど Bezos は、Amazon社員の大多数が理解する前に、Amazon はプラットフォームにならなければならないということを悟っていたんだ。
だって考えてもみてよ。なんで一オンライン書店が、拡張可能な、プログラマブルなプラットフォームになる必要がある、なんてことを考える？。そうだろ？
ともかく、 Bezos が気づいた最初の大きなポイントは、本を売り、出荷し、色々とやる仕組みが、素晴らしいコンピューティングプラットフォームに再利用でき得るということだ。だから今、彼らにはAmazon Elastic Compute Cloud があるし、Amazon ElasticMapReduce があるし、Amazon Relational Database Service があるし、その他たくさんのaws.amazon.com で見つけられるサービスを持っている。しかもこれらのサービスは大成功した企業のバックエンドを努めていたりもする。reddit なんか僕のお気に入りだね。
もう一つ、彼が理解した大きなポイントは、常にいつでも正しい、そんなものを作ることはできないということだ。これは Larry Tesler が、ママはこのくそったれサイトを全く使えないよと言ってのけたりでもした時に、 Bezos にピンと来るものがあったんだと思う。誰のママのことを言ったのかははっきりしないし、そんなことは問題じゃ無い。問題は、誰のママだろうとそのウンコサイトを使えないってことだ（訳注：アドバイスthx ！）。実際、僕自身、そこで5年ほど働いていたわけだけど、あのサイトは胸がザワザワするくらいひどいと思う。でも僕はその気が散るようなサイトに慣れてしまって、トップページのど真ん中あたりの数万ピクセルに集中できるようになったんだからね。
とまあ、実際の処 Bezos がどうやってその理解、一つのプロダクトで、全ての人にとってふさわしいものを作り上げることはできないということに、たどり着いたのかは定かじゃあ無い。でもその方法は問題じゃ無くて、彼は理解してるってことが重要だ。実のところこの現象には正式な名前だってある。そう、それはアクセシビリティと呼ばれるものだ。コンピューティングの世界で最も重要なものだ。
君は思うかも知れないね。「はあ？つまりそれって、目が見えない人や耳が聞こえない人のあれ？あのアクセシビリティ？」ってね。まあ君だけじゃないと思う。とにかく世間には、アクセシビリティってものを正しく理解していない、君みたいな人たちがいっぱいいっぱいいるんだから。ただそこにたどり着いてない人たちがね。だから、アクセシビリティを理解していないのは、目の見えない人や耳の聞こえない人や手足が不自由な人やその他障碍のある人の責任じゃないように、君の責任じゃない。ソフトウェアが（この場合アイデアウェアといった方が正しいかもしれない）何らかの理由で誰かにとってアクセシブルでないというとき、それはソフトウェア自身の、あるいはアイデアの伝え方そのものに責任があるんだ。それがアクセシビリティの失敗というやつなんだ。
人生における重要なその他もろもろと一緒でさ、アクセシビリティには邪悪な双子がついている。小さいときにパパとママの偏った愛情で見捨てられて、今や同じくらいの力を持つまでに育った宿敵って奴がね（もちろんアクセシビリティには宿敵はたくさんいる）。それはセキュリティだ。一体全体こいつらが仲良くやっていること何てあるかい？
でも、僕は主張したい。アクセシビリティは実際の処セキュリティより重要だということを。だって、アクセシビリティを0にダイアルするってことは、何のプロダクトも持たないってことさ。セキュリティを0にダイアルしたって、そこそこのプロダクトを持つことはできるだろう？Playstation Network みたいにさ。
まあつまりですね、僕はみんなが分かってくれないんだったら一冊丸々この話題で本を書くことだってできるよ。分厚くて、僕が働いてた会社のありんことピコピコハンマーのエピソードで一杯の面白いやつをね。でも僕がこの話を公開しなかったら、みんなが目にすることも無いだろう。そろそろまとめに入らなきゃ。
Google がうまくやれていない最後の一つは、プラットフォームだ。僕らはプラットフォームを理解していない。僕らはプラットフォームを自分のものにしていない。みんなの中にできている人はいるだろう。でも、そんな君はマイノリティだ。辛いことだけれど、これはこの6年で僕にはっきりと感じられた。僕は競争相手のプレッシャー、Microsoft やAmazon や最近じゃFacebook なんかが、僕らを一斉に目覚めさせて、ユニバーサルにサービスを始めるのを期待したりもした。アドホックな、中途半端なやり方じゃなくて、多かれ少なかれAmazon がやったようにだ。一度に全てを。マジで。偽りなしに。今その瞬間から最優先事項として扱うというように。
でも、そうはなっていない。10番やら11番めくらいのプライオリティだね。いや15番かも？。知らないけど、とにかく低い。真剣に取り組んでいるチームもいくつかあるけど、多くのチームは考えてもいない。一度もだ。ごく一部の人々がちょっとした規模でやっているだけだ。
多くのチームに、彼らのデータと処理に対してプログラマティックにアクセスできるような、ちょっとしたサービスを提供させるのだって大変だ。彼らのほとんどは、俺達はプロダクトを作っているんだ、って思っているからね。そんでもってそのちょっとしたサービスなんてのはみじめなもんさ。Amazon の教訓に戻ってリストを見てくれよ。そんで今すぐ使えるサービスを持ってきて見てくれ。僕が知る限りでは、そんなものはない。小ビンってのは便利かもしれないけどさ、そんなの車がいる時だけだろ？（訳注：この人、 Stubby という小瓶のビールと、 stubby という「ちょっとした・不格好な」という形容詞をひっかけてしゃべってます）
プラットフォームが無ければ、プロダクトなんて使い物にならない。いやもっと正確に言うならば、プラットフォームの無いプロダクトは、いずれ同等の機能を持ったプラットフォーム化されたプロダクトに、取って代わられる。
Google+ ってのはまったくまさに、エグゼクティブリーダーシップのとても高いレベルから（やあ Larry 、 Sergey 、 Eric 、 Vic 、やあやあ）枝葉の使いっ走りまで（やあ、君だよ）、全くプラットフォームを理解していないっていう良い例だ。そう、僕らはみんな、全く理解できていない。プラットフォームの黄金律ってのは、自分のドッグフードを食えってことだ。Google+プラットフォームってのは惨めなまでに後知恵だ。ローンチ時には一つたりともAPI が無かった。そんで最後にチェックしたときには、僕らが提供してたのはわずかばかりのほんのちっぽけなAPI さ。ローンチの時、あるチームのメンバーが行進してきて僕にそれを説明してくれた。だから僕は訊いたんだ「でさ、これはストーカー用API？」って。彼女はむすっとして、「ええ」ってだけ言った。いやジョークなんだよ…いや…ジョークじゃ無いんだ…僕らが提供する唯一のAPI は、誰かのストリームを読み出すだけ…。うーん、僕が間違ってたのか？
Microsoft はこの20年間ドッグフードルールで知られてる。この時代の彼らにとっての文化の一つなのさ。デベロッパにドッグフードを食わせて、僕らだけ人間のご飯を食べようってわけにはいかない。それは単に短期の成功のために長期のプラットフォーム価値を損なう行為だ。プラットフォームってのはまったく長期的な視点が必要なんだよ。
Google+ は脊髄反射の代物さ。Facebook が成功したのは、彼らがすばらしいプロダクトを作ったからだって言う、まあ実に近視眼的なものの見方の結果として生まれたものだ。でももちろん彼らが成功したのはそんな理由じゃ無い。Facebook は他の人たちにも何かをさせてあげられる、プロダクトの美しい集合全体を作り上げたから、成功したんだ。だからFacebook はみんなにとってそれぞれ違うものだ。Mafia Wars に全ての時間を費やす人もいれば、Farmville で遊ぶ人もいる。何百の、いや何千の、質の高い、暇つぶしができるってわけさ。つまり、みんなのためにふさわしい何かが必ずあるんだよ。
僕らのGoogle+ チームは、プロダクトを出した後のマーケットを見てこう思った。「おっとっと、我々もいくつかゲームが必要みたいだな。さっそくどこかと契約して、我々のために作ってもらおう」。これが信じられないくらい間違った考え方だってことが、君にもわかってきたかい？。問題なのは、僕らが、人々がほしい物を予測して、それを提供しようとしているということだ。
そんなことは出来ないんだよ。現実的にはね。確実にやる方法なんてない。もちろんコンピューティングの歴史全体を見渡せば、それを確実に信頼性を持ってできる人間ってのがごく数人いることにはいる。Steve Jobs がそうだろう。でも、僕らの処にはSteve Jobsはいない。悪いけど、いないんだよ。
Larry Tesler は、 Bezos がSteve Jobs じゃないってことを口説いたかもしれない。でも Bezos には分かっていた。全ての人にふさわしいプロダクトを提供する為に、彼がSteve Jobs になる必要はないっていうことを。インターフェースとワークフローこそが、人々が気に入り、安心感を得るものなんだっていうことを。彼はサードパーティの開発者にそれを可能にするだけで良かった。そうすれば、後の事は自動で進んでいく。
僕の言っていることが、あまりにも明白なことだろって感じているみんな（多かったらいいな）には申し訳ない。とにかくもうびっくりするほど自明なことなんだ。ただ、僕らがそれをやってないってことを除いてはね。僕らはプラットフォームを理解していない。プラットフォームを持っていない。アクセシビリティを理解していない。アクセシビリティを持っていない。これらは基本的には同じことだ。なぜならプラットフォームがアクセシビリティを解決するからだ。プラットフォームがアクセシビリティなんだよ。
