sola

2018-12-09に更新

個人開発サービスに用いられている技術 6日目

初めてのウェブサービスを WordPress + Vue.js で個人開発した話

WordPress PHP Vue.js Twitter YouTube Vagrant VCCW KUSANAGI 個人開発 VTuber

読了目安：18分

はじめに

11月25日(日) に「にじさんじ配信スケジュール」と呼ばれるウェブサービスをリリースしました。

正確には初めてリリースしたサービスでは無いのですが、会員登録機能が用意された本格的なサービスを出した事がこれまでなく、実質的には初めてのサービスと呼んでも良いだろうと考えています。

という訳で、Crieit「個人開発サービスに用いられている技術 Advent Calendar 2018」6日目は「初めてのウェブサービスを WordPress + Vue.js で個人開発した話」と題して、開発に WordPress や Vue.js を用いたこと、ウェブサービスを作るまでの話や、リリース直後の話をしたいと思います。

n番煎じなテーマですし、蛇足に感じられる内容も多々あるかと思いますが、適宜必要な箇所をお読み頂ければ幸いです。

この記事の想定読者

これからウェブサービスを個人で作りたい方や開発中の方
ウェブサービスで実際に用いられている技術やツールを知りたい方
開発ノウハウを知りたい方
技術面以外の話にも興味がある方

開発経緯

「にじさんじ」と呼ばれるバーチャルライバー (VTuber) グループが存在しています。

僕はこちらのグループのファンなのですが、公式がスケジュール情報の発信を行っておらず、スケジュールを把握しにくい問題がありました。
スケジュール情報を発信する非公式サイトやアプリも存在していますが、閲覧がしにくく使い勝手が悪い状態でもありました。
そこで、スマートフォンでも十分に閲覧でき、にじさんじライバーの配信スケジュールに特化したウェブサービスを作れば需要があるのでは考え、開発に着手しました。

主な機能

元々はシンプルにスケジュールを確認出来るだけのシンプルなサイト開発を考えていましたが、
自分自身が必要十分に感じるレベル（このサービスユーザーのペルソナの1つは自分自身です！）に加え、サービスとして多くの方々に利用頂く事を前提に機能検討した結果、リリース時は以下の機能を実装しようという結論に至りました。

ユーザー向け機能

バーチャルライバー (VTuber) グループ「にじさんじ」メンバーの生配信スケジュールの閲覧
実際の生配信（ライブ）、アーカイブ情報の閲覧
ライバー情報の閲覧
ライバーのフォローを元にしたスケジュール等の情報閲覧（要会員登録）
配信時間前のメール通知（要会員登録）
Twitter へスケジュール情報まとめツイート
端末を問わず利用可能（レスポンシブ）
ネイティブアプリっぽいリッチなデザイン

運営者向け機能

スケジュール、ライブ、アーカイブ情報の自動取得（API、スクレイピング）
情報登録時のメール通知
管理画面

にじさんじは59名（現在は58名）と多くのライバーを擁します。
ライバー全体の情報を網羅しようとした場合の情報量は馬鹿に出来ません。
ユーザーごとに追っているライバーは異なるため、にじさんじ全体の情報をすべてのユーザーに一律に見せる事はユーザーの負担に繋がります。
また、にじさんじには「1期生・2期生（無印）」「ゲーマーズ」「SEEDs」という3つのグループが存在していますが、それぞれを追っているファン層は異なります。
さらに、グループ問わず人気ライバーを追っている方や、特定のライバーに搾って追っている方など、ユーザーの興味は多種多様です。

そこで、以下のフィルタリング機能を備えることにしました。

にじさんじ内のグループごと
ユーザーによるライバーのフォロー

フォロー機能を用意する場合、会員機能の実装は欠かせません。

また、当サービスを多くの方に継続的に使っていただくことを考えた場合、アプリっぽいデザインで使いやすい UI を提供する事は欠かせないだろうと考え、フロンロエンドを Ajax で提供することに決めました。

運営者向け

過去に情報の手動更新で苦労した経験があった為、情報の自動取得は欠かせませんでした。
また、テストデータを作成したり、自動化を行った場合であっても、情報の編集は適宜必要となる事から、GUI の管理画面の存在も必要でした。

