N Code LaboでiOSアプリ開発を教えた6年間の振り返り

N高グループ・N中等部・NCodeLabo Advent Calendar 2025 の2日目の記事です。

挨拶・自己紹介

こんにちは、髙津悠樹と申します。

私は2019年入学のN高4期生で、2019年から現在までN Code LaboというN高グループで運営するプログラミングスクールで講師をしています。

生徒に教える講師の業務だけではなく、iOSアプリ開発周りの教材制作や修正なども担当をしています。

講師紹介
インタビュー記事

在学時には起業部(現: 起業部BLP)に所属をしており、現在でもOBとしてBLP生の壁打ちなどをするTAとしても学園内でお仕事をさせていただいています。

2019年からN高グループに生徒・TAどちらの立場でも関わらせていただき、丸6年が経過しました。
6年という月日は、小学生が入学してから卒業するまでの年月と同じだなぁと考えると、私はどれだけ卒業した高校にいるのだ？とふと感じることもありますが、6年間N Code Laboでプログラミングを指導し続けられているというのは非常に自分にとっても貴重な経験をさせてもらっているなと感じています。

このN高グループのアドカレを書くのは2019年ぶりらしいです。当時は高校1年生、16歳。若いですね。私は今22歳です。泣きました。
当時の未熟なアドカレが残っているので、恥ずかしいですがここにも貼っておきます。

さて、今日はタイトルの通り私のN Code Laboでの6年間をまとめてみます。私の文章に関してはAIを一切使わずにこの記事は作るので、最後まで読んでいただけると嬉しいです。

N Code Laboとは？

早速宣伝っぽくなってしまいますが、私が所属するN Code Laboについて簡単に紹介します。

N Code Laboは小学生 ~ 高校生までが通えるプログラミング教室です。Scratchをはじめ、Unityでのゲーム開発やSwiftでのiOSアプリ開発、Webアプリの開発まで、現役エンジニア・情報系の大学生の講師が少人数で指導しています。

東京2キャンパス・横浜1キャンパス・大阪2キャンパスで開講しており、オンラインでも授業を受けることが可能です。

個人的な感覚ですが、教材だけにとどまらず専門分野を研究している大学生講師や、現役ゲームエンジニアなどのサポートがありながらレベルの高い自主制作にも挑戦できている生徒が多いなという印象です。

私はN高の在学中から講師としてアルバイトをしていたので、朝から夕方まではN高生として授業を受け、放課後はN Code Laboで講師としてプログラミングを指導するという不思議な学生生活でしたが、卒業後も続けるくらいには良い教室です。

プログラミング教育における想い

6年間働く中で私が教育者としてどのような立場で生徒と接するべきか。ということを深く考え、ようやく最近自分の中で答えが出てきたので、変化と合わせて書いていきます。

働き出した当時には「圧倒的にプログラミング力が高く、なんでも教えられる先生」が理想の講師像だし、教育者としてそうあるべきだと考えていました。

保護者の方からお金をいただいているので、当然学びがある時間を提供することは第一ではありますが生徒との年齢差が離れていくにつれて徐々に変わっていきました。

今は「髙津という人間と出会い、人生変わったな」と思ってもらえる授業を提供することが教育者としての信念になっています。

AIが発達し、人がコードを書く必要なんてない。とまで言われる現代ですが、教育はなくなりません。
プログラミング教室の講師が言うことではないかもしれませんが、私に教えられることはChatGPTに月3000円払えば教えてもらえます。それくらいChatGPTが優秀なのです。

だからこそ、「髙津先生」という人間そのものに価値を感じてもらうことが大事だと考えています。

話はそれますが、私はN高起業部で教育系の会社を起業して取締役として事業をしていました。
教育系の会社をやる中で重要だと思ったことは「思春期に出会う、親でも学校の先生でもない大人」の重要性です。

言い方は良くないですが「プログラミングスクールの先生」には責任がありません。

生徒が健全に育成されることや教室内で危険が及ぶことはあってはならないので保護監督の責任はありますが、

塾の先生のように「成績を上げる / テストの点をよくする」といった責任や、部活の顧問の先生のように「全国大会で勝たなければ」なんて責任もありません。

「責任がないから無責任で良い」のではなく「責任がないからこそ、フラットに話せる信頼関係を作る」ことが責任なのだと感じました。

