ISO,ISMSについて考える

このページは、ISO-9000s，ISMS等とソフトウェア品質管理について私がつれづれに思うことを書いたものです。
いまは、一緒くたに扱っていますが、いずれ、記載が多くなれば体型だてて整理します。

トップメニュー

・ISO-9001/ISO-14001改訂(2015/02/15)

　下でも書きましたが、今年はISO-9001(QMS)とISO-14001(EMS)が相次いで、改訂および、MSSに合わせたフォーマットになり、今年私の保有しているQMS審査員補の資格もこの改訂に合わせた資格対応に移行することになるのでしょうが…それぞれの規格にISO-31000のリスクマネジメントの規格概念を持ち込むことになるので、まぁ大変なことになると思います。

・ISO/IEC-27001:2013(2015/02/15)

　ある意味、昨年一年はこの規格に振り回された年でした。
　情報セキュリティマネジメントシステム(ISMS)であるこの規格が一昨年改訂され、JIPDECはMSS（マネジメントシステム共通フォーマット：このフォーマットに合わせるためにISMSの改訂は約一年間遅れた）に合わせたマイナーチェンジと発表していましたが、そのJIS版のJIS-Q-27001:2014の中身を読むと旧版と比較して、CSRやISO-9004の概念とか取り入れていたり、リスクマネジメントはISO-31000の規格を参照する様になっていたり（今後、ISO-9001を含むすべてのマネジメントシステムはリスクマネジメントを行う事になっている）、事業継続はISO-22301（事業継続マネジメントシステム）に譲って、情報セキュリティ継続（その情報が失われた場合、どの様に事業を継続するか）とかに大きく変わっていて、特に旧版ではパソコンや記録装置のリスクマネジメントが、情報自体の価値に対するリスクマネジメントの概念に変わった事が私の頭を悩ませました（そのことを会社の周囲の人達は全く理解してくれなくて…）。
　そのため、聴くところによりますと、多くの組織で旧規格から新規格への移行に失敗したり、重大な不適合が発覚して審査中止したり、スムーズに新規格への移行ができなかったそうです。
　私は、幸いなことに上記のISMS以外のISO規格は既に目を通していた甲斐があって、この度の移行審査は何とか突破しました。

・ISO-9004:2009(2011/05/15)

　「組織の持続成功のための運営管理−品質マネジメントアプローチ」です。番号から判るように、品質マネジメントシステムであるISO-9000シリーズの一規格書です。
　2009年版の改正は、認証規格であるISO-9001:2008に遅れること一年かかりましたが、この度の改正は大幅改正と言われる程、その内容がQMSを構築する組織（必ずしもISO-9001:2000を認証した組織だけではない）がより継続的な改善を進めるための指針であった2000年版と違い、顧客価値の変化とそのための必要な経営戦略を重点が置かれていて、読んでいてドラッガーの論を元に書かれたのではないかと思えるほどです（デミングさん可哀想…）。
　まぁ、ドラッガーとデミングは同じ大学の同席だったそうで、デミングは師のシューハートの論を品質管理に持ち込んで、ドラッガーもシューハートの講義を聴くかデミングから聴くかなりして自身の経営戦略論に加えたのではないかと私は思っています。結果、よりよい品質の物を作るのには、よりよい経営が必要であるという考え…これは、デミングも同じ事を言っていたそうです。
　ISO-9004:2009の「解説と活用ガイド」を読みましたが、殆ど経営戦略本と同じような内容になっており、製品の品質だけではなく、経営の”質”についての意味合いが強調されているように感じました。

・ISO-26000(2011/05/01)

　「社会的責任に関する手引」です。以前、この規格に対しては、「企業の社会的責任」いわゆるＣＳＲの事をISO規格化していると書きましたが、紆余曲折して、ＣＳＲの”Ｃ”である”企業”が抜け落ち、”ＳＲ”となりました。発行は2010年の11月です。
　途中の紆余曲折に対する報告がIOS関係のページあり、”ＣＳＲ”から”ＳＲ”になったときには、「おいおい、大丈夫か？」と思いましたが、最近ようやく日本語訳を入手して一気に読みました。
　結果、”ＣＳＲ”から”ＳＲ”にして”Ｃ”である”企業”を削除したのは、サービスを提供する企業やそれに原材料を提供する顧客だけではなく、それを利用する消費者にも責任があり、だから”ＳＲ”すなわち”社会的責任”であると言うことが解りました。
　確かに環境や品質や安全衛生等の問題を企業側にだけ責めを押しつけて、それを利用する消費者がなにもしていなければ同罪であり、世界中の様々な組織が双方一致して色々な問題に取り組まなければ、後の時代を担う人達に未来はありません。
　その手引きとしてこの規格書は書かれています。またこの規格は品質マネジメントシステム(QMS:ISO-9000シリーズ)や環境マネジメントシステム(EMS:ISO- 14000シリーズ)等の規格と違い、後ろに”ＭＳ”の付く”マネジメント・システム”ではないので、マネジメント・システム特有のPDCAサイクルがありません。ですので認証規格ではなく、書いてあること全部が「こうあるべき」と言う手引き書です。
　その内容は、QMS,EMS,ISMS,ITSMS,FMS等の各種のマネジメント・システムや国連憲章とか各種国際会議での議定書・宣言書等を取り入れて、それらの統合的な規格書に位置づけられる物と私は感じました。

・改正不正競争防止法(2010/09/22)

　会社で経済産業省の不正競争防止法に関するガイドライン等の資料一式を読みました。
　そこには「営業秘密侵害罪」という刑事罰があり、”営業秘密”と言うのは、この法律のための用語あって、簡単に言えば、業務上知り得た事を口頭にしろ、紙媒体にしろ、電子データにしろ、持ち出し禁止の場所から無断で持ち出した場合は、罪に問われると言うことです。また、退職後や海外での無断使用も罪に問えるそうです。
　そうしないために各企業はどうすべきかと言うのがこの一連のガイドラインですが、読んでいる途中で、「なんか、ISMSの規定に書いてあることと似ているような…」と感じていたら、ある資料の最後に「ISMSの認証について云々」と書かれている箇所があり、どうやらこの一連のガイドラインはISMSのISO-27000シリーズを参照に作られたようでした。
　個人情報保護法がJIS Q 15001にマネジメントシステムとして認証対応しているように、企業機密も改正不正競争防止法で守られ、またISMSでマネジメントシステムとして認証対応しているようです。

・ISO 27003とISO 27004(2010/03/16)

　JIPDECの説明会に行ってきました。内容はISO 27001、ISO 27002の改訂状況と最近発行されたISO 27003とISO 27004ならびに現在ISO化が進行中の事業継続マネジメントのBCMS(BS 25999)の話です。
　ISO 27003は、ISO 27001の要求事項で実施が必要と考えられる管理策に対するガイドラインです。
　また、ISO 27004はISMSの有効性の測定に対するガイドラインです。
　これにより、ISO 27001で書かれている内容で曖昧な部分が明白になってきました。あとは、ISO 27005(リスクマネジメントのガイドライン)が早く発行されるのを期待しますが、それよりもJIS化されるのか心配です。

・プロジェクトマネジメントのISO化(2009/12/08)

