狠狠撸

Con?dential
株式会社テイラーワークス
執行役員 VPoE / アプリエンジニア
辰濱健一
【技術的負債 LT会】
私たちの技術負債最前線
～過去と未来について～
1
2024.08.01
https://coconala.connpass.com/event/325628/

Copyright ? TAILORWORKS.INC All Rights Reserved.
Agenda
Agenda
● 自己紹介
● プロダクト紹介
● 技术负债についての認識合わせ
● テイラーワークスでの技術負債と対応例

自己紹介
辰濱健一（Kenichi Tatsuhama）
徳島県神山町在住。
ジャストシステムを経て、Sansanで法人向け?個人向けの名刺管理サービスのモバイ
ルアプリ開発を担当し、同アプリのグローバル展開をリード。
Google Developer
Group 四国オーガナイザー。
2022年8月よりテイラーワークスに参画、執行役員
VPoEに就任。
趣味
● 楽器演奏（トランペット、篠笛）
● 旅行（2024GW は世界一周）
休日の過ごし方
● エンジニアコミュニティ活動
● 地域の草刈りや森の手入れ

会社概要

事業内容?MISSION
世界を変えるつながりを創る
テイラーワークスは、業界や文化を超えて革新的な技術やアイデアを繋ぎ、ビジネス
パーソンや企業間の共創活動を仕立てることで、社会全体のイノベーションを加速し、
世界に新たな価値をもたらします。

6
TAILOR WORKSは、
テクノロジーを活用してビジネスシーンのあらゆる関係構築を支援していく企業
目指すべき世界は、
あらゆるビジネスパーソンがデジタルツインを持ち、
もう一人の自分としてビジネスの関係構築を進めていける世界

7
TAILOR WORKSは、
エンジニアで言えば、
GitHub アカウントでの活
動や評価が該当

コラボレーション創出を仕組み化させる BtoBマッチメイキングエンジン
サービス紹介?AIマッチメイキングエンジン「TAILOR WORKS」
MATCHMAKING

コラボレーション創出を仕組み化させる BtoBマッチメイキングエンジン
サービス紹介?AIマッチメイキングエンジン「TAILOR WORKS」
MATCHMAKING
Since 2024/5
裏側で
Gemini を
使ってます

Copyright ? TAILORWORKS.INC All Rights Reserved. 10
before 2024/05…

多様な人々と共感やビジョンでつながり
世界を変えるアイデアを実現する
共創コミュニティプラットフォーム
2024/05 までの主力プロダクト

サービス比較
2024/05 にプロダクトが大きくピボットした
コミュニティ横断は自由
オープンなプラットフォーム
コンテンツもコミュニティ外に公開できる
イノベーション創出のための
コミュニケーションツール
コミュニティ運用支援
? 2024/05 2024/05 ?
ビジネスマッチメイキング
組織内に完全にクローズ
Needs
Visibility
このあたりの話もし
ます。

开発体制
PdM
デザイナ
（業務委託）
フロントエンド
（以後 FE）
バックエンド
（以後 BE）
VPoE / スマホアプリ
（たまにフロントエンド、まれにインフラ）
QA
（業務委託）
少人数ではあるものの、スキルや利用技術の都合上 FE / BE チーム分けをしている。
（フルスタックエンジニアになる事?チャレンジは Welcome）

サービス比較
利用技術
PHP, Python, MySQL, ECS
React.js, Next.js, TypeScript
? 2024/05 2024/05 ?
React.js, Next.js, TypeScript
TypeScript, PostgreSQL, EC2, Gemini
Frontend
Backend
AWS AWS
Infra
TypeScript が共通
→ フルスタックへの
ハードル減
往来のハードルが高い

技術負債とは
https://www.infoq.com/news/2010/05/what-color-backlog/
バックログのカテゴライズによると、見えないネガティブな価値
ユーザー体験開発者体験

技術負債とは
https://www.infoq.com/news/2010/05/what-color-backlog/
バックログのカテゴライズによると、見えないネガティブな価値
ユーザー体験開発者体験
ビジネスサイドか
ら理解されづらい
…
ビジネス的に優
先したい部分
開発者体験が悪い
と、生産性の悪化や
退職のリスク

技術負債とは
https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
発生理由による分類

技術負債とは
https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
発生理由による分類
未成熟
短納期
業務知識不足
新たな解決策
の登場
負債を負債と認識でき
てない…?

