先日、日経BPの出版局の方と話をする機会があったのだが、私がマイクロソフトでウィンドウズ９５の開発に関わったことに触れた際、「ユーザーインターフェイスの設計において、日本人であることで何か役に立ったことはありますか？」と聞かれた。日本人であることがプラスになったとは思わないが、ふと思い出したことがある。当時、「日本語はオブジェクト指向な言語だな」と思ったことである。 その当時（９０年代初頭）、アップルの方が使い勝手に関しては一歩も二歩もマイクロソフトより進んでおり、そのためには、もともとゼロックスが提案しアップルが商品化した、「オブジェクト指向ユーザーインターフェイス」の考え方を、より推し進めるしかないという戦略で、ウィンドウズ９５のユーザーインターフェイス（当時は Object-Oriented Shell と呼ばれていた）の開発をしていた。 「オブジェクト指向ユーザーインターフェイス」

仕様変更、追加開発が爆発的に増加し、予算オーバーでプロジェクトが中止──とはよく聞く話だ。今回は、そうした失敗をしないための上手な予算の配分について考えていこう さて、要件定義も固まり、仕様書もできたら、いよいよシステム開発である。これを社内でやるか、外注するかは別にして、できた仕様書は決して完ぺきではないということを忘れてはならない。いざ、システムができてきて、実際にリハーサルなどを繰り返すうちに、当初に残した2割の要求のほかにもあれこれ仕様が漏れていることが発覚するものだ。ときには、致命的な漏れを発見することもある。 そのときに「予算がありません」では、必然的に予算オーバーとなる。期間についても同様、ギリギリのスケジュールを敷いていると、途端に期間延長、予定遅れとなってしまう。そんなことにならないように、予算・期間に余裕を持たせておくことが必要である。また、運用段階での保守費用もあらか

IT業界でも“人の育成”が問題になっている。しかし、一部で話題の能力向上自己責任論は現実的ではない。独力で力を付けられる人間はごくわずかだ。部下の育成は「上司・管理者の大切な業務の1つ」だと考えるべきである。今回は、上司と部下の関係や部下の育成方法などを考える。 はじめに IT関係の多くの組織において、人の育成が問題になっている。 書店には、「SEのための……」や「プロジェクトマネージャの……」といったハウツー本が並ぶ。問題を細分化したり、言葉を新しくして再定義したぐらいで解決できる問題ではないのだが、人間力、EQ、コーチング、……などなど、人の能力にかかわる新しい造語がちまたをにぎわしている。 一方で、一部にある能力向上自己責任論は現実的ではない。独力で力を付けていける人は、世の中には一握りしかいないからだ。普通の人は、周りの人の手の掛け方次第で育ち方にかなり差が出る。人材育成の手間を省