→プロジェクトマネージャー

→スケジュール・進捗管理

→開発チームの構築

→リスクマネジメント

→顧客対応

→開発プロセス

→プロジェクト管理ツール

→ドキュメント作成

→開発支援ツール

→バグトラッキングツール


#contents


*関連ニュース・記事など [#vff4a486]
-[[どうやら本当のデスマーチを教える時が来たようですね>https://qiita.com/tanakahisateru/items/812fd9128259b6c5dfd9]] 2020.12

-[[ブルックスの法則を可視化できるのか(あるいは、人と月は等価交換できるのか)>https://dskst9.hatenablog.com/entry/2019/03/02/190222]] 2019.3
--要員数を増やしても生産性が上がらないことを計算式で説明

-[[ベンダーよ、シェルパの屍を越えていけ 〜 細川義洋×山本一郎「なぜ、システム開発は必ずモメるのか?」 (1/2)>http://www.atmarkit.co.jp/ait/articles/1402/21/news080.html]] 2014.2.22

-[[「ITエンジニアの『生産性』と、データ・サイエンスの微妙な関係」>http://d.hatena.ne.jp/JavaBlack/20130708/p1]] 2013.7.8
--[[続・「ITエンジニアの『生産性』と、データ・サイエンスの微妙な関係」>http://d.hatena.ne.jp/JavaBlack/20130712/p1]] 0213.7.12

-[[歴史から考えるアーキテクチャとマネジメント>http://arclamp.hatenablog.com/entry/2012/10/21/190000]] 2012.10.21

-[[ソフトウェア開発プロジェクトをとりまく6つの誤解〜プログラミングを経験しないとわからないこと>http://kuranuki.sonicgarden.jp/2012/08/post-78.html]] 2012.8.8
--既にあるソフトウェアを流用した方が速く作れる
--ソフトウェアはハードと違って後から容易に直せる
--誰が作っても中身は同じ品質になる
--共通部品から先に作ることが出来る
--人を増やせば一度に沢山の機能が作れる
--正確な見積もりを出すことが出来る

-[[伝えなければ伝わらないという当たり前の話>http://kuranuki.sonicgarden.jp/2012/08/post-79.html]] 2012.8.9

-[[ソフトウェア開発プロジェクトを蝕む10の典型的な過ち>http://japan.cnet.com/sp/businesslife/35017982/]] 2012.6.13
--「人数を増やせばよい」という誤解
--間違った指標を採用する
--現実離れしたスケジュールを組む
--時間の見積もりが大雑把すぎる
--作業を計算に入れ忘れる
--コミュニケーション不足
--ビジネス上の優先順位を無視する
--手続きによる壁を作る
--「すぐに本格的な作業を始められる」という神話
-- マルチタスク

-[[システムはどこまで内製化できるか>http://d.hatena.ne.jp/okachimachiorz/20111030/1319976727]] 2011.10.30

-[[Web2.0時代のソフトウェア開発手法>http://itpro.nikkeibp.co.jp/article/COLUMN/20060402/234199/?ST=selfup]]

-[[どのタスクも落とさないタスク管理、7つのコツ>http://plusd.itmedia.co.jp/lifestyle/articles/0906/01/news010.html]] 

-[[プロジェクトマネジメントで起こりやすい7つの問題と解決方法>http://coliss.com/articles/build-websites/operation/work/7-common-project-management-problems-and-how-to-solve-them-by-sixrevisions.html]]
--曖昧な要件 -> マイルストーン設定
--クライアントの返答待ち -> Yes/Noで答える質問
--遅延 -> 現実的な時間を割り当てたスケジュールをクライアントに伝える
--プロジェクトごとに異なる管理
--クライアントができたものに満足しない -> クライアントの動機を根本から理解
--プロジェクトのプライオリティが低い ->決定権のあるクライアントとコンタクト
--問題解決に時間がかかる -> テストの時間を多くとる(※それができたら苦労はない

-[[プロジェクトはなぜ成功するのか>http://itpro.nikkeibp.co.jp/article/Watcher/20101214/355220/]] 2010.12.14
--プロジェクトの成功は何で決まるのか、一言で言えと問われれば「プロジェクトの成否はメンバーで決まる」と答える。これが土台にある。しかし、それだけでは不十分で、プロジェクト管理の在り方で同じメンバーでも結果は大きく違ってくる。ポイントは以下の三つだ。
   1. 対症的プロジェクト管理でなく、予防的プロジェクト管理をすること
   2. 設計品質だけでなく、作業品質の向上を図ること
   3. プロジェクト全員が共通の目標を持つこと


-[[ダラダラ続くムダ会議から脱出!「会議」の効率を今すぐアップする方法>http://b.hatena.ne.jp/articles/201010/1856]]
        * 事前に必ずアジェンダを用意する。
        * 参加者を厳選する。
        * 議事録はそのプロジェクトに詳しい人がとる。
        * 何のための会議か、目的を参加者全員で共有する。
        * 時間通りに始め時間通りに終えられるよう、時間のマネジメントを徹底する。
        * 会議中、参加者は携帯電話やPCを操作しないで議題に集中する。
        * 会議が終わったら、決まったToDoを確認する。


-[[プロジェクト・アンチ・パターンの集大成「アドレナリンジャンキー」>http://dain.cocolog-nifty.com/myblog/2009/12/post-71bb.html]] 2009.12.21
--「アドレナリン・ジャンキー」とは、モーレツ社員(死語)、もしくはモーレツ社員で構成された組織のこと。すべての仕事は最優先で、全ての送信メールは、【!緊急!】で始まる。作業の順番は重要性ではなく、切迫度によって決められる。したがって、長期的な見通しは存在せず、全ての仕事は、ある日突然、「緊急」になるまで放置される。

-[[プロジェクトの失敗はスタート時点にあり。キックオフ前に、ミッションマップを作ろう>http://d.hatena.ne.jp/favre21/20091204#1259882766]] 2009.12.4
--1.あなたの会社(プロジェクト)のミッションは何か?
--2.あなたの会社(プロジェクト)の顧客は誰か?
--3.あなたの会社(プロジェクト)が提供する価値は何か?
--4.あなたの会社(プロジェクト)にとっての成果とは何か?
--5.あなたの会社(プロジェクト)の計画は何か?


-[[トラブル対応に必要な“余裕”をどう作る? >http://itpro.nikkeibp.co.jp/article/COLUMN/20091113/340521/?ST=pm&P=1]] 2009.11.17
--ルーチン作業を自動化するツールを作り、蓄積する

-[[プロジェクト成功のために>http://shokuning.exblog.jp/11209910/]]
--ソフトウェアは、多数のチームやプロジェクト、硬く結束した作業グループで開発するので、ハイテクビジネスではなく人間関係ビジネスに携わっているといえる。
--プロジェクトの成功は関係者の緊密な対人関係によって生まれ、失敗は疎遠な対人関係の結果である。
--仕事の人間的な側面より、技術面に注意を多く払う理由は、重要だからではなく、単に解決しやすいから

-[[『プロジェクトファシリテーション』書評>http://www.ringolab.com/note/daiya/2009/10/post-1089.html]]

-[[デッドライン ソフト開発を成功に導く101の法則>http://anond.hatelabo.jp/20090725154202]]
--適切な人材を雇用する。
--その人材を適所にあてはめる。
--人々の士気を保つ。
--チームの結束を強め、維持する。
--(それ以外のことは全部管理ごっこ)

--どれほど強い脅しをかけても、最初に割り当てた時間が足りなければ、やはり仕事は完成しない。

--短期的に生産性を高める方法などない。生産性は、長期的な投資によって向上する。

--成功を最大化するより、失敗を抑えることによって、全体的な成績を高めることができる。

--優れたプロジェクトは、デバッグに費やす時間の割合がはるかに低い。
--優れたプロジェクトは、設計に費やす時間の割合がはるかに高い。
--相手を好きになり、気遣わなければ、人に違うことをさせることはできない。相手を変えるには、相手の考えていることとその理由を理解し、尊重しなければならない。

--プレッシャーをかけても思考は速くならない。
--残業時間を増やすのは、生産性を落とす方法である。
--一時的なプレッシャーや残業は、人々の焦点を定め、その仕事が重要であるという認識を高めるには有効な方法かもしれないが、プレッシャーをかけすぎると、かならず失敗する。
--管理者が部下を刺激するために侮辱を使うことは、部下ではなく管理者の能力不足のしるしである。

--入出力の完全なリストのない仕様書は、見込みなしである。仕様を明確にする最初の一歩にもならない。

--理想の人数配分は、プロジェクト期間の大部分を少人数のコア・チームで行い、プロジェクトの終盤(プロジェクト期間の最後の6分の1ぐらい)に人数を大幅に増やすというものである。

--おそるべき推察:無茶なスケジュールを達成するように決められたプロジェクトは、妥当なスケジュールで開始されたプロジェクトに比べ、完成までに時間がかかると思われる。

--病んだ政治を下から治療することはできない。むだな努力で時間を浪費したり、自分の立場を危険にさらす必要はない。

--プロジェクトには目標と予想の両方が必要だ。この二つはちがっていて当然である。


-[[プロジェクト管理サーバーとは>http://forza.cocolog-nifty.com/blog/2009/04/post-2534.html]] 2009.4.11

-[[正解を知っていても、あえて黙っている方がよい状況を知る>http://business.nikkeibp.co.jp/article/nba/20090122/183567/]] 2009.1.30
--正解を知っていても総合的に見て黙っていた方がよいことに加えて、あと2つ重要なことがある。「正解を知らない人たちはダメだ」という愚痴を言わないことと、結果が出てから後出しじゃんけんのように「正解はこうだったんだ」と言わないことだ。 

-[[議論を恐れてはならない>http://itpro.nikkeibp.co.jp/article/COLUMN/20080725/311502/]] 2008.8.21
-[[プロジェクトを開始前の準備>http://itpro.nikkeibp.co.jp/article/COLUMN/20080729/311687/]] 2008.8.21
--スコープを決める
--ソリューションを最適化
--開発規模見積もり
--要員と体制の検討
--提案段階でフェーズが重ならないスケジュール
--リスクを識別・定量化



-[[空中戦をやってはいけない>http://itpro.nikkeibp.co.jp/article/COLUMN/20080725/311536/]] 2008.8.19
--空中戦とは,お互いの意見を文字にすることなく,ただ口頭だけで会議を行うこと
--会議では,必ず参加者全員が認識できるような方法で書き留めるべきである。板書書きやプロジェクタで映すやり方が有効である。

-[[旧来の手法では最先端の製品は開発できない>http://techon.nikkeibp.co.jp/article/COLUMN/20080423/150875/]] 2008.4.24
--昔風の開発のやり方で最新の高度で複雑な製品を開発しようとすると,個人に限界を超える負担を強いる場合が出てきます。その結果,個人に対して非常に過酷な影響が出る。しかも度々です。私も健康を害したことがあります。こうした環境は,どこの企業でも開発の最前線を歩いている人たちに共通かもしれません。僕は開発の責任者をしている期間がすごく長かったので,その恐ろしいほどのムダを身に染みて知っています。結局,(発展性が乏しかったり,汎用性が低かったりする)弱い技術を一生懸命育てようとすることになってしまい,手間がかかるだけで何の意味もありません。そういうことを何度も繰り返しやることに対して,本当にムダだなあ,と強く思っているんです。

-[[仕事の仕組み化は万能か?仕組み化の副作用>http://d.hatena.ne.jp/favre21/20080409#1207694340]] 2008.4.11
--うかつに「仕事の仕組み化」を行ってしまい、「仕組みを作り出す人」だけが自己満足に浸り、チームの生産性が逆に低下していくケースが多々発生するのです。論理的に、完璧な「仕事の仕組み化」を行っても、その中で働く「仕組みにより動かされていく人」のモチベーションがどんどん下がってしまい、相談に来られるというケースが増えています。

-[[システム開発から属人性を排除しようとして失敗する>http://forza.cocolog-nifty.com/blog/2008/04/post_f03f.html]] 2008.4.2

-[[アプリとインフラの担当者はなぜ分かり合えない?>http://itpro.nikkeibp.co.jp/article/COLUMN/20080229/295124/?P=1&ST=management]] 2008.3.5
--(1)お互いがインフラ(アプリ)のことを知らない
---アプリ・チームが作成した設計書をインフラ・チーム側で精査して各種パラメータを検討するとか,性能が出ないと思われるアプリについて単体テスト段階からインフラ・チームと検討する,といった協力体制があれば問題は未然に防げます。PMOはそのような協力体制を「仕組み」として作り込んでしまうことが必要なのです。メンバーの自主性だけに任せておくと,いつまでも同じような問題が繰り返し起こります。
--(2)プロジェクトの成功よりも自分の組織の成功を最優先に考える
---プロジェクトが1つの方向を向くようにナビゲートしなければなりません。上位組織に呼びかけるなどの対応は不可欠ですが,あくまでも『プロジェクトの成功が最も重要なゴールである』とプロジェクト全体に示す必要があります。その意味において,「プロジェクトとして成功したかどうか」を人事評価項目に含めるのも1つの手だと思います。
--(3)「相手が決めてくれないと自分の作業が進まない」という理屈が横行する
---「担当者同士の課題」から「プロジェクトの課題」へとエスカレーションできる仕組みを作る

-[[プロジェクト管理は「簡単なことを、確実に」>http://www.atmarkit.co.jp/im/cpm/serial/9target/02/01.html]] 2008.3.3
--成果を明確にする、作業分解、作業フロー、スケジュールの作成

-[[ITの地殻変動はどこで起きているか?>SeasarとRuby,PF>http://forza.cocolog-nifty.com/blog/2008/03/itseasarrubypf_bf37.html]] 2008.3.2

-[[今時の自動化>http://itpro.nikkeibp.co.jp/article/OPINION/20080225/294614/]] 2008.2.27
--自動化で成功している現場は適用範囲をやはり限定。それも人間のある作業に着目して自動化していた。その作業とは,「確認」「引き継ぎ」「判断」の三つである。これらの作業は自動化に伴うリスクが低いうえに,生産性や品質に直結するので自動化の効果も大きい

-[[わたしの7つのふりかえり>http://dain.cocolog-nifty.com/myblog/2007/10/7_ca8d.html]] 2007.10.2
--■01 定期的に、ふりかえる
--■02 わたしたち v.s. 問題
---相手の向こう側に「問題」があるので、相手を口撃してしまうのが、ホワイトボードに書き出すことで
 ホワイトボード(問題)  ←←←←← 「わたし and あなた」
になる
--■03 「問題」を持って、歩き回る
--■04 人を集める
--■05 よい質問
---* いま取り組んでいるのは、どんな問題なのかな
---* その問題が解決するとはつまり、○○ということになればOKなんだよね
---* 「○○になった」のは、どうやったら分かる?
---* それはいつ分かる?
---* それは誰が分かる?
---* あるいは、わたしが分かるためにはどうすればいい?
--■06 お菓子は、重要なのかもしれない
---一緒にモノを食べてると、敵じゃないという気になれる。
--■07 Getting out of the Box

-[[案件成功のための10の鉄則>http://enterprisezine.jp/article/detail/32]] 2007.7.30
--鉄則1:プロジェクト/案件内容の把握を確実に
--鉄則2:チームビルディングを楽しもう
--鉄則3:利害関係者間でコミット、自分の負担を軽減
--鉄則4:スケジュール作成で作業計画を明確化
--鉄則5:メンバー作業のトレースは最低1日1回
--鉄則6:上司への報告はスムーズに
--鉄則7: 工数把握でワーニングをキャッチ
--鉄則8:問題点のフロー化
--鉄則9:締めも肝心
--鉄則10:見直しは絶対しましょう

-[[masuidrive的プロジェクトの方針>http://blog.masuidrive.jp/index.php/2007/07/11/masuidrive-working-style/]] 2007.7.11

-[[プロジェクトを成功させる魔法の言葉>http://dain.cocolog-nifty.com/myblog/2007/03/post_41f0.html]]
--もし、問題があるとすれば、それは何ですか?
--あと何日?
--目的は何ですか? 成果物は何ですか? 成功基準は何ですか?

-[[Google、はてな、Appleに学ぶ失敗しないプロジェクトの3ヒント>http://www.itmedia.co.jp/bizid/articles/0702/28/news062.html]] 2007.3.8
--死守すべき締め切りを作らない
--メンバーのやる気に依存しない
--変化することを前提とする

-[[モチベーションを高めるには達成すればよい>http://www.atmarkit.co.jp/im/cpm/serial/need03/need03.html]] 2006.11.29

-[[生産性は計測できない:http://capsctrl.que.jp/kdmsnr/wiki/bliki/?CannotMeasureProductivity]]
--チームの生産性というのは、構築したソフトウェアをリリースしてから数年後に初めて分かるようなものかもしれない

-[[プロジェクトキックオフオリエンテーションで話すこと:http://www.atmarkit.co.jp/im/cpm/serial/user/11/01.html]] 2006.6.20
--機能要求仕様はユーザー側が主体となってまとめるべきものであり、ベンダへの丸投げはプロジェクトの失敗につながること
--システム仕様の作成とは要求事項を羅列することではなく、取捨選択、検討して絞り込むことであること

-[[プロジェクトを管理しないという発想:http://www.atmarkit.co.jp/farc/rensai2/emer01/emer01a.html]]



*PMBOK [#h2dab143]
-[[【PMP試験対策】 プロジェクトマネジメント・フレームワーク>http://dain.cocolog-nifty.com/myblog/cat491351/index.html]]

-[[PMBOK Guid 3rd Edition(pdf)>http://www.scribd.com/doc/43934/PMBOK-3rd-English]]
-[[PMBOKの実際を理解する>http://itpro.nikkeibp.co.jp/article/lecture/20070313/264660/?ST=lecture&P=1]]
-[[PMP試験の準備>http://dain.cocolog-nifty.com/myblog/2007/02/pmp_fa58.html]]
-[[PMP試験対策>http://dain.cocolog-nifty.com/myblog/2004/03/post_13.html]]
-[[簡単な説明@IT:http://www.atmarkit.co.jp/aig/04biz/pmbok.html]]
-[[PM University:http://www.pm-university.com/index.html]] PMBOK関係?


*関連Webサイト・参考資料 [#b6178284]
-[[日本プロジェクトマネジメント協会オンラインジャーナル>http://www.pmaj.or.jp/online/index.html]]

-[[ITプロジェクト管理考>http://www.itnetinc.co.jp/ITPMopinion/index.htm]]
-[[書評:プロジェクトマネジメント・現場マニュアル>http://dain.cocolog-nifty.com/myblog/2007/06/post_04aa.html]]
-http://www.toc-ccpm.net/index.html
-[[The art of project management読書感想:http://dain.cocolog-nifty.com/myblog/2006/11/post_eb6b.html]]
-http://www.pminfo.jp/index.htm
-[[One Hundred Rules for NASA Project Managers:http://www.altisinc.com/Links/100_Rules.html]]
-[[Martin Fowler's Bliki:http://martinfowler.com/bliki/]]
--マーチン・ファウラーのblog+Wiki
-[[@IT プロジェクト管理のトップ:http://www.atmarkit.co.jp/channel/pm/pm.html]]

トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS