選んだのは「内製回帰」の道――ひとり情シスの挑戦 － ＠IT自分戦略研究所
ITコスト削減によるユーザー企業の「内製化」の波が生まれている。SIerに外注するのではなく、自社のシステムを自ら作り出す。そうした「内製化」にこそビジネスとシステムの未来があると信じ、SIerからユーザー企業へと転身したエンジニアが、「内製化の可能性」と「やりがい」について語る。 第2回｜1 2｜次のページ 「GoTheDistance」というブログを運営している湯本と申します。簡単に自己紹介させていただきます。 2003年に、とあるユーザー系大手システムインテグレータ（SIer）に新卒で入社し、プログラマ、開発リーダー、プロジェクトマネージャ（PM）、コンサルタントというキャリアを歩んできました。 振り返ってみると、とても恵まれたキャリアを歩ませていただいていたと感じます。ですが、さまざまなユーザー企業さまのお話をお伺いしているうちに、システム開発は「内製」に向かうべきである、と感じる
【Top10】さらばDLL地獄、純関数型OS「NixOS」 － ＠IT
2位となった記事、「Linuxに勝てなかったPlan 9」は、十分に良い既存技術を、新規の技術で置き換えることは、たとえそれがより洗練されていたとしても難しいということを指摘したものだった。すでに広く普及していて使われているLinuxを置き換えるほどには、Plan 9がもたらすメリットは十分に大きくなかった。 この言及に対して、その名もずばり「Plan9日記」を公開しているoraccha氏から貴重なご指摘をいただいた。該当段落を引用すると、 また、研究OSってそんなもんだよという思いもある。Linuxという下位レイヤを維持するために、日々膨大な人的／知的リソースが投入されているわけだけど、Plan9のような少数精鋭による思考実験も、新しい進化のためには必要だ。その成果が新しい燃料として、実用OS（Linux）に投下されると。 という指摘だ。新しいアイデアを実際に動く実装で試すために研究OS
L'eclat des jours(2008-01-15) メモ
_ メモ ふと気づいたが、ソフトウェア産業＝工業という見方はよく反論の対象となるわけだし、実感としてもそれ（反対意見）は正しそうに思うのだが、実はやはり、その見方が正しいと言えるのではないだろうか。 レベルの設定が間違っているということだ。 工業は最初から、今の工業になったわけではない。 歴史の教科書的には、家内制手工業が来て（江戸時代末期の織物産業）、工員大量導入時代（明治の冨山あたりの時代）が来て、ベルトコンベア時代のオートメーションが来る。 それでいくと、単に、家内制手工業から工員大量導入時代のあたりにいる、というのを、ベルトコンベアと比較するからつじつまが合わない、ということではないか、ということ。 だから、専門的にもまだ近代の曙程度のレベルなんじゃないだろうか？ プログラマは設計をしているといっても、ベルトコンベアレベルに至っていなくて、せいぜい機織機を作っている程度に過ぎず従っ
仙石浩明の日記 「ソフトウェア開発」は「モノ作り」ではない
いつのころからか、 ソフトウェア開発がモノ作りに喩えられるようになった。 典型的なのは、製造業(例えば自動車製造)と IT 業界とを比較して、 前者が高度にシステム化されているのに対し、 後者がまるで家内制手工業のようだ、という批判である。 日経ビジネス online の記事に次のようなくだりがあった: 「というより、何といいますか、経営トップからすると、 ITはとにかく非常識な世界だ、としか思えないのではないかなあ。 例えば大きなシステム開発プロジェクトに取り組むと、 すぐ100億円を投資する、という話になってしまう。 100億円の経常利益を出そうと思ったら本当に大変。 ところが、100億円を投じたのに、期限までに完成しない、 出来上がってきたものが当初計画と違う、 直そうとするとさらに金がかかる。 こんなことが起きるわけですから、『一体なぜなんだ』と経営トップは思うわけです」 IT業界
ソフトウェアとソフトウェア以外のものを比較する : 小野和俊のブログ
このところとみに思うのは、ソフトウェアを他のソフトウェアを比較するのではなく、ソフトウェアをソフトウェアでないものとこそ比較しなければならないということである。 例えば Ajax vs. Flash を議論するのではなく、Ajax や Flash を駆使して開発された Web アプリケーションでも実現できなくて、しかし今自分の目の前にある紙と鉛筆では実現できることが何かを考えることである。ふと思いつくときというのは、編集性も保存性も高くコピー＆ペースト等の各種機能を持った Word や一太郎で文章や図表を作成しながら考えているときではなく、鉛筆で思いついたことくしゃくしゃになった紙に書きなぐっているときだったりする。 ソフトウェアについて考えてるとき、必ずしも PC やサーバーの上で動作することを前提として考えるのではなく、例えばマッシュアップしたら面白そうだと思うサービスがあったとき、そ
さよならコピーレフト | OSDN Magazine
Web 2.0は、オープンソースやフリーソフトウェアにどのような影響をもたらすのだろうか。Web 2.0はフリーソフトウェアの味方なのか、敵なのか。 ここのところ、「Web 2.0」という言葉がソフトウェア業界を席巻している。 しかし、その意味を正確に理解している人はほとんどいない。そもそも提唱者 Tim O’ReillyのWhat Is Web 2.0からして、対比的に「Web 2.0的な」事例はいくつも挙げてはい るが、言葉でうまく定義できているわけではない。その事例にしても、Web 1.0とどこが違うのかよく分からないものもある。例えば、CMSとWikiがどう本質的に違うのか、筆者には今ひとつピンと来ない。 ただ、流行ものには流行るだけの意味はあるもので、Web 2.0という話が全 く無意味かと言えばそんなことはない。ここ数年で、ソフトウェアの開発が発 想のレベルでだいぶ変わってきた
高木浩光＠自宅の日記 - ウイルスバスター2006は存在しないサーバ名もトレンドマイクロに送信する, ウイルスバスター2006はHTTPSサイトのURLもトレンドマ..
■ ウイルスバスター2006は存在しないサーバ名もトレンドマイクロに送信する 25日の日記に書いたように、 ウイルスバスター2006のフィッシング対策機能（Internet Explorerのツール バーとして搭載された機能）は、ユーザがアクセスしようとした任意のサイト について、アクセスする前の段階で、トレンドマイクロのサーバにそのURLの 全部を送信して、「評価」をもらった後、IEのアクセスを続けさせるかを判断 するようになっているそうだ。 しかし、DNSで名前解決できないホスト名を指定したURLにアクセスしようとし たときにも、そのURL文字列がトレンドマイクロに送信されてしまう。 つまり、例外なくどんなURLでも送信されるようだ。 たとえば「http:/a/」という文字列をIEのアドレスバーに入力してエンターキー を押すと、ウイルスバスターが自動的にTCPポート80番でトレンドマイ
習熟度でインターフェースをわけないということ - koyachiの日記
はてなおやさんがあいかわらずいいことを言っています。この文章の本質は最後のほうに書かれていることだと思いますが、その前振り(といったら失礼かも)もインターフェース的に重要です。 はてなブックマークをより使い易いように改良したいと思うけど、それは「初心者に使い易い」ようにする観点ではなく、あれはウェブを見るのが大好きな人たち向けのツールなんだから、初心者が成長してきたころに使うためのツールなんだと。 だから、「使い易い」というのと「初心者にわかりやすい」というのは別の話なんだ、そういう風に考えながら色々改善する。「初心者"にも"分かりやすい」のはもちろんベストですが、それが「初心者向け」に変化してしまって、やたらと説明文の多い設定画面だとか、最小限で済むはずのインタフェースが冗長になってしまったりとか、そういう罠にはまらないように。 naoyaのはてなダイアリー - 3年前の自分は別人、を他
高木浩光＠自宅の日記 - 適切な脆弱性修正告知の習慣はなんとか広まらないものか, 「はてなツールバー」がHTTPSサイトのURLを平文のまま送信していた問題,..
■ 適切な脆弱性修正告知の習慣はなんとか広まらないものか 2日の日記の件について、伊藤直也さんからトラックバックを頂いた。話は2つに分ける必要がある。1つ目は、一般にソフトウェア開発者・配布者が、配布しているソフトウェアに脆弱性が見つかって修正版をリリースしたときに、ユーザに伝えるべきことは何か、また、どのような方法で伝えるべきかという話。2つ目は、JVN側の改善の余地の話。 1つ目の話 はてなは以前から、Webアプリに脆弱性の指摘があって修正した場合、それを「はてな○○日記」で事実関係を公表してきた*1。これは、他のWebサイトの大半がそうした公表をしていない*2のと比べて、先進的な対応であると言える。 しかし、今回のはてなツールバーの脆弱性は、Webアプリの脆弱性ではなく、「ソフトウェア製品の脆弱性」である*3。一般に、Webサイトの脆弱性は、修正した時点でその危険性は解消するという性
Macintosh Human Interface Guidelines (HI Guide)
Inside Macintosh: NEW: Aqua Human Interface Guidelines This document describes how to design your application for the Mac OS X user interface, known as Aqua. Primarily intended for Carbon and Cocoa developers娊ut also applicable for Java developers庪ho want their applications to look right and behave correctly in Mac OS X, this document provides examples of how to use Aqua interface elements. Click
木走日記 - 抜本的改良は手遅れな東京証券取引所システム〜問われる技術立国日本の脆弱性
●実は手遅れな東京証券取引所のシステム処理能力拡大策 東証の社長が株式売買システムの約定処理能力について「1日当たり700万件以上に引き上げたい」との意向を表明したそうです。 【東証問題】「約定能力を700万件以上に引き上げたい」、西室社長兼会長が表明 東京証券取引所の西室泰三社長兼会長は1月19日、株式売買システムの約定処理能力について「1日当たり700万件以上に引き上げたい」との意向を表明した。現在のシステムでは、1日当たり450万件が限界。1月30日のシステム刷新で約定処理能力を500万件まで拡大するが、さらなるシステム拡張をしたいとの考えを示した。 東証は1月18日、ライブドアの強制捜査開始による影響で約定件数がシステムの限界に迫り、午後2時40分に東証1部・2部・マザーズ市場の全銘柄の取引を強制的に停止した（関連記事1、関連記事2）。当日の会見で、東証は「年内にも1日の注文処理能
お知らせ
タイトル・・[入門+実践] 要求を仕様化する技術・表現する技術 出版社・・・技術評論社 A5判／368ページ 価格・・・・定価 ２５８0円（＋税） ISBN4-7741-2523-7 発売・・２００５年１０月７日 都内大型店では９月末に並ぶようです ようやく、Software People vol.4（2004年の４月刊）で公開した要求の仕様化方法「要求の仕様化入門」が本の形にまとまりました。雑誌で公開したあと、読者の皆さんから大きな反響があり、急遽、内容と範囲を広げて原稿の作成に取り掛かったものですが、途中、私の本業であるSPIのコンサルティングが忙しくなったために、当初の予定より、６月以上も遅れてしまいました。 本書は、雑誌に公開した内容も、そのほとんどを書き直し、紙数の関係で雑誌では公開できなかった要求の表現や仕様化のテクニックもたくさん盛り込みました。事例もできるだけ多
Martin Fowler's Bliki in Japanese - ヒューメイン・インタフェース
http://martinfowler.com/bliki/HumaneInterface.html Ruby界隈で「ヒューメイン・インタフェース」という言葉を何度も耳にした。 この言葉は、クラスのインタフェースを記述する際のrubyistたちの姿勢(attitude)の一部を表したものである。 APIの設計については、2つの異なる考え方を対比していくと面白い（もうひとつは最小インタフェースである）。 ヒューメイン・インタフェースの肝は、みんなが何をやりたいかを見つけ出し、何度も起きることを簡単に行えるためのインタフェースを設計することだ。 最小インタフェースとの明確な違いは、ヒューメイン・インタフェースの方が大きくなる傾向があるという点だ。ただ、ヒューメイン・インタフェースの設計者はインタフェースが大きくなることをそれほど気にしてはいない。 以上のことは、ヒューメイン・インタフェースで設
Martin Fowler's Bliki in Japanese - 最小インタフェース
http://martinfowler.com/bliki/MinimalInterface.html 最小インタフェースとはAPI設計のスタイルである。 ここでは、ヒューメイン・インタフェースと比較していく。 最小インタフェースの背景にある考えは、クライアントが必要な機能をすべて提供できるようAPIを設計するが、仕事を成し遂げるための必要最小限のメソッドしか提供しないというものである（両者の違いについての例がヒューメイン・インタフェースにあるので参照のこと）。 ヒューメイン・インタフェースの主張はそちらのページに書いている。 ここでは、最小インタフェースの根拠について述べていこう。 インタフェースの習得には時間がかかる。 膨大なインタフェースを持つクラスはうまく使われることが少ないため、 最初の段階ではインタフェースは少なくしたほうがよいだろう。 インタフェースを小さく保ち、それらのメソ
Rubyでアジャイルプロトタイピング（1） ― ＠IT
想定する読者はこういう人々 本連載では、新たなアプローチでプロトタイピングを行い、アジャイルかつ正確にクライアントからの機能要件を取りまとめることを提案します。読者には、次のような方を想定しています。 上流工程に携わっているが、うまく進まず悩んでいる これから上流工程に挑戦しようとしている 下流工程でコスト、労力が増大してしまったが、その原因は上流工程にあったと感じている 上流工程の進め方について、新しいアプローチを模索している 本連載では、プロトタイピングに使用するツールとして、オブジェクト指向スクリプト言語であるRubyと、Ruby上に構築されたWebシステムフレームワークであるRuby On Rails（以下：RoR）についても説明し、実際に要件定義からプロトタイピングを作成してみるところまで行う予定です。 なお、Webシステムの開発を前提として解説を行いますが、クライアントサーバシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rogue Engineer's Diary / やさぐれ日記(2005-11-13) / 「アルゴリズム＋データ構造＝プログラム」？ 本当に？
日経ビジネス EXPRESS X : 【「ウェブ進化論」の梅田望夫氏に麻布の蕎麦屋で聞いた話：前編】「分かってほしい」熱気に驚いた
OKボタンの位置はどこが適切?
「現物主義」に基づいたソフトウェア開発手法
http://nicosia.is.s.u-tokyo.ac.jp/pub/essay/hagiya/7bits/genron