このエントリーをはてなブックマークに追加LINEで送る

10.3. 作業の明確化

ハッピィ・エンジニアリング表紙

 プロジェクトで実施すべき作業を明確化するためには、何がプロジェクトに必要な作業なのか、何がプロジェクトに不要な作業なのか、という2つの観点で、作業の洗い出しを行う必要がある。作業内容の洗い出しを行い、プロジェクトにおける作業を定義することを、「プロジェクトスコープの定義」と呼ぶ。

 

 厳密に言えば、プロジェクトに不必要な作業を具体的に洗い出す必要はない。ただし、あらかじめ「プロジェクトに必要な作業」以外のことはすべて「プロジェクトに不必要な作業」であるという認識をしっかりと持っておく必要がある。プロジェクトスコープマネジメントのうえで重要なことは、プロジェクトに必要な作業はなにか、なにが不必要な作業かを明確にし、それをコントロールしていくことである。なぜなら、プロジェクトの一部であるもの、同様に一部でないものを定義できないと、プロジェクトの成果に必要な作業が実施されない結果となったり、あるいは、必要のない余計な作業を実施する結果となったりするからである。必要な作業をしなかった場合も、不必要な作業をした場合も同様に、スケジュールや予算の超過という結果を生む。

 

 さらに、マルチベンダで行うことが一般的なシステム開発プロジェクトの場合、作業を洗い出すことの意味は大きい。受注者は、見積金額の中でどのような作業を行い、何を成果物とするのかを明確にすることができる。また発注者としては、どこまでを作業範囲として、何が納品されるのかを明確にできる。このように、業者間での開発対象や納品に関する契約の齟齬を未然に防ぐことが、プロジェクトを失敗させない重要な要素となる。

 

 プロジェクトスコープを定義するためには、事業戦略や、プロジェクトを開始するまでに検討した資料、さらには、RFP・提案書・発注書・見積もり依頼書・発注仕様書・要件定義書などが必要となる。SIベンダのプロジェクトマネージャであれば、営業担当者へのヒアリングや、過去に同じ顧客や似たようなシステムを担当したプロジェクトマネージャへのヒアリングも重要な情報となる。

 

