準二級.jp

「Business Model Generation」を読み、Business Model Canvas を描きながら世の中で成功しているビジネスの構造を理解しようとするうちに、思考のフレームワークがあると、物事の理解や整理がスムーズになる、と感じるようになりました。

そして先日、チームメイトの @kei_s と、ある Web サービスについて「モチベーション構造は、どうなっているかねぇ」とお話をしたときに、チームの共通言語として「モチベーション構造を図示する」というフレームワークの雛形をつくったのです。

今日は、そのフレームワークの適用実験として「ザ・インタビューズ」 のモチベーション構造を分析してみました。

これまでにも、ぼくが気になった Web サービスや、ソフトウェア、コミュニティ、イベント等々について、誰がコストを払って誰がハッピーになって、どのようにして「まわる」仕組み、つまり継続させられる構造になっているか、なんとなく、考えてはいました。でもきっと、理解できているなら構造を画に描けるはずだし、チームで会話するときに大事にしている「それを指させる状態にすること」に乗っかる意味でも、これからは積極的に、脳内にあるものを描き出していこうと思います。

ザ・インタビューズのモチベーション構造分析

登場人物

• (1) : インタビューする人
• (2) : インタビューされる人
• (3) : インタビューを横で聞いている第三者
• (4) : デフォルトの3つのインタビュー

モチベーション

• (A) : (1) として、普段はなかなか聞き出せないような話題を振ることができて、楽しい
• (B) : (2) として、他でもない「自分」にインタビューがきて、嬉しい
• (C) : (2) として、遠慮なく自分語りができて、満足できる
• (D) : (1) として、普段はなかなか聞き出せないようなことを聞けて、楽しい
• (E) : (3) として、面白いエピソードを読めて、楽しい
• (F) : (3) として、面白いエピソードに「いいね！」できて、楽しい
• (G) : (2) として、自分のお話を楽しんでもらえて、嬉しい

時系列を意識して「モチベーションフロー」として順序付けて書いてみました。

考察

うん、楽しい人や嬉しい人がいっぱい現れて、素敵なサービスだと思います。ぼくも (2) の人として、ずいぶん楽しく自分語りさせてもらっています。最初にログインしてみたときに、自分は (2) の人としてハッピーになりたいと思ったので、(1) の人が自分にインタビューしてくれるようにと、(4) には一生懸命に答えました。

さて。もし自分が、ザ・インタビューズの中の人だとしたら。懸念するのは (A) の収集が上手くいくだろうか、ってことです。

たぶん、潜在的に「自分語りしたい」って人はたくさんいて、そのおかげで (C) を目指してアクションするユーザは、多いように見えます。それと、コトノハやアバウトミー (もう終了してしまいましたけれど…) に慣れ親しんでいた自分は、(B) に気付けていなかったと思うので、ちゃんと (B) を担保していて、すごいなぁと感じています。だから (B) と (C) は今のところよさそうで、そこから派生する (D) (E) (F) (G) も、大丈夫そうです。

そうなると (B) の源となる (A) をいかにして集めるか、に尽きるのではないでしょうか。

人から人への興味は、無尽蔵に沸いてくるわけでもないでしょうから、そこをどうやって支えるかが、直近の勝負になると感じます。第三者が偉そうにすみません… 的外れなこともあるでしょうし、素人の思考実験と思って読んでいただけると助かります。

それと、実は上には書かなかった登場人物として、

• (5) : インタビューされない人

がいますよね。自分が中の人だったら「これはスケールするの？」と誰かに問われてしまったときには (5) について考えると思います。そういった問いとは無縁であれば、登場人物に含めなくてもよいかもしれません。

比較対象としては、Twitter のハッシュタグのうち「お題っぽいもの」を考えてみました。古典的なところでは #threewordsaftersex とか、最近になって日本語ハッシュタグが許容させるようになったので、色々な「お題を提起するハッシュタグ」があって、多くのユーザがそれに回答する形で Tweet を投稿しています。

でもこれだと (B) の気持ちは、生まれないんですよね。答えたかったら答えればよくて、もしうまいこと言えれば (G) は満たされることでしょう。そうでなかったとしても、そんなに落ち込むこともなさそうなので、期待も低く、利得も低い、といった位置付けでしょうか。

まとめ

思考のフレームワークとして、モチベーションの構造とフローを図示する方法を育てています。その練習として、ザ・インタビューズを題材に、整理に挑戦してみました。Twitter は (5) のような人を生み出しにくく、スケールするモチベーションモデルになっていると感じました。

