2012年12月8日土曜日

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

読書の目的

自分の興味があることはプロジェクトにおいてどのようなタスクがあり、どのような役割分担がされているかということ。

上司やチームメンバーへの報告、連絡、相談は、どのような事柄について、どのようなタイミングで、どのような粒度で行えばよいのかを明らかにする。


プロジェクトとは

  • プロジェクト = “独自”のプロダクト を“創造”する“有期性”の業務
  • 監視コントロールによって“計画”と“実行”を繰り返す
  • 要求 (作りたいもの) と資源 (ヒト + モノ + カネ + 時間 )のトレードオフ
→ まず計画段階ではどのくらいの資源が必要になるか、見積もりを行う必要がある。エンジニアがマネージャへ情報を伝える際には精度を伝える必要がある。
実行において見積もりが外れた場合、マネージャは要求を変更するか、資源を追加するかを判断する。

PMBOKの9つの知識エリア

  • 総合マネジメント 
  • スコープマネジメント (実施すること)
  • タイムマネジメント (スケジュール、何をいつまでにやるか)
  • コストマネジメント
  • 品質マネジメント
  • コミュニケーションマネジメント
  • 人的資源マネジメント (チームの編成・育成・管理)
  • リスクマネジメント (リスクの予測と対処)
  • 調達マネジメント 
→  これらの計画と実行結果異なっていれば、報告する。
成果物がスコープと異なる、納期に間に合わない、費用がかかる、品質が不十分、障害など予期せぬ悪影響が発生する

見積の種類

見積もりは「ざっくり」から「概算」を経て、「確定」へと進化させていく。

ざっくりとした見積もり 

提案書作成段階まで に行う見積もり。  過去の蓄積と比較し、だいたいこのぐらいという相場を提示する。

概算見積 もり

受注確定前までに行う見積もり。金額はまだ確定しない。与件や提案内容をもとにタスクやリソースなどの項目を洗い出す。

確定見積もり

プロジェクト終盤 で発注者に請求する段階での見積もり。プロジェクトの途中で成果、期日、使用リソースが変動したものを加味して確定する。

→ エンジニアは「ざっくり」と「概算」の見積もりにおいて、求められる情報の粒度が異なること理解し、伝えるべき情報の取捨選択する。
特に私の場合、情報をすべて(広範囲に、詳細まで)伝えようとするので、マネージャがそれを噛み砕いて状況を整理し、判断するコストが高い。


要件定義と詳細見積もり

心構え

  • 要件定義とは、与件や要望を実現するためにまとめ、明文化すること
  • 要件を作らなくてもプロジェクトはスタートできるが、逐次決定ではスタート以降のコントロール能力とスピードが低下する
  • 詳細見積もりは「正解を出す」よりも「あいまいさをなくす」


スコープ

「何を」「どう作るか」という「範囲」。それがそろってはじめて「いくらかかるか」がわかる。


Web制作のスコープ = 「プロジェクトのスコープ」 +  「成果物のスコープ」
プロジェクトのスコープ =  「成果物を提供するための作業」
プロジェクトのスコープ定義 =「その作業範囲を限定すること」
成果物のスコープ = 「何を制作し、何を納品するか」
成果物のスコープ定義 = 「要素成果物の洗い出し」

ベースライン

発注者と制作者で握り合った「基準」。成果物スコープ、プロジェクトスコープ、コストにおいて設定する。

コストコントロール


プロジェクト実行時に予算に変更をおよぼす要因を明らかにし、必要性を決定し、変更をコントロールするプロセス。


要件定義の作業

  1. 情報収集
    • 掘り下げ不足のチェック、メモ適切に使ってヒアリング
  2. 整理・分析
    • 優先順位をつける(ROIと重要度でクロス分析)
    • 大目的、目的、目標、今回のスコープを決定
  3. 文書化

デスマーチが起こる要因

デスマーチ = 制作メンバーが対応しきれる以上の負荷がかかり続ける状態。起こる要因は主として、スケジュールと作業量の見誤り。また要件定義と詳細見積もりのミスに起因。

不確定要素が発生したときの対処フロー

不確定要素が
致命的でない → 棄却/制作者内部で共有。
致命的 → メールや打ち合わせで確定させる。

致命的かどうかの判定

  • それについて決定しないと次のタスクに進めない
  • それについて決定を誤ると制作者と発注者の双方が不利益を被る


→  エンジニアとして要件定義に参加する場合、与件や要望を最小限満たすためにどのような解決策があるか、甚大な失敗をしやすい箇所はあるのかという情報に絞って、マネージャへ伝達する。また要件定義なしで着手した場合、後の工程でどのようなリスクがあるかを理解する。

詳細見積もりの手法とレビュー方法

手法
  • トップダウン見積もり
    • スコープから規模算出し、作業量(単価、工数)と合わせて計算する
    • 開発コスト = 規模×作業量 + 予備費
    • 規模の想定が正しければ、客観的。弱点は想定外タスクや取りこぼし。
  • ボトムアップ見積もり
    • 作業項目など全タスクを洗い出し、作業費(単価×工数)算出
    • 開発コスト = 開発作業費 +  モノ + 変動費 + 予備費
    • タスクをもれなく列挙するので、粒度が高い。弱点は見積もりにかかる時間と工数設定に主観が入りがちなこと。

見積もりの精度を上げるにはレビューをする。
技術的な観点から
  • 「その実装方法は技術的な要件を満たしているか」
  • 「物理的な制約と矛盾していないか」
などをチェック。
  

長くなってしまったので、残りは別の機会に。

0 件のコメント:

コメントを投稿