2012年12月9日日曜日

読書記録:失敗しないWeb制作 プロジェクト管理のタテマエと実践 (中編)

読書の目的

前回のエントリに引き続き、プロジェクトマネジメントを知り、エンジニアとして参画するときにいつ何をすればよいのかを読み取る。


特にプロジェクトがうまくいかなくなるのを未然に防いだり、立て直すためのコミュニケーションの方策を知りたい。

詳細見積もり

WBS (Work Breakdown Structure)

プロジェクトの作業と要素成果物を細かく定義する。
ボトムアップによる見積もりにつかう手法。

WBS作成のポイントと留意事項

ポイント
  • 必ず一度、実施項目を書き出す
  • 完璧を目指さない
  • レビューを通じて無理や破綻をつぶす
留意事項
WBS作成者は制作のワークフローや要領がわかり、各工程に慣れていることが前提。
不正確なWBSは重要なタスクを見落としたり、不必要なタスクを実行するなど失敗の元凶となる。

WBSは修正がされることを前提に、メンテナンスのしやすさとバージョン管理を考慮する。

見積もりの認識がズレがちなポイント

  • スコープ
  • 金額そのもの
  • 数量と単位の認識
  • 制限や制約

→ エンジニアとしてできることは、実現不可能な見積もりにNOを言うこと。技術的な制限や制約などを非エンジニアにわかりやすく、誤解のない表現にすること。 プロジェクト開始後に変更されそうなポイントの指摘、対策。

プロジェクト立ち上げ時の計画

PMBOKの計画プロセス群

  • プロジェクト総合マネジメント
  • プロジェクトスコープマネジメント
  • プロジェクトタイムマネジメント
  • プロジェクトコストマネジメント
  • プロジェクト品質マネジメント
  • プロジェクト人的資源マネジメント
  • プロジェクトコミュニケーションマネジメント
  • プロジェクトリスクマネジメント
  • プロジェクト調達マネジメント
マネジメント対象はリソース(ヒト、モノ、カネ)、スケジュール、アウトプット(スコープ、品質、リスク)、そしてプロジェクト自体の制御やコミュニケーション。

人的資源マネジメント

プロジェクトを推進する「人」の役割の明確化。
「ステークホルダー全員を、プロジェクト達成のために効率的に活かす」体制づくりがおろそかにされがち。

RACI (Responsible Accountable Consulted Informed) 

責任分担のマトリクス。どのタスクに対してどのような役割を果たすのかを示す。
R : Responsible 実行責任者。
A : Accountable 説明責任者。
C : Consulted 協業先
I : Informed 報告先
「誰を説得するか」「どこまでフォローするか」といったコミュニケーションの道筋がはっきりする。

リスクマネジメント

プロジェクト開始前にあらかじめありえるリスクを予想し、対処法を決めておく。

特性要因図 (fish-born chart)

リスクをリストアップして、リスクの程度と頻度、対応策を計画に落としこむ。
特性:現象や結果などのよくないこと。
要因:特性に影響する要素。 要因の抽象度(粒度)でレベル分けする。


調達マネジメント

「今回のプロジェクトでは、何を狙いとしてやるべきか?そのためには何が必要でどう取り寄せるか?」

対象はヒト(人員)・モノ(什器、ネットワーク)・カネ(予算、費用)・コト(手配、契約行為)。またプロジェクト終了後の返却や破棄・処分も計画する。


品質マネジメント

品質 = 「プロジェクトのステークホルダーが、プロジェクトに何を期待するか?」を満たすこと。

品質マネジメントの分類
  • 評価に関する作業 
    • 品質の維持するためのテスト計画、テスト実施
  • 予防に関する作業 (事前対応)
    • 欠陥を予防し、結果として欠陥対応にかかるコストを削減するための作業
  • 失敗に関する作業 (事後対応)
    • 成果に瑕疵やミスがあったときに、改修やクレーム対応を行う
→ エンジニアとしては、欠陥が発生したときの被害の大きさ、起こりやすさを把握し、計画段階で説明する。説明する範囲は責任分担マトリクスに従う。

コミュニケーション計画

プロジェクトは人が進めるもので、メンバーの作業と行為によって成し遂げられる。メンバー同士の意思疎通がうまくいかない状態や、想定の食い違いを放置していればプロジェクトは失敗する。

プロジェクト管理におけるコミュニケーション

コミュニケーションの分類
  • 情報配布 : 必要な情報をタイムリーに提供する
  • ステークホルダーへの期待のマネジメント : 関係者のニーズに応え、課題を解決し、プロジェクト破綻を防ぐ
  • 実績報告 : 実際のプロジェクト進捗とベースラインの差異を明らかにする。

プロジェクトの実行時はルールを元にコミュニケーションを図る。
ルールは堅すぎず流動的すぎず運用する(状況が変わればルールは変更する)。

コミュニケーションマネジメントに用いるドキュメント
  • プロジェクトマネジメント計画書
  • ステークホルダー登記簿
  • 課題や変更のログ : 課題管理票もしくはサービス(Excel,JIRA,Redmine,Backlog)
  • 実績報告書

コミュニケーションマネジメント計画書

記載項目例
  • ステークホルダーは誰か、どんな情報を必要としているか
  • コミュニケーションの手段、書式
  • コミュニケーション手段ごとの頻度
  • コミュニケーションの発信者、受信者、責任者
  • コミュニケーションマネジメント計画書の変更手続き
  • プロジェクトでの用語、コミュニケーション様式、書式関連の用語と説明

コミュニケーションの実践

コミュニケーションについて計画を立て、実行する目的は
  • 作業を効率化(タイムロスを減らす)
  • 混乱を起きにくくする、起きても早々に収束する
  • 各メンバーのストレスを減らし、作業に集中する
無駄を排し、意思疎通をしやすくするためにルールがある。
ルールに従う時やルールそのものを作ったり変えるときには
「プロジェクト推進の全体最適化」
「その情報伝達の先に何が控えているか」
「トラブルが発生したときに、どこを参照すればよいか」
などを考慮する。

コミュニケーションには感情が入り込むため、規格化とルール化でコミュニケーションの品質を担保する。
コミュニケーションが円滑であることは、必ずしも仲良しである、意見が一致しやすいといったこととは同じではない。

コミュニケーション計画で決めておくこと

  1. 決裁ルートと連絡体系
    • 「ものごとを取り決める」ために、誰が誰に相談し、誰が決めるか。
    • 「責任の所在」を含めた「取り決めの道筋」を事前に用意しておく。
    • 決裁ルートの「往路(打診)」と「復路(返答)」を押さえる。
      • 特に復路に不備があると、認識漏れが生じる
    • 決裁要件は「現象」、「プラン」、「どうして欲しいか」、「期限」
  2. 会議体
    • 種類、頻度、曜日と時間帯、所要時間、参加者、場所、司会、議事録
  3. 手段
    • 打ち合わせ、会議、メール、グループウェア、ファイル

コミュニケーションについての心づもり

  • 自分ができることは何か : 権限上可能なこと、状況として可能なこと
  • 主観を疑う : メンバーからのフィードバックを受ける
  • コミュニケーションツールの変更を想定する

 すべての情報を記憶し追うことは不可能。参照不可能な情報は存在しない。

→ エンジニアは、ルールに従い、感情の影響をした品質の高いコミュニケーションを心がける。 マネージャーが想定したコミュニケーションルールの問題に気づいたとき、その状況と改善方法を提案する。



まだまだあるので後編に続く




0 件のコメント:

コメントを投稿