社内では品質管理の名目で技術的負債の解消をミッションの1つとしているが、着手して一番最初に躓いたのは技術的負債とリファクタリングの認識が全く合わないことだった。
リファクタリングについては「リファクタリング」と「レガシーコード改善ガイド」にその定義が掲載されているのでソースをぶつけることで早々に解決した。
新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)
- 作者: Martin Fowler,児玉公信,友野晶夫,平澤章,梅澤真史
- 出版社/メーカー: オーム社
- 発売日: 2014/07/26
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (11件) を見る
- 作者: マイケル・C・フェザーズ
- 出版社/メーカー: 翔泳社
- 発売日: 2016/01/15
- メディア: Kindle版
- この商品を含むブログ (3件) を見る
しかし技術的負債のわかりやすい定義は検索しても意外と見当たらず、何が技術的負債か明確でないためにいろんなものが技術的負債としてバックログに積まれた状態でミッションはスタートすることに...
(技術的負債が何なのかわからない状態でそれの解消をミッションにしてしまった時点で何か大きな間違いを犯している気がするが、それについてはこの記事中では言及しない)
また、営業への説明も必要になりそうだったので、簡潔で非エンジニアでも分かるような定義を作ることにした。
それをすると決めてから一番最初に見たのは「エンジニアリング組織論への招待」で、こちらからカニンガムが提唱したのが原点だとわかった。
エンジニアリング組織論への招待 ?不確実性に向き合う思考と組織のリファクタリング
- 作者: 広木大地
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/22
- メディア: Kindle版
- この商品を含むブログを見る
曰く:
最初のコードを出荷することは、借金をしに行くのと同じである。小さな負債は代価を得て即座に書き直す機会を得るまでの開発を加速する。 危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは、借金の利息としてとらえることができる。 技術部門は、欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる。
(エンジニアリング組織論への招待 P249より)
この文章には、最初のコードは「品質が良くない」と前提があること、それを使い続けることの不利益について明言されていない、という問題を感じた。
同書では、「品質が良くない」前提については、新規追加しづらいコードを指しており、 使い続ける不利益については、「速度の低下」として表現されていた。
また、同書では技術的負債を「不可解な開発速度の低下」を説明しようとする言葉と記している。
まとめると、新規追加しづらいコードの蓄積=負債の蓄積で発生する借金の利息=開発速度の低下ということになる。
しかし、社内の開発を見渡すと、開発速度の低下の原因はコードだけに限らず、技術選定や運用プロセスもまたそれを低下させていると直感的に感じた(時間をかければ直感ではなくきちんと説明できると思う)。
そこで最終的にひねり出したのは、以下のような技術的負債の定義だ。
「ソフトウェア開発の加速を継続的に妨げる技術的な欠陥またはプロセスの不備」
「継続的に妨げる」は利息として払い続けることを指している。
「技術的な欠陥」は広範な意味を含んでいるが、理解しづらい・変更しづらいコード・アーキテクチャ、更新されていないライブラリ・フレームワーク、用途にマッチしないデータベースの選定、などが挙げられる(もっとあると思う)。 「プロセスの不備」も同様で、コードレビュー・リリースのフローが曖昧だったりとか、意思決定者が不明で誰に許可を取っていいかわからない、みたいな状況を指す。
非エンジニアには「欠陥を含まずに機能追加・変更を行うのは難しいため、それは負債のように蓄積され、利息として速度を奪っていく」という前提を添えて説明することにした。
この文章がカニンガムが提唱した概念から少し離れてしまっているというのはあるかもしれないが、言葉としては非常にわかりやすく、実用的だと思っている。
実際、この定義をごちゃごちゃしたバックログに溜まっている「技術的負債」に適用したところ、9割がたが「技術的負債」ではなく、ただのバグや小規模な改修要望であり開発速度の加速に関係ないものがほとんどで、 いかに定義なしでは技術的負債とそうでないものをごっちゃにしやすいかが身にしみてわかった。
まだ非エンジニアへの説明はしていないが、多分伝わるだろう。
もし社内の技術的負債が溜まっているようだったら、上記の定義をチーム内で共有してみてほしい。 また、非エンジニアに説明する機会があったら前提の一文を添えてうまく説明を試みてほしい。
うまく行けば幸い、だめでもこちらへの苦情は控えてほしい。
補: アジャイルサムライにも技術的負債について触れられていたが確認しそびれた。なんと書いてあったかちょっと気になる。
エンジニアリング組織論への招待 ?不確実性に向き合う思考と組織のリファクタリング
- 作者: 広木大地
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/22
- メディア: Kindle版
- この商品を含むブログを見る
新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)
- 作者: Martin Fowler,児玉公信,友野晶夫,平澤章,梅澤真史
- 出版社/メーカー: オーム社
- 発売日: 2014/07/26
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (11件) を見る
- 作者: マイケル・C・フェザーズ
- 出版社/メーカー: 翔泳社
- 発売日: 2016/01/15
- メディア: Kindle版
- この商品を含むブログ (3件) を見る