デスマーチ・プロジェクトでの正しい手の抜き方：＠IT MONOistゼミナール・レポート 〜品質向上による“コスト削減の最適化”〜

高機能・多機能化に加え、「品質向上」「コスト削減」「納期短縮」が強く求められる組み込み業界。小手先の対応では太刀打ちできない。

[八木沢篤，＠IT MONOist]

――高機能・多機能化に加え、短納期、高品質を求められる組み込みソフトウェア業界。ただでさえ、厳しい要求に応えなければならない中、これに追い討ちをかける昨年からの世界経済情勢の悪化……。これまで以上のコスト削減も避けては通れない。機能的な差別化をしつつ、「品質向上」「コスト削減」「納期短縮」を追い求めなければならない厳しい時代を生き残るには、小手先の対応ではとても太刀打ちできない。

　われわれは、こうした課題にどのような対策を打つことができるだろうか？

　2009年7月24日、東京コンファレンスセンター・品川にて、＠IT MONOist編集部主催の＠IT MONOist ゼミナール ソフトウェアテスト夏ゼミ「品質向上による“コスト削減の最適化”」が開催された。プログラムは、基調講演、セッション、パネルディスカッションで構成され、さまざまな視点から“品質向上”と“コスト削減”について講演が行われた。

［基調講演］デスマーチ・プロジェクトでの正しい手の抜き方

画像1　東海大学 大学院 組込み技術研究科 助教授（工学博士） 山浦 恒央氏

　基調講演『組み込み系デスマーチ・プロジェクトのテストでの正しい手の抜き方』というインパクトのあるテーマで登壇したのは、＠IT MONOist「組み込み開発」フォーラムで好評連載中の「山浦恒央の“くみこみ”な話」でおなじみ、東海大学 大学院 組込み技術研究科 助教授（工学博士） 山浦 恒央氏だ。

　2000年以降、組み込みソフトウェアの開発規模が爆発的に増加。ソフトウェアの巨大化・複雑化、短納期化が進み、世の中にデスマーチ・プロジェクトが誕生し、ソフトウェア開発現場を悩ませ続けているという。こうした現代のソフトウェア開発の課題に対し、山浦氏は“デスマーチ・プロジェクトでの正しい手抜き”の基本ポイントを3つ紹介した。

1. 混乱してから苦し紛れに手を抜くのではなく、プロジェクトの立ち上げ当初から計画的に手抜きを考えること
2. スケジュールの遅れや品質の現状を定量的に把握すること
3. どれだけの時間と人員を投入すれば目標の品質、出荷スケジュールを達成できるのかを定量的に見積もること

　「プロジェクトのリソース（時間、予算、人員）を把握し、それに応じてどこまで実現できるのかを計画することが大切。行き当たりばったりの対応ではなく、事前に（いい意味での）手抜きのバリエーションを用意しておけば、プロジェクトの状況変化に対応できる。また、感覚的に大丈夫だろうという判断ではなく、定量的にリソースを押さえておくことが重要。これがないと根拠のある手抜きができないし、関係者への説明・説得はできない。プロジェクトマネージャーは、最低でも週に1回はプロジェクトの見積もりを行わなければならない」と山浦氏。

画像2　デスマーチ・プロジェクトとは？

　デスマーチ・プロジェクトにおいて、一番厳しいリソースは「時間」だと、山浦氏は指摘する。そして、時間的制約のしわ寄せは必ずといっていいほど「デバッグ」と「テスト」にくるという。納期が目前にせまった状態で、品質を確保しなければならない現場はまさに戦場といえるだろう。

　山浦氏はデスマーチ・プロジェクトの対策として、『トリアージュ（Triage）的な手法』を紹介した。「人を増やさずに、限りあるリソースを“優先順位”の高いところへ割り当てる考え方。これに加えて、SLIM（Software Lifecycle Management）の『最短開発期間』をベースにプロジェクトを見積もることで、本来必要なリソースを把握しておくことも重要だ」（山浦氏）。

画像3　デスマーチ・プロジェクトの対策

　「優先順位を付ける項目は『機能』と『品質』」と山浦氏。機能なら機能ごとに、品質ならテスト項目ごとに「必須」「必要」「希望」のように分類する。

　では、この優先順位付けの作業をいつ行うのか。山浦氏は「プロジェクトの遅れが顕著になってからでは手遅れ。要求定義・機能設計の段階で、機能の優先順位を決め、これを基にテスト項目設計の優先順位を決めること」と説明した。

　このように山浦氏は講演中、トリアージュ的手法の考え方を披露し、デスマーチ・プロジェクトでの正しい手の抜き方の実践方法を紹介した。プロジェクトがいつもデスマーチ状態で出口が見えない中、ただがむしゃらにゴールを目指し続けている……。そんな方は、まず、プロジェクトの初期段階で、機能・品質から優先順位を決め、手抜きのバリエーションを用意すること。目標とする機能・品質の達成に必要なリソースを把握すること。プロジェクトを定期的に、定量的に見積もること。この3つを実践してみてはいかがだろうか。

	関連リンク：
