PHPerKaigi2023｜技術負債とプロジェクトと私たち(technical debt&project&us)

PHPerKaigi 2023におけるセッション「技術負債とプロジェクトと私たち」の資料です。

登壇：
takedajs / ヒエイ / おのぽん

概要：
サービス運用者の皆さん、技術負債解消に向き合えてますか？
機能拡張に対して技術負債がネックになり開発効率が落ちることに、何度も頭を悩ませた事があるのではないでしょうか。

ローンチして8年のフォトウエディング・前撮りの日本最大級のクチコミサイト「Photorait」では、サービスを更に拡大するべく新機能の開発を行いながら、長い年月の中で生まれたレガシーなシステムや非効率な運用フローなど、技術負債への課題解消も並行して行っています。

本セッションでは、新たな機能開発を止めずに並行して行っている負債解消への取り組みと、事業メンバーへの理解促進、そして今後の開発サイクル加速のために実施していることを発表します。

対象者
・サービス運用エンジニア全般
・技術負債改善の進め方を知りたい方
・事業メンバーの理解や賛同を得る方法を知りたい方

Transcript

1. 技術負債とプロジェクトと私たち

   PHPerKaigi 2023

   

   by 株式会社ウエディングパーク takedajs / ヒエイ / おのぽん
   

   ©WEDDING PARK CO., LTD.
   

   View Slide

2. 武田 翔平 (@takedajs)
   # エンジニアリングマネージャー
   # 新卒入社9年目
   # 猫2匹飼育😺
   ヒエイカザト (@zosokh)
   # チーフエンジニア
   # 中途入社4年目
   # ⚾ちなヤク🐧
   おのぽん(@onopon_engineer)
   # エンジニア
   # 中途入社1年目
   # 卓球ガチ勢🏓
   

   View Slide

3. ©WEDDING PARK CO., LTD.
   会社紹介

   

   View Slide

4. 公式キャラクター
   

   View Slide

5. 2018年12月　桂由美　ブライダルエディター賞

   

   View Slide

6. 2018年12月　桂由美　ブライダルエディター賞

   

   View Slide

7. 運営メディア

   結婚準備クチコミ情報サイト
   
 海外挙式の日本最大級クチコミ&フォトサイト
   
 ドレス選びがもっと楽しくなるクチコミサイト
   

   フォトウエディングの決め手が見つかるクチコミサイト
   
 指輪選びの決め手が見つかるクチコミサイト
   

   結婚の各領域に特化した専門メディアを運営。ITを活用し、カップルと様々なブライダルサービスのベストマッチを実現します。 

   

   View Slide

8. 結婚準備クチコミ情報サイト
   
 海外挙式の日本最大級クチコミ&フォトサイト
   
 ドレス選びがもっと楽しくなるクチコミサイト
   

   フォトウエディングの決め手が見つかるクチコミサイト
   
 指輪選びの決め手が見つかるクチコミサイト
   

   結婚の各領域に特化した専門メディアを運営。ITを活用し、カップルと様々なブライダルサービスのベストマッチを実現します。 

   運営メディア

   

   View Slide

9. ローンチ

   - 2015年1月 

   

   開発メンバー

   - ディレクター, エンジニア, デザイナー(十数名)
   

   

   利用技術

   - PHP (CodeIgniter, Laravel)

   - React, jQuery

   - Golang

   Photoraitについて

   

   View Slide

10. みなさん技術負債の返済をしていますか？

    

    View Slide

11. 目次

    フェーズ2

    チームと

    テストコード体制

    

    フェーズ3

    更なる開発の

    加速を目指して

    

    フェーズ1

    事業成長に

    伴う課題

    

    

    View Slide

12. 目次

    フェーズ2

    チームと

    テストコード体制

    

    フェーズ3

    更なる開発の

    加速を目指して

    

    フェーズ1

    事業成長に

    伴う課題

    

    

    View Slide

13. ©WEDDING PARK CO., LTD.
    事業成長に伴う課題

    takedajs

    

    View Slide

14. 開発体制

    

    View Slide

15. 開発の流れ

    

    View Slide

