スマホ経由CV数2.2倍に

数ヶ月かけて、進めてきた「サイタ(cyta.jp)」のリニューアル結果が出てきたので、今回はその設計思想とプロセスについてお話できればと思います。

結果から言えば、大成功でした。もはやサイタも、今はスマホのアクセスがほとんどですが、そのスマホ経由のCVRが2.2倍までupしました。そこで今回は、そんな「サイタ」での事例を、CtoCサービスを中心とした中規模~大規模サービス事業者にとってもいくつか参考になる部分があるのではと思い、記事を書いてみることにしました。

CtoCサービスのCVRを上げるのはなかなか難しい

「サイタ」でも、CVRはずっと抱えていた課題でした。しかも、 SEOによる集客が中心である「サイタ」のようなサービスでは、検索エンジンネガティブなことが起きる可能性のある、リニューアル案件は、なかなかやろうと思ってもリスクが高く動きにくかったので、まずは1ジャンル使って検証してみることにしました。

小さく試して、大きく展開。

リリースまで1週間、結果の検証3ヶ月というスケジュールで、「サイタ」のドラムジャンルのとあるテンプレを総入れ替えしました。

検証する部分は、

・CVRがどのくらい上がったのか

・入会率に影響はあったか(急激に落ちていないか)

・LTVの初速は落ちていないか

・SEOは落ちていないか

の4つのポイントでした。これを全て計測するには3ヶ月かかってしまいます。

ページの内容は、特定の駅で学びたいコーチを選ぶのみ、というコミュニケーションから、サイタの説明をバリバリやって、「選びたい人は先生選んで、わからない人はお問い合わせしてください。」というコミュニケーションに変更したものでした。

すると、このテンプレのランディング経由のCVRが2.8倍まで上昇したのです。また、入会率やLTV、SEOにも影響はなく、「これは、イケる！」と確信したのです。

「先生選び」という選択肢を減らすUX設計

もともと、「サイタ」では、「学びたいジャンルは決まっていても、どの先生に何を習ったら良いかはわからない」という問い合わせが多く、電話でコンバージョンすることがよくありました。「サイタ」では、2014年からコールセンターを本格稼働させて、サービスを伸ばしていきました。

これは、CtoCサービスの多くが直面している課題だと思います。ただし、「ユーザーが本当に求めているのは、こういったプラットフォームか？」ということを考えたときに、無理に先生を選ばるという選択は、「No.」でした。この思想を、今回の「サイタ」のスマホサイトリニューアルの目玉にしました。

料金体系や、サービスの仕組みをまず明確に伝える

ユーザーによりサービスを深く理解してもらわなければ、CVまでたどり着きません。サイタの流入元はOrganic検索が多く、「ドラム教室」や「ドラム　レッスン」といったようなクエリです。彼らが検索するにあたってどういった情報を求めているのか？ということを徹底的に考え、「どのようなレッスンを・どのくらいの料金で・どこで」出来るのかということが重要だと考えました。

ファーストビューには、その要素を盛り込みました。これまでは、「ドラム教室」や「イラストレータ　講座」などと検索すると、まずは地域を選んでください、先生を選んでくださいというコミュニケーションで作り込んでいたのですが、ユーザーが一番欲しがっているのは、「どのようなレッスンを・どのくらいの料金で・どこで」というイメージだと考え、このように画面を設計しました。

コーチを、より魅力的に伝える

また、リニューアルにあわせて、コーチの個別ページ(スクールページ)をリニューアルしました。よりコーチが魅力的にうつるように、そして写真も顔写真だけではなく、作品の写真やレッスンイメージの写真など、多くのアプローチで「レッスン感」を出せるように意識しました。

メリハリのある導線設計が一番大変だった。

このようにして、CVRを2.2倍まで上昇させることに成功しました。しかし、これらの画面の要素が重要であることはそんなに難しく考えなくても分かっていたのですが、これをサイト全体の構造を崩さずに、そしてOrganic流入を減らさずに行うというのは、とても大変でした。

「サイタ」では、各ランディングページをそれぞれ流入比率やコンバージョン率を細かく分析し、導線設計を丁寧に行いました。次回は、どうやってSEO評価を落とさずに導線設計をしたのか、そしてウェブサービスのバリューを崩さないことを意識したのか。というお話しをできればと思います。

この記事に興味をもっていただけた方は、likeとかシェアとかしていただけると、記事を書くモチベーションが上がります。笑

はじめに

こんにちは、「サイタ エンジニアブログ」は、今回から「サイタ 開発者ブログ」として、エンジニア以外からの記事も掲載していくこととしました。「サイタ」がどのようなメンバーで、どのような文化で開発/運営されているかを少しでも知っていただければうれしいです。

さて、今回はサイタの事業開発チームの中で社内勉強資料として使われれているものの一部を投稿させていただきます。

この記事では、「cyta.jp」時代には、もう手をつけられなくなっていた、カスタムキャンペーン設定を、サイタカメラ教室(ca.cyta.jp)でまるっと整理することができたので、それについてお話しさせていただきます。

Google Analyticsについての説明はここでやる必要はないと思いますが、このカスタムキャンペーン設定は本当に大変なんです。事業が始まって1年以上経過していれば、もう使いこなすことは不可能と言って良いと思います。

事業拡大期には、「打ち手」の正しい判断と効率化/定型化が必要。

事業「立ち上げ」期の仕事の進め方：「とにかく手を動かせ」

