読者です 読者をやめる 読者になる 読者になる

ボクココ

熱海で開発するブログ

サービス改善することの難しさと大切さ

素晴らしいサービスとそうでないサービスの違いはなんだろう?

みんな当たり前のようにいいサービスを作ろうと目指しているけども、なかなかできないことが多い。それの決定的な理由が、"修正が大変だから" の一言に集約されると思う。

修正することの難しさ

一度作ったものを直すことは、新しく作るよりも難しい。しかも修正する対象が、今まで自分が作ってこなかったシステムならなおさらだ。 修正が怖いから、修正すると大変だから、修正することを諦めて、機能追加する道を選ぶ。そっちの方が簡単だからだ。

その行き着く先は虚しい。 本当に使ってくれるかわからない機能が大量にあってごちゃごちゃした使いにくいサービスが出来上がる。引き継ぎを繰り返すプロダクトは基本的にこうなる運命にある。

それを打ち砕くには、修正できる能力が必要だ。その能力を得るためには、既存のシステムを深く理解し、一部を修正したことで起きる影響などがすぐ把握できるようになる必要がある。これが1から作った人でないと本当にきつい。どんなプロでもこれは難しい。ひどい作りのシステムなら尚更で、そういうコードがむしろ多い。そんな場合は作り直したりすることもあるだろう。

あなたはそのシステムの根本を修正できるか

たくさんのユーザーフィードバックを得たとき、その修正を無理と思うか、直せるか。ここの違いでサービスの良し悪しは決まる。そこに必要なのは技術力の高さなのか? きっとそうじゃない、必要なのはシステムを理解するための根気と、その根気を生むためのサービス愛だ。

それができないようなら、自分が1からサービスを作って修正できる環境にするしかない。

これができないところが多いと思う。1から作ったプロダクトでさえ修正はモノによっては難しいと思う。あなたの環境では大規模な修正ができるだろうか?ぜひ考えてみてほしい。できない時点で、あなたのサービスは良いものにはならないだろう。

自動電話応答サービスを作ってリリースした話

自動電話応答(IVR) を誰でも簡単に作れるサービスを目指してコールコネクトをリリースした。

www.callconnect.jp

自動電話応答(IVR)とは

自動電話応答(IVR)とは、例えばどこかの企業に電話をかけた時、「お電話ありがとうございます。〜に関するお問い合わせは1とシャープを、〜に関するお問い合わせは2とシャープを...」 みたいな感じでガイダンスが流れ、それに従ってボタンを押すと自動で指定の場所へ電話がリダイヤルされる仕組みだ。

これを使えば新人が電話をとって、誰かにとりつなぐといったロスが無くなるし、顧客としても話したい人にダイレクトにつながるので満足度が高まるだろう。

このような自動電話応答の仕組みは従来、一部の大企業がSIerなどに発注し、大掛かりなシステムとして何百万と予算をつぎ込まないと実現できなかった。低予算をアピールしているサービスでも、まずはヒアリングから開始し、それ向けにカスタマイズしたシステムを最低1週間を要するものであった。

コールコネクトについて

コールコネクト

コールコネクトなら、誰でも3分で導入できて、しかも月額9,800円からという破格の料金設定を実現した。それには一貫してこの自動電話応答(IVR)をクラウドで扱うということにより、運用コストを劇的に抑え、しかも早く導入できるシステムを構築した。より詳しい詳細については上記サイトを訪れてみていただきたい。

無料モニター募集中

サービス開発に関して、今までは一人で全てサービスのデザインから文章まで作っていたが、今回は自分と合わせて計3人の優秀な仲間と作ったため、クオリティに関してかなりの自信がある。が、より精度を高めて顧客にサービスを届けるために現在は無料モニター募集でモニター利用していただける方を募集している。無料モニターは事前にサービスを無料で利用できるだけでなく、ローンチ後の20日間は無料で利用できるため、2ヶ月程度無料でサービスを利用することができる。とはいえ品質に関してはすでにリリース可能なレベルまであるので、ご安心していただきたい。無料モニター期間は、いただいた意見からさらに良いサービスにするための時間だ。もちろん、その期間に満足できなかったらサービスの利用は無料期間だけで終わらせても問題は無い。それは私たちが満足できるサービスを提供できなかったということで反省し、改善したいと考えている。

もちろんコールコネクトのお問い合わせも、コールコネクトを利用した自動電話応答(IVR)になっているので、試しにどんなものか確認したい場合はぜひお問い合わせいただきたい。

技術的な部分

より使いやすいサービスにするために様々なブラウザの最新技術を始め、俊敏なサービス開発を実現するための工夫をこらしている。以下は使用技術の一例。

Canvas

<canvas>要素を使うことで、HTML文書の中に図を作ることが可能になる。コールコネクトではcanvasを利用することで電話が来た際の分岐の作成をよりわかりやすく表現することに成功した。 + ボタンや x ボタンを押して分岐のボックスを生成する。

