製品開発プロセス定義3つのポイント
先日、某電機メーカーのプロセス改革推進リーダーと意見交換した際に興味深い発言を聞きました。「過去にISOやCMMIなどを参照しながらプロセスを整備してきたが、そのときは形式的に標準書を整備しただけだった。その反省に立って現在は現場主導でプロセス改善を進めたが、今度はどのように標準書に反映したら良いか分からない・・・」あなたの会社でこのようなことは起きて無いでしょうか？
ITIDではITID INDEXを用いてお客様のプロセス定義度や実行度を調査し、業務の状態を4象限で確認しています（下表参照）。
冒頭の場合では、過去はプロセス定義度が高く、実行度が低い【形骸化】状態、現在は実行度が高く、定義度が低い【人依存】状態だと言えるでしょう。製品開発の現場にはこのような【形骸化】や【人依存】状態のプロセスもありますが、定義度と実行度ともに高い【組織的】状態のプロセスも存在します。【組織的】状態のプロセスは、作業が定型化されていることを意味し、一定の作業品質を保てる確率が高まるので良いプロセスと言えます。
ITIDが過去に調査を行った多くの企業には「プロセス定義書」「作業標準書」と呼ばれるものが存在しています。にもかかわらず【組織的】である場合と、そうでない場合に分かれてしまっているのです。この違いはどこからくるのでしょうか？
プロセスが【組織的】であるということは、定義、実行、改善の3つのステップを経て「実行すべきもの」としてプロセスが組織に根付いていることを意味しています。このうち【組織的】プロセスにするために最も重要なのは定義のステップです。なぜならば定義がうまくいかなければ、そもそもプロセスが実行されず、プロセスが組織に根付くために必要な３つのステップにならないからです。
では、プロセス定義を良いものにするにはどうすれば良いでしょうか？プロセスを定義する上で重要な3つのポイントを、調査中に見かけた失敗事例を通してお伝えします。
1.作業の目的と位置づけを明確にする
エレクトロニクスメーカーA社では、簡易の業務フロー図を用いて作業の概要を示し、プロセス定義としていました。これでは、実施する作業の過程が明確になっておらず、プロセス実行が人依存になってしまいます。プロセス定義では、フェーズよりも細かい単位で、どの作業を何のためにどのタイミングで実施するのかを明確にする必要があります。この場合は、業務フロー図だけでなく、開発パターンに応じたマイルストンレビューやレビューに向けて作成する設計書や検討すべき項目チェックリストなどのドキュメント体系を作るとよいでしょう。
2.実現性の高い作業を具体的に記述する
精密機械メーカーB社では、頭の中で考えた「あるべき姿」を書いた業務フロー図や詳細な作業記述書をプロセス定義書にしました。ISOやCMMIなどの規格を読み込み、必要な作業を事細かに決め、マニュアルまで整備したのです。このようなプロセス定義は、作成時はすばらしいものに思えるのですが、運用時に実現性が低くなるため、全く参照されなくなります。この場合、自分たちが実施できる作業を「タスク」として具体的に記述し、それらを組み上げて業務フロー図とし、その後に規格との対応を明確にするとよいでしょう。
3.運用を意識して事例やノウハウを記述する
情報システムサービス会社C社では、業務ステップごとに作成する書類（設計書など）を定義し、書くべき項目のみを明確にした書類の雛形を用意しました。これは良さそうですが、業務ステップが一般的な場合は読まなくても分かる一方、雛形の項目は抽象的すぎて分かりにくいものです。雛形が使われなくなり始めたら要注意。形骸化への道を歩み始めていると言えます。プロセスは定着させて作業品質を一定以上に保つことが最終目的になります。そのためには、他人にとって使いやすく、使うことによってメリットが出るように、作業成果物の肝になる部分が明確になっていて作業時のノウハウが入っている必要があります。
プロセスは誰もが一定の作業品質を保てるように作成するものです。上述のように【作業の目的と位置づけを明確にする】【実現性の高い作業を具体的に記述する】【運用を意識して事例やノウハウを記述する】の3つのポイントに留意してプロセスを定義することで、プロセスが「実行すべきもの」と設計者に意識され、組織に定着していきます。せっかく時間をかけて定義するのであれば、設計者全員が使いたくなるプロセスを作りたいものです。
執筆：前田 直毅
※コラムは執筆者の個人的見解であり、ITIDの公式見解を示すものではありません。