使用技術・開発ツール

今回用いた技術・開発ツール

WordPress

開発フレームワークとして WordPress を用いた理由ですが、

見知った技術であること
データの CRUD 、ページ作成、ユーザー認証など、会員機能付きウェブサービス作成に必要十分な機能が揃っていること
管理画面が標準で用意されていること
「プラグイン」を用いて楽が出来ること
枯れた技術であること

上のようなものが挙げられます。

特に「管理画面が標準で用意されていること」は重要で、管理画面が必要な状況において、これがあるのと無いのとでは開発工数に雲泥の差が生じます。

データモデルの構造上、複数のデータ項目への検索実装が難しい点が弱点ではありますが、検索を主体としたサービスでは無いため、あまり問題にならないと判断しました。

Advanced Custom Fields Pro

WordPress にてカスタムフィールドを扱う際 Advanced Custom Fields が欠かせません。
繰り返しフィールド（配列）を簡単に用いることが可能な有料の Pro 版を使用しています。

GUI でデータ構造や管理画面を作成する事ができ、大変重宝しています。
コードを書かずに済む作業は、書かずに越したことがないです。

WP-REST API

Ajax でのレンダリングを行う場合、情報元となる API が欠かせません。
以前は admin-ajax.php を利用して API を1から作る必要がありましたが、
今では WordPress コアに標準で API の機能が備わっています。WP-REST API を使わない手はありません。

jQuery

こちらも WordPress コアに標準で含まれています。
ユーザー画面においてもツールバーの描画に必要で、WordPress を用いる場合欠かせません。
また、後述する Semantic-UI のスクリプトも jQuery で出来ており、jQuery に依存せざる得ない状態です。

とはいえ、単一 DOM の表示切り替えといったシンプルな仕事は jQuery 向きであると言えると思います。
また、Ajax 用の仕組みも備わっており、上のような前提が存在する状況においては、別途 axios といったライブラリを用意しなくとも済む点は引き続き評価出来ます。

Vue.js

Ajax にて取得したデータを用いて画面を構成する場合、開発効率やコードの視認性、いずれを考慮してもビューとコントローラーの仕組みは欠かせないだろうと思います。

Angular, React, Vue.js あたりが採用候補にあたると思いますが、jQuery との併用可能な（最新バージョンを持つ）フレームワークは後者2つのみです。
元々 Riot.js を使っていた身として、またテンプレートエンジンライクな PHP 使いとして、 Vue.js の記法はとても親近感があり書きやすいものでした。
また、Vue CLI, Nuxt.js といった関連技術も充実しており、廃れる心配が少ない技術だろうという点も技術選定の後押しポイントになりました。

Semantic-UI

UI コンポーネントは Bootstrap が有名で、僕も用いたことがありますが、
あまりにも多くのサイトで用いられている事から見慣れてしまい、飽きを感じ始めていました。
そういった状況で Semantic-UI を見つけた時は感動したのを覚えています。

選定理由としてデザインの好みの影響は多分にありますが、UI パターンが Bootstrap 並に備わっており、技術者として実用に耐えうる UI コンポーネントであると感じています。

Twitter API

会員登録・認証に用いました。

利用に審査が必要となり導入敷居が上がりましたが、
Google 翻訳の手助けを得つつ簡単な英文で申請を行ったところ、サクッと審査がおりました。

また、Gianism と呼ばれる WordPress プラグインがあった為、認証に係る新規コードはほとんど書かずに利用することが出来ました。

YouTube API

YouTube のライブ、動画データを取得する為には欠かせませんでした。

動画 API は REST 形式でも提供されており、利用の敷居はとても低くなっています。

PHPMailer

メール通知の際にメール配信の仕組みが必要でした。

今回、サーバーはさくらインターネットさんのものを用いましたが、多くのスパム業者の利用実績の影響からか各プロパイダからの締め付けが強く、標準ポートでのメール配信は厳しいものがありました。

PHPMailer を用いると、Gmail といった各プロパイダからの受信規制の少ないサーバーを利用できるため、メール配信にあたり安心感があります。

さくらインターネットVPS + KUSANAGI

