投稿元:
レビューを見る
システム開発に携わるすべてのプロジェクト・マネジャー必携。
プロジェクト計画書の作成からシステム稼働後まで、開発現場で直面する
さまざまなトラブル・シチュエーションごとに「何を」「どう」すればよいかを、
読みやすいQ&A方式で具体的に解説します。
手法はすべてPMBOKをベースとし、最新PMBOK第5版にも対応。
「失敗」から得た現場ノウハウを基に、現場で生かせるテンプレートを豊富に収録しています。
理論の解説にとどまらず、「いま目の前にある問題」の解決方法がわかる、今までになかった実践書。
これからプロジェクトマネジメントを学ぶ方はもちろん、ベテランのプロジェクト・マネジャーの方が
自己流の弱点を補正するためにも最適な1冊です。
実務としてのプロジェクトマネジメント
•プロジェクトの進め方や人の使い方を考える。
•方針に対してメンバーのコンセンサスをとり、全員が責任を持って動ける状態をつくる。
•プロジェクトが進んでいく中で発生するリスクを早期に検知する。
•リスクに対して解決策を実施し、問題の発生を未然に防ぐ。
•結果として、スケジュールが遅れることなくプロジェクトが進行する。
【第1章】 使える計画書を作ろう
第1問■計画書に欠けている重要なものは何か?
第2問■プロジェクト運営を円滑にするには?
第3問■どんなリスクを考慮しておくべきか?
第4問■スケジュール表をどう書けばよいか?
第5問■工数をどのように見積もればよいか?
第6問■体制をどのように作ればよいか?
【第2章】 プロジェクトを遂行しよう
第7問■まずどこから手を付ける?
第8問■システムの品質をどう保つ?
第9問■続発する問題をどうさばく?
第10問■仕様変更をどう乗り切る?
第11問■テストはどう管理する?
第12問■完了報告書はどう書く?
【第3章】 問題を切り抜けよう
第13問■外部委託先が期待はずれだったときは?
第14問■見積もりが想定をはるかにオーバーしたときは?
第15問■要件を確定できないときは?
第16問■テストが終わらないときは?
第17問■プロマネが倒れてしまったときは?
第18問■スキルアップのメニューを作るときは?
【第4章】 プロマネの基本を学ぼう
第19問■統合マネジメントの成果物は何?
第20問■スコープ・コントロールとは何?
第21問■初期段階ではどう見積もればよい?
第22問■ソフトウエアの品質をどう確保する?
第23問■どんなエンジニアが必要?
第24問■ベンダーはどう選ぶ?
[解説]
・ビジネスアナリシスが役に立つシステムを生み出す
・人間心理を考慮したスケジュール管理手法
・PMOが果たすべき役割とは?
・PMに求められる能力とは?
・PMに課せられる役割とは?
・国際標準「PMBOK」とは?
・プロジェクトを円滑に進めるためのステークホルダー・マネジメント
■プロジェクトの進め方や人の使い方を考える。
プロジェクトを動かすため���、まず全体像に対してどの部分から進めていくか、
どういう手順を踏むか、誰にどういう役割を担ってもらい、何に対して責任を負ってもらうか、ということを考えます。
考える精度は高いほうがいいですが、自分1人で完璧なものを作る必要はありません。
進め方や役割はみんなで相談して決めていくものなので、自分の考えはあくまで草案だと思ったほうがいいでしょう。
実作業をする人にしかわからないことが必ずあると思うので、メンバーに詳細を考えてもらうための叩き台として、考えをまとめておきます。
方針に対してメンバーのコンセンサスをとり、全員が責任を持って動ける状態をつくる。
草案として考えた進め方や役割を、全てのメンバーに見てもらい、修正をし、コンセンサスをとります。
確認した結果、「この内容では出来ない」と言うメンバーがいたら、
その人が出来ると思う範囲まで仕事を減らして、「出来る」という言葉を引き出します。
この時、威圧して無理矢理「出来る」を言わせてしまってはいけません。
無理だと思っていることに対して、無理矢理「出来る」と言わせたところで、
そこに責任感、使命感は生まれないでしょう。
遅れが出ても、その人は「もともと無理だと思ってたし」と心の中で言い訳をしてしまうことになります。
本心から「出来る」を引き出して、役割を担ってもらうことが大事です。
■プロジェクトが進んでいく中で発生するリスクを早期に検知する。
コンセンサスをとって仕事を引き受けてもらったにも関わらず、
実際プロジェクトを進めてみるとメンバーからは「出来ない」「間に合わない」という声があがってきます。
自分の前工程の人の作業に遅れが出た。
ルーチンで持っているタスクに思っていたより時間がとられた。
別のクライアントからの緊急の問い合わせが入った。
何かしらの理由につけて、仕事が遅れてしまうのです。
もちろん、自分でリスクを報告してくれるメンバーばかりではありません。
なんとなく「まずいなぁ」と思っていながらも、それを素直に教えてくれないメンバーもいます。
というか、そんな人がほとんど。
そうした人が抱えているリスクには、こちらから気づいてあげる必要があります。
進捗を確認した時の回答の中に「多分」「なんとか」「まぁ」という言葉が含まれていたら要注意。
その人の仕事には既に遅れが発生しているか
これから遅れが発生する可能性が高いです。
常にリスクの予兆をキャッチし、見逃さないことが、この段階では非常に重要になってきます。
■リスクに対して解決策を実施し、問題の発生を未然に防ぐ。
リスクをキャッチしたら、対応方法を考えます。
前工程での遅れによって作業が進められないメンバーがいるのならば、
タスクの順番を組み替えて、進められるところから仕事を割り当てる。
他のチームが検討している内容を確認しないと設計が進められないメンバーがいるのならば、
すり合わせのための場をセッティングする。
ルーチンワークに時間がとられてしまってい��メンバーがいるのならば、
その人のルーチンワークに無駄がないかをチェックして改善案を出す。
メンバーからの申告で、見積もりに漏れがあったり、
そもそもスケジュールに無理があることがわかった場合は、正直にクライアントに報告をし、調整をかける。
ここではどんな問題が出てくるかわからないし、決まりきった対応方法なんて存在しません。
ただ、困っているメンバーがいるということに対処してあげることが大事です。
小さなリスクを放置すると、時間の経過とともに指数関数的に成長して大きな問題になってしまい、
プロジェクトに大ダメージを与えるなんてことにもなりかねません。
■結果として、スケジュールが遅れることなくプロジェクトが進行する。
人と人の間で揉みくちゃになりながらの調整の積み重ね。
"スケジュールに対して遅れがでないかたちでプロジェクトを進ませること"が僕たちプロマネの使命の1つですが、
スケジュールに遅れが出たかどうかという話は、こうした日々のリスクコントロールの結果に過ぎません。
スケジュールに対して「進捗どうですか?」と言っているだけ、
状況を上司に報告するだけ、遅れが出てから対処をするだけ、
そんな仕事をしているうちは真のプロマネとは言えないのではないでしょうか。。