おはようございます。
にゃん太郎さんの危惧、私もよくわかります。
私はにゃん太郎さんとタイプが似ており、何でも作りたいタイプなので、OS・コンパイラ・RDBMS・デバッガ・テキストエディタなどを作った事があります。
全て低機能なもので、本格的なものは今年から作り始めます。
それでも、システムソフトを作る事により、多くの知識が得られました。
やはり作らないと分からないものが沢山ありますし、ちょっと作るだけでも多くの知識が得られるのでシステムソフト作りはいいですよね。
その経験と仕事を通じて思ったのですが、情報処理技術は表面は変化していますが根本はあまり変わっていません。
ですから、技術の継承も出来る筈なのにちゃんとなされていない。
これは非常に憂慮するべき状態ですね。
これは、やはり経営者の怠惰もあるかと思います。
本来これは経営者が考えるべき事でもあります。
経営者は利益が生み出せる会社を作るのが仕事なので、利益の元である技術者が生み出せる環境づくりをしていないとおかしいです。
といっても、技術者の怠慢が許されるわけでもないので、個人的には鍛錬をしていますが、この業界の構造に違和感を感じます。
この業界に於いて経営者とはなんなのかと思えてなりません。

インドリさん、ありがとうございます。

> それでも、システムソフトを作る事により、多くの知識が得られました。

　これはそうだと思います。今はオープンソースでOSやミドルウェアもあるので勉強するなら昔よりも勉強しやすいと思います。実際私もLinuxのカーネルに手を加えて自分で使っています。恵まれているのですが、あまりに恵まれ過ぎて逆に何も考えなくなってしまっているエンジニアが世代を問わず増えているんだと思います。

> この業界に於いて経営者とはなんなのかと思えてなりません。

　インドリさんのようなフリーランスの場合、経営者と技術者が一緒なので仕事をしていったり広げていく上で技術力の向上は不可欠になるので仕事以外の勉強も必須になると思います。しかし、サラリーマンだと自分の仕事をこなせればそれで良いので職場での技術の継承や蓄積にはあまり力を入れない人が多いと思います。特にリストラを考えると逆に蓄積するよりは自分だけで持っていた方が有利と考える人もいるでしょうし、自分の事で精一杯で他の人まで構っていられないかも知れません。

　本当は若手の底上げは脅威ではなく仕事の幅を広げる事が出来るので結果的に自分の負担が減ります。若手を底上げしても人材はまだまだ足りないでしょうし。ほとんどの経営者は分かっているでしょうが、それ以上に売り上げ（仕事）の方が切実になるためプロジェクトを無難に終わらすことだけを考えてしまいます。仕方のない事とは言え両者の隔たりは大きくなります。

　技術の継承や蓄積に興味が無い経営者が多いのは確かなので（その割にスキル不足だと文句を言いますが）エンジニアは自分達でも考えなければならないと思います。

こんにちは。しっぱと申します。

私自身あまり技術力をウリにはしていないのですが、やはりコラムの内容は思うところはありますね。

現在、どこに行っても仕事ができるのはインターネットで簡単に調べてモノが作れてしまうことが一番大きいのかなと思います。

ただ、「工期圧縮」が「予算削減」が当然の世の中になってきて、早期完成のみを求められることが多いですね。
そうなるとコピペで作って早く終わらせる（バグがなくってのは大前提ですが）方が、会社の売り上げには貢献できるのかもしれませんね。

でも、それを続けていくと本質を「調べる」「学ぶ」という行為が身に付かなくなってしまいます。

こういった状態になってしまうと非常に厳しいですね。

私が実際に経験した現場ではインターネットに接続不可という環境がありました。
こうなってしまうと非常にきついです。

あと現在の私がそうなのでお恥ずかしいのですが、eclipse等統合開発環境での補完機能をフル活用してしまっている場合ですね。
今はおそらく現在使っているＪＡＶＡに関しても1から何も見ずに書けと言われると厳しいかもしれませんｗ
（ＳＱＬはほぼ共通なのでどこでも使えますが＾＾；）

こんな技術者ばかりにならないことを祈るばかりです。

私は幸い技術でなく「コミュニケーション」の力を常に磨かざるを得ない状態でしたので「プリセールス」という道で食べていこうと思っていますが＾＾；

返信有難うございます。にゃん太郎さん。
にゃん太郎さんのコラムと返信を読んでいて、株主が短期的利益を求めすぎるとある会社の社長が言っていたのを思い出しました。
その社長によると・・・

要約
株主は基本的に情報処理技術の事を知らず、今ある帳簿や株価しか見ないし長期的利益に興味もない。
今すぐ儲ける事しか考えていないので、こういう不条理な業界になった。

もしかしたらこの教育問題もそういった事が背景にあるのでしょうか？

しっぱさん、ありがとうございます。

> でも、それを続けていくと本質を「調べる」「学ぶ」という行為が身に付かなく
> なってしまいます。

　昔は「本などを探して調べる」→「あたりをつけて試してみる」→「それで良いか判断する」→「OK」だったのが、「ググる」→「取りあえず良さそうなものをコピペ」→「動作してOK」となって来ています。インターネットでは過程の解説って少なくて、サンプルコードがそのまま答えになっている事も良くあるので何も考えなくても良くなっている事が多いです。特にコードは英語が分からなくても読めるのでなおさらです。

> こんな技術者ばかりにならないことを祈るばかりです。

　こればっかりはエンジニアが意識してやる必要があるので自覚がないと難しいかな。特に顧客や会社は結果だけを早期に求めるので。自分も無意識にそうならない様に気をつけたいです。

　銀行とかは今でもインターネット接続はできないと記憶してます。私が前にいた職場では掲示板の類はアクセス出来なかったのでやや不自由だった憶えがあります。現場ではインターネットを切ってしまうか、調べもの専用端末を1台だけ置いておくなどがエンジニア育成には良いかも。非効率と思うのはやはり勉強不足だと私は思うのですが。

インドリさん、ありがとうございます。

> もしかしたらこの教育問題もそういった事が背景にあるのでしょうか？

　教育問題だけじゃなくて世の中の流れが、でしょうね。株は昔は企業にある程度まとめて投資して自分なりの意見を反映させて業績を上げられるように支援する側面がありました。会社の価値と業績が上がればそのまま自分に跳ね返ってきますし、下がれば損します。今は投資じゃなくて金儲けで小口の投資家が増えてきており、言う事と言えば「利益を還元しろ」「何で赤字なんだ」「役員は退陣しろ」ぐらいしか言わないのでそりゃ経営者も利益追求型になると思います。

　個人的な偏見で恐縮ですが、株で利益を上げるなとは言わないが、株で儲けを考えるなら働いて儲けを考えろと言いたいです。行き過ぎたマネーゲームは金銭感覚がおかしくなり、結局バブルやリーマンショックを招き一番被害を被るのは普通に働いて頑張っている人たちです。もっともそれを手助けしているのがITだったりするのが皮肉ですが。

前のエントリーもあわせて、違和感をおぼえます。
おそらく、「簡単」という言葉を、簡単に考えているのではないでしょうか。

C言語では、メモリの確保を行えば、解放するのは開発者の務めです。これによって、リソースの大きさと有効期間を強く意識しなければなりません。しかし、Java や .NET 言語では、あまり意識する必要がなく、リソース管理が簡単になっています。
フレームワークを使うことで、よくある言い回しを簡単に使うことが出来ます。
これら、簡単になったことによって、業務ロジックを考えることに割り当てる時間を増やせます。この、「業務ロジックを考えることに割り当てる時間を増やせる」ことが、すなわち生産性の向上ではないでしょうか。

しかし、業務ロジックは、簡単になりません。

私は、「簡単」という言葉を使う、“営業行為”こそ、諸悪（取り合えず、「悪」にする）の根元かと思います。誰も、“ただのアプリケーション”が作りたい訳ではない。“要望に沿ったアプリケーション”が作りたいのです。フレームワークなどは、“アプリケーション”を作ることを簡単に（より少ない手間、時間で作れるように）してくれますが、“要望を実現する”ことを、簡単にしてくれる訳ではありません。この難しさは以前から変わっておらず、むしろ、より難しくなっています（「リッチ」という要素が加わった）。

知識と知恵は、違います。言語もフレームワークも、知識です。知識は、知恵によって活かされます。しかし知恵も、知識がなければ生きられません。
私は、知恵を使うことを学ぶ機会が減っている、学ぶ機会なく使うことを要求されるようになってきているのであって、「簡単になること」が問題を生み出しているのではないと思います。

携帯から思い付きで投稿。後で訂正するかも。

にゃん太郎さん、こんばんは。

saki1208です。

私自身の考えとしてはですが...
IT技術者の仕事のほとんどは「頭」を使うことだと思っています。
要件に対するシステムの機能、ハードウェア/OS/ソフトウェアの構成、プログラムの
機能の設計/作成など必要となる作業のほとんどは手を動かす時間よりも、頭を使う時
間の方が長いと考えているからです。

