ボクココ

サービス開発を成功させるまでの歩み

Herokuで成功させるサービス開発

このエントリーをはてなブックマークに追加


ページ版執筆にあたって

ども、@kimihom です。

先日の技術書典5で販売した書籍の記事版として公開します。より多くの方へ Heroku でサービス開発を成功させていただきたいという思いから、ボクココの固定ページとして無償公開するに至りました。

電子書籍版は BOOTH で販売しております。

なお、本記事は、Heroku 社から認められていない非公式の記事となります。予めご了承ください。


はじめに

Happy Coding!

本記事はWebサービス開発を本気で成功させたいと考えているエンジニア向けに、サービス開発とHerokuの運用に関して記しています。サービス開発を成功させるには、限られた時間の中で注力すべき内容を見極め、サービスの差別化を推し進めることが重要です。ユーザーはなぜ他の多くのサービスではなくて、あなたが作ったサービスを使うのか。その問いに自信を持って答えられるようにしなければなりません。その状況の中で、どのテクノロジーを採用すべきなのかも重要なポイントの1つです。

Herokuが登場する前までは、開発者にとってWebサービスの公開までに大きなハードルがありました。まず専用のサーバーを用意してミドルウェアをインストールし、ネットワーク等の設定を確認する必要があります。試行錯誤の後にようやくサービスを公開できたとしても、運用におけるトラブルやセキュリティの対策等が待ち構えています。そのため、必然とサービスに携わる人を多くしなければ、サービスを成長させることはできませんでした。

Herokuをはじめとした開発者向けのプラットフォームの登場で、開発者はサービスを少人数で作って運用することができるようになりました。サーバーのインフラ管理を全てクラウド側に任せることで、開発者は本当に必要なプログラミングだけに集中することができます。

Herokuは、開発者をサービス開発に集中させてくれるプラットフォームです。使い方はとてもシンプルで簡単に始められます。しかしその反面、使い始めた先にある「何を開発すればいいのか」「どういうことに気をつけてサービス開発すべきか」、「Herokuをどう活かすべきか」といった所までは開発者に委ねられています。本記事は、これらの点をサポートする目的で記しました。

サービスを誰もが公開して運営できる土台が整ったのはつい最近のことです。それではHerokuを使ってサービス開発を始めましょう。

筆者について

筆者は、サービス開発者として5年以上Herokuを利用し続けております。メインで運用しているブラウザ電話システムCallConnectは、執筆時点で350社以上の企業の電話窓口として利用されています。現在もCallConnectはHerokuで動いておりますし、今後もHeroku上でサービスを動かし続ける予定です。特筆すべき点として、CallConnectのサービス開発に携わっているエンジニアは現時点で私一人だけという点です。サービス開発当初から追加のエンジニアを入れることをせずに、350社以上に使われるサービスにまで成長させることができました。これは、Herokuを使わなければ実現することができなかったことです。

Herokuでのサービス開発の経験を通じて、 Herokuに感謝したいという気持ちと、他のHerokuサービス開発事例を増やしていきたいという思いから、Japan Heroku User Groupの運営にも携わっています。Heroku Meetupでの登壇や、他の事例を持たれている方へ登壇を依頼・調整する活動をしております。本記事の執筆も、Herokuコミュニティを通じて執筆する決断に至りました。本記事の最後で、Herokuのコミュニティ活動についても記しています。よろしければHerokuコミュニティの参加をご検討ください。

サービス開発とは別に、個人で「ボクココ」というブログを運営しています。週1〜2回程度の頻度で、サービス開発やインターネットビジネス等に関する記事を公開しています。本記事の内容は、ボクココの記事の中でも、主にHerokuとサービス開発に関連する内容に絞ってお伝えします。

技術選定 - どんな時にHerokuを選ぶべきか

一口にサービス開発と言えども、様々な種類のサービスや開発手法があります。他のサービス開発方法と比較して、どのような時にHerokuを使うと効果を発揮するのかについて記します。

本記事はHerokuについて記していますが、全ての開発プロジェクトでHerokuを使うべきだとまでは記しておりません。それぞれの開発プラットフォームで強みや弱みがありますので、状況に合った開発者向けプラットフォームをお選びください。もしHerokuを使うことが最適なプロジェクトである場合には、次章以降の内容を参考にHerokuで開発を進めていきましょう。

IaaSによる自前構築

Herokuはクラウドサービスの中でもPaaS(Platform as a Service)と呼ばれる部類に位置します。PaaSは、開発者が書いたソースコードをデプロイするだけで、インフラ周りを全て自動で構築してくれるクラウドサービスのことを指します。それとは別に、IaaS(Infrastructure as a Service)と呼ばれるインフラ構築を自分でカスタマイズする方法もあります。IaaSは、AWSやGCP用いて構築するケースが多いです。

IaaSでサービスを構築する方法は、インフラから全て自分で構築するため、最も柔軟性の高いサーバー環境を構築することができます。何か問題が起こったとしても、強いアクセス権限を持つアカウントを所持できるため、自分で原因を特定し修復できる環境を持つことができます。そのため、自社で専門のインフラエンジニアがいるチームの場合、自前でIaaSからサービスを構築することが好まれています。

とりわけ、GPUを使った機械学習などのPaaSでは構築が難しい環境は、どうしてもIaaSから構築する必要があります。そのため、これから作ろうとしているサービスがインフラやソフトウェアの違いを強みにしたい場合には、IaaSを選択することが求められます。

ただし、IaaSを導入したからにはインフラの整備に多くの時間を要することを覚悟する必要があります。IaaSで最初にソフトウェアをインストールし、サービスを作ったら終わりではありません。トラブルが起きたときには自力で隅々までチェックするために、インストールしたソフトウェア全てにおいての専門性が求められます。またソフトウェアは常にアップデートされていくため、各ソフトウェアのアップデート内容を定期的に確認して追従しなければなりません。サービス開発の中で、こうしたインフラ整備に時間をかけるほどの価値があるのか、改めて考えてみてください。多くの場合、独自でインフラを構築する必要のあるケースはほとんどありません。インフラ構築をサービスの強みにする必要がない場合、IaaSから構築することは余計に多くの時間を割くことになってしまうため、お勧めできるものではありません。

Firebase等のFaaSを利用する

サービス開発者の間で、最近Firebaseが注目されています。とりわけFirebaseのうちCloud Functions for Firebaseが2018年4月に正式リリースになったことがFirebaseの勢いに拍車をかけています。Firebase以外にもAWS LambdaとAmazon API Gatewayを利用した「サーバーレス」と呼ばれるサービス開発手法も注目されています。これらの技術は一般的にFaaS(Function as a Service)」と呼ばれています。