技術負債とは
● バックログの分類上、見えづらいが見過ごせない領域
○ 見過ごすと、生産性の悪化や、エンジニアの退職のリスク
● 発生要因もいくつかある
○ 短納期、未成熟、業務知識不足、コミュニケーション不足…
○ 必ずしも、手抜きや悪とは限らない（短期的な最適解）
● 技術負債の返済
○ バックログの他の領域との優先順位判断が必要
○ 発生理由に応じた対応が必要

テイラーワークスでの
技術負債の原因と対応
前述の発生理由を
なぞってみます

負債事例①
同一の対象物の変数名が BE と FE で異なる
例）人物… Person, Member, User
● ドメインやユビキタス言語（やそのものの存在）の認識不足
● チーム間のコミュニケーション不足
○ リファインメントでユーザー目線で（日本語で）認識のすり合わせを行った
が、開発者目線で（変数名で）認識のすり合わせてない
● API 仕様を事前に決めず、API 実装後にスキーマが共有され、表記が違っても
後戻りできない状態…
● スキーマ駆動開発を参考にして、先に API のインターフェイスの合意を取る
→ 早い段階で英語の表記名が fix し、表記がブレにくくなる
● （既存実装は無理に揃えず、BE / FE 境界で名前を変換し、BE / FE 内の用語の
統制に留める）
事象
原因
対応

負債事例②
現行メンバーでメンテしづらい言語の実装
例）あるサービスの API が PHP 実装
● 初期実装メンバーのスキルセットでの当時の最適解
● 後のメンバーの入れ替わりで、チーム内のスキルセットが変わっていった
● 別サービスも立ち上がり、Python での API が増えて行った
● メンテしやすい言語での書き換え
○ 一気に書き換えるのではなく、機能修正で触るところから徐々に実施（リリー
ス前テストで触るので、デグレのリスクも軽減）
事象
原因
対応

負債事例③
status == 1 （1 って何を表しているの…！？）
例）0: 限定公開、1: 非公開、2: 全公開
● 可読性?暗黙知に関する無自覚
○ 動けば良い
○ 実装者は 0?2しかないことがわかっている
● 「API から 1 が返ってくるから FE も 1 で扱う他
ない」という設計知識の未成熟
● Enum での再定義
○ API から1が返ってこようが、API 利用側で
は enum で扱う
○ 未成熟要因なら、コストをかけてでもコード
レビューを通して習得してもらう
● switch 文の網羅性の恩恵がある
事象
原因
対応

未成熟要因の解消
【補足】未成熟要因の解消
● レイヤー化に限らず、設計の理解不足は後
のレビューコスト増にもつながるため、早期
解消を目指す
● PR のコメント上で解決しなさそうなら、コミュ
ニケーションをテキストから会話に切り替え
る
● 必要に応じて、チームの夕会で議論や認識
合わせを実施
未成熟要因

Switch 文の網羅性
【補足】Switch 文の網羅性
● switch 文の評価に enum, union type, sealed class などの列挙型を使うと、
不足している case があればエラーになる
● int や string を switch の評価に使っても、網羅性チェックは効かない
● API から primitive な値が返ってきても、FE では enum 等に変換する

負債事例④
フレームワーク（ Python）のアップデート
● 影響範囲が大きく、なかなかアップデートができていなかった
○ 例）主要な ID 型を変えざるを得ない
＆スマホアプリに先行して互換性対応を入れる
● 「見える価値」が優先されがちだった
○ （エンジニア側から「見えない価値」の訴求不足？？）
● 開発期間?検証期間を確保して対応
事象
原因
対応

負債事例⑤
SlowQuery の多発
● いくつものテーブルを join して返すケースが多かった
○ 例：メンバー詳細に色んなデータが紐付いていた
● API が各所で共通利用しており、不必要なデータも取得しているケースがあった
● Server Side Join から Client Side Join へ
○ API の呼び出し回数は増えるが、1リクエストあたりの時間は軽減
○ バックエンドの実装もシンプルになり、バグの温床が減る
○ フロントエンドでは bff を用意して、UI がほしい形式にデータを整形
事象
原因
対応

負債事例⑤
【補足】Service Side Join と Client Side Join
Service Side Join Client Side Join
1回の API
呼び出し
3回の API
呼び出し
join
join

