オブジェクト指向はしばしば，とっつきづらく難しい技術と言われます。その理由の一つには，対象とする分野が広く，それぞれに深みがあることが挙げられます。しかし，それ以上にこの技術を難しくしている落とし穴とも言うべき原因が二つあると筆者は考えています。それは比喩を乱用する説明の仕方の問題と，「もの中心」を意味するコンセプト自体の問題です。 そこで本特集では，「オブジェクト指向という言葉をよく聞くけど，実際どんなものかよくわからない」という方のために，初心者/入門者が陥りやすい落とし穴を明確にしながら，オブジェクト指向の全体像を説明します。余計な先入観やまぎらわしいたとえ話に惑わされなければ，オブジェクト指向そのものはそれほど難しい技術ではないことを理解していただきたいと思います。なお，オブジェクト指向プログラミング，デザインパターン，分析/設計といった個々の技術については特集2以降でそれぞれ解説

製造業の世界には「フロントローディング」とか「コンカレントエンジニアリング」と呼ばれる考え方がある。設計段階から、製造（実装、施工）等の後工程で問題になることをあらかじめ考慮しておくことを言う。言葉で言うのは簡単だが、組織的な連係やツールの活用などクリアしておくべき課題は多い。しかし実践できれば開発期間も開発コストも確実に圧縮できる。 システム開発でフロントローディングを実践するとしたらどんな形になるのだろう。「基本設計情報がバンドルされたオープンソースなアプリケーション」が、その決め手になると筆者は考えている。ソースコードだけでなく基本設計情報も添付されているアプリケーションを「オープンパッケージ」と呼びたい。つまり、オープンパッケージは「オープンデザインでオープンソースなアプリケーション」だ。 オープンパッケージを用いた開発は次のような手順で進む。 １．適合度の高いオープンパッケージの

このエントリは、「いきなりコンサルタントに抜擢されたSEが読むべき3冊」[参照]の続きになる。 「コンサルタント」と一緒に仕事をしたことがあるだろうか? 肩書だけのなんちゃって自称コンサルではなく、McKinsey & Company や accenture といった、それでメシ喰っている連中のことだ。 彼らの阿呆ほどの猛仕事ぶりは、「マッキンゼーITの本質」[参照] に書いたが、仕事の順序というか、ダンドリの要領よさについては常々不思議に思っていた。「俺たちに明日はない」という言葉がピッタリの猪突猛進なのだが、仕事のやり方は整然粛々としている。見た目のロジカルさだけでなく、コンサルティングの仕事そのものが、あたかも何かのマニュアルに従っているかのような感じがしてならなかった。 その予感はあたってた。マニュアルを見つけたんだ。それは、「情報システム計画の立て方・活かし方」。いや、その辺に転

テレビや新聞などのマスコミは，昨年11月以来，続発する東証のシステム・トラブルについて，その責任を追及する報道を続けている。そしてさまざまな人たちが，それぞれの立場で，東証の問題を指摘している。しかし，「どうすればよいのか」という根本的な解決策は出てこない。「あまりにも多くの問題が複雑に絡み合っており，即，解決するのは難しい。まずは時間が必要だ」というのが，金融分野やシステム分野における関係者・有識者の本音ではないだろうか。 金融とITを専門分野としてきた筆者は，多くのマスコミ関係者から東証の問題について，コメントを求められてきた。ただ，筆者は東証のシステムの詳細を知らないため，コメントするのは基本的に避けてきた。 ただ少なくとも言えるのは，一連の「東証システム問題」は，東証固有の問題から発生したわけではない，ということだ。 いまさら誰が悪いと責任追及するのは建設的ではない。まずは問題を洗