サーバーはさくらインターネットVPS（標準2GB） + KUSANAGI という形を取りました。

さくらインターネットVPS は国内サービスのため、契約周りでの安心感がありますし、国内サービスの中での信頼性は随一です。
また、ビジネス目的でのサービスでないため運用コストは抑える必要がありますが、従量課金で無く、不意な請求が絶対に起こりえない点もポイントでした。

KUSANAGI については WordPress サイトを運営する為に必要な nginx, PHP の設定がデフォルトで最適化されており、SSL 化に欠かせない Let's Encrypt も自動で走るなど、WordPress サイトを運営するために至り尽くせりな機能が OS レベルで備わっています。

heroku や Cloud9 といった PaaS に頼る手も検討しましたが、環境セットアップの安易さはそれらのサービスに劣らないことや、さくらインターネットの場合は VPS であってもスケールアップ可能といった特徴を持つことから、最初のウェブサービスはこの構成から始めることにしました。

VCCW

開発環境は VCCW を用いました。
VCCW とは Vagrant がベースの WordPress 開発に最適化されたツールです。
macOS での導入は一瞬でした。

PaaS ではなく VPS を用いた理由としては VCCW の存在も大きく、同梱された Wordmove で DB 含めたデプロイ（同期）が一瞬で完了するなど、VCCW を用いた際の総合的な体験がとてもスマートで感動しました。

実は、これまで Filezilla (FTP) を主なデプロイ手段としていましたが、どうして早く試さなかったのかと反省しています。

Visual Studio Code

コードはもっぱら Visual Studio Code で書いています。
これまで Sublime Text を用いていましたが、稀に落ちたり OS ごとの挙動差分が気になっていました。
Visual Studio Code は開発環境をベースとしており拡張性も高く安心感がありますし、動作が軽快なためストレスフリーにコードが書ける点がとても評価出来ます。

Google Chrome

開発関係のプラグインが豊富である事、検証ツールにてスマートフォンやタブレットの画面エミュレートが安易である点が良いです。

もちろん、最終的な動作確認の際は各種ブラウザ（Safari, Firefox, Edge, Opera, それぞれ最新）・OS（macOS, Windows, iOS, Android, それぞれ最新）でのテストも行っています。

Git

純粋にファイルのバージョン管理目的で用いました。

ちなみにホスト先は Bitbucket、クライアントには SourceTree を用いています。

Macbook Pro (13inch)

ハードウェアの好みで用いています。

スペックですがメモリ16GB、CPU Corei7 2.5GHz デュアルコア、SSD 512GBになります。

VCCW にて仮想環境を走らせる都合上、ある程度のメモリが必要となります。
8GB では処理が重く感じられる為、7月に new MacBook から移行しました。

メモ (Apple)

ToDo リスト機能が便利でした。

今回用いなかった技術・開発ツール

Gutenberg

WordPress のエディタにブロックの概念が導入され、レイアウトレベルで見たまま編集が行えるようになりました。その機能名の事を Gutenberg と呼びます。
WordPress 界隈においては有名な新技術ですが、Gutenberg を無効化する Classic Editor を入れ導入を見送りました。
以下のような理由からです。

今のところ新しい技術であり今後仕様が頻繁に変わるリスクがある
画面の表示要素を再利用したり、レイアウトを頻繁に変更したり、デザインを他人に任せたり、ユーザーに編集させたりといった、Gutenberg のメリットを享受可能な状況に置かれていない

Firebase

フロントエンド中心の開発の勉強も兼ねて用いることを考えましたが、自動化にあたってスクレイピングが必要で、サーバーサイド中心の開発にせざる得ませんでした。

Laravel, CakePHP 等の開発フレームワーク

複雑なデータモデルが必要であったり、検索が重要となるサービスを開発する場合は WordPress では限界があったと思いますが、そうではありませんでした。

Drupal, concrete5, baserCMS, Movable Type 等の CMS

前者2つについては、掲示板など会員管理周りの機能が充実している事やエディタのリッチさが売りかと思われますが、その点において今回メリットには感じませんでした。

