実装までにする7つの企画作業

何度か述べている通り、Webサービスにおいて「何を」つくるかは最も重要なことであり、いくら崇高な技術を持っていても「何を」つくるかによって、その技術が生きるか死ぬかが決まってきます。何をつくるかをしっかり決めることにより、実際に本番用のコードを書く実装の段階にも確信が持てますし、リリースした際のフィードバックも活きてくるでしょう。世の中でよく使われているサービスやアプリを見るとアイデアに富んだ今まで無かったと言われるような「何」がしっかりとしたものが多いと思います。

こうしたサービスの企画をつくるに当たっては各自の流儀に負うところが多く、世に言う企画書の書き方が十人十色のように、何を持って企画とするかも人それぞれです。また、各々のやり方といっても「企画」というものをうまく定型化できずに、頭の中でぼんやりと抱いているものを企画としてしまっているケースが多いかもしれません。特に複数人によるチームで企画を決める時に、皆がそのような意識であると企画をつめるに当たって「何を決めればいいのか？」が明確化されずに何となく実装に入ってしまうことも多々あります。ものづくりをしていて、自分（達）はいったい何がつくりたかったのか？と路頭に迷うことは最悪のケースです。

今回は、いまいち定型化しずらいとされている企画のつくり方をいくつかの段階に分けて解説していきます。これらは僕がデザイン思考で著名な奥出直人氏の研究会で長年学んだことや東大MOTで有名な宮田秀明氏の書籍「仕事のやり方間違えてます」に記載されていた事柄をまとめた結果でもあります。まず、企画と僕が言っているものには以下7つの項目を決めることです。

1. 哲学
2. アイデア
3. テーマ
4. コンセプト
5. 名前
6. デザイン
7. 内部設計

それでは一つ一つ見ていきましょう。

1. 哲学

個々人が持っている特定の興味に関する揺るがない気持ちのことです。サービスやアプリをつくる原動力の根底になります。

例えば、今ではiPhoneなどのスマートフォンに取って代わってしまっているかもしれませんが、よいプロダクトの例としてAppleのiPodを挙げて行きましょう。iPodを開発した人のおそらく根底にあるのは「音楽をもっと楽しみたい」という揺るがない気持ちです。そこに「なぜ音楽を楽しむ必要があるのか？」といった問いに対する理論的な理由は存在しなくてよいのです。「『音楽が好きだから』もっと身近にいつでも楽しめていいじゃないか」と反論できればいいです。各々の日々の生活から得られる「音楽が好き」といった強い気持ちが哲学として反映されるのです。

企画を考えていく上で後述するアイデアやコンセプトの部分は右往左往するかもしれませんが、哲学の部分は決して変わらないように日々興味のあることをピックアップしていけばよいでしょう。そして、それを一言で言い表すとよりよいです。

2. アイデア

哲学を叶えるための個別具体的なアイデアです。一つのサービスやアプリ、プロダクトに対してたくさんのアイデアがあってよいでしょう。

「これが欲しい」という哲学から発想していくと細かいアイデアがいくつか浮かんでくると思います。例えば、iPodの場合を考えてみましょう。いくつかアイデアと思われるものを汲み取ることができます。

• 所有している曲全てを持ち歩ける
• ディスプレイとコントローラだけのなるべく小さいサイズのデバイス
• 専用のソフトウェア（iTunes）で曲を管理しデバイスと同期させる
• コントローラは曲の選択とプレイヤーの操作だけできればよい
• アルバム別だけじゃなくてアーティスト別や年代別、ジャンル別などで再生できる
• 再生中は曲のアートワークをかっこよく表示させる
• 販売サイト（iTunes Music Store）で曲を買ったらそのままデバイスにも同期される

こうしたアイデアは最終的にiPodというプロダクトに活かされているものですが、おそらく企画をつくるに当たって没になったアイデアもいくつかあることでしょう。たくさんの個別具体的なアイデアを持っておき、後ほど吟味するとよいです。

3. テーマ

テーマとは哲学をより具体的にした勝負する領域のことを言います。アイデアを出していく過程などで固まっていくことが多いです。

iPodの場合は「携帯音楽プレイヤー」がテーマと言えるでしょう。ただ、Appleの戦略としてはiPodが単なる単体のプレイヤーというデバイスにとどまっていないのが妙でしょう。というのはiPodは音楽ソフトであるiTunesとオンラインの音楽販売ショップであるiTunes Music Storeとの連動により活かされる点が多分にあるからです。