16. 立ち上げ当時

    ・機能が足りないのでどんどん開発してリリース！

    

    

    ・影響範囲の調査にも時間がかからない！

    

    

    ・ＱA工数も大きな負荷ではない！

    

    View Slide

17. 事業成長に伴う開発体制の変化

    

    View Slide

18. 事業成長に伴う開発体制の変化

    

    View Slide

19. 事業成長に伴う開発体制の変化

    

    View Slide

20. 事業成長するにつれて起きてきた課題

    ・影響範囲の洗い出しに時間がかかる
    ・ＱAの工数が大きな割合になってきた
    ・障害が発生する確率が高くなってきた
    

    View Slide

21. どうすればいいっパ・・・

    

    View Slide

22. テストがないコードはレガシーコード！

    

    View Slide

23. テストコードはいいよ！

    

    View Slide

24. これっパ！

    

    View Slide

25. ただ、どう提案していけばいいっパ・・・

    

    View Slide

26. テストコード導入に向けての戦術

    戦術① ： 障害発生時の振り返りで、防止策として提案
    戦術② : 事業責任者とディレクターにWhyとHowを丁寧に説明
    

    View Slide

27. やった〜！導入決定っパ！

    

    View Slide

28. ただ、どう進めていけばいいっパ・・・

    

    View Slide

29. テストコードの導入推進するための取り組み始めるっパ！

    

    View Slide

30. 目次

    フェーズ2

    チームと

    テストコード体制

    

    フェーズ3

    フェーズ1

    事業成長に

    伴う課題

    

    更なる開発の

    加速を目指して

    

    

    View Slide

31. ©WEDDING PARK CO., LTD.
    チームとテストコード体制

    ヒエイカザト

    

    View Slide

32. 当時のチームとテストコード

    ● テストコードを書く習慣がない

    ○ 書く方法がわからない

    ○ PHPUnitを実行できる環境がない
    

    ○ 書いて何が良くなるのかわからない
    

    

    ● いくつかは設置してあるテストコード
    

    

    ● 書く人と書かない人がいる

    

    View Slide

33. ● テストコードを書く習慣がない

    ○ 書く方法がわからない

    ○ PHPUnitを実行できる環境がない
    

    ○ 書いて何が良くなるのかわからない
    

    

    ● いくつかは設置してあるテストコード
    

    

    ● 書く人と書かない人がいる

    なんとなく書かれている意図のないテストコード
    

    当時のチームとテストコード

    

    View Slide

34. テストコード体制のためにやったこと

    ● テストコードを書きやすい環境づくり
    

    

    ● ルールとフロー作成

    

    ● テストコード設置のための指標設定
    

    

    View Slide

35. ©WEDDING PARK CO., LTD.
    チームとテストコード体制

    テストコード環境づくり

    

    View Slide

36. テストコードを書きやすい環境づくり

    今まで

    ● 誰でもユニットテストを実行できる環境が無い
    

    ● いまいち立ち上げにくいユニットテスト環境があった
    

    誰でも扱いやすい

    ユニットテスト実行環境を作る

    

    View Slide

37. 誰でも実行しやすいPHPUnit環境をつくる
    

    テストコード環境づくり

    

    View Slide

38. 誰でも実行しやすいPHPUnit環境をつくる
    
 Dockerでテスト環境を用意 

    

    ● テスト用ローカルDBを立ち上げ 

    

    ● 1コマンドでDockerコンテナ上での
    PHPUnitを実行

    

    ● 他アプリケーションに依存しないテ
    ストコード設計

    

    テストコード環境づくり

    

    View Slide

39. GitLab CIを用いた自動テスト

    テストコード環境づくり

    

    View Slide

40. のちに他テストや静的解析を導入したCI環境
    

    テストコード環境づくり

    

    View Slide

41. ©WEDDING PARK CO., LTD.
    チームとテストコード体制
    

    指標とルール設定

    

    View Slide

42. 指標設定

    ● カバレッジ監視

    ○ カバレッジ値を知る

    ○ チームでカバレッジ数値目標を設定しテストコードを増やす対応をする
    

    レビュー時のテスト状態とカバレッジ値表示 

    GitLabにメインブランチのカバレッジ数値表
    示と

    カバレッジレポート閲覧 

    

    View Slide