⇒	連載記事「山浦恒央の“くみこみ”な話」

［セッション］使えるコーディング規約の作成と円滑な導入

　続いて、解析ツールの販売・導入を行っている富士通ソフトウェアテクノロジーズ、東陽テクニカ、コべリティの3社が登壇。それぞれの立場から、組み込みソフトウェアの品質向上に必要な具体策について講演を行った。

　本稿では、富士通ソフトウェアテクノロジーズ 第一Webソリューション基盤サービス部 佐々木 孝次氏の講演『使えるコーディング規約の作成と円滑な導入』について紹介する。

画像4　富士通ソフトウェアテクノロジーズ 第一Webソリューション基盤サービス部 佐々木 孝次氏

　講演の冒頭、佐々木氏は組み込みソフトウェアの品質の実態について「製品出荷後の不具合の約8割は『ソフトウェアの不具合』によるもの。この不具合が作り込まれるのは、当然ながら『ソフトウェアの実装・単体テスト』段階」と言及した。

　通常、プロジェクトにおける人的リソースは、ソフトウェアエンジニアと呼ばれる職種が大半を占める。佐々木氏は「コーディングに多くのエンジニアが携わるということは、スキル・経験による品質のバラつきだけではなく、ソースコードの書き方のバラつきも発生する。その割には、実装時のレビューが十分に行われていないのが現状だ」と実装工程での問題点を指摘した（注）。

※注：実装工程での問題は、ソースコードの質以外にも、製品要求、設計、開発環境などに起因するものもあるが、本講演では「ソースコードの作成」にフォーカスしている。

　こうした問題を解決に導く手段として、佐々木氏が紹介したのは、

1. 経験者のノウハウや統一した書き方を規定したコーディング規約の作成
2. コーディング規約の遵守をチェックする体制作り

の2点だ。

　一見、当たり前のことで、どこの企業でもそのメリットを十分に理解し、取り組んでいるように思えるが、「コーディング規約の運用に目を向けると、『過去に作られた規約がそのまま運用されているので、現在の開発にマッチしていない』『全社ルールとして規約があるが、個々のプロジェクトに適用しづらい』などの課題があり、形骸化していることがよくある」と佐々木氏は指摘する。

　こうした現状のコーディング規約を無理やり遵守してもソースコードの品質向上は図れない。あらためて、コーディング規約の目的を整理し、プロジェクト要件に合ったコーディング規約を整備すること。また、コーディング時はもちろんのこと、レビュー時にも規約を遵守しているかどうかをチェックする運用体制・ルールの整備が必要だという。

画像5　コーディング規約が保持すべき内容

　ここまできちんと整備できれば品質向上につながるが、運用時の課題は残る。特に、人手によるコーディング規約のチェックは、どうしても効率が悪く、抜け・漏れ、チェック精度のバラつきが発生してしまう……。

　ここで、効果を発揮するのが静的解析ツールだ。同社が提供するソースコードの静的解析ツール「PGRelief 2009（以下、PGRelief）」は、プログラムのソースコードをコーディング規約に即して静的解析し、「データ構造」と「処理の流れ」に基づいて欠陥を指摘し、解決策を提示するツールだ。プロジェクトで用いるコーディング規約をPGReliefに設定することで、関係者全員が同じ規約を用い、同じ精度でチェックできる。また、PGReliefは違反数の定量的な把握にも力を発揮し、指摘件数をカテゴリごとに表示するなど、違反ルールの集計が容易に行える。

画像6　PGReliefによる違反ルールの集計

　このように、静的解析ツールを活用することで、チェック時間の短縮や抜け・漏れ、チェック精度のバラつきが防止でき、さらに定量的な違反数の把握が可能となる。

静的解析ツールを活用した運用方法の改善

• 自己レビューは静的解析ツールでコーディング規約のチェックを実施
• 対面レビューは、機能漏れや実現方式についてのレビューに専念
• 遵守監視は、静的解析ツールの結果を集計することで把握

　最後に、コーディング規約の運用について佐々木氏は「コーディング規約は1回作れば終わりというものではない」と説明。「効果が低いルールや扱いにくいルールはないか、運用時に負担を感じた作業はないか、などのコーディング規約の振り返り・見直しを実施することも重要」と来場者にアドバイスした。

画像7　PGReliefによる違反ルールの集計

	関連リンク：
⇒	富士通ソフトウェアテクノロジーズ
⇒	PGRelief C/C++
⇒	PGRelief C/C++ 体験版ダウンロード
⇒	PGRelief Java
⇒	PGRelief Java 体験版ダウンロード

［パネルディスカッション］ソフトウェア品質の向上とコスト削減の2匹は追えるのか

画像8　ティアック プロダクト開発室 國方 則和氏

　ソフトウェアテスト 夏ゼミの最後を締めくくったのが、ティアック プロダクト開発室 國方 則和氏（モデレーター）と、基調講演で登壇した山浦氏、富士ゼロックス デバイス開発本部 デバイスコントローラプラットフォーム開発部 杉浦 英樹氏、エクスモーション シニアコンサルタント 斎藤　賢一氏の3名のパネラーによるパネルディスカッションだ。

