アカウント名:
パスワード:
これは・・・レベルが低いのを許す土壌があるからでは? レベルの低いプログラムでも給料(評価)変わらなかったり レベルの高いプログラムでも給料(評価)変わらなかったり。
「許す」というより、むしろ推奨する雰囲気すらあります。
人身売買が恒常的な、いわゆる「SIer」と言われるような会社では、スーパープログラマがプロジェクトをぐいぐい引っ張るよりも、馬鹿でもプログラムが書けるフレームワーク(と呼ぶのもおこがましいもの)を喜んで採用したり開発したりしたがるものです。プログラミングの一般
ソフトウェア開発系の会社に勤めたことないのですが、それプログラマですか?単なる翻訳者では。データの入出力が決まっているときにどうやってデータを変換するかの決定権がプログラマにないのならば、事実上コーディングの前段階でプログラミングが終わっているのでは。
また既に中国人、インド人への仕事の発注が始まっていますので将来があるかどうか良く考えられることをお薦めします。
それは、本物の機械でもできそうだけど、いざ機械だけでやろうとすると結構大変だってことじゃないですか?簡単だったらMDDなんてとっくに一般的になってなきゃおかしいですよね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
プログラマがやる気をなくした理由 (スコア:4, すばらしい洞察)
好きなプログラムを仕事でやり始めたからですよ。
プログラミングは
本来、論理的思考能力を使う作業です。
その内容を知らないバカにその上の設計を任せるから
負担がプログラマにかかってくる。
馬鹿なプログラムを作らなきゃダメになる。
そりゃモチベーション落ちますよ。
仕事にしなきゃ、やる気を維持する方法はあったんです、と。
# あとコミュニティの軋轢とかもあるから、
# 書いたプログラムは公開しない、と。
Re:プログラマがやる気をなくした理由 (スコア:0, フレームのもと)
それもあるけど、日本のプログラマはレベル低すぎるよ。
論理的思考力は必ずしも学歴できまるわけじゃないけど
本来は院卒クラスがやるべき仕事だと思うよ。
なのに、オタク発祥の地だからわからないけど
能力ないのにプログラマ目指すやつ多いから
プログラマ自体の地位が下がるんだよなぁ。
Re:プログラマがやる気をなくした理由 (スコア:1, 参考になる)
これは・・・レベルが低いのを許す土壌があるからでは?
レベルの低いプログラムでも給料(評価)変わらなかったり
レベルの高いプログラムでも給料(評価)変わらなかったり。
>論理的思考力は必ずしも学歴できまるわけじゃないけど
>本来は院卒クラスがやるべき仕事だと思うよ。
これは、院卒の定義は必要ないでしょう。
わざわざ、学歴は関係ないということで
論理的思考力という単語が使われているのに。
そんなレッテルより、ある程度話をするだけで分かるでしょう。
話して分かる人か分からない人か。
Re:プログラマがやる気をなくした理由 (スコア:4, すばらしい洞察)
「許す」というより、むしろ推奨する雰囲気すらあります。
人身売買が恒常的な、いわゆる「SIer」と言われるような会社では、スーパープログラマがプロジェクトをぐいぐい引っ張るよりも、馬鹿でもプログラムが書けるフレームワーク(と呼ぶのもおこがましいもの)を喜んで採用したり開発したりしたがるものです。プログラミングの一般
Re:プログラマがやる気をなくした理由 (スコア:5, すばらしい洞察)
うちの会社に入ったときにまず教えられたのは、大きなプロジェクトでは優秀なプログラマの影響は限定的であるというものでした。つまりプロジェクトが大きければ大きいほど個々人の力量の影響は限りなく小さくなり、プロジェクトは全て人月で計算するのが当たり前だというものです。
もう1つ別に大事なこととして常に力説されるのが個人の力量に頼ったプロジェクトはその個人の存在がリスクであるということです。つまり優秀な個人は存在そのものが危険で常に誰もがお互いの仕事を交代できる状態でなければならないとされています。
ですのでフレームワークの設計は個々人の優劣が影響しないことが必須とされます。
よって、プロジェクトはまず予算と締め切りが決定され、次に画面数からプログラムのステップ数が計算され、人月が決定し、投入人数が決定します。予算の枠に収まれば仕事を受け入れて、それがダメなら受け付けない。
次にプログラムはすべからく同じ形で記述することが望まれます。個々人の力量の差はリスクでありますから優秀なプログラマが活躍することは望まれません。統一した設計理論に基づきチャートを書き、図に従ってコーダーがプログラムを行えば誰が書いても同じプログラムになるのです。そのためにフレームワークはオブジェクト指向は使いません。データは全て台帳に存在するのであり、データはロジックへの入出力にすぎません。ロジックは1つのチャートにて記述されるので、JavaでもRubyでもメソッド1つで十分です。
このようにして各フェーズ毎に必ず成果物のQAを受け、リスクを徹底的に排除すればプロジェクトに失敗は起こらないのであります。
ないはずです。
SI業界では個人は存在しません。
全てリソースです。
人月単価で計算される機械にすぎません。
優秀な技術者はリスクですので、個人の名誉を大切にされる方はSI業界には向きません。
でもNTTデータの社長さんは個人を大切にしてくださるとのことですから、そういうのが好きな人はNTTデータに行ってみるのも手ではないでしょうか?
Re:プログラマがやる気をなくした理由 (スコア:3, すばらしい洞察)
> 優秀なプログラマの影響は限定的であるというものでした。
> つまりプロジェクトが大きければ大きいほど個々人の力量の影響は限りなく
> 小さくなり、プロジェクトは全て人月で計算するのが当たり前だというものです。
これは経営者が優秀な技術者に金を払わないために使う
典型的ないいわけだね。
しかし優秀なプロジェクトマネージャは口に出しはしないが
これが嘘であることを知っている。
彼らはそんな素振りは見せずにシステムに参画している技術者の技量を
チェックしていて、システムの要となるような重要な機能や全体の性能を
左右するようなクラスやライブラリの作成、その他の難易度の高い仕事を
優秀な技術者に割り当てる。
この仕事の割り振りにおける調整は、それをしていることを
表向きには公表せずに行われる。
ひとつの理由は先にいった通り、全ての仕事は平等なふりをすることに
よって優秀な技術者に特別な報酬を払わずにすませることにある。
もう一つの理由は優秀な技術者以外の人間に劣等感を与えて
しまわないことがある。
劣等感を感じながら仕事をする奴らが増えると現場の士気が下がるからな。
もし親コメントみたいなことを本気で信じているひとがいるんだとしたら
そいつはきっとこの「表沙汰にはされない調整」の結果、難易度の高い仕事を
任せられないと判断された奴らだ。
難易度の高い仕事を割り振られたことがなく、だからそんな仕事があること
すらわからず、だから
「フレームワークの設計は個々人の優劣が影響しないことが必須」
みたいな絵空事を信じれてしまう。
ある意味、幸せな人たちだな。
それプログラマ? (スコア:2, すばらしい洞察)
ソフトウェア開発系の会社に勤めたことないのですが、それプログラマですか?単なる翻訳者では。データの入出力が決まっているときにどうやってデータを変換するかの決定権がプログラマにないのならば、事実上コーディングの前段階でプログラミングが終わっているのでは。
四十九次
Re:それプログラマ?と言うか、元祖ワーキングプア (スコア:2, 参考になる)
仕様がバラバラな上に抽象化レベルのAPIと低レベルのAPIが混在しているミドルウェアとアルファベット順に列挙されているだけのミドルウェア仕様書…どういうポリシーのミドルウェアなのか明記もなければ、サンプルコードすらない。
単純にポンチ絵で制御対象のシーケンスが定義されていて、過去コードを参考にせよ…と言われて読んでみたら旧いヴァージョンのAPIで仕様以前に概念が違っているし、ソースコードごとにロジックの統一性という物がないので移植も糞もない。
わかってるのはCoding StyleのTAB数とコメントアウトは//でやれ。開発環境はこれ。
それだけで、なんぼ問い合わせても新版の設計書が出てこないので一から旧いヴァージョンのロジック読み取りやって逐次ロジック組み直していて、逐次コードを書いてテスト…納期逼迫したら「一から作った人間が三週間でできたのに、なんであんたは何ヶ月かかっても成果出せないんだ」って偽装請負屋の営業から、お客さんからそのようなクレームがきたんだが、お前はなんなんだ?などと罵倒される
…内心では、「前のヴァージョンのコードが事実上の設計書で、独自書式のシーケンス図が仕様書と言う状況で作らされてるこっちと、既に詳細設計が終わっていたのを貰ってただCodingしただけのアチラと一緒にするなよ(-_-#)馬鹿野郎が(-_-#)」とか毒づきましたがね。飽くまでも内心でですが。
まぁ、そんなアホな仕事やら多重派遣でこれまた「コーダやって」って事で入れられて、基板のテストコードやらRTOSのドライバやら一日単位でコロコロとデバイスが追加されたり仕様が変わる物を扱ってテストしたデータを元請け担当者に渡していたら、急なリストラでプロジェクトが縮小になってしまい、
余波を被って降ろされる羽目になって、現場の元請け担当者から「続けてほしいんだけど、上が決めてしまって、話を聞いてくれない…なんとか引継名目で二週間時間稼ぎするからそれで許してくれ」と土下座とは行かないけど頭を下げられる始末。で、例によって偽装請負屋の営業筋はそういう現場の事情など知らないで上の御方の話を鵜呑みにして散々説教垂れてくる(;´Д`)
結局、その偽装請負屋と縁切れた瞬間に監督署に行って打ち合わせて、査察入れてもらって不払い残業分だけはふんだくりましたが、因縁付けて単価減らしてきた分の差額は取れなかった(-_-#)それだけでも百万近くになりましたが(-_-#)
まぁ、本当の意味での「コーダ」のお仕事やる羽目になって、上から降りてきた詳細仕様書の通りにチームリーダの割り振った部分のコード書くという仕事があって、当然ながら(?)基幹システムとの整合が取れてない設計でシステム的に破綻していてとりあえず外面と表面的な動きだけ取り繕って納品する羽目になったこともありましたが(´Д`)y-~その偽装請負屋とやった仕事では…
# ま、どーせこれからはそういう仕事する気ないからIDでいいや(´Д`)y-~
そーゆー環境で「コーダ」と呼ばれて仕事やったこともありますが、あー言う仕事だけは請けたくない…と言うか
Re:それプログラマ? (スコア:1)
翻訳で済むのなら楽なんですが。。。。。
実際は、原文無しで翻訳しろと言われたり、原文が間違いだらけで翻訳の段階で直してあげなきゃいけなかったり、原文の用意も自分でやらなきゃいけないとかで、単なる翻訳以上の手間を要求されとります(苦笑)
詳細設計まで出来上がっていて、コードに置き換えるだけで済んだことなんて、ここ数年間で一度もなかったですよ(笑)
つーか、下手に翻訳だけで済まそうとすると、「どうして間違いを指摘してくれないんだ!」と言われるし、挙句の果てに「高い単価払ってるんだから、それに見合う仕事しろ!」と罵倒される場合も(高いって言われても、それは自社に入ってる金の話で私の給与にはほとんど未反映なんですがね)
Re:それプログラマ? (スコア:0)
SI業界ではPGは最下層の住人であり、最も頭を使わないと定義されています。
プログラムは全て詳細設計書にて完成しているということになっております。
当然、UT以降にてバグが見つかった場合に図のほうを直さねばなりません。
たまたま同じプログラマーという言葉を使いますが、SI業界でのPGはコーダーであり、プログラマではありません。値段の安さだけで選別される機械です。
ですから今ではGlobal resourceと呼ばれ、より安い中国産、インド産が求められているわけです。
ケースバイケースだよ (スコア:1, すばらしい洞察)
君の考え方はウォーターフォール至上主義の二十年前のローテクだ。
設計をしっかりしたら、重要な部分をオブジェクト化し日本では作れないから海外に出したりしてしまう。これが悲しい。
ウォーターフォールの時代に仕様書を片っ端からダイレクトにソースコードにしていた時代はプログラマーの個を問われることはあまりなかった。しかし、オブジェクト指向になってから、そういう時代ではなくなった。
いまだに大規模はウォーターフォールしかできない、と思い込んでいるローテクプロジェクトマネージャが多いから、どうしようもないが。
たとえばjavaがこれだけ使われているのは、どんな分野にもいいクラスライブラリーがあるからだ。あまりにも自然にそれを利用できているから、もはや日本で設計時にそれなりのクラスライブラリーを作ろうという考えすら出てこない。
一方で、みんなが指摘しているとおり、できるだけ時間のかかる作り方をしたほうが、得するという現実問題もある。いいライブラリーを買えばいいところを、へたくそなコードを書き散らかして時間をかけて恥じないSI会社は多い。
つまり、ウォーターフォールタイプのSIではローテクのコーダーが必要で、本当の意味の設計まで見通せるプログラマーを必要としない。
一方、技術的に困難さを伴うSIもある。グラフィックを使いまくったり、ちょっとした通信を伴うものなどでは、肝心なところはライブラリーを作ってもらう。そこは「この人」という人間を使わないとプロジェクトの浮沈にかかわる。そのライブラリーを使って作る部分はコーダーでかまわない。
プログラマーの個を必要としない、というのはシステムプログラミングなんかの開発をしたことがないから言えるんだよ。
俺はまともなプログラマーも単なるコーダーも十把一絡げにプログラマーというから話が見えないんだと思う。
Re:ケースバイケースだよ (スコア:0)
あなたがどんなバックグランドな人かわからないから貴方の違和感はわからない。
でもこれ、本気で嘘偽り無く今年今日の現状なんです。
いいですか?
あなたは20年前と言ってくれたからむしろ私は嬉しいけど、これは今の現状です。
Javaでもオブジェクト指向を使わないのは当たり前なんですよ。
ごめんなさい。私の会社の名前は言えないけれどオブジェクト指向は難しいからJavaでオブジェクト指向を使うのはやめようと言った社内製のフレームワークを使っているのが私の会社です。
ウォーターフォールの時代とか過去形で語られてしまっていますが、今現在、ウォーターフォールでない開発があると思いますか?
むしろあなたの背景を疑ってしまいます。
あなたがSI業界の人であるならぜひ自信を持ってあなたの会社を公表して下さい。
だって私の会社はウォーターフォールでなければEnterpriseは絶対に失敗すると教育している会社なのですから恥ずかしくて公表できません。
というわけでぜひ貴方のケースをどんと公表してください。
よろしくお願いいたします。
Re:ケースバイケースだよ (スコア:0)
驚きました。ここでは公表しないけど、どこの会社かある程度想像
できますが。
たぶん、仕事を受注した親会社で使われている開発手法が十何年と
ほとんどかわらないまま、今に及んでいると考えられます。
私も、開発手法を説明したマニュアルを読んだがありますが、開発手法を
考えているのは、会社で業務として開発を担当している人ではなくて、
企業のシステム研究所とかの研究所で学問として研究する人が行って
います。
実際の現場で通用するような実学ではなく、あくまでも学問としての
研究の成果です。ですから、実際に業務に適用してうまくいく
Re:ケースバイケースだよ (スコア:0)
まさか、顧客の予算確保の都合と全く合わないサイクリックな方法でしょうか?w
社内の小さいプロジェクトじゃあるまいし、大規模ではありえません。
Re:ケースバイケースだよ (スコア:0)
小さなイテレーション回した方が、最低限予算分のモノは出てくるから予算確保の都合に合わせやすいんじゃないの?
Re:プログラマがやる気をなくした理由 (スコア:1)
特に、この人が主張していることを新人時代から叩き込まれる会社に勤めていた自分としては...
自分がモデレータなら、おもしろおかしい をつけたはず。
---- 末は社長か懲戒免職 なかむらまさよし
Re:プログラマがやる気をなくした理由 (スコア:0)
あなたの書いてることはSI業界なら誰でも知っている常識(理想論)だと思うけど
そんなきれい事だけで上手くいくなんて現場サイドでは誰も思っていませんよ?
>SI業界では個人は存在しません。
>全てリソースです。
>人月単価で計算される機械にすぎません。
>優秀な技術者はリスクですので、個人の名誉を大切にされる方はSI業界には向きません。
>
>でもNTTデータの社長さんは個人を大切にしてくださるとのことですから、そういうのが好きな人はNTTデータに行ってみるのも手ではないでしょうか?
日本はあなたの書いている考え方でやってきて問題がありまくりだから
NTTデータの浜口社長は解決策を提示しているのでは?
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:プログラマがやる気をなくした理由 (スコア:1, 興味深い)
俗に社内SEと呼ばれる業種でしょうかね。
これも正直場合によると言えるでしょう。
低コストと短納期を求められるのは社内であろうと
変わらないし。しかもコストセンターだから
新人だってろくにもらえないし。
ヘタすりゃ昇進し損ねた高齢社員の吹きだまりとか。
#最年少がとうとう入社5年目になりました。
終わり無き繁忙感と無縁でいられるかどうかは
事前に確認しておくと良いでしょう。
Re:プログラマがやる気をなくした理由 (スコア:0)
長期的にはそれはどの業種でも同じ。同じことをする人間なら安い方が良いに決まってる。だからむしろ日本人であることのリスク。
全くの余談。そのリスクを回避する術は権力構造に取り入って、多くの人が嫌う利権を確保して、establishmentになるしか無い。ありもしないスキャンダルで失脚したりと普通に働くよりも厳しいかもしれないが。
Re:プログラマがやる気をなくした理由 (スコア:0)
単価でしか提案が出来ない時点でそいつはSEとしてもアマチュア。
そんな方法論しか持ってないヤツも業界から放逐すべき。
本当に必要な要件だけはずさずに枝葉をこそぎおとして、+アルファ、お客様が喜ぶ提案が出来れば、価格で負けても余裕。
価格交渉でむしろ重要なのはお客様の予算枠ですね。
Re:プログラマがやる気をなくした理由 (スコア:0)
> 人月単価で計算される機械にすぎません。
それこそ本物の機械にでもできそうなことをわざわざ人間に高い給料払ってやらせるなんてとんでもない金の無駄遣いですね。
という程度の計算ができる「優秀な」設計者とか経営者もやっぱりリスクなんでしょうか。
できそうとできるのギャップ (スコア:1)
それは、本物の機械でもできそうだけど、いざ機械だけでやろうとすると結構大変だってことじゃないですか?簡単だったらMDDなんてとっくに一般的になってなきゃおかしいですよね。
vyama 「バグ取れワンワン」
Re:プログラマがやる気をなくした理由 (スコア:0)
> ないはずです。
で、実際のトコロはどうよ?
Re:プログラマがやる気をなくした理由 (スコア:0)
プログラムのステップ数なんて計算できるわけないのに・・・・
というか画面数が決まっている事にビックリしたwww
でも、信じてるマネージャはいるんでしょうね