43. ルールとフロー作成

    ● 方針

    ○ 書けるところからテストコードを書いていこう！
    

    ○ テストコードの量を増やすことを目的に、カバレッジ値をチームで
    目標に置く

    

    View Slide

44. ルールとフロー作成

    しかし、うまくいかない…

    

    View Slide

45. ルールとフロー作成

    途中でぶち当たった壁

    ● 既存プロジェクト（テストコード無し）にテストを書くのは大変
    

    

    ● カバレッジ目標は達成できても、カバレッジ目標のためのテストコードになる
    

    ○ テストコード量産が目的になる／テストの質が下がる
    

    ○ カバレッジ値に追われてしまう

    

    ● 「書き方が分からない」を解決していないので、テストコードを書く人が偏る
    

    

    View Slide

46. ルールとフロー作成

    改善

    

    View Slide

47. ● 目標達成に追われないカバレッジ値設定
    ○ テストコード設置自体が目的にならないようにする
    ● テストコード設置のルールを明確にした
    ○ リリースにテストコードを入れる
    ○ E2Eテストとテストコードの棲み分けを明確化
    

    ● ペアプロを用いてチームでのテストコードの書き方を共有
    

    改善策

    

    View Slide

48. ©WEDDING PARK CO., LTD.
    チームとテストコード体制
    

    開発チーム外にやったこと

    

    View Slide

49. 併せて行ったこと

    ● 事業メンバーへの活動共有

    

    ● 社内LTや外部登壇での活動共有
    

    

    View Slide

50. メリット：

    ● 施策がサービスへの恩恵という理解につながる
    

    ● 活動を応援してもらう事で、やる気が出る！
    

    事業メンバーへの活動共有

    エンジニアが主導として動いている施策でも、事業に関わるメンバーには職種関係
    なくアピール。

    エンジニア以外の他職種メンバーへ活動共有 → 事業部全体での「活性化」
    

    

    View Slide

51. 事業の定例で、イラストを用いてテストコード施策を紹介
    

    

    

    

    

    

    

    

    事業メンバーへの活動共有

    ディレクターや営業など、エンジニア以外のチームメンバーへ「わかりやすく」
    

    

    View Slide

52. 社内LTや外部登壇での活動共有

    ● PHPerKaigi2022での登壇

    ● 社内勉強会でのテストコード施策について深堀り
    

    ● 他、勉強会などでの発表

    メリット：

    ● 共感の声が聞ける

    ● 他社でも同じ悩みを持った人が多くいる事を知る
    

    ● 「こんな活動しています」の声も聞く事ができた
    

    

    View Slide

53. 施策での変化

    ● テストコードを書かない人がいなくなった
    

    ただ、量と質は依然課題

    

    ● CIによるエラー検知を無視させない仕組みができた
    

    

    ● チームでテストコード工数の見積もり精度が向上
    

    

    View Slide

54. しかし課題は残る

    ● まだまだテストコードの薄い箇所が多い。カバレッジ値上げ止まり
    

    

    ● テストコード拡張に時間とエネルギーを消費
    

    

    ● そもそもテストコード書く設計になっていない部分が多い
    

    

    View Slide

55. しかし課題は残る

    ● まだまだテストコードの薄い箇所が多い。カバレッジ値上げ止まり
    

    

    ● テストコード拡張に時間とエネルギーを消費
    

    

    ● そもそもテストコード書く設計になっていない部分が多い
    

    

    View Slide

56. 開発加速のために技術負債を解消するっパ！

    

    View Slide

57. 目次

    フェーズ2

    チームと

    テストコード体制

    

    フェーズ3

    更なる開発の

    加速を目指して

    

    フェーズ1

    事業成長に

    伴う課題

    

    

    View Slide

58. ©WEDDING PARK CO., LTD.
    更なる開発の

    加速を目指して

    おのぽん

    

    View Slide

