ソフト開発計画の作成方法 プロジェクト管理の仕組み (その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)として、ソフトウェア開発スケジュールの問題点を解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
夢商品開発七つ道具の総括 【快年童子の豆鉄砲】(その55)

  1.夢商品開発七つ道具の総括 「夢商品開発七つ道具(Y7)」の説明をしてきましたが、開発理念が共通することから「創造的魅力商品開発七...

  1.夢商品開発七つ道具の総括 「夢商品開発七つ道具(Y7)」の説明をしてきましたが、開発理念が共通することから「創造的魅力商品開発七...


クレーム率シングルppmをゼロに(2) 【快年童子の豆鉄砲】(その57)

  1.「連関図法」による不具合発生体質の把握 1)スタッフワークレベルの連関図法の使い方 採取した言語データ91を連関図法で解析する...

  1.「連関図法」による不具合発生体質の把握 1)スタッフワークレベルの連関図法の使い方 採取した言語データ91を連関図法で解析する...


市場を各グループ、セグメントに分割する 普通の組織をイノベーティブにする処方箋 (その69)

 前々回から「知識・経験を物理量で整理する」議論を始めていますが、今回も前回に引き続き「整理の為に考える要素」の解説をします。 ◆関連解説記事『技術...

 前々回から「知識・経験を物理量で整理する」議論を始めていますが、今回も前回に引き続き「整理の為に考える要素」の解説をします。 ◆関連解説記事『技術...


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

もっと見る
サブシステムの開発目標 プロジェクト管理の仕組み (その42)

 前回のその41に続いて解説します。    下図は、改めて操作管理サブシステムだけを抽出したものです。   図78. 操作...

 前回のその41に続いて解説します。    下図は、改めて操作管理サブシステムだけを抽出したものです。   図78. 操作...


開発工数メトリクス1 プロジェクト管理の仕組み (その21)

 前回のプロジェクト管理の仕組み (その20)に続いて解説します。    進捗管理のための基本メトリクスセットについての解説を続けています。...

 前回のプロジェクト管理の仕組み (その20)に続いて解説します。    進捗管理のための基本メトリクスセットについての解説を続けています。...


設計部門とリスク管理(その2)

【設計部門とリスク管理 連載目次】 1. リスク管理とは目標達成までのシナリオ作成 2. コンティンジェンシープランの注意事項 3. リスク管理...

【設計部門とリスク管理 連載目次】 1. リスク管理とは目標達成までのシナリオ作成 2. コンティンジェンシープランの注意事項 3. リスク管理...