モバイルアプリの技術的負債に 全社を挙げて取り組む考え⽅ 2024-05-23 @ TechBrew in 東京 ~モバイルアプリの技術的負債に向き合う~ mkitahara ( @mikity01985 )

名前 ● mkitahara ( @mikity01985 ) / 北原 幹也 職能 ● エンジニアリングマネージャー / Androidアプリ開発 / プロダクトマネージャー 出⾝ ● 静岡県 - 埼⽟県 - 千葉県 職歴 ● SES会社 (2011/04〜 2014/12) ○ 新卒未経験でIT業界へ：研修で Androidアプリ開発に出会う ● 開発受託会社 2社 (2015/01 〜 2017/09) ○ PHPを中⼼にいろいろ ● EdTech会社 (2016/02〜 2023/06) ○ 業務委託時代を含めて7年所属：Androidエンジニアを中⼼にいろいろ ○ 出向‧業務委託のみ 30名程度の会社から 社員200⼈超えの組織の成⻑を経験 ● FinTech会社 (2023/07〜 ) ○ モバイルアプリチームのエンジニアリングマネージャーを中⼼にいろいろ ⾃⼰紹介

アジェンダ ■ 技術的負債とは？ ■ モバイルアプリ開発で発⽣する技術的負債の問題 ■ 負債にどう⽴ち向かう？

技術的負債とは

技術的負債とは？ ウォード‧カニンガムさんの⽂脈 Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise. ※1 ※1 Ward Cunningham, The WyCash Portfolio Management System (March 26, 1992) 初めてコードを出荷するということは、借⾦をするようなものだ。少しの借⾦は、書き 直しで速やかに返済される限り、開発を加速させる。オブジェクトはこの取引にかかる コストを許容範囲にしてくれる。危険なのは、借⾦が返済されない場合だ。適切でない コードに費やされた時間はすべて、借⾦の利息としてカウントされる。オブジェクト指 向であろうとなかろうと、統合されていない実装の負債によって、エンジニアリング組 織全体が⽴ち⾏かなくなる可能性がある。

ビジネスを進める上でのリスクとなり得るもの 技術的負債 (私なり)の定義

リスクとは リスク (Risk) - ⽬的に対する不確かさの影響※１ ※ 影響 - 期待することからの乖離 - 現状(AsIs)とあるべき姿(ToBe)からの乖離 - 好ましいもの、好ましくないもの、もしくは両⽅の場合がありうる ※1 ⽥邉 ⼀盛, エンジニアのためのリスクマネジメント⼊⾨ (2 27, 2030) 技術的負債を保持していること = ビジネスを進める⽬的において不確実な影響要因 を保持していること

未認知の技術的負債 技術的負債 リリース時に認知していた負債 リリース時に認知していない負債 そもそも負債 だと思っていなかった 環境変化により 技術的負債になった 感度を⾼めてなければそもそも負債だと気付くことができないが、 環境変化によって(今までベターな選択だったものが)技術的負債に変化するものもある リスクをとってリターン を得るために受け⼊れた

技術的負債の発⽣ リリース前は技術的負債なく、リリース後に認知済みの技術的負債が顕在化する 運⽤中の認知した時点で、技術的負債が浮き上がる リリース前 リリース後 認知済みの負債 運⽤中 認知済みの負債 未認知の負債 (負債として把握していない) 未認知の負債 新たに認知した負債 リリースすると 何かしらのリスクがあるもの

技術的負債による影響 - 許容量を超えると 許容度内 (影響を計画できる) 許容量オーバー (影響を受け⼊れきれない) リスクがない (影響なし) 許容量を超えると影響が発⽣する ‧⾒積もりがさらに不確実なものとなる ‧潜在的不具合の量が増える 開発が遅延する リリース後の不具合が増える

モバイルアプリに対する信頼度が激減する...... 組織がモバイルアプリに投資しなくなる...... 技術的負債による影響 - 遅延や不具合が多発すると

モバイルアプリ開発で発⽣する 技術的負債の問題