baserCMS については、CakePHP がベースに採用されており、かつ管理画面も備わっている事から、開発者目線ではとても魅力的です。
今回は採用していないですが、データモデルが複雑で、管理画面もサクッと用意したいという状況においては、選ばざる得ない選択肢だと思われます。

Movable Type は WordPress 以上に一般サイト制作に特化しており、会員管理等の標準機能が弱い印象があります。

CDN

入れれば速くて良いのですが、コストが気になります。趣味のサービスには向かないでしょう。
今回は KUSANAGI (nginx + サーバーキャッシュ) に頑張ってもらっています。

gulp, babel, webpack 等のフロントツール

実はまともに用いたことがありません。（勉強せねば…）
ただ、これらのツールが活用できずともウェブサービスを開発し運用を開始出来る状態になる事が分かります。

初心者はWebpackの事は一度忘れた方が良い - Crieit

AMP

文章や写真ベースの記事がほとんど無く、JavaScript に頼るページも多く導入は見送りました。

ただ、Vue.js でのレンダリング結果を Googlebot が拾ってくれない都合で、Vue.js のレンダリングが完了するまでは SSR の結果を表示する仕組みを入れた事で、JavaScript に頼るページがほとんど無くなりました。

AMP を導入した場合 SEO 効果も期待できるため、後々導入する可能性があります。

PWA

アプリっぽい見た目にした事や Ajax での情報取得は PWA 化を見越しての方法でもありました。
一旦 apple-touch-icon の設定でお茶を濁しましたが、AMP 同様後々導入する可能性があります。

Docker

VCCW のお陰で、動作環境としては Linux ベースで開発が出来ており、本番サーバーに環境も近いはずで、環境を揃える意味ではほとんど不要だろうと考えていたのですが、本番リリース直前に本番でのみ発生する不具合に見合わされました。
始めから Docker ベースでの開発であればそのような悩みも発生しなかっただろうと思います。
今後の新規開発の際に導入を検討する可能性がありそうですが、費用を中心に何かとコストが増えやすい為、趣味のサービス開発での導入は難しそうです。

開発やリリースで苦労したこと

上で記載した以外の点について触れたいと思います。

類似サービスの登場

開発開始からわずか数日ほど経ったタイミングで、VTuber のスケジュールを扱うサービスが登場しました。

一見デザインも綺麗で、にじさんじ以外も含め、様々な VTuber のスケジュールが登録されています。

ただ、スケジュールが不十分な部分があったり、にじさんじ好きにとってはノイズとなる情報も多いなど、欠点や方向性の違いによる差がある事も分かってきました。

当初の目的を常に意識しながら、なんとかリリースする事が出来ました。

Twitter アカウント凍結

現在 @nijisanji_net というアカウントを用いていますが、元々はドメイン取得時に別のアカウント名で作成し放置していたところ、何故か凍結の事態に…

このような事は初めてでしたが、凍結直後に気づくことが出来ず、凍結解除申請も虚しく現在も凍結されたままになっています。

惜しかったですが、思い切って別アカウントを作成し事なきを得ました。

スクレイピング

スクレイピング対象に想定外のパターンの文字列が混ざった場合、データに不具合が発生します。
中にはスクレイピング先情報の typo など、どうしようもないものもありますが、
大きなデータ崩れが発生しないように抑えるべく、多くの分岐処理が必要となりました。
スクレイピングは本サービスのコア機能になりますが、最も実装に時間のかかった部分でもありました。

Google Search Console

リリース直前に noindex,follow 指定で本番環境でのテストを行っていた影響で、この記事を書いている現在もエラーを吐く状態となっています。
当初は別に問題があるのではといろいろ試したのですが、不慣れのため、単純な時間の問題だろうと気づくまでにとても時間がかかりました。

Googlebot 上で Vue.js が機能しない

Search Console 上の問題もあり、時間が経つまでの検索インデックスは DOM に頼るしかない状態となっていましたが、
その問題に追い打ちをかけるように Googlebot 上で Vue.js が機能しない問題にぶち当たりました。

Googlebot で JavaScript を解釈できる事は知っていましたが、Vue.js など一部のスクリプトが正しく認識されない問題についての知識が無く、これには参りました。