FaaSを利用することで、開発者はPaaS同様にサーバーを意識することなく、プログラムを書くことに集中することができます。FaaSを利用することで、従来難しかったオートスケール等の仕組みを意識することなくサービス開発に集中することができます。急激に負荷がかかったとしても、FaaS側で自動でスケールしてリクエストに対応することができます。課金はサーバー起動時間ではなくリクエスト単位となり、費用を安価に抑えることができます。

ではほとんどのWebサービスをHerokuでなくFaaSで構築すれば十分なのかといえば、そうではないと考えています。

FaaSは、SDKとしてプログラムがまとめられています。認証やストレージ、バグ報告や分析などあらゆるサービスがFaaSの中で提供されています。これらを組み合わせてサービスを構築することが、FaaSにおけるベストプラクティスです。例えばFirebaseの提供するサービス一覧はFirebaseトップページにまとめられています。利用できるプログラム言語は限られており、Webフレームワークではなく、FaaSに乗っ取った開発をする必要があります。

そのため、 FaaSが特に力を発揮するのはシンプルなWebサービスを構築するときになります。ランディングページのような一部だけサーバーサイドのプログラムが必要なケースや、複雑なデータベース構成などを必要としないWebサービスで特に力を発揮するでしょう。

IaaS、PaaS、FaaSの順で開発における柔軟性を得られます。柔軟性と運用のトレードオフのなかで、最適な開発プラットフォームを選びましょう。Herokuは、IaaSの持つ柔軟性と、FaaSの持つ運用の手軽さの両方を備えたプラットフォームだと言えます。

Herokuの使いどき

IaaSやFaaSと比較して、Herokuはどのようなケースで力を発揮するのでしょうか。

まず、今まで利用してきたオープンソースのWebフレームワークを手早くデプロイできるため、すぐに開発を始めてサービスを公開したい場合に有効です。RubyのRuby on RailsやPythonのDjango、 Node.jsのExpressなど、あらゆるWebフレームワークのデプロイと運用に対応しています。これらのWebフレームワークは既に多くの情報がWeb上に出回っているため、問題が起きても解決しやすい特徴があります。

また、程よい選択の自由がHerokuにはあります。プログラミング言語やフレームワーク選定の自由の他に、Heroku Addonsが豊富に提供されています。Firebaseのような「基本Firebaseの提供するサービスしか選択ができない」というケースがHerokuにはほとんどありません。とりわけ利用するプラットフォームがサービスの差別化要因の1つとなる場合には、大きな助けとなるでしょう。

サービス開発においてはスピードが特に重要です。スピードを上げるには少数精鋭で意思決定を素早くし、本質的な開発に集中できるような環境が求められます。そんなサービス開発を志す方にとって、 Herokuは大きな助けとなるでしょう。

0→1フェーズでのHeroku

前節で利用するプラットフォームを選定した結果、Herokuが最適だと判断された方向けに、本節では0→1フェーズにおけるサービス開発の勘所を説明します。

どのようなWebサービスで勝負すべきか

Webサービスを作ることのできる土台は整っているものの、どのようなアイデアで勝負すればいいのかわからないという方を多く見かけます。サービスのアイデアを考えてみると、既に似たようなものが存在していたり、利用用途が明確でなく自信が持てないことが原因のようです。 「サービスや事業を始める前に100個アイデアを考えろ」とは事業開発時によく言われます。しかし、以下に記す条件を満たすことができれば、サービスの設計や開発を始める価値があると言えます。

1. そのサービスがあれば、あなたは確実に利用するか

これから作ろうとするサービスは、あなた自身が必要とするサービスであることが1つ目の条件です。他の類似サービスを使うのではなく、自分でサービスを作らなければならない理由が必要になります。これは、サービス開発におけるターゲット選定のプロセスです。なぜサービス開発でターゲット設定が重要なのか、理由は2つあります。

まず1つ目に、品質の高いサービス開発を続ける上で重要であるためです。サービス開発における大きなリスクのひとつとして、開発者のサービスに対する情熱が薄れて開発が止まるという点があります。サービスを公開してからしばらくの間、顧客が全く現れないということはよくあります。もし「顧客が誰もいなくても少なくとも自分は使う」サービスを作れば、サービス公開後に顧客が誰もいなくても開発にかけた時間が無駄になることはありません。サービスの利用と改善を続けていく中で、いつか自分たちと同じ課題を抱えた顧客が使い始めてくれるようになっていけば良いだけとなります。反対に自分が欲しいと思わないサービスでは、誰も使われない期間を耐えることができずにサービスを閉じる選択をしてしまうことになります。筆者自身、今まで多くのサービスのアイデアを考えてHerokuで動かしてきましたが、今も残り続けているサービスは結局のところ自分でも使うサービスだけになっています。

2つ目に、サービスの利用用途を明確にできる点があります。最初にローンチするサービスは、ユーザーのターゲットが狭ければ狭いほど良いサービスになる確率が上がります。一部の顧客の課題を完全に解決するサービスができれば、その顧客はサービスのファンになってくれます。そしてその顧客の熱狂が、次なるファンを獲得することに繋がっていきます。用途が明確でない、誰もが「あったらいいね」と思う程度のサービスだと、熱狂するファンを獲得することはできません。皆さんは「あったらいいね」くらいのサービスがあったとして、わざわざ今まで使っていたものを切り替えてまで新しいサービスを使うでしょうか。ほとんどの場合、手間がかかるなどの理由で使い始めることすらしないでしょう。

サービスのターゲット設定は、サービス開発の成功に大きく左右されます。この0→1フェーズで本当に実現したいサービスは何なのかを考えてみてください。その先のフェーズではサービスのアイデアの根本を変えることはできないため、慎重かつ大胆に検討しましょう。

2. リリース直後から使えるサービスか

例えば、メディアやECサイトのような大量のコンテンツや商品を用意してからでないとサービスの価値が上がらないものであったり、シェアリングエコノミーやマッチングアプリといったユーザーが増えないと価値の出づらいサービスがあります。これらのサービスは、ローンチ後にサービス開発とは別の努力が必要になります。例えばライターさんを雇ったり、ダミーのユーザーや商品を作ったり、広告に大きな投資をする努力で解決するなどが挙げられます。もちろんHerokuでこのようなコンテンツありきなサービスを作ることはできます。多くの人員と多くのユーザーとを確保できる場合には検討しても良いかもしれません。ただし、こうしたサービスはシステムの負荷やニーズの多様化によって最終的に多くの人員や機能が必要になってきます。そのため最初にHerokuを使ったとしても、成長するにつれて次第にIaaSで構築するケースが多く見受けられます。

