プログラミングが超苦手・・・悩んでいます

質問

はじめまして、現在、一般企業にてITヘルプデスクとして働いているものです。

業務の一環として業務アプリの作成(＝プログラミング)作業があるのですが、これが昔から非常に苦手で苦戦しております。

実はかつてプログラマーとして勤務していたのですが、適性の無さを痛感し挫折しました。
新しい言語を習得する度に参考書を買い込んだり人に聞きまくったりして得意な人の何倍も努力しても、そこまでやってもどうしても読み解くことができないプログラムがあったり、良いプログラムのロジックが思い浮かばないことが度々ありました。

現在はプログラミングはあくまで業務の一部でしかないので、何とかして乗り切りたいと考えてはいるのですが・・・新しい言語なので今までの経験が生かせず、またしても苦しんでいます。
（ちなみDBMagicという、市販の参考書も存在しないようなマイナーな分野です。）

うまく説明できないのですが・・・
例えば、人の話を聞いて理解する時や、本を読んで内容を理解する時などは順番に頭の中で単語を理解したり文脈を理解／推測しながら全体の内容を把握していく、というような感じだと思うのですが、それがプログラミングの場合だと何をどこからどのように考えていけばいいのか、いわゆる思考のプロセスのようなものが分からないのです。どこから考えていけばよいのか考えているうちに頭が混乱状態におちいってしまう、という感じです。
今回のように新しい言語の仕様を覚えていくのが特に苦手で、自分は頭が固いせいなのか言語に付属しているヘルプやチュートリアルのようなものを参考にしても、とても分かりづらい日本語で書かれている場合が多く、何度読んでもすんなりと頭にはいってきません。VBやJAVA、SQLなどのメジャーな言語であれば初心者向けに分かりやすく解説された参考書や勉強サイトなどが膨大にあるので今まで何とかなってきたのですが、今回は言語がマイナーすぎてそういった情報が一切なく、ヘルプを調べたり上司に聞くしか調査する手段がありません。

結局ゆきづまって上司に聞くことが多いのですが、答えを聞いたら以外と単純なことだったり、「なるほど！」と感心してしまうばかりで、自分はなぜそんなことが思い浮かばないのだろう、考えられないのだろうと思うと、そのたびに落ち込んでばかりいます。

当カテゴリにはプログラミングを職業にしていらっしゃる方も多くいらっしゃると思うのですが、プログラミングが上達するコツや考え方のプロセスなど、苦手だったプログラミングが得意になった方の打開策や思考法などがありましたら、是非とも参考にしたいと思いますので、アドバイスよろしくお願いいたします。

回答No.2

tasshi_ · ベストアンサー

こんにちは．

私はそれほど長い業務経験はないのですが，プログラミングは得意な方だと思っています．

DBMagicという言語（というよりツール？）は知らないので，憶測で話をしてしまい申し訳ないのですが，
かなり特殊な言語のようなので．最初はできなくても別に悲観する必要はないと思います．
上司の方も，昔は同じような経験をしていると思いますが，どうでしょうか．
普通，一度同じようなパラダイムの言語を学んでると，新しい言語を理解するのは早いですが，知らないパラダイムの言語はなかなか覚えられません．
たとえば，C++で多くの経験を積んでいる人でも，Javaを学ぶのは楽だと思いますが，
SQLやPrologのような言語を学ぶのは，結構苦労します．

次に新しい言語を学ぶ時ですが，私の場合とにかく適当なサンプルコードを写して実行させて動作を見たり，
改良しながら書き方を覚えていきます．
仕様書的な本は，ある程度プログラムが書けるようになって，理解を深めたいときくらいしか読みません．

とにかく，「よくわからないけどこうすれば動く」というようなことをたくさん覚えて実務を積んで，
徐々に言語や開発環境に対して深い理解をしていくのが，新しいプログラミング言語を学ぶ近道だと思っています．
（わからないコードを理解するのは，実行させて途中経過や最終的な結果を見るのが結局一番早いです．．）

また，ロジックを考えるのは，言語依存ではない部分も多いと思うので，ご経験のある言語で実装されたアルゴリズムの本
を一冊読むと良いかもしれません（できれば名著と呼ばれる本を）．
そこに書いてあるアルゴリズムが直接役に立つことは少ないと思いますが，参考にするべき考え方はたくさん学べます．

人並みの意見かもしれませんが，何か参考になれば幸いです．

回答No.4

akaginoyama

趣味のプログラマーですが
私も、長い事プログラムが上達せずに悩んでおりました。
最近急速にいままで理解できなかった部分が解るように
なっていたので自己分析しておりました。
参考になればと思い投稿させていただきました。

■プログラムが上達しなかった時
1.細部から入り全体を見ていなかった。一つの命令の理解を一つの解説等からその場で理解しようと
やっきになっていた。

2.理解出来ない、ソースは打ち込まなかった。
ソースは理解できてから打つ物だと決めつけていた。

3.複雑に問題が絡んでいた。
命令が解らない＋アルゴリズムが解らない＋やりたい事がぼやけている
と言った具合に複数の問題が絡んでいた。

とまあ、主な原因はこんな感じでした。
これらを下記の様に改善したら劇的に変わりました。

