ソフトウェア開発及びソフトウェア プロジェクトマネジメント（VI） 北京航空航天大学软件学院 马 平 博士 副教授 maping@buaa.edu.cn

第6回 プロジェクトの立ち上げ 及びスコープ・マネジメント 第6回 　プロジェクトの立ち上げ 及びスコープ・マネジメント 6.1 プロジェクトの立ち上げ 6.1.1　プロジェクトの立ち上げと「プロジェクト計画」　 6.1.2　プロジェクト計画の作成 6.2 スコープ・マネジメント 6.2.1　立ち上げ 6.2.2　スコープ計画 6.2.3　スコープ定義 6.2.4　スコープ検証 6.2.5　スコープ変更管理 6.2.6　システム開発における考慮点

6.1.1 プロジェクトの立ち上げと 「プロジェクト計画」 6.1.1　プロジェクトの立ち上げと 「プロジェクト計画」 「プロジェクト計画」とは？ 「プロジェクト計画書」の内容 「プロジェクト計画書」の更新 「プロジェクト計画」に基づくプロジェクトマネジメント 「プロジェクトの計画」策定作業の大まかな流れ

6.1.1 プロジェクトの立ち上げと 「プロジェクト計画」 （Ⅰ） 6.1.1　プロジェクトの立ち上げと 　　　「プロジェクト計画」　（Ⅰ） 「プロジェクト計画」とは？ 「プロジェクト計画」とは、プロジェクトを立ち上げ、プロジェクトを成功に終了させるまでの作業計画を立案する作業です。 このプロジェクト計画作業の成果物は 　　「プロジェクト計画書」としてまとめられます。

6.1.1 プロジェクトの立ち上げと 「プロジェクト計画」 （Ⅱ） 6.1.1　プロジェクトの立ち上げと 　　　「プロジェクト計画」　（Ⅱ） 「プロジェクト計画」の主な作業 プロジェクトの目的、ゴールの明確化 開発及びプロジェクト・マネジメントの作業の洗い出しと見積もり作業 プロジェクト・メンバーの選出と責任分担 リスク抽出と管理 外注企業の選出と管理方法の計画 構成管理計画 プロジェクトのレビューと承認フローの決定 プロジェクト予算の記述 品質保証計画 開発環境の記述 エンジニアリング・プロセスの選択と記述 各種基準とガイドラインの明記

6.1.1 プロジェクトの立ち上げと 「プロジェクト計画」 （Ⅲ） 6.1.1　プロジェクトの立ち上げと 　　　「プロジェクト計画」　（Ⅲ） プロジェクト計画書の内容 「プロジェクト計画書」とそのほかの計画書 　　　　　　　　　　　　　　　　　プロジェクト計画書 構成管理計画書　　　　　品質保証・管理計画書　　　外注管理計画書　　　リスク管理書 「プロジェクト計画書」の更新 　　　プロジェクト計画書Ver1.0　　　　　　プロジェクト計画書Ver1.1　　　　　プロジェクト計画書Ver2.0

6.1.1 プロジェクトの立ち上げと 「プロジェクト計画」 （Ⅳ） 6.1.1　プロジェクトの立ち上げと 　　　「プロジェクト計画」　（Ⅳ） 「プロジェクト計画書」の変更 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　連絡 　　　　　　　　　　　　　　　　　　　　連絡　　　　　　　　　　　　　連絡 プロジェクト　　　　　プロジェクト　　　　　　プロジェクト 計画書Ver1.0　　　　　計画書Ver1.1　　　計画書Ver2.0

6.1.1 プロジェクトの立ち上げと 「プロジェクト計画」 （Ⅴ） 6.1.1　プロジェクトの立ち上げと 　　　「プロジェクト計画」　（Ⅴ） 「プロジェクト計画」に基づくプロジェクトマネジメント プロジェクトが終了するまでの活動はプロジェクト計画書に沿って進められます。 一方で、プロジェクト計画書に記述されていない作業を実施することも許されません。

