「学問に王道はない」というのは、ある意味真実です。だれにとっても最適な方法といのは、存在しません。その人の持っている前提知識が違うからです。とはいっても、やはり勉強の方法や教材によって効率は違ってきます。
コンピュータの勉強の場合、受験勉強と違い、実際にコンピュータを動かして見る必要があります。知識だけで解決する勉強と違い、アプリケーションを正しく動作させることが目的だからです。SE/PGの仕事において勉強は必要か、というと、勉強しなければならないことは山のようにあります。ただ単に目の前の仕事をこなしていればいいというものではありません。第一、仕事をするには最低限の基礎知識は必要ですし、効果的に仕事をこなそうとすれば多くの知識が必要になります。
会社で教育プログラムや研究がある場合はいいですが、そうではない場合、仕事しながらの勉強ではどうしても断片的な知識になりがちです。大変かもしれませんが、勤務時間以外に時間を取って勉強する必要があります。
コンピューター関係のスペシャリストになろうと思ったら、自分で勉強するという姿勢は絶対に必要です。他の、例えば英語の勉強などは、学校に行って習うのでも十分上達しますが、コンピューターに関しては、学校で習うのでは全然足りません。これを覚えたらずっと大丈夫、というものはなく、次々と新しいことが登場します。限られたアプリケーションを使うだけなら、そのアプリケーションの使い方でもいいかもしれません。しかし、ＳＥ／ＰＧになるためには、自分で調べ、試し、解決するという姿勢が絶対必要です。
仕事を家に持ち込まないために、勤務時間中に勉強できるならそれがいいでしょう。ただし、それは会社が認めた場合はいいのですが、そうではない場合、仕事していない、サボっているとみなされる可能性があります。研修中ならともかく、会社は、あなたの知識を活用する時間に対してお金を払っているのであって、勉強時間に対してお金を払っているのではないのです。トータルとして、仕事のノルマをこなせば、１日、２日勉強に使ってもかまわないでしょうか、ずっとそうしていると、仕事ができるのかどうか心配になってきます。やはり、基礎的な知識はできるだけ短い時間で習得し、できなければ家に持ち帰って勉強し、会社では、仕事中にわからなくなったときに何かを調べるついでに勉強するのがよいでしょう。
社員が勉強しているのか、仕事しているのかはすぐわかります。入門書を長々と読んでいたり、本を読んでキーボードをいじっていなかったり、仕事に直接関係ないことをしていたりしたら、仕事はしていないとわかります。勤務中は、調査はいいですが、勉強はあまり望ましくありません。
忙しくて勉強する時間なんかないよ、と言うかもしれませんが、昼休みを使ったり、残業時間を使ったり（残業代が出ない場合は堂々とやってもいいでしょう）、通勤電車の中で本を読むというのもよいでしょう。私は電車の中では必ず本を読むか寝ますが、何もせずにボーっとしている人が多いのにはいつも不思議に思います。もったいないなあと思うのです。ＳＥ／ＰＧの人も大半がそうです。仕事で頭が疲れ切って本など読む気にならないのかもしれませんが。
いいのは、いち早くノルマを達成してしまい、スケジュールよりも早めに仕上げてしまうことです。その空き時間を使って、開発中に調べてきた断片的な情報を整理し、全体を学んでいくのもいいでしょうし、次のプロジェクトの予習をしておくのもいいでしょう。これなら何も文句を言われません。ただ、手が空いていると、他の仕事を手伝うように要請されるかもしれませんが。
では、どのようにすれば効率的に学習することができるのでしょうか。
わかりやすい本を選ぶことが学習効率を上げる秘訣ともいえます。ただ、わかりやすい本を探すのは難しいものです。ついつい見かけのデザインで判断してしまいがちです。優しい言葉で書かれているようで説明が悪かったりする本もあります。まとまりがよく、１ページ１項目として書かれている本は、とっつきやすそうですが、実際そうでもないです。ページ内に収まるように説明が端折られていて、無理に多くの内容を詰め込もうとしています。その結果、用語だけがだらだら並ぶだけで、読み終わってみても何も頭に残らないことが多いものです。
なので書店でパラパラめくるだけではなく、少し読んで見てからがいいでしょう。また他人の書評も参考になります。一般的に言って、よく売れている本は良書であることが多い（すべてではない）です。
とはいえ、わかりやすい本ばかりを読むことがいいわけではありません。
時には難解な本に取っ組む訓練も必要です。実際、新しい技術だと資料がなかなか手に入りません。その技術が広まってくると、先人が難解な本に取っ組み、あれこれ試行錯誤して動作させた結果、やさしい入門書を提供してくれるものですが、新技術はそうはいきません。また、アプリケーションに付属してくるヘルプやマニュアルも、わかりにくいものが多いです。だからこそ、入門書、解説書が売れて、ビジネスになるのでしょうが。
難解な資料はすらすら読み解くことはできません。やはり時間がかかるものです。だからこそ専門知識を持っている人は、それだけ価値があることになります。
難解なものを読み解くのも一つの能力です。分析し、意味を探り、頭の中でその概念の構造を把握していき、わかったという感覚が生まれるまで解読します。時には暗号を解読しているような気分にもなります。
とはいえ、時間に追われている中で、こればっかりやっていると気が滅入ってくるので、なるべくわかりやすいものを探し、なければ難しいものに取り組むというのがよいでしょう。
そして、もし自分が難解なものを読解しなければならなくなったとしたら、後の人のために、自分の理解の軌跡を残しておきましょう。どこがなぜ理解できなかったのか、どこをどう誤解したのか、等々。大概、つまづくところは共通しています。
ただ、これは学んでいる最中にやらないといけません。なぜなら、わかった途端に、何がわからなかったのかわからなくなってしまうからです。よく天才は教えるのが下手だといいますが、それは本人はすぐに理解してしまうので、理解できない人のことがわからないのです。私たちも、自分がよく知っていることについて、初心者に対して説明しなければならないとき、ついつい専門用語を使い、説明を端折ってしまうものです。自分がよく知っているので、マニュアルを読んでも、どこが説明が欠けているのかわからないのです。
この業界、特に最近はIT業界の人口も多いのと、技術の進歩やニーズの変化によって、新しい技術が次々と登場します。ソフトウエアも次々とバージョンアップして、そのたびに機能が追加されたり、仕様が変更になったりします。
苦労して学んだ知識は有効期限は短いものです。あるプロジェクトの仕様や設計に関する知識は、そのプロジェクト限りです。使っているサーバ製品の知識も、そのバージョン限りです。同じ製品を次の機会に使ってもバージョンアップしているので再度学び直さなければなりません。結果が労力に比例しているとは言いがたいものです。
そういう点で、これは受験のための知識に似ています。受験以外にはほとんど役に立たない知識です。まあそれでも記憶力や理解力の訓練になるでしょうが。
よく「次々新しい技術が出てきて大変だ。また覚えなきゃなんない」と愚痴をはくと、その道の先達たちは、根本を押さえておけばどれも同じだと断言します。プログラミング言語なんてどれも同じだと言う人もいます。
これはある意味正しく、ある意味不適切です。プログラミング言語も、変数、制御文、関数等に関しては同じですが、手続き型の方法とオブジェクト指向の方法とでは、やはり考え方が異なります。手続き型しか知らない人が、オブジェクト指向言語を使うことはできますが、その方法は手続き型の方法でしかありません。それはコーディングのレベルではなく、設計の部分から関わってきます。
また現場で作業をするには、抽象的な概念を抑えておくだけでは駄目です。具体的なコマンドを知らないと、結局は何もできません。目的はコンピュータを目的どおりに動かすことなので、正しい手順でやらないと、どんな天才でも使うことはできません。結局のところ、本一冊以上の知識を習得せざるを得ないのです。
もちろん、扱っているのは情報の流れであり、その扱い方について抑えておくべきポイントは今も昔も変わりません。実務を通して、いろいろな経験をつみながらつかんでいく必要があるでしょう。このホームページでもできるだけ、本質的な知識について扱っていきたいと考えています。
これはどちらも必要です。現場でその都度調べるのは、まさにそのとき必要とされている知識なので身に着けやすいし、また実践的です。しかし、基礎的なことや全体像を把握していないと、ときどき調査に悪戦苦闘することになります。どこから手をつけていいかわからなかったり、ネットで検索しても膨大にヒットしたり、あるいは逆に全然ヒットしなかったりして、かなり苦戦します。
そうした場合、単に行き当たりばったりの断片的な知識だけで、「よくわからないけどこのおまじないをすればいいや」という感じで、「なんだかわからないけどできてしまった」ということになります。結果だけ出せばいいのであればそれでもいいのですが、応用が利かず、少し条件が変わったら対応できなくなります。
なので、ベースから一通り全体像を把握し、基礎的な概念を理解しておく必要があります。そうすると今までの断片的な知識がつながってきて、よく深く理解できるようになります。
一方、勉強だけで経験がないのも問題で、こちらも深い理解ができません。第一、勉強自体が退屈になってきます。実際に動かしていないので、その技術を使う前の基本的なコンピューターの動作で躓いたり、予想外の結果でその場で立ち往生する結果となります。実際、手順を知っておく必要がありますし、どこに気をつけなければならないかはやって初めてわかることです。
現代は、インターネットの普及によって、様々な情報が簡単に手に入ります。インターネットは非常に便利なものです。わからないことがあれば、インターネットで調べれば簡単に答えが手に入ります。インターネットがあれば、解説書が手元になくても十分に仕事ができるほどです。
時々、現場でインターネットの使用が禁止されていたり、制限されていたりしているところがあって（セキュリティのため）、ひどく不便を感じることがあります。開発者にとって、インターネットが使えるか使えないかで、生産性が大きく変わってきます。
私が主に使用するのは、検索エンジンGoogleと用語辞典のサイト、アットマークITのサイトです。アットマークITのサイトは、良質の連載が多く掲載されていて、市販の本よりも内容が充実しているものもあります。
検索エンジンで、言葉を調べるときは、「○○とは」「○○は」「○○というのは」という風にすると、その言葉の説明や定義をヒットさせるのが容易です。またGoogleのキャッシュ機能を使うと、検索語がマーカー表示されるので該当箇所を探すのに便利です。またすでにリンク切れになっているページも表示することができます。
とはいえ、キャッシュにも残っていない場合があるので、あとで参照するかもしれないものでかつ個人サイトのものは自分で持っておいた方がいいでしょう。＠ITの記事などはおそらくなくなることがないでしょうが、個人サイトはブックマークしておいてもよくリンク切れになります。なのでブラウザでWebページを保存したり、Web巡回ツールで保存します。あるいは抜粋してメモしたり、「紙」などのツールを使って保存します。GREPやグーグルのデスクトップ検索を使うと用意に自分のPCの中を検索できます
新しい言語や技術を覚えるのに、長々と入門書を読む必要はありませ。一つの言語を覚えていれば、基本的に概念は一緒なので、違いを理解すればよく、さらに新しい概念があればそれを理解することに費やせばよいのです。違いを理解するのはキーポイントです。何が違うのかを理解しないと、既存の知識の枠組みで理解しようとするため、なかなか理解できなくなるのです。
新しい言語や技術を学ぶときに必要なのは、以下のこと習得することです。
それから、その技術の目的、規模、専門用語、適用分野、実装例、レファレンスサイト等についても知っておいたほうがいいでしょう。
あとは実践の中で覚えていくことです。簡単なサンプルを実行することは非常に重要です。そこから少しずつソースをいじっていって、動作を確認していくことです。
すでに学んでいるものとほとんど同じであれば、すぐにマスターできますが、違いがあると慣れるまでに最低一週間はかかります。十分に理解しないうちに、学んでから間を空けるとすぐ忘れてしまいます。
それから、細かいAPIの使い方は覚える必要がありません。頻繁に使うものは覚えておいた方がいいですが、通常は、APIリファレンスを参照しながらプログラミングを行いますので、不要です。どうやって調べたらいいかのリンクがあればいいです。
習熟度のランクは以下に段階わけできるでしょう。
たくさん習得しなければならない技術があるので、新しく習得したことはメモしておきます。自分にわかる程度でかまいません。コマンドや手順など、繰り返し使いそうなものはメモしておきます。本を読んでいて、ポイントとなる部分はメモに取ってまとめておきます。その際、紙に書いておくのではなく、テキストファイルに保存しておきます。そのためには、「紙」などのメモ専用の常駐型エディタなどが便利ですが、普通のエディタでもかまいません。常駐させておいてすぐに起動できるようにしておくか、クイック起動に登録しておきます。
同僚や先輩が自分の知らないコマンドを打っているときは、さりげなく覚えておいて、自分の知識としてしまうことです。自分では知らない、便利な方法を知っていたりするものです。
また、本を読んで勉強する場合、コツがあります。当たり前のことかもしれませんが、ポイントとなる箇所、意味不明な点、疑問点を記しておくことです。下線を引くか、付箋をはるか、折り目をつけるかですが、私の場合は、鉛筆で欄外に○や△、？を記し、疑問は言葉で記録しておきます。ボールペンを使わないのはあとで消せなくなるからです。よくはじめて読む本にマーカーやボールペンで書き込む人がいますが、最初は要点がわからないのであまり望ましくないと思います。本がマーカーだらけになってしまう人もいます。
また、一章読み終わったら、自分が何を理解してみたか頭に思い浮かべ、復習してみることです。そうすることで理解度を確認し、要点を頭に焼き付けるのです。１日で一気に最後まで読み通せる本でしたらいいのですが、何日、何週間とかけて読む場合、最初の方の内容を忘れてしまうからです。私自身、ちまちま復習してゆっくり進んでいくよりは、さっと一気に終わりまで行って、それから要点を拾っていく、というやり方の方が好きです。全体を知らないと個別の部分もよくわからないという考えを持っているようです。ただ時間の兼ね合いもあってそう簡単に最後までいけないのが難点です。
私は、最初の一ページから最後のページに至るまで順に本を読んでいくタイプです。もちろん調べることがはっきりしているならその部分しか読みませんが。少し前に、速読の本を読んでマスターしようと思ったのですが、その中で自分に必要なところをピックアップしながら読むとありました。いずれ必要な技術かなと思いましたが、なかなか私には難しいかもしれません。
大概、よくできた本は、きちんと編集され、まとめられていて、必要な知識が網羅され、無駄なところがありません。なので、全部読んでしまいます。もちろん、現在必要ない部分や前提となる知識が必要とされるところは飛ばします。また、一冊では紙数の都合上、必要な知識が省かれていたり、漏れていたりすることがあるので、数冊は読みます。
ただカタログ的な本は信用していません。これはページ数を合わせるために無理に形にはめ込んで作っているので、無駄な部分もあれば必要なところを端折っていたりします。
こう言うと、そんなにたくさんの本が必要なのか、と思われるかもしれません。必要です。抜きん出たいと思うならばそれだけ勉強が必要です。ただし当たりを選んでいくなら、読む本はずっと少なくて済みます。
また、「そんなたくさんの本を買うお金があるか」と言われるかもしれません。買わなくても済みます。毎月本代に２万円以上かけている知人がいますが、そこまでお金をかけなくても済みます。図書館、古本、オークション、立ち読み、会社の本、Web公開の本、等いくらでも安く済ませる方法はあります。
「聞くは一座の恥」
といのは嘘です。下手に初歩的なことを聞くとスキルを疑われます。何でも聞いていい状況でない限り、その場では知ったかぶりをして、あとでこっそりとGoogleで調べましょう。実際、ミーティングの場で、他のみんなが知っていることをいちいち質問することは迷惑です。それから何でもかんでも聞くという姿勢はよくありません。ただし、あまりにも長い時間かけて泥沼にはまるのもよくありません。一言聞けばわかることはすぐ聞きましょう。基本的に、自分で少し調べてわからなければ聞くというのがよいです。あと質問する相手を選ぶことも重要です。
コンピューターの世界では、専門用語がたくさん出てきます。それが果たしてごく一般的な用語なのか、その業界特有の用語なのか、その会社でのみ使っている用語なのか切り分けなければなりません。一般的な用語は調べれば出てきますが、その会社特有の用語は聞かないと絶対にわかりません。
専門用語は、用語辞典を読み通して覚えられるものではありません。使う現場にいて理解できるものです。なので、いろいろな現場を通して、知識が増えていくことになります。
また、技術者によって扱っている分野が違うので、その人の知っている知識は異なります。なので知らないことを特別恥じる必要はありません。実際、長年SEをやっていたにもかかわらず、ある現場では非常に基礎的な用語がその人に通じないことが驚かされることもしばしばあります。IT技術は範囲が広いので、何でも知っているという人は世の中にはいません。ある分野に非常に強いのでこの人は何でも知っていると思って、あれこれ聞いていくと、その分野はよく知らないと平気で言っていたりします。なので、何でもかんでも知っている必要はありませんが、無知をさらけ出すときは場を選びましょう。
最近では、資格ビジネスが盛んで、いろいろなところが資格を作り出し、その価値を宣伝して、受験産業を作り出そうとしています。資格自体の価値についての議論は別の機会に譲るとして、試験自体は、よい勉強の道具にもなります。
本を読んだだけでは記憶しようとはしませんが、問題に出されることで記憶することができます。調べればすぐわかることでも記憶している方が作業の効率はいいです。
また、出題されることで、今まで曖昧にしていたところ、理解していなかったところを明確にすることができますし、また良質の問題であれば、ポイントは何かを押さえることができます。ただ時々覚える必要もない重箱の隅をつつくような問題も出てきます。特にSunのJavaの試験はそんな感じがします。
また、試験を受けるということで、勉強に励みと緊張感をもたらすことができます。人間は尻を叩かれないとなかなか本気になれないものです。
というわけで、試験を活用するというのもいい方法です。試験代がもったいなければ、試験は受けずに問題集だけやるのもいいでしょう。
SEやプログラマが行う仕事というのは、ソースをガリガリ書いているばかりではありません。実際、それ以外の時間の方が多いのです。仕様の理解やドキュメントの作成や打ち合わせにかなりの時間を費やします。仕様が理解できなければ正しいソースを作ることはできないからです。バグは仕様の理解漏れに起因することも多いです。したがって技術とは別のところでかなり頭を使うことになります。ツールベンダであれば技術オンリーかもしれませんが、通常は、業務知識を含む、技術とは直接関係しない知識を身につけることになります。