事業立ち上げ期は、analyticsを含めて、何も準備する必要はありません。とにかく行動あるのみ。目の前のサービスを作ったり、ユーザーを作ることに集中するのがベストだと思います。あまりにも実績や結果がないので、その結果を作らなければ今後何も動くことができません。

事業「拡大」期の仕事の進め方：「非効率な業務は全部捨てる」

ただし、事業拡大期には、上記のような仕事の進め方をすればするほど、視野が狭くなり、サービスが思うように成長しなかったり、仕事を分業化できず、小忙しくなってしまいます。

これまでやってきた施策をレビューし、効率性をどんどん高くし、仕事を定型化し、メンバーや事業規模を拡大し続けるのが大事なのではないかと思います。

Google Analyticsのキャンペーン設定をきっちりとできれば、サービスは必ず伸びる。

そこで今回は、Google Analyticsのキャンペーン設定という部分について説明できればと思います。

カスタムキャンペーンで実現できること

上図は、実際に設定完了したAnalyticsのキャンペーン管理画面です。

これまでは、Adwordsであれば、Adwordsの管理画面。YahooであればYahooの管理画面。各メディアは各メディアの数値を集計して管理をしなければならなかったものが、一元管理できるようになりました。

各媒体を木、各個別施策を実として考えると、これまではそれぞれの木を見ながら、身を間引きして、悪いものは外し、良いものは残して伸ばす。ということをやったり、木自体を伐採して他の木に栄養を与える。というようなことをやっていました。

それが、「カスタムキャンペーン機能」を活用することで、リアルタイムに一元管理されるので、マクロに施策を捉えることができます。大きな木の幹を一つにできるようなイメージです。

例えば、

• 「広告自体、あんまりうまくいってないんじゃないの？」
• 「外部メディアからのアクセス、最近増えてるから、もっと増やしたほうが良いんじゃない？」
• 「いろんな広告で、リマーケティングやってるけど、全体的に調子が良くないから、リマーケティングだけ一旦止めてみない？」

といったような議論ができるようになります。

Analyticsならではの、「リアルタイム性」と、「各種統計情報」のストック。

AdwordsやYahoo listingは反映に1,2時間かかる場合が良くあります。各マーケティングツールなども、時間がかかるものが良くあります。しかし、Analyticsは、1秒単位でユーザーの情報を記録しているため、新しい打ち手をやった時に、「5時間後に判断する」というようなことができるようになります。

これまでは、1週間や2週間かけていたような施策のレビューを、朝やって、夜レビューというように1日の中でできるようになることで、事業開発のスピードがガンガン上がります。

あた、アナリティクスは、すべてのユーザーの行動履歴を同じようにまとめているので、各施策を比較するのにはとても便利です。滞在時間や直帰率など、ユーザーの傾向を見ながら、新しいアイデアを膨らます材料にすることもできます。

キャンペーン管理できるようになるために：「パラメータ」の機能と考え方。

カスタムキャンペーンに対応させるのは、とても簡単

URLの末尾に、Analyticsが指定するルール通りにパラメータを設定するだけで、管理可能になります。URLがめちゃめちゃ長くなりますが、がんばって耐えましょう。短縮URLや他のリダイレクトされるような分析ツールなどにも対応しているので、とても便利です。

パラメータのルール作りがとても重要

細かい仕組みなどについては、こちらの 「Google Analyticsのカスタムキャンペーンについて」を見ながら勉強してください。

ここでは、簡単に説明しますが、

• Source
• Medium
• Campaign

という3つの要素があります。これは自由にユーザーが割り当てることができます。広告管理での、「アカウント」「キャンペーン」「広告グループ」というような構造をイメージしていただけるとわかりやすいと思います。

ここで重要なのは、

• 「パラメータ」を変更すると、データは引き継がれない
• すべての施策ごとに、パラメータを設定しなければならない。

ということです。事業拡大期にパラメータ管理を行う上で、以上の2点が重要になります。

バナーの色合い、種類、キーワードの部分一致完全一致設定、タイトルの変更など、施策数は1年で軽く数百、数千の単位になると思います。これにすべてパラメータを割り当てなければなりません。とてもじゃないけれど、サービス開始から数年経ったサービスで設定するのは不可能です。立ち上げ期はそんなことをやっている暇がないので、この、拡大期の一番初めにやるのが大事なのです。

僕の場合、上記のようなルールで管理しています。

特に重要なのは、utm_campaignの部分。管理画面を開くと、一番最初に現れる部分です。(下の図です)

ここの名付けルールを間違えると、後で新しい施策をやった時に、MECEにならずやりなおし、とならないように注意します。

utm_campaignのルール付け

サイタカメラ事業では、上記のように名付けるようにしています。

• 媒体名(サービス名)ごとでの管理
• キーワード広告やバナー広告、メールなどの横断的な媒体種類別の管理
• インタレストマッチや、リマーケティングなど、施策分類別での管理

といったようなことができるようになります。施策番号やクリエイティブ番号にもルールをつけていけば、将来的には、コミュニケーションパターンや入稿するキーワードや配信ターゲット別などにも管理できるようになります。

別運用シートでかならず管理する。

まとめ

