見出し画像

黒子に徹さない、全員主役の組織力が強み<開発部インフラチーム紹介>

スマレジのさまざまな部署にスポットを当て、仕事内容をご紹介する【スマレジ部署紹介】。今回は、開発本部インフラチームについて、課長のSさんにお話を伺いました!


サービスの成長の裏で
緊急度が高まるインフラの「自動化」


ーー現在のインフラチームの体制を教えてください!

インフラチームでは、スマレジが提供する全プロダクトのインフラを管轄しています。チーム内は基本的にプロダクトごとの担当制を敷いていて、主担・副担を決めています。スマレジにはいくつかプロダクトがあるので、一人あたり複数のプロダクトを担当しています。

現状は社歴が浅いメンバーも多いので、ナレッジ習得のためにも担当のローテーションはしていませんが、その方のご経験やご希望を考慮した上で担当を決めています。特にご希望がなければ、特に人手が足りていないプロダクト担当にアサインしていますね。

▽さまざまな店舗向けサービスを展開する当社の事業

ーープロダクトによる業務の特徴はあるのでしょうか?ユーザー規模などにも違いがありますよね。

ユーザー数の増加に伴った対応であったりとか、影響度合いはプロダクトごとに異なりますし、どうしても優先度には差が生じます。ただ、少し前はメインプロダクトのスマレジPOSが最優先だったのですが、最近だとスマレジ・デベロッパーズで提供しているプラットフォームAPIの部分に関するインフラ対応の優先度が高まっていますね。おかげさまで近年デベロッパーさんの増加とともに、開発されるアプリ数やアプリの利用者数が増え、プラットフォームAPIのリクエスト数も日々増えてきていて。でも、プラットフォームAPIのリクエスト数が急増した場合のインフラの対応があまり追いついていないのが現状なんです。

ーー例えば具体的にどんな対応を取られているのですか?

要はAPIのリクエスト数に対して裁ききれていないイメージなので、できる限り自動的にサーバーをスケールさせる仕組みを作って、色々と試行錯誤している段階です。

というのも、お客様には大変申し訳ない状況なのですが、現状レスポンスが遅くなるような事象が発生してしまうこともあるので、早急に改善してお客様への影響を最小限にしたいと考えています。

▽「スマレジ・デベロッパーズ」について

限られた条件下での課題解決こそ、
エンジニアリングの醍醐味

ーー現在採用活動ではどんな方を求めていますか?

もちろんドメイン知識を持っているに越したことはないです。シニアクラスだとやはりAWSの経験も求めていますね。あとは、先ほどもお話したような、大量のリクエストを効率よくさばいてきたご経験があれば、かなりありがたいなと。

技術スキル以外で言うと、自ら課題立案して解決まで導いた経験も魅力的ですね。指示待ちではなく常にアンテナを貼りながら「もっとこうした方が良いのでは?」と自分で課題を見つけて実装して、解決に向けてリードしていただける方と出会えたら理想ですね。

ーー実際に何か課題解決につながったエピソードはありますか?

最近あったものだと、例えば勤怠管理システムの「スマレジ・タイムカード」だと、勤怠登録の機能があるので、朝晩の出退勤の時間帯でリクエスト数が増えるんですよね。逆にそれ以外の時間帯はそこまでリクエスト数が多くないというサービス上の特徴があります。

以前はピーク帯に合わせた性能を持つサーバーを用意してたので、リクエスト数が少ない時間も、高スペックなサーバーがずっと稼働していたのですがそれだともったいないのでは?という意見が出て。そこでピーク時間帯に合わせてサーバーの台数を調整することでコストを最適化できた事例がありました。

▽勤怠管理システム「スマレジ・タイムカード」

ーーコストについては普段から意識している観点なのでしょうか?

そうですね。やはりスマレジをリリースした当時はどうしてもお金がなくて、お金がない中でどうやってインフラを維持していくかを常に考えていたので、今もその名残はあると思います。お金を無尽蔵に使えてたらもっとできることもあったと思うのですが、 限られた予算の中で最良の手段を考えることもエンジニアリングの醍醐味だと思うんですよね。

今は多くのユーザー様にご利用いただいていて、インフラにかけられる予算も増えていると思うのですが「じゃあそれって誰のお金なの?」って話で。僕たちが使えるお金は元を辿ればスマレジユーザーの皆様から頂いた大切なお金なんですよね。当然お客様にとって貴重なお金だからこそ、あればあるだけ湯水のように使うんじゃなくて、誠実に使わせていただく必要があると考えています。

この話はメンバーにもよく言ってますし、むしろ限られた条件内で工夫するのが面白いと感じてくれるメンバーが集まっているように感じます。

「SRE」の概念が生まれる前から、
自然とSREをやっていた!

ーーその他、求める人物像やスキルなどありますか?

スマレジのインフラチームの特徴の1つとして、開発メンバーとの距離が近いという点があります。昔から開発メンバーから一方通行で依頼を受けて対応するというよりは、常に議論しながら仕事を進めていく風土があって。インフラメンバーにとって、開発サイドのニーズを引き出しながら提案ができる高いコミュニケーション能力が重要なんですよね。

また、現在はサービスインフラだけじゃなくて、社内インフラもやっているので、社員からいろいろな問い合わせが来ます。問い合わせの時点である程度内容が明確なものも当然あるのですが、中には不明瞭なものもあります。そういった場合に詳細をヒアリングしながら、どこに課題が潜んでいて理想の提案が何かを考えるスキルが求められます。

このように関係者とコミュニケーションを取る必要がどうしても生じるので、技術スキルも大事なのですが、 やはりコミュニケーション能力はかなり重視していますね。

