誰も仕様を知らない──負債を倒すチームをゼロから作った話 / Nobody Knows the App Specification - How I Built a Team from Scratch to Defeat Technical Debt

by tark_ann

Slide 1

Slide 1 text

©MIXI スクラムフェス大阪2025 2025/7/19 誰も仕様を知らない ──負債を倒すチームをゼロから作った話

Slide 2

Slide 2 text

2 ©MIXI 2 2 ⾃⼰紹介 ● ターク(@tark_ann) ● 株式会社MIXI iOSエンジニア ● スクフェス初登壇がスクフェス大阪2022 ○ 2.5年ぶりの登壇 ● アジャイルコミュニティとの関わり ○ アジャイル札幌メンバー ○ RSGT2023~ カメラスタッフ

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

©MIXI 技術的負債とは？

Slide 5

Slide 5 text

©MIXI 5 5 技術的負債とは？ ● 移⾏が必要 or 移⾏中のシステム ● プロジェクトやAPIのドキュメント不⾜ ● テストのデータ‧範囲‧品質不⾜ ● 低品質なコード ● デッドコード、放棄されたコード GoogleがIEEEで出した⽂献での技術的負債の定義 Ciera Jaspan, Collin Green Deﬁning, “ Measuring, and Managing Technical Debt”, IEEE Software, vol. 40, no. 3, pp. 15-19, May-June 2023, doi: 10.1109/MS.2023.3242137. https://ieeexplore.ieee.org/document/10109339 ● メンテナンスされず劣化したコード ● 必要な専⾨知識が不⾜しているチーム ● 不安定な依存関係 ● 移⾏失敗 or 中⽌による2バージョンの運⽤ ● 最適化されていないリリースプロセス

Slide 6

Slide 6 text

©MIXI 6 6 minimoが抱える課題 ● サービス全体 ○ 今現在のアプリ機能を説明するドキュメントが存在しない ○ ユーザーから⾒えないアプリロジックがコードにしか残っていない ● モバイルアプリ ○ レガシーな技術のメンテナンスコストが⼤きく、機能追加の⼯数が膨れる ○ iOS/Androidで機能‧仕様差異がある

Slide 7

Slide 7 text

©MIXI 7 7 minimoモバイルアプリの技術的負債 ● ⾮推奨APIを使った機能実装 ● ユニットテストは書けそうなところだけにしかない ○ ⼀番必要なコアロジックは密結合でテストが書けない ● 変な参照が残っているが実態はデッドコード ● 依存関係が複雑怪奇な泥団⼦モジュール ● その当時流⾏したアーキテクチャパターンが複数世代混在 ● Figmaコンポーネント定義とアプリ実装コンポーネントに差分がある

Slide 8

Slide 8 text

©MIXI だいたいの技術的負債を踏んでいました

Slide 9

Slide 9 text

©MIXI 9 9 技術的負債専任メンバーの発⽣ ● 平均20代後半の若⼿エンジニアチーム ○ 私以外リアーキテクチャ経験なし ● iOS/Android それぞれで課題を整理 ● 私はリードという名のPjMへ ○ 機能開発のサポートもやる機能開発とは別に専任メンバーで解消⽬処を⽴てる取り組みへ負債解消専任

Slide 10

Slide 10 text

©MIXI 負債解消の道を歩み始めたが...

Slide 11

Slide 11 text

©MIXI 11 11 認証基盤が作り出す"仕様の迷路" ● 11年前に作成されたコードによる混乱 ○ 同じ認証処理を通る謎ループやそのループ内の分岐⽤フラグ乱⽴ ○ 認証処理モジュールに突如現れるUIロジックの塊 ● 1つ調べようとするとわからないことが3つ以上出てくる ○ 終わりが⾒えない調査が延々と続く疲労感 ○ ⾒通しが⽴たない、爆発する⾒積もりとスケジュール ※ 当時AI活用は社内整備ができておらず、人力で調査する必要があった

Slide 12

Slide 12 text

©MIXI 11年の重みがつらい...

Slide 13

Slide 13 text

©MIXI 13 13 仕様の意思決定者あいまい問題 ● iOS/Androidの仕様差異の解消をどう意思決定するか決まっていない ○ 暫定の意思決定者のマネージャーはモバイル領域の技術に詳しいわけではない ■ 技術的なことは事実上私の意⾒が採⽤されていた ■ マネージャーを捕まえるのも⼀苦労、リードタイムが⻑くなる ○ プロダクト仕様はマネージャーだけでも決められない ■ PdMを巻き込む必要があり、さらにリードタイムが⻑くなる...

Slide 14

Slide 14 text

©MIXI 14 14 刻々と変わる組織状況 ● モバイルデザインのコンポーネントシステム改善の動き ○ デザイナーも技術的負債解消を進めることへ ● マネージャーの交代 ● 負債解消を推進していたAndroidメンバーの離脱