　IPAからのメールによりますと、プロジェクトマネジメントの国際規格ISO-21500として2012年に発行が予定されているそうです。
　P2M(プロジェクト&プログラムマネジメント標準ガイドブック(Project & Program Management For Enterprise Innovation))との関係が気になります。

・ソフトウェア設計には誤差はない(2009/11/01)

　今ソフトウェアの計測方法とか見積もり手法とかの本を読んでいますが、かつてハードウェアで電子回路設計や機械・機構設計もどきの作業経験がある私が今更ながら感じたのは、機械・機構設計の図面では物の寸法に±０．５ｍｍとか、電子回路設計の設計仕様に動作電圧４．５Ｖ〜５．５Ｖ等の誤差を入れて予め製品のバラツキを指定して、その範囲を超えたら不良品として扱います。そして不良品をなくすためにロバスト設計（製品を構成している各部品間の融通により、部品全体のバランスで良品にする設計）とかシックス・シグマ（不良品の発生率を計測して不良率を低減する方法）などがあり、設計時にかなりの製品の不良の程度を予想が出来るのですが、ソフトウェアはそうはいかず、例えば設計書・仕様書に「１００モジュール，１００オブジェクトにつきバグ１件なら良品とする」などと書くことが出来ません。ソフトウェアの設計書・仕様書は書かれていることが全部誤作動なしに動かなければなりません。
　それ故に、ソフトウェアの設計・製造にはレビュー等の設計・製造の各段階で品質の低下を防ぐ方法が取られていますが、予想の出来ない、あるいは防ぎようのないミスが入り込む隙があり、誤差などの余裕が許されないので、レビューでがんばって設計ミスを防いだつもりでも、結局仕様書に従った製造後のテストの段階で設計上のミス（大抵、それが重大なミスであったりする）が出てその対応に追われ、納期にも追われるのが常です。
　また、受注ソフトウェアの開発現場では、顧客にとって完成図が不透明、あるいはデモ画面で顧客にあらかじめ了解を得て設計・製造したものでも、顧客の一言（それが仮に顧客の感覚ではたわいのない物でも）で、簡単にソフトウェア技術者の首を真綿でジワジワと締め付け、モチベーションの低下とストレスの上昇につながります。
　それがソフトウェアの品質の難しさなのではないかと思った次第です。

・JIS X 0111シリーズ(2009/10/23)

日本規格協会さんのページで新しいJISやISOの規格書の発行状況を調べていましたら、
・TS X 0111-2:2009 ソフトウェア製品の品質―第２部：JIS X 0129-1 による外部測定法
・TS X 0111-3:2009 ソフトウェア製品の品質―第３部：JIS X 0129-1 による内部測定法
・TS X 0111-4:2009 ソフトウェア製品の品質―第４部：JIS X 0129-1 による利用時の品質測定法
が発行されました。
ISO/IEC 9126-2〜4(ISO/IEC 9126-1はJIS X 0129-1)の標準仕様書として公開されました。本来"TS"はJIS化の前段階で、日本工業標準調査会でJIS化に向けての判定中の段階のものを指しますが、聞くところによりますと元は"TR"としてJIS化をしないことにした参考資料だそうで、現在ISOとしてソフトウェア品質モデルの規格であるISO/IEC 9126-1〜4ならびに、ソフトウェア製品に関する評価プロセスの規格であるISO/IEC 14598-1〜6を体系的に見直して、SQuaREとして、ISO/IEC 25000シリーズとしてソフトウェア品質知識体系ガイドして構築中であるので、今回は"TS"での公開になったと思われます。
SQuaREは、
（1）2500n：品質評価全体の概念
（2）2501n：ソフトウェアの品質モデル
（3）2502n：品質測定法
（4）2503n：品質要求に対する要求
（5）2504n：品質評価に対する要求
の五つの部分から構成することを目的として作成しています。
現物を手に入れて読んで見たいのですが、値段が…会社は買ってくれないので、自腹でも手に入れたいのですが。

・JIS Q 9001:2008(2009/01/09)

　昨年の12/22にJIS Q 9001:2008が発行されました。早速新宿の紀伊國屋書店に買いに行くと、規格本書と規格の解説書、他に新旧規格の対照と解説書が販売されていたので、かなり財布に痛手ですが、背に腹は代えられないので、思い切って買ってきました。
　読んでいる間に、審査員登録機関から「現在資格更新またはサーベイランス中の審査員（補も含む）は、JIS Q 9001:2008を勉強したことに関する追加のレポートを提出すれば、JIS Q 9001:2008対応に更新します」とアナウンスがあり、先月審査員補の資格に対するサーベイランスの申請中の私は早速追加レポートを作成して提出して旧年中に郵送しました。
　レポートの提出期限は今日までですが、審査員登録機関から再提出云々と言うことを言ってきていないので、多分大丈夫だと思います。

・SQuBOKガイド(2008/10/30)

　日本科学技術連盟から、SQuBOKガイド第１版の改訂作業（アメンドメント）が公開されたと言う通知が来ました…もう改版？

・ISO/IEC 9001:2008(2008/10/29)

　ISO 9001が改定されると言うので、審査員を対象とした改定内容の説明会に言ってきました。
　改定内容は事前の情報通り、主文の内容は変更がないそうです（但し、言い回しが変わった…これは、JIS企画書の記載を定めている規定書が改版されたため）。
　その代わりに、あいまいな解釈がされがちな文にコメントや追記がされて、規定の趣旨がよりわかりやすくなっています。
　ISO 9001:2008は11/15に発行。JIS化されたものは12月に発行されるそうです。

・什器(2008/10/28)

　会社のISMSの情報資産管理の規程に「什器類も情報資産に含まれる」と書いてあり、「会社の浄水器や電気ポットも”情報資産”か？」と技術部門の部長に指摘され、以後何かと情報資産管理を行うことを話すたびにこのことを言い出しているので、調べなおしたら、ISMS Ver2.0を認証する際に参照したJIS X 5080(ISO/IEC 17799:2002)の情報資産の定義を引きずっていて、今のISMSの認証規定であるJIS Q 27001の規範であるJIS Q 27002(ISO/IEC 17799:2005)では、什器の記述が削除されているのにいまさら気づきました。
　什器：日常使用する器具・家具類。什物(じゅうぶつ)。什具。

・ソフトウェア品質技術者　初級資格認定試験(2008/10/24)

　ソフトウェアの品質を向上するために、財団法人 日本科学技術連盟主催の資格試験が実施されるそうです。
　内容は、SQuBOKガイド１版に従ったものだそうです。受けたいけど、先立つものが…(;_;)SQuBOKガイド１版も買いたいけど高価で…

・ISO 9001:2008(2008/10/08)

