プロジェクトを計画しすぎてダメにする方法 | タイム・コンサルタントの日誌から
「日本企業は、計画しすぎなんです。」——最近、ある外資系戦略コンサルタントから、こんなセリフを聞いた。いわゆるDXに関する話題の時だ。「計画して、それも細かく緻密な計画を立てて、石橋をたたくようにリスクを全て洗い出してから、はじめようとします。そして動き出したら、すぐ進捗率を問題にする。でも、そんなやり方では、イノベーションは動きません。」 たしかにまあ、日本企業、とくに製造業は、まず計画ありきで動いていると言ってもいい。年度計画（いわゆる「予算」）、月度計画、小日程計画・・。建設業も、似たところがある。全体工程表、月間工程表、週間工程表、等々。現場に行くと、計画表は、必ず目立つ位置にはり出してある。 だが、新しいビジネスモデルを創出するような、イノベーティブな試みは、目指すべき目的地が最初から決まっている訳ではない。登るべき山の頂が明確なら、アプローチの経路を地図の上に引き、どこまで登っ
「技術的負債だらけのチームで技術マネージメントしてみた」資料が素晴らしい - プログラマの思索
「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。＞技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、本当によくある。 (引用開始) １年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に本番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理
［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro
特許庁が5年前から進めてきた基幹系システムの刷新プロジェクトを中止する方針を固めたことが、日経コンピュータの取材で分かった。当初は2011年1月の稼働を予定していたが、業務分析の遅れなどから要件定義と設計が難航。稼働を3年遅らせたが、立て直すことができなかった。 政府が策定したレガシーシステムの刷新指針に基づき、特許庁は2004年10月に「業務・システム最適化計画」を策定した。この刷新指針は、特定のITベンダーとシステム保守などを長期契約することによるITコストの高止まりを解消する目的で策定されたものだった。同庁はさらに、入札に分割調達の仕組みを採用して競争原理を働かせることを目指した。 要となるシステム設計とシステム基盤の構築については、東芝ソリューションが入札予定価格の6割以下の99億2500万円で落札した。ところがプロジェクトが始まると、現行の業務やシステムを理解した職員と技術者が足
現場視点からの運用方法論
Copyright © 2004-2024 Impress Corporation. An Impress Group Company. All rights reserved.
同時進行プロジェクトの多い人の進捗管理、何がおすすめ？ | スラド IT
自分は社員数 50人程度の会社の唯一の IT関連従業員として働いており、仕事はプログラミングやサポートなど広範囲に及ぶ。 小さな会社ではよくあることだと思うが、物事の優先順位が頻繁に変化するため常に複数のプロジェクトやタスクを抱えることとなる。 ToDoリストには複数のプログラミングプロジェクト（新システムの開発や既存のシステムへの修正/改良など）や統合、リサーチ、メンテなどのプロジェクトやタスクが並んでいる。 タスク管理には現在 Outlook Tasksを使っているが、進捗状況を確認するために結局昔のメールなどを漁るはめになる。タスクからしばらく離れていた時などは進捗を確認するだけで 1～2時間かかることも稀ではなく、あまり上手くいっているとは言い難い。 MS Projectや OpenProjも検討してみたが各プロジェクトを独立したファイルにする仕様となっており、全てのプロジェクトや
わたしが知らないスゴ本は、きっとあなたが読んでいる: いきなりコンサルタントに抜擢されたSEが読むべき5冊
上長から「来週からコンサルタントとして○○社に入ってくれ」なんて言われたときに、あわてないための5冊。以下の条件全部にあてはまる人のための選書なので、関係ない方はスルーしてくだされ。シリーズ化しつつあるエントリ（ [その1]、[その2] ）だが、ここらでまとめ。 システム開発チームのメンバーまたはリーダー 顧客の御用聞きを「コンサルティング」だと思っている ←これ誤り McKinsey や accenture といった「ファーム」と一緒に、顧客の中に入って仕事しなければならなくなった これまで、即効性と実用性で4冊レビューしてきたが、このたび5冊目として扱いたいガイドを見つけた（4冊目）のでまとめてご紹介。 ■最初に結論 コンサル会社がやっている「コンサルティング」は、決まりきった手順や方法を粛々と実行しているに過ぎない。目標に対して泥臭いぐらい愚直に反応する。そうしたメソッドと沢山持って
見積もり・発注 - 技術情報Wiki
発注／調達 † 値切ってはいけない 2009.3.6 確かに，プロジェクトには予算が決められており，その予算の枠内でやり遂げる必要がある。どうしても予算と見積もり金額が合わない場合には，入念に価格交渉を行い，発注者と受注者の双方が金額の妥当性について合意した上で確定させるべきなのだ。 そのためには，PMは出てきた見積もりを査定する能力が必要であり，かつ高い折衝能力が必要である。 はじめてのRFP 2008.2.4 調達用語 RFP,SLCP,SPAとか ＲＦＰ（Request For Proposal：提案依頼書） ＳＬＣＰ−ＪＣＰ９８：Software Life Cycle Process - Japan Common Frame 1998 ＳＰＡ（Software Process Assessment）
脱Excel！ Redmineでアジャイル開発を楽々管理
ソフトウェア開発のタスクをチケットに登録すると、作業を始めるチケット管理をメインに、進ちょく管理、問題管理などができる。 バグ管理システムだけでなく課題管理システム（ITS：Issue Tracking System）で運用する開発プロセスは、チケット駆動開発（TiDD：Ticket Driven Development）と呼ばれ、最近注目されている。 Ruby1.9の開発はRedmineで管理されているように、近ごろは事例も増えている。 Redmine運用前の問題点 筆者がRedmine運用前に持っていたプロジェクト管理の問題点は下記2点だった。 1．Excelでのタスク管理の限界 従来からプロジェクトマネージャやプロジェクトリーダーの多くは、進ちょく管理やタスク管理をExcelで行ってきた。 プロジェクト管理では顧客へ進ちょく報告するために、残工数と残タスク数を計算する必要がある。だが
プロジェクト・マネージャの「やってはいけない」---目次 - プロジェクト・マネージャの「やってはいけない...：ITpro
プロジェクト・マネジメントのアンチパターンを徹底解説 プロジェクト・マネジメントにはセオリーがある。セオリーを知らずに，あるいは軽視して，失敗するプロマネは少なくない。現場でたたき上げたベテランの凄腕PMが，現場でプロマネがやってはいけないことを解説する。 関連サイト： ■メール編 ■やる気編 ■要件定義編 ■会議編 ■報連相編 ■協力会社対応編 ■品格編 ■課題管理編 ■変更管理編 ■コミュニケーション編 ■外注管理編 ■姿勢・資質編 ■計画＆進捗管理編 ■品質編 ■姿勢編 理由無き要求は機能化してはいけない プロジェクト事務局を軽視してはいけない 過去の成功体験にとらわれてはいけない 自己研鑽を怠ってはならない 目的を忘れてはいけない ■プロジェクト完了編 完了条件をあいまいにしてはいけない 完了報告会を省いてはいけない 成功・失敗要因を不明確なままにしてはいけない フィードバックを忘
ITpro プロフェショナルの現場
最強現場の作り方 あなたが働くシステム開発・運用の現場は，プロと呼べない独り善がりな現場になっていないだろうか。プロと呼ばれるITエンジニアの条件は「ユーザーに尽くし，ユーザーに信頼される」ことである。様々な切り口で，プロの現場になるための道を探る。 関連サイト： 7つの行動パターン プロとプロでない人のわずかな差 行動パターン1●情報システムや会社の歴史を調べる 行動パターン2●マニュアル類を手元に置く 行動パターン3●新聞，雑誌，Webサイトを読む 行動パターン4●緊急時の連絡網を整備する 行動パターン5●早く出社して段取りを確認する 行動パターン6●手順や作業内容を記録する 行動パターン7●明るく元気に挨拶をする あなたにもできる技術伝承 技術の断絶が起きている。社内にある技術，それを伝承できない現場に明日はない。だが，何を残せばよいのか。どう伝えればよいのか。「型」「反復」「体験」
プロジェクトマネジメントの理論と実践
この連載では，ITエンジニアにとって必須のスキルと言ってよいPMの基礎知識と情報システム開発への適用方法を，事例を織り交ぜながら解説していく。 第1回 PM実践体系--重要性増すPM,そのシステム開発での実践体系を知る 第2回 プロジェクト計画--システム開発プロジェクトの「計画」を作成する 第3回 品質管理計画--プロジェクト全体を通じた品質基準や方針を策定する 第4回 見積もりとコスト計画--開発負荷を見積もり，プロジェクトのコスト計画を策定する 第5回 マスター・スケジュール プロジェクト全体を見通す，実行性のあるスケジュールを作る 第6回 組織・要員計画--プロジェクトを効率的に推進できる組織・要員計画を作る 第7回 問題管理と変更管理--プロジェクトで生じた問題と仕様変更をコントロールする 第8回 ウォークスルーとインスペクション--設計・開発の早期に欠陥を発見・除去し品質を作り
プロジェクトの遅れを取り戻す方法10選
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます プロジェクトが計画通りに進まなくなる原因は数多くある。例えば、タスクの見積もりが甘かったり、プロジェクトから要員が抜けたり、リソースの割り当てがまずかったりということがある。本記事では、遅れの生じたプロジェクトを立て直すための実践的なテクニックを紹介する。 プロジェクトチームで働いた経験のある人であれば、様々な要因によってプロジェクトの納期がずれ込んでしまうということを知っているはずだ。一部の作業が当初の想定よりも手間取るものであったり、メンバーの入れ替わりが激しく、新担当者の業務知識に対する習得時間が無視できないものとなったりするのは珍しいことではない。また、単に作業見積もりが甘かっただけということもあるだろう。しかし原因がどのような
blog-entry-926.html
公共事業に従事する建設業はものすごく逆風の中を生きています。 その中で、地域の人から「ありがとうと言われたい」ということを 目的にし企業も行政もそして住民も三方が幸せになるためには、 できるだけ工期を短縮し、事業費を削減しながら利益を 確保することが必要です。 元々次工程が多く管理の難しい建設業の場合、 この工程管理が会社の業績を大きく左右するわけです。 その工期が長くなる大きな要因が、担当者の「サバ読み」 もちろん、ある程度のサバ（バッファ）がなければ 円滑な工事はできません。 ただ、人は責任感があるからこそ サバを多めに取りたくなるもの。 その申告されたサバをそのまま認めていては 工期が長くなりすぎ、住民への負担はもちろん 自社の利益も確保できないのです。 この本では、そのサバ取りの手法として、 ゆとりを創造することを積極的に議論する ゆとり創造型「科学的サバ取り段取り」を提唱していま
cpainvestor.com | 超長時間労働を厭わない組織風土をいかにして変えていくべきか
現役会計士が語るビジネス・会計・投資コラム このWebサイトに記載された事項は執筆者の私見であり、執筆者の所属ないし関係する機関・組織の見解ではないことをお断りしておきます。 1年半ほど前、今の主だったメンバーと仕事をするようになって、心に誓ったことが一つあります。「どんなにつらい状況に追い込まれたとしても、絶対に徹夜だけはするまい！」という信念です。 私が来る前の今のメンバーの組織は、「クライアントの期待に応える報告をするためには、何日か連続の徹夜も辞さない！」という方々が集まっていました。というか、そういう方しか残れない組織になっていました。「いくら日程的にタイトな状況に追い込まれることが多いM&A関連業務とはいえ、この状況は酷すぎる。体力的、精神的につらいからと言って反発して逃げるのではなく、自分が絶対にこの組織風土を変えてやる！」そう固く誓って、今のメンバーに合流しました。 それか
5分で絶対に分かるプロジェクト管理 ― ＠IT情報マネジメント
プロジェクト管理ってよく聞くけれど…… ソフトウェアの開発は、よく家を建てることにたとえられます。家を建てる場合、顧客の要望を聞いて設計などが終わった段階から、施工のスケジュールを立て、さまざまな関係者が予定に沿って作業を進めていきます。作業が予定どおりに進んでいるかを施工業者がチェックしたり、作業の途中で建築士が品質をチェックしたりしながら、家の完成まで工事全体を管理します。その管理をせずに家がちゃんと建つ保証はありません。 ソフトウェアを開発する場合も、顧客の要望を聞いて設計をした後に開発やテストの作業があり、その作業をさまざまな関係者が予定に沿って進めます。途中で作業が予定どおりに進んでいるかをチェックしたり、品質をチェックしたりしながら、完成までプロジェクト全体を管理する必要があります。 家を建てることは、何千年も前から行われてきているため、どうしたらうまくいくのか、何を管理してお
わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトを成功させる魔法の言葉
あいにく銀の弾丸の持ち合わせはないが、うまくいくプロジェクトでよく使われていた言葉は確かにある。耳にしたときは聞き流していてた言葉を、この本は思い出させてくれた。ここでは、そんな「魔法の言葉」を紹介する。 ネタ元は「目標を突破する実践プロジェクトマネジメント」。ふつう、図書館で読んだ本はそれっきりだが、こいつは買って周りにばら撒く。薄くて分かりやすくて、すぐにやってみようという気にさせるところがいい。 ■ もし、問題があるとすれば、それは何ですか? 朝会や進捗会議で「何か問題はありませんか?」という質問はよくするしされる。けれども答えはいつも決まっている→「特にありません」。でもって、不具合が起きると、「あのとき聞いたのにッ」←→「こうなるとは思ってなかった」となる。 身に覚えない? これを、冒頭の質問にしてみると、アラ不思議、いくらでも出てくる。「問題ない?」には無反応だったのが、「これ
MOONGIFT: � Excelではじめるプロジェクト管理「開発マイルストーン」:オープンソースを毎日紹介
プロジェクト管理の重要性は理解しつつも、実際にうまく管理されているケースはあまり多くない。大げさなシステムを導入した所で、普段の業務を圧縮してそのシステムを勉強する時間を作り出すのは非常に難しい。 わざわざシステムを導入するのではなく、現状の延長線上で考えよう。利用するのは普段使い慣れているExcelだ。 今回紹介するフリーウェアは開発マイルストーン、Excelを使った工程管理ソフトウェアだ。 開発マイルストーンはExcelアドオンと作業ファイルと二つで構成されている。アドオンを起動した後、作業ファイルを起動すれば利用できるようになる。 工程管理は面倒な帯をドラッグなどしたりしない。開始日と日数を入れれば自動で変更される。変更は表のみで、後は自動で描画が変わっていく。 関連を表す線も、一度クリアして再描画するだけでいい。さらに作業工数統計と言ったグラフ表示もできる。 慣れたExcelで作業
あるＳＥのつぶやき: プロジェクト管理メモ
プロジェクト管理はオンラインの情報だけで学べるものではないとは思いますが、情報がなくならないようにメモしておきます。 ■プロジェクト管理 プロジェクトマネジメント入門：ITpro プロジェクトマネジメント連載記事インデックス プロジェクトマネジメントの理論と実践：ITpro 計画部分を重視したプロジェクトマネジメント連載記事インデックス プロマネ最強マニュアル---目次：ITpro プロジェクトの火消し方法解説記事インデックス プロジェクト・マネージャの「やってはいけない」---目次：ITpro プロジェクトマネジメントアンチパターン解説記事インデックス なぜプロジェクトは失敗するのか インデックス － ＠IT自分戦略研究所 プロジェクト失敗理由の連載記事インデックス EnterpriseZine：コーナー：実務で役立つプロジェクトレビューの心得 リスク管理などのプロジェクト管理解説記事イ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
情報システム部門のタスク管理とIT全般統制 ～ Excel管理からの脱却 ～ (ITS Redmine #RxTstudy #5)
Amazon.co.jp： システム・シンキング入門 (日経文庫): 西村 行功: 本
