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

Slide 1

Slide 1 text

技術負債とプロジェクトと私たち  PHPerKaigi 2023    by 株式会社ウエディングパーク takedajs / ヒエイ / おのぽん   ©WEDDING PARK CO., LTD.

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

公式キャラクター

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

運営メディア  結婚準備クチコミ情報サイト   海外挙式の日本最大級クチコミ&フォトサイト   ドレス選びがもっと楽しくなるクチコミサイト   フォトウエディングの決め手が見つかるクチコミサイト   指輪選びの決め手が見つかるクチコミサイト   結婚の各領域に特化した専門メディアを運営。ITを活用し、カップルと様々なブライダルサービスのベストマッチを実現します。  

Slide 8

Slide 8 text

結婚準備クチコミ情報サイト   海外挙式の日本最大級クチコミ&フォトサイト   ドレス選びがもっと楽しくなるクチコミサイト   フォトウエディングの決め手が見つかるクチコミサイト   指輪選びの決め手が見つかるクチコミサイト   結婚の各領域に特化した専門メディアを運営。ITを活用し、カップルと様々なブライダルサービスのベストマッチを実現します。   運営メディア 

Slide 9

Slide 9 text

ローンチ  - 2015年1月     開発メンバー  - ディレクター, エンジニア, デザイナー(十数名)     利用技術  - PHP (CodeIgniter, Laravel)  - React, jQuery  - Golang  Photoraitについて 

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

目次  フェーズ2  チームと  テストコード体制    フェーズ3  更なる開発の  加速を目指して    フェーズ1  事業成長に  伴う課題   

Slide 12

Slide 12 text

目次  フェーズ2  チームと  テストコード体制    フェーズ3  更なる開発の  加速を目指して    フェーズ1  事業成長に  伴う課題   

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

開発体制 

Slide 15

Slide 15 text

開発の流れ 

Slide 16

Slide 16 text

立ち上げ当時  ・機能が足りないのでどんどん開発してリリース！      ・影響範囲の調査にも時間がかからない！      ・ＱA工数も大きな負荷ではない！ 

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

テストコードはいいよ！ 

Slide 24

Slide 24 text

これっパ！ 

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

目次  フェーズ2  チームと  テストコード体制    フェーズ3  フェーズ1  事業成長に  伴う課題    更なる開発の  加速を目指して   

Slide 31

Slide 31 text

©WEDDING PARK CO., LTD. チームとテストコード体制  ヒエイカザト 

Slide 32

Slide 32 text

当時のチームとテストコード  ● テストコードを書く習慣がない  ○ 書く方法がわからない  ○ PHPUnitを実行できる環境がない   ○ 書いて何が良くなるのかわからない     ● いくつかは設置してあるテストコード     ● 書く人と書かない人がいる 

Slide 33

Slide 33 text

● テストコードを書く習慣がない  ○ 書く方法がわからない  ○ PHPUnitを実行できる環境がない   ○ 書いて何が良くなるのかわからない     ● いくつかは設置してあるテストコード     ● 書く人と書かない人がいる  なんとなく書かれている意図のないテストコード   当時のチームとテストコード 

Slide 34

Slide 34 text

テストコード体制のためにやったこと  ● テストコードを書きやすい環境づくり     ● ルールとフロー作成    ● テストコード設置のための指標設定  

Slide 35

Slide 35 text

©WEDDING PARK CO., LTD. チームとテストコード体制  テストコード環境づくり 

Slide 36

Slide 36 text

テストコードを書きやすい環境づくり  今まで  ● 誰でもユニットテストを実行できる環境が無い   ● いまいち立ち上げにくいユニットテスト環境があった   誰でも扱いやすい  ユニットテスト実行環境を作る 

Slide 37

Slide 37 text

誰でも実行しやすいPHPUnit環境をつくる   テストコード環境づくり 

Slide 38

Slide 38 text

誰でも実行しやすいPHPUnit環境をつくる   Dockerでテスト環境を用意     ● テスト用ローカルDBを立ち上げ     ● 1コマンドでDockerコンテナ上での PHPUnitを実行    ● 他アプリケーションに依存しないテストコード設計    テストコード環境づくり 

Slide 39

Slide 39 text

GitLab CIを用いた自動テスト  テストコード環境づくり 

Slide 40

Slide 40 text

のちに他テストや静的解析を導入したCI環境   テストコード環境づくり 

Slide 41

Slide 41 text

©WEDDING PARK CO., LTD. チームとテストコード体制   指標とルール設定 

Slide 42

Slide 42 text

指標設定  ● カバレッジ監視  ○ カバレッジ値を知る  ○ チームでカバレッジ数値目標を設定しテストコードを増やす対応をする   レビュー時のテスト状態とカバレッジ値表示   GitLabにメインブランチのカバレッジ数値表示と  カバレッジレポート閲覧  

Slide 43

Slide 43 text

ルールとフロー作成  ● 方針  ○ 書けるところからテストコードを書いていこう！   ○ テストコードの量を増やすことを目的に、カバレッジ値をチームで目標に置く 