AppleのiPod、iTunes、iTunes Music Storeのような絶妙なコンビネーションを考える必要はありませんが、テーマを定めることは必要です。テーマを認識することで、同じテーマの既存サービスやアプリを調査することができるからです。

4. コンセプト

アイデアがたくさん出て、テーマも定まったならば、自ずと何を作るかのイメージが頭の中に浮かぶはずです。それを一言で表したものがコンセプトです。コンセプトはテーマに沿った、アイデアを形成するための骨格のようなものです。

iPodの場合だとコンセプトは以下の文章になるでしょう。

専用の音楽ソフトを経由して所有する曲全てを持ち運べる携帯型音楽プレイヤー

肝は「所有する曲全てを持ち運べる」という点ですね。このコンセプトに対して上記で挙げた個別のアイデアが付随してそれ何であるかを説明するという具合になります。このようにコンセプトとアイデア、テーマと分けて考えることにより、人に説明がつきやすい企画になります。例えば、「私たちがつくるものは」とはじめテーマ、コンセプト、アイデアという順番で説明していけば、抽象的なところからより具体的なところへと解説するので相手にもイメージが着きやすくなります。説明しやすいということはその企画は自分（達）の中でも明確化されているということなのです。

5. 名前

そのプロダクト、サービス、アプリの名前を決めることは非常に重要なことです。

焦る必要はありませんが、なるべく早い段階で名前を決めておくことをオススメします。もちろん仮でもよいです。というのは、これからつくろうとしているものを自分（達）で呼ぶのに名前が無いと気持ちが入りませんし、先に進まないケースもあります。例えばこれまで決まったアイデアやコンセプトなどの企画をまとめてデジタル化したい時、PCに作業用のフォルダをつくるとします。その際に仮でもいいですから名前があればそれを使ってフォルダ名とすればよいわけです。名前が無かったらどんな名前でフォルダ名を作ればいいか無駄に途方に暮れるかもしれません。些細な例でしたが、同じような悩みには多々遭遇するはずです。

6. デザイン

デザインというと見た目のデザインが思い浮かぶかもしれませんが、それだけではなく、全体のディテールを詳細に決めていく作業です。モックアップと呼ばれる一部の機能を叶える試作品をつくったり、同じテーマのプロダクトを調査する過程で固まっていきます。

コンセプトやアイデアを洗練させていくと無駄なものが削ぎ落され、最低限のサービスやアプリに対する機能が抽出されます。それらに対してユーザーがどういう風に使っていくかを具体的なイラストなどを元に試行錯誤していく作業を行っていきます。iPodの場合は「デザインがよい」という評判を聞きますが、それは機能を絞り込みそこに対するディテールをいかに使いやすく突き詰めたかの結果によるものでもあります。実装作業に入る前にiPodのような物理的なものならば木材や粘土などを用いたモックアップを作ることや、Webサービスであれば紙にUIのイラストを書くような作業を何度も繰り返すとよいでしょう。デザインに関しては様々な具現化の方法があると思いますが、複数人のプロジェクトにおいても、不思議と一つの形に定まっていくことが多いです。

7. 内部設計

今まではサービスやプロダクトを外から見た際の企画について考えてきましたが、内部的にどのように実現するかを設計していくことももちろん必要です。

Webサービスならば、情報の区分けを行いデータモデルを記述する、物理的な観点とソフトウェア的観点をあわせて大きな枠組みを考えるアーキテクチャ図を書くといった作業です。ユースケースと呼ばれるユーザーから見たシステムの振る舞いを書いてから作業に移るとよいでしょう。極力ユースケースに従った形で最低限の内部構造を持つことを考えていくと最初は作りやすいです。また、Webサービスの場合、他にもサービスのエンドポイントを決めるURI設計や、内部のクラス構造を考えるAPI設計なども設計作業に入ります。専用のモデリングツールと呼ばれるソフトウェアを使うのもよいですが、まずは、大きめの紙とペンで行います。

まとめ

以上、サービスを実装する前の企画とは何を決めなくてはいけないかを、7項目に分けて紹介してきました。この7つの項目はWebサービスだけではなく、ものづくり全てにある程度共通することではないかと思います。まずは、何度かこの項目に従ってつくり、自分なりのものづくりの方法を築いていくのもいいと思います。

参考

• ゆーすけべーラジオ
• デザイン思考の道具箱
• 仕事のやり方間違えてます

1. 長居しても嫌な顔されない

