skillに関するmorningriverのブックマーク (47)

  • 情報システム部門、成功と失敗の法則

    今日、企業の情報システム部門は、非常に困難な状況に置かれているように思われる。情報システム部門の多くは、広がり続け、波高まる一方のIT適用領域の海に向かって、十分な装備も、満足な航海技術も持たず、木の葉のように漂う状況に見える。まずは、最近の情報システム部門がはらむ問題を考えてみる 情報システム部門のミッション 情報システム部門の問題を考えてみる前に、企業における情報化の目的──すなわち情報システム部門のミッションについて考えてみよう。情報システム部門のミッションは、情報の流れ(発生~蓄積~提供)を通じて、自社の業務パフォーマンスの向上につながる“仕組み化”を行うことである。この「パフォーマンスの向上」という点がミソとなる。 行き交うものが情報ではなくマテリアルであれば、他部門(生産設備部門や物流部門)のミッションに重なるが、これらの部門は環境が変化する中での“相対的なパフォーマンス”向上

    情報システム部門、成功と失敗の法則
  • Rubyでアジャイルプロトタイピング(1) ― @IT

    想定する読者はこういう人々 連載では、新たなアプローチでプロトタイピングを行い、アジャイルかつ正確にクライアントからの機能要件を取りまとめることを提案します。読者には、次のような方を想定しています。 上流工程に携わっているが、うまく進まず悩んでいる これから上流工程に挑戦しようとしている 下流工程でコスト、労力が増大してしまったが、その原因は上流工程にあったと感じている 上流工程の進め方について、新しいアプローチを模索している 連載では、プロトタイピングに使用するツールとして、オブジェクト指向スクリプト言語であるRubyと、Ruby上に構築されたWebシステムフレームワークであるRuby On Rails(以下:RoR)についても説明し、実際に要件定義からプロトタイピングを作成してみるところまで行う予定です。 なお、Webシステムの開発を前提として解説を行いますが、クライアントサーバシ

    Rubyでアジャイルプロトタイピング(1) ― @IT
  • プロマネの楽しさとつらさはどこにある? - @IT自分戦略研究所

    プロジェクトマネジメントの方法は、各企業によって特徴があろう。さまざまな制限を課せられたプロジェクトマネージャは、どのようにしてプロジェクトをマネジメントしているのだろうか。連載では、現役のプロジェクトマネージャに登場していただき、実際にどうプロジェクトを進めているのか。またプロジェクトに対する考え方などを伺っていきたい。 プロジェクト・マネジメントの現場には、それぞれの企業が抱えるビジネス課題があります。その課題に立ち向かってきたプロジェクト・マネージャは、どのような考えを持ち、どのような経験をしてきたのでしょうか。 もし皆さんの中でプロジェクトマネージャ(プロマネ)を目指したい人、プロマネを数年経験したが、スケールアップを図りたい人、または企業の中でのプロマネの在り方を考えたい人であれば、現場で戦っているプロマネの言葉から、何かヒントがつかめるかもしれません。 今回話を伺ったのは、い

  • @IT:Webアプリケーションのユーザーインターフェイス[1]-1

    Webアプリケーションのユーザーインターフェイス[1] ユーザーにとっては “ユーザーインターフェイス”こそが製品そのもの ソシオメディア 上野 学 2005/6/2 ■はじめに Webクライアントの技術が進歩し、多様化するに従って、Webベースのシステムにはデスクトップアプリケーションと同等の品質を持つユーザーインターフェイスが必要となってきています。 しかし開発の現場では、ユーザーインターフェイス(特にGUI)デザインについての専門的なスキルを持った技術者が圧倒的に不足しています。その理由は、ソフトウェア製品におけるユーザーインターフェイスの重要性が正当に理解されていないためと、ユーザーインターフェイス・デザインに関する教育機会がほとんどないためです。 利用者の視点に立てば、ユーザーインターフェイスとは製品そのものです。いくら高度に洗練された仕組みがバックエンドにあったとしても、それが

  • 28歳から挑戦するITアーキテクト(1)

    日々追われる作業、上司からの圧力、顧客との苦い折衝、理解できない既存システム、遅延するプロジェクト、追いつくのが精いっぱいの次々と登場する新技術、複雑な外注関係、理不尽な納期、完成直前まで変更が続く仕様、永遠に続くかのようなバグの発生と切り分け、長期にわたる徹夜作業、擦り切れた人間関係、明日の見えないキャリアパス……。筆者の20代のころの経験は、主にこうした「混沌とした」ものから構成されていたといっても過言ではない。こうした経験は、まじめに仕事をすればするほど、どんどん狭く深みにはまっていくものだ。そうした悩み深きプログラマの1つの解として近年脚光を浴びている「ITアーキテクト」という役割。この連載では、いまも現場でもがき続ける現役ITアーキテクトの1人として、悩ましい20代への「次のステップ」の手引となるものを残していきたいと考えている。 ITアーキテクトとは 「ITアーキテクト」とは、

    28歳から挑戦するITアーキテクト(1)
  • 「問題発見能力を高める」インデックス

    問題を抱えている社内の顧客(業務部門)に対し、具体的な解決策=ソリューションを提示する「情報エキスパート」が持つべき視点や考え方について解説する。

  • IT技術者が「上流」に出て行く理由

    もしあなたが、IT技術質をつかみ、高度なアーキテクチャの設計ができ、その内容を関係者に説明し納得させられる力を持っているのなら、すでにコンサルティングに必要なスキルの大半は身に付いている。後は実践あるのみだ。経営者だって人の子。怖い人ばかりじゃない。勇気を持って踏み出してみよう(文より)。 1. 顧客満足につながるシステム構築のために 1.1 そのシステムで当にお客さまは満足しますか? あなたがプログラマなら、「いま、コーディングしているこのシステムは当にユーザーが望んでいるのだろうか?」「作ったものは当に役に立つのだろうか?」――、こんな疑問を感じた経験はないだろうか? 自分が開発したものが使われ、喜んでもらえることは、技術者であれば誰でも願うことであろう。多くの場合、こうした疑問は、見習いの段階を終えて、技術者として自信が出てくるころからわいてくるようになるが、先輩や上司

    IT技術者が「上流」に出て行く理由