日本のソフトウェア産業は「製造業」 - My Life After MIT Sloan
これは、MIT SloanのCusumano先生が本でも授業でもよく言ってる話。 面白いから忘れないうちに書き記しておく。 Cusumano先生は、Microsoft SecretやPlatform Leadershipで有名なソフトウェアビジネスの研究者。 日本の企業研究も色々されているし、一橋大学のビジネススクールで何年か教えてらしたりした日本通でもある。 そのCusumano先生が、ソフトウェア産業への取り組み方を比較して、こんなことを言っていた。 Europe: Software as a science －ヨーロッパにとってソフトウェアは「科学」 Japan: Software as production －日本のソフトウェアは「製造業」 India: Software as a service －インドのソフトウェア産業は「（プロフェッショナル）サービス」 U.S.: Soft
プログラミングを単純労働と捉える3つの理由 - GeekFactory
int128殿の会社では、 >プログラミングは誰でもできる、頭を使わない作業 と思う方が多くいるのかしら？ http://d.hatena.ne.jp/int128/20080414/1208181589 うちに限らず、多くの大企業SIerではプログラミングを単純労働と捉えています。その理由は3つあります。 （1）プログラミングは業務をプログラムに落とし込む単純労働 SIの開発手法（の考え方）は30年前から進化していません。業務をプログラムに落とし込む作業は誰がどうやっても同じようになるという思想に基づいています。現在のように高品質なフレームワークやライブラリが溢れる時代では、いかにそれらを組み合わせて作るかが効率化の鍵になります。組織のトップが進化した設計思想を理解しようとしないのは問題です。 30年前の設計思想であれば、プログラミングは業務をプログラムに落とし込む単純労働です。 （2）
プログラマーには、コーディングの生産性で10倍、コードレビューの速度では6倍もの能力差があるという
プログラマーの生産性をテーマにした有名な著書「ピープルウェア」には、最も優秀なプログラマと最低の成績のプログラマのあいだには約10倍にあたる生産性の違いがある、というデータが出てきます。 これは、1984年から1986年にかけて92社、延べ600人が参加したプログラミングコンテストのデータを分析した結果から導き出された結果で、課題として与えられたプログラミング作業の開始からコンパイル時のエラーを消すところ（第1チェックポイント）へ到達するまでにかかった時間を比べています。 グラフを見ても分かるように、最優秀者と最低者のあいだには作業時間にして約10倍のひらきがあります。また最優秀者は平均の約2.5倍の生産性だそうです。そして、COBOLやFortranのような旧世代のプログラミング言語と、PascalやCのような現代的なプログラミング言語でのコーディングでの生産性はほとんど同じであったそう
技術情報Wiki - 技術情報Wiki
Link: ソフト業界の労働環境(1d) マルチメディア関連ツール(1d) JBoss Seam関連(1d) JSF(JavaServer Faces)関連(1d) 言語・開発環境(1d) ドキュメント作成(2d) ExcelのVBA(2d) 読み物(4d) バグトラッキングツール(4d) Java関連(4d) 開発支援ツール(6d) Webで利用できるサービス(6d) ディスク関連ツール(6d) テスト・品質管理(6d) Webブラウザ(8d) .NETでの文字列処理(8d) Windows設定メモ(9d) セキュリティ関連(11d) データベース関連(14d) 周辺機器(15d) プロジェクト管理ツール(15d) JavaScript(16d) ネットワーク関連(20d) ソフトウェア業界(20d) 開発プロセス(20d) 開発に役立つデータ(22d) Web技術関連(24d) Web
浜口さんに贈るSI業界を良くする方法 - ひがやすを技術ブログ
浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
「渡された仕様書を実装するサラリーマンプログラマ」の悲哀
@ITの「業務用途でRubyを使う上での課題 」を読んでなんだか悲しくなった。 チーム開発でRubyを使ったときに今後起こりえる問題として、サン・マイクロシステムズ システム技術統括本部 チーフテクノロジストの下道高志氏は、こう指摘する。「他人の書いたPHPコードのメンテナンスはできない。Rubyはどうかといえば、現状はいい。しかし今後“職業プログラマ”ではなく、渡された仕様書を実装する“サラリーマンプログラマ”が増えてくると、コードのスパゲッティ化は避けられないだろう」。 【業務用途でRubyを使う上での課題 − ＠ITより引用】 これは言語の問題ではなく、日本のソフトウェア産業全体が抱える問題。以前にも「ソフトウェアの仕様書は料理のレシピに似ている」というエントリーで書いたが、本来のソフトウェア作りとは、絵を描いたり、音楽を作ったり、建物をデザインするのと同じ「創作活動」である。ドラッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.asahi.com/national/update/1027/TKY200710270270.html