コリー・マクニーリー氏はUHYコンサルティングのマネージングディレクターである。
あらゆる組織は、ある程度の技術的負債を抱えている。それは時限爆弾のように、長年にわたって静かに蓄積される。ここに時代遅れのシステム統合があり、あそこにカスタムフィールドがあり、誰かが何年も前に構築したワークフローで、誰もその理由を覚えていないが、誰もが重要だと考えているものがある。ある日目を覚ますと、かつては応急処置的な解決策だと感じていたものが、本格的な業務上の負債に変わっていることに気づく。技術的負債が自ら手を挙げて存在を知らせることはめったにない。組織内でゆっくりと蓄積され、小さな非効率、小さなダウンタイム、小さなフラストレーションとなり、やがてその小さな非効率がサポートに数百万ドルのコストをかけるようになる。
技術的負債は本質的に悪いものではない。実際、動きの速い組織では、避けられないことが多い。しかし、管理されていない技術的負債は危険になる可能性がある。アップグレードを遅らせ、拡張性を制限し、サポートコストを増加させ、最終的にはテクノロジー投資の収益を減少させ始める。私自身の経験からも、技術的負債がデータ品質、システムパフォーマンス、ビジネスワークフローに影響を及ぼし始めた瞬間、それは小さな厄介事ではなくなり、真の制約となる。
ヒューストン、問題が発生した。
通常、原因を理解する前に症状に気づく。私の場合、引き継いだ基幹業務システム（ERP）は、ほぼ10年間更新されていなかった。表面的には、適切な力技で機能していたが、亀裂はいたるところにあった。システムパフォーマンスの低下、どこにもつながらないワークフロー、データの不正確さ、手作業による回避策に費やされる時間。財務部門と製造部門は日々ボトルネックに直面し、出荷は継続的に遅れていた。毎晩、明確な説明なしにバッチ処理が失敗したという恐ろしいメールを待っていた。ログインのような単純なタスクでさえ、待っている間にコーヒーを飲めるほど時間がかかった。
状況をより深く掘り下げることにしたとき、私が予想していた通りのものを発見した。適切なガバナンス、管理、更新なしに放置されたシステムだった。上質なボルドーワインとは異なり、これは熟成せず、誰の口にも苦い味を残した。システムを深く調べれば調べるほど、システムが1つの大きな問題のために壊れたのではなく、何年にもわたる小さな決定が積み重なって、現在直面している故障システムになったことが明らかになった。
あなたも今日、同じ兆候を経験しているかもしれない。ページの読み込みが遅い、簡単なレポート作成にエクセルに依存している、手作業によるデータ入力、タスクを完了するためにチーム間でシステムを行き来する「回転椅子」プロセス、自動化の欠如に関する苦情、そして継続的な問題のトリアージ。これらは些細な問題ではなく、技術的負債が爆発しようとしている警告サインである。
これがあなたが思う以上に重要な理由
技術的負債は従業員をイライラさせるだけでなく、組織の拡張、実行、革新の能力を損ない、競争上の優位性を妨げる。システムが時代遅れで、過度にカスタマイズされているか、構造的に欠陥がある場合、より多くのサポートチケットが生成され、リソースの増加が必要となり、コストの増加につながる。また、データ品質の低下にもつながり、レポート作成と意思決定がより困難になる。
今日の相互接続されたデジタル世界では、リスクはさらに高い。時代遅れのシステムはセキュリティ上の問題を引き起こし、古いコードが悪用される可能性がある。サポートされていないコーディングは、データ侵害への扉を開く可能性がある。「後で修正する」はすぐに「なぜチャンスがあったときに修正しなかったのか」になる。技術的負債はもはや技術的な懸念だけではなく、サイバーセキュリティとコンプライアンスのリスクである。
技術的負債の原因を見つける
技術的負債を明らかにするには、システムをいじり回して偶然のひらめきの瞬間に出くわすことを期待する以上のことが必要である。ユーザーがシステムとどのように相互作用するかを理解する必要がある。私の最初のステップは、常にシステムのパワーユーザー、つまりツールに最も精通している人々と話すことである。多くの場合、彼らは技術的負債の苦痛に精通しており、現在の回避策、遅れているプロセス、非効率性、そして運が良ければ、それ以外の未知の問題を説明できる。
そこから、以下を調査する。
• 統合とサービスログ：どこで障害が発生しているか？障害の頻度は？パターンを持って発生しているか？
• カスタマイズ：システム内でもはや使用されていない、または理由を理解せずに使用されているシステム、フォーム、フィールド、ワークフローはどれか？
• システムコンポーネント：サポートされていない、またはアップグレードをブロックしているモジュールはどれか？
範囲を理解したら、戦略的な決定を下し始めることができる。
置き換えるか、廃止するか、維持するか？
技術的負債を評価する際、私は発見したものを3つのカテゴリに分類する。
1. 廃止：セキュリティリスクをもたらす、またはアップグレードをブロックするもの。
2. 置き換え：非効率なコード、時代遅れの統合、または最新化すべきプロセス。
3. 維持：明確なビジネス価値を提供し続け、長期的なアーキテクチャの一部として残ることができる項目。
優先順位をつけるために、私はシステムの安定性、拡張性、内部および外部の顧客体験、実装速度を考慮するスコアカードを使用する。アップグレードをブロックするものは、早期に対処するためにリストの最上位に移動する。
これには毎年予算が必要である。物理的資産を維持するのと同様に、デジタル環境を継続的に維持する必要がある。
事態を悪化させずに最新化する
組織が陥りやすい罠の1つは、カスタマイズがすべてのギャップに対する答えであると信じることである。しかし、目標を達成するには、単に設定を行うだけで済む場合もある。カスタムコードは、たとえ小さくても、長期的なコストを伴う。すべてのアップグレードサイクル中に、維持、テスト、更新、レビューが必要である。また、アップグレードを完全にブロックする可能性もある。ローコードプラットフォームとミドルウェアツールにより、これらの落とし穴を回避することが容易になった。可能な限り、明日の技術的負債となるカスタムコードをさらに構築する代わりに、これらを使用すること。
組織の将来性を確保する
AIアクセラレーターとクラウドベンダーがかつてないほど速く更新をリリースする中、効率的にアップグレードできない組織は遅れをとる。変化のスピードは増加する一方である。システムが追いつけなければ、それらのシステムの価値は低下する。
だからこそ、技術的負債は負債として扱われなければならない。監視し、計画し、積極的に管理するものである。ロードマップ、予算サイクル、パフォーマンス指標に組み込む必要がある。放置されたシステムは中立のままではない。障壁になる。
あなたの技術的負債が呼びかけている。あなたは応答するつもりか？
