コード品質向上タスクの優先順位を判断するために 必要な観点を探究する 2024-03-21 @ TechBrew in 東京 〜mtx2sさんと考えるコード品質とビジネスインパクト〜 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〜 ) ○ モバイルアプリチームのエンジニアリングマネージャーを中⼼にいろいろ ⾃⼰紹介

本資料のアジェンダ 背景 ■ ビジネスインパクトとコード品質の関係性 ■ コード品質を構成する要素 エンジニア視点での対処⽅法 ■ コード品質を向上させる⽅法 ■ なぜコード品質改善タスクが進まない？ ビジネスメンバーへの共有⽅法 ■ そもそもなぜ、コード品質劣化が起こるのか？ ■ コード品質改善タスクを説明しよう ■ 品質指標の基準は？ ■ コード品質向上タスクをビジネスメンバーに共有する⼿法 まとめ ■ まとめ

背景

ビジネスインパクトとコード品質の関係性

ビジネスインパクトを生み出す ※2 マーク‧J‧エプスタイン (著), クリスティ‧ユーザス (著), 鵜尾雅隆 (監修), 鴨崎貴泰 (監修), 松本裕 (翻訳), 社会的インパクトとは何か ― 社会変⾰のための投資‧評価‧事業戦略ガイド (10 14, 2015) ※1 W.K.Kellogg Foundation, Logic Model Development Guide (2004) ロジックモデル※1：インパクトに⾄るまでの⼀連の⾏動や事象のつながりを⽰す※2 ● インプットとアクティビティがアウトプットを⽣み出し、アウトプットがターゲットに影響を与える(アウトカム) ● アウトカムから得られたものがインプットとなり、さらなるアウトカムを⽣み出す ● いくつかのアウトカムがインパクトとなって社会に変化をもたらす アウトカム (成果) Outcome (結果) Input (投⼊資材) Impact (社会経済的変化) (波及効果) Activity (活動) Target (⼈‧周囲) Input (投⼊資材) Input (投⼊資材) Outcome (結果) Output (結果) アウトカム (成果) Outcome (成果)

アウトカム (成果) Outcome (結果) ビジネスインパクトを生み出す Input (投⼊資材) Impact (社会経済的変化) (波及効果) Activity (活動) Target (⼈‧周囲) Input (投⼊資材) Input (投⼊資材) Outcome (結果) Output (結果) アウトカム (成果) Outcome (成果) ビジネスインパクト：アウトプットによって⽣み出されたビジネスにおける変化 (アウトカム / インパクト) プロダクト：インプットとアクティビティによって⽣み出されたモノ (アウトプット) プロダクト ビジネスインパクト ビジネスインパクト = プロダクトによってターゲットにもたらされた変化

アウトカム (成果) Outcome (結果) ビジネスインパクトを生み出す Input (投⼊資材) Impact (社会経済的変化) (波及効果) Activity (活動) Target (⼈‧周囲) Input (投⼊資材) Input (投⼊資材) Outcome (結果) Output (結果) アウトカム (成果) Outcome (成果) プロダクト ビジネスインパクト プロダクトにもたらされた変化 (ビジネスインパクト) によって利益を得られる 利益

アウトカム (成果) Outcome (結果) ビジネスインパクトと品質の関係 Input (投⼊資材) Impact (社会経済的変化) (波及効果) Activity (活動) Target (⼈‧周囲) Input (投⼊資材) Input (投⼊資材) Outcome (結果) Output (結果) アウトカム (成果) Outcome (成果) プロダクト ビジネスインパクト 利益 (損害) プロダクトの品質は ビジネスインパクトに影響を与える ● 品質が⾼いプロダクトは わたしたちが期待したプラスのビジネスインパクト を与え、期待した利益を得られる可能性が⾼くなる ● 品質が低いプロダクトは マイナスのビジネスインパクトを与え、損害を被る可能性が⾼くなる ● プロダクトの品質の⼀つにコード品質がある プロダクトの品質 コード品質

コード品質を構成する要素

