こんにちわ。Beer and Tech の開発チームで Engineering Manager を担当しています八木田です。前回の記事から少し間が空いてしまいましたが、我々が運営しているお花とグリーンの EC サービス HitoHana の最近の開発の様子をお伝えさせていただければと思います。母の日、チームの成長、中長期計画の 3 点についてご覧いただければと思っております。それではどうぞ！

母の日がありました

我々が属する業界は一般に花き業界と呼ばれておりまして、お花の部門において5月に大きく商いが行われます。母の日ですね。サービスとしての HitoHana は母の日周辺のトラフィックが通常期との比較で数倍になることがわかっておりまして、その準備を年始頃から徐々に進めておりました。(トラフィックの様子はこちらの記事の最後の方をご覧ください)

準備したこと

準備したこととしては大きく分けると 2 つあり、ひとつが業務効率化のためのシステム改善、もうひとつがパフォーマンスボトルネックの解消、となります。

業務効率化のためのシステム改善として、大小さまざまあったのですが、代表例としてメッセージカードの自動化をあげてみたいと思います。(主に松山さんが対応してくれました)

HitoHana ではお花をご購入いただく際にメッセージカードにメッセージを添えてお送り先の方へ配送することができるサービスがあります。このメッセージカードの作成業務は従来はオペ担当者がパワポでメッセージカードの雛形にお客様に入力いただいたメッセージを打ち込む(温かみのある細かい修正はここでやる)=>印刷する=>確認して同梱するという業務フローで作業していました。一見単純ですが、これが1000件を超えてくると流石に無理なのでは... となってきます。実際に母の日はこの状況になるということで、お客様がメッセージを入力する UI を改善したり、印刷後と概ね一致するプレビューを表示したり(下図のようになります)、サーバーでメッセージカードにメッセージを入力してPDFを生成したりという自動化を行いました。大幅な工数削減・オペミスの防止につながる改善ができたかなと思っております。

パフォーマンスボトルネックの解消について、こちらも大小さまざまありましたが、大きな取り組みとしては 3 つあったかなと思います。

• 各種インスタンスアップ
• キャッシュ強化によるレイテンシー低減
• delayed_job から sidekiq への移行

昨年末からモニタリングツールをちゃんと導入していくことをやっておりまして、既存のものを捨てて、すべて Datadog に集約するということを母の日の対応を行う前にやっていきました。そこで取得した各種メトリクスや集約したログを確認しながら母の日の想定トラフィックに対応するための想定パフォーマンスが出せるところまでインスタンスアップしたりインスタンスを増やしたり、アプリケーションを調整して高いキャッシュヒット率になるような作りに変えたり、キューが詰まりがちだった delayed_job を諦めて sidekiq に移行したりということをやっていきました。結果としては、母の日周辺の期間でインフラ面、アプリケーション基盤面で目立った問題はなく通常運転できたかなというところでした。

母の日周辺のできごとについて

母の日周辺の期間は、社内の業務量を調整するための対応やお客様からのお問い合わせが大量に発生し、忙殺された期間になりました。下図のオレンジ色の枠線で囲った部分が母の日周辺の Sprint の Velocity のグラフです。各 Sprint の Velocity の大半で赤色領域が大きくなっていますが、これは赤部分の Story Point がそういった対応に終始していることを概ね示しています。来年はもう少し減らしていけるといいかなというところですね。この赤色領域のIssueの対応は新原さんと岡部さんが無双していました！

チームが成長しています

2019年後半から徐々に徐々に増員していた開発チームですが、ここにきて5月に一気に3名のエンジニアのジョインが決まり、すでに活躍していただいています！やったね！

6名=>9名の開発チームになりましたが、日々の開発プロセスは一旦従来のままスクラムを踏襲して運用している状況です。ふりかえりでの定性面の話・ベロシティの高め維持継続という定量面の話、両面からうまくスクラムが回っているなぁと捉えており、いい状況が継続していると判断しています。

また、開発チームの生産性(スピードx質x量)が高め維持していると社内で認識される状態に変化してきており、ビジネスサイドでの動きも歩調を合わせる形で活発になっているので、開発チームは明確に成長できてきたかなという感触です。

中長期計画の対応が少しづつ進捗しています

こちらの記事でふれさせていただきましたが、我々は去年の10月頃から中長期の計画を立てながら開発チームのディレクションを行うようにしています。ちなみに現在のマイルストーンは下図のようになっております。

前回のマイルストーンと比較すると随分雑な感じになっておりますが、僕のシステムへの理解度が向上した結果と母の日向けの対応を進めていった結果によるところが大きく、「これは全然思ったとおりにならないぞ」ということがわかって、諦めてよいところをスパッと諦めつつ優先順位の高い順に並べ直した結果こうなった、というアウトプットになります。(言い訳終わり)

4月から9月の半年間の目玉としては、コンテナベースの基盤に移行するところかなと思っております。現状は EC2 + Capistrano な実行環境とデプロイの仕組みで日々を過ごしていますが、これを ECS + Fargate + Github Actions な実行環境とデプロイに変更することを目指して実装を進めています。ただ、HitoHana の既存アプリケーションの構成をそのままコンテナに詰め込むのはなかなか難しいところがありまして... 例えばアセットをアプリケーションに内包していたりするところですね、それらを分離していくような枝葉の Issue が大量にあって半年でやりきれるかなんとも言えないところですが継続して対応を進めています。

この記事の読者の方の中には、Beer and Tech に興味をお持ちの方・興味を持てそうか確認していただいている方もいるという想定があります。実際にジョインして頂いた際にどのようなIssueの対応をすることになるのかの具体のイメージを持っていただくためにも、ご紹介できる範囲で Issue のリストをご紹介してみたいと思います。(僕たちの技術スタックについては Stackshare をご確認ください)

• セキュリティ対策: 不要コードの削除、ライブラリの削除・更新、Breakman 指摘の対応、認証・認可基盤の刷新など
• ログマネジメント: システムログ・アプリケーションログの最適化・調整、ログをデータに変換していくフローの構築
• 開発環境改善: 随時見直し、随時高速化、静的解析の最適化、テストの最適化、CI 最適化
• 実行環境改善: EC2からECSへ移行、RDSからAuroraへ移行、Stagingマシン運用からReviewApp運用へ移行
• CD改善: ビルドパイプライン最適化、アセットパイプライン最適化

他にも、コードベースをよりよくしていくための活動、レビューの方針の話、コードの書き方の話、アーキテクチャの方向性の話... やるべきこと・考えるべきことが盛り沢山な状況になっております。

Beer and Tech の 2021 年度(6月締めなのです)は、ビジネス的にもシステム的にも「成長した！」と強く言える 1 年だったなぁと思っています。チームも大きくなってきて、技術負債の本丸への切り込みを実行していく次の一年を一緒に走っていただける方をめちゃくちゃ待っています！ぜひとも一度お話しましょう！

よろしくお願いいたします！