第5話 エンジニアよ、もっと深く考えろ
今回はエンジニア側の問題点です。対象とするのはSEやPGで主に詳細設計から後の工程を担当するエンジニアです。ただ、テストエンジニアついてはちょっと方向性が違うので、対象としていません。上流のPMに関しては次の話の予定です。
注意！
以下の文章はあくまでわたし個人で感じていることであり、大多数のエンジニアをいっている訳ではありません。それを理解して読んで下さい。
一緒に仕事をしていて「最近のエンジニアは一昔前のエンジニアとは違うな」と感じることが結構あります。開発環境が随分変わってきたので一概にはいえませんが、一言でいえば「エンジニアとしての気質が変わってきたのでは」と推測しています。
傾向としては、だいたい次のことが挙げられると思います。
- あまり考えない
- プライドが高い
- コスト意識に乏しい
- コミュニケーションしない
■恵まれすぎると……
インターネットが当たり前になってきたのが一番なんですが、調べものをする時間がかなり短縮できています。本屋に行けば、雑誌も入門書もたくさんあります。検索すれば知りたい情報のほとんどは見つかり、ソフトだって自分が欲しいソフトを誰かが作っている可能性は非常に高く、ダウンロードすれば自分が作らなくてもすぐ使えます（有料・無料は別として）。OSですらオープンソースで公開されています。
エンジニアならつまずいたり失敗する場所がだいたい同じなので、忘備録的にWebページやブログに書いてある確率が高いです。教えて掲示板も多い。おまけに検索した情報からソースをコピペするだけで問題が解決してしまう……そう、意味なんか分からなくても解決します。こんなことばっかりやっていると、あまり技術を掘り下げない（意味を深く考えない）エンジニアが増えていきます。
昔はマニュアルが一番の資料でした。それこそ職場にはマニュアル専用の部屋もあるぐらいで、そこで探すのが一番早い選択肢でした。技術書専門の本屋でも本はありましたが、どちらかといえば玄人向けで、今のように誰でもできるように書かれた入門書は少なかったように記憶しています。確実にプログラムを組むという敷居が低くなっています。低いこと自体は業界の間口を広げる意味で良いことなのですが、そこから少しずつ掘り下げないので素人みたいなエンジニアが増えていきます。結果的にバグが増え、品質の低下やプロジェクトの失敗が多くなります。
ただ、昔よりは今の方が技術の範囲は広くなっています。全部を深く掘り下げるのは確かに無理だと思うので、少なくとも一通りの浅い技術、自分の関係する業務の部分は深く掘り下げて欲しいと思います。
■動けば良いのか？
最近のソフトウェアの開発環境はすばらしく出来が良いので、素人に毛が生えた程度の知識でも作ったプログラムは「動き」ます。PMの立場からすると「動けばいいのか、おい」と思うのですが、当人たちはナゼか「動くのに何が悪いの？」って開き直ります。たいした知識がなくても普通に動くので意外とみんなプライドが高いです。
動くことにだけ主眼があるので（それはそれで大事だけど）それ以外の部分になかなか気が回らない。正常系はあまり問題なくても異常系の観点から見ると見落としが多い。だからちょっと変なパラメータとか入れてやると動作がおかしくなる。そうすると「そんな入力想定してません！」と逆に怒られる。いやいや、使うユーザーみんながこっちの思惑通り使ってくれるわけがないんだから……想像力があまりに乏しすぎる。
以前、仕様書に「キャンセル」ボタンの明記をしてそれのテストをしてみたらキャンセルができない。作った担当者に聞いてみると以下のような会話に。
わたし：「これ、キャンセルボタン押しても何にも変わらないよ」
担当者：「キャンセルがうまくできないので押しても利きませんよ。利かなくても問題ないですし」
わたし：「なんで問題ないの？」
担当者：「ちゃんと動作しますから。それにそんなに長い処理じゃないですよ」
わたし：「でも、ケースによっては数分かかるよね？」
担当者：「大事な処理だから数分ぐらい待ってもらえば良いと思いますよ」
わたし：「……」
もう、何が正しいんだかわからなくなってきます。完全に都合の良い解釈していますが、できないのはスキル不足です。でも、動いているから大丈夫という発想はエンジニアとしては失格です。想定外の処理を考えてそこにセーフティネットを張るからこそ、ソフトウェアが正しく動くわけで、単純に動く動作だけプログラム化してもそれは不完全なシステムでしかありません。
「試行錯誤をあまりしなくなった」というのもあると思います。ネットや書籍で見つけたサンプルが結構動くのでその必要性が見いだせないのかも知れません。深く考えなくても動作すると言うのは便利な反面、エンジニア的な思考を低下させる原因でもあるといえます。
Webアプリとかになるとプログラム以外の要因で障害が出ることがあります。サーバの設定値など。プログラムだけを責められないことはありますが、自分の作ったプログラムがどのような仕組みで動作しているかを知っていれば、たとえ障害が出ても早期復旧は可能です。メモリ管理とか割り込みとか、遠い昔の話になってしまったのだろうかとふと思ってしまいます。
わたしだってこういうエンジニアに出くわすと怒鳴りたい衝動にかられます。でも、今は怒ったらダメ。うまいことおだてながらやんわり釘を刺します。昔は怒ると女性はたまに泣き出しました。今は男性の方もたまに泣き出します。気分的にはこっちが泣きたいです。
最近はバグが出たらその症状と該当するソースコードを抜粋して何が悪いか、そしてどうすれば良いのかヒントを文章にして担当者に渡します。時間がない時は修正して、ヒントではなく修正結果となぜ「こうしないとマズイのか」を明記して渡します。闇雲に怒っても反発して聞き入れないか、ショックで思考停止になるケースが多いので、仕方なくこんな対応しています。
でも、この対応は伸びるエンジニアと伸びないエンジニアを見分けることができます。伸びるエンジニアは、この結果からいろいろ考えて、次からバグが出ないように気をつけるようになります。逆に伸びないエンジニアは修正されると「もうけもん」と思うのか、何度も同じようなバグを繰り返します。管理する時はこの伸びないエンジニアを重点的に管理するようにするとテスト工程の前でかなりバグが減らせます。
■不幸が自慢ですか？
あくまでもわたし個人の感想ですが、エンジニアは残業時間や徹夜仕事、デスマーチをことさら大げさに言う傾向があるように思います。誤解を恐れずいえば、それを乗り越えるのが自慢みたいな。世の中には確かに修羅場のようなプロジェクトがたくさんあると思いますし、わたしもこれらの人がいわんとすることは理解できます（もちろん経験してますし）でも、それは間違いだと気づくべきです。
残業は、するよりもしない方が当たり前だと思います。わたし自身、しなくても良いように多少余裕を持ってスケジューリングします（それができれば苦労はしないと思う人はたくさんいると思いますが）。事実、わたしはここ数年ほとんど残業していません。ただ、最近はそうもいかないので逆に朝早く会社に来て仕事をしていますが、帰りは遅くても19時には会社を出ます。
仕事の評価方法にも問題はあると思います。何事もなく普通に終わったプロジェクトより、火が噴いて何とかみんなでやり切ったプロジェクトの方が一見すると充実感もあり、「よく頑張ったなぁ」なんて思われがちですが、そんなのわたしからいわせれば、
「頭悪いんじゃない？」
と思います。よほどコスト計算ができないか潤沢な資金があるかのどちらかです。エンジニアは技術には向き合いますが、コストに向き合う人はあまりいません。残業代がつかないし、お客様からも追加料金取らないからいいじゃん、と思うでしょ？ だからいつまでたってもこの業界は「3K/5K当たり前の劣悪な職場環境」なんていわれてしまうのです。
コストは何もお金だけではありません（経営者からすると光熱費もあるので結構コスト増になります）。自分の体でもそのコストを負担しています。
体を壊してからでは何にもなりません。プロジェクトの山場で体調壊してリタイアすることは非常に無責任です。おまけに無理して体調壊しても誰も面倒見てくれません。乱暴な言い方をすれば頑張り損です。
同じ頑張るなら残業せずに、仕事をこなして帰る方を頑張って欲しいものです。
■エンジニアの前に社会人ですよ。
昔から、エンジニアには内向的な人が多いと言われます。昔はメールなんかもなかったので、何かあれば会話するしかなかったのですが、最近では目の前や横にいる人さえもメールでコミュニケーションします。これが悪いとはいいませんが（相手が忙しそうな時は良いとおもいますし）、行き過ぎると本当に会話がなくなりますので、個人的にはほどほどが良いと感じます。
ただ、「挨拶」ぐらいはしましょうといいたいです。そう思うぐらいこの業界の人は挨拶ができない（しない？）人が多いと感じます（小学生じゃあるまいし……）。朝とかこちらが挨拶しても知らん顔なのもけっこうあります。よほど相手にされていないかなと悲しくなります。挨拶は基本的なコミュニケーションだと思います。それすらできないならプロジェクトもうまく回って行かない気がします。
前に書いた最近のエンジニアはプライドが高いって話ですが、あんまりガミガミいうとそのうち挨拶もしなくなります。あまりにあからさまなので逆に笑えるのですが、人としての器があまりに小さいと感じます。逆に「なにくそ！」って奮発して欲しいのですが、そういうモノではないのですかね。おっさんから見ると淋しいのを通り越して悲しいです。
■「モノ作り」ではない
わたしはソフトウェアに関しては「モノ作り」ではないと思っています。理由は……モノじゃないから。
こういってしまえば身も蓋もないのですが、入門書の最初によくある「Hello World!」を思い出してみて下さい。言語、環境なんかは何でもいいです。これで「モノ作り」といえるならエンジニアとして「どうかな？」といいたくなります。乱暴な言い方をすればソフトウェア開発はこの「Hello World!」の規模を大きくしたものだといえます。プログラムを言い換えればハードウェアの電気信号を制御する手続きのことです。そう、手続きなので正確には「製造」ではないと思ってます。よっぽどパソコンショップでパーツを購入して組み立てた方が「モノ作り」と思います。
ただし、ソフトウェア開発は単純な「モノ作り」よりは、かなり複雑です。プライドを持つのも自信を持つのも悪いことではないと思います。でも、プログラムは自分が組んだ通りにしか動きません。しかも、プログラムというのは、通常、全体のシステムのほんの一部です。ほんの一部ではありますが、少しでも変な動きをしたら全体に影響が出ます。資格を取るのも言語を習得するのも大事です。いろいろな手法を学ぶのも大切な事です。でも、忘れないで欲しいのは言語や手法だけが大事ではなく、本当に理解してロジックを組む事が一番だということです。何事も基本に勝るものはなし、です。
最後に後輩を持つ先輩に一言。後輩が質問してきても「ググれ（意味は分かりますよね？）」とは言わないで下さい。教えるのは答えでも調べ方でもありません。ヒントを出して考えさせるようにして下さい。後輩を立派なエンジニアにできるのは、先輩の接し方ひとつです。仕事の負担を軽くしたいなら後輩を自分のレベルまで引き上げてやるのが一番近道です。テクノロジ習得に王道はないですし、技術の進歩はそれこそ「日進月歩」ですが、地道に考えることのできるエンジニアに育てば生産性も上がるでしょう。切り捨てるのは簡単です。
便利だからこそ、その上にあぐらをかくことなくエンジニアとしての本筋を考えて欲しいと思います。エンジニアを取り巻く環境は厳しいですが、それでも技術に対して深く掘り下げ、規則正しい生活を送ることがソフトウェア開発の明るい未来を作る第一歩だとわたしは確信しています。
コメント
インドリ
今晩はにちゃん太郎さん、インドリです。
仰るとおりだと思います。
私も何度も同じ事を感じました。
「VBでも何でも動けばいいじゃん」という台詞を何度も聞きましたし、
「自分の業務外の知識は学習する必要なんて無い」だとか、
「保守性のため新人に合わせる」（プロが素人に合わせるの？）だとか、
もう技術者と呼べる意識を持たない人が目立ちますよね。
そのくせ、妙なところのプライドを持っている。
にゃん太郎さんは私よりキャリアが倍以上ありますので、私よりもその思いが強いと思います。
さらにコスト意識が無いですよね・・・
もうこの業界は駄目な理由が大盛りだと思います。
この業界は沈没船としかいいようが無い状態ですが、私は命ある限り自分の職人道を歩み続けようと考えている次第です。
インドリ
連続投稿になって済みません。
一つ質問があります。
それは「本当に必要な技術についての資料が不足」している事についてです。
私はOSを実装しようとした時や、ハードウェアを叩こうとした時などにその資料の少なさに愕然としました。
巷には資料が溢れかえっているのも関わらず、深いレベルになると一切ありません。
昔はBIOSなどの低レイヤについての飼料などがあったそうですが、現在は非常に探すのが困難なのです。
この資料不足も技術力不足に拍車をかけていると私は考えております。
そういった、低レイヤに関する技術の資料不足を乗り越え、より深く考えるにはどのようにすればよいでしょうか？
がると申します。
…多分。「学び方」を知らないんだろうなぁ、と、いつもながら考えてしまいます。
ただ。同じくらいに、上の人間が「教える事を知らない」という状況もまた、あるのかなぁと感じます。
# なので、私は個人的に「寺子屋」とかいう集団に属してたりしますが。
saki1208
にゃん太郎さん、こんばんは。
saki1208です。
考えない人、多いですよね。確かに。
ただ、老若男女はあまり関係ないようです。
問題が起きた時点で思考がとまってしまう...
# ほんのちょっと考えれば、ほんのちょっと調べればそこに答えがあるのに...
私は「この仕事は頭を使ってなんぼ」だと思っています。
そもそも、物理的な形のない物を売り物にしている訳ですし、決まった形がある訳でもありません。お客様がどんな形を望んでいるのかは頭を使って考えないと理解できないし、形に出来ないのです。にも関わらず、目の前の問題にすら頭を使わない、考えない人が多すぎです。
# 気持ち的には、そんな人には廃業してもらいたい。
どうすればそんな人達を「考える」様にしむけられるのでしょうね?
# サラリーマンである場合は簡単には淘汰されませんし...
永遠の課題のような気がします。orz
saki1208
連投すみません。
saki1208です。
私の周りにも挨拶できない人は多いですね。
「おはよう」ってこっちから声をかけても反応なしとか…
# 嫌われてるのかなorz
挨拶されたら例え相手が嫌いでも私は返事しますけどね。
社会人がとか言う前に人間かどうかを疑ってしまう。
うちの子供でも出来るのにw
なに考えてるんでしょうかね。
# 定年近いような年寄りにも多いので困ります。
おはようございます。
本当に半端なプライドを持っていて、私が言ってることなんて最上流でも「動いているのに」「そんなことしなくても終わる」とか……。
プログラムだけじゃなくて経営的にコストも考えてほしいし……。
私も教えずにヒントを出すようにしているのですけれど、相手はキョトンとして終わりだし……。
同じことで悩んでます。
にゃん太郎
インドリさん、ありがとうございます。
そうなんですよね。一概にエンジニアだけの責任ではないのですが、とにかく目
の前のプロジェクトを終わらせたい一心だけでみんな突き進んでいる気がします。
顧客満足度なんか完全に置き去り。システムなんかは動いて当たり前で、ユーザー
の操作ミスやハードウェアやネットワーク、データベースなどその他のシステムの
障害発生時にすみやかに復旧したり、代替処理に切り替えられるなど、本来はイレ
ギュラーな事態にどれだけ対応出来るかが大切なんですけどね。
ただ、少しずつでもエンジニアが意識を変えていけばこの業界も必ず良くなるん
じゃないかと多少は期待を込めてコラムを書いています。
> 巷には資料が溢れかえっているのも関わらず、深いレベルになると一切ありません。
> この資料不足も技術力不足に拍車をかけていると私は考えております。
> そういった、低レイヤに関する技術の資料不足を乗り越え、より深く考えるにはど
> のようにすればよいでしょうか？
この悩みは同じだと思います。MS-DOSの時代なんかはそういう資料がたくさんあ
ったような気がしますし（ちょっと昔なので不確かですが）私も、そういう本を見
てデバイスドライバやハードウェア制御をしていたと思います。シリアルやモデム
通信なんかは今ではほとんど使われないため資料がほぼないです。私の場合、必要
がある場合Windows95の時代に出た詳しい資料を今でも参考にしています。
コラムの中でも「入門書」が多いって書いてありますが、今のソフトウェア開発
だけ見ると低レイヤの資料までは必要ないと言うかニーズがほとんどないからだと
思います。ハードウェア制御もWindowsAPI（Read/Writeなど）でコントロールで
きるようにドライバで書かれていますし、プロトコルですら知らなくても通信でき
ます。VC++だって.Netを使ったものが主流でMFCの本なんか古いモノしかありませ
ん。ActiveXは今でも作っていますが参考資料はVC++5の時に出た本です。
Windowsの場合は「インサイドWindows」は必需品です。昔はメモリ空間が限ら
れていましたが今は非常に広大なため、昔と違いどんな用途にも利用できます
（I/Oマップなんてのも時代遅れだし）以前は「SoftICE」なんて便利なカーネル
デバッガがあったのでそれであちこちにブレークポイント仕掛けて解析してまし
た。Windows2000時代はデバッグ版のWindowsがありましたが、これって今でもあ
るのかな？（最近はそこまで必要ないので）
勉強法についてはまたいずれネタにするつもりです。ちなみに資料が少ない分、
自分で本を書いたら売れないかな、とちょっと考えています（笑）
にゃん太郎
がるさん、ありがとうございます。
昔と違い、教えられない先輩、調べ方がうまくない後輩なんでしょうね。聞く方
もどう聞いて良いかすら分からないケースも多々あるみたいです。聞きたいけど聞
けないとかも。今は時々聞いてやらないと溜め込むのでコワイです。「分からなか
ったら早く言えよ」はもはや禁句です。小さい頃からの教育の仕方（受け方）も影
響しているんでしょうが、ここは割り切って先輩や上司が何とかするしかないんで
しょうね。
にゃん太郎
saki1208さん、ありがとうございます。
> 永遠の課題のような気がします。
そう、そのとおりです。でも、このままずるずる行くとそれに巻き込まれる真っ
当なエンジニアも増えそうな気がします。これが多分業界にとって不幸。プロジェ
クト単位で考えると出来るエンジニアの負荷が高くなり、出来ないエンジニアはそ
の陰に隠れて何食わぬ顔でいます。結果的にプロジェクトは終わっても、貴重な人
材の疲労感は残り最悪の場合は業界を去っていきます。結果、残るのは･･･あぁ、お
そろしい。
挨拶にしてもスキルにしても若い人だけではないです。これって昔からそういう
土壌があったんでしょうかね。ただ、職場環境や待遇などで段々疲弊しているのか
な？とも思います。でも、同情はしますが賛成はしません。疲れているからこそ挨
拶ぐらいちゃんとしようと思うのですが･･･無理ですかね？
電車に乗ってもいい大人の方がマナーが悪いし、子供が迷惑かけても注意しない
親とか見ると業界以前に日本は大丈夫か？となります。
にゃん太郎
生島さん、ありがとうございます。
今回はプログラム設計から製造までの話ですが、次回は上流の話を書こうと思っ
てます。実は上流の方が事態としては深刻なんですよね。
サラリーマンにコスト意識を持たせるのは並大抵の事ではないですよね。私は昔
「必要経費だからケチケチするな」って言われた事があります。必要経費でも出所
がないと払えません。利益が出ないと給料やボーナスとして還元出来ないですし。
ま、コスト意識があってよく考えて仕事するエンジニアは会社辞めてフリーか起
業するんでしょうけど。
インドリ
> 勉強法についてはまたいずれネタにするつもりです。ちなみに資料が少ない分、
自分で本を書いたら売れないかな、とちょっと考えています（笑）
にゃん太郎さん是非お願いします。
OS自作入門も大ヒットした事ですし、低レイヤのディープな内容を書けば売れると思います。
少なくとも私は絶対に買います。
くま
こんにちは
人のふりみてわがふり直せで、私も耳に痛い
お話もありました。ありがとうございます。
■動けば良いのか
なっとくです。
これは業界全体の問題になってきている気もします。
２～３年前、東証の株売買システムが処理能力オーバーで
ダウンしてましたよね。諸事情があると思いますが、これが、
NYならとんでもない
事態だと思います。
身近なとこでも、受注システムを開発していた時に
感じたことがあります。
■不幸自慢ですか
年配の方には、武勇伝好きな人います。
そんな事より、暗黙知としてのノウハウの伝授を
してほしいです（笑）
■プライドが高い話。
お恥ずかしい話ですが、私にも当てはまる部分があります。
でも本当は、プライドが低いのです。
本当に高い人は、自分の行いを反省し、素直に
謝りに、フィードバックをかけてきます。
にゃん太郎
くまさん、ありがとうございます。
私も若いころはイケイケ（死語）でしたから…まぁ、反省も込めて。でも、本当に
問題なのは若いエンジニアが正しい方向に進むように指導できない先輩・上司・
職場環境なんですけどね。間違ったままキャリアを重ねて失敗プロジェクトを
続けるようなエンジニアになって行く方が末恐ろしくて。
真剣に考えなければならない時期だと思ってコラムを書いてます。
サブロー
こんにちはサブローです。
>何事もなく普通に終わったプロジェクトより、火が噴いて何とかみんなでやり切っ>たプロジェクトの方が一見すると充実感もあり、「よく頑張ったなぁ」なんて思わ>れがちですが、そんなのわたしからいわせれば、
>「頭悪いんじゃない？」と思います。
私の会社では火を噴いたプロジェクトを完遂したほうが、会社からの評価が高いのです。だからまず、普通にプロジェクトを終わらすことはNGなのです。
私はプロジェクトは火が噴いて当然なのです。
だから私のあだ名は「目組」です。
世の中のすべてのプロジェクトが火を噴いたほうがやる気がでるのでは。
普通にプロジェクトをしてもつまらないと思います。
にゃん太郎
サブローさん、ありがとうございます。
私はサブローさんの会社もあなたも知らないのでコメントから読み取れる範囲で
レスさせて頂きます。
火を噴いたプロジェクトを完遂した方が評価が高いというのは技術を売り物にす
る会社としてはどうでしょうか？「私たちは要件も設計も製造も上手ではなく、工
程や進捗管理もうまく出来ずしょっちゅうプロジェクトは火を噴きますが大丈夫で
す」と宣伝しているようなものです。
プロジェクトが火を噴くという事はどこかの工程（人）の見積が甘いためであ
り、それを逆手に「やる気が出る」というのはスキルやモラルが低い証拠です。そ
ういう所と取引している会社が気の毒です。ついでに何も知らず入社してくるエン
ジニアにとっても。
通常、火消しが出来るのはそれなりのスキルを持ったエンジニアがいるためです
が、その人が一生そこで働いている事は理由の如何を問わずありえません。絶えず
ギリギリの線でプロジェクトが回っているなら火を消しきれないケースも出てきま
す。
あなたは給料が増えない、減る、ボーナスカット、会社が倒産いずれかの事が起
こってもつまらないと言い切れますか？もし転職する際に面接官に「プロジェクト
は普通にやってもつまらないので火を噴いた方がみんなやる気が出て良いと私は思
います」と胸を張って言えますか？そうであるなら立派だと思います。ただ、あな
たの立場は分かりませんが普通のプロジェクトがつまらないと思うのは火の噴いた
プロジェクトの本当の怖さを知らないからだと思います。火を噴いた、あるいは失
敗プロジェクトの損益を何百万円も自己負担するハメになっても火を噴いた方が良
いと思いますか？まぁ、上司も口では「良くやった」と言っていても内心はどうか
わかりませんが。あなたが上司ならその会社のレベルも知れています。
火消しがうまくできるからと出世してもエンジニアとして幸せな結果はまず出な
いと思います。それを承知で火を噴いて当然と考えるなら頑張って放火して消火し
てください。そういう所に最後に残るのは燃えカスだけです。
# 釣られているかな？
ぶそん
情報をググれるようになってから、コピペ文化が広がっていったように思います。おっしゃる通り考えることをしなくなっているエンジニアは増えてます。残業の定義については私も心から同意します。そんな景色が全体に広がっていくと、まっとうなエンジニアもつられて・・・という気分も出てきますよね。そんな中、このコラムはそういったエンジニアにとって、今一度自分の立ち位置を確認するために必要なものになりますね。私自身も振り返ることができました。
友ぞう
こんにちは、にゃん太郎さん
友ぞうと申します。
> 仕事の評価方法にも問題はあると思います。
>何事もなく普通に終わったプロジェクトより、火が噴いて何とかみんなでやり切ったプロジェクトの方が一見すると充実感もあり、
>「よく頑張ったなぁ」なんて思われがちですが、
これ、わかります。私の部門長はまさにそういう考えの人で
大きなトラブルを起こしていない人よりも、
トラブルだらけの人のほうが評価が高く出世しています。
しかも、そのトラブルを解決しているのは本人ではなく周りの人なのにです。
こういう人が部門長だと不幸ですよね。
不幸をなげいても仕方ないので、自分はやれることをやるしかないですけど。
コードを書かないってのもわかります。
自分の手で書いたり（手書きではありませんが・・・）調べたりしていないことは
何も身につかないし、すぐに忘れてしまいますよね。
そういうことをしない人多い気がする。私の周りで・・・
にゃん太郎
ぶそんさん、ありがとうございます。
今学校は夏休みですが、夏休み中の天気や読書感想文なんかもコピペサイトがあ
って、これってどうなんだろうって思います。学校が学ぶ所ではなくルーチンワー
クになり、学習塾は受験のテクニックを教える。挙げ句の果てに世間で一流と言わ
れる大学を出ても明確な目的が持てず就職しなかったりニートになったりする人が
増えているようです。親の世代が比較的裕福だからこういう結果になるとは思うの
ですが、こういう風潮もあまり考えないエンジニアが増える要因だと思います。
もうすぐ選挙ですが、政治家や文部官僚の方々は「学ぶ」という事の原点を見直
す政策を考えて欲しいものです。
私としては振り返って頂く機会になればそれが本望です。私自身も振り返って初
心に返る意味でコラムを書いています。これからも読んで頂ければ幸いです。
にゃん太郎
友ぞうさん、ありがとうございます。
> 不幸をなげいても仕方ないので、自分はやれることをやるしかないですけど。
そうなんですよね。大半のエンジニアはこう思っているんじゃないのでしょう
か？実際、上司を批判するのは簡単ですがそれだけで問題は片付きません。やりす
ぎると「あいつは文句しか言わない」とかなっちゃいますし。私も若い頃はこれで
結構失敗しました。
私自身、ネットで検索して解決した事は何度もありますので、これを否定する気
はないのですが、それで終わってしまったら何も得るものはないんですよね。それ
を分かって欲しいと常々思っています。それは若いエンジニアにもそしてシニアエ
ンジニアにも。上っ面だけ体裁良くなっても、本質が分かっていないとトラブルの
時にメッキははがれてしまいます。本当に「動く」＝「実力」と勘違いしていると
思います。
kuma
にゃん太郎さん コメントありがとうございます。
>問題なのは若いエンジニアが正しい方向に進むように指導できない先輩・上司・
>職場環境なんですけどね。
そうですね。スターウォーズのジェダイのような方は..なかなかいませ
んね（笑）先輩や上司が適任かわかりませんが、リーダーやメンターが
求められている気がします。
"教える"とは、教わっている事だとつくづく感じます。
また、俺が”あいつを育てた～”と豪語するかたを見ると、尊敬します（苦笑)
次回も楽しみにしております。