4月に行われたノンスタカフェ「Webサービスの作り方入門」の書き起こし第2回は「Webサービス開発のプロセス?後編?」です。企画が決まり資金調達もできたら、さあチームを作りましょう！それではスタートです。（前編はこちら。）

チームを組む

教科書的には「デザイナー」「エンジニア」「マーケッター」の3人で始めるのが鉄板と書かれていることが多いです。
デザイナーは操作性やlook & feel、といったWebサービスの表側を決定します。一方エンジニアは、その裏側。例えば会員情報などをどのように保存して、リクエストがきたときにどのように情報を提示しようかなどを考える役割です。そして良いものをつくったとしても、それを世の中と結びつける人がいないと広まりません。マーケッターとは、サービスとお客様を結びつける人です。
このように3人または3種類の職能をもった人で始めるのがいいと一般的には言われています。

実装する

?プログラムとは

実装とは、Webサービスを形にする作業です。Webサービスとは、コード、プログラムの塊です。ではプログラムとは何か、私（高崎）は考えました。一つの答えとして「コンピュータにやってほしい仕事をコンピュータにわかる言葉で指示書にしたもの」であると思います。その指示書がプログラム、コードと呼ばれるものであります。
コンピュータを自分の部下と捉えると、コンピュータはどんな特徴があるかというと、「１から１０まで指示書のとおり完璧に仕事をする」「同じことの繰り返しが得意」「徹夜でも嫌な顔をしない」という特徴がある一方で、「指示していないことをしない」「指示ミスに厳しい」という面もあります。昔NTTのIP電話で数万件規模でとまった事件がありました。原因はプログラミングの大文字のSと小文字のsを間違えたというだけです。普通の人間ならば理解できる間違いであっても、このようなことが起きたということから、プログラムは指示ミスに厳しいということがわかると思います。そんな部下を育てることがウェブサービスを育てることと同義語かもしれません。

ブログラムの開発手法は大きくわけて２つあります。

• ウォーターフォール開発
• アジャイル開発

これは、プログラムをどう捉えるかによって、取り得る手法がかわります。

ウォーターフォール開発

ウォーターフォール開発は、プログラムをハードウェア、家電、建築のように取り扱うことです。ウォーターフォールという言葉のとおり、水が落ちていくように開発をするので、滝の上に設計図を完全にかためて、その下に流していくといったイメージです。メリットは建築や家電のように作るため、慣れている人やイメージつく人が多いという点です。デメリットはウォーターフォールなので、形にしてみて違ったなという場合や、下に落ちかけのとき（計画が進んでいったとき）に上に戻りたい（計画を修正したい）と思っても戻りにくいという点があります。

アジャイル開発

アジャイル開発のアジャイルとは「迅速な、俊敏な」という意味ですが、小説とか映画に近いものだと捉えて開発される手法です。デッサンを繰り返すように、コードを書いて形にして、形にしたのものをまた書き直して、といったイメージです。メリットは頭で思い描いていることを実際形にしたときの違和感を埋めてくれる点です。デメリットはどこで終わらせるかきりがないという点です。クライアントワークでは難しいな、と感じることがあります。
アジャイル開発で有名なのはFacebookです。１週間に２回くらいかわっていることがあるのは、アジャイル開発だからです。Webサービスは使う人と人数によって、考え方がかわってくるものなので、柔軟に対応できるのがアジャイル開発なのではと思います。

今から始める人も、要件が決まっている場合はウォーターフォール開発がいいかもしれませんが、お客様の反応をみたい場合はアジャイル開発をおすすめします。

フレームワークの活用