　いよいよISO 9001:2008が発行されるようです。内容はISO 9001:2000から大きな変更が無いという情報が入っていますが、審査員としての資格の移行はどうなるのか心配です。（数万円単位金額が必要な講習を受ける必要があるのかなぁ…(;_;)）
　正確な情報は、今度行われるJRCAの講演会で明らかになることと思われます。
　まぁ、世間では食品偽装事件がきっかけで、食品安全衛生マネジメントシステム(ISO 22000)が正常に機能しているかと言うことから始まった、他のISO 9001/14001/27001等のマネジメントシステムを審査する審査員の力量を問うと言うことがここ数年マネジメントシステムの審査員に対する講演会等で色々な議論されてきています。
　私もまたQMS(ISO 9001)審査員補として、あるいはISMS(ISO 27001)を社内で運営する担当者として関心が高いことです。
　その究極として、結局人が係わるものだから、心理学的なものが必要なのだろうと考え、心理学などを勉強したりしていますが、なかなか監査される人の心に共感してベストな方策を策定すると言うのはとても難しいと実感しています。
　それにして、相変わらずの世界規模の株安で、今後マネジメントシステムの認証維持に費用がかけられないからと、今後認証を返上する企業が増えるような気がします。

・ISO 90000-3

　JIS X 0160やJIS X 0129を調べていて気づきました。長いことISO 9003の誤植だと思っていたのです。
　内容は、ISO 9001をソフトウェア開発・保守会社で導入する場合にどのようにしてISO 9001の規格に当てはめるかと言うことが書いてあるそうです。ISO 9000シリーズの1997年版までは、品質マネジメントシステムのソフトウェア開発に適していた規格としてISO 9003と言う規格があったのですが、ISO 9001:2000版改版時にISO 9001にISO 9002（こちらはサービスに適していた）と共に統合されました。
　ISO 90000-3に対しては、制定時に紆余曲折あったそうでして、日本ではソフトウェア開発・保守に対してJIS X 0160やJIS X 0129を利用すればJIS X 9001で十分対応可能と言うことで残念ながらJIS規格化されていないそうです。

・ISO-26000

　企業の社会的責任(CSR)のISO版化(ISO-26000)が今現在行われています。日本の商習慣ではよく「三方よし」と言うように、企業・顧客・仕入れ先（ISO-9001ではこちらも”顧客”）が良くなることが暗黙の美徳としてしてきました。でも、グローバルスタンダードの世界では、この日本のよき商習慣は通用しないようで、企業自ら社会に対する貢献を訴えなければいけないようです。
　昔「男は黙って」と言うフレーズのコマーシャルがあり、黙って行動することが日本人の美徳とされていましたが、現代のグローバルスタンダードの世界では、企業の自己主張が必要なのだそうです。自己主張すると、なにか安っぽく感じるのは、私だけでしょうか？
　たしかに、主張することはできるでしょうが、ISO-14001同様、それを日々のマネジメントの改善（ＰＤＣＡサイクル）として企業内でいわゆる”乾いたぞうきんを絞る”と言うようなことをして企業の首を絞めるというのはどうかと…CSRは企業のポリシーだと私は考えています。ポリシーを毎年絞ってもすぐ行き詰まるのが関の山だと思うのですが。

・IT統制

　日本版SOX法とも言うべき金融商品取引法が2007年9月30日から全面施行されるそうで、今居る会社が将来上場企業を目指すならば避けては通れない道と思い、現在自主的に研究している最中です。
　現在、私が理解している範囲では、会社の財務に関するインプットとアウトプットを明確にして、決算に対する有価証券報告書と共に「有価証券報告書記載内容の確認書」と社内で評価された「内部統制報告書」なるものを作成して、公認会計士または監査法人の監査によって承認された「内部統制報告書の監査証明」の三点セットを金融庁に提出しなければならないのだそうです。
　その「内部統制報告書」の中に「ＩＴ統制」に関する報告があり、これはベースとなった米国のSOX法にはないものです。
　内部統制に関しては、私は先ほど述べた”会社の財務に関するインプットとアウトプットを明確にする”と言うことでは、ISO-9001(QMS)に近い感じがしています。また、「IT統制」に対しては、ISO-27001(ISMS)に近い感じがしています。ですので、上場企業の多くはISO-9001とISO-27001を取得しているので、「内部統制報告書」を作成することはさほど難しくはないのでしょうが、聞き及ぶところによると、財務に関してISO-9001より細かい物を求められているようです。また、IT統制も、ISO-27001以上にISO-20000(ITSMS)やリスクマネジメントに対する厳しい視野が必要とされるようです。

・JIS Q 17024

　JRCAの説明によりますと、審査員としての力量の評価に対する規格として、JIS Q 17024が制定されたそうです。
　要は、JRCAに所属するISO9000の審査員に対する新規登録と登録維持の方法が変わったと言うことです（但し、2006/02/10現在は確定していません）。
　新しくISO9000審査員補になる人は、今まで雇用者の推薦状を貰えば良かったのを、JRCA登録審査員の推薦状でないと駄目だとか、審査員補の資格維持には、ISO9000の実地審査経験がないと駄目らしいとか、色々変わっています。
　私のように、ISO9000審査員補の資格を持っているが、所属している企業がISO9000認証を取得してなく、ISO9000(QMS)の知識を持って他のマネジメントシステム（私の場合はISMS）に関わっていたり、コンサルタントとして活動するためにISO9000の審査員補の資格を維持している人達にとっては、大変なことです。

・リスクアセスメント

　ISMSでは、情報資産を洗い出し、それに対するリスク分析を実行し、そのリスクに対する対応計画を立てるものだと、ISMS審査の時に教えられました。私は、それをバラバラにやっていたので、情報資産からリスク対応計画に至る道筋が不明確なのだそうです。
　また、リスク分析も、２通りあって、情報資産を下から積み上げて、それに対するリスクアセスメントをする方法（ボトムアップ）と、リスクから情報資産の対象を絞り、リスクアセスメントをする方法（トップダウン）の方法があるとも教えていただきました。
　私の場合は、情報資産はボトムアップで、リスク分析がトップダウンなのに加えて、分析内容が希薄で、一貫性がないということを教えていただきました。

・ＳＥ業務に必要なもの

　ソフトウェアの品質管理を勉強していて、ソフトウェアの品質を左右する物の大部分は、仕様書の不明確と、度重なる仕様の変更なのですが、その辺を勉強していくと、とどのつまり、
　○仕様書の不明瞭に対する対応は、日本語文書の勉強しかない
　○たび重なる仕様の変更に対する対応は、顧客の業務知識の理解はもとより、顧客とのコミュニケーション能力であり、心理学の分野まで手を広げないといけない
と考える次第です。
　また、最近この手の関係の本が増えてきたので、現場のＳＥには、上のことが不足している人達が多いのかなぁ…と思いました。
　でも、最近物事が複雑かつ広大になりすぎて、一人のＳＥやＰＭの手では足りないので、現場のＳＥが苦労しているのもまた事実です。

・ISMS Ver2.0からISO-27001への移行

　従来のISMS Ver2.0認証企業がISO-27001に移行するのには、現在(2006年1月現在)では、サーベイランスにISO-27001の文書審査費用の上乗せだけで済むと言うことを第三者機関から聞いています。
　しかし、まだISO-27001の認定の権限を巡って、JIPDEC((財)日本情報処理開発協会)とJAB((財)日本適合性認定協会)が綱引きを行っているそうです。かたやISMS Ver2.0の認定実績があり、またかたやISO-9000/14000シリーズの認定を行っている機関であり、認定を受ける企業は関係ないのですが、現在ISO-9001の審査員補で、将来ISO-27001の審査員を目指す私にとっては、この綱引きの結果を固唾を飲んでうかがっています。

