プログラミング初心者から脱却するための第一歩

背景

プログラミングを勉強した後、次に何をすればいいのか悩んでいる人をTwitterで見るので書きます。
偉そうなことを書いていますが、これは一般論ではなく、個人的な経験に基づいた記事です。

TL;DR

プログラミングの勉強が終わったら、ソフトウェアを実際に作って、作り方を学びましょう。

想定読者

・Progateをとりあえず終わらせた
・いわゆるプログラミングスクールを卒業したが、自信はない。次に何をすればいいのかわからない
・仕事ができるかわからない

「経験」の積み方

求人情報に書いてある「経験」、すなわち実務経験は、会社に入らない限り積めません。
しかしながら、経歴書に書けずとも、似たような経験は積むことができます。

まず40万円用意します。これはあなたの給与です。
1ヵ月で、ソースコードをコピペしたり、AIに頼ることなく、一人用Twitterを作ってください¹。

...できますか？

できないと思います。「一人用Twitterを作ってくれ」と言われても、それがどういうものかイメージするのも難しいですし、そのイメージが要求と合っているかもわかりません。

しかしながら、こういったことを要求されるのが仕事であり、やってきた時間が「経験」に変わります²。

反対に、「自分で曖昧なことを決めていき、物を決まった期限内に作る」ことは、仕事と同じようなものです。

ここまでの内容で、よっしゃやろう、と気合いが入った人向けに、少し曖昧なテーマをいくつか書いておきます。機能や、期限も自分で決め、取り組んでみてください。
期限に遅れそうなら、今どこまで終わっていて、あとどれくらいで終わりそうか、メモしておくとさらに良いでしょう（必須ではありません）。

・一人用Twitter
・アルバムソフト
・電卓
・単位換算ソフト
・ペイントソフト
・商品注文ソフト

どうやってソフトウェアを作っていくか

まず、ソフトウェアを作るという作業は、今まで学習してきた「プログラミング」とは全く違います。

あくまでも、ソフトウェアを作るという作業の中にプログラミングがあり、プログラミングがソフトウェアを作ることの全てではありません。

今までプログラミングを学んできたように、ソフトウェアの作り方も学ぶ必要があります。
では、ソフトウェアの作り方を説明しましょう。
上の図で示したように、ソフトウェアを作るには、（ソフトウェアの）設計に関する知識や、他のソフトウェアを利用する知識が必要です。

また、それとは別に、作りたいソフトウェア自体の知識、すなわち「自分が何を作りたいのかを知る・決める」ことが必要です。

何を作るのか知る・決める

作りたいものがない人は、上のリストから好きなもの、もしくはランダムに（Googleでrandom numberと検索すればいいです）選びましょう。

作りたいものが決まれば、最初に「極限まで機能をそぎ落としたもの」を考えます。

例えば電卓なら、1+1だけ計算する、でもいいですし、アルバムソフトなら（アルバムと言いながら）画像を決まった1枚だけ表示するでもいいです。それが難しければ、画像のパス（画像ファイルの場所）を表示する、だけでもいいでしょう。
単位換算ソフトなら、1ccを1mlに変換できる、だけでもいいんです。

そんな最小のソフトウェアを考えてください。
考え終わったら、ソフトウェアの理想形を考えます。

iPhoneの電卓と完全に同じものがいいでしょうか？最強の関数電卓を作る方がいいですか？
私にはあなたの作りたいものはわかりませんが、とにかく自分が作りたいもので、既にこの世界にあるものを探します。
自分が作りたいものとぴったり同じなものがなくても、似たものはあるでしょう。

似たものを探したら、自分が作る機能を全て書き出します。途中で機能を書き出すのが辛いと思ったら、「この機能は欲しいな」と思うものだけで構いません。
ここで作成したリストは保管しておきます。

さて、あと少しです！自分が作りたいもののイメージはかなり固まってきました。
でも、あなたはこのリストの機能を全て作るのは難しいです。

もちろん、「経験」を積むうちにできるようになっていきますが、このソフトウェアを1つ作る間に、全ての機能が実装できるようにはなりません。
そのため、自分が今ここで完成だと決めれば、それがソフトウェアの（一旦の）完成です。
この完成の地点は、先ほど考えた最小のソフトウェアと、今作ったリストの間にあってもいいのです。

最小のソフトウェアの実装から始め、リストにある機能を一つづつ実現していくことで、あなたは着実にソフトウェア・エンジニアとしての腕を上げていきます。

手戻りをできるだけ減らす

ここまでの内容で、ソフトウェアを作り、（たくさんの失敗をしながらも）技術を上げていく方法を説明しました。
この作業をしていく中で、「新しい機能を追加しようとすると、既存の機能を壊してしまったり、どんどんソースコードが長くなり、どこを変えれば機能を追加できるかわからなくなる」、そんな経験があったでしょうか？