59. なぜテストコードの量と質は向上しなかったのか

    ◯テストコードを意識したコーディングになっていなかった
    

    ・密結合となってしまっている箇所が多い
    

    ・Fat Controllerとなってしまっている
    

    → 1テストケースを書くための関連データが多い
    

    どうしても負の気持ちが先行してしまい

    必要最低限のケース追加に抑えようとしてしまう
    

    テストコードに対して負の感情がなくなる何かが必要
    

    リファクタリングしようにもテストを書かないといけない
    

    がしかし、書きたくない・・・（手を加えたくない）
    

    

    View Slide

60. 取り組んだこと

    Photoraitに新しい風を吹かせよう

    

    

    

    日々のタスクの中でプラスαの改善を取り入れる
    

    

    古いコードにとらわれず、組織にとって新しい仕組みの開発による
    

    アップデートや提案を積極的に行う
    

    

    View Slide

61. ©WEDDING PARK CO., LTD.
    可変可能なSeeder

    (CustomSeeder)の作成

    新しい風の事例①

    

    View Slide

62. Seederを利用したテスト

    テスト用の仮レコードを作成するためにSeederを利用していた
    

    ◯Seederクラス
 ◯Seederを活用したテストコード例
    

    このテストコードにはいくつか改善点が・・・
    

    

    View Slide

63. Seederにおける課題

    ◯ マスターデータ（固定データ）を作るのに向いているが、
    カラムの一部変更などができない
    

    例）◯：Role（1: 管理者, 2: 閲覧者, 3: 編集者 etc）← Roleのidは固定データであってほしい

    △：User（1: WP太郎, 2: WP二郎）

    

    

    　 可変データをSeederで作るとテストの質を上げづらい
    

    ← 必ずしも1がWP太郎、2がWP二郎である必要はなく、
    　そうなるとも限らない
    idが100以外の時（idが可変時） 

    も通るべき

    名前やメアドも固定でなくても良い 

    idが101以外の場合もNotFound 

    の状況であってほしい 

    

    View Slide

64. CustomSeederの作成

    データを外から入れられるようにし、もし指定がない場合はデフォルト値を利用するような仕組みを作成 

    デフォルト値を定めておく 

    可変idのテストが可能 

    外から入れた値でテストできる 

    可変idのテストが可能 

    insert時に生成したidが返ってくる 

    emailの値をoverride@photorait.netに上書きする 

    

    View Slide

65. CustomSeederによる改善箇所

    テストケースの質を上げやすくなった
    

    　= より本番に近いデータでのテストが可能に
    

    

    ● SeederとCustomSeederの棲み分けが明確
    

    ○ Seeder：マスターデータ

    ○ CustomSeeder：可変データ

    

    ● リレーショナルなデータ構造も可変idで書くことが可能となる
    

    ● テストデータの作成が楽になる

    少しだけテストコードと向き合える状況を作れた
    

    

    View Slide

66. ©WEDDING PARK CO., LTD.
    バリデータの構造見直し

    新しい風の事例②

    

    View Slide

67. 既存のバリデータ

    色んなバリデータメソッドが存在していた。 

    しかし、メソッド内で複数のバリデートをチェックしており、似たようなバリデーションが数多く存在 

    →改修しづらく、新たにテストも書きづらい 

    例）
    ・メソッド内に複数バリデート関連のメソッドが存在（密結合）
    

    ・コピペされたソースコードが存在してしまっている（図の
    青・オレンジ）

    ・改修しようとすると、このメソッド内に追記することとなる
    

    

    

    View Slide

68. 必要なバリデータだけを組み合わせて利用できるようにした

    バリデータを作成するためのValidationAbstractを作り、 

    それらのバリデーションを集めて利用することのできるValidationAggregatorAbstractを用意した。 

    MailAddressValidationAggregator 

    RequiredValidator

    MaxLengthValidator 

    MailAddressFormatValidator 

    ・上記のAggregator, ValidatorはそれぞれAbstractを継承
    

    ・Validatorはboolを返すvalidateメソッドを持つ
    

    ・Aggregatorは所有するValidatorのvalidateメソッドを順番に実行し、実行結果を保有
    

    

    View Slide