品質ライフサイクル プロセス 品質 内部 品質 外部 品質 利⽤時の 品質 影響する 依存する SQuaRE (ISO/IEC 25000 / JIS X 25000 シリーズ) ISO 9126-1 / JIS X 0129-1 ※3 独⽴⾏政法⼈情報処理推進機構 つながる世界のソフトウェア品質ガイド あたらしい価値提供のための品質モデル活⽤のすすめ (5 29,2015) システム‧ソフトウェアの品質を作り込むときにどの段階で考えるべき/ 検証すべき を表したもの ● 内部品質 は 外部品質に影響 / 依存する (ひいては 利⽤時の品質にも影響 / 依存する) ● コード品質 は 内部品質 に含まれ、巡り巡ってビジネスインパクトに影響する 影響する 影響する 依存する 依存する

品質モデル ※3 独⽴⾏政法⼈情報処理推進機構 つながる世界のソフトウェア品質ガイド あたらしい価値提供のための品質モデル活⽤のすすめ (5 29,2015) システム‧ソフトウェア製品の品質モデル 利⽤時の品質モデル 品質要求を定義し評価するための枠組みであり、品質を分類‧整理する時の着眼点(観点)を与える さらに「製品品質モデル」と「利⽤時の品質モデル」がある → ⼀⾔で「品質を⾼めたい」と⾔っても品質特性のズレから⽬的がズレてしまうことがある......

コード品質：メンテナビリティ(保守性) に着目する ※4 Boehm, Brown, and Lipow's 23 Quality Characteristics (1976) なぜ？：プロダクト開発時に内部品質のなかでも犠牲されやすい ※5 Takuto Wada 質とスピード（2022春版、質疑応答⽤資料付き (5 9,2022)

コード品質：メンテナビリティ(保守性) に着目する 保守性 maintainability モジュール性 再利⽤性 解析性 修正性 試験性 ≒ 理解容易性 ≒ 変更容易性 ≒ テスト容易性 ※4 Boehm, Brown, and Lipow's 23 Quality Characteristics (1976) ※5 Takuto Wada 質とスピード（2022春版、質疑応答⽤資料付き (5 9,2022) コード品質に影響がある主要素

メンテナビリティ(保守性) が低くなると発⽣する問題 (⼀例) ■ 理解容易性 ● 問題が発⽣した場合に他メンバーがヘルプに⼊りにくい ● 対応コストの⾒積もりがしにくい ● 問題発⽣時に調査が難航する ■ 変更容易性 ● 施策対応後の影響範囲が読みにくい ● 施策対応後の完了条件が不透明 (対応のヌケモレが発⽣する) ● 既存機能との整合性が取れるのか判断しにくい ■ テスト容易性 ● テストができないメソッド、クラスが⽣まれる ● テストケースの品質が保証できない (偽陽性、偽陰性のテストが⽣まれる)

エンジニア視点での対処⽅法

コード品質を向上させる⽅法

コード品質を向上させる方法※7 ■ 古い機能の除去 ● メリット：開発が容易になる、性能が向上する ● リスク：その機能を使っているユーザーがいる？ ■ リファクタリング / リアーキテクト ● メリット：開発が容易になる ● リスク：過失によるリグレッション ■ リプレース ● メリット：開発が容易になる、性能が向上する ● リスク：開発⼯数の増加 ■ ライブラリのアップグレード ● メリット：バグフィックス、性能が向上する ● リスク：ライブラリの振る舞いが変化することによるリグレッション ※7 Chris Birchall (著), 吉川 邦夫 (翻訳), レガシーソフトウェア改善ガイド: 複合型アプリケーション時代に即した開発‧保守技法 (11 1, 2016)

やり⽅わかってるなら、すぐにやればいいのでは？

で、済む話ではないと思います 😅

なぜコード品質改善タスクが進まない？

コード品質改善タスクが進まない？ ■ 変化が怖い※7 ● 複雑でドキュメントが貧弱により、すべてを理解していない ● 内容が⾒えないのでリスクを過⼤評価してしまう ■ 知識の孤⽴※7 ● チームで知識の受け渡しがされておらず、情報をサイロのように貯蔵して孤⽴する ■ ビジネスが⽌まるのが怖い ● 狩野モデルでいう当たり前品質の向上 は マイナスをゼロにする業務 ● ビジネスが進んでいないように思えてしまう不安がある ■ 終わりがみえない ● どこまでもできてしまう ● どこまでやっていいのかがわからない ● ゴールがないのでビジネスメンバーに説明ができず、情報がないのでビジネスメンバーも判断できない ※7 Chris Birchall (著), 吉川 邦夫 (翻訳), レガシーソフトウェア改善ガイド: 複合型アプリケーション時代に即した開発‧保守技法 (11 1, 2016)

