コーディング歴1年、swift歴3ヶ月の学生がtry! Swift Tokyo 2026 に飛び込んだ話

はじめに

この記事は私が初めて作成したものです！なので誤情報や、誤字脱字などありましたら申し訳ありません！！ぜひ温かい目で途中まででもいいので見ていってください。

私は大学で情報学を学び始め、その中で Swift Student Challenge(以下、SSC)に興味を持ちました。ちょうど3ヶ月ほど前からSwiftを学び始め、SSCにも実際に作品を提出しています。

SSCについて学び、経験を積むためにさまざまなAppleのイベントに参加する中で知ったのが、今回参加した「try! Swift」というカンファレンスです。

この記事では、そこで私が感じたこと・分かったこと・得た知識を整理し、「初心者の目線から見たカンファレンス」 を、できるだけ臨場感を持って伝えたいと思っています。この記事が誰かのカンファレンス参加のきっかけになり、これからも try! Swift が盛り上がっていくことを願って。ぜひ読んでいただけると嬉しいです。

初心者ならではの壁

参加に踏み切るまでに感じた、大きな壁の話をさせてください。

私はアパレル系でアルバイトをしていて、コミュニケーションには人より自信があるほうでした。それでも、慣れない地域への参加、しかも英語のレベルが低く会話すらままならないかもしれない国際カンファレンス。「そもそも、自分のような未熟者が、こんなすごい場所に一丁前に参加していいのか?」とも思いました。

大学に入るまで情報学すら知らなかった私からすると、自分でアプリケーションを作るなんて到底できないことです。私たち29卒の世代は、初めてのハッカソンの時点で、すでにAIにコーディングさせる習慣が本格的に普及していた、最初の世代なのかもしれません。そのぶん、自分の力だけで制作物を作る経験は、授業以外では珍しい機会になっています。

今の時代の学生は、

1. 自分の力を過信しすぎてしまう人
2. 逆に、自分にはまったく力がないと思い込んでしまう人
3. 特に何も感じていない人

——この3種類に分けられる気がします。実際に情報系のイベントに参加すると、積極的に動く優秀な学生エンジニアたちとの交流が生まれます。私自身もイベントには積極的に参加するほうなので、その中で何度も自分の力のなさを実感してきました。だからこそ、知らないことだらけの場所に行って何か成果を得られる、という自信がなかったのです。

それでも参加したいと思えた理由は、Swift Student Challengeに挑戦した経験と、「もっといろんなエンジニアの方々や技術に触れたい」という圧倒的な好奇心、そして恵まれた環境にありました。

私は、大学でできた友人にイベントの情報を伝え、興味を持ってくれた人を「一緒に行こう」と誘いました。普通なら、「え、東京?カンファレンス?難しいし金欠やからやめとくわ」「まだそんなん言っても何も分からんって(笑)」と言われそうなものです。でも幸いなことに、声をかけた全員が興味を持ってくれて、結果的に 合計10人 で参加することになりました。本当にありがたかったです。

実際に参加してみて

私は4/11〜4/14の合計4日間、現地で参加しました。日にちごとに分けてお話しします。

1日目:学生ハッカソン

1日目は、try! Swiftに併設された「try! Swift Tokyo 2026 ハッカソン for Students」に友人と参加しました。

関西の田舎住まいで、普段は山しか見ていない私。六本木ヒルズに来たのはこれで2回目でしたが、やっぱりあのスケールには圧倒されてしまいました。

ハッカソンでは、try! Swift本編にもつながる6種類のテーマが用意されていました。参加者は興味のあるテーマのテーブルに着席し、そこからランダムでチームが組まれる形式です。テーマは次の6つでした。

• 魅せるSwiftUI — 表現力の極限へ:SwiftUIの描画力・内部動作・最新デザインを駆使して、ビジュアル表現の限界に挑むカテゴリ
• 越境Swift — Appleの枠を飛び出せ:Swiftをモバイル以外へ持ち出す。クロスプラットフォーム・組み込み・IoTに挑戦するカテゴリ
• AI×Swift — 知性をアプリに宿す:Apple Intelligence・AIエージェント・テスト自動化など、AIとSwiftを融合させるカテゴリ
• Swift言語ハッカー — 深淵を覗く:Swiftの言語仕様・型システム・コンパイラの深淵を覗き込む、ディープなカテゴリ
• 堅牢なプロダクトを支える技術:プロダクトの品質と開発効率を高める、堅実な実装・運用ノウハウのカテゴリ
• 輝くアプリのデザイン×ビジネス:ユーザー体験・アクセシビリティ・ビジネス戦略を磨き上げるカテゴリ

