最新記事一覧
さまざまな分野で効果が語られている「可視化」は、企業システムの要求仕様の策定には必須ともいえるものだ。そして業務を可視化することは、要求定義以外に数々のメリットがある。
()
ユーザー企業がシステムのために用語辞書を整備するのは、大変な困難が伴う。それを乗り越えるには、相応の工夫が必要だ。
()
社内で用語を統一するためには、用語辞典を整備するのがよい。用語辞典作成のポイントを解説していこう。
()
部門・部署ごとに使われている用語が違うことがよくある。言葉の不統一は、業務効率化やシステム開発に大きな障害となる。その改善アプローチとは？
()
システム開発にドキュメントはつきものだ。しかし、しばしばドキュメントが作られないプロジェクトが見られる。ドキュメントがないとどのような事態が発生するのだろうか？
()
業務部門からプロジェクトに人を出してもらう際、その人が来るまで手をこまぬいている必要はない。先にできる準備は、システム担当部門だけで進めておくことが大切だ。
()
システム開発の経験に乏しいメンバーの“やる気”を引き出すには、システム開発という仕事の楽しさや魅力を分かってもらうことが一番だ。オリエンテーションでその魅力を伝えておこう。
()
システム開発の経験に乏しいメンバーからなるプロジェクトチームは、最初の“オリエンテーション”が大切だ。前回に引き続いて、オリエンテーションで話すべき内容について考察する。
()
システム開発の経験に乏しいメンバーからなるプロジェクトチームを始めるに当たって、まずは“オリエンテーション”が必要だ。強いプロジェクトチームを作るには、最初に何を伝えるべきだろうか？
()
プロジェクトリーダーには自信が必要だ。その自信を生み出すための「準備」の仕方をついて考えていく。
()
プロジェクトチームがチームとして機能するか否か、リーダーの果たす役割は大きい。リーダーとはどういう存在か、あらためて考えみよう。
()
「システム開発プロジェクト」というとシステム担当部署が担当すると思われがちだが、大企業を除くとそうした望ましい体制を作ることは難しい。そんなとき、システム担当者の知恵を生かしてプロジェクトを推進する方法とは？
()
「危険なタイプ」にならないためにもプロジェクトチームはシステム担当者だけではなく、業務部門の人材を組み入れて作られるべきだ。しかし、そうした体制を構築するためには数々の障壁がある。
()
システム開発に不慣れなユーザー企業のプロジェクトチームには、3つの危険なタイプがある。「丸投げタイプ」「メッセンジャータイプ」「独断専行タイプ」だ。こうしたプロジェクトチームにならない方法を考えていこう。
()
プロジェクトの概要が決まってきたら、プロジェクトチームの編成となる。しかし、システム開発の経験がない企業では、名ばかりのプロジェクトチームになってしまいがちだ。
()
業務システム構築プロジェクトでは、業務部門の理解と協力が不可欠だ。これらの人々にシステム開発の意義、そしてシステムというものの特性などを説明することを省略してはいけない。
()
システムの“直感的なイメージ”ができたら、ベンダに見積もりを取る前に、スケジュールとコストの概算を求める。これは「システムを発注するスキル」を身に付けるために欠かせない作業だ。
()
業務システム構築の初期段階におけるシステムの概要設計について考える。これから構築するシステムには“直感的なイメージ”があるだろうか？ これは、その後の段階における指針となる重要な作業でもある。
()
企業システム開発は、スケジュール／コスト超過を含めて考えるとかなり失敗が多い。システム開発そのものが難しいのも事実だが、導入サイド（ユーザー企業）の誤解や能力不足に起因する失敗例が少なくない。ユーザー企業の現役システム担当者がユーザーサイドにおけるプロジェクトの進め方を解説する
()