プログラマという職業とその最低要件とは何かという事を勝手に考えてみた


 昔、インターネットもグーグルもない時代からプログラマをやっていた人達というのを自分は尊敬している。
そういう人達は、書籍やマニュアルを頼りにプログラムを組んでいたのだと思う。書籍やマニュアルは紙だから
調べるのも大変で、効率的に仕事をするには、言語仕様をつきつめて暗記していることが必須要件だったのだろうと思う。
翻訳されていないドキュメントから学ぶ必要もあったのだろう。あるいは、各社の中で、独自のマニュアルやドキュメントが
豊富にそろっていたのかもしれない。そういう時代には本当に適性のある人しかプログラマにはなれず目指すことすらできなかったのではないかと思う。
桁外れの記憶力と思考力を備えていない事には、どんなソフトウェアも生み出しえなかったのではないかと想像する。


 が、今はインターネットもグーグルもあるために、原典を取り寄せたり口承される希少な技術を学ぶためにどこぞの企業なり研究機関なりに
認められて一員となったりなどができなかったとしても色々なものを作るために必要な最低限の技術をサッと調べて使える時代になっている。
勿論、様々な組織体にはそれぞれ外に公開することで競争力を失う事になってしまわないよう中核の技術などはいつでも門外秘として大事に守られているし
そういうものがあることによって各組織体のアイデンティティや個性や長所は維持されていると思う。それはなんとなく、プライバシーが人の個性を支えている
事にも似ていて、セキュリティが企業の特徴を支えているのだという気がする。


 ある時期までインターネットは、LinuxであれApacheであれ根幹の部分がオープンソースソフトウェアによって支えられていて、
ソースコードそのものが公開されていたり、情報をくまなく広めるための広報的な側面に特化して尖っていたような気がする。ブログ化の時代と言われていた
WEB2.0の時代まではそうだった。が、SNS化の時代には、むしろクラスタ化されたそれぞれの集団が、内輪と外を明確に区別して
内輪にだけ情報が行き届くようなプライベートクラウド的な情報の統制が主流になってきているのかもしれない。
ビジネスの世界では、実際にはオープンソース系のソリューションを使わないところも多いようだ。なぜならオープンソース系のシステムの場合、
その部分に起因するトラブルがあった場合の責任主体が存在せず、全部公開しているのだから細部に至るまで仕様を理解すべきで、問題がおきたら使う側の自己責任であるという事になってしまうためだろう。
オープンソースでなければ普通は、販売元や開発元に問い合わせれば良いだろうが、オープンソースはそういう責任のあり方はしていないのではないかと思う。


 話が脱線したけれども、OSのソースコードであれプロトコルスタックソースコードであれ何であれ、インターネット上には公開されていて
それらを読み解くための必要なプログラムの文法もインターネット上には解説があるという中で、
例えば自分のような、たぶんインターネットがなかったらプログラミングには関わる事もできなかったであろう大した記憶力も思考力もないプログラミングの才能などない人間であってさえも
ググりながらなんとかプログラムを組み立てたり仕事をしたりする事が可能な時代になっている。
くまブであったりKDPランキングであったり、アンテナサイトであったりと言ったようなものを無から作り出すことができている。
で、大抵のプログラミングの入門書なり学習カリキュラムというのは、インターネットがない時代のプログラミング学習法を前提にしているように思える。
それはハローワールドから始まり、各データ型の扱える範囲などを覚え、ループ、分岐の後にオブジェクト指向を理解するというようなカリキュラムだ。
恐らくそのやり方は鉄板であり、そういう風に細部から入っていくことで系統立った仕方で体系的にすべてを理解し暗記することでしか、
本当に才能のあるプログラマにはなれないことは確かだと思う。細部の意味を理解し、細部から知識を組み立てていくような学習方法だ。
だがその一方で、付け焼刃的でしかないにせよ、最短コースで一瞬でプログラミングをある程度扱えるようになるための方法というのもある。
それは、細部を後にまわして全体像や骨格だけを先に完成させ、やせ細ったその骨格を少しずつ肉付けしながら太らせていくような学習方法だと言えるかもしれない。


 プログラマという職業において一番肝心な事は、ノウハウを生み出しつつ新しい知識をどんどん学べるかどうかだという事のように自分は感じている。
新しい知識をすぐに吸収できるかどうかという部分で、私の場合はだんだん学生時代のような勉強法ではない手順で学んでいくようになっていったが、
多くのプログラマが実は知らず知らず同じような方法を実践しているような気がする。
そしてその方法論を最初から知っていれば良かったのではないかという気がしている。


 ただこの方法論について語るときにどうしても思うのは、”とは言えやはり本当はこの付け焼刃的な理解では、本質は理解できないんだよ”という
自分に対する自戒の念だったりする。だから結局のところは、動くものが作れるようになったその後で、細部の意味を理解するための体系的な知識の
確認のほうへと、従来の学習カリキュラムを逆走するような形で原点回帰することが、本当にプログラマとして生きていく上では最終的には必要になる。
(そういうものを目指さず動くものを作れるようになるだけであれば、それは必要ない。車の運転をするだけなら車のエンジンの構造を学んでいなくても可能なのと同じ事だ)
世の中の大半のプログラマーは自分よりすごい人ばかりだから、そういう人には私の言っている事はやはり今更感があるだろうが、
むかしの自分にもし伝えられることがあるとしたら、新しい技術を自分で使ってみる時にどういう風に学ぶのが早かったかということを伝えたいもんだな、と思っていた。
ただ、私のやっている学習スタイルだと細部はほとんどスルーしてしまうから、動くものが作れたとしても本質は理解できていないし、
他のプログラマと議論するために必要な語彙もそろわなくなってしまうので、プログラマとして生きていく上では、動くものができたその後でもいいから
自分が作ったものが何なのかという事を細部に至るまで説明できるように関わっている言語仕様の詳細を学んでいくべきなんだろうねということ、
そしてそれは何も作れていない状態で言語仕様を学ぶのと比べればモチベーションは高い状態で取り組めるし、
とりあえずものが完成するというところにメルクマールを置くのであれば、最短最速の学習コースだといえるんじゃないか、という風に思っている。


 どんなものであれ最初から本質に入ろうとすると、抽象的すぎてすさまじく頭脳明晰な一握りの人達にしか超えられないハードルがあると思う。
例えばJava言語であれば、最初の1ページ目にあるハローワールドの一文である以下の文

System.out.println("Hello World !");

を理解するためには、最後のページあたりに説明されているオブジェクト指向やストリーム、ラッパーなどについて知っている必要がある。
Systemクラスの出力ストリームoutのprintlnメソッドの引数に文字列を渡しているからだ。
だがそれを、プログラミングとは何だろうと思って初めてJavaから学ぶ人の最初の入口で説明しても、頭脳明晰な一握りの人達にしかついていけない。
人間は意味の分からないものは覚えられないのだから、最初から意味を理解しようとする普通の人達の多くが、ここですでに挫折する。何を言っているのか意味が分からないからだ。
じゃあどういう順番で学べばよかったのだろうか。
そんな話を数年前に書いた。

最速プログラミング入門

最速プログラミング入門