コード品質改善タスクが進まない？ ■ 変化が怖い※7 ● 複雑でドキュメントが貧弱により、すべてを理解していない ● 内容が⾒えないのでリスクを過⼤評価してしまう ■ 知識の孤⽴※7 ● チームで知識の受け渡しがされておらず、情報をサイロのように貯蔵して孤⽴する ■ ビジネスが⽌まるのが怖い ● 狩野モデルでいう当たり前品質の向上 は マイナスをゼロにする業務 ● ビジネスが進んでいないように思えてしまう不安がある ■ 終わりがみえない ● どこまでもできてしまう ● どこまでやっていいのかがわからない ● ゴールがないのでビジネスメンバーに説明ができず、情報がないのでビジネスメンバーも判断できない ※7 Chris Birchall (著), 吉川 邦夫 (翻訳), レガシーソフトウェア改善ガイド: 複合型アプリケーション時代に即した開発‧保守技法 (11 1, 2016) 運⽤する以上、終わることはない......しかし、ビジネスメンバーも判断できない......

ビジネスメンバーへの共有⽅法

そもそもなぜコード品質劣化が起こるのか？

コード品質は劣化する 技術的負債 リリース時に認知していた負債 リリース時に認知していない負債 そもそも負債 だと思っていなかった 環境変化により 技術的負債になった 技術的負債はプロダクトをリリースし、認知されたときに⽣まれる※6 → エンジニアも予測しにくい 🙇 ● 「技術的負債だとあとで認知した」「環境変化により技術的負債になった」が劣化の原因 ● リリース時に認知していた技術的負債は想定内のリスクである (直せるなら直したい) ※6 mkitahara 技術的負債の発⽣と返し⽅の判断基準 (25 1,2024)

環境変化による劣化の一例 ■ アーキテクチャやコードの流⾏り廃り ● Androidアプリアーキテクチャのカオス期 (2017〜2021頃) ● 新フレームワークや⾔語の誕⽣ ■ OSやSDK、フレームワークのバージョンアップ、OSSのサポート終了 ● バージョンアップによる破壊的変更 ● IDEの更新 ● OSSが残念ながら保守終了となってしまった ■ プラットフォームの仕様変更 ● Apple のレビュー規約の変更 etc. ■ ビジネス環境の変化 ● 法律の変更により仕様を変更せざるを得ないとき ● ユーザーの利⽤状況の変化による仕様変更 ● 開発者の退職 や 開発者と運⽤者の変更 (同じ⾔語 の開発者だからできる ではない)

コード品質改善タスクを説明しよう

終わらせることをはじめよう※8 ※8 Marcus Hammarberg (著), Joakim Sundén (著), 原⽥ 騎郎 (翻訳), 安井 ⼒ (翻訳), 吉⽻ ⿓太郎 (翻訳), ⾓ 征典 (翻訳), 髙⽊ 正弘 (翻訳), カンバン仕事術 (3 26, 2016) ■ ゴールを決める ● ⽬標となる指標の達成値を決めて実施する ■ タイムボックスを決める ● 期限を決めて期間内に確実にできるものを実施する ■ 定期的に実施する ● 先に品質向上のためのタスク実施時間を確保して実施する ■ 必要なところだけを実施する ● ビジネス進める際に障害になる部分を先に実施する ● 中途半端な対応は技術的負債になる (が、認知している負債なので粛々と対応する)

ゴールを決める：コード品質を測定する指標の⼀例 ※9 ■ ソースコードの⾏数 (LOC) ● ソフトウェアの規模 ■ バグ密度 ● ソースコードの⾏あたりのバグ数 (バグ総数/LOC) ■ カバレッジ ● コードがどれくらいテストされているか ■ 重複 ● 重複するコード数。修正時の影響範囲がわかる ■ 循環的複雑度 ● メソッド内の分岐の量を⽰す ■ 凝集度 ● あるコードがどれだけそのクラスの責任分担に集中しているかを⽰す ■ 結合度 ● あるモジュールがどれだけ他のモジュールと結びついているかを⽰す ※9 ⻑瀬 嘉秀 (著), 伊藤 ⿓司 (著), ⽊村 泰久 (著), 杉浦 由季 (著), ⻑岡 晶史 (著), 松本 哲也 (著), エンタープライズアジャイル開発実践ガイド (12 28, 2020)

