新人の開発者が繰り返し突き当たるテーマがあります。プログラム言語を1～2種類勉強するのに時間を費やしたり、プログラミングの演習を行ったりすることに関して問題はないと感じていても、学んだことをどう応用していいのか分からずにいるのです。このことは、次のようなフレーズとしてよく耳にします。「プログラムの書き方は知っているが、何をプログラムしていいのか分からない」と。これに対する答えは、一般的に、「プログラミングの課題を行いなさい」、「オープンソースプロジェクトに貢献しなさい」、または、「ゲームを作りなさい」というようなものです。

プログラミングの課題を行うことは、知的ないい訓練にはなります。しかし新しいプログラムの開発方法を学ぶのにはあまり役立ちません。オープンソースプロジェクトに貢献するのは確かにステップアップになります。実際のプロジェクトがどのように構成されているか学び、プログラム言語の技術も向上できるでしょう。しかし、プロジェクトの全ライフサイクルについてはそれほど学ぶことはできないでしょう。また、プロジェクトの中には複雑すぎて初心者にとって脅威的なものもあります。ゲームを作ることもステップアップになります。ゲームは楽しいですよ。私はQBASICでゲームのプログラミングを始めました。しかし、そのうち同様のジレンマが生じてきます。「ゲームを作りたいけど、どんなゲームを作ればいいのだろう？　」と。

私はプログラムの他に音楽も教えているのですが、音楽を学ぶ学生に関しても同じようなパターンを認識しています。「すべてのコードを知っているし、手は滑らかに動く、だけど、曲の書き方を知らない」と。音楽に関していえば、実は適切な答え、創造することを学ぶための道筋があります。音楽家は普通、最初から自分の作曲をしたりはしません。自分の曲を作曲するところまで発展すること なく 、一生他の人の曲を演奏し続ける音楽家もいます。プログラムの世界では、この考え方は少し異なります。

ソフトウェアのコミュニティでの一般的な姿勢は、「車輪を再発明するな」ということです。成熟して安定したオプションが存在するのにライブラリを書き直したら、眉をひそめられることでしょう。一般的に言ってこれは良いルールではありますが、初心者に関して言えば、車輪を再発明することを恐れるべきではありません。学習や練習のために行うなら、車輪を作ることは完全にオーケーで、重要な学びの一部です。例えば、あなたの独自のバージョンのls、mv、wget、またはcowsayなどを書いてみてください。ゲームの道を目指すなら、PongやTetris、Space Invadersなどのクローンを作ってみましょう。まったく同じ機能を持たせる必要はないし、完全なレプリカである必要もありません。ただ、自分の目標を持ち白紙からスタートし、達成しましょう。

プログラムを書く前から、過去最高のアイデアを考え出さなくてはなどという意気込みを持たないようにしましょう。音楽家にも似たような傾向を見たことがあります。最初の試みで偉大な傑作を作ろうとし、すべてのエネルギーを1曲に注ぎ込むけれども、大局を見ていないというような姿勢です。大局とはつまり、あなたは1曲だけでなく、時と共にたくさんの曲を書くだろうということです。最初に書いた曲は出来が悪いはずで、多分捨てられてしまうでしょう。それでいいのです。最初の試みで、素晴らしい、伝説に残る、驚愕するような傑作を作ろうとは思わないでください。作曲のプロセスを学び、自分の経験から学び、毎週、練習に時間を注ぎ込む必要があります。良いプログラムを書けるようになるまでは、駄作しか書けないでしょう。それを乗り越え、乗り切り、経験を積んで初めて、仕様に見合ったものを自由に開発できるようになるのです。

「Hello world」から始めるように言うのには理由があります。経歴の初期段階でこのプログラムを作ることができれば、ある一定の基礎を攻略したということを意味するからです。つまりコンパイル、実行、関数をコールして引数を渡す、などの方法について理解できたということです。実在しているプログラムのクローンを書いてみることは、また1つの大きなステップです。「Hello world」と同じくらい重要で、さらに次のステージへのステップアップになります。どこから手をつけるか検討をつけ、計画し、考えをまとめ、バグに対処し、自分の個性を追加し、最後にはパッケージ化して使えるものにしなくてはなりません。単純なプログラムをクローンする時でさえ、すべての工程を学ぶことになるのです。

既存のプログラムをクローンすることが、なぜ 新しい アイデアを思いつく助けになるのか、疑問に思うかもしれません。音楽と同様、プログラムには創造性が必要です。音楽の場合、誰かの曲を演奏することが、自分自身の曲を作曲するのにどう役立つと思いますか？最初に、他の人がどのようにやっているか、つまり彼らの曲がどのような構造になっていて、どんなパターンが使われているかを理解しなくてはなりません。十分に数をこなして初めて大局が見え始めます。そうして初めて潤沢な知識が形成され、そこから引き出すことができます。様々なものから学んだ小さな要素をまとめて、目にしてきたいくつかのパターンを再利用するのです。そのパターンを微調整したり、統合したり、完全に破棄してもいいでしょう。よく言うように、ルールを知るためには一度壊さなくてはなりません。プログラムではMVC（Model View Controller）のような共通のパターンがあります。これはソフトウェアを書く際のパターンとして安定し受け入れられているものです。音楽の場合、例えば、 I-V-vi-IV などのように共通のコード進行があります。もちろんそれがすべてではありませんが、知っておくべきものです。

つまり、経験と創造性のコンビネーションです。プログラミングの創造性という観点については見落とされがちですが、これは非常に重要です。プログラマでありミュージシャンでもある人がどれだけいるか気付いたことがありますか？　音楽では多くの技術的分析、構造、パターンを行いますが、多くの人々は純粋にそれが創造的な努力だと考えます。プログラミングはよく完全に技術的な行動であると見なされますが、そのほとんどは創造的な努力です。プログラムをクローンすることで、創造性を育てることができます。その過程で、そのプログラムを微調整する方法を考え、個人的な機能を付け加えることすらあるかもしれません。新しいプロジェクトについてのアイデアを思いつくことにも役立ちます。創造性はあとからついてくるものです。まずはカバー曲の演奏を学ぶ必要があるのです。

時と共に、ほとんどすべてのことにプログラミングを応用できると分かってくるでしょう。タスクを自動化すれば実際の問題に取り組むことができます。「作りたいけど時間がないもの」についての長い長いリストを思いつくのは簡単でしょうし、即断即決で問題解決をしていくことができます。「ああ、100枚のシートがあるExcelのスプレッドシートをフォーマットし直して、別ファイルにしなくては、それからcsvに変換？　すぐやります！　」。次の大きいアイデアを思いつこうとするのに捉われないようにしましょう。自分で使うプログラムを書いてみてください。それをやっているうちに他のプロジェクトのアイデアが湧いてくるでしょう。

どのくらいの人たちが「何をプログラムしていいか分からない」という状況に陥ったことがありますか？　どのように対処しましたか？　その状況について他の人にどうアドバイスしますか？