月日組込みソフトウェア向けプロジェクト計画立案演習セミナー · Check 1 Check4 Check 2 Check5 Check 3 Check6 テーマ3 【説明】テーマ4 【説明】

Copyright© 2012 Information-technology Promotion Agency, Japan. All rights reserved.

IPA 独立行政法人情報処理推進機構

SEC ソフトウェア・エンジニアリング・センター

Information-technology Promotion Agency, Japan

Software Engineering Center

SECセミナー／JASA共催

Software Engineering Center 1

組込みソフトウェア向け

プロジェクト計画立案演習セミナー〔初級・中級向け〕重要ポイント把握編

～計画書に基づいたマネジメントを目指すプロジェクトマネージャーのために～

2012年2月24日

研究員松田充弘専門委員村松昭男

SEC Software Engineering for Mo･No･Zu･Ku･Ri

SECセミナー/JASA共催 (東京) Software Engineering Center 2012.2.24 2 Copyright © 2012 IPA, All Rights Reserved.

タイム・スケジュール

時間内容

13:30～14:30

（60分)

【解説】組込みソフトウェア向けプロジェクト計画立案の重要ポイント解説

（講師：IPA/SEC 研究員松田充弘）

14:30～14:45

(15分) 休憩

14:45～17:20

（2時間35分)

【演習】組込みソフトウェア向けプロジェクト計画立案グループ演習

課題１（６５分）

説明（5分）

各自理解＆グループ討議（35分）

発表（25分）

～休憩（１０分）～

課題２（８０分）

説明（5分）

各自理解＆グループ討議（45分）

発表（30分）

（講師：IPA/SEC 専門委員村松昭男）

17:20～17:30

(10分)

【質疑応答】

Copyright© 2012 Information-technology Promotion Agency, Japan. All rights reserved.

IPA 独立行政法人情報処理推進機構

SEC ソフトウェア・エンジニアリング・センター

Information-technology Promotion Agency, Japan

Software Engineering Center

SECセミナー／JASA共催

Software Engineering Center 3

【講義】組込みソフトウェア向け

プロジェクト計画立案の重要ポイント解説

研究員松田充弘

2012年2月24日



目次

1. 組込みソフトウェア開発向けプロジェクト計画立案トレーニングガイド（ESMG）の紹介

• ESMG発行の経緯

• ESMGのプロジェクト事例

• ESMGの構成と読み方

2. プロジェクト計画立案のために押さえておきたいポイント（ESMGから）

• 計画立案の流れに関するもの

• テーマ１「プロジェクト条件を洗い出す」際のポイント

• テーマ５「実施する作業を決める」際のポイント

• テーマ６「工程設計を行う」際のポイント

• テーマ７「要員計画を立てる」際のポイント

3. プロジェクト計画を立案するマネージャやリーダの心構え

(8)

(47)

(5)



組込みソフトウェア向け

▌プロジェクト計画立案トレーニングガイド

（Embedded System development Management Training Guide）

特徴

具体的なプロジェクト事例と計画書の実例を提示

プロジェクト計画の立案過程を演習形式で解説

プロジェクト計画書作成ガイドESMRの実践編

ドメイン非依存の計画立案手順を整理。

発行日：平成23年11月定価：１,000円（税込） A4変形判、288頁 PDF版は無償提供

想定利用者

現場のプロジェクトマネージャ、サブリーダ

プロジェクト計画に基づいたプロジェクト運営を始め

たい

プロジェクト計画を立案するためのノウハウを知り

たい

企業の教育企画担当者／学校の教育者

プロジェクト計画の立案の仕方を指導・教育したい



▐ESMG発行の経緯（ESMRの発行）

① 計画書にどのような項目を書いていいかわからない

② 部門として共通化された計画書のフォーマットなどが整備されていない

プロジェクトマネジメントガイド： ESMR（計画書編）（Embedded System development Management Reference）

解決するために

2006年11月

「ESMR」の発行

⇒組込みソフトウェア開発に携わっている人達の声

プロジェクト計画書に基づいたソフトウェア開発の推進



国際標準（IEEE 1058(1998)）参照＋委員企業の知見

PJの概要情報

PJの体制

Qualityの計画

Costの計画

Deliveryの計画

(2)

▐ プロジェクトマネジメントガイド（計画書編）：ESMR



自習しながら理解できる解説書を目指して

具体的なプロジェクト事例を用いて立案過程を示そう

