和田さん自身が精神科医さんということで心理学に立脚した方法論を展開されていたと思います。
わかりやすい文章を書く。勉強をする心構え。それぞれ対象が自己か他者かで異なるものの、人間に情報をインプット（働きかけ）するときの方法論を心理学の体系にそって整理して教えてくれた２冊だったと思います。
両書に共通しているキーワードは「メタ認知」。自分の考えや行動が正しいかチェックする。いわゆるフィードバック制御の仕組みのようです。
自分の勉強の仕方が正しいか、身についているか、役に立つか。この説明や文章で相手に伝わっているか、といったことを高い視点から監視する。
ビジネスのあらゆる局面に共通した方法論などないと思います。そのため、色々な方法を試してみるということを日常的に行っています。そのとき、この「メタ認知」ができるかどうかで勝敗が決すると思います。
自分の意見が通じているか、相手の意思を理解できているか、などなど。
今までこのページで言い続けていますが、ソフトウェア開発やプロジェクト管理が失敗する原因の多くは「人」です。お客様とのコミニュケーション、開発チームや上層部とのコミニュケーションがうまく伝わらなかったこと・意思疎通できなかったことから、ミスコミニュケーションとなり開発は失敗します。
オブジェクト指向や分散開発などソフトウェアを取り巻く環境はまさに日進月歩で、仕様が確定していてもそれを開発する道は幾通りもあり、難しいという現状があると思います。技術的な難しさです。
また、他者（他社）が関わる場合、仕様の認識違いなど、時間をとり戻すことができず、カットオーバーに間に合わない、所謂、失敗プロジェクトになります。
ソリューション系の雑誌をみていると、プロジェクトが失敗した理由として「技術が難しい」ということが挙げられるように思いますが、私が見てきた中では、断然、後者の要因の方が強いと感じます。（自分が技術リスクの高いプロジェクトを経験していない、ということもあると思いますが）
営業、プレゼン、運用方法打合せ、機能仕様打合せ、開発指針の提示や進捗のフォロー、課題解決・・・。
いずれも人と人とのコミニュケーションなくして物事が進むことはありません。自動プログラミングができたとしても、人が会社を動かしている以上、コミニュケーションは必要となります。いきつくところは、やっぱり人なんだと思います。
今日の結論は、「ソフトウェアを開発する技術（ソフトウェア工学）を学ぶことも必要ですが、人とのコミニュケーション能力を高める技術（心理学）を学ぶべし」です。
もちろん、自分に言い聞かせています。