さて、こんな記事を書いている大和田純さんに興味のある人は、インタビューをしてみてください。ぼくが幸せになりますし、ぼくが何か書けば、他の誰かにも楽しい気持ちをお裾分けできるかもしれません。なーんつって。

Interview29 – june29インタビュー

補足 (最初の投稿から数時間後)

このエントリをパブリッシュしてからも、色々と考えたので追記します。

まず、上に書いてあることは、とても定性的で、定量的なお話をぜんぜんできていないので、分析というには、ちょっと不誠実なところがあります。本来ならば、定量的な指標を用いて論ずるべきところで、じゃあ何を数値化しようか、というお話の前段階として、整理をしました、というところ。「分析」よりは「整理」に近いかもしれませんね。

中の人は、ぼくより定量的なお話をしやすいポジションにいるはずなので、ぜひぜひ定量的に「分析」して、ザ・インタビューズをもっと面白くして欲しいと願っています。ひとりのユーザとして、応援しています。素敵なアイディアの具現化、ありがとうございます！

Twitter の Direct Message に仕込んだ JavaScript が動作していた頃

Twitter が文字化けしていた日

すべての文字を画像に

Twitter の follow 通知メール

Tweet のページ

Twitter ユーザのタイムライン

We’re sorry, but buzztter is over capacity.

excite翻訳

Twitter で絵文字が使えた日

Twitter の follow 通知メール

ある日の buzztter

Tweet の投稿が何重にも重複した日

Favstar

同時発音の表現

mention の展開

まとめ

ここに貼ったのはほんの一部ですが、こうしてみると、Twitter が本当にすごいスピードで進化してきたんだな、って思いました。スクリーンショットをいっぱい撮っておくと、あとから見返して変化に気付くことができるので、よいですね。人類はもっとスクリーンショットをたくさん撮るべきだと思います。

18章の執筆者である濱崎健吾さまよりご献本をいただきまして、読むことができました！

O’Reilly Japan – ウェブオペレーション

「まえがき」から

かっこよすぎて、もう。

日々、我々は少しずつ賢くなり、少しずつ知恵をつけ、少しずつコツをつかんでいった。10年前に書いたスクリプトはツールや言語に発展した。我々の周りには産業ができた。知識・経験・ツール・プロセスは技芸になった。我々はそれを「ウェブオペレーション」と呼んだ。

ウェブオペレーションは技芸であり、科学ではない。正規の学校教育・資格・標準は (少なくとも今はまだ) ない。我々のやっていることは、学習にも習得にも時間がかかり、その後も自分自身のスタイルを模索しなければならない代物である。「正しい方法」はどこにも存在しない。そこにあるのは、(とりあえず今は) うまくいくという事実と、次はもっと良くするという覚悟だけだ。

「ウェブオペレーション」という言葉には馴染みがない、という人が多いことでしょう。自分も、この本を読み始めるまでは自分の中に持っていなかった言葉です。それでも、本書に少しでも興味を持った人は「まえがき」を読んでみることをおすすめします。本書を「かっこいい」と感じるかどうかは、それだけで分かると思います。

数々の戦場を生き抜いた戦士たちの戦いの記録

本書は、現場で活躍する人たちの「武勇伝」集でありました。「まえがき」にあった「次はもっと良くするという覚悟」の意味を、読み進める中で深く知っていくことになります。

逆に、本書は、これとこれとこれを覚えておけば大丈夫、という知識や事実の羅列ではありません。日本語版には1章から18章までがあって、それぞれ著者は別々の人たちなのですが、どの章も「あるときは、こうやったら、こういうことが起こった」「このときの経験から、こういうことを学んだ」「次は、こういうことにならないように、こうしてみようと自分は考えている」といった体験談、あわせて、体験から得た知見が綴られています。そしてだいたい「だからお前もこうしろ」ではなく「君には君の現場があるのだから、君が考えて振る舞うんだ」といった論調で全体がまとめられているのです。

それぞれの章には一人称の「ストーリー」を感じました。おかげで、自分にとってはとても読みやすかったのです。

ふと考えてみるとこれは、濱崎健吾さまが、一緒にごはんを食べているときにお話してくれる「最近はこんなことで悩んでいる」「こういうことを試してみたい」「もっとこうしていかなきゃいけないと思う」のストーリーにそっくりなんですね。ウェブオペレーションは、自分の立ち位置からすると、必ずしも専門のド真ん中というわけではないのですが、たとえて言えば、彼に読み聞かせてもらっているかのように内容を吸収することができて、とても楽しかったです。

また、同時に、彼がお話してくれる戦士の物語が、たまたま近くにいた自分がたまたま聞かせてもらえる特別なものではなく、より広く多くの人たちにも届く物語になったことを、心から嬉しく感じています。執筆、お疲れさまでした。

