（１）必ずしも理解する必要はない。サンプルが応用できれば良い
実務上では、コンピューター言語を理解して、まっさらから作るという練習をするより、サンプルを見つけて、それを一部変えて完成品を作るという練習をしたほうが良い。理解しようとすると、実務上時間はないし、そもそも、理解できるように書いていない場合もある。自分より頭のいいやつが本気で書いたプログラム（ヘタウマで書くのが普通なのだが、分けわかんないやつは、こーいう風に書くこともある）は、バカには分からない。一生わからない。でも使える。
うそだと思ったら、fopenで、何をやっているか、つまり、どのようなシステムコールを発行し、どのようにアクセスしているか、あなたは言えるだろうか。でも、fopenを使っている。ほとんど問題はない。どうして使えるか。。それは、サンプルがあるからだ。
サンプルを書き換えるだけなら、言語の種類は問題ない。逆引きマニュアルでサンプルを見つけて、それをかえるだけでいい。
そもそも、「いや、コンピューターは理解が必要だ」と豪語している人がどこまで理解しているか疑問だ。「おれはお前らより知っているんだぞ」というエリート意識を自己満足させるために、中途半端な知識を持っているやつが言っている場合もおおい。本当に知識を持っている人間は、すべてのコトは理解できず、自分の理解の境界線を知っていて、その境界線を拡張するように努力する。そして、そのたいへんさを知っているので、他人に理解を求めないのが普通だと思う。
（２）コンピューターは理系・技術者より、文系・経理に近い
ということは、コンピューターは理系というより、文系の簿記の授業に近い。
基本的なサンプルプログラムをまず、電卓でたたいて確認し、その後、その手順を練習問題でこなしていくというやり方だ。
ある程度練習問題をこなせば、新しい問題、応用問題もこなせるようになる。
理解するのではなく、問題をこなせば、出来てくるようになる。
だから、普通の業務のプログラムは、理系・技術者より、文系の経理担当者に近い。（理系の技術者が必要な分野もある。新たな画像処理方法の開発等。しかし、それはごくわずかの分野に過ぎない）
（３）動くが勝ち
どんなに理屈をこねられても、
どんなに努力しても、
どんなに理解できても
動かなかったらおしまいである。
逆に、サンプルを見てつくっても、それで動いちゃえばOKである。
動くが勝ちだ。
（４）オライリーの本を推薦する人に注意しろ！「超図解」「できる」で済む場合も多い
この業界でオライリーの本（動物や昆虫の絵が書いてある本）をやたら薦める人に注意しろ！そういう人は、技術に自信を持ち、エリート意識を持った、中途半端に知っている人が多い。そういう人に質問しても、専門用語を振りかざされて終わりだ。最悪、技術にプライドを持っている（これがなぜ、最悪なのかは、（５）で書く）
再度言う。動くが勝ちなのだ。
動かなかったら、どんなに難しい本を理解できてもダメなのだ。
そういう意味では、多くの場合、「超図解」シリーズ、「できる」シリーズの本で済んでしまうことも多い。それなら、その本を読んだほうが早い。
（５）過去の知識は、マイナスに働くことも多い
この業界は、過去、正しいとされていた知識は、完全否定されてしまうことが非常に多い。
１５年前、フリーソフトを仕事で使うなどといったら、「お前、障害起きたときに責任取れるのか？」といわれて、全人格を否定されるまで怒られた（つーか、クビ覚悟だったな）
今、プロプリエタリなシステムを仕事で使うなどといったら、「お前、なにかんがえているんだ」といわれて、全人格を否定されるまで怒られる可能性もある（オープンな人たちだと）
この間、何か状況が変わったわけではない。いまだに障害が起きたとき、ソースが公開されていても対応できるといったものではないという事実は変わらない。
ソースが公開されているから自分で修正できる。みんながテストしているから障害が少ない。常に更新されるという幻想と、ソフトにお金を払いたくないという企業の事情の蜜月時代を迎えたので、このような思想になっているだけである。
つまり、過去の考え方は、技術的な進歩とかにかかわらず１８０度変わる。
ましてや、技術的な進歩により、もっともっと変わる（例：昔はメモリをいかにとらないかというプログラムが盛んだった）
ということで、過去の知識は、マイナスに働くことが多い。常に新しい考え方、この業界の勝ち馬的な考え方（それが正しいとは限らない。正しくなくても勝ち馬は勝ち馬なのだ！）にいかに乗るかという軽薄さが重要なのだ！
だから、自分の知識にプライドを持つやつは最悪である。
今、「COBOLではこうだった」といわれてもねえ。。
逆に言えば、今JavaやRubyに自信とプライドを持っているやつも、その考え方が全否定される日が来る可能性がある。ある日突然、何の前触れもなく、オブジェクト指向が全否定される可能性も、０ではないのだ。
（６）マネージャーを目指したほうが得
ということは、今の知識をもとにする、ITアーキテクチャは、常に勉強していなければならない。しかし、この業界は、IPAのITSSを重視している。ITSSにおいて、ITアーキテクチャよりも、プロジェクトマネージャーのほうが上で、さらに、IPAの統計などを見ると、本来、この業界は理系重視ということになっている気がする。
ということは、ITアーキテクチャでは、勉強するための投資が必要だ。（時間の投資は当然必要だが、身銭を切らないで勉強することは難しい。企業は、時代遅れになるまで、過去の知識を身につけさせるため、会社の知識を学習しても、学習が終わったコロには時代遅れというのも多い）
だけど、ITアーキテクチャになっても、そんなに投資しても、マネージャーほどの給料にはならないことが多い。ITアーキテクチャは主任クラスで、マネージャー（課長クラス）の子飼いとなり、うまいように利用されまくり、昇進試験の勉強をする間もなく、子会社に捨てられる（あるいは、社内でオチこぼれになろ）ケースも多い。
むしろ、今後の日本を考えれば、このようなIPAの政策を続けていれば、日本の技術衰退は必至であり、海外へ、プログラム開発を委託するケースも多くなるだろう（いまのように人手が足りないからでなく、技術がないという理由で）。そうなってくると、マネージャー職になって、英語がしゃべれたほうが、生き残れる可能性は高い。
マネージャーとITアーキテクトは必要知識が違う。マネージャーなら過去の知識をもとにプライドを持って、エリート意識で世渡りすることも可能だ（マネージャーの知識はそんなにかわらない。PDCAやQC７つ道具は今でも生きている （＾＾）ｖ ）
有能な子飼いを見つければ、そいつらに仕事をやらせて、自分はCOBOL世界で生きていくことも可能だ（下はものすごーく迷惑だけど・・）
アクセス
トータル
ランキング
