日経コンピュータ副編集長，日経ビジネス編集委員， ビズテックプロジェクト担当，経営とIT新潮流2006編集 ITproの中で「ユーザー」と書けば，ITを利用する企業あるいはそこに勤務する社員を意味する。ITを生業にしている企業やそこに所属する社員をユーザーとは呼ばない。ただし，広く普及している製品を使う利用者については，所属企業を問わず，全員をユーザーと呼ぶこともある。いずれにしても，以上の言い方が許されるのはITproや日経コンピュータなど専門サイトや専門誌においてであって，一般のサイトや雑誌では通用しない。 ユーザーに対する言葉として「ベンダー」があり，ITベンダーとも書く。ITを生業にしている企業群，すなわちコンピュータ・メーカーやソフトウエア・メーカー，ソフト開発会社，コンピュータ販売会社の総称である。かつてはソフトハウス，システムハウスという言葉があったが，いつの間にか使われなく

本連載は「プロジェクトと人」を「人」に視点を当て、そこからある程度の普遍性を持ったプロジェクト運営のプロセスを探り出すことを目的としています。第1回（「スキルシートでいったい何が分かるのか」）はEさんを例に、プロジェクト内でうまく活躍できずに去らざるを得なかった経緯を見ながら、「チーム構成プロセス」や「開発プロセス」の「難しさ／問題点」を洗い出しました。今回は、皆さんから寄せていただいた第1回記事に対するWeb投票結果の考察から話を展開していきます。 集計結果から導き出される次なる課題 以下がWeb投票の結果です。「第1回において、Eさんがチームを去らねばならなかった最大の問題点は何だと思いますか」というのが質問です。選択肢は5つ設定しました。 プロジェクト入隊試験などフィルタリングを行わないチーム構築プロセスの未整備。あるいはメンバー選びなどを支援するノウハウのない所属する組織 メンバー

印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 9月5日に会津大学と福島県のIT企業エフコムとの連携で.NET技術者の育成において連携することを発表したマイクロソフト。同社が2005年に打ち出した日本における3カ年計画「Plan-J」の中には、教育機関や産業界との連携強化も掲げられており、今回の取り組みもその一環といえる。7月には札幌市との連携も発表しており、「優秀な技術者を育てることで雇用の各題と地域活性化に貢献したい」と、マイクロソフト執行役 デベロッパー＆プラットフォーム統括本部長の鈴木協一郎氏は話す。 今回福島県との連携でマイクロソフトは、会津大学にて10月より実施される.NET公開講座を支援するが、同社は日本の学生に合うようなテキストやカリキュラムを「導入キット」として用意

あるメガバンクのシステム部門に所属している友人から聞いた話である。 この友人は大学卒業後，このメガバンクの前身である大手都銀に入行。約2年の営業担当を経てシステム部門に配属され，SEとして様々なシステム案件を手がけてきた。 筆者は以前，この友人と会うたびに，彼が所属するシステム部門の保守的な文化や，部下の提案に聞く耳を持たない上司の愚痴などをよく聞かされていたのだが，その友人がある時，「もう我慢できない」と漏らしたことがあった。それは今から数年前，彼が勤務する大手都銀が別の大手都銀と経営統合することになり，両行のシステム部門がそれぞれシステム統合に向けた準備に着手した頃だった。 ご存知の読者も多いと思うが，企業間の合併・買収などに伴うシステム統合では，それぞれの企業が保有している既存システムを，業務（あるいは機能）単位で比較検討し，一方のシステムを存続させて他方のシステムを統合するか，それ

うーん、半ば炎上中ですね、中井さん。 この食い違いは他のコメントにあるとおりデキの悪い営業の意見を、もしくはその意見の表面だけを 一方的に受けて書いちゃったとこだな、うん。 どこがデキが悪いとか、なにが一方的かというと・・・ ここで提案だが、この記事を「営業担当者がＳＥに抱く不満」ではなくて 「キャバクラの店長がキャバ嬢に抱く不満」だと読み替えて欲しい。 その1「お客様の前で『それはできません』と即答しないで欲しい」 そのまんま・・・ですな。爆笑。 その2「お客様を満足させる顧客指向を持って欲しい」 「店長、アタシいやです」 「頼むよ、顧客指向で」 その3「指示・依頼を待つだけでなく、自分で考え積極的に提案してほしい」 「あっちのテーブルあいてるじゃないか、自分で動いてくれよ」 「それ店長の仕事でしょ？」 うーん、あまりに当てはまるのでこれからこういうこと言う営業マンを 「キャバテン営業」

最近のシステム構築では仕様書をきちんと記述しないで、いきなりツールを使ってプログラムを作成することも多いようだ。否定する気はないが、駆け出しのころはしっかり自分の手で仕様書を書いた方がいい。 前回は、SEを目指している皆さんに向けて、仕事に取り組む姿勢の観点からアドバイスを書いた。今回は、SEに求められるより具体的な知識やスキルの向上に役立つ話を書いてみたい。 SEとして必要な知識やスキルは非常に広範にわたる。経験を積み、上級SEになってくればより経営的な知識が求められるが、最初のころは、システム構築に必要な知識やスキルが特に重要になる。今回は、システム構築における基礎的なスキルの開発方法を紹介しよう。 仕様書を書くこと 最近のシステム構築では、仕様書をきちんと記述しないで、いきなりツールを使ってプログラムを作成したり、システムを構築したりする手法が取られることも多いようだ。こういった手法

