第23回 システム開発の“丸投げ”が命取りに
現行システムの維持・保守業務に加えて，新たなシステム開発案件に追われている情報システム部は多い。むしろほとんどの情報システム部は，途切れることのない開発案件の消化に明け暮れている。忙しさに加えて，リストラや慢性的な要員不足が理由で，開発案件のほとんどを外部企業にアウトソーシングするケースも増えている。外注化は有効な選択肢の一つだが，“丸投げ”になってしまっては，情報システムのみならず，企業の存亡にかかわりかねない。 本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なる部分もありますが，この記事で焦点を当てたITマネジメントの本質は今でも変わりません。 空調機器製造販売会社のB社では，全国の支店網をこれまで以上に地域密着型にして，ビジネスの活性化と同時に独立採算を徹底することになった。この方針の実施に合わせて新しい業務処理に適した販売管
「完ぺきな」プロジェクト計画書に潜む失敗の落とし穴
プロジェクトを開始するとき、多くのプロジェクトマネジャーはプロジェクトを計画し、その成果物として「プロジェクト計画書」を作成する。しかし会社や対象部門、プロジェクトなどによって、計画の進め方、計画書の形式や内容はさまざまであり、実態に合わない計画を立てたことが原因でプロジェクトが失敗してしまうこともある。 プロジェクト計画書は「絵に描いたもち」？ Y社は官公庁など公共機関のシステム構築を得意とするシステム開発会社である。大規模プロジェクトを扱うことが多いため、プロジェクトマネジメントを重要視しており、社内でマネジメントプロセスの標準化がなされている。 2007年、Y社はある地方自治体の工事管理システムを受注し、同様のシステム開発経験を持つA氏をプロジェクトマネジャーに任命した。A氏は顧客が作成した提案依頼書などを基にプロジェクト計画書を作成し、社内と顧客の承認を得て無事プロジェクトをスター
「納期に間に合わない！」の根本原因を探る － ＠IT自分戦略研究所
ソフトウェアを創造するエンジニア。しかし、その仕事は本当に「創造的」だろうか。仕事を創造的なものに変え、価値を生むための発想法を紹介する。 前回、自分の中に宝物が眠っていることを知った。どうすれば自分の宝物を掘り当てることができるだろうか。宝物探しの出発点は、身の回りに散在している問題を考えることだ。身近な問題を解決することができれば、その効果を直接獲得できるばかりでなく、解決策形成の体験を通じて、将来発生するであろう問題を解決するための応用力も獲得できる。 自分にとって身近な問題、自分のプロジェクトや自社が抱えている問題、あるいは自分のお客さまが抱えている問題に取り組むことから始めるといい。そして、問題解決のアイデアや提案を生み出し、自分だけでなく、プロジェクトチームにも、会社にも、そしてお客さまにも喜んでもらおう。 ■解決すべき問題をはっきりつかむ 前回挙げた、「身近な問題の例」を再掲
「下請けはきつい！」も見える化、新発想のToDo管理 － ＠IT
2008/11/17 システム開発やチームマネジメントのコンサルティングを行うトラストコンベクションは11月14日、タスク管理ツール「echo」（エコー）を正式リリースした。WindowsとMac OS Xで利用できるAdobe AIRで実装した専用クライアントと、ユーザー登録したオンラインサービスを組み合わせて利用する。利用は無料。 システム開発など大きなプロジェクトは、小さく分割して“タスクセル”と呼ぶ単位で扱う。このタスクセルをサッカーチームがボールをパスしあうようにチームメンバーの間でやり取りするのがechoの特徴。タスクセルには「準備」「実行」「確認」の3つのステータスがある。タスクセル自体が色分けして表示されるほか、メンバー間で授受の際にコメントを付けて投げ返すことができ、タスクの依頼状況、遅延状況、依頼側・受注者の感情を視覚的に確認できるという。また、タスク終了時には相互評価
完了報告書の作り方
誰が誰に何のために報告するのか。これを意識することが報告書の内容を考えるうえで重要である。 完了報告書を作成する役割は，プロジェクト・マネージャが担うケースが一般的である。システム開発プロジェクトでは発注側であるユーザー企業と受託側であるベンダーの双方にプロジェクト・マネージャが存在するが，どちらのプロジェクト・マネージャが誰に対して報告するのかによって完了報告書を書く目的は少々異なってくる。その報告者と報告先は下記の三つのパターンに分けることができる（図1）。 A.ユーザー企業のプロジェクト・マネージャが経営者や上長に報告する B.ベンダーのプロジェクト・マネージャがユーザー企業に報告する C.ベンダーのプロジェクト・マネージャが自社の経営者や上長に報告する Aの場合の完了報告書の主な目的は，経営者や上長が決断したシステム投資に対して，担当者として説明責任を果たすということである。システ
管理者とは - Fight the Future
システム開発の仕事は、「自ら考える」ことが必要な仕事です。自発的に工夫したり、考えたりしながら作業を進めているSEにとって、単なる作業マシーンの役目を指示されることは、とても苦痛なのではないでしょうか。 キャリア・働き方を考えるブログ: 第3回 システム開発とは「感謝／助け合いの連続」ではないかという考察（2） PMが単なる「丸投げ」をしていたのであれば、彼らのモチベーションは上がることもありませんでした。試行錯誤するメンバーと一緒に考え、時には手助けをしたからこそ、メンバーは継続的に期待に応えようとしたのです。 キャリア・働き方を考えるブログ: 第3回 システム開発とは「感謝／助け合いの連続」ではないかという考察（2） これこそ管理者の仕事だと思う。 スケジュールとか線表とかWBSを作るだけが仕事だと思っているPM？が多すぎる。 線を引いたらそのとおりにシステムができるんなら管理者なんて
ソフトウェアのプロジェクト管理に「実験」の余地を
毎週何千ものプロジェクトが頓挫していくのはなぜだろう。わたしたちは自分のプロジェクトとその環境で何が起きているかがつかめないのに、まるで未来を予言できる超能力があるかのように振る舞っているのが現実だ。われわれは愚か過ぎて現実が理解できない。 ではどうしたらいいのか。ガントチャートが作成できないというのなら、何が残っているのか。 作りたければガントチャートを作ればいい。問題なのはチャートではない。現実がそのチャート通りに進むと考えてしまうあなただ。言っておくが、チャートはただのコミュニケーションの道具にすぎない。ただのアイデアであって、不可侵なものでも何でもない。 自分も人間だと認めていいのだ。タスクが最終的にどうなるのかはっきり分からないからといって恥じることはない。とにかく試すこと、実験すること、試行錯誤だ。とにかくやってみて、どうなるか見極めることだ。それで正しい方向に向かうことができ
Amazon.co.jp: リストマニア
PMなら読んでるはずの本 asesino ソフトウェア品質管理のためのプロジェクトマネジメント "H14頃の「ソフトウェア産業、CMM、オフショア事情」などが紹介してある。CMMをとりましょうという啓蒙本か。" ITプロフェッショナルのためのビジネススキル プロジェクトマネジメント入門 "理論や技法の理想論で教科書風。図は整理されている。文章は分かり易い。でも続けて読める面白さはない。" 楽しく成功するプロジェクト・マネージメント (SCC Books) "非プログラマ向けPM講座、技術用語少なめ。流し読みするだけでもシステム開発の概要が頭に入るつくりが良い。" Joel on Software "プログラマ向けで読み物として面白い。でも開発経験ないと無理、面白さが分からないかと。" 要求仕様の探検学—設計に先立つ品質の作り込み "要件定義に失敗しているプロジェクトに参加しないといけない。
今だから出来る業務システムを
先日、とある業務システムの事例が発表されていました。最先端を好むエンジニアに評判の良い最新技術を採用しての開発ということで大きく注目を集めたようです。その事例記事自体は普通の紹介記事なので、そこからあれこれと邪推するのもどうかと思うのですがいくつか気になるところがあり、それが日本の業務システムの問題の一部を体現している気がするので、ちょっと気になるところを書き連ねてみます。 その記事には画面のスクリーンショットが掲載されていました。見た瞬間に「未だに？」と感じてしまいました。どういうことかというと、画面の一番上がラジオボタンになっており、 ◎追加 ○更新 ○削除 と、まずは今から行う操作の種別を入力するようになっているのです。 これは「伝票入力する」という業務がそのまま残っているということになります。どういうことかというと、昔々というのはコンピュータが非常に高価な時代でした。そこでまずは入
5分で絶対に分かるプロジェクト管理
メディア 記事一覧 オルタナティブ・ブログ 用語辞典 ITmedia エンタープライズ 5分で絶対に分かるプロジェクト管理：5分で絶対に分かる（2/6 ページ） » 2008年09月17日 12時00分 公開 [今田忠博，＠IT] 前のページへ 1|2|3|4|5|6 次のページへ 前のページへ 1|2|3|4|5|6 次のページへ Copyright © ITmedia, Inc. All Rights Reserved. SpecialPR 検索 SpecialPR 注目のテーマ 人気記事ランキング ZabbixにCVSS 9.9の「緊急」の脆弱性が見つかる 速やかなアップデートが必要 Windows TCP/IPにCVSS 9.8の脆弱性 広範囲に影響を及ぼすため要注意 伊藤忠テクノソリューションズの委託先でランサムウェア被害 取引先情報が漏えい “年収1500万円”が夢じゃなくなる
「派生開発を成功させるプロセス改善の技術と極意」 - asa nisi masa
昨日読んだ本。いろいろ考えさせられる本だった。 「派生開発」を成功させるプロセス改善の技術と極意 作者: 清水吉男出版社/メーカー: 技術評論社発売日: 2007/10/27メディア: 単行本（ソフトカバー）購入: 10人 クリック: 127回この商品を含むブログ (28件) を見る 当書籍では、「派生開発」という用語を「新規開発」以外の開発すべてを指す用語として使用している。「派生開発」は、改修や機能追加のすべてを含む。 ※「派生開発」は、著者が作成した用語である。 よく知られている通り、ソフトウェアライフサイクルの殆どはこの「派生」に属し、費用も新規開発の何倍もかかる。従って、この部分をどれだけ効率よくできるかが、TCOの削減に大きく寄与する。また、当然のことながら、「派生」で障害が発生すると業務に支障が出、顧客に迷惑をかけることがあるため、重要度はとても高い。 にも関わらず、「派生」
「大規模プロジェクトではどうするか」を考えるより、「大規模にしないためにはどうするか」を考えよう - kなんとかの日記
はっきり言おう。大規模プロジェクトは存在自体が悪。 続けて同氏は、ケーパース・ジョーンズ氏の著書「Patterns of Software System Failure and Success」から調査結果を引用し、大規模プロジェクトになればばるほど、当初の見積もりとは大きくかい離したものになり、かつ失敗する可能性が高いことを示した。「（一般的なプロジェクトも含めた調査結果でさえこれなのだから）デスマーチについては推して知るべし」とヨードン氏。 エドワード・ヨードン、デスマーチを成功に導く対症療法を説く - ITmedia エンタープライズ (強調は筆者による) うむ。言っていることはごくあたりまえのことではあるが、ヨードン氏が言うと説得力がある。 調査結果の抜粋。FP（ファンクションポイント）はジョーンズ氏が定義している単位で、1FPが100行程度のコードであるという。1FPであればほぼ
「Excelでプロジェクト管理」が圧倒的多数、しかし満足度は低め
昨今、システムの開発はより複雑化、多様化しており、開発者には成果物の品質向上や短納期、低コストをはじめとするさまざまな課題がのしかかっている。その中でも、現場の人間が最も問題だと感じているのはどの部分なのだろうか。 また、プロジェクトを成功させるためには「品質・コスト・納期」という3要素のバランスを取ることが不可欠となる。その実現をサポートするものの1つとしてプロジェクト管理ツールが挙げられるが、現場で求められている機能とはどのようなものか。本当に使いたい機能、使える機能とは何か？ そこで今回、TechTargetジャパンでは、プロジェクト管理に関する課題やプロジェクト管理ツールの利用状況を調査するため、会員を対象に「プロジェクト管理ツールの利用状況に関するアンケート」を実施した。656件の有効回答から見えてきた現状を読み解いていく。 関連ホワイトペーパー Excel | 工事進行基準 |
［応用編］第3回 プロジェクト開始前の準備－－やるべき作業は多い 周到に計画を立てスムーズに立ち上げる
プロジェクト開始前の段階からスコープやコスト，スケジュール，組織体制を十分に検討することは，プロジェクトのスムーズな立ち上げに欠かせない。ベテランのプロマネが，提案・契約に至るまでの計画作業を現場の経験を基に解説する。 布川 薫／日本IBM ゲスト執筆者：神野 幸英／日本IBM プロジェクト・マネジャーに任命されたものの，すでに提案・契約が完了しており，プロジェクトのスコープ（範囲）や新システムの稼働スケジュール，コストなども決められてしまっていた…。読者の中にはこんな経験をした人はいないだろうか。 これは請負型のシステム開発プロジェクトのあるべき姿ではない。請負型のシステム開発では，プロジェクトの提案・契約を実施する「プロポーザル・マネジャー」と，実際にプロジェクトを遂行していくプロジェクト・マネジャーを，一貫して同じ人が担当するのが本来の姿だからだ。 プロジェクトの計画を別のプロポーザ
「失敗」への対策は「管理」じゃない - Fight the Future
「失敗」を繰り返さないための対策は「管理」を強化することじゃない。 たとえば、プロジェクトにおいてあるメンバーのスケジュールが遅れていたことが後でわかった。 よくある対策としてはメンバーの進捗を「より」きちんと管理するという発想。 これが「管理」を強化するという意味。 たとえば、職場のネットで不正なサイトを閲覧していた。 対策としてフィルタリングを強化する。 これも「管理」を強化するという意味。 たとえば、本番環境へのデプロイの手順を間違えて失敗した。 対策として、デプロイ作業の手順をチェックリストにし、作業を実施する際に利用する。 これも「管理」を強化するという意味。 ふと考えると、(世の中もだけど)プロジェクトはこうした対処がありふれていることに気づく。 これは、問題の「対策」じゃない。 問題をひっくりかえしたて「対処」しただけだ。 進捗を把握できていなかった→進捗を把握するようにする
第1回 20年は遅れているITプロマネ | 日経 xTECH（クロステック）
近年，システム開発のプロジェクトマネジメントについての関心が高まっており，プロジェクトマネジメントに関する資格を取る人も増えています。しかし，そのために「システム開発の失敗事例が減ってきた」という話はあまり聞きません。 システム開発プロジェクトは，建築やプラント建設，船や工作物などの機械組み立てのプロジェクトと比べて，失敗事例があまりにも多く，納期どおりに完成する例は多くありません。実際，日本情報システム・ユーザー協会（JUAS）の「ユーザ企業IT動向調査 2006」でも，500人月以上の大規模プロジェクトでは相変わらず5割近くで工期遅れ，4割近くで予算超過が発生しています。スケジュールが遅れ，その結果としてコストが増加することが当然と受け取られています(図1）。 図1●プロジェクトは基本的に成功するもの プロジェクトは，プロジェクト・マネジャーがしっかりと顧客とメンバーを把握して，品質（
第5回 開発コストにムダが多いIT業界，解決策は「分離発注」と「分割発注」
第4回では，システム開発プロジェクトで起こりがちなコスト膨張のからくりについて，主にベンダー側の視点から説明しました。 ではユーザー企業は，ベンダーに任せっきりにして，膨れ上がるコストを眺めているだけでよいのでしょうか？あるいは，「絶対に追加費用は一銭も認めないぞ」とベンダーと強硬に交渉して，予算内で吸収するように持っていけばよいのでしょうか？ 今回は，ユーザー企業がプロジェクトを円滑に進め，なおかつコストを最低限に持っていける方法について解説しましょう。 随意契約では，開発コストが高くなる 第1回にも述べたように，システム開発プロジェクトはほとんどの場合，プラント建設で言うところの“改造プロジェクト”に相当します。 “改造プロジェクト”では，ユーザー企業の内部事情を知っている特定のベンダー（既存システムの開発を担当したベンダー）が，仕様を確認するうえでは非常に有利になります。しかし，内部
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
さらに分かっておきたいトランジスタの種類 − ＠IT MONOist
「俯瞰図」で危機要因を抽出
オープンソースソフトウェアの育て方