自分自身も思春期はありましたが、親や先生や学校の人には話せないことはたくさんありました。
一例ですが、↓ のようなことはこれを読んでいる方も一度は思ったことがあるのではないでしょうか。

「進路について親にはこう言われているけけど、自分はこう思っている、、」
「部活をやめようか迷っている」
「兄弟と喧嘩してる」
「文化祭の実行委員になったけど、クラスをうまくまとめられない」
「好きな人がいる」
そんなことをフラットに相談できる外部の大人って、意外と少ないと思います。
なぜなら、他で出会っている大人は何かしらその子に対して「責任」があるからです。

プログラミング講師としての責任はプログラミングを教えて、プログラミングの能力を向上させることです。
でも、プログラミングを学習するだけならChatGPTでも十分な時代になってきてしまいました。

そんな中で教室に来てくれる生徒の教育として重要なことは「信頼できる親でも学校の先生でもない大人」と出会える環境があり、安心して通えることだと思っています。

だからこそ、最近は私はプログラミングだけを教えることに終始するのではなく「最近どう？」と雑談から始めたり、時には人生相談で90分の授業を終えることもありますが（滝汗）そんな授業であっても生徒が教室に入ってきた時よりも帰る時に「来てよかった」と思ってもらえる時間を作れるように頑張っています。

それが、N Code Laboで教育者として6年間働いた総振り返りかもしれません。

N Code Laboで経験した技術面での振り返り

何を教えているのか

前置きが長くなりましたが、本題に入っていきます。
私は前述の通り、N Code Laboにて6年間iOSのアプリ開発を指導しています。簡単にいうと「iPhone向けアプリ開発の先生」です。

言語はSwift・エディタはXcodeです。

「プログラミング教育」におけるiOSアプリ開発の大変なところ

iOSアプリ開発の中で私が大変だなと思うところはいろいろありますが、毎年行われるiOSアップデートによって言語自体でできることが増えたり・減ったり。エディタのXcodeにもメジャーアップデートが年に一度必ず入ります。

・「古いXcodeバージョンでは、最新バージョンのiOSが入った実機に対してビルドが行えない」

・「教材で操作を指示している内容が、最新のXcodeでは別の挙動に変わった」

・「教材で使用している外部ライブラリが、最新のSwiftバージョンでは更新をしないことになっていた」

なんてことがザラに発生します。教材をアップデートする業務も私で対応していますが、そのためには常に最新の情報を勉強し続ける必要があります。

そのため、もともとAppleが好きだったので見てはいたWWDCをちゃんと見るようになりました。

必然的に最新情報や言語レベルでの知識をキャッチアップする状況ができたので、エンジニアとしても成長する機会ではあったなと今振り返ると思います。

また、現在でこそAppleの発表会の日本語訳はかなり正確ですが当時はまだまだ完全ではなかったので、英語のリスニング力だけは高まりました。

コロナ禍でのオンライン授業

上述の「大変なところ」と重なりますが、2020年には新型コロナウイルスによってN Code Laboでも対面授業からオンライン授業へ対応を変更しました。

今でこそZoomでの授業やMTGは当たり前ですが、指導歴半年の時にはかなり苦戦しました。
当時のHTML・CSSでのWeb開発の授業や、Pythonを使った授業ではGUIを使った指導ポイントはあまりなかったので、コードが正しく記述できていれば問題なく動作をするので比較的指導が簡単です。

一方でUnityやXcodeといったGUIのあるエディタやツールを使って指導をする場合は、教室であれば「その右上のボタンを押して」と画面に指差しして教えたり、「ちょっと貸してね」と講師が生徒のPCを一時的に操作をしてその操作をしながら指導する。ということが可能です。

Zoomになることで、「あれ」や「そこ」といった言葉ではなく「明確な機能の単語で」伝えることになり、ここでもある意味ではXcodeの理解を深めることができるきっかけになったと感じています。

教室でしていた「これ」や「そこ」といった抽象的なものではなく、具体的な名前で説明をすることになると、生徒からも「xxxxってなんですか？」という質問が来るようになります。