「もっと顧客から課題を聞き出す力があればなあ」「専門知識を生かして積極的に提案してもらえると助かるのだが」---。 営業担当者がITに関する商談で客先を訪問した際に、同行したSEに対してこんな不満や要望を抱いている。顧客に対して「何をすればいいのでしょうか」と“御用聞き”に徹して提案しようとしないSEや、顧客と積極的にコミュニケーションを図ろうとしないSEに対して、営業担当者はもどかしい思いをしているのだ。 日経ソリューションビジネスは，5月15日号の特集「SEの提案力強化で差をつけろ！トップ営業も認めるソリューションの達人育成法」に関連して企画・実施した調査で、ソリューションプロバイダの営業担当者208人から、“普段はなかなか話せないSEに対する本音”を聞いた。 その結果、「SEに足りないと思うスキル」の上位3項目は、「顧客の課題などを聞きだす力」、「その場に応じた会話ができる力」、そし

「所有してこそわかる感覚がある」。取材中，ある大手製造業のCIOはこんな言葉をふいに紡いだ。このCIOは大手ITベンダーのSEとしてキャリアをスタートした後，外資系ベンダーのマネジャを数社経験。そして数年前にユーザー企業のCIOとして就任した。 そのコメントの真意を聞いてみた。「ユーザー企業側に立って初めて，システムに対する愛着のようなものが湧いてきた。これまでベンダー側で接してきた顧客に対して失礼かもしれないが，ベンダーにいたときは，そんな感情はなかった」。CIOはこのように説明する。 情報システムの漠とした巨大さとはほど遠い「愛着」という言葉が出たことに，私は違和感を禁じ得なかった。いくら何でもクルマやカメラと情報システムは違う。しかし，そんな私の感想をよそにCIOは続ける。「運用体制をどうするか考えたり，システムの中長期的な計画を練ったり，といったシステムのライフサイクル全般について

今は昔、ひとりの駆け出しプログラマがいた。 その頃はCOBOLばかりで、しかも保守ばかりだった。そこで、独学で身に付けたCをやらせてもらえる仕事を奪ってきては書いた。スクラッチプロジェクトを見つける嗅覚だけは抜群だった。たいていは人手が足りず、新人でも歓迎されたからだ。 そこには優れた先達がいた。「スーパープログラマ」と呼ばれていた。 なぜ「スーパー」なんて修飾子がついたかというと、速いプログラムを早く書いたから。もちろん、「速い」とは少ないメモリ・小さいプログラムのことを指し、「早く」とは実装が早いこと。実際、彼らが書いたプログラムはサクサク動き、バグは簡単に見つけられた。 教えを請うと、先達たちは、おしなべてこういった。 最初に学ぶべきは、コンピュータサイエンス。特にアルゴリズムとデータ構造だ。実践的なコーディングテクニックよりも、まず基礎だ。これはコードを書きながらではなく、文献から

マイクロソフト執行役　デベロッパー＆プラットフォーム統括本部長の鈴木 協一郎氏がインタビューに応じた。鈴木氏はマイクロソフトの開発者向け製品，サービス部門の責任者。今年はWindows VistaやOffice 12の発売が予定されているが，日本の開発者に対してマイクロソフトのプラットフォームについて語ってもらった。発言の要旨は以下の通り。 ---このたび日本でも披露されたWindows VistaやOffice 12は，開発者あるいはユーザーに対して今までと違うどのような変化を与えますか。 マイクロソフトは.NETの構想を2000年に出しました。それ以降，ライブラリとしての.NET Framework，そして開発ツールとしてのVisual Studioを充実させて，「つなぐシステム」というものを広めてきました。その後.NETも開発プラットフォームの主流の一つとして広まるまでになり，開発人

仕事に対して前向きに取り組む姿勢を生み出し，個人の成長を加速させる「やる気」。この大切な“仕事への原動力”が，ITエンジニアにおいてどうなっているのか---。日経ITプロフェッショナルは2006年1月号の特集「ITエンジニアのやる気マネジメント術」と連動して，2005年11月に日経BPコンサルティングと共同で「ITエンジニアのやる気実態調査」を実施した。 ITエンジニアを対象にした任意参加のWebアンケートであり，前回のこのコラムでご協力をお願いした。その結果，有効回答だけで1613人もの方にご回答いただいた。この場を借りて，深く御礼を申し上げる。今回はその調査結果を抜粋して報告する。 半数近くが「自分のやる気が下がっている」 調査結果から浮かび上がった最も重要な傾向は，「ITエンジニアのやる気に危険信号がともっている」ということだ。最初に，このことを裏付ける2つの調査結果を紹介する。 ま

どうすればITエンジニアは職業人として幸せに生きていけるのか。私は記者活動のテーマとして，これを掲げている。 プロとしての能力を身につけるためには。よりよい評価や処遇の体系は。現場の労働環境はどうなっているのか，どうすれば改善するのか---。これまで私はベンダーの人材育成や処遇制度，あるいはITエンジニアのメンタルケアやプロマネの労働実態といった労働問題を取材し，記事を書いてきた。 私が言うまでもなく，このテーマは非常に奥が深い。当然，私のような冴えない若造には一筋縄ではいかない。だがそれでも「自分はどう働けば幸せになれるのか」と自分自身の問題としてもとらえつつ考えてきた。愚直に考え続ける理由は，「幸せに働いている人がいないIT業界など先はない」と思うからである。 職業人としての幸せは，自分の好きな仕事で他者に価値を提供し，その対価をもらって満足することだろう。では，自分は誰にどんな価値を