Slide 15

Slide 15 text

©MIXI 新マネージャーからひとこと

Slide 16

Slide 16 text

©MIXI このままだとヤバいね ...

Slide 17

Slide 17 text

©MIXI 17 17 新マネージャーから⾒た課題 ● iOS/Android/デザインが独⽴して動くことのマネジメントコストが⾼い ○ 事業として何がどれだけ動いて、その優先度は妥当か判断するのが難しい ● 今の体制で負債解消をやり切れるリードメンバーが不⾜している問題 ○ 今まで推進していたAndroidメンバー離脱によって停滞してしまう懸念このままだと失敗しそう

Slide 18

Slide 18 text

©MIXI 新マネージャーとどうしていくか議論中

Slide 19

Slide 19 text

©MIXI スクラムとかいいんじゃない？

Slide 20

Slide 20 text

©MIXI お？？？

Slide 21

Slide 21 text

©MIXI 21 21 私の頭の中によぎった反応 ● スクラムはできてないことを明らかにすると⾔われてるけど... ○ 今したいことはそれじゃないよね？ ● アジャイル‧スクラムの知識がないメンバーばかりだけどやるの？ ○ 考え⽅や価値観を学べてないメンバーでうまくいく⾃信はない ■ アジャイル‧スクラムを学ぶ時間的余裕もない印象だったし... ○ レクチャーしてもカーゴカルトスクラムになる懸念スクラムで何を解決できると思っているんだろう？？？

Slide 22

Slide 22 text

©MIXI マネージャーが何を考えているのかわからない

Slide 23

Slide 23 text

©MIXI 変な邪推をする前に直接聞こう！

Slide 24

Slide 24 text

©MIXI 24 24 新マネージャーと整理したこと ● マネジメント⽬線の課題解決ができればやり⽅はなんでもいい ○ 負債解消活動全体の⾒通しの悪さを改善したい ○ 短時間で把握できるように情報の⼀元管理できると嬉しい ● ⼀度に全部の課題を解消する必要はない ○ 課題が多いのはわかっているので、徐々に改善できればOK ○ 今の課題をどう解決していくか道筋を⾒つけたいスクラム導⼊で何を解決したい？？

Slide 25

Slide 25 text

©MIXI スクラムじゃなくてもいい

Slide 26

Slide 26 text

©MIXI 26 26 解像度を上げて整理した課題 ● ゴールのビジョンや課題へのスタンスが揃っていないかもしれない ○ 事業⽅針とマッチしているのか、優先度が妥当なのか判断できない ● 今どんなことをしていて、どんな計画で進められているのか共有されてない ○ どれくらいの⼈や期間が必要なのかわからない ○ メンバーを増やしても、スケールする体制になっていない iOS/Android/デザインがそれぞれ活動することの⾒通しの悪さが課題

Slide 27

Slide 27 text

©MIXI 負債解消チームになった⽅が良さそう

Slide 28

Slide 28 text

©MIXI 28 28 チームを作るときに考えたこと ● スクラムなどのフレームワークを丸ごと取り⼊れない ○ メンバーに知⾒がないので短期的にパフォーマンスが落ちる ○ やりたいことも⼭積みの中でメンバーがネガティブに捉えそう ● 課題解決のためのプラクティスについて、メンバーの納得がなければ導⼊しない ○ 納得感がないと「なぜ」が⾃分ごとにならず、やらされ感が出そう現場の課題に定着しそうな改善をコツコツ

Slide 29

Slide 29 text

©MIXI フレームワークの⼀部導⼊ってアンチパターンの典型例だけど...

Slide 30

Slide 30 text

©MIXI 今の課題は解決できそうという⾃分の直感を信じて試すぞ！

Slide 31

Slide 31 text

©MIXI 31 31 チームでやったこと1 ● Trello、スプシなど分散していたツールをNotionバックログ管理に⼀元化 ○ 全員が同じ場所を⾒て状況を把握できるように ● タスクに記載することなどフォーマットを統⼀ ○ Doneの必須化など記載することを整理しタスクのあいまいさを減らす ○ タスクのステータスを共通にしてフローを明確にそれぞれが持っているタスクリストをカンバンで管理 WIP制限などカンバンガイドのプラクティス全部は導入してない

Slide 32

Slide 32 text

©MIXI 32 32 カンバン導⼊で⾒えたこと ● 他のメンバーの状況が⾒えることでサポートしやすくなった ○ タスクの滞留状況が可視化され、相談やサポートの⽬安も可視化された ■ リード‧マネージャーからの問いかけがより効果的になった ● Done の明確化でやることのイメージが揃うようになった ○ 作業イメージのすれ違いによる抜け漏れを防げた

Slide 33

Slide 33 text