リリース直後から使えるサービスの場合、将来的にシステムの負荷や多くの機能が求められることが少ないという利点があります。具体的にはBtoCにおけるツール系のサービスであったり、BtoBのSaaSなど単一の問題を解決するサービスなどが挙げられます。このようなサービスは多くの開発が不要であるのと高負荷になる恐れが少ないため、Herokuを効果的に利用することができます。

HerokuはHeroとHaiku(俳句)が組み合わされたのが語源であると言われています。俳句と同じようにHerokuでシンプルで研ぎ澄まされたサービスを開発することで、HEROになることができるはずです。

3. 技術的な強みを活かせるか

例えばHTML5やTensorFlowのような機械学習のフレームワーク、ブロックチェインなどの新しいカテゴリが挙げられます。新しい技術やトレンドを駆使して顧客に最適な課題解決を提供できるかを検討してみましょう。その技術が出る前ではどうしても解決できなかった課題を見つけることが重要です。 もちろん既存技術を使って新しいサービスを作ることはできますが、似たものが既に存在していたり閉じられたりするケースが多くあります。既存技術で作られたサービスは、他でよくあるようなサービスとなってしまって注目を浴びづらいですし、顧客にとっても既存のサービスで十分である場合が多くなってしまいます。

Webサーバーを立ち上げて運用することは全てのWebサービスで必要なことですが、Herokuは開発者の誰もが同じようにかける時間を最小限に留めさせてくれます。自分たちの強みにしない技術はHerokuに任せてしまい、自分たちの強みにする技術に時間を割くようにしましょう。それが最終的に他サービスとの差別化にも繋がってきます。

仮説検証を始めよう

前述の章で勝負したいWebサービスのアイデアの条件を挙げましたが、最初に決めたサービスのアイデアは今後変わること前提で進めていくべきです。最初の仮説で作ったサービスを検証してみると、実際には他の課題が見えてきたというケースはよくあります。そこで事業転換(ピボット)を決断したら、サービスの根本から変えていくことが求められます。ここで求められるサービス開発の柔軟性は、大企業や大人数の組織では実現しづらい点です。しかし、より高確率でサービスを成功させるには、アイデアを柔軟に変えていくことが必要不可欠であると言えます。

例えば今では誰もが使うようになったInstagramは、サービス公開当初「現在地や写真を共有できるソーシャルチェックインアプリ」として公開されていました。しかしユーザーの利用動向を調べていく中で、ユーザーが最も必要としている写真機能だけに特化する決断(ピボット)をしました。その結果、現在の「写真の撮影と共有に特化したソーシャルネットワーキングアプリ」となって大成功を収めました。

このようにサービス開発における仮説検証は、非常に重要な役割を持っています。

Herokuでプロトタイプができあがったら、まずはそれをターゲットとなる人に使ってもらいましょう。自分自身がターゲットであっても、実際にWebページやアプリとして利用してみると、思っていたのと違うことになる場合はよくあります。そこで、単一の機能で完璧に課題を解決するサービスを作れなかった場合、すぐにHerokuアプリを壊して作り直しましょう。自前のIaaSで構築した場合、作り直しは困難なものですが、Herokuであれば簡単にできます。

ユーザーにとって、サービスを使うかどうかは印象的な1つか2つの機能で判断すると言われています。もしその象徴的な機能が便利でなかった場合、サービスの利用を継続しないことになります。だからこそ、中途半端な機能を増やしていくよりも、最初の時点で顧客に完璧にフィットする1つの機能を作り上げることに集中しましょう。そして、その単一の象徴的な機能を磨き続けることによって、他のサービスと圧倒的な差別化ができるようになり、サービスのファンを獲得することができるようになります。

利用する技術を選定しよう

最初の仮説検証の段階では、サービス開発を始める必要すらないかもしれません。絵を描いたりやプロトタイプツールを利用すれば、より素早い仮説検証ができます。やがてサービスの方向性が定まってきたら実際に作り始めていくことになります。

まずは技術の選定から入ることになるでしょう。Herokuでは様々なプログラミング言語やフレームワークをサポートしています。本記事で特定の技術を指定することはしませんが、大きな理由がなければ提供するHeroku Addonsとの相性がいいRuby, Node.js, Pythonなど公式のHeroku Buildpacksを利用することをお勧めします。これらのプログラミング言語ではHeroku Addons側で専用のライブラリやドキュメントが用意されていることがあります。もしHerokuでマイナーな言語やフレームワークを選定すると、せっかくHerokuで簡単に構築できるようになったのに、別で特別な実装が必要になってしまいます。それでは本末転倒ですので、本当に強みにしたい技術以外はHeroku標準の技術を使うようにしましょう。

筆者は以下のようなプログラミング言語やフレームワーク、Addonsを利用しています。全て無料から始めることができますので、何のAddonsを利用すれば良いのかわからない方は参考にしてみてください。

  • Ruby / Ruby on Rails
  • Buildpack: heroku/Ruby
  • Heroku Standard 1x Dyno
  • Heroku Postgres
  • Heroku Redis
  • Papertrail(ログ管理)
  • Process Scheduler(定期処理Cron)
  • NewRelic(メトリクス管理)
  • SendGrid(メール送信)

最初から利用する技術やソースコードにこだわりすぎる必要はありません。0→1フェーズでは前述の通りプログラムを作ったり壊したりを繰り返すため、検証が終わるまではスピード重視で開発していきましょう。

1→10フェーズでのHeroku

0→1フェーズでサービスの仮説検証が終わり、顧客の要望を満たせるサービスを提供できるようになったら、顧客がサービスを使い続けてくれるようにする必要があります。壊しては作り直しの0→1フェーズと、より安定したサービス運用をするための1→10フェーズでは、やらなければならないことが全く異なります。

Herokuでサービス開発を経験してきた方は、新しいものを作る0→1フェーズを好む傾向があります。しかし、この1→10フェーズを正しく実施しない限りサービス開発を成功させることはできません。本節では1→10フェーズでのHeroku活用方法についてご紹介します。

安定したHeroku環境を用意しよう

サービスを作り始める段階では、ほぼ全てのHerokuサービスを無料で利用・構築することができます。やがてユーザーを抱えるようになってきたら、安定した運用のためにHerokuの環境を整備する必要があります。本節では一般的なHerokuの安定稼働させるための方法について記します。

Production Check

安定したHeroku環境になっているかどうかを確認するために、Production checkを利用しましょう。Herokuのアプリページ右上 "More"より、"Production check"を実行します。これだけで、対象アプリがHerokuの推奨する本番環境になっているかをチェックすることができます。このProduction checkは定期的に更新されますので、気軽にチェックしてみてください。執筆時点でのチェック項目は以下の通りです。

