気がついたら21万人が利用するサービスを作っていた話
最近Twitterでめちゃめちゃバズって色々考えたり思い出すことがあった。
僕がインターンとして働いている会社で一年前に社内の様子をPRする記事を作成するために、インタビューを受けていた。そのときに、
インタビュアー:「今年1年の目標は何にしたい?」
僕:「10万人が利用するWebサービスを作ります!」
って言っていたのをふと思い出した。で、こないだ作った視認可能フレーム計測ツールのユーザー数を見たら21万人が利用していたので、一応目標達成していたことに気づいた。
今までにも似たような現象がたくさんあって、例えば小学校の卒業時にはロボットを作りたかったので「将来エンジニアになります!」と言っていたし、3年前は「Webサービスを作る」って宣言してなんだかんだ作りきった。一番最初にリリースしたWebサービスは2018年3月にリリースしたタイ人向けのサービスだった。
こうして並べてみると有言実行に映るかもしれないけど、実は全く意図していない。ほんとに「そういや俺あんなこと言ってたな〜」ってくらい。自分が気づかないうちに目標達成していた。
なんで有言実行が結果的にできているんだろうと考えたときに、自分にどんな習慣があったのかをちゃんと言語化しておこうと思った。
やりたいって思ったことのアウトプットは死んでも絶対出すこと
まず、やりたいって思ったことのアウトプットは死んでも絶対出すこと。これをやらないと市場に評価されることは100%ありえない。
フィードバックを受けない限り自分のアウトプットがアップデートされることは絶対にないし、一方で一度のアウトプットが慣れると2度目3度目以降の質は劇的に改善される。
最初はめちゃめちゃ緊張する。というか、自分以外の人にリアルな評価を受けるってものすごく怖い。このアウトプットに取り付く恐怖を克服する方法は今の所気合しか思い浮かばない。
だからこそ、とりあえずやってみる精神はめちゃくちゃ大事だと思う。捉え方によっては、自分が過去に出したアウトプットを下回るクオリティのものは出ないだろうから、自分の能力の最低水準を引くためにもとりあえず出すってのは重要だとも考えられる。
そうしたほうが幾分かは気が紛れる気がする。
受託開発で消耗して、消耗しないよう受託開発すること
これは本当にやって正解だった。受託開発って聞くと下請けという印象が強くてダサい印象が人によってはあるかもだけど、受託開発ってめっちゃ大事だと思う。特に、能動的に受託開発ができるか、受動的に下請けになるかは天と地ほどの差があると思う。
まず、なんでやってよかったのかというと、価値があるシステム開発とは何かを考えられるようになった。僕が思う価値あるシステムの定義は、「継続して利用するユーザーが1人でもいるシステム」だ。(これは今の定義。もしかしたら今後アップデートされるかも)
僕は今までインターン先でかなりいろんなツールを作ってきたけども、社内受託開発をしていた時期は作ったけど誰も使ってくれなかったことがたくさんあった。
せっかくわざわざ作ったのに誰にも触られないってめちゃめちゃキツくて、「俺なんのために労力割いて作ったんだろ」とショックを受けまくった。
そうした苦い経験のおかげで、どうしたら使われるプロダクトを作れるのかを必死こいて考えながら受託開発を行うようになった。既存の代替手段はあるか、利用者のスケールはどの程度か、利用者が使いやすいインターフェースになっているかなどなど。
結果、需要があり且つ利用されるツールやサービスをコンスタントに出力できるようになった。
もちろん、そうしたアウトプットを出力するための工夫を凝らしていたときに、「君は私の言うものだけをただ作ればいい」と言われることがあったけど、僕は絶対にやらなかった。そうして平然と依頼してくる人とは思いっきりケンカしたこともあった。プロダクト開発は自分のほうが圧倒的にプロだと思っていたし、何度もお客さんのところに足を運んだこともあるし、何よりクソみたいにクソみたいなアウトプットを散々していたからよくわかっていた。
おかげで、そんな脳死状態で作ったって誰にも使われないプロダクトが出来上がることは経験上知っていたから。相手が社会人としてのキャリアが長いとか、自分よりずっと年上だとか関係ない。自分には事実として経験したものがあって、その上で考えて出した結論だから間違っていると思わなかった。曲げる必要はなかった。
結果それは正しかった。
何度も諦めてもいいけど、何度も再チャレンジすること
僕は何度もプログラミングの勉強で挫折をした。Twitterの運用やサービス開発も去年似たようなことをやっていたけどうまくいかずに失敗ばかりして、誰も見ないようなアウトプットを出力しまくっていた。
その当時は諦めた。だけど、結局再挑戦した。最初は地道にGoogle Apps Scriptを触り始めて、次にPHPやネットワークの周辺知識を教えてもらう機会を手に入れることができた。おかげでWebサービスやアプリを作れるようになったし、触ったことがない言語でもドキュメントを見ればだいたい使い方がわかるようになった。
技術的な記事や書籍を読んで、コンピューターのアーキテクチャやインフラストラクチャも知識として吸収できるくらい基礎的な知識が身についた。
Twitterに関してもそうだ。フォロー・フォロワーの増やし方に関してはまだまだ分析できてないけど、少なくとも「これはこのユーザーにはバズりそうだ」みたいなのは狙えるようになった。受託開発のおかげで何がユーザーにとって利用価値があるかの判別の目がついていたから。
何が言いたいかというと、僕は最初できなかったとしてもとりあえずアウトプットしてみて、何度やってもうまくできなかったら諦めてもいいと思う。一回諦めて挑戦しない時間を作ることで休憩できるし、考えることができる。勉強する時間も作れる。
その一方で、時間を置いて再挑戦するのが大事だと思う。改めて挑戦してみると意外と発見があるし、すんなり壁を突破していたりする。
たぶん、失敗した経験があまりに悔しくて、諦めていた間に知らず知らずのうちに学習していたんだと思う。しかも、一度なにかにのめり込むとそれしか見れなくなって、人の視野はだいぶ狭くなるから、一度離れたうえで再度見直すのは発見があるんだろうなと思う。
終わりに
実は最近、イラストやデザインできる人が羨ましいなぁって思うことがあった。だって「絵を書くだけでこんなに評価されるんだいいなぁ」って。でもこの考えはすぐに軽率だなと思った。彼らもめちゃめちゃ努力して絵を出し続けた結果そうした評価を受けられるようになったわけだし、コードを書いてプロダクトを作る僕にはわからない苦労がきっとあると思った。
しかも、彼らの多くは僕のようにコードを書いてプロダクトを作ることはできないし、何よりコードを書くっていう手段だけで大勢に評価されるアウトプットを出せる人がいるのに、当時そうではない僕が絵を勉強したところで絵で評価されるようになるわけがないと思った。
ないものねだりしても仕方ない。今ある能力をフル活用できなければ、どれだけスキルが増えたところで大勢に評価されるものは作れないなと開き直って、今ある能力でしばらくどうにかやっていこうと思う。
視認可能フレーム計測を作って公開2時間で利用者3000人達成する前・後で思ったこと
謝辞
まずはブログに遊びにきてくれてありがとうございます。 ツールを使っていただいた皆さん、本当にありがとうございます。めちゃめちゃ喜んでいます。シェア、RTしていただいて本当に感謝しています。プロゲーマーの方々にも利用していただき、本当に嬉しく思っています。
また、僕の書いたプログラムや、僕がしっかり対応できていない端末で使ってみて、低いレートでがっかりさせてしまった方には本当に申し訳ありません。計測とはいえあくまで簡易的な目安で、状況次第では非常に遅くなることがあるので、できればあまり気にしないで欲しいです。
このブログの概要
実はこの度、大乱闘スマッシュブラザーズSPが好きなプレイヤーがどれだけフレームを視認できるかというツールを作ってみました。 silly-hawking-704109.netlify.com
フレームがわからない方は下記を参照 kotobank.jp
結果、公開2時間後めちゃめちゃバズってピーク時には3000人を超えました。
ので、なんでこの現象を起こすことができたのかを忘れないうちにちゃんと言語化して、あとで自分が思い返せるときに思い返してみようと思い、この記事を書きました。
まずは軽く自己紹介
今は都内の大学に通っている4年生です。プログラミング自体は2年前からやっていて、最近はスマブラのオフ会にお邪魔したり、授業の間にこうしてプロダクト開発をしていたり、たまにYouTubeで配信していたりします。
ゲーム垢:HAYATE (@hayate_inkling) | Twitter
独り言アカウント(今後はこっちを本垢にしたい): 田畑颯 (@hayatetabata) | Twitter
GoogleAds(旧GoogleAdWords)やFacebook、TwitterなどのWebの広告運用も2年近くやっていたので、Web広告に関しても知見がそこそこあります。
趣味は言うまでもないよね!?
なぜ開発に至ったか
このツールを作ろうと思った背景として、プロトバナムさんというスマブラ界隈上位プレイヤーの一人のあるツイートのリプライをひたすら見て勉強していた。
この中でどのツイートに対するリプライかは忘れてしまったけど、今日の19時までのリプライだったら、時間がある時に返信を返しますので質問ある人はどうぞ!
— ProtoBanham/プロトバナム (@SSBU_Lucina) May 20, 2019
・自キャラは書いてね。
・質問は一人1個か2個まででお願いします。#プロトバナムの質問コーナー
「相手キャラが走って攻撃してくるときに自分が視認できるフレームを覚えていたほうが良い」
ほ〜そうなんだ。でも、どうやって計測するんだろう。。。。 実際にはゲーム内にあるトレーニングモードでやるらしいが、よくわからなかった。
実際に「視認フレーム 計測」でググっても全然見つからなかった。これどうすればいいんだろうと思った。
「あれ、自分で作ればいいんじゃないか?というかこれ絶対バズるよね?」 そう思ったらすでにパソコンを開いていた。
なぜここまでバズったのかを紐解いてみた
なぜここまでバズったのかを自分で考えて紐解いてみた。
既存の解決策があるのか?(ここ重要)
まずこのツールはスマブラをかなりガチでプレイしているプレイヤーには需要があると思っていた。特に上位プレイヤー同士はわずかなフレームの違いによって勝敗が決まることもあるらしいし、技のフレーム数は覚えているようだった。
また、自分が反応できる範囲とできない範囲を認識してケースに合わせて対策を取ったりするケースがあるとのこと。なので、自分が反応できるフレーム数を覚えておく必要があるそう。
それに対して既存の解決策はある。キャラクターの攻撃を見てからガードをするフレーム数を測ることだ。大乱闘スマッシュブラザーズSPにはコマ送りという機能があり、フレーム数を調べることはできるが、計測までがややめんどくさい。しかも、僕のような新参プレイヤーにはやり方がわからないのである。だから、需要があると思った。
僕がここで書き残しておきたいのは、既存の解決策があるということは、その手段以上に別の便利な解決手段があれば必ず代替できる。だって困ってるからね。困ってる問題は何がなんでも解決したい。
逆に既存の解決手段がないということは、ユーザーは死ぬほど困ってないから時間をかけて対応しなくていい。これめっちゃ大事。僕は一時期これに時間を掛けすぎてめちゃめちゃ疲弊したので、本当におすすめしない。
使ってもらえるor広めてもらえるフォロワーがいるか?(これ超重要)
これめちゃくちゃ重要。本当に大事。
改めて思ったけども、Twitterでのフォロワーの影響力はものすごく大きい。自分が伝えられる以上に情報を伝えてくれるし、何かよくないことがあれば教えてくれる。一緒にモノを作るという点ではフォロワーには本当に助けてもらっていると思った。
一方、興味を持ってもらえない内容については広まることはほとんどない。たぶん僕が昨日食べた晩ごはんのメニューのツイートをしても広まることはないだろう。
ちゃんとフォロワーが関心を寄せてくれる内容になっているかどうかはしっかり抑えないといけないと思った。
ちなみに僕は昨日カレー食べました。
簡単に見つけられるか?
その上で調べてみたところ、該当するツールが簡単に見つけられなかった。
もしかしたらこの世のどこかにあるかもしれないけど、少なくともGoogle先生は全然教えてくれなかった。 仮にこの世に存在していたとしても、ユーザー視点から見ると存在しないように見える。だから、簡単に見つけられない情報があるならそれはチャンスだと思う。
簡単に利用できるか?
当然だけど、このツールはユーザー登録はない。
だって登録めんどくさいよね?僕も極力登録したくない!
だから、すぐに利用できる・登録が手間じゃないという部分については今後作るツールもものすごくこだわると思う。UIMilkなんかの記事を読んでても、ユーザーへの利用障壁は極力減らさないといけないって書いてるし。
しかもボタン押すだけ。本当にそれ以外機能はない。 これについてはまだまだ研究したいけど、インターフェースややれることは極力シンプルにしないとユーザーには使ってもらえない。
というか、機能がごちゃごちゃしたものは使いたくない!なので、可能な限り少ない機能にした。
簡単に使い方がわかるか?
ここ実はめっちゃこだわった。元ツイートもそうですが、サイト内でもやり方を一度挟んでから計測に入っている。
【視認可能なフレーム数チェッカーを作ってみた】
— HAYATE (@hayate_inkling) May 27, 2019
スマブラやってる時自分が反応できるフレーム数が大体どのくらいか知りたい時にウルフのブラスターで測るらしいけどうまくできないので作ってみた
自分は25Fまでは視認してガード間に合うっぽい
※PCの方が精度高め
※精度ズレるので何度かやってみて pic.twitter.com/Gn6U0bBxXr
一発で使い方がわからないと、めんどくさくなって使いたくなくなる。 逆に言えば、UI/UXがよければ使ってもらえる。
iPhoneはチンパンジーも使えるらしいからね!
だから、デザインはさておき、一発で使い方がわかる工夫を各種導線に置いておいた。
簡単に面白くシェアできるか?
また、自分がこうした診断メーカーなどでの結果をTwitterで投稿するという文化を知っていた。だから、結果をツイートできるようにしたら絶対にTwitterに流れて拡散すると思っていた。
一方であんまり元ツイートはRTされると思っていなかったので、どうやったら楽しんでシェアされるかを考えた。
ただ単純に視認できるフレーム数だと、「へぇ〜こんな感じなんだ」で終わってしまうかもしれないけれど、反応できるフレーム数がどのくらいの速度なのか、どんなアクションが起こるのかを明確に書いたほうが面白いんじゃないかと思い、最終的にはフレーム数によってコメントが変わるようにした。具体的にはこんな感じ。
「あなたの視認可能フレームは25です!しずえの釣り竿に反応できないかも! https://silly-hawking-704109.netlify.com 」
今回学んだこと
シェアリンクにサイトのリンクは絶対忘れちゃダメ
これ絶対に忘れちゃダメ。ユーザーが興味を持ったときにすぐ見れないし、どんなツールなのかがわからなくなってシェアされたツイートを見たユーザーが反応できなくなる。
先にも書いたとおり、この部分が今回最も拡散につながったファクトになっているので、これは絶対に忘れちゃダメ。
バグを残した状態でのリリース
最初に使ってもらったときに教えてもらったけど、バグをかなり残した状態でリリースしてしまった。バグで不快に思った方々、誠に申し訳ないです。
当然バグが出ないことなんてまず無いが、テストユーザーを募り十分にテストを行ってからであれば、こうしたバグも防げた。中には-4Fという結果が出て、未来視をするユーザーもいた。(もしかしたら本当に未来視してるかもしれないけど)
なので、次に作るプロダクトは何人か有志でテストプレイしてくれるユーザーにお願いして、しっかりテストを行った上でリリースします。
共有リンクにハッシュタグを付け忘れた
これもったいない。「視認可能フレーム計測ツール」でトレンド入りしたけど、それに興味を持ってTwitterで検索をするユーザー向けにハッシュタグをシェアリンクに乗せるべきだった。
海外対応
これも本当にもったいない。特にスマブラは海外でもかなり盛んで、来日してくれたり、日本のコンテンツに興味を持って楽しむプレイヤーが多いことは知っていたから、本当に反省。
次に作るスマノートは海外のプレイヤーも楽しめるよう英語対応は絶対やる。
最後に
実は今サービスを一個作ってて、一個は制作予定。
- エンジニア向けのWebサービス
- スマブラを愛するスマブラーのためのキャラ対策ノート「スマノート」
上はいずれQiitaという技術系サイトで紹介します。 下の方はこないだプロトタイプをツイートしたらめちゃめちゃ反響あったので作った後が楽しみです。
普段いろんなキャラ対戦した時に都度リプレイを見て反省したりするんだけど、iPhoneのメモ帳とかだとすぐにキャラを探せなかったり、ドキュメントいちいち開くのめんどくさいからこんな感じのスマブラノート作ろうと思ってるんですけど需要ありますかね?
— HAYATE (@hayate_inkling) May 24, 2019
欲しいって思う人はいいねとRTお願いします! pic.twitter.com/BiC2dAKdlr
最近色々企画をしていて思うのは、その界隈にいる人達をちゃんと知らないとわからないということと、ちゃんと価値になるものを作れているのか、それに対してしっかり回答を用意できるのかってことなんじゃないかなぁって思っています。
また、スマブラ界隈は昔からいる人達が新しくやってきてくれる人たちをかなり暖かく迎え入れている印象があります。初めてオフ大会に出たとき皆さん丁寧にルール説明をしたり、宅オフで対戦してくれる方など本当にありがたいなと思っています。だからこそ、こうして何か役に立てることがないかなと新参だとしても取り組めています。
一方、この界隈はまだまだ改善の余地はたくさんあります。すごい作れるものがいっぱいあります。 今の所僕は手を掛けられないのですが、思いついているものでいうと、
- 宅オフの申請管理や情報をまとめたWebサイト
- 簡易的にユーザーコミュニティを作れるWebサイト
- チーム戦を募るためのプラットフォームやレーティングシステム
などなど、結構やれることいっぱいあるんじゃないかなと。プロダクト開発とゲームが好きな人にとってはすごくいい環境だなぁとしみじみ思います。
なので、引き続きこんな感じで界隈が盛り上がるようなものを作っていきます!
直近だとスマノートですかね!頑張って作るので、お楽しみに!!
いずれバズる企画の作り方も紹介できるようになると思います!それでは!
書評:仮説思考 BCG流 問題発見・解決の発想法
エントリー内容
本書の特徴
- 高速かつ正確な課題解決を行うための効率的な考え方として、仮説を使った思考法を紹介している。
- ボストンコンサルティンググループの実務や多数の事例に裏付けられた仮説思考プロセスは非常に強力なものとなっており、日常的に使えるよう丁寧に体系化されている。
- 使うことを習慣化するためのトレーニング方法も記載されているため、すぐにでも実践に移すことができる。
仮説思考がなぜ重要なのか?
仮説思考の最も良いところは、「情報を集めて解決策を考える」のではなく、
「仮の解決策を情報で証明していく」という点。ビジネスで仮説思考を実践するとなると情報を先に集めがちだけれど、実生活に置き換えるとみんな何気なく仮説思考は使っていて、改めて「情報を集めて解決策を考える」というやり方は非効率だと痛感した。
例えば、朝早起きできないという問題があったとき、「情報を集めて解決策を考える」ことをやっていると、「睡眠時間」「布団の硬度」「寝返りの頻度」「寝た時間」などの数字を無闇矢鱈に集め始めてしまう。でも実際はこんなことは絶対にやらない。最初に必ず、寝不足になったと思われる原因を考えると思う。例えば、「睡眠時間が4時間しか取れなかったことじゃないのか」とか、「布団じゃなくて枕を変えたことが原因なんじゃないか」とか。
一方で、ビジネスでは全く別のやり方を撮ってしまいがち。
例えば、ピザの注文ができるサイトの解析を分析するとして、ユーザーがどのSNSからアクセスしているのか、特定のSNSを経由した場合の売上はいくらなのかなど、思い当たる節よりもデータに焦点が行きがちになることが多い。
もちろん、Webサイトがどんな構成になっているのか、購入までのプロセスがどうなっているのかなどの基本情報は必要だけども、何もGoogle Analyticsを舐め回すように見て、宝探し的なやり方で改善を考え、提案するのは時間が勿体ない。
この場合、データを見るなとは言わないけれども、まずは仮説を立てる。
具体的には、
- ユーザーは1回ピザを購入リストに追加したあと、複数購入したいためにトップページではなく検索画面に行きたいのではないか。もしそうだとしたら、購入リスト追加後はピザ検索画面に飛ばした方がいいのではないか。
- 申し込み画面で郵便番号を入力する際、半角数字しか受け付けないが、全角数字を入力して購入できず、離脱してしまうユーザーがいるのではないか
こういった仮説を立てることで、問題解決までの道のりはものすごく楽になる。
①であれば、Analytics上で購入リスト追加後にどのページへ移動しているのかを確かめればいいし、もしトップページではなく検索への移動が多いのであれば、実際にデザインを変えてみてLTVに響くかどうかを検証してみればいい。
②の場合は、試しに「全角数字を使うことはできません。」みたいなポップアップを出して、売上がどうなるかを検証してみればいい。
仮説を先に立てて、それを立証するために行動していれば、仮説の間違いに早期に気付けるし、何を明らかにすればいいかがスッキリするので、解決までの速度も向上する。
仮説思考を習慣化するには?
さらにこの本の良いところは、仮説思考をするトレーニングを紹介しているところにある。
「なぜ?」を5回繰り返すや、「So What?」を繰り返していくなど、トレーニング方法は様々だが、仮説思考をするために何をどのように鍛えるのかを詳細に紹介してくれている。
僕自身もこれらのトレーニングを日常的にやるようになってから学習速度があがったり、Webの分析と改善までの速度が挙がった経験があるので、このトレーニングは非常に良いと思います。
最後に
実はこの本を購入したのは2年前です。当時は一回読んでも、こんなの当たり前じゃね?と思っていました。
ところが、改めて読んでみると、意図せず自身が日常的に仮説思考を使っていたり、仮説思考を部分的にできていないために課題解決速度が遅くなっているケースがあることが明らかになりました。
また、改めて読んだ感想として、仮説思考は習得までには時間がかかるため、再現性のある課題解決ができるようになるためにも、いつでも振り返りができるよう、電子版ではなく実際の書物として1冊持っておくのはものすごく良いと思いました。
文系大学生エンジニアが紹介するネットワーク技術学習のおすすめ教材
ネットワークを学習したいエンジニア向けの資料まとめ
実践イカパケット解析
※この資料はチートやゲームの改造などを助長するものではありません。
みんな大好きスプラトゥーンのパケットを解析し、どのような通信の仕組みを行っているのかを図解してくれた資料です。
解析のやり方自体は至ってシンプルですが、データの考察や分析はものすごく丁寧にされていました。
FPSゲームなどのオンライン対戦の通信手法やどんなメリット・デメリットなどが存在するのか、どういった通信手段が用途に向いているのかを学習するきっかけになったので、非常におすすめです。
Coming Soon....
書評:ブロックチェーン入門(ベスト新書)
この本の特徴
誰がこの本を書いている?
森川 夢佑斗さん。京都大学在学中、アルタアップス株式会社というブロックチェーン導入に関するコンサルや、複数の暗号通貨に対応するWallet「Alta Wallet」の提供をしている会社を立ち上げており、国内におけるブロックチェーンコミュニティの発足や、専門メディアなどの運営を行っているそう。
この本が果たした価値は?
- ブロックチェーンがどのようなユースケースで有効なのか、対応できるのかを理解できた
誰にオススメできる?
- ブロックチェーンの仕組みは理解しているけど、どういったユースケースが存在するのかを知りたい技術者
書評内容
- なぜ今ブロックチェーンが盛り上がっているのか
- ブロックチェーンの実用化を後押しする仕組み
なぜブロックチェーンが盛り上がっているのか
ブロックチェーンの導入による大きな特徴として、信用のあり方が変わっていくということ。
今まで取引を個人間で行う際、必ず中立性を保つ信用のある第三者を保つことで安全な取引を行おうとしていたが、
この第三者が何らかの理由で機能できなくなってしまった場合、
取引の安全性は保証されなくなってしまう。
本書では詳細に解説するための事例としてUberを挙げていたが、
カウンターパーティー・リスクをなくすためには、中央管理をしないようにするための仕組みが必要だと述べている。
そこで、この安全性の保証を複数人で保証することで、第三者に情報を預けるリスクとデメリットから脱却するのがブロックチェーンの役目となる。
ブロックチェーンの実用化を後押しする仕組み
ブロックチェーンの大きな特徴として、
- 情報の改ざんが困難
- 中央管理者が存在せず、分散管理されている
この2点があげられるが、ブロックチェーンがビジネスで実用化されつつある理由はもう1つ存在する。それは、スマートコントラクトと呼ばれるものである。
スマートコントラクトとは、「一連の契約処理の流れを自動化する」仕組みのことで、
イーサリアムネットワーク上で動作する。
スマートコントラクトによって、取引が成立するまでの条件をスクリプト化して、
より取引を安全かつ高速に処理ができるようになる。
前提として、取引において重要な点は、下記の2点となる。
- 契約や合意の内容が取引中に更新されないこと
- 所定のやり取りが正しく実行されること
スマートコントラクトは良く自動販売機を例に取り上げられることが多い。
自動販売機は飲み物の購入をするために複数の条件を指定する。
- 購入したい飲み物の金額以上のお金を入れる
- 購入したい飲み物のボタンを押す
この条件によって飲み物が自動的に買い手のものになる。
中古住宅の販売であれば、
- 売り手が家の鍵をロックする
- 買い手が所定の金額を売り手に支払う
この2つの条件が満たされることで、買い手側に鍵と家の所有権が移転する、といった流れになる。実際には鍵以外にも、土地登記所、不動産審査会社、住宅ローン会社などの情報も必要になるが、これらをスマートコントラクトに組み込むことによって、より安全かつ高速に契約を行うことができる。
ブロックチェーンのユースケース
- ある作品の著作権を誰が保有しているかという情報の管理
- アート作品の真偽と価値の管理
- 土地の所有者と契約データの管理
- 個人間の商売(Eコマース)
etc……
これ以外にも10個ほど実例があり、非常にわかりやすいユースケースが本書では紹介されている。
感想
ユースケースのインプットと、どういった場面で有効になりそうかは理解できた。
ただ、下記の疑問が上がった。
- 中央集権的でないのであれば、一体誰がどんなモチベーションでネットワークを作るのか。完全にボランティアじゃないのか。
- 本書ではブロックチェーンの特徴は仲介業者を必要としない、という話ではあったが、結果的に仲介業者は存在しうると思う。2者間での取引で、どちらか一方が合法的な不利益を被った場合、自己責任なのか?それを利用者は許容するのか?そこの危機負担機能を担う仲介業者の需要は必ず生まれるはず。
おそらく筆者の言うような中央集権的な仕組みからの脱却は部分的であり多くの人はできないと考えている。もっと簡単に言うと、「Bitcoin wallet」をプログラミングできない人間がブロックチェーン上の取引を執行できるのか?と言う話。
それは非常に難しく、必ずブロックチェーンやネットワーク上の窓口に仲介業者が現れる。
活用事例を多くインプットできた一方で、本当に完全な仲介業者や中央管理者の存在しない経済圏が普及するのかどうか、より疑問と興味を深める1冊だった。
機械学習概論 ~教師なし学習編 AIブートキャンプ1日目~
教師なし学習とは
入力データを元に出力を出すこと。入力データにどのような傾向があるのかまでは見ない。データに規則性を見出したり、正解のデータをそもそも用意出来ないときに使用する。
クラスタリング
特徴量からクラスタに分けること。
参考: クラスタリング - MATLAB & Simulink
主成分分析
データのばらつきが最大化するように線を引き、データの大まかな傾向を線で捉える手法。この記事がめちゃくちゃ分かりやすかった。
機械学習概論~AIブートキャンプ1日目 教師あり学習編~
学習内容
- 教師あり学習
- 教師なし学習
- 深層学習の基礎技術(DNN)
機械学習とは
条件分岐に必要なパラメータを変数化して、それをデータの入力により動的に変化させることで、最適解を得る手法
教師あり学習
教師データを用いて分析する手法。教師データとは、入力内容と期待する出力結果が対になっているデータを指す。
例えば、ヨークシャーテリアの写真を入力し、これは犬であると学習させる。また、チワワの写真を入力し、犬と学習させる。そして、もしコーギーの写真を入力した場合、犬と判定する。
教師あり学習のモデル
そもそもモデルとは?…「やり方」を意味するので、教師あり学習のやり方と覚えてもいいと思う。
回帰モデル
入力に対してどのような評価が返ってくるのかを予測するモデル。関数を作成し、その線付近に対して入力データがどの位置にいるのかを判定する。
分類モデル
学習データをクラスタリングしておき、入力データがどこのクラスタに該当するのかを判定するモデル。
過学習とテストデータ
過学習とは、モデルが学習しすぎてしまい、判定が厳密になったり、勝手に特徴を見出して、精度が落ちてしまうことを指す。これをやるには、学習するためのデータと実際に精度がいい感じになっているかどうかを検証するためのテストデータを用意して学習を進める必要がある。
回帰モデル
- 線形回帰
- サポートベクター回帰
- カーネルトリック
- 汎化・正則化
線形回帰
関数を書いて、その関数を元に入力データがどの位置にいるのかを割り出して予測する。線形単回帰であれば入力値は1つだし、重回帰であれば入力値を複数取れる。
この時、機械が学習してくれるのは直線の傾き(いわゆる重み)とバイアス(切片)である。
Tips!
もちろんデータは必ずしも法則に則った出力を返してくれるわけではないので、誤差を認識して修正する必要がある。その誤差の求め方の1つとして、最小二乗法が用いられる。ちなみに、誤差を求める関数を損失関数と呼ぶ。
Tips!
回帰の決定係数とは?
予測がどの程度正しいのかを明らかにするために、どの程度ばらつきがあるかによって判定するための係数。
汎化
過学習を防ぎ、精度の高い予測データを出せるようにすること。学習のチューニングをやってくれる。基本的に回帰モデルは関数で、傾きが存在する。この傾きによってある程度予測の精度が決まってくるため、傾きの変化が大きいことは学習としては望ましくない。そこで、傾きに関するペナルティ(制限)を損失関数に加えることで、予測データの精度をそれらしいものにする。
汎化の種類その1: Ridge回帰
汎化の種類その2: Lasso回帰
汎化の種類その3: Elastic Net回帰
カーネルを用いた回帰
サポートベクター回帰
データに対して許容範囲(マージン)を定め、その範囲内の誤差を0と認識する手法。
分類モデル
- ロジスティック回帰
- SVM
- 決定木
- ランダムフォレスト
- K-NN
ロジスティック回帰
回帰だけど分類をする手法。出力は確率で出す。
例えば、服のセールのキャンペーンを行ったときに、お客さんが反応し購入する確率は0.8となり、0.2の確率で服を購入しない、といった具合である。
SVM
クラスタ同士の最も近い点の距離を最大化して、はっきりと境界線を引くことで分類を行うモデル。
これが参考になった。
決定木
データを分割しておき、回答を徐々に絞り込んでいく手法。質問に対する回答により、徐々に正解を絞り込んで予測をするため、ユーザーのセグメンテーションに利用できる。ただ、枝が深くなりすぎると過学習(回答がめちゃくちゃ細かくなる)してしまうため、多くの変数を渡し予測するには向いてない。競馬とかは無理。
こんな感じ。
以下参考。
ランダムフォレスト
訓練データからランダムに複数の決定木を作り、それらをまとめてモデルとする手法。
複数の決定木から回答を出し、多数決で最終的な出力を決定するため過学習を防ぎ、汎化性を高めてくれる。
「はじめてでもわかる RandomForest 入門-集団学習による分類・予測 -」 -第7回データマイニング+WEB勉強会@東京
K-近傍法
事前学習を一切行わず、出力を求められた場合にのみ学習データをプロットし、学習データとの距離から対象がどのクラスに分類されるのかを判別する手法。下記の記事が参考になる。
データの分け方
ホールド・アウト法
教師データを指定した割合でざっくり分割する方法。教師データを70%、テストデータを残り30%といった具合。超絶シンプル。
K-分割交差検証
教師データの分割数を定め、その回数だけ学習とテストを繰り返す手法。
混同行列
混同行列とは、実際の入力値に対し、どのような予測を行ったのかどうかを一目でわかるように示した行列。具体的には以下を参照。
scikit-learn でクラス分類結果を評価する – Python でデータサイエンス