#RAKUSMeetup ©2022 RAKUS Co., Ltd. 楽楽精算の開発課題から学ぶ、 改善取り組み 株式会社ラクス 坂田光

#RAKUSMeetup 自己紹介 ● 坂田 光 ● 2020年入社 ● 楽楽精算開発チーム シニアエンジニア ● メインはバックエンド（Java）

#RAKUSMeetup お話ししたいこと ● 楽楽精算開発チームの改善取り組み ○ 日々開発に取り組む中で積み重ねてきた事例を紹介 ○ 小さな改善の積み重ねが品質向上につながる ○ 少しでも改善できそうなところがあれば、とりあえず やってみる

#RAKUSMeetup 事例①　テスト項目書 ● 課題　テスト項目の組み合わせ改善 ○ 設定値や状態の組み合わせが多く、毎回テスト項目を作るのが大変 ○ 毎回似たような組み合わせになるので、同じことをやるのが苦痛 因子1 因子2 因子3 水準1 水準1 水準1 水準2 水準2 水準1 水準2

#RAKUSMeetup 事例①　テスト項目書 ● 改善　組み合わせのテンプレートを作成 ○ 予めテンプレを用意しておくことで、都度作成する工数を削減 ○ テンプレはバージョンごとにメンテし、常に最新の状態に

#RAKUSMeetup 事例②　リファクタリング ● 課題　条件分岐の改善 ○ 業務要件が複雑で分岐が多い ○ ロジックが複数画面で共通化されているため、遷移元画面ごとの分岐があ る ○ 設定値ごとの分岐もあり、画面ごとの分岐と相まってネストが深くなってい く ○ よく見たら重複した分岐がちらほら

#RAKUSMeetup 事例②　リファクタリング if (screen == “screenA”) { if (setting == “settingA”) { return “A”; // 重複 } else if (setting == “settingB”) { if (registerDate <= “20221031”) { return “B”; } else { return “C”; } } } else if (screen == “screenB”) { if (setting == “settingA”) { return “A”; // 重複 } else { return “D”; } }

#RAKUSMeetup 事例②　リファクタリング ● 改善　早期リターン ○ 重複した分岐を冒頭に持ってくることで、可読性を向上

#RAKUSMeetup 事例②　リファクタリング if (setting == “settingA”) { return “A” // 重複 } if (screen == “screenA”) { if (setting == “settingB”) { if (registerDate <= “20221031”) { return “B”; } else { return “C”; } } } else if (screen == “screenB”) { return “D”; } if (screen == “screenA”) { if (setting == “settingA”) { return “A”; // 重複 } else if (setting == “settingB”) { if (registerDate <= “20221031”) { return “B”; } else { return “C”; } } } else if (screen == “screenB”) { if (setting == “settingA”) { return “A”; // 重複 } else { return “D”; }

#RAKUSMeetup 事例②　リファクタリング ● この他、若手を中心に様々なアプローチのリファクタリング を計画中 ○ 若手エンジニアがリファクタリングに関する社内勉強会で持ち帰った知識が 活かされている

#RAKUSMeetup 事例③　性能劣化との戦い ● 課題　肥大化する環境への対応 ○ 提供開始から10年以上が経過 ○ 累計導入社数1万社、利用者数延べ100万人を突破 ○ 蓄積されるデータもどんどん膨大になる ○ 中にはこの環境に適応できず、性能劣化する機能もちらほら

#RAKUSMeetup 事例③　性能劣化との戦い ● 改善　非効率なコードの見直し void execute(Enum enumType, String name) { for (i = 0, i < 100, i++) { Enum value = this.valueOf(enumType, name); // do something } } Enum valueOf(Enum enumType, String name) { try { Enum.valueOf(enumType, name); } catch (IllegalArgumentException e) { return null; } } 例外クラスの生成というコスト の高い処理を行った上で、処 理を続行している ループ回数が少なければいい が、増えれば増えるほど処理 時間もどんどん増える

#RAKUSMeetup 事例③　性能劣化との戦い ● 改善　非効率なコードの見直し ○ 今回の例では、Enumの取得で例外をスローしない別の処理に置き換える ことで対応 ○ このような非効率なコードが、そこかしこに隠れていると思われる ■ まだまだ改善の余地あり

#RAKUSMeetup 事例③　性能劣化との戦い ● 改善　非効率なコードの見直し ○ 闇雲に全てのコードを洗い出していてはキリがない ○ 現状は劣化の発生ベースで、都度問題箇所を確認している ■ 週次の性能検証 ■ 本番での検知 ○ 問題が特定出来たら、横展開で確認して同様の問題を潰す ■ これの積み重ねで、全体の処理を効率化

#RAKUSMeetup 事例④　モブプロの実践 ● 課題　コードレビューの効率化 ○ GitLabのマージリクエストでレビューするスタイル ○ テキストでやり取りしているとレビュアの意図がうまく伝わらなかったり、ま たその逆もある ○ やり取りの回数が増えて時間がかかる

#RAKUSMeetup 事例④　モブプロの実践 ● 改善　モブプロをやってみた ○ メンバーが一堂に会してコードを作り上げるスタイル ○ 何かあったら直接会話しながら修正できるので、マージリクエストでやり取 りするより早い ○ 複数人でチェックしあうことで品質を向上 ○ 歴の浅いメンバーの訓練にもなる ■ 歴の長いメンバーから直接レクチャーを受けることができる

#RAKUSMeetup 事例④　モブプロの実践 ● 改善　モブプロをやってみた ○ 複数人の時間をいっぺんに使うので、場合によってはいつもより工数がか かるかも ■ 自分たちの場合はそんなに変わらなかった ○ 人によって向き不向きもありそう ■ 黙々と進めたい人には向かないかも ○ やってみると結構疲れる ■ 小まめな休憩は必須

#RAKUSMeetup 事例④　モブプロの実践 ● 改善　モブプロをやってみた ○ リモートワークでも全然いける ■ リモート環境におけるエディタ共有等、リモート・モブプロを支援する ツールを使うと快適 ■ 楽楽精算チームではJetBrainsのCode With Meを活用中

#RAKUSMeetup 事例⑤　老朽化したシステムの更新 ● 課題　システム内部の老朽化改善 ○ 息の長いサービスの宿命 ■ レガシーコード ■ 古いフレームワーク（伝統的なServlet-JSP） ■ EOL間近のミドルウェア、ライブラリ

#RAKUSMeetup 事例⑤　老朽化したシステムの更新 ● 改善　ミドルウェア・ライブラリの更新 ○ Java、DB、APサーバ etc… ○ リリースノートの調査やアップデート後の検証が大変 ■ オフショアのリソースも借りつつ進行中 ○ 機能改修を止めるわけにはいかない ■ 合間を縫ってコツコツやる精神が大事

#RAKUSMeetup 事例⑤　老朽化したシステムの更新 ● 改善　アーキテクチャの刷新 ○ フロントエンド／バックエンドの分離を計画中 ○ 現開発チームはバックエンド開発に集中できる体制を構築し、開発効率化を 目指す

#RAKUSMeetup 最後に ● とにかく小さな改善の積み重ねが大切 ● 改善はモチベーションアップにもつながる ○ 作業を楽にしたり、新しい技術にチャレンジしてみたりすることで、開発者 のモチベーションアップにもつながっていく