f:id:cevid_cpp:20181028143510p:plain

  • Heroku-18 Stack Heroku Stackと呼ばれる、Herokuが管理するOSのタイプです。Heroku-18はUbuntu 18.04をベースに構築されており、OSの発展と共に定期的にHeroku Stackは更新されます。
  • Production Dynos 本番環境用のDynoが利用されているかどうかのチェックです。Dynoにはfree/hobby/standard/performanceの4タイプがありますが、standard以上であることが求められます。
  • Dyno Redundancy Dynoが複数立てられているかのチェックです。1つのDynoのみでサービスを運用すると、そのDynoが停止・再起動した時点でサービスが止まってしまいます。必ず2つ以上のDynoが起動し続けていることが、Dyno Redundancyに求められる条件となります。
  • Production Postgres Database 本番環境のHeroku Postgresが利用されているかの確認です。Heroku Postgresには、Hobby/Standard/Premium/Private/Shieldをベースに、それぞれで容量の違いなどでプランが分けられています。Standard以上のプラン利用でチェックが通ります。
  • Postgres High Availability 可用性の高いPostgresが利用されているかのチェックです。StandardではこのHigh Availabilityの項目がないため、Premium以上の契約が必要となります。High AvailabilityなHeroku Postgresを利用することで、Heroku Postgresに障害が発生しても自動でフェイルオーバーする仕組みを導入できます。
  • App monitoring アプリのモニタリングAddonsがインストールされているかの確認です。NewRelicやLibratoなどのAddonsがインストールされていれば通ります。
  • Log monitoring ログのモニタリングAddonsがインストールされているかの確認です。PapertrailなどのAddonsがインストールされていることが条件です。
  • Custom Maintenance Pages 独自のメンテナンスページが用意されているかの確認です。アプリの環境変数にMAINTENANCE_PAGE_URLがあり、その値が適切なURLになっていることが必要です。
  • Heroku SSL Heroku SSLでHTTPSに対応したサービスであるかの確認です。Heroku SSLはLet's Encryptに対応しており、無料で簡単にSSL化することができます。もちろん、Let's Encrypt以外にご自身で購入されたSSLを適用することもできます。

1→10フェーズでも、ユーザー数が少なかったりしてサーバー停止が大きなリスクとならない場合には、無理して全てのCheckを満たす必要はないかもしれません。実際Hobby Dynoでサービス運用をしても、一日1回の再起動以外でサーバー停止することはほとんどありません。どうしてもサービスが止まるとまずい状況になってきた段階で、それぞれのチェック項目を満たすかべきどうかを判断してみてください。

Dyno管理の最適化

HerokuにはDynoと呼ばれるアプリのコンテナの種類と数によって機能や金額が異なります。現時点でDynoには以下の種類が提供されています。

  • free: Sleepあり、RAM 512MB、1x CPU Share
  • hobby Sleepなし
  • standard-1xプロフェッショナル機能(スケールやメトリクス等)
  • standard-2x RAM 1024MB、2x CPU Share
  • performance-m RAM 2.5GB、100% CPU Share、専用サーバー
  • performance-l RAM 14GB

Dynoの種類はHerokuアプリで必要になるメモリや、CPUの利用状況に応じて選択する必要があります。

Dynoの数に関しては、まず複数Dynoを起動するにはstandard Dyno以上の利用が必須となります。その上で最適なDynoの数は、サービス運用をしながら探っていきましょう。常に多くのDynoを起動し続けるとその分費用がかかるため、適切なタイミングで適切なDyno数が起動されるように調整します。ここで注意しなければならないのが、Herokuの仕様としてDynoは任意のタイミングで一日1回の頻度で再起動をするという点です。再起動の間はリクエストを受け付けることができなくなってしまうため、最低2つのDynoを起動し続けることが前提となります。

Herokuなら深夜の時間は2 Dynoだけにしておき、リクエストが来る日中の時間帯だけ4 Dynoの構成にするなどの設定が簡単にできます。この場合、時間に応じてDyno数を指定できるHeroku Addons(Process Scheduler)を利用します。もし時間によらず意図しない大量リクエストが来ることが想定されるサービスの場合、オートスケール系のHeroku Addons(Adapt Scale等)の利用を検討してみましょう。このようなDyno数の運用によって、効率的なサーバー管理とHerokuにかかる費用を節約することができます。

各Addonsのプランの確認

HerokuのDynoやPostgres以外にも、Addonsを利用している場合には適切なプランを選択する必要があります。サービスの成長につれて必要になる機能やスペックがプランとしてAddons毎に提供されています。定期的に各Addonsの利用状況を確認し、アップグレードが必要かどうかを確認しましょう。多くのAddonsはアップグレードが必要になりそうなタイミングでメール通知を送ってくれるため、そのタイミングで検討するのも良いでしょう。Addonsのプランが上がれば、よりハイスペックで便利な機能が使えるようになったり、より丁寧なサポートが受けられるようになります。

似たようなHerokuのAddonsでも、プランによって金額や機能が大きく異なります。サービスの成長につれて他のAddonsの方が適切になる場合もあるため、現在のAddonsのプラン以外にも定期的に他のAddonsをチェックするようにしましょう。

コラム: HerokuからIaaSに移ることの選択

「IaaSで自前構築するよりもHerokuは値段が高い」という意見を聞くことがあります。しかし、それは当然のことだと言えます。なぜならIaaSを利用する場合には、その分インフラの管理が必要になり、そのためのインフラの学習や人員が必要になります。Herokuを使えばインフラの管理を取り除き、それらを替わりに管理してくれます。Herokuで追加される費用が、IaaSで追加で必要になる金額や時間とどちらが最終的な目的を達成できるか、改めて検討してみてください。

また、「HerokuはUSにサーバーがあるため、レイテンシ(通信の遅延)の問題があるからIaaSに移った」という事例もよく聞きます。実際にHerokuでWebサービスを運営している筆者の経験では、レイテンシによるレスポンス速度が問題になったことは一度もありません。通信速度が遅い原因は、ほとんどはアプリ側の実装によるものです。

「サービスが成長するにつれて、機能が複雑になりHerokuだけで管理することが難しくなった」「自社でIaaSのエンジニアを採用できたので、よりサービスに最適なインフラ環境を整えたい」といったタイミングで自前のIaaSで運用することへ切り替える方が多いようです。この場合でも、最近のHerokuではHeroku Private Spacesによって大規模サービスの構築や日本リージョンに対応してきています。また、Heroku Buildpacksによってアプリ構築の柔軟性も強化されています。そのため、サービスが成長したとしてもIaaSに移るべきかどうかを改めて考えてみて欲しいところです。

Dataclipsで最新情報やサマリを取得しよう

