井上恭輔(@kyoro353)の私的かつ技的な日記です。米国サンフランシスコで暮らすエンジニアです。この広告は、90日以上更新していないブログに表示しています。目が疲れて遠くを見つめた時に勝手にMacの画面を消してくれる便利な奴を作るこんにちは、きょろです。コーディング中に目が疲れて遠くを見つめた時に、Macの画面を勝手に消して光量を落とし、リラックスを手助けしてくれるプログラムを作ってみました。MEMEのセンサーデータをMQTTを使って外部に送り、受信したプログラム側で色々遊ぶという事をためしてみたいと思います。Qiita」が良くまとまって書かれているのでぜひご参考ください。MEMEの応用例を考えてみようと思ったからです。MEMEと自動で連携して動き出す」みたいなIoTな世界を体験することができます。一般的にMQTTを使うメリットには、以下の様な事があります。MEMEを使った、特にリアルタイムの通信を伴うアプリを作る際にも有用です。MEMEから頭の傾きデータを受けたiPhoneアプリが、MQTTでブローカー(サーバー)にセンサーデータをパブリッシュし、MQTTブローカーを経由して、Mac側でサブスクライブしているNode.jsのアプリにデータを受け渡します。受け取ったデータを元に、Node.jsのプログラム側で画面の点灯制御を行います。MQTTブローカーを用意するそれでは実際に開発に入りましょう。データを中継するMQTTブローカー(サーバ)を用意しましょう。これはMQTTブローカーであればぶっちゃけ何でも良いです。IoTを使ってもいいですし、SangoやMilkcocoaでも良いです。興味がある人は私の過去の記事で詳しくまとめていますので、ぜひ参考にしてみてください。MEMEのセンサーデータをMQTTブローカーに投げつけましょう。MEMEのデベロッパーサイトで配布されているリアルタイムデータ取得のサンプル(MEMELib_RealTime)を改造していきます。MQTTKitの導入MQTTブローカへの接続には、クライアントライブラリのMQTTKitを使います。podでサクッと入るので、MEMELib_RealTimeのプロジェクトに追加しましょう。OnlyをYESにしましょう。MEMEのSDKの都合でビルドが通りません。MMDataViewController.mの改造あとは簡単な改造です。データ取得の大部分は既存のサンプルを使うので、MQTTブローカへの送信部分だけ追加で実装しましょう。MQTTKitのヘッダーを読み込みます。lastSentTimestamp;viewDidLoadedには、MQTTブローカへの接続ロジックを記述します。}];あとは、データを送りつけるメソッドを用意します。MEMEのデータ取得レートは結構速いので、さすがにMQTTと言えど、Unixtimeを見て毎秒1回の送信程度に制限します。トピックは受信側のプログラムと揃えれば何でもいいです。今回は頭のピッチ方向(上下)の傾きしか使わないので、「pitch:」というフォーマットで送信します。}最後に、memeRealTimeModeDataReceivedの最後に先ほど記述したデータ送信メソッドを呼び出す処理を書き足せば完成です。sendDataToMQTTServer:data];Node.js側のプログラムを書くそれではMacで動かすNode.js側のプログラムを作りましょう。前に、Macの画面の輝度を制御する、その名も「brightness」という簡単なコマンドがあるので、先立ってそれをbrewで導入しましょう。brightnessまた、MQTTライブラリが必要なので、npmでインストールしましょう。mqttコードを記述します。SDKと違いライセンスが自由です。ライセンスはとりあえずMITにしておきますのでご自由にお使いください。頭の確度は上を向くほど小さくなりますので、今回はいい感じになった-15°と決め打ちにしています。状況にあわせて変えてください。以上で開発は終わります。MEMEを接続して、上を向いてみてください。MEMEを使って、iPhoneアプリ意外の物を簡単に連携させることができました。MEMEが生活と連携する世界って面白いまとめです。MEMEとNode.JSをMQTTで繋ぎ、リアルタイムに動作するプログラムを作成しました。MEMEらしく「目を閉じた時」とか「集中力が下がった時」なんかをトリガーにすると、もっと面白いかもしれませんね。MEMEの何よりの良さは「使っていることを忘れる」レベルに自然に日常使いができるという所だと思います。実際、今回は単なるデモアプリでしたが、このブログ記事を書いたる間にふと遠くを見つめたときにMacの画面が消えて、おおっ!と思いました。「意識しなくていい」というのは、とても大切なUXだなと再認識しました。MEMEが、それこそ「接続」や「設定」などの意識的な動作が不要に、気づかないうちに空間や世界と連携しているような未来が来ると面白いな、と思いました。目が疲れて遠くを見つめた時に勝手にMacの画面を消してくれる便利な奴を作るTweet広告を非表示にするもっと読むコメントを書く2015-10-23Mosquittoに認証プラグインを導入する今回はMosquittoに認証プラグインのmosquitto-auth-plugを導入して、MQTT接続時のユーザ認証を試してみます。mosquitto-auth-plugのワークディレクトリに移動して、config.mkをサンプルから作る。今回はHTTP-Backendのみ使うので、以下のようにする。1ん?なんか最後でコケた関係なさそうだったので、見つからなかった-lcaresと-lmosquittoを外してみる。*.soauth-plug.soわーい、コンパイルできた!プラグインを設定する早速使ってみましょう。authorised.ユーザ名&パスワードを指定してももちろん接続できません。(認証サーバが無いので)これでMosquittoの認証プラグインが有効になりました。次回は簡単な認証サーバを書いてMosquittoのアクセス制御を行ってみたいと思います。今日は自前でMQTTブローカーを構築して試してみたので備考録を残しておきます。MQTTの説明についてはネット上により詳しく丁寧な情報が乗っていますので、ここでは割愛。14.04上でMosquittoを使ったMQTTブローカー(サーバ)を構築します。world!めっちゃお手軽ですね!次回は認証プラグインの導入をやってみようと思います。09:06UbuntuでMQTTブローカーを構築Tweet広告を非表示にするもっと読むコメントを書く2014-07-14株式会社ミクシィを寿退職しました本記事は「寿退職」エントリーです。前の事で恐縮ですが、本年3月5日(巫女の日!)にサンフランシスコ市庁舎にて、はとねさん(@hatone)と結婚し、晴れてco-founderとして新しい家庭をスタートアップすることになりました。それに伴いまして、新卒入社から6年2ヶ月勤めた株式会社ミクシィを卒業して、はとねさんの勤務地であるシリコンバレーに本格的に移住することにしました。退職エントリーに関しては諸説あるので「別に書かなくても大丈夫??」なんて気軽に思っていたのですが、実際には皆様にご報告しておかないと、実生活で結構色々と大変...というか、せっかくミクシィやお仕事の関係のお話を頂いてもお答えすることができず、申し訳ないと思う機会が日々増えてきましたので、この機会にきちんとご報告させて頂きたいと思います。在職中は社内外問わず、オンでもオフでも本当に沢山の皆様にお世話になりました。本当にありがとうございました。良い人生の転換点でもありますので、この機会にミクシィでの生活を振り返ってみようと思います。私は、2008年4月に株式会社ミクシィの新卒採用第1期生として入社しました。当時は「Web2.0かっこわらい」なんて言葉が出始めた時代。今も昔も言葉そのものは「かっこわらい」以外の何物でもないのですが、全ての人がネットを介して繋がり、サービス同士もどんどん繋がり、お互いが様々な情報をリアルタイムで交換する「単なるデータベース」では無いインターネットが始まりつつある時代でした。FacebookもTwitterもまだ日本語版はありません。(追記:デジガレと組んでTwitter日本語版が始まったのが4月23日なので、これは入社前後の話。YouTubeはGoogleに買収される前で、スマホと言えば感圧式タッチパネルにWindowsCE、多くの人が家ではTrident、外ではNetFrontでレンダリングされたWebを使っていました。そんな時代に何が出来るか、何をすべきか、まだ私を含め多くの人は答えを出せてはいませんでしたが、来るべき時代の夜明けを感じ、その未来にWebに関わる多くの人が希望を抱き、心を踊らせて色んな挑戦をしていたような気がします。当時の僕が作ったパワポには「数年後の世界」としてこんな事が書いてありました。他人との距離は、ネットでもっともっと近くなる。他人の体温をネットで感じる。ソーシャルなんて形はどうあれ、空気のように当たり前になる道行く人々全てにIPアドレスが振られ、リアルタイムでコミュニケーションするのが普通になるスマホが当たり前の今ではどれも当然の事ですが、たった6年前の自分にとっては「作りたい明日」だったのです。振り返ると、何でもないようなこの業界の日々の変化というのは、実は凄く大きい物なんだなと再認識させられます。同時に、自分が夢見ていた時代がちゃんと来た事をすごく嬉しく思っています。ミクシィでやったことミクシィでは本当に多くの仕事を担当しました。最初の仕事はヘルプシステムの改修、その後にコミュニティやレビューなど、コミュニケーション関係のサービスの開発やリニューアルを多く担当しました。フォトサービスのリニューアルではバックエンドからフロントエンドまで大部分のコードを書き直しました。「ミクシィ(笑)」といつも馬鹿にされるサービスですが、それでも当時のトラフィックは大きく、時に悩み、時に苦しみつつも、本当に楽しくてやり甲斐のある仕事でした。優秀なエンジニアに囲まれて、ビビりながらも多くを学べたのも良い体験でした。会社員の身分で結構自由に何でもやらせてもらえたの本当に良い経験で、公式ブログで萌えオンラインコーヒーポット「萌香」たんのハードウェアハックを実名で公開したり、「Web2.0中の人ナイト」というライブイベントを色んなベンチャー企業の中の人を集めてやったり、個人で作ったNFCを使った趣味サービス「Taglet」を絡めて会社でサービスを作ってTechCruchに載せてもらったり、記事の執筆でも勉強会でも外部講演でも、いつも社名を背負って好き勝手に色々やらせてもらいました。4年目には「ちょっとアメリカ行ってくる」みたいな無茶なノリで、ミクシィに籍を置きながら1年間シリコンバレーのスタートアップ「fluxflex」に旅に出させてもらいました。ビジネスの立ち上げやファイナンスなど、スタートアップを日常を経験する中で「0を1にする仕事、新規事業の立ち上げは本当に面白い!」と、心から思うようになりました。「面白さ」という価値観も、単に目立つ一発ネタではなく、ちゃんとした社会への影響と持続性を持って初めて成し得るもの、というふうに価値観や人生観が変わりました。技術だけでなく、ファイナンスを含めて興味を持って実践し始める良い機会になりました。帰国してミクシィに復帰してからは、イノベーションセンターの立ち上げから、一貫して新規事業に取り組みました。やるなら、海外のマーケットに対してもアプローチできる事業が面白いと考え、言語の壁を超えやすい「開発者支援」「バックエンド」という事業領域に対して、ミクシィの開発基盤を元にした「DeployGate」というスマホ開発者向けのテストプラットフォームを作って挑戦を挑みました。DeployGateはおかげさまで93カ国以上で使ってもらえるサービスに成長し、75%以上が海外ユーザという自分の作ったサービスの中では初めてのグローバルなプロダクトになりました。イノベーションセンターでは他にもPoPollyを初めとした様々なプロトタイプの開発を行いました。世に出たもの、出なかったもの共に沢山ありますが、ビジネスを含めて仮説を立て、次から次へとモノを作って世の中にぶつけて検証して行く作業は、本当に楽しい仕事でした。今思い返せば、何だかんだで有意義で、心から楽しかった素敵な経験だったと思います。社内外問わず、良い人達に出会えて、一緒に良い仕事が出来て本当に幸せでした。Brunoに家を借りて妻と一緒に暮らしています。新婚早々、無職にジョブチェンジという大変問題な状況ではあるのですが、このような状況に理解を示し、次の挑戦に向けて応援してくれている妻に心から感謝を伝えたいと思います。(本当にありがとう!)これから取り組みたいと考えているのは、Webとスマホでやってきた技術を使って、フィジカルな世界の社会的問題を解決するという事です。個人的な想いなのですが、自分としては「バーチャルの世界は結構十分やり切った」という感覚を持っています。今まで、私達はWebの世界、スマホの世界と技術を持って色々な課題を解決して来ました。Webもアプリも使いやすいものへと進化を続けていくと思いますが、それ以上に、この世界には画面から出てこないと解決できない問題があまりにも多すぎます。Everythig)と呼ばれる世界で、確実に変化が起こりつつあると言うのをベイエリアにいると肌で感じるという事があります。実際のところ、現段階では「作ってみた」以上のものではないかもしれませんが、明らかにノウハウがたまって「小慣れて」きており、もはやビジネスや問題解決を実現する1つの手段として十分に戦えるレベルに成熟してきていると感じます。それはまるで、単なるデータベースであったインターネットが、コミュニケーションプラットフォームに姿を変えていく過程を追体験しているようです。今までWeb&スマホエンジニアが培ったネット技術やUXのノウハウを用いれば、ちょっとしたハックでもっと便利に、もっと素敵になる事は山のようにあります。次はそういった事業領域に、身を投じてみたいなと考えています。今、少しずつではありますが準備を進めていますので、お知らせできる段階になりましたら改めてご報告させて頂きたいと思います。最後にサンフランシスコで入籍しましたが、結婚式&披露宴は日本でやる予定なので、皆様よろしくお願いします!それでは、何か面白いお話がありましたら、いつでもお気軽にご連絡下さい。今後とも、どうぞ宜しくお願いいたします。2013の18日目の記事です。ActiveMerchantをWebPayで使ってみる。TBDWebPayLiteを改良してみたこんにちは!WebPayアドベントカレンダー3日目で「WebPayLiteを使ってiOSから簡単にクレジットカード決済する」という記事を書いたところ、シークレットキーを使ってクライアントサイドで決済させる実装が良くなかったのか、なんか記事が干されてしまった感に地味に落ち込んでいる、きょろです。;⌓;)とはいえ、落ち込んでいても仕方ないので、今回は私の作った「WebPayLite」というObjective-C向けの軽量WebPayクライアント・ライブラリを改良し、クライアントサイドでのトークン化に特化させる実装に変更しましたので紹介しようと思います。WebPayLiteの使い方WebPayやWebPayLiteの紹介は前回と変更がありませんので、WebPayLiteを使ってiOSから簡単にクレジットカード決済するをご参考下さい。それでは、WebPayLiteを使ってカード情報をクライアントアプリサイドでトークン化する方法を紹介します。WebPayLiteにはサンプルのiPhoneアプリのプロジェクトが付随していますので、そちらを参考にしながら読み進めて下さい。ファイルをプロジェクトに追加します。WebPayLiteをGithubから入手して、「WebPayLite.h」と「WebPayLite.m」をあなたのプロジェクトに追加します。ViewController.hに、インポート宣言とデリゲート宣言、クラス変数の定義を追加します。トークン化機能を実装するViewControllerのヘッダファイルに、WebPayLiteのインポート宣言、コールバックのデリゲートを受け取るためのデリゲート宣言、WebPayLiteのインスタンスを格納するクラス変数の定義を追加してください。*wpl;}3.初期化処理ViewController.mの実装ファイル側に、初期化処理を追加します。場合、viewDidLoadedとかに追加すれば問題ないと思います。内容はインスタンスの作成、デリゲートの登録、WebPayの公開可能鍵の登録です。公開可能鍵のハードコーディングが気になる場合は、キーチェーンなどを利用して適切に保護してください。鍵を設定するプロパティは、secretKeyからapiKeyに変更になっているのでご注意ください。@"YOUR_PUBLIC_KEY";4.トークン化ここまですれば後はトークン作成メソッドを呼ぶだけです。createTokenメソッドでトークンの作成ができます。基本的にはWebPayのAPI呼び出し時のパラメータをそのままNSDictionaryで与えればいいだけの薄いラッパなので、WebPayのAPIドキュメントを見ながら自由に呼び出してください。必要に応じてWebPayLiteDelegateの各種コールバックをViewControllerに実装してください。引数として渡されるjsonはNSStringですので、NSJSONSerializationなどを使って必要なキーを読み取って下さい。戻り値なども基本的にはWebPayのAPIドキュメントの通りです。ここでは、WebPayLiteDelegateCompletedを受け取って、作成したトークンを取得してみます。トークンをサーバに送信し、サーバーから秘密鍵で課金する。ここまでくれば後は簡単です。WebPayLiteで作成したトークンをあなたのサーバに送信し、秘密鍵を使って顧客の作成や課金などを行って下さい。WebPayにはRubyやPHP、Pythonなどの各種言語バインディングがありますので、サーバーサイドの課金の実装はとても簡単です。詳しくは他のWebPayアドベントカレンダーをご参考ください。みんなで楽しくトークン決済!こんな感じで、皆さん、できるだけトークン決済を行うように心がけましょう。トークン決済はお客さんの決済情報を守るだけでなく、アプリを作るあなた自身の不安を取り除き、楽しく決済機能を実装できるようになります。WebPayLiteはGithubで、MITライセンスにて公開中です。ご自由にお使い下さい&プルリクエスト歓迎です。04:59WebPayLiteを使ってiOSから簡単に決済用トークンを作成するTweet広告を非表示にするもっと読むコメントを書く2013-05-28Squareが承認されたので爆速で決済してみたSquareついに日本上陸!のニュースを聞いた直後に申し込んでいた日本のアカウントが今朝方、無事承認されたので、爆速で決済を試してみました!もちろん、まだリーダは届いていないのですが、アメリカで買ったリーダ(旧版も新版も両方)が問題なく使えたので、それを使いました。ツアーとか終わるとこういう画面になります。電卓みたいですが、ここで商品名とか値段を打ち込みます。(別に空欄でもいい)もちろん、+を押して複数の商品を一緒に決済するのもOK。最低決済金額は100円からで、現金で合わせて決済することもできます(クレカ決済分から除外される)せっかくなので写真も撮ってみましょう!スクエア形状に商品写真を撮影後にクリップします。写真撮影を除けば、ここまでわずか数秒です!素晴らしい。ここでリーダーを接続して(接続すると認識される。ちなみに、なぜか楽天スマートペイでも認識される(笑))カードをスワイプ!!!!!ただちにオーソリ(承認)作業が開始され承認完了!サインを記入する画面が出ます。サインを書いて決済完了です!早い!!!レシートはSMSかメールで受け取ることもできますし、省略することもできます。メールで送られてくるレシートはこんな感じ!とにかく簡単!これは本当に素晴らしい。こんな素敵なエクスペリエンスが日本でもいよいよ誰でも手元に持てる時代がくると思うと、ワクワクしますね!!!ちなみに先週末のMakerFair@シリコンバレー・サンマテオでは、手芸のバザーのほとんどのお店でSquareが使えてクレカで買い物ができました。露天の机の右下にSquareのマークが輝いていますね!日本で使えないアメリカンエクスプレスなども使えます。日本で使えないのは、おそらくJCBが使えないからというのが理由だと思われます。日本のアメックスはJCBのネットワークで決済するのですが、JCBは日本の会社ということもあって、リスクが読めず、まだまだこの領域は様子見なのでしょう。早く使えるようになるといいな!!日本でもフリマや即売会(ガチのコミケだと人&回線的にトランザクションを捌けなそうだけどw)から、田舎の露天の八百屋で野菜買うときまで、すべてクレカ決済が使える時代が、すぐそこに来ています!ちなみにクリス・アンダーソンのMAKERSには、Squareがどうして生まれたか、みたいな事が書いてあったりするので、興味がある人は一度読んでみると面白いです。APKというgemを作ってrubygemsで公開したよ!Androidのマニュフェストファイルを読んで、アプリ名やパッケージ情報を取得できます。gem作るのは初めてだったのだけど、cpanより断然簡単でビビった。releaseとコマンドを打つだけで一発公開。いうことで、興味のある方はよろしければどうぞ。Port)-HDMI変換ケーブルがおすすめ「え〜キモ〜イ☆Macの寿命ってOSアップデート1回分までだよね〜。キャハハ」こんにちは。11インチ(2010年初代モデル)を買い換えたくなってきた、きょろです。私はあやしいデバイスやサプライ品を買う(そして失敗して後悔)するのが趣味なのですが、今回は珍しく「これは凄いコスパが良くて気に入った!」と思った商品があったので紹介します。MacBook持ちなら全種類ひと通り持っておきたいディスプレイ変換ケーブル(通称、しっぽ)Macとモニタを接続するときに使う、ディスプレイ変換ケーブル、しっぽ(尻尾)はみなさんお持ちですか?あれって地味に種類がVGAとDVIの2種類があるし、勉強会でのプレゼンや職場など、使おうと思った時に持ってくるのを忘れたり、どこかに置き忘れてなくしちゃったり、いつのまにか友人に奪われてたり、持ち運ぶの色々面倒くさいですよね。大画面だと解像度的にDVI接続が良いし、でもプレゼンのプロジェクタだと大抵VGAだし、そのたびに誰かに借りるのも申し訳ないし。ディスプレイ側に全部に尻尾を装備して、尻尾を持ち歩かない生活がしたいなー」と思っていたわけです。尻尾って意外と高いんですよね。アップル純正品だと3400円もします。家のデスク、リビングの42インチ液晶テレビ、寝室のプロジェクタ、職場のモニタ。4つ買ったら13600円。お買い得な互換品を使おう!以上のような状況から、安い互換品が無いかな〜と探したら、普通にありました。なんとお値段、送料込み440円!しかも安心のAmazonさんです。Port用と書いてありますが、もちろんThunderboltでも使えますよ!で、こいつが更にいいのは、HDMI接続という所なんです。HDMI接続をすると、なんと音声もモニタ側から出力できるんです。液晶TVなどに繋げば、MacBookから大画面で音声も一緒にアニメ再生できたりします。最近のフルハイビジョンの大型液晶TVは1920x1080の表示にも対応してるので、HDMI接続にすればフルハイビジョンモニタとして普通に使えます。目がチカチカすることもありません。大画面にターミナルを表示して、プログラムを晒しながら、リビングでペアプロとかできちゃいます。これで440円はかなりお得です。ノーブランドじゃなくて、せめて名前を聞いた事のある日本のメーカーの製品が良い!という人もご安心ください。HDMI変換アダプタの互換品って結構いろんな種類があって、たとえばサプライ品で有名なエレコムの商品だと1800円から、プラネックスだと1320円くらいからあったりします。変換アダプターだとHDMIケーブルが別に必要で煩わしい...と思う人には、HDMIケーブルと変換アダプターが一緒になったタイプがおすすめです。一方がHDMIになってるので、このケーブル一本でTVとMacをつなぐ事ができちゃいます!便利ですね〜。ほかにも互換品の尻尾っていろんな種類があって、DVIなら950円、VGAなら1518円で送料込みです。共にプラネックス製です。おすすめはDVIの950円の方で、こちらはなんとDVI−Iが出力できます。変換アダプタでDVIにもVGAのアナログディスプレイにも両方出力できるんです。一石二鳥!(Appleの純正DVI変換ケーブルはDVI-DなのでVGAに変換できません)安すぎる製品には注意ここに上げた商品は全て実際に自分で購入して「これはいける!」と感じたものをピックアップしています。プラネックスの製品は、昔の安い方は断線しやすいので、ここで紹介したPL-MDPVG02の方がおすすめです。映らなくなったり、断線したりと大変で、実際に私も何種類か購入したのですが、結局は安物買いの銭失いでした。Port化!というわけで、Apple純正尻尾を1個買う値段で、互換品ならHDMI、DVI、VGAと3種類全部買い占めれます!(笑)自分の生活圏のモニタをすべてMiniDisplayPort化したら、私は日々の生活が幸せになりました。同僚のらいちゃんや、ジョンや、うかやれまで。未踏のくまぎさんや、高専のあやちゃん、恩師の岡田先生から後輩、Googleの小西さんと、サイバーの、えと、はじめましての方!!!(笑)アメリカのfluxflexメンバーやルームメイトの友人やしゃんさんまで!!!!もう感動して泣いてしまいました。なんてソーシャル、なんて温かい!こんなに誕生日を祝ってもらったのって本当に初めて。こんなにも大切にしてもらえて、俺は本当に幸せ者です。誰にもローカルじゃ祝ってもらえないさみしいものでした。それが、1年後にこんなにも幸せに包まれるなんて想像もしなかった...!みなさん本当にありがとう。Startup」の日本語版が4/16に出るらしい!今までソフトウェアの開発手法に関しては「アジャイル」だの「プロトタイプモデリング」だの、色々とノウハウやナレッジが生まれてきては話題になっていた。個人的には「で、結局それらを使ってどうやってビジネスをしたり、サービスを運営すればいいの?」という、事業主として(またはプロジェクトを運営する個人開発者として)どうオペレーションを回していけばいいのか、という点に関しては、結局のところ良い答えや、見習うべきモデルや、テンプレートが全く分からないままだった。そんな自分に、ある1つの解を与えてくれたのが、この「リーン・スタートアップ」だ。リーン・スタートアップのリーン(lean)とは、英語で「〔人や動物が〕ぜい肉の取れた、体が締まった、痩せた」という意味だ。この本では、極限まで必要最小限にそぎ落としたスタートアップを生み出すには、どういうオペレーションを回していけばいいかというノウハウについてまとめられている。この本で大切にされているポイントはいくつかあるのだが、個人的に重きを置いているなと思うのは「MVPを生み出す事」「検証可能性があるものはどこまでも検証すること」「イテレーションをとにかく短くし、検証から学び改善することを怠らない事」という事だと思う。その中から、MVPとは何かということについて今回は話そうと思う。product」の略で、市場ニーズを迅速に検証できる最低要件の小さなプロダクトという意味だ。何か新しいプロダクトを生み出そうとしたとき、そのプロダクトが結局顧客のニーズに合っているかとか、新しい価値を創造できているかというのは、はっきり言って結果論でしかなく、やってみないとわからない事が多い。数億円の社運をかけたビックプロジェクトをドカンと投下したものの、全く当たらず響かず、大コケするなんてことは、実際にすごく多い事例だ。これが体力のある会社だったら、まぁ高い勉強料ってことになるのだろうけど、小さなスタートアップや個人開発者にとっては1回のチャレンジで人生が詰んでしまう大変な問題だ。そこで、今自分たちが創造したいと思っている価値の最小単位まで機能を削ぎ落としたプロダクトを作り、それが市場に受け入れられるか実際にリリースしながら検証(Validation)し、鉱脈を掘るまで何度も何度もイテレーションを回して、ピボットを繰り返すことで、成功の確度を高めようと言うものだ。このとき、MVPというものとプロトタイプやベータ版なんかがごちゃごちゃに日本では訳されて取り扱われている感じがするけど、実際にはMVPはそれらとは別のものだ。MVPのM(ミニマム)は機能要件を絞ったプログラムという意味のMではなく、ビジネスやサービスとしてのMという意味である。必要最低限の機能やビジネスモデルが通っている必要があって、たとえば課金モデルが前提のサービスであれば「その最低限の機能に対してユーザがお金を支払うか」という仮説まで含めてMなわけなので、課金の実装もしっかり行い、お金もユーザから取らなければ、ちゃんとしたMVPではないし、仮説の検証は出来ない。fluxflexで良く話していたのは、MVPとは、大きな製品の1部分から段階的につくる事(プロトタイプ)ではなく、小さな完成された結晶を生み出す作業だということ。どんなに小さくてもいいので、まずはビジネスとして完結した小さな結晶を生み出す事に全力になる必要がある。そのプロダクトの世界観をしっかり生み出す事ができれば、あとは物量を投下して結晶を徐々に大きくしていけばいいのだと俺は考えている。語ってしまったが、これだけでは伝えられない様々なスタートアップのノウハウがこの1冊に集約されている。全ての個人開発者とプロダクト生産者に読んでほしい教科書が、このリーンスタートアップだ。英語版しかなかったときは僕も苦しみながら、ちょっとずつ摘み読みをして、ネイティブレベルの英語力のメンバーに補足してもらいながら理解を深めていた。そんな読み方でも、圧倒的に得られるものが多い1冊だった。本当に良書なのだが、残念ながら洋書なので、全ての友人に読んで!とお願いするのはさすがに気が引けた。こんなとき、このタイミングで日本語版が出るのはとてもうれしい。旨を張って、すべての人にお勧めしたい。僕ももう一度、日本語で読み直してみようと思う。12:47全ての個人開発者に読んでほしいスタートアップの教科書「リーン・スタートアップ」の日本語版が出るらしい!Tweet広告を非表示にするもっと読むコメントを書く2012-03-09細けぇことはいいんだよ!シリコンバレーのNFC交通事情と開発スタイル日本であたりまえのSuicaやPasmo,日本がNFC先進国と呼ばれていたのは今は昔。米国でもじわじわとNFCを使うシチュエーションが増えてきた。いうか、この1年ですっかり日常に溶け混み始めている。その普及速度はとても速い。(まだ利用者はそこまで多くないので、コモディティ化とまではまだ言えないが)代表的なのはClipperCard。これは、日本のPasmoみたいなもので、バス、カルトレイン(電車)、路面電車で共通して使える電子乗車券だ。面白いなぁと思うのが、実装が超簡素で、運用がすっごくレイジーなところ。自動改札なんてものはカルトレインにはない。カルトレインというのは、カリフォルニアの西海岸をサンフランシスコからサンノゼまで走ってる鉄道で、車を持たない人の移動でもっとも一般的な移動手段の1つだ。写真ではわかりにくいかもしれないけど、これぞアメリカ!って感じで、かなりデカイ。2階建てで、自転車なんかも持って乗ることができ、轟音を響かせながら走る。このカルトレイン、基本的に全部無人駅だ。改札なんてものはない。面白いのは課金方式だ。OFF時に実区間分の料金を残した上で、不要分を返金(Refound)する。デポジットのような感じだ。OFFを忘れると返金されない。OFFを忘れた方が悪いというスタイル。そんな適当な仕組みと運用だと、クレームがついたり無賃乗車する人が続出するんじゃない?!なんてエンジニアは思っちゃうわけだけど、そこは運用でカバーしている。ルールがとても厳しいのだ。ONを忘れて乗っていると、ものすっごく怒られる。何人か怒られている人を見たことがあるんだけど、日本の怒るとかのレベルではない。列車は最寄り駅に停車し、罰金200ドル払うか、警察を呼んだから、降車して逮捕されるかどちらか選べと怒鳴られる(本当に警察来てる)。ONを確認する習慣が着いた。アメリカの仕組み全般的に言えることなんだけど、基本的に自己責任という運用方式が多いような気がする。鉄道事業者は取るだけ取るし、消費者は返してもらえる分だけ返してもらうという感じ。不親切のように見えるこの仕組みだけど、実はとても、消費者と提供者の責任分界点が明確で合理的だ。アメリカの運用は、ルールを大まかにざっくり、そして、しっかりと決める。細かい運用や問題は、問題が発生したときに、レイジーに裁量をもって対応する。ClipperCardの認識速度がタッチして3秒くらいかかる酷い実装でも(Suicaの100倍くらい反応速度が悪い)、自動改札やインフラの整備にお金や時間をかけなくても、ルールの大枠の中でうまく回るし、導入が始まれば、合理的な実装かつ低コストなので、一気に広まる。これがとてもアメリカ的で、リーンなスタイルだなと感じる。シリコンバレーのアプリやWebサービスの開発にも共通しているなぁって思う。面白いこと、便利なものを、細かいことを考えずに、とりあえず実用化しちゃうのがアメリカ流。日本のWebやアプリ開発の現場は、こういう文化の人たちと戦っていかなければいけないのだ。問題や責任は、よっぽど大きなものが想定されない限り、起こった時に考えればいい。いう考え方が、日本の現場にはもっと必要なのかもしれないね。最後に、技術的なことを書いておくと、ClipperCardはNFCの種類ではType2(MIFARE)を使ってる。日本のSuicaに使われてるFeliCaよりは価格競争力はありそうね。あと面白いのが、ClipperCardのWebサイトで、カードのシリアル番号を入れて、そこに自分のクレジットカードをひもづければ、クレカ引き落としのオート・リロード・カードになったりする。乗車履歴や残高確認もオンラインでできちゃいます。アメリカはオンラインとオフラインをうまく組み合わせてサービスを作るのも進んでるなと思う。「WebでできることはWebでやればいいじゃん!便利だし安いしスケールするし!」というメッセージを随所から感じる。少なくとも、全PC用にPasoriを買わせるって仕組みよりは、すごく合理的だよね。今日スタバに行こうと歩いてたら、ホームレスっぽい人にバス停で6セント頂戴って言われたので、6セントだけ?ならいいよ!って返して、多めに25セント硬化をあげた。理由説明してみ?」っていう会話のやり取りをしたんだけど、このときのやり取りが思ったより楽しかった。思ったんだけど、1ドルくらいあげるか、コーヒをおごってあげて、30分くらい話しようよ!って言ったら、意外としてくれたりするのかな。英会話の相手と考えたら、意外とコスパいいかもとか思ってしまった。他には、コールセンターとか銀行も無料英会話教室として秀逸だよね。最初のころは怖くて話なんてできなかったんだけど、最近は度胸もついてきて楽しくなってきたなって思う。アメリカに来て1年だけど、それなりに成長してるんだな。13:12バス停英会話Tweet広告を非表示にするもっと読むコメントを書く2012-03-01大切なのはユースケースを絞り込むこと、忠実にアプローチすること。Eventbriteシリコンバレーのスタートアップが作る最近のサービスは、ユースケースがすごくSpecificで良い。ユースケースの絞り込みって、サービスを新しく作る上で凄く重要で、そのユースケースに必要ならば、決済だろうが、オフラインだろうが、Webで解決できないこともどんどん盛り込んでいくくらいの方がよいし、実は収益化や差別化のポイントはそこにあるんじゃないかなって思う。Eventbriteは、イベントの企画運営や、チケットの販売なんかが行えるサービスだ。日本で言うATNDのような感じなのだけど、チケットをオンラインで販売して参加費を回収したり、残席数の管理を自動で行ったり、チケットにバーコードをつけて入場管理なんかができちゃう便利なサービスだ。デザインも綺麗でいいよね。japanを狙っているのだと思う。俺が面白いなって思うのは、Eventbriteの導線設計がすごくシンプルで洗練されていることだ。基本的にEventbriteでイベントを探すことはなくて、Facebookやブログ、オフィシャルサイトなんかにEventbriteプラグインが埋め込まれてて、そこからチケットを購入したり予約を入れに行くかたち。プラットフォームとして設計されてて、ごちゃごちゃしてない。単なるイベント企画と募集ならWebで十分なんだけど、その一歩先の、イベントの運営管理といったペインにしっかりアプローチして、ローカルのソリューションまでも拾い上げてサービスにしている。Meetupとかでは捨ててた部分をしっかり拾い上げているのがいいね。ATNDはトレンドを拾い上げるのが凄く良かったし、タイミングもばっちりだった。そこで終わってしまったのが、今から思えば少し勿体無かったなという感じかもしれない。ユースケースを絞り込んで、忠実に手段を選ばずアプローチを続けることが大切だ。19:40大切なのはユースケースを絞り込むこと、忠実にアプローチすること。EventbriteTweet広告を非表示にするもっと読むコメントを書く2011-12-23俺が勝手に考える正しいMVCの実装。DB」だと考えている人が多いなぁと感じたので、このあたりに関する自分の考えをまとめて書いておきます。俺の考えなので、違ってたらごめんね。MVCをちゃんと理解している人には当たり前すぎる話かもなのでスルーでよろしく!初学者はViewをモリモリ生やすこれはプログラミングを始めた人なら誰でも経験ありますよね。href="${hoge}">link</a>';なんてのは完全にViewだけで実装されたプログラムですね。最近のMVCのテンプレートはとても高機能です。プログラムのロジックをそこに生やしてしまいたくなる気持ちはわかりますが、やはりMVCという考え方において、その実装は正しくありません。Viewにロジックが入り込んでしまうと、Viewの生産性とポータビリティ、保守性を下げてしまうからです。自分が本格的にMVCを触れた時に使ったテンプレートは、PerlのHTML::Templateでした。気づけば半強制的にViewとControllerの切り分けを意識させられていました。時代遅れ感はあり、いろいろ問題もありますが、私としては好きなモジュールです。MVCが理解できた!と思った頃に陥るController厨Viewにロジックを書くことをやめ、処理と表示を切り分けて考えれるようになった頃に、多くのひとはController厨になり、Controllerに処理をモリモリ生やし始めます。いうか、Controller厨で止っている人は意外と多いんじゃないでしょうか。書いて捨てるコードなら、コントローラだけで十分な場合も多いです。Railsに影響を受けた多くのフレームワークがそうですが、一見すると「モデル=データベース」と扱っているように見えてしまいますので尚更です。「railsでモデルって勝手に作られるけど、自分でコードを足したことないなぁ」って人もいるんじゃないかな。コントローラにすべてのロジックを埋めこんでおくと、これもはやり保守性が下がります。モデルから呼び出したデータをキャッシュしたり、MySQL以外にKVSに格納されているデータと連携させたり、TwitterのAPIにアクセスしたりするような処理を想像してください。ある日、TwitterのAPIのスキーマが一部変更になりました。それに応じてKVSへのデータの保持方法が変わったり、DBのカラムが追加しなければいけなくなりました。このとき、すべての処理をコントローラに書いていると、モデルの書き直しに加え、コントローラの大幅な書き直しが発生します。コントローラには入力値のヴァリデーションから表示用データの加工まで様々なロジックが入っています。処理が長いこと、変更箇所が多いことは、それだけでバグを埋め込む確率が上がります。正しいMVCではModelが太るコントローラ厨時代を乗り越え、「こりゃダメだ」と感じ始めると、エンジニアは表示、処理に加えてデータという概念を持ち始め、モデルを太らせ始めます。様々な考えがあると思いますが、私はモデルが太っているコードのほうが健全だと思います。上記のケースであれば、モデルにメソッドを生やして、モデル内部でTwitterAPIやKVSの処理を隠蔽して実装していれば、ビューや、コントローラ側の実装に一切手を加えること無く、プログラムを改修することができます。MVCにおけるModelとは、広い意味でのデータ全般であり、DBだけを差すものではありません。TwitterAPIや外部ストレージ、Memcached、KVS、こういった生データやデータストア系はすべてModelで取り扱い、その処理を隠蔽すべきだと私は思います。ModelはMVCにおけるデータAPIModelはMVCにおいて、データAPI的に設計すべきです。それは、たとえばモデルへのアクセスがメソッド呼び出しじゃなく、RPCやWebAPIになったとしても困らないくらい綺麗なモデルのインタフェースを設計した方がいいという意味でもあります。Railsのモデルをコントローラでnewしたり、createすることって、ほとんどありません。その理由は、フロントエンドのデータをそのまま無加工で流し込んで終わり、ってシーンがほとんどないからです。ユーザ登録を行うことを考えてみましょう。)とするのは良くない実装です。SALTや、ハッシュ化のロジックは、コントローラではなくモデル依存の都合のものなので、クラスメソッドとしてモデル内に隠蔽すべきです。user.saveendこうしておけば、SALTの変更や認証ロジックにTwitetr連携や他の操作を追加しようと思った時に、モデルの変更だけで改修が可能になります。コントローラ側からすれば、モデルの内部実装を考えなくてすむ綺麗な呼び出し(インタフェース)なので、使いやすいですね。オブジェクト思考は共同開発におけるプライベートスペースぶっちゃけ、複数人で共同開発しているときには、他人のコード1行1行について趣味や価値観を押し付けあうのは、お互いにとって精神衛生良くないことですし、指摘する方も指摘される方も、なんだかギスギスしてしまいます。それに、書き方なんて人それぞれの好みがありますし、友達と一緒に作る趣味プログラムに、厳格で厳しいコーディング規約を策定したりするほうが辛いし切ないですよね。インタフェースを綺麗に設計し、内部の実装にはある程度寛容に不干渉、というのが、みんなで楽しく開発するために良いスタイルじゃないかなと考えています。そのぶん、インタフェースの設計に関してはどこまでもこだわって意見をぶつけ合って良いと思います。人間関係もそうですが、共同開発にも「プライベートスペース」って大切ですよね。06:29俺が勝手に考える正しいMVCの実装。APIにアクセスするサンプルを書いたよMacでmono使って書いた。APIにアクセスするサンプルを書いたよTweet広告を非表示にするもっと読むコメントを書く次のページプロフィールid:kyoro353ウェブエンジニア、井上恭輔(kyoro353)の私的かつ技的なブログです。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。