■変わった点
1.全体を見る事でこう変わった
いまやろうとしている事ではなく先に必要になる
部分の情報収集を休憩がてらやっておく事で、それに
取り掛かる時には用語等が頭の片隅にあり、解説を見た
時に何を言っているのかイメージがつきやすくなった。
さらに、全体を見て無理そうな部分を前もって把握出来
別のやり方を用意する準備時間が取れる様になった。

2.理解出来ない、ソースも打ち込む様になった。
解説書などは、英語から翻訳された物が多く、難しい表現
なので命令の動作を勘違いているケースが非常おおかった。
最近は野球やバスケットを習うように自身で実行することが
多くなった。これはキャッチボールと言う簡単な動作でも
言葉や文章で習う事を考えればどれほど複雑に書かないと
いけないかを考えればよいと思います。
手の角度や力の入れ具合等数字で言われても理解出来ない様な
事に近い。

3.複雑に問題が絡んでいたのを問題整理、分解した。
2つ解らない部分があると2倍の時間がかかるだけと思っていたけ
ど、実際にいくつかの作業でみると解決するのに4倍以上の時間
が掛かっていた。挫折した作業を思い出してみると３つあった。

一つの解らない所は、予想やトライアンドエラーでさほど苦労無く
解決出来る事にきずいたので、問題を一つに絞り込む事に全力を
使った、半年掛かっても解決できなかった問題もあっさりクリアできた。

忙しくても、上記の様に自信の問題を調査してみる事が最も近道だと
思います。

■独り言
ちなみに、コードを入力してみるとか、問題を切り分けるとか
全体をみるとかと言う事はたくさんの本や人が言っていた気が
しますが、私の場合は単に実践出来てなかったのです。

私は、まだ、たくさんの事も見落としていると思いますが
みる目や聴く耳をもっと磨いて行きたいです。

お互いがんばりましょう。

回答No.3

don_go

言語の仕様をマニュアルや参考書に書いてある単語や文脈の
意味を理解／推測しようとする事は案外効果が薄い物です。
単語の意味を追いかけるのではなく自分がやろうとしている
事を実現する為にはどうしたら良いかを考えるべきです。
例えば、日常的な挨拶の言葉を他国の言葉ではどう言うかと
いう様に。

データベース処理にしても
1)データベースに接続する。
2)データベースをオープンする。
3)SQL文を作成して実行する。
4)データを取得する。
5)データベースをクローズする。
6)データベースの接続を解除する。
といったのが基本的な流れとなりますが、これを
1)トランプを棚から出してくる。
2)トランプをケースから出す。
3)指を鳴らす。
4)カードをめくって見る。
5)トランプをケースにしまう。
6)トランプを棚に戻す。
の様に、自分にとって身近な事に置き換えてみると、何を
しようとしているかがイメージしやすくなります。
後は、マニュアルから該当するコマンドを探してくるだけ
です。
＃データベースの種類が変わったとしても基本的には同じ
＃様な事しかしていません。

回答No.1

sgwjn

このような考え方については、個々人によって適した方法は異なると思いますので、こうすれば良いと言った明確な答はないと思います。

個人的には、処理全体を初めは大きく、その後細かく分割して考えていくことが多いでしょうか。最初から実装レベルで細かく考えていくと、全体像を把握しにくくなりますから。
英語を訳すときに、文の頭から訳していくのではなく動詞以前（主語）、動詞（否定かどうかとか）、動詞以降（その他修飾とか）などのブロックに分けて考えるようなものです。

例えば、数字をソートするプログラムを作るとします。
大まかに処理を考えると、『入力』→『ソート』→『出力』となりますよね。
その次に、各処理をもう少し細かく考えます。
例えば、入力であれば
『入力値の受取』→『入力値の健全性検査』→ データをソート処理へ送る
のようになると思います。
その後、また各処理をもう少し細かく考えて行き、最終的にプログラミング可能なところまで落とします。
この例で言えば、『入力値の受取』は、例えばCではscanf()を終了条件が満たされるまで繰返す方法などが考えられます。ファイルから読込むかもしれません。
『入力値の健全性検査』では、少なくとも数値に変換できない入力値はエラーとなるでしょう。エラーがあれば、メッセージを出力して処理終了となるかもしれません。

このように、慣れないうちは段階を踏んで徐々に細かいところまで考えていくようにすれば、自分の考えを少しずつまとめながら作業を進めていけるので良いのではないでしょうか。それに、この類の考え方は、フローチャートも比較的書き易いのではないかと思います。

あと、新しい言語を覚える時ですが、私は特にチュートリアルやリファレンスを読んで、詳細な言語仕様やAPIなどを覚えたりはしません。
一番最初は、各種変数と関数の宣言方法、代入文、演算子、条件分岐（if）や反復処理（for）の書き方を覚えるくらいです。基本的に、これだけ押さえておけば大体の処理は書けます。その後で、必要に応じて標準関数やクラス、言語特有の処理（ポインタ、構造体、継承とか）などについて調べていきます。
これもアルゴリズムの考え方と同じで、初めに大まかな基本を押さえて、必要に応じて徐々に細かく調べていくということです。

初めから一度に何でもかんでも手を出しても、効率は余り良くないですし、不要な部分にまで時間を費やしてしまうことも少なくありません。
初めてのこと、慣れないことについては、最初は最小限のことから始めて、必要なときに必要なことを調べる、それを繰返して段階を踏んで進んでいくのが、結局は一番効率が良いのだと思います。