6.1.1 「プロジェクトの計画」策定作業の大まかな流れ 6.1.1　「プロジェクトの計画」策定作業の大まかな流れ 見積りを 立てる プロジェクトの作業範囲を明確にする 作業パラメータを決め「見積り方式」を決定する プロジェクトが採用するライフサイクルを決定する 決定した「作業パラメータ」と「見積り方式」から作業工数と費用を見積もる 見積もったデータを基にスケジュールを作成する プロジェクトのリスクを特定し、管理計画を立てる 成果物 リスク管理計画書 プロジェクトの成果物など、データの管理方法を決め、計画を立てる 必要なリソースの計画を立てる 外注管理計画を立てる プロジェクトに必要な知識を検討する プロジェクトの利害関係者を洗い出す 連絡方法の検討と決定 「プロジェクト計画書」の作成 外注管理計画書 プロジェクト計画書 ほかのプロジェクトなど利害関係者のスケジュールを調整する 見積りより立てた計画を状況に合わせて調整、バランスをとる 「プロジェクト計画書」を利害関係者とレビューする。承認されたか？ 　YES / 成果物 「プロジェクト計画書」のリリース NO / 再検討し、再び レビューを行う プロジェクト 計画を立てる 計画のコミットメントを得る 経営用語の基礎知識（第2版） コミットメント　Commitment 達成すべき目標であり、未達成の場合は具体的な形で責任をとるもの。コミットメントのない変革は頓挫する。 　経営トップの掛け声（スローガン的なもの）だけで、大規模な企業変革は可能でしょうか。実際、経営トップの力は必要不可欠ですが、経営トップが上からモノをいうだけでは不十分です。トップの統制力を利かせながらも、社員の自発的な力を束ね、変革に結びつけていくことが、企業変革の成功の鍵ではないでしょうか。 日産の「用語辞典」 　日産自動車には、カルロス・ゴーン社長の指示でつくられた「用語辞典」があるそうです。それは会社再建に欠かせない約40語の定義が社内の情報ネットで共有化されているというものです。従来の日産は、新しい車種を市場に送り出して、それがヒットしなくても、その責任が技術部門にあるのか営業部門にあるのかあいまいで、誰も責任をとろうとしない無責任体質であったといわれています。この辞典は、それを打開し従業員の意識改革を求める策として打ち出されたものなのです。 　日産の「用語辞典」によると、「コミットメント」と「ターゲット」という言葉が使い分けられています。「コミットメント」は達成すべき目標であり、未達成の場合は具体的な形で責任をとるというものです。「ターゲット」とは、コミットする目標よりさらに高い目標を指します。 言葉のあいまい性を排除 　ゴーン氏の改革のねらいは従業員を追いつめることではなく、能力の発掘にあります。大事なことは、日本語に翻訳される過程でその定義をあいまいにすることなく、確実にゴーン氏のポリシーを伝えきるという、その徹底ぶりにあります。 　コミットメントという言葉は訳し方によっては「できる限りのことをする」というあいまいなもので、勝手な解釈も可能なのです。しかし、日産社内での解釈は「未達成の場合は具体的な形で責任をとる」というあいまい性の排除にその取り組みの本気度が表れています。 　つまりコミットメントは、目標と達成責任を明確にすることで、社員の挑戦志向、変革志向を高めようとしているのです。このように、トップの変革への強い意志と、社員の主体的な変革への参画と能力の発揮を促すことが、企業改革の大きな梃子として作用するのです。

6.1.2 プロジェクト計画の作成 プロジェクト計画時における作業とは 詳細な計画作成の手順 見積りを立てる 「プロジェクト計画」を立てる 6.1.2　プロジェクト計画の作成 プロジェクト計画時における作業とは 詳細な計画作成の手順 見積りを立てる 「プロジェクト計画」を立てる 「プロジェクト計画」のレビュー 「プロジェクト計画書」の記載項目

　見積りを立てる プロジェクト作業の範囲を明確にする プロジェクトの属性の選択と見積もり ライフサイクルを計画する 作業工数と費用を算出する