――「品質とコストが求められる中、現場ではどのような問題を抱えているのか？」（國方氏）。

斎藤氏　「現場では“納期”が第一。そのため、作り込みが優先となり、テストがおろそかになる傾向がある。その結果、バグを修正する手戻り・コストが発生している。こうした負のループが発生しているのが現場の実情である。また、過剰品質を求める傾向もある。無駄なテストをしていることもしばしば……。テストの基準も見直すことも大切だと思う」。

杉浦氏　「品質向上もコスト削減も実現すべきものとされているが、改善率やリソースの数など、経営側と現場側とでギャップがある。また、ソフトウェアの生産性に対する基準や品質に対する基準が“あいまい”である点が現場の問題として挙げられる」。

山浦氏　「勘や経験、もしくは過去の類似案件からプロジェクトを見積もることがよくある……。これでは品質向上・コスト削減が強く求められているいま、正確な判断ができない」。

画像9　エクスモーション シニアコンサルタント 斎藤　賢一氏

　山浦氏の基調講演にもあったが、納期という時間的制約のために、本来求められている品質が不十分となり、その修正対応でコストが余計に掛かってしまう。斉藤氏の言葉を借りると、まさに『負のループ』が起きているわけだ。では、正しい納期を設定するにはどうしたらよいのだろうか。また、そもそも正しい納期とは何であろうか。ここからは、斎藤氏が『開発者』、山浦氏が『テスト設計者』、杉浦氏が『プロジェクトマネージャー』の視点でそれぞれの考えを披露した。

――「では、品質やコストを左右する“納期”についてだが、そもそも納得できる納期設定はできているのか？ 根拠のない納期……。これを防ぐためにそれぞれの立場で何ができるのか？」（國方氏）。

斎藤氏　「急な作業依頼が発生するケースがよくあるが、開発者としては、それによってどのような作業が発生し、どれくらいの影響があるかを明確に把握しておく必要がある。一機能を担当する開発者であっても“正確な情報を基に見積もり”を行い、関係者に説明・説得できる準備を日ごろから行うことが重要」。

杉浦氏　「発注元からの要求と開発者たちのスループットを理解したうえで、調整役に徹すること。これがプロジェクトマネージャーの大切な役割だ。調整を行ううえで大切なのは、自分の部下や関連部署のリソース、スループットの把握。そして、シビアに計画・見積もりを行うこと。まずは、“事実のデータ”をつかむことが第一」。

画像10　山浦 恒央氏

山浦氏　「納期のしわ寄せは、最終的にテスト・デバッグ工程にきてしまう。与えられた納期でどこまで実施できるのかを明確に把握・説明できるようにするためには、あらかじめ、機能やテスト項目に優先順位を付け、“定量的な管理”を行う必要がある」。

　この議論を通じ、品質とコストの両方を追い求めるには、「正確な情報」「事実のデータ」「定量的な管理」に基づく根拠のある見積もり、納期設定が必要だということが見えてきた。

　しかし、現実は厳しい……。いくら事実のデータを基に見積もりを行い、納得できる納期を算出したとしても、発注元や上司から与えられた根拠のない納期を覆すことは難しいだろう。最後に、モデレーターの國方氏は次のような質問をパネラー3名に投げかけた。

――「プロジェクトの理想像はイメージできたがハードルは高い……。では、明日からすぐに始められることはあるか？」（國方氏）。

画像11　富士ゼロックス デバイス開発本部 デバイスコントローラプラットフォーム開発部 杉浦 英樹氏

　この問いに対し、3名のパネラーは来場者へ次のようなメッセージを送った。

斎藤氏　「開発者の皆さんは、例えば急な作業依頼を受けたときに、『何のために必要なのか？』という疑問を持つことを心がける。そして、作業の背景を理解し、納得することからはじめること。また、自分が担当している機能（ソースコード）の定期健診をすることも正しい情報を得るためには大切」。

杉浦氏　「プロジェクトマネージャーの立場の方は、起こっている事実をきちんと把握すること。解決を急ごうとすると、議論の中に推測や推論が混在することがよくあるが、急がば回れの精神で、事実を基に議論をすることからはじめるべき。また、5年、10年先を考え、現状の課題は何か？ できること、できないことは何か？ を考えること」。

山浦氏　「テスト設計者は、テスト技法ばかりではなく、テストの運用法も勉強するとよい。また、テスト自身のバグというものも存在するので、テスト項目の品質チェックやテスト項目の優先順位付けなどを定期的に行うこと」。

画像12　パネルディスカッションの様子

---

　「発注元の要求をそのまま聞かないと失注してしまう」「時間的に余裕がない現状で手間の掛かることなどやっていられない」など、現実と理想のギャップは大きいかもしれないが、何もしなければ負のループからの脱却どころか、品質向上とコスト削減を追い求めることはできない。いま置かれている現実に不平や不満を口にするのであれば、まず、明日から自分たちで何ができるのかを模索し、それを信じて自ら実践してみてはいかがだろうか。本稿と今回のセミナーがそうした取り組みの一助になれば幸いである。