新しい施策にチャレンジして、成功するには、たくさんのチャレンジの種を育てないといけません。その育てる種の一つが、GoogleAnalyticsのカスタムキャンペーン管理だと思います。また、種であると同時に、後任担当者への情報共有ツールにもなります。新規事業を成長させる段階では、人を増やす場面も多いと思います。状況に応じた施策の行い方をおこなうことで、事業スピードも数倍高まるのではないかなと思います。

先日、サイタの MTA を全面的に SendGrid に移行しました。移行後数ヶ月経ち、今では安定運用のフェーズに入っております。実は移行直後はなにかと色々あったのですが、その辺りのゴタゴタも含めて、移行の顛末をお話したいと思います。

なぜSendGridなのか

これは、約1年前の検討記事をご覧いただいたほうが良いのですが、当時いろいろ比較した結果、私たちの業務上必要な要件を(APIレベルで)十分に満たす、最後の選択肢だったからです(現時点でも、ざっと調べましたが、他の有力な選択肢は挙がってきませんでした)。加えまして、前記事をポストした後、日本での代理店である構造計画研究所の担当者さんよりコンタクトをいただいており、たびたび facebook 経由でメッセージをする機会もあったものですから、漠然とサポートに対する安心感を抱いておりました。

なぜこのタイミングで移行したのか

結論から言えば、けっきょく運用が大変になってきた、ということになります。

背景としては、おかげさまで、サイタのレッスン実施量が前年に比べて倍以上に増大してきているということが大きく影響しています。当社のメール配信は、主としてオフラインでのレッスン実施という行動を支えるための、リマインダーや意思確認が目的ですので、レッスン量が倍になったことで、メールの配信量は数倍以上に増加してきました。各種施策での一斉メール配信についても定常化してきたため、いよいよシステム運用が大変になってきました。

具体的には、とくに一斉メールとレッスン実施数が重なる曜日や時間帯について、一部ドメインから deferred 応答で嫌われるということがたびたび発生しておりました。運用担当者としても、deferred 発生時の backoff time をどう調整するか、そもそも送れなかったメールがレッスン実施のために重要なものなのであれば、調査復旧以前に電話などメール以外の連絡方法でサポートしなければならないのではないか、などの調査/サポート/判断をたびたび迫られることになってきました。こういった状況が「運用の人的コストを本当に下げられるのであれば、外部運用に移行しよう」という決断を後押ししてくれました。

さらに言うなら、サイタでは昨年後半より新規事業立ち上げの仕込みをおこなっており、ちょうどこの事業の立ち上がりに合わせて、チームの編成をいろいろ見なおしているところでした。私自身「やるなら、今だな」と納得できるタイミングだったと言えます。

どう進めたのか

かねてより facebook メッセージでやりとりしていた担当者さんに、「相談させてください」とコンタクトしつつ、昨年頭より寝かせてあった米国アカウントでの、仕様の読み進めと検証環境の開発をおこないました。対面での相談の機会に備えて、ある程度確認するポイントを絞っておいたほうが良いと考えたからです。進めていく上で、2点ほどハマったので、ざっとまとめます。

日本でやるならおとなしく日本アカウント作ったほうがよい

構造計画研究所さんのサイトからサインアップすると、数日でアカウントが使えるようになり、ダッシュボードにもアクセスできるようになります。このダッシュボードにある日本語のドキュメントが、とてもわかりやすく構成してある(個人の感想です)ため、本家のマニュアル見ながら唸るよりも、とっととコレをみればよかった、と感じました。構造計画研究所さんでアカウントを作っておけば、サポートのときも同じダッシュボードが共有できるようで、そういった面でも日本アカウントにしておくのが安心です。

Bounce をメールで受け取ることはできない

私たちの元々の運用では、個別のメールの Bounce を Return-Path に設定したアドレスへのメールで受け取り、これをパースして Bounce 処理をおこなっていました。SMTP API を使えば良さそう、ということはわかっていたのですが、検証していても Bounce メールは戻ってきてくれないですし、実際に送信されたメールを見るに、SendGrid 側で Return-Path を追加しているようだったので、「ウチの要件の場合、単に MTA を切り替えるだけではダメだな」と感じていました。

SendGrid の仕様を読んでいくと、Event Notification という機能があり、これを設定しておくことで配送成功/失敗の各種イベントが受け取れることがわかりました。Event Notification は HTTP でのコールバックで受け取ることができ、このコールバックで SMTP API で仕込んでおいたパラメタを受け取ることもできそうだったので、この機能が使えるのではないか、と考えました。プロトタイプレベルの実装でも問題なく動いていたので、SendGrid の方との打ち合わせでこの設計方針について意見交換し、諸々不安な点も解消できたので、この方向で行こう、という判断ができました。

ちなみに、担当の方との打ち合わせで使ったのは、以下のようなドキュメントでした。

けっきょく、切り替えに当たり、若干の追加開発を伴うことになりましたが、個人的に API とお話するのは嫌いではないので、楽しみながら開発と切り替えの準備を進めました。

どう切り替えたのか

もともとオンプレのメール配信環境において、postfix の transport(5) によるリレー配送をおこなう構成にしてあったので、切り替えのハードルは比較的低かったです。まずは一部のドメイン宛のみ SendGrid 配送に切り替えて様子見し、新旧の MTA を混在させた状態で数日様子見をしました。問題なく運用できそうだったので、最終的にリレー先の MTA を一気に SendGrid へ振り向けることで切り替えを完了しました。

それでもハマった