・ISMSが本格的にISO化

　BS7799-2が今年(2005年)の10月に正式にISO27001となり、ほぼ同時にISO17799(BS7799-1)も、ISO27002になります。大元のBS7799シリーズから、
　　　BS7799-1 -> ISO27002
　　　BS7799-2 -> ISO27001
と言うように、BSとISOでは末番の１と２が入れ替わります。
　当然BS7799-2をベースにしているISMSも来年(2006年)にはJIS化され、JIS-Q-27001として規定されるそうです。
　ISO27001とISMS Ver2.0では、規格の項目が10から12へ、また詳細管理策も127から133に増加しています。ただ増えたのではなく、内容の統廃合などがあったそうです。

・IOS9000:2005

　ISO9000が9月にバージョンアップされました。内容は2000版と対して変わらず、ISO19011との関連で用語が変更されたくらいなのだそうです。
　私個人としましては、ISO9000:2005対応のレベルアップの費用がいくらかかるかを考ええてビクビクしています。

・内部監査員

　ISO9000,ISO14000,ISMSなどは、マネジメントシステムの有効性を検証するために、定期的な監査を行うことになっています。
　　・第三者：審査機関による審査
　　・第二者：利害関係者（顧客等）による監査
　　・第一者：内部監査
　そのうち内部監査（第一者）は、自社内で行なわれ、自社の業務を知っている人が監査をするため、有効に活用すれば業務の改善に繋がります。
　ISO900,ISO14000シリーズには、内部監査員の指針としてISO19011と言う規格があり、その中で内部監査員に要求される力量（知識、技量等）が示されていますが、それを読むと、個人的特質に対しては、
　　・論理的である
　　・心が広い
　　・外向的である
　　・観察力がある
　　・知覚が鋭い
　　・適応性がある
　　・粘り強い
　　・決断力がある
　　・自立的である
が要求されるのだそうです…これ全部に当てはまる人にいままでお目にかかったことがありません。

・ISMSとISO-9000との差

　ISMSで各種手順書を作成しますが、業務内容に踏み込んだ作業手順書を作成するとそれはISO-9000の領域になってしまいます。意外とその差が解らない人が居て、相談を受ける度に方向修正をするのに苦労します。
　確かにISMSでは、ISO-9000と似たような文書を要求されます。ISO-9000の文書は、簡単に言いますと、「インプットとアウトプットを明確にする」事です。その内、ISMSでは、「どのような情報が入ってきて、何処にどう保存して、どう出力ないしは破棄することを明確にする」まででいいのです。そこで「どう加工して、出力する」と言うことを書くと、ISO-9000のレベルになります。
　別に、将来ISO-9000認証を目指すのと、この際業務の流れを明確にしようとすれば作るのが望ましいですが、それでは作業量と文書量が増えてしまいます。そこをどうシンプルで簡潔にするかが問題です。

・ISMS認証作業も技術業務の応用

　ISMSの認証作業で、現在規程書類を連日作成しています。この規程書類を作成して気づいたのは、これらの規程書類に書かれている内容は、マネジメントシステムと言う会社の運営システムの仕様のドキュメント化であり、今まで私が技術部で行ってきた仕様書作成業務とあまり変わらないことです。
　ただ規模が大きすぎて、今までファームウェアと呼ばれている電子機器に組み込む様なコンパクトなソフトウェアの仕様書を書いていた私には、ギャップがあって戸惑いましたが、結局やっていることが同じで応用が利くと理解できましたので、今は順調に作業をこなしています。
　言うなれば、ISMS認証とは、最終客先からの検収印と思えば、次のように考えられます。
　　・ISMS認証審査は、客先検収のための受け入れ試験。
　　・試用期間の内部監査は、社内テスト。
　　・情報セキュリティ基本方針は、概要設計。
　　・規定書は、内部設計。
　　・手順書は、詳細設計。
　　・試用運用が試験。
と、言い換えることができます。プログラム組まないだけ、ましかもしれません。

・ISMSがISO化へ

　つい先頃、BS-7799-2がISO化されることが決まったそうです。BS-7799-1をベースとして作成されたISO-17799に合併統一されると思っていたのですが、ISO-24743として2006末には発行されるのだそうです。日本国内のJIS規格化はそれから一年半〜二年程かかると思います。
　BS-7799-2がISO化されることにより、BS-7799-2をベースとして作成された日本国内の規格であるISMSもまた、ISO-24743に統一されるものと思われます。

・ソフトウェア業者のISO-14000s対応

　最近、ソフトウェア業者でもISO-14000sに対応または準拠していないと取引をしないと言う会社が出始めました。いわゆるクリーン調達と言われる物です。
　でも、ソフトウェアは人間の頭脳が創り出す産物であり、私はソフトウェアはアートだと思っています。それと環境マネジメントの考え方とはかなり隔たりがあり、私は熱心に研究していませんでした。しかしながら、企業としてソフトウェア業者を捉えると、環境に配慮する必要があると考えられたらしく、最近ISO-14000s対応の話が出始めました。私は、企業側からの取引先縮小の口実と勘ぐりたくなりますが…
　単純に考えますと、ゴミの分別廃棄、コピー用紙の節約、休み時間の消灯、長時間の離席時のパソコンの電源オフなどかすぐ上がりますが、ISO-14000sはマネジメントシステムであり、環境方針をたててそれに対する年次毎の環境目標を決めて延々と活動する物なので、このようなことはすぐに限界に達し、乾いた雑巾をなお絞るような格好になり、社員が悲鳴を上げてしまいます。
　手段としては、上記の対策をそこそこに、パソコンや備品のクリーン調達率のアップや、ソーラー発電器の導入、パソコン部品のリサイクル、廃棄物のリサイクルや廃棄時にISO-14000s対応業者の選定などがあると思います。
　私が思うには、ソフトウェア業者にISO-14000sの対応を要求するなら、客先自体が綺麗でさわやかな環境にして、プログラマやSEの頭をすっきりクリーンにして作業効率を上げて残業を無くして作業できる環境が欲しいですが…

・個人情報保護法対策の参照資料

　JIS-Q-15001やISMSの情報に対するセキュリティの三大要素は、
　　・機密性：許可された者だけが情報にアクセスできる。
　　・完全性：情報の正確性と完全性を常に維持する。
　　・可用性：要求に従って適切な情報にアクセスできる。
です。
　JIS-Q-15001やISMS認証を取得する際に、不正アクセスや災害等のリスクに対する考え方が必要になります。それらにどう対処するかというガイドラインを作成する場合に、リスクマネジメント(JIS-Q-2001)と言うのが良い資料になります。要は、孫子の兵法じゃないですけど、「敵(リスク)と戦(対処)わずに屈服(予防・回避)させるのが最高の戦略」と言うことです。
　また、ISMS認証を取得する場合、ISMSの規定を読んだだけではよくわからない人のために、ISO-TR-13335(GMITS)と言うガイドラインがあり、これはJIS-X-0036シリーズとしてJIS化されています。

・マネジメントシステムの最低要素

