プログラミングを学ぶ上で重要な考え方のひとつとして、「デザインパターン」とか「アーキテクチャ」という概念がある。「デザインパターン」とは、プログラミングを進めていく上で突き当たるであろう問題を解決するための「典型的な方法」だ。
身近な例でいえば、「コンロが一つしかないキッチンだが、夕食にはカレーだけではなくコロッケも提供したいと考えている。どうすれば２つの料理が冷めていない状態で提供できるだろうか」などといった問題だ。
このとき、最善の回答は「新しいコンロを用意する」とか「隣家のコンロを使わせてもらう」ことかも知れないが、よくある回答(そして悪くない回答でもある)は「電子レンジで調理する」とか、あるいは、「カレーを作ったあと、鍋にこびり付いたカレーをコロッケの衣で拭き、その熱を使ってそのまま揚げ物を始める」とか、そういう感じだろう。これがデザインパターンだ。
むろんこれは「解の公式」ではない。完全な回答ではないが優れたトレードオフであることを保証する、「突然の思いつきよりは洗練されたアイデア」だ。

そして、「ひとつのソフトウェアを、どのように設計するか、どのように構築し実装していくか」を定義するのが「アーキテクチャ」だ。
一つ例を挙げると、「生徒会委員は全校生徒会の運営と議決事項の執行にのみ務める。生徒会委員は全校生徒によって任命される。保護者への対応や対外的な活動は教師が行う。が、教師に対して生徒会委員の及ぶ権限は及ばず・・・」などといった「仕組み」のことだ。
もちろんこういうものはそれぞれの状況やソフトウェアによりまちまちであろうが、少なくとも「生徒会が教師を解雇できる仕組み」を持つ学校が成功した例はないし、タタミの上に浴槽がおいてある部屋はそうそう作られないだろう。大抵の組織やソフトウェア、建築物、etc…、たいていのものはアーキテクチャに従っている。

ところで、デザインパターンやソフトウェア・アーキテクチャは完成するソフトウェアのどのような面に貢献するのだろうか?
この業界の用語でいえば「可読性」「保守性・メンテナンス性」「作業能率」などの言葉がその答えとなる。多くの人間にとって扱いやすく、わかりやすいということだ。
先人の知恵は共通の認識として共有されているから、理解しやすいというわけだ。

しかしこれらの概念は、時にイノベーションを阻害する。
本当に革新的なモノが作られたときには、ソフトウェアの世界では、アーキテクチャやデザインパターンの型にはまらないものも多い。可読性や保守性は、往々にしてソフトウェアの表面に、ユーザーにとって関係のないことだし、どれだけ綺麗なコードで書かれていても、ふざけたインターフェースのソフトに遭遇することはあるだろう。もちろんその逆もある。汚いコードで書かれていても、本当に革新的なモノであれば、それが革新的なモノであることを少しも不安定にするものではない。

革新的な技術を前にしては、旧来のアーキテクチャスタイルを当てはめようとするのは無駄な試みだ。

実際、人間社会の組織や人間関係というものも、こうした「デザインパターン（決まり事）」や「アーキテクチャ（ゆるい拘束）」が多い。そしてそれらがイノベーションの阻害となっていることも。
重要なのは、その枠組を見出すことだ。なんとなく不愉快な気持ちを持て余すのではなく、
自分がどのようなアーキテクチャ/パターンに問題意識を抱えているのか、言葉として理解することだ。
そのためにこうした分野を学習していくのも、悪くはない。