ソニー生命保険で，あるとき次のようなことがあった。
「大規模開発があるので，運用担当者に対して大量の依頼書を出す必要がある。準備しておいてほしい」。同社では，開発担当者は稼働環境に触れないルールになっているため，稼働環境を変更するためには依頼書を起票する。大規模なため，必要な枚数は膨大だ。
しかしよく調べると，このときは開発環境を構築するために，資源定義依頼書を個別に数百枚起票しようとしていたと分かった。そこで，開発環境の構築は開発側に権限を移し，依頼承認プロセスを簡素化した。さらに環境一括作成ツールを作り効率化したら，1人月以上を要していた依頼書起票作業が2人日で済んだ。表面的には作業の繁雑さという問題に見えたが，問題の本質は権限の持ち方にあったわけだ。
問題を発掘したらつぶす。しかも対処療法的につぶすのではなく，根治療法を目指す。これが第2の力，「探る力」である。問題の本質が究明できれば，目指すべきゴールが明らかになる。解決の道筋にブレが無くなる。
シンプルに整理する
東京カンテイの瀧内誠氏は数年をかけて，アプリケーション保守の問題を根本的に解決した。
瀧内氏が東京カンテイのシステムを引き継いで1年後，基幹システムをリプレースする話が持ち上がった。ところが当時，プログラムの構造が不明だった。さらに，OSの非互換性にも悩まされた。旧システムは「HP-UX 9」。これを「HP-UX 10.10」に移行する。「9」と「10.10」とでは，プログラムのバイナリ互換はあるが，ソース互換がない。C言語で書かれている稼働中のプログラムをそのまま移行できるが，移行後，プログラムに修正を加えた場合に「9」上でコンパイルしてから「10」上に移す作業が必要になる。
瀧内氏は，問題の本質が「作業や構造が複雑であること」にあると考えた。構造が明解で，作業がシンプルであれば移行に苦労することはない。そこで「アプリケーション構造の把握」と「OSの非互換性問題からの脱却」という二つのゴールを設定した。
前者については，既存アプリケーションのプログラム間の関係を関連図に整理した。ドキュメントを見て分からないものは推測し，エンドユーザーからフィードバックを得ながら精度を高めていった。最終的には，基本設計書レベルのドキュメントまでリバース・エンジニアリングを行った。
後者のOSの非互換性問題については，ミドルウエアの採用で回避する方針を立てた。C言語で開発したプログラムを捨て，Perlで作り直した。実行環境がその下のレイヤーの違いを吸収できるからだ。移行しやすいシステムの構築はこれで完了した（図4）。
 |
| 図4●東京カンテイが実施したシステム移行を楽にするアーキテクチャの変遷 基幹システムのサーバー機をリプレースするたび，アプリケーションの保守性の悪化に苦労していた。OSの非互換性に問題の本質があると考え，ミドルウエアにその差を吸収させるアーキテクチャに移行。アプリケーションの保守性を高めることに成功した [画像のクリックで拡大表示] |
その後，性能向上を目的とした移行を2回実施。いずれも，大きな問題は発生せず，アプリケーションの保守性を損なうことなく移行できた。