ーー”エンジニアとの距離の近さ”について、何か具体的なエピソードはありますか?

例えば当社では、サービスのレスポンスが悪い状況が検出されるとSlackの通知でアラートが来るようになっています。その際、まずはインフラチームが調査し、原因がインフラではなくてサービス側に起因していると思われる場合は、開発チームを巻き込んでどこがボトルネックになってるのかを一緒に探します。

対処方法として開発チームにプログラムを修正してもらうこともあれば、インフラチームで暫定的にスペックを上げたりと、ユーザーさんへの影響を最小限に留められる方法を共に模索し実行するのですが、こうした過程でエンジニアメンバーとの連携やコミュニケーションが欠かせないんですよね。

最近だと「SRE(Site Reliability Engineering)」という職種が生まれたりもしていますが、イメージはそれに近いのかなと。僕自身が元々開発エンジニアでもあったので、SREという概念が生まれる前からSREのような仕事をしていたという経緯も影響しているかもしれません。

ーー開発側にも興味がある人は合いそうですね。

そうですね。開発チームと一緒にプロダクトの価値を高めて社会にインパクトを残したい!みたいな方は合うのかなと思います。逆に「インフラ作って終わりです」みたいな方は合わないかもしれないですね。「もっと自分もプロダクトにコミットしたいのに」みたいな感じでうずうずしている方がいたら、ぜひ来てほしいなと(笑)。

ーーそうですね(笑)。実際に、開発経験は必要なのでしょうか?

開発経験があると、開発メンバーとのコミュニケーションが取りやすくなるとは思うので、あればすごくありがたいですが、 必須ではないですね。むしろインフラもやってるけど、実はプログラミングにも実は興味があって、みたいな方も大歓迎です。

全員で意思決定・全員で解決!
インフラチーム流の組織づくり

ーー技術面のお話を伺ってきましたが、インフラチームの雰囲気や組織の特徴などがあれば教えてください!

今は大阪と福岡にメンバーがいるので基本的にはオンラインでコミュニケーションを取っています。日頃意識しているのは、何か意思決定をするときはチーム全員の合意を取るということです。必ず全員でディスカッションをしてから決めますね。

他にも最近取り組んでいるのが、チームMTGでファシリテーターを交代制にすることです。元々僕が担当することが多かったのですが、オンラインのMTGって発言が被ったりするのもちょっと怖いし、チームの中で喋る人と喋らない人みたいなのが生まれがちじゃないですか。なので全員が平等に喋る機会を得られるようにしているのと、僕がファシリをやる時は、結構名指しでバンバン当てちゃいます(笑)。

あとは当然ですが誰かの意見を否定しないとか、1on1の冒頭でアイスブレイクを大事にするなど、できるだけ心理的安全性の高い組織でありたいなと考えています。

インフラ観点でプロダクトに向き合い、
「チームでできた!」を増やしていく

ーー業務や組織づくりに対してさまざまな取り組みをされていることが分かったのですが、逆に現状課題に感じていることはありますか?

冒頭にもお話しましたが、ユーザー増加に伴う対応がまず1つですね。ありがたいことに導入店舗数がどんどん増えていったり、アプリマーケットもアプリがたくさんリリースされる中でAPIの増加に対してインフラがまだまだ不足しています。

スケールの仕方はいくらでもあると思うので、これまでのご経験やナレッジを活かして新しいやり方をぜひ提案していただきたいです。サービス規模の大小はあまり関係なくて、ユーザー拡大期におけるリクエスト増への対応経験はかなり活かせる環境かと思います。

2つ目は属人性をなくすことです。元々僕が1人目でやってきたところと、その後2人体制の期間が結構長かったので、属人的に仕事をしている部分が少なからずあります。具体的に言うと、アラートが上がった時の対応って、ある程度経験値がモノを言う部分があるんですよね。そういう経験を別の人にも重ねてほしいなと思いつつ、ユーザーさんのことを考えると確実に速く対応したいというジレンマがあります。ベテラン社員のナレッジをいかにチームメンバーに共有していくかが今後の鍵になってくると思います。

ーー確かに悩ましいところですね。詳しくお話ありがとうございました。それでは、最後に読者の皆様に一言メッセージをどうぞ!

インフラの仕事って、 昔は作って終わりみたいなところがどうしても多かったと思うんですよね。自分の仕事が貢献した部分がなかなか見えづらかったというか。そして、開発エンジニアに比べると、プロダクト開発においてどうしても日の目を見にくい、みたいなところもありましたよね。

その点当社のインフラチームは常にプロダクトに向き合うことが大前提なので、実際に世の中の「便利」を作れたとか、それこそスマレジが掲げる「お店を元気に、街を元気に!」のように、社会的なインパクトを実感しやすいと思います。

あとは先ほどもお話したように、何事もチームで決めていくカルチャーが根付いていますし、何か問題が起きたときはチームで解決する体制なのでこれまで少人数とか1人でインフラ担当をされていた方など、もっとチームで1人でできないことをやってみたいと考える方には、望んでいる環境を提供できるかなと考えています。

「チームでできた!」と思えるような、皆で達成感や一体感を感じられるチームでありたいですね。


今回は当社のインフラチームについて、詳しくご紹介しました。開発メンバーとともに、社会に価値を届けるインフラチームの魅力が伝われば幸いです。

現在インフラチームでは、新たなメンバーを大募集中です!少しでも興味を持っていただけた方がいらっしゃれば、ぜひお気軽にお問合せくださいね。


〜おすすめの参考記事〜

\「めちゃくちゃ良い!」を作るエンジニアを募集しています/