私自身も「これを押したらこうなる」という概念的な理解しかできていなかった箇所が当時は多く、コロナ禍での自宅授業では教室であれば他の生徒を指導している同僚の先生に「これってなんでしたっけ」と聞くことができますが、それもできないので、オンライン授業のはじめはとにかく授業が終わった後は自己反省して自分で勉強をしていました。

今であればChatGPTに「これってなんだっけ？」と聞けば一発で答えが出てきますが、それを自力でググって解決したり、redditで謎のエラーを共有している外国人と会話をしたりして学習機会にすることができたのは、コロナ禍でのオンライン授業で私が得た最大の学びだったと感じています。

⬇︎ 2020年4月の授業中のスクショです。若い、、、

UIKitからSwiftUIへの教材のフルリファクタリング

2019年の開校初年度は、iOSアプリコースはUIフレームワークにUIKitを採用していました。
当時もSwiftUIは存在していましたが、まだまだUIKit依存の箇所が多くSwiftUI単体として教材にすることは難しく、UIKitで授業をしていました。

ある意味、UIKitを使っていなければオンライン授業でGUI操作をする必要は半分以下になるのですがそんなことは想定していなかったので、UIKitで指導をしていました。

UIKitはObjective-C時代から現在のSwift時代まで、一貫してネイティブアプリ開発のUIフレームワークとして存在し、GUIによって直感的にUIを配置できる。という良さはありますが、autolayoutなどを使ってiPhoneSEの画面サイズと、iPad Proの画面サイズどちらにも対応させる。といったことを設定する必要があり、慣れている私でも稀に「なんだこれ？」となるので、学生に指導をするのはかなり大変でした。

また、私自身がN高起業部などの別の活動で多忙となり、SwiftUIについてキャッチアップを進めることができず、実際にSwiftUIを人に教えることができるレベルになったと言えるようになったのは2021年ごろでした。

2021年ごろの記憶を遡ってみると、多くのiOSのネイティブアプリを開発している会社で徐々にフレームワークのリファクタリングが行われていた時期なのかなと感じています。

当時はFirebase自体こそ使えるものの、
公式サンプルコードや FirebaseUI のような周辺ライブラリが UIKit 前提 になっているものが多く、
SwiftUIのAppライフサイクルとうまく噛み合わせるのに苦戦する場面がありました。

実装した機能がどうしても動かずに 2 日ぐらい悩んだ末、
「一旦 UIKit で書き直したら普通に動いた」ということもありました😇

当時はSwiftを学習している生徒はすべて私ともう一人の先生で対応をしていたので、教材が間に合わなくても自分たちの頭の知識と公式チュートリアル・ドキュメント、そしてたくさんのQiita記事によって授業を成立させていました。

2022年ごろにようやく時間が生まれたのでこのタイミングでUIKitからSwiftUIへの教材のリファクタリングを行いました。

思わぬトラップでしたが、SwiftUIはシンプルかつ分かりやすい記法で設計されているため、UIKitの教材をそのままリファクタリングをすると教材のページ数が1/3程度になってしまうということがわかり、「ページ数少なすぎないか、、、？」と議論をしたのが印象に残っています。

SwiftUIはAIでコードを書かせてもコピペでロジックとUIが接続されて動作をさせることができるので、「プログラミングといえばHTML」みたいな感じで宣言型UIによって書いたものが表示される。という体験をすぐにわかるようになったのは、教材としてかなり良いUIフレームワークだなと感じています。

例えば、以下のUIを実装しようとした時、UIKitとSwiftUIではかなり実装されているプログラム量に差があります。

SwiftUI

FruitListView.swift

import SwiftUI

struct FruitListView: View {
    let fruits = ["Apple", "Banana", "Orange"]

    var body: some View {
        NavigationView {
            List(fruits, id: \.self) { fruit in
                Text(fruit)
            }
            .navigationTitle("Fruits")
        }
    }
}

struct FruitListView_Previews: PreviewProvider {
    static var previews: some View {
        FruitListView()
    }
}

UIKit(ViewController)

FruitTableViewController.swift

import UIKit

class FruitTableViewController: UITableViewController {

    let fruits = ["Apple", "Banana", "Orange"]

    override func viewDidLoad() {
        super.viewDidLoad()
        title = "Fruits"
        tableView.register(UITableViewCell.self, forCellReuseIdentifier: "cell")
    }