さらに加えて、やはり地獄の角征典さんの訳のおかげで読みやすかったのでした。本文中に「やべ！俺たちカッコいいわ。カッコいいわー」や「リア充」と言った文字列を見つけたときは、思わず声を出して笑ってしまうわけですが、伝わってくる雰囲気は、文章の流れからするとまったく違和感なく受け取れるものでした。さすがだなぁと思いました。

グッときた

本文中の気になった箇所をマークしておきます。

正しいコードの書き方を教えるのではなく、プロダクション環境での失敗から学ぶ環境を作るのだ。

4.5.1「なぜ継続的デプロイが有効なのか?」 4章 継続的デプロイ

「根本原因」をもとに評価をするのは、失敗の本質に関する技術的な理解からではなく、結果に対して社会的あるいは文化的な何らかの非難が必要だったものと考えられる。

7.1「いかにして複雑なシステムは失敗するか」 7章 いかにして複雑なシステムは失敗するか

一方、開発チームと責任を共有すれば、サイトの安定性やパフォーマンスが良くなることに気付いているグループも多い。開発者を全面的に信頼して、コードのダブルチェックをしなくなれば、開発者は自ずから責任感を持つようになる。

10.3「信頼」 10章 開発と運用の協力と連携

お互いに助け合う環境を作るには、障害にあとに非難を禁止した「ふりかえり」を開くとよいだろう。このとき「どんな間違いを犯したのか？」のような質問をしてしまうと、自己弁護に陥ってしまう。「次はどうすればうまくできるのか？」のように質問すれば、みんなが非難をせずに改善案を提案するようになる。

10.5「非難を避ける」 10章 開発と運用の協力と連携

ウェブオペレーションについて議論する前に、組織の技術標準が恥ずかしいほど低いということを正直に認めなければならない。ウェブ業界でしばらく働いていれば、それが嘘ではないことだと分かるだろう。わかっていないなら、あなたは本当に幸運か、大事に保護されているか、単なるバカだ。問題は何だろう？あらゆる技術の問題は、人の問題である。そして、解決策も人である。あらゆるバグ・障害・機能停止・復旧は、人によって行われる。

16章 アジャイルインフラストラクチャ

「アジャイル」になるかどうかなんて気にするな。「すごい」人を目指せ。技術的な問題を解決するのは人だ。みんなで幸せになろうよ。

16.5「結論」 16章 アジャイルインフラストラクチャ

通常、ウェブサービスのインフラエンジニアがユーザの方と接する機会は皆無に近いものだと思われるが、このフォームのおかげでインフラにかかわるユーザの声を直接受け取れるというのは、インフラ構築の指標の材料としても、エンジニアのモチベーションの原動力としても大変役に立っている。

18章 日本の料理のインフラ

総じて、自分が身震いとともに読んだ文章というのは「人そのもの」や「人の成長」を対象にしたものであると、こうして全体をざっと眺めてみて気が付くこととなりました。10章の「開発と運用の協力と連携」なんかは、ここでいう「開発」と「運用」をそれぞれまったく別の言葉に置き換えたとしてもそのまま言えるようなことがふんだんに書かれていて、それは、結局はチームの構成単位は「人」に他ならないことのあらわれだと確信します。16章の「アジャイルインフラストラクチャ」では「技術的な問題を解決するのは人だ」と言い切っています。これも、とてもしっくりくるものでした。18章の「日本の料理のインフラ」では「エンジニアのモチベーション」という表現で、人への注目があります。

本書を読み終えた直後に、ちょうど、濱崎健吾さまと面と向かってお話する機会にも恵まれて、技術者が自分の価値を相手に認めさせることと、技術をコモディティ化して自分への依存を排除することと、その間にある葛藤について意見を交わしました。なかなかに頭の痛いお話ですが、自分たちエンジニアにとっては、決して目を背けることはできないトピックであるとも思います。

そうなったときに残るものはなんだろうか、と考えると、自分の「成長」を信じることなのかな、と今は思います。たとえ専門分野が変わったとしても、置かれた環境が変わったとしても、できることといえば、その場での自分の役割をまっとうし、最高を求めて終わりのない旅をすること、くらいですよね。だとすれば、本書「ウェブオペレーション」に綴られているウェブオペレータたちの武勇伝から自分が学び取るべきことは、まさに、そこにあるはずなんです。

さてさて。引用はしないけれど、自動化のための Vim スクリプトのお話と、その訳注も面白かったです。

謝辞

献本をくださった濱崎健吾さま、どうもありがとうございました。献本の相手として選ばれたことを、心から光栄に思います。執筆という偉業への尊敬と、ありのままの感謝を。

