「ソフトウェアの部品化」が失敗する理由 ― ＠IT
経済産業省のとある外郭団体の委員をしている方と話をしていたら「我が国のソフトウェア産業を改革するためには、ソフトウェアの部品化を推進しなければならない」と話していた。うーん……ソフトウェアの部品化かぁ……。正直、頭をよぎったのは1980年代後半に国内のソフトウェア部品の集積を目指して立ち上げられたが、失敗した「Σ（シグマ）プロジェクト」だ。 Σプロジェクトから20年の歳月を経て同じコンセプトが出現するには理由がある。日本の輸出を支えている製造業で、製品におけるソフトウェアの比重が高まるに伴って、業界全体がソフトウェア・エンジニアの不足および、ソフトウェア関連の障害の多発に悩まされているからである。 外注先企業が作ったソフトウェア障害に悩まされている製造業の視点から見れば「なぜ、ソフトウェアはこんなにトラブルが出るのか？ 部品化して、それぞれの部品の品質チェックをもっと厳しくし、その上で再利
「作っては壊す」過程があってこそ良いものが作れる
iPhone用の「はてな人気エントリーリーダー」、そろそろ形になってきたのだが、作ってみていろいろと発見した部分もあったので、全面的にクラス構成を見直し、大幅に書き直した。 HTTPで通信をしているコードが二カ所に分かれていたので、それをDataOverHTTP/XMLOverHTTPという二つのクラスにまとめ（XMLOverHTTPはDataOverHTTPのサブクラス）、はてな独自のRSSフィードを読んでいるコードから一般的なRSSフィードを扱うコードをくくりだしてRSSFeed/RSSFeedLoaderという二つのクラスにまとめて、あとで別のアプリケーションで再利用することを可能にした。それに加えて、各種ローダーに非同期通信をさせる主体をController（HotEntryViewController）からModel側（HateneHotEntry）に移すことにより、難解になりが
Fog Creek is now Glitch!
We’ve been thrilled to see the community embrace Glitch as the home for creating and discovering the coolest stuff on the web, so after 18 years, we’re saying goodbye to the Fog Creek name and betting our future on Glitch. TLDR: We’ve renamed Fog Creek to Glitch, Inc. to represent our single-minded focus on Glitch. We’re hiring for a bunch of new positions (with more to come!) and welcoming a slat
Joel on Software -
プログラマのためのユーザインタフェースデザイン 第 1 章 第 2 章 第 3 章 第 4 章 第 5 章 第 6 章 第 7 章 第 8 章 第 9 章 ストラテジーレターV 2002年6月12日 ミクロ経済学の補完財の原理について考えていて、私はオープンソースソフトウェアに関する興味深いあることに気がついた。それが何かというと、オープンソースソフトウェア開発に多額の資金を使っている企業の多くは、それが彼らにとって良いビジネス戦略だからそうしているのであって、突然資本主義を信じるのをやめて、「言論の自由と言うときの自由」に浮かれるようになったわけではないということだ。ストラテジーレターⅤ 5つの世界 2002年5月6日 5つの世界：すべてのソフトウェア開発が同じではない。 追記：インターナルシステム、コンサルウェア、パッケージソフトの間には大きなグレーゾーンがあり、この3つの世界はしばし
業務連絡。その２
・・・コホン。 先日に引き続き、業務連絡その２！（社内向け）。 ２ヶ月ほど前の話。 アメリカで急速に利用者が伸びているとあるサービスを 見つけたアメーバ事業部の2年目の若手社員が、 「社長、これうちでやりましょう！」 「いいねぇ。やろう。頼むよ」 （こういう感度の良く、ベンチャー精神をもった社員が いる限り当社は安泰だなぁ・・・） このインターネットサービス（詳しくは書けないですが）は、うちが やらなくても他のネットベンチャーが間違いなく手がけるだろう。 うちもスピードで負けていない。 ・・・そして２ヶ月後。つい先週のミーティング。 綺麗にカラーコピーされた企画書を持って、再度 プレゼンテーションされた。 その社員に。 「え？これだけ」 「はい」 「システム会社に発注してないの？」 「まだです」 「見積もりは？」 「まだです」 ・・・・・・・。 ・・・・・・・。 ・・・・・・・・・・・・・
僕はなぜアーキテクチャにこだわるのか (arclamp.jp アークランプ)
「僕はITアーキテクトです」と名乗るのが、昔は恥ずかしかったものです。ですが、ある時期から吹っ切れていました。やはり僕の原点なんだなと思って。 そのものではなく環境を見る 大体において、「そのもの」が悪いってことはないのです。日経SYSTEMSのコラムに書いたものを引用します。 「間違えたのはITエンジニアだから悪いのはITエンジニアである」ということから一歩進んで，「なぜITエンジニアが間違えなくてはならなかったのか」と考えるわけである。そのためには，プログラミングという作業全体を俯瞰し，その前後左右に何があるのかを見る ITエンジニアを取り囲む環境の中に，バグを誘引する要素がある 書き方がバラバラな仕様書，複雑で理解しにくいアプリケーション・フレームワーク，ドキュメントが無いライブラリ群，使いこなせないIDE（統合開発環境），など。いずれも，バグを引き起こす原因になることは説明するま
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
大学で身につけるべきは技能より教養だろ - 雑種路線でいこう
上野で飲みながら小耳に挟んだだけなので確かめた訳じゃないけど、いまどき本郷でさえCのポインタを理解できない学生がいたり、やれRubyだAJAXだと騒いでいるらしい。いやRubyは素晴らしい言語だし、ちゃらけた文系学生にプログラミングのイロハを教えるには最高だけどさ。 僕も断乎、教育にはJavaやC#よりPythonやRubyを推す。しかし本郷で騒ぐことじゃないだろ。Rubyを覚えたってRubyのように革新的な何かをつくれるようになる訳じゃなし。別にRailsやAJAXを齧るのは勝手だけど、きっと5年後には誰も話題にしなくなってる。空気のように普及してPHPのように時給数百円までコモディティ化するか、もっとクールなフレームワークが登場しているか、どっちにしても専門学校や職業訓練校で教えれば済むことだ。少なくとも本郷が血眼になって取り組むことじゃなくて、藤沢あたりに今も棲息している起業家予備軍
優秀なエンジニアは「入社時のスキルを問わない会社」には就職してはいけない
ちまたで問題になっているIPAフォーラム2007に参加した学生がエントリーを書いているのだが、それが半端じゃないぐらいのエンターテイメント。 ...IT産業というよりSIerの人気がないことについて語りたいだけなんじゃないかという顔ぶれだったし... ...はてなブックマークのコメントを見ている限りでは、パネリストの方々は相当現実の見えていない発言をしているようだ。... ...ITを専攻している学生達からは、「就職時にITスキルが問われないのだとしたら、大学でやっていることには何の意味があるのか」という質問が出ていたのだけど、明確な回答はなかったと思う。その人たちは、ちょっとショックを受けていたような気がする。... ...その流れで、「入社時にITのスキルを問わないというのは、Googleのような企業の方針とは反対であるが、それですばらしいサービスを作ることができるのか」という質問が出
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://kano.feena.jp/diary/20080309.html