まず、これが一番でしょう。長い時間居てもコーヒー一杯頼めば店員さんに嫌な顔全くされません。 むしろ店員さんは笑顔です。

2. 場所によっては空いている

で、お店が混んでる時には長居してるとお店に悪いなーって感じでその点はもちろん考慮した方がいいでしょう。 ですが、場所によってはいつも空いている店舗があったりしてそういう場所は使いやすいです。

3. 電源が使える


次に大きいのは、PC等向けに電源が使える席があります。 恵比寿店など店舗によっては電源が用意されてないところもありますので注意が必要ですが、 大抵貸してくれます。

4. livedoor無線LANが使える

自前でe-mobileやWiMAX等のネットワークを用意できない場合はlivedoor Wirelessがこれも大抵の店で利用できます。 月額525円で使える公衆無線LANサービスです。僕も以前ネットワークが無くてお世話になったことがあります。

5. 打ち合わせにも使える

席と席との間隔が狭いわけではないので、隣のお客さんの声があんまり聞こえない構造になっている？のか、 同席した人との会話がしやすい気がします。よって打ち合わせにも向いているかなーと。 実際にこの前八重洲口のルノアールで某ミーティングをしたのですが、快適でした。

6. お茶がエンドレスに出てくる

長い時間いると最初に注文した飲み物も無くなってのどが乾いてしまいますが、 ルノアールの場合暖かいお茶がエンドレスか！ってぐらい出ててきます。 これはありがたい。

7. 禁煙席・喫煙席と分煙


禁煙席、喫煙席と分煙です。区分けはそこまで厳しくないので、禁煙席の方にも香ってきますが、一応分煙。 逆に言うならば、喫煙者にとっては喫煙席が必ずあるということでタバコを吸う方にはありがたいかも。

8. コピー機があったりする

確か、関内のルノアールにはコピー機があってお金を入れれば使えた気がします。

9. 会議室を持っているところも

会議室を持っているルノアールは結構ありますね。よく利用するのは、渋谷のルノアール系カフェ「カフェ・ミヤマ」のマイスペースっていう会議室です。場所が便利なのがいいっすね。

10. 今ならルノアールEdyで15%オフ

ルノアールが発行しているEdyがあって最近作ったのですが、これを使うとなんと飲み物等が15％オフになります。 今はキャンペーン中らしいのですが、通常でも10％オフ。こりゃお得。

まとめ

このようにルノアールにはお世話になっているので、コーヒー一杯だけではなくてもっと飲み物頼めばいいのかと思いつつ、 エントリーを書いてみました。店員の皆様、いつもありがとうございます！ルノアールのHPはこちらから。

• 銀座ルノアール

モヒカンだけど、「普通に」してください

ってまめさんに要求。まめさんは「普通でいいんですかー？」とバリカンを入れながら聞いてきます。 これから切る髪型についての話をバリカン入れながらってすごいっすね。 で、いきなり吹き出して「完成を思い描いたら面白くなっちゃったw」と今日もノリノリです。 10分ほどの短い時間で、「これどーですかー？」と外してた眼鏡を持ってきてくれた。 鏡を見てみると普通っていうか、案の定面白い感じになってるじゃないかー！

メンズノンノに載ってるモデルさんっぽくないっすかー？

と、メンズノンノに載ってるくらいだから＝普通を主張してきてなんとなく納得しちゃったじゃないか！

ってなわけで、メンノンカットが出来上がりー。モヒカンの頂点がかなり長くて、横に流す髪型です。 下の写真はまめさんとスタッフのしょうくんとの写真です。

美容室の社長さんまで巻き込んで完成の様子を写真で撮りました。

まずは、遠目から。

そして、どアップ！

このメンノンカット、スタイリングには艶の出るジェルがいいとまめさんに言われるが、ワックスくらいしか持っていません。 そこで、会計の帰り際にまめさん、

ポイントが溜まっているから、さっきも使ったジェル、プレゼントできますよー

おー、ということでプロ仕様のジェルをただでいただきましたよ。 なんだかんだいってメンノンカット気に入ったし、さんざん美容室の中で騒いだし、社長さんも含めみんないい人だし、 コストパフォーマンスも含め楽しめましたー。コムズヘアーいいよ！最近、辻堂のテラスモールにもできたみたいなので、 湘南地域の人はチェックしてみてくださいな。

• コムズヘアーの公式サイト

とりあえず「eroken」って名付けた。

どんなサイトに対応しているの？

