©SO Technologies Inc. 
 リアーキテクチャにおけるアンチパターンへの向き合い方と次なる挑戦 @ラクスルオフィス 2024/06/18 (Tue) 岸田 慎之介 / SO Technologies株式会社 システムと組織の課題克服を目指す リアーキテクチャとユーザ移行

©SO Technologies Inc. 
 自己紹介 ● 　SO Technologies 株式会社 ● Go言語でAPI/バッチ処理の開発を主に行いつつ 問い合わせの調査も行っている グループ横断の取り組みで使うアプリの開発にも従事 ● 　毎週ボルダリングに通ってる 岸田　慎之介 @mwudo 2

会社概要 会社名 SO Technologies株式会社（SO Technologies, Inc.） 所在地 東京都文京区後楽1-4-14 後楽森ビル 19F 設立 2013年4月2日 従業員数 102名（2024年4月時点） 事業内容 中堅・中小企業向けマーケティングテクノロジーの提供 代表 荒木 央 3 ©SO Technologies Inc. | | | | | |

©SO Technologies Inc. 
 ATOMとは 4

©SO Technologies Inc. 
 5
 5
 広告運用の 業務効率化を実現する Web広告代理店向けの Web広告レポートツールです。 報告業務の自動化 実績把握と課題特定を最短に 確認漏れの防止や異常値を察知 ATOMとは・機能 5


©SO Technologies Inc. 
 ATOMとは・データの流れ 6

©SO Technologies Inc. 
 プロダクトの歩み 7
 2014年 社内利用開始 0→1フェーズ 2015年 社外向けリリース 1→10フェーズ 10 → 100 の開発フェーズがないまま 4 年経過 2019年中頃 リニューアル版開発開始 100→1000フェーズ β機能としてリニューアル版リリース 2021年 リニューアル版正式リリース 2022年

©SO Technologies Inc. 
 課題などの話なのでプロダクトのネガティブな面ばかり出ますが 従来システムがあるおかげでリアーキテクチャができています 決してプロダクトを非難している訳ではありません 8
 前提

©SO Technologies Inc. 
 リニューアル（リアーキテクチャ）の背景 9 技術的課題 ❏ 技術スタックのレガシー化 ❏ データベースモデル設計の課題 ❏ コードの老朽化 組織的課題 ❏ ビジネスの構造とシステム構造の不一致 ❏ ビジネス課題に適応できない

©SO Technologies Inc. 
 技術的課題 10
 ● スパゲッティ ○ 汎用テーブルの乱用、N対N構造の乱立、不必要な冗長化 ● 命名規則が FREEDOM ○ 一貫性が無い ● 1テーブルの肥大化 DBモデル設計の課題 ● スパゲッティ ○ 可読性が低下。秘伝のタレしかない ● 神クラスの存在 ○ すべての箇所でこのクラスを継承 → 依存性 最大化 ● グローバル変数の多用 ○ 神クラスとの 相乗効果抜群！ コードの老朽化

©SO Technologies Inc. 
 作った人がいません 11
 組織的課題

©SO Technologies Inc. 
 12
 組織的課題 ❏ 想定されない利用方法の発生 ❏ 汎用的なドメインモデル ❏ 整合性を合わせるのがユーザー依存 ❏ 間違った使い方を防ぐためにサポートが必要 ❏ ユーザーにとって習得が困難 ビジネスの構造とシステム構造の不一致

©SO Technologies Inc. 
 なぜこのような状態になったのか 13
 リニューアル（リアーキテクチャ）の背景 ❏ リファクタリングを行っていない ❏ 1→10フェーズの時の基盤がベース ❏ 継ぎ足しの対応を繰り返し、設計に一貫性が無い ❏ 部分最適化が多い ❏ 個社毎の要望を聞きすぎてしまう ❏ 短期的な売上の開発を優先させてしまう ❏ 一つの機能でなんでもできるよう汎用化 ❏ 開発を行うための基準が無い ❏ システム全体としての優先順位を判断する基準が無い ❏ 判断基準となるKPIが売上のみ ❏ 売上に直接関係無い部分の優先順位を判断する基準が無い

