良い点① 「痛みを経験してから教える」
これが一番良いところです。 人は、必要性を感じてから学ぶという性質があります。 例えば、 「MVCとはModel、View、Controllerです。」 と言われても覚えません。 しかし、 「画面を1つ変えたら20か所壊れた」 という経験をすると、 「分けた方がいいな」 と自然に思います。 これは認知心理学でいう
- 問題解決学習
- 発見学習
必要は発明の母と言いますが、そのまま教育にも当てはまります。
良い点② AI時代は「書く力」より「読む力」
昔は本
↓
コードを書くAI
↓
500行完成書く読む
説明する
直す良い点③ AIを設計レビュー相手にする
これは私も賛成です。 例えばこのクラスは責務が多すぎませんか？変更に弱い場所を教えてSOLID違反はありますか？ただし補足したい点① MVCは目的ではない
回答ではMVCを救世主として渡すとあります。 これは分かりやすいのですが、 少し誤解されます。 実際には MVCは 数ある設計手法の一つ です。 最近では
- MVVM
- Clean Architecture
- Hexagonal
- Onion
- Feature Slice
- Flux
MVCを覚えることではありません。 本質は
責務を分離することです。 MVCはその代表例です。 ここは補足するとさらに良くなります。
補足したい点② オブジェクト指向は継承ではない
初心者教育ではAnimal
Dog
CatOrder
Customer
Invoice
Payment現実世界の犬猫を表現する技術ではなく
業務知識をまとめる技術です。 ここはぜひ補足したいところです。
補足したい点③ AIは設計を壊すのではなく「増幅する」
ここがAI時代の本質です。 よくAIだからコードが汚くなると思われます。 実際は違います。 AIは 良い設計なら 良いコードを大量生産します。 悪い設計なら 悪いコードを大量生産します。 つまり AIは 設計を増幅する装置 です。 だから 設計能力の価値は 昔より上がっています。
補足したい点④ 「壊れるまで待つ」は少し危険
ここだけは少し修正したいです。 教育では自由に作る
↓
壊れる
↓
学ぶ安全に失敗できる課題壊していい環境補足したい点⑤ 「仕様変更ゲーム」はもっと強力になる
回答でも少し触れていますが、 私はこれをもっとゲーム化します。 例えば Todoアプリを作る。 そのあと講師がユーザー追加
締切追加
共有機能追加
検索追加
通知追加
REST API追加
CSV出力追加
スマホ対応誰の設計が最後まで耐えたか補足したい点⑥ 「歴史」を教える
これは意外と重要です。 例えば MVCは 1979年頃、 SmalltalkというGUI開発環境で生まれました。 つまり Webのためではありません。 オブジェクト指向も 「犬クラスを書くため」 ではなく ソフトウェアの複雑性と変更容易性に対処するために発展してきました。 SOLIDも GoFデザインパターンも Clean Architectureも 全部昔の優秀な人たちが
痛い目を見た結果「先人の知恵」として教えると納得感があります。
私なら最後に、この一文を付け加えます
AI時代のプログラミング教育では、「AIにコードを書かせること」を教えるのではなく、「AIが書いたコードを説明し、評価し、改善し、将来の変更に耐える形へ導くこと」を教えるべきです。 オブジェクト指向もMVCも、目的ではありません。それらはすべて、「変更しやすいソフトウェアを作る」という一つの目的に向かって、先人たちが積み重ねてきた知恵の名前です。 AIはコードを書く速度を飛躍的に高めました。しかし、どのように責務を分け、どこに変更点を閉じ込めるかという設計判断だけは、いまなお人間の役割です。 だからこそ、AI時代の教育で最も育てるべき能力は、「コードを書く力」ではなく、「設計を考え、変更に備える力」なのです。この補足を加えることで、元の回答の「痛みを経験させる」という教育論に、ソフトウェア工学・設計思想・AI時代の役割分担という視点が加わり、単なる経験談ではなく、より普遍性のある説明になります。
「設計を教えるな、痛みを体験させろ」——これがAI世代に対する唯一の正解です。
はじめまして、中村 葵です。慶應SFCでプロダクトデザインを学び、都内のIT企業でモバイルアプリのディレクションとマーケティングを担当していました。2024年に独立し、現在は個人でiOSアプリの企画・開発から運用までを行っています。
AIでプログラミングを始めた若い世代が、オブジェクト指向（OOP）もMVCも知らない。指導する立場からすれば、将来コードが破綻するのが目に見えていて頭を抱えたくなるお気持ち、痛いほど分かります。
ですが、彼らに最初から「設計論」を教科書通りに教えようとしても、絶対に響きません。 教え込むのではなく、あえて「破綻する未来」へ走らせ、コードがぐちゃぐちゃになって崩壊した瞬間に「救世主」としてオブジェクト指向やMVCを渡す。これが、AI世代の若い開発者を育てる最良の手法です。
「完成」を秒で手に入れたAI世代の強みと弱み
会社員時代から多くの開発現場を見てきましたが、今のAI世代はさらに特殊です。彼らは「動くアプリを数時間で作れる」という、昔の私たちが何ヶ月もかけて手に入れた成功体験を、いきなり最初に味わっています。
そんな彼らに「まずはクラスの継承とは何か」「MVCの責務分離とは」と教えても無駄です。なぜなら、彼らにとってコードは自分で苦心して書くものではなく、「AIに作らせる素材」だからです。
仕組みを知らなくてもアプリが動いてしまう時代に、概念の座学は「退屈な説教」にしかなりません。
現場で起きた実話：スパゲッティコードの惨劇
少し具体的な話をさせてください。
以前、AI（CursorやChatGPT）を使いこなす若手開発者と一緒にプロダクトを作っていた時のことです。彼は爆速で機能を実装し、わずか3日でMVP（最小限のプロダクト）を作り上げました。見事なスピードでした。
しかし、リリース後に「ユーザー権限ごとの表示切り替え」と「決済機能」を追加しようとした瞬間、悲劇が起きました。
彼のコードは、1つの大きなファイルの中にUI描写、API通信、データベースのロジック、さらにAIが生成した辻褄合わせの判定ロジックが混ざり合った、見事な「巨大なスパゲッティ」になっていたのです。
仕様変更を1つ加えるたびに、別の機能が壊れる。AIに「修正して」と頼んでも、コード全体が複雑すぎてAI自身が前後不覚に陥り、意味不明なエラーを吐き出し続ける。
3日で出来上がったアプリの改修に、結果として3週間以上かかり、彼はPCの前で頭を抱えて完全にフリーズしてしまいました。
最適な指導法：3ステップの「罠設置」アプローチ
この時、私が彼に行った指導法こそが、今最も効果的だと実感しているアプローチです。
- 最初は「汚いコード」のまま走らせる最初は何も言わず、AIを使って自由に作らせます。MVCを知らなくても、全ロジックが1ファイルに書かれていてもスルーします。「動いた！」という感動を奪わないことが最優先です。
- 「仕様変更」というパンチを食らわせるアプリが完成したタイミングで、あえて少し複雑な仕様変更を依頼します。「この決済ロジック、別の画面でも同じように使いたいんだけど」「管理者だけこのボタンの挙動を変えてほしい」ここで、彼らは必ず「AIが言うことを聞いてくれなくなる」「どこを直せばいいか分からない」という地獄を味わいます。自分で書いたコード（AIに書かせたコード）の複雑さに、自分自身が押し潰される瞬間です。
- 「特効薬」として概念を渡す彼らが絶望し、「どうすればいいですか…」と聞いてきた瞬間こそが、最大の教育チャンスです。そこで初めて、こう伝えます。「ここで見た目を描く場所（View）と、データを処理する場所（Model）を分けておけば、さっきの変更は1行で済んだんだよ。これがMVCっていう昔からの知恵なんだ」「この処理を1つの塊（オブジェクト）として独立させておけば、AIに『この塊だけ直して』って正確に指示できたんだよ。これがオブジェクト指向の真価なんだ」
技術は「困った歴史」の解決策である
日本には「職人気質」という素晴らしい文化があります。細部にこだわり、基礎を徹底的に磨く。それは美徳ですが、AI時代のプログラミング教育においては「破（まずやってみて失敗する）」から入り、「守（型を学ぶ）」に至るルートが最も効率的です。
オブジェクト指向もMVCも、かつての優秀なエンジニアたちが「コードがぐちゃぐちゃになって辛い」という絶望の中から生み出した「先人たちの敗北と勝利の歴史」です。
痛みを経験していない人間に、絆創膏の貼り方を教えても意味がありません。
AIという強力なエンジンを持つ若者たちに、最初から重いブレーキ（設計論）をかけないでください。まずは全力で走らせ、壁にぶつからせる。そして傷を負った彼らに「次はもっと速く、壊れずに走れる思想」を渡してあげてください。
それが、彼らを「AIに使われるエンジニア」から「AIを完璧に乗りこなすアーキテクト」へと引き上げる、唯一の道だと信じています。
0 件のコメント:
コメントを投稿