PR
図1  プロジェクトを遂行する上での課題
図1 プロジェクトを遂行する上での課題
[画像のクリックで拡大表示]
図2  開発プロセスの選択理由と課題の関係
図2 開発プロセスの選択理由と課題の関係
[画像のクリックで拡大表示]
図3  選択した開発プロセスと製品出荷後の不具合率の関係
図3 選択した開発プロセスと製品出荷後の不具合率の関係
[画像のクリックで拡大表示]
図4  選択した開発プロセスとプロジェクト・マネジメントの工数
図4 選択した開発プロセスとプロジェクト・マネジメントの工数
[画像のクリックで拡大表示]

 開発プロセスの整備に早急に取り組まなければ,品質の改善は望めない──。前回は,2005年6月に情報処理推進機構(IPA)のソフトウェア・エンジニアリング・センタ(SEC)が公開した「2005年版組込みソフトウェア産業実態調査報告書」を基に,組み込みソフトウェア開発現場にとって開発プロセスへの取り組みが急務となっている実態を述べた。今回は,開発プロセスを効果的に適用するためにはどんな点に留意すべきかについて考察したい。

目的に応じてプロセスを選ぶ

 開発プロセスを適切に選択するには,その特性を理解することが必要不可欠だ。例えば,組み込みソフトウェア開発で現在最も多く採用されているウォータフォール方式は,決められた期間の中で開発を完了させるのが難しい傾向がある(図1[拡大表示])。ウォータフォール方式は開発の各工程を順を追って進めればよいため,マネジメントが比較的楽だという利点がある。ただ裏を返せば,マネジメントが軽視されやすい。入念なマネジメントを怠たると,開発期間の超過を引き起こす。

 アジャイル方式を採用したプロジェクトには「メンバが習得するのに時間がかかった」という回答が突出しているのが目立つ。アジャイルは,開発したものを逐次顧客に使ってもらってフィードバックを受けながら最終的なシステムを作り上げる方式である。従来の組み込みソフトウェア開発では見られなかったスタイルであるだけに,慣れるにはそれ相応の時間がかかる。

 実は,こうした特性を理解したうえでプロセスを選択しているプロジェクトは少なくないようだ。その証拠に,開発プロセスの選択理由と直面した課題には相関関係が見られる(図2[拡大表示])。例えば「品質確保が容易」という理由でプロセスを選んだプロジェクトは,品質の確保にはそれほど苦労していない。ただ逆に言えば,それとトレードオフ関係にある課題には苦しめられる。

 ここで重要なのは,ハードウェアに起因するトラブルにいかに対応するかという視点を持つことだ。組み込みソフトウェア開発における最大のリスクは,プロジェクトの約9割が直面するハードウェアに起因するトラブルである。ハードウェアの不具合をソフトウェアで回避したり,ハードウェアの仕様が変更になるといったことが起こり得る。プロジェクトの最重要項目を達成するのに適した開発プロセスを選択したとしても,こうしたハードウェアに起因するトラブルへの対応手法が盛り込まれていないと,それ以外の問題の発生を抑えられない。

アジャイル方式は未達率が高い

 では,実際に各プロセスにはどんな特性があるのだろうか。プロジェクトの未達率と開発プロセスとの関係を見ると,各プロセスの特徴がよく分かる(図3[拡大表示])。

 最も特徴的なのが,プロトタイピング方式が機能・性能や品質の確保に有効であるということ。プロトタイピング方式は,まず動くものを作って検証し,それを基に改善するという作業を繰り返す。このプロセスを採用するプロジェクトは,開発すべき機能や達成すべき性能が前もってはっきりしている場合が多い。明確な目標に基づいて検証した結果を次の開発作業にフィードバックするため,品質を確保しやすいと考えられる。

 これに対してアジャイル方式とインクリメンタル方式は,他のプロセスと比較して未達率が高い項目が目立つ。例えばアジャイル方式では,費用の超過が70%を超えている。期間の超過も,標準的な開発プロセスを持たないプロジェクトとほぼ同等の水準にある。インクリメンタル方式では,機能・性能や品質の未達率が群を抜いて高い。特に,機能・性能では他のプロセスの倍近くに達している。

 この二つのプロセスには,共通点がある。製品の全体像が,前もってはっきりしていない場合に適用されるケースが多いことだ。アジャイル方式は,実装すべき機能が明らかになっていないため,そのつど顧客に確認してフィードバックを受ける。市場のニーズがはっきりしていない場合に有効だが,そのぶん開発費用や開発期間にしわ寄せがいく。

 インクリメンタル方式は,実装すべき個々の機能は分かっていても,機能と機能とがどのように関連し合うかがはっきりしていない場合に用いられる。ともかく分かっている部分から順に積み重ねていくことになるので,システム全体としてうまく動作させるのが難しい。その結果,品質や機能・性能の未達率が高くなってしまう。どちらも企業システムの開発では注目されているプロセスだが,現時点では組み込み分野で効果的に適用するのは難しいと言えそうだ。

PMにコストをかけるべき

 一方,プロジェクト・マネジメント(PM)の重要性も忘れてはならない。望ましいPMとは,それぞれの工程で,誰が,何をすべきかをはっきりさせながら開発作業を進めていくことである。図4[拡大表示]によれば,アジャイル方式やスパイラル方式ではPMにかける工数が少ない傾向がある。ただこの二つに限らず,PMの重要性は今一度認識すべきだ。今回の調査では,PMにかけた工数の全体の平均は7%程度だったが,10%以上の工数をかけるとプロジェクトの達成率が上がる結果も出ている。PMに10%程度の工数を費やすことを目標にしてもよいのではないか。