切り替え後は、ダッシュボードの Activity 機能で処理状況を確認していました。数時間は問題なくメールが流れていたようで、胸をなでおろしていたところ、一部のドメイン宛のメールが軒並み deferred 応答になっていることに気がつきました。前回、Mailgun に切り替えたときと同じ状況です。恐らく最初から、このドメイン相手では deferred になっていたのでしょうが、相手方からのメッセージが broken pipe と表示されており、どうも情報が少ない。状況をみるに、宛先ユーザー特有ではなく、宛先となった当該ドメインに対するすべてのメッセージでこの応答になっておりました。

実際に送られているメールのSMTPヘッダの構成確認や、アプリケーションを介さない手元からの送信試験などで切り分けを進めましたが、SendGrid 経由のときだけ相手方に嫌われているような印象だったため、SendGrid サポートに連絡をとりました。幸いにも、導入前に相談に乗っていただいていた方が、直接切り分け作業にご協力いただけたので、数時間ほどで宛先方の要因: SendGridアカウントに割り当てられたIPアドレスを拒否されているのではないか、という話に至りました。さらに、異なる帯域でのIPアドレスを追加し、ラウンドロビンで配送しわけることで、当該ドメインへのメールが通り始めるのであれば切り分けできる、というご提案をいただき、即時IPの追加を依頼しました。

さらに数時間後、この追加IPからの配送ではメールが正しく送られることを確認できました。これで完了か、と思っていた矢先、今度は別の宛先ドメインで追加したIPを拒否されるという地雷を踏んでしまいましたが.. そういった切り分けや別IPの割り当てなどのご対応を随時メッセージでやりとりできたおかげで、対応は深夜にまで及んだものの、完全切り替えから24時間以内にひと通りの問題が解消、というところまで行き着くことができました。サポートの方は、切り替え初日から異なる帯域のIPの即時割り当てや切り分けの調整で、米国側ともやりとりしていただけたようで、このスピード解決は本当にありがたかったです。

その後

切り替え後3ヶ月ほど経ちますが、非常に順調に稼働しております。なにより、たびたび(あまり予期できないタイミングで)発生する deferred と個別に付き合わずとも、かなりいい感じに早めに再送してくれているところは、本当に助かっています。切り替え当初は Activity を見ながら「おお、こんなに早く再送かけちゃうんだ」と、そのノウハウに感動しました。連日大量のメールを捌いているのは伊達じゃない。

また、サポートの方とは、何かあるたびに、気軽にコンタクトできますし、利用状況や Reputation も気にかけていただけているので、なんとも言えない安心感があります。ちなみに、自前のオンプレでは 96% 前後だった Reputation も 99% 以上を維持できています。

まとめ

スタートアップのような小さなチームでやっていると、インフラエンジニアを専任で確保するのは難しいですし、とはいえインフラ系でハマると調査と解決に孤独な戦いを強いられることになります。そういう状況が頻発してしまうようなフェーズにおいて、インフラ業務の技術的な部分をがっつり相談できる SaaS のユーザサポートはとてもありがたいですし、SendGrid のサポート体制には本当に助けられました。

サービス開発にあたって、運用の部分でラクをできる SaaS は数多くありますが、エンドユーザ向け機能の商用環境に投入するとなると、なかなかハードルは高いものです。SaaS の提供元が海外企業だったりすると、なおさら情報が少なく万一の際にどこまで自力で対応できるのか、本当にコストメリットが出るのか、などの理由で、どうしても二の足を踏んでしまいます。そもそも、移行による価値を予想/確信しにくいからかもしれません。

少ない人数でサービス運営をしているからこそ、サポートの存在はありがたいです。自分が本当に費やすべきエンジニアリングに対する時間を確保するためにも、SaaS を選ぶときには、サポート体制にしっかり目を向けることが重要、そして、この価値観/視点は(機能検証と利用コストのみを気にしていた)去年の自分にはなかったな、と思う次第です。

こういったメールサーバ運用の話はあまりお見かけしないのですが、どなたかの参考になれば幸いです。それでは、また。

補足

当社のメール配信周りの運用について、先日、AWS Startup Tech 夏のLT大会 2015 at dots.でお話させていただきましたので、こちらの資料もよろしければどうぞ。

オフライン行動を支えるメール配送管理 at サイタ - SlideShare

@tmtysk

このたび、コワーキングスペース茅場町 Co-Edo（コエド）様の会場をお借りして、 “スタートアップチームコミュニケーション術報告会” と題した勉強会を開催しますので、この場を借りて告知させていただきます。

サービスの開発現場では、エンジニアやデザイナ、事業プロデューサなどの役割を超えた、オープンでフラットなコミュニケーション文化が重要ですが(と筆者は考えていますが)、イベントという形式で、スタートアップチームに特化したチーム内コミュニケーションの実態が共有される場はあまり無かったように思います。

今回の報告会では、「あのアイコン」のブログでおなじみのKonifar氏ほか、事業フェーズやチーム規模の異なるスタートアップのエンジニアを登壇者に迎え、各社の社内コミュニケーションフローや開発プロセス、トライアンドエラーの実態に迫ってみたいと考えています。

参加申込は connpass でおこなえます。多くの方のご参加をお待ちしております。

@tmtysk

去る 2015/6/5 に、当社オフィスにて「神南エンジニアリング勉強会Vol.1」を開催しましたので、そのレポートをします。

「神南エンジニアリング」とは、渋谷区神南地区にお勤めまたは出没しているWebエンジニアのためのコミュニティで、2015年5月に活動を開始しました。 主な活動内容は以下のようなものです。