訳者の角さん、編集の高さん、この文章を (自分にとっては極めて親しみやすい) 日本語で読むことができて、助かりました。偉業に感謝します。それと、角さんの訳文を高さんがどのようにハンドリングしているのか、そのプロセスにはとても興味があります。次にお会いしたときに、質問させてもらうと思います。

上記3名さま、RubyKaigi2011 の会場でお会いできそうなので、楽しみにしています！この度は、ありがとうございました！

おしまい。

監訳者の河村圭介さんよりご献本を頂戴しまして、読むことができました。自分がずっと家にいなくて、せっかく届いた本が戻ってしまったりしてご迷惑をお掛けしましたが… ご献本、ありがとうございました！

はじめての監訳作業「大規模Webアプリケーション開発入門」 – developer’s delight

大規模Webアプリケーション開発入門 ―変化に強いWeb開発を実現する10の原則 Kyle Loudon 河村 圭介 オライリージャパン 2011-03-25 by G-Tools

書籍のタイトルと内容について

自分は「Web アプリケーション開発者」という立場でこの本を読みました。

そうすると、すでに「Web アプリケーション開発」には「入門」しているわけで、タイトルにある「大規模」の部分が、この本から自分が学び取るべきことかな、と想像しながらページを開きました。

ほいで、ざっと読んでみての感想からすると、内容は「Web アプリケーション開発入門」といったところです。「大規模」と聞いてまっさきに想像した「パフォーマンス」のお話は第9章で語られるのみに留まっており、第2章「オブジェクト指向」第3章「HTML」第4章「CSS」第5章「JavaScript」などは、これから Web アプリケーション開発に関わることになる人たちに読んでもらいたい内容です。

「ちゃんと意味を考えてマークアップしましょう」などは、開発の対象となるアプリケーションが大規模かどうかに依らず、常に覚えておくべき提言です。なので、タイトルが「大規模」からはじまることで敷居が高く感じられるのだとしたら、少しもったいない気がしました！

自分の立ち位置の確認

本を一通り読んでみて、あらためて、今の自分の立ち位置を確認することになりました。

自分が Web アプリケーションをつくるときに、まず前提として大きく存在しているのは「これはプログラミングである」という認識です。なので、プログラミング一般に対して言われる「DRY 原則」などは、無意識のうちにコードに反映されていきます。本書の中で「モジュール化しよう」が繰り返し強調されているのは、すんなりと受け入れられました。

また、自分が Web アプリケーション開発に携わってきた期間は、ほとんどが「Rails/Sinatra と関わってきた期間」と言えます。Rails の routes.rb や Sinatra アプリケーションのコードを書くときは、否が応にも「URL 設計」を強く意識することになり、アプリケーション全体を「リソース指向」に設計する傾向があります。

その点で、本書に「URL 設計」の章がなかったのは、自分にとっては「ほう」と思う箇所でした。

まとめ

こうして思い直してみると、自分は「Web アプリケーション開発に入門」と明確に感じたことはなかったけれど、アイディアを形にしたい一心で、気が付けばいくつか Web アプリケーションを動かすようになっていたので、たとえば後輩に「どこから勉強すればよいですか」と聞かれたら、上手く答えられなかったことでしょう。再現性の低い学習プロセスを踏んだと思います。

本書のように「入門」に焦点を当てて整理された本が1冊あると、とりあえず網羅的に知識を付けておきたい、とか、自分に足りないものを明確にしたい、とか、そういった人とはスムーズにお話ができるようになりそうです。

最後にもう一度。河村さん、ご献本ありがとうございました！

4月13日にサインアップ申請をしておいた Cloud Foundry から「準備できたよー」のメールが届いたので、さっそく触ってみました。今なら、サインアップから10日くらいで使えるようになるってことでしょうかね。

The industry’s first open platform as a service. Run your Spring, Rails and Node.js applications. Deploy from your IDE or command line.

Welcome to Cloud Foundry

今回は Rails アプリ、Sinatra アプリ、Node アプリのデプロイを試してみました。ソースコード一式を GitHub においてあります。

june29/cloudfoundry-samples – GitHub

(写真は本文と関係ありません。手に入って嬉しかったので載せました)

準備

コマンドラインのクライアントを gem でインストールしました。

$ gem install vmc
$ vmc -v
vmc 0.3.10

Rails アプリ

普通に Rails アプリをつくって、プロジェクトのディレクトリで vmc push を実行します。

$ vmc push