私はAIに強い興味があったので、「AI×Swift — 知性をアプリに宿す」のチームを選びました。そして気づけば私は、多国籍で経験豊富なメンバーが集まるチームのリーダー(PM)を務めることに。チームメイトは3回生や大学院生の方々で、技術面では何度もリードしてもらえました。

私たちが考えたのは、日常の何気ないポーズを撮影して、AIで漫画のワンシーンのように変換するアプリ「まんがる」です。

衝撃だったのは、ワンデイハッカソンならではの開発時間の短さ。なんと、開発はわずか 3時間。正直、ハゲそうでした(笑)。さらにメンター陣が恐ろしいほど豪華で、主催のメルカリ様、MIXI様、pixiv様、サイボウズ様のエンジニアの方々、そしてApple Japanのエバンジェリストの方々など普通に学生をしていたら絶対に出会えないような人たちが、参加者より多いのではと思うほどいて、ひたすらビビっていました。

「技術的にすごいだけ」の罠

優秀なエンジニアが揃っていたこともあり、最初チームは熱狂していました。「最新のAR技術を駆使して、空間に漫画のエフェクトを立体的に出そう!」と。今振り返れば、完全に 手段が目的化 していたのだと思います。

案の定、開発中盤で高度なAR実装の壁にぶつかり、プロジェクトは著しく停滞。3時間しかないのに、です。このとき私は強烈な違和感を覚えました。

このままでは、ただ「技術的にすごいだけの未完成なデモ」で終わってしまう。私たちが本当に作りたかったものは、なんだっけ?

思考を切り替える ——「技術の引き算」

ユーザーが求めているのは、高度なAR技術じゃない。友達の変なポーズを見て、一緒に笑い合える「コミュニケーションの体験(UX)」 のはずだ。そう考え直し、私はチームに方針転換(ピボット)を提案しました。

• 技術の引き算(Less is More):ARを潔く捨てる。代わりに、実装リスクが低く確実に動く「2D画像の切り抜き + 生成AIによる背景・セリフ合成」へと技術要件をダウングレードしました。
• 体験(UX)の再定義:技術を下げた分、体験の質に全振り。「AIがいかに絶妙で、クスッと笑えるセリフ(吹き出し)を自動生成するか」というコア体験に、残りのリソースを集中させました。

ここで、技術的な壁にも一つ当たりました。セリフ生成を担っていたのが Apple Intelligence の FoundationModels framework(端末上で動くローカルLLM)だったのですが、このモデルには扱えるトークン数(コンテキスト長)に上限があります。背景もセリフも欲張ってすべてLLMに任せようとすると、その上限に引っかかってしまう。そこで LLMの役割を「短くて笑えるセリフの生成」一点に絞り、背景は別の手段に任せるという割り切りも、この「引き算」の一部でした。

FoundationModels framework は、端末上で動作する テキスト生成のローカルLLM です(画像生成そのものは Image Playground / ImageCreator などが担当します)。「LLMに何でもやらせる」のではなく、得意なタスクに絞って使う 設計が、限られた制約の中では効いてきます。

最後はチームの合意形成です。「せっかくのハッカソンだから妥協はしたくない」というチームの気持ちも、もちろんありました。それでも、一番ユーザーの感情を動かすプロダクトこそが、本当に作りたいもの。技術をシンプルにして、最高の笑いを取りにいこうそう決断しました。

結果:MIXI特別賞

この決断で開発スピードは劇的に加速し、時間内に最高のプロトタイプが完成しました。また、プレゼンは私が担当しました。準備時間はわずか5分。Canvaのテンプレートで一瞬でスライドを作り、ぶっつけ本番で臨みました。発表は最大3分のところ、アプリのデモも十分に見せて、ちょうど3分で終えられた。そして結果は——コミュニケーションの創出を企業理念に掲げる株式会社MIXI様から、特別賞。審査員の方には、まさに私たちが狙いすました「人を笑顔にする直感的なUX」を高く評価していただけました。

このハッカソンで得た教訓は、シンプルです。技術は目的ではなく、手段。 何を作りたかったのかさえ見失わなければ、技術は引き算してもいい。むしろ、引き算する勇気こそが、ものづくりを前に進めるのだと知りました。