• Slackでおしゃべり
• ランチに行く
• 勉強会をやる
• 飲みに行く

当社は少数のエンジニアチームでやっておりますので、かねてから情報交換を求めて、近隣の会社に突然声をかけては、ランチを口実に話をする、という行為に及んでおりました。そういったことを重ねているうちに「意外と神南地区に同じくらいの規模のチームが多いな」ということに気づきはじめ、「じゃあ、全員同じコミュニティで交流できるようにすれば、もっと有意義だし、面白いし、ひとりランチ難民になるリスクも下がるじゃないか」ということで、このようなコミュニティ活動を開始した次第です。

さて、今回の勉強会は、初回だったのでクローズドに企画(というわりに、connpass でしれっとイベントページを作っていましたが)していたのですが、嬉しいゲストもあり、総勢11名参加での開催となりました。

勉強会のテーマは「各社のサービス環境共有会」ということで、参加各社から15分程度の発表+質疑応答というメニューで進行。各社の開発プロセスや利用ツール、改善へのアプローチや試行錯誤など、多少踏み込んだところまでが垣間見える、非常に有意義な会でした。

以下、勉強会の様子を簡単に紹介します。

STORES.jp 運営の Bracket 社さんからは新卒エンジニアMさんの、初発表でした。冒頭のメニューから、「発表内容がちゃんとしている..!」と会場がざわつき、残りの発表者2名が急いでスライドを修正追加するという事態に。

スライドは、こちらからどうぞ。

2番手、コーチ・ユナイテッド社(当社)からは私が発表しました。開発プロセスや稼働環境の話に加えて、先のブログでも紹介した Twilio の話などをご紹介しました。

スライドは、公開版として少し削ってありますが、よろしければこちらからどうぞ。

最後にLiB社からYさんが発表。社内での Slack コミュニケーションの様子や、おひとりで開発を支えてこられた時代から編み出された改善の手法など、非常に参考になるお話が聞けました。

スライドは、こちらからどうぞ。

勉強会後の懇親会でも、発表内容に関する質問や意見が交わされており、とても楽しい時間となりました。ご参加の皆様、ありがとうございました。

さて、「神南エンジニアリング」は、ローカルな活動をしておりますが、こういった勉強会についてはオープン開催ができる時期がくるかもしれません。そのときには、またこちらのブログなどで紹介させていただきたいと思います。

@tmtysk

CtoC サービスで個人間の待ち合わせ用電話システムを実現するのに、Twilio を使ってみたらとても面白くて簡単だった、という話を書きます。(Twilioさんから何かもらってるわけではないですよ。)

当社の習い事サービスは、オンラインでの申し込みから始まりますが、実際のレッスンはオフラインでおこなわれます。つまり、会ったことがない個人と個人に、時間通りに予定の場所で出会ってもらうというのをコーディネートするわけですが、これは、なかなか簡単にはいきません。

待ち合わせといえば携帯電話が便利ですが、携帯をつかった待ち合わせは、お互いの電話番号がわかっていることが前提。これからレッスンを受ける/教える相手とはいえ、見知らぬ相手と、携帯電話番号を交換してしまうことに抵抗を感じる方は少なくないと思います。

そこで、Twilio です。

Twilio は、電話や SMS を Web サービスに統合できる API サービスなのですが、上記のような当社の課題にうまくフィットしてくれました。

具体的には、以下の図のように、お互いの電話番号を知らなくても、通話ができるシステムを構築しました。(開発時のイメージにつき、裏紙手書きはご容赦ください。)

Twilio は、サインアップして、050 番号を取得して、着信時のリクエスト先(上図の 2 の接続先 URL)を設定すれば準備完了。サイタのシステム側では、発信者番号から当日のレッスン予定を検索し、4 の応答(TwiML と呼ばれるXML形式)を返してやるだけでした。

TwiML では音声読み上げを指定できます。たとえば以下のような応答です。

<?xml version="1.0" encoding="UTF-8"?>
<Response>
  <Say voice="woman" language="ja-JP">
    お電話ありがとうございます。
    こちらはサイタ事務局、お待ち合わせ専用ダイヤルです。
  </Say>
  <Say voice="woman" language="ja-JP">
    ヤマダタロウさんへお繋ぎいたしますので、このまま少々お待ちください。
  </Say>
  <Dial callerId="+8150xxxxxxxx">+8190xxxxxxxx</Dial>
  <Say voice="woman" language="ja-JP">
    お電話ありがとうございました。 
  </Say>
  <Hangup/>
</Response>

実際に読み上げさせてみると、日本語の読み上げは、やや違和感はあるものの、実用上問題ないレベルです。(アプリケーションを組み上げる前に、幾つかサンプル応答を返すモックサーバーを用意してやって、句読点による読み上げかたの違いや、よく使う漢字の読みの正確性を確認したりしました。(読み上げだけならテストするツールがあったような気も。))

ちなみに、講師などは、1日に複数のレッスンを抱えていることもあります。そこで、当日のレッスン予定が複数ある場合は、プッシュ信号を送ることで、接続先を選択できるようにしました。このときの応答は、以下のようなものになります。

