プロセス監査の強化～やりきり感の見える化～

ボッシュ株式会社
パワートレインECU事業室
玉井　治久

1. はじめに

　私の所属する部署は、部品サプライヤー（以下B社）としてお客様の完成車メーカ（以下A社）へ納めるエンジン制御ユニットのソフトウエア（以下SW）を開発しています。 SWの品質を保つため、B社内でのValidation後、A社内でも、完成車としてValidationを行います。 また、B社内では、Projectへの開発中のプロセス履行監査（以下監査）を行っています。

ある時、そのA社のSW品質監査室の方から「B社さん、A社へ開示できないノウハウを含め詳細な内容に立ち入った監査をB社で完結することにより、不具合の防止をして下さい。ついては、B社さんの監査の仕組みのアセスメントをします」と言われました。

そこで私どもB社の監査のアセスメントをA社さんに行っていただきました。その際頂いたご指摘を基に、現在仕組みの強化中です。本編では今までB社の構築してきた監査の仕組みと、現在の強化の取り組みについてご紹介します。

2. アセスメント結果と指摘事項

　A社のアセスメント結果は、「監査の仕組みがあり、必要なことの大部分はカバーされている。 しかしプロジェクト全体としての『やりきり感』が見えず、そのやりきりの監査が出来ていないので、やりきりを監査する仕組みを構築して欲しい」とのことでした。 やりきり確認の監査の方法はB社へ一任されました。

B社の監査の方法はインタビュー形式で、作業成果物の確認を行っています。そのため、 今までのインタビュー形式では例えば、「コードレビューを行っていますか？」に対し、プロジェクトリーダー（以下PL）は数件のレビュー結果（エビデンス）を示して、「はい」と答えればよいことになっていました。つまり、レビューを行った事実の一部を見せればよく、プロジェクトが設計工程でやるべき全てのレビューとテストをやりきっているか確認できていませんでした。

　 　

3. やりきり確認の仕組み作り

　上記の『プロジェクトのやりきりの監査』構築のために、当初は監査担当者が直接エビデンスの確認を行うつもりでした。 しかし、エビデンスが入っているフォルダーを監査担当者が見ても、現在のプロジェクトの進捗に対し、全てエビデンスが格納されているのか判断できませんでした。
そこで、先ずプロジェクト自身で『やりきり』を『見える化』し、その姿を確認出来るようにしました。これによって、（１）今までは、担当者のレビューなどの工程スキップにPLが気付かなかった、または気付いても放置していたことによる不具合の流出への歯止めになると期待しています。また、（２）エビデンスチェックをインタビューの前に行っておくことにより、忙しいPL達とのインタビューの時間を短く出来ました。【図1】『やりきり』に関しては後述します。

上記をまとめますと下記のような方法になります。
『「プロジェクトの開発者が工程を遵守していること」を
「PLが確認（検図）していること」を
「監査部が監査する」』
また、監査部門として、開発プロジェクトへお願いした新たな品質目標は、以下の2点です。
（１）『工程不遵守による不具合ゼロ！』
（２）『工程未定義による不具合ゼロ！』

図1　完成度見える化表を使用した、やりきり度を確認する監査の仕組み　拡大図

　　

以下で、『やりきり』と『見える化』の具体例を示します。

　　

『やりきり』とは

　　

行動としてまずは、例えば、全て（10件）の顧客要件に対して、それぞれ（10件）テスト結果があるということです。設計工程の例で言えば『要件分析－設計－コーディング－単体テスト－結合テスト』の工程があり、それぞれの工程にレビューがあり、テストにはテスト報告書があります。これらの全てのレビューとテストが行われていること。 これが『やりきり』の第1ステップです。当たり前に『愚直』に行うことですね。

　　

『見える化』とは

　　

各顧客要件に対して設計工程での作業成果物（エビデンス）が全てあることを確認したことを『見える化』します。【図2】の例では、3件の顧客要件に対し、PLは各設計工程でのレビューとテストの作業成果物を検図した後に●をつけます。

『見える化』のポイントは、ステータスの良し悪しが一目でわかる ことです。【図2】の例では、顧客仕様No.0002の『結合テストRM（レビュー議事録）』の欄が空白（検図されていないand/orエビデンスがない）になっているのが一目でわかります。

　　

図2　工程やりきりの見える化表の例　拡大図

　　

　監査部署では、PLへ空白の理由を確認後、不適合項目として監査報告します。PLは報告に対して原因に対する是正処置をとります。

上記『見える化』例で考慮すべきことは5S（整理、整頓、清潔、清掃、躾）の精神だと思います。いつもきれい（全て●）になっていないと、空白があっても気にしなくなってしまうからです。

4. レビュー自体の『やりきり（品質）』は？

　これはきりの無い質問です。しかしまずはRM（レビュー議事録）を見て、「(1)レビューアは間違いを指摘できるレベルの経験者である。*1　(2)添付されているレビューチェックリスト（ノウハウとしての観点集）を全て確認（✓ฺ）している。　(3)レビュー時間がレビュー対象の量に対して妥当である。*2　(4)全ての指摘事項に対し対策が打たれている。」
上記4点でレビューの『やりきり』を確認します（上記4点が検図の観点であり、レビューの『良品条件』です）。

*1：『指摘できるレベルの経験者』の判断は現状、検図者であるPLに任せています。 勿論「対象領域での経験年数3年以上」など、定義できなくは無いですが、運用レベルに達していません。
*2：レビューの時間も検図者であるPLの経験値で判断しています。

5. 今後

　対策中で、まだまだ改善の余地があります。大きなポイントは以下の2点です。

・当事者のリーダー自身がどれだけ真剣 に確認しているか
プロジェクトの当事者ではない監査担当は、所詮エビデンスチェックで重箱の隅を突っつくことしか出来ません。どれだけ、当事者のリーダー自身が真剣 に確認しているかが最終品質に影響することに変わりはありません。 この活動のキックオフに際し、「監査の仕組みつくりは、開発者のプロセスへの理解と意識の向上とを並行して行う」と宣言して活動しています。

・監査担当者のスキル確保
エビデンスへのアクセスを確保し、いざとなったら監査担当者もエビデンスの中身の良し悪しを確認出来る技術レベルの確保が必要です。運用後の監査担当者の人選と教育計画も必要です。

6. 最後に

　『やりきり』という言葉は、無限∞なイメージがあります。きっと決まったゴールは無く、自分で限界を決めてしまってはいけないという心があるのかもしれません。また『やりきり』とは、行動（努力）を示す一方、『やりきった』ことの判断は結果でするものかもしれません。今回の対策例に対し、これで十分『やりきっている』のかという問いは、『工程不遵守による不具合ゼロ！』を維持できていますかという問いに代わるのかもしれません。ですから逆説的ですが、手段としての『見える化』だけをやり過ぎることにより工数ばかり掛かって結果の出ない『見せる化』にならないよう注意が必要だと感じています。