Web アプリケーションエンジニアの 
id:todays_mitsui です。
この記事は『Inside GigaViewer for Apps』連載14回目の記事です。
はてなでは Webマンガビューワ「GigaViewer for Web」を使って、出版社様ごとに異なる Webマンガサービスの構築・運用を行っています。
おかげさまで多くの出版社様に導入いただいており、私もチームに加わって以来、いくつかのサービス立ち上げに関わってきました。
この記事では、私たちが新しいサービスを立ち上げるときに考えていることを、アプリケーションエンジニアの目線から紹介します。
タイミングを逃さないように素早く立ち上げたい
サービスの立ち上げには、出版社様・弊社のそれぞれで多くの人が関わります。
そのため、企画がスタートしてから公開に至るまでには、どうしても半年〜1年ほどかかってしまうことも珍しくありません。
とはいえ、私たちとしては「なるべく素早く立ち上げて希望のタイミングで公開できるように」という気持ちで仕組みを整え、開発に向かっています。
たとえば「こんな風に作品を届けたい」「このタイミングでキャンペーンを打ちたい」といった明確なゴールがある場合、それを実現する日は早い方が望ましいことも多いと考えています。
そのために、私たちは「共通機能をベースにした素早い立ち上げ」を大切にしています。
マルチテナント構成で典型的な要望を素早く実装
これまでの連載でも何度か話題に出ていますが、GigaViewer for Web のバックエンドはマルチテナント構成になっています。
出版社様ごとにサイトデザイン・掲載コンテンツ・ドメインなどが異なっていても、裏側でレスポンスを返しているアプリケーションは共通です。
これは私たちエンジニアが楽をするためでもありますが、それ以上に「典型的な要望を素早く確実に提供する」ことで、出版社様にもメリットを感じてもらえる仕組みになっています。
つまり、すでに他サービスでうまく動いている機能があるなら、それをそのまま横展開するのが一番早くて確実、ということです。
新しいサービスを立ち上げるときは、既存の実装に設定を追加するだけで基本的な動作がすぐに確認できる状態になっています。
やるべきことは、出版社様の要望に応じて適切な Feature Flag を有効にすることだけです（詳しくは過去の連載記事で紹介しています）。
インフラの構築も共通化&自動化
また、ドメイン・ロードバランサー・ファイルストレージといった出版社様ごとに別々に必要なリソースについても、Terraform による IaC（Infrastructure as Code）で管理しています。
そのため、既存サービスの設定を流用するだけで、自動的にインフラを整備できます。
共通化されているとはいえ、設定だけでは終わらない
ここまでの話だけを見ると、「GigaViewer for Web って設定だけでサイトが立ち上がるんですか？」と思われるかもしれません。
それは半分正解で、半分は誤解です。
たしかに、典型的な機能については事前に用意が整っているので、必要な設定を追加して Feature Flag をオンにすれば、ある程度の動作確認まではすぐに行えます。
しかし、出版社様ごとに異なるご要望があるのも当然のことです。
「ここの見せ方を少し変えたい」「この作品だけ特別な取り扱いが必要」といったケースは日常的にありますし、そうした要望にしっかり向き合って実装することも、私たちの重要な仕事です。
そんなわけで、新規サービス立ち上げにともなって出版社様からの要望に応じて新しい機能を実装することもあります。むしろ、そうした「現場発」の機能こそが、GigaViewer for Web をより便利にしてくれるものです。
ここで「それってマルチテナント用ではなく専用機能になっちゃうのでは？」と思われるかもしれません。
実際、最初の段階ではどうしても“専用っぽい”実装になることが多いです。
なぜなら、1つのサービスだけで必要とされている時点では、「この機能をどう汎化すべきか」の判断材料がまだ少ないからです。
でも、その後に別のサービスで似たようなニーズが出てきたときが、私たちにとってのチャンスになります。
同じ課題に対する別の角度からの要望が重なることで、「じゃあこの機能ってこういう設計にすれば、いろんなサービスで使えるよね」という共通化・拡張の方向性が見えてくるのです。
こうした流れを経て、最初は特定のサービスのために作られた機能が、やがてさまざまなマンガサービスにとっても有用なものにブラッシュアップされていきます。
逆に、既存のサービスで既に動いていた機能を、新サービスの要求に応える形で拡張したパターンもあります。
そうやって「機能の育て方」を意識しながら、日々の実装に取り組んでいます。
機能でカバーするか？運用でカバーするか？
すべての要望をシステムの新機能で対応しているわけではありません。
とくにマンガサービスの場合、運用そのものが非常に重要な要素になるため、「どういう機能を作るか」だけでなく、「どう運用されるか」をセットで考える必要があります。
たとえば、連載中のマンガでは決まった曜日に新しいエピソードが入稿され、公開されます。
バナーやキャンペーンの更新作業も日々行われていますし、SNSとの連動施策にあわせて一時的な無料期間を設定するといった、柔軟な運用が求められる場面もあります。
こうした日々の運用がスムーズに回るように、各社の運用担当者から「どんな運用が行われているのか」「どんな施策があるのか」といった実態をヒアリングしたうえで、機能設計に活かしています。
その結果として、あえて機能を複雑にしすぎず、運用の裁量で柔軟に対応できるような仕組みに留める、という判断をすることもあります。
要望をすべて機能で解決するのではなく、運用の中で無理なくコンテンツを届けられるように、必要な仕組みを考えるようにしています。
サービス立ち上げ後に思うこと
そんなことを考えながらサービスを作っているので、公開後にアクセス数や売上が右肩上がりに伸びてくれると、やっぱりめちゃくちゃ嬉しいです。
はてなでは各サービスのアクセス数やコンテンツの売上などもレポートで確認していて、「この機能、この施策、ちゃんと効果あったかな？」という答え合わせを公開後に行うようにしています。
効果が数字に表れていると、「じゃあこの機能を他のサービスにも横展開したら、もっと喜ばれるかも！」というモチベーションにもつながります。
単に「お金をいただいてシステムを構築する」という気持ちではなくて、効果の出る機能をどんどん展開して、サービス全体の価値を底上げしていきたい——そんな思いで日々開発しています。
さいごに
今回は私が GigaViewer for Web の新サービス開発に関わるときに考えていることを書き出してみました。
はてなのエンジニアとしてマンガサービスに関わると、サービスのリリース後に出版社様の反応とエンドユーザーの反応の両方を知ることができ、自分自身ユーザーとしてサービスを使うこともできることに面白く感じています。
