私は、大学でこそ情報処理を選考とする学科を卒業しましたが、本格的なプログラムというものに
触れたのは社会人になってからです。
とある企業に採用になり、配属になったのは情報システム部門
といっても、その頃は厳密に情報システム部門というのは存在しておらず、社内のネットワークやら
メールやらＰＣ管理やらいわばＩＴに関する何でも部門のような位置づけでした。
初めて構築したのは、システムはオープンソースの組み合わせ
Linux ＋ Apache ＋ PostgreSQL ＋ Perl
それまでプログラムどころかLinux自体に触れた事もありませんでした
しかも、配属になった部門では先輩社員はゼロ・・・
そして、先ほど説明したようにどちらかというと社内のITインフラ整備の特色が強かった部署で
上司にもプログラマー出身の人はいませんでした。
誰にも聞く事ができず、配属になった同僚と取りあえず参考書を買いに行き
本を読みつつ、何がなんだか分からないまま手探りの状態で構築を開始
幸い、同期でLinuxに触れそしてプログラムの経験が多少あるメンバーがいたので彼を
中心になんと構築する事ができました。
今でもそのシステムというのは稼動しているのですが、今改めてソースを見てみるとそれは
ひどい事・・・
モジュールという概念こそ取り入れているものの、システム設計という概念などまったく無く
構築されたシステムは、まともに動いているのが不思議なくらいガラクタを寄せ集めて作った
ロボットのように不恰好なものです。
しかし、その当時は出来上がった時の喜びと完成度の高さに満足していた記憶があります。
時は流れ、社内でのポータルサイトというものの必要性を見出した上司の指示を受け
ゼロベースで構築を初め、今もなおその業務を行っています。
これまた、当初のソースを見るとひどいと思うのですが、様々な参考書とインターネット上に
転がる他人のソースを読み、身につけていくうちにその内容というのは洗練されていっている
と感じます。
プログラムを書く上で必要なエッセンスを詰め込んだ、様々なデザインパターンや方法論を
自分たちは、誰かに直接教わることなく参考書やインターネット上に転がるソースを読んで
体験し、そして取り入れてきました。
その先人たちが苦しんだ事を、遅れる事数年、同様に悩みそして体験できた（気づけた）事は
非常に重要な経験だったと感じています。
うちの上司は、技術は人から教わるものではないという考え方の人なので、なんでも自分たちで
調べ、体験して身につけていくというスタイルを自分たちにとらせてくれました。
これは非常に時間のかかるやり方だと思いますが、何の疑問も無く言われた事を受け入れる
のではなく、ちゃんと考えて体験し、悩みそして理解するというサイクルは非常に重要なものだと
今でも感じてます。
そのような経験と、上司と、恵まれた環境に感謝をしたいですね。