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

スクラムフェス大阪2025 の登壇資料です
https://confengine.com/conferences/scrum-fest-osaka-2025/proposal/22754

Transcript

1. ©MIXI スクラムフェス大阪2025 2025/7/19 誰も仕様を知らない ──負債を倒すチームをゼロから作った話
2. 2 ©MIXI 2 2 ⾃⼰紹介 • ターク(@tark_ann) • 株式会社MIXI iOSエンジニア • スクフェス初登壇がスクフェス大阪2022 ◦ 2.5年ぶりの登壇 • アジャイルコミュニティとの関わり ◦ アジャイル札幌メンバー ◦ RSGT2023~ カメラスタッフ
4. ©MIXI 技術的負債とは？
5. ©MIXI 5 5 技術的負債とは？ • 移⾏が必要 or 移⾏中のシステム • プロジェクトやAPIのドキュメント不⾜ • テストのデータ‧範囲‧品質不⾜ • 低品質なコード • デッドコード、放棄されたコード GoogleがIEEEで出した⽂献での技術的負債の定義 Ciera Jaspan, Collin Green Defining, “ 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バージョンの運⽤ • 最適化されていないリリースプロセス
6. ©MIXI 6 6 minimoが抱える課題 • サービス全体 ◦ 今現在のアプリ機能を説明するドキュメントが存在しない ◦ ユーザーから⾒えないアプリロジックがコードにしか残っていない • モバイルアプリ ◦ レガシーな技術のメンテナンスコストが⼤きく、機能追加の⼯数が膨れる ◦ iOS/Androidで機能‧仕様差異がある
7. ©MIXI 7 7 minimoモバイルアプリの技術的負債 • ⾮推奨APIを使った機能実装 • ユニットテストは書けそうなところだけにしかない ◦ ⼀番必要なコアロジックは密結合でテストが書けない • 変な参照が残っているが実態はデッドコード • 依存関係が複雑怪奇な泥団⼦モジュール • その当時流⾏したアーキテクチャパターンが複数世代混在 • Figmaコンポーネント定義とアプリ実装コンポーネントに差分がある
8. ©MIXI だいたいの技術的負債を 踏んでいました
9. ©MIXI 9 9 技術的負債専任メンバーの発⽣ • 平均20代後半の若⼿エンジニアチーム ◦ 私以外リアーキテクチャ経験なし • iOS/Android それぞれで課題を整理 • 私はリードという名のPjMへ ◦ 機能開発のサポートもやる 機能開発とは別に専任メンバーで解消⽬処を⽴てる取り組みへ 負債解消専任
10. ©MIXI 負債解消の道を歩み始めたが...
11. ©MIXI 11 11 認証基盤が作り出す"仕様の迷路" • 11年前に作成されたコードによる混乱 ◦ 同じ認証処理を通る謎ループやそのループ内の分岐⽤フラグ乱⽴ ◦ 認証処理モジュールに突如現れるUIロジックの塊 • 1つ調べようとするとわからないことが3つ以上出てくる ◦ 終わりが⾒えない調査が延々と続く疲労感 ◦ ⾒通しが⽴たない、爆発する⾒積もりとスケジュール ※ 当時AI活用は社内整備ができておらず、人力で調査する必要があった
12. ©MIXI 11年の重みがつらい...
13. ©MIXI 13 13 仕様の意思決定者あいまい問題 • iOS/Androidの仕様差異の解消をどう意思決定するか決まっていない ◦ 暫定の意思決定者のマネージャーはモバイル領域の技術に詳しいわけではない ▪ 技術的なことは事実上私の意⾒が採⽤されていた ▪ マネージャーを捕まえるのも⼀苦労、リードタイムが⻑くなる ◦ プロダクト仕様はマネージャーだけでも決められない ▪ PdMを巻き込む必要があり、さらにリードタイムが⻑くなる...
14. ©MIXI 14 14 刻々と変わる組織状況 • モバイルデザインのコンポーネントシステム改善の動き ◦ デザイナーも技術的負債解消を進めることへ • マネージャーの交代 • 負債解消を推進していたAndroidメンバーの離脱
15. ©MIXI 新マネージャーからひとこと
16. ©MIXI このままだとヤバいね ...
17. ©MIXI 17 17 新マネージャーから⾒た課題 • iOS/Android/デザインが独⽴して動くことのマネジメントコストが⾼い ◦ 事業として何がどれだけ動いて、その優先度は妥当か判断するのが難しい • 今の体制で負債解消をやり切れるリードメンバーが不⾜している問題 ◦ 今まで推進していたAndroidメンバー離脱によって停滞してしまう懸念 このままだと失敗しそう
18. ©MIXI 新マネージャーと どうしていくか議論中
19. ©MIXI スクラムとかいいんじゃない？
20. ©MIXI お？？？
21. ©MIXI 21 21 私の頭の中によぎった反応 • スクラムはできてないことを明らかにすると⾔われてるけど... ◦ 今したいことはそれじゃないよね？ • アジャイル‧スクラムの知識がないメンバーばかりだけどやるの？ ◦ 考え⽅や価値観を学べてないメンバーでうまくいく⾃信はない ▪ アジャイル‧スクラムを学ぶ時間的余裕もない印象だったし... ◦ レクチャーしてもカーゴカルトスクラムになる懸念 スクラムで何を解決できると思っているんだろう？？？
22. ©MIXI マネージャーが何を考えているのか わからない
23. ©MIXI 変な邪推をする前に直接聞こう！
24. ©MIXI 24 24 新マネージャーと整理したこと • マネジメント⽬線の課題解決ができればやり⽅はなんでもいい ◦ 負債解消活動全体の⾒通しの悪さを改善したい ◦ 短時間で把握できるように情報の⼀元管理できると嬉しい • ⼀度に全部の課題を解消する必要はない ◦ 課題が多いのはわかっているので、徐々に改善できればOK ◦ 今の課題をどう解決していくか道筋を⾒つけたい スクラム導⼊で何を解決したい？？
25. ©MIXI スクラムじゃなくてもいい
26. ©MIXI 26 26 解像度を上げて整理した課題 • ゴールのビジョンや課題へのスタンスが揃っていないかもしれない ◦ 事業⽅針とマッチしているのか、優先度が妥当なのか判断できない • 今どんなことをしていて、どんな計画で進められているのか共有されてない ◦ どれくらいの⼈や期間が必要なのかわからない ◦ メンバーを増やしても、スケールする体制になっていない iOS/Android/デザインがそれぞれ活動することの⾒通しの悪さが課題
27. ©MIXI 負債解消チームになった⽅が良さそう
28. ©MIXI 28 28 チームを作るときに考えたこと • スクラムなどのフレームワークを丸ごと取り⼊れない ◦ メンバーに知⾒がないので短期的にパフォーマンスが落ちる ◦ やりたいことも⼭積みの中でメンバーがネガティブに捉えそう • 課題解決のためのプラクティスについて、メンバーの納得がなければ導⼊しない ◦ 納得感がないと「なぜ」が⾃分ごとにならず、やらされ感が出そう 現場の課題に定着しそうな改善をコツコツ
29. ©MIXI フレームワークの⼀部導⼊って アンチパターンの典型例だけど...
30. ©MIXI 今の課題は解決できそう という⾃分の直感を信じて試すぞ！
31. ©MIXI 31 31 チームでやったこと1 • Trello、スプシなど分散していたツールをNotionバックログ管理に⼀元化 ◦ 全員が同じ場所を⾒て状況を把握できるように • タスクに記載することなどフォーマットを統⼀ ◦ Doneの必須化など記載することを整理しタスクのあいまいさを減らす ◦ タスクのステータスを共通にしてフローを明確に それぞれが持っているタスクリストをカンバンで管理 WIP制限などカンバンガイドのプラクティス全部は導入してない
32. ©MIXI 32 32 カンバン導⼊で⾒えたこと • 他のメンバーの状況が⾒えることでサポートしやすくなった ◦ タスクの滞留状況が可視化され、相談やサポートの⽬安も可視化された ▪ リード‧マネージャーからの問いかけがより効果的になった • Done の明確化でやることのイメージが揃うようになった ◦ 作業イメージのすれ違いによる抜け漏れを防げた
33. ©MIXI 33 33 チームでやったこと2 • 朝会には相談コーナーを設定、気軽に相談できる⽂化作りを意識 ◦ 2次会3次会を推奨、やることが明確になるまでとことん話す • スプリントごとにやることの⽅向性を擦り合わせる ◦ iOS/Android/デザインで協働することがないか⽬線合わせ ◦ バックログの順番を整理し、iOS/Androidでやることが重複しないよう連携 朝会‧スプリント‧ふりかえりの導⼊ デイリースクラムの原則15分は完全に無視 スプリントレビューはない
34. ©MIXI 34 34 チームでやったこと2 • KPTではない、⽬的が違うふりかえりをすることを説明 ◦ 個⼈で課題に悩むのではなく「チーム vs 課題」として考えたい ▪ 課題に感じたことをチームの共通認識にしたい ▪ ⼀旦は解決案とか考えなくていい ◦ 無理に改善が出てこなくてもOK ▪ 私やマネージャーの知⾒を積極的に活⽤してほしい 朝会‧スプリント‧ふりかえりの導⼊ 全員で課題と向き合うことを第一に
35. ©MIXI 35 35 朝会‧スプリントの導⼊で⾒えたこと • 課題共有の頻度が増え「チーム vs 課題」で考える機会が増えた ◦ Slack など⾮同期の相談も徐々にでるようになった • メンバー間のサポートがしやすくなった ◦ 「余裕なさそうなのでこっちは引き受けますね」という会話が出るようになった • 朝会が終わった後の雑談などコミュニケーションが活性化 ◦ エンジニア‧デザイナーの考え⽅の違いなど深い話もできるようになった •
36. ©MIXI 36 36 ふりかえりの導⼊で⾒えたこと • どうすればいいかわからないけど変えたいという意⾒が出るようになった ◦ 私が「どうすればいいかわからないけどこう感じてる」を積極的に出した ◦ 「私のためにもわからないことがあったら⾔ってほしい」を⼝癖にした ◦ メンバーも少しずつこう感じたという発⾔をしてくれるように • 俯瞰して⾒直すことで、作業当時は⾒えていなかった改善に気づけるようになった ◦ やらなければならないことだけではなく、やりたいことも話せるように
37. ©MIXI 37 37 チームでやったこと3 • トレードオフスライダー ◦ ⼟台となる観点設計は私が事前に整理、メンバーと⼀緒にブラッシュアップ ◦ クイックソートアルゴリズムで観点の重みを整理 ▪ 中⼼となる観点を1つ設定し、ざっくり2つのグループに分ける ▪ 2つのグループの中で中⼼観点を設定し、また2つのグループに分ける ▪ グループ分類しながら価値観の違いを明らかにし相互理解していく トレードオフスライダー、やらないことリストでチームの共通⾔語を作る
38. ©MIXI 38 38 チームでやったこと3
39. ©MIXI 39 39 チームでやったこと3 トレードオフスライダー、やらないことリストでチームの共通⾔語を作る 定期的に見直して価値観をアップデート • やらないことリスト ◦ iOS/Android/デザイナーそれぞれで決まってないと困ることを洗い出す ◦ 具体例を元に課題が出ないかイメージしながらチーム⽅針を整理 ◦ 「あとで決めること」という項⽬を設定 ▪ 今重要ではなく保留で問題ないものは意図して決めない
40. ©MIXI 40 40 チームでやったこと3
41. ©MIXI 41 41 チームの共通⾔語を作って⾒えたこと • 「わかっていたつもり」が⾒つかる ◦ 具体的なユースケースを例に議論すると認識のズレに気づける ◦ 組織課題と現場課題の解像度が上がり相互理解が進んだ • パッと判断できない、わからないという率直なフィードバックはとても貴重 ◦ 相⼿がどう考えているか知る機会になり、信頼関係構築の場として効果的だった
42. ©MIXI ⼀つずつ課題に対応するプラクティスを 導⼊していった結果
43. ©MIXI 43 43 マネージャーの課題感を解消できた • メンバーがそれぞれ何をやっているのか把握できるようになった ◦ ミーティングに参加できなくても困ることが減った ◦ どんなことで連携が必要か把握しやすくなった • マネージャーがサポートした⽅がいいことも考えやすくなった ◦ 現場に任せてよさそうかどうか判断できるようになった ◦ 先を⾒据えて考えたいことを現場に相談できるようになった
44. ©MIXI まだまだ課題が現れる...
45. ©MIXI 45 45 意思決定の参照コストが重い問題 • 不確実性が⾼い環境下なため、暫定⽅針としての意思決定をすることが多い ◦ ⼀週間前に決めたことが、翌週には⽅針が変わることもある ◦ ドキュメントを書いてもすぐ捨てる環境での書くコストの重さ • 紆余曲折あった意思決定を後から⾒直した時に、経緯がわかりづらい ◦ 議事録ベースで記録されているため、時には記述が分散していることも ◦ ⼝頭の議論が加熱して議事録にすら残ってなかったことも...
46. ©MIXI 46 46 新メンバーのオンボーディングが⼤変 • 新メンバーが⼊るタイミング次第で、どんどん環境が変わっている ◦ 定型的なオンボーディングタスクと不安定なオンボーディングタスクが混在 ◦ 技術検証中で実装⽅針がそもそも決まってないこともある • 不安定なタスクは既存メンバーに聞くしかない状況 ◦ オンボーディングページに記載がないことも...
47. ©MIXI 後回しにしていたドキュメント負債が ⽛を剥いてきた
48. ©MIXI 48 48 ドキュメント書いて運⽤するのがそもそも⼤変 • 暫定⽅針を決める > やっぱダメそうというサイクルが早い環境 ◦ その度にドキュメントを更新するのは⼼理的にもコストが⾼い • 気軽にドキュメントを書けるようにならないとダメそう ◦ 暫定の⽅針を書く ◦ 紆余曲折する中で検討したことをまとめる ◦ 最終的に決まった⽅針を書く
49. ©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)フォーマットを使⽤
50. ©MIXI 50 50 ADRの導⼊
51. ©MIXI 51 51 ADRでドキュメントを整備した結果 背景まで残っていると説明コストが改善された • 前提が変わった時の議論の⽅向が明確になった ◦ 前提が変わることによるちゃぶ台返しのような提案も遠慮なくできるように • 新メンバー‧機能開発メンバーへ共有する際にも活⽤ ◦ 何をどういう検討をして意思決定したのかわかるので納得しやすくなった
52. ©MIXI 次に現れそうなのは ドキュメント更新忘れ問題
53. ©MIXI 53 53 オンボーディングでドキュメント更新 わからないことをまとめるのが最初の仕事 • オンボーディング中にドキュメントの改善ポイントを⾒つけてもらう ◦ わからないことや古い内容など新メンバーだから⾒えることを探してもらう ◦ オンボーディング設計も改善したいので都度修正ではなくメモで蓄積 • オンボーディング完了時にふりかえりを実施 ◦ 表現など記載内容の問題なのか、作業⼿順などプロセスに課題があるのか整理
54. ©MIXI 現場をコツコツ改善して 辿り着いた先は？
55. ©MIXI 55 55 モブワークなど協働が⾃然にできる環境へ • ここのデザイン実現を悩んでいて...直接作業を共有しながら検討 ◦ Figmaの画⾯共有しながらパターン⾒て議論 ◦ 直接の関係者以外も気になったら参加できるスタイルでの検討が増えた • iOS/Android仕様整理する時も協⼒しながら調査 ◦ OS差分を調査しやすいフォーマットへ仕様書をアップデート ◦ 事前に協⼒しながら仕様書を埋められるように ◦ OS差分をどう解消するかを中⼼に議論
56. ©MIXI 56 56 メンバーからの改善提案が出るようになった • バックログ管理のここがわかりづらいからこんな感じにしたい ◦ この情報があった⽅がいいのでは？ • ふりかえりを職能別にするようにしたい ◦ iOS/Androidなど込み⼊った課題をふりかえりたいが話しづらい問題が発⽣ ◦ チーム全体の課題は解決されたが専⾨領域の課題は依然残ったまま ◦ チーム全体のふりかえりをやめて職能のふりかえりへシフト
57. ©MIXI 57 57 • 「わからない」ことを表明できる環境を作ろう ◦ 「わからない」にはヒントがいっぱいある • アンチパターンも状況によっては効果的なこともある ◦ 課題を観察しアンチパターンの状況と同じなのか冷静に分析しよう ◦ 世間的にはダメと⾔われていても課題が解決するなら挑戦する勇気を持つ • 課題背景をドキュメント化してチームの所有物にしよう ◦ 「なぜ」がわかると納得感を⽣みチームの前進⼒になる ◦ 課題背景が残っていると議論の空中戦を回避できる 効果的だった取り組みまとめ