私はソフトウェアエンジニアの採用活動を仕事柄しているのですが、DDDやクリーンアーキテクチャに興味を持つ人に本当によく会うことが多いように感じます。 私もDDDやクリーンアーキテクチャの本は読んでみたことはあり、それらが提唱する思想自体はすごくいい内容だと感じます。 DDDは「モデリングを行う上で、ビジネスドメインのエキスパートと議論をすることの大切さ」について説いていますし、クリーンアーキテクチャは「レイヤ化して依存の方向を制御することで、メンテナンス性高いアーキテクチャにすることの大切さ」について説いています。 （読んだのが大分昔なのでうろ覚えですが、エッセンスとしてはそのあたりが重要だったと記憶しています）
ところが、DDDやクリーンアーキテクチャの本で出てくるようなアーキテクチャ図がネットで一人歩きし、それらを覚えることで理想のアーキテクチャができるかのような銀の弾丸的な捉えられ方をしていることが多いように感じます。
そのあたりの話はこのブログにもまとまっており、個人的な感覚としてはとても同意する意見です。
さて、少し話が広がりますが、インターネットやリアルでのエンジニアの声を聞いていると、DDDやクリーンアーキテクチャだけでなく、スクラム・ティール組織等の話題も非常に人気だなと感じます。 これら全てに共通するのは、「海外の偉い人が作った人気のフレームワークであること」「あらゆる時代・組織において発生しがちな課題（コード保守性課題・組織課題）に対する対応策であること」などかと思います。 そして（全員が全員とは言いませんが）非常に多くの人が、「それらのフレームワークを活用して自分たちの現場にフィットした枠組みを作り上げること」ではなく、「それらの原本を忠実に覚え忠実に実践することや、原本が説明している事細かな単語の定義について議論することに心血を注いでいる」ように感じるときがあります。（※ あくまで自身の観測範囲の話です）
フレームワークを勉強すること自体は非常に大事です。 それはあくまで、現実の課題を理解する枠組みを得るため、そして現実の課題に対処する枠組みを考え出すために重要という話です。 そのフレームワークを勉強したりだとか、そのフレームワークについての（用語の定義などの）議論に参加することで、時間をかけた分だけ技術力が向上したと考えてしまいがちな思考の罠があると私は思っています。 フレームワークの正確な定義を理解していることが技術力ではなく、フレームワークを応用し現実の課題へのより良い対処法を生み出せることこそが技術力です。
これがソフトウェアエンジニアにおける”正解を求めてしまう”罠です。 ソフトウェアエンジニアはその名のとおり、”ソフト”、つまり動的に変化する課題領域に対処しなければいけないクリエイティブな職業なので、理論を勉強することを目的化するのではなく、その先の理論を応用し新しいモノを生み出す存在であって欲しいなと感じます。