Slide 44

Slide 44 text

ルールとフロー作成  しかし、うまくいかない… 

Slide 45

Slide 45 text

ルールとフロー作成  途中でぶち当たった壁  ● 既存プロジェクト（テストコード無し）にテストを書くのは大変     ● カバレッジ目標は達成できても、カバレッジ目標のためのテストコードになる   ○ テストコード量産が目的になる／テストの質が下がる   ○ カバレッジ値に追われてしまう    ● 「書き方が分からない」を解決していないので、テストコードを書く人が偏る  

Slide 46

Slide 46 text

ルールとフロー作成  改善 

Slide 47

Slide 47 text

● 目標達成に追われないカバレッジ値設定 ○ テストコード設置自体が目的にならないようにする ● テストコード設置のルールを明確にした ○ リリースにテストコードを入れる ○ E2Eテストとテストコードの棲み分けを明確化   ● ペアプロを用いてチームでのテストコードの書き方を共有   改善策 

Slide 48

Slide 48 text

©WEDDING PARK CO., LTD. チームとテストコード体制   開発チーム外にやったこと 

Slide 49

Slide 49 text

併せて行ったこと  ● 事業メンバーへの活動共有    ● 社内LTや外部登壇での活動共有  

Slide 50

Slide 50 text

メリット：  ● 施策がサービスへの恩恵という理解につながる   ● 活動を応援してもらう事で、やる気が出る！   事業メンバーへの活動共有  エンジニアが主導として動いている施策でも、事業に関わるメンバーには職種関係なくアピール。  エンジニア以外の他職種メンバーへ活動共有 → 事業部全体での「活性化」  

Slide 51

Slide 51 text

事業の定例で、イラストを用いてテストコード施策を紹介                 事業メンバーへの活動共有  ディレクターや営業など、エンジニア以外のチームメンバーへ「わかりやすく」  

Slide 52

Slide 52 text

社内LTや外部登壇での活動共有  ● PHPerKaigi2022での登壇  ● 社内勉強会でのテストコード施策について深堀り   ● 他、勉強会などでの発表  メリット：  ● 共感の声が聞ける  ● 他社でも同じ悩みを持った人が多くいる事を知る   ● 「こんな活動しています」の声も聞く事ができた  

Slide 53

Slide 53 text

施策での変化  ● テストコードを書かない人がいなくなった   ただ、量と質は依然課題    ● CIによるエラー検知を無視させない仕組みができた     ● チームでテストコード工数の見積もり精度が向上  

Slide 54

Slide 54 text

しかし課題は残る  ● まだまだテストコードの薄い箇所が多い。カバレッジ値上げ止まり     ● テストコード拡張に時間とエネルギーを消費     ● そもそもテストコード書く設計になっていない部分が多い  

Slide 55

Slide 55 text

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

目次  フェーズ2  チームと  テストコード体制    フェーズ3  更なる開発の  加速を目指して    フェーズ1  事業成長に  伴う課題   

Slide 58

Slide 58 text

Slide 59

Slide 59 text

なぜテストコードの量と質は向上しなかったのか  ◯テストコードを意識したコーディングになっていなかった   ・密結合となってしまっている箇所が多い   ・Fat Controllerとなってしまっている   → 1テストケースを書くための関連データが多い   どうしても負の気持ちが先行してしまい  必要最低限のケース追加に抑えようとしてしまう   テストコードに対して負の感情がなくなる何かが必要   リファクタリングしようにもテストを書かないといけない   がしかし、書きたくない・・・（手を加えたくない）  

Slide 60

Slide 60 text

取り組んだこと  Photoraitに新しい風を吹かせよう        日々のタスクの中でプラスαの改善を取り入れる     古いコードにとらわれず、組織にとって新しい仕組みの開発による   アップデートや提案を積極的に行う  

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Seederを利用したテスト  テスト用の仮レコードを作成するためにSeederを利用していた   ◯Seederクラス  ◯Seederを活用したテストコード例   このテストコードにはいくつか改善点が・・・  

Slide 63

Slide 63 text

Seederにおける課題  ◯ マスターデータ（固定データ）を作るのに向いているが、カラムの一部変更などができない   例）◯：Role（1: 管理者, 2: 閲覧者, 3: 編集者 etc）← Roleのidは固定データであってほしい  △：User（1: WP太郎, 2: WP二郎）      　可変データをSeederで作るとテストの質を上げづらい   ← 必ずしも1がWP太郎、2がWP二郎である必要はなく、　そうなるとも限らない idが100以外の時（idが可変時）   も通るべき  名前やメアドも固定でなくても良い   idが101以外の場合もNotFound   の状況であってほしい  

Slide 64

Slide 64 text

CustomSeederの作成  データを外から入れられるようにし、もし指定がない場合はデフォルト値を利用するような仕組みを作成   デフォルト値を定めておく   可変idのテストが可能   外から入れた値でテストできる   可変idのテストが可能   insert時に生成したidが返ってくる   emailの値を[email protected]に上書きする  

