ITシステム開発の世界では、依存の少ないことがよいとされている。たとえばAというシステムがBという別のシステムの機能を使って処理を行っているとする。この時Bのシステムの機能に変更があった場合、Aのシステムの処理が正しく動かなくなる可能性がある。また、Bのシステムがトラブルで動かなくなった時にAのシステムも動かなくなるという問題も発生する。

このように、ITシステム開発において依存というものは、とくに限定された場面 (理由はともあれ、とにかく早くシステムを作らないといけない場合など) を除いては「悪」というのが通説だ。依存関係にならないように設計したり、プログラミングしたりすることが、すぐれたアーキテクト、プログラマということだ。

これはITシステムの世界以外に限らず、実生活においても同じことが言えるかもしれない。たとえば、恋愛に過度に依存してしまって、別離を告げられたときに自傷行為に走ってしまったり、身を投げてしまったりする人がいる。これは恋愛や恋愛対象に対して過剰な依存が発生していると言えるのではないだろうか。恋愛に限らず、熱狂的なファンが、その推しているものを失ってしまうときにも同様のことがある。アイドルグループの解散や、有名人が逝去することはたしかに悲しいことかもしれないが、それによって自分の人生まで終わってしまうと感じるのは間違いだと個人的には思う。

話をITシステム開発に戻すと、プログラミングの世界ではクラス間の依存を減らす対策として、「依存関係逆転の法則」というものがある。これは、上位と下位の依存関係を逆転させるための考え方だ。

たとえば、「車」クラスと「タイヤ」クラスがあり、車クラスに「タイヤを動かす」処理があったとする。その場合、「車」クラスが「タイヤ」クラスを必要としていた場合、上位の「車」クラスが下位の「タイヤ」クラスに依存している関係といえる。そのような依存関係がある場合、「タイヤ」クラスに変更があった場合、「車」クラスにも影響が及ぶため、好ましくない状態といえるだろう。

そうではなく、「車」クラスは「タイヤとはどういうものか？」といった抽象的な情報 (インタフェース) しか知らず、「タイヤ」クラスはそのインタフェースに適合するものという条件 (ルール) にする。そうすると、上位の「車」クラスは下位の「タイヤ」クラスに直接依存しなくなる。逆に「タイヤ」クラスは、インタフェースに依存することになり、依存関係が逆転する。これを「依存関係逆転の法則」という。

この考え方を実生活に適用するとどうなるだろうか。上述した恋愛の話であれば、「この人と恋愛関係でないと生きていけない」のではなく「この人と恋愛関係がなくなっても、同じように満たしてくれる他の人でも問題ない」状況ということではないだろうか。そうすれば、恋愛関係が破綻しても別の人とやり直せばいいか、という気分になれるはずだ。

ファン活動においても同じだ。推しているアイドルグループが解散したり、メンバーが卒業したりしても、同じように推せるグループや人がいれば乗り換えられる状況になっているほうが好ましい。そのためには、自分がファンになる条件や、その対象に求めるものを (深い依存関係になる前に) 明確にしておく必要がある。

人生において過度な依存は問題になることがある。好きなものを愛する気持ちは必要だが、うまく折り合いをつける必要があると言えるだろう。