海外10個以上のサイトに対応している。xvideos、tube8、empflix、tnaflix、spankwireとかだいたい網羅したと思う。fc2入れようと思ったけど日本語サイトなんでやっぱりやめた。

なにエロ動画これ検索できんの？

正確に言うとエロ動画サイトの動画ページが検索できる。 一部日本語にも対応しててAV女優名を入れるとそこそこの精度で動画出てくるよ。 おまけとして「エロ動画検索として役に立つかもしれないエロ英単語」を左側に付けたから活用してね。

検索するとサムネイルも出るじゃん！

Google側で最近動画っぽいサムネイルを表示してくれるみたい。 CSSで無理矢理拡大してるから見やすいと思う！ ちなみに、オートコンプリートって言って検索のための補助語を出してくれる機能もつけた。 AV女優の名前一覧をぶっこんだから名前っぽい文字いれても保管されるwww

どうやって作ったの？

Googleカスタム検索のページ行って、対応させるサイトを入れたりして設定。 あとは簡単なJavaScriptのドキュメント読んでページに読み込ませた。簡単。

masturbationで検索したら男のちんこができたんだけどwww

それ俺もやったwww

ということでGoogleカスタム検索で作ったエロサイト検索は使えるかな！？ eroken、気になった人は見てみてください！！

Twitter OAuth認証の流れ

Twitter OAuthでは主にキーと鍵のペアの値がいくつかでてきて混乱しがちなのでイカ、おっと間違えた、以下にまとめておきます。

• 「コンシューマトークン、コンシューマシークレット」 アプリケーション固有のキーと鍵。Twitter Developerのページで発行される。アプリケーション開発者以外に知らせてはいけず、通常は設定ファイルなどに記載してアプリケーションで読み込ませる。
• 「リクエストトークン、リクエストトークンシークレット」 アプリと連携する際にTwitterのサイトでログインをしてもらうが、そのログイン画面へリダイレクトさせるURLが発行されるタイミングと同じくらいで使うトークン。リダイレクトさせる前に取得し、クッキーなどで保持し後ほど自サイトにユーザーが戻ってきた時に照合させる。
• 「アクセストークン、アクセストークンシークレット」 そのアプリにおけるユーザー固有のキーと鍵。これと上記のコンシューマトークン＆シークレットがあればTwitterにアプリケーションでログインが可能になりタイムラインの取得などができるようになる。実際にはTwitter上の認証画面から返ってきた際に初めて取得できる。

そして上記の言葉を使った、カタカナばかりでちょっと分かりにくい、開発の流れはこのようなものです。

1. Twitter Developerのページにてアプリケーションを登録
2. アプリケーション固有のコンシューマトークンというキーとコンシューマトークンシークレットという鍵をもらう
3. アプリを実装。設定からコンシューマトークン＆シークレットを呼び出せるようにしておく
4. コンシューマトークン＆シークレットを元にリクエストトークンとリクエストトークンシークレットを作り出す
5. リクエストトークン＆シークレットをクッキーで保持しておく
6. Twitterの認証ページにリダイレクトさせる
7. コールバックURLにGETパラメータの引数付きで返ってくるのでそれを元にユーザー固有のアクセストークン、アクセストークンシークレットを取得
8. アクセストークン＆シークレットをクッキーで保持しておく
9. コンシューマキー＆シークレット、アクセストークン＆シークレットを使ってログイン、タイムラインなどを取得

サンプルアプリの方針

Twitterログインをして自分のタイムラインを見られるような機能をサンプルとして作成したいのですが、 少々それだけだと味気ないです。 Perlのライブラリ置き場CPANを漁っていると「Acme::Ikamusume」なる興味深いモジュールを発見したのでそれを使ったアプリを考えてみます。このAcme::Ikamusume、動かすのにMeCabという形態素解析のソフトが必要なのが多少敷居が高いですが、簡単に使えてかつ面白いです。

my $text = Acme::Ikamusume->geso('変更したいテキスト');

とするとアニメ「イカ娘」でイカちゃんがしゃべるような言葉に変換されます。自分のTwitterのタイムラインがイカ娘変換されるとどうなるか！？おもしろいんじゃなイカ！？ってことでやってみます。ちなみに作者の富田さんが自身でイカ娘変換を簡単に試せるサービスとAPIを公開していますのでそちらもご参考ください。

• 侵略！ イカ娘変換でゲソ！

実装の方針ですが、PerlのMojolicious Liteを使ったものとさせていただきます。上記の流れを最低限の機能で追うので他の言語でも応用できると思います。また、Mojolicious Liteのセッション管理は若干貧弱なためPlack::Sessionを代わりに、Twitter APIの処理にはNet::Twitter::Liteを使います。

