Ruby Kaja

午後のセッションに入る前にKaja運営主担当の矢部剛嗣さんから，日本のRubyist表彰制度としてつくられたRuby Kajaの発表が行われました。第1回の今回，国内14のコミュニティが自分たちのコミュニティの中からそれぞれの視点で選出しました。Kajaとなった方々は次のとおりです。

• 比嘉正栄さん（@hanachin_⁠）⁠- Okinawa.rb
• 山口真央さん（@gutch_jp⁠）⁠ - 岡山Ruby, Ruby on Rails勉強会
• 小玉直樹さん（@volpe_hd28v⁠）⁠ - Ruby札幌
• たなべすなお（@sunaot⁠）⁠ - るびま編集コミュニティ
• 南齋雄一さん（@track8⁠）⁠ - guRuby
• 池澤一廣さん（@awazeki⁠）⁠ - toRuby
• Takahashi Hayasakaさん（@iwhurtafly⁠）⁠ - Tokyo Rubyist Meetup
• 三村益隆さん（@takkanm⁠）⁠ - Rails勉強会@東京
• 福井修さん（@iR3⁠）⁠ - Sendagaya.rb
• 矢部剛嗣さん（@tyabe⁠）⁠ - Shibuya.rb
• 西川茂伸さん（@shishi4tw⁠）⁠- Sinjuku.rb
• 中田伸悦さん（@n0kada⁠）⁠ - Asakusa.rb
• 成瀬ゆいさん（@nalsh⁠）⁠ - Ruby開発コミュニティ
• 高橋一生さん（@1syo⁠）⁠ - Yokohama.rb

江渡浩一郎さん「ユーザ指向サービスデザイン」

独立行政法人産業技術総合研究所の江渡浩一郎さんによるコンテンツ制作に関する発表です（スライド等はこちら⁠）⁠。江渡さんは「パターン，Wiki，XP」の著者としても知られ，最近では「ニコニコ学会βを研究してみた」を出版され，ユーザ参加のコンテンツについて研究しています。また，江渡さんが開発したメーリングリストとWikiをコラボレーションしたサービス「qwikWeb」は，本札幌Ruby会議2012でも実行委員会での情報共有に利用させていただきました。

このセッションでは，江渡さんの提唱する「ユーザ指向サービスデザイン」について，その概要と，具体的にどのようなケースで成功するのかについて話しました。

ユーザ指向サービスデザインとは？

「ユーザ指向サービスデザイン」とは，どちらかといえば「ユーザによるサービスデザイン」と呼ぶ方が好ましいかもしれないと言います。ユーザ指向サービスデザインを適用したサービスでは，ユーザの協力によって共有された情報を元にプログラムが動作します。さまざまな人の力を集結してサービスが成長していくこと，人の手によって作られた情報であるため状況変化への対応が早く正確なデータを集めやすいという特徴があります。

AutoPagerizeによるWeDataの事例

ユーザ指向サービスデザインが成功したケースとして，AutoPagerizeというブラウザ拡張を紹介しました。AutoPagerizeはページングが必要なウェブサイトで，ページングを行わずに次のページを読み込む機能をブラウザに追加します。

AutoPagerizeでは，次へのリンク位置，読み込むコンテンツの領域などの情報が，ウェブサイト毎に必要になります。さらに，それらの情報はページデザインが変更されれば修正が必要になる情報であり，ウェブページ毎に異なる内容を何らかの手段で設定する必要があります。

AutoPagerizeでは，これらの情報をWedataを使うことで解決します。Wedataはデータに特化したWikiといえるサービスです。特定の利用者が登録したデータを別の利用者が利用でき，さらに変更もできます。したがって，ある利用者がAutoPagerizeを使っているウェブサイトであれば，その他の利用者もAutoPagerizeを利用できるのです。

具体的にどの程度の共同編集が行われているのかというデータは中々興味深いものでした。AutoPagerizeでは，現在，3,000件強の情報が登録されており，そのうち2,000件程度の情報が共同編集されているとのことです。つまり，約7割のデータは誰かが作成し，誰かが修正したデータであり，サービスがニーズにマッチしていることが分かります。

なお，Wedataは様々なアプリ，特にブラウザ拡張で多く利用されているとのことです。

Tweenによる事例

