情報はどこで仕入れればいいの？ 　最初に説明しましたが、情報そのものは結構あります。 　まず、あなたが今見ているようにホームページを探してみましょう。できれば、英語のページも探してみましょう。このページのような解説以外にも、電子掲示板やメーリングリストなんかを扱っているところもあります。 　ニュースグループやニフティのような掲示板タイプのところもお奨めです。ただ、日本のプログラミング系ニュースグループはあまり活気がないような気がします。英語の方はかなりの量があるので知りたい情報が見つかるかもしれません。ニフティは初心者から上級者までフォーラムが広く存在するので、安定して情報を得られると思います。ただ、今現在インターネット経由だと過去１０００項目しか見られないようなので注意。 　ウィンドウズ関係では「ＭＳＤＮ」というマイクロソフトが作製した大量のドキュメントがあります。最新のウィンドウズプログラミングを行う場合には必要なものでしょう。 　本は……高いです（泣）。ただ、やはり「情報の完成度」はピカイチだと思うので、その点では安心でしょう。 　あとは、やっぱり人に訊くことです。全体的に見ると訊かれると困る人は結構いるみたいです（説明するのが大変、人付き合いがイヤ、めんどくさい、他色々）。まーどうしても分からなかったらメールください。絶対ちゃんと答えます。

文字列を数字に変換したいんだけど 　というような簡単な機能を使いたい場合ですが、これは言語に大きく依存します。というわけで、こういった質問はなんらかの本などを見て解決しましょう。 　ホント言うと、その言語のマニュアルを見るのが一番なんですが、学校の授業とかだと見られないことがほとんどなので、図書館などである程度ちゃんとした本を探してみることをお奨めします。この辺はマイナーな言語ほど（と、そのころの流行によっては）難しいと思います。

配列を並べ替えたいんだけど 　こういう並べ替えをソートといいます。ソートにはバケットソートとか基数ソート、クイックソートなど様々な方法があります。そして、それぞれの方法ごとに特徴があり、処理速度が違います。こういう「方法」のことを「アルゴリズム」といいます。 　使う機能は普通の物、それらを組み合わせて何らかの処理をしたいというばあい、この「アルゴリズム」にしたいことがあるかどうかチェックするのがいいでしょう。色々な言語で「アルゴリズム集」といった感じの本が出ていますし、基本的にはアルゴリズムは言語に依存しないので、言語を乗り越える自信があるのなら詳しく書いてあるもの（特にＣ言語の）を１冊買うのをお奨めします。

３ＤＣＧを表示したいんだけど 　こういった「最新技術」を扱う場合には、それなりに最新の情報を取得する必要があります。しかし、そういう最新情報はたいがいの場合英語です。また、高価な場合が多かったりします。 　ただ、そういう情報は基本的に「最先端」の部分からしか出ないため、取得が意外と簡単という利点があります。また、なんだかんだ言っても少し待てば日本語の本や雑誌に載ったりするので、急がなければ困ることもないでしょう。それに、３Ｄみたいな誰もが注目してる物は、横の継ながりもできやすいのでそういったものも利用しましょう。

ポリゴンをアニメーションさせたいんだけど 　これが、いわゆる「最終目的」とでも言えるものです。つまり、細かい技術、最先端技術、アルゴリズムをすべて組み合わせる部分なんですけど……これは、かなり情報を取得しにくいと思ってください。 　例えばゲームとかでのこういった技術は、いわゆる「企業秘密」だったりします。そのため、もちろん本になったりすることも少ないですし、そこらに情報が転がってくることもありません。 　だから、基本的には「似たものを作る」ことになると思います。もちろん、中のプログラムは違うかもしれません。でも、速くて小さくて安定してればいいんです。つまり、ここの部分に関して独自の処理を見つけだせれば、世界に羽ばたけるかもしれない！！　ということです。 　ま、要するにこの部分がプログラムを組むという部分で、プログラマーの資質が問われる部分のひとつということが言えるでしょう。

