おはようございます！マネジメントオフィスいまむらの今村敦剛です。
ISO9001:2015 各箇条解説シリーズ。今日から箇条8.3「製品及びサービスの設計・開発」の要求事項を詳細に見ていこうと思います。今日は箇条8.3.1「一般」と、箇条8.3.2「設計・開発の計画」を解説します。
動画でも解説しています（無料・登録不要）
箇条8.3.1「一般」と、箇条8.3.2「設計・開発の計画」の位置づけ
まずは今日解説する箇条の位置付けを見てみましょう。
箇条9「運用」は、全体的いうと、製品やサービスの作り込みの部分だというお話をしました。その中で箇条8.3は、お客さんのニーズを、実際の製品・サービスにおとしこむための「設計・開発」という位置づけでしたね。
箇条8.3は、細かく６つの項目から成り立っています。今日説明するのはまず箇条8.3.1「一般」ですが、これは設計・開発に関する全体的な要求事項です。つづく箇条8.3.2「設計・開発の計画」は、設計・開発を誰が、どうやって、どういうスケジュールで進めていくかという計画を作ることに対する要求事項です。
8.3.1「一般」の要求事項
では具体的な規格要求事項を見ていきましょう。
まずは8.3.1「一般」ですが、非常に短い要求事項です。短いんですが、読み飛ばしてはいけない大切なことが書いています。まず冒頭に「組織は、以降の製品及びサービスの提供を確実にするために」とありますが、これは設計・開発の定義を指しているとも言えます。
お客さんが「おいしいうどんを食べたい」という要望を言ってきたとします。その「おいしいうどん」というものを作るためには、もっと内容を具体的にしないといけませんよね。うどんの麺はどこそこ産の小麦を使うか、水は何cc入れるか、だしは何で取るのか、どこ産の鰹節を何ぐらむ使うのか、という具合に、詳細なレシピに落とし込まないと、うどんづくりはできません。
ということで、お客さんのざっくりとした要望である「おいしいうどんがたべたい」というものを、レシピに落とし込むプロセスが設計開発です。詳細なレシピに落とし込まなければ、「おいしいうどん」という製品を、確実に提供できませんからね。
つまりこの箇条8.3.1は、お客さんが言ってきたことを、こちら側（組織側）で具体的に細かく落とし込まなければ、ちゃんとした製品・サービスが提供できないという場合は、設計・開発をやりなさいと言っているんですね。細かく落とし込むことが、その後のプロセス（具体的には実際に製品やサービスを作り込むプロセス）に大きな影響を与えるからです。
8.3.1「設計・開発の計画」の要求事項
続いて8.3.2です。これは設計・開発の計画を作りなさいという要求事項です。
a)からj)までたくさんあって嫌になりますが、8.3.2項の最初の行には「設計・開発の段階及び管理を決定するに当たって，組織は、次の事項を考慮しなければならない。」と書いているように、ここのa)からj)までについて考える必要はありますが、考えた結果として、除外することもできます。
また、文書化の要求事項ではありませんので、「設計・開発計画書」みたいなものを作らないといけない、というわけではありません。（必要ならば作ります）
設計・開発の段階及び管理とは、具体的にはどういうものを指しているのでしょうか。以前もこの動画の解説で、設計開発の流れは下記の図のようになっているという話をしました。これが全体的な設計・開発の流れですが、実際にはこの赤枠の部分では、もっと細かな段階に分けられるはずです。
誰がいつ、どういう設計開発行為をやって、その設計開発でよいのかどうかという評価や判断を、誰がいつやるか、評価結果が思わしくなければどうするか、みたいな細かな作業項目があるはずですね。「設計・開発の段階及び管理」とは、そうした詳細なプロジェクト計画のようなものを指していると考えるとわかりやすいでしょう。
では、a)からj)までを簡単に解説したいと思います。
まず、a)では設計・開発活動の性質、期間及び複雑さを考えて計画を作りなさいと言っているわけですが、ダムとかトンネルとかを作る場合は、いろんな人が関わるでしょうから、とても複雑な計画になりそうですよね。ところが、ふつうにきつねうどんを提供しているうどん屋が、冷やしきつねうどんという新製品を作るという場合ならば、そんなに複雑な設計・開発の計画は不要でしょうね。そうした内容に応じて設計・開発の計画は変わるものだから、設計・開発の内容を考慮しなさいということがa)で書かれています。
b)以降は、具体的な計画の中身について触れた部分と言ってもよいでしょう。B)は、どういう順を追って設計・開発をすすめるのかというスケジュールみたいなものと言ってもよいでしょう。レビューも含むとありますが、ここでいうレビューは、開発を次の段階に進めていいかどうかの評価・判断のことですので、どういうテストが必要で、どういう要件を満たしたら次の段階に進むのかといったところも考えなさいということですね。
c)は検証と妥当性確認活動も計画を作る上で考慮しなさいと言っています。検証と妥当性確認というのは、ISO9000で定義されています。検証とは、客観的証拠によって要求事項が満たされていることを確認することで、例えばお客さんからの図面に寸法やが書かれていたとすると、その寸法通りで公差内におまっているかどうかを、測定して確認するようなことを指します。一方、妥当性確認とは、意図された用途・適用に関する要求が満たされているかどうかを確認すること、という意味があります。使い勝手とか、安全性とか、具体的な数値・仕様書などで表しにくいことが満たされているかどうか、ということですね。こうした要件がなんであるかを考えなさいということです。
d)については、責任と権限ですから、誰がどんな作業をやって、開発を次の段階に進めていいかどうかの評価・判断を誰がやるのかを考えなさいということですね。
e)は、社内・社外に限らず、どういう人を巻き込んで、どんなスキルや機器、情報などを使って設計・開発をすすめるかを考えなさいということですね。
f)はちょっとイメージがわきませんが、設計・開発に関わる人たちのコミュニケーションのことだと思えばわかりやすいです。どんな会議体やコミュニケーション手段で進捗を確認したり、次の段階に進めていいかどうかの評価・判断したりするのか、という感じでしょうか。多国籍な開発環境だと言語の問題などもあるでしょうね。
g)はお客さんを設計・開発に巻き込むかどうか、ということを考えなさいということですね。場合によっては、ユーザーテストなどをする必要もあるでしょう。
h)もちょっと難解ですが、製造段階やサービスの提供段階、アフターサービスの段階のことも考えなさいということですね。設計はしたけど複雑すぎて作りにくいとか、保守やメンテがしにくいというのではよくないですから、現場での作りやすさなども考えて設計・開発しなさいということですね。
i)もちょっとわかりにくいですが、顧客や利害関係者が、どのくらい我が社（組織）の設計・開発の管理レベルを期待しているのかを考えなさいということですね。設計開発に関してお客さんが逐一報告を求めたり、設計開発の評価や判断に関与したりしてくるケースもあるでしょう。そうしたお客さんの関わり方に応じて、こちらの設計開発計画のあり方も変わってきます。
最後にj)です。要求事項を満たすかどうかの証拠を文書化しなさいということです。これは実はこのあと、8.3.5の設計開発からのアウトプットなどでも似たようなことが要求されています。この8.3.2のjは、それ以外、つまり8.3.5などの、他の設計開発の箇条で示された要求以外で、必要ならば文書化した情報を残しなさいといっていると解釈できます。
設計開発というプロセスは、製品の設計のよしあしはもちろんですが、その後の製造品質のよしあしにも深く関わる重要なプロセスです。その重要なプロセスを確実に行うための原点が、今日解説した設計開発の計画です。設計・開発の成否は計画のよしあしが握っているといっても過言ではないでしょう。