プロダクトは継続的に改善するもの。それができてはじめて "CARTA っぽい" 【ベストエンジニアインタビュー】

技術広報 ShuzoN__ (以下、しゅーぞー)です。

今回はベストエンジニア表彰を受けた株式会社 DIGITALIO トモカツさんに半年の取り組みをインタビューしました。

プロダクトは継続的に改善するもの。それができてはじめて "CARTA っぽい"

そんな言葉も飛び出した今回。

ベストエンジニアのトモカツさんの仕事とともに、"CARTA っぽいエンジニアリング"を紐解いていきます。

新保 智喝(シンボ トモカツ)

DIGITALIO リテールDX事業本部 デジクル事業部 所属。小売・リテール業界のデジタル化を推進するプロダクトの開発、データ分析基盤の構築を担当。CARTA HOLDINGS には2017年新卒として入社。インフラを扱う部署に配属し、デジタルギフト「デジコ」を運営する事業部を経て現在に至る。趣味はベランダ園芸、水槽、テニス。文中では「トモカツ」。

Twitter 懸賞システムの移管と再実装

仕事の概要

しゅーぞー: 今回の仕事ではざっくりどんなことをやりましたか？

トモカツ: 当時はデジコというデジタルギフトを提供しているチームにいました(現在は異動)。

デジコとは CARTA HOLDINGS(以下、CARTA)が提供しているデジタルギフトサービス
デジタルギフトとは、日常的に使っている〇〇ペイやギフトに交換できるポイントギフト

トモカツ: 事業的な背景から説明しますね。デジコを市場に流通させるソリューションとして既存の Twitter インスタントウィンが選ばれました(以下、旧システム)。今回の仕事では、その旧システムのリプレイスを行いました。 背景としては、CARTA 内の別事業部が持っていたシステムを DIGITALIO が引き取った経緯があります。

トモカツ: Twitter インスタントウィンとは、 Twitter 上で懸賞応募、当選通知を行うツールを指します。 Twitter で「フォローといいねをすると懸賞に応募できる」ようなキャンペーンを見たことがある人もいるでしょう。あれを実現するシステムです。

チームの体制

しゅーぞー: 体制としてはどのような状態でしたか？

トモカツ: アプリケーションエンジニアがメインで 2 名、インフラは業務委託 2 名という体制でした。アプリケーション改修は私と新卒で行い、インフラ構築は私が業務委託のマネジメントをしていました。

今回の仕事で意識していたこと

しゅーぞー: 今回の仕事で意識していたことを教えて下さい。

トモカツ: 今回の仕事で強く意識をしていたのは「チームの開発者に変更のしやすさを提供すること」です。 チームメンバーは少ないながらも複数プロダクトを扱っているので、問題が起きても安全にリリースできることを意識していました。

しゅーぞー: ありがとうございます。では、具体的な仕事について聞いてきます。

旧システムと当初の状態

インフラの課題

サーバ 1 台で全てを担う構成

しゅーぞー: 買い取った旧システムの当初の状態はどのような感じでしたか？システム面をお聞きしたいです。

トモカツ: 当時は EC2 インスタンス 1 台で全てのサービスを担う構成でした。 AWS の環境上に本番とテスト用の EC2 インスタンスがそれぞれ 1 台ずつ動いていました。

ロードバランサが存在せず、負荷分散していない
DB は MySQL がサーバにインストールされている状態
サーバのモニタリングもログローテーションもしていない

しゅーぞー: なるほど、単一障害点そのものですね。

手動デプロイと意図のわからない監視通知

しゅーぞー: デプロイや計測周りはどんな感じだったんですか？

トモカツ: デプロイは手動です。 サーバーに入って git clone してリリースする人の手が入るデプロイフローでした。

トモカツ: 監視についてはアプリケーションから通知する仕組みはありました。しかし、何か起きた時に気づけるように監視が整備されているとは言い難い状態でした。

通知内容から次のアクションがわからない
通知意図がそもそも分からない
サーバ自体の監視もない

アプリケーションの課題

バージョン管理されておらず、サーバー上で独自拡張かつ脆弱

しゅーぞー: アプリケーションレベルでの問題はありましたか？

トモカツ: 旧システムは PHP で動いていて、具体的には以下のような問題がありましたね。

リポジトリに存在するアプリケーションのファイルに欠損がある
composer でインストールしているファイルがサーバ上で独自に改造されている
脆弱性が多数検出された
マイグレーションの仕組みはなく、PHPMyAdmin から直接操作
ログレベルがすべて app_info という独自のもの

しゅーぞー: つまり、 1 台のサーバーに依存し、脆弱でデプロイも難しいメンテ不可な状態だった んですね。

トモカツ: そうですね。なかなか厳しい状況ではありました。

移管という大きな分岐点と判断

より良くしたくなるはずだから、初めからちゃんとやろう

しゅーぞー: システムリプレイスはビジネス的には大きな判断です。 どのような判断があったのでしょうか？

トモカツ: ざっくり経緯を説明します。要点は以下です。

