NEW
デプロイ頻度は5倍、リードタイムは6分の1に。在庫管理自動化SaaSを手掛けるスマートショッピングの開発生産性向上に向けた取り組みとは？
IoT重量計「SmartMat」を使った在庫管理・発注自動化のソリューションを展開する株式会社スマートショッピングでは、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。
今回は、スマートショッピングでエンジニアリングマネージャーを務める仙葉さんと、SREとして活動する木村さんにインタビュー。開発生産性の計測において、これまでに進めてきた取り組みの内容や、実際に「Findy Team+」の数値がどのように変化したかなどについて伺いました。
目次
SREチームを立ち上げ、信頼性や生産性の向上のため活動
――まず最初に、お二人のご経歴や現在の役割について教えてください。
仙葉：私は新卒で入ったSIerの会社で3年ほど開発を経験したのち、スマートショッピングに入社しています。入社直後は、以前弊社で運用していた価格比較ECサイトでバックエンドエンジニアをして、その後はtoC向けの「SmartMat Lite」という在庫管理のプロダクトの立ち上げに携わりました。
現在は、toB向けの「SmartMat Cloud」というプロダクトの開発チームのEMをしています。弊社にはプロダクトの開発チームが3つあり、そのうちの2チームに横断的に所属していて、組織運営や開発生産性をメインミッションとして活動しています。
木村：前職は従業員15人くらいのスタートアップで、バックエンドエンジニアとしてキャリアをスタートしています。スマートショッピングに入社した直後は、バックエンドエンジニアとして、インフラにも触れつつプロダクト開発を行ってきました。
その後はスタートアップらしく、どんどんサービスの新たな機能を開発していたのですが、運用面や信頼性に課題を感じて、SREチームの再立ち上げをしました。それからは、SREとしてインフラや信頼性の向上、全社の生産性向上など幅広く活動しています。
――SREチームの再立ち上げには、どういった背景があったのでしょうか？
木村：もともと前身のSRE組織があったのですが、ほぼ兼業のメンバーしかおらず、あまりプロアクティブに動く組織ではありませんでした。そのまま新機能の開発ばかりを行っていると運用が破綻してしまうという危機感から、2021年の年末ごろに改めてSREチームを立ち上げました。
――現在の開発組織の規模や体制について教えてください。
仙葉：エンジニアは、Webアプリケーションを開発するメンバー、SRE、R&Dを含めて11名。その他にPdMが2名、デザイナー1名が所属しています。
――開発組織ではどのようなミッションを掲げられていますか？
仙葉：「技術を磨いて日常を革新するプロダクト開発をする」ことをミッションに掲げています。さまざまな意味が込められていますが、社会に新たな価値を生み出すことや、未来の技術を蓄積して発信していくことなどが含まれます。社内的には、全社の技術向上に寄与することもミッションの1つで、AIでの議事録作成など社内のいろいろなところでの自動化を追求しています。
――開発組織にとどまらず、全社的に自動化への取り組みをされているのですね。
木村：SREの活動として信頼性の維持や向上に取り組んでいますが、生産性が高いことによる頻繁な改善や顧客価値提供の素早さなども含めて、信頼性だと解釈しています。そして、それはエンジニアリング組織だけでなく、全社の生産性も同様だと考えています。
全社での取り組みでは、例えば商談の動画の議事録をAIで作成したり、インサイドセールスから営業への申し送り事項を自動生成したりしています。
――そういった取り組みの背景には、ビジネスサイドとの距離の近さなどがあるのでしょうか？
仙葉：正直に言うと、以前までは課題がある状況だったと思います。ですが、これからの会社の成長を考えていくと、ビジネスサイドとの壁はどうしても邪魔になるので、ここ1年くらいで全社的に取り組みを始め、組織の構造も変えました。
加えて、エンジニアとカスタマーサクセスが参加するオフサイトミーティングなども今後予定されていて、意識的に交流の機会を増やす取り組みも行っています。
全社的な生産性への意識の高まりから、可視化の取り組みへ
――開発生産性の計測の取り組みを始めたのには、どのような背景がありましたか？
仙葉：もともと会社全体で、全社の生産性についての話題が上がっていました。そのなかで、弊社はエンジニアの人数が多い組織なので、エンジニアの生産性はどうなのかと何度か聞かれていたんですね。しかし、エンジニアの生産性について定量的に答えるのが難しい状況がありました。
エンジニアは信頼できるメンバーが多く、開発のスピードが遅いとは感じていませんでしたが、他の部署からはそれが見えません。なので、他社と比べても、しっかりと生産性を出せていることを定量的に証明したいという思いがありました。
――どのようなきっかけから「Findy Team+」に興味を持っていただきましたか？
木村：役員会議で全社の生産性の話題が出ていたのと同時期に、『LeanとDevOpsの科学』を読んで、Four Keysを可視化したいと考えていました。最初はCTOの長島さんが、GitHub Actionsなどを使って、自前で実装して指標を集めようとしていたのですが、集めた数値をグラフィカルに可視化するところまでやろうとすると、なかなか実装コストがかかります。
そうしたなか、長島さんが「Findy Team+」を見つけて、調査するなかで記事などを見て良さそうだということで、導入に向けてコンタクトを取ったという流れでした。
――「Findy Team+」の導入にあたって、社内の理解を得るためにどのようなアプローチをされましたか？
仙葉：稟議まわりに関しては、全社的に生産性への意識が高まっていたこともあり、エンジニア組織に任せてもらい、スムーズに導入が決まりました。開発メンバーも、みんな生産性が見えていないという課題感を持っていましたし、木村さんがFour Keysの可視化について発信してくれていたこともあって、かなり前向きに導入が進んでいきました。
――「Findy Team+」導入後、取り組みにおいて難しかったポイントはありましたか？
仙葉：いろいろありましたが、なかでも難しかったのは文化の形成です。みんなが同じ方向を向いた状態で進めていかないと、全然変わっていきませんでした。例えば、変更のリードタイムを短縮するために、プルリクの粒度を小さくしようとか、レビューを改善しようとか、そういったところですね。
もう1つは、攻めと守りの共存。数字はどんどん良くなってきていますが、その一方でテストなど守りの部分が足りているのかといったところは、今でも難しいなと思っています。
――数値をどのように扱うかなど、共通認識をつくっていく活動は導入初期のころからされていましたか？
木村：2022年6月ごろに「Findy Team+」のトライアルを始めて、指標が見えるようになってすぐに、DevOps委員会を立ち上げました。取り組みをリードするための委員会で、そこで施策やルールなどを話し合って決めていきました。
まず決めたのは、「Findy Team+」によって見えるようになった指標を、評価には使わないということ。そして、生産性の指標を向上させ、半年で2倍にすることを目標に掲げてスタートしました。
1PR200行以内、モブレビュー、自動化などの取り組みを実施
――これまでに行ってきた具体的な取り組みの内容について教えてください。
仙葉：いくつかありますが、サイクルタイムの改善に関しては大きく2つあります。まず1つは、1PR200行以内にする取り組みで、これは今もみんなに強く意識してもらっています。チケット作成の段階からタスクを分解して、なるべくPRサイズに分けるように、全体のなかで1PR200行以内を守る流れをつくっていきました。
もう1つは、レビューでの取り組みですね。初期のころは、レビューに3コメント以上かかる場合は、Slackのハドルミーティングで会話しようというルールを設けていました。それもきっかけにはなりましたが、より大きく変わったのは、積極的にモブレビューを行うようになってからです。
もともと一部のメンバーにレビューが偏ってしまっていて、そこがボトルネックになっていることは「Findy Team+」の数字からも見えていました。そうした状況から、レビューを出したときに集まれる人で集まって、みんなで声をかけ合いながらレビューするようになり、レビューのリードタイムがかなり短縮されました。
モブレビューを行うことによって、お互いの成果物をリスペクトし、その場ですぐにみんなで対応しようという文化が根付いていったことも良かったです。あとは、木村さんが取り組んできた自動化のところが大きいですね。
木村：仕組み的なアプローチはいくつか行っていて、まずは200行以上のPRが上がってきたらアラートが飛ぶようにしました。また、開発フローをよりシンプルにするため、もともとgit flowで開発していたのですが、GitHub Flowに変更しました。
開発から本番リリースまでの流れとしては、featureブランチで開発して、masterにマージしたら開発環境に反映。本番環境に反映するときはリリースタグを設定し、それを検知してデプロイする。要するに、masterブランチだけで開発するようにしました。
以前はmaster、developブランチ、QAブランチ、featureブランチといった多段構成になっていて、本番環境にデプロイするまでに面倒な手順が必要でした。なので、そこをシンプルにできたのは良かったと思います。
それから、デプロイまでの手順を削減するため、GitHubでmasterにリリースタグを設定しています。弊社では今Kubernetesを使っていて、GitOpsという手法でデプロイしています。Kubernetesの設定ファイルのイメージタグを、Dockerコンテナのイメージタグに書き換えることでデプロイされる仕組みで、各サービスのリポジトリでリリースタグをつくってKubernetesの設定ファイルを書き換えます。
その手順のなかで、もともとは前回のリリースのバージョンを目で見て、手動でリリースタグをつくっていたのですが、それを自動化しました。また、Dockerコンテナのイメージの書き換えは、もともとKubernetesのリポジトリに書き換えのPRが上がり、それをマージするフローでしたが、そのマージを自動化しました。いくつもあった手順を自動化して削減したところが、デプロイ頻度の向上につながったと思います。
あとは、基本的に1PR1デプロイが理想なのですが、CI/CDで時間かかるとデプロイを忘れてしまうという問題がありました。リリースタグ発行のPRが上がっても、そのCI/CDを待っている間に忘れてしまい、次のPRがマージされて、どんどんPRが重なってしまう。それが、変更のリードタイムが伸びる要因の1つになっていました。
そのため、CI/CDが終わってデプロイの準備ができたら、自動的にメンションで通知するようにして、気づきやすくしました。これらの取り組みのほかに、サイクルタイムの改善に効いたのは、フィーチャーフラグの導入ですね。
仙葉：そうですね。全体的な仕組みとまではいっていないものの、フィーチャーフラグに関して、フロントエンドやバックエンドでそれぞれルールを整備しました。フューチャーフラグの導入によって、ユーザーの影響を気にしてデプロイで待つことがない状態を構築できたのは、非常に大きかったです。
――そのほかにも、何か取り組まれた内容があれば教えてください。
木村：取り組みを始める前は、あまりデプロイとリリースを区別していなかったのですが、それをきちんと分けて定義しました。デプロイはユーザー影響がなく、いつでも行っていいもの。一方で、リリースはユーザー影響があるもので、何か起きたときに対応できるように土日祝日の前日は行わないというルールで始めました。
デプロイ頻度は約5倍、変更のリードタイムは約6分の1に
――開発生産性の可視化を通じて、メンバーの意識や行動で変化した部分はありましたか？
仙葉：前までは何も見えていなかったので、メンバーのなかでも漠然とした内容で会話されていました。可視化できるようになってからは、特定のメンバーは自分たちでも数字を見ていて、メンバーから改善の提案が上がってくるようになりました。そういったマインドが醸成されたことは大きかったと思います。
もう1つ、コミュニケーションの活性化にも大きくつながっていると感じます。モブレビューをするようになって、お互いの作業に興味を持つようになり、普段の開発やレビューのなかで細かく会話するシーンが非常に増えました。
――開発組織以外の方々からの反応はいかがでしょうか？
仙葉：ちょうどこれから、カスタマーサクセスとのオフサイトミーティングの場などで、可視化したものを見せていこうと準備しているところですね。今までは少し壁があったので、これから積極的に伝えていこうと考えています。
――実際に「Findy Team+」で導入直後半年と直近半年の数値を比べてみると、デプロイ頻度は約5倍、変更のリードタイムは約6分の1と、とても大きな変化が見られます。
導入直後の半年（2022/8/1〜2022/11/30）
直近半年（2023/9/19〜2024/3/18）
仙葉：そうですね。かなり改善しました。特に変更のリードタイムに関しては、直近の数値ではさらに短く、24時間を切るようになっています。
木村：最初に取り組みを始めたときは、数年放置されているプルリクなど、たくさんあった観測の邪魔になるものを片付けるところから着手しました。プルリクをクローズしたり、マージしていいものはマージしたり。あとは、「Findy Team+」のラベル除外機能が改善されていったので、それも活用しながら進めていきました。
直近28日間（2024/2/20〜2024/3/18）
攻めと守りのバランスを取りながら、継続的な取り組みへ
――開発生産性の計測による、ベネフィットを感じた部分について教えてください。
仙葉：ボトルネックが可視化され、課題に対する改善の働きかけができるようになったところがすごく良いと思っています。改善するためにはどうしたらいいかといった、話し合いのきっかけになるところも大きいですね。意見が違っても、数字が出ていれば心理的な読み合いになることがないので、施策を進める側も進めやすいです。
木村：今はDevOpsの大きなところを見ていますが、取り組みを始めたころは、PRの平均変更行数など細かなところの改善から進めていました。そういった細かい部分の数値が出ることでボトルネックがわかりやすく、対策のアクションにつながったと思います。
――開発生産性に関して、今後のトライとして考えていることはありますか？
仙葉：攻めと守りのバランスは、今後も課題になってくると思っています。今かなり良い流れをつくれているので、引き続き可視化しつつ、メンバー全員がそこに向き合っている意識の高いチームをつくっていきたいですね。
木村：引き続き「Findy Team+」を見ながら、ボトルネックがあれば対処していきたいと考えています。また、最近はGCPを使い始めて、SREに依頼して待つことが増えてきているので、できるだけ待ちが発生しないようにセルフサービス化を進めていきたいと思っています。
弊社で今メインで使っているAWSはTerraform化されていて、開発チーム主体でPRのやり取りだけで変更できますが、GCPはまだSREが手動でコンソール操作をしています。高頻度に変更する組織だと、依頼待ちがボトルネックになってしまうので、そこは対応していきたいです。
――「Findy Team+」のおすすめポイントを挙げるとしたら、どんなところでしょうか？
仙葉：やはり可視化が改善の第一歩になります。そこが今回、自分としても学びが大きかったので、そういったところがおすすめポイントになると思います。
木村：可視化は大事ですね。システムのパフォーマンスチューニングなどと同じで、まずは可視化してボトルネックを特定するところから、すべてが始まると思います。
――それでは最後に、御社の開発組織のアピールポイントを教えてください。
仙葉：自動化への取り組みはアピールポイントの1つだと思います。自動化はやりたいと思っていても、なかなかできないケースもあると思うのですが、そこにしっかり取り組むことができている組織です。
木村：技術刷新を前向きに行っていて、技術的負債への対処や生産性のボトルネックになりそうなアーキテクチャの改善も進んでいます。
例えばインフラでいうと、私が入社した当初は、AWSのEC2サーバーにSSHでログインし、バイナリを置いてデプロイするという、完全に手動の方法でした。しかし、今ではKubernetes基盤に乗せて、コンテナ化もされています。
フロントエンドも最近、Vue.jsからNext.jsに移行したり、モノレポへの移行も行ったりしていて、技術的なチャレンジができる環境があります。
――一緒に働きたいと思うエンジニア像はありますか？
仙葉：弊社では、「SmartMat」という物を乗せて重量を測るIoTデバイスをつくっていて、今まで取れそうで取れていなかったデータを可視化できるところが強みです。そういったデータを面白いと感じる方、データを活用して未来を創造していける方と、ぜひ一緒に働きたいですね。
木村：同感です。あとは、やはりスタートアップなので、主体的に課題を見つけて、オーナーシップを持って動ける方が向いていると思います。
――仙葉さん、木村さん、ありがとうございました！
※スマートショッピングでは、エンジニアを募集しています。
※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