見積りを立てるーー 見積もりの技法の例 見積もりの技法 解 説 COCOMO （Constructive Cost Model） 見積りを立てるーー 　見積もりの技法の例 見積もりの技法 解　　　　　　　　説 COCOMO （Constructive　Cost　Model） ベームが1981年に軍関係のプロジェクトの分析結果に基づいて提案した見積もり手法。ソフトウェア開発の工数や期間を推定するモデル見積もりのためのパラメータとして「開発モード」「開発規模（行数）」「努力係数」を用いる。そのほか、細かなパラメータがある。 COCOMO Ⅱ COCOMOの発展系で、ファンクション・ポイントを利用できるように改良されている。 ファンクション(function)・ポイント 開発する機能に着目し、５つのタイプの「内部論理ファイル」「外部インターフェース」「外部入力」「外部出力」「外部参照」ごとに定義されている計算方法でファンクション・ポイントを計算し、開発の規模を見積もる。他の方法に比べて、経験値や推測が少ないと言われるが、GUIで機能を数え上げられるシステムに特に有利と言われている。 デルファイ(Delphi)法 見積もりを複数の専門化が行う。 PUTNAM プットナムが提唱している。別途「開発規模」と「要員」から「開発コスト」を計算する。「開発途中の費用の流れ」「累積費用」を予測する。 COCOMO ココモ / constructive cost model

プロジェクトメンバー構成図と役割分担 リスク管理計画書 プロジェクト計画」を立てる プロジェクトを明確に 作業のバランスを取る 「プロジェクト計画書」の構成 プロジェクト計画書 プロジェクトメンバー構成図と役割分担　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　リスク管理計画書 トレーニング計画書　　　　　　　　　　　　　　　　　　　　　　　　　　品質保証計画書 外注管理計画　　　　　　　　　　　　　　　　　　構成管理計画

「プロジェクト計画」を立てるーー 「プロジェクト計画書」の記載項目 　「プロジェクト計画」を立てるーー 　　　　　「プロジェクト計画書」の記載項目 プロジェクトの目的やゴールを明確化する 成果物の特定と規模の見積もり

「プロジェクト計画」を立てるーー プロジェクト計画書の内容 「プロジェクト計画書」の内容 ①　プロジェクト憲章（けんしょう） ②　プロジェクトマネジメント・アプローチや戦略記述書 ③　スコープ記述書 ④　WBS ⑤　コスト見積り、作業開始日、遂行部門割付 ⑥　コストとスケジュールの進捗率算出のためのベースライン ⑦　主要マイルストン ⑧　主要スタッフ ⑨　主要リスクと対策案 ⑩　個別のマネジメント計画書 ⑪　未決事項

「プロジェクト計画」を立てるーー プロジェクト憲章に記述する項目 「プロジェクト計画」を立てるーー 　　　　　プロジェクト憲章に記述する項目 ①　プロジェクト名 ②　プロジェクトの背景になるニーズ ③　プロジェクトの最終目的 ④　プロジェクトの成果物 ⑤　プロジェクトの予算 ⑥　プロジェクトの納期 ⑦　プロジェクトが完了する条件 ⑧　プロジェクトメンバーと組織 ⑨　プロジェクト運用のルール ⑩　プロジェクトによる学習

プロジェクト計画」を立てるーー プロジェクト憲章の例 　本プロジェクトを「プロジェクトS」と呼ぶ。 　本プロジェクトは顧客からの直接注文により、顧客のニーズ 　　を吸い上げ、顧客満足度の向上に寄与するために、N社と 　　N社の顧客を結ぶネットワークを構築することである。 　本ネットワークを「ステーショナリネット」と呼ぶ 　……

プロジェクト計画」を立てるーー システム開発における考慮点 プロジェクト計画書作成に際しての要約を、以下に示す。 ①主要な記述項目 プロジェクト概要（プロジェクト名、顧客名／業種、開発期間、概要） プロジェクト定義（目的とゴール、遂行方針、適用範囲、成果物、参考資料） プロジェクト体制（役割と責任、全体組織図、管理プロセス） 作業項目及び見積り 資源（要員計画・機材・設備計画） スケジュール（工程スケジュール） レビュー及び承認 リスクと対応策 ②作成時期 分析フェーズ ③入力情報 要件定義書 ④　責任者 作成責任者：プロジェクトマネージャ 承認者：上位管理社、顧客プロジェクトマネージャ

