2012年12月13日木曜日

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

読書の目的

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


プロジェクト詳細設計(続き)

タイムマネジメント

WBSの最小単位はワークパッケージ。ワークパッケージをさらに細かく作業単位に落し込み、スケジュールを作成する。

アクティビティ

作業単位。 ソフトウェア開発で言えば、「プログラム作成」がワークパッケージで、プログラムを構成する「モジュール作成」がアクティビティに該当する。

アクティビティの依存関係
  1. 強制依存 : 「☓☓が終わらないと、〇〇は開始できない」
  2. 任意依存 : 「この順序で進めると無駄がなく効率的」
  3. 外部依存 : プロジェクトのアクティビティそのものではない

マイルストーン

アクティビティを実行していく過程で訪れる節目。 プロジェクトが目標を達成しているか検証し、必要であれば修正を行うタイミング。
例)「デザイン承認」「システムリリースの見極め」




→ 作業には順序と依存関係がある。 どこの作業で遅延が生じやすいか、遅延が後の工程に響く部分であるかを把握し、プロジェクト進行での時間見積もりの際に共有する。またスケジュールは変更されるので、スケジュールの書式は変更管理を前提にする。


プロジェクト運用

プロジェクトの発足

プロジェクトチーム育成の責任

マネージャはプロジェクト目標を達成するためにチームを特定し、形成し、維持し、動機付けし、リードし、奮起させる。

ソフトスキル = マネージャに要求される人間関係スキル。メンバーについて、その感情を理解し、行動を予測し、関心ごとを認識し課題を追跡することで問題を最小限にし、連携を強化できる。

プロジェクトチームの形成活動

チーム環境を作るうえで最も重要なスキルのひとつは、プロジェクトチームの問題をチームの課題として取り扱い、話し合えること。

プロジェクトマネージャが担う役割
  • トップマネジメントの指示やチームメンバーの積極的な参加を取り付けること
  • 表彰と報酬
  • チームアイデンティティの形成
  • 衝突のマネジメント
  • チームメンバー間の信頼とオープンなコミュニケーション促進

キックオフミーティング

プロジェクトの「これまで」と「現状」を共有し、リスクを検討する。
アジェンダ
  • 自己紹介 : 所属・役割を紹介
  • 制作者の提案・プロジェクトの経緯 
  • 進め方 : タスクが誰から発生し、誰へ引き継がれるか、どの段階で確認をとるか。
  • 想定されるリスク : 主たるリスクは時間不足とコミュニケーション
  • 体制の確認
  • コミュニケーションルール
  • 会議体とその参加者
  • 質疑応答
  • 次のアクションについて : とりかかること、調べて再度連絡すること

変更管理シート

「手を動かす」段階になると、考慮漏れが表面化する。
規模が小さなプロジェクトや突貫工事のようなプロジェクトでは、トラブル発生時など「いざ」というときに経緯を失念していることがあるので、品質管理はデータ化する。

参照性の高いドキュメントフォーマット

政策の前提が書かれた資料はプロジェクトにおいて頻繁に流用・転用される。
適切なファイル命名規則を定めておくことでファイルの数が増えても管理ができる。

→ エンジニアはマネージャの意図を汲み、コミュニケーションにおいてはプロジェクト目標の達成を第一に考える。口を開く前に、その情報が「チームの課題を解決できる」、「チーム間の信頼向上につながる」など、チームにとって役に立つかという判断基準でチェックし、適切に発言する。個人的な感情は抑え、チームメンバーとして求められる振る舞いを意識する。

制作ディレククションとプロジェクトマネジメント

品質 = 「本来備わっている特性がひとつにまとまって、その結果、どの程度要求事項を満たしているかの度合い」。欠陥のなさ、扱いやすいさ。 機能数などは「等級」であり、品質とイメージは似ているが、意味は同一ではない。


マネージャはプロジェクトの品質と成果物の品質を監視・管理する

→ 成果物が納期に間に合うだけでなく、そのプロジェクト自体がどう進んだかもマネージャの関心事項。 エンジニアは状態が芳しくないときこそ、遠慮無くマネージャへ報告・連絡・相談する。

計画の変更とその手順

変更 = 要件定義の段階で定めた成果物かスコープが代わること。

多くのWeb制作プロジェクトは期間が短い。 見積もりに割ける時間が短く、「やりながらわかる」ことが多い。完全にプロジェクト計画通りになるプロジェクトはない。重要なのは変更の必要が生じたとき、マネージャが誰かのスキルやリソースの「せい」にしないこと。

変更の種類
  • 成果物 (数量)
  • スコープ (仕様、メンバー、予算、期日、ToDo)
  • 変更計画および変更の手順
  • 変更管理の対象 
  • 担当者
  • 連絡体制
  • 見直しの頻度
  • 会議体

→ エンジニアはプロジェクトの変更は不可避であることを理解し、変更が必要になるときに変更内容となぜその変更が必要なのかをマネージャへ伝える。

制作フェーズにおけるヒトのマネジメント

マネージャはプロジェクト実行フェーズでは
  • プロジェクトチーム育成およびトレーニング
  • 経営企画、人事、財務おいった機能部門との調整
  • コンフリクトの解決
をおこなう。


コンフリクトのパターン
  • プロジェクトチームのメンバー同士
  • メンバーとプロジェクトマネージャ
  • 制作者と外部パートナー
  • 制作者と発注者
  • 制作者と発注者側のステークホルダー
  • 発注者と発注者側のステークホルダー

