アカウント名:
パスワード:
海外のソフトウェアの質が高いのはなんでだろう?その答えが知りたい。
それはそうと、国内・海外にかからわず、SEという職種に求められる能力って、他の職種と比較するとなんか異常に高くありません?技術があってマネジメントもできて営業もわかる… スーパーマンみたいな人じゃないと勤まらないような気がする。
海外のソフトウェアの質が高いかどうかは分かりませんが, 日本のソフトウェア, 特にユーザアプリケーションレベルの品質が低い理由は明確でしょう.
大きくは2つほど挙げられると思いますが, まず第一は人材のレベルが極めて低いことです.
一般に日本ではプログラミングレベルの作業を「製造」と称していますが, これは他の製造業に当てはめてみると「設計」段階になります. 言い換えてみれば, ソフトウェア産業において特異的なこととして, 「製造」というフェーズが無いか極めて小さいことになります. 他の製造業においては「設計」が行えるのは最低でも工専あるいは大学の工学部で基本的な工学の素養を身につけたものか, 熟練技能者以上となります. これに対してソフトウェアについては「製造」という表現に甘えて, プログラミングができれば誰でも本来の「設計」にあたる段階をやらせてしまっていることになります. これでは工業製品としてのソフトウェアの品質レベルが維持できるはずがありません. たとえて言えば日曜大工レベルの人間に家を建てさせるようなものです. ですから現実のソフトウェア品質管理においても, 問題になるのはテストを通ったかどうかだけで, その内部構造がどのようなものであっても, 具体的な問題が発生しない限りにおいて不問にされます.
第二の問題として, 日本のソフトウェア企業の財務体制が脆弱なことから, 必ず利益の出せる仕事しか行えないということがあります.
必ず利益の出せる仕事, すなわち評価の確定した分野での仕事となりますから, ソフトウェア産業における重大な利益獲得源である先行者有利は絶対に望むことができません. そのため, 業績に置ける利益率は下がり, 益々財務内容が悪化するという負の連鎖が進むわけです.
こう言っては何ですが, 大きく日本のソフトウェア業界というくくりで見た場合, 特定の企業を除いては技術者としての希望は皆無に等しいと思われます. サブジェクトにも挙げたダンテの神曲にも出てくる言葉「一切の望みを捨てよ」こそが最もふさわしいでしょう.
アプリの開発を依頼することがよくあるのですが、発注側としては 「以下の仕様を満たして下さい」という風に発注します。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
現実社会の厳しさを見た (スコア:3, 興味深い)
ビジネスが時間との戦いである事が分かった。
しかし考えて欲しいのは失敗した時のリスクが余りのも大き過ぎる事だ
大企業となれば何はともあれ、一度できた商品などの修正は莫大な資金を必要とする。
少なくても日本は質の
Re:現実社会の厳しさを見た (スコア:1)
海外のソフトウェアの質が高いのはなんでだろう?その答えが知りたい。
それはそうと、国内・海外にかからわず、SEという職種に求められる能力って、他の職種と比較するとなんか異常に高くありません?技術があってマネジメントもできて営業もわかる… スーパーマンみたいな人じゃないと勤まらないような気がする。
一切の望みを捨てよ (スコア:2, すばらしい洞察)
海外のソフトウェアの質が高いかどうかは分かりませんが, 日本のソフトウェア, 特にユーザアプリケーションレベルの品質が低い理由は明確でしょう.
大きくは2つほど挙げられると思いますが, まず第一は人材のレベルが極めて低いことです.
一般に日本ではプログラミングレベルの作業を「製造」と称していますが, これは他の製造業に当てはめてみると「設計」段階になります. 言い換えてみれば, ソフトウェア産業において特異的なこととして, 「製造」というフェーズが無いか極めて小さいことになります. 他の製造業においては「設計」が行えるのは最低でも工専あるいは大学の工学部で基本的な工学の素養を身につけたものか, 熟練技能者以上となります. これに対してソフトウェアについては「製造」という表現に甘えて, プログラミングができれば誰でも本来の「設計」にあたる段階をやらせてしまっていることになります. これでは工業製品としてのソフトウェアの品質レベルが維持できるはずがありません. たとえて言えば日曜大工レベルの人間に家を建てさせるようなものです. ですから現実のソフトウェア品質管理においても, 問題になるのはテストを通ったかどうかだけで, その内部構造がどのようなものであっても, 具体的な問題が発生しない限りにおいて不問にされます.
第二の問題として, 日本のソフトウェア企業の財務体制が脆弱なことから, 必ず利益の出せる仕事しか行えないということがあります.
必ず利益の出せる仕事, すなわち評価の確定した分野での仕事となりますから, ソフトウェア産業における重大な利益獲得源である先行者有利は絶対に望むことができません. そのため, 業績に置ける利益率は下がり, 益々財務内容が悪化するという負の連鎖が進むわけです.
こう言っては何ですが, 大きく日本のソフトウェア業界というくくりで見た場合, 特定の企業を除いては技術者としての希望は皆無に等しいと思われます. サブジェクトにも挙げたダンテの神曲にも出てくる言葉「一切の望みを捨てよ」こそが最もふさわしいでしょう.
Re:一切の望みを捨てよ (スコア:0)
アプリの開発を依頼することがよくあるのですが、発注側としては
「以下の仕様を満たして下さい」という風に発注します。
その仕様を満たしている限り、内部構造がどうであれ発注側では
どうしようもないかな?とよく思います。
ところが、現実に出来たアプリというのは仕様書は満たしているものの
妙なバグを抱え込んでいることが多々あります。
「どーやったら、こんなバグ作れるの?」と頭をかかえたくなるようなものが
良くあります。
発注
Re:一切の望みを捨てよ (スコア:0)
仕様を作ることが設計です。
つまり、あなたが設計しているのですよ。
仕様に合わせて作れる、作れないは、「製造」の問題でしょ。
Re:一切の望みを捨てよ (スコア:1)
Re:一切の望みを捨てよ (スコア:0)
「作らせている人間に設計能力が無い」
ととれる発言は、間違いなく自分の首を絞めている。
Re:一切の望みを捨てよ (スコア:0)
と実行すると、問題なし。
cd /hoge
./hoge
も問題なし。
その他、どのディレクトリにいて実行しても、問題無いんですが、
cd /bin
/hoge/hoge
とやった場合だけ、まともに動かない。
これもやっぱり仕様の問題なんでしょうか?
私があたまが痛いバグというのはこーゆーレベルな