Webサービス・Webアプリ独学個人開発|僕の作り方(3年後追記)

Pocket

3年程前に書いたこちらの記事ですが、閲覧・ブックマークともにそこそこな数になってきました。
当時は初心者に毛の生えたくらいの知識でこの記事を書いていましたが、その後さらにプログラミングを進め、当時より見えるようになったものやWeb業界?の変化とかを感じています。なので、初心者の目線でというスタンスはそのままで、情報をアップデートしました。
もしアップデート前のものをご覧になりたい場合は http://archive.is/TJQdD をご覧ください。 2018年8月22日

Webサービス・Webアプリケーション・HP・androidアプリ・ECサイトなんかを独学で作り始めて、1+3年くらい経ちました。始めたころはWebサービスの全体像がよくわからず思うようにいかないことが多かったのですが、言語や環境関わらずいろいろ作っているうちに、Webサービスを企画してから公開するまでの一連の流れがようやくしっくりくるようになってきました。
今回は最近開発したTecqii(テッキー)というサービスを例に、Webサービス開発の始めから終わりまで、その作り方を公開します。
※普通のWebエンジニアの方ならよくご存知の内容ばかりですが、私がいろいろ開発してきた中で疑問にもった内容を詰め込んでます。これからWebサービスの開発をしたいと考えている方や挫折しかけている方におすすめの内容です。
※細かい技術的な部分は間違いもあると思います。私自身、技術は作りたいものを作るために必要最低限で良いと考えているので、間違っている箇所はごめんなさい。

これまでつくったものまとめ

DanceMovieOohWee

初めて作ったのはこのダンス動画のキュレーションサイトです。Wordpressを使って普通に記事を更新するというものなので、Webサービスとは呼びません。こういったキュレーションサイト・ブログ・コーポレートサイトなどとWebサービスでは構築の方法が大きく異なってくるのですが、当時はこのあたりがはっきりせず混乱していました。具体的にどのように異なるかは後ほど言及します。
また、以前はこのようなキュレーションメディアみたいなものが結構多く見られました。しかし最近はGoogleのアルゴリズムの移り変わりや、DeNAの『WELQ』を発端とした問題などが相まって、もう盛り上がっている様子は無いように感じます。
またこういったサイトは、ひたすら検索に上位表示されるコンテンツを増やすという労働集約的な事業になってしまいます。時間的余裕がない、コンテンツに思い入れが無い限り一人では継続することが難しくなるかと思います。
カスタマイズが簡単なWordPressテンプレート『bones』4つの特徴

オンラインメモ

アクセスするとサイト上でメモを取り、メモ内容がローカルストレージに蓄積され、再度アクセスした時もその内容を編集できるものです。このローカルストレージは新しいcookieみたいなもので、ユーザーのブラウザにメモ情報がたまる作りになってます。 素人がWebサービス(Webアプリ)を一人で開発しリリースする方法

今回作ったWebサービス『Teqcii(テッキー)

今回はTeqcii(テッキー)|Qiita エンジニア検索・ランキングサイトというWebサービスを作りました。

FireShot Capture 34 - Qiita エンジニア検索・ランキング I エンジニアランキング - http___tecqii.com_

FireShot Capture 35 - Qiita エンジニア検索・ランキング I suin - http___tecqii.com_user_3

サービスの概要

Teqcii(テッキー)|Qiita エンジニア検索・ランキングサイトは https://qiita.com/ に登録している10万人を超えるエンジニアを検索できるサービスです。具体的には

  • 言語やフレームワーク、ライブラリ等エンジニアのスキルセットから検索
  • SNS情報が登録されているかどうかで絞り込み
  • 居住地情報が登録されているかどうかで絞り込み
  • フリーワード検索

といった機能があり、エンジニアの得意分野や実際に連絡が取れる・もしくは会いやすいかどうかで絞り込めるようにしてあります。
起業家・スタートアップがジョインしてくれる・業務を手伝ってくれるエンジニアを探したり、企業がスポットで働いてくれるフリーランサーを探すといった用途で利用されることを想定しています。

採用した技術や環境

  • 開発言語: Python
  • Webフレームワーク: Django
  • バージョン管理:git
  • インフラ:ConoHa VPS
  • デザインテンプレート:bootstrap4