2日目:本編スタート ——「Foundation Modelsでアプリを強化する」ワークショップ

2日目は、いよいよtry! Swiftの本編が始まる日。私は 「Foundation Modelsでアプリを強化する(Enhance your app with Foundation Models)」 というワークショップに参加しました。登壇は Shun Takeshi さん、Alberto Ricci さん、Melvin Tan さん。全員がAppleのテクノロジーエバンジェリストという、とても豪華な顔ぶれでした。

正直に白状すると——まだまだSwiftの知識が浅く、基礎すら不安なレベルで臨んだ私には、実装パートに完全についていくことはできませんでした。それでも、「最高のワークショップだった」と胸を張って言えます。理由は2つあります。

ひとつは、サポートの手厚さ。分からなくなって手が止まっても、後ろに控えたメンターの方々がすぐ来てくれる。飲み物も後ろに用意されている。「終わらなくても大丈夫、パニックにならないで」という空気が、最初から作られていました。

もうひとつは、内容そのもの。実際にAIを使って仕事をされているエバンジェリストの方々が、トークンをどう節約するかといった話を、システムの側面から細かく解説してくれたんです。どんなレベルの人が聞いてもためになる、そんな構成でした。

ワークショップで学んだこと(初心者なりの整理)

せっかくなので、自分の理解の整理も兼ねて、内容をまとめておきます。

Foundation Models とは
WWDC25で登場したフレームワークで、Apple Intelligenceと同じ オンデバイスのLLM に、自分のアプリから直接アクセスできるものです。オンデバイスで動くため、データが外に出ず(プライバシー)、オフラインでも使え、利用料もかからず、アプリの容量も膨らみません。基本は「テキストを入れて、テキストが返る」というシンプルな仕組みです。

ワークショップの題材
会議の議事録アプリ「FM Sample App」に、3つの機能を実装していく流れでした。

1. 録音した内容から、タイトルとイメージ画像を生成する
2. 議事録から「誰が・いつまでに・何を」のToDo/タイムラインを抽出する
3. 蓄積した内容について質問できるQ&A

各タスクは「説明 → 20分のハンズオン → Albertoさんが実装をライブコーディングで解説」を繰り返す形式。手で書いてもCodexやClaude Codeを使ってもOK、という今どきの進め方でした。

ここが核心:オンデバイスならではの制約
サーバーサイドのLLM(パラメータ1000億超)と違い、Foundation Modelsは約30億パラメータと小さく、コンテキストは4,096トークンしかありません。だから、サーバー向けの感覚で長く冗長なプロンプトを書くと、すぐ限界に当たってしまいます。

ここで、まさに 前日のハッカソンで私がぶつかった壁の正体 が分かりました。英語は2〜3文字で1トークン程度に圧縮されますが、日本語・中国語・韓国語は、ほぼ1文字=1トークン。つまり、指示やプロンプトを日本語で書くだけでトークンを浪費してしまうのです。対策はシンプルで、指示(instructions)は英語で書き、「Please answer in Japanese.」のように出力する言語だけ指定する。

画像生成は Foundation Models の担当ではありません(あくまでテキスト専用)。画像は Image Playground / ImageCreator が担当します。議事録 → Foundation Models で「絵にする概念」を生成 → ImageCreator で画像化、というように フレームワークを組み合わせて 使うのがポイントでした。

印象に残ったプロンプティングのテクニック

• 指示はできる限り短く、1文で。複雑な「〜して、〜して」は避ける。
• 条件分岐(if/else)はプロンプトに書かず、コード側で先に分岐してから、その条件に合ったプロンプトだけを渡す。LLMに考えさせる量を減らす。
• LLMは「もちろんです、こちらが…」のような余計な前置きを付けがち。@Generable で出力する型を定義し、意味のあるプロパティ名を付けると、狙った値だけがきれいに返る(text01 のような名前は混乱のもと)。
• 余計な説明を吐き出させたいときは、UIで使わない reasoning のようなプロパティを用意して“逃がす”と、本命の値が汚れない。
• 細かく説明するより、出力例(few-shot)をいくつか渡すほうが効くことが多い。ただし「この例の内容はコピーしないで」と明示する。
• 結果は ストリーミングで受け取り、生成の途中から表示するとUXが良くなる。
• プロンプトをいちいちビルドして試さなくても、Xcode 26の #Playground マクロで結果を即確認でき、反復が速い。