逆に，同じようにWedataを利用していたサービスで，うまくいかなかったサービスも紹介しています。TwitterクライアントのひとつであるTweenは，データリポジトリとしてWedataを利用していたとのことです。しかしながら，Twitterのウェブサイトの情報についてWedataを利用するメリットはありませんでした。なぜならば，Twitterという特定のサービスの変更が行われた場合にのみ，Tweenを更新して対応すれば済むからです。前述のAutoPagerizeのように様々なサイトに対応するためのデータを共有し，共同編集する必要がないのです。

Wedataが適する条件

共有データを扱うWedataがうまくはまるサービスの条件は厳しいと言います。その条件とは，次のようなものです。

• セキュリティ上の問題が無いデータに限られる
• 悪意のあるユーザがデータを入力しても一部分動かなくなる程度で大きな問題にならない
• データを入力することが自分の利益になる
• その上で全員の利益にもなる

AutoPagerizeのようなブラウザ拡張では，不特定で多くのサイトに対応する必要性から，これらの条件を満たすとのことでした。

GitHubとWedata

Rubyistであればお馴染みのGitHubですが，実はWedataとほぼ同時期（2008年春頃）に開始されたサービスです。Wedataに比べ，GitHubではセキュリティへの対応がなされているなど，より洗練されているサービスではありますが，複数人が共同でリポジトリやデータを育てていくという点においては似た思想のサービスであると話します。

異なる点は，プロジェクトにオーナーが存在し，勝手にコードベースを編集できない点です。GitHubで利用しているpull requestという仕組みについては，いくつかのセッションで紹介されていますね。

最後に

本セッションでは，ユーザー自身がサービスを便利にすることができる，ユーザー指向サービスデザインという考え方を紹介し，具体例としてWedataという共有データリポジトリを実装してわかったことを話しました。実際にWedataはブラウザ拡張で多くのユーザに利用され，一定の成功を収めているため，「⁠ユーザが自分でサービスを拡張でき，その情報を共有することで成長できるようなサービスというのは有効である。みなさんもユーザーの力を取りいれるサービスを設計していこう」という提唱しました。

白土慧さん「Spree で約3ヶ月でイチからEコマースサービスを作るまで」

札幌生まれのWebアプリケーションエンジニア・白土慧さんから，開発に携わったEコマースサイトと，利用したRuby on Rails製Eコマースサイト構築基盤「Spree」についての発表です（スライド等はこちら⁠）⁠。

「Oh My Glasses」

白土さんが開発に携わったのはOh My Glassesという，メガネをインターネット上で販売するB2CのEコマースサイトです。セッション冒頭ではOh My GlassesからFacebookページの開設のお知らせ，ならびに札幌Ruby会議2012参加者向けクーポンコードを提供しました（クーポンコードはsprk2012です。掲載確認済み⁠）⁠。

答えの決まっていない問題に立ち向かう

Oh My Glassesは2011年12月にクローズドベータ版が開始，2012年1月に正式リリースしたサービスです。運営母体はいわゆるスタートアップと称される，所属メンバー4人のベンチャー企業です。白土さんの参加以前はエンジニアが誰も所属していませんでした。

エンジニアがいない会社でサービスを始めるのってどうなの？と疑問に思う人もいるでしょう。ただ，白土さんはこの方針に賛成の立場です。

「メガネをWebで販売することは可能なのか？」という答えの決まっていない問題に対し，白土さんは書籍「リーンスタートアップ」を引き合いに出し，何よりもまずはサービスを始めてみることが，答えを作りだすためのフィードバックを得る最短の方法だと考えているとのことでした。

実際にサービスを始めることで，顧客はどこにいるか？ 商品の仕入れはどうするか？ オペレーションは回るのか？ といった，やってからでないとわからない様々な問題にぶつかります。こういった問題に対処するためにも，どんな形であれ，まずはサービスを出してしまうことが正解と考えています。

「リーンスタートアップ」で述べられている，

• 答えの決まっていない問題に答えを出す
• 評価をするためにフィードバックを使う
• 締め切りまでにイテレーションをどんどん回す

といった考え方は，書籍「アジャイルサムライ」にも共通して言及されています。前者は経営者向け，後者は開発者向けを意識しているという違いがあり，それぞれの書籍を読むことでお互いの手法が参考になるだろうと白土さんは話していました。

PHPからRuby/Railsに切り替えた理由

Oh My Glassesは当初，PHP製のEコマースフレームワークMagentoで構築していました。縁あって白土さんがエンジニアとしてOh My Glassesに参加したとき，「⁠PHPのフレームワークを使い続けるか？ Ruby on Railsで作り直すか？」という選択を迫られました。

