ソフト開発の手戻りを小さくするには プロジェクト管理の仕組み (その8)

更新日

投稿日

 
 この数回はプロジェクト管理をテーマにお話ししていますが、前回からはソフトウェア開発のスケジュール作成方法について解説しました。組み込みソフト開発は、スケジュールの内容、そして、その妥当性判断がソフト屋さん以外にはわかりづらく、そのため十分な進捗管理ができないことが多いものです。そこで、ソフト開発経験がないプロジェクトリーダーやハード屋さんでもスケジュールが理解でき、進捗管理ができるようになるスケジュール作成方法を解説します。少しこれまでの解説から、おさらいをしておきましょう。
 
 まず、製品仕様とソフトウェア内部構造の関連づけを行う方法を解説しました。これにより、ある機能を作るのにソフトウェアのどの部分に手を入れる必要があるのかがわかり、また、あるモジュールを変更することが、製品のどの機能に影響を及ぼす可能性があるのかがわかるようになります。つまり、ソフト屋さんでなくても、開発する製品機能とソフトの内部構造とを関連づけて話をすることができるわけです。
 
 次に、ソフト屋さんは開発する機能ごとに、基本設計、詳細設計、コーディング、単体テスト、結合テストという、流れ作業でソフトを作成するようなスケジュールを作りがちですが、実際のソフト開発はこのような流れ作業では進まないことをお話ししました。さらに、ソフトを実際に動かして動作確認をしながら、段階的に完成度を確認することが重要であることをお伝えしました。今回は、実際にソフト開発全体をどのようにスケジュールすればよいのかを解説します。
 

1. ソフトの開発スケジュールの具体化

 
 ソフトの開発スケジュールを具体化するときに最初に決めておくべきことは、結合テストの進め方です。前回お話ししたように、ソフト全体のどの部分(範囲)を、どういう順序で結合テストを実施するのかを決めます。ここでは、図36 を検討結果としましょう。機能セットA~Fの6回に分けて段階的にソフトの完成度を確認する計画になっています。
    
 一方、個々のモジュールは、図34で示したように、それぞれ関連する製品機能が決まっていますから、その製品機能を実現するために相当する機能(モジュール機能)をプログラムとして作成することになります。通常、あるひとつのモジュールは複数のモジュール機能を作り込みますから、できるだけ、段階的にこのモジュール機能を作成する計画にします。
 
 複数のモジュール機能を同時に作り込まざるを得ないことも、複数のモジュール機能を作るために事前に共通のモジュール機能を作っておかなければならないこともあります。したがって、単純に順番にモジュール機能を作ることができず、多少の工夫が必要になることもありますが、いずれにしろ、モジュール機能を段階的に作ってその都度単体テストにより動作確認を行うように計画します。図37 は各々のモジュールが、そのモジュールが実現すべきモジュール機能を段階的に作成することを示しています。たとえば、モジュールAは機能 A-1, A-2, A-3, A-4 と段階的に機能を作り込んでいくわけです。
 
R&D
   図37. モジュールの機能開発と結合テストの関係
 
 そして、結合テストを行う機能セット(ここでは、結合テストセットとよびましょう)とは、関係するモジュールについて、その機能セットの製品機能に相当するモジュール機能をモジュールができた段階で結合したものになります。たとえば、結合テストセット(機能セット)Bは、モジュールBの機能 B-2 、モジュールCの機能 C-1、モジュールDの機能 D-1 を作成した時点で、モジュールB,C,Dを結合して動作確認をすることになります。他の結合テストセットについても同様です。したがって、個々のモジュールは、なるべく結合テストの段取り(結合テストセットとその実施順序)に合わせて段階的に作成することになります。この例では図38 に示すような作業の流れになります。
 
 R&D
   図38. モジュール開発と結合テストの作業の流れ
 
 組み込みソフトの場合は、結合...
 
 この数回はプロジェクト管理をテーマにお話ししていますが、前回からはソフトウェア開発のスケジュール作成方法について解説しました。組み込みソフト開発は、スケジュールの内容、そして、その妥当性判断がソフト屋さん以外にはわかりづらく、そのため十分な進捗管理ができないことが多いものです。そこで、ソフト開発経験がないプロジェクトリーダーやハード屋さんでもスケジュールが理解でき、進捗管理ができるようになるスケジュール作成方法を解説します。少しこれまでの解説から、おさらいをしておきましょう。
 
 まず、製品仕様とソフトウェア内部構造の関連づけを行う方法を解説しました。これにより、ある機能を作るのにソフトウェアのどの部分に手を入れる必要があるのかがわかり、また、あるモジュールを変更することが、製品のどの機能に影響を及ぼす可能性があるのかがわかるようになります。つまり、ソフト屋さんでなくても、開発する製品機能とソフトの内部構造とを関連づけて話をすることができるわけです。
 
 次に、ソフト屋さんは開発する機能ごとに、基本設計、詳細設計、コーディング、単体テスト、結合テストという、流れ作業でソフトを作成するようなスケジュールを作りがちですが、実際のソフト開発はこのような流れ作業では進まないことをお話ししました。さらに、ソフトを実際に動かして動作確認をしながら、段階的に完成度を確認することが重要であることをお伝えしました。今回は、実際にソフト開発全体をどのようにスケジュールすればよいのかを解説します。
 