「パッケージ化」をもう一度 　さて、くどいようですが、もう一度パッケージ化について見ておきたいと思います。 　「パッケージ化」、言わずもがなですが、関数の中に変数を閉じこめることで「データの処理単位」を小さく細かく分けて、データの管理を簡単にすることです。 　この「パッケージ化」をはき違えないで欲しいのが、決して「関数を見えなくする」ことではありません。関数でパッケージするのは「関数の中身」ではなく、「データ」です。 　でも、実際にプログラミングをしてみると、おそらく「中身の見えない関数」ばっかりでしょう。特に簡単な関数ほど隠されています。 　で、元々隠されているものはしょうがないとして、自分が作る関数はどうすべきでしょうか。

プログラム＝アプリケーション？ 　プログラムとアプリケーション、同じ物でしょうか。 　アプリケーションの書かれている「マシン語」から、かなり近い形までプログラミング言語へと変換できます。これを比べてみると、プログラムとアプリケーションはほぼ同じ物だということが分かると思います。そう考えると、この＝は成り立ちそうです。 　でも、もう少し考えてみましょう。アプリＡとアプリＢがあったとします。ＡとＢは機能的に全く同じ、ファイルサイズも同じ、何もかも同じです。ところが、中の「現在の日付の取得」に、Ａは関数ＦｕｎｃＡ()を、Ｂは関数ＦｕｎｃＢ（）を使っているとしたらどうでしょう。そのどちらの関数を使ってもファイルサイズには変わりなく、機能的にも変わりありません。でも、明らかに違う関数です。 　こうなると、「プログラムＡ＝アプリＡが成り立ち、アプリＡとアプリＢは成り立つが、プログラムＡとアプリＢは成り立たない」という、いわゆる「三段論法」が成り立たない自体になってしまいます。 　まぁ単純に、プログラムとアプリとじゃ次元が違うのが原因です。アプリという「見た目と機能」だけの世界では見えない部分が違うというわけです。 　これは、思った以上に大きな問題を示唆しています。つまり「プログラム」から「アプリケーション」へと変換した時に多くの部分が隠されるということです。ふたつの一見同じアプリケーションが、その「隠された部分」で大きく違う可能性があります。そして、その「隠された部分」に大きな問題があるとしたら……。 　隠された部分の違いが、ファイルサイズや実効速度に影響しているのであれば、その部分の問題点がわかりやすくなります。ですが、作製したアプリケーションに似たものがなかった場合、どんなにファイルサイズが大きくても、どんなに実効速度が遅くても、比較できないために「それが普通」と考えられる可能性があります。 　また、例えば「確率１０００分の１で落ちる」とかの分かりにくい問題はどうでしょう。問題の部分に何らかのミスがあるのかもしれない、でもないのかもしれない、そういったあやふやな感じになりやすいでしょう。

「完成できてしまう」こと 　例えば、forループを使って１００回同じことをすべき部分を、９９回コピー＆ペーストして同じように実現していたら、どうでしょう。この部分は、前述の「隠れる部分」にあたるのですから、アプリケーションではどちらでも変わりありません。 　皆さんは「こんなことしないよ」と思うかもしれません。でも、これほど極端ではないと思いますが、いや、それほど目立たないからこそ、パッケージ化やコードの簡略化などを怠ってプログラムを組んでしまいがちです。 　日程に追われていると、どうしても「きれいなプログラム」を書かなくなります。力技のコーディングをして、同じコードをコピー＆ペーストして、ひとつの関数の中に何百行ものコードを書き込んで……。 　ところが、これでもアプリケーションは動きます。レポートだったら単位をもらえ、仕事だったら給料がもらえてしまいます。じゃぁ、これでいいってことでしょうか。 　ある意味これでいいんでしょう。アプリケーションを作るのであれば、これで十分だからです。 　でも、もしあなたが「上」を望むのであれば、それはやめた方がいいでしょう。たとえ最初は辛くても、上司から評価されなくても、地道な努力であっても、きれいでしっかりとしたコードを書くべきです。 　なぜか？　何度となく書いてきました。データの管理を楽にするためです。「管理」、つまり「メンテナンス」は雪ダルマ式に膨れ上がってきます。汚いコードを書き、それを無理矢理使い回していけば、いつかは破綻するでしょう。 　破綻しなくても、メンテナンスに追われる日々が続きます。逆に言えば、きれいに書けばその分時間に余裕ができることになります。余裕ができたらどうするか？　遊ぶ？　いえいえ、勉強するんです。

