「技術的負債」とは何でしょうか？どうしましょうか？

【このテーマの目的・ねらい】
目的：
　「技術的負債」とは何か、

　　どうすべきかについてご研究いただきます。
ねらい：

　「技術的負債」対応をご検討ください。　

ーーーーーーーーーーーーーーーーーーーーーーーー
日経コンピュータ誌の５月１２日号に「技術的負債に向き合う」

という特集がありました。

「技術的負債」多くの人にとってはこの言葉は初耳なのですが、

1992年にウォード・カニンガム氏が使いだした言葉だということが

紹介されています。

「ソフトウェアの複雑さがだんだん増していって、
機能追加や適切な改修が難しくなっている現象」

なのだそうです。

当特集ではこういう解説がされています。

システムのブラックボックス化が引き起こす「技術的負債」の問題に、
日本企業が真剣に向き合い始めた。

システムの改修や新機能追加にかかるコストが膨れ上がり、

ＩＴによる事業強化や業務改革といったＤＸの足かせになる事態を防ぐためだ。
旧来のアーキテクチャの見直しからクラウドをはじめとした最新技術の取り込み、

生産性や保守性の見える化と継続的な改善、

経営陣と開発陣の密な連携まで課題は山積み。

 先進企業の取り組みを通して、長く険しい、

技術的負債に立ち向かう道のりを追った。

 ご承知のようにこのテーマは、

経済産業省が2018年の「ＤＸレポート」の中で「2025年の崖」として

問題提起したものです。

この問題提起にもかかわらず、その後、大半の企業においては、

「検討はしているが、何らの手も打っていない」という状況でした。

今回の特集は、「2025年の崖」対策に取り組みだした

先進企業があるぞ、という紹介記事なのです。

そこで、私はハタと思いついて、

技術的負債が発生しないようにするあるいは軽減できるような

ガイドを作成することにしました。

それが「技術的負債リスク　チェックリスト」です。

その「ソフトウェア保守業務編」「開発業務編」

「マイグレーション業務編」の３編を作成しました。

最も技術的負債に関係深いのは、ソフトウェア保守業務です。

ソフトウェア保守業務が難儀する元は開発業務にあります。

何とかしなくてはと思いながら作り直しを逡巡するマイグレーションも

技術的負債の継続に「貢献」しています。

以下に、開発業務編のチェックリストをご紹介します。

このチェックリストで、開発業務の場合は、

担当組織ごとにチェックをしてＮＧの比率を算定します。

上掲の例では、５５％です。

定期的にチェックをして改善または改悪状態を把握します。

このチェックリストには解説がついています。

解説欄をクリックすると以下のような解説が表示されます。

このチェックリストは、３業務込みで商品としてご提供しています。

そのご案内は以下をご参照ください。

gijututekifusai.pdf (newspt.co.jp)

これをご覧になってどう思われますか？

「有料のものなら自分たちで作ろう」そう思われますか？

できそうですが、いざとなると喧々諤々、議論百出でまとまりませんよ。

「ＭＡＫＥｏｒＢＵＹ」という言葉がはやったことがありました。

必要だと思われたら「ＢＵＹ」した方が早いのです。

ただし、どういう風に利用するかを検討されないと、

「宝の持ち腐れ」になりますから、

その点にも注意が必要ですね。