プログラミングは「作りながら」が最強 - 未経験から2週間でアプリをリリースした学習法
こんにちは、Matzです。フリーランスでUI/UXデザイナーをやりながら個人開発でアプリを作っています。
さて、今回は「プログラミング学習」について書こうと思います。
少し自分の話をすると、2023年の10月から全くの未経験でSwiftの勉強を始めて約1年が経ちました。勉強を始めて2週間で体重管理アプリをリリースし、さらに2024年の6月に料理アプリをリリースしました。
料理アプリの方は以下でもリリースエントリーとして記事を書いているので良かったら読んでください。
そして現在、3つめのアプリを2024年中にリリースできるペースで開発しています。
2つめのアプリは開発に7ヶ月ほど掛かりましたが、今回のアプリは、同じくらいの複雑さにも関わらず、約3ヶ月ほどで実装できそうなので、自分としてもかなり成長を感じています。
そんな自分が、効率良く、かつ楽しくプログラミングスキルを身につける方法について「これしかねぇ！」という確信が持てるようになったので書き留めたいと思います。
モチベーション
「プログラミングの学習方法」なんてものは、多くの先輩エンジニアによって語り尽くされています。
それがわかっていてなぜ、経験の浅い私がこれを書くのか？
それは、今まさに成長を実感している人間だからこそ語れることがあるからです。ベテランエンジニアは、初学者の頃の生々しい記憶が薄れているかもしれません。でも私はつい最近まで全くの初心者で、今この瞬間も成長の真っ只中にいます（自分で言っていくストロングスタイル）。
特に注目してほしいのは、多くの記事で語られる「効率の良さ」に加えて、「かつ楽しく」という視点です。これは語られることが少ないです。
はっきり言って、楽しめる人は最強です。
プログラミングを楽しむことができれば、勉強を「勉強」と思わずのめり込むことができ、みるみる技術力は高まっていきます。当然、アウトプットの質・スピードが上がり、周りからも高い評価がもらえるでしょう。
会社の研修や、チームの勉強会やらで仕方なく「勉強するかぁ😩」という人が勝てるわけありません。
これを読む人には、ぜひプログラミングを楽しめるようになってほしい、これが本記事を書く私のモチベーションです。
この記事は主にエンジニア志望の方や、駆け出しエンジニアの方を対象としています。
これを読むことで、あなたは効率が良いだけでなく、同時にプログラミングが好きになれる方法を知ることができます。
では、はじめましょう。
結論
さっそく結論から言うと、プログラミングを楽しく・効率よく身につける方法は「分厚い技術書による勉強を今すぐやめて、とにかくアプリや動くものを作ること」です。
で、出たー！「とにかく作れ」って言うやつー！！
あなたもそう思いましたか？そのとおりです。
「また同じことを...🤔」という反応も当然です。もし驚天動地、一発ツモ裏ドラ、一子相伝、アバンストラッシュのような方法を期待していたなら、申し訳ありません。
ここで少し立ち止まって考えてみましょう。
この「とにかく作る」という方法は、たしかによく耳にする助言です。でも不思議なことに、なぜか多くの人はこの方法を実践できていません。
その理由は明確です。きっとあなたもそうでしょう。
多くの人は学校教育で染み付いた「勉強の仕方」から抜け出せていないのです。つまり、教科書（技術書）を最初から順番に読んで、体系的に理解してから実践しようとします。
私も最初はそうでした。真面目に技術書を買い込んで、「基礎からしっかり学ばないと」と思い込んでいました。会社の研修なども同じで、なぜか基本情報技術者試験の勉強からスタートしたり、その前段階となるコンピュータサイエンスの基礎から教えたりします。
でも、これは大きな間違いでした。
私は1年間の経験を通じて、断言できます。
効率良くかつ楽しくプログラミングを身につけるには「とにかく作る」これ以外にありません。
なぜそう言えるのか？
私の経験から、「とにかく作る」ことが最良の学習方法だと確信できる理由が4つあります。
1. 本当に必要な知識は20%程度だから
パレートの法則って知っていますか？
パレートの法則とは「特定の要素20%が全体の80%の成果を生み出している」という法則です。例えば、成績上位20%の営業マンが、売上全体の80%を生み出しているようなものです。
実はプログラミングにもこの法則が当てはまります。
実際のアプリ開発では、技術書に書かれている知識のたった20%程度で、必要な機能の80%を実装することができるのです。
もちろん20%というのはあくまで目安で、多少のブレはあるでしょう。アプリの機能の複雑さや、チームにおけるあなたの役割に応じて、求められる知識は変わります。
しかし、あなたがプログラミング入門者や駆け出しエンジニアなら、この法則はピタリと当てはまります。
だから、あなたが最初にやるべきは分厚い技術書を開くことではありません。
本当に必要な知識は、実際の開発を通じて自然と見えてきます。
2. 必要なときに調べると理解が深まるから
「遅延評価学習法」という言葉を知っていますか？
これは、けんすうさんのブログで有名になった考え方で「必要なことは必要なときに必要な分だけ勉強する」というものです。
学校教育の「体系的に理解してから実践」という方針とは真逆の、アウトプット重視の学習法です。
自分も「遅延評価学習法」の考え方には全面的に賛成です。なぜなら、こっちの方が圧倒的に理解度が高いからです。
アプリを作っていると、さまざまな問題に直面します。たとえば以下のツイート。データベースに保存したレシピデータをアプリに表示する、という一見単純な機能を実装するのに3日もかかりました。
バックエンドの知識皆無なので、Supabaseからデータ取得して表示するだけでめっちゃ苦労した。テーブル作成時にデフォでRSLが有効になってるから、RSLでデータ取得を許可しないとデータ表示すらできないらしい。おかげでRSL完全に理解した。 pic.twitter.com/6t9UV3EpV4
— Matz | nanitabe開発者 (@Matz_Tak) October 22, 2023
「データの表示」という基本中の基本の機能すら実装できず苦労しました。でも、アプリを完成させるために絶対に必要な機能だったからこそ、必死で調べ、深く理解することができたんです。
もし同じ内容を技術書で読んでいただけなら、きっと今頃は忘れていたでしょう。なぜなら、切実な必要性がないからです。
逆に言えば、目の前で必要に迫られていることこそが、最高の学習モチベーションになります。そして、苦労して実装できた時の「できた！」という喜びは、技術書を読むことでは決して得られません。
3. 目に見える成果によって達成感を得やすいから
プログラミング学習において、モチベーションを維持することは誰にとっても大きな課題です。
ここでも「とにかく作る」アプローチの強みが光ります。
例えば、私が最初に作った体重管理アプリでの話です。画面にテキストを表示するだけのところから始めて、少しずつ機能を追加していきました。
入力した体重がリアルタイムで反映される
データが端末に保存される
UIが整っていく
これらの変化は、すべて目で見て確認できる成果です。小さな進歩の一つ一つが、「プログラミングができるようになっている」という実感につながります。
対して、技術書での学習はどうでしょう？
確かに章を読み終えるごとに達成感は得られます。でも、それは「読んだ」という達成感であって、「作れた」という達成感ではありません。
プログラミングという技術は、究極的には何かを作るための手段です。だからこそ、実際に「作れた」という経験が、次の学習への最強の推進力となります。
私の場合、最初のアプリで味わった小さな成功体験が、2つ目のアプリ開発へのモチベーションとなり、そして今、3つ目のアプリを開発するまでの原動力となっています。
このように、目に見える形で進捗を実感できることが、プログラミング学習を継続的で楽しいものにしてくれるのです。
4. 成果物があると他人に評価されやすいから
プログラミング学習において、意外と見落とされがちなのが「他者からの評価」の重要性です。これは個人としての成長だけでなく、会社でのキャリアにも大きく影響します。
自分の経験を話します。
料理アプリ「nanitabe」をリリースした時のことです。App Storeでリリースした後、Xで開発者としてアプリを宣伝しました。
正直、反応があるとは思っていませんでした。しかし、予想に反して：
「UIがシンプルで使いやすい！」
「初めてのアプリとは思えないクオリティ！」
「こういう機能も欲しい！」 など
たくさんの反応やフィードバックをいただきました。中にはエンジニアの方からの技術的なアドバイスもあり、そこから新しい知識を得ることもできました。
この経験は私に大きな自信を与えてくれました。
技術書を読破したところで、誰かに評価してもらえる機会はありません。どんなに基礎を学んでも、それを活かして何かを作らなければ、他者からのフィードバックは得られないのです。
また、会社では「技術書をどれだけ読んだか」ではなく、「何が作れるか」が評価されます。個人開発の実績があれば、あなたの技術力は目に見える形で証明されます。実際、多くのエンジニアの方から「転職時は個人開発の経験が強みになった」という話を聞きます。
逆に、たとえ完璧ではなくても、動くものを作って公開することで：
「すごい！」「よく作った！」という純粋な賞賛
「UIがきれい」「使いやすい」というアプリに対する評価
技術的なフィードバック
機能面での要望
デザインについてのアドバイス
バグの報告 など
さまざまな形での評価を得ることができます。
特に心強いのは、多くの先輩エンジニアが「作ったものを見せてくれ」というスタンスを持っていることです。彼らは完璧なコードを書けなくても、まずは作って公開する勇気を評価してくれます。
実際、私も最初のアプリは決して良いコードではありませんでした。でも、その段階で公開したからこそ、多くの方から改善のアドバイスをもらうことができ、それが次のアプリでの大きな成長につながりました。
つまり、成果物を作って公開することは：
自分の成長を可視化できる
具体的なフィードバックが得られる
次の成長へのヒントが得られる
コミュニティとの繋がりが生まれる
会社やキャリアでの強みになる
という、プログラミング学習において極めて重要な要素を含んでいるのです。
補足：技術書の価値について
本記事では「とにかく作る」ことの重要性を強調して説明するために、あえて技術書と対比する形で書きましたが、誤解のないように補足させてください。
技術書に書かれている内容は非常に重要です。プログラミングの奥深さや、より良いコードを書くための知識は、技術書から得られることが多いです。実際、私も今では技術書から多くのことを学んでいます。
今回伝えたかったのは、「楽しむこと」が最も重要だということです。そして、その楽しさこそが最大の効率化につながるということです。
多くの人にとって、プログラミング学習の初期段階で分厚い技術書を頭から読み進めることは、かなり退屈な作業になりがちです。その結果、モチベーションが低下し、学習自体が停滞してしまうことがあります。
重要なのは「タイミング」なのです。
例えば：
アプリ開発中に「もっと効率の良い書き方があるはずだ」と感じたとき
実装した機能の背景にある理論が気になったとき
より良いアーキテクチャについて考え始めたとき
こういったタイミングで技術書を開くと、その内容が格段に身になります。なぜなら、すでに実践での経験があり、具体的な文脈の中でその知識を理解できるからです。
つまり、本記事で提案しているのは「技術書を否定する」ということではなく、「プログラミングはあくまで手段であることを自覚し、作ることを楽しむこと」「技術書を読むタイミングを工夫すること」なのです。
プログラミングの学習に、これが絶対に正しいという方法はありません。でも、少なくとも私の経験からは、「とにかく作って楽しむ」というアプローチが、技術書の内容を真に理解することにもつながった、と確信を持って言えます。
さいごに
あなたの目の前に、まだ読んでいない技術書が積まれているかもしれません。
でも今日は、その技術書をいったん脇に置いて、「作りたいもの」を考えてみませんか？
最後までお読みいただきありがとうございました！