PR

図1●レビュー/インスペクションの方法と手戻り率の関係
図2●レビュー/インスペクションの観点の工程別の違い
図3●プロジェクトで採用した開発プロセス
図4●開発プロセスの選択理由
 平均的なソースコードの行数は100万行で,新規開発で30万行にのぼる。大規模化が進む一方の組み込みソフトウェア開発現場は人手不足に悩んでいる。現在開発者は国内で約17万5000人ほどだが,約7万人足りない。こうした状況が,組み込みソフトウェアの品質低下を招いている—。2005年6月,情報処理推進機構(IPA)のソフトウェア・エンジニアリング・センター(SEC)が公開した「2005年版組込みソフトウェア産業実態調査報告書」は,組み込みソフトウェア開発の現場が直面している困難な状況を浮き彫りにした。

 同時に,こうした状況を打開するには,開発プロセスの整備や適切な適用が不可欠であることも明らかになった。腰を据えて,早急に改革に取り組まなければならない。

手戻りの多さが失敗につながる

 調査は,組み込みシステムにかかわる企業約250社,開発プロジェクト約280件,技術者約1400人を対象に実施した。全体を通して,開発現場が多くの課題に直面している実態が明らかになった。

 例えば開発プロジェクトにおける,品質,機能/性能,開発期間,開発費用を当初の計画と比べた順守度合い。未達成率は,品質で1/3,機能/性能で1/4ほど。開発期間は約半分,開発費用にいたっては約6割が超過したと答えた。

 こうした状況を生み出す大きな原因の一つが,手戻りだ。ある工程のテストで,それより前の工程で作り込まれた不具合が見つかり,作業をやり直すことを指す。手戻りの多さは,品質の低下や開発期間と開発費用の超過につながる。

 手戻りを減らすには,各工程ごとに実施すべき作業を確実にこなすことが大切である。例えばレビューやインスペクションをきちんと実施すると,手戻りは大幅に減る(図1[拡大表示])。レビューやインスペクションをまったくしないプロジェクトの手戻り発生率は90%近いが,開発者以外の第三者がすべてを実施した場合は40%強。50ポイントほど差がある。

 特に,第三者によるレビューが非常に有効であることも明らかになった。各開発者がすべてのレビューを実施した場合と,第三者が特定部分のみレビューしてそれ以外の部分は実施しなかった場合を比べると,手戻り率はあまり変わらない。自分で作ったものを自分でレビューしても,不具合は見つかりにくい。第三者の目線による客観的なチェックが必要だ。

 また,当然ながらレビューの内容も重要である。工程に応じて,適切なレビューの観点を持たなければならない(図2[拡大表示])。機能性や使い勝手は,企画や要求分析などの最上流と,テストのような最下流の工程で重視すべきである。下流に進むに従って重要になるのが信頼性。効率性,機能性,移植性のように,設計や実装の工程で重視すべきものもある。

 このように,レビュー/インスペクションだけを見ても,誰が,いつ,どのようにそれを実施するかがプロジェクトの成否に大きな影響を与えることがよく分かる。ソフトウェア開発の手順をきちんと決めて確実に進めていかなくてはならないこと,つまり開発プロセスの導入に真剣に取り組まねばならないことが,データで裏付けられた。

開発条件に適したプロセスを

 もちろん,現状でも多くの現場で何らかの開発プロセスは導入されている。調査によれば3割以上のプロジェクトがウォータフォールを採用し,次にスパイラルが続く(図3[拡大表示])。新興の開発プロセスとして話題にのぼることが多いアジャイルも,わずかだが採用されている。

 重要なのは,どのような理由でそれらを選択したかである(図4[拡大表示])。実は,最も採用数が多いウォータフォールは,必ずしも開発の条件に適しているから採用されているというわけではない。「プロジェクト・メンバが慣れている」「社内部門の標準プロセスだから」といった消極的な理由が多い。古くから使ってきたためマネジメントしやすいという利点はあるが,現状に適しているとは限らないことに注意すべきだろう。

 それ以外の四つは,開発条件に適しているという積極的理由があって選ばれることが多い。中でも,組み込みソフトウェア開発の実情に即していると思われるのがスパイラルとプロトタイピング。どちらも,まず動くソフトウェア(プロトタイプ)を作って動作確認と評価をし,必要な改善を加えるという作業を複数回繰り返す。実現すべき機能ははっきりしているが技術的に不安な要素があり,作ってみなければ判断できないという場合に適したプロセスである。ハードウェアの厳しい制約の中で,先進的な機能を次々に搭載することが求められる組み込みソフトウェア開発にはなじみやすい。

アジャイルの利点を生かすのは困難

 これに対してアジャイルやインクリメンタルは,技術的には枯れているが実現すべき機能がはっきりしないときに有効とされる。システムに対する要求仕様が明確でないため,開発したものを逐次顧客に使ってもらってフィードバックを受けながら最終的なシステムを作り上げるのがアジャイル。インクリメンタルは,実現すべき個々の機能は分かっているが機能間の関係が前もってはっきりしないため,ともかく主要な機能から順に積み上げていくというやり方だ。

 この二つはどちらも,企業情報システムの分野ではこのところ注目を集めている。しかし組み込みシステムでその利点を生かすのはたやすいことではない。この問題については,次回で述べる。

(田丸 喜一郎=情報処理推進機構 ソフトウェア・エンジニアリング・センター)