<?xml version="1.0" encoding="UTF-8"?>
<Response>
  <Say voice="woman" language="ja-JP">
    お電話ありがとうございます。
    こちらはサイタ事務局、お待ち合わせ専用ダイヤルです。
  </Say>
  <Gather timeout="60" action="https://example.com/example" method="POST" finishOnKey="#">
    <Say voice="woman" language="ja-JP">
      ヤマダタロウ様の、本日のレッスン予定は、5件です。
      これからご案内する番号をダイヤルし、最後にシャープを押してください。
      10時00分からの キムライチロウさんへのお電話は、1。
      11時00分からの キムラジロウさんへのお電話は、2。
      16時30分からの キムラサブロウさんへのお電話は、3。
      20時00分からの キムラシロウさんへのお電話は、4。
      21時00分からの キムラゴロウさんへのお電話は、5。
      を押し、最後にシャープを押してください。
    </Say>
  </Gather>
  <Say voice="woman" language="ja-JP">
    お電話ありがとうございました。 
  </Say>
  <Hangup/>
</Response>

Gather という動詞で、受け取ったプッシュボタンの送信先を指定してやります。冒頭の図でいえば、4 と 5 の間に、ひとつ API を追加して、このボタンに応じた電話の中継先を返してやるイメージです。

追加した API(URL) での応答は、接続先は決まっているので、以下のような簡単な内容となります。

<?xml version="1.0" encoding="UTF-8"?>
<Response>
  <Say voice="woman" language="ja-JP">
    キムラジロウさんへお繋ぎいたします。このまま少々お待ちください。
  </Say>
  <Dial callerId="+8150xxxxxxxx">+8190xxxxxxxx</Dial>
</Response>

なお、実際にシステムを構築し、検証してみたところ、上記 1 の発信先 050 番号は、複数電話番号から同時にかけても話中になること無く、通話可能であることがわかりました。当初、複数の電話番号を取得しておき、ユーザーごとに電話番号を動的に割り当てるような運用が必要になるかも(そうなると、電話番号が毎回変わるのでユーザーが混乱しそう)と考えていたのですが、この仕様のおかげで、単一の電話番号で運用できます。電話番号毎にかかる月額料金も最小限で済みますね。

こちらの機能は「待ち合わせ専用ダイヤル」としてリリースしました。リリースして1ヶ月ほど経ちますが、大きな問題もなく運用できています。こういった電話を使用したシステムのリリースは初めてだったので、どれだけスムーズに受け入れられるか心配でしたが、ユーザーにとっては Web のシステムよりも電話システムのほうが馴染みがあるのかもしれませんね。

システム側では電話着信ログを取得することもできるので、これまで把握できていなかった、「実際にどれくらいのユーザーが(待ち合わせのために)電話による通話を利用しているのか」を見ることができるようになりました(そして、想像していた以上に利用されることもわかりました)。これは、レッスンまでの各種誘導のコミュニケーション改善効果を測る指標としても使えるかもしれません。

公式サイトのハウツードキュメントを見ると、他にも電話連携のための様々な機能が利用できることがわかります。電話と繋がるWebシステムって楽しいですね。電話会社出身の筆者としては、こんなシステムが、ここまで手軽に構築できてしまうことに驚きです。数年前までは、こういったものを独自構築したら、機材設備含めて数百万円以上のプロジェクトだったのではないでしょうか。

というわけで Twilio で、簡単に電話連動サービスができてしまったというお話でした。

それでは、また。

@tmtysk

毎年思うのですが、花見のシーズンってすぐに終わっちゃいますね。今年は、オフィスから徒歩圏内の代々木公園で2度ほどお花見ランチができたので、だいぶ春を味わっている感があります。花粉つらいですが。

さて、社内文書を晒すシリーズ第2段。今回は、社内のコードレビュー運営について書いてみたいと思います。

早速ですが、以下が、当社の定期コードレビュー運用に関するドキュメント(無修正)です。

定期コードレビュー

目的

言語化されていない、コーディング/設計ノウハウや文化/価値観の洗い出しと共通認識の形成

哲学

• レビュー対象はコードであり、プログラマではない
• コードレビューでは、設計やコードの修正を求めない
• 自分のことは棚に上げ理想論を振りかざすのが善、現実論は聞き流す程度に
• 発言が善、沈黙は悪

運用の設計

• 週1、30min
• 進行は当番制
• 進行役が、責任をもって、開催までに、レビュー対象のコミットやコードを選定する
• 選定の候補は、自薦もしくは他薦で事前に募る。この募集プロセスも進行役の役目
• 毎回5min、KPT (Keep, Problem, Try)のふりかえりをする
• 随時レビューは、これまで通りおこなう

このドキュメントを書いたとき、つまりコードレビューを定期的にやろう、と思い至ったときに考えていたことは以下のようなことでした。

• コードレビューが個人攻撃の場にならないようにしよう
• かといって、現実を見つめて傷を舐め合うような場にはしたくない
• むしろ前向きで、かつ、プログラマであることが楽しいと思えるような場にしよう

こういう当初の考えというものは、口頭で伝えたところで流れていってしまいがちですし、自分自身忘れてしまうので、自分の気持ちを整理する意味もこめて、ドキュメント化するようにしています。また、こういったドキュメントは、書きっぱなしになって忘れられることもままあるため、プリントアウトしたものをデスクの前の窓に貼っています。こうしておくことで、たびたび目に入ります。

既にこの運用になって、進行の当番も何周かまわっていますが、今のところ、当初の目標から外れること無く運用できているように思います。