コロケーション  = チームとしての実行能力を高めるために、プロジェクト、チーム、メンバーの大部分または全員を同じ場所に集めて仕事にあたること。 面と向かって速やかに問題解決を行えることがメリット。

スキルとパフォーマンスの見極め

「スキル」と「パフォーマンス」、「モチベーション」はプロジェクトの進行によっへのどうするため、マネージャはメンバーのアサインが妥当であるか、常に確認する。 

スキルとパフォーマンスを混同しないこと。
スキル = 技量。
パフォーマンス = 性能、成績。

スケジュールにしわ寄せが着て、あるメンバーにタスクが集中した場合、そのメンバーのパフォーマンスは落ちる。


チェックイン = 近況や心境をフリートークで話す。メンバーの様子を把握するファシリテーション技術のひとつ。 

対立の芽を摘む

Webサイト制作が分業制で、全体のスコープや進捗を把握できるメンバーが限られている以上、すべてのメンバーにすべての情報が与えられているとは限らない。

マネージャはスケジュールと優先度を睨みつつ、対立の芽を先見的に摘んでいく。

→ マネージャは士気をあげようといろいろな施策を打つ。 エンジニアはその施策が何を目的としているのか、意図を理解し、妨げないようにする。


制作フェーズにおけるコミュニケーションのマネジメント

コミュニケーションモデルとノイズ

コミュニケーションの要素
  • 発信者
  • 受信者
  • メッセージ
コミュニケーションの手順
  1. エンコード :発信者は伝えたい事柄を、伝達可能なメッセージに変換する
  2. 伝達 : メッセージをメディアを介して受信者に届ける
  3. デコード : 受信者は発信者からのメッセージを、読み取り、理解する。
伝達やデコードの段階で「ノイズ」が入り、受信者の理解が妨げられる場合がある。

ノイズ
  • 発信者と受信者の距離
  • 文化や経験などバックグラウンドの違い
  • 受信者の気分

ステークホルダーの期待のマネジメント

  • プロジェクトの便益とリスクを明確に理解してもらい、適切な支援を得る
  • プロジェクトの成果物の受け入れ(承認や検収)の可能性を高める
  • 潜在的なリスク、懸案事項を早期に発見し、対処する


制作ディレクションは、ひとつひとつの判断や確認を短時間で済ませることの連続で、非常に負荷が高い。しかも、プロジェクトマネージャは、メンバーの誰もが追い込まれている状況でコンタクトを取る。

プロジェクトマネジメントにおけるコミュニケーションスキル = 主観なき情報伝達の交通整理

コミュニケーションは「無駄を省く」観点で見直す。 

→ エンジニアは「チームメンバーが理解できる表現」を心がける。 客観的に、誤解をまねかない平易な言葉で。 専門用語、カタカナ語は極力使わない。同じものに対して、2つ以上の呼称を混在させない。

制作フェーズにおける品質保証とテスト


品質管理 = 品質の基準と計画を取り決め、実施すること。

「発注者が喜ぶと思ってデザインに磨きをかけた」、「とりあえず形にした/とにかく納期に間に合わせるためやっつけた」などの対処的行動は、PMBOK本来の「品質」の基準と関係がない。納品物に求めれるのは「取り決めた品質の基準に適合しているか」。


品質管理計画と立てるとリスクを発見したり、成果物をチェックしているときにバグが見つかって納期を圧迫するなど、品質管理とリスクマネジメントは密接な関係。

Web制作におけるリスクマネジメント手法

前提条件のテスト:定性的なリスク分析。WBSやファイルリストから、「たられば」で状況を想定して、対処方法を検討する。

コンティジェンシー計画:「不測の事態」(=コンティジェンシー)が発生したさいにどのように対処するかを前もって決めておく。この計画がうまくいかなければ、さらに代案を検討する。

品質管理の観点

よいプロジェクトは 「発注者のニーズに応える」と「納品品質を満たしている」が均衡する。 発注者は人であり、満足度は感覚的・定性的。 納品物はソフトやモノであり、数値的・定量的である。

品質チェックのフロー
制作 → 内部チェック → 発注者確認 → 修正 → 発注者承認 → 確定

チェックの留意事項
  • 計画することが目的化していないか
  • チェック者が「やっつけ」「流れ作業」に陥る手段やプロセスになっていないか
  • チェック結果は後に取りこぼしを生まぬよう、整理されているか
テスト計画で決めること
  • テストの種別と目的
  • テスト手法とタスク
  • テスト要員

チェック = 中間生成物に瑕疵がないか、要件に適っているか。
テスト = 要件を満たしているか、バグなく稼働するか。
発注者レビュー = チェックやテストとは別個で発注者に依頼し、承認を得る


チェックは「他人の間違いをあげつらう」のではなく、「検収をするまでのプロセスを残す、責任をもって制作し品質管理を実施したという根拠を残す」。

→ エンジニアとしては品質の数量化・定量化を行い、品質が確認できるようにする。  
人力によるチェックを計画する際はチェック実施時の「めんどくささ」を考慮し、「やっつけ」を防ぐ。ソフトウェアモジュールなら単体テストがGREENになった件数などで定量的に品質が評価でき、自動化も可能。


読み終えて

品質に対する考え方、士気に対する考え方は改める必要性を強く感じた。
凝り性を抑えて実装する方法、コミュ障が士気を下げないようにする方法など、自分用の指針は別途考えないといけない。



0 件のコメント:

コメントを投稿