わたしの勉強法：森を見て樹を見る。大きな視点を失わない
こんにちは。ヨギです。初めて時事争論に参加します。(^^)/
3月のお題「わたしの勉強方」にちなんで、わたしが心がけている「勉強のコツ」のお話をします。
■大きなところから入る。細かいことはアト
わたしは、新しい技術を勉強する際は、なるべく「大きなところ」から入ります。
今の自分がそれを勉強する必要があるかもチェックします。
例えば、オブジェクト指向言語はC++が既にあるのに、世間で「Java、Java」って言うのはなぜ？ どんなメリットがあるわけ？ みたいなところから入ります。
少し調べると、Javaにはインタプリタ（Java仮想マシン）があって、1つのプログラムがWindwosでもUNIXでも実行できる、なんてことがわかる。そりゃすごい、C++とか他のプログラム言語では、そうはいかないよなあと思い、食指が動きます。
プログラムのOS間移植に苦労したことのあるわたしにとっては、大変な魅力です。
こうして、勉強する原動力となる火が1つ灯ります💡。
しかも、環境含めて基本的に無料だから、会社のPCでもすぐ試せる。
言語の成り立ちを見ると、C++は出発点（C言語）がプロシージャ指向だからか、どうもあちこちムリのある感じだけど、Javaは最初からオブジェクト指向を意識して、それが言語仕様に組み込まれている。Javaをモノにするってことは、オブジェクト指向をモノにするということじゃん。
そんな感じで、1つ、また1つと、原動力となる火が灯ります。
こうして、その技術が世に出てきた理由や経緯、メリット（デメリット）などを知ることで、勉強するための原動力となる火を、なるべくたくさん灯します💡。その後で、細かな勉強に入っていきます。
原動力となる火が燃えているので、勉強の途中で行き詰まっても、簡単には投げ出しません。
逆にこの段階で、メリットや魅力、由来の納得性を感じられず、気持ちに「火が灯らない」場合は、仕事上、その技術を使わざるを得ない場合を除き、世間が騒いでも勉強しません。
■分からないコトは、いったん脇に置く
勉強の遅い方を見ていると、「分からない箇所にぶつかると、そこを理解するまでは先に進もうとしない」という傾向があるようです。まじめな態度ではあるけれど、これは自らにブレーキをかける行為だと思う。
僕はそういうときは、あまりこだわらず、分からないコトはいったん脇に置いて、思い切ってその先を勉強します。
というのは、「その先」は、「分からないコト」より更に難しいとは限らないからです。ベクトルが違うだけ、ということもあります。
「分からないコト」は、たまたまその人にとって理解しにくいというだけで、「その先」は意外とすんなり理解できることも往々にしてあります。 そして「その先」を理解した後になって、「分からないコト」が理解できたりします。
それに、ある技術の中で、使いこなせない概念の1つや2つあったところで、仕事に影響することは、そうそうありません。
わたしはC++を勉強したとき、ポリモーフィズムについて、その概念は分かるものの、仕事レベルではどうしてもコードで表現できませんでした。でも仕事に支障はきたしませんでした。
詳細は省きますが、使いこなせるテクニックで、ポリモーフィズムの代替えとなる処理を作って回避しました。
後日、ポリモーフィズムでコード実装できるようになった時に、そのコードと、過日、ポリモーフィズムの代替えとして作ったコードを比較しました。
これにより、過日は何が分かっていなかったかが分かったため、結果、ポリモーフィズムの理解がより深まりました。 分からないことの前で考え込んでいるよりは、はるかに有意義な時間の使い方だと思います。
■熟練者と話をする
ある程度その技術をモノにしたと思ったら、わたしはその道の熟練者と話をします。いろんな話題が出るよう、できればコーヒー片手にザックバランな感じで。
すると、熟練者の豊富な話題の中から、自分の理解の足りないところ、応用例、もっと理解を深めた方がいいところなどが自然と分かってきます。そうしたらそこを勉強します。
しかもこれは、熟練者との会話がベースなので、自分が更に勉強すべき箇所の取捨選択が、雑誌や書籍を読むよりも効率よいです。
■既得技術と比較する
これは一石二鳥の効果があります。
まず、既得技術の復習になります。そして、既得技術との違いという切り口から新技術を理解するため、ガッチリした相互理解になるからです。
といっても、あまり大げさには構えません。
過去記事の「もうお腹いっぱい」と、お嘆きの貴兄貴女にから一部引用すると、
- C++はだいぶムリして、オブジェクト指向を実現してるように見える
- Javaに比べて、C++はかなり神経を細かく巡らしてコードを書く必要があるな
- UML図が、Javaの方が素直にコードに落とせる
……まずはそんな感じの、ザックリした相互比較です。
そしてできたら、新技術で実装されたことを、既得技術であえて表現してみます。
例えばC言語で、C++の「クラス」を作ってみる。最終的にできあがったモノが、「クラスもどき」でもいいと思う。
大切なのは、そのためにどれだけ工夫したか。 そしてその工夫・苦心に応じて、クラスのありがたさがわかり、理解が深まればいいのだ。
■既得技術で作った過去のソフトを、新技術で作ってみる
以前C言語で作ったちょっとしたツールやユーティリティを、C++で作ってみる。C++を習得済みならJavaで作ってみる。
すると、ある部分は簡潔に記述できたり、別の部分は意外とまわりくどい記述が必要だったりして、よい勉強になります。
■誰かのためにアプリやツールを作る
例えばプログラム言語は、何らかのアプリを作れて始めて、とりあえずは習得したと言えます。
でも、仕事ならともかく、勉強のためにアプリ作るなんて面倒くさくて、やってらんない。
そういう時は（わたしのことですが）、誰かのためにアプリを作る🍒。
うちの例で言うと、
- 小学生の娘が今「プリキュア」に夢中
- C++を勉強中なので、VisualC++でプリキュアのパズルゲームを作ってあげる
- 娘、大喜び
次は娘の要望を取り入れて、もう少し凝った造りのパズルにする→さらに喜ぶ→さらに凝ったパズルを作る→C++のウデがぐんぐん上がる。楽しい上昇スパイラルです🎵。
この「娘」の部分を、大切な誰かに置き換えればいいわけです。
これなら、同じ勉強するでも、アプリを作るのでも、わりと楽しいと僕は感じます。
■「1冊目」は日本人著作の書籍を買う
技術習得のために、初めてその関連書籍を買う場合は、日本人著作の書籍を買うようにしています。 なぜなら、翻訳本は分かりにくいと感じるからです。
翻訳本は、訳者の翻訳力に大きく左右されますし、また、翻訳上の規制というのがあり、訳者が「こういう表現や言い回しの方が読者がわかりやすいだろう」と思っても、勝手にはできないそうです。
結果、どこか不自然な日本語になり、ただでさえ新しいことを勉強しようとしているのに、説明文が分かりにくくては、それが足かせになるので、「1冊目は日本人著作の書籍」と決めています。
■メリハリをつける
勉強のコツとは直接関係ありませんが、新鮮な気持ちで勉強に取り組めるように、以下のことを心がけています。
●勉強は原則、会社でする。家ではしない
勉強を家でやると、1日中IT漬けとなる。若いうちはいいが、長い目で見た場合、心身に悪影響を及ぼすと感じるから。わたし自身そういう生活を続け、一時期、自律神経を酷く失調する経験をした。
資格試験の勉強などは、早い時間に出社して（タイムカードを押さずに）行う。
●休日は原則、勉強しない。
仮にするとしても時間帯は早暁。家族が起き出してくるまで。
●平日帰宅後はなるべくPCを起動しない。
起動しても、メールとブログチェックくらいで落とす。
●週に1度は、自宅のPCを起動しない日を作る。
●必要以上にTVを見ない。
仕事でディスプレイを見続けて視神経、ひいては脳が疲れているのに、TVを見るのはさらにそれらを酷使することになるから。本当に見たい番組を見たら、潔く消す。寝る時間まで垂れ流し状態で、TVを付けたままにしない。
思いつくままに書きましたが、何か参考になることがあれば幸いです。
ではまた！🍶
コメント
ちょいとお邪魔するよ（笑）。
>「分からない箇所にぶつかると、そこを理解するまでは先に進もうとしない」
わしじゃ、わしのことじゃ、これは。
そんなわけで、わしゃ、ものを覚える・理解するのが人並はずれて遅いんだよ。
わからないのに先に進む勇気がなくてねぇ。
たまたまWEBの世界に入ったのが社内でも3番目くらいで早かったから、なんとか人並に仕事できてたけどねぇ。よーいドン！で勉強させると、間違いなくビリから二番目くらいだねぇ。
今度新しいこと勉強するときは、理解できなくても先に進んでみることにするよ。
m
はじめまして、こんにちは。
>勉強する原動力となる火が1つ灯ります。
>原動力となる火を、なるべくたくさん灯します。
そうか！ そうやって、自分の原動力を少しずつウォームアップするべきなんですね！
私も勉強が遅く、唸っておりましたが、「そういうことなのかっ！」と目の前がぱっと開けた気がしました。
ただ、私自身もテストエンジニアですが、入社以来、テストエンジニアのみを１X年。開発はちっちゃなシェルスクリプトを書くぐらいで、「■誰かのためにアプリやツールを作る」はちょっとハードルが高そうです。その辺は自分の工夫次第だろうという気はしますので、次に新技術挑戦のときは、自分の中の原動力をひとつひとつ灯していこうと思います。
組長
こんにちはー。
今回のコラム、無謀な資格取得計画をぶち上げた私にはとても参考になります。初めて社内の講習会に参加して泣きそうになりながらも最後までやり遂げた時、「昨日までは分からなかったことが、分かるようになる」という勉強の醍醐味を味わいました。これが私の「勉強の灯」の原動力ですね。
でも、やっぱり疲れることもあるので、ヨギさんのコラムを参考に上手に息抜きしながら楽しく勉強していきたいと思います！
soloist
こんにちは
前回は暗ーーく愚痴ばかり書き込んでしまったsoloistです。先日は失礼しましたm(_ _)m
今回はチョット小ネタ(?)
> 技術習得のために、初めてその関連書籍を買う場合は、日本人著作の書籍を買うようにしています。 なぜなら、翻訳本は分かりにくいと感じるからです。
いやいや、日本人著作の本でもわからない本はあるんですよ。
かなり前にオブジェクト指向の本を買って読んでみたんですが、どうもわからない(頭悪いだけかも...)。というか、間違ってない？って思うことが。で、後日たまたまその本の出版社のサイトで正誤表を見ることがあったのですが、あまりの多さにビックリ。今、改めて数えてみたら、73件も訂正個所がありました。校正はやってるんでしょうか？(^-^;
いまさら金返せっていうのもなんだし、交換してくれたとしても読み返す気もしないし....
家帰ったら捨てるかな～
どうも勉強用に買う本にはハズレが多い気が...。趣味の本はそんなことないんですけどねぇ。熱意の問題か(爆)
ヨギ
Xさん。こんにちは。
> ちょいとお邪魔するよ（笑）。
よく来たねえ、待ってたんだよ.......すいません。もうパクリやめます。
> わしじゃ、わしのことじゃ、これは。
すいませんでしたあああ。そんなつもりではあああああ！
> そんなわけで、わしゃ、ものを覚える・理解するのが人並はずれて遅いんだよ。
> わからないのに先に進む勇気がなくてねぇ。
でも、リアクションのオリジナリティとセンスはピカ一だと思いますよマジで。
> 今度新しいこと勉強するときは、理解できなくても先に進んでみることにするよ。
そうっすね。トライしてみてください。
でも小説読んでてコレやると、ホントに話がわからなくなっちゃいますから。はい。
ヨギ
mさん、はじめまして。
そうですね...人にもよると思うのですが、
僕はITが３度のメシより好きなわけでも、マニアでもないので
何か原動力がないと勉強しない....というか、できないタイプなんです。
だから勉強する火を灯す.....別の喩えをすると、石炭をたくさん焚く感じかな（笑）。
それにしても、「目の前がぱっと開けた気が」したのでしたら、私も嬉しい。
記事を書いた甲斐があります。
>誰かのためにアプリやツールを作る
は、ハードル高そうですか？
でもテストエンジニアのみとは言え、それを１X年。
小さいながらシェルスクリプトを書いた経験がおありなら、
恐らくはアプリを作る基礎の土台はあるんじゃないでしょうか。
例えばですよ。
僕が記事に挙げたように、いきなりVisualC++等はムリがあるかもしれませんが、
組込みの世界では、まだまだC言語が健在ですから、Cで、1～75の数をランダムに、且つ、
重複して発生させないプログラムを作るとかはどうでしょう。
Cを少し勉強すれば、すぐできるようになります。
で、ちょっと踏み込んで、できるだけ数字が偏らないように数を発生させるように改良するとか。
今、100円ショップに行けば、ビンゴゲーム用のカードが30枚100円で売ってますから、
それでビンゴゲームができますよね。乱数を発生させるための、デパートなんかで売ってる高いオモチャを買わなくてすむわけです。
みんなで遊べますし。どうでしょう。(^^)/
ヨギ
組長さん、こんにちは。
ど、どんな無謀な格取得計画ブチ上げたんでしょう。
興味あるところです。
しばらくすると、「昨日までわかってたことが、今日わからない」という時がいつかやってくるので、
（わたしのことですが）
そんなときにも通用する、自分なりの「火の灯し方」を徐々に身につけておくといいですよ。
>上手に息抜きしながら楽しく
そうそう、勉強のコツはこれに尽きます。
楽しくないとね。
私は「息抜き」でなく「手抜き」にならぬよう、気を付けたいと思います。
ヨギ
soloistさん、こんにちは。
いえ、特に気にしてないですよ。
同じような方がいるのだと、再認識したくらいなので。
本題ですが、
>日本人著作の本でもわからない本はあるんですよ。
確かにそうだと思います（わかります）。
この件は、soloistさんが指摘されたようなことなどもあり、
いろいろ書くとこれで一記事書けてしまうくらいなので、
とりあえずバッサリと「日本人著作の書籍を買うようにしています」と書いたのです。
売れてはいるけど、現場をあまり知らない、学者さんが書いた書籍はわかりにくいか、
わかりやすくても、現場であまり使えない内容が多いと感じます。
内容が、現場のコードに即してないというか。
しかし73件の訂正個所ってすごいですね。
ほとんど初校の状態な気が。。。。
あと僕はけっこう、本の表紙を見てピンと来たものは必ず手にとって見てみます。
意外とアタってることが多いです。 ご参考までに。(^^)/
ukeyama
こんにちは。
今、C++を勉強中なのですが、ちょっとお聞きしていいですか？
■既得技術と比較する、のところで、
>できたら、新技術で実装されたことを、既得技術であえて表現してみます。
>例えばC言語で、C++の「クラス」を作ってみる。
>最終的にできあがったモノが、「クラスもどき」でもいいと思う。
のところなんですが、CでC++のクラスのしくみって表現できるもの
なのでしょうか？ 今C++の継承がだいたいわかってきたところです（と言ってもサクサクプログラミングはできませんが）。
それでヨギさんの記事を読んで、なるほどと思い、Cで表現してみようと思ったのですが、どうにもこうにも、手が出ません。
何かヒントいただけないでしょうか？
（記事への苦情とかではありませんので、怒らないでくださいね）
ヨギ
ukeyamaさん、こんにちは。
クラスの「しくみ」と受け取られましたか。
これは僕の文章が悪かったかもしれないですね。
CでC++のクラスの「しくみ」は作れないです。
いや、Cでガッチリとフレームワークを作って、
その中でクラスのしくみ（又はそれに近いもの）を作ることはできますが、
それは相当なハイテクニックです。
僕が言いたかったのはもっと基本的なもので、
例えばCだと、構造体があって、その中にメンバ変数があって、
その変数にアクセスするための関数があって...となるわけですが、
構造体と、それへアクセスするための関数は、結びつきはないですよね。
C++のコンストラクタやデストラクタに相当する関数もバラで作って、
プログラマが明示的に実行させる必要がある。
そこで、構造体と関数をC++のように
少しでも有機的に結びつけることはできないものか。
構造体の実体（変数）を生成/解放するときに、
コンストラクタやデストラクタに相当するものを、
自動的に実行させる手段はないものか。
そういうことを、Cではどうプログラミングすればできるだろう。
或いは近いものができるだろうかと、工夫してみることの提案です。
いかがでしょうか。
m
ヨギさん、お返事ありがとうございました。
>組込みの世界では、まだまだC言語が健在ですから、Cで、1～75の数をランダムに、且つ、
>重複して発生させないプログラムを作るとかはどうでしょう。
！！！！！
実は、Ｃは自分の大学のときの専門です（石田晴久先生の御本にお世話になりました。合掌）。
C++も会社で多少、鍛えられました。なぜだかJavaは苦手なのですが（汗）
そうか！ そんな、ちょっとしたことから始めれば……なるほど！
ちょっとフリーor安い開発環境を探してみようかな、家用に…。
あ、あと、その、「ちょっとしたこと」を「すっ」と思いつけるように、もう少し頭をやわらかくしたいです(^^)/
第3バイオリン
ヨギさん
第3バイオリンです。
>技術習得のために、初めてその関連書籍を買う場合は、日本人著作の書籍を買うようにしています。 なぜなら、翻訳本は分かりにくいと感じるからです。
それは私も思いますね。
一度アメリカ人が書いたテスト関連の本を斜め読みしたことありますが
開発やテストのスタイルがアメリカと日本では違うみたいで、どうもピンとこなかった経験があります。
（だから斜め読みで止めました）
言葉以外にも思わぬ壁があるものですね。
>誰かのためにアプリを作る
開発時代、同じプロジェクトの人がデジカメで撮った写真を整理するアプリを家で作っていました。
日曜大工のプログラム版といったところでしょうか。
会社でプログラミングして、家でも勉強のためプログラミングして・・・という
生活をしてて、私も心を壊してしまいました。
自分はプロとしてのプログラミングはできそうにありませんが、
日曜大工はちょっとやってみようかなと最近思い始めました。
>mさん
私も大学時代、C言語を石田先生が翻訳された本で学びました（石田先生亡くなられたんですね）。
C++の開発環境であれば、私は「Visual C++ 2005 Express Edition」を自宅でプログラムの勉強に使っていました。
Microsoftのサイトから無料でダウンロードできますよ。
最新版は2005じゃないかもしれません。
ヨギ
mさん、こんにちは。
>...Ｃは自分の大学のときの専門です（石田晴久先生の御本にお世話になりました。合掌）。
> C++も会社で多少、鍛えられました。
え、そうなんですか。
プログラミング言語の経験が無いという前提で話をしましたが、
それならぜんっぜんイケると思いますよ。
第3バイオリンさんがフォローしてくださってますが、
C++の開発環境であれば、「Visual C++ Express Edition」がいいと私も思います。
無料だし、最新版は確か2008だったかな。
「Visual」という言葉で、少しヒクかもしれませんが、
あれはWindowsのGUI(=Visual)を作りやすいという意味なので（たぶん）、
恐れることはないです。
>なぜだかJavaは苦手なのですが（汗）
Javaは、CやC++を知っていると、それが却って邪魔になる気がします（僕がそうでした）。
一度あたまをまっ白にしてトライするのがコツな気がします。
CもC++も放り投げ出したくなるくらいすごい言語ですよ。
自動テストの環境までありますし。
僕は、客先ではCが使われてることが多いので、仕事ではCを使いますが、
自分でちょっとしたユーティリティを作る際は、だいたいJava（かPerl）です。
p.s.
十分、あたま柔らかいと思います。 少なくとも私より（汗）。
ヨギ
第3バイオリンさん、こんにちは。
（mさんへのフォロー、ありがとうございます）
> 開発やテストのスタイルがアメリカと日本では違う
そうですね。 僕はテストスタイルに大きな違いを感じます。
アメリカではテスト文化がかなり根付いているせいか、
学者や研究者などが提唱するテスト手法を、
積極的に取り入れる姿勢があるように見えます。
余談ですが、アメリカも元はテストを軽く見る傾向があったそうですが、
ビルゲイツだったか、初期WindowsＮＴ開発の指揮を執ったカトラーだったかが、
テスタを軽視する開発チームに、「テストチームを軽く見るな」と激怒したことがあり、
それが発端で、マイクロソフトの中では、テストを重視するようになっていったのだそうです。
> 開発時代、同じプロジェクトの人がデジカメで撮った写真を整理するアプリを家で作っていました。
うんうん、いいじゃないですか。そういうのでいいと思うんですよ。
そのアプリを利用する人も、アプリを作る人も楽しめるようなもので。
> 会社でプログラミングして、家でも勉強のためプログラミングして・・・という
> 生活をしてて、私も心を壊してしまいました。
私もその経験があるので、さぞ辛かったのではと想像します。
（そのうち、そういうタイプの記事を書こうと思っています）
> 自分はプロとしてのプログラミングはできそうにありませんが、
> 日曜大工はちょっとやってみようかなと最近思い始めました。
ふだん仕事でテスト（ＩＴ）をされているのですから、どうかムリのない範囲で。
今回の記事の中の最後に、僕が家で勉強する際に心がけていることを少し書きましたので、
宜しければ参考にしてみてください。 (^^)/