• 技術が本来それであるところのもの＜すなわち技術の本質＞
• 大事なのは、メンバーが腹落ちするような方法で対話することです。 それぞれのチームでそれぞれのやり方を考えればいいし、何も会社全体が一つのスタイルでコミュニケーションする必要はありません。
• 常に進化する目的
• むしろ、「わがままを引き出すから、競争力がつく」のです。 そのことがつかめると、会社の見え方だけでなく、社会の見え方も変わってきます。
• 部下が、放っておいても組織の目標を受け入れると思うのは、未熟な楽観主義の表れである。個人が組織の目標を引き受ける仕組みは、はるかに複雑である。
• 生きて知る以外に知ることができない
• 学問は、本来、勉強なんかじゃないさ。この世でいちばん楽しい遊びなんだよ。
• なぜなら、概ね言葉の意味を否定しっ放しのポストモダニズムとは異なり、暗黙知は絶えず「言葉の意味」を志向し、それを形成しようとするものだからだ。暗黙知が目の前の言葉の意味をいったん否定するかに見えるのは、意味の更新を志向するからなのに他ならない。言葉と意味の関係は静的なものではない。生きることが常に新しい可能性に満ちているように、言葉はつねに新しい意味のポテンシャルに満ちているのだ。
• 本当に良いチームというのは、選手ミーティングをやらない。たとえ問題が起きても、普段から選手同士が話せる環境にあるのだから、ピッチでも部屋でもどこでもいいから話し合って、解決してしまうと思う。
• もっと大事なことは、選手がどれだけそのシステムを理解して、動けているかということ。監督がどんなに素晴らしいシステム、戦術を持っていたとしても、それをチームとして遂行できなければ、意味がなくなってしまう。
• ソフトウェアの名著や、達人たちの語る言葉には、このような気付きポイントが一字一句に潜んでいるものです。そのような言葉の背後にある意図、概念や哲学が見えた時、ソフトウェアエンジニアとして生きていく長い道のりを一歩進んだ喜び、達人たちがいる遥か高みの世界のすごさを実感した感動が押し寄せます。
• 一般化すれば、「ある環境下で、取り扱いやすいデータ構造」というのが、その環境が持つインピーダンスだ。確かにデータ構造が違っている（ミスマッチング）から、ERモデルからオブジェクトモデルに情報を伝達しづらい。ここを上手くやってくれるのが O/Rマッパー ＝ データ構造変換器 ＝ インピーダンス変換器 である。
• インピーダンスの差が小さければ、その場その場でのコーディングをわずかに頑張れば、わざわざ変換器を通してやらなくても良いだろう。変換器を作るコストの方が高い。ただ、ある程度大きなインピーダンスミスマッチがあると、モデルクラスのSRP（単一責任原則）が崩壊してくる。様々な業務に対応すべく、モデルがスマート（多才）になっていき、カオス化する。
• 重要な関心事は変更頻度が高いことが多いので、保守性の低下は禍根を残します。なので、重要な関心事はきっちりとオブジェクト化することが大事です。しかし、過度なオブジェクト化は逆に可読性を下げます。
• つまり、関心は別なんだけど実装が同じなんだよ！それはどうするの！という話です。そういうときには、伝統的なオブジェクト指向ならば「手続きだけに関心を持ち、データには関心を持たないクラス」ってのを作って、そのクラス（やインスタンス）をデータに責任を持つクラスが保持し、実際の処理は「手続きだけに関心を持つクラスのメソッドを呼ぶ」というやりかたをすると良いでしょう。この「手続きだけに関心を持つ」ってのが最初は理解しづらいのだけれど、そのあたりはストラテジーパターンとかブリッジパターン
• そんな中、C++の作者であるストロヴストルップは1987年の“What is "Object-Oriented Programming?"”という論文でオブジェクト指向プログラミングを次のように「データ隠蔽」および「データ抽象」の延長上に位置付けています。
• 本書の要点は、実装、設計、そしてチーム内のコミュニケーションの根底にあるモデルは１つだけであるべきだ、ということである。こうした別々の目的のために別々のモデルを持つのは危険である。
• すなわち、ソフトウェア開発は、すべてが設計なのだ。
• モデル駆動設計は、モデルと実装を密接に結びつける。ユビキタス言語はそれらすべての情報のための水路であり、開発者、ドメインエキスパート、ソフトウェアの間で情報がよどみなく流れるようにしてくれる。その結果できるのは、コアドメインに対する基本的な理解に基づいた、豊富な機能を提供するソフトウェアである。
• 複雑なプログラムはレイヤに分割すること。各レイヤで設計を進め、凝集度を高めて下位層だけに依存するようにすること。標準的なアーキテクチャパターンに従って、上位レイヤに対しては疎結合にすること。ドメインモデルに関するコード全部を１つの層に集中させ、ユーザインタフェース、アプリケーション、インフラストラクチャのコードから分離すること。