どんなふうにして計画を立案して行けば良いのか事例を示して欲しい。

▐プロジェクト計画書作成上の問題点（まだ在る）

• 何を書けば良いかはわかったが。。。。。

• どんなフォームで書けば良いかもわかったが。。。

③ 計画を立案することは難しい

けれども

Exercise Guideを発行

2011年11月「ESMG」の発行



事例プロジェクト

全体規模 1,200KLOC

開発規模 166KLOC

開発期間 15ヶ月

ピーク時要員数 26人

自動改札機に搭載するソフトウェアの開発

▐ ESMGの事例プロジェクト①

★派生開発（流用率８５％）



システム部分は事例プロジェクトの範囲外。ソフトウェア

開発のみを対象

・作業範囲

・開発体制

▐ ESMGの事例プロジェクト②



項目1.1

項目1.2

項目1.3

テーマ１

【説明】

Step4.1.1

項目4.1

項目4.2

項目4.3 Step4.2.1

Step4.3.1

Check 1 Check4

Check 2 Check5

Check 3 Check6

チェックカード

Check 1 Check4

Check 2 Check5

Check 3 Check6

テーマ３

【説明】

テーマ４

【説明】

テーマ１１

【説明】

ここでのポイント

項目3.1

項目3.2

項目3.3

▐ 計画立案トレーニングガイドの構成

計画立案手順の説明（テーマ、項目、Ｓｔｅｐ）

計画立案のための検討作業を、テーマ → 項目

→ Step →Checkの順に詳細化して解説。

検討例は、チェックカードに具体例を提示。

ここでのポイントに、注意点を示す。



▐ 計画立案トレーニングガイドの構成（テーマ、項目、Ｓｔｅｐ）



項目1.1

項目1.2

項目1.3

▐ 計画立案トレーニングの仕方（読み方） ①全体の計画立案手順を把握したい場合

テーマ１

【説明】

Step4.1.1

項目4.1

項目4.2

項目4.3 Step4.2.1

Step4.3.1

Check 1 Check4

Check 2 Check5

Check 3 Check6


Check 1 Check4

Check 2 Check5

Check 3 Check6

テーマ３

【説明】

テーマ４

【説明】

テーマ１１

【説明】

手順１

手順２ここでのポイント

手順３

項目3.1

項目3.2

項目3.3

手順１：各検討テーマ順に、テーマの説明を理解する。

（項目やStep は読み飛ばす）

手順２：更に理解を深めたい場合は、各検討テーマの項目の説明を理解する。

（Step は読み飛ばす）

手順３：更に理解を深めたい場合は、各項目のStep の各Check 項目と「ここでのポイント」を理解する。必要に応じて「チェックカード」の事例を参照する。



項目1.1

項目1.2

項目1.3

テーマ１

【説明】

Step4.1.1

項目4.1

項目4.2

項目4.3 Step4.2.1

Step4.3.1

Check 1 Check4

Check 2 Check5

Check 3 Check6


Check 1 Check4

Check 2 Check5

Check 3 Check6

テーマ３

【説明】

テーマ４

【説明】

テーマ１１

【説明】

ここでのポイント

項目3.1

項目3.2

項目3.3

▐ 計画立案トレーニングの仕方（読み方） ②個別のテーマの詳細手順を習得したい場合

個別のテーマを選択して、テーマ →

項目 → Step →Checkまで、通して読み進める。



組込みソフトウェア開発向けプロジェクト計画立案トレーニングガイド（ESMG）の紹介

以上 (8/60)



プロジェクト計画立案のために押さえておきたいポイント

（ESMGから）１．計画立案の流れに関するもの

計画立案作業の最終成果物は日程計画表（線表）計画立案にはいくつかの検討テーマがある

計画立案作業は「準備」「立案」「まとめ」の流れで行われる

３．テーマ５「実施する作業を決める」際のポイント

４．テーマ６「工程設計を行う」際のポイント

５．テーマ７「要員計画を立てる」際のポイント

２．テーマ１「プロジェクト条件を洗い出す」際のポイント

(5)

(4)

(10)

(15)

(10)



計画立案作業の最終成果物は日程計画表（線表）

プロジェクト計画書を一覧に集約したものが日程計画表

【目的】

プロジェクト計画を可視化し、プロジェクト関係者の間で共

有する



計画立案にはいくつかの検討テーマがある

プロジェクトの開発作業として実施する作業