「プログラマー」に求められるもの 　プログラマーがすることは、プログラムを組むことです。つまり、アプリケーションを作ることではありません。 　どんなアプリケーションにするか――ファイルサイズ、実行速度、ユーザーインターフェイス、安定度――ということを決めるのは、アプリケーションデザイナーであり、グラフィックデザイナーであり、プロデューサーであり、ユーザーです。プログラマーは、その希望を叶えるだけです。 　言ってみれば、プログラマーは「コンパイラの上に立つコンパイラ」です。普通の言葉しか使えない人達から望みを聞いて、それをコンパイラの分かる言葉に変換することがプログラマーの仕事です。 　普通に翻訳をするときと同じように、同じ意味でも複数の単語があり、微妙なニュアンスに合わせてそれらを使い分ける必要があります。こういったことがプログラマーにも求められます。 　ただ単に翻訳するだけなら、辞書さえあれば誰にでもできます。翻訳家に求められているのは、いかに速く、そして最も適切な翻訳をしてくれるか、ということです。 　それができるために、勉強する必要があるのです。だから、プログラムが組める、それだけで満足しちゃいけません。 　もし本格的に「プログラマー」を目指すのであれば、限界まで突き詰めてみましょう。３ＤＣＧアニメーション、ＯＳ、原子力発電所、ジャンボジェット、気象予報。「限界」を求められる「プログラミング」はちゃんとあります。ここまでではないにしろ高い位置を目指すのであれば、できるだけ「余裕のあるプログラミング」を心がけることが大切になってくるでしょう。

「見せられる」コード 　もしできれば、アプリケーションではなく、プログラムを評価してもらってください。完成したアプリケーションと、それを作りだしたプログラムを比較してもらい、どこを改善すべきなのかをはっきりとすることが大事だと思います。 　そのためにも、関数の中身は公開すべきです。人に見られても困らないコードを書き、ライブラリにソースコードも付属させて、使ってもらう。こういう経験が必ず役に立ちます。 　実際には、人に見せられるコードを書くことは口で言うほど簡単ではありません。自分で作った関数の引数や戻り値に対して「なんでこういう形にしましたか？」と訊かれたとき、「適当に」と答えてはダメです。ちゃんとした理由を持って答えられることが必要です。 　コードのパッケージ化、コンパクト化は当然のこと、変数の命名規則も初めから最後まで統一されているのも当然。コメントも分かりやすくちゃんと書きましょう。 　めんどくさいですね、イヤですね。アプリケーションができてしまえば、プログラムなんてどうでもいいんですから。 　でも、あなた方の使命を忘れてはいけません。アプリケーションを作るのではありません、プログラムを作るのです。 　なんせ、「プログラマー」ですから。

そして 　プログラムなんて、子供にだって組めます。アメリカとかで少年がクラッキングしたというニュースは何度となく聞いているでしょう。情報と時間、あとは直感力と計算力があればたいがいのプログラムは作れてしまうのです。 　でも、作れてしまうからこそ、その奥にあるもっと大事なことを学んでもらいたかった、だから「ゼロ」の状態の皆さんにこんな講座を開いたわけです。ただひたすら「プログラムを組むこと」にのみ浸ってしまって、ベースにある基本的なことを学ばずに成長して欲しくなかった、ということです。 　「プログラマー」への道へは、楽な近道も遠回りな茨道もあります。 　でも、「自分が何をしたいのか、どこへ行くべきなのか」。これだけは忘れないでください。そうすれば、自らの道が必ず開けてくるはずです。 　比較的「努力すれば報われる」分野です。着実に一歩一歩進んで、努力を自信に換えてけば、かならず目的地にたどり着けるでしょう。 　この講座がそんな皆さんの第一歩になれれば、うれしい限りです。