これには原因があります。

・経験不足
・不適切な命名
・コメントの不足
・正しく動いてた状況に戻せない

などなど、実はほぼ無限に原因を書くことができます。
この問題を解決するために、何冊もの書籍が出ています³。

問題の完全な解決はできなくても、軽減はできます。
そのうちの一つは、きちんと記録を取っていくことです。

有名なのはGitでの記録でしょう。ソフトウェアを変更したとき、その差分を記録します（手動）。後から差分を確認し、場合によっては元に戻すことで、変更したときのリスクを減らします。
ここでは使い方の説明を割愛します。各自勉強してください。

他の原因も同様に、さまざまな軽減策があります。これは書籍や記事などで、どんどん学んでいくといいでしょう。

困ったときの情報の調べ方

機能を追加していく上で、つまづくことも多いでしょう。詰まる内容で多いのは、他のソフトウェアの使い方です。ループの書き方など、プログラミング言語に関する悩みは非常に少ないです。

「他のソフトウェア」というのは、例えばデータベース（○○SQLとか○○DBという名前のアレです）であったり、WindowsやLinuxなどのOS。他にはReactやRails、ffmpegなどのフレームワーク・ライブラリです。
さらに他にも学ぶ領域は多いですが、そのレベルに行く頃には学ぶ領域も見えているでしょう。

さて、典型的な詰まる例を紹介します。

1. ○○をしたいと思って検索します。

2. どうやら○○のためには○○がいいらしい、とわかりました。

3-a. 使い方が全くわからず、頑張って検索しても情報はなく、手詰まり。

3-b. 謎のエラーが出て、直す方法も書いておらず、手詰まり。

2の段階で間違えていることもあります（マイナーな技術を選択してしまうなど）が、基本的には3の段階で詰まります。
3-aの解決策は、書籍を買いましょう。無料の本ではなく、出版社が入っている本だとよいでしょう。大きな書店に行くのも良いです。
そもそも、悩んでいる理由は体系的な知識がないことなので、それを金の力で解決します。

3-bの解決策は、エラーメッセージから固有名詞を取り除き、検索することです。

しかし、日本語での書籍・情報がなかったり、極端に少ない場合もあります。そんな人のための、最強で無料の情報ソースを教えます。公式ドキュメントです。有名なソフトウェアであれば、たいていQuick StartやTutorialがあり、そこを起点に体系的な知識を得られます。
関数やクラスの説明も、リファレンス（Reference）があります。使い方の説明も載っていますし、親切なところならサンプルコードを載せている場合も多いです。

1に書籍、2に公式ドキュメント。この2つを駆使すれば、ほとんど問題ないです⁴。

ソフトウェアをいくつか作ったあと、何をするか

ソフトウェアをいくつか作ったあとは、苦戦しながらも、自分で考え、学び、ソフトウェアを完成させられる。そんな状態になっています。...ここでようやく、エンジニアとしての第一歩を踏み出したと言えます。

ここまで、これだけ頑張ってきて、まだ先があるのかと思われるでしょう。この先、ここまでの数倍ないし数十倍、数百倍学ぶことがあります。でも、基本は変わりません。文章を読み、自分か他人が書いたソースコードを読み、機能を追加する。先人が考えた便利な考え方、やり方を学び、実践する。ただそれだけです。
これを他人に強制されることなく自発的に行うようになると、いつの間にか隣には誰もおらず、自分が分野の最先端にいたり、全てをこなせるジェネラリストになっています。

では、次のソフトウェアを作りましょう。

1. 「ソースコードをコピペ」「AIに頼る」ことは、ソフトウェアを作る際に権利的な問題が発生することがあります。そのため、禁止される場合があります。 ↩

2. 実際に行う仕事は、もう少し明確なことが多いでしょう。しかしながら、不確定な部分があるものを作ることに変わりありません。コミュニケーションが重要な理由のうちの一つですが、コミュニケーション能力については記事の主旨に沿わないため、本文中では触れません。 ↩

3. ソースコード自体の可読性、設計、開発手法、マネジメントなどなど、様々な角度からソフトウェアの変更を容易にする試みと、その具体的な方法が書かれた書籍が出ています。すなわち、それだけ難しい問題だと言えます。 ↩

4. オープンソースソフトウェアであれば、ソースコードを直接読むのも情報収集として活用できます。これは3つめの選択肢になります。4つめは、この記事のような個人の記事に頼ることです。公式ドキュメントに比べて網羅性はない代わりに、同じレベルの人が書いた記事であれば、同じ詰まり方をするので解決できることが多いです。1つめを書籍としたのは、そのライブラリ・フレームワークを使う際の前提知識も網羅している場合もあるからです。最新の情報が載っていたり、正確な情報が載っているのは、やはり公式ドキュメントになります。翻訳ソフトに適宜頼りつつ、読んでいきましょう。 ↩