技術的負債は開発者体験を悪化させる - mtx2s's blog
ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官として参加し、これまで数多くの退職理由を見聞きしてきた。その中で、 レガシーシステムを リファクタリング ・リアーキテクティング・リライトできないことへの不満を理由として挙げるエンジニアは多かったように思う。裏を返せば、自社のソフトウェアプロダクトが技術的負債にまみれたまま放置されているなら、優秀な人材が他社に流出するリスクがあると認識すべきだ。 本稿では、技術的負債と開発者体験の関係について紐解くとともに、それに対してソフトウェアエンジニアリング組織を預かるマネージャーが取るべき行動について考えてみたい。 ※これは、 Engineering Manager Advent Calendar 2021 の21日目の記事です。 下の図は、 バックログに含まれるアイテムをカテゴライズし、4色に色分けしたものだ。 フィリップ・クルーシュテン（Philippe Kruchten）によって2009年頃に考案され、" What Colo(u)r is Your Backlog?" というタイトルで発表された。ここでは2013年に彼の ブログ記事で紹介されたバージョンに基づいている。 技術的負債（technical debt） を返済するためのアイテムは、右下の黒いエリアにカテゴライズされている。 四象限の左側にカテゴライズされた バックログアイテムは、ソフトウェアプロダクトの「 振る舞い（behavior）」を変える・正すものだ。振る舞いは目に見える（visible）。「振る舞いを変える/正す」目的は、「 ユーザー体験（UX, User eXperience） 」を向上・改善することだろう。 対となる右側にカテゴライズされた バックログアイテムは、ソフトウェアプロダクトの「 構造（structure）」を変える・正すものだ。構造は目に見えない（invisible）。「構造を変える/正す」目的は、振る舞いの「 変更容易性（modifiability） 」を向上・改善することだろう。 「振る舞いを変える/正す」のはエンジニアの役割なのだから、ソフトウェアプロダクトの変更容易性の良し悪しは、エンジニアの体験に影響を与える。「構造を変える/正す」意思決定が適切になされないと、「 開発者体験（DX, Developer eXperience） 」が悪化することが想像できる。 フィリップ・クルーシュテンの 同ブログ記事にも書かれているように、右上の黄色いエリアである「アーキテクチャ（architectural, structural features）」にカテゴライズされるアイテムに手を付けない選択は、右下の黒いエリアである「技術的負債」にカテゴライズされるアイテムの増加につながってしまう点も留意すべきだろう。 変更容易性の悪化が、ソフトウェアデリバリのリードタイム（lead time for changes） を悪化させることは言うまでもない。 マーティン・ファウラー（Martin Fowler）によれば、コード品質を高く保つコストを削ることで生産性を上げる試みが通用する期間、いわゆる "design payoff line " に到達するまでの時間は、せいぜい 数週間以内だと言う 。 それに加え、複雑化しすぎたコードを変更することは、多くのバグを生み出しやすい。それがリリース後の障害となり、変更失敗率（change failure rate） を押し上げる。こうしてエンジニアは度重なる障害対応に追われ、精神をすり減らし、疲弊していく。 このような、本来やるべきことをやらなかったために後から強いられる労力のことを "failure demand " と言う。技術的負債のメタファーで言えば、「利子を支払う」といったところだろう。この利子の支払いは、エンジニアが新たな価値を生み出す "value demand" のための時間を奪い、開発現場は益々混乱していく。書籍『 LeanとDevOpsの科学』によれば、ロー パフォーマーに分類される組織は、ハイ パフォーマー ...