なお、このドキュメントを書いたり、コードレビューを運用するにあたって、いろんな会社さんのやり方を参考にさせていただいています。

たとえば、「自分のことは棚に上げ、理想論を振りかざす」というフレーズは、以前 Google さん主催の Startup Tech Night に LT 参加した際に、スピーカーの足立さん(カブク)が仰っていたものです。コードレビューを楽しむという点において、このフレーズのキャッチーさは素晴らしいなと感銘を受け、早速当社でも使わせていただきました。

また、各人が自身の仕事を持っていると、コードレビューのような時間をしっかり確保することは、ついついなおざりになってしまいがちです。そこで、当社では、定期コードレビューの時間を bot から Slack に通知させるようにしました。

このアイデアをいただいたのは、ご近所スタートアップ Bracket さんとのランチのときです。(その節はありがとうございます。また行きましょう :)

さて、書き出すと、もうちょっと補足したいところ(とくに「設計や修正を求めない」の箇所)や、じっさい運用してみて思ったこと、変えていっていることなども書きたいのですが、長くなってしまいそうなのでまたの機会にしたいと思います。

当社としてはわりと普通のことを書いているつもりですが、こうやっていろんな会社さんのやり方を取り入れつつ、「うちはこうやってるよ」を晒していくことで、同業者さんに少しでも参考にしていただけるところがあれば嬉しいです。

最後に、毎回の告知で恐縮ですが、当社では、開発を楽しみつつ、現場をぐいぐい改善していきたいエンジニアを絶賛募集中です。よろしければ、ぜひ募集をご覧になってください。

それでは、また。

@tmtysk

　こんにちは。今回のエンジニアブログは、エンジニアデビューして5ヶ月目の、元高校世界史教員がお送りします。先日、5月末に行われる、TOKYO METROPOLITAN ROCK FESTIVAL 2015（通称メトロック）というロックフェスのチケットが当たり、今から開催が待ちきれずそわそわしています。

　さて、本日はタイトルにもある通り、フロントエンド寄りのテーマでお送りいたします。

　このたび、jQueryメインで構成されているサイタの管理画面を、全面的にZepto.jsに移行できないかチャレンジしてみました。結果として一部のみZepto.jsに置き換えという形になってしまったのですが、そのあたりの紆余曲折と、Zepto.jsの個人的なオススメどころをお話できればと思っています。

なぜZepto.js？

　jQueryを置き換えるライブラリとして、Zepto.jsを選定した理由は以下の3つです。

1. jQuery互換

　Zepto.js を選んだ最も大きな理由はコレです。

　本家サイトには

Zepto is a minimalist JavaScript library for modern browsers with a largely jQuery-compatible API. If you use jQuery, you already know how to use Zepto.

　とあり、Zepto.jsの大部分がjQueryと互換性のあるAPIで構築されていること、そしてjQueryの利用経験があれば、すぐにZeptoを使いこなせると謳っていることがわかります。

　管理画面の実装済みの機能数は多く、ほぼすべての画面でjQueryが読み込まれ、それに即したコードが書かれています。それらをすべて書き換えるのはかなりのコストがかかります。しかし、jQueryと互換性のあるZepto.jsなら、jQueryライクに書いたコードも大きな修正コストを書けずに置き換えることができるのではないかと思いました。

2. 軽量

　これまで使ってきたjQueryの利便性はいわずもがなですが、jQueryは様々な機能を持っている分、容量が大きいのが難点。サイタの管理画面で利用しているjQueryはver1.4と古く、Minifyしても80KBになります。

　サイタの管理画面は、様々な人が利用します。また、社内PCからだけでなく、出先でスマホやタブレットPCなどのスマートデバイスから利用するニーズもあります。

　しかし、現状の管理画面はおせじにもモバイルフレンドリーとは言えない状態でした（今もそうですが）。

　そもそも、レイアウトが最適化されていない（viewport指定しているところはゼロ！）のもそうですが、とにかく読み込んでいるJSの容量が多い。上記のjQueryに加えてjQuery UI（ver 1.8）も利用しているので、合わせると300KB近くなり、他のプラグインも全て読み込むと400KBは優に超えます。コンテンツも加わると、モバイルネットワーク環境には少々厳しいサイズになってしまいます。

　しかし、Zepto.jsはMinify時で30KB程度ととにかく軽量。メインで使用するライブラリの容量が約3分の1になるのは、モバイル利用も考えると、置き換える価値があると考えました。

3. 対応してるUIフレームワークもちらほら

　スマホのレイアウトも考えるとなると、それなりのデザインでUIを構築したくなるのが人の性ですが、しかしリッチなUIを作ろうとすると結構なコストがかかります。それを吸収してくれるTwitter Bootstrapや、jQtouchといったフレームワークが対応していることも大きなメリットでした。

置き換えにチャレンジ！

1. 苦労したところ

　jQueryプラグインを使用しているところで特に苦労しました。今時当たり前かもしれませんが、管理画面ではjQueryに加えて、jQueryのプラグインをいくつも読み込んでいます。例えば、当ブログの記事でも紹介された架電記録やお客様情報画面ですが、ここで使われているボタンやタブなどのUI部分には jQuery UI が使われています。

　このjQuery UIを初めとしたjQueryプラグインで多くのエラーが発生しました。当たり前ではあるのですが、いくらZepto.jsがjQuery互換とはいえ、仕様の違いによるエラーも多く、jQueryで動作するように作られたライブラリたちをZeptoでも使えるようにするためには、一筋縄ではいかない苦労がありました。