アプリケーションの登録とコンシューマキーの取得

まず、Twitter Developer のページでこれから作るアプリケーションの情報を登録します。

いくつかの項目は後から変更が効きますが「Name」の欄は変更がきかなかったり早い物勝ちだったりするので慎重に考えて入力しましょう。アプリケーションを登録したらいつでも「My Applications」からそのアプリを選んで、設定情報を確認することができます。コンシューマキー＆シークレットである「Consumer key」「Consumer secret」という文字列が表示されていると思うので、それを後ほど使います。

アプリケーションの実装、設定からキーを呼び出す

いよいよアプリケーションの実装に入っていきます。mojoコマンドを使ってアプリケーションの雛形を作ったら「myapp.conf」などの名前で設定ファイルを作り、そこにコンシューマキー＆シークレットを書き込みます。またアプリケーション内でConfig Pluginを使い、設定を呼び出します。

myapp.conf

{
    consumer_key    => 'xxxxxxxxxxxxxxxxxxxxxx',
    consumer_secret => 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
};

myapp.pl

my $config = plugin('Config');
my $nt = Net::Twitter::Lite->new(
    consumer_key    => $config->{consumer_key},
    consumer_secret => $config->{consumer_secret},
);

consumer_keyとconsumer_secretをそのまま渡してNet::Twitter::Liteのインスタンスを作ってそれを使い回していきます。

Twitterログイン画面に飛ばす

次に「/login」にアクセスするとTwitterのログイン画面に飛ぶために、URLを取得しリダイレクトさせる実装をします。 その際にリクエストトークン＆シークレットをセッションで保持しておくのを忘れないようにします。

get '/login' => sub {
    my $self    = shift;
    my $session = Plack::Session->new( $self->req->env );
    my $url     = $nt->get_authorization_url(
        callback => $self->req->url->base . '/callback' );
    $session->set( 'token', $nt->request_token );
    $session->set( 'token_secret', $nt->request_token_secret );
    $self->redirect_to($url);
};

「$nt->get_authorization_url」のcallbackパラメータで指定している通り、Twitter側でのログインの処理が終わると「/callback」に戻ってくるように指定しています。

Twitterログイン画面から戻ってきた時の処理

ということで次は「/callback」を実装します。GETメソッドのパラメータ「oauth_verifier」の値と照合させてアクセストークン＆シークレットを取得できます。それらの値をセッションで保持し、トップページにリダイレクトさせています。また、もしユーザーがTwitterのログイン画面でログインを拒否した場合には「denied=xxxxxxxx」というパラメータ付きで「/callback」に返ってくるのでその際はセッションのセットをしていません。

get '/callback' => sub {
    my $self = shift;
    unless ( $self->req->param('denied') ) {
        my $session = Plack::Session->new( $self->req->env );
        $nt->request_token( $session->get('token') );
        $nt->request_token_secret( $session->get('token_secret') );
        my $verifier = $self->req->param('oauth_verifier');
        my ( $access_token, $access_token_secret, $user_id, $screen_name ) =
          $nt->request_access_token( verifier => $verifier );
        $session->set( 'access_token',        $access_token );
        $session->set( 'access_token_secret', $access_token_secret );
        $session->set( 'screen_name',         $screen_name );
    }
    $self->redirect_to('/');
};

ログイン後のホーム画面の処理

セッションにはアクセストークン＆シークレットが保持された状態になるので、これでユーザーのタイムラインを取得することができるようになります。ホーム画面では「$nt->home_timeline」で取得したツイートにイカ娘変換をかけて配列リファレンスに入れ、そのままテンプレートに渡しています。テンプレートではその配列リファレンスやセッションに値が入っていればそのまま表示し、そうでなければログインしていない状態と見なしログインを促すリンクを張っておきます。

myapp.pl

get '/' => sub {
    my $self    = shift;
    my $session = Plack::Session->new( $self->req->env );
    my $tweets;
    if ( $session->get('access_token') ) {
        $nt->access_token( $session->get('access_token') );
        $nt->access_token_secret( $session->get('access_token_secret') );
        for my $tweet ( @{ $nt->home_timeline } ) {
            next if $tweet->{user}{protected};
            $tweet->{text} = Acme::Ikamusume->geso( $tweet->{text} );
            push @$tweets, $tweet;
        }
    }
    $self->stash->{screen_name} = $session->get('screen_name');
    $self->stash->{tweets}      = $tweets;
    $self->render('index');
};