https://s3-ap-northeast-1.amazonaws.com/callcloud/assets/function01-abfd48c57218ea47448fbb3c6e343588.png

WebRTC

WebRTCはリアルタイムビデオチャット的な使い方が有名だが、これを使えばブラウザ上で音声の録音もできる。コールコネクトでは、ガイダンス音声は機械音声、音声録音、音声アップロードの3種類を提供している。WebRTCにより、手軽に声を録音し、実際の声で適切なガイダンスを流すことが可能だ。注意点として、IEは対応していないため、他のブラウザーで録音する必要がある。

サーバーサイド

サーバーサイドは一般的な構成だ。 Ruby on Rails, PostgreSQL, Redis, Unicorn で運用している。テストには馴染みの深いRspecを採用した。この構成が最も早く開発できるし、一般的なテクノロジーにすることでメンテナンスコストも下げている。

終わりに

よりコストを抑え、スマートに電話対応されたい方、ぜひコールコネクトのご利用をお待ちしている。

サービス志向と技術志向のエンジニアの価値観

いやはや、前回の記事が想像以上にバズったけども、その中で否定的な意見も出てくるだろう。そんなことはない、と。お前は勉強不足だ、と言われても仕方のない記事だったと思う。

それは自分にとってプログラミングとはサービスを作るためのものという認識だからだ。それは技術志向のエンジニアとは大きな違いがあると思っている。

なんのための技術か

プログラミングは手段であって目的ではない。 出ましたお決まりフレーズ! これさえ言えば色々わかってる感が出る。これをいう人、共感できる人はサービス主体エンジニアだと言えよう。断っておくが、プログラミングが目的であっても全く問題ないと思う。むしろそういう人も必要だ。

色々な考えを持ってみんなプログラミングを学び、使っている。以下のようなパターンが挙げられる。

  • 私の仕事はプログラミングをすることなので、それをいかに楽にできるかを考えています。
  • 私は新しい技術を作ることに興味があるので技術を学んでいます。
  • 私は技術で新しいものを作ることに興味があるので技術を学んでいます。
  • 私は技術で世の中の課題を解決するために技術を学んでいます。
  • 私は技術が好きなので学んでいます。

どれも素晴らしいモチベーションで、それぞれが技術向上できることだと思う。ただその中でも先述の通り、 技術志向か、サービス志向か というのに分かれる。これは縦割りの激しい大企業のエンジニアは特に前者が多く、スタートアップには後者が多い。むしろ大企業のエンジニアの求められるのは前者のみだったりすることもある。

技術志向エンジニア

技術主体のエンジニアは新しい技術だったり自分で技術を作ることに情熱を傾けられれば一流になれる。それ以外のことは考えなくても、そこだけ突出していればかなり評価されることだろう。そして最新技術を駆使して難しいシステム構築を実現したりOSSにして公開したり。エンジニア界隈で有名人になれれば最高だと思う。そんな方々を私は尊敬している。

サービス志向エンジニア

ただ創業時のスタートアップではそうはいかない。全て自分でできないといけない。そうなった時、新しい技術を作ることに情熱を傾けるべきではない。もちろん、新しい技術を積極的に使っていくべきだけども、それよりも大事なのはいかにサービスを早く作ってリリースするか、ここにかかっている。リリースの障壁、遅延となりそうなことは徹底的に排除して優先順位を決める必要がある。技術主体エンジニアの方々の作った素晴らしいコードを使っていかにユーザーに届けるかが勝負になってくる。

両者について

  • 技術志向エンジニアは「いかに考えた技術を実現できるか」に価値を置く。
  • サービス志向エンジニアは「いかに考えたサービスを実現できるか」に価値を置く。

自分はサービス志向エンジニアなので、早くできるかできないかが最優先で、それが難しそうなら排除したり、早くできそうならすぐ取り入れる。そういう考えの上での前回の記事だったということだ。技術志向エンジニアの方にはきっと共感できない記事だったと思う。

そんなわけで、私は勉強会よりも賞金付きハッカソンが好きである。勉強会に行く理由が私にはほとんどない。

なんだかんだで SPA から jQuery に戻った話

最近は SPA とか React といった話題が尽きないが、自分は結局 フロントエンド JavaScriptjQuery が最もいいと感じている。それはそれら SPA の JavaScript をいじった経験を踏まえての感想。

理由としては、「 やりたいことができにくい 」これに尽きる。

最新を追うということ

自分が最初にSPAを触ったのは AngularJS だった。なるほど、この ng-repeat や $route, $scope などを使えば、今までサーバサイドでやってたようなレンダリングが表側で制御できるようになる!と感動したものだった。この気持ち良さはきっとサーバーサイドでごにょごにょやっていた経験のある人ならなおさら感動するものだ。

