プログラマのやる気を上げよ 325
ストーリー by kazekiri
コードを書いている人が偉い 部門より
コードを書いている人が偉い 部門より
Anonymous Coward 曰く、
本日の産経新聞にやたらにでかくNTTデータの浜口社長のインタビューが掲載されている。「日本のソフト業界はプログラマーを軽視した。能力のあるプログラマーにはいい報酬を支払い、品質や生産性を上げなければならないのに、そうしなかった。」ということで、「スーパープログラマーとでもいうべき技術者を集めて、生産性の高いソフト制作の手法を編み出したい。相応の処遇についても検討する」と、優秀なプログラマーを重要視した方向にもっていきたいようだ。何となくどこかで見たような話だが、日本最大のSI屋のトップの発言ということで、搾取され続けるプログラマーの皆さんには一筋の光なのかもしれない。
そんなことを思っていたら、Geekなページにプログラマがやる気をなくした理由というエントリ。フィクションということで、とにかくやる気をなくしている理由を列挙したものだが、これを見ると何だか浜口社長の意気込みも遅かったのではないかと 思ってしまう。
プログラマがやる気をなくした理由 (スコア:4, すばらしい洞察)
好きなプログラムを仕事でやり始めたからですよ。
プログラミングは
本来、論理的思考能力を使う作業です。
その内容を知らないバカにその上の設計を任せるから
負担がプログラマにかかってくる。
馬鹿なプログラムを作らなきゃダメになる。
そりゃモチベーション落ちますよ。
仕事にしなきゃ、やる気を維持する方法はあったんです、と。
# あとコミュニティの軋轢とかもあるから、
# 書いたプログラムは公開しない、と。
Re:プログラマがやる気をなくした理由 (スコア:3, すばらしい洞察)
新人なんかは入社したときから「PGなんて早く卒業してSEになれ」って擦り込まれるしね。
そうやって促成されたSEは技術を舐めてるっていうか自分のPG経験をもとに考えちゃうからねぇ。
＃そりゃぁ、ネットのサンプルコードをコピペして作ったシステムと、
＃設計も行った上で作ったシステムじゃぁ信頼性が違うわな。
Re:プログラマがやる気をなくした理由 (スコア:2, すばらしい洞察)
＃コードサイズや労働時間しか買ってくれないからねぇ
Re:プログラマがやる気をなくした理由 (スコア:4, 参考になる)
当たり前です。
多くの労働者は下請けですから時間外労働は絶対に減りません。
まず契約の時点で人月計算されてパイが決まります。しかも本当にギリギリの作業量です。
給料が出ないから帰るなんて悠長な事をしていたら会社が潰れます。
充分な利益さえ出せているなら、私ならむしろ労働時間を減らします。
労働を時間、ステップ数でしか評価しないのも、納期を短縮するだけで
際限なく対価を引き下げる事が可能だからです。
この構造を変えない限り、時間外労働は絶対に減りません。
下請けの会社そのものが正当な評価をされない限り無意味です。
Re:プログラマがやる気をなくした理由 (スコア:2, 興味深い)
私の会社では数年前に人事制度が変わって、半期に一度数値目標を上司と面談しながら設定、半期単位で達成度を見て評価ということになりました。
蓋を開けてみたら、期末に後付けで（終了する期の）目標設定と”同時に”達成度評価、しかもろくに面談もせず、「時間無いから書類提出だけお願い」というありがちなパターン。
そもそも、この評価システム自体がソフトウェア開発に向いているかどうかというのを計算に入れなくても破綻しきってます。
こんなんで給料決められれば、そりゃやる気もどんどん減退するってもので･･･
＃さすがにACなのを指差し確認してから投稿
物差しが悪い (スコア:2, 興味深い)
普通は小さくエレガントに書こうとすると、余計に時間がかかるんではないですか？
わざわざ時間かけて小さくエレガントに書いているのに、
エレガントさは考慮されず、
作業時間に対してサイズが小さいとか
努力した結果と全く逆の物差しで計られるのが問題なのであって、、、
まぁ、それはともかくとして、
短時間で小さくエレガントに書けるのに、
わざわざ、長時間かけて、大きく、非エレガントなコード書くのは
どう考えても、アレげではないと思います。
uxi
Re:組み込みハード屋ですが、なにか？ (スコア:3, 参考になる)
俺たちも2000年ごろまではハードの価格競争力を維持するために
コンパクトで高速なソフトを書くことが俺たちのコア技術だと思ってがんばってたわけさ。
それがあるとき機能拡大に伴って
・なんだかんだいってソフトウェア規模が増大してきた
・コンパクトさとか速度を確保するための仕組みがテスト工数を増大させてきた
・コンパクトさを得るための特殊な作り方のせいで他社とソフト共通化できない
とかいうあたりのデメリットが強烈に喧伝され
Linuxを入れろだのフレームワークを使えだの
「それがソフト開発の正しいありかただお前らはバカだ」などの
偉そうなことを言うやつらがのさばってきたんです。
俺たちは当然
Linuxなんかにしたら起動速度おそくなるよ
X入れたらもっさりになるよ
そもそもメモリバカ食いになるじゃんどうするんだよ
というような抵抗をしてきたんだけど、最終的には
「俺たちがバカだったです今度からはでかくてまぬけなコードを大量生産することにするよ」
と上層部に誓わされたわけです。
もう最近は中国やインドに出してるのでコンパクトなコードを作る体制なんてまったく残ってないですよ。でもそれは俺たちのせいじゃないからね。
Re:プログラマがやる気をなくした理由 (スコア:2, すばらしい洞察)
Re:プログラマがやる気をなくした理由 (スコア:4, すばらしい洞察)
「許す」というより、むしろ推奨する雰囲気すらあります。
人身売買が恒常的な、いわゆる「SIer」と言われるような会社では、スーパープログラマがプロジェクトをぐいぐい引っ張るよりも、馬鹿でもプログラムが書けるフレームワーク(と呼ぶのもおこがましいもの)を喜んで採用したり開発したりしたがるものです。プログラミングの一般的な慣習をもとにコードを書くと、「こういう書き方をされると私が読めないのでやめてください」などと言われる始末。実際、私が Java でデータベースから引き出したデータをリンクリストを使って管理する簡単なクラスを作ったら、コードレビューで「会社で一番 Java に詳しい」と目される人から「こんな書き方をされても読めません。私、バカですから」と言われて二の句が継げなかったことがあります。
# まともなコードは副業で書いているので AC
Re:プログラマがやる気をなくした理由 (スコア:5, すばらしい洞察)
うちの会社に入ったときにまず教えられたのは、大きなプロジェクトでは優秀なプログラマの影響は限定的であるというものでした。つまりプロジェクトが大きければ大きいほど個々人の力量の影響は限りなく小さくなり、プロジェクトは全て人月で計算するのが当たり前だというものです。
もう1つ別に大事なこととして常に力説されるのが個人の力量に頼ったプロジェクトはその個人の存在がリスクであるということです。つまり優秀な個人は存在そのものが危険で常に誰もがお互いの仕事を交代できる状態でなければならないとされています。
ですのでフレームワークの設計は個々人の優劣が影響しないことが必須とされます。
よって、プロジェクトはまず予算と締め切りが決定され、次に画面数からプログラムのステップ数が計算され、人月が決定し、投入人数が決定します。予算の枠に収まれば仕事を受け入れて、それがダメなら受け付けない。
次にプログラムはすべからく同じ形で記述することが望まれます。個々人の力量の差はリスクでありますから優秀なプログラマが活躍することは望まれません。統一した設計理論に基づきチャートを書き、図に従ってコーダーがプログラムを行えば誰が書いても同じプログラムになるのです。そのためにフレームワークはオブジェクト指向は使いません。データは全て台帳に存在するのであり、データはロジックへの入出力にすぎません。ロジックは１つのチャートにて記述されるので、JavaでもRubyでもメソッド１つで十分です。
このようにして各フェーズ毎に必ず成果物のQAを受け、リスクを徹底的に排除すればプロジェクトに失敗は起こらないのであります。
ないはずです。
SI業界では個人は存在しません。
全てリソースです。
人月単価で計算される機械にすぎません。
優秀な技術者はリスクですので、個人の名誉を大切にされる方はSI業界には向きません。
でもNTTデータの社長さんは個人を大切にしてくださるとのことですから、そういうのが好きな人はNTTデータに行ってみるのも手ではないでしょうか？
Re:プログラマがやる気をなくした理由 (スコア:3, すばらしい洞察)
> 優秀なプログラマの影響は限定的であるというものでした。
> つまりプロジェクトが大きければ大きいほど個々人の力量の影響は限りなく
> 小さくなり、プロジェクトは全て人月で計算するのが当たり前だというものです。
これは経営者が優秀な技術者に金を払わないために使う
典型的ないいわけだね。
しかし優秀なプロジェクトマネージャは口に出しはしないが
これが嘘であることを知っている。
彼らはそんな素振りは見せずにシステムに参画している技術者の技量を
チェックしていて、システムの要となるような重要な機能や全体の性能を
左右するようなクラスやライブラリの作成、その他の難易度の高い仕事を
優秀な技術者に割り当てる。
この仕事の割り振りにおける調整は、それをしていることを
表向きには公表せずに行われる。
ひとつの理由は先にいった通り、全ての仕事は平等なふりをすることに
よって優秀な技術者に特別な報酬を払わずにすませることにある。
もう一つの理由は優秀な技術者以外の人間に劣等感を与えて
しまわないことがある。
劣等感を感じながら仕事をする奴らが増えると現場の士気が下がるからな。
もし親コメントみたいなことを本気で信じているひとがいるんだとしたら
そいつはきっとこの「表沙汰にはされない調整」の結果、難易度の高い仕事を
任せられないと判断された奴らだ。
難易度の高い仕事を割り振られたことがなく、だからそんな仕事があること
すらわからず、だから
「フレームワークの設計は個々人の優劣が影響しないことが必須」
みたいな絵空事を信じれてしまう。
ある意味、幸せな人たちだな。
それプログラマ？ (スコア:2, すばらしい洞察)
ソフトウェア開発系の会社に勤めたことないのですが、それプログラマですか？単なる翻訳者では。データの入出力が決まっているときにどうやってデータを変換するかの決定権がプログラマにないのならば、事実上コーディングの前段階でプログラミングが終わっているのでは。
四十九次
Re:プログラマがやる気をなくした理由 (スコア:3, すばらしい洞察)
>NTTデータの浜口社長は解決策を提示しているのでは？
はい、ですから浜口社長に共感される方はNTTデータに行かれるべきだと思います。
今現在、プロジェクトに問題が多発しているのは事実です。
しかし今の仕組みを変えるような大手術ができる企業が少ないのも事実です。
NTTデータ社長のような意見は少数派であるのが残念ですが現実です。
残念ですが今のところ多くのSI企業では単価の高い技術者にプログラムを書かせてくれることはありません。また若者から中堅までコードを読むことができず優れたプログラマが評価される環境は整っておりません。
また繰り返しますが優れたプログラマはリスクであり、評価されません。
今現在SI業界にはプログラムとは全く縁もなかった文系の学生を含め、手当たりしだいに人を集め半年の研修で一人前のSEとしてお客様先に送られることが多いのです。
プログラム等、誰でもできる低レベルな仕事だという定義が前提です。
このような業界に就職されるならプログラムを書かない覚悟が必要です。
今からSI業界に就職されるのであれば、管理職になり、人使いを覚えるか、お客様に食い込み、お客様自身が良くわかっていないシステム化を提案できる人になるしかありません。
評価の基準は利益のみです。
プログラマになりたくてSI企業に入るのは間違いですし、また下請け、孫請けの会社に入るのなら人権無し、残業代無しが当たり前の世界であることを覚悟してください。
またプログラマであることを誇りにする仕事ではありません。常に仕事は最低レベルの人間に合わせて実行されますので優秀な技術者に活躍の場はありません。DFDであれUMLであれ、フレームワークに合わせて図を書く人間がおり、図が書きあがってプログラミングが発注されるのです。優秀な技術者を育てる環境もありません。
また既に中国人、インド人への仕事の発注が始まっていますので将来があるかどうか良く考えられることをお薦めします。
プログラマでやっていかれるのならばWebアプリのベンチャーやGoogleのようなプログラマーをきちんと評価する企業に入るべきです。
SI企業の多くはお薦めできません。
NTTデータ社長の言うことはごもっともです。
問題は既に他のスレッドで書かれているとおりに現状を直すには時間がかかるでしょう。
優秀なプログラマをどう評価するのか、優秀なプログラマに払う高い金をどこから出すのか、優秀なプログラマをどう育てるのか、問題は山積みです。
何より優秀なプログラマがほとんど市場におりません。
NTTデータは最近非常にOSSに力をいれており、自社でOSSを開発し、他組織のOSSを研究し、多くの場で発表を行っています。良いプログラマを育てる環境は整ってきているようです。
後はお客様が短納期・コスト削減をより一層要求するなかでどうやってそれを実現し、かつ優秀なプログラマに高い給料を払うかです。今現在安く買い叩いているプログラマを支える仕組みをつくるのは並大抵ではないでしょう。Rod Johnsonやまつもとゆきひろが主張する少数精鋭の仕組みが果たして実現できるのか、それとも単純にSEの実力アップ（実装の理解）で終わるのかは注目に値します。
日本のお客様の多くは納期の短縮とコスト削減にしか興味がありません。それは当然であり仕方がないのですが、この劣悪な環境で誰もが短期の儲けを挙げることだけで精一杯です。
若い人や学生にはとにかく英語を勉強しろ、アメリカにいくかGoogleに入れとしか言えません。それ以外の人は一般企業の情報部門に入られることをお勧めします。発注側と受注側はまさに天国と地獄です。後は数少ないパッケージか組み込みでしょう。しかしそれらの幸せは長くないでしょう。皆、生き残るためには必死にならざるを得ない状況です。
Re:プログラマがやる気をなくした理由 (スコア:3, 興味深い)
プロフェッショナルの中のトップクラスと最低クラスでは2倍くらい違うのが普通。プログラマだけはトップクラスと最底辺が数倍～10数倍の違いがある。 トップクラスプログラマの半分以下の力しかないプログラマはこの業界から退場させるのがよい。と。
一理あるなぁと思いました。
手遅れでしょう (スコア:3, すばらしい洞察)
「ソフト産業は3K職種」などといわれて、学生の人気が下がったのはもうずいぶん昔の話でしょう。
これからその「常識」を切り崩していくことは、非常に困難だと思います。
# といって、インドや中国に外注…で全てが済むわけでもないんだな。
言っていることとしては、良い着眼点もありますね。「分業化」が魅力を半減させたのはその通り。
もう一つ、私としては「マニュアル化」も挙げたいところ。
人気が下がった？ (スコア:2, すばらしい洞察)
ITバブル期でも、プログラマの人気が高かった記憶は無いんだけど、そういう時代ってあったの？
Re:人気が下がった？ (スコア:2, おもしろおかしい)
# 時代は変わったねえ。
Re:人気が下がった？ (スコア:5, おもしろおかしい)
プログラムを書かせてもらえなくてやる気が出ない (スコア:3, 興味深い)
最近仕事に取り組む情熱を失ったなあと自分で感じているのですが、どうもコードを書かなくなった時期と一致しているような気がします。
趣味でプログラミングしろって? いやー、子供が生まれて家ではそんな余裕もなく……。ここ1年は数行のシェルスクリプト以上の量のコーディングをしていません。
おれにコードを書かせろー!
Re:プログラムを書かせてもらえなくてやる気が出ない (スコア:3, すばらしい洞察)
Re:プログラムを書かせてもらえなくてやる気が出ない (スコア:2, 興味深い)
上の管理がアホ過ぎていやになってしまって、結局情熱は取り戻せていません。
こんなんだったら自分で管理した方がましだよ、って思います。
個人的には一番情熱を持っていたのは、管理の仕事を始めた頃、
"オレならばあいつらとは違って、まともなプロジェクト管理をしてみせる"
と息巻いていた頃でした。。。
Re:プログラムを書かせてもらえなくてやる気が出ない (スコア:3, 興味深い)
優れた技術者が管理職の仕事もできるとは限らない。
優れた技術者が管理職の仕事を好むとは限らない。
優れた技術者が出世して管理職になると、現場にスキルのある者がいなくなる。
という問題がある、という指摘を聞いたのは、社会人になって間もない15年以上前。
（俺が知らなかっただけでもっと前からその指摘はあったかも知れない。）
何の進歩もない世界だな。
Re:プログラムを書かせてもらえなくてやる気が出ない (スコア:2, 興味深い)
そして、業界にいる人種が非常に偏っているため、その潔癖で攻撃的な性質が業界に由来するものか、人種に由来するものか、判断が付かないなあとも。
どうも、そういった性質の人ばかりが寄り集まっているために、現在の業界の問題点が形成されているような気がしてなりません。
何事につけ、交渉とか駆け引きとか、人間的にぐちゃぐちゃとやっていかなきゃならない問題を軽視or忌避するタイプの人ばかりが集まった結果、一山いくらで人間が売り買いされるような業界になってしまったというか。
理系的思考と、理系に集まる人間が持っていがちな人格的欠陥（酷い表現だけどうまい表現がとっさに出てこない）てーのは峻別すべきであって、そして後者はなんとかしていかなきゃならんと思うのですけど。
現状まだこの2つをごっちゃに考えている人が多いように見えます。
もっとも、切り離すことが難しい（不可能？）以上、分けて考えたところで意味ないだろ！という考え方もあるとは思うけど。
ゼロ戦 (スコア:3, すばらしい洞察)
開発部が同等の内容を上に進言したところ、「神国日本の兵士が当たる訳は無い」「気合いと根性でどうにかしろ」という理由（？）で、却下された。経験豊富なパイロットから死んでいき、機体は改良されてもパイロットが新米で機能が十分発揮できず、最後は「カミカゼ」に使われた。開発部（のＯＢ）曰く「カミカゼやらせるために機体を開発しつつけたんじゃない」。
コンピュータ業界の「上司」は、能力の差や経験値等を評価するのがとかくヘタクソ。能力や経験は、頭数や気合いと根性でどうにかカバーができると信じてやまない。戦後６０年以上経ってるのに、未だに「カミカゼ根性」が消えていない。残念ですね。
-- gonta --
"May Macintosh be with you"
Re:ゼロ戦 (スコア:5, すばらしい洞察)
どうせNHKだろうけど、マスコミは自分の論旨のためになんぼでも歪曲する。
最初、零戦に防弾装備が無かったのは海軍からの要求仕様に無かったから。
（海軍からの要求は速度と９６艦戦と同等の格闘力だけ。
艦載機であることも最初の要求には無かった）
堀越主任はパイロットに（機体規模の）違和感を持たれることを恐れて1500馬力級ではなく
1000馬力級のエンジンを選び、要求速度を満足させるために徹底的な軽量化を行った。
そのために急降下テストでの幾人かの犠牲を出すことにもなった。
パイロット不足は、日米の教育水準や教育方法にも影響されてる。
高卒が普通だったアメリカと、そうでない日本では操縦させる前に教えるべき
座学の量が違う。
車の免許を持ってるのが普通の奴と、一からエンジンの理屈を教えねばならんのと。
アメリカでは教習所方式で、しかも初等訓練は民間で行えたのに対し、
日本では師弟方式だった。
（教習所なら毎回先生も違うし、一定期間内に上に行けない奴はクビ。
大戦争の局面において、どっちが平均的搭乗員の大量養成に適しているか。
師弟方式では一番下の奴に授業のペースが合わされてしまう。
でも、一応メリットとしては下手な奴をすくいあげることはできる。）
日本の幹部な人たちは、とにかく「過去の成功体験」に依存しすぎ。
失敗しても前に成功したのに照らして「これが足りない、アレが足りない」となり、
それが物理的・時間的なものを自分が充足できないので精神的なものへと
転嫁している。
ビジネス書コーナー見たら大抵は「孔明の〜」とか「信長〜」とか
「成功体験」にあやかろうとするやつばかり。
そしていまだに「日露戦争」「日本海海戦」ですわ。
それを模倣しようとして戦った第二次大戦はかくのごとし。
ベトナムでの実戦の統計から、本番１０回まではベテランもルーキーも
被撃墜率は同じというのを見出してトップガンやアグレッサーを作って
成功した（本番に等しい体験をあらかじめ訓練でさせちゃう）アメリカのような
対処ができるようになるのを期待したい。
Re:ゼロ戦 (スコア:3, 参考になる)
昭和１８年からは、特別操縦見習士官制度を作って、学生を大量募集採用してますが、
途中からは、燃料難で教練の飛行を行うことも出来なくなり、操縦士達は飛行機の周りで
壕を掘ったりして日々過ごしてたそうですし。
更に、レイテ海戦の頃には、空母があっても、それに載せる飛行機も足りず、
空母３隻を囮で使って、敵を惹きつけて沈む役割にしたりしました。
燃料不足で出撃出来ずに港に停泊したままの艦船も多かった。
また、もし、戦局が好転しても戦争が昭和２０年の秋以降に戦争が長引いていたら、
慢性的な資源不足が食料問題にも影響してきて、日本本土は飢餓列島になると
予測出来ていたために、何が何でも秋の収穫前に終戦する必要があったと
言われています。結局、GHQの緊急食料援助で日本は生き延びた。
というわけで、日本の敗因は、技術、経営、戦略とかよりも、
元からの経済力の差の要因が大きい筈です。
ですから、ゼロ戦の話と、プログラマの仕事環境の話は、例え類似の構造が
あったとしても本質的な解にはなりえないと考えられます。
Re:ゼロ戦 (スコア:2, すばらしい洞察)
信長（天下を取る前に部下に暗殺された）は
失敗例のような気がしなくもないわけですが…
Re:ゼロ戦 (スコア:2, 興味深い)
さらに，いい年齢になってきて管理する側へシフトするべき者に対して「いや，お前はまだまだ現場だ．俺だって本当は現場でやりたいんだ．お前がうらやましい位だ」とか意味不明なことをいって阻害したりして，ホントに困ります．
…っていうクソバカ上司に苦労してるだけなのでAC．
中途半端に技術者上がりの偉い人 (スコア:3, 参考になる)
いわゆるコボラーに多いですよね。
日本のソフトウェア産業にトドメを刺したのは
団塊世代のコボラーが、1990年代初頭にオープンシステムやインターネットに付いて行けなくなり
自分達の技術者・専門家としての地位と名誉を守る為に、上流に聖域を作って
若い者・新しい技術を技術馬鹿 [nikkeibp.co.jp]だなんだと罵倒し始めた事じゃないかと思います。
Re:ゼロ戦 (スコア:2)
[Q][W][E][R][T][Y]
何がダメかって (スコア:3, すばらしい洞察)
工場メタファを用いる限りプログラマは工員なんだから。
このSIerがなぜ滅びたのか、わたしにはよくわかる。 (スコア:3, おもしろおかしい)
頭にニーモニックを叩き込み デバッガと共に生きよう 上司と共に夜を明かし 客と共にカットオフを謳おう
プログラマは、、、バイナリから離れては生きていけないのよ！
結局は (スコア:3, 参考になる)
(1)逃げない
(2)見捨てない
(3)物事の核心を検出できる
(4)優先順位を正しくつけ、物事の省略ができる
(5)ロジックを自分が理解できるだけでなく、他人にわからせることができる
(1)(2)はリーダー・メンバーともに必要。
これがない人間は働く資格が無い。
(3)が無い人間に発展はない。チンケなプライドに拘る人間は目が曇っていて(3)の能力が劣る。
(4)のできない人間は仕事が遅い。
(5)のできない人間は状況が動かせないので、他人の言いなりに地獄に引き釣りこまれる。リーダーはメンバーを理不尽から守るためにこの能力が無いと困る。
プログラマではなくSEの質が悪い (スコア:3, すばらしい洞察)
だから悪いのはSEか、そもそもSEとPGという今の線引きにしたことだと思います。プロジェクトが遅れるのは要件定義からコーディング手前までなのが多いので、SE（特に発注側SE）というものがうまく機能していないことは明らかです。ここに人件費掛かりすぎです。
スパイラル開発の思想を取り入れて、SEのやることを減らしてPG側にもっと仕事を投げるべきです。余計な調整が激減するはずです。でもってプログラマなんていう呼称はやめて、ソフトウェアエンジニアという呼び名が一般的になればいいと思います。
プログラミング以外の仕事 (スコア:2, すばらしい洞察)
モチベーション上げて仕事しても、他人の仕事が回ってくるようになって人手を減らされたりするし。自分で自分の首を絞めないように、ある程度手加減している人も多いかも。
経団連コペルニクス的転回 (スコア:2, 興味深い)
（建前）
下層で苦しんでいるプログラマを優遇しよう。
能力・業績主義で、出来る人には高給を。
（本音）
ホワイトカラー（SEエンジニア）＞ブルーカラー（プログラマ・運転）という区分をぶち壊して、全員を作業者に。
失敗プロジェクトは給料なし。
Re:経団連コペルニクス的転回 (スコア:2, すばらしい洞察)
正しくないんですよ。実態に合ってない。
しかし経営者・お年寄りの感覚はそんな物です。
ちなみにエンジニアは、平たく言えば職人と理解されています。本物のホワイトカラーでは無いのです。
コンサルは先生という区分だと思います。水戸黄門に登場する、いわゆる「先生」です。
こういう２０世紀的な身分概念によって、ある意味保護されてきた物を、既得権益としてチャラにするのが
「経営者の本音として利点」ではないかなーと思っているのですが、如何でしょう？
組み込み系やってますが (スコア:2)
今でもそんな感じですよね？
うちだけじゃないですよね？
Re:組み込み系やってますが (スコア:2, 興味深い)
うちはここ４～５年でそういう傾向から遠ざかりつつあります。工程横分割によるチームプレイを強要されるようになっています。私は開発工程を縦に機能単位で分割すべきで一人で完結させるべきだと思いますが、「V字モデル」だの「ウォーターフォール開発」だの、そういうある種の宗教じみた傾向に職場全体が流されているところです。
私一人（といっても他に数名の賛同者はいますが所詮下っ端、私は偽装請負の外注）異を唱えても、大きな図体は一度動いたらたとえ間違っていてもなかなか止まりません。三十六計逃げるにしかず、近々私は職場を離れることにします。管理帳票の山よ、さようなら。次のところでは正社員として自社開発に当たれるので、理想の体制を整えられたらと願ってやみません。
ほえほえ
ソフトウェア”工学” (スコア:2, すばらしい洞察)
その技術の継承は重要であると言うのをメディアを介して聞きます。
その熟練工の人達は、工学部, あるいは工業高校を出て社会人になってから、
ずっとその現場で腕を磨いていく（いた）訳ですよね。
じゃ、ソフトウェアは？
情報系の学部を出て就職。
30半ばで管理職…
ん？彼（彼女）には何が残るの？管理職としてのキャリア？
まあ確かに、”優秀な管理職”は必要ですよ。
そりゃもう確かに引っ張りだこ。
でもなんかおかしくね？
そもそも、管理職の能力と技術者の能力って違くね？
それに情報系の経験と知識だって蓄積されるもんだと思ってたんだがね？
移り変わりも激しいから蓄積なんか要らんってこと？
最初はへぼだったけど、
ちゃんと鍛えてみたら結構優秀だったってのは要らないのかな？
少数の入社時エリートプログラマの他は、使い捨てで良いんですか？
# そもそもそれも最初から凄腕な訳じゃなくて、自分で鍛えた訳でしょ？
前の会社にもいたねー
凄腕から、管理職になった人。
まあそれはそれで良かったんだろうけど、管理職もそこそこに、
現場に入れたあげたら活き活きしてたに違いないって感じだった。
ん、そういう人は要るけど、ちょっと使ってへぼだったらやっぱり要らない？
確かにあんまりへぼだったら困るか。
でも、普段ビジネスアプリ書いてて思うのは、
そんなに天才的な脳味噌が必要かというと、違うでしょ？
OOP だってちゃんと教育すれば、誰だって身に付けられると思わない？
個々の技術だって、ひとつひとつはそれほど難解じゃなかったと思うし…
え、やっぱダメ？金も無いし、そんな時間も無い？
と言うとあれかな？
日本人の言うところの日本人ソフトウェア産業プログラマの分類はと言うと、
1. 少数エリート凄腕プログラマ
2. まー使えるかな 30半ば多分管理職移行組
3. ダメポ。その後は？
おやおや、全体の技術の底上げには多数の（熟練者の）存在が強みかと思ってたんですが、
日本のソフトウェア業界は違うんですかね？
熟練工が多数存在するような仕組みには見えませんね。
熟練工を多数生み出すような仕組みにも見えませんね。
底上げも”少数の”エリート凄腕さん達が 全部 担うんですか？
ふぅーん、へぇーーー
Re:ソフトウェア”工学” (スコア:2, 興味深い)
いる時もあるし、それを発注する場合もある。それがすべてでもないけれど。
感じるのは、プログラマという言葉には、定型的な誰でも作れるものを
トレースするという感じのニュアンスが含まれている気がします。
誤解が含まれるのは、綺麗なコーディングやアルゴリズムを駆使して、
処理水準を上げたりしても、さほど評価されず、あっても内部評価か、
製品であれば売り上げでしょうか。
早く的確に仕事を上げるという部分で熟練工並?の能力と
評価されているのではないかなと。
コードを見れば一目瞭然という感じもわからなくはないですが、
むしろ、そのシステムが要求する専門分野に精通した知識や理解度を
反映し喜ばれる面が多いと感じてて、
熟練工というのはそういう専門分野をいかにソフトウェアとして反映するのか、
わからない分野であっても、理解度やコミュニケーション能力に重点が
おかれてる気がします。
では、コーディングの熟練工とシステム設計の熟練工。
どちらが上という話になると、システムを発注する人にとっては、
後者ではないでしょうか。
それはエリートではなくて、その対象分野に精通しソフトウェアと考えたとき、
山ほどの改善点のアイディアを持った人かもしれないです。
がんばろう。と自分に言い聞かせる。
Re:プログラミングは職人技です (スコア:2, すばらしい洞察)
＞下っ端作業員のくせにプログラマという尊称をよくも名乗れるものだ……
そうなるとやはりここはよくネタになる資格化ですかね。
プログラマとアマグラマの分離。
「１級プログラマほげほげプログラミング事務所」
という事務所を開くためには１級プログラミング資格が必要とか。
・・・さらに一歩踏み込んで
要件をまとめる側も資格が必要かな。
日本語を聞く能力、日本語を話す能力。
聞いた内容をまとめる能力。
定型ドキュメントがかけるかじゃなく、こういう技能ね。
# 是非、面接込みで
Re:プログラミングは職人技です (スコア:2, すばらしい洞察)
Re:プログラミングは職人技です (スコア:3, おもしろおかしい)
Re:システムエンジニアが評価されていない (スコア:2, 参考になる)
逆にそれらがしっかりしてれば、最悪RADツールのウィザード任せでも何とかなる。
Re:20年前に言えという感じです (スコア:2, 参考になる)
私も聞いた話ですが、アメリカのプログラマは、社会的地位はともかく、割り切って気楽に働けるようですよ。
年齢ではなく、スキルのみで評価される。仕事内容や責任が契約できっちり決まっていて、連帯責任ではない。
要するに第二次世界大戦のアメリカ兵のごとく、５時になったら前線から撤退できる。
一方、日本兵はジャングルに立て篭もって、しまいには万歳突撃という事みたいです。
Re:浜口友一さん (スコア:3, すばらしい洞察)
EVMS [atmarkit.co.jp]を採用するだけ、のような気がするな。
「工数に対していくら」がおかしいのは同感だけど、だからといってプログラマの仕事の成果を数値で評価できるとは思えないですね（生産性は計測不能 [capsctrl.que.jp]）。
僕は、いわゆる下請けプログラマーの仕事は経験がなく、長らくインハウスの開発をやっていて、最近SIerのPMに転職したのですが、実際ひどいね。下請けさんたちは搾取されることがわかっているから、相応の態度で仕事をしている（そうせざるを得ない）。こっちはこっちで経営層が数字で評価するから（経営層もまた、そうせざるを得ない）、経営層が満足するような数字を作ることを目指さざるを得ない。
結局、経営層が個々のプロジェクトの内情を正確に把握し、PMが個々の開発者を正確に評価する、という連鎖が好ましいのは正直わかってないわけではないと思う。理想はそうなんだ。だけど、どのような評価方法も、評価方法を定めた時点で本質ではなく評価方法に向かって仕事する奴らを生み出してしまう（計測性機能不全）。
大事なことは、そのような現実があるとしても、PMがプロジェクトのメンバーを信頼し、やる気を鼓舞し、技術的にも人間的にも伸びるように創意工夫をこらすことですよ。経営層はPMにそれを求めることです。単純に下請けからPMの評価を聞き出すだけでもいい。社内の数字からは見えてこない色々なことがわかりますよ（もちろん、下請けからの評判だけでPMを評価してもダメです）。
Re:いやー (スコア:3, すばらしい洞察)
ただし、プログラムを組む上で「何ができて何ができないか、何が簡単で何が難しいか」は分かってないとダメでしょう。
経営者は「何が簡単で何が難しいか」は分かってなくても構わない。
ただし、『誰が「何が簡単で何が難しいか」を分かっているのか』は分かってないとダメでしょう。
Re:なんつーか (スコア:2, すばらしい洞察)
腕がよいか否かはともかく、金の文句は言うだけ時間の無駄だからです。
Re:プログラマーって、そんなに特別なのでしょうか？ (スコア:3, すばらしい洞察)
プログラミングは「機械設計」や「電子回路設計」などと比べて，そうは違わないかもしれない．特に最近の「CPUの設計」などは，複雑さにおいてもソフトウエア並になっており，ある意味で最も近い分野だろう．
だがSIerにおいては，（建て前としては）プログラミングとは「機械製造」や「家電の量産」とそう違わないものだとされている．事実「設計工程」と「製造工程」に分けられている所もあるということだ．ゆえにプログラマーとは設計技術者ではなく，ネジを締めたり半田付けをするだけの作業員と同じとして扱われている．人月単価ベースになるのもこのためだ．
>出来上がるのが「物」ではないこと以外は、
そしてもう一つ．「ソフトウエアの持つ本質的な複雑さ」がある．
遙かに多くの部品で組み立てられた，遙かに複雑な部品を，遙かに短期間で設計している．ソフトウエアがハードより遙かに柔軟なものであるとは言え，やはりこれだけ複雑なものを設計するのは容易ではない．しかしSIerにおいては「それは「製造」であるので，誰がやっても同じ品質のものが確実に作れるはずだ」という建て前になる．そして建て前通りにならなかった責任が，すべて現場に押し付けられてきた．
なお製造工程については極めて効率化されており，「ビルド」ボタンをクリックするだけで，長くても数分程度終わってしまう．
参考：
「ソフトウェア設計とは何か？」
http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html [biwa.ne.jp]
「プログラマーというのは、飛行機を作るようなもの」
http://labs.cybozu.co.jp/blog/akky/archives/2006/12/programmer_making_... [cybozu.co.jp]
ここまでがソフトウエアと電気回路設計などの違い部分．日本のSIに関して言えば，これに加えて多重下請け構造や開発と営業の対立，日本企業の丸投げ体質など，産業構造の持つ本質的な問題も加わる．