日本最大級のポイントサイトで経験した失敗と挑戦

日本最大級の ポイントサイトで 経験した失敗と挑戦

moppyについて

moppyのビジネスモデル

moppyのビジネスモデル 約35種類のAPIがある

moppyのビジネスモデル 約50媒体とのAPIがある

moppyの沿革 moppy誕生 最初はガラケーのみの サービスでした 2005 累計会員数 ガラケー版サ終/ 2010 PC版表示対応 2011年にはSP版も誕生 もっとも古いコードはここ モバトク統合 1,000万人突破 のちに「お財布.com」も 統合する 「ポイ活」が バズワードに 2018 2020 アプリ版 moppy誕生 アプリ需要高騰に伴い アプリ版moppy爆誕 2022

moppyの沿革 累計会員数 ガラケー版サ終/ moppy誕生 最初はガラケーのみの サービスでした モバトク統合 1,000万人突破 のちに「お財布.com」も 統合する 「ポイ活」が バズワードに 18年の歴史が詰まっている 2005 2010 2018 2020 2022 PC版表示対応 2011年にはSP版も誕生 もっとも古いコードはここ アプリ版 moppy誕生 アプリ需要高騰に伴い アプリ版moppy爆誕

過去のmoppy 事業会社として、 売上利益を上げる目標はエンジニアも意識すべき ↓ 開発スピードを最優先にして開発を行なっていた

その結果どうなったか…

その結果どうなったか 不具合が急増

不具合急増の要因 PHP Version5.4 整備されていない レガシーコード バージョンが古い 謎のテンプレートエンジン 処理がベタ書き データ件数が増加

バージョンが古い PHP Version5.4 ・2015/09/14にEOL ・セキュリティリスクに晒されている ・最新版に比べて動作が遅い ・array_mergeなど使いたい関数がない ・タイプヒンティングがまともに書けない

謎のテンプレートエンジン その名も「mumu」 ・更新が2017年で止まっている ・入れたいテンプレートエンジンが入らない PHPバージョンが低いから ・マイナーなテンプレートエンジンの為、学習コストが高い

処理がベタ書き 各API、エンドポイントでは… ・パスタコードになっている 開発スピードに全振りしていた時代の産物 ・一箇所変更するだけでも大量のリグレッションテストが必須 ・処理を把握するのが苦痛 ・自動テストを導入したくても、テストコードが書けない

データ件数 データの取り扱い件数が増加の一途 ・関連テーブルが増加し、主要テーブルの把握が困難になった ・最も多い時期で1,045テーブルが存在していた。 不要なテーブルも多く、整理されていない状態 ・テーブル構成に引っ張られてデータアクセス関係のクラスがカオスに

moppyは歴史が長く複雑だ。 moppy力を付けなければ やれらるぞ。 by moppyチームマネージャー

不具合が非常に発生しやすい状況 ↓ 外部品質に固執してしまい、 内部品質を放置しすぎたという失敗

失敗に対する取り組み

失敗に対する現在の取り組み PHP Version5.4 整備されていない レガシーコード コーディング規則制定 5カ年計画の遂行 戦術的DDDの導入 不要機能の削除

5カ年計画 2021年から5か年計画を遂行中 2024年を目処にPHPのバージョンを8系にする計画 今はWEB側のPHPのバージョンが5.6になった 管理画面側は7.3に！ それに伴い、先週テンプレートエンジンがtwigへ移行された！

5カ年計画 対応したこと ・下位互換の変更点修正 ・MysqlConnectの撲滅 詳しくはセレスのqiita記事を参照 https://qiita.com/test000000001/items/d8096580a447e902b933

• https://qiita.com/test000000001/items/d8096580a447e902b933

コーディング規則の制定 コーディングスタイルを統一化 「雰囲気で書く」を止める 施策が増えるごとにルールごとも増えるので、ドキュメントを整備した。 あわせて既存の処理を触る際は工数の10%を、 リファクタリングに充てることに。

コーディング規則の制定 対応したこと ・クラスやレイヤーごとに規則のページを作成して粒度を細かくした ・タイトルと要件を箇条書きで記載するように縛る 説明は文章でもOK ・Readmeに規則のリンクを記載することで、 新規アサインメンバーのキャッチアップを迷わないようにした

戦術的DDD（軽量DDD）の導入 テストコードの記述が行えるように！ 不具合を減少させる為、戦術的DDDを導入 ※PHP7系で動いているリポジトリのみ ValueObjectを皮切りに、単体テストの自動テストが実行可能に！ 「事業会社として、売上利益を上げる目標はエンジニアも意識すべき」 という方針の基、リソースと開発工数が抑えられる戦術的DDDを選択。

不要機能の削除 1,045テーブルから… 不要な機能（処理）を削除することで、上記減少を図った 839テーブルとなった…！

取り組みの失敗も…

コーディング規則が機能しなくなった… 問題点 ・1枚のドキュメントに全ての規則を凝縮した ・記述方法が乱雑で、箇条書きと文章が混在している ↓ 「読まれないドキュメント」が完成してしまった

実装方法に差異があるケースも… 問題点 「事業会社として、売上利益を上げる目標はエンジニアも意識すべき」 作業工数とリソースが増える問題は切っても切り離せない課題 ↓ Domain以外の設計に時間を掛けずに開発を進めた結果、 アーキテクチャの設計思想がおざなりになった（ドメインモデル貧血症も発生）

まとめ

まとめ 中長期的な負債を解消する ・5カ年計画の遂行 EOLの解消 ・コーディング規則制定 ・不要機能の削除 学習コスト削減 ・戦術的DDDの導入 レガシーコードからの脱却

まとめ 取り組みをしても失敗は付きまとう 歴史が積み重なっているプロジェクトほど、 計画を立てて実行することが大切。 トライ&エラーで見えてくることもあるので、 自分たちが現在行なっている作業がトライ&エラーなのか、計画に則った作業な のかの目的を正しく認識して期限を設けて進めていくことが大切である。

ご清聴 ありがとうございました！