さて、じゃあといって「次作るのは SPA のサービスにしよう!」と意気込んで初めて見たとする。それで作っただけで話題になるし、エンジニアとしては誇らしい。 しかししばらくすると徐々に問題が起きてくる。。

例えば、 グラフを作りたいだとか、クールなUIを実装したいとなった時。調べてみると大抵 jQuery ~~ とあって、 Angular や React 用のがなかったりして、結局 jQuery と混在させなきゃいけなくなったりすることがよくある。それがやりたくなければ、自分で実装するしかない。(今ならあるかもしれないが、当時できたてのAngularJSにはもちろんそのようなものがなかった)

自分で実装しようとした時、いきなり問題に直面する。どうやってこの複雑な機能をこのフレームワーク内で実装するのだろうか。そこは勉強不足の点もあっただろうが、場合によってはフレームワークの奥まで知らなければならないことがある。そこまで頑張って追って実装したあと、それをメンテナンスするのは誰だろう?

そして頻繁なフレームワークのアップデート。それらに対応しなければならない。もしうまくいかなかった時は最悪だ。 StackOverflowを見渡して見つからなかければ1日以上かけて問題の解決のためにソースを読まなければならない。あなたはそこまでする覚悟があるだろうか?

乱立するフレームワーク

ちょっと前までは backbone.js が一番人気だった。これこそが次なるJavaScriptだ、と言われていた。が、今になってみれば全くそれ関連の記事が見当たらない。当時 backbone.js を触っていた人はそれでちょっとしたのをつくれるようになったかもしれないが、誰もメンテナンスできないサービスが完成したことだろう。

今は react.js だが、これも本当に続くものだか全くもっての疑問だ。そんなの気にせずに時間をかけてでもそのフレームワークを愛するというのであれば話は別だけども。

テスト?

SPAで処理をするということは、本来サーバ側でやっていたロジックをJavaScript側にやらせることが多くなる。そんな時はJavaScriptでテストを書きたくなってくる。ただページ遷移とかも全てJavaScriptで制御しているので、その状態まで持ってきた状態のテストを書くといったことが必要だ。これがなかなか大変。 そうなるとテストを書かないでいろいろ実装してしまうことになる。果たしてこれがいいのだろうか。

jQuery について

基本的にロジックはサーバーサイドで実行させて、細かい動きのところだけ jQuery をちょろっと使う。これがやはり本来あるべき JavaScriptの存在意義なのではないだろうか。それ以上に JavaScriptに仕事をさせようとすると、メンテナンスが一気に大変になる。

jQuery はやはり強力だ。 jQuery ~~ でググれば大抵のプラグインは手に入る。ちょろっと入れれば簡単に導入できる。そしてたくさんの知見がネット上に転がっている。

ReactやAngularのバインディングの仕組みは確かに素晴らしいし書いていてクールだ。だけどそれ以外のことに目を向けると、jQuery、やはりまだあなたが自分には必要だ。

Amazon Lambda と Kinesis についての調査

AWS

最近、AWSがアツい。

というのも今までは EC2 をベースにいかに大規模処理の分散を工夫するか (RDS, Elastic~) とか、いかにデプロイをカッコ良くするか(OpsWorks, BeanStack, CodeDeploy) や、 S3, Route53 などのものの印象が強かった。

しかし、近年になってそうした EC2 ベースでなくとも強力なAWSが出てきたので、これらは是非チェックしておきたい事項になっている。

今回紹介したいのは Amazon LambdaAmazon Kinesis の2つ。この2つでどんなことが作れるのかは、以下の記事をまず参照していただきたい。

池澤あやかさんにお願い! AWS Summit Tokyo 2015「デベロッパーカンファレンス」を盛り上がるアプリを一緒につくってください!

これ、素人向きかと思ったらかなりガチな最新トレンド取り入れた興味深いテーマになっている。池澤さんが羨ましすぎる。。

以下は上記記事に加えて自分が調べた内容だ。

Amazon Kinesis

スマホやセンサーデータ、ログデータなど、同時期に大量の通信が走る場合サーバ負荷が一気にかかる。それらを一気に引き受けてくれる担い手となるのが、このAmazon Kinesis だ。

Amazon Kinesis に送られたデータは最大24時間まで保存されているので、その期間の間までに何かしらでデータを取ってきてどっかに保存したりするのが一般的な使い方。その取ってき方は後述するAmazon Lambda の他にRESTで取ってきたりAWS CLI 使ったりAWS SDKから取ってきたりいろいろ。それらをDynamoDBに突っ込んだりすればおk。