前日、「FoundationModelsのトークン上限で背景生成が思うようにいかなかった」と書きました。その答え合わせを、翌日にエバンジェリストの方から直接もらえる。参加してよかったと、心から思えた瞬間でした。

3日目:本編のセッション

本編のトークセッションは、正直に言うと、今の私には難しすぎました。世界中から集まった登壇者が、コンパイラの型理論や、巨大なレガシーコードの運用、テキスト描画の深淵といった話を、当たり前のように語っていく。動画を何度も見返して、ようやく「たぶんこういうことかな」と輪郭がつかめたくらいで、正直まだ理解しきれていません。

でも、それでよかったと思っています。「Swiftの世界は、こんなにも広くて深いのか」 と打ちのめされる感覚そのものが、参加の価値でした。ここでは、今の自分なりに「面白い」「いつか分かるようになりたい」と思えたセッションをいくつか紹介します。

Lil Ossa「Living with Genmoji」

WWDC24で登場したGenmoji(プロンプトや写真から自分だけの絵文字を作る機能)を、サードパーティアプリに組み込むハックの話。標準UIの ImagePlaygroundSheet にはGenmojiスタイルが出てこないので、ImageCreator から availableStyles をフィルタして“隠しスタイル”を引き出す、という攻め方が痛快でした。

特に刺さったのが、エラー回避のテクニック。プロンプトに「男」「私」など人を指す言葉が入ると Concept requires person identity で弾かれてしまうので、間に Foundation Models(LLM)を挟んで、人物への言及を取り除いた絵文字向けのプロンプトに“浄化”してから渡す、という発想です。これ、Day 1・Day 2でさんざん向き合った Foundation Models と ImageCreator の組み合わせそのもので、「自分が触っていた技術って、こう使うのか!」と一気に視界が開けました。

Nishant Bhasin「Open Source at Scale」

Mozillaのエンジニアリングマネージャーが語る、Firefox iOS(10年以上続く巨大なレガシーコード)の運用と、個人がOSSに貢献する方法。リポジトリをフォークして「Good First Issue」を探し、コメントで宣言してから直すという最初の一歩を、その場でターミナルを開いてライブでPull Requestを作り、マージするところまで見せてくれました。

中でも、PRを何度もクローズされてもめげずに貢献を続け、ある機能を実装し、最終的にMozillaのフルタイム社員になった参加者の話。「最初は誰でも初心者なんだ」という事実を、これ以上ない形で見せてもらった気がします。

Klemens Strasser「The Art of Caring」

Apple Design Award受賞のインディー開発者が語る、アクセシビリティ・ユーザーサポート・そして開発者自身のケアの話。「アクセシブルにできないアイデアはボツにする」という基準で、視覚的なパズルを、視覚障がいのある人も遊べるテキストモードに作り替えたエピソードが印象的でした。

星1レビューに定型文ではなく人間味のある返信をすると半分くらいが消えるか星5に変わる、という生々しい話や、会社員時代に無理をして健康を害した経験から「休むことが一番いいアイデアを生む」と語る姿に、技術以前の“ものづくりへの姿勢”を教わりました。

Joannis Orlandos「Swift Outside Apple」

Swiftはもう、Appleのエコシステムの中だけのものじゃない、という話。Androidでネイティブに動かす、WebAssemblyでブラウザ上で動かす(iOSアプリ「GoodNotes」のWeb版という実例)、Linuxのサーバーサイド(iCloudでも採用、すでに10年の歴史)、Windowsや組み込み機器(ESP32やRaspberry Pi)までSwiftの“射程”の広さに、ただただワクワクしました。「Swiftを武器にする」と決めた自分にとって、これは大きな希望でした。

そのほか、刺激をもらったセッション

理解はまだ追いついていませんが、忘れないようにメモとして残しておきます。