Four Key Metrics デプロイ頻度 - 本番環境へのリリース頻度 変更のリードタイム - commitから本番環境稼働までの所要時間 サービス復元時間 - 本番環境での障害から回復するのにかかる時間 変更障害率 - デプロイ起因による本番で障害が発⽣した割合 ゴールを決める：普段から品質の低下を検知する指標の⼀例 SPACE Satisfaction and well being - 開発者が⾃分の仕事、チーム、ツール、⽂化にどれだけ満⾜してい るか Performance - 開発者が書いたコードは、想定されたことを確実に実⾏したか？ Activity - 業務を遂⾏する過程で完了した⾏動やアウトプットの数 Communication and collaboration - メンバーやチームがどのようにコミュニケーションをとり、協⼒し 合うか Efficiency and flow - 個⼈であれシステムであれ、中断や遅延を最⼩限に抑えて作業を進 める、完了する能⼒ コード品質の低下に気づくこと → 普段とは違う状態を検知すること

品質指標の基準は？

品質指標の基準は？ ビジネスドメインによる！ ⾼ければ⾼いほど良いと判断しがちですが、Too much (過剰な)対応になってしまうことがある。 費⽤対効果、運⽤可能なレベル、最低限守らないといけないレベルを認識して、 ビジネスドメインを判断軸にして、適切な数値を決めていく必要がある。

コード品質向上タスクビジネスメンバーに共有する⼿法

リファクタリングはHowである What Why(なぜやるのか？) ？ How(どうやってやるのか？) リファクタリング What (なにを達成するのか？) ？ エンジニア希望のHowのみを伝えてもビジネスメンバー、POは他のアイテムと⽐較して判断ができない

リファクタリングはHowである What Why(なぜやるのか？) 変更時のリスクを下げる How(どうやってやるのか？) リファクタリング What (なにを達成するのか？) 変更容易性を向上させる 影響想定箇所のカバレッジ：◯％ 以上 ゴールデンサークル + When + リスク を伝えて判断材料を提供することで、他の施策と優先順位を判断できるようになる When (いつまでに達成するのか？) ビジネスメンバーの希望と⽬標達成できる⽇時 risk (対応しないとどうなる？) 影響範囲が不透明になり、テスト⼯数が読めなくなる テスト項⽬の品質が保証できなくなる How以外の項⽬を明記して 施策アイテムと⽐較できるようにする

まとめ

まとめ 背景 ■ ビジネスインパクトとコード品質の関係性：ロジックモデルからビジネスインパクトとコード品質を紐づけました ■ コード品質を構成する要素：コード品質の中でも犠牲にされやすい保守性から発⽣する問題点を出しました エンジニア視点での対処⽅法 ■ コード品質を向上させる⽅法：レガシーソフトウェアを改善するいくつかの⽅法をご紹介しました ■ なぜコード品質改善タスクが進まない？：終わりが⾒えないタスクで情報がないのでビジネスメンバーも判断できないです ビジネスメンバーへの共有⽅法 ■ そもそもなぜコード品質劣化が起こるのか？：環境変化による劣化があるため、エンジニアも予測しにくいです ■ コード品質改善タスクを説明しよう：終わらせることをはじめましょう ■ 品質指標の基準は？：ビジネスドメインに寄り、この観点でもコード品質はビジネスインパクトに紐づくことが⾔えます ■ コード品質向上タスクをビジネスメンバーに共有する⼿法：なぜ、ゴール、期⽇、リスク を伝えることで判断しやすくなります 同じ会社のメンバーは⾒ている⽅向が同じ(はず)なので共働してビジネスをグロースさせましょう！

おまけ：コード品質に向き合う際の注意点 グッドハートの法則 ● 測定が⽬標になると、それは適切な測定ではなくなる キャンベルの法則 ● 社会的な意思決定において重要な指標ほど操作されやすい ■ 指標は、変化に気付くことくらいの気持ちで過度に⽬標値として設定しない ■ コード改善タスクとビジネスグロースタスクは分けて対応する リファクタリングを実施したときは、振る舞いを保証するために必ずテストを実施すること ● 振る舞いを変更したものと変更しないものを混ぜ込んでしまうと複雑度が増す ● グロースタスクのついでにリファクタリング......は事故のもと

ありがとうございました