まとめると、IT負債とは、ITシステムの技術的な負債のこと。古い技術を使っていること、DB中心でシステムが密結合しているために、保守や改修にとても工数がかかる。これが日本ではITシステムのコストの8割、アメリカだと6割を占める。DXに対応していくために、密結合の巨大システムから、もっと小さい単位のマイクロサービス化して、１つの改修がシステム全体に影響を及ぼさないようにすることで、開発速度をあげていく。マイクロサービス化することで、システム間を疎結合にしていく。また、マイクロサービスの利用にあたり、API化していく。マイクロサービス化、API化は、アメリカでは潮流であり、不可逆な流れになっている。そのとき、クラウド化（シフト）するのではなく、クラウドに最適化（リフト）していくことが求められている。
マイクロサービス化は、わからなくもない。ただ、どこまでマイクロサービス化するのかは議論の余地がありそうだ。いまどきの技術者の場合のマイクロサービス化だと、本当に細かい単位で、かつサーバレスでの動作というイメージがある。でも、レガシーシステムを抱える企業の場合は、そこまで小さくしたいわけでなく、ある機能の単位でわけていくくらいがちょうどいいと思う（単機能のシステム）。そして、それを疎結合させるだけでも、足枷がゆるくなるはず。あと、マイクロサービス化するとき、開発をするときの言語選びやフレームワーク選びも重要。流行りに合わせていると、結局、保守しないといけない開発言語や環境の数がふえていく。だからといって、固定にしてしまい、選ぶものを間違えると、人は集まらない。どっちかっていうと、常に新しくしつづけていく必要があり、そこにコスト（人など）をかけるということが大事だと思う。それが一番重要。
以下は、気になったところを抜粋。
P.5 本書のタイトルである「IT負債」とは、「ITシステムの技術的負債」のことを指している
IT負債
P.5 技術的負債が重いほどIT費用は「ランザビジネス」（現在のシステムを維持していくため）に使われ、その割合は日本では8割、米国では6割という統計値がある。
IT負債
P.23 IT技術者の視点で見ると、DXの本質はデジタル化にある。デジタル化とはデータ化であり、データはソフトウェアで処理するため、「ソフトウェア化」と言うこともできる。
IT負債
P.44 従来のシステム設計の根本思想は、データベースを中心として、トランザクションを活用しながら他システムと連携するというものだ。これが密結合のシステムを生む根本原因である。そして、密結合であることが様々な問題を引き起こしている。
P.69 2019年にエストニアを訪問した際、彼らの国のシステムの中核にある「X-Road」について説明を受けた。X-Roadでは、個人の情報を分けてデータベース化し、分けたデータベース単位でサービス化していた。新たなサービスを立ち上げる場合は、そのサービスを提供する企業に対して厳しいセキュリティ要件を確認するとともに、必要なデータをすべて提供するのでは無く、最低限必要な情報に限定し、API接続にて提供している。
P.135 大きな問題として、DXレポートでも指摘されているが、アジャイル型開発の場合の契約形態がある。常駐型でユーザー企業を支援していく場合、ユーザー企業の社員とITベンダーの社員が、適切な指揮命令系統に従って活動しないと派遣法に抵触する恐れがあるからだ。通常、ITベンダーとユーザー企業は、準委任契約を締結して業務を行うので、法的には受託契約の形態をとっている。
P.186 特に2018年は「マイクロサービス」をキーワードに有識者へのヒアリングを行った。クラウドベンダーは「リフト」（クラウド移行）よりもコスト削減効果の著しい「シフト」（クラウドネイティブ化＝マイクロサービス化）に重点を置き始めている。この点は2017年に訪問したときと相当変わってきている。
P.193 米国では、モノリスシステムからマイクロサービスへの移行は、SoEやSoRに関係なく、ソフトウェア開発技術の基本技術の変化として捉え、急速な変革が進んでいる。また、新たな技術の適応に関して、不可逆な方向転換が起こっていると思う。
P.223 米国の企業にマイクロサービスの規模について尋ねると、異口同音に「テストケース数」という答えが返ってきた。確かに、新たなマイクロサービスを開発する場合、追加された論理パターンの数（テストケース）が実際に必要な開発量やテスト量と強い相関を持つことは想像に難くない。