開発の流れと期間

  • 企画構想: 2時間
  • Qiita APIの検証: 2時間
  • ローカル開発環境構築、アプリケーションの土台を準備: 1時間
  • 本番環境(ConoHa VPS)へデプロイ: 1時間
  • 開発(バック及びフロントエンド): 2日
  • キーワード抽出ロジック追加: 1日

こんな感じで3日半くらいで完成させました。ローカル開発環境構築や本番環境へのデプロイはあまり頻繁に行う作業ではない&毎回条件がことなる(利用する技術やインフラが違うなど)こともままあります。今回は毎回使っている技術達の組み合わせだったので、特に時間がかかるということはありませんでした。
それではこの流れを追いながらWebサービスの全体像をご説明します。

企画構想

まずは何を作るか?です。 何を作るかは一人で開発する上でもちろんめちゃくちゃ重要な決定事項です。
作りたいと思うものの技術的なハードルやサービスの規模、サービス提供開始後の継続的なメンテナンスの必要性などによっては、1人ではかけられる時間の限界を簡単に超えてしまうためです。
いろいろな制約がある中で、1人でプロダクトを開発する上で重要だと感じることがいくつかあります。
(ちなみに、お金儲けを目的にするとWebサービスのマネタイズの種類(課金・マッチング・広告・EC)とかの話になるんですが、もっと初歩的な内容です。)

自分の課題解決を目的にする

スタートアップ界隈のバイブル的な本である『リーンスタートアップ』では、まずプロトタイプの製品を開発して、早い段階でユーザーのフィードバックを獲得し、製品の改善を行う。このサイクルを高速化させることが大事だ、とされています。さらに最近の『起業の科学』には、まずあるべきはユーザーの課題で、その課題をブラッシュアップして、その課題を解決するようなソリューションが自ずと見えてくるのでプロトタイピングする、と書かれています。
とってもおっしゃる通りなんですが、初心者が1人で開発を行うときはこのプロトタイプを開発するだけでヒーヒーです。プロトタイプを開発する時点でなるべくユーザーの声を聞くためには、自分自分をユーザーとして、これがあると自分が嬉しくなる、というような課題解決を目的として作ると良いと思います。
例えば

  • 釣りが好きなら釣り好きな人たちが集うコミュニティを作る
  • テレビを一人で見ることが多い人が、同じようにテレビを見ている他人とリアルタイムで感想を述べ合うSNS

など、自分の作りたいものを作ることでモチベーションも保てます。

シンプルな情報を入力し、管理するだけのアプリケーションにしない

Webサービスでよくあるのは、例えば特定の分野の写真を投稿するものや、行った場所やダイエットの記録をつけるものなど、そのサービスに何かの情報を記録して、保存して、表示する、というものです。
個人的にはこれだけだとそのサービスで完結してしまうため、もっと付加価値をつけるためにいくつか取りうる方法があると思っています。

なお、ここではリアルビジネスと組み合わせてなにか価値を生む、みたいなものは省きます。
例えばWebで予約すると毎月自分に似合う服が見繕って送られてくるようなレンタル事業など、WebサービスというよりはリアルなビジネスのエントリーポイントやリテンションのためのインターフェースとしてWebがあるようなものです。

1. 情報に人が集まるサービス

何か知りたいことがある、見つけたいものがあるような人がアクセスするようなサイトで、ニュースサイトとかランキングサイト、いわゆるポータルサイトみたいなもののイメージです。
豊富な情報があればあとはSEOを適切に対応すれば、ある程度のアクセスは見込めるので、特に変わったことをしたり特殊な技術が求められるようなことが少なく、個人的には作りやすいと思います。

このタイプのサービスの問題はそういった情報・コンテンツをどう拡充するか、という点です。自分で頑張るとキュレーションメディアのような形で時間がかなりかかります。とはいえユーザーが自発的に投稿してくれるようなサービスにするには、また別の難しさがあります。
私としては、この解決策は外部APIもしくはスクレイピングを利用して、半自動的に情報を取得するという方法かな、と思います。

1-1. 外部API

