技術負債について考える

世の中のソフトウェアシステム開発において 「ドキュメントが満足に揃っていない」 「修正しても必ずバグが生まれるので手がつけにくい」 みたいなお悩みを持っているシステムを運営するエンジニアはたくさんいます。 よほど開発がしっかりと管理をして運用を行っている会社組織でない限り、 問題点は山積みて、それらに手をつけるどころか、新しい仕事はどんどん降って湧いてくるので、臭いものにフタをしている状態になっているケースが多いようです。 これらは、「技術負債」という風に呼ばれますが、技術負債が溜まっている組織ほど技術負債に目を向けていない傾向があるので、 ちゃんと理解して、どのように対応すれば良いのかを考えてみたいと思います。

技術負債が発生する理由

そもそも、「技術負債」というものが発生するメガニズムは次の様な事が考えられます。 耳の痛い組織も多いと思いますが、まずはしっかりとこうした事実を理解する事が重要です。

スピード優先の意思決定

・「とにかく早くリリースしたい」など、納期重視で短期的な開発判断が優先される。 ・設計やテストを後回しにして、実装を急ぐ場面でよく見られる。

不十分な設計や仕様の変更

・初期設計が甘い、または仕様変更に伴い、後から継ぎ足し的な修正が重なる。 ・結果として、全体の整合性が崩れる。

ドキュメント不足や知識の属人化

・設計意図や背景がドキュメント化されず、特定の人しか分からないコードになる。 ・組織やチームから人が離れるとブラックボックス化する。

経験不足や技術力の差

・技術的にベストな選択肢が分からず、暫定的な方法で乗り切ってしまう。 ・新人が急ぎで書いたコードが後に足かせになることも。 ・コーディングルールやチーム内教育などの不整備。

保守コストを意識しない設計

・再利用性や拡張性を考慮せず、目の前の要件にだけ対応。 ・結果として、修正や追加が難しくなる。 ・修正をするたびに新たな不具合が発生する。

チーム内コミュニケーションの不足

・コード方針やレビュー基準が曖昧で、ばらばらな実装が混在する。 ・結果的に統一性がないコードベースとなる。 ・仕事以外の雑談力が不足していると、目標思考がブレる事が多い。

技術やフレームワークの老朽化

・依存ライブラリの更新放置や、レガシー技術の使い続けで、モダン化が難しくなる。 ・エンジニアは、とにかく最新のフレームワークに飛びつきたがる傾向があるので、安定して長期間運用する事に目を向ける必要がある。

返済計画の立て方

技術負債を解消するには、住宅ローンと同じ様に「返済計画」を立てなければいけません。 アタフタして、しどろもどろしているだけでは、負債の解消はできません。 技術負債は、必ずしも「悪」ではなく、意図的に抱えることもあります。 返済計画（リファクタリングや改善のタイミング）を立てないままだと、開発速度が遅くなり、品質もどんどん悪化していきます。 定期的な見直しと、チーム内での共通理解、また経営層などの投資理解が大切です。 ということで返済計画の立て方は次のとおりです。

1. 技術負債の「可視化」

まずは、負債の種類を洗い出す事が重要です。 （例：スパゲッティコード、古い依存関係、テスト不足、命名不一致など） そして、影響度や緊急度を分類します。 たとえば「高影響・高緊急」など、できるだけドキュメントとして、誰が読んでもわかるモノを作る事を意識しましょう。 それらを、課題チケット化してバックログに入れることで、仕事としてのマイルストンとなり、返済計画が実施され始めます。 JiraやGitHub Issueなどのツールを使う事で、よりチーム認識がしやすくなります。

2. 優先度の決定と分類

ただ、リストをやみくもに作業していくというのは、効率があまりよくありません。 ビジネスへの影響も考えて、 障害リスク、保守コスト増大、などの様に、優先度をつけるようにしましょう。 「今すぐ対応」「次のスプリント」「将来的に検討」など、分かりやすくするとより効果的です。 開発効率を劇的に改善する負債は最優先にすると、改善していく事で、倍速的に効率化して行き、モチベーションもアップしやすいです。

3. 返済スケジュールの策定

組織での理解度を増すために、定期的な返済タイムを設けます。 また、やった作業を認識しやすくするための目標セットも重要です。 例えば、「毎スプリントに1つは負債を解消する」とか・・・ 開発と返済を並行する時間配分のルールを決めることも重要です。 80%機能開発、20%返済というようにすることで、通常業務との並行で行う作業として認識できて、 経営層などへのアプローチもしやすくなるはずです。 リファクタリング専用スプリントを年に数回設定するのも有効かもです。 スプリント運用ができていないチーム開発の場合は、まずはその下準備は必要になるかもですけどね。

4. 返済手段の選定と実行

実際の返済手段は、大きく分けて次の様な内容になります。

リファクタリング（構造改善）

ソースコードの修正はそもそものコーディングルール制定も含めて重要です。

テストの追加（ユニット・統合）

よくトラブルが起きる点や、修正が多い箇所などを重点的にテストを充実させると、開発者の心的負荷が軽減します。

ライブラリアップデート

ライブラリなどは、運用がしっかりとできるように整備しなおす必要もありますが、 バージョン管理などが行き届かないのであれば、安定的なレガシーシステムを検討することも必要な場合もあります。

ドキュメント整備

伝言ゲームになっているような場所は、必ずメモに残すか、ちゃんとしたドキュメントとして整備しておきましょう。 言った言わないは、開発には御法度です。

自動化導入

CICDを理解しているエンジニアは、必ず自動化運用を極限まで考えます。 これは自分の仕事効率をよくするだけでなく、背品の品質も担保できるため、検討ができていない組織のシステムは、品質が悪いというふうに考えられます。

5. フィードバックと継続運用

返済の効果を定期レビューすることで、経営者などへのアピールをする事ができます。 「バグ率が減った」「開発速度が上がった」などは、製品品質そのものですからね。 また、振り返りミーティングで負債発生の原因と対策を共有して、チーム内のコミュニケーションを活性化させましょう。 そして、新たな負債を増やさない仕組みを取り入れることで、開発員の意識向上を教育することにもつながります。 コードレビュー強化、Lint導入するなどの思考になると、システム改善する以上に得られるものが多いはずです。

あとがき

ITの中身はよくわからない経営者の人は、プログラミングを理解しなくてもいいので、 今回紹介した技術負債に対しての返済計画をするという事を意識して、開発部門に対して会話ができるだけで、 自社のシステム品質の格段の向上につながります。 逆にこういう理解がないと、開発員が居つかない会社組織になりがちなので、 エンジニアを理解する一つの大きな学習というふうに捉えてもらってもいいかもしれません。 さて、次はどんなシステム負債を解消しますか？