　いわゆる”マネジメントシステム”を言う名前を有する規格(ISO-9000s,ISO-14000s,ISMS,OHSAS18001等)には、以下の事が必要であり、
　　1.方針をたてる
　　2.方針に向かって目標計画をたてる
　　3.目標に対する施策を実施する
　　4.施策の実行結果を点検評価する
　　5.評価した結果を是正する
と、1.〜5.を行い、以降2.〜5.の繰り返しをすることです。これがＰＤＣＡ循環と呼ばれるものです。そしてそれには、
　　・経営者主導
と言うのが必須であり、
　　・社員(経営者をも含む)の教育
　　・手順書の作成
　　・記録の作成
の活用をしてのＰＤＣＡの循環をしていくことです。

・個人情報保護法

　「個人情報保護法」が2005/04/01から施行されます。政治家やマスコミは、この法規制からずるく抜けていますが、この法のおかげで日本中の事業者は”個人情報”と言うものに対して敏感になることになります。
　この”個人情報”と言うものの定義は、「個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述または、個人別に付された番号、記号その他の符号、画像もしくは音声により当該個人を識別できるもの（当該情報のみでは識別できないが、他の情報と容易に照合することができ、それにより当該個人を識別できるものを含む。）をいう」となっています。要するに、その人個人を特定できる情報は”個人情報”と考えて良いと思います。
　ですので、たとえばこれはその一部ですが、今まで雑誌のアンケートや懸賞などで集める、個人の氏名、住所、電話番号等は、集める側はその収集する目的を明確にし、それに収集することに対しての了承を得て収集し、またそれを目的以外に使用してはならないことになります。また、応募する側もこのことをよく認識しなければなりません。
　この法のやっかいなのは、これだけではなく、この法に対応をした対策をとらねばならないことです。それには、次の三つの方法があります。
　　・単純に法に一致するような対策をとる。
　　・JIS-Q-15001に従った対策をとる。
　　・ISMSに従った対策をとる。またはISMS認証をとる。
　以上の対策の方法は、上から下に行くほど厳しくなりますが、JIS-Q-15001は日本規格協会が示す国内規格であり、ISMSは元はBS-7799と言う英国の規格から派生したISO-17799と対になる国際的な規格を元にしています。
　JIS-Q-15001やISMSも、その内容にはマネジメントシステムが含まれています。継続的な改善、いわゆるPlan->Do->Check->ActのいわゆるＰＤＣＡの実施が必要になります。

・ソフトウェア開発成功の鍵はコミュニケーション

　以前、「人月の神話」の項において、「ソフトウェア品質管理（ソフトウェア工学）は、大規模なソフトウェア開発に限って適用できることであり、私などが現在業務で行っている小規模ソフトウェア開発には当てはまらない。また、ソフトウェア開発要員のリソースは、製造ラインで業務している要員と同じと考えてはならない。ということです。」と書きまして、また、トム・デマルコの本などを読むと、小規模ソフトウェア開発においては、キーを握る人物が指揮をとり、コミュニケーション豊かにチームワークを重視して開発する方が効率的だし、ソフトウェア品質が良い物ができると書かれています。私もそう思い、最近宗旨替えした次第…。
　”コミュニケーションが大事”って書くと、『じゃぁ藤次郎が今まで言っていたソフトウェア工学はいらないのか？』と勘違いされるので補足しますが、ソフトウェア工学もまた必要です。と書くと『言っていることが矛盾する』と言われそうですが、ここで言うコミュニケーションの中には、ドキュメントの作成，レビュー，スケジュールやマネジメントの打ち合わせなども入っています。これらはソフトウェア工学の基本ですから、私の言ってる”コミュニケーション”は、これらを含み且つそれ以上の事柄です。
　では、それ以上の事とは何かと言いますと、他のメンバーの教育（メンタルトレーニング）などです。無論、それに基づく雑談も入ると考えています。理想は、メンバーのストレスマネジメントもできればいいのですが…これらには、日本の古くからの”飲みにゅけーしょん”と言う、良い意味と悪い意味の場がありますが、今の若い人たちは、年齢の上下のつながりをなんとなく嫌う風習があり、よけい仕事の場でのコミュニケーションが大事と考えています。
　ですから、ソフトウェア工学の方式に則った開発でも、コミュニケーションとチームワークは重要視されるべきだと思います。
　プリセールスSEの人は、顧客とのコミュニケーションが大切だし、開発SEは、プログラマを束ねる上でのコミュニケーションが大事です。当然、両SE同士のコミュニケーションがとれていなければ、顧客満足の製品が作られないどころか、顧客に会社自体を疑われてしまいます。
　最近になって、SEのコミュニケーションスキルについて書かれた本が何冊か売られるようになりました、それだけ、コミュニケーションが重要視されていると言うことです。
　私も、この手の本を買って読んだり、またそれ以前から心理学の本などを読んでいますが、人という者はソフトウェア品質管理ほど簡単には扱えません。だから私は、普段から社内での教育やコミュニケーションを計って、社内のメンバーの人となりを見たりして、スキルのコンサルタントとかマネジメントとかが大事と思っています。
　…もっとも、今の会社では各個バラバラに派遣されるので、チームワークもコミュニケーションも無いのですが。

・顧客満足

　ISO-9000sの一番の基本は「顧客満足です」。
　ISO-9000s認証企業は､「顧客満足」を目指して、経営業務の改善に取り組まなくてはならないのです。その経営業務改善の努力が正しく行われているのを判定するのが､第三者審査機関です。
　しかし、どうも日本のISO-9000s認証企業の多くは、この認証を何かのお墨付きと勘違いしているようです。
　認証取得の動機も、親会社や関連会社が認証を取得したので付き合いで認証取得をしたと言うのが多いそうです。
　そして、ISO-9000s認証を得られさえすれば､経営がよくなると考えていて、認証後に継続的な改善努力を何もせずに､審査時期になって慌てて表面上を取り繕っているだけで、「せっかく認証取得しても、金と手間ばかりかかって仕方がない」と言う経営者が多いそうで、また、一部には３年後のサーベイランスの前に認証を返上してしまう企業があるそうです。
　これでは、本末転倒ですし、ISO-9000sの認証を取得する意味がありません。
　ISO-9000sは、投資対象ではなくて､会社が「国際規格に則って、継続的に経営業務の改善努力をしています」ということを第三者審査機関に審査してもらって認定やサーベイランスを受けることにより､それを見た顧客が信頼して､初めて企業に仕事を依頼する…ということが解っていない経営者が多すぎます。
　この未だに景気が回復していないこの時に、企業の多くにはISO-9000s認証を取得維持する予算はないでしょうし、また、今の風潮として､一時期のように「猫も杓子もISO-9000s認証」とは言われなくなりました。また、顧客も建設業界などの一部業界を除いて､「ISO-9000s認証していなければ云々」とも言わなくなりました。しかしながら､ISO-9000sを利用することは経営を見直すよいチャンスだと思います。
　ISO-9000sの認証を取得維持する予算がなくても､将来ISO-9000s認証を見越して社内の規定や手順書を作成して実際に運用し､顧客に「我社は、ISO-9000s準拠で経営業務しています」と言っても別に誰から文句は言われませんし､「じゃぁ、証拠を見せてください」と言われれば､作成した規定や手順書を見せて（これを第二者監査と言います）顧客に納得してもらえればよいのです…もしかすると､顧客がISO-9000sの認証費用を出してくれるかもしれません。

