プロダクトを丁寧に育てるということ

PROFILE

三田 英一

楽楽勤怠開発1課 テックリード

SIerにて活躍後、2014年にラクスに中途入社。当時はまだ新規事業だった楽楽明細の開発担当に着任。現在は楽楽勤怠の開発を行うと共に、エンジニアが自発的に考え、助けあえるチーム構築に取り組んでいる。

現在のチームでの担当範囲・役割を教えていただけますでしょうか。

現在は楽楽勤怠のサービス開発担当、テックリードの2つの役割を担っています。

楽楽勤怠のサービス開発では、アーキテクトとして技術選定やアーキテクチャ検討からアプリケーションの設計/実装/テストとと言った実作業まで担っています。現在開発している案件ではKotlinやGraphQL、コンテナを開発に取り入れることにチャレンジしています。同時に、現場感覚を失わないように、コーディングやテストなど実際に手を動かすことも大事にしています。テックリードとしては、全社的な開発者体験(DX)や生産性向上に寄与するような、例えばGitHub Copilotの導入を推進したり、読書会や勉強会、各種情報共有などを通じて社内のコミュニケーションの活性化と技術力の底上げに努めています。

“納品して終わり”ではなくプロダクトを育てたかった

そもそも転職されようと考えた背景を教えてください

前職はSIerだったのですが、受託で開発を行うため、カットオーバーすると次の開発現場に異動になることが多くありました。

自分がつくったシステムにはもちろん愛着があるのですが、世に出したそのシステムがユーザーにどのように評価されているのか、改善されていくのかまでを知ることはできませんでした。そのため、プロダクトのライフサイクルのうちごく一部しか関われない寂しさを感じていました。

また、プロジェクト期間中、いちエンジニアである私はシステム全体の中のごく一部にしか携わることができませんので、スキル面でも偏りが出てきていることにも将来のキャリアを考えると不安を覚えていました。

そのため、自社プロダクトをもつラクスに興味をもち、転職することにしました。

入社当時のことを教えてください

入社してから関わった楽楽明細は2013年にローンチしたサービスで、私が入社した2014年当時はまだ営業や開発もあわせて10人ほどのチーム。顧客企業も数社しかいない新規事業でした。

当時からWebで帳票をつくって、ダウンロードを促すといったコアとなる機能はあったのですが、まだ顧客ごとに機能をカスタマイズする管理機能等は揃え切れておらず、いざ導入時に要望をいただくと、プログラムやデータベースを直接いじったりしていたこともありました。そのため、本当に顧客ごとにいちから機能開発をしているようなものでしたね。

最初は「プロダクトの裏側ってこんな感じなんだ」と思いました(笑)

それから少しずつ少しずつ整備をしていきました。正直大変なこともありましたが、とても改善のしがいがありましたよ。入社する前もそれなりにキャリアはありましたが、初めて体験することも多く学びが多い時期でしたね。

入社2ヶ月目で開発した郵送代行機能。
愛着をもった機能の申込数が増えていくのが嬉しかった

これまで、楽楽明細に関してさまざまな開発に携わってきたと思いますが、中でも特に印象的なものはありますか?

楽楽明細の郵送代行機能ですね。「入力情報を確定するたびに1通1通郵送するのではなく、複数の明細データを日ごとにまとめて郵送すべき」など、顧客要望をすべて満たしていこうと思うととても要求レベルが高い開発で、社内で何度もレビューと再設計を繰り返しました。

オプション機能としてリリースしたのですが、営業担当者や企画担当者から「お客様からいい機能だって褒めてもらったよ」と教えてもらったり、実際とても多くの顧客企業からお申込いただくことができているので、たくさんのユーザーに喜んでもらえているのだなと分かってとても嬉しかったです。

楽楽明細の郵送代行機能はラクスのCMで紹介されることになり、毎月沢山の請求書を印刷して郵送する負荷の高い仕事のお役に立つことが出来たことを改めて実感しました。1つのプロダクトに長く関わって育てていくことができるというのはすごく誇らしいなと感じます。

それはすごいですね!前職まではシステム全体に携わることがなかなか難しかったとのことですがラクスではどうですか?

SIer時代はシステムの開発部分にしか携われないことが殆どでしたが、要求定義から保守までシステム全体に関わりました。多重請けによる組織構造の問題がないので、ラクスではすべてゼロベースから関わることができ、自分たちにとってその時々で最適と思われる技術やアーキテクチャを採用する裁量もあります。