Slide 65

Slide 65 text

CustomSeederによる改善箇所  テストケースの質を上げやすくなった   　= より本番に近いデータでのテストが可能に     ● SeederとCustomSeederの棲み分けが明確   ○ Seeder：マスターデータ  ○ CustomSeeder：可変データ    ● リレーショナルなデータ構造も可変idで書くことが可能となる   ● テストデータの作成が楽になる  少しだけテストコードと向き合える状況を作れた  

Slide 66

Slide 66 text

Slide 67

Slide 67 text

既存のバリデータ  色んなバリデータメソッドが存在していた。   しかし、メソッド内で複数のバリデートをチェックしており、似たようなバリデーションが数多く存在   →改修しづらく、新たにテストも書きづらい   例）・メソッド内に複数バリデート関連のメソッドが存在（密結合）   ・コピペされたソースコードが存在してしまっている（図の青・オレンジ）  ・改修しようとすると、このメソッド内に追記することとなる    

Slide 68

Slide 68 text

必要なバリデータだけを組み合わせて利用できるようにした  バリデータを作成するためのValidationAbstractを作り、   それらのバリデーションを集めて利用することのできるValidationAggregatorAbstractを用意した。   MailAddressValidationAggregator   RequiredValidator  MaxLengthValidator   MailAddressFormatValidator   ・上記のAggregator, ValidatorはそれぞれAbstractを継承   ・Validatorはboolを返すvalidateメソッドを持つ   ・Aggregatorは所有するValidatorのvalidateメソッドを順番に実行し、実行結果を保有  

Slide 69

Slide 69 text

改修後のコード  ● バリデーションひとつひとつを疎結合にできた  ● バリデーション毎にテストを書けば良いので、   テストコードを簡潔に書けるようになった  ● 新たにバリデーションを追加する場合も、都度   AggregatorやValidatorを作成し、必要な   バリデーションを利用すれば良い状況となった   他のエンジニアも率先して利用してくれるようになった   ロジック  テスト 

Slide 70

Slide 70 text

なぜ状況は好転したのか？  チームの皆が新しい取り組み（=挑戦）を面白がってくれるため   ● 変化に柔軟なプロジェクトだった   ○ 自分の挑戦を周囲のエンジニアが面白がって肯定してくれる（= 応援してくれる）    ● 「こうあるべき」というビジョンや認識が同じであり、ゴールまでの組織の変化を楽しんでくれる     ● 思い立ったタイミングで挑戦できる     ● 誰かが挑戦しているとそれに触発され、新しい挑戦が生まれる  

Slide 71

Slide 71 text

テストコード拡充により目指すプロジェクトの未来  人による仕様の担保（QA）が少ない   人による仕様の担保（QA）が多い   仕組み（テストコード）   による担保が少ない   仕組み（テストコード）   による担保が多い   現在  ①第3象限から第4象限へ移動中  ②ゆくゆくは第1象限へ！ 

Slide 72

Slide 72 text

働き方の変革をPhotoraitから全社へ  テストコード拡充により期待できること   ● QAに疲弊する人が減る  ● エンジニアが改修に自信を持てる状態に（バグを未然に防止）できる   高速なリリース、人の手が今よりもっと社会への価値提供に向けられる未来に   Photoraitを成功事例として、良い取り組みを全社に広めたい   全社的にも人力でカバーする場面が多いので、  

Slide 73

Slide 73 text

入社1ヶ月後、他プロジェクトのエンジニアとペアプロを行なったことを機に、   エンジニアが誰でも参加できる座談ミーティングを定期的に開催することを推進してもらえた     　　ミニマムでミーティングの開催をし続け、少しずつ自身の認知・信頼へと繋げることができた   普及活動のための種蒔き  入社直後の目標：部署内外問わず、自身を認知・信頼してもらう  入社直後訪れたチャンス   入社時の想い：チームの皆がいち早く社会に価値を提供できる環境作りをしたい  自身の考えや想いをプロジェクトに合った形で一緒に提案・賛同してもらえる状況を作る必要がある   入社8ヶ月後…    ・本セッションへの登壇   ・社内エンジニアを対象としたテストコード研修会開催   → オープンソース化しました！（ウエディングパークテストコードで検索♪ 💻）  etc...  活動の場を広げることができた     WPテストコード   詳細はこちら▼  

Slide 74

Slide 74 text

さいごにまとめっパ！ 

Slide 75

Slide 75 text

まとめ  フェーズ2  チームと  テストコード体制    フェーズ3  更なる開発の  加速を目指して    フェーズ1  事業成長に  伴う課題    ● 開発体制の変化    ● 事業成長するにつれて起きた課題    ● テストコード導入提案     ● テストコード環境作りとカバレッジ値可視化    ● カバレッジ目標を設定したテストコード推進    ● 事業メンバーを巻き込んで応援されよう  ● 日々のタスクの中にプラスαの改善を    ● 周りが挑戦を面白がってくれる環境が大事    ● みんなの手で、今よりもっと社会へ価値提供できる未来を目指して 

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

No content