    override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return fruits.count
    }


    override func tableView(_ tableView: UITableView,
                            cellForRowAt indexPath: IndexPath) -> UITableViewCell {

        let cell = tableView.dequeueReusableCell(withIdentifier: "cell", for: indexPath)
        cell.textLabel?.text = fruits[indexPath.row]
        return cell
    }
}

コードがシンプルになり、教材がわかりやすくなるのは明確なメリットでしたが、教材を作って教える立場の中ではこれまで以上に教材のわかりやすさや機能の応用を追加する必要があり苦戦しました。

非同期処理の実装簡略化による高難易度教材の修正

Swift 自体にも大きな変化がありました。
それが async/await による非同期処理の書き方です。

N Code Labo では、Firebase を使ったチャットアプリの教材を用意していますが、
async/awaitの登場によって、この教材の実装コストもかなり下がりました。

それまでは、いわゆる「コールバック型」の非同期処理で実装をしていました。

demo.swift

func sendMessage(text: String, completion: @escaping (Error?) -> Void) {
    let data: [String: Any] = [
        "text": text,
        "createdAt": Date()
    ]

    Firestore.firestore()
        .collection("messages")
        .addDocument(data: data) { error in
            completion(error)
        }
}

//ViewController側の実装
@IBAction func didTapSendButton(_ sender: UIButton) {
    let text = messageTextField.text ?? ""

    sendMessage(text: text) { [weak self] error in
        if let error = error {
            self?.showError(error)
            return
        }

        self?.messageTextField.text = ""
    }
}

この書き方だと、

@ escaping の説明や[weak self] をつける理由、
コールバックの中で UI を更新するタイミング
エラー処理でさらにネストが増える...

など、チャットアプリではないところでの学習コストがかなり高くなっていました。
そのため、従来はSwift教材の再難易度教材の一つでした。

Swift Concurrency（async/await）が使えるようになってからは、
同じ処理をかなりシンプルなプログラムで書けるようになりました。

例えば、SwiftUI + Firestore + async/await でメッセージ送信をする場合は、
教材では次のような形にしています。

swiftUIdemo.swift

@MainActor
final class ChatViewModel: ObservableObject {
    @Published var messageText = ""
    @Published var isSending = false

    func send() async {
        guard !messageText.isEmpty else { return }

        isSending = true
        defer { isSending = false }

        do {
            let data: [String: Any] = [
                "text": messageText,
                "createdAt": Date()
            ]

            _ = try await Firestore.firestore()
                .collection("messages")
                .addDocument(data: data)

            messageText = ""
        } catch {
            // 本番ではエラーをちゃんと実装しています。
            print("Failed to send message: \(error)")
        }
    }
}


-------------------------------------------------------------
//View側の実装
struct ChatView: View {
    @StateObject private var viewModel = ChatViewModel()

    var body: some View {
        VStack {
            // UIをここに実装しています。

            HStack {
                TextField("メッセージを入力", text: $viewModel.messageText)

                Button("送信") {
                    Task {
                        await viewModel.send()
                    }
                }
                .disabled(viewModel.isSending)
            }
            .padding()
        }
    }
}

チャットアプリのような題材は、

• メッセージの送信

• 新着メッセージの取得

• ログイン・ログアウト

など、非同期処理だらけです。

難易度の高かった教材をリファクタリングすることで誰しもが到達できる教材レベルへ変更できたことは、プログラミングスクールで授業をする中で「どの先生」が担当しても同じクオリティで授業ができるという授業の質の担保にも繋がります。

わかりやすい教材は同時に生徒の理解にも繋がりやすいので、かなり良い教材になったのではと考えています。（現在はFirebaseが有料でないと一部機能が使えなくなってしまったので、改めて作り直しをしています、、、)

AI時代への対応

2025年になり、急速にAIコーディングが発展し「使っている前提」くらいになってきました。
私も個人開発ではClaude CodeやGPT CodexやGemini cliにCursorなど一通り有名どころのAIコーディングツールを使ってvibe codeingをしています。

一方で、プログラミング教育において「AIによって簡易的なMVPを作れてしまう」というのはかなりリスクもあると考えています。