負債事例⑥
オープンなプラットフォームだったはずなのに、非公開機能の要件が
増えてくる
● 顧客ニーズの変化
○ 他コミュニティとの交流から、自コミュニティ内での交流にシフト
● ターゲット市場のシフト
○ 収益性の高い市場にシフトしたことにより、コミュニティ内の情報の秘匿性が
増してきた
● 初めのうちは公開設定機能を増やして対応
● 誤操作（非公開設定にし忘れ）による情報漏えいリスクも増え、
プロダクトをピボットしてフルスクラッチ
事象
原因
対応

ピボット前
ピボット前
● Facebook のように、
○ 全顧客同じ URL でログイン
○ ログイン後にコミュニティ往来が自由
● 非表示コミュニティも作成できる
● 未ログインでも一定のコンテンツは閲覧でき
る
コミュニティを横断で
きる
サービスdomain配下に
コミュニティ
未ログインでも閲覧
できる
他コミュニティの公開
コンテンツが並んで
いる

ピボット直前
ピボット直前
● Facebook のように、
○ 全顧客同じ URL でログイン
○ ログイン後にコミュニティ往来が自由
● 非表示コミュニティも作成できる
● 未ログインでも一定のコンテンツは閲覧でき
る
コミュニティを横断で
きる
サービスdomain配下に
コミュニティ
未ログインでも閲覧
できる
他のコミュニ
ティには行かせ
たくない！
ログインしない
と見せたくない
独自環境で
動かしたい
（サブドメイン）
他コミュニティの公開
コンテンツが並んで
いる
他のコミュニ
ティの情報は不
要
IPアドレス制限した
い！
データは他顧客と
論理的に分断され
ているか？
??

サービス比較
プロダクト要件の変化
コミュニティ横断は自由
オープンなプラットフォーム
イノベーション創出のための
コミュニケーションツール
コミュニティ運用支援
? 2024/05 2024/05 ?
ビジネスマッチメイキング
組織内に完全にクローズ
Needs
Visibility
共通環境
独立環境
（マルチテナント）
Infra
(Needs)
2023年秋頃から、
独立環境のニーズが
ちらほら…
別サービスとして
フルスクラッチ！
コンテンツの公開範囲設
定などで、
独立環境ニーズを凌ぐ

約2ヶ月で別サービスをフルスクラッチ開発

フルスクラッチ後
フルスクラッチ後
● メリット
○ ビジネス要件は解消 ?
○ ピボット前のプロダクトの技術的課題（今だと他に最適解がある）もこの機に解消?
● デメリット
○ 短納期だったので、意図的な負債はたくさん発生…
○ マルチテナントのデータ分離のために、MySQL -> Postgres の乗り換えをしたので、無自覚
な負債もちらほら…
○ BE / FE は得意領域にフルコミットしてもらったので、API を境界に双方の業務知識の認識
不足が発生…

【新たな学び】
技術的負債はビジネス要件からも発生する
（どれだけ技術力が高くても不可避）

Wrap Up

Wrap Up
● 確認したこと
○ バックログ上の技術負債の位置づけ
○ 技術負債の原因
● 技術負債対応の紹介
○ コミュニケーション（API 駆動開発）
○ ドメインを正しく型で表現
○ コードレビューを通した教育
○ 慣れている言語に徐々に置き換え
○ Client Side Join
○ フルスクラッチ

技術的負債は開発活動にはつきもの。
実現したいこと
×：技術負債のない開発現場（←たぶん無理）
○：プロダクト?会社が目指すべき世界

41
TAILOR WORKSは、
エンジニアで言えば、
GitHub アカウントでの活
動や評価が該当

そのためにも …

● 「技術的負債」の共通認識
○ 意図して選択することもある。悪とは限らない
○ 一定の共存は必要
● 技術負債もバックログに載せて優先度判断
○ みえづらいが見過ごせないタスク
● 技術負債の要因分析と対応
○ いかに発生を抑制できるか？（教育?認識合わせ?情報共有）
○ ビジネス要件で発生することもある

最後に…

Hiring
採用ページ： https://www.wantedly.com/companies/tailorworks

企業ページ：https://tailorworks.com/
採用ページ：https://www.wantedly.com/companies/tailorworks

狠狠撸

【技術的負債LT会】私たちの技術負債最前線?過去と未来について? 2024/08/01

More Related Content

【技術的負債LT会】私たちの技術負債最前線?過去と未来について? 2024/08/01