実施する作業の順序

作業に割付ける要員

作業の実施期間

作業環境、設備、ツール類

作業の体制（プロジェクト内部と外部）

品質計画

リスク検討と計画



ESMGの計画立案のための共通検討テーマ

テーマ６工程設計を行う

テーマ７要員計画を立てる

テーマ５実施する作業を決める装置ドメイン

開発形態（投資型、請負型）

ソフトウェア規模

等に非依存の検討テーマ

テーマ１プロジェクト条件を洗い出す

テーマ１１日程計画表を作成する



計画立案作業は「準備」「立案」「まとめ」の流れで行われる

①プロジェクト条件を洗い出す

③プロジェクトの特徴や課題を把握する

②プロジェクトの目的・目標・終了条件を明確にする

⑤実施する作業を決める

④品質計画を立てる ⑥工程設計を行う

⑦要員計画を立てる

⑧コスト計画を立てる

⑩プロジェクトの体制と運営の仕組みを明確にする

⑪日程計画表を作成する

⑨リスクマネジメント計画を立てる

★準備（洗い出し・把握） ★計画立案（じっくり検討）

★整理と纏めプロジェクトの目的を明確に共有しなければ、人によって異なる理解が生じる（②）。

品質計画を明確にした上で作業を決める（④）。

日程計画表をイメージするために工程設計表を作成する（⑥）。

気になることは、リスク候補として常にメモしておく。（⑨）。

各テーマを擦りあわせながら立案してゆく。各テーマを行ったり来たりすれば良い。




プロジェクト計画を立案する作業に入る際には、ま

ずプロジェクト全体を俯瞰して、当該プロジェクトは何を作るのか、予算やスケジュールはどうなっているのか、どのようなことが既に決まっているのか等、

全体のプロジェクトイメージを固めておく必要があります。本テーマでは、プロジェクトに対する

要求事項と、その要求事項を満足するための条件を漏らさず洗い出します。

(4)




プロジェクトチーム

・予算

・スケジュール

・品質

・関係部門等

①開発対象への要求事項や条件

ソフトウェア

・機能

・非機能

・ハードウェア

装置

・他の関連

システム

・作業範囲

・引渡し条件

③プロジェクト内部で検討できる条件

②プロジェクトを

計画するために

与えられる条件

ツール類

作業場所

メンバ

請負会社候補

条件を洗い出す視点３つ

漏れなく洗いだす（ESMGにCheck項目を整理している）

メンバ候補




■出力情報

制約条件と前提条件に分類しておく

未決定事項を明確にしておく

（以上、テーマ１）



テーマ５実施する作業を決める

■出力情報

機能と作業マトリクス

■作業手順

作業テンプレートを持っておく

実現する機能に対して何をするかを整理する。

詳細化は、工程が進んで行くに従って行えば良い。

作業一覧表

(10)

(17/60)




当該プロジェクトの開発プロセス（作業テンプレート）を明確にする。

これを元に、そのプロジェクトに合った作業を決めてゆく



5.ソフトウェア結合テスト



■出力情報

作業内容や作業量を検討するためには、実現する機能を正確に把握しなければならない。

機能と作業マトリクスに整理する




小規模の開発の場合は、アクティビティを纏めるなど工夫する。

ｿﾌﾄｳｪｱ要求定義

ｿﾌﾄｳｪｱｱｰｷﾃｸﾁｬ設計

ｿﾌﾄｳｪｱ詳細設計

実装及び単体ﾃｽﾄ

ｿﾌﾄｳｪｱ結合ﾃｽﾄ

ｿﾌﾄｳｪｱ総合ﾃｽﾄ

ｿﾌﾄｳｪｱ要求定義




ｿﾌﾄｳｪｱ結合ﾃｽﾄ

ｿﾌﾄｳｪｱ総合ﾃｽﾄ

（通常規模）

（小規模の例）

管理面、技術面から実装イメージを考えてソフトウェア機能を分割し、機能を軸に作業を考える。

ソフトウェア機能を分割するには、機能ユニットがある程度、抽出されていなければならない

機能

作業



まずは、機能ブロック（サブシステム）のレベルで機能分割する。

プロジェクトの計画（見通し）を共有することが重要と考えて、プロジェクト計画の段階的なリリースを考える。

ある程度の機能分割が可能出れば、メンバーの配置を示すことが可能になる。

機能分割できなくても、各工程のマイルストーンは示す必要あり