要求開発サミット2006に参加してきた 要求開発サミット2006に参加してきた．参加の直前に慌てて書籍「要求開発」を購入し，斜め読みで予備知識も詰め込んだ．これらを通じて大いに刺激を受け，色々なことを考えたり感じたりした．その一つをここに書いてみる． 私の問題意識 以前にid:kuranukiさんの記事を読んだ． ディフェンシブな開発 〜 SIビジネスの致命的欠陥 - kuranukiの日記（移転しました）→ http://kuranuki.sonicgarden.jp これには強烈なインパクトを受けた．前々から感じていた問題が明確に表現されていた． 私自身，手前味噌で恐縮だけど以前に次のような文章を書いてみたこともある． http://www.geocities.co.jp/u_1roh/columns/game.html SIerはどうしてもディフェンシブにならざるを得ないという構造的

我が国は通信業界・金融界の巨額投資が世界に類をみない交換機・汎用機3社を生き存えさせてきた訳だが，まず通信のIP化で交換機ビジネスが崩れて，次いで銀行大合併と2007年問題で汎用機ビジネスが崩れつつあるようにみえる． この銀行大合併と郵政民営化によるレガシーシステム更新の波を乗り切っても仕事がなくなるし，乗り切れずデスマーチ化したら諦めてインドの金融パッケージでも買うしかないのだろう．N社がIPサービス参入時にC社のルータを買ったように，見切りは思いのほか早いかも知れない． 横並びの業界のことだから，大手のなかで1グループでもレガシーシステムからパッケージとオフショア開発に舵を切ったら，流れは大きく変わりそうな気がする．海外のERPも日本の業務プロセスに合わないとかいわれ続けた割に，今では多くの老舗企業に入り始めているし． こんなに未来のない業界に，優秀な若手技術者が来ないだろうな．とゆー

優秀なエンジニアをかき集め，革新的なサービスを次々とリリースしてきたGoogle。「エンジニアのエンジニアによるエンジニアのための会社」（梅田望夫氏）といわれる同社の研究開発はどのように行われているのか。インターナショナル・プロダクトマネジャ アンジェラ・リー氏に話を聞いた（聞き手はITpro発行人，浅見直樹） ---Googleは自前主義と言われます。 リー氏: 本当に1からコードを開発している。メモリーの深い部分をどう効果的にコントロールするか，から始めて，ハッシュテーブルをどうするか，ユーザーインタフェースの部分まで，最後の1バイトまで自分たちで書いています。 買ってきたものだと限界にぶつかる なぜかといえば，他社のプラットフォーム上にコードを書いていると最終的にはどこかで壁に突きあたるんです。私の場合，国際化を担当していますが，日付の順番などが各国の言葉によって異なるところが，プラ

メモ。 志の高い人を雇いたがるのは、志の高い企業のするべきことなのだろうか。志の高い企業は、ふつうの志の人を雇い、高い志を持たせるような企業ではないだろうか。あるいは、ふつうの志の人を雇い、ふつうの志のまま、よい仕事をさせるような企業ではないだろうか。 優れた人を雇いたがるのはよいことなのだろうか。それは極論すれば、優れていないひとはどうでもいい、ということなのではないか？　そのような企業で働きたいと思うだろうか？　そのような企業で働きたいと思う人ばかりの社会で生きていたいと思えるだろうか？ ふつうの人が9時から6時まで（または10時から7時まで）、ふつうにプログラムを書いていればふつうに生活ができる、という世界の実現は困難なのだろうか。 今のソフトウェアエンジニアリングはふつうの人に辛すぎる。ここで言う「ふつうのひと」とは、たとえば「基本的に自分で本を買わない」「就業時間以外はプログラム

del.icio.us/tag/del.icio.usを眺めていたらFlickrのときみたいに面白い資料を見つけたの紹介します。 Things to look out for when building a large application.というタイトルでサーバーサイドの管理等の話が中心かと思って読んでいたらそれ以外のインターフェース、実装すべき機能、spam対策、アプリケーションを如何に広めるかといった話にも触れていて面白いです。 以下にまとめてみました。 スケーリング 早期の最適化を避ける。SQLでスケーリングするのではなく、データを複数マシンに分散させる方法を考慮すべき。SQLプロファイリング重要。Nagiosがお勧め。 タグはSQLと相性がよくない。インデックシングの仕組みを理解し、その方針を決定する。最初の数ページに限定すれば小規模で高速なインデックスを保てる。 Apache