性格的にはブラックボックスがあちこちにあると居心地が悪いのですが、そういったことがないのが気持ちいいですね。「なんでこの設計になっているんだろう」というモヤモヤがないんです。「どこまでも自分たちで決めることができる」「すべてが自分たちの手の中にある」というのは大変ですがやりがいがあります。

その後、楽楽明細の機能開発をけん引されるだけでなく、楽楽明細で発行した電子帳票を保存できる楽楽電子保存の立ち上げにも関わってこられました。今までの主な取り組みをご紹介いただけますか?

楽楽明細の技術的な話では、ユーザ自身で請求書などをデザインできる機能の開発でReactを採用したり、JavaScriptからTypeScriptへの移行、など息の長いプロダクトを継続的に改善する取り組みを行いました。

この時期の話は何度か社外向けに発表しているので資料も見てください。

・既存 Web アプリケーションへの React.js 適用
https://speakerdeck.com/eichisanden/react-for-web-application
・息の長いサービスのフロントエンドを少し改善する営み
https://speakerdeck.com/eichisanden/frontend-improvement
・トラブルゼロで乗り切ったTypeScript移行
https://speakerdeck.com/eichisanden/trouble-free-typescript-migration
・スクラム開発チームをLessでスケールさせた話
https://speakerdeck.com/eichisanden/scaling-scrum-team-with-less
・楽楽明細の開発を支える技術
https://speakerdeck.com/eichisanden/le-le-ming-xi-falsekai-fa-wozhi-eruji-shu

楽楽電子保存は私にとって、ラクスに入社して初の新サービス開発で、既存サービスの開発とは違い技術的な制約が少ない中で今までの経験を活かすような開発ができました。Java17やプール型のマルチテナント方式を採用したり、意欲的に開発を行いました。楽楽電子保存の開発についてはJJUG CCC 2022 Springで発表しました。

・短納期でローンチした新サービスをJavaで開発した話
https://speakerdeck.com/eichisanden/launched-new-service-using-java

これらのプロダクト担当を経て、現在の楽楽勤怠に至ります。

その他、取り組んだこととしては開発フローの改善(カンバンボード導入/1週間単位の単位のイテレーティブな開発/ふりかえり)、開発ツール導入(git/Mac/IntelliJ IDEA/GitHub/GitHub Copilot/開発環境のコンテナ化)、運用改善(ChatBotを導入して運用負荷軽減、ReDashを導入してデータ分析強化)などいろいろとあります。

常に顧客の課題解決を最優先にした開発体制

楽楽明細はウォーターフォール型の開発になるのでしょうか?

アジャイルの良さを活かしたプラクティスも多く取り込んでいます。顧客企業の悩みや痛みを解決することを最優先にシステム開発を行っているので、開発優先度が日々変わっていってしまうんです。そのためには柔軟に予定を組み替えられるようにしないといけなくて、ウォーターフォールだとそれに対応することが難しい。

営業チームや企画チームもそうした想いは一緒なので、優先度の高い機能開発のためであれば優先度の低い機能開発は次期リリースに延期しましょうかという会話がストレスなく成立します。こういったコミュニケーションを頻繁にとっているので、お互いベストを尽くしているという信頼感がありますね。

顧客の課題解決を最優先にしながらプロダクトを育てる。そのためにテックリードとして取り組まれていることはありますか?

システムは、時間がたつとレガシーになります。構成が古臭くなるとリスクも高まりますしメンテナンスしないといけません。ただ新規開発は継続する必要がある。その中で、品質を保ちながらレガシーな部分をどうアップデートしていくか。そうしたバランスを大事にしています。

私だけがそうした知見や能力を身に着けるだけではいけません。チームメンバーみんなの知識や技術もアップデートしていくことも大切です。ラクスには沢山のサービスがあり、それぞれチームに別れて開発しているため、意識的に情報共有などで交流する場を設けないと知識がサイロ化してしまう恐れがあります。そこでテックリードやリードエンジニアを中心に情報共有会を立ち上げて、取り組んでいることや困りごとなど情報共有を行っています。

その効果により、他のチームでやっていることを把握できたり、分からないことをチーム間でも気軽に質問し会えるような空気が作れたと思っています。また、役に立ちそうなことは積極的に情報発信したり、面白かった本を紹介したり、読書会や勉強会を主催したりしています。

みんなが自発的に考え、助け合える、そして属人的なことのない透明性があるチームにしていきたいと考えています。

Back to list