結局 Vue.js で出力される内容をサーバーサイドレンダリング (SSR) させ、 Vue.js が読み込まれるまでの間の表示をサーバー側に任せる事でなんとか事なきを得ました。

開発期間・工数

9月9日に開発を開始し、11月25日に公開しました。
開発期間は約3ヶ月、累計作業工数は142時間でした。

工数について

当初はせいぜい数十時間で終わるだろうと見込んで開発を開始しましたが、実際はサービス開発を行いながら仕様を詰めており、当初の想定よりも機能が増えたことから、予定よりも工数が嵩んでしまいました。

また、作成していたプログラムの不具合の影響で、手動で作成していたライバーデータを全て別データで上書きしてしまったのですが、そのライバーデータの作成に10時間近くかかっており、再度同様の工数が発生しました。

さらに、リリース直前に発生した本番環境限定の不具合もあり対処に10時間ほど時間が取られてしまいました。

実際にかかった時間と比較し20時間〜30時間ほどは短く出来たのではと思います。次に活かしたいです。

余談ですが、改めて2つ歳下のせせりさんのすごさを実感しました。

「1人で6時間で作った」　Twitterで匿名質問「Peing」人気、月間2億PV超えへ - ITmedia NEWS

開発以外で取り組んだこと

他の趣味活動の制限

ポッドキャストやブログでのアウトプット、仲間との Discord など、日常的に様々な趣味活動を行っていましたが、業務、他のプライベートでの活動も含め忙しく、削れる活動は制限する事に。

もちろん、万人が意識する事でも無いと思いますが、忙しい社会人が開発を継続していく為には、多少他の活動を制限する覚悟が必要だと感じています。

息抜きは欠かさない

とは言いつつも、仕事も開発、プライベートも開発で休み無しという状況では、つらい日々が続きます。

趣味のアニメ視聴時間は一切削らず、本サービスで扱っている VTuber 動画の視聴時間もある程度確保した事は、
モチベーションの維持に大きく貢献しただろうと思います。

開発者コミュニティへの加入

運営者ギルドのメンバーとなりましたが、他のみなさんの発言は「自分も頑張らないと」という刺激になりました。

リリースしてからの気付きや変化

アクセス数が気になって落ち着かない

公開から数日たった現在は多少慣れましたが、公開1日目は気づいたら Analytics の画面を見ている状態で本当に落ち着きませんでした。

運用に時間が取られる

理論上は自動化出来ているため、運用に時間が取られることも少ないだろうと考えていましたが、実際は更新ツールの不具合を修正したり、データを一部手直ししたり、アクセス数を増やすための SEO や PR を行ったりと、100%の自動化は中々難しく今後の課題であると感じています。

WordPress + Vue.js を用いてどうだったか

WordPress

サービス開発においても使用感は悪くなかったです。

そもそもとして、開発フレームワークではない WordPress を開発に用いる事に対する心配をお持ちの方は多いと思われますが、上に記載した通り

データモデルの構造上、複数のデータ項目への検索実装が難しい点が弱点

問題はこの程度だと考えています。

大規模な開発になった際に、規約が少なくコードの品質が担当者間で不揃いになりやすかったり、
データモデルの都合上パフォーマンスの問題も出てきますが、
個人開発レベルにおいてはほとんど心配する事ではないだろうと思いますし、
現実的な対策は十分可能ですので今後業務の開発でも用いると思います。

Vue.js

リリース後に SEO 面の問題が発生した為、フロントエンド技術に頼った開発は難しそうだと実感させられました。
ただ、今回のようなサーバーサイド技術との併用であれば小回りも効くため、十分実用的ではと思います。

WordPress と Vue.js の併用

下記2点があり、併用には全く支障がありませんでした。

WordPress 標準で API が提供されている
WordPress コアに含まれている jQuery と Vue.js が併用可能

その他

Semantic-UI と Vue.js のかみ合わせがあまりよろしくなく、
Semantic-UI 内の JS ライブラリで作成したフォームの value が Vue.js 側で上手く取得できませんでした。
Semantic-UI に value を直接返す関数が提供されておりどうにかなりましたが、
サードパーティ製ではあるものの Semantic UI Vue と呼ばれる UI コンポーネントも存在している事から、今後はそちらを使っていく可能性があります。