Heroku Postgresを利用すると、Heroku Dataclipsという便利な機能を利用することができます。1→10フェーズにおけるよくある課題と、それをDataclipsでどう解決するかについて説明します。

Dataclipsとは

Heroku Dataclipsは、Heroku PostgresへのSQLコマンドを保存し、必要なタイミングでWeb上からデータを閲覧、利用することのできるサービスです。

f:id:cevid_cpp:20181028143524p:plain

Dataclipsのページ内でデータを閲覧するだけでなく、CSVやJSON・XLS形式で出力することにも対応しています。これによって例えばExcelでデータを表示してグラフ化するのに利用したり、JSON形式でアクセスすることでサービス開発のMockとして活用するなど、URL経由で便利にデータを活用することができます。

URLは予測困難なものであるため、URLを知られない限り第三者からアクセスされる心配はありません。Heroku PostgresのStandardプラン以上をご利用の場合は、セキュリティ強化のために指定したHerokuアカウントでしか閲覧できないようにすることもできます。

シンプルながら強力な機能を提供しているDataclipsですが、具体的にサービス運用の中でどう活用するのかについて説明していきます。

Dataclipsの活用

管理ページの替わりとして

サービス開発をしていると、利用者が使う機能の他にサービス運営側のための管理ページが必要になることがよくあります。例えば、ユーザーから問い合わせが来た時に、そのユーザーがどのような状態なのかを確認できる管理ページがあると便利でしょう。わざわざユーザーの状況を確認するために、サポート担当者がエンジニアへデータベースから確認してもらう作業をしてもらうようでは、それだけで多くの時間が取られてしまいます。サービスの利用者や運営側の人数が多くなればなるほど、こうした管理ページでのデータ取得が重要になってきます。

管理ページを作るために、別のアプリをゼロから構築する場合があります。運営者だけが見られるページにしなければならないため、認証機能の実装を始めとしてデータの取得・表示の実装とサーバー運用が必要になります。しかし、このような管理ページの開発・運用にかける時間は、運営のためでありユーザーのためではありません。サービス開発者としては、ユーザーと直接関係のある部分だけを開発していきたいものです。

そこで、Dataclipsの出番です。Dataclipsでサポート担当者や営業担当者が必要なデータをいつでも取り出せるようなSQLを用意しておきましょう。担当者はDataclipsから欲しい情報を参照できるようにすれば、エンジニアの開発工数を減らすことができます。

もちろん、Dataclipsでデータ取得をするだけでは難しいケースもあります。Dataclipsで欲しいデータに特定のIDが必要になると、Dataclips内で都度SQLを編集しなければならなくなります。そのためDataclipsで解決できるものはDataclipsを使い、それ以外は管理ページを用意するといった使い分けを意識しましょう。Dataclipsでは全体の顧客動向の分析や最新データの取得などで特に力を発揮します。

カスタマーサクセスの基盤として

顧客の利用動向を分析して、顧客の成功を支援するカスタマーサクセスが注目されています。このカスタマーサクセスは、ユーザーが少ないうちは会ってフィードバックを直接得たり利用方法を観察する方法もありますが、ユーザーが増えていくにつれてデータを元にした分析ができるようになる必要があります。

まずは収益管理や全体の顧客の利用動向をSQLで取ってこれるようにしたいところです。こうしたデータはビジネスにおいて非常に重要な情報となるため、1→10フェーズの早いうちに用意しておきたいものです。データを元に最適な顧客像を定義してマーケティングや営業に活かせば、正しくサービスを成長させることができます。

ゆくゆくは本格的なカスタマーサクセスのための専用のツールを利用することはあるかもしれませんが、1→10フェーズではDataclipsを便利に活用できるでしょう。

Dataclipsで知っておくべきSQL

サービス開発をメインで行うエンジニアの方は、分析・集計用のSQLを利用する頻度は多くないかもしれません。Dataclipsはあくまで1つのSQL文を実行する作りであるため、例えばプログラムで順番にデータを取り出してデータ表示をしたりすることはできません。しかし、最近のSQLでは、まるでプログラムを実行しているかのように柔軟性の高いSQLを書くことができるようになっています。もしアプリを作るSQL以外でSQLを触れたことがない方は、以下のようなキーワードで調べてみてください。より便利にDataclipsが利用できるようになることでしょう。

  • COALESCE関数
  • CASE式
  • ウィンドウ関数
  • 共通テーブル式(Common Table Expression)

通知の環境を整備しよう

サービスをリリースして運用が始まると、サービス開発以外に様々なタスクが入ってきます。いかに運用タスクの属人性を排除してサービス開発に集中できるかが、今後のサービスの成長に深く関わってきます。

運用タスクの中でも、サーバーの状態やユーザーの利用動向などの定期的なチェックを無くしていくことが重要です。なぜ定期的なチェックを省くべきかというと、結果がどうであれチェックするための時間が定期的に必ず必要になってきてしまうためです。定期的にチェックするのではなく、本当に行動が必要になったタイミングで適切な通知を送るようにしましょう。本節では、Herokuにおける通知環境の構築について記します。

Heroku Metricsのアラート通知

Heroku Metrics内で、サーバーが異常な状態になった際にメール通知を送る機能があります。日頃からそもそも障害が起きないようにする努力が必要ですが、まずは問題が発生した時の通知を設定しておきましょう。

Heroku Metricsのページ右上のConfigure Alertsをクリックすると、アラートを出す条件と、どこにアラートを送るのかを設定することができます。

f:id:cevid_cpp:20181028143540p:plain

Monitor Response Times 全体のリクエストのうち、最小から数えて95%のレスポンス速度が指定秒数以上になった時に通知を送ります。

Monitor Failed Requests 全体のリクエストのうち、指定した割合以上に失敗リクエストが発生した際に通知を送ります。

どちらも深刻な問題が発生している状態になっているため、このアラートメールがHerokuから来た時は必ずログなどを確認するようにしましょう。すぐに解決ができない状態の場合には、heroku releasesでリリース履歴を確認し、heroku releases:rollback {バージョン}でロールバックを実行することができます。プログラムでの実装で解決が難しい場合は、サービスの仕様を変えるなども検討しましょう。

エラー通知

サービス開発をしている中で、アプリ側でエラーが発生することは避けられないことです。そのエラーを早く直して平常運用させることができれば、ユーザーからの信頼を得ることができます。エラーが起き続けたり、いつまでも直らないようなサービスでは、ユーザーからすぐに見放されてしまうことでしょう。そのため、アプリでエラーが発生したら迅速に通知を得て対応する仕組みを用意することが必要です。