API(Application Programming Interface)とは、プログラム同士が情報をやりとりをする取り決めです。 FacebookのAPIを利用してユーザーの個人情報を取得したり、wikipediaのAIPを利用して専門的な知識を活用するなど、外部のサービスが持っているリソースをただで利用することができます。 例えば、wikipediaには今SNS連携の機能がありませんが、ここでもしFacebook連携の機能をつけたら、、と考えるわけです。 ユーザーはFacebook情報にて会員登録して、閲覧情報は全てwikipediaに保存されている情報を活用。会員管理するので閲覧履歴は自動で溜まって、閲覧したページが多いほど知識ランクが高い、みたいなサービスを作って『FacePedia』のような名前をつければ、立派なサービスです。
※本当に作ろうとするとwikipediaのAPIでどこまで出来るか次第ですが、検証してないです。 APIはまだ国内においてはあまり知られてないものも多いようなので、これを探して興味のあるものがあれば、まだ日本では現存していないサービスを開発出来る可能性がありそうです。

今回作ったサービスはまさにこれで、QiitaのAPI経由で取得した情報を加工して利用しています。
しかし、実際は情報を載せただけでアクセスが増えるというのは難易度が高いと思います。そもそもWeb上には様々な整理整頓された情報を表示するようなサイトが多いためです。
さらにAPIが公開されているということは、そのAPI経由で取得できる情報はすでに本家のサイトで利用しているため、よっぽどの付加価値をつけないと難しいのではないかと思います。

1-2.スクレイピング・クローリング

スクレイピングやクローリングは、プログラムで自動的にインターネット上から情報を取得してくる技術です。グーグルのクローラーが回遊して、取得したページを検索結果に表示させるというのは有名ですが、これで使われている技術です。 APIが提供されていないWebサイトから情報を取ってくることができるので、例えば複数の不動産のサイトから物件情報を根こそぎ取ってきて、全部一括で比較するようなサービスが作れます。ただ、実際はスクレイピングを禁止しているサイトとかもあるので、その辺りは実施する上で注意が必要です。

2. 便利さに人が集まるサービス

何かの情報処理や情報管理をしてくれるようなサービスです。
Gmail、Torello、Slackといった有名なツールであったり、文字数カウント、画像の白抜き処理、アイコンのダウンロードといった必要に応じて利用するようなサイトのイメージです。
こういったサービスはユーザーに使ってもらって受け入れられると、継続して使ってもらうことができます。そのため一度作ってしまえば(あまり集客)をしなくても、徐々に利用者が増えていきます。
冒頭紹介したオンラインメモはこれに当たると考えています。

このタイプのサービスの問題は、技術力と構築にかかる時間だと思います。例に上げたようなツール系のサービスは大抵は誰か他の人・会社がすでに開発していることがほとんどです。それらを超えるためには、機能・UI/UX・パフォーマンス(速度とか)などで上回り、乗り換えても良いと思えるレベルまで押し上げるエンジニアリングの能力が必要になります。
さらに、技術力があったとしてもそれなりの規模のものを作るにはかなり時間がかかります。

3. 面白さに人が集まるサービス

脳内メーカーや性格診断のような、使うとちょっとおもしろいみたいなサービスです。流行ると爆発的にアクセスが伸びるので、時間をかけてコツコツみたいなものとは逆のイメージです。
また、ボケてのようにユーザーがコンテンツを増やすことでてサービスが大きくなるUGC(User Generated Contents)も個人的にはこれに近く、1. 情報に人が集まるサービスをUGCにしたい場合はこの面白いということがポイントなんじゃないかと考えています。

このタイプのサービスの問題は、まずうまくヒットさせるのが難しい(アイデア次第)というところと、飽きられやすいので長期的にサービスを育てて行きにくいという点かなと思います。

ではどんなサービスが良いのか

それぞれ開発や運営、集客のハードルがある中、ではどれが良いのかという個人的な意見は、2. 便利さに人が集まるサービスです。
1. 情報に人が集まるサービス3. 面白さに人が集まるサービスに比べると構築のための労力がよりかかりますが、特定のニーズに合わせた機能を開発すればある程度長期間、そのニーズを持ったユーザー層に利用されやすくなると思います。さらに実用的な機能を開発する必要があるため技術的な勉強にもなり、一回作って終わりではなくシステム保守的な観点も身につくと思います。

キャッチアップ

何を作るかが決まったら、作るために必要な技術や知識をキャッチアップします。 そのためには、作るものの機能を細分化していって、そのために必要な勉強をします。
初めてWebサービスを作る方からしたら何からやればいいかもわからないと思います。ざっくり、どんなWebサービスを開発する場合でも必要になる知識をまずリストアップしてみました。

