ソフト開発計画の作成方法 プロジェクト管理の仕組み (その5)

更新日

投稿日

 前回のその4:プロジェクトの進捗管理に続いて解説します。前回は CMMI を使い、要件管理、計画作成、進捗管理のポイントを紹介しました。多くの開発組織では、これらのポイントをおさえた上で仕組みを整備してますが、表面的なものになっていることが少なくありません。そのため、せっかく仕組みを作っても期待の効果を出せていません。より大きな効果を出すためには、開発作業の本質を見極め、仕組みをより進化、深化させることが重要です。
 

1. 組込型ソフトウェア開発のスケジュール作成方法

 
 製品開発はソフトウェアを抜きにしては成り立たないというのは間違いのないところです。しかしながら、ソフトウェア開発の進捗はわかりづらく、開発遅れの原因となっていることが多くの開発現場で発生しています。今回は、ソフト屋さんでなくても進捗管理ができる計画作成の仕組みを、前回紹介した話の具体例として解説します。それでは、組込型ソフトウェア開発のスケジュール作成方法を説明したいと思います。前回の図33 で紹介したスケジュール作成過程にしたがって作成していきます。
 
                       R&D
                                              図33. スケジュールが作成される過程
 
 ソフト開発スケジュールを作成するには、まず、製品の外部仕様をソフトウェア内部のモジュール、もしくは、ブロックやユニットの機能に変換して、必要となる変更や新規作成作業を分析し、開発作業を明らかにする必要があります。ソフト屋さんはこの一連の作業を頭の中でやってしまうことが多いので問題になります。経験者でないと見積もりができない、計画や見積もりの妥当性を誰も確認できないということになるからです。したがって、まずこの時点で必要なことは、外部仕様をソフトウェア内部のモジュール、ブロック、ユニットなどの機能仕様に変換する工程を見える化し、洗い出した開発作業が妥当かどうかを、ハード屋さん含めてプロジェクト関係者が確認できる仕組みにすることです。
 
                R&D
                                           図34. 外部仕様から内部構造への変換
 
 図34 はそのための基本的な考え方を示しています。ソフトウェア内部構造の各要素に対して、モジュール、ブロック、ユニットなど様々な呼び方があり、各社各様の使い方をしていますが、以後、モジュールと統一することにします。さて、図34 では、モジュールAとモジュールBは機能1と機能2の両方を実現するためにそれぞれに必要な処理を実装する必要があること、そして、モジュールCは機能1、モジュールDは機能2を実現するための処理を実装する必要があることがわかります。これを全部の機能について実施することで、必要なモジュールとその機能が明らかになります。
 

2. 手順

 
 手順を整理しておきましょう。外部仕様である製品機能がある程度固まったものから、その機能についてソフト内部構造上の処理の流れを考えます。そして、この分析を製品機能の一つひとつについて実施することで、製品がソフトウェアのどのような振る舞いで機能するのかを明確にします。この分析により、製品機能全体を実現するためにソフトの各モジュールが備えるべき処理(内部機能)と、モジュールとモジュールの間のやりとりが明確になります。
 
 明らかになった、外部仕様として挙がっている製品機能一覧とソフト内部のモジュール一覧との関係を設計文書としてまとめたものが、前回紹介した図32「要求仕様と内部構造の双方向追跡を可能とする設計文書」です。このような文書に整理できていれば、ある機能に関係しているモジュールがどれなのか、そして、あるモジュールが影響する機能が何なのかといった、外部仕様とソフト内部構造相互の関連づけを簡単に把握することができるようになります。
 
 この分析は、プログラムも出てきませんし、ソフトウェア固有の知識も必要ではなく、ハード屋さんでもプロジェクトリーダーでもわかる内容になっています。また、アウトプットの設計文書を見れば、製品機能(外部仕様)とソフト内部の振る舞いが関連づけられているので、ソフト屋さんでなくても、あるモジュールの進捗が遅れているということがどの機能に影響があるのか、また、重要な機能の動作確認を早めに行いたいときにどのモジュールを完成させる必要があるのか、などがわかります。
 
 さらに、仕様変更や設計変更への対応も見える化されます。開発当初にすべての外部仕様が決まっていれば理想的ですが、製品開発現場では困難です。外部仕様ができていないから開発が遅れるというのはソフト屋さんから良く聞かれる言葉ですが、現実の開発を考えれば、外部仕様が繰り返し変更される状況であってもソフト開発として対応する必要があります。このような要求に対しても、外部仕様が変更されるたびにこの分析を実施し図34 や図32 の文書化を行うことで、ソフト屋さんだけでなく、ハード屋さん含めたプロジェクト関係者全員で、仕様変更に対する対応方法やその難易度などを共有することができ、適切な対応をとることが可能になります。
 
 次回は、プロジェクト管理の仕組み(その6)として、ソフトウェア開発スケジュールの問題点を解説します。
 
 
