EDA・ソフトウエア 強いLSIやボードを設計するための
 

【福井信二が語る:第4回】構成管理・プロジェクト管理の原理原則

福井 信二=オムロン インダストリアルオートメーションビジネスカンパニー コントロール機器統轄事業部 技術部 技術開発グループ 技術専門職
2006/09/04 08:00
印刷用ページ

不具合の修正は影響範囲を意識

 適切な計画を立案して,混乱させることなくプロジェクトを遂行することに主眼を置くプロジェクト管理や構成管理に対し,プロジェクトが混乱に陥った場合に復活する手段として使えるのが不具合管理である。不具合の修正漏れや修正ミス,不具合修正の進捗が見えないといった問題に対処するための技術である。品質データの可視化にも有効だ。

 不具合管理の難しさは,不具合の量に起因する。ソース・コード1000行当たり2件の不具合というのは,かなり品質が高いプロジェクトといえる。それでも,ソース・コードが10万行になると200件,100万行になると2000件の不具合が現れることになる。混乱しているプロジェクトでは,この値が10倍にも20倍にもなってしまう。

 さらに,変更管理との関係もある。不具合を修正する場合,ソース・コードに手を入れる。つまり,利害関係者に影響を与える可能性を持った変更を実施することになる。変更の判断のための委員会を設置するという考え方が出てくるくらい,変更には大きなリスクが伴うのである。大量に発生する不具合の1つ1つについて変更を適切に管理するためには,コンピュータを使った自動化が必要になってくる。

 不具合の発見に伴う変更のフローは,各社ともそれほど大きく変わらないだろう(図6)。重要なのは,変更の影響範囲をいかに特定するか,という点である。変更の可否を検討する構成管理委員会によって,他のどの部分に影響を与えるのか,それも修正する必要があるのか,などを十分に議論しなければならない。この水準まで不具合管理を実施している企業は,現時点ではほとんどないだろう。

不具合の修正フローを明確にする
図6 不具合の修正フローを明確にする
発見した不具合だけを考えて修正を加えると,別の部分に不具合を生じさせる可能性もある。修正だけでなく,その修正が及ぼす影響を見極める作業フローを定義しておかなければならない。

 ここでは,不具合レポートの内容を的確なものにする努力が欠かせない。これを怠ると,変更の可否を適切に判断できなくなってしまう。不具合レポートに変更レビューの必要性の有無を明記したり,変更レビューの議事録を不具合レポートに追加したりすることが必要になる。このほか,変更の影響範囲を調べるテスト結果を不具合レポートに追加するというルールを設けるのも手である。

 不具合管理をコンピュータ化すれば,そこにデータが揃う。不具合の出方と修正の進捗状況,サブシステムごとの品質などのグラフが得られるようになる。構成管理のステータス&アカウンティングと同様に,状態を適切に管理することが,作業状況の統計的な把握を容易にするというメリットをもたらす。(連載のこの章終わり)

<技術者塾>
電源制御と主回路の定式化手法(2日間)
~状態平均化法によるコンバータの伝達関数の導出と制御設計の基礎について事例を基にわかりやすく解説~



これまでの電源設計の教科書にはない新しい見地から基礎理論および実践例について解説するとともに、「系の安定度」の問題点と解決手法についても解説します。今年3月に発刊した「スイッチング電源制御設計の基礎」(日経BP社刊)をベースに最新の内容を解説いたします。詳細はこちら

【日時】:2015年9月28~29日 10:00~17:00 (開場9:30)予定
【会場】:化学会館(東京・御茶ノ水)
【主催】:日経エレクトロニクス

コメントする
コメントに関する諸注意(必ずお読みください)
※コメントの掲載は編集部がマニュアルで行っておりますので、即時には反映されません。

マイページ

マイページのご利用には日経テクノロジーオンラインの会員登録が必要です。

マイページでは記事のクリッピング(ブックマーク)、登録したキーワードを含む新着記事の表示(Myキーワード)、登録した連載の新着記事表示(連載ウォッチ)が利用できます。

協力メディア&
関連サイト

  • 日経エレクトロニクス
  • 日経ものづくり
  • 日経Automotive
  • 日経デジタルヘルス
  • メガソーラービジネス
  • 明日をつむぐテクノロジー
  • 新・公民連携最前線
  • 技術者塾

Follow Us

  • Facebook
  • Twitter
  • RSS

お薦めトピック

日経テクノロジーオンラインSpecial

記事ランキング