プログラミング教育の観点で特に難しいなと思う点は
「なんとなく動く」もののクオリティが圧倒的に高いことと、
自分自身がどんなに学習をしてもAIが一瞬でアウトプットしてくるものを上回ることが難しいことであると考えます。

これまでは、ググって出てきた記事の内容をコピペして動く → 動かないのでまたコピペをする→ みたいなコピペプログラミングでは身になる学習にはならないといった課題はありました。

一方で、動くものを作れるようになるにはそれなりの苦労や時間が必要で「コピペ」だとしても正しい場所へコピーするためにプログラムを読んだり、関数名を変えたりするといった手作業での実装は発生していたので、コピペプログラミングも一概に私は否定をする気はありません。

一方で、AIプログラミングではそういった「コピペ」が「完成品をコピーしてエディタへ反映させるだけ」になってしまっています。
これでは、クオリティの高い動くものが一瞬で出てきてしまうので、プログラミングを学んでいるから作れるのではなく、プロンプトのうまさに左右される要素になってきているなと感じています。

AIを初めて使った時の生徒の感想は「すごい！」がほとんどです。詰まっていたエラーを解決させることができたり、後一歩、、をサポートしてくれる時にはAIに本当にありがたみを感じますし、今後生徒たちが生きていく中ではAIを使っていくことが必須になることは間違いないので、中高生の年齢から最新のAI技術に触れていることも重要である。と理解をする反面、私の存在価値などについて現実を突きつけられる時間でもあります。

また、長くプログラミングを学習している生徒からすれば「今までの努力は・・・？」となってしまうのではと考えてうまく使わせることができないという葛藤もありました。

2022年ごろにChatGPTが話題になりだしたタイミングから今に至るまで、私は生徒にAIを使ってコーディングをさせる際には「できるだけ明確なプロンプトを書くこと」「動いた事実ではなく、”なぜ”動いたのか意識して自分の言葉で説明をしてもらう」を意識しています。

※ChatGPT等のAIツールは利用規約に則り、保護者の同意がない限りは生徒に使用させることはありません。

これ以外にも細かなことは山ほどありますが、書いていると終わらないのでこの辺りで技術面での6年間の振り返りを終わりにします。

生徒の実績

6年働いての振り返りなので、一応生徒の実績も出せるものは記載します。
前提として生徒の努力が実績の一番の理由ですし、私はあくまでも裏方です。

• N Code Labo教室内でのLT大会に出場🔥
• WWDC Swift Student Challenge 受賞

• アプリ甲子園2024年ファイナリスト
• アプリ甲子園2025年ファイナリスト

• N Code Laboを卒業して大学生になった後に、講師としてとしてN Code Laboに戻ってきてくれた

伏線回収的な感じになりますが、きっとコンテストで受賞した生徒は「人生が変わった」と思いますし、プログラミングを習う立場から教える立場になった元生徒も「人生が変わった」のかなと思っています。

何か実績を出したから。プログラミングで仕事を始めたから。だけが「人生が変わった」の基準ではないと思っていますし、卒業した後に生徒が「高校生の時にプログラミング習ってたけど、髙津って先生なんか面白かったな」と思い出してくれるだけでも、本人の人生に何かしら変化をもたらせたのかなと思って嬉しい気持ちになりますし、そうなる授業とは何か常に考えています。

今後目指していくところ

まとまりのない記事ですが、まとめていきます。

私は2019年7月 ~ 現在まで講師を続けています。正しく書けば「7年目」になります。
7年目になってくると、教室の中でわからないことはほぼないですし、歴だけであれば1,2番に長いです。

きっとこれからももっとAIは発展しますし、「プログラミング教室」が「AI・プログラミング教室」になる日も遠からずなのかもなと感じています。

だからこそ、「髙津」個人の人間性を磨くこと、そして実績が残せる生徒や一緒に働きたいと思ってくれる生徒を育てることはもちろん、日々AIとプログラミングをし、学習をすることで最新情報や最新の技術を伝えることができる状態であろうと思っています。

プログラミング教育はとても面白いです。自分のキャリアの中で見ても一番長く関わっている業界になりました。

そして、歴が長くなるにつれて慢心するのではなく変わらず生徒の成長に対して喜びを感じ、出迎え・見送ることができる教育者を引き続き目指していきます。

長くなりましたが、今後もN Code Laboをよろしくお願いいたします。

髙津