Herokuを使ったチーム開発奮闘記（エンジニアが1から8人になるまでにやったこと）
仕事で とあるスタートアップ企業の自社サービスのアプリケーション開発を引き継いだときのこと。
当初エンジニアは自分1人しかいなかったのですが、最終的にはチームとして8人（社員3名、インターン5名）でコードレビュー・デプロイを行いながら、ガシガシ開発が進められる状況になりました。
その裏には Heroku というプラットフォームを取り入れたことが強力に働きました。
初期の少ないリソースの中でどのようにして新規開発を行なってきたのか、チームで開発が回るようになるまでの経緯と、行なってきた工夫についてメモしていきたいと思います。
エンジニア 1人
もともとぼくが関わる以前のアプリケーション開発は外注されていました。
1人目のエンジニアとして入社し、運用を引き継ぐことになったのですが、ある程度 形になっているアプリケーションをいきなり1人で運用するには不安が大きく、同時に実装したい機能は日々 増えていく中で、インフラ面で時間をかけていて満足にコードを書けない状況は非常にわずらわしいものでした。
とくに小さなスタートアップ企業だったので、やりたいことは毎日のように溜まっていきます。また、それは早いサイクルで検証を繰り返し、1ヶ月後に大きく施策が変わっていることも多々ありました。
もしかすると1年後に消えてしまうかもわからない会社で、いかにプロダクトを早く形にするかが求められる中、コードを書く時間が満足に取れない状況は致命的です。Wantedly さんが Heroku で運用していた実績を見たり、知り合いのエンジニアから知恵を拝借させていただいて、Heroku の導入を検討することにしました。
実際に導入してみてわかったのですが、スタートアップでの初期の開発において、Heroku を用いるメリットがいくつかありました。
初期コストが安い
Heroku は初期のコストが安く、Hobby プランなら $7 /month、Professional プランなら $25 /month 、DB はプランによって $9 /month、$50 /month 程度から使うことができます。
デプロイがお手軽
git push を行うだけで、デプロイ時に必要なプラグインのアップデート、コンパイルや圧縮など最低限必要なことは勝手に Heroku 側でやってくれます。
外部ツールの導入がラク
New Relic や Papertrail などのツールがアドオンとして提供されているのでそれを使っていました。とりあえず試してみて、いらなかったらやっぱり消すということも最低限の手間で可能です。
それなりの金額で、デプロイのしくみとログや監視ツールの導入を、最小限の手間で構築することができる点において非常に重宝しました。
エンジニア3人
入社して2ヶ月ほどが経ち、エンジニアが2人増えて 1日のコミット数が増加したおかげで、優先度の高い施策は常時 改善が進められる状況になりました。
これくらいの規模であれば 各自がそれぞれ何をやっているのか把握できるので、Slack や直接 声をかけながら、ひとりひとりが大きな裁量を持って主体的に開発を進めることができました。
また、ユーザー数の増加、SEOによる流入アップによってアプリケーションへトラフィックが増えことにより、DBやサーバーのスケールアップが必要になりました。
デフォルトでインフラの監視ツールが用意されていることや、ダッシュボードでdyno数（コンテナ数）を指定するだけで、自動的にスケールアップが可能です。
インフラ監視
アドオンで外部のツールを導入することも可能なのですが、あらかじめ使用メモリやレスポンスタイム、スループットなどがダッシュボードで確認できるようになっています。
※ Dyno タイプが professional のときのみ
スケールアップが簡単
dyno（Heroku 上での資源の単位）を増やしたり、DBのスケールアップはダッシュボードやコマンドラインから行うことができ、例えばメディアに掲載されてアクセスが集中している1時間だけ dyno を10にして、また元に戻すことも瞬時に可能です。
従量課金制なので請求額は使った時間分であり、無駄にコストがかかることはありません。
エンジニア 8人
エンジニアの採用が進んだことで新たにメンバーが5人増え、いよいよチームらしくなってきました。デザイナーも含めると10人くらいになります。この頃は複数のプロジェクトが同時に並行して進み、情報共有も必要になってきました。
一方でチーム全体の知見も増えて、経験豊富なメンバーの参加によって、技術的なことについては誰かが知っていて相談したり、そのときに手の空いていた人が対応することのできる強いチームとなりつつもありました。
ちなみに余談ですが、開発は基本的には各自の主体性に任せる方針で、その代わりに自分自身としては使っている技術をキャッチアップし、問題があったときにはすぐに対応にあたれるように意識していました。また、各メンバーが滞りなく開発が進むように、致命的なミスが起きないように、技術の選定やデータベースの設計、コードレビューには積極的に参加するようにしていました。
そのときの会社の雰囲気としては、来月そのアプリケーションの仕様が大きく変わったり、実際に公開してみてうまくいかなければ方向転換、といったスピードが求められる現場だったので、賛否両論あると思いますが、基本的にはガンガン作っていくことが主軸にあって、致命的なミスが起きないように、また、起きたとしてもすぐに対処できるように最悪のラインの柵を超えないようにだけ注意しないといけないな、と考えていました。
量と質のバランスは難しいところですが、とはいいつつ だんだんコードが煩雑になっていくことも実感し始めていたため、この頃から質を維持していく必要性も感じ始めていました。
ブランチ運用やテスト環境構築において、Heroku で提供されていた機能が非常に重宝しました。
Automatic deploys 機能
指定したブランチに変更したコードを Push すると、自動的に専用の環境にデプロイさせることができます。
master ブランチにマージされると、ステージング環境に自動的にデプロイされるように設定していました。
Review apps 機能
Pull Request ごとにアプリケーションを展開することもできるようになっています。
Pull Request を作成すると、専用の環境が立ち上がり、Pull Request を閉じると自動的に消えます。
各プロジェクトごとに動作確認環境を自動で作成することができるため、たとえばデザイナーがデザイン修正を行って「こんな感じでいいですか？」と社内に共有するといった使い方もできます。
これらの機能を用いることで、Pull Request を立ち上げてコードレビューと必要であれば社内で動作チェックを依頼、問題なければデプロイするという GitHub Flow のブランチ運用ルールの中にすっきりと開発環境を組み込むことができました。
考えたこと
最終的に2年間くらい Heroku を用いた運用を続けてきました。これまで使ってきた所感としては、「意外と不便を感じることがなかった」ということです。やはりAWSがメジャーで、商用で利用するアプリケーションに本当に耐えうるのか、というところが不安だったのですが、普通にウェブサービスを運用していれば大抵のことは不自由なくできると感じます。
ただかんたんな分、柔軟さにはどうしてもAWSのほうに軍配が上がります。サブディレクトリ以下に WordPress を設置したい、みたいにちょっと道に外れたことをやろうとすると実現が難しかったりするのですが、できるだけシンプルにアプリケーションを管理していくという意味では Heroku の設計にのっとったほうが健全という考え方もできます。
ユーザーに価値を提供するうえで、必要なときに必要に応じてプログラムを使いこなしていくという場合に、Heroku というプラットフォームは手軽で、身動きがとりやすく早いです。
一言で言うなら、お客さんに「はい、作ってみました！ これでどーですか？」を叶えてくれる素敵なツールだと思いました。
もし不都合が出てきたら Heroku から AWS に移行すれば良いと考えているので、初期の段階では安価に手軽にウェブサービスをローンチできる Heroku という選択肢を検討するのもアリかと思いました。
ウェブサービスの開発がどんどんパッケージ化され、手軽になっていきます。
よく考えてみればチーム開発のノウハウとか、GitHubといったサービスが生まれたのもほんのここ10年くらいの話で、まだまだ確立されていなかったりしますよね……。これからますますブラックボックス・一元化・高級・パッケージ化という流れは進むと思うので、基本原理は勉強しつつ、必要に応じて技術の恩恵をありがたく享受しながら 便利なものは取り入れていくようにしていきたいな、と感じていたりします。