69. 改修後のコード

    ● バリデーションひとつひとつを 疎結合にできた

    ● バリデーション毎にテストを書けば良いので、 

    テストコードを簡潔に書ける ようになった

    ● 新たにバリデーションを追加する場合も、都度 

    AggregatorやValidatorを作成し、必要な 

    バリデーションを利用すれば良い状況となった 

    他のエンジニアも率先して利用してくれるようになった
    

    ロジック
 テスト

    

    View Slide

70. なぜ状況は好転したのか？

    チームの皆が新しい取り組み（=挑戦）を面白がってくれるため
    

    ● 変化に柔軟なプロジェクトだった 

    ○ 自分の挑戦を周囲のエンジニアが面白がって肯定してくれる（= 応援してくれる）

    

    ● 「こうあるべき」という ビジョンや認識が同じ であり、ゴールまでの 組織の変化を楽しんでくれる 

    

    ● 思い立ったタイミングで挑戦できる 

    

    ● 誰かが挑戦しているとそれに触発され、新しい挑戦が生まれる 

    

    View Slide

71. テストコード拡充により目指すプロジェクトの未来

    人による仕様の担保（QA）が少ない 

    人による仕様の担保（QA）が多い 

    仕組み（テストコード） 

    による担保が少ない 

    仕組み（テストコード） 

    による担保が多い 

    現在
 ①第3象限から第4象限へ移動中

    ②ゆくゆくは第1象限へ！

    

    View Slide

72. 働き方の変革をPhotoraitから全社へ

    テストコード拡充により期待できること
    

    ● QAに疲弊する人が減る

    ● エンジニアが改修に自信を持てる
    状態に（バグを未然に防止）できる
    

    高速なリリース、人の手が今よりもっと社会への価値提供に向けられる未来に
    

    Photoraitを成功事例として、良い取り組みを全社に広めたい
    

    全社的にも人力でカバーする場面が多いので、
    

    

    View Slide

73. 入社1ヶ月後、他プロジェクトのエンジニアとペアプロを行なったことを機に、 

    エンジニアが誰でも参加できる座談ミーティング を定期的に開催することを推進してもらえた 

    

    　　ミニマムでミーティングの開催をし続け、少しずつ自身の認知・信頼へと繋げることができた 

    普及活動のための種蒔き

    入社直後の目標：部署内外問わず、自身を認知・信頼してもらう

    入社直後訪れたチャンス 

    入社時の想い：チームの皆がいち早く社会に価値を提供できる環境作り
    をしたい

    自身の考えや想いをプロジェクトに合った形で一緒に提案・賛同してもらえる状況を作る必要がある 

    入社8ヶ月後…

    

    ・本セッションへの登壇 

    ・社内エンジニアを対象としたテストコード研修会開催 

    → オープンソース化しました！（ウエディングパーク テストコードで検索♪ 💻）

    etc...

    活動の場を広げることができた 
 

    WPテストコード 

    詳細はこちら▼ 

    

    View Slide

74. さいごにまとめっパ！

    

    View Slide

75. まとめ

    フェーズ2

    チームと

    テストコード体制

    

    フェーズ3

    更なる開発の

    加速を目指して

    

    フェーズ1

    事業成長に

    伴う課題

    

    ● 開発体制の変化

    

    ● 事業成長するにつれて起
    きた課題

    

    ● テストコード導入提案 

    

    ● テストコード環境作りとカ
    バレッジ値可視化

    

    ● カバレッジ目標を設定し
    たテストコード推進

    

    ● 事業メンバーを巻き込ん
    で応援されよう

    ● 日々のタスクの中にプラ
    スαの改善を

    

    ● 周りが挑戦を面白がって
    くれる環境が大事

    

    ● みんなの手で、今よりもっ
    と社会へ価値提供できる
    未来を目指して

    

    View Slide

76. 告知

    概要：PHPerであるウエディングパークによる、PHPerのための
    　　　登壇もできるLT会。PHPerがLTを楽しむイベントです。
    　　　※PHPerKaigiをもじって勝手に開催します
    4/18(火)
    19:00～
    ＠オンライン
    ▼connpass募集ページ
    

    View Slide

77. View Slide