・ＱＣ７つ道具と新ＱＣ７つ道具

　品質管理の手法に､ＱＣ７つ道具と新ＱＣ７つ道具というものがあります。
　　ＱＣ７つ道具
　　　・パレート図
　　　・特性要因図
　　　・グラフ
　　　・チェックシート
　　　・散布図
　　　・ヒストグラム
　　　・管理図
　　新ＱＣ７つ道具
　　　・親和図法
　　　・連関図法
　　　・系統図法
　　　・マトリックス図法
　　　・マトリックス・データ解析法
　　　・アロー・ダイヤグラム法
　　　・ＰＤＰＣ法
　それぞれは､ＱＣ７つ道具はハードウェア製造、新ＱＣ７つ道具はソフトウェア製造に適していると前の会社の教育で教わりました。
　これらの道具を使用して､不良品またはバグの発生する要因を究明し､それに対策を施すことによって不良品またはバグをなくそうというのがこのツールの目的です。
　でも、実際には､一貫して同じものを製造しつづけるハードウェア製造と違い､ソフトウェア製造は創造物で、二つとして同じものを製造しません。そのため、ソフトウェアのバグを見つけて対処しても､次回に生かせません。また定量的な計測がしづらいので、この７つ道具が生かされないのが現状です。
　私は､今までにハードウェア開発､ソフトウェア開発にこのＱＣ７つ道具、新ＱＣ７つ道具の両方を使用しましたが、この両方に必ずと言っていいくらいに入ってくるのが､人の問題です。
　…スキル不足、コミュニケーション不足、訓練不足等々…
　ソフトウェア工学では、人のスキルは、あらかじめ任に堪えうる十分な訓練が施されていることを前提としているので､出てこないファクターです。また、コミュニケーション不足は考えていませんし､訓練不足に対しては一応教育がありますが、今の時代ですと､教育にかける時間と費用はないというのが現状でしょう。
　ISO-9000sでも、不適合の原因を人のせいにしてはいけないと言う暗黙の了解があり､審査で指摘された不適合項目の原因を「誰々の不注意」とか「誰々のせい」というようなことにすると、審査員はよい顔をしません。
　会社のＱＣ活動で特にソフトウェアのＱＣ活動をすると、どうしても人にかかわる問題が出てきます。
　しかし、その問題解決をＱＣ活動にすると大抵の管理者は却下します。その理由の根幹は「改善の効果金額が明確にならない」からです。管理者が会社のトップに話をするのに具体的または数値的に明確でないものを説明するのが大変ですし、またしたがりません。したとしても、これが、技術畑出身のトップなら多少の理解をしてくれるかもしれませんが､大部分の企業のトップは経理畑出身者なので､具体的または数値的に明確でないものには、まったく理解してくれません。
　ですので、製造されるソフトウェアのライン当たりのバグの発生件数の削減とか､一定期間内のライン生産数の向上とかなどの比較しようがない前回作成したソフトウェアとの定性的な比較でお茶を濁さざるを得ないのです。そういうＱＣ活動なら､止めたほうがいいと私は思います。
　逆に、ソフトウェア開発効率やテスト効率向上のための機能やツールなどの開発やその技能の取得のほうがよっぽど気が利いていると思いますが､企業のトップは､「余計なこと」「そんな暇があったら､仕事しろ」と理解をしてくれません。困ったものです。

・ソフトウェア開発業務での仕事の流れ

　ソフトウェア工学では､
　　・外部仕様書　->　システム試験仕様書　->　マニュアル
　　・内部仕様書　->　結合仕様書
　　・詳細仕様書　->　単体試験仕様書
という、縦の流れと、それぞれ左のドキュメントをベースとして作成する各種ドキュメントが製造前の段階で出来上がっていることとされています。
　しかし、これはあくまで理想論です。
　実際には製造段階､あるいは単体試験中に変更や不具合が発生し､数々の手直しが繰り返されます。挙句には､その上の内部仕様，はては外部仕様にまで影響が及ぶことがありますし､また、顧客の都合で外部仕様にあたる部分が変更されることがしばしばあります。
　従いまして､現実は､
　　・外部仕様書　->　内部仕様書　->　製造　->　単体試験　->　結合試験　->　システム試験　->　マニュアル　->　詳細仕様書（および内部，外部仕様書へのフィードバック）
と言う流れになりがちです。無論､書きませんが（いや、複雑になるので書けなかった）､当然ながら、その間に外部仕様の変更が上の流れの間に割り込んできます。
　外部仕様の変更は､即座に工程や納期に影響します。たびたび外部仕様が変更されては、いかにドキュメントを作成し、レビューをきちんとやっても､その場限りのことになってしまいます。でも、たとえその場限りになろうとも､上流工程でのレビューを怠ると、そこでの仕様の漏れは下流工程に多大な影響をもたらします。
　目先の理想は、「開発が始まったら､外部仕様が変更されないこと、または、顧客が口を出さないこと」ですかね。
　それでは、顧客の理想と期待したものに比べて､出来上がった製品がかけ離れている可能性が高くて、顧客も最初のリリースでは満足しないでしょうから､最近は､一発勝負のウォーターフォール・モデル型の開発よりも、小出しにして顧客の理想に近づけて修正しながらリリースするプロトタイプ・モデル型の開発が実践されていると思います。

・インプット、アウトプット

　以前書いた「次工程はお客様」の続きになるかもしれませんが､工程管理の基本として､その工程毎のインプットとアウトプットを明確にされていることが問題となります。ISO-9000sでも、これはうたわれています。更に言うなら､「アウトプットは検証積みであること」ということが追加されます。
　ISO-9000sやISMSで、手順書を作成する場合は､会社全体->各部門->各作業工程というように徐々に細分化して作成するとよいようです。
　そして、どの段階で別の部門または他社にアウトソースするかを明確にしなければなりません。これは、文章よりはフローチャートなどの流れ図がよいと思います。見易いし、ソフトウェア会社ならなおさら…
　以前のISO-9000s:1994では、アウトソースされる側にはISO-9002と言う、設計に関する項目が除外された規定がありましたが、現在は、ISO-9001に統一されています。でも、設計に関する業務をしていなければ、「適応外」と書けばいいのです。

・CMMというのは

　CMMには以下の五段階のレベルがあります。
　　レベル１：初期段階
　　レベル２：再現可能段階
　　レベル３：定義段階
　　レベル４：定量管理段階
　　レベル５：最適化段階
　レベル１から始まって、それぞれの上のレベルに適合するように継続的な改善、いわゆるPlan->Do->Check->ActのいわゆるＰＤＣＡの実施による継続的改善を要求されていますので､ISO-9000sの知識がある程度必要になります。
　だいたいのソフトウェア企業は、レベル１か２、レベル３以上は滅多にないそうです。しかしながら、そのレベル分けの評価はソフトウェア工学に基づいた開発方法を評価しています。
　またISMSも、マネジメントの項目においては､その規定に「ISO-9000sを参考してください」と書いてあるので､ISMS認証取得するのには､ISO-9000sの知識が必要になります。
　なおISO-9000sでは、Plan->Do->Check->ActのＰＤＣＡは経営と製造の両方に存在し､二重ループといわれています。ただし、私が考えるには､CMMの場合のＰＤＣＡは、製造のＰＤＣＡについて重要視しているみたいです。