WBSの作成

 

 プロジェクトスコープの定義にはWBS(Work Breakdown Structure)を利用する。WBSは、プロジェクト全体の作業を、一貫性のある分解基準で詳細化したリストである。各作業項目の記述は「目的語+名詞」として、その作業の実態をわかりやすく簡潔に記述する必要がある。詳細化した最下位レベルの作業を「ワークパッケージ」と呼ぶ。

 

 つまり、すべてのワークパッケージを合計したものが、プロジェクトにおけるすべての作業である。作業をリストアップし、詳細化していくことにより、プロジェクト全体の作業ボリュームを測ることができ、各作業の実施順序を決定できる。つまり、WBSはプロジェクトスコープを定義するために作成した後に、リソース計画、工数の見積もり、スケジュールの作成などに利用するドキュメントとなる。

 

 WBSの作成において重要なことは、トップダウンで作業を詳細化していくことである。ボトムアップで作業を抽出し上位にくくり出す場合、階層レベルがバラバラになり整合性の確認に多くの時間を必要とする。また、ワークパッケージの抜けや重複が発生する結果を生む。

 

 WBSのトップレベルを決める要素には、いくつかのものがあるが、業務システム開発のWBSの場合は、プロセス、あるいは成果物にしておくのが一般的かつ無難である。特にプロセスにした場合は、その下位のレベルは成果物になっているのが望ましい。なぜなら、WBSの最上位を時系列やプロセスにすることは、誰にでも書きやすいというメリットを持つが、その半面で作業の前後関係の検討や、進捗を管理する上で成果物の達成状況がわかりにくくなるなどのデメリットが生まれるからである。

 

 トップレベルを決定したら、どのように作業を詳細化していくかを検討する。WBSは、リスクの洗い出し、資源の割り当て、見積もり、スケジューリング、スコープ管理などに利用するドキュメントとなる。これらの活用手段をふまえ、レベルごとに詳細化の観点を変えてもよい。ただし、あるものはレベル2を機能単位に分割し、ほかのものはレベル2を時系列で分割するような、一意ではない詳細化を行ってはならない。あくまでも各レベルは同一の観点で詳細化しなければならない。成果物名称の下位レベルには、目次の大項目などを利用するのがよいだろう。

 

 どのような観点で詳細化を行った場合にも、資源の割り当て・見積もり・スケジューリングなどのすべてに活用しやすい形式になることはない。一番利用するケースを想定して、どのような観点で詳細化を行うかを決定する必要がある。

 

 作業を詳細化するにあたり、WBSに含める作業と含めない作業を確定しておく必要がある。一般的に、WBSに含める作業は成果物作成に直接関連する作業と、プロジェクトマネジメントを行う上で必須となる作業である。WBSに含めない作業は、プロジェクトマネジメント上の定常的な作業や、WBSの各作業に包括できるような内容の作業である。

 

 成果物作成に直接関連する作業としては、以下のようなものがある。

 

  • アプリケーションの開発作業
  • 基盤構築、導入や支援作業
  • 開発環境の構築

 

 プロジェクトマネジメント上、必須となる作業には、以下のようなものがある。

 

  • レビュー
  • テスト計画
  • プロセスの標準化作業
  • 開発環境の構築
  • 成果物の検収

 

 WBSに含めない作業には以下のようなものがある。

 

  • 定例報告
  • チーム内での非公式なレビューや成果物のチェック

 

 ただし、これらは一般論である。WBSはプロジェクトスコープを明確化し、コスト・スケジュール・リスクなどを管理するうえでの情報となるものであるため、スコープ・コスト・スケジュール・リスクに関わると思われる作業はすべてWBSに含めておいたほうがよい。また、アウトソーシングするような作業は一般的にはWBSに含めないことになっているが、システム開発の場合、顧客作業やほかのベンダの作業、ハードウェアの設置、ネットワークや電源の工事などスケジュールに影響を及ぼす外的な要素が多い。これらもWBSに含め、スケジュール作成時には、各作業の前後関係を明確化していく必要がある。
 完全に詳細化されたWBSを作成する場合は、ワークパッケージはどのレベルまで詳細化すべきかを、あらかじめ決めておく必要がある。ワークパッケージのひとつひとつが数時間の作業だとしたら、管理するうえで不便である。ワークパッケージのひとつひとつが10日間の作業だったとしたら、詳細化が足りない。

 

 作業を詳細化するうえでは、管理したい対象をふまえ、以下の考え方のいずれかを採用するのがよい。

 

  • 「8/80ルール」
  • 「5人日分割」

 

 8/80ルールとは、8時間の作業より小さい単位のものは、ほかの作業と統合すべきであり、80時間を超える作業は、より小さい作業に分割すべきだという指標である。

 

 システム開発では、それぞれのメンバの進捗や生産性を考慮し、5人日程度を想定した作業に分割できれば管理しやすい。5人日はメンバ1人の1週間の作業量であり、スケジュールの作成や進捗の把握などに利用しやすいサイズである。

 

 プロジェクトを管理するうえで適切なサイズに分解されたワークパッケージは、プロジェクトを進めるうえで、以下のような大きな効果を持つ。

 

  • ワークパッケージの進捗を監視することで、プロジェクトの進捗が可視化される
  • ワークパッケージごとに、必要なスキルや要員の数を検討することで、プロジェクト終了までに、どの作業にどれだけのスキルを持つ要員が何名必要かを把握できる
  • ワークパッケージを基準にコミュニケーションを取れば、無駄に多くの人数を集めて会議する必要性が減り、議論の発散を防ぐことができる
  • すべての作業が洗い出されたかを確認することができ、作業の前後関係を検討できる
  • ワークパッケージごとに、作業の難易度・前提条件・想定されるリスクを洗い出すことで、より確実性の高いリスク管理が可能になる

 

WBS辞書の作成

 ワークパッケージには簡潔な名称をつけるのが一般的である。そのため、WBSのみで、その作業内容を明確に定義することはできない。そこで、誤解やあいまいさをなくすために作成するのがWBS辞書である。WBS辞書は、すべての要素に対応した作業詳細を記述する。IDやWBS番号を利用し、個々の要素と詳細項目がきちんと関連付けされるようにしておく。

 

 WBS作成の段階において記述できるものは、インプットとなるドキュメント・リソース・対象成果物など一部に限られる。見積もり・スケジュール作成・リスク管理計画などのプロセスで更新を行い、以下の情報がすべて記載された段階で完成となる。

 

  • WBS要素同士の先行、後続関係
  • その作業のインプットとなるドキュメント、リソース
  • 作業手順、作業の制約条件
  • 作業担当者
  • 管理責任者
  • 承認者
  • 対象成果物
  • 予想されるリスク
  • コスト

 

 当然のことながら、WBS要素に変更が生じた場合、WBS辞書も整合性を失わないように改訂する必要がある。しっかりとしたWBS辞書を作成することで、WBS辞書はそのままSOW(Statement Of Work)として活用可能となる。

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

10.3. 作業の明確化 ハッピィ・エンジニアリング関連ページ

10.1. 段取りなしの現場状況
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
10.2. 段取り八分
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
10.4. ネットワーク図の作成
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
10.5. リソース計画
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
10.6. 見積もり
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
10.7. スケジュールの作成
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
10.8. 進捗管理
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング