ソフト開発計画の作成方法 プロジェクト管理の仕組み (その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)

       人口減少による人手不足、既存製品のコモディティ化、新技術の導入などに対応していくために、企業が...

       人口減少による人手不足、既存製品のコモディティ化、新技術の導入などに対応していくために、企業が...


思考パターン 普通の組織をイノベーティブにする処方箋 (その75)

 現在、関係性の種類を解説しています。前回は関係性の種類の一つ「原因と結果」の中の「逆ピラミッド(複数の原因→一つの結果)」が起こる3つの要...

 現在、関係性の種類を解説しています。前回は関係性の種類の一つ「原因と結果」の中の「逆ピラミッド(複数の原因→一つの結果)」が起こる3つの要...


自社のコア技術の補完技術をどう探すか 普通の組織をイノベーティブにする処方箋 (その30)

 この解説では、KETICモデルの最初の知識(Knowledge)の中の技術の知識の解説をしていますが、今回は、前回で議論した外部技術の活用法の内、「その...

 この解説では、KETICモデルの最初の知識(Knowledge)の中の技術の知識の解説をしていますが、今回は、前回で議論した外部技術の活用法の内、「その...


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

もっと見る
技術資源の有効活用: 事例紹介 (その2)

 TRM(Technology Resources Management)事例その2は、建築物の防食事業を営む企業の取り組みをご紹介いたします。   ...

 TRM(Technology Resources Management)事例その2は、建築物の防食事業を営む企業の取り組みをご紹介いたします。   ...


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

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

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


設計部門の課題と原因分析(その1)

【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...

【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...