10Xに技術的負債をもたらした「2つの境界の歪み」その構造と解消への営み

https://technical-debt-con.findy-tools.io/2026での発表内容です。

1. に技術的負債をもたらした 「2つの境界の歪み」 その構造と解消への営み 10X, Inc. ALL RIGHTS RESERVED
2. 自己紹介 坂本 和大（さかもと かずひろ） @kazu0620(X, GitHub) 株式会社10X 執行役員 エンジニアリング管掌 2020年入社。現在は10Xの開発組織全体のマネジメント を担当。 10X, Inc. ALL RIGHTS RESERVED 2
3. 10X概要 Product s 小売産業の生産性や利益を高めるためのプロダクト 群を開発/運用。 MISSION: 小売業の未来を拓く 私たち10Xは、小売業が直面する課題を解決す るため、スーパーマーケットを中心とした小 売業のあるべき姿を描き、顧客体験と働き方 の進化に貢献します。 10X, Inc. ALL RIGHTS RESERVED 3
4. 10X概要 • ネットスーパーの運営に必要なすべての機能を提供してい る、国内トップクラスのネットスーパープラットフォーム • 様々な業態・規模・地域のネットスーパー事業を支えてい ます 導入企業 10X, Inc. ALL RIGHTS RESERVED 4
5. 10X概要 お客様向けネットスーパーアプリのほか、 ネットスーパー事業を支える業務用アプリケーションも提供しています 小売事業者向けアプリ 配達スタッフ向けアプリ ミスが少なく効率的な業務オペレーションを実現 スタッフ用アプリと完全連動し、効率的なルーティングを実施 10X, Inc. ALL RIGHTS RESERVED 5
6. 技術的負債とは何か 10X, Inc. ALL RIGHTS RESERVED 6
7. 技術的負債とは何か 同じ開発リソースを投じても、 生み出される価値を低減させるもの 開発自体の効率を下げるもの • 認知コストや変更コストの増大 • 開発フェーズにおける意図せぬバグや手戻りの増大 開発に使える時間を減らすもの • 利用者からの問い合わせによる調査 • 不具合やインシデントの対応 • 開発者の手動オペレーション 10X, Inc. ALL RIGHTS RESERVED 7
8. 技術的負債とは何か 技術的負債とは何か CASE: 1 初期状態 開発にリソースを注いだ分が摩耗す ることなくそのまま価値をもたらす。 また、妥当なコストで保守運用を営む ことができている状態。 10X, Inc. ALL RIGHTS RESERVED 8
9. 技術的負債とは何か 技術的負債とは何か CASE: 2 開発効率の低下 初期と同じ時間を開発作業に当てた としても、生み出される価値が半減し ている。 保守運用にかかるコストも増え、開発 作業に捻出できる時間自体も減って いる。 10X, Inc. ALL RIGHTS RESERVED 9
10. 技術的負債とは何か 技術的負債とは何か CASE: 3 ジリ貧の状態 初期よりも開発作業に大きく時間が かかる状態。かつ、開発自体に割け る時間も非常に少なくなっている。 小さな価値しか生み出せないまま前 に進むか、価値を生み出すことを一 時的に止めて、負債を返却するしか ない状況。 10X, Inc. ALL RIGHTS RESERVED 10
11. 技術的負債とは何か • 技術的負債は、同じ開発コストあたりで生み出せる価 値を低減させるもの。 • 技術的負債は、開発自体に使える時間を低減させるも の。 • 結果、技術的負債が増えると、その返却に当てる時間 を取ること自体が難しくなる 現実には、開発によって資産を作り出し、その資産が価値(売上)をもたらすので、より複雑 なモデルとなる- cf. ソフトウェアと財務 10X, Inc. ALL RIGHTS RESERVED 11
12. 何が技術的負債を生み出すのか 10X, Inc. ALL RIGHTS RESERVED 12
13. 何が技術的負債を生み出すのか 技術的負債をもたらすもの • • • • 業務理解が浅い状態で作り上げられた実装 将来の拡張や変更のコストを考慮しない実装 運用や保守のコストを見越した上での制約や設計の欠如 それらを助長する構造 10X, Inc. ALL RIGHTS RESERVED 13
14. 何が技術的負債を生み出すのか 技術的負債を助長する構造 ソフトウェアを開発する組織内での責務(境界)の問題 • 開発チームがオーナーシップを持って判断できない • 負債のツケを、開発したチーム自身が払う構造になっていない • 短期的な意思決定に寄りがちになる ソフトウェアの利用者との責務(境界)の課題 • 小売業だけで業務が完結できずオペレーションが必要になる • 調査の問い合わせが来る 10X, Inc. ALL RIGHTS RESERVED 14
15. 10Xが向き合ってきた構造の課題 チームの責務境界 10X, Inc. ALL RIGHTS RESERVED 15
16. チームの責務境界 Before: 顧客単位で開発チームを組成 • • • 10X, Inc. ALL RIGHTS RESERVED 当時は、個々のパートナーの 質問や要望にタイムリーに答 えることが特に重要だった。 着手までのリードタイムを減ら すために顧客単位でチームを 組成した。 将来的にプラットフォーム的な チームの組成を予定してい た。 16
17. チームの責務境界 実際どうだったか？ 良かった点: • パートナーに寄り添った意思決定/開発ができた。 • ビジネスサイドと開発チームが密にコミュニケーションしパートナーの 課題を柔軟に解決することができた。 • 実際に調査や要望に答えるスピードは上がった。 課題となった点: • 短期的に要望に答えるため、時に保守や長期的な観点を欠いた機能開発 が行われた。 • 対象とする業務の知識が開発チームに蓄積されない。 • 開発した機能のオーナーシップを持ちきれない状態になった。 10X, Inc. ALL RIGHTS RESERVED 17
18. チームの責務境界 オーナーシップを持ちきれない、とは？ • • • • ある機能を作った開発チームがそれをリリース後に運用し続けるわけで はない。 「運用でツケを払うのが開発したチーム自身」という構造になっていな かった。 長期的に機能としてどうあるべきかを考えた上でNoを言うことが難し い。結果、局所最適な実装が多くなる。 業務の理解よりも、目の前の課題を解くことにフォーカスする。 10X, Inc. ALL RIGHTS RESERVED 18
19. チームの責務境界 技術的負債とは何か 10X, Inc. ALL RIGHTS RESERVED 19
20. チームの責務境界 After: ドメイン別に開発チームを組成 • • • 10X, Inc. ALL RIGHTS RESERVED 業務ドメインの単位で開発 チームを再構築。 要望に答える速度よりも、長 期的にプロダクトが良いコン ディションを保てることを重 視。 ドメインごとに開発チームが オーナーシップを持って運用 する。 20
21. チームの責務境界 実際どうなったか？ 良かった点: • 開発チームが業務の知識を深める動きを取りやすくなった。 • 長期的なトレードオフを意識した上で、開発チームがスタンスを持って 意思決定できるようになった。 • 調査や運用のコストを下げるための提案や開発がチームから出るように なった。 課題となった点: • 個別パートナーの短期的な要望に寄り添ってタイムリーに答えることは 難しくなった。 10X, Inc. ALL RIGHTS RESERVED 21
22. チームの責務境界 短期的に早く要望を満たせないことについて • • 短期的に早く個別の要望に向き合えたとしても、長期で見ると結局要望 を満たすためにかかる時間は増大する（開発にかかるコスト / 保守のコ ストが増える）。 長く事業を続けることが前提として成り立つのであれば、初手から将来 のコストが増えない作り方をした方が、結果より多くの要望を満たすこ とができるはず。 10X, Inc. ALL RIGHTS RESERVED 22
23. チームの責務境界 チームの構造によってすべてが解決したのか？ • • • • No。構造は問題を解決しやすくする方向づけをするが、それによって 解決するわけではない。 各開発チームがソフトウェアの保守性を下げる要素を整理したり言語化 し、1つずつ向き合って解決してきた。 その改善に時間を割く、という組織としての意思決定は必要。 また、期待する開発に時間を割くことができる状況かのヘルスチェック も定期的に実施する必要がある。 10X, Inc. ALL RIGHTS RESERVED 23
24. チームの責務境界 モニタリング 10X, Inc. ALL RIGHTS RESERVED 24
25. チームの責務境界 顧客別のチーム構造の再考余地 • • • 10X, Inc. ALL RIGHTS RESERVED この形も当然事業や組織の状 況によって成立し得る。 ただし、組織やソフトウェア上 に境界/ガードレールがない と、容易に個別性がプラット フォームを侵食する。 プラットフォームの外側と内側 の境界をソフトウェア上でも明 示的に設計し、 IFや契約を介 して個別性を外側に配置でき るなら成り立つと考える。 25
26. チームの責務境界 学び • • • コードレベルで局所的に負債を返却したとしても、構造の課題が解消で きていないと負債は増え続ける。 負債が増え続けないような意思決定が可能となる構造を作る必要があ る。 そのためには、負債に対して開発チーム自身がコントロールできて、学 びのフィードバックサイクルを回せる状況であることが重要。 10X, Inc. ALL RIGHTS RESERVED 26
27. 10Xが向き合ってきた構造の課題 顧客との責務境界 10X, Inc. ALL RIGHTS RESERVED 27
28. 顧客との責務境界 技術的負債とは何か 保守運用として、 どんなことに時間 を使っているのか をチームごとに精 査する、というこ とをした。 10X, Inc. ALL RIGHTS RESERVED 28
29. 顧客との責務境界 何に時間を割いていたのか？ • • 機能の改修や開発以外の保守に、多くの時間を割いていることがわかっ た。 イレギュラーな調査やオペレーション（イレギュラーといいつつ、実際 には定常的な業務になっている）。 イレギュラーな作業の例 • • • 一定の頻度で必要となる手動オペレーション。 コード内にハードコーディングされた設定値の変更。 内部データを確認する必要がある調査依頼。 10X, Inc. ALL RIGHTS RESERVED 29
30. 顧客との責務境界 レギュラーなイレギュラー作業 • • • • • アプリケーションの仕様やコードで表現されていない業務。 アプリケーション上でガードレールを設計できず事故りやすい。 想定しなかったステータスやデータの状態になりかねない。 アプリケーションで担うべき業務がアプリケーションで表現されていない、 というモデリングの負債とも言える。 （アプリケーションで担うべきではない業務を持っているが故の負債、もあ る。） 10X, Inc. ALL RIGHTS RESERVED 30
31. 顧客との責務境界 レギュラーなイレギュラー作業はどこから生まれる？ • • • 開発のタイミングでは想定できなかった業務や概念が運用に入ってか ら発見される。 最初はイレギュラーなように見えるが、実はその業務を行うためには 一定の頻度で必要な業務であることが多い。 これをイレギュラーという認識のまま責務を明確にせず対応すると、 どこかで歪みが来る。 10X, Inc. ALL RIGHTS RESERVED 31
32. 顧客との責務境界 歪みを正すために - 責務の境界を再設計する • • • 10X, Inc. ALL RIGHTS RESERVED アプリケーションの利用者とアプリ ケーションの責務の境界を改めて明 らかにする。 そのために、イレギュラーだと捉え ていた業務を改めて理解した上で、 ソフトウェア上にモデリングする。 技術的な修正だけではなく、仕様や アプリケーションの利用方法を含め た線引きの調整が必要になる。 32
33. 顧客との責務境界 事例1. 配達エリア移管オペレーション ネットスーパーが店舗ごとに持っている「配達エリア」を移管する機能。例えば新しい店 舗がオープンしたとき、近隣店舗のユーザーの担当店舗が変更になる。 各種データの変更、ユーザー通知が必要となる。当初はこの業務を織り込んでいなかった ため、必要に応じて手動オペレーションで対応していた。 後に業務フローを整理した上で、正式なアプリケーションの機能として組み込む意思決定 をした。エリア移管、と呼ばれる定常業務が存在するならばそれはアプリケーションの機 能として提供されるべき。 本来アプリケーションが持つべき責務を、開発チームの手動オペレーションによって担っ ていた事例と言える。 10X, Inc. ALL RIGHTS RESERVED 33
34. 顧客との責務境界 事例2. 決済失敗時の手動徴収業務 クレジットカード決済で避けられないエラーが発生した際、小売スタッフが代金を手動で 徴収する業務が存在していた。この業務や状態の管理がシステムの外で行われていたた め、想定外のデータ状態や開発チームによる手動オペレーションが一定頻度で発生してい た。 該当の決済エラーを準正常系の業務として扱い「手動徴収が必要」という状態をステータ スに組み込んだ。結果、アプリケーションの想定した状態遷移に沿って業務を完結できる ようになった。 本来アプリケーションが持つべき責務を、顧客企業の手動オペレーションによって担って いた事例と言える。 10X, Inc. ALL RIGHTS RESERVED 34
35. 顧客との責務境界 事例3. 掲載商品データの不具合調査 小売企業の基幹システムから商品データを取り込み、売場に表示する工程で「なぜこの商 品は表示されないのか」「なぜこの価格になるのか」という問い合わせが頻発していた。 これを解決するために、10Xが担っていた小売企業ごとの個別データパイプラインを標準イ ンタフェースを介したものに移行し、責務の境界を動かす、共通の中間生成物をデータ ベース上に残すといった改修を実施。現在は、この中間生成物を小売企業が閲覧できるよ う開発を進めている。 個別性を受け入れるためにまず必要だったのは、個別の実装ではなく共通インタフェー ス。 本来顧客企業のアプリケーションが担うべき責務を、我々のアプリケーションが担ってい た事例と言える。 10X, Inc. ALL RIGHTS RESERVED 35
36. 顧客との責務境界 これらは技術的負債と言えるのか？ 広義には言えると考える。業務を理解し、その概念を蒸留した上でモデリン グすることがソフトウェア開発・エンジニアリングであるとするならば、適 切ではないモデリング・不足したモデリングは技術的負債とも言えるのでは ないか。 機能開発時の業務の理解不足や考慮不足の結果、あるべき境界で責務を切る ことができなかったがゆえの負債である、と捉えることはできる。 10X, Inc. ALL RIGHTS RESERVED 36
37. 顧客との責務境界 最初から責務が曖昧な部分を生まないために • • 開発チームが業務を理解して、リリースだけではなく運用まで見据えた 上でトレードオフの判断や意思決定を行う。 アプリケーションの利用者が、アプリケーションの中で例外的な作業も 含めた上で一連の業務を完結できるのか、考慮し設計する。 10X, Inc. ALL RIGHTS RESERVED 37
38. 顧客との責務境界 言葉の発明 - 運営自律性 • • • 「ネットスーパーの運営を小売企業で完結させるための機能が揃ってい るか？」を意味する言葉。 保守性に向き合うタイミングで誕生し、社内では浸透している。 この「運営自律性」という言葉があることによって、仕様や設計の時点 でその運営まで含めて正しい責務を設計できてるか？を意識しやすく なっている。 10X, Inc. ALL RIGHTS RESERVED 38
39. 顧客との責務境界 学び • • コードレベルの品質が高まったとしても、アプリケーションの利用者と アプリケーションの責務が正しく設計されていないと、開発やソフト ウェアの改善に向き合う時間が圧迫される。 正しい責務の境界を切るためには、業務を正しく理解することが重要。 そのための対話や調査を行う時間を取る。 10X, Inc. ALL RIGHTS RESERVED 39
40. おわりに 10X, Inc. ALL RIGHTS RESERVED 40
41. おわりに 生成AIと境界の課題 • • • • ここまで話したような境界の課題は、生成AIで開発コストが下がる世界 では課題とならないのでは？ 初期的にはYes。ただし、構造が誤っていれば結局コストは増え続け る。 コストは無くなったわけではない。トークンという形で支払うことにな る。 ある意味、初期にサインが見えづらくなるので、より注意深くなる必要 があるのではないか。 10X, Inc. ALL RIGHTS RESERVED 41
42. おわりに まとめ • • • 負債が増えづらい構造を作らないと、局所的に技術的負債を解決したと しても、負債は増え続ける。 開発チームがオーナーシップを持ち、運用のツケを引き受けつつ業務の 理解を深める構造であることが重要。 その上で、顧客との責務の境界を正しく切るモデリングをすることが運 用のコストを低く保つことにつながる。 10X, Inc. ALL RIGHTS RESERVED 42