タグ

techtargetに関するtokogleのブックマーク (9)

  • “アジャイル開発”適用への3つの課題――IPAが指摘

    独立行政法人情報処理推進機構(IPA)ソフトウェア・エンジニアリング・センターは、アジャイル型開発を中心とした“非ウォーターフォールモデル型開発”に適したシステムの分野や規模などについての調査「非ウォーターフォール型開発に関する調査」を行い、17のサンプル事例を含む報告書をWebサイトで3月30日に公開した。 IPAが刊行した「ソフトウェア開発データ白書2009」によると、開発プロジェクトの96%がウォーターフォール型開発を採用しているという。今回IPAは、アジャイル型開発の普及に向け、適用分野などの現状把握とその課題を整理して今後の対応へ結び付けることを目的とした「非ウォーターフォール型開発に関する調査」を実施した。この調査では、Webアプリケーションや企業の業務システムなど幅広いシステム開発の領域からサンプル事例を17例収集し、アジャイル型開発が「どのような特性のプロジェクトに向いてい

    “アジャイル開発”適用への3つの課題――IPAが指摘
    tokogle
    tokogle 2010/04/22
    IPAが刊行した「ソフトウェア開発データ白書2009」によると、開発プロジェクトの96%がウォーターフォール型開発を採用しているという。今回IPAは、アジャイル型開発の普及に向け、適用分野などの現状把握とその課題を整
  • 全員参加型のタスク管理を支援する「@task」

    プロジェクトは、各メンバーが割り当てられた「タスク」を実行することで、そのゴールに一歩一歩近づいていく。プロジェクトで実行される作業の最小構成単位であるタスクは、あるメンバーのタスクの前提条件が別のメンバーのタスクとなることもあり、その進ちょく状況の把握は個々人ではなくプロジェクトメンバー間で共有されるべきだ。しかし、タスクの粒度は明確に定義されているわけではないため、メンバー間でタスクを効率よく管理することに頭を悩ませる管理者もいることだろう。 今回は、プロジェクトにおけるタスク管理を支援する、日アットタスクの「@task」を紹介する。製品名に文字通り“タスク”と付いているこのツールの特徴とは一体何だろうか。 プロジェクト管理に必要なすべての業務情報を可視化 @task画面《クリックで拡大》 @taskは、現場メンバーが日々登録する情報を集約し、プロジェクト管理に必要なすべての業務情報

    全員参加型のタスク管理を支援する「@task」
    tokogle
    tokogle 2010/04/22
    @taskは、現場メンバーが日々登録する情報を集約し、プロジェクト管理に必要なすべての業務情報を一元管理・可視化することを支援する、SaaS(Software as a Service)型のプロジェクト管理ツールだ
  • “脱Excel”を実現する、PMBOK準拠システム「SI Object Browser PM」

    PMBOK適用は難しい!? プロジェクト管理に関する国際標準として広く認知されている「PMBOK(Project Management Body of Knowledge)」は、プロジェクト管理に関する基的かつ汎用的な考え方や手法を集めたノウハウ集である。プロジェクト管理の対象領域を9つの知識エリアに分け、プロジェクトの提案段階から評価に至るまでの一連のプロセスを実施する際のフレームワークとして利用される。 システムインテグレータの梅田氏 PMBOKをプロジェクトに適用することで、QCD(品質、コスト、納期)のバランスを取りながら、品質の高い成果物を生成することができる。すなわち「プロジェクトを成功へと導くことが可能」になるのだ。しかし、システムインテグレータの代表取締役社長、梅田弘之氏は「あくまでノウハウ集であるPMBOKを、実際のプロジェクトの現場に適用することは難しい」と指摘する。

    “脱Excel”を実現する、PMBOK準拠システム「SI Object Browser PM」
    tokogle
    tokogle 2010/04/22
    OBPMは、2008年11月にリリースされた統合プロジェクト管理システムだ。そのメニュー画面は、PMBOKが定義する9つの知識エリアと5つのプロセスに沿っており、各プロジェクトのスケジュール、コスト、リソースなどのデータを
  • 「脱・Excel」から脱するためのExcel活用

    ご存じの通りマイクロソフトの表計算ソフト「Office Excel」(以下、Excel)は、一般的な表計算ソフトとしての王道的な使い方からグラフ、データ分析まで幅広く応用でき、とても利便性が高いアプリケーションだ。実際に中堅・中小企業では、まだまだExcelが業務アプリケーションの主役であるところも多く、これまで蓄積してきた膨大なデータ資産がある。 大企業の中では、基幹システムの見直しを機にExcel依存のITを見直す「脱・Excel」の方向に向かっているところもあるようだ。だが、現在のような未曽有の経済危機の中で中堅・中小企業が生き残っていくためには、むしろ従来のリソースを最小のコストで最大活用し、企業競争力を高めていくことも必要だろう。 そこで稿では「業務をラクにするExcel活用術」をテーマに、使い慣れたExcelを駆使して業務効率を高める方法について、支援ツールの紹介を交えながら

    「脱・Excel」から脱するためのExcel活用
  • レガシーホストに塩漬けの「部品表」、その中身はどうなっている?

    前回「製造業のバイブル『部品表(BOM)』の復権」では、部品表とその発展形である統合化部品表の概略について述べた。まずは簡単に、その内容をおさらいしておこう。 メインフレーム上で動作するMRP(資材所要量計画)システムのインフラとして誕生した「第1世代」の部品表は、統合化部品表の登場で一気に第2世代から第5世代まで発達することになった。各世代の要点は以下の通りだ。 第1世代:MRP計算のための部品表 第2世代:統合化部品表の誕生と製番概念の導入(インターネットによる部品表と成果物の共有、時間軸による管理、仕向地・生産地の管理、ソフトウェアとハードウェアの管理) 第3世代:統合化部品表の進化(部品表とルーティングデータの統合、回路図・基盤図・半導体系部品表の管理) 第4世代:グローバル統合化部品表の誕生(リッチクライアント、Javaによる多言語化、マルチカレンシー、グローバル時系列) 第5世

    レガシーホストに塩漬けの「部品表」、その中身はどうなっている?
  • ニッポンの製造業が飛躍するためのIT戦略を探る

    前編「製造企業が“今”を乗り切るためのIT投資の在り方」では、ガートナー ジャパン ガートナーコンサルティング マネージング・ディレクターの中村祐二氏に、製造業全般において今後取るべきIT投資の大まかな指針について聞いた。後編の今回はもう少し深掘りすべく、製造業の企業タイプ別に取るべきIT戦略について中村氏に聞いた。 製造業は大きく3タイプに分類できる 一口に製造業といっても企業のタイプはさまざまであり、それぞれ取るべきIT戦略は異なってくる。中村氏は、製造業のタイプは大きく3つに分類できるという。 第1のタイプは「技術主導型」製造業だ。これは、高い技術力を有し、その能力で競争優位を維持している企業である。日でいえば、自動車メーカー大手がその代表的な例だ。 第2は「マーケティング主導型」製造業である。このタイプの企業は、技術力そのものに大きなブレークスルー要素や独自性は少ないものの、巧み

    ニッポンの製造業が飛躍するためのIT戦略を探る
  • 現場の抵抗勢力も納得する「ツール導入術」

    「ツール導入」は標準化推進の鬼門? 開発ツールはさまざまな機能と利便性を提供してくれるものだが、組織内における開発業務の標準化を推進する上では、その導入は鬼門だと思われることが多い。特に、使いづらいツールや実効性に乏しいツールをトップダウンで展開した経験を持つ組織では、「ツールの導入による効率化」などという文言を見ただけで、「結局は無駄な労力になるだろう」と拒否反応を示される場合もある。読者の中にも同様の認識を持っている方がいるのではないだろうか。しかし、ある課題に対してツールの導入による解決を図ることは、来有効な選択肢となるはずである。 今回は、社内の標準推進部署と現場が協力し、構成管理の問題に対してツールをうまく導入して解決を図ったZ社の事例を紹介する。プロジェクトマネジャーのみならず、自社内の標準化推進業務を担当している方にも、開発現場との連携に役立つ事例としてぜひ読んでいただきた

    現場の抵抗勢力も納得する「ツール導入術」
  • 社内標準化ではビジネス部門とIT部門の連携が重要

    わたしは非IT分野のキャリアを経てIT責任者になった。社内では周知の事実だが、実はCEOがわたしにIT部門を任せたのは、わたしがITについて不平ばかり言うのでうんざりしていたからだ。実際、彼はわたしにこう言った。「そんなに批判するなら、自分でIT部門を運営したまえ」。それからわたしはIT業務に明け暮れることになった。その中にはソフトウェアとアーキテクチャの標準化が含まれる。 ITを担当する前、ソフトウェアとアーキテクチャの標準は、わたしにとって最大の不満の1つだった。ITスタッフがこうした標準を盾に取ってわたしの構想を阻止しているように見えたからだ。わたしには構想を進めるための技術やアプリケーションのアイデアがあったのに、ITスタッフが「標準」や「アーキテクチャ」にかかわる理由を挙げてアイデアを却下するということが何度も繰り返された。 IT仕事に就いてからは、わたしはソフトウェアとアーキ

    社内標準化ではビジネス部門とIT部門の連携が重要
  • ベンダー依存のシステム開発から脱却する“7つのポイント”

    “ベンダーがいないと何もできない”現状 一般にシステム開発は「V字型のプロセス」によって実施されることが多い。このプロセスには「ユーザー主体の作業」と「開発ベンダー主体の作業」が存在する。上流工程では、ユーザーが主体となりシステム化構想が行われ、ユーザーがベンダーの支援を受けてシステム要件を定義する。その後、ベンダーがシステムを実装し、その成果物をユーザーが受け入れテストとして検証するという流れである。 V字型のシステム開発プロセス しかし、多くの企業では「ユーザー側が主体となるべき工程までベンダーに依存している」のが現状ではないだろうか。 稿で紹介するH社は、システム開発のほとんどを特定のベンダーに委託しており、システム開発の主導権をベンダーが完全に握っていた。このため、以下に挙げるようなさまざまな課題があった。 開発コストがベンダーによってコントロールされてしまう 長い付き合いによる

    ベンダー依存のシステム開発から脱却する“7つのポイント”
  • 1