エラー通知にもログ管理AddonsであるPapertrailを活用することができます。アプリログでエラーが発生した際に "Error" の文字を出すように指定し、PapertrailでErrorのログが出たらSlackに通知すれば完了です。Slackに短期間で多くの通知が飛べば、それだけすぐに対応しなければならないということで優先度を高められる利点があります。ただし、この方法では同じエラーが出る度にSlackへ通知が飛ぶため、エラーの発生が多すぎると運用が難しいかもしれません。

バグの発生が多く、それらを効果的に管理をしたい場合には、BugsnagやSentryといったバグ管理のHeroku Addonsの利用を検討しましょう。

デプロイ通知

Herokuにデプロイが完了したら、通知が送られるようにしておきましょう。Herokuのデプロイでは完了後に必ず再起動が走るため、一時的にアクセスできない状態が発生します。通知がないと、開発者以外はエラーなのかサーバー不調なのかデプロイが原因なのかを判別することができません。

また、そのデプロイによって何が変わったのかを他のメンバーに知らせることも重要です。これはコミットログを通知内容に含めることで対応ができます。わざわざ他のメンバーに今回のデプロイの変更点を説明するようでは、余計な時間がかかってしまうことになります。

HerokuのGitデプロイ時に通知を送ることは、デフォルトで提供されていません。Heroku Release Phaseを利用してデプロイ後のスクリプトを実行したり、CircleCIやBitbucket PipelineのようなCI環境を整備することが求められます。最初の一手間で、以降の多くの時間を節約することができます。

サービス運用で必要な通知

アラートやデプロイ通知以外にも、ユーザーが特定の行動をした際に通知を送ることで迅速な対応ができるようになります。会員登録やプラン登録、退会、サービス内で問い合わせが来た時などが挙げられます。これらも定期的に管理ページへ確認しにいくのではなく、通知によって気づくことのできる仕組みを用意しましょう。

先述したログ管理AddonsのPapertrailを利用すれば、特定の文字にマッチするログが出たらSlack等へ通知を送るように設定できます。

自前のIaaSで同様の通知を実現するのは、環境を用意するだけでも時間がかかります。Herokuを最大限活用してサービス運用を減らし、本質のサービス開発に集中しましょう。

パフォーマンスチューニングを行おう

本記事の後半でパフォーマンスチューニングを取り上げたのは大きな理由があります。なぜなら、0→1フェーズの段階から効率的なシステムを目指しすぎるのは、結果として時間の無駄になる可能性があるためです。エンジニアであれば理想のシステムを最初から作って運用したいと一度は思うことでしょう。しかし、理想のシステムを追い求めすぎると、その分多くの時間をかけてしまいます。本質のサービス開発に時間を割くことができずに成長が止まり、サービスを閉じる結果となることが起こりえます。「早すぎる最適化は諸悪の根源」とドナルド・クヌース氏が述べているように、サービスの成長段階では集中すべきことを見極めることが重要です。

最適化とは反対に、開発初期のフェーズではソースコードのパフォーマンスを気にせずにプログラムを書くことがあります。開発初期のフェーズではどんなに効率の悪い処理を書いても、そもそもデータやリクエスト数が少ないため問題になることはありません。そのため、0→1フェーズが終わってサービスを運営し続けられる保証を得られた時点で、パフォーマンスチューニングに取り組んでいきましょう。後からでもパフォーマンスを改善していくことは十分に可能です。少しずつできるところから進めていきましょう。

ソースコードの改善

パフォーマンス改善のために、既存のソースコードを処理効率の高いものへ修正していく必要があります。本節では具体的にどのようなことを意識してプログラム改善をしていくべきかを列挙します。

ソースコードを定期的にメンテナンスする

0→1フェーズで急いで修正や削除を繰り返していると、ソースコードの中で無駄な処理が残ってしまうことがあります。複数人でサービス開発していると、他人の書いたコードを理解して修正することをためらい、無駄な処理を残して妥協することもあるかもしれません。こうした過去のソースコードの負債を定期的に返済することが求められます。その改善がやがて次なる開発のスピード向上や、安定したサービス運用に繋がってきます。

なぜ動いているのかよくわからないコードが散乱している場合、その部分のソースコードを追加・修正するには多くの時間を要します。このフェーズではテストコードも丁寧に書いて、今後のサービス開発をより加速させるための準備をしたいところです。ソースコードをメンテナンスしやすい状態に保ちましょう。

プログラム言語やフレームワーク、ライブラリを最新に保つ

ソースコードは常に進化を続けます。とりわけプログラム言語は、定期的にメモリ処理やパフォーマンス改善のアップデートが行われます。実際に、プログラム言語のバージョンを上げただけでメモリ効率が改善されることが多くあります。同様に、フレームワークやライブラリもオープンソースコミュニティを通じて定期的に改善されていきます。そのため、利用するもの全てを最新に保ち続ける努力が必要です。

ソースコードをアップデートするときに、テストコードは特に役立ちます。何もテストコードがないと、ソースコードの1つ一つを手動で実行しながら確認する時間が必要になってしまいます。テストの自動化を整備することで品質を安定させながら開発速度を上げることができます。

起動メモリ(ライブラリロード)を減らす

Herokuを使う利点の1つは、サードパーティ製のライブラリやオープンソースを手軽に適用できる点が挙げられます。RubyならGem、Pythonならpipといったパッケージ管理ツールを手軽に利用できます。 サービス初期の段階では様々なライブラリを入れてみて、適用できるかを試行錯誤することでしょう。うまく活用することができれば、開発の時間を一気に短縮することができます。しかし、あまりにも多くのライブラリを取り込むと、起動時に多くのメモリが必要になってしまいます。サーバーを立ち上げた時点でメモリが80%以上を超えていると、やがてメモリが100%を超える恐れがあります。

もちろんサービスにおいてどうしても使わなければならないライブラリであれば使うべきですが、使う必要のないライブラリがあれば削除してコンパクトに保つ意識を持ちましょう。たくさんのライブラリがあれば、その分多くのライブラリのバージョンアップデートに追従しなければなりませんし、ライブラリの依存関係で問題が出てくるケースも出てきます。できる限りライブラリの利用はスリムを意識することが重要です。

大量のレコードを取得するようなUIを作らない

一覧ページを実装する際、必要とするデータだけを取得するように実装しましょう。例えば、SELECT カラム名構文で取得する、LIMITで必要なデータのみを取得するなどが挙げられます。これらの最適化によって大量データ取得時のメモリ利用を大きく抑えることができます。また、適切にテーブルへインデックスを張ることも、データが増えるにつれて重要になってきます。

これはデータが少ないうちは問題が起きないため、見落とすことが多い点です。しかし、データが増えるにつれて問題が顕著に現れてきます。1→10フェーズで適切な実装をしてデータベースの負荷を下げることを心がけましょう。

ファイルアップロードはサーバー介さずストレージへ直接あげる