旧システムクローズの話が出た
デジコは、社内クライアントとして旧システムを使っていた
デジコの販促ソリューションとして旧システムに期待をしていた
クローズするならばデジコが買い取って改修しよう

しゅーぞー: クローズ予定の旧システムを買い取った形だったんですね。

トモカツ: そして、蓋を開けてみると、ここまで話した通りのような状態でした。

トモカツ: ゼロから Twitter インスタントウィンのシステムを作る話もありましたが、経営陣とも話し、今のアプリケーションはできるだけ生かすことにしました。そして「既存の品質の状態としても、ビジネス的な期待としてもアプリケーションに手を加えていきたくなるはずだから、メンテナンスしやすい仕組みにのせよう」と舵を切りました。

トモカツ: いずれにしてもシステムを稼働させ始めると、後から必ず手を入れたくなります。また、何か問題を発見したときに安全に手を加えたい。そのためにちゃんと基礎から CI/CD を作ることを徹底しました。

トモカツ: ちょうど同じ時期に隣の事業部でも似たサービスの開発を検討していたので、組織としてどこに人と時間をかけるのかという判断があったりもしました。

今回の仕事において「捨てたこと」

しゅーぞー: 今回の仕事において「捨てたこと」はありますか？

トモカツ: 進め方の面では、アプリケーションの大きな改修、機能追加はしないと決めたことですね。 また、要件を限定して、不要な機能は使わず捨てることにしました。もちろん稼働に必要な修正や細かい改善は行っています。また、旧システムは、今回のリプレイスでそのまま捨てています。

デリバリは人の手が一切入らないように

しゅーぞー: デリバリーや SLA について、こだわった部分はありますか？

トモカツ: デプロイ時に人の手が一切入らないようにしました。 依存するパッケージやアプリケーションのバージョンは YAML で管理し、デプロイのたびに同じ環境になる。変更すればちゃんと反映される。それは意識しましたね。

トモカツ: また、セキュリティ診断の結果、脆弱性が多いこともわかったためちゃんとアップデート出来る構成にしておくこともやっています。「CARTA では当たり前にやるよね」をちゃんとやる意識はしていますね。

フレームワークとして成立しないものを一つ一つ改修

しゅーぞー: アプリケーションレイヤで手こずったことはなんですか？

トモカツ: フレームワークを使うために揃っておくべきファイルがバージョン管理されていませんでした。つまり必要なファイルが git 上にはなく、サーバ上だけに存在していました。当然、その状態で git clone しても正常に動きません。

トモカツ: 問題を切り分けるために自分たちのコードなのか、フレームワークのコードなのかを一つずつ突き合わせながら仕分けをしていきました。そうやって、一つ一つ動かすためのステップを踏みました。

トモカツ: また、 PHPMyAdmin で本番 DB に接続し、テーブルに変更を加える運用をしていたためマイグレーションファイル管理がされていませんでした。 テーブルの変更などは頻繁に行わないと判断し、PHPMyAdmin からエクスポートしたテーブル定義をリポジトリに追加して管理するようにしましたね。

トモカツ: 正直動くか不安だったので、動作確認できた時はかなり安堵しました（笑）

CARTA っぽいプロダクトとは

プロダクトは継続的に改善するもの。それができてはじめて "CARTA っぽい"

しゅーぞー: 事前資料に 「CARTA のプロダクトとして多くの点で至らないと感じたのは事実」 とあり、とても好きな表現でした。そう思った理由を教えて下さい。

トモカツ: プロダクトは作って終わりじゃなくて継続的に改善するものです。小さく作ってより良くしていく。継続的にメンテナンスしていく。その開発プロセスがベースにあり、 CARTA のエンジニアリング文化にも根付いていると思います。「継続的な改善」が達成できる状態ではなかったことが一番大きいと思います。

トモカツ: 逆に、お客さんに対して安全にサービス提供するための要件に足りないのは"CARTA っぽくない"。 小さい単位でどんどん変更を加えていくために、安全にサービスがリリースされる必要がある。何回リリースしても安定的にリリースできる。いってしまえば CI/CD 環境ですが、技術者がデプロイ時に気にすることが減るように整備しました。

動いているものについてのリスペクト

しゅーぞー: ベストエンジニア受賞時に「すでに動いているものへのリスペクトを忘れず」とおっしゃっていました。どのようなリスペクトがあるのでしょうか？

トモカツ: 一言でいうと「事業の顧客がもつペインを解消している実績」に対するリスペクトですね。僕たちが今作っているプロダクトは、これまで向き合ってきた人たちの努力や視野を広げてきた痕跡の上に立っています。旧システムについては、不確実な市場で競争しお客さんからお金をもらうまで質を高めたことは評価をしてよいはずです。その上で、技術的に課題があるのであれば、過去の実績とは別の文脈として改善していく。ただ、そのときに「古い、技術的に課題があるから駄目」と言い切らず、これまで価値を生んできたことに対するリスペクトは忘れてはいけないと思います。