ユーザードリブン開発は1人ではできない【Engineer's voice#2】
スマレジ開発本部バックオフィスチームのOです。
今回はスマレジにおけるリーダーエンジニアの働き方だけではなく、私が業務の中で大切にしていることについてもお話していきたいと思います。
〜まずは簡単に自己紹介〜
■エンジニア歴：12年
前職はSIerのプロジェクトマネージャー。住宅メーカー向けのシステム企 画・開発に従事していました。
■スマレジ入社：2020年7月
転職理由は、マネージャーとしての管理業務だけではなく、自分でもコードを書くなど手を動かしたかったため。プレイングマネージャとして働ける環境が魅力的だと感じました。
開発部門にバックオフィスチーム？
実は、入社当時はPOSレジの開発を担うPOSチームの配属。サーバーサイド開発を担当していましたが、入社半年ほどで現在メインで担当しているお客様の契約管理や請求管理などの社内システム開発をも兼任しはじめ、入社1年後にはバックオフィスチームの専任、チームリーダーになりました。
背景として、私が入社した2020年頃、ありがたいことにユーザー数も増加し、全社的にお客様の契約管理や請求管理などのバックオフィス関連業務が増大していました。早急に業務改善を推進する必要があったため、専任で担当することになりました。
「管理業務」と「開発業務」の絶妙なバランス
そんな過程を経て、現在はバックオフィスチームのリーダとして、社内システムやお客様向けマイページの開発・運用を行なっています。より具体的には、以下のような業務が発生します。
■営業本部・CS部・管理部など関連部署への要望のヒアリング
■リリース計画の策定
■メンバーのタスク管理／レビュー
■設計／実装
■問い合わせ対応など運用作業
おおよそ3〜4割がメンバーマネジメントなどの管理業務、6〜7割が自身でも手を動かす開発業務という割合で、まさに転職時に希望していた“プレイングマネージャー”として働くことができています。
スピード感とメリハリのある開発
さまざまなタスクがある中で開発スケジュールをどう立てるか。
私のチームでは「関連部署からの要望」と「エンジニア発信での改善（リファクタリングやテスト環境整備）」の主に2つの観点で業務が発生します。そのため「今月は関連部署からの要望対応をやろう」「来月はエンジニア発信での改善に注力しよう」などと、チームの裁量でスケジューリングし、メリハリをつけながら開発を進めています。
上長やお客様の承認がないと開発が進められなかった前職のSIer時代と比較すると、スピード感が全然違うと感じています。
というのも、私が当時在籍していたSIerでは、要件ヒアリング -> 見積 -> 上長承認 -> お客様承認・発注 -> 開発のようなフローが定石。一方で、スマレジでは自分たちで関連部署へ要望や困りごとをヒアリングし、スケジュールも決めるため、要件ヒアリング -> 見積 -> 開発のようなフローで開発が進んでいきます。
また、開発スケジュール以外にも、
■開発プロセス（アジャイル的なアプローチをするかウォーターフォール的なアプローチをするか）
■技術選定（どういう技術を使って機能を実現するか）
なども基本的には開発チーム内で最適な手段を考えて決めており、裁量権の大きさはスマレジのエンジニア組織の特徴ではないかなと思います。
思わず頭を抱えた、新プランの登場！
ユーザーが増加することで、ご要望の数が増加するだけではなく、多種多様なご要望をいただくことが増えてきました。例えば、
■人件費を含めた売上分析がしたい
■売上傾向を見ながらシフト調整をしたい
■店舗の生産性を可視化したい
etc
POSレジのスマレジと勤怠管理システムのスマレジ・タイムカードを連携することで上記のようなニーズにお応えできるよう、2022年1月にタイムカードの新機能（人時生産性・人時売上高）をリリースすることになりました。
そのリリースと同時に、複数のプロダクトをご活用いただいているユーザー向けに新プランを追加することになりました。スマレジ（有料プラン）とセットでご利用された場合には値引きがあるプランです。
開発を担う私としては、スマレジのお客様とスマレジ・タイムカードのお客様のプラン変更や月額請求の仕組みの設計に非常に苦悩しました。
■タイムカードの新機能（人時生産性・人時売上高）と同時リリースが必要でありスケジュール面の制約があった
■担当プロダクトのほぼ全機能への影響があったが、チームにjoinして1年未満だったこともあり知見がない機能もあった
■スマレジとセット値引きの仕組みがあり、仕様上考慮すべき点が多かった etc…
そんな状況下で取り組んだのは、事前にソースコードの確認・実装当時のメンバーに既存仕様の確認などをした上で計画を立てたこと。既存タスクの優先順位やリリース時点でMUSTの内容がどこまでかなどを整理し、リリースに間に合うよう関連部署とも調整を重ねました。
また、お客様がアカウント作成されてから解約されるまでのフローから考慮すべきケースを洗い出し、各ケースでどういうデータ状態になるかなどを整理しながら設計を行いました（例えば、セット値引き利用中にスマレジだけ解約や無料プランに変更した場合にどうなるか？など）。
考慮漏れが出ないよう、とにかくあらゆるケースを洗い出し、無事にリリース日を迎えることができました。正直、大変だったことはここに書き切れないくらいたくさんありますが（笑）、印象深い仕事の1つです。
本質の先に、自ずと“手段”は見えてくる
仕様検討など、エンジニアに主導権があるからこそ意識していることがあります。それは、 ユーザの課題を本質的に解決していくこと です。
例えば、関連部署から要望があがってきた場面。「その要望の背景にどういう業務があり、その中のどんな課題を解決したいのか」そして「その課題を解決するための手段としては何が最適なのか」を常に意識してヒアリングし、解決策を考えるようにしています。
本質的な課題を捉えることができれば、新たな機能を実装するという選択肢以外にも、既存機能の運用の工夫であったり、軽微な改修で課題を解決できることも往々にしてあります。そうすれば、別の要望や改善に工数を割くことができ、よりユーザーのためになるプロダクト開発を推進できるはずです。
技術は手段。ユーザーの課題解決に、部署の垣根は作らない。
「ユーザーのためになるプロダクトをつくる」
この意識は、私個人だけではなく会社全体で浸透しているように感じます。
担当しているプロダクトがバックオフィス業務を担っていることもあり、様々な部署の方から要望を受け、仕様の調整などを行いながら開発を進めますが、エンジニアが機能開発をするのはあくまで課題解決の手段の一部。運用含めた解決策を、部署の垣根なく検討できる環境だと感じています。
例えば、要望に対して100%の状態まで開発してリリースするにはどうしても工数が大きくかかる場合、一旦50%の状態でリリース、残りの50%は運用でカバーすることで最終的にやりたいことをよりスピーディに実現する、といったことも他部署の協力により実現できています。
実際に何か機能を実装して、ニーズにお応えできた時はもちろん嬉しいのですが、運用方法の提案によって課題が解決した時の方がより嬉しいと感じることが多いです。他部署の方と一丸となって課題解決をしていくことはとても達成感を感じますし、大きなやりがいになっています。
今回はスマレジのリーダーエンジニアの働き方、そして私が業務の中で大切にしている「課題解決」の考えについてお話してきましたが、いかがでしたでしょうか。
本記事を通じて、スマレジのエンジニアの働き方を少しでもお伝えできていれば幸いです。
〜おすすめの参考記事〜
＼「めちゃくちゃ良い！」を作るエンジニアを募集しています／