6.2 スコープ・マネジメント 6.2.1 立ち上げ 6.2.2 スコープ計画 6.2.3 スコープ定義 6.2.4 スコープ検証 6.2 スコープ・マネジメント 6.2.1　立ち上げ 6.2.2　スコープ計画 6.2.3　スコープ定義 6.2.4　スコープ検証 6.2.5　スコープ変更管理 6.2.6　システム開発における考慮点

スコープ・マネジメントのプロセス 立ち上げのプロセス 計画のプロセス コントロールのプロセス スコープマネジメントは次の図に示す ５つのプロセスがある。 　　　　　　　　　　　　　　　 立ち上げのプロセス 　　　　　　　　　　　　　　　　　　　　　　　 計画のプロセス 　　　　　　　　　　　　　　　 計画のプロセス 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　 コントロールのプロセス 　　　　　　　　　　　　　　　 コントロールのプロセス スコープ・マネジメント 立ち上げ スコープ計画 スコープ定義 スコープ検証 スコープ変更管理

1.1 立ち上げ インプット ツールと技法 アウトプット 立ち上げ 1. 成果物記述書 2. 戦略計画 3．プロジェクト選定基準 1.1　立ち上げ 立ち上げ インプット 1.　成果物記述書 2.　戦略計画 3．プロジェクト選定基準 ４．過去の情報 ツールと技法 1.プロジェクト選定手法 ２．専門家の判断 アウトプット １．プロジェクト憲章 2.　プロジェクトマネージャ 　　の選定・任命 ３．制約条件 ４．前提条件

1.1.1 プロジェクト憲章 ① プロジェクト概要 ② ゴールと目的 ③ プロジェクト成果物 ④ ビジネス・ニーズとプロジェクトの必要性 1.1.1　プロジェクト憲章 プロジェクト憲章はプロジェクトの存在を正式に承認する書類であり、ビジネス・ニーズと成果物記述書の内容を含む。また、プロジェクトマネージャの責任と権限を明確化し、プロジェクトマネージャに必要な資源の使用を認める。具体的な記述項目は以下のようなものである。 　　①　プロジェクト概要 　　②　ゴールと目的 　　③　プロジェクト成果物 　　④　ビジネス・ニーズとプロジェクトの必要性 　　⑤　資源とコスト見積もり 　　⑥　プロジェクトマネージャの役割と責任 　　⑦　主要ステークホルダーの役割

1.2 スコープ計画 インプット ツールと技法 アウトプット スコープ計画 1. 成果物記述書 2. プロジェクト憲章 3．制約条件 1.2　スコープ計画 スコープ計画 インプット 1.　成果物記述書 2.　プロジェクト憲章 3．制約条件 ４．前提条件 ツールと技法 1.　成果物分析 ２．収益・費用分析 3.　代替案の識別 ４．専門家の判断 アウトプット １．スコープ記述書 2.　詳細資料 ３．スコープ・マネジメント 　　計画書

1.2.1 スコープ記述書 ① プロジェクトの妥当性（ビジネス上のニーズ） ② 最終成果物（簡単な概要説明） ③ プロジェクトの要素成果物 1.2.1 スコープ記述書 スコープ記述書の明記されるべき事項は、以下のとおりである。 ① プロジェクトの妥当性（ビジネス上のニーズ） ② 最終成果物（簡単な概要説明） ③ プロジェクトの要素成果物 （プロジェクト完成に必要な主要な成果物リスト） ④　プロジェクト目標 （コスト、スケジュール、品質、おのおの(each)に定量的に設定）

1.2.2 スコープ・マネジメント計画書 スコープ・マネジメント計画書は プロジェクト・スコープの管理方法、スコープの変更をプロジェクト遂行に 反映させる方法などを計画化してまとめた文書で、プロジェクト計画書の 一構成要素となる。また、以下の内容を明記する。 ①　プロジェクト・スコープをいかに(how)管理するか、またスコープ変更をいかにプロジェクト遂行に反映させるか。 ②　プロジェクト・スコープの想定される安定度 　　　（程度、頻度、影響） ③ スコープ変更をいかに識別、分類するか。