Webサービスに必須の技術や知識

  • HTML / CSS
    • HTML:Webページの内容(コンテンツ内容やコンテンツの重要度、役割などを)を定義したもの
    • CSS:Webページの見た目を装飾するもの
      この辺は解説しているページがたくさんあるのであまり書きませんが、ようはサイトのページそのものを書く技術です。Webサービスの場合、プログラムが自動的にHTMLを生成してブラウザに返して、ユーザーに表示されます。
  • プログラミング言語
    例えば単なる自己紹介のWebページを作るだけなら、自己紹介文をHTMLで書いて表示するだけで事足ります。
    しかし、生年月日に従って自動的に年齢を計算して表示したり、データベースにプロフィール情報を保存してその内容を表示したりするためには、必然的に何かしらの計算や情報処理が必要になります。こういった場合にはプログラミング言語でその処理内容を定義してあげないといけません。
    Webサービスと親和性の高い言語は、Ruby、Python、PHP、Javaなどです。よくどの言語が良いか、みたいな議論があると思いますが、これは好き嫌いなので別になんでも良いと思います。周りに教えてくれる人がいると良い、という意見もあるので、もしそういった方がいればその言語にするのもありだと思います。
    ぶっちゃけそんなに大したものを作らないレベル(の私など)であればどの言語で作ってもアウトプットは変わらないので、本当になんでも良いというのが正直な所です。
    プログラミング言語に関しては、HTMLとプログラミング言語をどう関連付ければ良いか、最初よくわかりませんでした。
    イメージ的には、HTMLで書いた中に、言語毎に決められた書き方で処理内容を書くという感じです。
    なのでよくわからなくても、『なんだ、1つのファイルの中に同居させられるのね』、と安心してくれればと思います。
  • Webフレームワーク
    プログラミング言語はいろいろなものに使えます。Webサービス、デスクトップアプリ、業務アプリ、スマホアプリなどの裏側ではいずれかのプログラミング言語が利用されています。
    Webフレームワークはこの中のWebサービスを作るのに特化した機能の雛形集みたいなものです。具体的にはユーザー管理、ログイン処理、セキュリティ対策、DBとの接続インターフェースなどです。
    このWebフレームワークは各プログラミング言語ごとにいくつかの有名なものがあり、例えばPythonならDjango・Flask、RubyならRuby on Rails、PHPならLaravel・CakePHP、JavaならSpring Frameworkなどです。
  • Webの仕組み
    HTML / CSS、プログラミング言語といった話は実はサービス全体の中では実は細かい枝葉の部分だったりします。
    Webサービスにはユーザーが何か入力などをして、その情報を基にまた何かがユーザーに返されるという流れがありますが、これをなんとなくでも良いので掴んでおくと楽かな、と思います。
    具体的には、下記の感じです。

    1. ユーザーのブラウザからhttpリクエストというお願いが発信されます。このお願いは大まかに『こんな情報くれよ(GET方式)』『こんな登録がしたい(POST方式)』という2種類がよく使われます。
    2. httpリクエストはWebサービスが格納されているサーバーに飛ばされ、処理されます。『こんな情報くれよ(GET方式)』で自己紹介の性別が指定されれば、性別の情報がデータベースから引っ張り出されます。
    3. そして、Webサービスの中で性別の情報が見やすい形で生成され、HTML形式でユーザーのブラウザにレスポンスとして返されます。
    4. 最後にブラウザがHTMLファイルを読み込み、人間が見やすい形で表示するのです。
      このようにどんなリクエスト・レスポンス・情報が渡され、処理されているかのイメージがつくと、作業がすごくはかどるようになります。
  • SQLによるデータベース操作
    データベースを活用しないWebサービスも作れますが、情報を蓄積しないものは大して何もできないので、データベース操作はほぼ必須の知識です。
    どのデータベースにどんな処理( よく Create(生成)、Read(読み取り)、Update(更新)、Delete(削除)の頭を取って”CRUD”と呼びます)をさせるかはSQLというデータベース言語を使って実施します。

Teqcii(テッキー)|Qiita エンジニア検索・ランキングサイトでの必要機能の洗い出し例

さて、長くなりましたが今回Teqcii(テッキー)|Qiita エンジニア検索・ランキングサイトでの必要機能の洗い出し例を作る上で必要になりそうなことは下記のように想像しました。このように必要な要素を想像すると、どのような新しいことをキャッチアップする必要があるのか見えてきます。

  • QiitaのAPIを定期的に叩いて情報を取得・更新する
  • サイト上での表示のためにAPI経由のデータを定期的に集計する
  • サイト上での検索・フィルタリングを実現する
  • グラフやワードクラウドをJavaScriptで実現する
  • ワードクラウドのための形態素解析やキーワード抽出処理を実現する
  • データ量が多くなるので、ある程度速度を担保できるようにする

ざっとこんな感じで必要機能を書き出し、どんな書き方をすると実現出来るのか、キャッチアップをしながら部分的に試しつつイメージを固めていきます。

キャッチアップの方法

身につけないといけない技術がわかると、その勉強を始めます。
おすすめのキャッチアップ方法は、まずドットインストールで必要な部分をざーっと勉強して、ドットインストールで言及されていない部分は地道に検索して知識をつける、という流れです。
動画でレクチャーしてくれたりチュートリアルに従ってコードを書く練習が出来るサービスが最近多いですが、正直入門本を片手にコードを写経するようなものに感じます。私の場合、作りたいもののために必要な知識だけつけられればそれで良いので、あまり基礎からみっちりといったことはやりません。このあたりは好みですね。 ドットインストールすばらしい教育サービスが、

  • 簡易的なサービスを実際に作る、という内容が多くかなり実践的
  • 結構レベル高いものも多い(twitterAPI連携ツール作りましょう、とか) という特徴から、特に参考にさせて頂くことが多かったです。

あとは、細かい部分をひたすら検索して調べます。 今回ですと例えば、”Django 速度改善”、”Python APIコール”といったワードでググりまくりました。
Webサービス開発を始めた4年程前と比べると、情報量がやはり格段に増加しているように感じます。特にQiitaは知りたい内容がかなりしっかりまとまっている(しかも似ている内容のものも複数あるので比較できる)と思います。
上記のようなワードで検索すると大体Qiitaの記事が上位に表示されます。

全体像と設計

続いて設計の部分ですが、今回作ったWebサービスはかなり小規模なものなので、設計的に大変だったり工夫する部分はありません。
どちらかと言うと、

  • 環境ってなに?開発環境と本番環境?
  • 開発環境で作ったとして、どうやって本番環境に適用(ビルド・デプロイ)するの?
  • MVCってなに?言語とかサーバーとかミドルウェアとかネットワークとかいろんな用語があるけど、どこに位置してどんな意味があるの?
  • Webサービス作るときもCMSとか使うの?

といった、初心者だった私にとっては概念的・抽象的すぎてイメージがつかなかった部分の解説も交えます。 今回のWebサービスの全体像を図にしたので、これ交えてご説明します。
サービス構成俯瞰図
※ここではWebフレームワークの中身を後の説明のために一般的なMVCとしています。今回利用したPython製フレームワークDjangoはやや呼び方が異なるMTVモデルですが、基本的には呼び方が異なるだけで本質的には変わらないので、あまり気にしないでください。

環境と環境構築

まず、環境ってなんだ?という部分です。上記でWebの仕組みを簡単にお伝えしましたが、ユーザーが見ているブラウザからのhttpリクエストは、どこかに物理的にあるサーバー(コンピューター)に飛ばされます。このサーバーは受け取ったリクエストに対してレスポンスを生成して返しますが、その一連の処理をするかたまりが環境です。
ひとかたまりの環境には、処理を行うための様々なものが必要です。例えば
・レスポンスを受けて起動させるプログラミング言語 (Python・Ruby・PHP・Javaなど)
・プログラムを効率的に上手に組むためのフレームワーク (Django・Flask・Ruby on Rails・Laravel・CakePHP・Spring Frameworkなど)
・データを格納するためのデータベースソフトウェア(MySQL SQLite PostgreSQLなど)
といったものです。
そして、環境には採用したプログラミング言語やフレームワーク、データベースソフトウェアをインストールして、使える状況に環境を構築してあげる必要があります。インストール作業は通常はMacならターミナル、windowsならコマンドプロンプトを使います。真っ黒の画面で文字だけ書いていく、あのいかにもギークな感じのソフトです。
これが環境です。続いて当時私が勉強する中で最初は戸惑った開発環境と本番環境についてです。

ローカル開発環境と本番環境

よくプログラミングを勉強しましょう、といった内容のページや本で学習すると、ローカル開発環境という言葉が出てきます。これはつまりは自分のパソコンの中に、httpリクエストを受け取ってレスポンスを返す機能を構築して、その中でプログラミングをしてテストしましょうというものです。
MacならXAMPPとかMAMPといったソフトをよく使いますが、これらによって自分のパソコンの中に、WebサーバーであるApacheやデータベースを構築することができます。これがローカル開発環境(テスト環境と言うこともある)です。上の図では左下の部分ですね。
XAMPPやMAMPは起動や停止という概念がありますが、環境というのはスイッチをオンにしないとリクエストを受け取っても何もできません。常にスイッチがオンの状態で全世界に対してレスポンスを返し続ける環境、つまり本番環境が必要になります。
Webサービスは24時間365日使えるのが大前提なので、スイッチがオフになっているというのはありえないことです。しかし、自宅のパソコンを常に起動させて環境をオンにしておいてレスポンスを返し続けるというのは現実的ではありません。
24時間365日オンになっていて、開発したWebアプリケーションを動かす環境を提供するのが、外部のレンタルサーバー・VPS・Herokuなど、いわゆるインフラ面のサービスです。
私はVPSを使うことが多いので、今回もVPSを利用してこのサービスを動かしています。上の図でいう真ん中の部分ですね。
レンタルサーバー・VPS・Herokuといったインフラサービスは、できること・手間・費用の掛け合わせでそれぞれ特徴が異なります。一つづつみていきます。

レンタルサーバー

ロリポップ、さくらインターネット、Xservreといったベンダーのサービスが有名です。
レンタルサーバーはその名の通り、外部のサーバーを借りて、その中にプログラミング言語とかをインストールして環境を構築します。そしてローカル環境で開発したプログラムをサーバーに格納することで、全世界に対して公開ができます。
FTPソフト(外部サーバーと自分のパソコンをつなぐソフト)を使ってレンタルサーバーに直接ファイルをアップロード出来るので、最初のうちは何をしているかわかりやすかったです。
各レンタルサーバーとも、Webと親和性の高い主要なプログラミング言語はサポートされています。しかし、OSが固定され管理者権限が無いため、ライブラリなどを入れて利用するということの制約が結構発生します。
少しわかりにくいと思いますが、Webフレームワークとか使わずにすごくシンプルな構成でサービスを作ろうとすると実現はできますが、より高度なことをしようとするとかなりつまずくと思います。(これを本気でやろうとしたことがないので不確かで、すみません)

VPS

VPS(Virtual Private Server )とは、外部の物理的なサーバーを複数の(もちろんお互いに知らない)利用者で共有するが、それぞれの利用者の自由度は担保されたサービスです。サーバーを共有するという意味ではレンタルサーバーと同じような考え方ですが、レンタルサーバーと異なりOSの選択から管理者権限での処理まで可能なので、自由度がぐんと上がります。
ただサービスを構築するためには前準備が結構必要になってきて、プログラミング言語をインストールしたり、Webサーバー(Apacheやnginx)をインストールしたり、ファイヤーウォールの設定をしたり、https対応をしたり、DBをインストールしたりと、やらないといけないことが多いです。VPSはこのあとのHerokuと比較すると安価なので、やるとしても技術的なことがだんだんわかってから取り組むのが良いかと思います。

Heroku

HerokuはVPSよりも一段階至れり尽くせりで、VPSでやらなければいけなかったことがほぼ自動的に行われるようなイメージです。もう少し具体的には、ローカル開発環境からHerokuに対してWebサービスを転送(Push)すると、Webサービスとその設定ファイルの内容から、必要な環境を作ってくれるという感じです。
便利な分コストがかかりますが、しっかり運営する目的ではなくとりあえずWebサービスを外部公開したいといった場合用の無料プラン(毎日6時間以上はサービスが停止されていないといけない)もあるので、最初の練習にはもってこいだと思います。

MVCって何?

ここまでで、ローカル環境・本番環境の両方に開発したプログラムが入っていることになる、とお分かりいただけると思います。上の図では本番環境と書いた枠の中のアプリケーションと書いた部分です。
では、その開発するプログラムはどのような方針や設計で作れば良いのでしょうか。Web系のプログラムですと、MVCという概念で設計することがお作法みたいになっています。
MVCも調べればいろいろ出てくるのでここではあんまり語りません。というか、どのプログラミング言語でも何かしらのフレームワークを採用すれば、MVC型のアーキテクチャのサービスを開発することになります。それらのフレームワークはMVCのお作法で開発することを前提としているのです。
むしろ、このフレームワークとかMVCという概念は取り入れないといけないものなのでしょうか。私はとりあえず何か作るのなら、別に踏襲しなくてもいいと思います。
例えばTeqcii(テッキー)|Qiita エンジニア検索・ランキングサイトをWebフレームワーク(Django)なく機能的にもシンプルに作ろうとすると、ファイル構成は下記みたくします。

  • Qiitaユーザーの一覧を作るファイル 検索やフィルタリングに対応
  • Qiitaユーザーの詳細ページを作るファイル
  • QiitaのAPIを叩くファイル

ページを作る2つのファイルは、ヘッダーなど共通する内容も多いですが(本来はテンプレートファイルみたいなものを作るべき)ページの数が少ないので無視します。Teqcii(テッキー)|Qiita エンジニア検索・ランキングサイトはとてもシンプルで今後の拡張性もあまり考えていないため、このくらい安易な作りでも良いかなと思います。
MVCはお作法的な概念なので特に必須ではないですが、実際はフレームワーク使っていると自然とMVCに則ったWebサービス開発になっていきます。

バッチ処理はどうするの?

サービスを作っていると、ユーザーの行動に応じて何か表示するMVC的な部分とは全く別に、定期的に自動的に動作するプログラムもよく必要になります。
例えばデータが増えすぎると無駄なデータとか活用されていないデータを自動的に消す、みたいなことです。
これは、サーバーやHeroku側の機能で補填することができます。cronやスケジューラーと呼ぶのですが、それぞれの環境で登録しておくと自動で実行されます。さらに、もしフレームワークを活用する場合は、大体”バッチのような自動処理はこのディレクトリに定義してね”、という領域があるので、そこに書きます。

Webサービス作るときもCMSを使うの?

まず簡単にCMSとは?というお話ですが、CMSとは(Contests Management System)の略で、Webサイトにアップする記事・特集ページ・静的ページなどのコンテンツを効率的に管理するツールです。例えばニュースサイトで記事を書く場合、記事は静的ページなのでHTMLファイルをアップロードすれば良いのですが、例えば記者の方はHTMLがわからないとか、後で編集するときにいちいちHTMLファイルを探さないといけない、一括で編集ができない、、など手間がいっぱいかかります。CMSはそういったことを簡単にするためのものなので、ほとんどのWebサイトで活用されます。現にいまご覧いただいている私のブログも、Wordpressを使って作ってあります。
ほとんどのWebサイトで活用されるのですが、Webサービスを構築するときはCMSは基本使いません。
ブログなどを書いている方がWebサービスを始めようと思うと、見た目を綺麗にしたいから、テンプレートの多いWordpressを使おう!みたいな考えになるかもしれませんが、下記のような理由であまりおすすめしません。

  • そもそもCMSには構築するWebサービス自体に何か処理能力を付与するといったことをあまり前提としていない。
  • 処理能力をもたせようとすると、CMSをカスタマイズしたり無理やり処理する機能を外に作る必要がある。
  • Jqueryなど、CMSごとに独自のものを活用しているため、自分が使いたいと思うものと互換性が合わず、バッティングする。

では、よく見るWebサイトみたいにカッコいい見た目にするにはどうするんだ、という話になるのですが、デザインフレームワークを使います。

デザインフレームワーク

CSSフレームワークやデザインテンプレートとかいろんな言葉がありますが、ようするに簡単にサイトの見た目を綺麗するためのすぐに使えるデザイン集です。
有名なところだと、BootstrapやMaterialize CSSで、私は大体Bootstrapを使います。理由は有名で使い方の解説がそこらへんにたくさんあるのと、自分自身がBootstrapに慣れてきたからです。
デザインフレームワークは、Webサービスの任意のディレクトリに配置し、HTMLからそのフレームワークを読み込みに行くことで(HTMLファイルの中でパスを記載する)使えます。
上の図だと、本番環境の中のプログラムの中のViewの隣にBootstrapとありますが、ViewがHTMLを生成するときに読みに行っているイメージです。

開発