直接DynamoDBとかに突っ込めばいいんじゃないかって話もあるかもしれないけど、ある程度のデータだったらそれでも問題ない。が、先ほど述べたようなセンサーデータやログデータなど、一気に押し寄せてくるデータを扱う場合はこのKinesis をまず受け皿にすることでどんなに大量に同時アクセスが来ても対応できるスケーラブルな環境を構築することが可能ってわけだ。

まとめると、Kinesis は大量データの受け皿と一時的な保存。この役割を担う。

日本語ドキュメントがあるので、興味あればぜひ。

docs.aws.amazon.com

Amazon Lambda

去年から話題になっているのがこのAmazon Lambda。これは簡単に言えばAWSにコードを置いてAWS内で実行するための仕組みだ。

こうすると何が嬉しいのか? もちろんEC2などのサーバを用意する必要がなくなるということはあるが、それよりもAWS内のイベントを拾ってそのタイミングでコードを実行できるということが魅力的だ。

例えばAmazon S3に画像がアップロードされたタイミング。このタイミングでAmazon Lambda内で画像をリサイズして保存するといったことがわざわざ自分のサーバを用意しなくても可能になる。

Lambdaではどんな環境でコードを実行できるか?

Amazon Lambdaではどんなコードを実行できるか? Amazon Lambda内ではデフォルトで Node.js, ImageMagick, AWS SDK がデフォルトでインストールされている。 それにプラスしてお好きなNode.js の NPMモジュールを取り込んでzipとしてアップロードできるので、色々なコードが実行できることがわかるだろう。

Lambdaではどんなイベントをキャッチできるのか?

これもかなり色々な種類がある。現在サポートしているのは以下のサービスだ。

Amazon S3, Amazon DynamoDB, Amazon Kinesis, Amazon SNS, and Amazon Cognito

DynamoDBにデータが保存されたタイミング、 SNSで通知を送ったタイミング、 Cognito でIDが発行されたタイミングなど、あらゆる場面でコードの実行が可能だ。

そして先ほど紹介したAmazon Kinesis もイベントとして登録可能だ。

ただAmazon Kinesis に関してはプル型のイベントとなっていて、Kinesisにデータが突っ込まれたタイミング、ではなくてAmazon Lambdaが定期的にpollingして、取ってきたデータ複数Amazon Lambdaで処理できる内容となっている。だからこそ大量データをKinesisで一旦受け取って、Lambdaでまとめて処理、みたいなことが可能な訳だ。この組み合わせがアツい。

Lambdaで受け取ったデータはLambdaのNode.js内のコードで他のあらゆるAWSサービスとの連携が可能だし、普通のNode.jsコードなので自分のサーバと連携することもできる。

やり方次第でありとあらゆることができそうな、可能性を感じるAWSサービスだ。

Lambdaは最新すぎて日本語ドキュメントはないので、興味ある方は英語でがんばって。そのうち日本語も出るでしょう。 S3 のリサイズのサンプルや、Kinesisとの連携サンプルもここに載っている。ゆくゆくはNode.js以外の言語もサポートされるようになるような様子は見せている。

http://docs.aws.amazon.com/lambda/latest/dg/lambda-dg.pdf

終わりに

"EC2は高い"そういうイメージが強いけども、こうしたサービスは100万件まで無料とかかなり気前のいい感じになっている。AWS初心者の方は是非とも他のサービス、特に (SES, SNS, S3, Route53, Cognito) あたりはチェックしていただきたい。

やけにお金かかるのはAWSでサービス構築(サーバとか全て)やった場合だけな気がする。

表参道で Swift 学習者向けの発表をしてきました

iOS

久々にスライド作ったなー。

今日は表参道で Swift 勉強会的なのがあったので、ゆるい感じで発表してきました。

最近 Swift 関連書籍は出てるけど入門者向けの本しかなくて、それで詰まっている人は多いと思う。そんな方のためのスライドを作ってみたので、よければ見てみてください。

Table 要素をレスポンシブに対応させる

CSSで感動するっていう滅多にないことが起きたのでメモw

レスポンシブデザインにする上で最も面倒だったのがこのTable要素。普通にやったらスマホじゃまともに見ることができない。でもdisplay要素を巧みに変えることで、クールなUIを実現することが可能だ。

  table {
    border: 1px solid #858585;
  }
  tbody tr{
    display: block;
  }
  tbody th,
  tbody td{
    display: list-item;
    list-style: none;
    border-bottom: 1px solid #858585
  }

@media screen and (min-width:768px) {
    table {
      border-bottom: 1px solid #ddd;
      border-left: 1px solid #ddd;
    }
    tbody tr{
      display: table-row;
    }
    tbody th,
    tbody td{
      border-right: 1px solid #ddd;
      display: table-cell;
      border-bottom: none;
    }
    th {
      width: auto;
    }
}

こうすると、スマホは1行ずつ表示され、PCは普通のTable構造で表示される!ポイントはth, td を display: list-item; とするところですね。

クールだ。