プロジェクト管理の概要 開発工程を見積もる方法 成果物やプロセスの品質を評価する方法
プロジェクト管理
https://www.sss.fukushima-u.ac.jp/~kami/Lecture/SD/
１．プロジェクトの計画と管理
• プロジェクト管理とは – 要求を満たすソフトウェアを顧客に決められた期 間で納品するために，ソフトウェア開発において， 誰がどの段階で何をすればよいのかを計画する 作業 • プロジェクト管理の目的 – 遂行に関わる経営諸資源（人，物，金，技術，情 報）を最も効果的に使用し，「費用」「時間」「品質」 の統合化を計りつつ，プロジェクトの目標を達成 すること1.1 プロジェクト計画
• プロジェクト計画において検討すべき項目 1. 開発目的 2. 開発目標 3. 開発対象業務及び運用方針 4. 開発システムの基本構成 5. 開発工数 6. 開発スケジュール 7. 開発体制 8. 開発環境や開発方法 9. 成果物の管理方法 10.リスクの管理方法（6） 開発スケジュールで用いられる手法
– 作業明細構造 ： プロジェクトで実行される作業
（アクティビティ）を分割，詳細化して記述したもの
– ガントチャート：各アクティビティを並列に記述し，
ネット販売システムの構築 システム計画（1.0） 仕様の検討（1.1） 設計（2.0） 実装（3.0） 予算の検討（1.2） スケジュールの検討（1.3） 計画の立案（1.4） 最上位レベルの設計（2.1） プロトタイプの作成（2.2） UI設計（2.3） 詳細設計（2.4） コーディング（3.1） ■ 作業明細構造の例
作業内容 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 ‥ システ ム計画 1.1 仕様の検討 （仕様の承認） 1.2 予算の検討 （予算の承認） 1.3 スケジュール の検討 （スケジュールの承認） 1.4 計画の立案 （計画の承認） 設計 2.1 最上位レベ ルの設計 2.2 プロトタイプ の作成 2.3 UI設計 2.4 詳細設計 （設計の承認） 実装 3.1 コーディング ■ ガントチャートの例 ※最後に演習 本日 完了タスク 予定タスク マイルストーン：特定のアクティビティの終了時点
（8） 開発環境や開発方法 ：ハードウェア環境 文書を作成・閲覧するコンピュータ，プログラミ ングを行うコンピュータ，テストに使用するコン ピュータ ：ソフトウェア環境 OS，プログラミング言語，コンパイラ，種々の開 発ツール，コミュニケーションのためのツール ：方法論，コーディング規約，テストの方針 （10） リスクの管理方法 リスク衝撃（リスクにより引き起こされる損失），リ スク確率，リスク制御（リスクの影響を最小限に回避）
1.2 開発工程の見積もり
• プロジェクトの規模を見積もる代表的な方法 1. 経験に基づく方法
2. LOC法
– 生成するソースコードの行数（Lines of source code） をもとに開発規模を見積もる方法 3. ファンクションポイント法 • 開発にかかる工数を見積もる代表的な方法 1. 経験に基づく方法 2. 標準タスク法 3. COCOMO 4. COCOMO II
ファンクションポイント法（FP法）
• アルブレヒト（Allan J. Albrecht） • ソフトウェアに含まれる機能の数（ファンクショ ンポイント）により，ソフトウェアの規模を算出 する方法 • ソフトウェアの内部でどのような処理が行わ れているか（行われる予定か）を分析し，５つ の機能に分類 （1） 外部入力（external input：EI） – 外部からソフトウェアへの入力 （2） 外部出力（external output：EO） – ソフトウェアから外部への出力（3） 外部照会（external inquiries：EQ）
– 外部からソフトウェアへの照会
（4） 内部論理ファイル（internal logical files：ILF）
– ソフトウェア内部に存在するファイルの規模
（5） 外部インタフェースファイル（external interface
file：EIF）
– 他のシステムで管理され，ソフトウェアが参照する ファイルの規模
11 利用者 開発ソフトウェア 内部論理ファイル ILF システム外部 ELF EI EO EQ 関連 ファイル 数 でデータ項目数 1～4 5～15 15～ 0～1 単純 単純 普通 2 単純 普通 複雑 3～ 普通 複雑 複雑 関連 ファイル 数 でデータ項目数 1～4 5～15 15～ 0～1 単純 単純 普通 2 単純 普通 複雑 3～ 普通 複雑 複雑 関連 ファイル 数 でデータ項目数 1～4 5～15 15～ 0～1 単純 単純 普通 2 単純 普通 複雑
EIの複雑度 ILF, ELFの複雑度
EO, EQの複雑度 ■ ファンクションポイント法における機能分類と複雑度に関するマトリックス EI:外部入力（入力画面など） EO:外部出力（集計や分析、フォーマッティングを行った 出力画面，帳票出力画面） EQ:外部照会（インプットとアウトプットがそのまま同じよ うな単純な入力・出力機能。単票の入力画面など） ILF:内部論理ファイル（データベース） EIF:外部インタフェースファイル（オンライン処理など）
複雑度 機能 単純 普通 複雑 EI 10 9 15 EO 14 12 14 EQ 2 4 7 ILF 3 3 6 EIF 4 5 5 複雑度 機能 単純 普通 複雑 EI ×3 ×4 ×6 EO ×4 ×5 ×7 EQ ×3 ×4 ×6 ILF ×7 ×10 ×15 EIF ×5 ×7 ×10 複雑度 機能 単純 普通 複雑 EI 10×3 9×4 15×6 EO 14×4 12×5 14×7 EQ 2×3 4×4 7×6 ILF 3×7 3×10 6×15 EIF 4×5 5×7 5×10 ■ ファンクションポイントの算出 ＝680 （未調整FP） （a） 複雑度別の機能数 （b） 重み付け係数 （c） ファンクションポイント EI:外部入力 EO:外部出力 EQ:外部照会 ILF:内部論理ファイル EIF:外部インタフェース ファイル
• 最終的なファンクションポイントを算出する際に は，ソフトウェアの特性に応じて得点を割り当て， 調整用係数を算出する必要がある • ソフトウェアの特性を評価する項目は，全部で14 項目（データ通信，分散処理，パフォーマンス， など） • 各項目に対して，6段階で得点を付ける – ０：まったく関係ない – １：ほとんど影響を受けない – ２：適度に影響を受ける – ３：平均的な影響を受ける – ４：大きな影響を受ける – ５：非常に大きな影響を受ける
• ソフトウェアの特性に関する合計得点をPとすると • 調整用係数 C = 0.65 + ( 0.01 × 合計得点P ) • P の最大値は70(5点×14項目) • 調整後のファンクションポイントは FP ＝ （調整用係数 C ）×（未調整ファンクショ ンポイント ） 調整用係数の範囲：0.65～1.35 例） P=28 のとき C = 0.93 最終的なファンクションポイント FP = 0.93 × 680 = 632.4
• オブジェクトポイント法 – 自然言語（4GL）に類するものにはFP法に代えて 利用可能 １）各オブジェクトの複雑度を重みづけ ２）上記を合計 ３）NOP = OP × （ 1 － 再利用比率 ） ４）環境要因、PRG生産性の逆数をかけて、工 数を求める
• ソフトウェア開発に必要とされる作業（標準タス ク）ごとに開発工数をあらかじめ設定し，そのうえ で，実際のソフトウェア開発に現れる作業を予測 して，それらに応じて工数を積み上げていく算出 方法
標準タスク法
複雑度 規模 単純 普通 複雑 小 1 2 3 中 1.5 3 5 大 2 4 7 複雑度 規模 単純 普通 複雑 小 1×10 2×5 3×0 中 1.5×10 3×30 5×5 大 2×0 4×10 7×10 複雑度 規模 単純 普通 複雑 小 10 5 0 中 10 30 5 大 0 10 10 ■ 標準タスク法による工数見積もりの例
（a） 標準タスクAの作業工数 （b） プロジェクトXにおける標準タスクAの件数
（c） プロジェクトXにおける標準タスクAの工数 標準タスクAの総工数 ＝260 プロジェクトXの総工数 ＝標準タスクAの総工数 + 標準タスクBの総工数 + … …
開発 規模 （LOC） 開発 工数 COCOMO変換モデル 基本COCOMO 中間COCOMO 詳細COCOMO
{
組織モード：小規模開発で小規模なチームによる 組込みモード：大規模で複雑な開発を多人数で行う 半組込みモード：組織モードと組込みモードの中間的 な開発{
COCOMO
• Constructive Cost Model
• ソフトウェアの開発規模と開発工数の関係を統
計的なモデルから推測する技法
• 開発ソフトウェアの規模を，コメントを除いたソー
（1） 基本COCOMO – 開発の初期段階で使い，主としてLOCだけで見積 もる。 （2） 中間COCOMO – 要求定義が完了した後で使い，構成要素ごとに 影響要因を考慮して見積もる。 （3） 詳細COCOMO – 設計が終了した後で使い，システム・サブシステ ム・モジュールの３分割に対して影響要因を考慮 して見積もる。
• COCOMOで用意されている３つのモード （1） 組織モード – 少人数で行う単純で小規模な開発の場合のモード。 開発自体を自社で行っている場合に相当。 （2） 組み込みモード – 複雑で大規模，あるいは，厳しい制約をもつ開発の 場合。 （3） 半組み込みモード – 一般的な業務処理ソフトウェアの開発などの場合の モード。 • 最終的な開発工数は，人月値（１人が1カ月の間 にソフトウェア開発に費やす時間）
COCOMO II
• 開発工程の早期にソースコードの行数を知ることは困 難 → COCOMO II• 3
つのモデルを用いて開発工程を見積もる （1） アプリケーション組み立てモデル – GUIビルダーやコンポーネントを用いたプロトタイプ開発に おいて，オブジェクトポイントの観点からソフトウェアの規 模を見積もるモデル。 （2） 初期設計モデル – ファンクションポイント法を用いて，機能数から規模 を測定するモデル （3） ポストアーキテクチャモデル – 外部設計によりシステム構造が定義された後に， ファンクションポイント法やソースコードの行数によ り開発工数を算出するモデル２．プロジェクト管理の知識体系
従来のプロジェクト管理 QCD quality：品質 cost：コスト delivety：納期 PMI（米国プロジェクト管理協会） PMBOK（プロジェク ト知識管理体系） プロセス群を５つの グループに分類 日本国内のガイドライン ： SLCP-JCF98 ： ６つの主プロセス，８つの支援プロセス， ４つの組織 に関するプロセス，システム監査プロセス，修正プロセス + ＫＫＤ（勘と経験と度胸）視 点 内 容 総合管理 プロジェクト計画の策定，実施，変更管理 スコープ管理 スコープ（プロジェクトで実施される作業やプロジェクトで生 成される成果物）に関する定義，検証，変更管理 時間管理 スケジュールの作成，作業順序の決定，所要時間の見積 もり，進捗管理 コスト管理 資源計画，コストの見積もりと予算化 品質管理 品質（信頼性，使用性，保守性など）の評価と保証 人的資源（人 材）管理 プロジェクトチームの組織構成，開発要員の調達，チーム 編成や育成 コミュニケー ション管理 情報の共有化，コミュニケーションの確立，実績報告 リスク管理 リスクの洗い出し，リスクの定量化，リスク対策 調達管理 機器の調達，発注先の選定，契約 PMBOKの９つの視点（知識エリア：管理すべき対象領域）
アーンドバリュー（Earned Value）分析 • コスト，資源，生産性を管理するために有効なツール • アーンドバリュー： 成果物の達成度を金額に換算した出来高 のこと • 出来高（完了した作業の予算コスト），実コスト、計画を比較し て，パフォーマンスを測定する。 • 実コスト(AC:Actual Cost) – 実際に費やした作業コストのこと。 – 作業実行者のコスト単価と要した時間で求めることができる。 • コスト差異(CV:Cost Variance) – ある時点における計画コスト値と実績コスト値の差のこと。 – アーンド・バリュー(EV)から実コスト(AC)を引いた値がコスト差異(CV)と なる。 – CV ＝ EV － AC – 値が 0 であれば計画通りであることを示す。正の値なら計画を下回っ ていることを示して、負の値だと計画コストを超過していることになる。
• スケジュール差異(SV:Schedule Variance)
– ある時点における計画スケジュール値と実績進捗値の差のこと。 – SV ＝ EV － PV
– 値が 0 であれば計画通りであることを示す。正の値なら計画を前倒し していることを示して、負の値だと計画から遅れていることになる。
• コスト効率指数(CPI:Cost Performance Index)
– プロジェクトのパフォーマンスを計測する指標で、計画時の予算を ベースにコストの効率を測る。 – 計画予算から計測時点で超過しているのか下回っているのか、また 何パーセント乖離しているかを知ることができる。 – CPI ＝ EV / AC – CPIが1.0未満のときにはコスト超過を示し、1.0を上回っている場合に は見積りコストを下回っていることを示す。
• スケジュール効率指数(SPI:Schedule Performance Index)
– プロジェクトのパフォーマンスを計測する指標で、計画時の予算を ベースにスケジュールの効率を測る。 – 計画スケジュールから計測時点で超過しているのか下回っているの か、また何パーセント乖離しているかを知ることができる。 – SPI ＝ EV / PV – SPIが1.0未満のときにはスケジュールが遅れていることを示し、1.0を 上回っている場合には計画より前倒しに進んでいることを示す。
• 完成時総コスト見積り(EAC:Estimate at Completion) – ある時点で、その作業が全て完了した際の総コストを予 想した値 – EAC を求めるには3種類の方法がある。 • 差異を反映した EAC 現在生じている計画と実績の差異が今後も継続すると判断した 場合に用いられる。 つまり、現時点で計測したコスト効率(CPI)が、今後も変化せずに 継続すると判断できる場合にこの方法を採用する。
EAC ＝ AC ＋ (BAC － EV) / CPI ＝ BAC / CPI • 偶発差異を織り込んだ EAC 現在の計画と実績の差異が特殊なもので今後同様の差異は生じ ないだろうと判断した場合に用いられる。 つまり、以降は計画時に設定したコスト効率で作業が進められる と判断できるときは、これらの方法を使用する。
EAC ＝ AC ＋ (BAC － EV) • 前提条件に誤りがある場合の EAC これはつまり、見積もり直す必要があるということで、それまでの 実績値では求めることはできない。 再見積もりした残作業見積もり（ETC）を現在の実コストに足すこと で、EAC の値になる。 EAC ＝ AC ＋ ETC
• 残作業のコスト見積り(ETC:Estimate to Complete) – ある時点で、終わっていない作業量をコスト的に定量化した値のこと。 – ETC ＝ EAC － AC • 完成時総予算(BAC:Budget at Completion) – 作業が完了した時点のPVの値のこと。 – 作業が完了した時点のEVの値でも同じ。 つまり、その作業が完了するのに必要だと見積もった計画値のこと。
BAC
PC EV EAC
EVMの計算例 • 計画： a.完了予定予算 BAC = 1000万円 b.予定工期 5ヶ月 • 現時点の測定値： c.測定時の計画価値（予算） PV = 300万円 d.アーンド・バリュー EV = 240万円 実コスト AC = 400万円 • 現状把握： e.コスト差異 CV = EV－AC = 240－400 = －160万円（160万円のコスト超過） f.スケジュール差異 SV = EV－PV = 240－300 = －60万円（60万円分のスケジュール遅延） g.コスト効率指数 CPI = EV／AC = 240／400 = 0.6（予定より40%コスト超過） ＊予算消費実績（400万円）に対して60%の価値しか生み出していない。 h.スケジュール効率指数 SPI = EV／PV = 240／300 = 0.8（予定より20%スケジュール遅延） ＊スケジュールは予定に対して 80% しか進んでいない。 • 完了時予測： i.今後発生するコスト予測 ETC =（BAC－EV）／CPI =（1000－240）／0.6 ≒ 1267万円（但し今後も同様の傾向が続くと仮定） j.完了時総コスト予測 EAC = AC + ETC = 400 + 1267 = 1667万円（667万円のコスト超過） k.予測工期 完了予測後期 = 予定工期／SPI = 5／0.8 = 6.25ヶ月（1.25ヶ月の工期超過）
例） 製造コスト10万円の製品を10個作るプロジェクト
• 基本パラメータ
– 完成時総予算（BAC：Budget at Completion）
• 完成時総予算
• アーンド・バリュー（EV：Earned Value） – 出来高。 – 完了した作業に対する予算コスト – 予算上100万円分のコストの作業を完了したら、 EVは100万円。 – ※たとえ実際のコストが1000万円であっても1万 円であっても。
• プランド・バリュー（PV:Planed Value） – ある時点で、完成する予定の作業に対する予算 コスト – 4月1日に100万円分の予算の作業が完了する計 画になっていたら、その時点のPVは100万円。 – 実際は計画からすごく遅れているかもしれないけ ど、「計画上は、現時点で100万円分の作業が完 了したはずだよね」というのがPV。
• 実コスト（AC:Actual Cost）
– ある時点までの作業によって発生した「実際のコ スト」。
– 5月1日時点で合計1億円のコストが出ていたら、5 月1日時点のACは1億円。
パフォーマンスを測定する指標
• スケジュール差異（SV：Schedule Valiance） – SV = EV - PV （出来高から計画を引いたもの） – プラスならば作業先行(OK)、マイナスなら遅延 (NG)。 – SVが1万円なら、1万円分の作業が進んでいる。 – SVがマイナス1万円なら、1万円分の作業が遅れ ている。• コスト差異（CV:Cost Valiance） – CV = EV － AC （出来高から実際のコストを引い たもの） – プラスならコスト内（OK）、マイナスならコスト超過 （NG） – CVが1万円なら、予定より1万円少ないコストで済 んでいる。 – CVがマイナス1万円なら、予定より1万円のコスト 超過。
• スケジュール効率指数（SPI：Schedule Performance Index） – CPI = EV / AC （出来高と実コストの比） – 1より大きい場合はコスト効率が良い(OK) （出来高＞ 実コスト） – 1より小さい場合はコスト効率が悪い(NG) （出来高＜ 実コスト） – CPI = 1.1 ならば、1.1のコストがかかる作業を、1のコ ストで終わらせた。 – CPI = 0.9 ならば、0.9のコストがかかる作業に、1のコ ストを使ってしまっている。
• 残作業のコスト見積り（ETC：Estimate To
Complete）
– ETC=（BAC－EV）÷CPI ※現在のCPIが今後も続く 場合のモデル
• 完成時総コスト見積り（EAC：Estimate At Completion） – EAC = AC＋ETC • 完了時コスト差異 （VAC：Variance At Completion） – VAC = BAC－EAC
• 残作業効率指数（TCPI ：To-Complete-Performance-Index） • TCPI＝（BAC―EV）／（BAC―AC） もしくは （BAC―EV）／（EAC―AC） ※計画を当初予算を変えない場合と、目標予 算を変更した場合 • 計画予算内に収めるために必要となるコスト 効率
PMBOK における５つのプロセス群 （1） 立ち上げプロセス ： プロジェクトまたはプロジェクトのフェーズを定義し，認可 する （2） 計画プロセス ： プロジェクトの目標を定め，それを洗練する。さらに，目 標とスコープを達成するために必要な一連の活動を計画 する。資源（予算，人，機器など）の調達も行う。 （3） 遂行プロセス ： プロジェクト計画を実施する。スコープの検証や品質の 保証も行う。 （4） 制御プロセス ： プロジェクト計画との差異を認識するために，実績報告 や進捗の測定を行う。変更管理やリスク対応も行う。 （5） 終結プロセス ： 契約の完了手続き行い，プロジェクトを終了する。
３．プロセス評価モデル
• ソフトウェアプロセス改善のサイクル1. プロセスの計測 2. プロセスの分析 3. プロセスの変更
CMMI (CMM Integration)
• CMM(Capability Maturity Model)：SEI(Software Engineering Institute) が，1980 年代半ばに構築した，ソフトウェアプロセスの 成熟度に関するモデル
• CMMI (CMM Integration)：他の領域にも提供 できるように，類似したモデルを統合したモデ ル
レベル５ 最適化 レベル４ 管理化 レベル３ 既定義 レベル２ 反復可能 レベル１ 初期 •プロセスが未定義である•成功は偶然か個人の能力で決まる プロセスの抑制 プロセス改善 定量的管理 プロセスの定義 •基本的な管理プロセスが存在する •過去に成功したプロセスを繰り返せる •定量的な分析のフィードバックにより 継続的にプロセスを改善できる •プロセスとプロダクトの定量的データを収集している •データ分析とデータに基づく管理ができる •プロセスが文書化，標準化されている •すべてのプロジェクトで標準プロセスを 利用している
SW-CMMにおける成熟度
４．プロジェクト管理におけるヒューマ
ンファクター
• ピープルウェア – コンピュータに関係する構成要素の考え方で，ハード ウェアとソフトウェアと対比して人間的要因を表した 用語 • ブルックスの法則 – 「遅れているソフトウェアプロジェクトへの要員追加は さらに遅らせるだけ」 • デスマーチ – 長時間の作業といった作業環境悪い状況で，成功の 可能性が低いプロジェクトに参加させられている状況 を説明する言葉ガントチャート
とは
• プロジェクト管理や生産管理などあらゆる管理工程に使う 表。横棒グラフを使用し完了日などを管理する。 「スケ ジュール表」「管理表」などと呼ぶ組織もある • 何かの作業を進めていく「段取り」を項目別にまとめた表。 • 「全体の計画を見える化し、パッと見ただけでおおむね全 体像をつかめる」 • 「ツリー構造」と「チャート（横棒）」で表す。 • 左側のツリー構造部分には、「管理するタスク名」「完了日 などの日付のデータ」「担当者」などの項目を列挙 • 右側のチャートには、開始日と完了（予定）日＋αを表記。 横軸の単位は、「日」「週」「期」「年」など、プロジェクトの長 さによってスケールを変えて表記。ガントチャートに使う項目の例
• やること（管理項目名） • 開始日、完了（予定）日 • 作業内容 • 担当者 • 作業間の関連 • マイルストーン例）
• あなたは「料理の素人3人のチームで、イタリ アンのランチを、ランチタイム内に提供する」 というプロジェクトのマネジャーになりました。 • 「やるべきこと」を列挙し、上司に「報・連・相」 しながら、期日まで（時間内）に料理を出さな ければならないプロジェクトの３つの
「決まっていること」
• 目的が定まっている → イタリアンのランチを提供する • 期限が決まっている → 11～14時のランチタイム内 • 使える資源が決まっている →メンバー「3人」、コンロ「2つ」、まな板「1 枚」プロジェクトを管理するために必要なこと
1. やるべきタスクを洗い出す（網羅されている こと） 2. 上司や先輩に「本当にこのやり方で良いの か」事前にチェックしてもらう 3. タスクを分類する（管理しやすいようにまとめ る） 4. タスクにメンバーをアサインする（責任の所 在をはっきりさせる） 5. おのおののタスクに「開始日」と「完了日」を 設定する（そのうちはNG）おそらくこれは 細かすぎ
ガントチャートの「タタキ」ができ，「ピザの生地作り」「ピザの盛り 付け→焼き」「サイドメニュー（サラダとスープ）の作成」という3つ の大きな流れが分かる
まとめ ガントチャート作成時の注意点
• タスクの粒度は細か過ぎず、荒過ぎず。項目 を眺めただけで全体像がイメージできる程度 を目安にする。 • 作業日程の割り振りは、最初からムリな計画 を立てない。• タスク – 管理項目の最小単位。「開始日」「完了予定日」 が定義されている。 • タスクグループ – 複数のタスクを束ねたもの。 – イタリアンランチプロジェクトでは、「ピザを作る」と いうタスクグループの中に「生地作り」「ソースを 作る」「焼く」「仕上げ」という4つのタスクが入って いる。複雑なチャートになると、この階層が複数 に何重にもなる。 • リンク – タスクの依存関係。「タスクAで作成した成果物を 用いて、タスクBを作成する」などがある。
• ステータス – タスクの状況を表すもの。「着手前」「着手」「順調」 「遅れ」「完了」などが代表的なステータス。 • アウトプット – 成果物。プロジェクトやタスクグループ、ステータスご とに成果物がある。道路工事プロジェクトでれば、開 始時、途中、完了後に提出する写真などが成果物に 当たる。 • マイルストーン – 進捗（しんちょく）を管理するために、途中に設定して いる目印。もともとは高速道路などで距離を表す標 識の意味。最終的なゴールへの重要な途中経過と考 えるとよい。 – 製品開発プロジェクトであれば「リリース会議」や「試 作品の判定会」などが設定される。
• リソース – 管理する（される）項目。分かりやすいのは「人」。 「お金」であったり「設備」であったり「資材」であっ たりもする。「リソース管理」という言葉も使われる。 • クリティカルパス – プロジェクト全体に関わる重要なタスク郡。イタリ アンランチプロジェクトであれば、「ピザ作成」の 「生地作り」の辺り。ここがコケると「ピザのないイ タリアンランチ」になりかねない。 – ガントチャートでプロジェクトを管理する肝は、「ク リティカルパス」を見える化し、全体のスケジュー ルが遅れないようにすることと言っても過言では ない。
Excelでガントチャート作成
1 タスクを洗い出す
• 料理名「ピッツァ」「スープ」「サラダ」の三つが 大項目 • 大項目の下に中項目として料理の工程を設 定。大項目「ピッツァ」の中項目は、「生地作 り」「ソースを作る」「焼く」「仕上げ」の四つ。 • その後、洗い出したタスクを中項目にひも付 ける。例えば、タスク「生地をこねる」「生地を 伸ばす」は中項目「生地作り」にひも付く。
3 Excelにタスクと日付を記入する
• ExcelのA列に、タスクをグループごとに記入す る。 • インデントを操作して、タスクの階層を「見える 化」する • 行1に「月」を、行2に「日」を記入 • セルの色を変更して、曜日の区別を付ける。 （ここでは、平日を灰色に、土曜日を薄い青色 に、日曜日を薄い赤い色に）ツールバーの「インデント」ボタン
4 日程の割り振り
• 各タスクを実行するために必要な日程を割り 振り、割り振られた日程のセルの色を変更。 （ここでは、紺色に塗りつぶし）
5 マイルストーンの設定
• 最後にマイルストーン（目印）を入れる • ピッツァ作成は生地の出来具合が重要 – 中盤に「生地ができているかの確認」というマイ ルストーンを追加 – ゴールとして、「テーブルに運んでフィニッシュ」と いうマイルストーンも追加Sample
関数とグラフで負荷状況を「
見える化
」する
• Excelの機能を使って、ガントチャートをさらに1 タスクの数（工数）を積算する
• Excelの「COUNTA」関数を使って、日別の工数 を積算できるようにする （COUNTAは、指定した範囲に含まれるデータの合計を 計算する関数） 1) まず、タスクの入っているセルに何でもいい ので、文字を入力 • ここでは、見た目に分かりやすいように「■」と いう黒い四角の文字を使う • 分かりやすいように文字を赤くするが、実際 に作成する場合は背景と同じ色で構わない2) 次に、日にちの一番下のセルに、文字の入っ たセルをカウントする関数「COUNTA」を使った 式を記述する。 • これで、一日ごとのプロジェクト全体のタスク 数が計算できる。 • 例えば、セル「F44」に「=COUNTA（F9:F43）」と 記入すると、入力した範囲内の「■」の総数が 表示される。
2 プロジェクトの負荷状況を「
見える化
」する
• Excelの「スパークライン」機能（ワークシートのセ ル内でデータを視覚的に表現する小さな棒グラフ） を使って、作成した日ごとのタスク数をグラフ 表示し、プロジェクトの負荷状況が一目で分 かるようにする（Excel 2010以降）スパークラインの挿入手順
1. 対象期間の上にあるセルを全て選んで一つ に結合する（F～CA） 2. 結合したセルをクリックして、ツールバーより 「グラフ」→「スパークライン」を選択する 3. 「スパークラインの挿入」というボックスが出 てくるので、「データ範囲」をマウスでドラッグ して指定する（今回は積算されたタスク数を 表す「F45～CA45」→「配置する場所」で【1】 で結合したセルを指定する→「OK」ボタンを 押す負荷状況を調整する
• 図のグラフを見ると、7月16日前後のタスクが 多過ぎることが分かる。タブを見ると、7月15 ～17日の工数合計が「4」となっている。 （Ｅｘｃｅｌの条件付き書式を活用） • 本プロジェクトの条件は、「メンバーは3人」 「1人が1度に処理できるタスクは1つまで＝4 つのタスクを同時進行させられない」なので、 工数合計がオーバーしている日のタスクを他 の日に割り振って、負荷を分散させなければ ならない。• 全体のバランスを見ると、中項目「オニオン スープを作る」の日程を変更しても全体に支 障が出ないことが分かるので、これらを6日分、 後倒しする。 • 図の黄色い囲みにある「AS30～BU36」までの セルを選択し、それをドラッグして右にずらす。 • そうすると、一日当たりの工数が3以下になる
• 実際のプロジェクト運用では、工数の調整は 複雑な要因に依存し、「あちらを立てればコチ ラが立たず」になりがち。 • だからこそ、ガントチャートを作成する時点で、 できるだけタスク同士がかぶらないように設 計することが大切。
第２章 演習問題解答例 設問１ (1) エ (2) イ 設問２ (1) ウ (2) イ (3) ア 設問３ ・開発工程の初期の段階で要求を完全に確定することは一般に困難であり， 要求が完全に確定しないまま先に進むことになり，結果として後戻りの原 因となる． ・テスト工程がプロジェクト後半に設定されているため，上流工程に欠陥が あってもそれがプロジェクトの終盤まで発見できないケースが多い． 設問４ • インクリメンタル型開発が，システムを機能やサブシステム，あるいは サービス単位に分割し，分割単位ごとに設計とテストを繰り返し行うのに 対して，イタラティブ型では，前サイクルの成果を土台にして次サイクルを 開発する形でシステム全体を繰り返し開発し，サイクルをまわす毎に完 成度を高めていく． 設問５ • ユーザ要求や仕様の変更リスクを軽減するために，顧客や開発者間の コミュニケーションを重視し，コーディングとテスト，コードの修正に重点を 置いて，短期間のリリースを繰り返して開発を進めていくソフトウェア開発 方法論で，アジャイルプロセスモデルと総称される一連の手法のうちの 代表的な１つである．テスト駆動開発やペアプログラミング等の技法がと られる．