1.3 スコープ定義 インプット ツールと技法 アウトプット スコープ定義 1. スコープ定義書 2. 制約条件 3．前提条件 1.3　スコープ定義 スコープ定義 インプット 1.　スコープ定義書 2.　制約条件 3．前提条件 ４．他の計画からの 　　アウトプット ５．過去の情報 ツールと技法 1.ワーク・ブレークダウン 　・ストラクチャー（WBS） 　のテンプレート ２．要素分解 アウトプット １．ワーク・ブレークダウン 　・ストラクチャー（WBS） 2.　スコープ記述書更新版 WBS(Work Breakdown Structure): 工作分解结构 Templet：テンプレート, 雛形.

開発プロジェクトに参加した経験のある人でしたら、一度は図のような「線表」というのを目にされたことがあると思います。ガントチャートともいいます。プロジェクトで実施すべき項目とその実施スケジュールをグラフの形で示したもので、いわば、プロジェクトの航海図のようなものです。 　さて、このガントチャートを作るためには、そのプロジェクトでどのような作業があるかを検討して、それぞれがどれだけの作業量なのかを決め、スケジュールを決めなくてはなりません。それを、うまく行う方法としてWBS（Work Breakdown Structure）という手法があります。 　WBSの説明の前に、WBSの元になる「プロジェクトの成果物」という概念を理解しておきましょう。開発プロジェクトの成果物はいうまでもなくソフトウエアです。「SEの仕事（１）」で説明したソフトウエアの定義を思い出してみてください。 　開発プロジェクトの成果物とは、プログラムだけを指すのではなく、プロジェクトで最終的に納入されたものはすべて成果物です。たとえば、取扱説明書や保証書、販促資料、そして保守体制などもすべて成果物に含まれると考えて良いですし、中間的に生成されるドキュメント、テスト結果報告書などもすべて成果物です。まず、これをしっかり、頭に入れておいてください。 ガントチャート Gantt chart / ガント図 / 横線工程表 / 線表 　プロジェクト管理や生産管理などで使われる、作業計画およびスケジュールを横型棒グラフで示した工程管理図のこと。またはその表記法をいう。 　縦軸（行）に作業（タスク、アクティビティ）ないし資源（リソース）を置き、横軸に期間（時間）を取って、各作業／資源の所要期間をそれに比例した長さの横棒で示した図である。 単純なガントチャートの例 　各作業（または資源使用期間）がいつ始まり、いつ終わるのかが一目瞭然であるため、作業担当者にとってスケジュールの把握がしやすい。また作業実績を逐次記入すれば、計画に対する作業実施状況が即座に分かるため、作業管理者にとっても極めて有効な進ちょく管理表となる。 　土木・建築や製造業の工程管理では広く一般に用いられており、横線式工程表、横線工程表と呼ばれる。ITプロジェクトの世界でも利用されており、バーチャート、線表（せんぴょう）ともいう。 　ただし、多数の作業が複雑に入り組んだ工程を計画・管理しようとすると、作業相互の依存関係が分かりづらく、管理の重点ポイントがどこにあるかをつかむことが難しいという欠点がある。また、ある特定の作業の進ちょくが遅れた場合に、それが全体にどのような影響を及ぼすかについて予測することが困難で、実施段階に入ってからの計画変更や状況変化に対して柔軟性に欠ける。 　誰にでも分かりやすいので、PERTなどのネットワーク手法（アルゴリズム）を登載したプロジェクト管理ソフトでも計算結果をスケジュール表示する際に使われる。その場合であれば、ガントチャート画面で行った変更でも依存関係を再計算してスケジュールを表示する。 　ガントチャートという名は、考案者のヘンリー・L・ガント（Henry Laurence Gantt）に由来する。ガントは米国のエンジニアで、フレデリック・W・テイラー（Frederick Winslow Taylor）とともに科学的管理法を研究したメンバーとして知られる。ガントは1903年に「A Graphical Daily Balance in Manufacture」と題する生産工程の順序を図解する方法を考察した論文を発表、1910年代に入るころにはこれを体系的な管理手法に発展させた。 　1917年、第一次世界大戦に参戦することになった米国は、ドイツの無制限潜水艦戦に対抗するために大規模な造船計画に着手した。コンサルタントとしてこれに参加したガントは、自身の管理手法を適用して効果を示し、大統領表彰を受けた。 　ガントの死後、ガントの部下であったウォーレス・クラーク（Wallace Clark）が「The Gantt chart: A working tool of management」（1922年）を出版し、ガントチャートの名と手法を一般に広めた。その後、1931年のフーバーダムの建設、1956年に始まったインターステートハイウェイ網の建設などの大規模プロジェクトにも使用され、古典的管理手法としてその地位を確立することになった。 　ガントチャートは、大まかにタスク・ガントチャートとリソース・ガントチャートに分類できる。前者は棒グラフで作業（タスク）を示したもの、後者はリソースすなわち設備や担当者などの作業割り当て状況、稼働状況を示したものをいう。初期のガントチャートはリソース・ガントチャートだったが、今日ではタスク・ガントチャートが主流である。このほか、マイルストーンを書き込んだ表記法（マイルストーンチャート）、タスク同士の依存関係を示す補助線を加えた表記法など、多くの書き方が派生している。

