タグ

システム開発と読み物に関するhrksb5029のブックマーク (15)

  • 「SIガラパゴス」を育んだIT部門の罪

    IT産業は、世界に類を見ないユニークなエコシステム(生態系)をつくり上げた。大手SIerを頂点とする多重下請け構造のピラミッドから成るITサービス業のことだ。日だけで独自進化し一大産業として繁栄した。私はこれを「SIガラパゴス」と呼ぶ(関連記事:日だけ!「SIガラパゴス」に明日はあるか)。 極めて便利な存在であるため、ユーザー企業はこの生態系を育んだ。その結果、日企業のIT活用は今や欧米企業に比べ周回遅れで、新興国の企業にも追い抜かれようとしている。 米国のITベンダーの日法人社長は、社の幹部から「なぜ日にはITサービス会社があんなにたくさんあるのか」とよく聞かれるそうだ。米国にもアクセンチュアやEDSのような企業は存在するが、数は限られているからだ。そして回答に苦慮する。 「日のユーザー企業は独自仕様のシステムを作りたがるのに、その開発を外部委託することが多いから」。

    「SIガラパゴス」を育んだIT部門の罪
  • Javaはアプリケーション開発言語として行き詰まっている、とアナリスト

    Javaによるビジネスアプリケーションの開発は複雑すぎる。開発チームはJavaからの逃避を検討すべきだ」という内容のレポート「Java Is A Dead-End For Enterprise App Development」(Javaはエンタープライズアプリケーション開発に行き詰まっている)を調査会社フォレスターのアナリストMike Gualtieri氏がブログで公開しています。 Gualtieri氏は、Javaはビジネスアプリケーションの開発言語として確固たる地位を築いており、COBOLが消え去らないのと同じように急に消え去ったりはしないけれど、Java以外の選択肢を検討した方がよいとしています。 ビジネス要件が変わり、プレゼンテーションレイヤで失敗した Javaが行き詰まっているというGualtieri氏のおもな理由をピックアップしてみましょう。 ビジネスの要件が変わってきた 変化

    Javaはアプリケーション開発言語として行き詰まっている、とアナリスト
  • セガが取り組んだ「ゲーム開発のプロセス改善策」

    家庭用ゲーム機の劇的な進化がゲーム開発をより困難にしている? 1983年に任天堂の「ファミリーコンピュータ」が登場し、社会現象を巻き起こしてから約26年。家庭用ゲーム機は飛躍的に進化を遂げ、現在の最新機であるソニーの「プレイステーション 3」(以下、PS3)、マイクロソフトの「Xbox 360」などでは、CGを駆使してまるで実写のようなリアルな映像が楽しめるゲームタイトルが次々と生み出されている。 こうした家庭用ゲーム機の進化に伴い、ゲームソフトの開発を手掛けるメーカーにとっては「より高品質なゲームタイトルを、より短納期に開発する」ことが求められるようになった。そのため、その開発プロジェクトも従来とは比べものにならないくらい規模が大きくなった。これが「開発工数とプログラムコード行数の増大によるバグの大量発生」など、さまざまな問題を引き起こしており、ゲーム業界全体の重大な課題となっている。

    セガが取り組んだ「ゲーム開発のプロセス改善策」
  • プログラマーには、コーディングの生産性で10倍、コードレビューの速度では6倍もの能力差があるという

    プログラマーの生産性をテーマにした有名な著書「ピープルウェア」には、最も優秀なプログラマと最低の成績のプログラマのあいだには約10倍にあたる生産性の違いがある、というデータが出てきます。 これは、1984年から1986年にかけて92社、延べ600人が参加したプログラミングコンテストのデータを分析した結果から導き出された結果で、課題として与えられたプログラミング作業の開始からコンパイル時のエラーを消すところ(第1チェックポイント)へ到達するまでにかかった時間を比べています。 グラフを見ても分かるように、最優秀者と最低者のあいだには作業時間にして約10倍のひらきがあります。また最優秀者は平均の約2.5倍の生産性だそうです。そして、COBOLやFortranのような旧世代のプログラミング言語と、PascalやCのような現代的なプログラミング言語でのコーディングでの生産性はほとんど同じであったそう

    プログラマーには、コーディングの生産性で10倍、コードレビューの速度では6倍もの能力差があるという
  • 第28回 日本企業を見限ったインドの“システム屋”から学んだこと

    経営者にとって、情報システムは頭痛の種になりがちだ。業務に必須だが投資に見合った効果が出るとは限らない。ほかの設備投資に比べて専門的で難解でもある。 野村総合研究所で約20年間勤務した後に、人材派遣大手スタッフサービスのCIO(最高情報責任者)を務め急成長を支えた著者が、ベンダーとユーザー両方の視点から、“システム屋”の思考回路と、上手な付き合い方を説く。 前回(第27回)で登場したインド人の“システム屋”経営者の言葉をもう1つ紹介したいと思います。彼から「日企業向けの仕事はもうやりたくない」と言われたことがあります。英語力の問題ではなく、日人はそもそもシステム開発に向いていないというのが彼の主張です。 これを聞いた私は、その場では苦笑するほかありませんでしたが、日人の“システム屋”として悔しいという感情が残りました。しかし今ようやく、この意見には反論が可能だという思いに至りました。

    第28回 日本企業を見限ったインドの“システム屋”から学んだこと
  • Manifesto for Software Craftmanship(ソフトウェア職人マニフェスト)にサインしよう:An Agile Way:オルタナティブ・ブログ

    最近、アジャイル開発を「繰り返し型」の形として採用するのはいいが、そこで実際に開発活動をする人たちのスキルに、再度焦点が当たっている。つまり、プロジェクト管理手法としてのみアジャイルを取り入れても、破綻する、ということだ。ソフトウェア開発技術は、匠の技であり、この技術は職人の技だ。この議論は、 James Shore の「アジャイルの衰退と凋落」 Brian Marick の「What's missing from the Agile Manifesto」 Uncle Bob Martin の「Craftmanship over Crap」 などからの流れなのだが、ついに、「ソフトウェア職人宣言」が出現した。以下に、訳文とそのURLを書いておくので、同意する人は、サインをしよう! ソフトウェア職人宣言(原文: http://manifesto.softwarecraftsmanship.o

    Manifesto for Software Craftmanship(ソフトウェア職人マニフェスト)にサインしよう:An Agile Way:オルタナティブ・ブログ
  • 「測定できないものは制御できない」は誤りだった。-- by Tom Demarco:An Agile Way:オルタナティブ・ブログ

    ソフトウェア工学の祖の一人である、トム・デマルコが、最近IEEE Software 誌に、過去のソフトウェア・メトリクス賛美を悔い改める記事を書いている。 「ソフトウェア工学」というコンセプト-その時が来た、そして、その時は去った。http://www2.computer.org/portal/web/computingnow/0709/whatsnew/software-r 1982年に、デマルコは有名な「計測できないものは制御できない」という一文から始まる、『品質と生産性を重視したソフトウェア開発プロジェクト技法』という名著を書いている。このドグマは、ソフトウェア工学の考え方に強く根ざしている。むしろ、すべての「工学」という活動は、科学や経験から得た知見を使って自然現象をコントロールし、人間の役に立てることをその定義としており、そこでは測定を元にしたコントロールという概念はその中核にあ

    「測定できないものは制御できない」は誤りだった。-- by Tom Demarco:An Agile Way:オルタナティブ・ブログ
  • ライブドアのすべらない話!?   ディレクター×エンジニアのガチンコ座談会 : LINE Corporation ディレクターブログ

    こんにちは、櫛井です。 ライブドアの現場の空気感とか文化的なものを少しでも皆さんに伝えられればなあという思いから、「ディレクターとエンジニアと対談したいね」と1年以上前から話していました。 今回は、ディレクターとエンジニアがそれぞれ二人ずつ登場し四人で対談をしてみましたのでその模様をお届けします。内容に関してはニュアンスが変わらないよう可能な限り発言そのままでお届けいたしております。あらかじめご承知おきください。 ではどうぞ。 ■出演者プロフィール ・栗原由樹 職業:webエンジニア/シニアマネージャー 1977年生まれ、2001年ライブドア入社。受託制作時代を経て現在はモバイル自社サービスを手がける。デジタルガジェットを愛しすぎて月々の支払いがえらいことになっている。Yokohama.pm主宰。更新が少ないことで有名なTech Blogの担当でもある。Perlハッカー。 ・井原郁央 職業

    ライブドアのすべらない話!?   ディレクター×エンジニアのガチンコ座談会 : LINE Corporation ディレクターブログ
  • SW開発で火を噴くパターン - プログラマの思索

    【1】SW開発ではいつも結合テスト以降で火を噴く。 設計、開発、単体テストまで順調であっても、結合テストから受入テストに至るまでに致命的な問題が発覚する。 例えば、下記のような問題がいつでもどこでも噴出するのではないか。 設計書には、複数の画面遷移による業務フローが考慮されていなかった。 業務のインターフェイスがシステムとして整合性が取れていなかった。 シナリオに従ってテストしたら、設計時には気付かなかった業務フローが見つかったり、想定しなかったデータが作られて、その対応が漏れていた。 つまり、設計漏れ。 実際に結合テスト環境で動かそうとすると、そもそも動かない。 実は、DB環境にViewやプロシージャがもれていた。 あるいは、帳票出力やPDF出力、バッチ処理などに必要なサードパーティのライブラリがテスト環境に無かった。 モジュールをビルドして、Webサーバーを再起動する作業が手順化されて

    SW開発で火を噴くパターン - プログラマの思索
  • すごい現場

    皆はどんな現場で,どんな仕事をしているのだろう。何に悩み,どうやって乗り越えているのだろう。プロの仕事とそうでない仕事の境目はどこにあるのだろう。システム開発や運用の現場を歩き,そこで見聞きした面白い話,感動的な話,すごい話を紹介します。 ・大企業からベンチャーまで ぼくはこんな現場を歩いてきた ・SEを潰した値引き 信頼も連帯感も消えた ・期限は明日――若手SEの気迫を見た ・寝不足のプレゼン ドリンク剤も効かず ・中国の開発現場もすごい 若き社長が率いる修羅場 ・オンラインダウン発生! あの日,何もできなかった ・建築設計事務所で見た 巨匠のすごいレビュー ・コンサル泣かせの現場 “小さな王国”の弊害 ・逝去した巨匠への追悼 感激したあの言葉 ・人の話を聞かない40代 あるコンサルの失敗 ・過ぎたるは及ばざるがごとし 作りすぎたRFPの悲劇 ・人間万事塞翁が馬 得難いレクチャーの裏事情

    すごい現場
  • 4Gamer.net ― 日本のゲーム業界ってほんとにヤバイの? さすらいのゲーム業界人 島国大和氏に本音のところを聞いてみた

    ゲーム業界ってほんとにヤバイの? さすらいのゲーム業界人 島国大和氏に音のところを聞いてみた 編集部:TAITAI 東京ゲームショウ2008の基調講演にて,日ゲーム産業の危機を訴えたスクウェア・エニックスの和田洋一氏 TGSフォーラムにおけるスクウェア・エニックスの和田洋一氏や,Gamefest 2008におけるカプコンの竹内潤氏の発言にも見られるように,昨今(……というか,結構前からだが),日ゲーム産業に対する危機感を表明する業界人が増えてきた。ゲーム産業が世界的には右肩上がりの成長を続けるなかで,一時期は世界を席巻した日ゲームのシェアは落ち込み,また開発力/資金力の面でも,欧米の企業に水を開けられつつあるのではないか……というのが,彼らの持つおおよそ共通した危機感の内訳。 実際,3Dゲーム全盛のここ数年,目を見張るほどのグラフィックステクノロジーの進歩と,それに見合

    4Gamer.net ― 日本のゲーム業界ってほんとにヤバイの? さすらいのゲーム業界人 島国大和氏に本音のところを聞いてみた
  • SEとPG、どっちが頭がいい?(2):下流から見たIT業界:エンジニアライフ

    刺戟的な題名で続けます。 前回は日独特のSE/PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE(システムエンジニア)だというものでした。 ●C言語@UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ

    SEとPG、どっちが頭がいい?(2):下流から見たIT業界:エンジニアライフ
  • 「テストをすべきなのは知っているが,現実にはできない」という現場の状況をいかに打破するか,気鋭のソフト開発者とテスト技術者がパネル討論

    「テストをすべきなのは知っているが,現実にはできない」という現場の状況をいかに打破するか,気鋭のソフト開発者とテスト技術者がパネル討論 Developers [Test] Summit 2008(デブサミTest) 「建前ではなく実際にテストを普及させるにはどうすればいいのか」。2008年4月23日,東京・九段で開催されたテストに特化したソフトウエア開発者向けカンファレンス「Developers [Test] Summit 2008(デブサミTest)」で「【徹底討論】テストなんていらない?!-テストを,どこまでやるべきか?」というパネル・ディスカッションが開催された。 司会を務めたのはタワーズ・クエスト プログラマ兼取締役社長であり,テスト駆動開発(TDD)の日での第一人者である和田卓人氏。同氏に,オープンソース・プロジェクト「Seasar」のチーフコミッタであるひがやすを氏,テストの

    「テストをすべきなのは知っているが,現実にはできない」という現場の状況をいかに打破するか,気鋭のソフト開発者とテスト技術者がパネル討論
  • Djangoへの片思い日記 - ■Struts脳の恐怖とRails

    Strutsは良いフレームワークであった。 登場時のStrutsは MVCを体現しWebフレームワークとしてプログラマ達に夢を見せた。 今見てしまえば冗長で可読性の低い設定ファイルに 糞のようなtaglibとゲロのようなjspであるが それでも当時はセンセーショナルだった。 しかし、その後、Strutsには悲劇が起きる。 あまりにもセンセーショナルなデビューのおかげで それを金に換えようとしている奴らに目を付けられてしまった。 人月計算とExcelスーツで出来ている奴らだ。 奴らは Strutsをいかに簡単であるか宣伝し 役に立たない講習会で金を取り sessionが何なのかすら知らない人間を大量に生み出した。 そうやって生み出されたStruts脳人間は 「動くコードが正義」の負の面を体現し スパゲティを更に絡ませたActionFormを書き 解読不能なActionを書いた。 勉強など一

    Djangoへの片思い日記 - ■Struts脳の恐怖とRails
  • プログラマなら人月なんかさっさと超えろ - 矢野勉のはてな日記

    Java, プログラミングノリノリで書いてみる。 人月というのは「人月の神話」以来、現場の技術者にとっては「お金の計算にしか使えない単位」なのですが、発注者側に分かりやすいということでいまでも大はやりしています。というか受注者側もまじめにこの単位で計算しています。 そしてJavaの世界というのは、私のようにJavaが大好きだからやってる、という人間はすごく少数派で、「そろそろJavaでもやっとくか」「Strutsの使い方覚えたからもういいか」「できればJavaなんかいじりたくないなー。俺も早くプログラマに『これやっといて』って言えるようになりたい」という人のほうが多いのが実情なんですね。その点Rubyの世界は、今は「好きだからやってる」人が圧倒的でしょう。プログラム能力の高いJavaプログラマを探すのは、プログラム能力の高いRubyプログラマを探すよりずっと大変だろうと思う。 Javaの世

  • 1