モバイルアプリで発⽣する技術的負債の例 ■ 環境の変化 ● 利⽤者1万⼈を想定して作ったのにいつのまにか100万⼈を⽬指している。 ● 数年後に法改正することが決まった...... ■ 開発プロセスの課題 ● 動作を保証するテストがない？ ● 過去の意思決定判断基準がわかるドキュメントがない？ ■ 開発技術の変化 ● MVC→MVP→MVVM？VIPER？TCA？というモダンなアーキテクチャの変化 ● Swift Concurrencyやkotlin coroutineによりRxが古くなった？ ■ プラットフォームの変化 ● SDKがバージョンアップしたから動かなくなった？ ● OSがアップデートしてバックグラウンド処理が変わった？ ● OSSライブラリのメンテナがいなくなった。

モバイルアプリで発⽣する技術的負債の例 ■ 環境の変化 ● 利⽤者1万⼈を想定してたら100万⼈を⽬指している。 ● 数年後に法改正することが決まった...... ■ 開発プロセスの課題 ● 動作を保証するテストがない？ ● 過去の意思決定判断基準がわかるドキュメントがない？ ■ 開発技術の変化 ● MVC→MVP→MVVM？VIPER？TCA？というモダンなアーキテクチャの変化 ● Swift Concurrencyやkotlin coroutineによりRxが古くなった？ ■ プラットフォームの変化 ● SDKがバージョンアップしたから動かなくなった？ ● OSがアップデートしてバックグラウンド処理が変わった？ ● OSSライブラリのメンテナがいなくなった。 ビジネス状況の変化や開発プロセスが関係し 組織課題にしやすい 既存タスクと並べて対応可能！

モバイルアプリで発⽣する技術的負債の例 ■ 環境の変化 ● 利⽤者1万⼈を想定してたら100万⼈を⽬指している。 ● 数年後に法改正することが決まった...... ■ 開発プロセスの課題 ● 動作を保証するテストがない？ ● 過去の意思決定判断基準がわかるドキュメントがない？ ■ 開発技術の変化 ● MVC→MVP→MVVM？VIPER？TCA？というモダンなアーキテクチャの変化 ● Swift Concurrencyやkotlin coroutineによりRxが古くなった？ ■ プラットフォームの変化 ● SDKがバージョンアップしたから動かなくなった？ ● OSがアップデートしてバックグラウンド処理が変わった？ ● OSSライブラリのメンテナがいなくなった。 モバイルアプリチームで判断しやすいが 課題がモバイルアプリチームに閉じてしまう

チームに閉じた技術的負債の何が問題か？ 技術的負債の対応は ■ 「状態を維持する対応」によりふるまいの変化がないことが多い ● 変化がないため、状態を想定しにくい ● 運⽤にもコストが掛かることはなんとなくわかるがイメージしにくい ■ 「判断含めてモバイルアプリチームに閉じてしまう」ことが多い ● ビジネスグロースのタスクに埋め込まれてしまうことが多く、 周りから⾒るとなにをしているかわからなくなる

チームに閉じた技術的負債の何が問題か？ 技術的負債の対応は ■ 「状態を維持する対応」によりふるまいの変化がないことが多い ● 変化がないため、状態を想定しにくい ● 運⽤にもコストが掛かることはなんとなくわかるがイメージしにくい ■ 「判断含めてモバイルアプリチームに閉じてしまう」ことが多い ● ビジネスグロースのタスクに埋め込まれてしまうことが多く、 周りから⾒るとなにをしているかわからなくなる 既存のタスクに詰め込むと⾒積もりがズレて開発が遅延する 想定外のタスクによりテストケースが不⼗分で品質の保証ができない

(チームに閉じた) 技術的負債にどう⽴ち向かう？

チームに閉じた技術的負債にどう⽴ち向かうか？ 技術的負債の解消を安全‧安⼼して進めるためには ■ 既存のタスクと優先順位を⽐較して技術的負債解消タスクの優先度を上げる ● 既存タスクと優先順位を⽐較できるだけの情報が必要 ■ ⼀定の期間だけビジネスタスクを⽌めて開発側にくださいという交渉を⾏う ● ビジネスタスクをどれくらい⽌めるか期間を判断するための情報が必要