アジャイル開発においては、早めに形にすることが何より大切です。なぜなら、それを助けるツール＝フレームワークと呼ばれるものががたくさんあるからです。フレームワークとは「その仕組みやルールに従えば、どんなスキルや考えの人でも一定の成果をだせるもの」と考えるとわかりやすいと思います。
例として、コンビニ経営で考えてみましょう。2人アルバイトを雇って1人はレジを担当、もう1人はPOSを登録しています。「お店が混んできたときは、POSをやめてレジにまわる」というマニュアルがあったそうですが、「混んでいる」という基準が人によって違うため、従業員同士でけんかになることが多かったそうです。そこで、マニュアルを「2人以上のお客様がレジが並んだ場合は、POSをやめてレジにまわる」という内容に変更をしたらけんかは少なくなったそうです。これは一つのフレームワークの考え方の例で、「混んでいる」という言葉は主観的で、人によって違いますが、「2人以上」は誰でも同じように捉えることができます。その仕組みやルールに従えば、どんなスキルや考えの人でも同じように対応でき、チームとしてお店が混んでいるときは対処できる、という考えです。

有名なフレームワークの例

Webサービスのフレームワークとしては、Twitter Bootstrapが有名です。ダウンロードしてそれに沿ってデザインしていけば、TwitterのようなWebサービスのデザインを作ることができます。これはプログラミングのフレームワークの表側とも言えます。一方、プログラミングのフレームワークの裏側として有名なのは、Ruby on Railsです。こちらもTwitterに使われているプログラミングです。Ruby on Railsのルールに従ってプログラミングを書けば、Twitterのようなサービスが簡単に作れてしまいます。

このように、ゼロからプログラムを勉強をして開発しなくても、簡単に思いついたものを形にするフレームワークを、うまく活用しながら開発していくのがいいのではないかと思います。

リリースする

良いものでも宣伝なしでは使ってもらえません。リリースから先は開発に使ったくらいのエネルギーを使ったほうがいいとも言われています。

宣伝する

「伝える」から「伝わる」へ

さて、どう宣伝するか。今の時代は情報化社会なので、30年前に比べて１日に接触可能な情報は１万倍見ていると言われています。アメリカでは、１年間に２万個の広告に触れるといいます*。そんな中でどのように宣伝をみてもらえるか。一方的に広告する「伝える」というスタンスより、相手手動で「伝わる」というスタンスがいいかと思います。「エモーションのないインフォメーションは伝わらない」という言葉があります。お客様は売り込みは嫌いだけど買い物は好きです。

お客様にファンになってもらう

そしてお客様にファンになってもらうことが大切です。ファンになってもらうためには、エモーションのある情報をどれくらい発信するかが大切です。弊社のOnceの例をとってみると、タイムトラッキングツールでお金と時間を管理できます、という説明より「ノマドワーカーの独立を応援したい、ノマドが抱えるお金と時間の問題を解決する」とブログで発信したほうがFacebookのいいね数も多く、反応がみられました。
その製品がどこを目指して、世界においてどんな問題を解決するか、が伝わったとき、はじめて応援してもらえるのかもしれません。
あとは舞台裏に招待することが大切です。苦労話について良いところも悪いところも含めて発信するということです。成功している例がAKB48ですね。裏側まで出して、ドキュメンタリーや映画にしています。赤裸裸にすることでファンがついてくるのでしょう。
「ファンになってもらう」「思わず応援したくなる」というのがキーワードです。

ブログの活用

一般的な宣伝手法として、グーグルの連動型広告などもあります。キーワードにもよりますが、1クリック＝200円くらいです。それよりは、ブログを書いてファンになってもらったほうが効果が高いと思います。私たちがブログを書くと約100人見にくるので、2万円の効果があることになります。普通の宣伝手法もいいですが、ファンになってもらうことが何よりも大切なのではと、最近感じています。

以上、Webサービス開発の6つプロセス「企画」「資金調達」「チームを組む」「実装する」「リリースする」「宣伝する」でした。
Webサービスは人と人がつながる場なので、お店を開いているような気持ちになります。ぜひ第2のマーク・ザッカーバーグになってください！

---

*参考：総務省情報流通センサス報告書