1.3.1 WBSの例 ① WBSの例 システム開発 プロジェクト 分析 設計 開発 導入 運用 プログラミング マニュアル作成 システムテスト 操作説明書 運用説明書 　　1.3.1　WBSの例

1.3.2 WBSの例 ② EC サイト 構築 A マイルストーン A01 全体設計完了 … B プロジェクトマネジメント C システム D． Webプログラム D.01　画面 D.01.01　設計 D.01.02　製作 D.02　CGI D.02.01　設計 E.　商品データ E.01 自社商品 E.01.01 画像データ E.01.01.01撮影 E.01.01.02データ化 E01.02 商品紹介テキスト E.02　他社商品 F.ハードウェア F.01　PC F.01　調達

1.4 スコープ検証 インプット ツールと技法 アウトプット スコープ検証 1. 作業結果 2. 成果物に関する文書 1.4　スコープ検証 スコープ検証 インプット 1.　作業結果 2.　成果物に関する文書 3．ワーク・ブレークダウン 　・ストラクチャー（WBS） ４．スコープ記述書 ５．プロジェクト計画書 ツールと技法 １．検証 アウトプット １．公式な受け入れ 明确性(Specific)：是指绩效考核要切中特定目标，不能笼统。 衡量性(Measurable)：是指绩效指标是数量化或者行为化的，验证这些绩效指标的数据或者信息是可以获得的。 可接受性(Acceptable)：是指绩效指标在付出努力的情况下是可以实现的。 实际性(Realistic)：是指实实在在的，可以证明和观察。 时限性(Timed)：是指要注重完成绩效指标的特定期限。

1.5 スコープ変更管理 インプット ツールと技法 アウトプット スコープ変更管理 1. ワーク・ブレークダウン ・ストラクチャー（WBS） 1.5　スコープ変更管理 スコープ変更管理 インプット 1.　ワーク・ブレークダウン 　・ストラクチャー（WBS） 2.　実績報告書 3．変更要求 ４．スコープ・マネジメント 　　計画書 ツールと技法 １．スコープ変更管理 　　システム ２．実績測定 ３．追加の計画 アウトプット １．スコープの変更 ２．是正処置 ３．教訓 ４．改訂ベースライン 　　一、部门关健绩效指标（KPI）划分为六个部分，即：人事360度考核KPI、质量考核KPI、成本考核KPI、交期考核KPI、时效考核KPI及5S现场考核KPI，并根据功能别和职位别不同进行分解及赋予不同权重。六个部分的关键绩效指标（KPI）考核的综合积分（即为：部门的整体绩效分），同本部门不同岗位（参照《职阶表》）的考核工资挂钩。同时，部门的整体绩效分还与公司年度整体效益挂勾，根据公司年度效益比值分配不同岗位的年度效益工资。

1.6　システム開発における考慮点 目的とゴール プロジェクト推進方針 適用範囲 成果物 参考資料