gamba!の開発10年を振り返ってみて 〜 中編
gamba!の開発プロセスで、少ない開発リソースで継続的な開発を実現する一番重要なポイントは、テストの自動化とデプロイの自動化です。
gamba!の開発では、サーバサイドはRuby on Railsに付属するテストツールRSpecを使って、すべてのAPIやモデル・コントローラに対してユニットテストが作成されており、全部で約1,500項目ほどあります。同様にクライアント側にもJestを使ったユニットテストが作成されており、こちらは約2,500項目あります。
gamba!の開発はいわゆるテスト駆動開発のような厳密なやり方はしていませんが、何か新しい機能を作ったり、不具合を修正した時には必ずユニットテストを作成するように徹底しています。
もちろん、ユニットテストを作成することはその分、工数増になります。しかしユニットテストを作っておくことは、新たな開発をおこなった際に思わぬところで悪影響が出て不具合が発生する可能性を最小限にすることにつながります。
また、ユニットテストですべての不具合を検出できるわけではなく、手作業による実機テストがなくなることはありません。ただ、テスト工数は圧倒的に減らすことができます。
実際、初期の開発では不具合を修正したら新たな不具合を埋め込んでしまった、みたいな笑えない話を何度も繰り返し、工数が雪だるま式に膨れ上がるみたいな経験を何度もやらかしました。ユニットテストをきちんと作っておくようになって以来、テスト段階で未然に不具合を予防できた、というヒヤリハットは枚挙にいとまがありません。
ユニットテストは、長期で見れば間違いなく工数削減になります。このことは、声を大にして言いたい。「SaaSスタートアップは、ユニットテストを書け！」
とはいえ、それでも、リリースしてから不具合に気づくという事態は完全には防げません。そんな時に頼りになるのが、デプロイの自動化です。
リリースした瞬間にテストで見つけられなかった深刻な不具合が表面化し、今すぐ修正しなければいけない、みたいな状況を想像してみてください。慌てて修正版を作成し、テストし、よしリリースだ！となったとして、チームは当然混乱しています。こんな時は焦っているが故に、思わぬオペミスが起きがちです。
また、iPhoneアプリのリリースにはApple Storeの審査が必要なため、修正版のリリースに最悪数日の日数がかかってしまうことがあります。
gamba!の場合、修正したコードを本番環境に展開するのも、スマートフォンアプリに反映させるのも、チャットBotに指示を出すだけで数分程度で完了します。gamba!のスマートフォンアプリにはCodePushという仕組みを導入しているので、Apple Storeの審査なしに、あっという間に修正版の配信が可能です。
gamba!には、新たな機能や改善・不具合の修正などで5〜10項目程度の改善バージョンが毎週リリースされています。大半の変更は、お客様がまず気づかないような細かなものばかりですが、そういったものが積もり積もって最終的に大きな使い勝手の違いに繋がっていきます。
目の前の要望を叶える開発をするだけでなく、不具合の発生を防いだり、不具合の影響を最小限に抑え、かつ、エンジニアの手作業や努力に頼らない、見えない部分を効率化する仕組みづくりが絶対に必要です。
私の尊敬する友人に、Excelで業務改善を指南するたくさんの著書を出している吉田拳さんという方がいるのですが、彼の提唱する「前向きな怠惰」という言葉には、わかりみしかありません。
というわけで、冒頭のバナーに吉田さんの写真を使わせていただきました。
gamba!公式サイトはこちらへ！ 《無料で15日間gamba!お試しできます》
株式会社gamba! カスタマーサクセスチーム note
gamba! 公式 facebookページ
gamba! 公式Twitter
この記事が気に入ったらサポートをしてみませんか？