「実践・ソフトウェアのISO9000」（日本能率協会マネジメントセンター：新倉忠隆著）の内容から抜粋しています．（1994年版のISO9001の解説です．出版当時のTickITにも対応しています．）

４．４　設計管理

品質システム構築のポイント

• 　設計管理の手順を「ソフトウェア開発標準」のような文書名とし，利用者から見て開発工程全般がカバーされていることがわかるようにするとよい．
• 　「ISO9001をソフトウェア品質システム審査登録に適用するための解釈に関する見解」（日科技連/SPC研究会：1996/6発行）に基づいて品質システムを構築する場合でも，『検証活動のためのテストを実施する場合には，「ISO9001 4.10 検査・試験」を適用する』というように決めれば，テスト工程に対する要求事項が明確になる．
• 　品質を作り込むためには，フェーズごとの検証が重要である．逆に検証を行わなくても品質が作り込めるフェーズがあるとしたら，開発工程の見直しを行い，そのフェーズを次のフェーズと一つにするなどの工夫をするとよい．
• 　システム製品やハードウェアに組込まれるソフトウェアなどは，テスト活動や量産のための試作の段階などで，機能や生産性の観点から修理の担当部門や工場の生産部門などから変更を求められることもあり，そういった部門とのインターフェイスも考慮する必要がある．
• 　レビューの実施方法にはいろいろなやり方がある．自由な発想で行うことが重要なレビューは，手順を文書化する際に基本的なルールを規定するだけにしておき，実質的な内容はガイドとすることを奨める．
• 　デザイン・レビューの記録は品質記録なので，関係者が容易に取り出せるように管理する必要がある．従って，電子メールでやりとりした記録は，サーバーなどの保管エリアに格納しておくか，印刷したものを品質記録として管理する必要がある．
• 　組織が企画して開発するソフトウェアパッケージの妥当性確認は，組織が設定した使用者のニーズや要求事項に適合していることを確かめればよい．通常，こういった確認は，総合テストやシステムテストなどの開発の最終段階で行うテストの中に組み込まれて実施されていると判断される．このような場合には，妥当性確認の結果の報告書（記録）でそれらのテストのどのテスト項目で確認したかを示せばよい．

審査に関連して

• 　設計作業の割当てに関して，「設計作業を行うには何か資格が必要ですか」とか「この設計作業に割り当てられている○さんの教育・訓練の記録を見せてください」というように，プロジェクトの活動の監査に関連して人事的管理の側面の監査を行うこともある．
• 　TickITに基づく審査では，進捗レビューの記録を品質記録として管理していることが前提となっていて，記録の提示が要求されることがある．（審査機関による．）また，記録中に何か実施すべき作業項目が記述されているような場合に，誰が，いつまでに，何をするかを記録していなかったり，完了の確認がされていないと， 「4.14.2 是正処置」に関する不適合を指摘されることがある．
• 　デザインレビューの参加者に「どのようにレビューするのか」と尋ねることがある．普段きちんと実施していても，予想していなかった漠然とした質問に面食らって答えられない人がいる．デザインレビューの手順を規定してあれば，それに従って実施すると答えてもよいし，手順の中に書かれている一部を引用して説明してもよい．監査人はいろいろな情報を引き出すために質問することもあるのであわてないことである．
• 　変更要求について記述したもの（変更要求票）からどのソースコードを修正したかを調べ，そのソースコードを見ながら別の観点の監査に移ることもある．例えば，そのソースコードの作成時に適用されるプログラミング規約を守っているかを調べたり，そのソースコードがどのバージョン/リリースに使用されているかを調べたりする．

2000年版では

　大きく変わった点は，手順の文書化が要求事項ではなくなった点であるが，ソフトウェアの開発の基本的なやり方は文書化が必須であろう．ソフトウェアの開発は，人の作業が主体となるだけに品質の作り込みのためには，製品実現の方法を誰にもわかる形で定義しておく必要があるであろう．

　特に注意すべき点は，設計・開発のレビュー，検証および妥当性確認の結果の記録には，結果として必要となった処置があればそれを記録しておくということである．

以上
１９９５，２００１　新倉忠隆