白土さんは，イテレーションをどんどん回して試行錯誤しながら答えを出すために，今いるエンジニアの手に馴染んだ早く開発のできるプラットフォームを選ぶべきと考え，白土さんにとって馴染んでいるRuby/Railsを選択しました（ただし，もしPHPが得意なメンバーがいればPHPを使い続けていたかもしれません⁠）⁠。

巨人の肩の上に立つ

システムをRailsで作りなおすことを決定しましたが，この時点で白土さんにはEコマースサイトを構築した経験がなく，特にカートや決裁処理を一から実装することに不安を感じていました。そこで調査して見つけたのが「Spree」でした。Spreeには販売商品の登録・展示，カート処理・決裁，管理者のための管理画面といったEコマースサイト向けの機能が標準で備わっていました。

白土さんのチームは事業を成功させることを最優先とし，Spreeというすでに用意された仕組みに乗っかることに決めました。白土さんは，このように「先人の残したよいものを活用する」ことを，慣用句である「巨人の肩の上に立つ」という言葉で表現していました。

巨人の構造を知る

続いて，Spreeという「巨人」について概要の説明がありました。Spreeの構造は，spree_coreをベースにspree_api, spree_auth_devise, spree_promoなど複数のgemに分かれており，利用者の必要な機能を選択して導入することができます。これらのプログラム群は，Rails3のEngineという機構を用いています。なおEngineについては2日目の松田明さんのセッションでも説明されています。

白土さんは，開発を始める前にSpreeの内部構造を知るために解析を行いました。公式のドキュメントにはコードに関する説明は少なく，コードそのものを読んだり，時には入手したソースコードにデバッグ用コードを埋め込んで実行することで解析を進めました。この作業においては，機能に影響を与えずに指定オブジェクトのダンプ情報をコンソールに出力するtappがたいへん役に立ったとのことです。

フォーカスを絞る

Spreeへの置き換えにあたっては，サービスを公開し事業を回すことを優先しました。このため，PHP版で提供してた機能は最低限Spreeには移行するものの，新しい機能の開発は後まわしして，やるべきことにフォーカスを絞って作業を進める方針をとりました。

例えば，Oh My Glassesではメガネのフレームをカートに入れた後，フレームのみ購入するか，レンズをはめた場合度つきにするかしないか，顧客自身で選択することができます。選択したレンズの種類によって最終的な価格が変動しますが，このような処理はオリジナルのSpreeには存在しないため，独自に処理を追加してカスタマイズする必要がありました。この場合も，できるだけ少ないコード量で「選択したレンズの種類に応じて価格を変動させる」処理を追加する方法を調査して，おおがかりな実装をせずにすませることができたそうです。

こうして2012年1月からOh My GlassesのSpreeへの置き換えを始め，3ヶ月後の2012年3月に新しいサイトをリリースすることができたとのことでした。

ふり返り

白土さんはSpreeを利用して，カートと決済周りがよくできていると感じています。ただ商品の取り扱いに関しては，Spreeに依存しすぎることで後から大変になるかもと感じています。最初から管理画面が使えることは好印象で，商品の発送やキャンセル処理など，非エンジニアのスタッフが管理画面から作業を行えることは大事だと感じたと話します。

EコマースのWebサービスを作ってみてどう感じたか？という問いに対しては，白土さん自身，もともとB2CのEコマースサービスをやってみたかったこともあり，開発には楽しさを感じているとのことでした。また「メガネを買ってもらい，お客様に喜んでもらい，事業が成功する。以上」というシンプルでわかりやすいビジネスモデルであることにも，やりやすさを感じていると述べていました。

最後に，社員4人だけのスタートアップに参加したことについて白土さんは，人が少ないのでやることがとにかく多いと感じています。何を優先すべきか検討し，決まったらそれのみに集中するよう心がけており，仕事を進める上でもフォーカスを絞る事を常に意識して行動しています。また，誰かに指示されなくても，自分で何をするか選択して仕事を進める事にも楽しさを感じているとのことでした。

まとめ

SpreeによるEコマースサイトの構築事例だけに収まらず，スタートアップ環境における仕事の雰囲気や，仕事の進め方・心構えがよく伝わるセッションでした。

セッション終了後の質疑応答の時間では，アプリケーションのテスト方法の苦労話，デザイナーとの協業，Spree自身のパフォーマンス，Spreeに依存しすぎることに対する懸念点などの質問が会場から寄せられました。