しかし、昨今の状況としては短納期化や低価格競争の影響でとにかく時間的な猶予が
なく、事前調査や教育にさえ時間を割くことができない場合が多いと感じます。
ある意味、「ググって、コピペ」のみが正解としか...
# 私自身はそんなことはしませんが、経験の少ない若いエンジニアには多いでしょう
# ね。

与えられた仕様でプログラムを作成するのみの仕事であればそれでもこなしていける
のでしょうが、仕事の幅が膨らみ設計などを行うようになると困るでしょうね。
当事者だけではなく、一緒に仕事をする人全員が。

そうなってから気付いても遅いのですが...

Jittaさん、ありがとうございます。

> 「簡単になること」が問題を生み出しているのではないと思います。

　本筋はおっしゃる通りだと思いますが、現実は問題の一端を担ってると私は考えます。効率化というか生産性を手っ取り早く上げるには「簡単」にしてしまう事でしょう。現在はとにかく納期が短くなり、短くなるという事は同様に価格も下がる傾向にあると言えます。現場にそれが求められる以上、とにかく手を入れる手間を省けるだけ省いてとなればエンジニアと言えど余裕がなくなり、簡単な方、楽な方に流れていく事は必然だと思います。それは機能実現だけを目的にSQLを覚えずにO/Rマッパーを使うのと同じだと思います（あくまでも例えです）

　簡単と言うか、エンジニアの考え方が短絡的になっているんでしょうね。それは顧客も同じなので結局そうならざるを得ないのかも知れません。

> 私は、知恵を使うことを学ぶ機会が減っている、学ぶ機会なく使うことを要求される
> ようになってきているのであって

　にわとりと卵の関係ではないですが、これがエンジニアの負のスパイラルなんでしょうね。これはググるなど結果を知る手段が容易になった事でこれからも加速するんじゃないかと危惧しています。

saki1208さん、ありがとうございます。

> IT技術者の仕事のほとんどは「頭」を使うことだと思っています。

　本来はそうなのですが、プログラムを組む方はとにかくロジックを考えるよりロジックを「探す」方に一生懸命になって、設計はとにかく読んだ人が分かりやすい様に文章や絵をどうやって入れようかということに一生懸命な気がします。ドキュメントを書いてもなかなか行間を読んでくれるエンジニアが少なくなったので最近は本当に細かくモジュールを分けてあまり余計な事を考えなくてもいい様に書いています（あくまで今の私の場合）

　過保護でもダメだし、ほったらかしてもダメなのでそれならどうしたら良いんだろうか、と言うのが悩みなんですよね。だからなるべく結果だけを見ないようにコードチェックやレビューを欠かさない様に心がけています。

１つ前のコラムからの継続ということなのでこちらでコメントしますね。

私は今も昔も、プログラムに関連する仕事をしている人のやっていることは本質的には変わっていないと思っています。
違うのはプログラムに使える部品の大きさと、完成させるべきプログラムの大きさだけじゃないかな？
どちらも昔に比べたら巨大になっていると思います。
細かい部品で小さなプログラムを作っていた時代と、大きな部品で大きなプログラムを作る時代の違いですね。
どちらも、部品を上手に組み合わせて使うことができるかどうかだと思います。
望んだ部品が無い場合に、どうするかってのも昔と変わらないでしょう。

古い人間は、大きな部品を構成する小さな部品を知っているだけです。
大きな部品のまま使っているのならば、小さな部品のことは知る必要がありません。
小さな部品を知っていることで、大きな部品の特性がわかるかもしれません。
小さな部品を知っている人は、その特性を使うことも可能でしょう。
しかし、大きな部品の中身が入れ替わる（構成が変わる）場合も考えれば、そのような特性を前提にされると困りますね。
結局、大きな部品は大きな部品として扱うのが正しいでしょう。
もちろん、部品そのものを作りたい場合は、話が別ですね。

部品を使いたい人が、部品の作り方を学んでも得られるものは別のものだと思うのですよ。
それ以前に、部品の使い方がわからない人が、その部品を作り出すことは難しいでしょう。
だから、使い方を知るために、作るということの意味は、あまりないのではないでしょうか？

「.NETを使う人は、.NETが作れるぐらいじゃないとイケナイ」

私には賛同できません、「極端」に書いて解りやすくすることも必要でしょう。
しかし、例が悪ければ、それにより賛同する人を減らしていると思います。

プログラムを作るということは、論理的に考えたものごとを特定の形式に当てはめることじゃないかな？
言語だったり、フレームワークのルールだったりね。

論理的に考えれるかどうかがもっとも重要なことだと思います。
これは、センスが必要なことで、このセンスが無ければプログラムを作ることは難しいですよね？
でもって、このセンスが無い人は昔からたくさんいるわけですよ。

特定の形式に当てはめることにもセンスが必要です。
どんな部品を選択するか、この選択に失敗するとしなくてもよい苦労を背負うことになりますね。