ある程度の機能分割を示せれば、ある程度の作業分担も示すことができる。

アーキテクチャ設計しなければ、機能ユニットは抽出されない

プロジェクト計画の立案作業を諦めてはいけない




【備考欄】大よその作業ボリュームを検討しておく

作業テンプレートを元に機能ごとに実施する作業を明確にする。

（以上、テーマ５）




■出力情報 • 工程設計とは、実施する作業を時間軸上に並べる作業（参照：ESPR）

• 最終的なアウトプットの日程計画表をイメージするもの（中間資料）

要員配置を考えるためには、日程計画表(スケジュール表）のイメージ上でシミュレートする。そのために必要。

テーマ5の「機能と作業マトリクス」が工程を考える前提となる。

■作業手順

(27/60)

(15)



テーマ６工程設計を行う（作業手順）

プロジェクト条件表

■入力情報

■出力情報

足並みを揃えて行う作業と揃えなくてもできる作業に分けて考える。

前者の例：要求定義、総合テスト

後者の例：詳細設計、実装、単体テスト

重要イベントの視点

・顧客、

・システ取り纏め部門、

・自プロジェクト



優先作業を記す


■入力情報

■作業手順

■出力情報


【備考欄】大よその作業量（テーマ５）




ツール無しでは大変な作業になる







工程設計表（拡大）

重要イベント

開発工程

開発工程が見えるようになると、人のアサインを具体的に行える。

開発工程が見えるようになると、各作業の工数が見積もり易くなる。

検討漏れや課題がもっと見えてくる。

戻30,32



ソフトウェア要求定義


ｿﾌﾄｳｪｱﾌﾟﾛｼﾞｪｸﾄ計画立案（具体化）

ｼｽﾃﾑｱｰｷﾃｸﾁｬ設計

システム要求定義

ｿﾌﾄｳｪｱﾌﾟﾛｼﾞｪｸﾄ計画立案

（プロジェクト概要）

ハードウェア設計



ソフトウェア要求定義


ｿﾌﾄｳｪｱﾌﾟﾛｼﾞｪｸﾄ計画立案（試作）

ｼｽﾃﾑｱｰｷﾃｸﾁｬ設計

システム要求定義

ｿﾌﾄｳｪｱﾌﾟﾛｼﾞｪｸﾄ計画立案

（プロジェクト概要）

ハードウェア設計



ｿﾌﾄｳｪｱﾌﾟﾛｼﾞｪｸﾄ計画立案（具体化）



開発モデルを工夫する


★スパイラルの例

★Waterfallの例

【例】ｿﾌﾄｳｪｱｱｰｷﾃｸﾁｬがほぼ決まっている

【例】ｿﾌﾄｳｪｱｱｰｷﾃｸﾁｬの見直しリスクが高い

WaterFall型で作業見通しが立たない場合




■出力情報

「要員毎の稼働計画」と「作業毎に割付ける要員の一覧表」の両方を作成する。

作業量（開発規模と工数）を見積もったうえで要員をアサインする。

要員毎

作業毎

(42/60)

(10)







■入力情報 ■出力情報








工数＝開発規模÷プロジェクトの生産性



6 611 15 18 22 22 25 25 25 24 22.5

15.5 14.5 12.5

0

5

10

15

20

25

30

1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 13月 14月 15月


・工数1人月で、ソフトウェア要求定義からソフトウェア総合テストまでを含めて開発することができるコード行数

(人)

社内標準の生産性（例） V0／E 〔KLOC/人月〕

開発規模 V0 〔KLOC〕生産規模 V1〔KLOC〕総工数 E〔人月〕

総工数 E〔人月〕内訳：・SW要求定義(E1)

・SWアーキテクチャ設計(E2)

・SW詳細設計(E3)

・実装及び単体テスト(E4)

・SW結合テスト(E5)

・SW総合テスト(E6)

・プロジェクト取り纏め等管理工数(E0)

類似プロジェクトや社内標準から参照する生産性については、生産性の定義を明確にすることが重要です。




除く管理工数15％






テーマ６で導いた期間

７．１項で配分した工数





プロジェクト条件表


■入力情報

作業毎の要員計画

■出力情報要員毎の要員計画

作業一覧表（人数と必要スキル）工程設計表




スキル不足が明白であれば、出来るだけ定量的に明示し、リスク計画に織り込む。




予備工数は、生産性の設定である程度織り込んでおく。






プロジェクト計画立案のために押さえておきたいポイント

（ESMGから）

以上 (52/60)



プロジェクト計画を立案するマネージャやリーダの心構え

計画立案はなぜ難しいと感じるのか

小規模から中規模への移行により気付く事

プロジェクトマネージャの板挟み

プロジェクトマネージャの覚悟

プロジェクト計画書は誰のために作成するか



① 小規模開発から中規模開発に移行し、頭の中だけで、プロジェクトのイメージが描けなくなった。

② プロジェクト計画立案の仕方を教わる人がいない

③ 一部の機能ユニットの「詳細設計」「実装及び単体テスト」を受注する仕事がメインだったが、ソフトウェア丸ごと請け負うことになった。要求定義やアーキテクチャ設計の経験がなくスキル不足を感じる。

④ 未経験作業の工数が見積れない。

⑤ 未経験技術の作業工数が見積れない。

等々

▐ 計画立案は何故難しいと感じるのか

※プロジェクト計画を立案するということは、未来を予測することであるため、難しいのは当然。

※経験を積む以外にはない。ただし、自分の周りに、経験者が居れば安心できる。

※一人で背負うのではなく、皆で知恵を出しながら、協力してやるべき。



▐ 小規模から中規模への移行により気付く事

開発規模が増え、プロジェクトが肥大化すると、プロジェクトの進むべき方向を共有することが大切になってくる。しかし、共有することが難しくなる。

開発規模／プロジェクト規模

小さい大きい

考えの共有が難しい

考えの共有がやり易い

1人で全て

を把握できる。

1人で全て

を把握できない

ゴールを示せば、後は、リーダシップでこな

せる

プロジェクト計画の共有（合意）



▐ プロジェクトマネージャの板挟み

あるべき姿で計画せよ

無理のない現実的な計画を立てるべ

きだ。経営者寄りの考え

現場寄りの考え

・根拠のない、失敗するような計画は立てたくない。

・例：納期と品質を守りたい。そのためにはコストオーバーは仕方がない。

・例：絶対にコストオーバーはしない。追加コストを認めさせる。機能削減を交渉する。

プロジェクト計画書には、プロジェクトマネージャが、こうやりたいという思いを示す。

決められたコスト

決められた納期

バグのない完成品

キツイ作業は担当したくない。

決めるべきことを決めてからスタートして欲しい。

プロジェクト計画



▐ プロジェクトマネージャの覚悟

プロジェクトマネージャが、プロジェクトを背負って行く覚悟がなければ、計画は立てられない。（機械的にアウトプットできるものではない。）

マネージャ自身の能力は、そのプロジェクトの身の丈に合っているか？

・5人のプロジェクトを回せる能力と20人のプロジェクトを回せる能力は違う。

・上流工程を含むプロジェクトを背負うには、上流工程のマネジメント経験や技術スキルが要る。

リスク要素が大きいプロジェクトは、リスクを一人で抱え込んではいけない。上位管理者を巻き込んで組織的な行動に努める。

これから始めるプロジェクトに対峙して、

・開発規模

・要員

・フォーメーション

・リリース時の品質

・プロジェクトのスキルアップが必要なところ

・マネージャ自身の負担

を把握または想定できているか？



▐ プロジェクト計画書は誰のために作成するか

経営者経営判断の視点から

管理者組織管理の視点から

ＰＪマネジャプロジェクト運営の視点から

ＰＪメンバー個々の担当作業の認識の視点から

＊それぞれの視点に

必要な情報が必要

プロジェクト

計画書

関係他部署部署間インタフェースの視点から



ご清聴ありがとうございました後半のグループ演習は、今解説したところのテーマ６「工程設計を行う」、テーマ７「要員計画を立てる」に関するところの演習課題をグループで実施して頂きます。

グループ演習は、日頃、プロジェクト計画立案という作業の中で感じている問題点や悩みを、他社の同じような立場の方と共有して頂き、解決のヒントを得て頂く機会と考えています。

Documents

月 日 組込みソフトウェア向け プロジェクト計画立案演習セミナー · Check 1 Check4 Check 2 Check5 Check 3 Check6 テーマ3 【説明】 テーマ4 【説明】

月日組込みソフトウェア向けプロジェクト計画立案演習セミナー · Check 1 Check4 Check 2 Check5 Check 3 Check6 テーマ3 【説明】テーマ4 【説明】