|
[2008 年 6 月号] |
［レポート］
2008年5月14日(水)〜16日(金)、東京ビッグサイトにて、リードエグジビションジャパン株式会社主催の「第11回 組込み開発技術展(ESEC)」が開催されました。ESECは、組込みシステム開発に必要なハードウェア、ソフトウェア開発環境などに関する専門展で、テスト・検証、画像処理、無線通信、タッチパネル・ディスプレイ、モーションコントロール、設計・開発サービス/コンサルティングの6つのゾーン、および特設として組込みボード・コンピュータのゾーンが設置され、多数の企業が参加しました。
この記事では参加したセミナーや会場の様子について報告いたします。
オムロン(株) コントロール機器統轄事業部 技術部 技術専門職
福井 信二 氏
WBS・クリティカルパス・リスク管理などプロジェクト管理の基本について、組込みソフト開発の実例を用いて解説する。加えて、大規模な組込み開発で重要になるソフトウェア構成管理について、I/F管理、変更管理など実際に使えるテクニックを解説する。
※講演プログラムより引用。
本講演では、一般的なプロジェクトマネジメントの基本、組込み系開発におけるプロジェクトの要点、構成管理上のテクニックなどの解説が行われました。
プロジェクトマネジメントの基本においては、不確実なプロジェクトを確実にするための技法として、WBS、PERT、リスク管理プロセスなどの基本的な手法の紹介がありました。
次に、組込み系開発におけるプロジェクトの要点では、組込み特有のリスクとその回避策の提示がありました。組込み系特有のリスクとしては、(1) 仕様を決める際の関係者が多く、すり合わせのコミュニケーションコストが大きいこと、(2) ハードウェアとソフトウェアが並行開発されるため、後半の機能テストにおいてハードウェアとソフトウェアを結合する段階にリスクが集中してしまうことが挙げられました。
前者のコミュニケーション上のリスクを低減する方法として、プロジェクト計画書と構成管理委員会 (Configuration Control Board) の重要性が指摘されました。プロジェクト計画書に関しては、プロジェクトの計画段階で、各関係者に何を提示すべきか、何をしてもらうかを明確にし、プロジェクト計画書において、組織体制図とWBSのマッピングなども明示する必要があるとのことでした。また、仕様決めの関係者間の調整をしやすいように、仕様変更の管理を行う「構成管理委員会(CCB)」を変更が影響する組織単位ごとに設置する必要があるとのことでした。例として、製品ごと、製品内の担当領域(ハードウェア、ソフトウェアなど)ごと、担当領域内のサブシステムごとなどです。これらのCCB単位で仕様変更などの判断を行い、CCB間で仕様変更に関する情報を共有します。
後者の並行開発に関するリスクを低減する方法としては、開発のV字プロセスにおける各工程で発生するリスクと回避策を蓄積し、組織内で資産化する必要が挙げられました。また、プロジェクトの計画に、リスクに対応する期間を盛り込んでおくなども必要です。
組込み系開発においては、インタフェース管理が重要とのことでした。組込み系開発では最初から詳細が決まらないことが多く、サブシステム間のインタフェースにおいて、詳細化のレベルは十分か、上位設計との整合性は取れているかを管理するべきであるとの指摘がなされました。
後半の講演が構成管理に関するものであったため、特に組込み系のプロジェクトマネジメントを中心に解説が行われていました。
著者は、まだ組込み系開発の経験が浅く、講演内で指摘されていた組込み系開発におけるプロジェクトマネジメント上のリスクに関しては十分理解できていませんが、マネジメントを考える立場の人たちに対して、プロジェクトメンバーが何をすべきか考える上で本講演は参考になりました。
(株)豆蔵 ES事業部 主幹コンサルタント
濱野 隆芳 氏
構成管理に課題を抱える組織は多い。本講座では、複数製品・多バリエーションへの対応も含め、組込み系開発における構成管理の典型的課題を取り上げ、改善/対処のポイントを本質的＆実践的に解説する。
※講演プログラムより引用。
本講演では、組込み系開発における構成管理の典型的な課題、適切な構成管理の適用のポイント、複数製品間・多バリエーションの構成管理について解説がありました。
組込み系開発における構成管理の課題の中で、本講演で取り上げられた課題は、(1) 適切な構成管理の適用ができていないこと、(2) 共通的・基盤的なソフトウェアや部品群の管理・維持ができていないことの2つです。
1つ目の適正な構成管理ができていない理由として、プロジェクトに適正な構成管理を実施する余裕が持てていないことが挙げられました。まず、小〜中規模の開発が多く、少人数体制でプロジェクトを運営している場合が多くあり、さらに短い開発サイクルの中で、仕向け・派生開発によって仕様・プラットフォームの違う製品を開発しており、多数の仕様変更が行われる傾向にあることで、構成管理に十分な工数を割くことができていません。結果として、変更管理や変更の記録が十分行われていないことが多くあります。
2つ目の課題の理由として、プロダクトライン的な開発に移行できていないことが挙げられました。このため、ソフトウェア部品などの切り出しが行われたとしても、各製品開発で変更され、最終的に形骸化してしまうことがあります。
適正な構成管理を適用する上で重要なポイントとして挙げられていたのは、何のために構成管理を実施するのか、その目的を理解し、理想と現状のギャップを識別すること、そして、効果を意識して開発プロセスに適合した管理レベルを設定することでした。講演者の指摘する構成管理の目的は、任意の時点の構成を復元できるようにすること、また、プロジェクトの成果物間の一貫性を確実にすることです。これらを意識し、開発プロセス、開発体制・規模、品質要件、意図的な構成の記録の要否などを考慮して構成管理の管理レベルを設定するとのことでした。
組込み系開発においては、複数製品・多バリエーションの構成管理を行う上で、会社としてのメインストリームとなる構成管理の流れと、製品ごとに発生するブランチの流れが分岐し、製品ごとの変更がメインストリームにうまく反映されないことが多くあるとの指摘がありました。しかし、今後、複数製品・多バリエーションの開発を効率的に行うためには、構成管理においても、いかに共通部分を最大化し、製品固有部分を最小化するかを考える必要があります。そのためには、構成の設計として共通部分と製品固有部分を切り分け、ベースラインと呼ばれる単位で適正な管理を行う必要があります。
著者の現業務の中で実施している構成管理のポリシーはかなりシンプルなものなので、後半の複数製品の構成管理はかなり参考になりました。ソフトウェアのアーキテクチャについても、再利用を考慮したものを設計するとともに、構成管理の面でも複数製品に対応したポリシーを検討する必要があると感じました。
ソフトウェアの個別部分と共通部分を分けて構成管理をしやすくする手法に関しては、各所属の設計ポリシーに合わせて考える必要があるとのことです。著者の現在の業務ではどうすべきかを考えていきたいと思います。
今回初めてESECに参加しましたが、規模の大きさと参加企業・参加者の多さに圧倒されました。
実際に参加する前は、ハードウェアに関する出展が多いと考えていたのですが、ソフトウェア開発環境、テスト・検証技術、組込みソフトウェア開発の教育・コンサルティングなど、ソフトウェアに関する出展が目立っていました。メディアにおいて、組込みソフトウェアの品質の問題をよく目にする中、ESECにおいても、ソフトウェアに対する品質向上への意識の高まりを感じました。
| © 2008 OGIS-RI Co., Ltd. |
|