・ソフトウェア開発には、ISO-9000sよりはCMM

　以前居た会社での話。
　品質管理がやりたいので、その関連の部門（その会社には品質管理部という部署がなく、総務部の関係部署が、らしきことを行っていた）に転属を願い出たとき、当時の上司が「これからはISO-9000sではなくて、CMMが重要になる」と言いました。
　当時、CMMが何か知らなかった私は、不思議に思うだけだったのですが、後で調べてそれが本当だと悟ったのは、会社を退職した後…
　CMM（能力成熟度モデル）は、アメリカ政府が情報システムを導入する際に、企業のソフトウェア開発の成熟度を評価するための物差しです。日本でも、アメリカ政府の影響でしょうか、やはり情報システムの導入の際の評価項目として採用しつつあるそうです。
　CMMに似たものとして、SPICE(ISO-15504)と言うのもあり、これらもISO-9000sと同じく、審査員が現在国内でも養成されています。
　私も、お金があればISMSと同時に審査員補を目指したいのですが、あいにく、厚生労働省の資格取得のための援助制度はISO-9000s審査員研修で使ってしまったので、あと３年はこれが使えないです。

・人月の神話

　ソフトウェア品質管理関係の本を読むと、その殆どに『人月の神話-狼人間を撃つ銀の弾はない-』と言う題名の本の話が載っています。（もう一つ、『プログラミングの作法』と言う本も併記されていることが多いです）
　この本はかなり昔（原著が出版されて２０年だそうです）に出版された本で、私も題名は知っていたのですが、読んだことがありませんでした。
　派遣先の近所に大型書店があり、休み時間に行ってみたら、この本が新装版で販売されていました。早速手に取り、レジに行ったことは言うまでもありません。
　現在読んでいる最中ですが、要するに私が自分のWeb Pageで公開している「ISO,ISMSについて考える」のページで私が論じていることの下地となっているソフトウェア品質管理（ソフトウェア工学）は、大規模なソフトウェア開発に限って適用できることであり、私などが現在業務で行っている小規模ソフトウェア開発には当てはまらない。また、ソフトウェア開発要員のリソースは、製造ラインで業務している要員と同じと考えてはならない。ということです。
　確かに、現場にいて実際に作業をしている立場から言えば、この本とこれと同時に読んでいるトム・デマルコ（『ゆとりの法則』，『ピープルウエア』）の本の内容など「もっともだ！」と納得してしまいます。
　しかしながら、同時にISO-9000s審査員補の目で見ると、「ソフトウェア品質管理に則った作業をしてもらわないと困る」と思うし…
　つい最近まで、社内の新人教育でソフトウェア品質管理の講義をしていましたので、この本を読んでいる最中ですが、今、ジレンマを強く感じています。

・次工程はお客様

　私が会社でISOやソフトウェア品質管理の話をするときに、必ず言うのは「次工程はお客様と思え」です。
　ISO-9000sでは、前工程をチェックしてから本工程を行い、本工程をチェック完了してから初めて次工程に渡す事を重要視しています。要するに「インプットとアウトプットを明確にする」と言うことです。また、”お客様（顧客）”は、ISO-9000sの世界では、インプット先もアウトプット先も指します。
　ソフトウェアの開発工程に限って話をしますが、ソフトウェアの開発の一般的な話として、ウォーターフォールモデル（但し、今では古い手法とされていますが…今のプロトタイプモデルでも小工程は同じ物だと思います）について話をすると、
　　・外部仕様（要求仕様，基本仕様とも言う）
　　・内部仕様（機能仕様とも言う）
　　・詳細仕様
　　・製造
　　・単体試験（机上デバッグも含む）
　　・結合試験
　　・総合試験
　の各工程において、当然〜仕様書（製造工程についてはソースコード）と言うドキュメントが作られますが、この場合、工程に入るインプットは、上流工程の仕様書です。また、アウトプットは、本工程で作成する仕様書です。このときに、上流工程の仕様書をチェックしてから、本工程の仕様書の作成に入り、作成した仕様書をチェック（レビュー）して、それが完了してから、初めて次工程に渡すべきなのです。
　なるほど、機械の組み立てなど工程ではインプットとアウトプットが明確になっていますが、ソフトウェアの世界では、その前工程に引き続いて同じ人間が次工程を行う場合が多く、「分かるからいいや」とばかりにいい加減な仕様書を作成し、レビューも「ISO-9000sがうるさいから」と形だけのレビューで、ひどい場合は、レビュー記録自体もでっち上げの場合がままあります。
　しかし今の時代は、次工程のアウトソース（この場合、アウトソースは他社だけではなく、社内の別の人に担当させる場合も含みます）の可能性も高いので、だからこそ、前工程のチェックは正確を期して貰わなければなりません。
　だから、私はいつアウトソースしても良いように「次工程はお客様」と言っています。

・ドキュメント

　ISO-9000s:2000になって、それ以前のISO-9000s:1994ほどにうるさくドキュメント類を要求されなくなりました。
　ISO-9000s:1994では、やたらとドキュメントの一部である”記録”を要求されて、議事録，レビュー記録はもちろんのこと、電話のメモまで要求しかねないほどうるさかったです。
　なにかの本で読んだのですが、「ドキュメント力を上げるには、議事録を書かせると良い」との事だそうで、そういえば、私も若い頃は打ち合わせに行っては、議事録をたくさん書かされました。議事録は、会議のその場で書き上げて、内容について客先との相互の了解を得て初めて完了する物です。そのため、今思うと、議事録は短時間で端的に文書をまとめる技術と、分かり易い文書力をもとめられます。
　…そういえば、この前の仕事で部下に議事録を書かせていたら、部下のドキュメント力が上がりました。
　また、良いドキュメントを多く目にするのもドキュメント力を上げる良い機会で、会社の若い連中にも、もっと良いドキュメントをたくさん見せてあげたいのですが、今手元にあるのは私の駄文だけ…

・第三者審査員の実態

　第三者審査員の人は、日本適合性認定協会(JAB)の認定の審査員研修機関で規定の研修を受けて最終試験に合格すると、審査員になる資格を得ます。その資格を例えば、ISO-9000sならば日本規格協会(JRCA)に登録することにより審査員補となり、審査登録機関の機関員になって経験を積み、上級の審査員の推薦があると、審査員補->審査員->主任審査員とランクが上がります。
　しかしながら、審査登録機関の機関員になるのは、審査員が余っている現在ではなかなか難しく、また、実際は審査登録機関の大多数では、審査員と委託業務で契約することにより、審査のあるときだけその審査登録機関の機関員として顧客の企業に行って審査をしています。それでも、審査員の数が多いので、年に数えるほどしか審査活動をしないそうです。しかし、ISO-19011では、審査員の技能維持のために、毎年の資格更新時までに規定された審査実績をクリアしなければなりません。
　では、審査がないときはどうしているかというと、その多くの人がコンサルタントとして活動しています。ある人は個人経営で、またある人はコンサルタント会社の社員として…
　まぁ、言うなれば裁判官が裁判がないときには弁護士の仕事をしているというのと同じです。これは、矛盾していると思います。しかし、自身(自分の所属する会社,団体)のコンサルタントした企業の審査はできないことになっていますが…
　今、ISOコンサルタントに対する規定を作ろうとしています。これができると、どうなることやら…