©MIXI 33 33 チームでやったこと2 ● 朝会には相談コーナーを設定、気軽に相談できる⽂化作りを意識 ○ 2次会3次会を推奨、やることが明確になるまでとことん話す ● スプリントごとにやることの⽅向性を擦り合わせる ○ iOS/Android/デザインで協働することがないか⽬線合わせ ○ バックログの順番を整理し、iOS/Androidでやることが重複しないよう連携朝会‧スプリント‧ふりかえりの導⼊デイリースクラムの原則15分は完全に無視スプリントレビューはない

Slide 34

Slide 34 text

©MIXI 34 34 チームでやったこと2 ● KPTではない、⽬的が違うふりかえりをすることを説明 ○ 個⼈で課題に悩むのではなく「チーム vs 課題」として考えたい ■ 課題に感じたことをチームの共通認識にしたい ■ ⼀旦は解決案とか考えなくていい ○ 無理に改善が出てこなくてもOK ■ 私やマネージャーの知⾒を積極的に活⽤してほしい朝会‧スプリント‧ふりかえりの導⼊全員で課題と向き合うことを第一に

Slide 35

Slide 35 text

©MIXI 35 35 朝会‧スプリントの導⼊で⾒えたこと ● 課題共有の頻度が増え「チーム vs 課題」で考える機会が増えた ○ Slack など⾮同期の相談も徐々にでるようになった ● メンバー間のサポートがしやすくなった ○ 「余裕なさそうなのでこっちは引き受けますね」という会話が出るようになった ● 朝会が終わった後の雑談などコミュニケーションが活性化 ○ エンジニア‧デザイナーの考え⽅の違いなど深い話もできるようになった ●

Slide 36

Slide 36 text

©MIXI 36 36 ふりかえりの導⼊で⾒えたこと ● どうすればいいかわからないけど変えたいという意⾒が出るようになった ○ 私が「どうすればいいかわからないけどこう感じてる」を積極的に出した ○ 「私のためにもわからないことがあったら⾔ってほしい」を⼝癖にした ○ メンバーも少しずつこう感じたという発⾔をしてくれるように ● 俯瞰して⾒直すことで、作業当時は⾒えていなかった改善に気づけるようになった ○ やらなければならないことだけではなく、やりたいことも話せるように

Slide 37

Slide 37 text

©MIXI 37 37 チームでやったこと3 ● トレードオフスライダー ○ ⼟台となる観点設計は私が事前に整理、メンバーと⼀緒にブラッシュアップ ○ クイックソートアルゴリズムで観点の重みを整理 ■ 中⼼となる観点を1つ設定し、ざっくり2つのグループに分ける ■ 2つのグループの中で中⼼観点を設定し、また2つのグループに分ける ■ グループ分類しながら価値観の違いを明らかにし相互理解していくトレードオフスライダー、やらないことリストでチームの共通⾔語を作る

Slide 38

Slide 38 text

©MIXI 38 38 チームでやったこと3

Slide 39

Slide 39 text

©MIXI 39 39 チームでやったこと3 トレードオフスライダー、やらないことリストでチームの共通⾔語を作る定期的に見直して価値観をアップデート ● やらないことリスト ○ iOS/Android/デザイナーそれぞれで決まってないと困ることを洗い出す ○ 具体例を元に課題が出ないかイメージしながらチーム⽅針を整理 ○ 「あとで決めること」という項⽬を設定 ■ 今重要ではなく保留で問題ないものは意図して決めない

Slide 40

Slide 40 text

Slide 41

Slide 41 text

©MIXI 41 41 チームの共通⾔語を作って⾒えたこと ● 「わかっていたつもり」が⾒つかる ○ 具体的なユースケースを例に議論すると認識のズレに気づける ○ 組織課題と現場課題の解像度が上がり相互理解が進んだ ● パッと判断できない、わからないという率直なフィードバックはとても貴重 ○ 相⼿がどう考えているか知る機会になり、信頼関係構築の場として効果的だった

Slide 42

Slide 42 text

Slide 43

Slide 43 text

©MIXI 43 43 マネージャーの課題感を解消できた ● メンバーがそれぞれ何をやっているのか把握できるようになった ○ ミーティングに参加できなくても困ることが減った ○ どんなことで連携が必要か把握しやすくなった ● マネージャーがサポートした⽅がいいことも考えやすくなった ○ 現場に任せてよさそうかどうか判断できるようになった ○ 先を⾒据えて考えたいことを現場に相談できるようになった

Slide 44

Slide 44 text

Slide 45

Slide 45 text

