ITmedia総合  >  キーワード一覧  > 

  • 関連の記事

「ユーザーサイド・プロジェクト推進ガイド」関連の最新 ニュース・レビュー・解説 記事 まとめ

「ユーザーサイド・プロジェクト推進ガイド」に関する情報が集まったページです。

ユーザーサイド・プロジェクト推進ガイド(19):
業務の可視化で、多くの関係者を巻き込め!
さまざまな分野で効果が語られている「可視化」は、企業システムの要求仕様の策定には必須ともいえるものだ。そして業務を可視化することは、要求定義以外に数々のメリットがある。(2007/6/8)

ユーザーサイド・プロジェクト推進ガイド(18):
工夫と規律で「システム用語辞書」を実現せよ
ユーザー企業がシステムのために用語辞書を整備するのは、大変な困難が伴う。それを乗り越えるには、相応の工夫が必要だ。(2007/3/9)

ユーザーサイド・プロジェクト推進ガイド(17):
社内用語を統一する「用語辞典」作成のポイント
社内で用語を統一するためには、用語辞典を整備するのがよい。用語辞典作成のポイントを解説していこう。(2007/1/16)

ユーザーサイド・プロジェクト推進ガイド(16):
言葉の不統一がもたらす業務とシステムへの悪影響
部門・部署ごとに使われている用語が違うことがよくある。言葉の不統一は、業務効率化やシステム開発に大きな障害となる。その改善アプローチとは?(2006/10/27)

ユーザーサイド・プロジェクト推進ガイド(15):
ドキュメントを作成しないユーザーは、失敗する
システム開発にドキュメントはつきものだ。しかし、しばしばドキュメントが作られないプロジェクトが見られる。ドキュメントがないとどのような事態が発生するのだろうか?(2006/9/16)

ユーザーサイド・プロジェクト推進ガイド(14):
プロジェクトメンバーがそろう前に行っておく事前準備
業務部門からプロジェクトに人を出してもらう際、その人が来るまで手をこまぬいている必要はない。先にできる準備は、システム担当部門だけで進めておくことが大切だ。(2006/8/31)

ユーザーサイド・プロジェクト推進ガイド(13):
システム開発プロジェクトの魅力を伝えよう
システム開発の経験に乏しいメンバーの“やる気”を引き出すには、システム開発という仕事の楽しさや魅力を分かってもらうことが一番だ。オリエンテーションでその魅力を伝えておこう。(2006/8/2)

ユーザーサイド・プロジェクト推進ガイド(12):
プロジェクトチームのマインドとルールを方向づけるには
システム開発の経験に乏しいメンバーからなるプロジェクトチームは、最初の“オリエンテーション”が大切だ。前回に引き続いて、オリエンテーションで話すべき内容について考察する。(2006/7/22)

ユーザーサイド・プロジェクト推進ガイド(11):
プロジェクトキックオフ! オリエンテーションで話すこと
システム開発の経験に乏しいメンバーからなるプロジェクトチームを始めるに当たって、まずは“オリエンテーション”が必要だ。強いプロジェクトチームを作るには、最初に何を伝えるべきだろうか?(2006/6/20)

ユーザーサイド・プロジェクト推進ガイド(10):
プロジェクトリーダーは十二分な準備で自信を生み出せ
プロジェクトリーダーには自信が必要だ。その自信を生み出すための「準備」の仕方をついて考えていく。(2006/5/30)

ユーザーサイド・プロジェクト推進ガイド(9):
プロジェクトチームのリーダーに向く人、向かない人
プロジェクトチームがチームとして機能するか否か、リーダーの果たす役割は大きい。リーダーとはどういう存在か、あらためて考えみよう。(2006/5/11)

ユーザーサイド・プロジェクト推進ガイド(8):
プロジェクトチームにおける“システム担当者”の役割
「システム開発プロジェクト」というとシステム担当部署が担当すると思われがちだが、大企業を除くとそうした望ましい体制を作ることは難しい。そんなとき、システム担当者の知恵を生かしてプロジェクトを推進する方法とは?(2006/4/8)

ユーザーサイド・プロジェクト推進ガイド(7):
プロジェクトチーム結成──業務部門との関係を考える
「危険なタイプ」にならないためにもプロジェクトチームはシステム担当者だけではなく、業務部門の人材を組み入れて作られるべきだ。しかし、そうした体制を構築するためには数々の障壁がある。(2006/3/24)

ユーザーサイド・プロジェクト推進ガイド(6):
プロジェクトチームに付きまとう制約を打破するために
システム開発に不慣れなユーザー企業のプロジェクトチームには、3つの危険なタイプがある。「丸投げタイプ」「メッセンジャータイプ」「独断専行タイプ」だ。こうしたプロジェクトチームにならない方法を考えていこう。(2006/3/4)

ユーザーサイド・プロジェクト推進ガイド(5):
タイプ別プロジェクトチームの問題点
プロジェクトの概要が決まってきたら、プロジェクトチームの編成となる。しかし、システム開発の経験がない企業では、名ばかりのプロジェクトチームになってしまいがちだ。(2006/2/14)

ユーザーサイド・プロジェクト推進ガイド(4):
不良システムを作らないプロジェクトの枠組み
業務システム構築プロジェクトでは、業務部門の理解と協力が不可欠だ。これらの人々にシステム開発の意義、そしてシステムというものの特性などを説明することを省略してはいけない。(2006/1/6)

ユーザーサイド・プロジェクト推進ガイド(3):
スケジュールとコストは、ユーザー側が始めからつかめ
システムの“直感的なイメージ”ができたら、ベンダに見積もりを取る前に、スケジュールとコストの概算を求める。これは「システムを発注するスキル」を身に付けるために欠かせない作業だ。(2005/12/14)

ユーザーサイド・プロジェクト推進ガイド(2):
最初が大切──構築システムの“概要”を作る
業務システム構築の初期段階におけるシステムの概要設計について考える。これから構築するシステムには“直感的なイメージ”があるだろうか? これは、その後の段階における指針となる重要な作業でもある。(2005/10/28)

ユーザーサイド・プロジェクト推進ガイド(1):
ユーザー企業側プロジェクトチームの使命と役割
企業システム開発は、スケジュール/コスト超過を含めて考えるとかなり失敗が多い。システム開発そのものが難しいのも事実だが、導入サイド(ユーザー企業)の誤解や能力不足に起因する失敗例が少なくない。ユーザー企業の現役システム担当者がユーザーサイドにおけるプロジェクトの進め方を解説する(2005/9/21)


サービス終了のお知らせ

この度「質問!ITmedia」は、誠に勝手ながら2020年9月30日(水)をもちまして、サービスを終了することといたしました。長きに渡るご愛顧に御礼申し上げます。これまでご利用いただいてまいりました皆様にはご不便をおかけいたしますが、ご理解のほどお願い申し上げます。≫「質問!ITmedia」サービス終了のお知らせ

にわかに地球規模のトピックとなった新型コロナウイルス。健康被害も心配だが、全国規模での臨時休校、マスクやトイレットペーパーの品薄など市民の日常生活への影響も大きくなっている。これに対し企業からの支援策の発表も相次いでいるが、特に今回は子供向けのコンテンツの無料提供の動きが顕著なようだ。一方産業面では、観光や小売、飲食業等が特に大きな影響を受けている。通常の企業運営においても面会や通勤の場がリスク視され、サーモグラフィやWeb会議ツールの活用、テレワークの実現などテクノロジーによるリスク回避策への注目が高まっている。