整理されていない構造に、知らず知らず慣れてしまっていませんか？

こんな経験はないでしょうか。

・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で見る

技術の基礎からやり直すために、なぜ一歩勇気を振り絞れたのかのノンフィクション作品です。