templates/index.html.ep

% if ( $screen_name ) {
<h3><a href="/">@<%= $screen_name %>さんのイカ娘タイムライン</a></h3>
<ul>
  <li><a href="/logout">ログアウト</a></li>
</ul>
% }else{ 
<ul>
  <li><a href="/login">Twitterログイン</a></li>
</ul>
% }

% if($tweets) {
<hr />
% for my $tweet ( @$tweets ) {
<p style="margin-bottom:1em;padding-bottom:1em;border-bottom:1px dotted #ccc;">
  <img src="<%= $tweet->{user}{profile_image_url} %>" alt=""
       width="36" height="36" style="float:left;margin-right:1em;"/>
  <a href="http://twitter.com/<%= $tweet->{user}{screen_name} %>" 
     target="_blank">@<%= $tweet->{user}{screen_name} %></a>: <%= $tweet->{text} %>
  <span style="display:block;clear:both;"></span>
</p>
% }
% }

ログアウトの実装

最後にログアウトの実装をします。保持しているセッションをクリアして、トップページに遷移させます。

get '/logout' => sub {
    my $self    = shift;
    my $session = Plack::Session->new( $self->req->env );
    $session->expire();
    $self->redirect_to('/');
};

デモとコードの在りか

さてこれらのコードを組み合わせれば「イカ娘タイムライン的な何か」が完成です。

そのうち使えなくなってしまう可能性大ですが、一応今のところ動いている物をイカの、いや以下のURLでデプロイしておきました。機能は少ないですがあなたのイカ娘タイムラインを眺めることができると思います。

• http://twitter-ikamusume.yusuke.be/

また、ソースコード一式をgithubに置いておきます。

• yusukebe/Twitter-Ikamusume

こうやって作ってみるとタイムラインを見るだけじゃなくてイカ娘な発言もしたくなってくるでゲソ。 ってな感じでアプリを拡張したりするのもいいと思います！ということでお楽しみください。

お知らせ

メルマガ「ゆーすけべーラジオ」ではこうしたWebサービスにまつわるエッセイ風のテキストやデザイン思考について書いています。よろしければお試し購読を。

• ゆーすけべーラジオ

僕はいくつかのエロサイトを管理しているのですが、 その中に月間700万PVのアクセスをいただいている「サイトA」があります。 サイトAの場合、トラフィックもそこまで無かった当初からパフォーマンスに関する問題がいくつか発生し、 その都度調べては実践で試して対策をしてきました。また、できる限り少ないリソースでの運用を目指しています。 今回はWebアプリのパーフォマンスアップ作戦として、 サイトAでの運用経験からのいくつかの方針やTipsを紹介したいと思います。

それはどこのパフォーマンス問題？

まず、パフォーマンスといってもWebアプリの場合、どこがボトルネックになっているか？ その「どこ」を把握することが大事です。単に「Webサイトが遅いよ」と言っても、 Webページ自体のレスポンスを返すのが遅いのか、ページ内で使われている画像の配信が遅いのか、描画が遅いのか... 様々なケースが考えられます。 そこで、大きく切り分けて以下の3つでパフォーマンスを考えるといいと思っています。

• バックエンド、アプリ部分のリクエストを処理する際の性能
• フロントエンド、アプリ部分以外のページ全体を構成するパーツ郡の配信性能
• クライアント、ページ全体を描画する際にクライアントにどれだけ負荷をかけるかの性能

今回はあえて、フロントエンドとクライアントを分けて考えています。 クライアントは人間がページを見る場合ですと、 昨今、マシンの性能が上がっているので、ある程度負荷をかけてもいいところかもしれませんが、意識することは必要です。

バックエンドの性能計測

パフォーマンスに対する問題を解決するには、対策と結果をどちらも把握しなくてはいけません。 それには結果に対する計測が必要になってきます。ちなみに、最初に言っておきますと、 計測の原則として常に同じ環境で計測するというのが前提となってきます。

さて、バックエンドの性能を計測するには一般的にApache Benchmark「ab」というコマンドが使われています。 その名の通りApacheに付属しているツールです。

「http://127.0.0.1:5000/」にリクエストしてパフォーマンスを計測するには以下のようなコマンドを実行します。

$ ab -n 100 -c 10 "http://127.0.0.1:5000/"

オプションの「-n」はリクエストの回数、「-c」は同時接続数を意味します。結果は以下のように出力されます。