• matsuji「Polishing Liquid Glass」:iOS 18以降の新UIで、狭い画面だとツールバーのボタンが「Moreメニュー」に自動で畳まれるときの実装Tips。アイコンだけのボタンでも title を省略しない、カスタムビューには menuRepresentation を設定する、など。
• Ryo Tsuzukihashi「GeoJSON × SwiftUI」:市町村の実際の地形に合わせて写真を切り抜き、地図に埋め込む表現を、GeoJSONとSwiftUIの Path・マスクで実装した話。手作業の微調整からデータドリブンへの転換が見事でした。
• Yasuhiro Inami「Swift Concurrency Type System」:@MainActor などの「Capability(どこで実行するか)」と、Swift 6のRegion-based Isolationによる「Region(値がどこにあるか)」という2軸で並行処理を捉える、型理論レベルのディープダイブ。……正直、一番ついていけませんでした(笑)。
• Wataru Nishimoto「Furigana Deep Dive!」:ふりがな(ルビ)の描画。UIKitは CoreText の CTRubyAnnotation、SwiftUIはiOS 17の TextRenderer でフックする、という地味だけど奥深い世界。
• Satsuki Hashiba「Beyond Translation」:単語の翻訳を超えたローカライズ。FormatStyle で日付・通貨・人名の順序をユーザーのLocaleに合わせる、RTL言語のために leading/trailing を使う、など「Feel at home」を作るための配慮。

英語のセッションも多くありましたが、try! Swiftにはリアルタイム翻訳の仕組みも用意されていて、初心者でも置いていかれにくい工夫がされていました。

そして夜は、ビーチサイドパーティへ

3日目の夜には、ビーチの近くでパーティが開かれました。DJがいて、美味しいお肉やご飯がたくさんあって、世界中のエンジニアたちが一堂に会して楽しむ、あんな空間は、人生で初めての体験でした。

そこで生まれる交流から、コミュニティが広がっていく。海外のエンジニアの方々と知り合える、本当に貴重な機会でした。ここで、英語に不安がある人にこそ伝えたいことがあります。スピーキングに自信がなくても、大丈夫。みんな、自分が思っているよりずっと優しいし、こちらの話を聞こうとしてくれます。あとは、その場のノリと“出川イングリッシュ”で何とかなります(笑)。

交流のきっかけは、夜だけではありません。セッション中も休憩時間も、会場では企業のブースが開かれていて、ガチャガチャや抽選など各社が用意してくれた企画を体験しながら、その会社を深く知り、いろんな質問ができます。日中のブースで話が弾んだ方とは、夜のパーティでさらにじっくり。「今の自分がやるべきこと」「将来に向けてやっておくべきこと」を、たくさん、優しく噛み砕いて教えてくださいました。

明けて最終日。4日目も、朝から濃密なトークが続きます。

4日目:最終日

最終日は、さらにバラエティ豊かなトークが並びました。型システムでマージャンの役を判定しようとする挑戦から、お金をかけずに組み込みSwiftを始める方法、AIエージェント時代にSwiftの型が効いてくるという話まで。ここでも、特に印象に残ったものを紹介します。

Paul Hudson「Why is SwiftUI like that?」

「Hacking with Swift」で知られる、Swift学習者なら一度はお世話になる教育者Paul Hudsonさん。テーマは「SwiftUIはなぜ、ああいう挙動をするのか」。「親がサイズを提案し、子が自分のサイズを決め、親が配置する」というレイアウトの3ステップや、if/switch がコンパイル時に _ConditionalContent というツリーに変換される「構造的アイデンティティ」の話など、普段なんとなく書いているSwiftUIの“裏側”を見せてもらえました。@ViewBuilder 内の条件分岐を三項演算子に置き換えるとアニメーションが滑らかになる、という実用Tipsまで。憧れの著者の話を生で聴けたのは、それだけで震えました。

Shinichiro Oba「Getting Started with Embedded Swift Programming from ¥0」

「ハードを持っていなくても、0円で組み込みSwiftを始められる」という、私のような初心者に一番ありがたい話。ブラウザ上でRaspberry Pi PicoやESP32をエミュレートできる「Wokwi」を使えば、はんだ付けも実機もいらず、手元のMacだけで試せるとのこと。実機もRP2040やESP32-C6なら1,000円前後。「お金も技術も足りない」と思い込んでいた自分の言い訳が、ひとつ消えた瞬間でした。

Yuta Koshizawa「How Swift's Type System Guides AI Agents」

