タグ

ブックマーク / xtech.nikkei.com (9)

  • IPAがITアーキテクトなど9職種の“理想の人生”を作成

    情報処理推進機構(IPA)は2010年3月をめどに、ITスキル標準(ITSS)で規定された11職種のうち、マーケティングとセールスを除く9職種のモデルキャリア(標準的なキャリア経歴)を文書化する。モデルキャリアの策定に当たっては、各職種とも10名程度の現役エンジニアにインタビューしてまとめる。モデルキャリアを提示することで、学生や若手エンジニアに広がる将来への不安感の払拭を狙う。 この事業は経済産業省の「IT人材育成強化加速事業」の一つで、公募によりIPAが受託した。IT人材育成強化加速事業にはITSSの9職種のモデルキャリアの文書化のほか、各職種の人材育成ノウハウ集の策定なども含まれる。2008年に経済産業省が策定したプロジェクトマネジャのモデルキャリアを文書化したもの(関連記事)が好評だったため、対象職種を拡大した。 モデルキャリアの策定に当たっては、各職種とも40代前後の現役エンジニ

    IPAがITアーキテクトなど9職種の“理想の人生”を作成
    yorunaka
    yorunaka 2009/08/23
  • 第4回 データの「見える化」ならDFDを使おう

    「ずいぶん前に使っていたと,先輩から聞いたことがある」「今はUMLがあるからそんな手法はいらないのでは」――。開発現場で最近,DOA(Data Oriented Approach)についてこんな声を耳にする。確かに,システムの部品化が進んでSOA(Service Oriented Architecture)に注目が集まり,UMLやBPMN(Business Process Modeling Notation)を用いたモデリング手法が広がりを見せている。 しかし,従来から変わっていないことがある。それはすべてのシステムは必ず「データ」を扱うことだ。システムが大きくなればなるほど,扱うデータも多くなる。ここで機能を中心に考えていると,データの漏れや不整合の発生を招き,システム全体を見渡すのが難しくなる。だから筆者は,データの流れの把握と分析に着目したDOAにこだわる。以下では,筆者が実践するD

    第4回 データの「見える化」ならDFDを使おう
    yorunaka
    yorunaka 2009/08/23
  • 先人の知恵を集めた「ソフトウエア・パターン」:ITpro

    ソフトウエア・パターン(Software Pattern)とは,ソフトウエア開発における「問題(Problem)」と「解決策(Solution)」を一つの組みとして示した文書(文章や図,絵,サンプル・コードなど)のことです。従来は分析・設計・実装といったエンジニアリング向けが中心でしたが,より上流の業務分析に関するパターンが登場したほか,マネジメント(管理)とテストのパターンもあります。 こうしたソフトウエア・パターンを分かりやすく丁寧に解説します。 <目次> 第1回 適用範囲が拡大する「ソフトウエア・パターン」 第2回 アクティビティ配置のひな型「ワークフロー・パターン」 第3回 成果物や組織の管理方法「マネジメント・パターン」 第4回 単体テストの問題解決「テスト駆動型開発」 「絵で見るテクノロジ」過去の連載----------------------------------- ●ユー

    先人の知恵を集めた「ソフトウエア・パターン」:ITpro
    yorunaka
    yorunaka 2009/08/23
  • 顧客の幸せを“倍速”で作る

    「日で一番、お客様を幸せにするシステムを作る会社」。 こんな経営ビジョンを掲げて、事業展開するシステム開発会社がある。社員数わずか約20人の倍速開発(東京都豊島区)だ。技術担当の吉沢和雄代表取締役と営業担当の牧貴子代表取締役は今のITサービス業界には、「『お客様が頼んで良かった』『当社は作って良かった』と両者が“幸せ”に思えるシステムを開発することが必要だ」と口をそろえる。 背景には「SEはユーザーに言われたことに責任を持って淡々とこなす。だが、他のSEが担当した部分には責任外と知らん顔。その結果、途中で仕様変更があれば、ユーザーとつまらないことで争いになる」(吉沢氏)ことがある。それを解消するため、他社の“倍”のスピードで開発することにした。残りの半分の時間で顧客のわがままを聞き、かゆいところに手が届くようなシステムに仕上げられるからだ。 牧氏は「お客様が『便利になった』『うれしかった

    顧客の幸せを“倍速”で作る
    yorunaka
    yorunaka 2009/08/23
  • 顧客満足度が最重要指標 信頼されれば営業効率も高まる:ITpro

    2008年5月にシグマクシスを設立し、代表取締役CEO(最高経営責任者)に就いた。日IBMで副社長、プライスウォーターハウスクーパースコンサルタント(PwCコンサルティング)、日テレコムなどでトップを務めたIT業界屈指の論客の転身は話題を呼んだ。その倉重氏が売り上げや利益よりも経営者として重要視するのが、顧客満足度である。 倉重さんにとって、顧客満足度はどのくらい重要なものですか。 当社で経営に当たって重視する指標は四つあります。売り上げ、利益、品質、顧客満足度です。優先順位はこの逆です。つまり、顧客満足度が一番高くなります。 こう考えられるようになったきっかけは? 昔から重要だとは考えていました。公言するようになったのは、PwCコンサルティングに転職してからですね。PwCコンサルティングの事業はすべて人間が提供するものです。顧客満足度が低いと、いつか発注されなくなります。 顧客の満足

    顧客満足度が最重要指標 信頼されれば営業効率も高まる:ITpro
  • [ITpro EXPO]「世界のエンジニアを使いこなす存在となれ」 --- 大前研一ビジネス・ブレークスルー代表取締役社長

    2008年10月15日,東京ビッグサイトで開幕した「ITpro EXPO 2008 Autumn」。開幕式に続く基調講演に登壇した大前研一ビジネス・ブレークスルー代表取締役社長は,世界経済の動きに大きな影響を与えつつあるICT(情報通信技術)の存在感,そしてその担い手であるICTのプロフェッショナルが進むべき方向性について語った。 ICTが世界経済に与える影響の大きさがよく分かる例として,大前社長は米大統領予備選におけるオバマ候補の勝利,そしてサブプライム・ローン問題に端を発する金融危機を挙げた。オバマ候補の勝利の背景には,情報発信の手段として,クリントン候補,マケイン候補よりも積極的にインターネットを活用したことがあるという。 サブプライム・ローン問題では,不安に駆られた預金者が資金を電子的手段で引き上げることにより,金融危機が瞬時に広がった。大前社長は「まさに21世紀型。サイバー社会の

    [ITpro EXPO]「世界のエンジニアを使いこなす存在となれ」 --- 大前研一ビジネス・ブレークスルー代表取締役社長
  • ITpro プロフェショナルの現場

    最強現場の作り方 あなたが働くシステム開発・運用の現場は,プロと呼べない独り善がりな現場になっていないだろうか。プロと呼ばれるITエンジニアの条件は「ユーザーに尽くし,ユーザーに信頼される」ことである。様々な切り口で,プロの現場になるための道を探る。 関連サイト: 7つの行動パターン プロとプロでない人のわずかな差 行動パターン1●情報システムや会社の歴史を調べる 行動パターン2●マニュアル類を手元に置く 行動パターン3●新聞,雑誌,Webサイトを読む 行動パターン4●緊急時の連絡網を整備する 行動パターン5●早く出社して段取りを確認する 行動パターン6●手順や作業内容を記録する 行動パターン7●明るく元気に挨拶をする あなたにもできる技術伝承 技術の断絶が起きている。社内にある技術,それを伝承できない現場に明日はない。だが,何を残せばよいのか。どう伝えればよいのか。「型」「反復」「体験」

    ITpro プロフェショナルの現場
  • だれも教えてくれなかった外部設計の「極意」---目次

    外部設計書で最も大切なことは,「システム開発を依頼してきたお客様」(発注者)に読んでもらい,理解してもらうことです。外部設計書を,開発メンバーではなく,発注者に理解してもらうためには,「いかに発注者にとって分かりやすい外部設計書を作成できるか」と「レビューを通じていかに合意形成を図るか」が重要になります。連載では,発注者が理解しやすい外部設計書の書き方とレビューの方法に関する具体的なノウハウを解説していきます。 第1回 ユーザーと意思疎通が図れない外部設計書は危ない 第2回 [システム振舞い編]一覧表に一工夫入れることで漏れや重複をなくす 第3回 [システム振舞い編]全体を俯瞰でき,システム化範囲が一目で分かる業務フローを作成する 第4回 [システム振舞い編]発注者が理解しやすいシナリオの記述方法 第5回 [画面編]見れば“わかる”「画面レイアウト」の作り方 第6回 [画面編]画面遷移を

    だれも教えてくれなかった外部設計の「極意」---目次
  • 現行システムの見える化---目次

    「度重なる改修やドキュメントの不備などで現行システムがブラックボックス化し,調査工数の増加や予期せぬ障害を招いている。この特集では,現行システムの見える化の実態とそのテクニックを解説する。 第1回 6割はいらないコードだった 第2回 設計書がない!担当者がいない! 第3回 コードの調査だけで数カ月! 第4回 データの「見える化」ならDFDを使おう 第5回 システムと業務をUMLでマッピングしよう 第6回 「見えない」システムが増殖する 第7回 こんな見える化は失敗する 第8回 業務とシステムを関連付けたい! 第9回 効率よくヒアリングしたい! 第10回 ソースコードのロジックを見える化したい! 第11回 インフラを見える化したい! 第12回 稼働中のシステムを見える化したい! 第13回 障害原因を見える化したい! 第14回 変化に強いシステムかどうかを見極めよう

    現行システムの見える化---目次
  • 1