・ISO-9000sとソフトウェア品質管理　其の二

　以前、「でも、よくよく考えたら、こういうときにはこのパターンのコードの書き方とか、またはモジュールの組み合わせ方とかを無意識にしている事に最近気づきました。こういうのを手順書にしてパターン化することにより、効率化と信頼性が高まることを遅ればせながら思いついた次第です。」と書きましたが、よくよく考えると、これは私自身の手順書であって、これを他人に適用することが無理ではないかと…
　これを他人に適用するとなると、ある意味での思想統一であり、製造物と言う意味でのソフトウェアではいいでしょうが、創造物としてのソフトウェアとしては面白みがないです。要は、ビジネスに徹するか、それとも、アートというか匠に徹するかの難しいところです。でも、あまりに匠に徹すると、他の人に読めないソースコードができてしまいます。他人に読めないソースコードは、後の改修，改造に支障をきたします…私も人にわかりやすいソースコードを書いているとは必ずしも言えませんが(^^;
　また、手順書を作って適用すると、経験の浅い新人に対しては教科書になるでしょうが、それだと逆に押しつけになり、新人の創造力がなくなりますし…難しいところです。

・ISO-9000sとTQC

　日本では、戦後の高度経済成長と共に発展した来た改善活動であるTQC活動があります。"KAIZEN"と言う英語があるそうです。
　ISO-9000sもその規格の中で改善をうたっています。両者の違いはTQCがボトムアップ型の改善活動に対して、ISO-9000sはトップダウン型の改善（改善活動ではない）であることです。
　ISO-9000sを取得した、または取得するためにTQC活動をやめてしまうのは、大間違いで、この両者は共存可能で、逆にこの両方があって日本の企業は良い方向に向かっていくと私は思っています。
　だから、TQC活動もISO-9000sの作業手順書に入れて、日常の業務に取り込むと良いと思います。TQC活動の事を手順書に書くと、審査員によっては「これは、ISOの規格外だから審査できません。削除して下さい」みたいなことを言われるかもしれませんが、「これは当社の作業手順書です」と言い切れば、無理に削除しろとは言われないはずです。

・ISO-9000sとソフトウェア品質管理

　もともとISO-9000sの1994年版の品質に関する考え方の基本は、機械等の組み立て現場での発想で、部品の組み込み位置があらかじめ決まっているものに対する品質コントロールについて書かれていました。それが、ISO-9000sの2000年版になって、サービス産業やソフトウェア産業にまでその適用範囲が広まりました。
　しかし、私は以前から、「ソフトウェアは創造の産物であり、果たして創造物の品質管理ができるのか？」と常々疑問に思っていました。
　ISO-9000sには教育，文書化，検査（テスト）がうたわれています。しかしながら、ソフトウェア技術者のスキルの平均化やスキルアップのための教育や、コーディング基準などの文書化や、テストの徹底をしてもなかなかバグが減らないものです。思想の統一化が一番効き目があるような気がしますが、それでは技術者としての面白みがないと思っています。ソフトウエアの製造は、その目標の実現に対して複数のルートというべき方法が存在していいと私は思っています。ただ、そのルートがあまりにも遠回りだと困りものですが…
　後は、ソフトウェアの部品化と流用ですが、私の仕事は組み込みのファームウェアの開発が多く、組み込む装置に特化したソフトウェアを組むので、ソフトウェアの流用と言うことに関しては、いままで、あまり関心がありませんでしたし、また流用と言うものを「できあがったものをそのまま利用する」と言う考えに固執していました。でも、よくよく考えたら、こういうときにはこのパターンのコードの書き方とか、またはモジュールの組み合わせ方とかを無意識にしている事に最近気づきました。こういうのを手順書にしてパターン化することにより、効率化と信頼性が高まることを遅ればせながら思いついた次第です。
　また、最近気づいたのは、オブジェクト指向の考え方で、私の解釈が間違っていなければ、この考え方の一つには部品の組み合わせという考え方があるので、オブジェクト指向の開発はソフトウェア品質管理にもマッチしているのかと思います。

・第三者審査機関の審査員は恐れることはない

　審査員といえども人であることは変わりがありません。やっていることは裁判官みたいなことをやっていても、権力のバックアップはありません。横暴な審査員に対しては、反論や抗議をすることができますし、審査機関自体を変更すること（認証後も変更可能です）ができます。また、審査員自体にもISO-19011と言う審査員に対する戒めと言うべき規格が存在します。
　今まで、ISO-9000s/14000sの横暴な審査員に苦しめられた方は、是非一度、参考文献に掲載した本を見てください。審査員は贈り物を受け取ってはいけないし、審査後の接待も受けてはいけません。（以前、ISO-14000sの審査員が審査後の接待を受けたことがばれて審査員の資格を剥奪されました）
　ISO-19011は、つい最近規格化されましたが、それ以前は、別の規格でISO審査員に対しての規格がありました。この両者の違いは、ISO-9000s/14000s両方の審査員に対する規格を統合したのと、社内で行われる内部監査の監査員に対する規格が決められたことです。これにより、内部監査員も規定の教育を受けた人しかできないようになりました。
　また、将来ISOコンサルタントに対する規格も検討中とのことで、へたすると、私は近い将来ISO-9000sコンサルタントができなくなるかも…

・最初に言葉の説明

　ISO-9000s:品質(マネジメント)システム(QMS)
　ISO-14000s:環境(マネジメント)システム(EMS)
　ISO-17799(BS7799-P1):情報セキュリティ管理実施基準
　BS7799-P2:情報セキュリティマネジメントシステム(ISMS)
　と言われる様に、いわゆるISO(アイソ)のシステム基準には、マネジメントシステムが重要視されています。マネジメントシステムと言うのは、「方針及び目標を定め、その目標を達成するためのシステム」のことをさします。
　以前のISO-9000s(1994年版)は、製品の品質に関する規格が主でしたが、今度のISO-9000s(2000年版)は、会社の運営にまで及んでいます。そのため大きくなったせいか、1994年版ではうるさかった文書化の話は多少緩くなっています。
　だから、これからISOの認証を取得するというのは、経営者に一番負担がかかるのですが、それが理解できない経営者がまだ多いみたいです。
　また、ISOと一般に言っていますが、ISOの規格そのままだと日本では使いづらいところがあるため、ISOを日本で使えるようにしたJIS規格が存在します。
　ISO-9001:JIS-Q-9001
　ISO-14001:JIS-Q-14001
　ISO-17799:JIS-X-50807→2005年10月にISO-27002になりました。2006年4月にJIS-Q-27002になります。
　ISMS:JIS化されていません→2005年10月にISO-27001になりました。2006年4月にJIS-Q-27001になります。
　第三者審査機関と呼ばれるISO認証機関の審査員の人達は、実際には日本国内ではJISの規格で審査します。

お品書きへ、

・ソフトウェア開発に関係する規格一覧

お品書きへ、

・参考図書

お品書きへ、