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

浜村拓夫(・∀・)作品集

頭の中にあるイメージを表現できるデザイン力が欲しいです(><)

最小限の労力でWebサービスを作るノウハウ

web

Webサービスを作るとき、「あれも欲しい」「これも欲しい」と、機能をたくさん付けようとして欲張ると、制作に時間がかかってしまい、なかなかリリースすることができません。

必要な機能を絞り込み、最小限の構成にすると、制作時間を短縮できます。

 

hamamuratakuo.hatenablog.com

 

時間がかかる完璧主義から脱却するには、「いかにして、手間を省くか?」を追求したら良いと思いました。

 

・欲張り → システムの仕様を肥大化させる(無駄も増える)

・足るを知る → システムの仕様を厳選して、絞り込む(無駄が減る)

 

両者はトレードオフの関係になっていますが、スタートアップの段階では、まず最小構成から始めて、徐々に機能を追加していく方式が良いと実感しました。

 

近年流行っている「マイクロサービス」のように、小さい単位で作っていくという発想ですね。

www.nttdata.com

f:id:hamamuratakuo:20160728211812j:plain

 

●簡略化と手抜きの違い

・簡略化 → 品質は維持。必要な部分は削らない。無駄な部分を削ぎ落とす。

・手抜き → 品質の低下を招く。無駄な部分も必要な部分も削ってしまう。

 

Webサービスをシンプルに作る方法が紹介されていました。

 

type.jp

 

■ネタサイトの作り方その1: アイデア、DB設計を手書きでメモ

落書きのようなメモですが、実はこれでだいたい設計が決まります。

f:id:hamamuratakuo:20160728182253p:plain

 

DBの設計もメモします。ぶっちゃけDBができたら、後の画面設計とかしません。

f:id:hamamuratakuo:20160728182327p:plain 

 

・動的なWebサイトは、ぶっちゃけDBの「ラッパー」でしかない。

 

f:id:hamamuratakuo:20160820095405j:plain

 

・データ構造が決まれば、自ずとラッパーの設計も決まってくる。(Data Oriented Approach

・データストレージは、定番のリレーショナルデータベースを使えば、迷う余地はほとんど無し。

 

itpro.nikkeibp.co.jp

f:id:hamamuratakuo:20160728190926j:plain

 

データベースの設計は、決済など、金銭絡みのヘビーなシステムでもない限り、適当でOK?(トランザクション不要)

 

楽々ERDレッスン (CodeZine BOOKS)

楽々ERDレッスン (CodeZine BOOKS)

 

  

データベース設計論 T字形ER―関係モデルとオジブェクト指向の統合をめざして

データベース設計論 T字形ER―関係モデルとオジブェクト指向の統合をめざして

 

 

T字ERDのやり方を参考にすると、テーブルとカラムは、メモ書き程度でも設計できるようになるでしょう。

 

(1) 5mm方眼紙ノートでメモ書き

(2) エクセル方眼紙(笑)で清書 → 訂正が簡単なのでデジタルツールも重宝します。

 

f:id:hamamuratakuo:20160728200926p:plain

(↑罫線が白飛びして見えませんが、5mmの方眼紙ノートにDB設計をメモ)

 

f:id:hamamuratakuo:20160728201028p:plain

 

f:id:hamamuratakuo:20160728201037p:plain

(↑Excelの代わりに、Google DriveのSpreadSheetでもOK)

 

この後の実装、コーディングの部分を手抜き…じゃなかった…簡潔にしたいです。

 

■ネタサイトの作り方その2: コードをもりもり書く。なるべくPHP

ある程度設計が固まったら、ブラウザでCloud9を起動して、いきなりコードをもりもり書きます。

 

サーバの言語はPHPが多いです。運良くヒットした時、日本の大きな会社にサービスを売却するのに便利なのはPHPだからです。 

 

CSSとかは書きません。

最近はBootstrapもMatrial DesignのCDNがあるので、直リンクでそれを貼って終わりです。

 

・簡単に作るなら、LLのスクリプト言語で十分。

PerlPythonRubyPHPの中では、PHPが一番簡単

CSSJavaScriptは、ライブラリーやフレームワークを活用。

・長期に渡るメンテナンスが必要なら、コードの可読性が高いPythonでもOK。

Ruby on Railsは、学習コストが高い、規約を外れると面倒、テスト地獄なのでNG?

 

バグ上等!…テストなんかやってられませんねw

 

基礎 Python (IMPRESS KISO SERIES)

基礎 Python (IMPRESS KISO SERIES)

 

 

■ネタサイトの作り方その4: 決済方法を決める

最初はPayPalにします。PayPalのUIはゴミクズ以下ですが、審査もへったくれもなく、postで僕のメアドと金額などなどのパラメータを投げるだけでクレジットカード決済フォームに飛ばしてくれる上に、ちゃんとコールバックも投げてくれるので楽です。

審査なしの決済はSpikeやGumroadなどいろいろありましたが、結局、これが一番楽でした。

 

課金型のサービスだと、マイクロペイメント(少額決済)をどうするか?悩みの種ですね?

PayPal(海外のサービス)でも良いけど、日本の企業で、どこかが手軽なオンライン決済手段を提供してくれたらいいのになー。

 

ferret-plus.com

1.広告収益モデル

2.ネットショップ販売収益モデル

3.コンテンツ/サービス課金モデル

4.マッチングサービス(手数料)モデル

5.キャリア/ISP課金モデル

 

Webサービスの収益化手段は、

・広告

・課金

・販売

等があります。

まずは広告、次に販売、最後に課金、という順番が手間いらずでいいかな?

 

■ネタサイトの作り方その5: ドメインはヒットしてからの取得でOK

昔はいちいちドメインを取ってましたが、最近は、ドメインなんか取ってもみんな検索するので、もうネタサービスごときでドメインなんか取りません。サブドメインで十分です。

ドメインなんて、ヒットしてから取って、リダイレクトか何かすればいいのです。

 

(1) 最初は、わざわざドメインを取得せずに、サブドメインで実験的に始める。

(2) 成長してきたら、ドメインを取って、独立させる。

 

Webサービスを独立させるときの注意点は何でしょうか?

ドメインの変更 → DNSの設定で切り替える 

・サーバーの変更 → バックアップとリストアの簡便化。Dockerとか利用?

・データベースの変更 → 各サービスで共通したテーブルを使わない。疎結合にする。

 

ログイン認証で、FacebookTwitterなどソーシャルサービスのログイン機能を利用した場合、ユーザー情報の紐付けには気を付けるべきでしょう。

ドメインを変更した場合でも、ユーザーから見て影響が出ないようにしておく。

サブドメインは使っていても、各サービスは独立した構造にしておく必要がありますね。

 

●まとめ

(1) サービスの仕様をイメージ(メモ書き)

(2) DB設計(メモ書き)

(3) PHPでコーディング(フレームワーク、ライブラリーの活用)

(4) サブドメインで公開

(5) 成長したら、独立させる

 

村上福之さんのやり方を参考にして、Webサービスの制作方法を簡潔にしたいと思います。

 

twitter.com

 

 

A. Vivaldi - Summer Presto