...
 前回のその4:プロジェクトの進捗管理に続いて解説します。前回は CMMI を使い、要件管理、計画作成、進捗管理のポイントを紹介しました。多くの開発組織では、これらのポイントをおさえた上で仕組みを整備してますが、表面的なものになっていることが少なくありません。そのため、せっかく仕組みを作っても期待の効果を出せていません。より大きな効果を出すためには、開発作業の本質を見極め、仕組みをより進化、深化させることが重要です。
 

1. 組込型ソフトウェア開発のスケジュール作成方法

 
 製品開発はソフトウェアを抜きにしては成り立たないというのは間違いのないところです。しかしながら、ソフトウェア開発の進捗はわかりづらく、開発遅れの原因となっていることが多くの開発現場で発生しています。今回は、ソフト屋さんでなくても進捗管理ができる計画作成の仕組みを、前回紹介した話の具体例として解説します。それでは、組込型ソフトウェア開発のスケジュール作成方法を説明したいと思います。前回の図33 で紹介したスケジュール作成過程にしたがって作成していきます。
 
                       R&D
                                              図33. スケジュールが作成される過程
 
 ソフト開発スケジュールを作成するには、まず、製品の外部仕様をソフトウェア内部のモジュール、もしくは、ブロックやユニットの機能に変換して、必要となる変更や新規作成作業を分析し、開発作業を明らかにする必要があります。ソフト屋さんはこの一連の作業を頭の中でやってしまうことが多いので問題になります。経験者でないと見積もりができない、計画や見積もりの妥当性を誰も確認できないということになるからです。したがって、まずこの時点で必要なことは、外部仕様をソフトウェア内部のモジュール、ブロック、ユニットなどの機能仕様に変換する工程を見える化し、洗い出した開発作業が妥当かどうかを、ハード屋さん含めてプロジェクト関係者が確認できる仕組みにすることです。
 
                R&D
                                           図34. 外部仕様から内部構造への変換
 
 図34 はそのための基本的な考え方を示しています。ソフトウェア内部構造の各要素に対して、モジュール、ブロック、ユニットなど様々な呼び方があり、各社各様の使い方をしていますが、以後、モジュールと統一することにします。さて、図34 では、モジュールAとモジュールBは機能1と機能2の両方を実現するためにそれぞれに必要な処理を実装する必要があること、そして、モジュールCは機能1、モジュールDは機能2を実現するための処理を実装する必要があることがわかります。これを全部の機能について実施することで、必要なモジュールとその機能が明らかになります。
 

