偶然なのか、ひょっとしたら業界の流行なのかわかりませんが、最近、複数のソフトウェア開発業の会社さんから、ISO9001のお問い合わせや引き合いをいただくことが重なりました。

それならばということで、ソフトウェア開発業とISO9001との関係について書いてみます。

ソフトウェア開発の業務プロセスとISO9001の要求事項との大まかな関係は以下の通りです。

業務プロセス 成果物 ISO9001要求事項
見積り・受注 見積書、契約書 7.2.1 顧客要求事項の明確化
・顧客の要求を明確にする
開発計画 プロジェクト計画書 7.1 製品実現の計画
・製品実現に必要なプロセスを計画する
要件定義 要件定義書
ソフトウェア要求仕様書
7.2.1 製品要求事項の明確化
・製品要求を明確にする
7.2.2 製品要求次項のレビュー
・製品要求を確認する
設 計 アーキテクチャ設計書、詳細設計書 7.3 設計・開発
・設計・開発の段階を明確にする
・段階に応じて検証やレビュー等を行う
実 装 単体テスト仕様書
結合テスト仕様書
7.5.1 製造及びサービス提供の管理
・製造→リリース→引渡し後の活動
試 験 単体テスト報告書
結合テスト報告書
8.2.4 製品の監視・測定
・適切な段階での製品検査の実施
8.3 不適合製品の管理
・不具合の改修
インフラ構築 総合テスト仕様書・報告書
ハードウェア稼働報告書
7.4 購 買
・外注先を評価・選定する
・受入検査の実施
7.5 顧客支給品の管理
・客先の機器、設備を適正に管理する
リリース プロジェクト完了報告書、出荷依頼書 8.2.4 製品の監視・測定
・リリース記録の保持
運用・保守 障害報告書 8.3 不適合製品の管理
・障害への対応

「普段からやっていることばかりじゃないか」と言われそうですね。実際その通りです。

普段やっていることが、ISO9001要求事項のどの項目に該当するかを紐づけて、それを品質マニュアルに書いておく。品質マニュアルに書いてあることをその通りにやる。

基本的にこれでISO9001は取得できます。

取得はできても、役に立つISO9001かと言えばさにあらず。ソフトウェアの品質をよくしたいのでしたら、もっと工夫が必要です。

全体の見通しが立たないうちから、プログラムの作成に手を付けてしまう。プログラムの終盤になって根本的な考え違いに気づき、全部作り直し…。

といった症状を改善したいのでしたら、「開発計画」のプロセスで一工夫が必要です。例えば、「プロジェクト開発計画書」のフォーマットを標準化し、時間をかけずにヌケモレなくプロジェクトの全体像を把握できるようにするといったことです。

そもそも、プログラムの作成についつい手を付けてしまうのは、とりあえずプログラムを作ってお客様に見せてイメージしてもらってからでないと、うまくお客様のニーズを引き出せないという事情があります。

であれば、例えば、お客様のニーズを上手に引き出せるようなツールや手順を「要件定義」のプロセスに組み込むことが必要です。

「バグを潰す」のではなく「バグを出さないようにする」企業文化にしたいのでしたら、「設計」プロセスを機能させる施策が必要です。過去の設計・開発情報を参照できるようにしたり、レビュー体制の充実といったことです。

どうせ、ISO9001を取得するなら、こういった課題を解決するためのツールとして使っていただきたいものです。