CBcloudに入社してからの1年半で何をやってきたのか
「届けてくれる」にもっと価値を出したい、新垣です。
2020年8月からCBcloudという物流テックのスタートアップにソフトウェアエンジニアとして入社し、PickGoという配送プラットホームの開発メンバーとして働き2022年4月で大体一年半以上在籍していることになりました。
ちょうど4月という振り返り＆目標を立てるのに適した時期なので、この一年半で何をやってきたのか振り返っていきたいとおもいます
ちなみに以下の成果は自分がほぼ一人で手を動かしたものもありますが、エンジニアリングマネジャーとして意思決定・プロジェクト化を行い、チームに所属する優秀なメンバーたちの努力によって実現してくれたものも含まれています。
GCPのCloudSQLからAWSのRDS Aurora MySQL互換へのDB移行
私が入社したのが2020年の8月で、その最初のミッションはGCPのCloudSQL上で動いているMySQLを、AWSのRDS Aurora MySQL互換へ移行することでした。
今回対応したのがPickGoという配送マッチングプラットフォームのサービスのDBですが、このサービスは歴史的背景で初期Scalaで実装されたAPIがGCPに、その後Railsで実装されたAPIがAWS上に、そしてそれらが利用するデータベースがGCP上のCloudSQLで動いている状態でした。
それを今後クラウドは基本的にAWSに統一していくこと、セキュリティやパフォーマンスの問題を考慮してAWSのAuroraに移行することとなりました。
そもそものサービス構成や仕様を理解するところ始まり、移行の段取り・検証を進め、途中に別の機能開発などにも参加しながら最終的には1月にほぼトラブルなく移行を完了させることができました。
CBcloudで東京オフィスに社員は集中していて当時僕が初めての沖縄オフィスのエンジニアとして入社し、いきなりミッションクリティカルな仕事をやるのは、かなりエキサイティングでしたがこの仕事のおかげでリモートでも沖縄のエンジニアでも価値の高い仕事ができると証明できてだいぶ信頼貯金が溜まった気がします。
自動テスト・ドキュメントを書くカルチャーの醸成
DB移行後からはサービス開発比重を増やしていっていたのですが、そこで問題となっていたのはバックエンドで利用しているRailsの、コードの品質の低さと仕様理解の難易度の高さです。
PickGoのコードはある意味典型的なスタートアップの初期のコードで、スピード重視で開発をして、ユニットテストもほぼなく仕様を知るためのドキュメントも少ないという状況でした。
それでうまく開発が回っていればある意味問題ないのですが、仕様が不明なために影響範囲が漏れておりバグが発生したり自動テストがないためにデグレが発生したりとリリースのたびに問題が起きている状態でした。
これに対する危機感は僕以外のメンバーも全員理解していたので、まずチーム内の方針として、「新機能・バグ修正をする場合はそこに関わる実装のテストは自分が触ったことのない実装出会ってもテストをすること」「新しい機能開発をする際には、なぜこの機能を作ったのか、どういう仕様で作ったのかを追えるようにドキュメントを書こう」という方針を決めました。
これに加えて、ビジネス上重要なAPIの自動テストをモブプロしながら書く時間を作ったり、CIでテストカバレッジを取るようにしたり、リリースのたびに0.1%でもカバレッジが増えていれば意図的に大騒ぎして称賛したり、バグや新機能開発する際に既存機能の仕様を調べた際には他の人も参照できるようにドキュメントにしたりと小さな改善をコツコツ、チーム全員で取り組んでいきました。
その結果、入社時点(2020年8月)では280件程度の件数だったドキュメントの数が本日時点(2022年4月7日)で3500件を超えるドキュメントの数に、テストカバレッジは60%まで上がりました。
後述しますが、当時は1週間に一回デプロイできれば良い方で、かつそのデプロイもバグが発生しないかビクビクしながらの作業、バグが発生して切り戻すことも頻発するという状態でしたが、現在では一日に5回デプロイをすることも珍しくなく、切り戻しが発生する頻度とも2-3週間に一度あるかないかという程度に低くなりました。
NewRelic導入によってモニタリングの強化
PickGoではdatadogというサービスで一応アプリケーションモニタリングをしてはいたのですが、ただ入れているだけ実際うまく使いこなせている状況ではなく、効率的にバグ調査やパフォーマンス改善が行えていませんでした。
そのタイミングで入社した開発本部長が前職で導入していたNewRelicに乗り換えてモニタリングを強化して行く提案をしてくれたことで、PickGoのNewRelic導入を進めていきました。
これによってバグ原因の特定やパフォーマンス上のボトルネックの特定が格段に早くなり、障害発生頻度の減少と問題発生したときの復旧速度の向上に大きく貢献しました
アドホックなリリースからWeekly Release、そしてDaily Releaseへ
当初はバグ修正や機能追加のリリースは「出来たらリリースする」という感じで特に計画立てて行うものではありませんでした。
そこから入社した開発本部長によってQAチームが組織され、リリース前にQAを行う体制を作っていきました。
最初は2週1回のリリースで徐々にはじめていき、その後週1の定期リリースに切り替わり、週1+施策系のリリースの大体週1~2のリリースが行えるようになり、現在はデイリーリリースといって毎日リリース、しかも一日に何度もリリースを行えるような体制まで持っていきました。
ただ現在もまだ開発速度よりもリリース速度の方がボトルネックになっていてリリース待ちが数多く発生しているため、今後は更に速度をあげれるように改善を進めていく予定です。
属人性の高い問い合わせ対応をナレッジ化
これまで少ない人数でできるだけ早くドライバーや荷主向けの機能開発を優先して進めてきた結果として、ホントは必要な管理機能が十分に揃っていない状態で機能がリリースされていき結果として開発チームに依頼しないとオペレーション出来ないことが多い状況でした。
それ以外にもバグ報告であったり仕様についての確認・調査依頼など非常に多くの問い合わせがカスタマーサポートや営業から開発チームに入ってくる状況なのですが、新しくジョインしたメンバーが多いこともあり問い合わせ対応が特定の人に集中してしまう問題がありました。
この問い合わせ対応のナレッジ化をおこなうために、あらゆる問い合わせ対応を行う場合にはドキュメントツールのesaにページを作り調査・対応した内容を記載していくことで、他の人もURL一つでノウハウの伝承を可能にしました。
この運用を2021年8月から初めてから今時点(2022年4月)で232件のページが作られており、大抵の対応はesaを検索してそれに沿って対応することが可能になってきました
開発に依頼しないとできないオペレーションをへらすため新管理画面を開発し運用開始
前述したとおりドライバー・荷主向けの開発を優先して管理機能が不十分なため、サービス運営上必要のオペレーションが開発に依頼されて、エンジニアが心を込めた温かみのあるSQLを直接DBに流し込んで対応するというのものが非常に多くありました。
その対応に時間とマインドシェアが持っていかれるためまともに開発に集中する時間が取れず、時間がないから開発出来ない→開発する時間がないから管理機能は後回ししてなんとか新機能をリリースする→オペレーション依頼が開発に来る→開発する時間がなくなるの負のループがガンガンに回っている状態に陥っていました。
その問題を解決するために、新しい運用管理画面にフォーカスして開発するエンジニアをアサインして新運用管理画面を作ることをスタートし、つい先日社内リリースを行い運用に乗せ始めることができました。
すでに問い合わせで数多く来ていたオペレーションのほとんどはすでに新運用管理画面上で実現可能になり、それによってエンジニアは開発に集中する時間が増え、他部署は開発待ちによってオペレーションのリードタイムが伸びてしまう問題を解決することができました。
さいごに
今回は具体的な機能開発以外の改善として行ったことをピックアップしました。
入社当初はほんとに技術的課題が山積みで、「これやっていけるのか・・？」と不安になる部分も多かったのですが、チームに巡れたこともあり、かなりの多くの課題を解決することができました。
課題を解決したことによって得られたチームの開発速度の向上も重要ですが、それ以上に「自分たちはちゃんと課題に向き合って解決することができる」という自信を得ることができたのがこの1年半の大きな成果だと思います。
まだまだ技術的課題も山積みですし、なによりもユーザーや社会に対してより大きな価値を、より早く出していくためにどうすればよいかという課題にこれからも向き合っていく必要がありますが、この1年半で得た自信を胸により良いプロダクト、より良い開発組織にさらに進化していけると信じて頑張っていきます
宣伝
バックエンド、フロントエンド、モバイルアプリのエンジニアなど全方位採用を進めていますので少しでも興味のある方はぜひ採用ページを覗いてみてください！
沖縄オフィスもあるよ！
この記事が気に入ったらサポートをしてみませんか？