2. 手順

 
 手順を整理しておきましょう。外部仕様である製品機能がある程度固まったものから、その機能についてソフト内部構造上の処理の流れを考えます。そして、この分析を製品機能の一つひとつについて実施することで、製品がソフトウェアのどのような振る舞いで機能するのかを明確にします。この分析により、製品機能全体を実現するためにソフトの各モジュールが備えるべき処理(内部機能)と、モジュールとモジュールの間のやりとりが明確になります。
 
 明らかになった、外部仕様として挙がっている製品機能一覧とソフト内部のモジュール一覧との関係を設計文書としてまとめたものが、前回紹介した図32「要求仕様と内部構造の双方向追跡を可能とする設計文書」です。このような文書に整理できていれば、ある機能に関係しているモジュールがどれなのか、そして、あるモジュールが影響する機能が何なのかといった、外部仕様とソフト内部構造相互の関連づけを簡単に把握することができるようになります。
 
 この分析は、プログラムも出てきませんし、ソフトウェア固有の知識も必要ではなく、ハード屋さんでもプロジェクトリーダーでもわかる内容になっています。また、アウトプットの設計文書を見れば、製品機能(外部仕様)とソフト内部の振る舞いが関連づけられているので、ソフト屋さんでなくても、あるモジュールの進捗が遅れているということがどの機能に影響があるのか、また、重要な機能の動作確認を早めに行いたいときにどのモジュールを完成させる必要があるのか、などがわかります。
 
 さらに、仕様変更や設計変更への対応も見える化されます。開発当初にすべての外部仕様が決まっていれば理想的ですが、製品開発現場では困難です。外部仕様ができていないから開発が遅れるというのはソフト屋さんから良く聞かれる言葉ですが、現実の開発を考えれば、外部仕様が繰り返し変更される状況であってもソフト開発として対応する必要があります。このような要求に対しても、外部仕様が変更されるたびにこの分析を実施し図34 や図32 の文書化を行うことで、ソフト屋さんだけでなく、ハード屋さん含めたプロジェクト関係者全員で、仕様変更に対する対応方法やその難易度などを共有することができ、適切な対応をとることが可能になります。
 
 次回は、プロジェクト管理の仕組み(その6)として、ソフトウェア開発スケジュールの問題点を解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!


「技術マネジメント総合」の他のキーワード解説記事

もっと見る
スタートアップ知財支援とは 新規事業・新商品を生み出す技術戦略(その67)

1. 特許庁主催の知財活動表彰ニュース  2020年3月19日、特許庁のスタートアップの支援やイベントの開催を行う知財コミュニティポータルサイト「I...

1. 特許庁主催の知財活動表彰ニュース  2020年3月19日、特許庁のスタートアップの支援やイベントの開催を行う知財コミュニティポータルサイト「I...


ロードマップの作り方

   別稿で解説した通り、ロードマップを作るに際して、技術ベースで考えるか(フォーキャスト型)、市場要求からの逆算型(バックキャスト型)で...

   別稿で解説した通り、ロードマップを作るに際して、技術ベースで考えるか(フォーキャスト型)、市場要求からの逆算型(バックキャスト型)で...


オープン・イノベーションを社内で実現する方法  研究テーマの多様な情報源(その29)

1.自社のコア技術を外部に発信する理由    前回のその28に続いて解説します。それでは、まず自社のコア技術を外部に発信する理由は何なのでし...

1.自社のコア技術を外部に発信する理由    前回のその28に続いて解説します。それでは、まず自社のコア技術を外部に発信する理由は何なのでし...


「技術マネジメント総合」の活用事例

もっと見る
マトリクス体制での品質保証3 プロジェクト管理の仕組み (その32)

 前回のマトリクス体制での品質保証2に続いて解説します。    これまで説明してきたのは、プロジェクトごとに作成する品質計画(プロジェクト品...

 前回のマトリクス体制での品質保証2に続いて解説します。    これまで説明してきたのは、プロジェクトごとに作成する品質計画(プロジェクト品...


‐産学交流からの開発テ-マと市場の観察‐  製品・技術開発力強化策の事例(その7)

 前回の事例その6に続いて解説します。産学交流による開発テ-マの探索や共同開発に関心が寄せられています。 大学には基礎研究の面で優れた開発テ-マの候補にな...

 前回の事例その6に続いて解説します。産学交流による開発テ-マの探索や共同開発に関心が寄せられています。 大学には基礎研究の面で優れた開発テ-マの候補にな...


ソフトウェア開発の成果物による進捗管理 プロジェクト管理の仕組み (その16)

 前回は、計画時の見積もり精度を上げるための基準モデルと、進捗を見える化するための基本ツールである基本メトリクスセットのひとつ、作業成果物メトリクスについ...

 前回は、計画時の見積もり精度を上げるための基準モデルと、進捗を見える化するための基本ツールである基本メトリクスセットのひとつ、作業成果物メトリクスについ...