©SO Technologies Inc. 
 この状況を打破するためにリニューアルがスタート だが、しかし、、、 14
 リニューアル（リアーキテクチャ）の背景

©SO Technologies Inc. 
 従来のシステムを運用しつつ 裏で完全に 独立したサービス として始動 15
 リニューアル（リアーキテクチャ）でのつまずき ❏ 0→1、1→10フェーズを経験したメンバーがいない ❏ リバースエンジニアリングをしてしまい車輪の再開発 後の 再リファクタリング に繋がる

©SO Technologies Inc. 
 16
 リニューアル（リアーキテクチャ）でのつまずき これ終わる？？ に加えて これらで使用するデータを管理する機能 作るべきものが多すぎる

©SO Technologies Inc. 
 リニューアル（リアーキテクチャ）でのつまずき 作るべきものが多すぎると プランニングが困難で見通しが立たず 不安からメンバーの士気の低下 ビックバンリリースが多発（いつか爆散する） 段階的に 移行しろ 17
 https://www.oreilly.co.jp//books/9784873119311/

©SO Technologies Inc. 
 スコープが大きすぎたことを反省して ❏ 機能を絞ってリリースする作戦へ（まずはレポート機能） ❏ 進捗管理、アラートの順で機能を作成 （その間も機能改修・不具合修正も並行） ❏ 既存ユーザが使えるように従来システムから データ移行 リニューアル（リアーキテクチャ）でのつまずきの反省 18


©SO Technologies Inc. 
 プロダクトのビジョンを明確化 リニューアル（リアーキテクチャ）でのつまずきの反省 日々の業務における「手間」をテクノロジーを活用した業務フローによって解消し 広告担当者が集客成果を上げられるような業務環境をつくること 19


©SO Technologies Inc. 
 やるべきことも明確化 リニューアル（リアーキテクチャ）でのつまずきの反省 ❏ 集客成果を上げられるような業務環境をつくれているかに拘る ❏ 解消するのは「日々」の業務における手間 ❏ 単にテクノロジーを提供するのでなくテクノロジーを活用した業務フローを提供する 20


©SO Technologies Inc. 
 ❏ 現行版の問題点を洗い出し ❏ 機能を使うことで解決したいユーザの問題を定義 ❏ 必要最低限を意識（MVP開発） リニューアル（リアーキテクチャ）でのつまずきの反省 リニューアルする上で提供している機能すべてで 21


©SO Technologies Inc. 
 既存ユーザの移行 既存ユーザも移行を行い従来システムの止めることが目標だが、、、 ❏ 個社要望や現行システムの機能再現などが求められる ❏ ユーザ側がリニューアル版を使う動機付けが低い 移行してもらうハードルがかなり高い 22


©SO Technologies Inc. 
 既存ユーザの移行のつまずき 従来システムの終了期限を決めて移行を進めたこともあった ❏ こちら都合のスケジュールを一方的にお客様に押し付ける形になり 大変な ご迷惑 をおかけすることに ❏ 期限までに開発しなければならないものもあった（かなりタイト） 終了期限までに移行がすべて終わらない 23


©SO Technologies Inc. 
 既存ユーザの移行のつまずきからの反省 従来システムの終了期限を設けず、丁寧にユーザの移行に寄り添う形に ❏ 従来・リニューアルのコストを抑制できたことが大きかった ❏ 移行がスムーズに行えるような移行ツールの開発 リニューアル版の機能の改修、社内フローを確立 ❏ リニューアル版のみの機能も開発して移行への動機づけ （従来システムでは機能追加がほとんど行われていない） ❏ ユーザをいくつかのグループに分けてそれぞれに合った方法を模索 24


©SO Technologies Inc. 
 25
 今後の挑戦 ❏ リニューアルを完遂 ❏ アウトカムを意識した開発 ❏ 利用状況から解約防止や機能の利用促進などのコンサルティング ❏ 広告データの利活用