　jQueryに代わってZepto.jsを読み込ませた後の、架電記録やお客様情報画面がこれです。　

　架電記録はまだボタンのデザインがブラウザ標準に戻っただけですし、データの更新・登録にJSを使うわけでもないので、まだ妥協できるところはあります。しかし、お客様情報画面はもうダメでした。見た目もそうですが、タブのきりかえと同時に表示するデータの取得を行っているので、タブの切り替えが出来なくなると完全に使えなくなってしまいます。

　例えば、このインターフェースが数KB程度のライブラリで構築されていれば、修正コストはそこまで高くなかったかもしれません。しかし、jQuery UIのような大きなライブラリに依存していると、それに応じて修正する個所も増えていきますし、また、様々な画面で使われていたりするので、すべての画面で同じふるまいをするか検証するのも相当大変です。そこに労力をかけるよりも、むしろプラグインの使用を止め、独自でUIを構築するか、BootstrapなどのZepto.js対応のUIフレームワークに全面的に置き換える方が良いのではないだろうか…と考えるようになりました。

2. うまくいったところ

　以下のコードは、サイタの管理画面で有名な申込みフォームピコピコアラート機能（お客様から申込みがあると、ピコッという音が再生される）の一部抜粋です。

　このload_alertメソッドでは、新しい申込みがあったかを確認し、更新があれば音声を流しつつ、アラート表示部分のデザインを変えるという一連の処理を行っています。サイタのエンジニアが実装したものですが、この中で、Zepto.jsに置き換えることによって、エラーが発生したところはどこだと思いますか？ 　

function load_alert(){
  var li;
  $.ajax({
    method: 'get',
    url: 'hogehogeJSON.php',
    dataType: 'json',
    cache: false,
    success: function(data){
      ....
      $('div#alert-box ul').text('');
      $('span#adimn-alert-count').text(data.length);

      if(!data.length){
        $('div#alert-box').fadeOut(50);
        $('div#admin-alert').removeClass('active');
        return;
      }

      for(var i in data){
    .....
        $('div#alert-box ul').append(li);
    .....
      }

      if(is_sound){
        // 音の再生
        audio.play();
      }
      $('div#admin-alert').addClass('active');
    },
    ........
  });
}

　じつは 　

$('div#alert-box').fadeOut(50);

　この個所だけなんです。そもそもZepto.jsには fade() というメソッドが用意されてないので、エラーが発生するのが当たり前なのですが、$.ajaxで非同期通信を行い、PHPから返ってきた値を使ってDOM操作を行う…Zepto.jsに置き換える前はどこかしらでエラーが起きそうだと思ったのですが、予想以上にすんなりと動いてくれました。

　また、fade()のようなアニメーション系のメソッドも、Zepto.jsが標準で用意しているモジュールを読み込むことによって利用可能になるので、ほぼコードの修正をせずに、独自実装部分のZepto.js対応が可能になりました。 　このような非同期通信を行っている個所はそれなりにあるのですが、移行コストがそこまでかからないことがわかり、これは大きな収穫でした。

Zepto.jsへの移行に挑戦してわかったこと

　移行チャレンジのなかで見えてきた課題をまとめてみます。

• jQueryプラグインを利用した個所の移行コストが高い
• 特にjQuery UIを利用したところは大変（でも結構画面数多いのよ）
• Zepto.jsに置き換えるなら、UIやプラグインの再構築・再選定を行うべき

　できれば、Zepto.jsに移行して、デザインはすべてTwitter Bootstrapにする…が理想です。はい。しかし、現実的には、管理画面のすべてのUIを置き換えるほどの開発コストを投じるのは難しい。

　そこで、一からデザインの構築、プラグインの選定を行うことができる、サイタのスマホ版管理画面制作時に、Zepto.jsを利用することにしました。

　それに合わせてSencha Labsが開発したjQtouchを使用しました。いずれ機会があればこちらのお話も出来ればと思いますが、Zepto.jsに対応している軽量UIフレームワーク（メインJSのサイズは12KB！）で、よくあるiOSアプリのようなインターフェースを簡単に作り上げることができます。フレームワーク独特のクセもありましたが、サクサクと開発をすすめることができました。

まとめ

　今回、サイタの管理画面では既存のライブラリやUIとの兼ね合いが大きなハードルとなってしまいました。しかし、以下の条件が適う場合、Zepto.jsを使って開発を行うことを検討しても良いのではないかと思います。

• 利用ブラウザが新しい（リファレンスを見て欲しいんですが、実は古いブラウザ非対応なんです）
• スマートフォン、タブレット向けサイト（PCブラウザだとIE10からしか対応してませんし…）
• 利用ブラウザを限定できる、社内向けの管理画面
• 既存の画面とのしがらみ（UIやプラグインなど）が少ない

　jQueryから抜け出したい…と思っている皆さんのお役に立てれば幸いです。

ちなみに

　冒頭書いた通り、私はエンジニア歴5ヶ月目です。今回紹介した Zepto.js 移行を任せてもらえたのは入社して2ヶ月目でしたが、入社早々に本番運用している管理画面の開発にチャレンジできたことで、既存の管理画面のUIやフロントエンドの全体像を理解する良い機会となりました。

サイタでは、これまでの経験に関わらず、より良いサービスを作っていくためにご活躍いただけるエンジニアを募集しています！