ファイルアップロードは、ファイル容量に応じてサーバーのメモリを急上昇させる原因となりやすい機能の1つです。

この対策として、ダイレクトアップロードと呼ばれるHerokuを介さないアップロード方法があります。フロントエンドのJavaScriptやスマホアプリを通じて、Amazon S3などのファイルストレージへ直接アップロードすることで実現できます。画像のリサイズやトリミングなど、従来はサーバーサイドでしかできなかったような処理は、今ではHTML5を使って柔軟に実装できるようになりました。どうしてもサーバーサイドにファイルを持っていかなければならない理由がなければ、ダイレクトアップロードによる実装を検討してください。

サーバーを経由してアップロードしたい場合でも、ファイルの容量制限は必ず実装するようにしましょう。ユーザーが何MBのファイルをアップロードするか予測できません。1回でも数GBクラスのファイルをアップロードされると、メモリが急上昇してしまう恐れがあります。

時間のかかる処理はWorker Dyno, Scheduler, AWS Lambda等へ移す

例えば外部のAPIと頻繁にやりとりする処理や、大量のメモリが必要となる一連の手続きがある場合に、処理が重すぎてメモリが急上昇することがあります。

こうした処理は、専用のWorker Dynoに任せることが一般的な対応方法となります。別のプロセスで重い処理を実行させることで、Web Dynoの処理を効率化することができます。ただし、Worker Dynoにも同様の課金が発生するため、処理量に応じて日頃から適切なWorker Dyno数に最適化していくことが求められます。

その他の方法として、Heroku Schedulerを用いて定期的な処理として実行させることもできます。基本的に常に立ち上げる必要のあるWorker Dynoと違って、特定の時間でのみ起動するDynoであるため、利用料金はある程度節約できます。ただ実行の間隔が一番短くても10分であるため、実行の遅延が許される場合に利用を検討しましょう。

最近ではAWS LambdaやGoogle Cloud Functionsのような、ソースコードをデプロイするだけで処理が実行されるようなサービス(FaaS)が登場してきています。FaaSに処理を依頼するために一度Heroku側からHTTPリクエストを送る必要がありますが、それ以降で時間のかかる処理をFaaSに任せることができます。FaaSの実行は料金を安価に抑えることができるため、利用を検討する価値があります。

Herokuメトリクスを観察しよう

Heroku Dynoのうち、Hobby Dyno以上を選択するとHerokuのダッシュボード内でメトリクスを閲覧することができます。Herokuによるサービス運営が初めてでも、メトリクスの基本的なことを理解することが重要です。メトリクスを定期的にチェックすることで、問題を事前に回避することができます。

f:id:cevid_cpp:20181028143600p:plain

以下に各項目についての説明と、注視すべき点についてご紹介します。

Events

Herokuのイベントには以下のような種類があります。

  1. Errors: Heroku内で起きたエラーが赤色、警告がオレンジ、情報がグレーで表示されます。
  2. Platform Status Events: インシデントが黄色、メンテナンスがグレーで表示されます。これら情報はHeroku Status でも定期的にチェックすることができます。
  3. Configuration Variable Change Events: 環境変数が更新された時に表示されます。
  4. Deployment Events and Markers: Herokuにアプリをデプロイした時に表示されます。
  5. Scaling Events: Dyno数を増加、減少させたり、 Dynoの種類を変更した際に表示されます。
  6. Restart Events: Dynoは1日1回、自動で再起動が起こります。それ以外に手動で再起動した場合などを含め、Dynoが再起動したタイミングで表示されます。

この中で特に注意すべき点は、Errorsの項目です。アプリで短期間のうちに大量のエラーが起きている場合、たくさんの赤色タグでEventが埋め尽くされます。サービスを正しく提供できていない状態ですので、原因を見つけて早急に対応することが求められます。

エラーが起きた際、一般的には以下のような情報が課題解決の参考になります。

  • いつから発生したか
  • エラーはどの頻度で発生しているか
  • エラー内容は何か (ログから読み取ります)
  • 特定のDynoのみか、全てのDynoで発生しているか

特定のDynoのみで問題が発生している場合、対象のDynoを再起動すれば解決することが多いです。この際、1つのDynoのみでサービスを運用していると、そのDynoの調子が悪くなった時から再起動するまでの間、サービス停止状態になってしまいます。このことからも、Dynoは最低2つは常時起動しておくことが望ましいと言えます。

Herokuへデプロイしていないにも関わらず突然問題が発生した場合、利用しているHeroku Addonsや、その他の連携サービスでトラブルが発生している可能性があります。日頃から連携サービスの健康状態をチェックするようにしましょう。最近ではHeroku Statusのように、サービスの健康状態をオープンに公開しているサービスが多くあります。この情報を購読して、問題が起きたらメールやSlackへ通知できるようにしておきましょう。

リリース直後からエラーが止まらない場合には、リリースした内容が問題であることがすぐにわかるはずです。日頃からこのような問題が起きないよう事前にテストを徹底すべきですが、万が一問題が起きたら迅速に対応できるようにトラブル時の体制を整えておきましょう。

Memory Usage

サーバーのメモリがどのくらい消費されているのかを時系列で表示します。定期的にメモリが100%を超えないようチェックしましょう。もし100%を超えてしまった場合、スワップ領域と呼ばれるメモリ領域にメモリを退避するようになり、レスポンスが極端に遅くなってしまいます。メモリが100%を超えると、R14(Memory Quota Exceeded)エラーが発生し、Eventsにたくさんの赤色タグで埋め尽くされるようになります。

メモリは低ければ低いほうが望ましいですが、どうしてもメモリを高くしないとサービスが運営できない場合には、Dynoの種類をアップグレードすることで高メモリのサーバーで運営することができます。この方法はあくまで最後の手段とし、まずはソースコードで改善できないか入念に検討しましょう。

Response Time

Herokuでリクエストを受けてから、レスポンスを返すまでにかかった時間です。全体の平均や、遅いレスポンスの50%や10%での平均などが表示されます。Herokuはデフォルトで30秒以上かかったらH12 request timeoutを出してエラーを返します。

レスポンス速度は早い方が良いに越したことはありません。Response Timeを定期的にチェックして遅い処理が実行されていないかを確認しましょう。具体的にどのリクエストで遅延が発生しているのかは、別途NewRelic等のメトリクスツールを利用する必要があります。

Dyno Load

指定期間の間でどのくらいのDyno Loadが走ったのかを表示します。この値が高ければ高いほど、多くの処理を必要としたことになります。リクエストが多ければその分多くの処理が必要になります。それ以外にも特定の重い処理が走った際にも、この値が上昇します。

Throughput