Would you like to deploy from the current directory? [Yn]: Y
Application Name: sample29rails
Application Deployed URL: 'sample29rails.cloudfoundry.com'?
Detected a Rails Application, is this correct? [Yn]: Y
Memory Reservation [Default:256M] (64M, 128M, 256M, 512M or 1G) 64M
Creating Application: OK
Would you like to bind any services to 'sample29rails'? [yN]: N
Uploading Application:
  Checking for available resources: OK
  Processing resources: OK
  Packing application: OK
  Uploading (15K): OK
Push Status: OK
Staging Application: OK
Starting Application: OK

scaffold だけでつくったアプリをデプロイしてあります。普通にデータベースに書き込めている感じ。

http://sample29rails.cloudfoundry.com/

Sinatra アプリ

app.rb を書いただけ。これだけで vmc push したら動きました。

$ vmc push

Would you like to deploy from the current directory? [Yn]: Y
Application Name: sample29sinatra
Application Deployed URL: 'sample29sinatra.cloudfoundry.com'?
Detected a Sinatra Application, is this correct? [Yn]: Y
Memory Reservation [Default:128M] (64M, 128M, 256M, 512M or 1G) 64M
Creating Application: OK
Would you like to bind any services to 'sample29sinatra'? [yN]: N
Uploading Application:
  Checking for available resources: OK
  Packing application: OK
  Uploading (0K): OK
Push Status: OK
Staging Application: OK
Starting Application: OK

http://sample29sinatra.cloudfoundry.com/

Node アプリ

ファイル名は app.js にしておく必要があると書いてあったのでそうしてみたら動きました。express を使ってみたので、package.json を書かなきゃいけなくて、npm bundle も実行しておかなきゃいけない。

参考にしたのは Deploying a Node.JS app with NPM dependencies : Cloud Foundry Community です。

$ vmc push

Would you like to deploy from the current directory? [Yn]: Y
Application Name: sample29node
Application Deployed URL: 'sample29node.cloudfoundry.com'?
Detected a Node.js Application, is this correct? [Yn]: Y
Memory Reservation [Default:64M] (64M, 128M, 256M, 512M or 1G) 64M
Creating Application: OK
Would you like to bind any services to 'sample29node'? [yN]: N
Uploading Application:
  Checking for available resources: OK
  Processing resources: OK
  Packing application: OK
  Uploading (123K): OK
Push Status: OK
Staging Application: OK
Starting Application: OK

http://sample29node.cloudfoundry.com/

おまけ

Heroku の heroku コマンドと同じ感覚で適当にコマンドを打ったら通るので面白かったです。

デプロイしたアプリの一覧を見るときは vmc list でした。

$ vmc list

+-----------------+----+---------+----------------------------------+----------+
| Application     | #  | Health  | URLS                             | Services |
+-----------------+----+---------+----------------------------------+----------+
| sample29sinatra | 1  | RUNNING | sample29sinatra.cloudfoundry.com |          |
| sample29node    | 1  | RUNNING | sample29node.cloudfoundry.com    |          |
| sample29rails   | 1  | RUNNING | sample29rails.cloudfoundry.com   |          |
+-----------------+----+---------+----------------------------------+----------+

デプロイしたアプリを削除するときは vmc delete です。

$ vmc delete #{app_name}

あとあと、vmc push したけど「何のアプリケーションか分からなかったよ」ってときは、以下のようになります。

$ vmc push

Would you like to deploy from the current directory? [Yn]: Y
Application Name: sample29
Application Deployed URL: 'sample29.cloudfoundry.com'?
[WARNING] Can't determine the Application Type.
Select Application Type: (Rails, Spring, Grails, Roo, JavaWeb, Sinatra or Node)

内部では、どのようにアプリケーションを判別しているのでしょうね。ちょっと興味があります。

まとめ

「Heroku さんが息をしていないから…」というわけでもないのですが、Web アプリのホスティング先として Heroku 以外の選択肢があってもいいですよね。Google App Engine も視界にはありつつあんまり手が伸びていなくて、Cloud Foundry は「Rails も Sinatra も最初から動くよ」と謳っていたので勢いで触ってみました。Node アプリが動くという意味では Joyent に並ぶ選択肢にもなるので嬉しいですね。

Heroku の場合は「ああ、git で push すればいいのか」だったのが、Cloud Foundry の vmc コマンドは、独自に覚えることが多くなりそうです。パッと触ってみたところでは「よく分かっていないけれど動かせている」感じで、もうちょっと踏み込んだことをしようと思ったら、色々と調べる必要が出てきそうです。

今後もちょこちょこ触ってみようと思いました！おしまい。

もっとちゃんと説明してあるエントリを見つけたのでリンクしておきます！

VMware発のPaaS、CloudFoundryを試してみた – y-kawazの日記