部品が大きくなって、これらのセンスの無さがわかりやすくなっただけじゃないんですかね？
コピペでＯＫとしている人は、そのいい例でしょう。
説明できないコードが存在している時点で論理的な思考ではなく、感覚的なものでコーディングしていることになると思います。
まぁ、たちが悪くなると、それでわかったつもりになってたりするわけで(^^;;;;

エンジニアが育たない？
そんなことはないでしょう、情報収集が昔とは比べ物にならないぐらいできる時代ですよね。
学習の基本は、教えてもらうことではなく、自分で学ぶことではないでしょうか？
学ぶチャンスは昔よりも沢山あると思いますよ。
特にサンプルとなるソースの入手が容易になっていることは大きいですね。
解りにくい仕様も、サンプルにより理解できることが多いと思います。

情報が増えると、センスが無い人は、わかったつもりになりやすいですね。
ソースを見て、わかっているつもり。
サンプルをうつして、わかっているつもり。
新しい用語を知っているから、用語を知らない人よりもわかっているつもり・・・
最新の技術を追いかけているから、わかっているつもり・・・

新しい技術ができたから、さぁ覚えよう？
違う、違う、作りたいものが先になければ駄目。
技術というものは手段であって、目的ではないのだから・・・

にゃん太郎さん

にゃん太郎さんは、「シャイで優しい人」なんだろうと思いました。
　>結果だけではなく過程も大切にしてあげないと、
　>未熟なエンジニアに結果だけを求め、できなかったら責めるような業界では未来は明るくなるはずもありません

今回、上記を伝えたかったんじゃないのでしょうか？（＾＾）

本当に、上記を実践するのは難しい世の中だと思います。余裕がないんですよ。

SIerや企業のシステム部では、ほとんど開発経験をつまさずに、「管理」の
仕事にすぐ廻して、パートナーに、「開発」をさせるというスタイルも多い気
がします。　現場しらずの現場監督ができあがります。
本当に、誰が徳をするのだろう？　と思ったりします。

さて、私は技術を抜きにして、人は「育つものか育てるものか？」を
考える事があります。私は、人は育つものと思っています。
もちろん、教える時に、相手の事を考えて教えないといけないと思います。まだ、
青いのでよく空回りしてます（汗）

山本五十六の言葉
「やってみせ、言って聞かせて、させてみせ、ほめてやらねば人は動かず」
結構、本質ついているなと思います。

色々なコメントが寄せられていますが、皆さん、真剣にコメントを寄せられて
いて素晴らしいです。おそらく、にゃん太郎さんも色々なコメントが寄せられ
ると分かってコラムを書かれたのではないですか？
無用な人格攻撃とかもないですし。これだけ真剣に考える人がいるなら、
そんな未来は暗くないと思いますよ。

すごく楽しめました。　皆様に感謝です。

んー、Sodaさんに書かれてしまったぞ(笑)

10年前、「ゆとり教育」が言われたとき、私は「ゆとりがないのは子どもではない。親にゆとりがないのだ」と思いました。今も、変わっていません。おそらく同じように、余裕がないのは経営層や、ある意味お客様でしょう。その余裕がない状態が末端まで伝播しているのであって、伝播の元を解決することなく、先だけ解決することは出来ないと思います。
今、就学前の子どもがいるのですが、小学校で、「絵本を読み聞かせてください」と言われます。1～2年生の間に、保護者へのアンケートで、「月にどれくらいの本を読み聞かせていますか」というアンケートがあります。
なぜでしょう？
幼児期に読み聞かせることで本に親しみ、就学期に本を読むことに抵抗がなくなるからだそうです。
今の児童にこう言われるということは、今の大人にそうした習慣がないことを意味しています。
問題は、現場で発生しているのではなく、現場で顕在化している（現場以前に問題がある）のではないでしょうか。

にゃん太郎さんがおっしゃることは、確かに問題なのですが、問題の本質ではない、と思います。

Ｓｏｄａさん、ありがとうございます。

　Ｓｏｄａさんのおっしゃられている「センス」などは非常に良く分かりますし、個人としてはそうだと思います。コメントを読んで、全体的に感じるのはそれなりにキャリアのある「デキる」エンジニアから見た意見なのだと感じました（もちろん、本人を知らないのであくまで推測です）

　ソフトウェア開発を趣味ではなく工業製品（を構成するもののひとつ）として考えるならば、私はそこにセンスを持ち出すのはいかがななものかと考えています。好き/嫌いや向き/不向きは自分自身で考える以上は仕方ないのですが、他人に対してセンスの有無を言ってしまうとそこにソフトウェア開発が「選ばれた人（センスがあると思われる人）」のみの職業になってしまいます（さすがにそこまでは思っていないでしょうが）

　ソフトウェア自体、一般の製品に比べると不具合に関しては寛大だと思います。それはモジュールが多く（大きく）なってシステムも単一ではなく連携して複数で関係しあいながら複雑に動作しているからどうしても部分的に「汎用」になりにくい所があるからだと思います。規模自体が大きくなる以上、それぞれ汎用的な部分（OSやフレームワークなど）は出来合いのものを、となるのも必然です。ただ、トラブルがあった場合にブラックボックスだから分からないと言っても顧客はまず「それじゃあ、仕方ないよね」とは言ってくれません。そういう意味である程度はどのように動いているかを知るのは必要だと思っていますが、なかなかそこまで踏み込んでくれるエンジニアは少ないな、と感じているのがある意味私の危機感です。

> エンジニアが育たない？
> そんなことはないでしょう、情報収集が昔とは比べ物にならないぐらいできる時代ですよね。
> 学習の基本は、教えてもらうことではなく、自分で学ぶことではないでしょうか？
> 学ぶチャンスは昔よりも沢山あると思いますよ。
> 特にサンプルとなるソースの入手が容易になっていることは大きいですね。
> 解りにくい仕様も、サンプルにより理解できることが多いと思います。

　これもその通りだと思いますが、情報が昔と比べモノにならないので逆に「育ち」にくいと思います。私やＳｏｄａさんのようにある程度経験があればこれはその通りですが、これだけ正解だけが容易に出てくると学べと言う方が難しいとも思います。しかも本を買って勉強するよりも安価で簡単ですから、それが当たり前の世代ではこっちが育つように考えてやらないとダメだと思ってます。

　もっともそんな中でも自分で育つ輩はいますが。

　いつもコラムを書きながら、極端だなと言う事とすべてがそうでないだろうと言う事だけは私も思います。物事には「全て」と「絶対」はまずありません。私の考えが大多数とも思っていないですし、人によっては同じ会社に長くいればそこの現場が自分のデファクトスタンダードになるために、比較的恵まれた現場ならなかなかいろいろなケースを想像するのも無理だと思います。

　賛同が欲しい訳でも、自分の意見をごり押しして炎上させたい訳でもなく、現状にたいしてエンジニアが「どう考えているのだろう？」という意味でコメントが欲しいと考えています。すべてを正確に把握して書く事が出来るのが一番なんでしょうが、それも出来ないのでなるべくテーマを絞ってフォーカスするようにしています。

　最近は賛同できる、できないは別にしてある程度意図をくみ取ってくれる方もいるのでこれはこれで成功かな、と思います。私だって本気で

> 「.NETを使う人は、.NETが作れるぐらいじゃないとイケナイ」

　ここまでは思いませんが、でもこう書く方が意図がつたわりやすいのかなと思ってます。

　自分が管理者や経営者で無かった時は気付かなかった事も、プロジェクトを束ねてみるとエンジニアとしての考え方やスキル、性格も含めて考えないとうまく回す事が段々難しくなっていると気付きます。エンジニアだった時は他人に対しても「もっと勉強しろよ」「なんでこんなものもわからねーんだ？」と思っていました。そう思ってしまう方が簡単ですし、出来なければ「センスが無い」と言ってしまえばそれで良かったからです。でも、本当はそう人にこそ「理解」してもらえるように努力する事が必要だと思ってます。それこそ技術は手段であってセンス（感覚的なもの）ではないのですから。元々どちらかと言えば苦手だったソフトウェアが好きになり、それなりに理解出来るようになった体験からするとそこはセンスだけではないと思います。

　言いだすと広がってしまってキリがないんですけどね。最近は自分の文才の無さの方が問題だと思ってます。

kumaさん、ありがとうございます。

> 今回、上記を伝えたかったんじゃないのでしょうか？（＾＾）

　「シャイで優しい人」は間違っているような気がしますが、これはその通りです。私はどちらかと言えば短気です。自分が親や先生から褒められるよりは叱られて（鉄拳制裁）育って来たので、若い時は後輩をかなり叱ったりしていましたが、そうすると男性でも泣き出したり（鉄拳制裁は当然しませんよ）いきなり来なくなったりする事が多くなってくるのでいろいろ考えました。自分の育った事と同じではダメだと気付いたのでそれならどうすれば、と考えた事が私のコラムの原点です。

> これだけ真剣に考える人がいるなら、
> そんな未来は暗くないと思いますよ。

　コラム自体は基本的にどちらかと言えば「ネガティブ」な部分を強調するようにしています。本当に明るい未来が無いのなら逆にコラムを書く意味ってあまりなくて、明るい未来が見えにくいからこそあえて明るくするには、という意味も含蓄して書いています。だから逆にコメントで未来は暗くないって書いてもらい、それをいろいろなエンジニアの人に読んでもらえるとそれが一番だと考えています。

　ですから、賛同する・しないではなくてある程度「こういう事かな」と推測してもらった上でいろいろな意見がもらえればそれで良いと思います。私と全く同じ考えの人ばかりではないとは分かっていますので。

　だから、内容的な賛否はあっても個人的には取りあえず成功しているかなと思います。それこそ、感謝しています。

Jittaさん、ありがとうございます。

> にゃん太郎さんがおっしゃることは、確かに問題なのですが、問題の本質では
> ない、と思います。

　そうなんですが、エンジニアライフのコラムと言う事で、エンジニア側からどうすれば良いかという事を考えて書いています。おっしゃる通り、現場以前の問題なんですよね。そうは言ってもエンジニア側に問題がないかと言えばそうではない。もうちょっと突っ込んで書けば経営者や顧客の考え方を変える事っていうのは、私は無理だと思っています。それならエンジニア側から出来そうな事を考えた方がある意味建設的だと思い、コラムを書いています。

　でも、余裕が無いから仕方がないのかと言えばそれって言い訳だと思います。本質ではないからではなく、エンジニア側から変えていける事があればそれをやっていった方が早いのでは、と思います。結局はそれぞれの自覚なのでしょうが、日々余裕のない状況ではやはり先輩が考えなくてはならない問題だと思います。

　教育もそうですが、家庭環境も様変わりしているんでしょうね。昔は「親の背中を見て子は育つ」と言いましたが、今はそうではないんだと思います。これだけコミュニケーション手段が増えると親が黙っていてもそれ以外の所からいろいろな情報が入ってくるので（小さいころから耳年増）親の背中を見る前に自分なりに価値観を持ってしまうのでしょう。それに親子がタメ口で会話しているのを聞くと時代も変わったのかなと思います。私は父親も母親もタメ口で話すと必ず殴られていました。「親に育ててもらってなんて口のきき方だ！」と。当たり前と思っていましたが今は違うんでしょうね。エンジニアの現場もそうなんだと思います。

にゃん太郎様

こんにちは。早希都と申します。
Windows向けのドライバと連動するソフトウェア開発のリーダーだったので、「出来たからいい」と思う部下と、それを認めてしまう上層部に歯がゆい思いをした記憶があります。

部品（フレームワーク）を十分使える事こそ必要な技術だという意見がありますが。
それら「部品」と呼ばれる数多のフレームワークにも、非常に大量のバグが潜んでいます。.NETやWin32 APIもです。

使いこなそうとすればするほど、「バグを発見して対処できる」技術を身につけなければなりません。
バグが直るまで待てず、その部分を「再開発」する場合もあります。納期あってこその仕事ですし。

そうすると、にゃん太郎様のおっしゃる通り、いつのまにか使っているフレームワークと同じものを開発できるレベルの技術に近づいていくんですよね。程度の差はあれ。

組み合わせだけで「開発」できるのはとても幸せな事ですが、その「幸せな方策」しか探せない新人が多い事に、警鐘を鳴らしておられるのだと思います。
実体験からして、部品の中身も知ることは非常に重要です。知り続けていくことが。

私自身Googleフリークで、Googleへのアクセスが多すぎて上司に事情聴取(笑)されるほど、開発の時は辞書として猛烈に使用しています。
でも、インターネットにあるソースコードを「良い」と評価できる能力は、たくさんのソースを読めば身に付くものではありませんし、私にもどうやって身につけるのかも分かりません。教えて欲しいくらいです。

結局私も、上司がひたすら部下のソースコードをレビューして、自分の経験から、ああだこうだと助言してあげる以外に無いのかなと思っています。助言の内容は、まぁその上司にがんばってもらう事にして。

センスがある人はいると思います。一種の天才と思える人もいます。
でも、そういう人がオフィスの端っこで１開発者としてすり減っていたり、下手をすると火消し専門の何でも屋にされていたり。どうやったらちゃんと屋台骨として技術を発揮して、周りの人に広めてもらえるんでしょうね。経営者の方々にはその辺に注力して欲しいです。

早希都さん、ありがとうございます。

> 組み合わせだけで「開発」できるのはとても幸せな事ですが、その「幸せな方策」
> しか探せない新人が多い事に、警鐘を鳴らしておられるのだと思います。
> 実体験からして、部品の中身も知ることは非常に重要です。知り続けていくことが。

　その通りです、ホントに。まぁ、中身を知らずに余計なトラブルに巻き込まれない幸運な人であればそんな事も関係ないのかもしれませんが。

　Windowsドライバという言葉が出て来たのでちょっと私の経験を書こうと思います（以前、少し触れているとは思いますが）私がドライバを開発したUSB機器が特定の機種の特定の特定のOSで認識されない、という不具合がリリース後に起こりました。出来ないのは後にも先にもそれだけでした。同じ機種でもOS（Windowsのバージョン）が違えば動作しますし、同じメーカーでも機種が違えばそれも動作します。ハードウェア（グループ企業で開発）担当者も上位アプリ開発者も分からなかったので「ドライバでは？」とあたりをつけて相談してきました。そうは言っても原因が分からなかったので、取りあえず動くものと動かないもを並べて上位アプリから順にさかのぼる形で調べて行きました。すると、USBのパケットが途中で認識されなくなっていました（これが「ドライバでは？」と疑われた理由）結果的にはハードのファームウェアがUSBの規格に外れた動作をしており、他の機種ではそれがスルーされていたのがその機種だけ（正確にはUSBのホストコントローラ）がちゃんとチェックしていてエラーになっていただけでした。

　特定の条件なので、場合によっては「ハードウェアとの相性」という言葉で片付けてしまってもWindowsの場合、ナゼか許容される雰囲気はあります。この場合もそうかも知れません。でも、調べて原因を突き詰めた上でどうしても仕方ない時は代替策を提示してお客様に説明すればたいていは納得してもらえますし、この場合のようにファームウェアの書き換えで正常に動作する事もあります。仕組みを知ると言う事はこういう時に対処出来るかどうかだと思います。何でも「相性」で片付けてしまってはやはりプロのエンジニアとしては失格では、と思います。

> センスがある人はいると思います。一種の天才と思える人もいます。
> でも、そういう人がオフィスの端っこで１開発者としてすり減っていたり、下手をす
> ると火消し専門の何でも屋にされていたり。どうやったらちゃんと屋台骨として技術
> を発揮して、周りの人に広めてもらえるんでしょうね。

　あくまで個人的な意見ですが、性格と学歴（大企業は特に）が結構関係しているように思います。上司受けが悪いと優秀でも「便利屋」程度に使われてしまいますし、大企業ではセンスがあっても基本的に学歴優先なのでいちいち個人のセンスなんかお構いなしです。私は新人の頃に別グループのそういう人に結構面倒見てもらってましたが、誰もがその人を優秀と認めていながら、扱いはヒドかったですよ（本人もそれは分かっていて、悩んでいました）

ＩＴエンジニアって「職人」であるべきか、「工員」であるべきか、どっちだと思います？

定義としては、「工員」とは部品を組み合わせることで商品を提供できる人で、「職人」とは部品そのものを作り上げ、商品を提供できる人です。

育成対象のエンジニアが「工員」であるならば、「育てる」ことはできるでしょう。むしろ「作れる」といっても過言ではないと思います。ですが、「職人」ならば、「育てる」ことはできないと思います。育つ環境を周りが用意できると思いますが、本人に意思がない限り無理でしょう。１６年しかこの業界で働いてませんが、そう思います。

もっともベーマガ見ながらコーディングして、手直しして・・・を入れたら人生の半分以上、浸ってますが（汗）

CMPさん、ありがとうございます。

> ＩＴエンジニアって「職人」であるべきか、「工員」であるべきか、どっちだと思います？

　私個人の意見としては、

　　理想：「職人」であるべき
　　希望：「職人」であって欲しい
　　現実：「職人」と思い込んでいる「工員」が多い

　でしょうか。まぁ、コラムもそうですが統計を取った訳でもなく、何百社というたくさんの現場を知っている訳ではないので、自分の周辺や見聞きした感じですが。育てるのは難しいですが、育てる土壌は用意してやれると思います。ただそれと芽が出て花が咲くのとは別物ですけど。一度にたくさんは無理ですが、少ない人数からエンジニア個人の性格に合わせて教育してやればある程度「使える」エンジニアにはなると思います。そこから先は本人のやる気ですが、せめてそこまでは「育ててやる」事は必要と思います。育つのを待ってても育つエンジニアを待ってても仕事は待ってくれませんから。

# 余談ですが、お名前をみて思わず「CP/M」を思い出しました。知ってる人、少ないだ
# ろうなぁ。

にゃん太郎様
高速レスをありがとうございます！

>結果的にはハードのファームウェアがUSBの規格に外れた動作をしており、
>他の機種ではそれがスルーされていたのがその機種だけ
>（正確にはUSBのホストコントローラ）がちゃんとチェックしていて
>エラーになっていただけでした。

ドライバやファームウェアもある意味広義のフレームワークですね。
「相性」とか便利な言葉が氾濫する時代ですが、組み込み開発者だった（今は主にWeb開発ですが）時代には通用しませんでした。それは仕方が無いね、でもなんとかしろ、と。
でも、それはどの分野の開発者でも同じですし、同じであるべきだと思います。

相性の関係無い製品を作るのは不可能ですが、相性だから知らない、と突っぱねる人間は、個人的に技術者の風上にも置けないと思います。
企業としては仕方なくとも、その中の技術者達までが同じでは話になりません。
あっという間に「知らない」の範囲が無限に広がっていくと思います。

極端な物言いになりました。申し訳ありません。
まぁ20代半ばのシステム屋に言われて動く人間などあまり居ないのですが。

>あくまで個人的な意見ですが、性格と学歴（大企業は特に）が結構関係
>しているように思います。

確かにその通りだと思います。
経営者には人を見る力が云々、とか言いますが、本当に会社の中の人間を正確に評価できる経営者などいないですし。結局好みが強く反映されますよね。嘆

筋肉質な会社が生き残る、とか言いますが、結局身体は使いこなしてなんぼなので、特に頭脳労働が多い、開発に関わる企業には、人間やそれぞれのセンスを生かす方法を考えて欲しいです。

>にゃん太郎さん
>ソフトウェア開発を趣味ではなく工業製品（を構成するもののひとつ）として考えるならば、私はそこにセンスを持ち出すのはいかがななものかと考えています。

私はセンスも技能だと思っています。
どの職業でも、成功するには、その職にあったセンスは必要なんじゃないかな？
ソフトウェア開発はセンスがなくてはできない職だと思っています。
機械的にプログラムが作成できるのならば、人間はいらないでしょ？ｗ

・・・で、このセンスは鍛えることが可能なのですよ。
自分から学びたいと、向上心があればですけどね。

>ソフトウェア自体、一般の製品に比べると不具合に関しては寛大だと思います。

どちらかといえば、修正が簡単にできると思われているからーだと思ったり(^^;
ただ、見つかった不具合は修正することになることが多いですよねぇ。
不具合がでるのは、仕方が無い、修正すればＯＫってなだけかと。
修正できなければ駄目なわけで、最終的には完全に近いものしなければならず、ある意味ハードよりも厳しいのかもしれませんよｗ

>これもその通りだと思いますが、情報が昔と比べモノにならないので逆に「育ち」にくいと思います。

情報に埋もれるのは、目的がはっきりしていないんじゃないかなぁ。
今も昔も、目的が見えてない人は必要な情報を得るのがヘタなわけで(^^;

>ここまでは思いませんが、でもこう書く方が意図がつたわりやすいのかなと思ってます。

うーん、現実的ではないけれど理想としてそう考えているということですかね。
ブラックボックスに対する考え方の違いなのかなぁ。

早希都さんとのやりとりとも関係しますがー
ブラックボックスにバグがあった時の為にも、ブラックボックスの中身を知っておいたほうが良いと考えてるように見えます。
私は、ブラックボックスの中身を知る必要性は無いし、知っていても意味が無いと思うのですよ。
知らないといけないのは「仕様」だけです。
私なら、仕様通りに動かないブラックボックスは使わないという選択をしますね。
使わないのはブラックボックスの一部かもしれないし、全体かもしれない。
なぜなら、ブラックボックスに手を加えることができない場合が多いからです。

それに、ブラックボックスにバグがあるかどうか疑うのは最後ですよね？
おかしいのは、ブラックボックスを使っている場所なのか？
そして、それを仕様通りに使っているのか？
色々調べて、最後の最後にブラックボックスを疑うことになるんだと思います。

・・・というか、ブラックボックスを疑ってたらきりがないですよねｗ
ハードなのかもしれないし、コンパイラのバグなのかもしれないｗ

お二人の会話の中にある「仕組み」というのは「仕様」の割合のほうが高いと思います。
私はブラックボックスを作る（修正する）立場ではないなら、ブラックボックスの中身（コード）を知る必要性はないと考えているのです。
全てを知っている必要は無く、わからない時に知ることができれば良いという発想です。

そして、「仕様」をわかっていない人がブラックボックスを作ることは不可能だとも考えます。
「仕様」をわかっている人がブラックボックスを作るから、その「仕様」に対する理解が深まるのではないでしょうか？

考え方のイメージとして、ボトムアップなのか、トップダウンなのかという違いなんですかね？
後は、知らないということに不安を感じるかどうかなのかな？
おそらく理想だと思っていることが違うだけで、「駄目だ！」と思っていることは同じようなことなんでしょうね。

ＰＳ．
>キャリアのある「デキる」エンジニア

錯覚ですｗ
SQL、UML、ER図、STL・・・知らないことのほうが多いですねぇ。
開発が主にWindowsであり、データベースが必要となるような開発したことないしｗ
だから私からみるとIT業界って異次元ですよｗ
CP/Mはー動いてるとこ見たことはないですねぇ・・・8インチFD時代ですよね？ｗ

>CMPさん
>ＩＴエンジニアって「職人」であるべきか、「工員」であるべきか、どっちだと思います？

どうあるべきかってのはー個人の目標によって違うんじゃないかな？
研究開発に傾く人は「職人」ですね。
お客の近く・・・というか、営業やデザイナーに傾く人は「工員」かな？

時代が進むにつれて、「工員」が求められるようになるんじゃないですかね。
お客にとっても、わずかな「職人」と多くの「工員」が理想できかな？

まぁ、さらに時代が進めば「工員」の仕事は、お客でもできる仕事になるのかもしれませんが(^^;

Soda様

>私は、ブラックボックスの中身を知る必要性は無いし、知っていても意味が無いと思うのですよ。
>知らないといけないのは「仕様」だけです。
>私なら、仕様通りに動かないブラックボックスは使わないという選択をしますね。

返答するべきか悩んだのですが…。やっぱり書いておきます。

ええと、Sodaさん、率直な言い方をします。怒らないでくださいね。

おそらくSodaさんはシステム開発を「一社員として」したことがないのでしょう。
企業内でフレームワークを選定する人間は、通常開発者個人ではありません。
選定者は所属企業であり、お客様であり、チームの上の方のリーダーです。

で、プロジェクトリーダーは「使え」と言われたOS、フレームワーク、開発環境を使い、何があっても約束の品を期限内に作成し、テストを完了して納品しなければならないのです。これは当然ですね。仕事ですから。

また、特に私はドライバも開発していたせいもあるのですが、実はWindowsそのものにも大量のバグが残っています。デバイスドライバも然り、ハードウェアに搭載されるファームウエアにもバグが有ります。
当然、フレームワークと呼ばれるプログラムも例外ではありません。フレームワークと呼ばれるだけでバグが無くなるなら、こんなに幸せな事はありませんね。

でも、仕事で「Windowsのバグなので仕方ありません」は通用しません。
問題を塞ぐパッチか独自処理を自分で書いて、無理にでも完成させる事になります。本来APIなら２行で済むはずの処理が、APIのバグのせいで数100行になった、なんてこともよくある話です。

場合によっては、本来すべきでない制御や処理をしてでも、結果として正常に動作させなければなりません。ハードウェアのバグでは、そういう回避しかできないこともあります。

それで、結局「部品」といっても、絶対どこかにバグが有るし、それに対処するには基礎的な技術力も必要、という話をしていたわけです。
OSですらその状態ですし、世の中の「フレームワーク」の開発者向けバグリストを見れば、多分何を言いたいか理解してもらえると思います。

もちろん、最初から使っているフレームワークを疑うのはおかしな話です。
自分で設定を間違っているのに、フレームワークのバグだと思って勝手に回避処理を書き始める新人もいますしね。これは本末転倒です。

まぁ、こういう目に見えない部分の苦労がつきまとうので、ソフトウエア開発は一向に楽にならないんですよね。結局表面部分しかユーザーには見えないわけで。
そこが、このコラムの主題「ソフトウエア開発に幸せな未来はあるのか」になっているのでしょう。

Ｓｏｄａさん、早希都さん、ありがとうございます。

　なんだか前回のコラムの内容に対してのコメントみたいになってきましたね。私は現状ではＳｏｄａさんのおっしゃる事の方が大勢だとは思います。ただし、早希都さんのおっしゃる事もまた現実です。

　ソフトウェアに100%バグがない、と言い切れないのは誰しも思っていると思います。つまり正常に動いているのはバグがないからではなく、バグが表面化しないだけだという事です。フレームワークにしてもOSにしても覚えはあるでしょう。1つ1つは問題がなくても組み合わせる事で出てくる問題もあります。これらはソフトウェア特有の問題かも知れません。

　どっちが…って言うと今はどっちもになっているんでしょうね。言い換えればよそのせいにして終わってしまうか自分が尻拭いするかだけでしょうから。

　エンジニアの気概としてブラックボックスはこじ開けるぐらいの気持ち（本当にやったら場合によっては犯罪なので）は常に持っていて欲しいというのがある意味私の希望です。エンジニアの醍醐味って言うか誇りは技術的な引き出しを増やす事だと思うので実際にやるかやらないかは別にしてとにかく貪欲に知識を求めて欲しいです。確かに知識だけではダメで知恵は必要ですが、ITの場合は知識があって初めて知恵が生かせると私は考えています。

　この問題はこれだけソフトウェアが複雑になってくるとなかなか難しいんでしょうね。だからこそ考える必要があると思ってます。

>早希都さん

んーー同じことを言ってると思うのですがー書き方が悪かったかな？
引用部分の次に

>使わないのはブラックボックスの一部かもしれないし、全体かもしれない。

って私が書いた部分がそうなんですよ。
開発環境が限定されている場合は、一部を使わないことになりますね。

で、バグの話はーちと、このコラムの本質的な部分からズレた感じがするんですけど・・・
バグの特定技術はまた別の話・・・じゃないのかな？
本来あってはいけないことだし、致命的なものは公開されてることも多いですし(^^;

「部品の動作が仕様通りではない」

仕様がわかっていれば、仕様通りかどうかは判断できます。
「なぜ」仕様通りではないか？を追求する必要があるかどうかは、ケースによりますよね。
「バグを判別するために、部品の中身を知らなくてはいけない」というのは、そのうちの１つでしょう。

究極のところ、「理由はわからないけれど、仕様通りに動かない」という状況に対応できる必要があるわけで(^^;
どこに原因があるかという切り分け技術は、中身を知らなくてもできないといけないですよね。
ですから、バグを例えにして中身を知っていたほうがいいというのは、ちと弱いと思うのですよ。

本質的には同じようなことを言っているんだと思うのですが・・・
違うのは、ブラックボックスを開けるタイミング。
私は、ギリギリまで開けるべきではないと考えているってことです。
そして、仕様がわからない人が開けても得られるものは少ないと考えているんですよ。

わかっている人が開くから意味があるのであって、わからない人が開けても駄目じゃないか？ってことです。
それは、中身が知りたいと思う人が、中身にあたりをつけて調べるから意味があるのではないかと。

仕様を理解せずにＯＫとしている人に対して、どう改善できるかという趣旨のコラムだと思っています。
そして、その改善案として提示されている内容では改善されないのではないか？と疑問を持っているということです。

「駄目な奴は、なにやっても駄目」という迷言があります。

仕様を理解できなかった人がなにやっても駄目でしょ。
まずは仕様を理解しようという努力や、これはどう動いているんだろうと思う疑問をもてないとプログラムを書いていくのは厳しいんじゃないかなーと思うわけです。
これは、周りに強制されても駄目なんじゃないですかね。

本気で困るのはー本やソースコードをみてわかった気になってしまう人とかだったり(^^;
無から有を作り出すのが一番難しいことだということに気がつかず、覚えたこと（暗記に近い）が技術力だと錯覚しているのです。
知っているということと、使えるということは別なんですよねぇ。

ＰＳ．
小さな部品を知っている人が見るから、大きな部品は小さな部品の集合に見えるのですよ。
小さな部品を知らなければ、大きな部品は、分解しようがない最小の単位になるわけです。
どれが大きな部品なのかは、時代によって変わります。
古い時代の人間からみたら、大きな部品しか扱わないことに不安をもつのは当然でしょう。
しかし、大きな部品で困ることがない限り小さな部品は登場しないですし、大きな部品も困らないような仕組みが残される場合が多いですね。
持たなくても良い不安を持っている・・・そうは思いませんか？

ＰＳ．２
VS2005、MFCのバグで悩んだことはありますよー。
たしか、印刷するページ範囲が反映されないようなバグで、公式にも上がってたような記憶がー。
自分のコードのなにがいけないのか、散々調べたのに、間違いらしいものが見つからず、同じ症状の人がいないか検索したら見つかったという(^^;
一度バグと遭遇すると、頭の片隅に「またバグなんじゃね？」とよぎるのが、自分の弱いところですｗ

はじめまして。榊と申します。

おそらく私はその『「横着」なエンジニア』の部類に入っていると思います。
「どういうことかわからないけどなんとか動いた」
というままで思考放棄していたことがありました。
でもコードレビューなどで説明を求められたときに説明できず
様々な突っ込みを受けて凹んだ記憶があります。

「コピペでもそれを使った自分に責任があるから
　すべて説明ができるようにしろ」

と先輩に言われたことがあります。
「結果に対するプロセスが正しいものだったかどうか」
意外と確認していくと”もやっ”と放棄していたものが
すっきりして楽しかったです。
食わず嫌いだったのかもしれません。

今でも放棄してしまいそうな気持ちがよく沸き起こりますが＾＾；
先輩・上長からせっつかれるのを恐れてかしぶしぶでも
にゃん太郎さんがおっしゃられているプロセスを確認するようになってきました。

そして後輩が同じくコピペの功罪を知らぬまま使うシーンを
目の当たりにするようになって不安に感じました。
何か後輩自身に「もうこれだけ情報が多すぎるともう追いつかない」
といった諦めに似た雰囲気が感じられるのです。

この後輩へ自戒も含めて
「あきらめずに勉強していこう」と伝えつつ、自分も進もうと
改めて感じた次第です。

ためになりました。
ありがとうございます。

榊さん、ありがとうございます。

> 何か後輩自身に「もうこれだけ情報が多すぎるともう追いつかない」
> といった諦めに似た雰囲気が感じられるのです。

　昔は逆に情報量が少なかったので、その少ない情報をかき集めて調べながらプログラムを書いていました。今は逆ですね。って言うか「調べる＝ググる」って式が成り立っているのが個人的にはおかしいと思ってます。

　例えるなら、昔は机の上に数えるほどの資料しか推測するしかなかったのが、今は机だけでは乗り切らないほどの資料が大量に置かれている中から探し出すようなものです。しかも資料によって少しずつ内容が異なったりしています。私の様に長い間エンジニアをやっていればある程度区別できますが、経験が浅いエンジニアにこれは酷だと思ってます。

　そういう意味でも「環境」をつくって助言してやるのが先輩の務めだと思います。それに気付いた榊さんは良いエンジニアになれると思います。

　頑張って下さい。

にゃん太郎さん、こんにちは。
前回のコラムでお世話になりましたMASASHIGEです。
日が経っていますが、コメントさせてください。
（前半は前回の話題の続きになってますが）

まず、システムとしての理想を申し上げるのであれば、
使用する部品にバグがあった場合、部品の製造元がその部品を直すべきです。

それが無理だったとしても、開発の作業者一人ひとりが解決を図るのではなく、
その部品を使うことを決めた人が、責任持って修正するなり、回避策を練るなりして解決を図るべきだと思います。

大抵、部品を使用して開発してる段階で問題が発覚するので、
問題を発見した人が責任を負わないといけないような気がしてしまいますが、
こうやって使え、と命令されて用途通りに使って問題があるなら、使えと命令した人が全責任負って何とかしろよ、と思います。
そこを「何とかしろよ、技術者だろ」って投げるのも如何なものかと。（それがまかり通ることは知ってます）
使用する際に相談があって、問題なし、と請け負ったのであれば、
請け負った技術者の責任もありますから何とかする必要がありますけどね。

使うことを指示する側、使用方法を提示する側（管理者やアーキテクト）は、
使用方法を守っている限り問題がないことを保証し、そこで起きた問題を一手に引き受けるべきです。

上記の考えの元、私がフレームワークの担当として作業する限り、フレームワークは私が保証しています。
所定の使い方をして問題がある場合は、私に問題を上げてもらい、私が解決して展開します。
所定の使い方以外をしたい時は申請してもらいます。
開発者ごとの勝手な解決を許しません。
私は解釈の違いなどが起きないわかりやすいドキュメントとサンプルを作成して、
作業者が疑問を持つことなく作業できるように整えます。
そうすることが品質の向上につながると考えております。

これが、フレームワークを組み合わせて使わせているエンジニアとしての私の考えです。
そのフレームワークを利用することを私が決定することは少ないですが、
開発メンバーで一番にフレームワークを解析し、カスタマイズし、
サンプルとドキュメントを作成し、他のメンバーに展開する、という作業を行ってきた上での考えです。

入社した当初から上記のような作業を行う機会に恵まれ、試行錯誤を繰り返して成長してきたと思っております。
（入社するまでHTMLくらいしか触ったことなかったんですが…）

その上で、上手に組み合わせて使うことを「検討する」ことは、エンジニアとしての成長につながると思っています。
問題は、組み合わせが決まった状態で渡されて、「これ使って今すぐ作れ」と言われる状況が多いことかな、と。
（組み合わせを決めて渡している私が言うのは問題かも知れませんが）

エンジニアに必要なことは、問題の解決策を考えることですが、
短納期、高品質が求められる現場では、考えなくても作れる状況が必要です。
その状況に甘んじている開発メンバーを教育するために必要なことは知識を教えることよりも、
考える意識を持たせることですね。

私が入社してすぐ先輩に言われたことは、
「自分の作業すべてにおいて、理由を説明できるようにしろ」でした。
コード一行でもドキュメント一行でも、
何のために行うかをすべて説明できるようにしなくてはいけない、と教えられてきたために、
インターネットから持ってきた情報が正しいことを自分で証明できないことには落ち着かなかったものです。
今、自分の後輩にもこれをしっかり教え込もうとしてますが、なかなか…

ほかの方のコメントの焼き直しにしかなってませんが、
書いたのを消すのももったいないので、書き残します。
コメント汚し、失礼しました。

Ｓｏｄａさんへ
＞まぁ、さらに時代が進めば「工員」の仕事は、お客でもできる仕事になるのかもしれませんが(^^;
私も近い将来、「工員」の仕事は、お客でもできると思ってます。最近のIDEを見れば十分予見できるかと（＾＾；）

だからこそ、お客では「できない」ことを実現するのが「職人」であり、プロなんじゃないでしょうか？

一流と呼ばれている職人さん達って材料から吟味して商品を提供してるでしょ？
だったらエンジニアも、フレームワークやライブラリ、コンポーネントを吟味して商品を提供できるようにならないとね、と思ってるわけで。ちゃんと吟味していれば、その部品にはどんな特性（または不具合）があるかわかるわけだし。
（そんな時間あるわけないだろ！って突っ込みが着そうな予感ｗ）

こんばんは、saki1208です。

私自身、究極的には「レゴ」みたいになることが理想だと思っています。仕事は
なくなってしまいますけど...
# 現役の間には実現しないだろうと高を括っています。
# 自分自身でできるところまで実現したいと言う思いもありますがw

過去にもどこかで書いたのですが、私自身が苦労して学んできたことを後輩たち
が改めて苦労する必要はなく、正しく継承できればそれでよいと思います。
ただ、いつも使っている便利な道具がその場にないとき、無い物ねだりするだけ
ではなくエンジニアとしてどのような代替手段を提案できるか、自分で作り出す
ことができるかってことを真剣に考えて欲しいと思います。
# ムリだと判断することもありです。

>CMPさん
>だからこそ、お客では「できない」ことを実現するのが「職人」であり、プロなんじゃないでしょうか？

お客でも「できる」ことを、時間や手間の関係で代わりに行うという仕事もありますね。
「工員」の仕事は、そのような場面で期待されているものをより早く、完成させることになると思います。

本質的に「使う」仕事と「作る」仕事は別だと思うのですよ。
ソフトウェア産業って昔は「作る」仕事が主だったと思うのですが、今は「使う」仕事の割合も多いんじゃないですかね？
エンジニアというと「作る」イメージですが・・・元々エンジニアという言葉自体も適切なのかどうか(^^;
今はデザイナーとの境界線があいまいだと思ったり。

>一流と呼ばれている職人さん達って材料から吟味して商品を提供してるでしょ？

どちらかといえば、道具や材料が決まっていて、その中で作らないといけない場面のほうが多いような気がします。
時間があれば、自家菜園で素材から作ることもできるでしょうし、それにこだわるのも１つだと思います。
でも、どんな不味い材料でも、どうにかして美味しい料理にする魔法が使えるほうがもっといいなと思ったり。
「なんでそんなことができるの？」と思わせるプログラムって魔法みたいじゃないですか。
エンジニアになりたい人も多いと思うのですが、私は魔法使いになりたいなと思うのですよｗ

吟味というのが、仕様の把握だけではなく、構造の把握までを指しているのだとすれば、そこまでは不要かなと思います。
それは、使う人からみたら仕様が全てであり、構造は関係ないからです。
バージョンアップしたら構造はごっそり変わるかもしれませんしね(^^;
まぁ、仕様まで変わる場合もあるのが悲しいところですが・・・

特性はー使ってみたらわかることのほうが多いかもしれませんよ？

Ｓｏｄａさんへ
＞お客でも「できる」ことを、時間や手間の関係で代わりに行うという仕事もありますね。
そうなんですよね。ただ、「代行」がエンジニアかって言われると・・・う～んって感じなんです。誰でもできることを、あえて代わりにやってるだけだし。

＞「工員」の仕事は、そのような場面で期待されているものをより早く、完成させることになると思います。
そういう考え方もあるな。勉強になります。

＞本質的に「使う」仕事と「作る」仕事は別だと思うのですよ。
「道具を使う仕事」と「道具を作る仕事」は、確かに別ですよね。でも、道具を使う仕事の人が、その道具がどうできているのか気にならないものですかね？
気にしないのであれば、そこが意見の相違の場所かなと。私は、エンジニアを名乗る以上は「気にすべき」です。

＞エンジニアというと「作る」イメージですが・・・元々エンジニアという言葉自体も適切なのかどうか(^^;
それいったら、ＩＴに関する単語（ｒｙ

＞特性はー使ってみたらわかることのほうが多いかもしれませんよ？
吟味の最終目標は「構造の把握」ですけど、サンプルでも簡易ツールでもいいから、まずはそれを使って何か作ってみようよってことで。
そうすることで、何かを感じるわけだし。（インスパイアされて、よりよい設計になるかもだ）
「単体テストしてたら、このコンポーネントの特性が原因でこんな問題が発生しました！どうしましょ？」じゃ遅いと思うんだよね。

まぁ、何事にも例外あるってことを意識してスケジュールを組んであれば、なんとかなるかｗ

>CMPさん
>でも、道具を使う仕事の人が、その道具がどうできているのか気にならないものですかね？

使っている道具の仕組みが気になるかどうかといえば、人によるんじゃないかなぁ(^^;
多くの場合は、仕組みまでは気にしないと思いますが・・・
家電製品とかだとわかりやすいですよね、道具は使い方がわかればよくて、その仕組みを知る必要はありません。
ライブラリやフレームワークなどの仕組みを知らなくてはいけないのは、それらを作る人であって、使う人ではないと思うのですよ。

仕組みを知っていれば、仕様にない特性が利用できるかもしれません。
その特性を使えることは技術的に高度なことだと思います。
しかし、互換性などを考慮すれば、仕様にないことは変化する可能性があるものだと認識したほうが良いと思います。
私は、仕様に無い特性を利用したソフトは行儀の悪いものだと思っています。
これがブラックボックスを開かない最大の理由です。
ライブラリのバージョンを上げたら特性が変わり、使えなくなったでは困ると考えます。

仕組みを知ること自体は悪いことではないと思いますが、知らなくてはいけない、知るべきだ！といわれると、違うんじゃないかなーと思うわけです。

>それいったら、ＩＴに関する単語（ｒｙ

いや、ITという名称自体もどうなの？って感じなんですけどｗ
こーなんか後から勝手に名称が追加されているんだけど、具体的な定義が特にないようなものって多くないですか？
システムエンジニアとかーフレームワークとかー・・・
横文字の名称がポコポコ増えてるんですよねぇ。
でもって、後から付けられたその用語を知らないと馬鹿にされるとｗ

体感的には、エンジニアってのも後から追加されたような感じなんですよ。
プログラムを書く仕事がプログラマー・・・だけだったのがいつの間にか色々と呼び名が増えていったような感じ？

>吟味の最終目標は「構造の把握」ですけど、サンプルでも簡易ツールでもいいから、まずはそれを使って何か作ってみようよってことで。

「構造を把握」することと「使える」ことは、また別の話なんですよ。
「構造を把握」していれば、うまく「使える」とは限らないと思うのです。
また、「構造を把握」しているから「特性」がわかるとも限らない。
特性をより詳しく把握するのは「使う」人間だと思います。
特にバグってものは、仕組みを理解しただけでは気がつかないものも多いですから(^^;

そして、うまく「使える」のなら、「構造を把握」していなくても問題がないのですよ。
逆に「構造を把握」しないと、うまく使えないでは弱いと思うわけです。

「作る」人になりたいのか、「使う」人になりたいのか。
「作る」人のほうが優れているわけでは無いと思うのですよ。
ソフトウェア産業も広がっていて、全てが「作る」人でいる時代ではないと思うのですが・・・

＞Soda様

早希都です。大変遅くなり申し訳ありません。

なるほど。そういうことでしたか。
十分把握せずに浅慮な口を挟みました。大変失礼致しました。

きちんと「仕様」つまりどう動くべきかを把握しておくことは、開発に色々な「部品」つまりフレームワークや開発環境を利用する上での基本ですね。
同じ事ですね。失礼致しました。

でも、「使う側」「作る側」どちらから始めた人でも、「うまく使う」「うまく作る」為に、結局対極の理解も必要になると思います。

上手く使うためにも、その構造を知らなければなりません。
上手く作るためにも、それがどう使われているかを知らなければなりません。

一応書いておきますと、私は「ソースを読め派」(笑)ではありません。逆です。
本当の理解はソースコードではなく、アルゴリズムにあると思うからです。
オリジナルを読むのは、場合によっては逆効果です。
ただ、使っている部品（プログラム）と同等のものを、自分でアルゴリズムを考えて開発できる技術を身につけるべきだと思います。

この部分は、多分Sodaさんと意見が違うのでしょうか。
私の場合、使えるなら、構造の理解は必要無いとは思っていません。問題にぶつかって、初めて理解しようとするのは遅い気がします。
「うまく」使う、つまり問題にぶつかりにくくするためにこそ、構造の理解が必要だと思います。

仕様と言っても、その開発者の「理念」が完璧に反映された仕様書はありません。
最低限、使われているアルゴリズムにはどんな特性があるのか、どういう使い方をすると「きしむ」のか、作る側の視点で「も」見るべきだということです。

きしみはじめて、つっかえ棒をして、「そうか、こういう使い方をすると、つっかえ棒がいるのだ」というのは、特性を理解したことにならないでしょう。
使ってみるだけでは無理があります。理想論ではありません。こういう使い方をしてくれれば、そもそもそんな苦労しなかったのに、と設計者に言われるのが落ちです。

作る側が優れるとは思いません。作る側は、どう使われているかを正確に把握して、それに見合うものを作る責任があります。
でも逆に、使う側には、きちんと上手に乗りこなす責任があります。文句を言うなら、ですが。文句を言わずに使うのをやめるなら、問題ありません。

でも、優れたフレームワークには理念があります。それを理解するには、構造を把握すること「も」必要と思うのです。

Ｓｏｄａさんへ

＞「構造を把握」することと「使える」ことは、また別の話なんですよ。
＞「構造を把握」していれば、うまく「使える」とは限らないと思うのです。
「使いこなす」と「使われている」のも違いますよね？
部品が暴走したとき、使いこなしている人は最小限の被害で済ましますが、使われている人は破滅しますよ。なにも、「完全ブラックボックス」をこじ開けて調べよといっている訳ではないです。こういう構造なのかな？くらいがわかる程度の知識はつけておきなさいよ、という提言です。

＞ソフトウェア産業も広がっていて、全てが「作る」人でいる時代ではないと思うのですが・・・
普段は「使う人」でいいですが、お客の要望に応じて「部品くらいは作れる人」であるべきじゃないかな思うのですよ。

なんか、コラムの主題とだいぶかけ離れた話なっちゃってますね（汗）。
そうそう、Ｓｏｄａさんは「育てる」ではなく、「育つ」って方でいいのかな？
そういった意味では考えは同じで、「育つ」側の人にどこまで期待（要望）するかが違うでいいんですよね？

>早希都さん＆CMPさん

内容が被ると思うので、まとめさせてもらいましたー。

>上手く使うためにも、その構造を知らなければなりません。

たぶんーですが、早希都さんやCMPさんの言われる「構造」は、私の言う「仕様」と同じようなものじゃないかなぁ。

>本当の理解はソースコードではなく、アルゴリズムにあると思うからです。

「構造」というと、どうしても設計図というか、中身そのものをイメージしてしまうのですよ。
それ自身の中身ではなく、動きそのものの理解ということで、「構造」といわれているのであれば、それは「仕様」ではないかなと思うわけです。

>仕様と言っても、その開発者の「理念」が完璧に反映された仕様書はありません。

「理念」を理解する必要があるか、どうかは微妙かもしれません。
いや、理解しておいたほうが良いとは思いますが、それにとらわれるのは良くないと思うのですよ。
道具や部品をどう使おうが、それは使う人の自由なわけです。
元々の「理念」からは大きく外れているが、別の方面で活躍することもあるからです。
こー盲目的に「○○は、こうあるべきだ！」と固定概念にとらわれるのも不幸なわけです。
人間わりと我侭で「理念」を自分の都合のいいように解釈し始めるわけで・・・

>こういう使い方をしてくれれば、そもそもそんな苦労しなかったのに、と設計者に言われるのが落ちです。

その例だとー仕様の説明不足なだけのような気が(^^;;;
「構造」の把握というよりも「仕様」が把握できていなかったように見えます。

理想だけ言えば、わずかな「仕様」から自分なりの大まかな「構造」を理解できるのがいいんですけどねぇ。
この辺は経験などによりセンスを鍛えないと駄目ですね。
「仕様」から論理的に理解して欲しいと思うわけです。

アレですね、言葉だけではお二人と私では違うことを言っているように見えるのですが、本質的に求めているものは同じだと思うのですよ。
体感で違うのかなーと思うのは、部品の動作原理まで知るべきだと考えているように見えるところかな？
私の考える「仕様」の範囲なのか、それ以上なのか。
こー理想としての話でズレているだけで、現実的なものを例にとったら、把握した方が良いと考えているものは同じレベルのもののような気がするｗ

>「使いこなす」と「使われている」のも違いますよね？

そうですね。
ただ、会社の思惑として「使われている」状態でも良しと考えることもできるのですよ。
「工員」の最大のメリットは、差し替えが可能であることです。
会社としての理想は、工場などのライン生産のようにソフトが完成することでしょう。
設計する人の人数は少数で、生産する人数を増やす・・・
昔では考えられなかったことですが、開発環境が進化することで、現実に近づきます。
ソフトウェア産業が特別な時代は終わり始めてると思うのですよ。

>普段は「使う人」でいいですが、お客の要望に応じて「部品くらいは作れる人」であるべきじゃないかな思うのですよ。

この先ーというか今もそうだと思うのですが、「工員」と「職人」は明確に分かれていくと思うのですよ。
でもって、「職人」になれるーというか、「職人」としてやっていける人ってのは、そうなりたいと思っている人だけだと思うんです。

>そうそう、Ｓｏｄａさんは「育てる」ではなく、「育つ」って方でいいのかな？

うん、「育つ」ですね。
やる気がある人は、応援する。
本人にその気がないのに、周りから何をいっても無駄だとも思う。
仮に外部から手を加えるとしたら・・・その気をどうやって引き出すか？そこからだと思う。
「職人」を目指すものじゃないと、「職人」にはなれない。
「工員」は「工員」で目指す方向が違う、より多くの部品を素早く使えるようにならないといけない。
私には、エンジニアという枠の中に、異なる職種を押し込んでいるように見える。
「工員」に「職人」の真似事は無理にさせなくても良いと割り切ってもいいんじゃないかなと。
まぁ、現実的には真似事をさせることも多いだろうし、無理にでも「職人」になってもらわないといけない場合もあるのでしょうが(^^;

Ｓｏｄａさんへ

たとえで説明すると、私にとっての「仕様」は、【INPUTに対し、こういうOUTPUTがあるよ】であって、どういう理由で【こういうOUTPUT】がでるのかは関係ないです。
それに対し、「構造」は、【こういうOUTPUTが出てくる理由】に該当します。
それを踏まえた上で、同じかどうか判断してください。

それにしても、非技術者が経営しているIT会社（特に派遣主体）って、まともなエンジニアがいないよね。「お、こいつできる！」と思った人は大抵中途採用組だし。
そういうところのエンジニア育成方法を見てみたいよ。どっかにないかな？

>CMPさん

なるほど、その説明だと、私は圧倒的に「仕様」重視ですね。
「工員」は「構造」を知っていても良いが、互換性を考え、それを利用してはいけない・・・となります。
ブラックスボックスを使うということは、そういうことだと考えます。

コピペでＯＫと考えている新人さんは、「仕様」が理解できていないか、しようとしていない。
「仕様」を理解せずに「構造」に進んでも無駄だと考えています。
ですので、「仕様」を理解するために「構造」を学ぶということに疑問を感じるわけです。

バグなどの原因究明に「構造」を理解していたほうが優位に立てるという考えもわかります。
その時点で、ブラックボックスから外れるような気はしますが(^^;

私は「仕様」から論理的な「構造」を想像できるセンスを求めたいのです。
どのような部品が提示されても、柔軟に使えるように。
物理的な「構造」を見ることができなくても論理的な「構造」がわかるように・・・。

その「構造」は実際の「構造」とは異なっていても良いと思うのですよ。
その人がその人の理解で論理的に考えているのだから、その論理に矛盾が生じた時に、調査して論理を修正すれば十分だと考えるからです。

まぁ、このように考えているので、実際の「構造」がどうなっているのかということは、二次的ですね。
「職人」も同じように考えますが、既存のものよりも良いものを作るなど、状況によって「構造」を理解しないと改良ができないものもありますね。
元々の「構造」が良いものとは限らないですし、できれば元の「構造」を調べずに、自分の発想で作り、その後で比べるほうが望ましいと思います。
・・・が時間がそれを許してくれない場合が多いですよね(^^;

論理的な「構造」を軽視しているわけではないので、本質的には同じような理解を求めているんじゃないかなーと思うのですよ。
お二人の説明する「構造」は論理的なものだと思うからです。

うぅ、説明がヘタで申し訳ないです、感覚的なものを伝えるのって難しいですね。(^^;;;;

ＰＳ．
「構造」を知らないと使えないという環境があるならば、それは不完全なものかもしれません。
私が主に使う環境であるMFCは「仕様」のレベルでも十分使えると考えています。
・・・が人によってはMFCで使われる「メッセージ」は「構造」と考えるかもしれません。
ここら辺は、個人の感覚で温度差がでるとこかもしれませんね。
部品も同じで、私にとってメインの部品はコントロールやMFCで用意される関数です。

Ｓｏｄａさんへ

＞うぅ、説明がヘタで申し訳ないです、感覚的なものを伝えるのって難しいですね。(^^;;;;
いえいえ。ようやく、お互いの考え方が伝わったような気がします。

＞コピペでＯＫと考えている新人さんは、「仕様」が理解できていないか、しようとしていない。
＞「仕様」を理解せずに「構造」に進んでも無駄だと考えています。
おっしゃるとおりです。

＞私は「仕様」から論理的な「構造」を想像できるセンスを求めたいのです。
＞どのような部品が提示されても、柔軟に使えるように。
この考え方もまったく同じです。

そのセンスを磨くorつけるためにも、先人達のセンスはどういうものかを見ておくことも必要だろうってのが、私の考えですね。（あれこれ考えをめぐらすだけでも十分なのですが＾＾；）
でも、それは「職人」を目指す人だけでなく、「エンジニアを名乗るならば、それくらいやりなさいよ」っていう苦言でもあります。

＞うぅ、説明がヘタで申し訳ないです、感覚的なものを伝えるのって難しいですね。(^^;;;;
私こそ説明が下手で申し訳ないです（大汗。

私自身としてはネットが広まって情報があふれたおかげで、昔は自己流の考え方書き方をしていたものが、標準的なコードスタイルだとか作法を意識するようになりました。
例えばif文の括弧の位置、括弧の前後のスペースの入れ方が昔は迷いまくっていましたが、ネットやEclipseのお陰で決まったり。Strutsのお陰でWebアプリの作りを教えられました。
またRubyがメジャーになったのはネットのお陰だと思いますが、ネットでRubyを知って勉強して、コードの考え方が変わったと思います。
自分自身のエンジニアとしてもスキルは大きく底上げされたと思っています。

部品の話がありますが、オブジェクト指向って隠蔽化・部品化が売りの一つのはずですから現在の流れは必然ですよ。車輪の再発明よりも新たな付加価値(高機能、短納期)の方向へ行くのは特に仕事の上では当たり前で、にゃん太郎さんの得意分野の根っこの部分わからないで使っていいのか？という気持ちもわからなくはないですが、必要に迫られない限りわからないままでしょうし、わからなくてもいい時代なんだと思います。昔だってVBだってろくに書けない人、GOTO文満載コピペだらけのコボラーが居ましたがシステムは動いていましたし、そういう人が歳をとっても業務知識やPG作る以外の分野でずっと活躍していっています。

プログラムや技術好きな自分の視点としては賛同できる意見が多いですが、
そうでなくてもIT会社内で成功している人も居ます。