1秒間のリクエスト数(rps: Request Per Second)に対して、どのレスポンスを返したかの集計です。2XX(成功)、3XX(リダイレクト等)、5XX(サーバーエラー等)で分けられています。5XXが発生してメモリが急上昇するなど、それぞれのメトリクスの因果関係を読み解きながら課題を解決していくことが求められます。

モニタリングのHeroku Addonsを導入しよう

Herokuメトリクスは、Herokuアプリの現状を知る上で有用なものです。しかし、何か問題が発生した際に具体的にどの部分で問題が発生したのかまでを把握することはできません。それらは別途New RelicやLibratoのようなモニタリングAddonsを導入する必要があります。各URLでの処理に応じたメモリ上昇率やレスポンス速度、リクエスト数などを把握できるようにしましょう。それらの情報を元に、問題となっている箇所を特定して修正していくことが求められます。

モニタリング系のAddonsを最初に入れて放置してしまうケースがありますが、油断は禁物です。プログラムを修正してHerokuへデプロイした後、必ずログやモニタリングAddonsを注視して問題が起きてないかを確認する習慣をつけましょう。

情報発信を意識しよう

サービスを作って公開すれば、ユーザーが勝手に使い始めてくれるものではありません。そのため1→10フェーズではサービス開発や運用だけでなく、情報発信が重要です。使ってほしい方へリーチする情報発信をして、サービスを知っていただけるように工夫する必要があります。

とりわけ、利用してほしいユーザーに響くコンテンツを発信していくことが求められます。例えば技術者が使うサービスでは、最新の技術についてブログで情報発信をしたり、仕事効率化のサービスであれば働き方のメディアなどを運営するなどが考えられます。また、サービスにおいて象徴的なユーザーがいれば、その方へインタビューするのも効果的な施策の1つです。エンジニアであれば発信が不要かといえばそうではありません。サービス利用のきっかけはサービスとあまり関係のない技術的なブログの記事を読んでからだったということもよくあります。また、将来的にエンジニアを採用したいという時にも、技術情報を発信すれば最適な仲間を集めやすくなります。

情報発信には以下のように多くの方法があります。

  • ブログやメディアの運営
  • メルマガの配信
  • YouTubeでの動画配布
  • プレゼントキャンペーンの実施
  • ライブ配信によるウェビナー
  • ソーシャルメディアでのつぶやき
  • ポッドキャストの収録
  • 資料PDFの配布
  • イベントでの登壇やスポンサー

お金があればGoogle Adsenceで広告を出したり、専門のライターさんを雇ったりすることもできなくもありません。しかし、まずは自分たちでできることから始めていきましょう。サービス開発をした本人こそがサービスに対する思いを一番知っていて、誰に使ってほしいかを知っているはずだからです。その思いを発信して届いたユーザーが、将来のサービスのファンとなってサービスが広まっていくきっかけになります。

最初のうちはブログなどを読んでいただく方が少なくて情報発信の継続が難しくなることがあるかもしれません。ですが、Web上に公開された記事や動画は数年経った後に読んでいただく方が出てくることもあるロングテールで効果的なマーケティング手法です。最初は読者が少なくても、めげずに発信を続けてきた人だけが、最後の利益を得ることができます。サービス開発に対して深い愛情がなければできないことですが、サービスをより多くの方へ知って使っていただくようにするためにコツコツと続けていきましょう。

筆者のブログ「ボクココ」では、現在では370を超える読者の方に購読いただいております。ここまでの規模になるには長い時間がかかりましたが、とりわけ以下の点は記事を書き続ける上で重要な点だと考えています。

  • 当番制や日時制にせず、自ら沸き起こったモチベーションで記事を書く
  • 短期的な利益を求めず、読者のために書く意識を持つ
  • あらゆる接点で情報発信を知っていただく機会を作る(SNSやイベント登壇時など)
  • 無難な解説記事ではなく、そこに自分の意見を記す

ブログだけに限らず、他のアウトプットの方法でも同じように知っていただくきっかけは重要です。上記を参考に、サービス公開後から情報発信を意識してみてください。

Herokuコミュニティ活動

本記事の最後に、より深くHerokuを学びたい方向けにHerokuユーザーグループをご紹介します。Herokuユーザーグループでは定期的に開催される Heroku Meetup や、Slackグループがあります。それぞれの活動についてご紹介します。

Heroku Meetup

3ヶ月に1回ほどの頻度でHeroku Meetupを開催しております。東京での活動がメインですが、大阪でも先日開催されています。

Herokuの利用事例や高度な使い方をシェアするセッションと、Herokuでやってみた等をシェアするLTの2部で構成されています。最近ではより大規模なHeroku運用事例をシェアいただくケースが増えてきていますが、既にHerokuを使っている方から、これから使おうと考えている方まで幅広い方にお越しいただいています。

f:id:cevid_cpp:20181028143613p:plain

Heroku Slackグループ

日常のHerokuに関する情報共有をするために、HerokuユーザーグループのSlackチャンネルが開設されました。

以下のようなトピックで日々 Herokuユーザー同士で交流が行われています。

  • コミュニティからのお知らせ: 次回のHeroku Meetup開催のお知らせやそれに向けての登壇者の募集など、コミュニティの最新情報をお知らせします。
  • 技術的な質問: Herokuであらゆるアプリを構築されている方が集っていますので、「こういうアプリをHerokuでどうやって作るか」「こんな問題が起きたが、どう解決すれば良いか」といった質問ができる環境があります。
  • Heroku更新・障害通知: Herokuが発信しているRSSチャンネルを購読したチャンネルがあるため、わざわざHerokuステータスのRSSを購読する必要がなくなります。また、これらの最新ニュースを適宜Slack内で議論するといったことも行われています。
  • Meetupの動画共有: Meetupの内容は配信・録画しており、当日参加できなかった方でも後でSlackに動画が共有されます。

もし参加に興味のある方はURLから参加することができます。

Herokuを一緒に盛り上げていきましょう!

終わりに

本記事は新しくHerokuでサービス開発する方向けに、筆者が5年間Herokuでサービス開発を続けてきて得られた情報やノウハウを記しました。

サービス開発を100%成功させることはできませんが、その確率を上げることは可能です。本記事によって、少しでもHerokuでサービス開発を成功させる方が増えることを祈っております。そして、サービス開発の成功事例をHeroku MeetupやSlackコミュニティを通じてシェアされるようになれば、本記事を書いて良かったと心から思うことができます。

読者の皆様が単に本記事を読んで満足するのではなく、実際にHerokuでサービス開発を始めてくれると信じています。一緒にサービス開発の成功に向けて駆け上がりましょう。

最後に、改めて本記事をお読みいただきありがとうございました。


このエントリーをはてなブックマークに追加