©MIXI 45 45 意思決定の参照コストが重い問題 ● 不確実性が⾼い環境下なため、暫定⽅針としての意思決定をすることが多い ○ ⼀週間前に決めたことが、翌週には⽅針が変わることもある ○ ドキュメントを書いてもすぐ捨てる環境での書くコストの重さ ● 紆余曲折あった意思決定を後から⾒直した時に、経緯がわかりづらい ○ 議事録ベースで記録されているため、時には記述が分散していることも ○ ⼝頭の議論が加熱して議事録にすら残ってなかったことも...

Slide 46

Slide 46 text

©MIXI 46 46 新メンバーのオンボーディングが⼤変 ● 新メンバーが⼊るタイミング次第で、どんどん環境が変わっている ○ 定型的なオンボーディングタスクと不安定なオンボーディングタスクが混在 ○ 技術検証中で実装⽅針がそもそも決まってないこともある ● 不安定なタスクは既存メンバーに聞くしかない状況 ○ オンボーディングページに記載がないことも...

Slide 47

Slide 47 text

Slide 48

Slide 48 text

©MIXI 48 48 ドキュメント書いて運⽤するのがそもそも⼤変 ● 暫定⽅針を決める > やっぱダメそうというサイクルが早い環境 ○ その度にドキュメントを更新するのは⼼理的にもコストが⾼い ● 気軽にドキュメントを書けるようにならないとダメそう ○ 暫定の⽅針を書く ○ 紆余曲折する中で検討したことをまとめる ○ 最終的に決まった⽅針を書く

Slide 49

Slide 49 text

©MIXI 49 49 ADRの導⼊ Michael Nygard, November 15, 2011, “Documenting Architecture Decisions” https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions.html Olaf Zimmermann, Sep 6, 2022, “ADR = Any Decision Record? Architecture, Design and Beyond” https://ozimmer.ch/practices/2021/04/23/AnyDecisionRecords.html ● Any Decision Record ○ アーキテクチャに限らず、デザインの意思決定も記録するようにした ■ Architecture Decision Recordをより汎⽤的に使う ○ LADR(Lightweight Architecture Decision Records)フォーマットを使⽤

Slide 50

Slide 50 text

Slide 51

Slide 51 text

©MIXI 51 51 ADRでドキュメントを整備した結果背景まで残っていると説明コストが改善された ● 前提が変わった時の議論の⽅向が明確になった ○ 前提が変わることによるちゃぶ台返しのような提案も遠慮なくできるように ● 新メンバー‧機能開発メンバーへ共有する際にも活⽤ ○ 何をどういう検討をして意思決定したのかわかるので納得しやすくなった

Slide 52

Slide 52 text

Slide 53

Slide 53 text

©MIXI 53 53 オンボーディングでドキュメント更新わからないことをまとめるのが最初の仕事 ● オンボーディング中にドキュメントの改善ポイントを⾒つけてもらう ○ わからないことや古い内容など新メンバーだから⾒えることを探してもらう ○ オンボーディング設計も改善したいので都度修正ではなくメモで蓄積 ● オンボーディング完了時にふりかえりを実施 ○ 表現など記載内容の問題なのか、作業⼿順などプロセスに課題があるのか整理

Slide 54

Slide 54 text

Slide 55

Slide 55 text

©MIXI 55 55 モブワークなど協働が⾃然にできる環境へ ● ここのデザイン実現を悩んでいて...直接作業を共有しながら検討 ○ Figmaの画⾯共有しながらパターン⾒て議論 ○ 直接の関係者以外も気になったら参加できるスタイルでの検討が増えた ● iOS/Android仕様整理する時も協⼒しながら調査 ○ OS差分を調査しやすいフォーマットへ仕様書をアップデート ○ 事前に協⼒しながら仕様書を埋められるように ○ OS差分をどう解消するかを中⼼に議論

Slide 56

Slide 56 text

©MIXI 56 56 メンバーからの改善提案が出るようになった ● バックログ管理のここがわかりづらいからこんな感じにしたい ○ この情報があった⽅がいいのでは？ ● ふりかえりを職能別にするようにしたい ○ iOS/Androidなど込み⼊った課題をふりかえりたいが話しづらい問題が発⽣ ○ チーム全体の課題は解決されたが専⾨領域の課題は依然残ったまま ○ チーム全体のふりかえりをやめて職能のふりかえりへシフト

Slide 57

Slide 57 text

©MIXI 57 57 ● 「わからない」ことを表明できる環境を作ろう ○ 「わからない」にはヒントがいっぱいある ● アンチパターンも状況によっては効果的なこともある ○ 課題を観察しアンチパターンの状況と同じなのか冷静に分析しよう ○ 世間的にはダメと⾔われていても課題が解決するなら挑戦する勇気を持つ ● 課題背景をドキュメント化してチームの所有物にしよう ○ 「なぜ」がわかると納得感を⽣みチームの前進⼒になる ○ 課題背景が残っていると議論の空中戦を回避できる効果的だった取り組みまとめ