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

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
3ステップメソッド:リスク低減の原則

1. リスク低減の重要性  製品安全に関する大規模なリコールですが、エアバッグメーカーのタカタや家具メーカーのイケアなど、いずれも数千万台規模のリコール...

1. リスク低減の重要性  製品安全に関する大規模なリコールですが、エアバッグメーカーのタカタや家具メーカーのイケアなど、いずれも数千万台規模のリコール...


研究開発テーマ、上司を説得する必要はあるのか~技術企業の高収益化:実践的な技術戦略の立て方(その33)

【目次】 ▼さらに深く学ぶなら!「技術マネジメント」に関するセミナーはこちら! 「このテーマで良いんでしょうか?」と仰るのは技術者...

【目次】 ▼さらに深く学ぶなら!「技術マネジメント」に関するセミナーはこちら! 「このテーマで良いんでしょうか?」と仰るのは技術者...


マクロ環境分析:社会 普通の組織をイノベーティブにする処方箋 (その40)

        現在、この連載ではマクロ環境分析の議論をしていますが、今回は、PESTEL(Politica...

        現在、この連載ではマクロ環境分析の議論をしていますが、今回は、PESTEL(Politica...


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

もっと見る
‐市場の観察から開発テ-マを得る‐  製品・技術開発力強化策の事例(その6)

 前回の事例その5に続いて解説します。新技術が社会に普及し始めると、それに関連した新商品を顧客の要求に即応して供給出来ないで、新技術搭載製品の供給不足が起...

 前回の事例その5に続いて解説します。新技術が社会に普及し始めると、それに関連した新商品を顧客の要求に即応して供給出来ないで、新技術搭載製品の供給不足が起...


コアコンピタンスを生かした開発と販売の発展とは

        今回は、次のような想定企業の状況で、自社の独自技術を生かした製品開発と販売方法について解説します。   1. 想定企業の経営状況...

        今回は、次のような想定企業の状況で、自社の独自技術を生かした製品開発と販売方法について解説します。   1. 想定企業の経営状況...


サブシステムの開発目標 プロジェクト管理の仕組み (その41)

 前回までで、化粧品の自販機についてシステムの内部構造を決めました。システム内部構造は、システムを独立したサブシステムにブレークダウンしたもので、ブロック...

 前回までで、化粧品の自販機についてシステムの内部構造を決めました。システム内部構造は、システムを独立したサブシステムにブレークダウンしたもので、ブロック...