みなさんは「保守・運用」と聞くとどのようなイメージをお持ちでしょうか？
もしかしたら良いイメージをお持ちでない方もいらっしゃるかもしれません。
しかし、売り上げを生み出している既存コードの保守運用はビジネス上、新規機能開発と同等かそれ以上に重要な存在です。
保守運用は歴史あるサービスでは欠かせない作業ですが、STORESもその例外ではありません。
STORESの最初のコードが書かれてから、8年の歳月が経ちました。
今となってはコードの量も多く、今年(2020年)の8月に入社した私(@zakky)も全体を把握しきれてはいません。
STORESにジョインした最初の1ヶ月間、「商品の在庫数を一括で更新する機能」の開発に私は専念しており、その他の機能のコードを触る機会がほとんどありませんでした。
目の前のチケットを消化していくのに必死で、周りを見る余裕が無かったとも言えます。
「運用週」との出会い
入社して1ヶ月が経ち、少しSTORESでの開発に慣れてきたタイミングでメンターから、
「じゃあzakkyさんは来週から1週間、運用週に入ってもらうね」
との言葉をもらいました。
STORESにおける運用週とは、1週間プロジェクトから離れて以下の運用・保守作業に専念する週のことを指します
- 社内メンバーからの依頼対応 (ログの抽出依頼や不具合報告などを受けることが多い)
- 外部決済サービスのメンテナンス対応
- 突発的な障害への一次対応
- 発生したエラーへの対応(日常的なエラーはSentryで捕捉しています)
- 社内メンバーの手作業の効率化
- etc ...
下記画像のように各チーム内でローテーションを組み、定期的に運用担当としてアサインされる仕組みです。
「運用担当」という言葉を聞くと身構えるかもしれませんが、体験してみて非常にこれは上手い仕組みだなと感じました。
以下、運用週について私の体験ベースで紹介していきます。
プロジェクト外の機能に触れるチャンス
売上の振込機能
入社してから1ヶ月間、商品の在庫数のことしか考えていなかった私でしたが、初めての運用週でアサインされたタスクは、
「ストアオーナー様が設定している売上振込先となる銀行口座の変更履歴をもっと多く表示してほしい」
という社内要望への対応でした。
これなら軽くできるだろうと思って取り掛かりましたが、実際には下記のように複数の概念が絡んでくる箇所でした。
- 「振込先口座」という情報はどういうデータモデルで表現されているか
- 口座に振り込む金額、すなわち「入金代金」の計算はどうなされているか
- 入金時に発生する「手数料」の計算はどうされているか
- 入金の特別対応の機能である「スピードキャッシュ」はどう実装されているか
これらの情報が書かれているコードを読んでいく中で、STORESの入金周りの仕様がだんだんと理解できました。
この運用作業に入る前も、たまに「入金処理」という言葉を同僚から聞いたり、社内Slackで飛び交っているのを目にしたりしていましたが、
やはり実際にコードを確認し、その上で実際に管理画面を触ってみると理解が深まるなと実感しました。
外部サービスを利用した決済機能
そうして入金周りのコードを見ていると、今度はSTORESが契約している決済サービス事業者からのエラー通知が送られてきました。
ちょうど運用チーム夕会のタイミングだったので、運用メンバーで集まって画面共有をしつつエラー内容を見始めました(DiscordやGoogle Meetを使うことが多いです)。
( 運用チームは毎日、昼会と夕会を行いコミュニケーションを取っています )
STORESでは各種外部決済サービスと連携しているため、こうした外部サービスから送られてくるエラーへの対応も行います。
こうしたエラーに対応するためには、以下の業務知識が必要になります。
- STORESが契約している外部決済サービスは何か
- 外部決済サービスのAPIを叩いているコードはどこに書かれているか
- 外部決済サービスが返してくるエラーコードの種類と意味は何か
- 各エラーコードが返ってくるケースとしてはどういうものがあるか
- そもそも決済の前段階で発生する「商品の注文」はどういったフローとロジックで行われるか
私はSTORESに入るまでは各種決済サービスの仕組みについて全く理解しておらず、
まずはクレジットカードの決済の仕組みについて学ぶところからスタートしました。
クレジットカード決済の仕組みだけでなく、STORESが利用している各種外部サービスについて理解が進むと、
次第にビジネスサイドの方々がSlackで話している内容も分かるようになってきました。
最近では連携している決済事業者様との打ち合わせに出たり、決済関連のコードをプロジェクト内で書くことも出てきましたが、
運用週で取組んだおかげでキャッチアップがスムーズにできました。
運用作業がプロジェクト進行に良い影響を与えているな〜と感じます。
運用週は自然とプロダクト理解が深まっていく仕組み
考えるまでもなく、「ストアオーナーへの売上入金」も「外部決済サービスとの連携」も、STORESというサービスにおいて超重要な機能です。
にも関わらず、私はそれらを実装しているコードに触れることなく機能開発を進めていました。
もし運用週という仕組みがなければ、プロジェクトのスコープ外のコードに触れる機会がなく、突発的な障害や社内外からの問い合わせに対応できるメンバーが限定的なままだったことでしょう。
実際に同僚からも、「前いた会社では障害が起きても、『この機能はAさんしか分からないからAさんじゃないと直せない』という状況があった」という話を聞いたことがあります。
こうした属人化した状況を改善するための仕組みとして、運用週は上手く機能していると感じています。
おわりに
「運用・保守」と聞くと、決まり切った単調作業を繰り返すというイメージがあるかもしれません。
今のところSTORESでは、運用作業といってもGUIを手順書に従ってポチポチすることは少なく、むしろコードを書いて対応することが多いです。
その場しのぎの対応に終始せず、「そもそもこの運用作業を自動化できないか？」という観点から新機能を作成することもよく見かける光景です。
なので運用週でもコードを書きますし、普段のプロジェクトにもその経験が活きてくるという正のサイクルが回っている仕組みです。
また、運用作業を通して直にユーザーの悩みや疑問に触れることができるため、ユーザーの顔が見えない開発にはならないというのもメリットとしてあるかなと思います。
というわけで、heyでは自社サービスへの深い理解をしながら開発をしていきたいエンジニアを募集中です。
もちろんエンジニアのみならず、デザイナー、PM、CS、セールス、コーポレートなど全職種で採用活動を促進中です！
興味のある方は是非とも採用ページをご確認ください！ぜひ私たちと一緒にお仕事をしていきましょう！
