「アーキテクチャ」と「設計」って同じじゃないの?と思ってた話

Last updated at 2026-07-27Posted at 2026-07-24

恥ずかしながら今まで「設計」と「アーキテクチャ」は同じ意味だと思っていました。しかし、とある書籍を読んで明確には違うことが分かりましたので内容を簡単にまとめていきます。

そもそも何が違うの

一言でいうと、設計は「どう作るか」を決めること、アーキテクチャは「何を優先するか」を決めることらしいです。

私のイメージだと、設計もアーキテクチャも「技術的にいい感じの構成を考える仕事」でひとくくりでした。でもよく考えたら、コードの書き方とかクラス構成を決めるのと、システム全体としてスケーラビリティを取るか開発しやすさを取るか、みたいな話は、たしかにレイヤーが違ったかもと思います。

私が経験してきたイメージだと、アーキテクトが偉い人として上から全部決めて、開発チームはそれに従うだけ、みたいな構図をなんとなく持ってました。

でもこれ、実はうまくいかないパターンとして紹介されていました。（驚き）
決めたことが現場にちゃんと伝わらなかったり、逆に現場での気付きがアーキテクト側にフィードバックされなかったりして、結局アーキテクチャが形だけのものになってしまうそうです。

なので本来は、アーキテクトと開発チームが常にやり取りしながら、アーキテクチャ自体も一緒に育てていくものらしいです。「一度決めたら終わり」じゃないんですね～

私は「アーキテクト=一番技術に詳しい人」だと思っていたんですが、これも違うようです。

開発者に求められるのは特定の技術を深く掘り下げる力で、アーキテクトに求められるのは逆に「幅広く選択肢を知っている」ことらしいです。ひとつの技術のスペシャリストであるより、「この問題には解決策が5つくらいある」と知っている方が価値が高い、、、と。

確かに、言われてみれば確かに一つの技術しか知らないと、他の選択肢と比較検討すらできないですもんね。

これが一番なるほどと思った部分です。

REST APIがいいかメッセージングがいいか、みたいな話に、検索すれば出てくるような「唯一の正解」はないそうです。あるのはトレードオフだけ。

メリットだけ語れる人は多いけど、デメリットまでちゃんと説明できる人は少ない、という話も出てきて、私も反省しました。良さそうな選択肢ほど、あえて「ここが弱点です」まで言えないといけないんですね。

技術の話だけしていればいいと思っていたんですが、実は「なんでこの性能が必要なのか」をビジネス側の言葉に翻訳できないといけないらしいです。ここは私もまだピンときていない部分なので、引き続き勉強していきます。

同じように「設計とアーキテクチャって同じでしょ」と思っていた方の参考になれば幸いです。