AIが自分でコードを書き、コンパイルし、エラーを直す「AIエージェント」の時代に、言語の型システムがAIの性能をどう左右するか、という検証。Swiftは関数宣言に throws が現れるので、AIはシグネチャを見ただけでエラー処理の要否を正しく判断できる。一方TypeScriptでは判断できず、見落としたり、厳密に追わせるとトークン消費が跳ね上がるというデータが示されました。コンパイラの厳格なフィードバックが、AIを正しい実装へ導くガイドになる。AIにコードを書かせるのが当たり前の世代として、「だからSwiftなのか」と腑に落ちる話でした。

そのほか、刺激をもらったセッション

• Daniel Steinberg「The hidden power of Async Sequences」:25年分のAppleの「通知」の歴史(Selector → Blocks → Combine)をたどり、AsyncSequence と for await でイベントを美しく扱う話。Sendableな値型の「Async Message」でアクター境界を安全に越える設計が鮮やかでした。
• freddi「Hacking Final Cut Pro with Swift」:旅行動画の字幕付けを自動化。Final Cut Proの限界をFCPXMLの書き換えで突破し、Speechフレームワークの文字起こしを字幕として流し込むmacOSアプリを自作。「Swiftは創造性を拡張する道具」という言葉が刺さりました。
• kishikawa katsumi「Bare-Metal Programming with Embedded Swift」:OSのないRaspberry Pi Picoで、ブートローダーからメモリ初期化までをC言語ゼロ・Swift100%で実装する話。@_section や Volatile など、普段触らない最下層の世界。
• Kazushi Oenoki「Practical CRDT」:複数端末の同期でデータが消えるコンフリクトを防ぐ「CRDT」を、Core DataとCloudKitで実用化。1文字ごとにIDやタイムスタンプを持たせ、3,000件ずつチャンク化してCloudKitの制約を回避する工夫が見事。
• Natalia Panferova「The Evolution of SwiftUI」:元AppleのSwiftUIチームの視点から、NavigationStack や @Observable がなぜ生まれたのか、その設計の裏側を解説。
• giginet「Play 🀄 on swiftc!」:Swiftの型システムだけで麻雀の役判定に挑む怪作。Integer Generic ParametersやUnion Typesの壁にぶつかり、最終的にSwift Macrosで“コンパイル時に”アガリ判定を実現。発想が痛快でした。
• Yusuke Kita「Let AI Generate XCUITest Code」:AIがテストコードで存在しないIDを捏造する問題を、プロンプトではなくコンテキストの構造化(IR・辞書・テンプレートの3層)で解決。AIにも人間にも効く「信頼できる唯一の情報源」の作り方。
• Akira Fukunaga「Zero-Downtime Migration」:14年・50万行の巨大アプリを、開発を止めずにCocoaPods → SPM + Tuistへ、たった2人で移行した話。自作ツールとCIのガードレールで無事故移行を達成。
• Adam Lyttle「Designing App Store Onboarding」:課金率を跳ね上げるオンボーディング設計を心理学から解説。「水族館のギフトショップ理論」「Shark Tank Moment」など、技術とは別ベクトルで面白かった一本。

英語のセッションだらけで、分からないことは相変わらず山ほどありました。でもいや、だからこそ、「いつかこの場所で戦えるようになりたい」と本気で思えたんです。最初にあった「自分なんかが参加していいのか」という気後れは、4日間を終えるころには「もっと知りたい」に変わっていました。

おわりに

正直に言うと、参加前の私は不安だらけでした。英語も、技術力も、「自分なんかが行っていいのか」という気後れも。

でも、飛び込んでみて分かったのは、カンファレンスは「すごい人だけのもの」ではない ということです。分からないことだらけでも、その場には壁打ちに付き合ってくれるメンターがいて、一緒に悩んでくれる仲間がいて、何より「やってみたい」という好奇心が一番のパスポートになります。

もしあなたが、かつての私と同じように迷っているならぜひ一歩、踏み出してみてください。その一歩の先で、まさかMIXI特別賞をいただけるなんて、私自身まったく想像していませんでした。

そして、もし「セッションが難しくてついていけなかったらどうしよう」と不安なら、それも心配いりません。講義の内容は後日YouTubeにアップされるので、家でゆっくり、じっくり復習できます。だから現場では、すべてを理解することよりも、そこで感じる興奮と熱狂を全身で浴びることに意味があるのだと思います。

私は、あの会場で受け取ったエネルギーとやる気を燃料に、奥深くて、どこまでも面白いSwiftの世界に、これからもっと熱中していきます。この記事が、あなたの「参加してみようかな」の背中を、少しでも押せたら嬉しいです。