チームに閉じた技術的負債にどう⽴ち向かうか？ 技術的負債の解消を安全‧安⼼して進めるためには ■ 既存のタスクと優先順位を⽐較して技術的負債解消タスクの優先度を上げる ● 既存タスクと優先順位を⽐較できるだけの情報が必要 ■ ⼀定の期間だけビジネスタスクを⽌めて開発側にくださいという交渉を⾏う ● ビジネスタスクをどれくらい⽌めるか期間を判断するための情報が必要 モバイルアプリ開発チームが適切な情報を提供し ステークホルダーと優先度判断のための認識を揃えて みんなの問題として対応していく

技術的負債(リスク)の情報共有 ■ 結果とインパクトで対話する ● リスクを放置して対応しなかった場合、 ○ いつ‧誰が‧どうなる？ ■ コストとリスクを⾒積もる ● 理想の状態 もしくは 許容内に収まる状態になるまでに、 どれくらいの期間とコストをかければよい？ ● ビジネスグロースのタスクを並⾏で実施できる？ ○ できない場合はどれくらいの期間？ ○ そのリスクは？ ■ テストケースについて認識を揃える ● 技術的負債の対応はリファクタリング等、ふるまいを変えずに整理していく。 ● 現在のテストケースが正しく不具合を検出できるか認識を合わせていく

チームの状況‧状態を⾒える化 ■ 何をやっているのか、余⼒がわかるようにする ● チームのバックログを全社共有 ● バックログアイテムのフォーマットを共有する ○ ドキュメントの書き⽅、読み⽅を連携 (認知負荷を軽減する) ○ モバイルアプリチームではなくてもリスクがわかるように ■ チームの開発能⼒を定点観測する ● 仮説の検証回数 ○ 意図通りのリリースができたのか？量が少なければどうすれば多くできるか？ ● ベロシティ ○ 相対⾒積もりを⾏うための指標、タスクの切り⽅が適切か？ ○ 過去のチームの数値と⽐較 ● Four Key Metrics ○ デプロイ頻度、変更のリードタイム、サービス復元時間、変更障害率

モバイルアプリ開発ってFour Key Metrics をとるの難しい？ ■ なぜ？ ● 本番環境へのリリース速度を早めすぎてもユーザーに負担が掛かる ● Apple、Google への審査など、アンコントローラブルな要素がある

Four Key Metrics をシフトレフト(前倒し)してみよう ■ 検証環境へのリリースでFour Key Metricsを取得する ● デプロイ頻度 ○ 検証アプリ配信環境への配信頻度 ● 変更のリードタイム ○ 着⼿開始から検証環境配信までの所要時間 ● サービス復元時間 ○ 指摘された不具合チケットを解消するまでに掛かる時間 ● 変更障害率 ○ 検証環境に配信されたアプリで障害が発⽣した割合

※ただし数値を⽬標にしすぎない ■ グッドハートの法則 ● 測定が⽬標になると、それは適切な測定ではなくなる ■ キャンベルの法則 ● 社会的な意思決定において重要な指標ほど操作されやすい 重要なのは ● あくまで過去の⾃分たちと⽐較すること。 ● 要因を正しく分析‧判断すること。 ○ 数値が下がった → 技術的負債がある ではない。 ● 技術的負債を殲滅しようとは考えない ○ 負債の受⼊許容量を設定し、計画的に技術的負債と付き合いましょう。

まとめ

まとめ ■ 技術的負債とは？ ● ビジネスを進める上でのリスクである ● 未認知の技術的負債は問題が発⽣して初めて認知される ● スケジュールの遅延、不具合増加により、組織からの信頼関係崩壊につながる ■ モバイルアプリ開発で発⽣する技術的負債とは？ ● ビジネス環境に影響がある技術的負債は みんなで判断可能 ● モバイルアプリチームに閉じた技術的負債を組織課題としてみんなの課題に昇華させる ■ (チームに閉じた)技術的負債にどう⽴ち向かう？ ● 情報を共有し透明性を⾼めましょう ○ モバイルアプリチーム以外のメンバーでも結果やリスクの判断ができるようになる ○ モバイルアプリチームの開発能⼒‧状態を⾒える化する

まとめ モバイルアプリ開発チームに閉じた技術的負債も 技術的負債 vs わたしたち の構図を作り、 組織単位で協⼒して対処していきましょう！

ご静聴ありがとうございました！