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