整理されていない構造に、知らず知らず慣れてしまっていませんか？
こんな経験はないでしょうか。
・1つのクラスに、数え切れないほどのメソッドやメンバー変数
・1つのフォルダに、無数のクラスファイル
・ドキュメントも、一つのフォルダに、嫌になるほどのファイルの数
──結果、どこに何があるのか、すぐに見つけられない。
そんな状況に「なんとなく慣れてしまっている」ことが、
私たちの設計と認知の限界を曖昧にしているのかもしれません。
そして最近では、AIが出力したコードや設計のアウトプットも増えてきました。
そのレビューで、思わず「もう見たくない…」と感じたことはありませんか？
（もちろん、指示の出し方が悪かった──という反省もありますが）
美しいコードとの出会いと、謎の違和感
「読みやすいコード」「美しいコード」──
その理想像を語るとき、多くの人が思い浮かべるのが名著『リーダブルコード』でしょう。
私も例にもれず、その本から多くのことを学びました。
けれど、どこか物足りなさを感じていたのも事実です。
「もっと本質的な、なにかがあるのではないか？」──そう思っていたとき、
ある過去の体験を思い出しました。
まだ駆け出しだった頃、私はCOBOLのレガシー案件に携わっていました。
当時のコードは、増改築を繰り返した“どこに何があるか分からない構造”ばかり。
正直、うんざりしながらも、納期を守るために残業地獄の日々でした。
ところがある日、そのプロジェクトでふと古い設計書とコードに出会ったのです。
それは、30年以上前に書かれたものでした。
驚きました。
そのコードは、あまりにも整っていたのです。
・フォルダ構成は3階層以内
・ファイルごとに責任が明確
・一つの関数もシンプルで、まるで建築図面のような構造
初めて「見とれるほど読みやすいコード」を体験した瞬間でした。
誰が作ったのかわかりませんでしたが、
その設計とコードを手がけた名もなきエンジニアに、
私は心から尊敬の念を抱きました。今でもその記憶は色褪せません。
ただ当時の私は、それがなぜ“美しい”と感じたのか、言葉にできませんでした。
ただ──「妙にスッと頭に入る」──そんな印象だけが残っていたのです。
“美しさ”の正体──マジカルナンバー7±2
その疑問が解けたのは、後に出会った師匠の言葉でした。
設計は、“人の脳”の構造を意識しないとダメなんだよ。
ひと目で理解できないものは、設計とは呼べない。
そう語った師匠が教えてくれたのが、心理学者ジョージ・ミラーの論文です。
いわゆる「マジカルナンバー7（±2）」──
人間の短期記憶で、一度に処理・認識できる情報は5～9個が限界である、という有名な実験結果です。
みなさんも、職場で次のような適性検査を受けたことはありませんか？
「画面に表示されたボールの数を、すぐに答えてください」
──そういった形式のものです。
3〜6個程度なら、感覚的にすぐに判断できます。
ところが、7個を超えた途端に「あれ……何個だっけ？」と迷いが生まれる。
そんな経験、心当たりはありませんか？
実際、思い返してみると、あの美しかったCOBOLのコードは、まさにこの原理に沿っていたのです。
・フォルダ内のファイル数：7つ以下
・クラス内のメソッド数：多くても7±2
・1つの処理ステップで追うべき変数：5～9個以内
・設計ドキュメントも、一枚絵で7つ以内のモジュール構成
つまり、「ひと目で理解できる単位になるよう、すべてが構造化されていたのです。
現代のコード、そしてAI出力が壊す“構造”
一方で、現在の現場では、構造が見えないまま開発が進むような状況を、私自身も何度も経験してきました。
クラスは肥大化し、画面を何度もスクロールしないと構造が把握できない。
数十個の引数、数百行の関数──
もはや「全体をひと目で把握すること」は不可能になりつつあります。
最近ではAIがコードや設計・要件まで出力するようになりました。
確かに便利です。驚くほど大量のコードを、一瞬で出力できます。
しかし。
・要件が20個並んでいるが、優先順位も依存関係もわからない
・クラスの役割が重なっていて、どこに何を追加すべきか迷う
・“一望できない構造”のまま、量だけが膨らむ
──これでは、結局人間が“見て判断する”負荷は減りません。
むしろ、認知限界を超えるアウトプットによって、破綻のリスクが増しています。
AIと人間の“共作”には、構造というルールが必要
では、どうすればいいのでしょうか。
答えはシンプルです。
人が認知しやすい構造を、AIにも守らせる。
そのための“設計ガイド”を与えるのです。
たとえば：
・1ファイルあたりの関数数は7つ以内
・フォルダ階層は3段まで
・if文やswitchは5分岐以内に抑える
構造が深くなるなら分割する
実際に、CやC++などの分野では、MISRAやAUTOSARといった業界ガイドラインでも
「構成要素を限定する」ことが推奨されています。
これは単なる“ルール”ではなく、
人間が安全に理解・判断するために必要な“認知設計なのです。
おわりに──設計とは、“人の目にやさしい構造”をつくること
設計とは、ロジックを書くことではありません。
「人間が理解しやすいように、構造を整えることです。
その観点でいえば、AIが出力するものも同じ。
「人に見せるコード」「人が読む構造」である以上、
AIに対しても、人に優しい構造を求めるべきなのです。
この視点に立つことで、
私たちはAIと“並んで仕事する”時代にふさわしい設計力を、改めて磨いていけるのではないでしょうか。
そして最後に──
整った構造の美しさを教えてくれた先人たちに、心から感謝を伝えたいと思います。
あの時出会った設計とコードがなければ、今の自分の設計観は生まれていませんでした。
また、今回紹介した内容をより実践的に学びたい方には、以下のUdemy講座もおすすめです。
Udemyコース（8,800円 → クーポンで割引中）
▶️ AIとC#で極める！クリーンコードの技法（限定クーポン付き）
C#でクリーンコードと設計力を身につける実践講座
ChatGPTの活用方法や、伝わるコードの考え方を解説
出版書籍『あきらめない者たち』
▶️ Amazonで見る
技術の基礎からやり直すために、なぜ一歩勇気を振り絞れたのかのノンフィクション作品です。