「お客様に良いものを作って届けたい」ECサイトにおける開発生産性とサービス信頼性の向上に取り組むテックリードの挑戦
※本記事の内容は取材時のものであり、組織名や役職等は取材時点のものを掲載しております。
モノタロウではビジネスの成長に伴い、エンジニア組織も拡大を続けています。組織規模が大きくなってもアジリティをもって開発を進めることと同時に、成長を続けるECサービスにおいても信頼性をもって安定的にお客様に価値を届けることが重要になってきています。今回当社でDevOpsとSREを担うエンジニアの伊藤さんに、これらの取り組みとモノタロウで働く魅力などを聞きました。
仕事の「再現性」への挑戦、キャリアの幅を広げるチャンスを求めて
ーーこれまでのご経歴について教えてください。
現在社会人としては14年目で、大学を卒業して最初の3年半は受託開発会社でプログラマーとして働いていました。その後QAサイトを運営する会社へ移り、およそ10年間で開発エンジニアやプロジェクトリーダーを務め、最終的にはテックリードとして主にバックエンドのシステム開発に携わりました。最後の2年ほどは、オンプレからクラウドへ移行する際のアーキテクチャ設計、TDD（テスト駆動開発）やDDD（ドメイン駆動開発）といった開発手法の実践に取り組んでいました。この他にもスクラムマスターとしての活動や、メンバーとの1on1を実施し技術的なサポートを行ったり、輪読会を催したりして考えやアイデアのすり合わせを促すなど、チームビルディングにも携わっていましたね。そこからモノタロウへと移り、現在に至ります。
ーー転職をしようと思ったのはなぜでしょうか？
理由は2つありまして、一つは、どんな会社でも、より規模が大きいシステムでも、テックリードとして通用するか、仕事の「再現性」にチャレンジしたかったからです。もう一つは、DevOps／SREエンジニアとしてのスキルや経験も得たいと考えていたからです。これまでは開発エンジニアとしてコードを書く機会が多かったのですが、ただシステムを開発するのではなく、開発したものをより信頼性をもって安定的にユーザーに届けることに興味が湧いていました。ですので、大規模システムを持っていて、運用や保守がいっぱいあるような会社に行きたいと考えるようになり、転職を思い立ちました。
ーーモノタロウを選んだ理由は何でしたか？
モノタロウを選んだ理由は大きく2つあります。一つは、自社で大規模なデータやシステムを扱っているという点です。もう一つは、やはり事業が安定して成長している点です。事業の成長が停滞している会社ですと、開発のために必要な予算を確保することが難しくなってくるなど、どうしても仕事やキャリアの幅が制限されてしまいがちです。モノタロウのように右肩上がりに成長を続けている会社だと、自分のキャリアを広げるチャンスが多いのではと考えていました。何かやりたいというときに挑戦できる環境があり、もし仮に「ちょっと違うな」と思った場合でも、別の方向性で違ったチャレンジができる機会があるなと感じていました。
また、はてなブログやnoteなど、エンジニアが目にしやすいメディアで積極的に情報発信が行われている点もモノタロウを選ぶキッカケになりました。モノタロウのエンジニアは決して受け身ではなく、チャレンジ精神を持って事業に取り組んでいることが、発信情報から想像できたのが良かったです。
はてなブログで運営しているモノタロウのテックブログはこちら！
DevOpsの推進とSREの実践
ーー伊藤さんの現在の主な取り組みについて教えてください。
現在は業務のキャッチアップとしていろいろと行っていますが、主に開発チームの生産性の計測、可視化とその分析といったDevOpsの仕事と、検索システムのSLO（Service Level Objective：サービスレベル目標）作成といったSREの仕事に取り組んでいます。
まず、DevOpsについてですと、Four Keys（※1）を参考にし、各部署のメンバーやマネージャーの方々からフィードバックを得ています。モノタロウの組織、開発現場の実態にあった粒度で分析ができるように適宜オリジナルを加え、計測する指標の定義から集計、可視化を進めてきました。現在は、見つかった改善点を克服するためのプロジェクトも発足し、その中で例えばカナリアリリースといった施策を立てて、実行しているところです。
また、システムやアプリケーションの処理時間・コストなどを開発者、運用・保守者の双方の目線で可視化し、パフォーマンスチューニングやキャパシティプランニングにつながるように仕組み化を進めています。
もう一つのSREについては、単純にシステムがちゃんと稼働しているかどうかだけでなく、ビジネス的なコンテキストが保たれているかどうか、サイトの反応速度や安定性などの観点でユーザーにとって使いやすいサービスとなっているか、といったモノタロウが提供するサービスの信頼性に関わる指標の作成を行っています。SREチームではSREの本家であるGoogleのエンジニアから研修を受けながら、これまでにECサイトでのSLO作成やオンコール体制の構築といったSREのベストプラクティスを反映してきました。取り組みをはじめてから半年程かけて、フロントエンドで実践をはじめ、バックエンドシステムや基幹システムへの普及はこれからといった状況です。フロントエンドでのSREの実践も完ぺきではないので、改善を進めつつ、バックエンドや基幹システムへSREを普及させていこうとSREチームが一丸となって取り組んでいます。
※1
Four Keysとは：Google社のDevOps Research and Assesment (DORA) チームが実施した 6 年間の研究の結果定義された、ソフトウェア開発チームのパフォーマンスを示す 4 つの指標のこと
引用：
DevOps Research and Assessment（DORA）チームが実施した 6 年間の研究から、ソフトウェア開発チームのパフォーマンスを示す 4 つの指標が確立されました。
デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
変更のリードタイム - commit から本番環境稼働までの所要時間
変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）
サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間
概要レベルでは、デプロイの頻度と変更のリード時間は速度の指標であり、変更障害率とサービス復元時間は安定性の指標です。チームはこれらの値を測定し、継続的に改善を繰り返すことで、ビジネス成果を大幅に向上させることができます。
Google Cloud：エリート DevOps チームであることを Four Keys プロジェクトで確認する
ーーでは、現在の取り組みを今後どのように進化させていきたいとお考えでしょうか？
DevOpsに関してですと、現状難しいと感じているのは、指標を可視化することがゴールでないということですね。最終目標は開発生産性を上げて、ECサイトを利用されるユーザーの方々にいかに満足いただけるシステムを作れるか、ということだと考えています。そのために、各エンジニア、チームが自律的に開発のフローの中でどこに課題があるのか、どこが強いのか、現状どれぐらいの開発生産性があるのかを把握し、改善のフィードバックループを回していけるようになることを目指して取り組みを進めていきたいと思っています。
SREについては、モノタロウのシステムはいわゆる大規模システムで、検索システムや基幹システムなどは他のシステムとも多く結合していて、SREの適用、普及、実践する事自体のハードルが高く難しいと感じています。担当している検索システムの運用監視周りではビジネスの成長に追い付いていない部分もあり、問題が起きた時の対応が過剰、または不足してしまうこともあります。まずはこれらの面を是正していきたいと思っています。まだ挑戦のまっただ中ですが、将来的に業務部門とも協力し、システム観点だけでなくユーザーやビジネスの観点に加え、そのうえで提供するサービスの信頼性を定義して、会社全体でサービスレベルを向上していきたいと考えています。
根本にあるのは「お客様に良いものを作って届けたい」という思い
ーーエンジニア目線でモノタロウの魅力を教えてください。
研修が豊富なことがエンジニアとして非常に魅力的です。本家のGoogleのエンジニアの方からの研修や一緒にワークショップをしたり、また技術アドバイスをいただいている著名なエンジニアである和田卓人さん（@t_wada）との定期的なミーティングがあり、そこでのフィードバックだったりから、大きな気付きや学びを得ることができています。
また、行動規範でもある「他者への敬意」が全社的に浸透していることを感じられるのも魅力だと思っています。たとえば、障害報告のミーティングでも非難はなく、アクションアイテム（改善項目）の作成といった改善にフォーカスし、建設的に議論が進められています。
また、大規模な環境でのパフォーマンス改善はチャレンジングかつエキサイティングです。監視やSLO作成といったものもスケール感が大きく、良い意味で「エンジニアとしての実験の場」が多いことに魅力を感じています。
あとは、労働環境ですね。大規模なアプリケーションの運用や保守は休日や深夜の突発的な障害対応が多いイメージでしたが、モノタロウはサービスの特徴的に平日の日中がメインのビジネスの時間帯で最も商品の購入が多いため、深夜や休日の突発的な対応が少ないのかなと思います。ですので、それこそ家庭を持っている方でも安心して働ける環境だと思います。私自身、月の残業時間は多くて20時間、平均すると10時間程度です。
ーー逆に、改善点したほうが良いことも教えてください。
エンジニア自身での学びの文化がより発展すれば良いなと思っています。現在でも「ManabiCon」という社内テックカンファレンスがありますが、それに留まらず、外部の勉強会に参加したりほかのエンジニアと交流したりという動きができればと思います。これは自戒の意味も込められていますけどね(笑)。もう一つは自動化、属人性の排除です。これは事業成長が早く、人員だったり組織の拡大が追い付いていない側面が大きいと思いますが、仕組み自体を構築して問題を解消し、そのうえでより本質的な仕事へ取り組めるようになりたいなと考えています。
ManabiConに関する記事はこちら！
ーー最後に、今後チャレンジしていきたいことを教えてください
これまでのキャリアでは開発者として務めてきましたが、今後はその中で得た経験を活かしつつ、DevOpsやSREの領域で更に経験を積んで運用や保守のプロを目指したり、大規模システムを支える一員になったり、そのためにテックリードとして技術面で組織への貢献を達成したいと考えています。根本にあるのは「お客様に良いものを作って届けたい」という思いです。
開発者として「作る」ことも大事な一方、運用・保守者として「届ける」ことも大事だと、これまでの自社サービスの開発経験の中で感じています。また、いろいろなことができるようになれば、それが武器となり、仕事としてできることも広がります。そうなれば仕事自体がより楽しくなるだろうと考えています。
ーー伊藤さん、ありがとうございました！