全体像がわかってくると、それを実現するべくローカル開発環境でガリガリプログラミングを進めていきます。
初心者のうちは必然的にいろんなサイトからソースコードをパクってコピペして微調整して、という方針で開発を進めると思います。ここで覚えておくと大事なのは、デバッグという概念と、デバッグの方法です。

何から手を付けるか

デバッグが大事

デバッグはバグを取り除く、つまり問題点を見つけてそれを修正するという作業です。
いろんなサイトにソースコードがあるので、やりたいことの実現方法はたくさんあります。しかし、1人で作っているとコピペしてもそれがうまく動かないときに、どうして良いかわからず立ち往生してしまいます。
そこで、様々な方法で問題点を見つけるアプローチがあります。

サイトに表示させる

手っ取り早い方法です。問題が起きている箇所の直前で、保持しているデータの内容をサイトのフロントに表示させるというアプローチで、例えばPHPならプログラムの中に ”echo 中身を見たいデータ” とか、”var_dump(中身を見たいデータ)”という風に書くことで、この内容がサイトに表示されます。

フレームワークのデバッグ機能を使う

使うフレームワークによって、デバッグ機能がついていると思います。基本的には上のサイトに表示させるという方法を似ているのですが、もっと細かく見ることができます。この方法も、プログラムの中にフレームワークごとに定義された方法でデバッグの命令を記述します。

httpリクエストの中身を見る

httpリクエストをうまく送れていないことが不具合の原因だったりします。
例えば名前を入力して保存ボタンを押して、サーバー側でデータベースに登録する、といった時に、自分はサーバーの登録処理に問題があると思っていても、実際は保存ボタンを押しても入力した名前がリクエストとして送られていなかった!みたいなことがあります。 こんな時は、Chromeのデベロッパーツールでnetworkタブを開いて、レスポンスの内容を見ます。 howtodebug こんな感じです。この方法を覚えてからは結構効率的に問題点を見つけられるようになりました。

本番環境へデプロイして公開

さて、なんとかWebサービスをローカル環境で作ると、次は全世界への公開が待っています。
公開のために必要なものと手順を追って説明します。

本番環境を用意する

上で説明したレンタルサーバーやHerokuのような外部サービスに登録します。

ドメインを取得する

ドメインとは、WebサイトやWebサービスのインターネット上での住所を表すもので、このブログであれば http://mtitg.com/ です。
サービスによってはドメインを無料で取得出来ることもありますが、完全に自由なドメインにする場合は数百円~数千円払う必要があります。サービスを大きくしていくつもりだったら必要ですが、とりあえず何か作る、くらいであればこだわらなくてもいいと思います。
もしまずはとりあえず作ってみたいということでインフラはHerokuを利用する場合、ドメインは無料で自動的に取得することができます。その場合ドメインは https://~ここは自由に決められる~.Herokuapp.com というものになります。
Herokuであれば、後からドメインを取得してもすぐ変えられます。なので最初は無料のドメインを使っても良いんじゃないでしょうか。

本番環境へデプロイ

自分のパソコンのローカル開発環境から、契約したサーバーなどにプログラムをコピーします。

データベースにテーブルを作る

プログラムだけだと、Webサービスはまだ動きません。データを格納するためのデータベースに、テーブルが出来ていないのです。
そのため、ターミナル・コマンドプロンプトから直接SQL文を送ったり、レンタルサーバーの管理ツールでテーブルを作ったりします。

集客や拡散周りを行う

もう公開は目前です!
あとは細かい部分をざっとやってしまいます。

  • google analytics設定を行う
  • web master登録をする
  • SNSのシェアボタンをつける
  • SEO対策をする   
    • goodkeywordsとkeiwordplannerで狙いに行くワードを決める   
    • titleタグを記載   
    • meta descriptionタグを記載   
    • hタグの階層を整える
  • 拡散のためにいろんなWebサイトに登録する  
    ※これは以前記事を書いたのでご覧ください。 新しいWebサービスの宣伝・拡散は普通にやってちゃ駄目だこりゃ
    こんなところでしょうか。集客系はやりだすと終わらないので、チェックリストなどを眺めて、ここまでやろう、というラインを切ってやると良いと思います。
    いかがでしょう、私が1+3年間やってきてなんとなくイメージがつかずにモヤモヤしていた『サービスの全体像』や、『全体像の中での各領域の関係性』を全部ご紹介してみました。是非、みなさんのWebサービス開発に役立ててください。
Pocket

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です