1. ソフトの開発スケジュールの具体化

 
 ソフトの開発スケジュールを具体化するときに最初に決めておくべきことは、結合テストの進め方です。前回お話ししたように、ソフト全体のどの部分(範囲)を、どういう順序で結合テストを実施するのかを決めます。ここでは、図36 を検討結果としましょう。機能セットA~Fの6回に分けて段階的にソフトの完成度を確認する計画になっています。
    
 一方、個々のモジュールは、図34で示したように、それぞれ関連する製品機能が決まっていますから、その製品機能を実現するために相当する機能(モジュール機能)をプログラムとして作成することになります。通常、あるひとつのモジュールは複数のモジュール機能を作り込みますから、できるだけ、段階的にこのモジュール機能を作成する計画にします。
 
 複数のモジュール機能を同時に作り込まざるを得ないことも、複数のモジュール機能を作るために事前に共通のモジュール機能を作っておかなければならないこともあります。したがって、単純に順番にモジュール機能を作ることができず、多少の工夫が必要になることもありますが、いずれにしろ、モジュール機能を段階的に作ってその都度単体テストにより動作確認を行うように計画します。図37 は各々のモジュールが、そのモジュールが実現すべきモジュール機能を段階的に作成することを示しています。たとえば、モジュールAは機能 A-1, A-2, A-3, A-4 と段階的に機能を作り込んでいくわけです。
 
R&D
   図37. モジュールの機能開発と結合テストの関係
 
 そして、結合テストを行う機能セット(ここでは、結合テストセットとよびましょう)とは、関係するモジュールについて、その機能セットの製品機能に相当するモジュール機能をモジュールができた段階で結合したものになります。たとえば、結合テストセット(機能セット)Bは、モジュールBの機能 B-2 、モジュールCの機能 C-1、モジュールDの機能 D-1 を作成した時点で、モジュールB,C,Dを結合して動作確認をすることになります。他の結合テストセットについても同様です。したがって、個々のモジュールは、なるべく結合テストの段取り(結合テストセットとその実施順序)に合わせて段階的に作成することになります。この例では図38 に示すような作業の流れになります。
 
 R&D
   図38. モジュール開発と結合テストの作業の流れ
 
 組み込みソフトの場合は、結合テストを実施するにはハードウェアが必要となることが普通ですから、このように単純には計画を立てることができないこともありますが、まずはこのような考え方で最適なスケジュールを作成することが大切です。そして、ハードがないとテストができないという制約も工夫によって乗り越えることも大切です。既存のハードに手を加えるとか、既存のハードでも動かせるようにテストドライバーやテストスタブを作成するとか、何らかの方法によって結合テストを実施し動いている状態で動作確認することは、余分な手間をかけるように思えても結果的に十分に報われることが多いものです。ムダなことと簡単に結論を出すのではなくぜひトライしてください。
 
 次回は、ソフト開発スケジュールの内容確認と進捗管理を解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
味覚 普通の組織をイノベーティブにする処方箋 (その154)

  現在、イノベーション実現に向けての「思考の頻度を高める方法」を解説していますが、そのための2つ目の要素「同じ一つの行動をするにしても思...

  現在、イノベーション実現に向けての「思考の頻度を高める方法」を解説していますが、そのための2つ目の要素「同じ一つの行動をするにしても思...


オープンイノベーションを成功させる 『発注者のエンジニアリング』

 『発注者のエンジニアリング』とは、耳慣れない言葉だと思いますが、技術革新が著しい分野でオープンイノベーションにより優れた特注品を創り出したいときに、目覚...

 『発注者のエンジニアリング』とは、耳慣れない言葉だと思いますが、技術革新が著しい分野でオープンイノベーションにより優れた特注品を創り出したいときに、目覚...


有能感獲得の活動 普通の組織をイノベーティブにする処方箋 (その84)

 前回エドワード・デシの4段階理論における第3段階を実現する活動として、「(その1)有能感への貢献:目的達成が自分自身の成長につながることを理解する」...

 前回エドワード・デシの4段階理論における第3段階を実現する活動として、「(その1)有能感への貢献:目的達成が自分自身の成長につながることを理解する」...


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

もっと見る
品質の仕組みとは2 プロジェクト管理の仕組み (その28)

 品質の仕組み、前回に続いて解説します。今回は、品質計画についてです。    計画の重要性は ISO9001でも「品質計画」として強調されて...

 品質の仕組み、前回に続いて解説します。今回は、品質計画についてです。    計画の重要性は ISO9001でも「品質計画」として強調されて...


仕組み見直しとグローバル化(その1)

◆「気づき」能力向上のカギは製品開発経験の活用    前回は、日本の多くの開発現場で「組み合わせ型」アーキテクチャの製品を「擦り合わせ型」の...

◆「気づき」能力向上のカギは製品開発経験の活用    前回は、日本の多くの開発現場で「組み合わせ型」アーキテクチャの製品を「擦り合わせ型」の...


設計部門と組織政治の影響(その2)

 前回のその1に続いて解説します。   1. 政治的要因のリストアップ    設計部門と組織政治の影響を考察する際に、最初にや...

 前回のその1に続いて解説します。   1. 政治的要因のリストアップ    設計部門と組織政治の影響を考察する際に、最初にや...