Benchmarking 127.0.0.1 (be patient).....done

Server Software:        
Server Hostname:        127.0.0.1
Server Port:            5000

Document Path:          /
Document Length:        271 bytes

Concurrency Level:      10
Time taken for tests:   0.227 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      44000 bytes
HTML transferred:       27100 bytes
Requests per second:    440.95 [#/sec] (mean)
Time per request:       22.678 [ms] (mean)
Time per request:       2.268 [ms] (mean, across all concurrent requests)
Transfer rate:          189.47 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   4.4      0      20
Processing:     4   20  12.8     20     104
Waiting:        0   19  12.7     19     103
Total:          4   22  13.1     22     104

Percentage of the requests served within a certain time (ms)
  50%     22
  66%     23
  75%     24
  80%     26
  90%     36
  95%     46
  98%     56
  99%    104
 100%    104 (longest request)

ここで注目したいのは「Request per second」という欄ですね。

Requests per second:    440.95 [#/sec] (mean)

これは秒間に「440.95リクエスト」を処理しているということを意味しています。 「Hello World」程度のWebアプリなので速い数字が出てます。 この数字は複雑な処理をしたり、データベースアクセスやWeb APIへの接続をするアプリになってくると、 極端に小さくなっていきます。つまりアプリの処理速度が低下することを意味します。 サービスの規模や処理内容によるのでどういう数値が適切かはケースバイケースですが、 バックエンドのパフォーマンス計測に使う値の一つです。

Webサーバの構成

「サイトA」はPerl製のPSGI互換Webアプリとしてつくられています。 よって様々なWebアプリケーションサーバで起動することができるのですが、サイトAの場合は「Starman」を使用しています。 このStarmanで立ち上げているアプリだけでサイト内のコンテンツを全て配信して完結させることは可能ですが、 フロントエンドサーバとして「nginx」を構えさせています。 nginxがCSSや画像ファイルなどの静的コンテンツの配信とリバースプロキシによるバックエンド、 つまりStarmanとのつなぎをしています。

Starmanなどで起動するアプリサーバのプロセスがどうしてもメモリを占有してしまうために、 画像などのアクセスの多いコンテンツはフロントエンドに任せています。 サイトAの場合だとStarmanの子プロセスが一つ50MBほどになってしまいますから、 静的ファイルを全てアプリケーションサーバで配信すると大変なのです。 このような構成にすることで、最小限の動的コンテンツ部分をアプリケーションサーバで担うことになって、 プロセス数の把握がしやすくなり、プリフォークさせるプロセス数の調整がしやすくなります。

アプリケーションでのキャッシュ

アプリケーションでのキャッシュをすることはバックエンドの性能を向上させる常套手段でもあります。 キャッシュプログラムでよく使うのは「set」と「get」で、それぞれ簡単な概念です。 とあるキーを指定して、値をキャッシュするにはこのようなプログラムになるでしょう。

 $cache->set('key', $value);

値を取り出す時は、

my $cached_value = $cache->get('key');

とします。memcachedなどを利用した場合、「set」する際にキャッシュの有効期限を指定することができます。 例えば、24時間だけ値をキャッシュしたい時には

$cache->set('key', $value, 60 * 60 * 24);

と、秒単位で時間を記述します。この有効期限を利用して、 サイト内で頻繁にアクセスのあるデータをある一定時間キャッシュさせるということをサイトAでは行っています。

my $data = $cache->get('key');
return $data if $data;
$data = $api->get_data();
$cache->set('key', $data, 60 * 60 * 24);
return $data;

このコードは、もし、キャッシュにヒットしたらその値を即座に返し、そうじゃなかったらデータを取得し、 キャッシュに設定するということを意味しています。 このコードはよく使うパターンです。

また、データのキャッシュよりも効果的なのは、制限が多くなりますが、 HTMLのページをまるごともしくは一部をキャッシュする方法です。 Web Application Framework内でビューを通してレンダリングした結果をキャッシュに乗せてそれを利用すればよいでしょう。

クライアント側でのパフォーマンス計測と対策

静的コンテンツの配信、そしてそれの描画に関するクライアント側での最終的なパフォーマンス計測には、 ブラウザのアドオンであるYahoo! YSlowやGoogle Page Speedなどが利用されています。 対象となるサイトをブラウザ開きつつアドオンを起動すると様々なチューニングポイントと共に、 「A」とか「C」とかアルファベットでスコアを付けてくれます。 ちなみに今、サイトAのランクを計ったら「B」のスコアをいただきました。

これを「A」にしなくてはいけないというわけでは決してないです。 それぞれのチューニングポイントは、サイトによって達成しなくていい項目も含まれているからです。

僕は最低限、自分がフロントエンドサーバで配信するコンテンツに関しての「header」調整はします。 特に「expires header」を適切に設定することでクライアント側に画像やCSSなどのファイルのキャッシュをすることができます。 サイトAでは極力長く1年間のexpiresを設定しています。nginxのコンフィグファイルは以下のように記述しています。

location ~ ^/(favicon.ico|images|js|css)/  {
    expires 1y;
}

注意したいのはこちらが意図的に「/css/style.css」を書き換えたとすると、 そのファイルのクライアント側のキャッシュを解除しなくてはいけません。 対象となるCSSを読み込むHTMLでファイル名にパラメータを付加することで強制的に書き換えた新しいものを読み込ませています。

<link rel="stylesheet" href="/css/style.css?v=0002" />

クライアントサイドに関して様々な環境が存在するので、ある程度慎重にパフォーマンスを改善していくことがいいと思います。 ちなみにフロントとクライアントサイドのチューニングについては以下の書籍が詳しいです。

ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール

posted with amazlet at 12.03.06

Steve Souders スティーブ サウダーズ
オライリージャパン
売り上げランキング: 91462

Amazon.co.jp で詳細を見る

まとめ

他にもサーバ構成をより見直すことができますし、非同期で処理するべき点はそうすべきかもしれませんし、 データベースアクセスなどは簡単に改善ポイントであります。 サイトAを例に取りましたが、やり方は色々あるので一つの参考にしてください。 また、Web上にも似たような事例、もっと大規模なチューニング事例が多く掲載されているのでそちらも見てみるとよいと思います。

お知らせ

メルマガ「ゆーすけべーラジオ」でもWebアプリのつくり方を連載しています。よろしければお試し購読を！

• ゆーすけべーラジオ

ニート革命、つまり職がないときにじゃーどうするの？という問題について、こんなことを書いていた。

...

最近はもう考え方が結構変わっていて、 とりあえずWebで月10万円稼げる方法を何とか見つける！というのが直近の答えなのかなーと思う。

...

僕なりの解釈だと、Webだけで10万円を稼げれば、 住む場所によってはレバレッジが効いて場所と時間に束縛されないんで自由な生活できるんじゃね？ってとこです。

すごい同意です。特に今だったら日本円を稼いで東南アジアに住むなんてプランはありありだと思います。 また10万円という単位も一つの目標としてよい設定値だと思います。

さて、僕は、諸々の事情があって日本に住んでいますが、 Webだけで10万以上稼ぐことはしています。時間や場所に縛られている感覚もありません。 このWebだけで10万円ってのには様々な手段があります。また「Web」ってのをちょっと拡大解釈すると、 アプリ販売も候補に挙ります。

• アフィリエイトBlog
• iPhoneアプリ販売
• Webサービスで広告収入
• メルマガ
• etc...

これら全て僕は実践してきた、もしくは実践しているものです。 そしていくつかは収入として10万円超えを達成しています。

で、僕が書きたかったのはこの中でも 「iPhoneアプリ販売」が一番10万円を達成するのに素早かった という点です。

このグラフは何も関係ないのですがw、まず販売から収入が入ってくるまで2ヶ月で月10万円超えを達成しました。 弊社の企業秘密的なことも含まれるので詳しいことは書きませんが、これは自分にとってかなり驚異的なスピードです。 また、アプリの開発期間は言語能力の取得も含めても2ヶ月ほど。 これを考慮しても速い。

アフィリエイトサイトで10万円以上を達成しているものを所持していますが、 結構この10万円というある意味大台へ載せるのに継続的な運用が必要だったりで大変です。

ま、だからと言ってニート革命の時代はiPhoneアプリを作ろう！というわけではないですが、 一つの事実として記してみたかったということです。iPhoneアプリで収入を得ることに関しては、 以下の本が面白いです。

iPhoneアプリで稼ごう

posted with amazlet at 12.03.03

丸山弘詩 川畑雄補 脇俊済
毎日コミュニケーションズ
売り上げランキング: 63241

Amazon.co.jp で詳細を見る

ちなみに現在は僕にとっての第2弾のiPhoneアプリの配信準備中です。また、 メルマガでは僕のWebで稼ぐワークスタイルを紹介していきたいと思うので興味のある方はお試し購読をば！

• ゆーすけべーラジオ