なぜ定義が重要なのか
何かを学ぶとき、最もよい方法の一つは、その最も基本的な定義に立ち返ることだ。
ある概念が常識のように見えても、そこで問いを止めてはいけない。それはいったい何なのか。一言で明確に説明できるだろうか。
この問いは簡単そうに見えて、実は難しい。私たちは、ある言葉を使えていても、本当に理解しているとは限らない。普段どのような場面で使われるかを知り、ほかの人の言い方を見て、それをまねることもできる。だが、いざ定義を求められると、理解の空白が露わになる。
たとえば、Gitの「コンフリクト」だ。
コンフリクトとは、mainが先へ進んだことそのものでも、双方が同じファイルを変更したことそのものでもない。より正確に言えば、次のようになる。
Gitが二つの開発履歴を統合しようとしたとき、一部の変更を自動ではマージできず、最終的な結果を人が決める必要がある状態。
古いバージョンをもとに、私があるコードを変更したとする。その間に、mainでも同じ箇所が変更された。Gitが両方の変更を一つにまとめようとすると、それぞれが何を変更したかは分かっても、最終的にどちらの結果を採用すべきかまでは判断できない。
Gitは私の代わりに選べない。
そこでGitは処理を止め、コンフリクトしている箇所を示し、判断を私に委ねる。mainのバージョンを残すのか、私のバージョンを残すのか、それとも両方を組み直して第三の結果にするのか。
この定義が明確になると、多くの疑問もそれに伴って解けていく。
mainに新しいcommitが増えても、必ずコンフリクトするわけではない。双方が同じファイルを変更しても、やはり必ずコンフリクトするわけではない。変更箇所が異なるか、変更をどう共存させるかをGitが判断できるなら、引き続き自動でマージできる。
本当のコンフリクトが起きるのは、双方の変更を、Gitが一つの確定した結果へ自動でまとめられないときだ。
まず境界を明確にする
よい定義は、それが何であるかだけでなく、何ではないかも教えてくれる。表面上は似ていても、実際には異なる状況を見分ける助けになる。
この境界がなければ、「mainが更新された」「同じファイルが変更された」「コンフリクトが起きた」を混同してしまうかもしれない。問題が起きたときにも原因を取り違えやすくなる。誰かがコードをcommitすれば自分のbranchは必ずコンフリクトすると思ったり、コンフリクトを避けるために、ほかの人が触れたファイルを変更できなくなったりする。
定義があれば、本当に注目すべきなのは「誰かが変更したか」ではなく、「それらの変更を自動でマージできるか」だと分かる。
結論の根拠をたどれるようにする
概念を理解するとは、一文の説明を覚えることだけではない。その一文を起点に、さらに先まで考えられることだ。
コンフリクトとは、Gitが最終的な結果を自動では決められない状態である。ならば、コンフリクトを解消する本質は、数行の特殊なマーカーを消すことではなく、Gitに代わって判断することにある。双方の変更がそれぞれ何を解決しようとしたのかを理解し、最終的なコードの形を決めなければならない。
そこから、さらにいくつかのことを導ける。コンパイルが通ったからといって、コンフリクトを正しく解消できたとは限らない。片方をすべて削除することも、必ずしも正解ではない。コンフリクトマーカーが消えたという事実が示すのは、Gitがその選択を受け入れたことだけであり、その選択がコード本来の意図に沿っていることまでは保証しない。
こうした結論を、一つずつ暗記する必要はない。定義を理解していれば、そこから導き出せる。
多くの知識がばらばらに見えるのは、大量の結論を覚えていても、それらが生まれる起点を見つけていないからだ。定義は木の根に似ている。根がしっかり張っているほど、あとで出会う新しい問題も同じ構造の中に位置づけて理解しやすくなる。
まず同じことを話しているか確かめる
多くの議論は、表面上は結論について話しているようで、実際には双方が同じ言葉に異なる意味を与えている。
ある製品を「シンプルだ」と言うとき、機能が少ないという意味で使う人もいれば、初めて使うときに理解しやすいという意味で使う人もいる。長く使っても繰り返し手入れする必要がない、という意味で使う人もいる。三人とも「シンプルさ」について話していながら、論じているものは同じではない。
このような言葉はほかにも多い。効率、品質、完了、安定性、リスク、自由、公平などだ。
よく使う言葉ほど、互いに分かり合っていると思い込みやすい。ところが具体的な話になると、言葉の背後に隠れていた違いが現れる。ある人が「この機能はもう完成した」と言うとき、コードを書き終えたことだけを指しているかもしれない。別の人にとっての完成には、テスト、ドキュメント、リリース、監視まで含まれている。
最初に定義を明らかにしなければ、その後の議論を深めるほど、ずれが大きくなりかねない。
だから重要な議論で「その言葉は具体的に何を指していますか」と尋ねるのは、言葉尻をとらえることではない。双方が同じ足場に立っているかを確かめる行為だ。
本当に理解しているだろうか
曖昧な理解は、しばしば心地よい。説明する必要さえなければ、自分はもう分かっていると思いやすい。
だが定義しようとすると、選択を迫られる。どの特徴が本質で、どれがたまたま伴うことの多い特徴なのか。どの状況を含め、どの状況を除外すべきなのか。ある条件を取り除いても、その概念はなお成り立つのか。
「自分の言葉で説明してみる」ことが有効な学習方法なのも、そのためだ。原文を別の言い方に置き換えるのではなく、その概念に欠かせない部分を捉えられているかを試している。
もちろん、一言で明確に説明するとは、あらゆる複雑さを一文に詰め込むことではない。
定義は現実の完全な記述ではなく、現実へ入るための扉だ。核心を捉えられるほど簡潔であると同時に、重要な違いを消さないほど正確でなければならない。広すぎる定義には物事を区別する力がなく、狭すぎる定義は現実の状況を締め出してしまう。
さらに重要なのは、定義にも適用範囲があることだ。
日常会話でいう「衝突」とGitの「コンフリクト」は同じではない。法律、数学、哲学でも、同じ言葉にそれぞれの定義があることは珍しくない。文脈から切り離して、いつでも正しく、あらゆる場面に当てはまる一文を探すことはできない。
定義を答えにしてはいけない
定義は議論の終点ではなく、観察、実践、判断の代わりにもならない。現実の世界には境界的な事例がしばしば存在し、古い定義も知識の発展に伴って修正されることがある。定義の価値は、複雑な物事を永遠に固定することではない。今ここで考えるための、明確で検証可能な出発点を与えることにある。
問題が混乱してきたら、一歩引いて問い直してみるとよい。私たちが話しているそれは、いったい何なのか。
定義を見つけたからといって、多くの問題が自動的に消えるわけではない。それでも定義があれば、少なくとも自分たちが何を話しているのか、問題はどこで起きているのか、次にどの方向へ考えを進めるべきかが分かる。
それだけでも、何かを理解するための重要な一歩になる。